動画広告の字幕・テロップを、原稿と表記ルール・注釈の指定に照らして、誤字・表記ゆれ・注釈の抜けを納品前に点検する

処理の起点を決める

案件フォルダの「点検待ち」に動画が置かれたことを起点にします。 編集所からの納品は、修正のたびに版が上がって何度も届きます。1日1回まとめて点検すると、修正の往復が1日ずつ延びます。 置かれた時点で1本ずつ動かします。

起点を「編集所から届いたとき」ではなく、担当者が「点検待ち」に置いたときにしているのは、届いたものすべてが点検の対象ではないからです。仮の編集や、広告主に見せる前の試写用のものまで流すと、指摘の一覧が意味のないもので埋まります。

処理が終わったら、動画を「点検済み」へ移します。移すのは一覧の作成まで成功したときだけです。 「点検待ち」に残っている本数が、そのまま未処理の本数になります。

入力データを集める

質を決めるのは、注釈の指定です。 「満足度No.1」に「※2026年○月 当社調べ」を付ける、と対応表になっていれば、AIは強調表示を見つけたときに何を探せばよいかが分かります。対応表がなければ、注釈が抜けているかどうかを判定できません。

前の版の点検結果は、尺違いの確認に使います。 30秒の版で出ていた注釈が、15秒の版で消えていないか。同じ企画のなかで比べると、第3章の（a）が見つかります。

データの取得方法を決める

動画は Files API に上げ、返ってきたファイルの参照を使って Gemini API を呼びます。アップロードのあと、処理が終わるまで待ってから呼ぶ手順は公式の例にもあります。

1回目は動画全体を既定に近い設定で読み、2回目は疑いのある区間だけを細かく読みます。 全体を最初から細かいコマ間隔で読むと、テロップの少ない場面までトークンを使います。細かく読むのは、確かめる必要がある数秒だけにします。

テロップの小さい文字を読むために、メディアの解像度を上げます。 解像度を上げると細かい文字や小さな部分を読み取る力が上がる一方、トークン数と待ち時間が増えるとされています。注釈は画面の隅に小さな文字で出ることが多いので、この用途では解像度を上げる側に倒します。

AIへ渡す前に整形する

1. そろっているかの確認 … 確定原稿・表記ルール・注釈の指定のどれかが無いときは、読み取りを始めずに担当者へ戻します
2. 形式の確認 … mp4 や mov など、対応している動画の形式であることを確かめます
3. 版の確認 … ファイル名から案件番号・尺・媒体・版の番号を取り、原稿の版と合っているかを確かめます
4. 原稿の分解 … テロップ原稿を画面ごとの文言に分け、ナレーション原稿を文ごとに分けます
5. 注釈の対応表の展開 … 強調表示の文言と、付けるべき注釈の文言を1行ずつの組にします
6. 表記ルールの展開 … 「お客様→お客さま」のような置き換えの組と、商品名の正しい表記を一覧にします
7. 同じ企画の前の版の取得 … ほかの尺・前の版で検出された注釈の一覧を引きます

3番目を軽く見ないでください。 修正前の原稿と修正後の動画を比べると、直したはずの箇所がすべて「食い違い」として出ます。 版のずれは、指摘の一覧を一番早く信頼できないものにします。

AIに処理させる

1回目にさせるのは、動画に出ている文字と聞こえる言葉を、時刻付きでそのまま書き出すことです。 原稿と照らすのはそのあとです。書き出す段階で原稿を見せると、原稿に引きずられて「正しく読めた」ことにしてしまうからです。

右端の列の not_detected が、この構成でいちばん大事な区別です。 1回目で見つからなかったというのは、「動画に無い」ではなく「1回目の読み方では拾えなかった」ということです。区間を切り出し、コマの間隔を細かくして読み直し、それでも無いものだけを missing にします。

2回目の読み直しで見つかったものは、表示時間が短い可能性が高いと考えます。 1秒に1コマで拾えなかったということは、出ている時間が短いか、画面の隅で小さいかのどちらかです。抜けではなくても、出し方の確認が要るものとして一覧に残します。

3行目がいちばん起きやすい失敗です。 小さくて読めないテロップを、原稿の文言で補って書き出すと、その瞬間、原稿と動画が一致したことになります。 1回目の書き出しに原稿を渡さない理由がこれです。

指示内容を固定する

1回目（書き出し）の指示：

あなたは動画広告の納品前の点検を手伝う立場です。
この動画に出ている文字と、聞こえる言葉を、時刻付きでそのまま書き出してください。
原稿は渡しません。見えたもの・聞こえたものだけを書いてください。

【書き出すもの】
1. テロップ・字幕・注釈など、画面に出ているすべての文字
   - 出始めと出終わりの時刻を MM:SS で
   - 画面のどこに出ているか（上・中央・下・隅）
   - 文字の大きさの目安（大・中・小）
2. ナレーションと、登場人物のせりふ
   - 文ごとに、話し始めの時刻を MM:SS で

【厳守事項】
- 読めない文字を推測で埋めないでください。読めない部分は status を
  unreadable とし、読めた部分だけを text に入れてください。
- 聞き取れない言葉を推測で埋めないでください。status を unclear にしてください。
- 誤字に見えても、画面に出ているとおりに書き写してください。
  正しい書き方に直さないでください。
- 「お客様」「お客さま」のような表記の違いも、出ているとおりに書いてください。
- 同じ文字が続けて出ている場合は、1件として出始めと出終わりを書いてください。
- 商品の画像に写っている文字（パッケージの印字など）は、kind を package にして
  テロップと分けてください。
