暗いビデオから構造化された資産へ：時間ベースのメタデータパイプラインの構築

放送局、スポーツリーグ、メディア企業、エンタープライズプラットフォームは、ペタバイト規模のビデオアーカイブを抱えています。そのコンテンツの大部分は、私たちがダークビデオと呼ぶものです。つまり、存在はしていても、検索できず、構造化されておらず、意味のレベルで操作することができない状態です。

その理由は、きわめてシンプルです。ビデオはテキストではないからです。ビデオファイルを grep することはできませんし、SELECT * FROM video WHERE scene = 'scoring_play' のような言語体系は存在しません。ビデオが経済的価値を持つためには、まず構造化されたセグメントと機械可読なメタデータに分解される必要があります。私たちはこれをビデオのアセット化（資産化）と呼んでいます。

この記事は、私たちがTime-Based Metadata（TBM）とその評価システムをどのように構築してきたかを紹介するストーリーです。その過程で、時間軸に基づくビデオ理解を設計および評価するには、テキストモデルや画像モデルで有効なアプローチとは異なるアプローチが必要であることが明確になりました。

1. アセット化のギャップ：顧客が真に望んでいること

20万時間のニュースアーカイブを管理する放送局を思い浮かべてみてください。現在、その作業は手作業で行われています。アーキビストが各セグメントを手動で記録し、ストーリーにタグを付け、発言者を特定し、トピックの境界線をマークしています。ビデオ1時間あたりにおよそ15ドルのコストがかかり、予算は縮小傾向にあります。これでは到底スケールしません。

あるいは、数千本ものインフルエンサービデオの中から、自社製品のプロダクトプレイスメントを追跡しようとしているCPG（消費財）ブランドを例にとってみましょう。彼らは、製品が画面に映っている間にクリエイターがカメラに向かって話しているすべての瞬間を必要としています。製品が登場したことを知るだけでは不十分で、いつ、どれくらい目立つ形で、どのような文脈で登場したのかを正確に知る必要があります。

これらは仮定の話ではありません。放送アーカイブの管理、スポーツハイライトの自動生成、ブランドインテリジェンス、コンプライアンス監査など、私たちが遭遇するエンタープライズビデオのワークロードのほぼすべてが、次の2つの独立した要素を同時に要求します。

1. 正確な時間的境界：各セグメントはどこで始まり、どこで終わるか？

2. スキーマに適合した構造化メタデータ：そのセグメント内で何が起きたか？

今日のほとんどのビデオ言語モデルに「このビデオで何が起きているか？」と尋ねれば、流暢な文章が返ってくるでしょう。しかし、「トピック、発言者、信頼度の構造化されたフィールドを含む、すべての編集ナラティブの開始/終了タイムスタンプ」を求めた瞬間、汎用的なビデオ推論とプロダクションレベルのセグメンテーションが、まったく異なる問題であることにすぐに気づくはずです。

放送局がアウトプットとして実際に必要としているのは次のようなものです。各編集セグメントには、タイトル、説明、編集対象、主要なエンティティ、および信頼度（confidence）が必要です。1時間のニュース番組の場合、TBMは以下のようなものを出力します。

各セグメントには、editorial_subjects（編集対象）、visual_subjects（視覚対象）、names（名前）、confidence（信頼度）といった構造化メタデータが含まれます。この瞬間、1時間の番組が検索可能なオブジェクトのセットに変換されます。

2. 既存のアプローチが不十分な理由

境界予測の問題

大規模言語モデルは、要約、Q&A、コンテンツ記述など、特定のタイムスパンにわたる推論に優れています。しかし、セグメントの境界線がどこにあるかを予測することは、全く異なる種類のタスクです。

境界予測は、次の3つの難解な問題の交差点に位置しています。

• 弱教師あり時間的ローカリゼーション：グラウンドトゥルース（正解データ）が疎であり、主観的であること。

• マルチモーダルな変化点検出：境界線は、視覚、音声、セマンティックシグナルの同時変化によって定義されること。

