インフルエンサーのキャンペーン応募フォームの内容とアカウントの情報から、募集条件とNGジャンルに合うかを判定して、選考リストを作る

処理の起点を決める

応募フォームへの回答が届くたびに、Watch Responses で1件ずつ処理します。 締め切りの後にまとめて処理する設計にはしません。締め切り直後に100件をまとめて流すと、判定の結果を見始めるのが翌日になります。 届くたびに処理しておけば、締め切りの時点で選考リストができています。

フォームは1つにし、最初の質問でキャンペーンを選んでもらいます。 キャンペーンごとにフォームを分けると、Make のシナリオもキャンペーンの数だけ要ります。

締め切りを過ぎた応募を判定しないのは、条件表がその後に書き換わることがあるためです。 次のキャンペーンのために条件を変えた後で古い応募を判定すると、別のキャンペーンの条件で判定した結果が残ります。

入力データを集める

質を決めるのは、競合ブランドの一覧です。 会社名だけの一覧だと、応募者が「○○（ブランド名）のPR」と書いたときに当たりません。会社名とブランド名の対応を表で持ち、両方をAIに渡します。

応募者の氏名と連絡先は、AIに渡しません。 判定に使うのはアカウントの情報と数字だけで、連絡先は選考リストの側で応募のIDと結び付けておきます。

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

キャンペーンの条件表は、Search Rows でキャンペーンのIDを絞って1行を引きます。 条件表は1キャンペーン1行で、列に条件を並べます。

最後の列が、第5章の5番目の規則です。 どの条件が外れたら対象外にするかを、キャンペーンごとにこの列で決めます。 書かれていない条件が外れた応募は、対象外ではなく「要確認」になります。

インサイトの画面は、フォームの回答に入っているファイルのIDで Download a File を呼びます。 画像が複数あれば、1枚ずつ取り出して全部を1回の依頼に入れます。

AIへ渡す前に整形する

1. ファイルの形式の確認 … Claude が受け付けるのは JPEG、PNG、GIF、WebP です。それ以外（HEIC など）はフォームの側で受け付けないように設定します
2. 画像の大きさの確認 … 1枚あたりの上限は、Claude API に直接渡す場合で base64 にして10MB、縦横は8000×8000ピクセルまでです
3. フォロワー数の表記をそろえる … 「1.2万」「12k」「12,000」を数字にそろえます
4. 競合ブランドの一覧の展開 … 条件表から、そのキャンペーンの競合の会社名とブランド名を全部引き出します
5. 重複の確認 … 同じアカウントのURLで、同じキャンペーンの行が選考リストにあれば「再応募」にします

3番目は、AIに任せずワークフローの側で行います。 数字の比較は規則で行うほうが確実で、AIには「画面の数字と申告の数字が食い違っていないか」だけを見させます。

2番目の上限は、画面の写真を高い解像度のまま出してくる応募者がいるためです。 大きすぎる画像は縮小されて処理されるので、縮小で文字がつぶれないかを最初に数件で確かめます。

AIに処理させる

させるのは、条件ごとに、合う・合わない・確かめられないを判定し、根拠を書くことだけです。

右端の列が、この構成でいちばん大事な区別です。 not_meets は条件から外れていると読めたもの、unverifiable は材料が足りなくて判定できないものです。前者は対象外の候補、後者は応募者に出し直してもらえば候補になりうる人です。

最後の行は、ステルスマーケティングの規制に関わります。 消費者庁のページでは、2023年10月1日からステルスマーケティングは景品表示法違反となり、広告には企業がインフルエンサー等の第三者に依頼・指示するものも含まれるとされています。規制の対象は広告主である事業者で、だからこそ、広告であることを表示することへの同意を応募の段階で確かめます。

2行目が、この構成の前提です。 Claude の公式ドキュメントの制限事項に、画像がAIで生成されたものかを判断できず、尋ねられても誤ることがあるとあります。インサイトの画面が加工されていても、AIは写っている数字をそのまま読みます。だから候補に残った人は、担当者がアカウントで確かめます。

指示内容を固定する

あなたは広告会社のキャスティングの補助です。
インフルエンサーのキャンペーンへの応募が、募集条件に合うかを
条件ごとに判定します。起用するかどうかは判断しません。

【入力】
- 応募の回答：{application}
- インサイトの画面（画像1〜3）：添付のとおり
- 募集条件：{conditions}
- NGジャンルとその説明：{ng_genres}
- 競合の会社名とブランド名の一覧：{competitors}

【条件ごとの status の選び方】
- meets ......... 材料から条件に合うと読める
- not_meets ..... 材料から条件に合わないと読める
- unverifiable .. 材料が無い、画像が読めない、表記が近いが一致しないなど、判定できない
迷ったときに meets も not_meets も選ばず、unverifiable にしてください。

【厳守事項】
- 画像に写っている数字や割合は、読めたとおりに写してください。
  読めない数字を申告の数で埋めないでください。
