「この商材・この表現は媒体の審査を通るか」を、媒体ごとの広告ポリシーと過去の審査落ち・修正の記録から探し、根拠の条文と過去の例付きで返す

処理の起点を決める

起点は、担当が確認の画面で案を送ったことです。 画面は社内の ID でログインした社員だけが使え、ログインした社員の所属チームが、過去の例の元の版を見られるかの判定に使われます。

1つの案は、1回の確認で完結させます。 続けて「では、この語を外したら」と聞くときは、表現を直した案として送り直してもらいます。同じセッションで表現を少しずつ変えると、どの表現の確認結果なのかが記録の上で分からなくなります。

ポリシーの取り込みは、別に週に1回動かします。 中継プログラムが各媒体のポリシーのページを取得し、前回の写しと比べて変わった章だけを、新しい取得日の版として取り込みます。

入力データを集める

質を決めるのは、審査の記録の「表示された不承認の理由」と「日付」です。 理由が「落ちた」としか書かれていない記録は、どの条文に当たったかが分からず、今回の案と比べようがありません。 媒体の管理画面に表示された理由を、言い換えずにそのまま写します。

画像は、画像のまま渡さず、担当が言葉で説明して入れます。 「施術の前と後の顔写真を左右に並べる」「商品を持った医師風の人物」のように、ポリシーの条文の言葉で引ける書き方にします。画像そのものを検索に入れても、条文と照らす手がかりにはなりません。説明の書き方の例を、画面の入力欄に添えておきます。

カテゴリーと章の対応の表は、運用のベテランの知識そのものです。 「健康食品なら、この媒体ではこの章とこの章」という対応を表にしておくと、検索が1つの章だけを見て終わることを防げます。

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

ポリシーの写しと審査の記録は、Cloud Storage に置いてデータストアに取り込みます。 メタデータは JSONL の各行に id、structData、content.mimeType、content.uri を書きます。

絞り込みの式は、媒体とカテゴリーで書きます。 項目を索引可能にしておけば、media: ANY("search_ads") AND category: ANY("supplement") AND doc_type: ANY("policy") AND status: ANY("current") のように書けます。2回目の呼び出しでは doc_type を record に替え、ポリシーと記録が同じ回答に混ざらないようにします。

審査の記録には、伏せ字の版と元の版を作ります。 元の版には広告主名と商品名が入っていて、競合する広告主を担当する別のチームに見せてはいけません。 文書のメタデータの acl_info に担当チームの group_id を書くと、そのチームの社員の検索にだけ出ます。伏せ字の版は全員に見せます。

アクセス制御は、データストアを作るときにしか有効にできません。 また、Cloud Storage からの定期的な取り込みではデータソースのアクセス制御が使えないとされています。記録は書かれたたびに取り込みを実行し、定期の同期は使いません。

AIへ渡す前に整形する

1. ポリシーを章ごとに分ける … 媒体のページを章ごとのファイルにし、章の名前を付けます
2. 改定日を付ける … 前回の写しと比べて本文が変わった章に、変わった日を付けます
3. 審査の記録を写す … メールと社内チャットから、媒体・表現・結果・理由・日付を様式に写します
4. 伏せ字の版を作る … 広告主名、商品名、ブランド名を、カテゴリーの言葉に置き換えます
5. 記録にカテゴリーを付ける … 商材のカテゴリーを、カテゴリーと章の対応の表と同じ言葉で付けます
6. 閲覧の範囲を付ける … 元の版に担当チームの group_id を書きます
7. 地域を付ける … 配信する地域でポリシーが違う媒体は、地域を付けます

2番目を省かないでください。 改定日が無いと、中継プログラムは例の日付と比べる相手がありません。ポリシーのページが丸ごと新しい日付になっても、変わったのが別の章なら、その例は今も参考になります。 章の単位で比べるのは、そのためです。

4番目の伏せ字は、表現そのものを伏せません。 伏せるのは誰の広告かで、どの表現が落ちたかは残します。 表現まで伏せると、例として使えなくなります。

AIに処理させる

させるのは、案に関係するポリシーの条文と、似た過去の例を見つけ、どこが問題になりうるかを条文の言葉で示すことです。 審査を通るかの見込みは書かせません。

2行目の「確かめる点」には、表現の前に商材そのものの条件が入ることがあります。 制限されているコンテンツの扱いでは、表現をどう直しても、媒体の認定を受けていない広告主は出稿できないという条件が先に来ることがあります。条文に認定や証明の記載があれば、表現の話より先に示させます。企画の段階でいちばん早く知りたいのは、この条件です。

answer メソッドの設定は次のようにします。

検索は、ログインした社員の ID で行います。 中継プログラムが広い権限で検索すると、他のチームの広告主の元の記録が、例として表示されます。

2行目がいちばん起きやすい失敗です。 落ちた例と通った例を並べると、モデルは「この語をこう変えれば通る」という言い換えを作りたがります。それは審査を避ける表現の工夫で、媒体が禁じている行為に近づきます。 示すのは、記録に残っている修正の事実までです。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます（1回目のポリシーの呼び出し用）。

あなたは広告会社で、企画段階の広告の案について、
媒体の広告ポリシーの該当箇所を示す担当です。
読むのは、広告主に提案する前の営業と運用の担当です。

【前提】
検索の文の最初に、媒体、商材のカテゴリー、配信する地域、表現の案が並んでいます。
検索の対象は、その媒体のポリシーの写しだけです。