• 自己回帰デコーディングにおけるトークンレベルの分類：モデルが正確なタイムスタンプをトークンとして出力しなければならないこと。

私たちの初期の実験では、最先端のモデルであっても、文脈上は理にかなっているものの、時間的にズレている境界を出力しました。本来はハードカットで始まるべきセグメントが5〜15秒ほど流れてしまうのです。モデルは何が起きているかは理解していましたが、それがいつなのかをピンポイントで特定できませんでした。

スキーマがなければ、アセットとは言えない

ほとんどのビデオ言語モデルは、自由形式のテキストを生成します。

「このビデオはニュース番組を示しています。2分経過したあたりで、スポーツのコーナーに切り替わります...」

これは人間が読むには便利ですが、後続の自動化処理にはほとんど役に立ちません。エンタープライズワークフローが実際に必要としているのは、以下のようなデータです。

{
  "start_time": 120.45,
  "end_time": 245.80,
  "metadata": {
    "segment_title": "NFLプレーオフ要約",
    "editorial_subjects": ["NFL", "プレーオフ", "怪我レポート"],
    "names": ["パトリック・マホームズ", "ラマー・ジャクソン"],
    "confidence": "HIGH"
  }
}

表現豊かなプレーンテキストと、機械可読な構造化出力の間のギャップは、単なるフォーマットの問題ではありません。これは、モデリングと評価の問題が複雑に絡み合った結果です。

3. 私たちのアプローチ：スキーマ条件付きの時間的抽出

どの問題を解決するかを選択する

私たちがTBMの設計に着手したとき、岐路に立たされました。ビデオを受け取ってそれに関するあらゆる質問に答える、多機能の中の一つの機能としてセグメンテーションを持つ「汎用モデル」を作るべきか？それとも、ビデオとユーザー定義のスキーマを受け取り、そのスキーマで指定された通りに正確にセグメントとフィールドを埋める「スキーマ条件付きの抽出モデル」を作るべきか？

最初は前者の選択肢が自然に思えました。しかし、セクション2で挙げた失敗パターン（曖昧な境界、自由形式のフィールド、実行ごとの出力のブレ）は、汎用的な枠組みが持つ構造的な限界であることが判明しました。スキーマがなければ、モデルは何を探すべきか、どれほど正確に特定すべきかを知る術がなく、評価も「尤もらしく聞こえるか？」というレベルに留まってしまいます。

そこで、私たちは後者を選択しました。TBMは、何でもできる汎用モデルではありません。正確な時間的境界とスキーマに適合するメタデータの抽出に特化した抽出モデルです。

スキーマ条件付けがもたらす実際のメリット

TBMでは、ユーザーが segment_definitions（どのセグメントを検出し、そこからどのメタデータフィールドを抽出するかを定義した構造化された仕様）を提供します。これは単に便利なAPIの設計というだけではありません。モデリングの観点から見ると、スキーマ条件付けは以下の3つの効果をもたらします。

探索空間の縮小。 ビデオのあらゆる側面について自由形式の自然言語を生成する代わりに、モデルはスキーマによって定義された境界のある出力空間の内部で動作します。スポーツ放送であれば、down（ダウン）、scoring_play（得点プレー）、penalty_type（ペナルティの種類）を指定するだけで十分です。もっともらしくても無関係な観察の広大なスペースは切り捨てられます。

境界アライメントの安定化。 モデルは何を探しているのか（「プレーの境界線」なのか「広告への切り替え」なのか）を認識すると、ジェネリックな変化点検出のヒューリスティクスに頼る代わりに、ホイッスル、フォーメーションの変化、フェードアウトのパターンといったドメイン固有の時間的手がかりを活用できるようになります。

評価の基準化。 各スキーマフィールドが具体的で測定可能な評価対象になります。「モデルはビデオを理解したか？」という曖昧な質問に代わり、「モデルはこのセグメントの down フィールドが 3 であると正確に特定できたか？」を問いかけることができます。

