記事広告・タイアップ・インフルエンサーの原稿を、ステルスマーケティングの運用基準に照らして「広告」の表示の有無と分かりやすさを判定し、直し案を出す

処理の起点を決める

審査フォルダに原稿が置かれたことを起点にします。 公開日の直前に集中するため、1日1回の定時処理にはしません。夕方にまとめて回すと、直しが翌日になり、公開日に間に合わない原稿が出ます。

フォルダは案件番号ごとに分け、ファイル名に原稿の種類を付けてもらいます（article_、post_、video_script_、telop_、image_）。種類が分からないと、ハッシュタグとして読むべき行を本文として読みます。

処理が終わった原稿は審査済みフォルダへ移します。移すのは判定が一覧に書き込めたときだけです。 審査フォルダに残っている本数が、そのまま未審査の本数になります。

入力データを集める

質を決めるのは、下の2つです。 案件の情報が無ければ、そもそも「広告主の表示か」の段を前提にできません。社内基準が無ければ、AIの判定に「どこまでなら分かりやすいか」の物差しがなく、担当者で厳しさが違うという今の問題を、AIがそのまま引き継ぎます。

社内基準の秒数や順番は、運用基準に書かれた数値ではありません。 運用基準は「一般消費者が認識できないほど短い時間」「大量のハッシュタグ」と書くだけで、何秒・何個とは定めていません。数値は法務担当と広告主とで決めたものを、自社の基準として置きます。

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

案件台帳は案件番号で引き、広告主名では引きません。 同じ広告主の案件でも、媒体社が自主的に企画した記事と、広告主が費用を出した記事広告が並ぶことがあります。名前で引くと、関与の事実を別の案件から持ってきてしまいます。

AIへ渡す前に整形する

1. 原稿の分解 … 記事は見出し・本文・キャプション・末尾の注記に、投稿文は本文とハッシュタグに分けます
2. ハッシュタグの番号付け … 先頭から何個目か、全部で何個かを付けます
3. テロップの時間の整理 … 開始秒・終了秒から表示の秒数を出し、動画の長さに対して冒頭・中間・末尾のどこかを付けます
4. 画像の確認 … JPEG・PNG・GIF・WebP であること、1枚8000×8000ピクセル・10MB以内であることを確かめます。PDFのカンプは画像に書き出します
5. 小さすぎる画像の検知 … 長い辺が200ピクセルに満たない画像は判定に回さず、元のカンプを求めます
6. 関与の事実の確認 … 案件台帳の「依頼の有無」「対価」「商品提供」が空欄なら、ここで止めます
7. 既判定の検知 … 同じ案件番号・同じファイルの直しの版なら、前回の判定と一緒に渡します

3番目を軽く見ないでください。 運用基準は、長い動画で冒頭以外（中間・末尾）にだけ表示する場合も、認識しにくい例に挙げています。秒数と位置は、テロップ表から数字で出せるものなので、AIに読ませる前に出しておきます。

7番目は、直しの往復を短くするためです。 前回どこを指摘したかが分かれば、AIは同じ箇所が直ったかを先に見られます。

AIに処理させる

させるのは、原稿の中から広告である旨の表示を探し、運用基準の「不明瞭な方法」の型ごとに当たるかを判定して、根拠の箇所と直し案を書き出すことだけです。

右端の列が、この構成の安全装置です。 判断がつかないものを「問題なし」に倒さず、unknown として人に回します。

1行目がいちばん起きやすい失敗です。 投稿文が自然な口調だと、AIは「自主的な感想に見える」と書きたがります。見え方の話と関与の事実の話を混ぜると、依頼した案件が通ります。

指示内容を固定する

あなたは広告会社の審査担当として、公開前の原稿を点検します。
この原稿は、広告主が表示内容の決定に関与した案件です（案件台帳の記録による）。
関与があるかどうかは判断しないでください。前提として扱ってください。

【点検すること】
原稿の中で、広告主の表示であることが一般消費者に分かるかを、次の8つの型ごとに判定してください。
1. no_disclosure ........ 広告である旨の表示が見当たらない
2. partial .............. 一部の箇所・一部の投稿にしか表示がない
3. contradiction ........ 表示がある一方で、第三者の感想・自分で購入した等の文がある
4. video_timing ......... 動画で、表示が短い／冒頭以外にしか無い（秒数は【テロップの集計】を使う）
5. unclear_wording ...... 【表示に使う文言の一覧】に無い語で表示している
6. end_only ............. 表示が末尾や追記の位置にしか無い
7. low_visibility ....... 周囲より小さい・薄い色・長文の中に入っている
8. buried ............... ハッシュタグなど他の情報に紛れている（個数は【タグの集計】を使う）

【result の選び方】
- hit ....... その型に当たる
- not_hit ... その型に当たらない
- unknown ... 原稿・画像・テロップ表が足りず判断できない
迷ったときに not_hit を選ばないでください。

【厳守事項】
- 原稿に書かれていない事実を補わないでください。画像が読めないときは unknown です。
- 「#PR」などの文字があることを、分かりやすいことの根拠にしないでください。
  位置・大きさ・周囲との関係で判定してください。
