広告代理店に届く運用開始の依頼から、広告アカウントの権限・計測タグ・素材の依頼リストを作り、足りない情報を確かめる

処理の起点を決める

フォームの回答が送信されたことを起点にします。 Google Forms の New Form Response は即時に動くので、広告主が送った直後に依頼リストができます。営業が回答に気づくのを待たずに、案件台帳に行が増えます。

1日1回まとめて処理する形にはしません。運用開始の依頼は、開始日から逆算して日数が少ないものほど急ぎだからです。朝まで待つと、権限の付与を頼む日が1日遅れます。

回答の修正は別に扱います。 New or Updated Form Response という、回答が追加または変更されたときに動くトリガーもありますが、本記事では使いません。同じ回答の修正で依頼リストが二重にできるためです。広告主が回答を直したいときは、営業に連絡してもらい、営業が台帳を直します。

入力データを集める

質を決めるのは、2つ目と3つ目です。 案件台帳に付与済みの権限が無ければ、媒体追加の依頼ですでにある権限をもう一度頼むことになります。雛形表に招待先のメールアドレスが無ければ、依頼の下書きに宛先が入りません。

フォームの設問は、自由記述を3つに分けておきます。 アカウント・計測・素材を1つの欄に書かせると、どの媒体のどの話かを AI が取り違えます。設問を分けるだけで、抜き出しの誤りの多くが消えます。

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

フォームの回答はトリガーがそのまま渡します。案件台帳と雛形表は、Google Sheets の検索のアクションで引きます。

会社名だけで引かないでください。 「株式会社」の前後や略称で一致しないことが多いからです。Lookup Spreadsheet Row は補助の検索列と値を指定して、両方に一致する行だけを探せます。 メールのドメインを補助に使うと、同名の別会社も避けられます。

一致する行が無かったときの動きは、ステップの設定で決めます。 本記事では、一致しなければ新規の広告主として扱い、行を作らずに先へ進めます。 新規の行は、最後の書き込みの段で作ります。

AIへ渡す前に整形する

1. 媒体の選択肢を正規化する … フォームの複数選択の値を、雛形表の媒体名と同じ表記に直します（Formatter の置換）
2. 自由記述の空欄を印にする … 3つの欄のうち空のものに「記載なし」を入れ、空欄であることを AI に明示的に渡します
3. URL を文字列のまま扱う … LPのURLは開きません。AI by Zapier は URL から情報を取ってこられないためです
4. 開始希望日から残り日数を出す … 今日からの営業日数を計算し、急ぎの印を付けます
5. 媒体追加の依頼かを決める … 案件台帳に一致した行があれば、付与済みの権限の列を AI への入力に加えます
6. 重複の検知 … 同じ会社・同じ媒体の依頼が直近7日にあれば、二重送信として印を付けます

2番目を省かないでください。 空の欄をそのまま渡すと、AI は他の欄から推し量って埋めにいきます。「記載なし」と書いて渡すと、not_stated として返ってきます。

3番目は、仕様として知っておく点です。 AI by Zapier はウェブサイトや URL から情報を検索・抽出できないとされています。LPにタグが入っているかを見たいなら、それは別の仕組みの仕事です（UC-0489）。

AIに処理させる

させるのは、媒体ごとに、アカウント・計測・素材の状況を決まった区分で抜き出すことだけです。

区分の右端 not_stated が、この構成でいちばん大事な値です。 「書かれていない」は広告主に聞けば済みますが、「無い」は設置や制作から相談が要ります。not_stated を not_created や none に寄せると、依頼の中身が変わります。

exists_no_id と exists_no_owner も同じ考え方です。 「ある」とは書かれているが、依頼に要る情報が無い状態で、第3章の（c）そのものです。この区分があることで、聞き返すべき具体的な項目が決まります。

3行目がいちばん起きやすい失敗です。 「制作会社がサイトを作っています」という回答から、GTM も制作会社が持っていると書いてしまいます。それらしいが確かめていない値が、依頼の宛先になってしまいます。

指示内容を固定する

あなたは広告代理店の営業部で、新しい広告主の運用開始の依頼を受け付ける立場です。
フォームの回答に書かれていることだけを、媒体ごとに項目へ抜き出してください。
書かれていないことを推測で埋めないでください。

【媒体ごとに抜き出す項目】
1. account_status：広告アカウントの状況
   ready / exists_no_id / not_created / not_stated
2. account_id：回答に書かれたアカウントIDをそのまま写す。無ければ空
3. account_owner：advertiser / previous_agency / unknown
4. ga4_status・gtm_status：ready / exists_no_owner / not_installed / not_stated
5. conversion：計測したい成果として書かれた語をそのまま。無ければ空
6. assets_status：ready / partial / none / not_stated
7. assets_note：素材の置き場所や、足りないと書かれた素材

【区分の選び方】
- 「記載なし」と渡された欄は、その欄の項目をすべて not_stated にしてください。
- 「ある」と書かれていてもIDや管理者が書かれていなければ、
  exists_no_id または exists_no_owner にしてください。ready にしないでください。
- 「まだ無い」「これから作る」とはっきり書かれているときだけ、
  not_created・not_installed・none を選んでください。
- 迷ったときは ready を選ばないでください。