4. カバー範囲の広さ：4つのTierからなるキュー（手がかり）システム

スキーマ条件付けを実際に機能させるには、スキーマがどのような種類のシグナルに対応しているかを知る必要があります。ビデオセグメンテーションを困難にする要因の一つは、境界を定義するシグナルの種類が多岐にわたることです。カメラアングル切り替えのようなフレームレベルの視覚的変化、ニュース編集パッケージの構造的な移行、話者交代のような音声の手がかり、そしてこれら視覚、音声、ゲームのルールを組み合わせたスポーツの複合イベントなどが挙げられます。単一のアプローチでこれらすべてを処理することは不可能です。

私たちは、この多様性を以下の4つの手がかり（キュー）Tierに分類しました。

この分類が重要である理由

一般的なビデオモデルは、これらのTierを区別しません。しかし、実際の顧客のセグメンテーションニーズは、特定のTierやそれらの組み合わせに明確に対応しています。

• 放送局の「個別の編集ナラティブ」 → 高レベル（トピック移行 ＋ 編集パッケージ境界）

• 編集チームの「カット境界検出」 → 低レベル視覚（カメラカット、アングル変更）

• スポーツリーグの「プレーごとのセグメンテーション」 → 複合（フォーメーション ＋ ホイッスル ＋ ゲームルール）

• ポッドキャストプラットフォームの「話者セグメント化された文字起こし」 → 音声（話者交代 ＋ ASRトピック変化）

これは単なる分類のための分類ではありません。Tierごとに、異なるモデリング戦略、トレーニングデータ、および評価指標が必要です。「低レベル視覚」はフレームごとの変化検出に近く、「複合」は長いコンテキストでの推論を必要とします。

5. マルチモーダルグラウンディング：テキストを超えて

エンタープライズ向けビデオセグメンテーションを行う中で、私たちが繰り返し直面する制限があります。それは、テキストだけでは何を探せばよいかを指定できないことが多いという点です。

テキストが十分ではない理由

旅行コンテンツプラットフォームを例に挙げてみましょう。彼らが解決したい問題はこうです。

ソウルを訪れた外国人観光客が作成した何万本ものVlogから、「Nソウルタワー」が画面に映っているすべての瞬間を見つけ出したい。そして、それが漢江や街のスカイラインから撮影した遠景の状況設定カットなのか、南山公園を歩いている途中のカットなのか、展望台からの接写なのか、あるいは夜間のライトアップなのかを分類したい。

テキストだけでは対応できません。モデルが「Nソウルタワー」という名前を知っているからといって、そのビジュアルデザインを高い信頼度で自律的に識別できるとは限りません。言語による認識と、特定のエンティティの視覚的同定は、動画言語モデルにおいては別の問題です。トレーニングデータの偏りによっては、視覚的な表現が曖昧になったり、東京タワーやCNタワーのような見た目が似ている別の電波塔と混同してしまう可能性があります。しかし、Nソウルタワーの参照画像を1枚提供すれば、モデルはビデオフレームと直接比較するための視覚エンベディングの基準（アンカー）を得ることができます。「テキストをビジュアルに翻訳する」という負担が解消されるのです。

エンティティリファレンスシステム

TBMは media_sources をサポートしています。セグメント定義の中に <reference_name> タグを挿入すると、モデルは文章からユーザーが登録した参照画像を直接指定することができます。

出典：世宗学堂財団（KSIF）

{
  "segment_definitions": [{
    "id": "namsan_tower_appearances",
    "media_sources": [
      { "name": "namsan_tower_img", "media_type": "image", "media_url": "<https://cdn>.../namsan_tower.jpg" }
    ],
    "description": "<namsan_tower_img> で特定されるNソウルタワーが画面に表示されているシーン",
    "fields": [
      { "name": "screen_prominence", "type": "string",
        "enum": ["HERO_SHOT", "PARTIAL", "BACKGROUND"] },
      { "name": "shot_type", "type": "string",
        "enum": ["CITY_ESTABLISHING", "PARK_WALK", "OBSERVATION_DECK", "NIGHT_LIGHTUP"] }
    ]
  }]
}

