Case Study

2週間で技術検証から本番実装へ — 放送局LLMプロジェクトのスプリント設計

ケーススタディwildcard生成AIチーム8 min read

PoCやMVPの典型的な失敗は、「一度は動くものができたのに、検証と本番が分断されて止まる」ことです。本記事では、放送局のLLMによる映像メタデータ自動生成プロジェクトで、新機能を2週間で技術検証から本番実装まで接続した実例を、スプリント設計の実数とともに公開します。

Summary

この記事のポイント

  • Week 1は検証スプリント(10時間×4本)で、4つの新機能の技術リスクを潰す
  • Week 2は本番実装スプリント(40時間)で、テストを組み込み運用に耐える資産コードへ
  • 「スピード最優先の検証コード」と「運用に耐える資産コード」を最初から分ける
  • 単発のPoCではなく、約1年続くDevOpsの中でこのサイクルを繰り返している

プロジェクトの背景

このプロジェクトは、放送局の映像アーカイブに対してLLMでメタデータを自動生成するもので、約1年にわたりDevOpsを継続的に回してきた取り組みです。明示的なキーワードに依存せず、映像の状況や行為から文脈を理解してシーンを横断的に取得できる状態を目指しています(公開している技術例はWorks: 映像文脈検索を参照)。

課題は、新機能を追加するときの進め方でした。既存の大規模コードベースに手を入れるため、思いつきで実装を始めると影響範囲が読めません。かといって重い検証プロセスを挟むと、LLMの進化スピードに追いつけません。実装可能性を素早く見極め、検証から実運用までをスムーズに接続する仕組みが必要でした。

Week 1 — 検証スプリント(10時間×4本)

1週目は、技術検証だけを行うスプリントを4本回しました。

  • 1イテレーション = 10時間 に固定
  • 各スプリントで、Gemini による動画解釈、音声活用などの新機能候補を1つずつ検証
  • スプリントごとに最小限の核心課題を一つに絞る。「この方式で精度が出るか」「このAPIで処理が成立するか」など、外れたら方式を変えるべき問いだけを確かめる
  • 書くのはスピード最優先の検証コード。テストや設計の美しさは意図的に省略する

10時間という制約は、検証範囲を絞る強制力として機能します。10時間で確かめられない問いは、問いが大きすぎるか、分解が足りないかのどちらかです。

Week 2 — 本番実装スプリント(40時間)

2週目は、検証結果をもとにプロダクション実装へ切り替えました。

  • 1イテレーション = 40時間
  • 検証スプリントで方式が確定した機能を、既存コードベースに組み込む
  • テストを組み込み、デプロイ可能な状態に仕上げる
  • 書くのは運用に耐える資産コード。検証コードは参照するが、そのまま流用しない

PoCからプロダクションまでの期間で書いたコードは11,971行です。2週間という期間は、機能を薄くしたからではなく、1週目でリスクを潰し切り、2週目を「分かっていることの実装」に専念させた結果です。

なぜ2週間で接続できたのか

検証コードと資産コードを最初から分けた

このプロジェクトの核心は、捨てる前提のコードと育てる前提のコードを混ぜないことです。

観点検証コード(Week 1)資産コード(Week 2)
目的核心課題への答えを出す実運用で価値を出し続ける
品質動けばよいテスト・エラー処理・運用込み
寿命スプリント内で使い捨て既存コードベースの一部になる

検証コードを「もったいないから」と本番に流用すると、修正のたびに障害が増え、結果的に高くつきます。逆に最初から本番品質で検証すると、外れた方式にも実装コストを払うことになります。この分離はMVPの要件定義で開発前に合意しておくべき項目です。

核心課題を一つに絞った

4つの機能を1週間で検証できたのは、各スプリントの問いを一つに絞ったからです。「動画解釈が使えるか」を丸ごと確かめるのではなく、判断を左右する核心だけを検証します。この絞り込みは、PoCとMVPの順番で解説している「致命的な技術リスクだけを先に確認する」考え方の実践です。

検証と本番を同じチームが担った

検証チームと開発チームが分かれていると、検証結果の引き継ぎだけで数週間かかることがあります。同じチームが検証と本番実装を連続して行うことで、学びが直接コードに反映されます。

この事例から一般化できること

  1. PoCの速さは時間制限から生まれる — 10時間×4本という箱を先に決めると、問いの分解が強制される
  2. 「捨てるコード」と「育てるコード」の区別が、検証と本番の分断を防ぐ — 分断の原因は組織やツールより、この設計の欠如であることが多い
  3. 検証は単発イベントではない — このプロジェクトでは約1年のDevOpsの中で検証→本番のサイクルを繰り返している。1回のPoCで終わらせない体制が、LLMの進化に追従する条件になる

MVP開発全体の進め方はMVP開発とは、他の実例はMVP開発の事例3選で公開しています。プロジェクトの支援内容は10X BUILDをご覧ください。

FAQ

よくある質問

どんな案件でも2週間で本番実装まで進めますか

いいえ。この事例は、既存のDevOps基盤と約1年の運用実績の上で、新機能の追加を2週間で接続したものです。ゼロからの構築では、基盤づくりを含めた期間設計が必要です。タイプ別の実績期間はMVP開発の期間を参照してください。

検証スプリントの成果物は何ですか

「この方式で進めてよいか」への答えです。動くデモではなく、核心課題への判断材料(精度・処理成立性・コスト感)を成果物として扱います。デモの見栄えに時間を使わないことが、10時間で検証できる条件です。

プロジェクトについて教えてください