- 申告の数と画像の数が食い違うときは、両方を evidence に書いてください。
- 画像が加工されているか、本物かを判断しないでください。
- 画像に写っている人物が誰かを書かないでください。
- 外見や容姿について書かないでください。
- 競合ブランドは、一覧の会社名かブランド名と一致するときだけ not_meets にしてください。
  似ているだけのときは unverifiable にし、似ている名前を evidence に書いてください。
- 起用すべきか、候補に残すべきかを書かないでください。
- evidence には、判定の根拠にした回答の文言か、画像から読んだ値を書いてください。

「迷ったら unverifiable」を明記しないと、読めない画面を not_meets にします。 年齢層の画面が無いと「条件の層であることが確かめられない、よって合わない」と書き、出し直せば候補になる人を落とします。

競合ブランドを「一致するときだけ」にしているのは、逆の誤りを防ぐためです。 似た名前のブランドを競合と判定すると、関係の無い会社のPRをした人まで対象外になります。 似ているものは担当者に回します。

出力形式を固定する

Make an API Call で Messages API を呼び、画像のブロックとテキストを1回の依頼に入れ、構造化出力で次の形のJSONを受け取ります。 画像は base64 にして image のブロックで渡します。Claude API の構造化出力は、output_config.format に type: "json_schema" でスキーマを渡す形です。

{
  "application_id": "",
  "campaign_id": "",
  "checks": [
    { "condition": "follower_count",
      "status": "meets | not_meets | unverifiable",
      "declared": "", "observed": "", "evidence": "" }
  ],
  "image_readable": true,
  "notes_for_staff": ""
}

checks には条件の数だけ要素を並べます。condition は follower_count ／ audience ／ region ／ genre ／ ng_genre ／ competitor ／ age ／ disclosure_consent です。

1つ目の理由は、checks と区分を別の層に置けることです。 checks はAIが埋め、候補・要確認・対象外の区分はワークフローが条件表の「対象外にする条件」の列で決めます。キャンペーンごとに対象外の決め方が変わっても、直すのは条件表だけです。

2つ目は、declared と observed を並べられることです。 申告のフォロワー数と画面に写っている数が並んでいれば、担当者は食い違いのある行だけを開けます。

注意が1つあります。 構造化出力でも、enum の値が大文字小文字だけ違って返ることがあるとされているので、区分を決める比較では大文字小文字を区別しません。

システムへ連携する

応募者への連絡は、この構成からは送りません。 対象外の連絡も、画面の出し直しの依頼も、担当者が選考リストを見てから送ります。判定が誤っていた1件の不採用の連絡は、取り消しが効きません。

Google Forms のアプリには、注意書きがあります。 Make のページでは、Google の OAuth のプロジェクトがテストの状態だと毎週つなぎ直しが要るとされています。自社の Google Cloud のプロジェクトでつなぐときは、公開の状態にしておかないと、ある週に応募が止まります。

人が確認する

担当者が開くのは「候補」と「要確認」の行です。 「対象外」は理由の列を流し見て、明らかな誤りが無いかだけを見ます。

1. 「要確認」を先に見る … unverifiable の理由を読み、画面の出し直しで済むものは応募者に連絡します
2. 「候補」のアカウントを開く … 画面に写っていた数字が、アカウントの表示と大きく違わないかを確かめます。画像は本物かをAIが見ていないので、ここは省けません
3. 投稿の雰囲気と広告の表示のしかたを見る … 過去のPRの投稿に、広告であることが分かる表示があるかを見ます
4. 起用の候補を選び、広告主に提案する … 選んだ理由を選考リストに書きます
5. 判定を覆したら記録する … どの条件を、どちらに変えたかを残します

2番目を省かないでください。 インサイトの画面は応募者が撮ったもので、この構成はその数字を読んでいるだけです。 広告主に提案する人については、担当者が自分の目で確かめたという記録を残します。

目標は、600件をならして1件2分です。 「候補」と「要確認」が3割前後という想定で、それより多いキャンペーンは、条件表の書き方があいまいです。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、応募フォームの案内の問題です。 「フォロワーの年齢層・性別・地域の3つの画面を出してください」と見本の画像つきで案内すると、この3行は減ります。

記録を残す

• 応募の回答と、インサイトの画面の画像のファイルID
• 判定に使った条件表の内容（そのときのキャンペーンの条件）
• AIが返したJSONの全文と、ワークフローが決めた区分
• 担当者が判定を覆した記録（どの条件を、どちらに変えたか）
• 担当者がアカウントで確かめた日時と、確かめた人
• 起用した人と、広告主に提案したときの理由

2つ目で「そのときの条件」を残すのは、条件表が書き換わるためです。 広告主の要望で途中から層の条件を変えることがあり、当時の条件が残っていないと、なぜこの人が対象外だったかを説明できません。

4つ目は、条件表とプロンプトを直す材料です。 同じ条件で覆す件数が多ければ、その条件の書き方があいまいか、AIの読み方がずれています。