テレビ・ラジオのCMの原稿を、放送局の考査で指摘されやすい表現と広告主の表記ルールに照らして入稿前に校正する

処理の起点を決める

所定のフォルダに原稿が保存されたことを起点にします。 入稿の締切は局ごと・案件ごとにばらばらで、まとめて夜に流すと、締切の当日に置かれた原稿の校正が間に合いません。置かれた原稿から順に、1件ずつ動かします。

保存のたびに Azure Functions が原稿を読み、案件管理の表から広告主・商品・放送局・尺を引きます。案件管理の表に行が無い原稿は、校正を始めずに制作の担当へ戻します。 広告主が分からないと、照らす表記ルールが決まらないからです。

同じ原稿の版が何度も置かれることがあります。 ファイル名と案件の番号で版を区別し、前の版との差分の行には印を付けて指摘の一覧に出します。尺違いや局ごとの差し替えでは、直した行の周りに古い表記が残る失敗が多いからです。

入力データを集める

質を決めるのは、過去の考査の指摘の記録です。 放送基準の条文は誰でも読めますが、どの局がどの表現にどう反応したかは、自社にしか残っていません。 記録には「表現の型」の列を足し、superlative（最大級）、efficacy（効能効果）、comparison（比較）、price（価格）、testimonial（体験談・証言）、science_claim（調査や学術用語の引用）のような決まった値を入れます。

表現の型の列が無いと、似た指摘を引けません。 「売上No.1」と「販売数第1位」は文字が違っても型は同じ superlative です。型で引けば、言い回しの違う過去の指摘も出てきます。

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

過去の指摘は、全部をAIに渡しません。 商品分野で絞り、さらに原稿に含まれる表現の型で絞ります。原稿の表現の型は、前段で辞書（「No.1」「第1位」「いちばん」「日本一」「最高」など）に当たった語から決めます。 辞書に当たらない型はAIが拾うので、過去の指摘は同じ商品分野の直近のものを一定の件数だけ足します。

放送基準は、第13章から第18章までの条文と、商品分野に関わる条文だけを渡します。 健康食品の原稿なら第16章を、不動産の原稿なら第17章を必ず入れます。全条文を毎回渡すと、番組の基準の条文を根拠にした的外れな指摘が混ざります。

AIへ渡す前に整形する

1. 行への分割 … 原稿をナレーション・スーパー・映像の説明の行に分け、行番号を振ります
2. 版の差分 … 同じ案件の前の版があれば、変わった行に印を付けます
3. 表記の機械的な照合 … 広告主の表記ルールの辞書で、商品名の正式表記、登録商標の記号、価格の示し方の型（税込の表示など）を照合します
4. 表現の型の当たり付け … 最大級・比較・効能効果などの語の辞書に当たった行に、型の印を付けます
5. 過去の指摘の抽出 … 商品分野と表現の型で、過去の考査の指摘を引きます
6. 注釈の対応 … スーパーの注釈（「※自社調べ」「※個人の感想です」など）が、どの行の表現に付いているかを対応させます

3番目の結果は、この段階で確定させます。 正式表記と違う商品名は、AIに聞くまでもなく不一致です。AIには「表記の照合の結果」として渡し、同じ点を重ねて指摘させません。

6番目は、テレビの原稿で特に効きます。 「満足度95％」というナレーションに対し、調査の主体・時期・対象を示すスーパーが同じ場面に出ているかを確かめます。注釈がどの行に付いているかが分からないと、AIは注釈の有無を判断できません。

AIに処理させる

させるのは、原稿の行ごとに、3種類の根拠に照らした指摘の候補を挙げ、直しの案と、考査で求められそうな裏付けの資料を付けることです。

needs_evidence が、この構成でいちばん大事な区別です。 「No.1」や「満足度95％」は、裏付けの資料があれば表現として使えることもある、というのが考査の実際です。AIに裏付けの有無は分かりません。 「表現を変える」と「資料をそろえる」のどちらにするかは人が決めるので、AIはどんな資料を聞かれそうかを挙げるところまでにします。

3行目がいちばん起きやすい失敗です。 「No.1」の行に「調査に基づく表示であれば問題ありません」と書かれると、担当は資料を確かめないまま通してしまいます。AIの出力に「問題ありません」と書かせない指示を、プロンプトに入れます。

指示内容を固定する

あなたは広告会社の考査対応の担当として、放送局へ入稿する前の
CMの原稿を校正する立場です。
放送してよいかの判断はしないでください。それは放送局の考査が決めます。
あなたの仕事は、考査で指摘されそうな箇所と、広告主の表記ルールと
違う箇所を、根拠を付けて挙げることです。

【根拠の種類】
- broadcast_standard ... 放送基準の条文（番号で示す）
- past_finding ......... 過去の考査の指摘（記録の番号で示す）
- client_rule .......... 広告主の表記ルール（ルールの番号で示す）

【status の選び方】
- revise ......... 表現を直したほうがよい
- needs_evidence . 裏付けの資料があれば使える可能性がある。資料の確認が要る
- unclear ........ 商品の区分や条件が原稿から分からず、判断がつかない
迷ったときは unclear を選んでください。

【厳守事項】
- 指摘には、根拠の種類と番号を必ず付けてください。
  渡した条文・記録・ルールに無い根拠で指摘しないでください。
- quote には、原稿の該当する行の文言をそのまま写し、line_no を付けてください。
- suggestion は、その行の最小の直しにしてください。
  原稿全体の書き直しや、別の訴求の提案はしないでください。
- 裏付けの資料があるかどうかを推測しないでください。
  「問題ありません」「通ります」と書かないでください。