モデリングの観点から見ると、これによりセグメンテーションはオープンボキャブラリーの検出問題から、位置特定に紐付けられた検索 (Grounded Retrieval) ＋ 時間的ローカリゼーションの問題へと再構成されます。

1. 参照の解決 (Reference Resolution)：モデルはビデオ全体を通じて、<namsan_tower_img> を特定の視覚パターンに結びつける必要があります。

2. 視覚エンベディングのアライメント：参照画像は、ビデオフレームと同じ表現空間にエンコードされます。

3. 条件付き境界検出：一般的なシーンの切り替えではなく、特定の視覚エンティティの同時出現によってセグメント境界決定が判断されます。

これが、「都市景観のカットを探す」と「Nソウルタワーが映っているカットを探す」の違いです。これは技術的な難易度の差ではなく、プロダクトが実際にどのような問題を解決しているかの違いです。

エンティティの紐付けが導入されると、セグメンテーションの失敗軸は、時間的境界、セマンティックラベル、視覚エンティティの同定の3つに増えます。これにより、評価の問題にさらなる次元が加わります。

6. 品質保証：デュアルトラック評価

TBMを運用する中で得られた最も決定的で、かつ最も直感に反する知見は、セグメンテーションの品質を単一のスコアで評価することはできない、ということでした。

隠れたカップリング（密結合）問題

以下の2つの失敗シナリオを比較してみましょう。

シナリオA。 モデルが「10.0秒〜25.0秒」のセグメントを出力。正解データ（グラウンドトゥルース）は「12.0秒〜48.0秒」でした。モデルはキャスターの15秒間の導入部分を捉えましたが、その後に続く本編の23秒間を丸ごと見落とししました。キャスター名、トピック、発言者タグはすべて完璧でしたが、時間的境界は実際のコンテンツの3分の1しかカバーできませんでした。

シナリオB。 モデルは「12.0秒〜48.0秒」を正確に突き止めました。しかし、「政治分析」を「気象情報セグメント」と誤認識してタグ付けしてしまいました。境界は完璧でしたが、メタデータが正しくありません。

単一の総合スコアでは、これら2つのケースを区別できません。しかし、修正に必要なアクションは全く異なります。前者は時間的モデリングの改善を必要とし、後者はセマンティックアライメントの強化が必要です。これらの失敗モードを分離しなければ、モデルの改善が実際に効果をもたらしたのかどうかを判断することすらできません。

私たちの解決策：2つの独立した評価トラック

セグメントトラック：「モデルは正しいインターバル（区間）を見つけられたか？」

時間的正確さを測定します。セグメントレベル（個々のインターバルがどれだけ捉えられているか）とタイムラインレベル（タイムラインのどの部分が正しくカバーされているか）の両方を評価します。これらは、一方が優れていても、もう一方が劣ることがあるため両方が重要であり、どちらの側面が失敗しているかによって、解決すべき問題が特定できます。最終的な比較では、両方の視点を組み合わせた総合スコアを主要指標として使用します。

メタデータトラック：「正しいインターバル内において、モデルは正しく構造化できたか？」

セグメントがマッチした後、一致したセグメントペア内で各フィールドを個別に評価します。フィールドタイプに特化したガイドラインのもと、LLM評価者（LLM-as-judge）を0.0〜5.0のスケールで適用します。

さらにもう一つの工夫。 境界の精度が狭く合致しているほど、フィールドスコアの重みが高く設定されるようにします。これにより、境界自体の抽出がルーズであるにも関わらず、「一見正しく見える」メタデータによって総合スコアが水増しされるのを防ぎます。

副次的なメリット。 メタデータの評価は推論から分離されたポストプロセス（後処理）として実行されるため、時間とコストのかかるビデオ推論自体を再実行することなく、LLM評価者の基準（プロンプトや採点基準）を迅速にイテレーション（反復適用）することができます。