【厳守事項】
- アカウントIDは書かれた文字列をそのまま写してください。
  桁を補う、ハイフンを足す・消す、それらしい形に直すことをしないでください。
- ある媒体について書かれたことを、別の媒体に当てはめないでください。
- サイトやLPがあることから、GA4 や GTM があると判断しないでください。
- 頼む権限の種類（管理者・編集など）は書かないでください。
- 開始日に間に合うかどうかは書かないでください。
- evidence には、判定の根拠にした回答の文をそのまま写してください。

【選ばれた媒体】{media_list}
【アカウントの状況】{answer_account}
【計測の状態】{answer_measurement}
【素材の状況】{answer_assets}
【付与済みの権限（既存の広告主のみ）】{granted}

「ready を選ばないでください」を2か所に書いているのには理由があります。 回答の多くは前向きな書き方で、「入っています」「用意できます」とあります。何も言わなければ、その語感を根拠に ready を選びます。 依頼に要る情報がそろっているかで決める、と明記します。

「別の媒体に当てはめない」も要ります。 「アカウントはあります」と1回だけ書かれた回答で、選ばれた3媒体すべてを ready にする誤りが出るからです。

出力形式を固定する

Analyze and Return Data の出力項目を定義し、「Return a list of results」を有効にして、媒体ごとに1要素の配列で受け取ります。

[
  {
    "medium": "Google 広告",
    "account_status": "ready | exists_no_id | not_created | not_stated",
    "account_id": "",
    "account_owner": "advertiser | previous_agency | unknown",
    "ga4_status": "ready | exists_no_owner | not_installed | not_stated",
    "gtm_status": "ready | exists_no_owner | not_installed | not_stated",
    "conversion": "",
    "assets_status": "ready | partial | none | not_stated",
    "assets_note": "",
    "evidence": ""
  }
]

1つ目の理由は、区分の値で Paths を分けられることです。 not_stated・exists_no_id・exists_no_owner が1つでもあれば「不足あり」、すべて ready か「無い」がはっきりしていれば「不足なし」です。自由文で返させると、この分岐が書けません。

2つ目は、依頼リストを雛形表と掛け合わせて作れることです。 区分ごとに、雛形表の文言を当てはめます。

3つ目は、evidence で営業の確認が速くなることです。 回答のどの文からその区分にしたかが並ぶので、回答全文を読み直さずに確かめられます。

システムへ連携する

メールは Create Draft にします。 Gmail のアクションには Send Email もありますが、送信は営業が下書きを確かめてからにします。広告主にとっては代理店からの最初の実務の連絡で、宛先や敬称の誤りがそのまま印象になります。

案件台帳への書き込みは、依頼リストの列だけにします。 契約や予算の列には書き込みません。既存の広告主の行は Update Spreadsheet Row で更新しますが、1回の実行で更新できるのは1行です。 媒体ごとの行は、依頼リスト用のシートに追加する形にします。

人が確認する

営業が見るのは、依頼リストと下書きの2つです。

1. 急ぎの印から見る … 開始希望日までの営業日が少ないものを先に開きます
2. evidence と区分を見比べる … とくに ready の行を見ます。ready と出ていても、依頼に要るIDや管理者が本当に書かれているかを確かめます
3. 営業だけが知る事情を足す … 前の代理店との契約、広告主の社内の担当の違いなどを下書きに書き足します
4. 送る … 下書きを直して送ります。送信は営業が行います
5. 区分を直したら記録する … どの項目を、どの区分からどの区分へ変えたかを台帳の列に残します

2番目で ready を見るのには理由があります。 not_stated の誤りは広告主に聞けば分かりますが、ready の誤りは権限の付与を待つ段で初めて分かります。 運用開始の直前に詰まる、第3章の（a）の形に戻ってしまいます。

運用担当は、権限が付いたことを自分で確かめてから作業に入ります。 依頼リストは「頼んだ」記録で、「付いた」記録ではありません。

例外に対処する

6行目は、Formatter で桁数と区切りの形を見るだけで検知できます。 AI に直させるのではなく、形が合わないことを事実として依頼リストに載せます。

Paths は左から順に確かめられ、規則に合う枝は複数動きうるとされています。不足あり／不足なし／読み取れない回答の3つの枝の条件を、互いに重ならないように書きます。 どれにも当たらないものは Fallback の枝で営業に回します。

記録を残す

• フォームの回答の全文と、受け取った日時
• AI の出力（媒体ごとの区分と evidence）と、そのとき引いた雛形表の行
• 依頼リストの各行と、下書きを作った日時
• 営業が区分を直した記録 … どの項目を、どの区分からどの区分へ変えたか
• 広告主へ送った日時と、権限の付与を確かめた日時
• 媒体ごとの、依頼から付与までにかかった日数

2つ目で「そのときの雛形表の行」を残すのは、権限の種類の取り決めが後から変わるためです。 たとえば GA4 で頼む役割を変えたとき、過去の依頼がどちらの取り決めで出たかが分からないと、付与の状況を見直す範囲が決まりません。

最後の行は、媒体ごとの段取りの見直しに使います。 特定の媒体だけ付与までの日数が長いなら、依頼の文言か、招待の手順の伝え方に理由があります。