- needs_evidence のときは、考査で求められそうな資料を evidence_needed に
  具体的に書いてください（調査の主体・時期・対象・方法など）。
- 法令に違反するかどうかを断定しないでください。
- 【表記の照合の結果】にある点は、重ねて指摘しないでください。
- 指摘が無い行には、何も作らないでください。

【案件の情報】{case_info}
【放送基準の条文】{standards}
【過去の考査の指摘】{past_findings}
【広告主の表記ルール】{client_rules}
【表記の照合の結果】{dictionary_checks}
【原稿（行番号付き）】{script_lines}

「問題ありません」と書かせない指示を独立させているのは、それが一番危ない出力だからです。 指摘が無い行に何も書かないのと、「問題ない」と書くのとでは意味が違います。前者は「見つからなかった」、後者は「確かめた」に読めます。

evidence_needed を具体的に書かせるのは、広告主への確認を一度で済ませるためです。 「裏付けの資料を確認してください」だけでは、広告主から届くのは調査の結果の数字だけで、調査の時期や対象が抜けます。

出力形式を固定する

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

{
  "case_id": "",
  "script_version": "",
  "findings": [
    {
      "line_no": 0,
      "line_type": "narration | super | visual",
      "quote": "",
      "expression_type": "superlative | efficacy | comparison | testimonial | science_claim | price | other",
      "status": "revise | needs_evidence | unclear",
      "basis_type": "broadcast_standard | past_finding | client_rule",
      "basis_ref": "",
      "suggestion": "",
      "evidence_needed": "",
      "reason": ""
    }
  ]
}

1つ目の理由は、根拠の種類で並べ替えられることです。 broadcast_standard の指摘は直さなければ考査で止まる可能性が高く、client_rule は広告主と相談して決めるもので、担当が読む順番と、返す相手が違います。

2つ目は、照合ができることです。 quote と line_no はプログラムが原稿と突き合わせ、basis_ref は渡した条文・記録・ルールの番号に実在するかを確かめます。どちらかが合わない指摘は一覧に出しません。 存在しない条文番号を根拠にした指摘を、ここで止めます。

3つ目は、expression_type で考査の傾向を数えられることです。 月ごとに、どの型の指摘が採られ、考査でどの型の差し戻しを受けたかを数えれば、制作の担当向けの注意書きに何を書くべきかが分かります。

構造化出力のスキーマでは、公式のページにあるとおりすべての項目を必須にし、additionalProperties: false を設定します。 evidence_needed が要らない指摘では空の文字列を返させ、項目そのものは省かせません。

指摘の一覧は、担当が次の形で読みます。

【案件】〇〇食品　青汁　30秒　テレビ　第3版
 行12 ナレーション「飲み始めて、朝がすっきり」
   型：efficacy ／ status：revise ／ 根拠：放送基準(136)
   案：「毎朝の一杯を、続けやすく」
 行15 スーパー「愛用者満足度95％」
   型：science_claim ／ status：needs_evidence ／ 根拠：過去の指摘 K-0412
   要る資料：調査の主体・時期・対象者数・設問、「愛用者」の定義

システムへ連携する

原稿には書き込みません。 指摘を原稿のコメントとして書き込む作り方もありますが、採否を選ぶ前の指摘が制作の担当や広告主に見えてしまいます。 指摘の一覧は別のファイルにし、採ったものだけを担当が返します。

放送局への入稿は、この構成の外です。 入稿の経路や形式は局ごとに決まっており、この構成は入稿の手前までを受け持ちます。 考査の結果は、担当が記録の表に入れます。

人が確認する

考査対応の担当が、指摘の一覧を読んで採否を選びます。 原稿を最初から読むのではなく、指摘ごとに原稿の行と根拠を読みます。

1. broadcast_standard の revise を先に見る … 健康食品の効能効果のような指摘です。直しの案が訴求を変えすぎていないかも見ます
2. needs_evidence は広告主に資料を求めるかを決める … evidence_needed を読み、資料があれば表現を残し、無ければ表現を変えます
3. client_rule は広告主の担当に確かめる … ルールの解釈が分かれるものは、広告主の判断に従います
4. unclear は商品の区分や条件を確かめる … 医薬品か健康食品かで、使える言い方が変わります
5. 考査の結果を記録に入れる … 局から受けた指摘を、表現の型・原文・直した後の文言とともに記録します

5番目を省かないでください。 この構成の精度は、過去の指摘の記録の厚さで決まります。差し戻しを受けた指摘も、通った表現も、決まった形で残します。

目標は、180件をならして1件8分です。 指摘の少ないラジオの読み原稿は数分で終わり、健康食品や不動産の原稿に時間を使います。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、案件の情報と原稿の受け渡しの問題です。 商品の区分を案件管理の表の列にしておくだけで、unclear はかなり減ります。

記録を残す

• 原稿の各版と、校正に使った放送基準の版・表記ルールの版
• 表記の照合の結果と、引いた過去の指摘の一覧
• AIへの入力と出力のJSONの全文
• 担当の採否の記録 … どの指摘を採り、直し、外したか、その理由
• 広告主に求めた資料と、届いた資料の対応
• 考査の結果 … 局、日付、指摘の有無、指摘の要旨、表現の型、直した後の文言

最後の行が、次の校正の材料になります。 考査の結果を入れるときに表現の型を付けておけば、次に同じ型の表現が出たとき、局ごとの反応まで含めて引けます。

採否の記録で、外された指摘が多い型を月ごとに見ます。 外される型は、AIの読み方か、渡している条文の範囲に問題があります。