インフルエンサーの投稿後に届く投稿URLとインサイトの画面を、指示書・広告の表示・投稿期間と照らして点検し、広告主への実績報告を下書きする

処理の起点を決める

提出フォームに回答が入ったことを起点にします。 1日1回の定時処理にはしません。投稿は施策の期間の最初の数日に集中し、夕方にまとめて見ると、修正のお願いが翌日になります。 投稿から時間がたつほど、直してもらっても見られる回数は戻りません。

提出は2回に分けます。1回目は投稿の当日（投稿URL、投稿画面、キャプション）、2回目は投稿から7日後（インサイト画面）です。フォームの設問で回の区別を選んでもらい、1回目で点検、2回目で数値の読み取りを行います。一度に全部出してもらうと、点検が7日遅れます。

あわせて、毎朝1回動く別のシナリオで、台帳上は投稿日を過ぎているのに1回目の提出が無いインフルエンサーを拾い、担当者へ一覧で知らせます。スケジュールの設定で、毎朝決まった時刻に動かします。

入力データを集める

質を決めるのは、指示書の項目の書き方です。 「ブランドの世界観を大切に」のような文は判定に使えません。「#ブランド名 を必ず付ける」「本文の1行目に『PR』を入れる」のように、ある・ないで答えられる形に書き直します。 書き直せない項目は判定の対象から外し、人が見る項目として一覧に残します。

キャプションは画像と本文の両方でもらいます。 本文のコピーは文字が確実ですが、本人が貼り間違えることがあります。画像は実際の投稿の姿ですが、長いと切れます。両方を突き合わせ、食い違えば needs_human にします。

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

投稿URLの先を、機械で読みに行きません。 媒体の多くはログインを求め、外からの自動取得は利用規約の確認が要ります。URLは形式（媒体のドメインとアカウント名）だけを照合し、実際の投稿を開くのは人が確認するときだけにします。

指示書は案件番号で1行を引きます。 施策の途中で指示書を変えたときのために、行に版の番号を持たせ、判定のログに版を残します。

AIへ渡す前に整形する

1. 画像の形式の確認 … Claude が受け付けるのは JPEG・PNG・GIF・WebP です。スマートフォンの既定の形式で届いたものは変換します
2. 画像のサイズの確認 … API への直接の送信では1枚10MB（base64）まで、寸法は8000×8000ピクセルまでです
3. 小さすぎる画像の除外 … 公式は、低画質・回転した画像・200ピクセル未満の小さな画像で誤りが出ることがあるとしています。縮小されたサムネイルが届いたものは resubmit にします
4. 期間の照合 … 投稿日時が指示書の投稿期間に入っているかを、Make の条件式で比べます
5. アカウント名の照合 … 投稿URLに含まれるアカウント名と台帳の登録を比べます
6. ハッシュタグの抜き出し … キャプション本文から「#」で始まる語を抜き出し、数と、「PR」の類が何番目にあるかを数えます

6番目を生成AIの前に済ませるのは、数を数えるのが機械の仕事だからです。 Claude の公式も、画像の中の物の数は近似になることがあるとしています。「30個のうち28番目」は文字列の処理で出し、生成AIにはその数を渡して「埋もれているか」の判定だけをさせます。

AIに処理させる

させるのは、指示書の項目ごとに「投稿にあるか」を判定し、根拠の文字列を書き出すことと、インサイト画面の数値を読み取ることです。

表示の判定の物差しは、消費者庁の運用基準です。 運用基準は、明瞭となっていると認められる例として「広告」「宣伝」「プロモーション」「PR」の文言や、「A社から商品の提供を受けて投稿している」といった文章を挙げる一方、これらの文言でも表示内容全体から明瞭と認められない場合があるとしています。明瞭でない例として、部分的な表示、冒頭の「広告」と文中の「第三者としての感想」の食い違い、末尾の位置、周囲より小さい文字、大量のハッシュタグの中に埋もれさせる表示を挙げています。判定の型は、この例に合わせて分けます。

2行目と3行目が、広告主に出す資料としての線です。 レポートの数字は、インフルエンサーが出した画面にある数字か、それを式で足したものだけにします。

指示内容を固定する

あなたは広告会社で、インフルエンサーの投稿を指示書と照らして点検する担当です。
渡された投稿画面の画像、キャプション本文、指示書の項目だけを見て判定してください。
推測で埋めないでください。

【点検する項目】
指示書の項目一覧（{instruction_items}）の1行ずつについて、投稿にあるかを判定する。
あわせて、広告である旨の表示について次を判定する。
- 表示の文言（広告／宣伝／プロモーション／PR／提供を受けた旨の文）
- 表示の位置（本文の冒頭／本文の途中／末尾／ハッシュタグの中）
- ハッシュタグの総数と、表示が何番目にあるか（{hashtag_stats} の値をそのまま使う）
- 本文に「個人の感想です」「第三者として」など、広告でないと受け取れる記載があるか

【status の選び方】
- present ...... 投稿にある。evidence に該当する文字列を写す
- absent ....... 画像と本文の全体が写っていて、それでも無い
- not_visible .. 画像が途中で切れている、動画の中にあるなど、提出物から見えない
- unreadable ... 文字は写っているが読み取れない
- ambiguous .... 判断が割れる。理由を note に書く
迷ったときに present も absent も選ばないでください。

