広告代理店がインフルエンサーから届く投稿の案を、画面の見え方のスクリーンショットごとステルスマーケティングの表示の決まりに照らして判定し、投稿者ごとの直しの依頼を作る

処理の起点を決める

提出フォームに投稿の案が届いたことを起点にします。 投稿予定日の数日前に届き、直しのやり取りに1〜2往復かかるので、まとめて夜に処理するのではなく、届くたびに動かします。

直した案の再提出も起点になります。 前回の判定と今回の判定を並べて見られるよう、投稿者と施策の組に版の番号を付けます。 審査の担当は、前回の指摘が直っているかを最初に見ます。

投稿予定日の前日になっても pass になっていない投稿者は、施策の担当に知らせます。 投稿を待ってもらうか、広告主と相談するかは人が決めます。投稿予定日を過ぎて投稿された場合の確認は、この構成の外です。

入力データを集める

質を決めるのは、下の2つです。 広告主の表示の指定が台帳に書かれていなければ、「指定どおりか」を見られません。自社の審査の基準に、通した例と直させた例の画面が入っていれば、担当者ごとの指摘のずれを縮められます。

施策の条件は、AIの判定の前提として渡しますが、判定の対象にはしません。 商品の提供と投稿の依頼があることは台帳で決まっており、「この投稿は広告に当たるか」をAIに問わないためです。

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

キャプションと画面は、提出フォームから提出の番号で取り出します。施策の条件と表示の指定は、案件の台帳から施策の番号で引きます。

画面は、投稿の種類ごとに必要な枚数を決めておきます。 フィードなら一覧と詳細の2枚、ストーリーズならコマの数だけ、リールならカバーと表示が出る場面。足りなければ前処理で止めます。

動画は、AIに動画のまま渡しません。 表示が出る場面の画面を投稿者に出してもらい、何秒から何秒まで表示が出ているかは投稿者に申告してもらいます。 運用基準は、一般消費者が認識できないほど短い時間の表示や、長い動画で冒頭以外にだけ表示する場合を分かりにくい例に挙げており、秒数は申告と人の確認で見ます。

AIへ渡す前に整形する

1. 画像の形式の確認 … JPEG・PNG・GIF・WebP 以外（スマートフォンの写真の HEIC など）は変換します
2. 画像の大きさの調整 … 1つの要求の枚数が20枚を超えそうなら、各辺を2,000ピクセル以下に縮めます。縮める前の画像は保存しておきます
3. 枚数の確認 … 投稿の種類ごとに決めた枚数がそろっているかを見ます。足りなければ投稿者に再提出を頼みます
4. キャプションの整え … 改行とハッシュタグの並びを保ったまま、テキストとして渡します。ハッシュタグの数を数えておきます
5. 画像に番号を付ける … 「画像1：フィードの一覧」「画像2：フィードの詳細」のように、短い説明を画像の前に置きます
6. 投稿者の識別子の置き換え … アカウント名や本名は記号に置き換えます。画面に写ったアカウント名は消せないため、判定の出力に書かせないようにします

5番目は、公式のページの勧めに沿ったものです。 複数の画像を送るときは、「Image 1:」のような短いラベルで各画像を紹介すると、指示の中で名前で参照できるとされています。判定の根拠に「画像2の右下」と書かせられれば、人が確かめる時間が短くなります。

2番目で縮めすぎないでください。 ストーリーズの小さな「PR」は、縮めると潰れます。枚数を20枚以下に抑えて大きさを保つほうを先に考えます。

AIに処理させる

させるのは、項目ごとに判定と根拠を返すことと、直しの依頼の文の下書きです。

③と④が、画面を見せる理由です。 キャプションの文字列からは、それがスマートフォンの画面で何行目に来るか、どの大きさと色で見えるかが分かりません。画面を見れば、人が見るのと同じ材料で判定できます。

④の判定には限界があります。 公式のページは、空間の推論や位置の出力はおおよそであり、200ピクセル未満の小さな画像や低画質の画像では誤ることがあるとしています。だから④は ok と unclear を分け、unclear は必ず人が見ます。

2行目を守らないと、AIの出力がそのまま「適法」の証明のように扱われます。 運用基準は、表示内容全体から判断するとしており、項目がすべて ok でも、それは「この項目では引っかからなかった」という意味にとどめます。

指示内容を固定する

あなたは広告代理店で、インフルエンサーの投稿の案について、
広告である旨の表示が一般の人に分かるかを点検する補助をします。
広告に当たるかどうか、違法かどうかの結論は書かないでください。

【前提】
この投稿は、広告主から商品の提供を受け、投稿の依頼を受けたものです。
広告である旨の表示が必要な投稿として点検してください。
広告主の表示の指定：{disclosure_rule}
投稿の種類：{post_type}

【点検する項目】
1 表示の有無：キャプションか画面のどこかに、広告である旨の表示があるか
2 文言：「PR」「広告」「宣伝」「プロモーション」「〇〇社から商品提供」など、
  一般の人に分かる文言か
3 最初に見える範囲：画面で「続きを読む」などに隠れずに見えるか。
  ストーリーズでは最初のコマにあるか
4 見えやすさ：周囲の文字と比べて小さすぎないか、背景の色に溶けていないか
5 紛れ込み：多数のハッシュタグの中に埋もれていないか
6 食い違い：「個人的な感想」「頼まれたわけではない」など、
  表示を打ち消す言い回しが本文にないか
7 指定：広告主の表示の指定の文言・位置どおりか