この分離が重要である理由。 セグメントスコアが改善しているのに、メタデータスコアが低下した場合、それは「時間的ローカリゼーションは改善したが、セマンティックの精度は低下した」というシグナルになります。この場合の解決策は、モデルのアーキテクチャを見直すことではなく、トレーニングデータのバランス調整です。これは、トラックを分離しているからこそ診断可能になります。

7. セマンティック・フライホイール：アセット化がもたらす複利効果

アセット化は一度きりの作業ではありません。ひとたび機能し始めると、改善がさらなる改善を生む自己強化ループに入ります。

私たちはこれをセマンティック・フライホイール（Semantic Flywheel）と呼んでいます。放送アーカイブ、ブランドインテリジェンス、コンプライアンス監査、スポーツハイライトの自動作成など、TBMで実行されるワークロードはそれぞれ異なる領域に属していますが、すべて同じ軌跡をたどります。セグメントとメタデータのペアが蓄積されるにつれ、顧客が修正した境界、拒否されたタグ、編集されたフィールドなどの利用ログデータが、次世代モデルのトレーニングシグナルとなります。この回転が始まれば、アーカイブは単に「整理される」だけでなく、自転を通じてより精微に整理されるシステムへと進化していきます。

このフライホイールを回転させるための唯一の前提条件は、「改善が観測可能であること」です。時間軸の正確性とメタデータの正確性を別々に測定できなければ、どちらが改善し、どちらが後退しているのかを判断できません。方向性がなければ体系的なイテレーションは不可能であり、それができなければフライホイールは停止します。アセットの構造を忠実に反映した評価システムがなければ、アセット化は一時的なギミック（一発芸）で終わってしまうのです。

8. 私たちが学んだこと

TBMとその評価フレームワークの構築から得られたいくつかの教訓を共有します。

セグメンテーションはQ&Aではない。 時間的セグメンテーションを「他の数あるLLMタスクの一つ」として捉えようとした初期の直感は、私たちをしばらくの間、非生産的な方向へ導いてしまいました。境界予測は、異なる失敗モード、異なる評価要件、そして異なるモデルアーキテクチャへの感度を持っています。このことに早く気付いていれば、何ヶ月もの時間を節約できていたでしょう。

構造化出力は、流暢な出力に勝る。 実際の運用においては、境界がわずかに大雑把であるものの完璧に構造化されたJSONセグメントの方が、構造化されたフィールドを持たない美しいプレーンテキストよりも遥かに有用です。「人間にとっての読みやすさ」よりも「機械可読性」を優先させた判断は、結果として大正解でした。

決定論的（デターミニスティック）であることは、制約ではなく機能である。 非重複セグメント、厳格なスキーマへの適合、temperature=0をデフォルトとする設定など、これらの制約は当初、「モデルの可能性を狭めている」として反発を招きました。しかし実際には、これらこそが本番運用の自動化システムにおいて信頼できる出力を担保するものとなりました。顧客がAPIの上にシステムを構築する際、機能の高さよりも信頼性の高さの方が勝るのです。

今後の展開

ビデオのアセット化はまだ始まったばかりです。より長いコンテキスト（3時間以上）、より豊かなマルチモーダル条件付け（数十枚の参照画像を持つ複数のエンティティ）、そしてこの「構造化抽出」のアプローチを動画だけでなく音声やポッドキャストなどの他のパッケージ化されたアセットへ拡張すること。これらが次のロードマップです。

しかし、最大の挑戦は、モデルの進化スケールに追従できる評価フレームワークを構築することです。ビデオ言語モデルが高性能になるにつれ、失敗モードはより微細になり、それを追う評価システムもより鋭敏である必要があります。

大半のエンタープライズビデオアーカイブは、依然として手つかずのまま眠っています。そこから価値を引き出すことは、単に優れたモデルを構築することだけではありません。モデルが実際に「正しい瞬間を見つけているか」、そしてそれを「正しく表現できているか」を測定できるようになること。それこそが、鍵なのです。