制作事例 ｜ AI駆動開発の現場から
この記事は、収録した音声を、アップするだけで文字起こし・要点抽出・要約まで自動処理するツールを作った制作事例だ。非構造な"声"を、検索でき・読み返せる"読める資産"に変える。音声1本を4段のAIパイプラインに通し、月$26程度のコストで回している。設計とコスト判断ごと開示する。[1]
作ったきっかけは、ある人生インタビュー番組だった。毎週、ゲストが自分の人生で大切にしてきた「宝物」を語る——言葉、経験、一曲の音楽。心に残る話が毎回そこにあった。だが収録が終わると、その音声はフォルダの奥に積まれ、二度と聞き返されることなく眠っていく。流れて、消えていく。もったいない、と誰もが思っていた。この「聞き流されて消えるもの」を資産に変えるのが、このツールの目的だ。
この記事では、①なぜ音声は"消えて"しまうのか ②どう自動化したか（4段パイプライン）③長時間音声をさばくチャンク分割と、外部依存を捨てた設計判断 ④コストをどう$26に抑えたか——の順に見ていく。
01毎週の収録が、聞き流されて消えていく
ラジオやインタビューの収録は、その場では熱量がある。だが終わった瞬間から、音声は「探せない・読めない・思い出せない」の三重苦に陥る。30分の音声のどこに、あの良い言葉があったか。誰がいつ、何を語ったか。聞き返すには、また30分かける必要がある。だから、結局聞き返さない。
本当にもったいないのは、そこに「人生の宝物」が詰まっていることだ。ゲストが大切にしてきた言葉や経験——番組の核そのもの。それが、音声という"開けにくい箱"に閉じ込められたまま積み上がっていく。求められていたのは、収録したら、あとは勝手に整理されている状態。人が頑張って書き起こすのではなく、AIが自動で。だから、これは"声を資産化する工場"を作る話になった。
人の手で書き起こす選択肢もある。だが、毎週30分の音声を文字に起こし、要点を拾い、まとめる——これを毎回やり続けるのは、現実的でない。外注すれば費用がかさみ、自分でやれば時間が溶ける。どちらも「続かない」。番組は毎週来る。だから仕組みの方が、人の頑張りに頼らず毎回・自動で・同じ品質で回らなければ意味がない。「一度だけ頑張る」ではなく「ずっと楽に回る」を作る——これが工場という発想の出発点だった。
02何を作るか：声を、構造化された資産に変える
作ったのは、管理者がログインして使うダッシュボードだ。やることは、ただ一つ——収録した音声ファイルを、アップロードする。それだけ。あとはAIが裏で全部やる。
アップロードされた音声は、自動的に3つの成果物に変換される。① 文字起こし（全文テキスト、スクロールで読める）、② 宝物ワード（ゲストが語った「人生の宝物」を、引用元の発言つきで抽出）、③ 要約（3分で読める短いまとめ）。これらはエピソード単位で整理され、放送日・ゲスト情報・写真・放送後メモと一緒に、いつでも一覧・検索できる。「声」という非構造データが、読めて・探せて・引用できる構造化された資産に変わる。過去の全エピソードが、一元的なアーカイブとして積み上がっていく。
03AI処理パイプライン：4段の自動工程
「アップしたら全部やる」の裏側は、4段の自動パイプラインになっている。音声が来たら、人の手を一切介さず、順番に流れていく。
- ① 分割。長い音声はそのままだと処理できないので、扱えるサイズに切り分ける。
- ② 文字起こし。各かたまりをAIの音声認識にかけ、テキストに変換して結合する。
- ③ 宝物ワード抽出。全文をAIに読ませ、「これは人生の宝物だ」という発言を、引用元つきで拾い出す。
- ④ 要約。全文と宝物をもとに、3分で読めるまとめを生成する。
各工程の進み具合は、画面上でステータス（処理中・完了・エラー）として見える。途中で失敗しても、自動でやり直す仕組みと、手動の「リトライ」ボタンを用意した。アップロードした人は、待っていれば結果が揃う。裏側の複雑さは、すべて隠す。これが"工場"の発想だ。[2]
04「宝物ワード」を、AIに掘らせる
この工場の心臓は、「宝物ワード」の抽出だ。文字起こしや要約は、いまや珍しくない。だが「ゲストが語る人生の宝物を拾い出す」のは、その番組の価値そのものを、AIに理解させる仕事だった。
難しいのは、宝物が言葉とは限らないこと。ある人にとっては母の口癖、ある人にとっては学生時代の経験、ある人にとっては大切にしている一つのモノ。これらを、ただのキーワードとして拾うのではなく、「なぜそれが宝物なのか」が分かる発言の引用とセットで取り出す。だからAIへの指示（プロンプト）を、番組の文脈を踏まえて丁寧に設計した。抽出された宝物は、種類（言葉・経験・モノ）と、元の発言の引用つきで保存される。番組の"らしさ"を、構造化されたデータに翻訳する——ここに一番、頭を使った。
ここが、AIを「ただ使う」のと「作り込む」の分かれ目だ。文字起こしAPIを叩くだけなら誰でもできる。だが「この番組にとって宝物とは何か」を定義し、それをAIが安定して拾えるように指示を設計し、結果をデータベースの構造に落とし込む——この一連が、プロダクトとしての価値になる。汎用のAIを、その番組専用の道具に仕立てる。引用元の発言を必ず添えるのも、後から「本当にゲストがそう言ったか」を確かめられるようにするためだ。AIの抽出を鵜呑みにせず、人が検証できる形で残す——ここにも、誠実さの設計がある。
05大きな音声を、どう捌くか
派手ではないが、実務でいちばん効くのが「大きい音声をどう処理するか」だ。30分の収録は、ファイルにすると数十メガバイト。これをそのままAIに渡すと、サイズ制限に引っかかって弾かれる。さらに、文字起こしから要約まで一気にやると、処理が長すぎて途中でタイムアウトする。
そこで2つの工夫を入れた。1つはチャンク分割——音声を扱えるサイズのかたまりに切り、別々に文字起こししてから繋ぎ直す。もう1つはバックグラウンド処理——重い処理を、ユーザーを待たせる画面の裏側に逃がし、十分な実行時間を確保する。アップロードした人にとっては「アップしたら、しばらくして結果が出る」だけ。だが裏では、サイズの壁と時間の壁を、両方くぐり抜けている。表に出ない部分こそ、作りの差が出る。
06設計判断の現場：うまくいかない選択を、捨てる
制作事例として正直に書いておきたいことがある。最初に選んだ仕組みは、本番でうまく動かなかった。
当初、重いバックグラウンド処理は専用の外部サービスに任せる設計だった。理屈の上では正しい。だが本番で、その外部サービスの設定がうまく噛み合わず、AI処理が動かない事態に陥った。ここで取った判断は、こだわらず乗り換えること。外部サービスを丸ごとやめ、使っているフレームワーク自身が持つ「重い処理を後回しで実行する仕組み」に切り替えた。結果、依存パッケージが大きく減り、設定の噛み合わせ問題も消えて、本番が安定して動いた。「最初の設計が正しいとは限らない」「動かないものに固執しない」——AI駆動でも、この見極めは人間の仕事だ。うまくいかない選択を、勇気を持って捨てられるか。それが、本番で動くかどうかを分ける。[3]
外部サービスに頼ること自体が悪いのではない。問題は、「導入した」ことに満足して、本番で本当に動くかの確認を後回しにすることだ。今回も、本番で実際に音声を流して初めて「動かない」が見えた。だから私たちは、派手な機能より「本番環境で、最後まで通しで動くか」を最優先で確かめる。理屈で動くはずのものが、現実では動かない——その差を埋めるのが、制作の最後の、そして一番大事な仕事だ。シンプルな構成に寄せたことで、結果的に保守も楽になった。複雑さは、それ自体がコストになる。
07月いくらで回す：続けられるコスト設計
個人や小さなチームの番組で、もう一つ外せないのがランニングコストだ。どれだけ高機能でも、毎月の費用がかさめば続かない。だから最初から「月いくらで回るか」を設計の制約に組み込んだ。
具体的には、文字起こしも要約も、精度とコストのバランスが良い軽量なAIモデルを選んだ。データベースやファイル保管は、必要十分なプランに抑える。ホスティングや裏側の処理は無料枠で賄う。結果、月4本の収録を処理して、月額およそ$30以下に収まる設計になった。内訳を表に整理する。[4]
| 費目 | 月額 | 内容 |
|---|---|---|
| AI（文字起こし＋要約） | ~$1 | 精度とコストのバランスが良い軽量AIモデルを採用 |
| DB・保管 | $25 | データベース／ファイル保管を必要十分なプランに抑える |
| ホスティング・裏処理 | $0 | 無料枠で賄う |
| 合計 | ≈$26／月 | 月4本想定。目標$30以下をクリア |
※ 月4本の収録処理を前提とした試算（v0・利用量により変動）。
「作れる」と「続けられる」は別の問題だ。派手な機能を盛るより、毎月確実に・安く回り続けることを優先する。これも、使う人の現実に寄り添った設計だ。
08締め：流れて消えるものを、残す
この制作事例の本質は、「流れて消えていくものを、資産に変える」ことだ。毎週の収録、語られた言葉、その場限りの熱量——放っておけば積み上がって埋もれていくものを、AIが自動で拾い、構造化し、いつでも引き出せる形で残す。
文字起こしも、要約も、単体ではもう特別な技術ではない。価値が生まれるのは、それらを一つの流れに組み上げ、その番組ならではの「宝物」を取り出し、安く・確実に回り続ける形にまとめ上げたときだ。さらに、最初の設計が外れたら潔く乗り換える判断、大きな音声を裏で捌く工夫、月いくらで続けられるかの設計——表に出ない部分の積み重ねが、「使える工場」を作る。電脳技巧集団（AI職人ギルド）は、「言語化できるものは、全て作る」。声のように形のないものでも、言葉にできれば、残せる資産に変えられる。
聞き流して消える vs 資産として残す。AI駆動で、声の扱い方が変わる。
| 観点 | 従来（人力 or 放置） | AIコンテンツ工場（CAG） |
|---|---|---|
| 収録後の音声 | フォルダの奥で眠る | 自動で文字起こし・宝物・要約に変換 |
| 探す・読み返す | 30分かけて聞き直す | テキストで検索・3分で要約把握 |
| 番組の"宝物" | 記憶頼み・取りこぼす | 引用つきで自動抽出・データ化 |
| 運用の手間 | 毎回の書き起こし作業 | アップロードするだけ |
| 続けやすさ | 外注は高くつく | 月$30以下のコスト設計 |
| 蓄積 | バラバラに散らばる | 全エピソードが一元アーカイブ |
※ 本記事はCAGが実際に開発したAIコンテンツ処理ダッシュボードの制作事例。番組名・関係者名・固有の運用情報は伏せた匿名ケーススタディ。技術構成・設計判断・コスト試算は実際のものに基づく（v0・2026時点）。
脚注
- 本件は、ある人生インタビュー番組の収録音声を起点に、AIが自動で文字起こし・「人生の宝物」抽出・要約を生成し、エピソード単位で一元管理する管理ダッシュボード。番組固有の名称・人物は匿名化し、技術構成と設計判断を開示する。
- パイプライン＝音声の「分割 → 文字起こし → 宝物抽出 → 要約」を、人手を介さず順に流す自動処理の連なり。各工程はステータスで可視化し、失敗時は自動リトライ（指数バックオフ）＋手動リトライの二重で復旧する。
- 当初は外部のバックグラウンド処理サービスを採用したが、本番環境で設定が噛み合わず処理が起動しない問題が発生。フレームワーク（Next.js）標準の「レスポンス後に重い処理を継続実行する仕組み」へ移行することで、外部依存と設定起因の不具合を同時に解消し、依存パッケージも大幅に削減した。「正しそうな設計」より「本番で動く設計」を優先した判断。
- コストは、精度とコストのバランスが良い軽量AIモデルの採用、必要十分なデータベース/ストレージプラン、ホスティング/バックグラウンド処理の無料枠活用で構成。月4本の収録処理を前提に、月額およそ$30以下に収まる試算（v0・利用量により変動）。
「収録した音声・動画・会話が、活かせないまま溜まっている」——それ、資産に変えられます。
声や文章のような形のないものも、AIで構造化された資産に。まずは相談から——問い合わせは、AIがその場でお応えします。
無料で相談する →
