広告会社の制作担当が動画広告の絵コンテ・台本を Gemini で点検し、打消し表示の抜け・表示時間の短さ・根拠の要る表現の候補を考査に出す前に挙げる

処理の起点を決める

案件のフォルダの「点検に出す」にファイルが保存されたことを起点にします。 プログラムは15分ごとに動き、前回から増えたファイルだけを処理します。夜間にまとめて処理する形にはしません。 絵コンテは打合せの直後に直され、その日のうちに広告主に出すことが多いからです。

点検は版ごとに行います。 絵コンテの初版、広告主の修正を反映した版、仮編集の映像の3回が基本です。ファイル名に版の番号を付ける決まりにし、プログラムは同じ案件の前の版の結果を一覧で並べます。前の版で出た確認する点が直っているかを、制作担当が見られるようにします。

処理が終わったファイルは「点検済み」へ移します。 移すのは一覧への書き出しが成功したときだけです。「点検に出す」に残っている数が、そのまま未処理の数です。

入力データを集める

質を決めるのは、局内の基準の書き方です。 「強調表示に当たる言葉」「打消し表示の型」「根拠の確認が要る表現」を例つきで並べた文書にし、Gemini への指示にそのまま入れます。 打消し表示の型は、消費者庁の資料にある例外型・別条件型・追加料金型・試験条件型の分け方を見出しにすると、漏れなく並べられます。

読み終えられるかの目安は、局内で決める数字です。 資料では、打消し表示が含まれる画面の表示時間が適切かは、表示されている時間に加えて、その画面に含まれる強調表示や打消し表示の文字数等も勘案されるとされています。公的な秒数の基準が示されているわけではないので、 局内で「1秒あたり何文字まで」の目安を決め、プログラムの設定に置きます。

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

プログラムは、案件のフォルダを読むだけです。 絵コンテと台本と映像を取り、案件シートから業種・媒体・尺と根拠資料の受領状況を読みます。

絵コンテは、PDF をそのまま渡します。 テキストを抜き出してから渡すと、コマの絵の中に描かれた文字と、テロップの欄の位置関係が失われます。 公式の案内では、PDF に埋め込まれた文字は抜き出されてモデルに渡されるとされており、画として読む分と文字として読む分の両方が使えます。

映像は Files API で上げてから参照します。 公式の案内では、上げたファイルは48時間保持されます。点検が終われば使わないので、 プログラムは処理後に削除します。

AIへ渡す前に整形する

1. ファイルの種類と大きさを確かめる … 絵コンテは PDF（50MB・1000ページまで）、映像は mp4 などの動画の形式です。範囲外は制作担当に戻します
2. 絵コンテの欄を確かめる … 1ページ目にカット番号・秒数・テロップ・ナレーションの欄があるかを、最初の呼び出しで返させます。欄が無い書式の絵コンテは点検しません
3. 台本と絵コンテの尺を照らす … 台本の尺と、絵コンテの秒数の合計が違えば、一覧の先頭に書きます
4. 映像の取り出しの間隔を指定する … 仮編集の点検では、1秒に1フレームより細かく指定します
5. 同じ案件の前の版を探す … ファイル名の版の番号から、前の版の結果を引きます

2番目を最初に置くのは、欄の無い絵コンテで判定させないためです。 手描きのラフで秒数の欄が空のものを渡すと、Gemini は画から秒数を推し量って埋めます。埋めた秒数で表示時間を計算すると、 一覧の数字がすべて根拠の無いものになります。

AIに処理させる

させるのは、カットごとの表示を取り出すことと、強調表示と打消し表示の対応と組み合わせを判定することです。

1行目を守るのが、この構成で最も大事なことです。 消費者庁の資料も、打消し表示の表示方法や表示内容に問題があり、一般消費者に著しく優良又は有利であると誤認されるときに景品表示法上問題となるおそれがある、という書き方をしています。同じ「別のカットにある」でも、問題になるかは表示全体で変わります。 Gemini には事実を挙げさせ、結論は書かせません。

指示内容を固定する

あなたは広告会社の制作部で、動画広告の絵コンテを考査に出す前に
点検するための材料を作る担当です。表示が問題になるかの結論は書きません。

【材料】
- 絵コンテのPDF（カット番号・秒数・画・テロップ・ナレーションの欄）
- 台本（ナレーションとセリフの全文）
- 案件の情報：業種 {industry}／媒体 {media}／尺 {length}秒
- 局内の基準：{criteria}（強調表示の例、打消し表示の型、根拠の確認が要る表現の例）
- 根拠資料の受領状況：{evidence_list}

【手順】
1. カットごとに、秒数・テロップ・ナレーション・画の中の文字を、絵コンテの記載のまま写す。
2. 局内の基準の例に当たる文言を強調表示として、出どころ付きで挙げる。
3. 局内の基準の型に当たる文言を打消し表示として、型付きで挙げる。
4. 各打消し表示が、どのカットのどの強調表示に対するものかを示す。
   対応する打消し表示が見つからない強調表示は unmatched に入れる。
5. 打消し表示ごとに、強調表示と同じカットか、ナレーションでも同じ内容が
   読まれているか、同じカットに商品や人物などの目立つ画の記載があるかを判定する。
6. 数値・順位・効果・「No.1」「初」「最」などを含む表現を挙げ、
   根拠資料の受領状況に対応する資料があるかを示す。