- 秒数や個数を自分で数え直さないでください。集計の値をそのまま使ってください。
- ステルスマーケティングに当たるか、違反かどうかは書かないでください。
- evidence には、根拠にした原稿の文字列をそのまま写し、location に場所を書いてください。
- fix には、表示の追加・位置の変更・食い違う文の削除だけを書いてください。
  投稿者の言い回しや商品の説明は書き換えないでください。
- 表示に使う語は【表示に使う文言の一覧】から選んでください。

【媒体の種類】{media_type}
【表示に使う文言の一覧】{approved_terms}
【タグの集計】{hashtag_stats}
【テロップの集計】{telop_stats}
【前回の指摘】{previous_findings}
【原稿】{manuscript}

冒頭で「関与は前提」と書いているのが、いちばん効く1行です。 これが無いと、自然な口調の投稿文に「自主的な感想と考えられる」と書き、判定の前提ごと崩します。

「文字があることを根拠にしない」を明記しないと、型8は当たりません。 タグの20個目に「#PR」があれば、何も言わなければ「表示あり」で終わります。

出力形式を固定する

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

{
  "case_id": "",
  "file": "",
  "media_type": "article | influencer_post | video | affiliate",
  "disclosures_found": [
    { "text": "", "location": "", "kind": "word | sentence | telop | image" }
  ],
  "checks": [
    { "type": "no_disclosure", "result": "hit | not_hit | unknown",
      "evidence": "", "location": "", "fix": "" }
  ],
  "verdict": "clear | needs_fix | needs_legal",
  "notes_for_reviewer": ""
}

checks には8つの型を1つずつ並べます。verdict はAIに出させず、スクリプトが checks から規則で埋めます。

1つ目の理由は、判定と結論を別の層に置けることです。 checks はAIが埋め、verdict はスクリプトが決めます。社内基準が変わっても、直すのは規則だけです。

2つ目は、構造化出力で形が保証されることです。 result を enum にしておけば、「おおむね問題なし」のような中間の言葉が返りません。一覧の並べ替えと件数の集計が、そのままできます。

3つ目は、evidence と location で確認が速くなることです。 審査担当は原稿を頭から読み直さず、指摘の箇所だけを開きます。

システムへ連携する

原稿のファイルは書き換えません。 直し案は審査一覧に書くだけで、原稿に反映するのは制作担当です。 自動で書き換えると、投稿者の言葉に代理店が手を入れたことになり、別の問題を生みます。

案件台帳も読み取りだけです。 関与の列が空欄でも、スクリプトは埋めません。埋めるのは営業担当で、契約の内容を確かめてからです。

人が確認する

人が開くのは needs_fix と needs_legal です。 clear は一覧で媒体と案件名を流し見て承認します。全件を読み直す設計にすると、第10章の20.0時間には収まりません。

1. needs_legal を先に見る … 多くは、テロップ表や画像が足りないだけです。資料不足なら制作担当に差し戻し、本当に迷うものだけを法務担当へ回します
2. needs_fix の根拠を確かめる … evidence と location を開き、指摘が原稿どおりかを確かめます
3. 直し案を整える … 投稿者に送る文面は人が整えます。言い回しは投稿者に任せ、表示の位置と文言だけを指定します
4. 判定を覆したら記録する … どの型を、どちらに変えたかを残します

clear の流し見も省かないでください。 毎週数件を抜き出して全文を読み、AIが not_hit にした型が本当に当たらないかを確かめます。 ここで見つかった取りこぼしが、指示の直しの材料になります。

目標は、240件をならして1件5分です。 直しが要るものが3割前後という想定で、それより多い月は、社内基準が投稿者に伝わっていないか、テロップ表が付いていない案件が増えています。

例外に対処する

上の3行が大半を占めます。 どれもAIの問題ではなく、案件の情報と制作資料のそろい方の問題です。 判定の精度を上げるより、資料の出し方を決めるほうが効きます。

5行目と6行目は、運用基準そのものが分けている場合です。 対象から外れる表示を機械的に clear にすると、例外の条件（謝礼の多寡など）を見ないまま通すことになるので、省く場合も記録を残し、迷うものは人に回します。

記録を残す

• 原稿の各版と、届いた日時・制作担当・投稿者
• 判定に渡した入力（分解した本文、タグの集計、テロップの集計、画像）
• Claude API が返したJSONの全文と、スクリプトが決めた verdict
• そのとき使った社内基準の版と、案件台帳の関与の列の内容
• 人が判定を覆した記録 … どの型を、どちらに変えたか、理由
• 制作担当へ返した直し案と、直った版との対応
• 公開された最終版と、公開日

4つ目を残すのは、社内基準も台帳も後から変わるためです。 基準の秒数を変えたあとに「なぜこの動画を通したのか」と聞かれたとき、当時の基準が残っていないと答えられません。

最後の2行は、広告主に説明するための記録です。 運用基準は広告主を規制の対象としているので、広告主から審査の経緯を求められたときに、どの版に何を指摘し、どう直ったかを出せるようにしておきます。