【答え方】
1. 案に関係する章の名前と、条文の要点を1つずつ書いてください。
   条文の言葉をそのまま使ってください。
2. 案のどの語・どの画像が、その条文に関わるかを書いてください。
3. 条文に、事前の認定や証明が要ると書かれていれば、その旨を書いてください。

【厳守事項】
- 検索結果のポリシーに書かれていることだけで答えてください。
  一般的な広告の知識や、他の媒体の決まりで補わないでください。
- 審査を通るか、通らないかの見込みを書かないでください。
- 審査を通すための言い換えや、表現の工夫を提案しないでください。
- 法律に違反するかどうかを書かないでください。
- 関係する条文が見つからないときは、
  「この媒体のポリシーに該当する記載が見つかりません。運用部の担当に確認してください」
  とだけ書いてください。

2回目の過去の例の呼び出しでは、【答え方】を「似た例を3件まで、日付・表現・結果・表示された理由・修正後の表現の順に書く」に替え、【厳守事項】に「記録に書かれていない修正の理由を推測しない」を足します。

「言い換えを提案しない」を名指しで書くのが、この指示の要です。 「見込みを書かない」だけでは、モデルは見込みの代わりに「こう書けば問題になりにくい」と書きます。禁じるのは、審査をくぐる工夫そのものです。

出力形式を固定する

2回の応答を、中継プログラムが次の形に整えて、画面と記録に渡します。

{
  "check_id": "",
  "media": "",
  "category": "",
  "region": "",
  "draft": { "headline": "", "body": "", "image_note": "" },
  "policy_refs": [ { "chapter": "", "point": "", "fetched_at": "", "revised_at": "", "uri": "" } ],
  "concerns": [ { "draft_part": "", "chapter": "" } ],
  "precedents": [ { "record_id": "", "date": "", "result": "rejected | approved_after_fix | approved",
                    "reason_shown": "", "fixed_text": "", "after_revision": true, "visibility": "masked | team" } ],
  "status": "found | no_policy | no_precedent | skipped",
  "consulted": false
}

1つ目の理由は、after_revision を規則で付けられることです。 中継プログラムは、例の date と、その例に関わる章の revised_at を比べ、例の後に改定があれば false にします。 画面では false の例を「改定前の例」として別の枠に出します。

2つ目は、concerns で確かめる箇所が分かることです。 案のどの部分がどの章に関わるかが並ぶので、営業は条文を全部読まずに、関わる箇所から見られます。

3つ目は、visibility で見せ方を分けられることです。 伏せ字の例は誰にでも出し、元の版の例は担当チームにだけ出ます。画面に出す前に、もう一度 visibility と社員の所属を照合します。

4つ目は、status の no_precedent を数えられることです。 条文はあるのに例が無い確認は、記録が足りないカテゴリーの一覧そのものです。 月ごとにカテゴリー別に数え、多いものから過去のメールを掘り起こして記録に写します。

consulted は、運用部に相談したかどうかです。 相談した確認の結論を記録に足すと、次に同じ案が来たときの例になります。

システムへ連携する

媒体の管理画面には、つなぎません。 入稿や審査の申請はこれまでどおり運用の担当が行い、この構成は企画の段階の確認だけを受け持ちます。 管理画面から審査の結果を自動で取り込む作りは、記録の様式が定着してから考えます。

人が確認する

営業は、提案に使う前に、必ず条文の原文を開きます。 返ってくるのは要点で、条文の細かい条件（地域、年齢、認定の要否）は原文にしかありません。

1. 媒体と地域を確かめる … 案に入れた媒体・地域の条文かを見ます
2. 改定前の例を今の根拠にしない … 改定前の例は、何が問題になったかの参考にとどめます
3. 例が無い・判断が付かないものは運用部へ … 「例なし」は「問題なし」ではありません
4. 審査の結果を記録に足す … 出稿したら、運用の担当が結果を書きます

3番目を軽く見ないでください。 記録の少ない新しい商材は、例が見つからずに条文だけが返ります。それを「過去に落ちていないから大丈夫」と読むと、(c)の差し戻しがそのまま起きます。

画面をそのまま広告主に送らないでください。 画面には伏せ字の他社の例が並び、要点は条文の言い換えです。広告主への説明には、営業が条文の原文と自社の判断をまとめ直して使います。 画面の転送を前提にすると、伏せ字の例から他社が推測される危険が残ります。

目標は、600件をならして1件7分です。 返ってきた条文と例を確かめる時間と、運用部に相談する時間の平均です。

例外に対処する

5行目と6行目は、媒体側の都合で起きます。 ポリシーのページは予告なく構成が変わり、取得の仕組みが古い章の分け方のまま動き続けると、改定日が付かなくなります。 取得のたびに章の数を数え、前回と違えば運用部に知らせます。

記録を残す

• 案の全文、媒体、カテゴリー、地域、日時、所属チーム
• 中継プログラムが組み立てた検索の文と、使った絞り込みの式
• answer メソッドの応答の全文（2回分。要点、出典、回答しなかった理由）
• 表示した条文の取得日と改定日、例ごとの after_revision
• 運用部に相談したかどうかと、その結論
• その案で出稿したときの審査の結果

最後の行は、記録を育てる材料です。 確認した案と審査の結果を結びつけておけば、条文と例を見て出した案が実際に通ったかを数えられ、その結果がそのまま次の例になります。