【厳守事項】
- 秒数は絵コンテの記載のまま写してください。記載が無いカットは null とし、
  画や台本から推し量って埋めないでください。
- テロップの文字は一字も変えずに写してください。
- 「問題がある」「違反」「NG」「適切」「問題ない」と書かないでください。
- 打消し表示の文案を作らないでください。
- 判断がつかないものは uncertain にし、理由を書いてください。
- 迷ったときに「対応あり」としないでください。

「迷ったときに対応ありとしない」を書かないと、近くのカットの注記を何でも対応づけます。 強調表示と打消し表示の対応は、この点検の土台です。誤って結び付けると、打消しの抜けが一覧から消えます。

秒数を null にさせるのは、プログラムの計算の側で止めるためです。 null のカットは「読み終えられるか」を計算せず、「秒数の記載なし」として一覧に出します。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "storyboard_check": {
    "has_required_columns": true,
    "total_seconds_in_board": 15,
    "cuts": [
      { "cut_no": 3, "seconds": 2.0, "telop": "", "narration": "", "image_text": "" }
    ],
    "claims": [
      { "claim_id": "C1", "cut_no": 3, "text": "", "source": "telop | narration | image" }
    ],
    "disclaimers": [
      { "disc_id": "D1", "cut_no": 5, "text": "",
        "type": "exception | other_condition | extra_fee | test_condition | survey_source",
        "for_claim": "C1 | unmatched | uncertain",
        "same_cut_as_claim": false,
        "read_by_narration": false,
        "eye_catching_image_in_cut": true,
        "note": "" }
    ],
    "unmatched_claims": ["C2"],
    "evidence_needed": [
      { "claim_id": "C1", "expression": "", "evidence_in_list": "found | not_found | uncertain" }
    ]
  }
}

プログラムが、このJSONから「読み終えられるか」を計算します。 打消し表示のあるカットについて、seconds と、そのカットの telop の文字数（強調表示と打消し表示の合計）から、局内の目安の「1秒あたりの文字数」と比べ、ok ／ short ／ no_seconds を付けます。

1つ目の理由は、事実と計算と判断を別の列に置けることです。 Gemini の判定は事実の列、目安との比較は計算の列、問題かどうかは人が書く列です。目安を変えても、Gemini を呼び直さずに計算だけやり直せます。

2つ目は、前の版と並べられることです。 claim_id と cut_no で前の版の結果と突き合わせ、前の版の確認する点が直ったかを同じ一覧で見せます。

システムへ連携する

絵コンテと台本には書き込みません。 直すのは制作担当で、プログラムは一覧を作るところまでです。 考査や広告主の法務に出すのも人です。

有料の利用で呼びます。 Gemini API の規約では、無料の利用（無料枠の Gemini API など）では送った内容が製品の改善に使われ、人が読むことがあるとされ、機密や個人の情報を送らないよう書かれています。課金を有効にしたプロジェクトの有料の利用では、プロンプトを製品の改善に使わず、データ処理の取り決めに従って扱うとされています。公開前の広告は広告主の機密なので、有料の利用に限ります。

人が確認する

全部の一覧を制作担当が読み、自主点検の担当が考査に出す前に読みます。

1. 「秒数の記載なし」と「欄が無い」を先に見る … 絵コンテを直してから出し直します。点検の土台が無い状態です
2. unmatched の強調表示を見る … 打消し表示が本当に要らない強調表示か、付け忘れかを決めます
3. short の打消し表示を見る … 秒数を延ばすか、文字数を減らすか、別の見せ方にするかを決めます
4. 同じカットでない・音声が無い・目立つ画がある打消し表示を見る … 資料が挙げる「別の画面」「文字のみ」「人物等に注意が向く」の場面に当たるかを、表示全体で判断します
5. 根拠資料が見つからない表現を営業担当に回す … 広告主に資料の有無を確かめます
6. 直さないものには理由を書く … 一覧の「人の判断」の列に書きます。自主点検の担当がその理由を読みます

4番目は、人にしかできない判断です。 同じ「別のカット」でも、強調表示の直後に同じ大きさで出る打消しと、最後のカットに小さく出る打消しでは、受ける印象が違います。一覧は、その判断をするカットを絞り込むためのものです。

目標は、1件あたりの確認が12分です。 確認する点が少ない絵コンテは5分ほど、強調表示の多い通信・金融の絵コンテは20分以上かかります。

例外に対処する

6行目は、公式の案内が勧めていることそのものです。 構文として正しい JSON でも、カット番号が飛んでいる、秒数の合計が尺を超えている、といった中身の誤りはありえます。プログラムで機械的に検証できるものは、一覧に出す前に止めます。

記録を残す

• 点検に出した絵コンテ・台本・映像のファイル名と版の番号、出した日時
• Gemini が返したJSONの全文と、そのとき使った局内の基準と目安の版
• 点検の一覧と、人が書いた判断と理由
• 考査や広告主の法務から受けた指摘（どのカットの何について）
• 根拠資料の確認の結果（広告主の回答と日付）
• 映像を Files API から削除した記録

考査の指摘を残すのは、局内の基準を育てるためです。 一覧で挙がらなかったのに考査で指摘された点は、強調表示の例か打消し表示の型が基準に足りていないことを示します。自主点検の担当が月に1回見直して基準に足します。

基準と目安の版を残すのは、後から一覧を読み直すためです。 目安を変えた後で前の案件を見ると、short の付き方が変わります。