【厳守事項】
- 画像が途中で切れているときは、切れた先を absent にしないでください。not_visible です。
- 画像と本文のコピーで文字が食い違うときは、mismatch に両方を書いてください。
- ステルスマーケティングに当たるか、違反かどうかの結論を書かないでください。
- 画像に写っている人物が誰かを書かないでください。

【インサイト画面がある場合】
- 画面に表示された項目名と数値の組を、そのまま metrics に入れてください。
- 合計・平均・比率を計算しないでください。
- 桁区切りや「万」の表記は、画面の表記を raw に写し、数値に直せる場合だけ value に入れてください。
- 読めない桁があるときは value を null にし、confidence を low にしてください。
- 画面に表示された集計期間とアカウント名を写してください。

【指示書の項目】{instruction_items}
【ハッシュタグの集計】{hashtag_stats}
【キャプション本文（提出されたコピー）】{caption_text}

「切れた先を absent にしない」を明記しないと、写っていない「#PR」を無いものとして扱います。 画像に写っているハッシュタグが途中で終わっていても、何も言わなければ全文として読みます。not_visible を独立した値にしたのは、このためです。

インサイトで「計算しない」を書くのは、レポートの数字の出どころを1つにするためです。 生成AIが合計を書くと、式で出した合計と1違うだけで、どちらが正しいかを調べる時間が生まれます。

出力形式を固定する

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

{
  "submission_id": "",
  "campaign_id": "",
  "checks": [
    { "item": "", "status": "present | absent | not_visible | unreadable | ambiguous",
      "evidence": "", "note": "" }
  ],
  "disclosure": {
    "wording": "", "position": "head | middle | tail | in_hashtags | none",
    "hashtag_total": 0, "hashtag_index": 0,
    "contradicting_text": "", "status": "present | absent | not_visible | ambiguous"
  },
  "mismatch": "",
  "metrics": [
    { "label": "", "raw": "", "value": null, "confidence": "high | low" }
  ],
  "metrics_period": "", "metrics_account": ""
}

1つ目の理由は、判定と結論を別の層に置けることです。 checks と disclosure は生成AIが埋め、verdict は Make の Router が規則で決めます。

2つ目は、needs_fix と resubmit が混ざらないことです。 前者はインフルエンサーに投稿を直してもらうお願い、後者は画面を撮り直してもらうお願いです。混ぜると、正しく投稿した人に「PRが抜けています」と送ることになります。

3つ目は、metrics の raw と value を分けたことです。 「1.2万」は raw に写し、数値に直すのは確実なときだけです。value が null の行は、人が画面を見て埋めます。 スキーマの数値の範囲の制約は構造化出力では使えないため、値の範囲の確認（保存数がリーチを超えていないか等）は Make の条件式で行います。

システムへ連携する

インフルエンサーへの連絡は自動で送りません。 下書きを点検結果の行に置き、担当者が直して送ります。修正のお願いは、相手との関係と次の起用に直接ひびきます。

実績表には数値の確信度も書きます。 レポートの集計は confidence が high の行か、人が確かめた行だけを対象にします。確かめていない数字が広告主の資料に入る経路を作りません。

人が確認する

人が開くのは pass 以外の投稿です。 pass は一覧で件数とアカウント名を流し見ます。

1. needs_human を先に見る … 食い違いや、広告でないと受け取れる記載があるもの。ここは投稿を実際に開いて確かめます
2. needs_fix の根拠を確かめる … evidence を読み、投稿を開いて本当に無いか、末尾にあるかを見ます
3. resubmit を送る … どの部分が写っていなかったかを添えて、撮り直しをお願いします
4. 数値の low を埋める … インサイト画面と見比べて値を直します
5. 判定を覆したら記録する … どの項目を、どちらに変えたかを残します

2番目で投稿を開くのは、修正のお願いを出す前に必ず行います。 提出後にインフルエンサーが自分で直していることがあります。

運用基準の明瞭でない例に当たるかどうかで迷うものは、法務担当へ回します。 担当者が自分の判断で「これくらいなら大丈夫」とすると、施策ごとに基準が変わります。

例外に対処する

上から4行目までの多くは、提出のしかたの問題です。 提出フォームに見本の画像を載せると、resubmit は減ります。

記録を残す

• 提出フォームの回答と提出画像（施策の終了後も、契約で決めた期間）
• 生成AIに渡した指示書の項目とその版、ハッシュタグの集計
• 生成AIが返したJSONの全文と、Router が決めた verdict
• 人が判定を覆した記録 … どの項目を、どちらに変えたか
• 修正のお願いと撮り直しのお願いを送った日時と、その後の対応
• 数値を人が直した記録 … 読み取りの値と、直した値

2つ目で指示書の版を残すのは、施策の途中で指示書が変わるためです。 どの投稿がどちらの版で見られたかが分からないと、指摘の正しさを後から説明できません。

最後の行は、読み取りの弱い画面を知る材料です。 直しが多い画面は、提出の見本を変えるほうが効きます。