- 文字の内容が正しいか、広告として適切かは書かないでください。

2回目（区間の読み直し）の指示：

この区間に、次の文字が出ているかを確かめてください。
【探す文字】{expected_note}
出ていれば、出始めと出終わりの時刻と、画面のどこに出ているかを書いてください。
一部だけ読める場合は、読めた部分だけを書き、status を partial にしてください。
出ていなければ found を false にしてください。
似た文字を見つけても、同じ文字として扱わないでください。

「正しい書き方に直さない」を明記しないと、誤字を直して書き出します。 生成AIは自然な日本語を返そうとするので、「お問合わせ」を「お問い合わせ」に、「¥1,980」を「1,980円」に整えます。整えた瞬間、点検の材料が消えます。

2回目の指示で「似た文字を同じ文字として扱わない」と書いているのは、注釈の文言が少しだけ違う場合を拾うためです。 「※当社調べ」と「※2026年○月 当社調べ」は似ていますが、調査時期の抜けは注釈の抜けと同じくらい重い指摘です。

出力形式を固定する

1回目の書き出しは、次の形のJSONで受け取ります。 Gemini API の構造化出力で JSON スキーマを渡し、この形を守らせます。

{
  "video_id": "",
  "duration": "00:30",
  "captions": [
    { "start": "00:04", "end": "00:06", "text": "", "kind": "telop | subtitle | note | package",
      "position": "top | center | bottom | corner", "size": "large | medium | small",
      "status": "ok | unreadable" }
  ],
  "narration": [
    { "start": "00:03", "text": "", "status": "ok | unclear" }
  ]
}

照らし合わせたあとの指摘の一覧は、Python が次の形で作ります。

{
  "video_id": "",
  "script_version": "",
  "findings": [
    { "time": "00:05", "type": "typo | style | note_missing | note_partial | note_short | note_separate_screen | narration_diff",
      "found": "", "expected": "", "rule": "", "evidence": "" }
  ],
  "re_read": [
    { "range": "00:04-00:08", "expected_note": "", "result": "found | partial | not_found" }
  ],
  "summary": { "typo": 0, "style": 0, "note_missing": 0, "needs_review": 0 }
}

1つ目の理由は、書き出しと指摘を別の層に置けることです。 captions と narration は動画に何があったかの記録、findings は原稿と照らした結果です。表記ルールが変わっても、書き出しをやり直す必要はありません。

2つ目は、時刻で動画に戻れることです。 time を見て、その数秒だけを再生すれば確認が終わります。頭から見直す必要がありません。

3つ目は、re_read に読み直しの経緯が残ることです。 1回目で見つからず、2回目で見つかった注釈は note_short の候補として残します。「抜けではないが、出ている時間が短いかもしれない」という指摘は、この記録がないと出せません。

システムへ連携する

編集所へは、この構成から直接送りません。 指摘の一覧は担当者が見て、直すものだけを選んで依頼します。自動で送ると、取りこぼしによる誤った指摘まで編集所に届きます。

通知には note_missing の件数を必ず入れます。 誤字は後でまとめて直せますが、注釈の抜けは、そのまま納品すると広告主にとって重い問題になります。 件数が1以上の動画を、担当者が最初に開けるようにします。

人が確認する

人が見るのは、指摘の一覧と、指摘のある数秒の動画だけです。 動画を頭から見直す設計にすると、第10章の20.0時間には収まりません。

1. note_missing と note_partial を最初に見る … 指摘の時刻の前後を再生し、本当に注釈が無いかを目で確かめます
2. note_short と note_separate_screen を判断する … 表示秒数と配置を見て、広告主の基準に照らして直すかを決めます
3. typo と style を確かめる … 原稿と動画の該当箇所を並べて見ます
4. 直すものを選んで編集所へ依頼する … 一覧から選び、時刻を添えて送ります
5. 指摘を覆したら記録する … どの指摘を、なぜ直さなかったかを残します

2番目は人にしかできません。 消費者庁の資料は、動画広告で打消し表示が含まれる画面の表示時間が短い場合や、強調表示と別の画面に表示されている場合に、一般消費者が正しく認識できないおそれがあることを示しています。ただし、何秒なら足りるかは文字数や画面の情報量も勘案されるとされ、一律の秒数ではありません。 AIは秒数を測るところまでで、足りるかどうかは広告主の基準と担当者が決めます。

目標は、120本をならして1本10分です。 指摘が数件の動画は数分で終わり、注釈の確認が要る動画は時間がかかります。10分を大きく超える月は、原稿の版のずれか、注釈の対応表の不足を疑います。

例外に対処する

上から2行目までが最も多く起きます。 どれもAIの問題ではなく、原稿と動画の受け渡しの問題です。 案件フォルダの置き方を決めるほうが、読み取りの精度を上げるより効きます。

記録を残す

• 点検した動画の案件番号・尺・媒体・版の番号と、照らした原稿の版
• Gemini API が返した書き出しのJSON（captions、narration）
• 区間の読み直しの記録（re_read）と、そのときの設定
• 指摘の一覧（findings）と、担当者が覆した指摘とその理由
• 編集所へ依頼した修正と、次の版で直ったかの確認
• 広告主ごと・編集所ごとの指摘の種類別の件数

4つ目で「覆した理由」を残すのは、表記ルールの側を直すためです。 同じ style の指摘が毎回覆されるなら、ルール集のほうが実態に合っていません。

最後の行は、編集所との打ち合わせの材料になります。