【判定の仕方】
- 各項目の status は ok / ng / unclear から選んでください。
- 画面の文字が小さい、潰れている、隠れているなどで読み取れないときは、
  ng ではなく unclear にしてください。読めないことと、無いことを分けてください。
- evidence には、根拠にした画像の番号と場所（例：画像2の右下）、
  またはキャプションの該当の文をそのまま写してください。
- 迷ったときは ok を選ばないでください。

【直しの依頼の下書き】
ng の項目があるときだけ、投稿者あての短い依頼文を書いてください。
どの画面のどこを、どう直すかを具体的に、丁寧な言葉で書いてください。
投稿の内容や感想の書き方には触れないでください。

【厳守事項】
- 画面に写っている人物が誰かを書かないでください。
- アカウント名や本名を出力に書かないでください。
- 動画の表示の秒数は判断しないでください。

画像1：{label_1}
（画像）
画像2：{label_2}
（画像）
キャプション：{caption}

「読めないことと、無いことを分けてください」が、この指示でいちばん大事な一文です。 書かないと、潰れて読めない「PR」を ng にし、表示を入れている投稿者に「表示がありません」という依頼が飛びます。 投稿者との関係に直接響く誤りです。

「投稿の内容や感想の書き方には触れない」も外せません。 直しの依頼にAIが「商品の良さをもっと具体的に」と書き足すと、広告主の側が投稿の内容に踏み込んだ記録が残ります。 依頼は表示の直しに限ります。

出力形式を固定する

次の形のJSONで受け取ります。 スキーマは output_config.format に type: "json_schema" で渡します。

{
  "submission_id": "",
  "version": 1,
  "checks": [
    { "item": 3, "status": "ok | ng | unclear",
      "evidence": "画像1 キャプションの4行目以降（続きを読むの後）" }
  ],
  "hashtag_count_seen": 0,
  "fix_request_draft": ""
}

checks には項目1から7を1つずつ並べます。スキーマの配列の minItems は 0 と 1 しか使えないとされているため、7つそろっているかは受け取った側で確かめます。 欠けた項目は unclear として扱います。

判定は、次の規則で機械的に決めます。

1つ目の理由は、判定の規則を自社で持てることです。 どの項目の ng を直させるか、unclear をどう扱うかは、法務の判断で変わりえます。AIの出力を変えずに、規則だけを直せます。

2つ目は、hashtag_count_seen を前処理で数えた値と比べられることです。 画面で見えたハッシュタグの数と、キャプションの全体の数の差が大きければ、表示が隠れた側にある可能性を示す材料になります。

3つ目は、evidence で人の確認が速くなることです。 「画像2の右下」と書かれていれば、その画面のその場所を開くだけで済みます。

システムへ連携する

投稿者への送信は自動にしません。 下書きは施策ごとの一覧に置き、審査の担当が直して送ります。 投稿者は広告主の取引先であり、代理店から見ても大切な相手です。

案件の台帳は読み取りだけです。 表示の指定が台帳に無い施策は、判定の前に施策の担当に入力を頼みます。

施策ごとの一覧には、画面の縮小図と判定を横に並べます。 pass を流し見るときに、文字だけの一覧では、画面の見え方を確かめた気になれないからです。縮小図をクリックすれば元の大きさの画面が開くようにし、evidence の場所を開く手間を減らします。施策が終わったら、この一覧をそのまま広告主への報告の材料にも使えます。

人が確認する

審査の担当が開くのは fix と review です。 pass は施策ごとの一覧で、画面の縮小図と判定を流し見て通します。

1. review を先に見る … unclear の項目の画面を開きます。潰れて読めないだけなら、投稿者に大きい画面を出し直してもらいます
2. fix の根拠を画面で確かめる … evidence の場所を開き、本当に見えにくいかを目で見ます
3. 直しの依頼を直して送る … 下書きを、相手との関係に合わせて直します
4. 判定を覆したら記録する … ng を通したもの、ok だったが直させたもの。後者は、自社の審査の基準に例として足します

2番目を省かないでください。 AIの画面の判定はおおよそで、位置や大きさの見立てがずれることがあります。 直しの依頼を送る前に、人の目で一度確かめます。

動画の表示の秒数は、ここで人が見ます。 投稿者の申告と、動画の該当の場面を照らします。申告が無い動画は、review のまま施策の担当に戻します。

目標は、360件をならして1件4分です。 fix と review が4割前後という想定で、それより多い施策は、広告主の表示の指定が投稿者に伝わっていない可能性があります。

例外に対処する

4行目と最後から2行目が、この構成の安全弁です。 読めないものを ng にしない、AIが止まったら通さない。どちらも、判定の結果が無いことを「問題なし」と扱わないための決まりです。

記録を残す

• 提出の番号と版、キャプションの全文、画面のスクリーンショット（縮める前と後）
• そのときの施策の条件と、広告主の表示の指定
• AIに渡した指示の版と、返ってきたJSONの全文
• 規則で決めた判定と、審査の担当の判断、覆した記録
• 送った直しの依頼の最終版と、送った日時
• 投稿者が申告した動画の表示の秒数と、人が確かめた結果

2つ目で「そのときの表示の指定」を残すのは、施策の途中で指定が変わることがあるからです。 広告主が文言を「PR」から「〇〇社から商品提供」に変えた場合、前に通した投稿がどの指定で通ったのかを、後から説明できるようにします。

画面のスクリーンショットは、投稿の後に投稿者が画面を変えた場合の比べる材料にもなります。 投稿前に何を確かめて通したのかを、画面のまま残しておきます。