Media > AI活用ユースケース > 営業 > 広告代理店がクライアントからメールで届く制作物の修正依頼を、Zapier で修正の種類と担当に分けて修正台帳に記録する

広告代理店がクライアントからメールで届く制作物の修正依頼を、Zapier で修正の種類と担当に分けて修正台帳に記録する

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

クライアントからメールで届く修正依頼を1通ずつ修正項目に切り分け、項目ごとに「修正の種類」と「担当」を決まった選択肢から選んで、修正台帳に1項目1行で記録します。見積の範囲を超えうる依頼は営業に知らせます。

サマリー
生成AI
ChatGPT/Claude
連携・自動化
Make/n8n/Power Automate/Zapier
対象業界
EC/不動産/小売/広告
対象部門
営業
対象業務
分類・仕分け/台帳・マスタ管理
主な課題
入力作業が多い/属人化している/期限・対応漏れが起きる
AIで行う処理
分類
主な効果
入力漏れ削減/対応スピード向上/工数削減
導入難易度
★★☆☆☆
実装レベル
半自動化
費用感
ノーコード連携(中)
人間の確認
条件付き
現在工数
60h/月
AI導入後
20h/月
想定削減
67%
年間削減
480h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 営業担当がクライアントからの修正依頼のメールを受け取る
  2. メールを読み、どの案件の、どの制作物についての依頼かを確かめる。件名に案件名が無いことも多い
  3. 本文から修正を1つずつ拾い出す。箇条書きのこともあれば、段落の中に3つ4つ混ざっていることもある
  4. 修正ごとに、コピーライター・デザイナー・コーダーのだれに頼むかを決める
  5. 修正の記録のスプレッドシートに、案件・制作物・修正の内容・担当・受けた日を書く
  6. 担当者にチャットで伝える
  7. 「サイズの追加」「媒体の追加」など、見積に無い依頼が混ざっていれば、追加の見積を出すかを考える
  8. クライアントに「承りました」と返信する
導入後(After)
  1. 人クライアントのドメインから届くメールに、Gmail のフィルタで「修正依頼」のラベルが付くよう設定しておく
  2. 自動ラベルが付いたことをきっかけに Zapier が動く
  3. 自動差出人のドメインと件名から、案件台帳の行を引く。案件の制作物の一覧と、いまの修正の回、見積に含む修正の回数を取り出す
  4. 自動AI by Zapier がメール本文を修正項目に切り分け、項目ごとに修正の種類・担当・対象の制作物を選ぶ
  5. 自動修正項目を1つずつ修正台帳に1行で書き込む
  6. 自動修正の回が見積の回数を超えている、または「仕様・範囲の変更」が含まれるときは、営業に知らせる
  7. 自動担当ごとに、自分の行が増えたことを知らせるメールを送る
  8. 人営業が修正台帳の新しい行を見て、`needs_review` の行と、案件を特定できなかった行を直す
  9. 人範囲外の可能性がある依頼について、追加の見積を出すかを決め、クライアントに返信する
各工程の詳しい説明を読む
  1. 営業担当がクライアントからの修正依頼のメールを受け取る
  2. メールを読み、どの案件の、どの制作物についての依頼かを確かめる。件名に案件名が無いことも多い
  3. 本文から修正を1つずつ拾い出す。箇条書きのこともあれば、段落の中に3つ4つ混ざっていることもある
  4. 修正ごとに、コピーライター・デザイナー・コーダーのだれに頼むかを決める
  5. 修正の記録のスプレッドシートに、案件・制作物・修正の内容・担当・受けた日を書く
  6. 担当者にチャットで伝える
  7. 「サイズの追加」「媒体の追加」など、見積に無い依頼が混ざっていれば、追加の見積を出すかを考える
  8. クライアントに「承りました」と返信する

(a)1通に混ざった修正の2つ目以降が落ちる。 3番目の拾い出しは、急いでいると最初の1つ2つで止まります。段落の最後に「あとロゴも少し小さく」と書かれた修正は、拾われないまま次の版が出て、クライアントから「直っていない」と言われて初めて分かります。

(b)担当の振り分けが営業ごとに違う。 「色を合わせる」をデザイナーに頼む営業もいれば、LPのボタンならコーダーに頼む営業もいます。どちらに頼むかの決まりは文書になっておらず、新しく入った営業はそのたびに先輩に聞いています。

(c)回数を超えた修正に気づかない。 修正の記録には「何を直したか」はあっても「何回目の修正か」が書かれていないことがほとんどです。3回目の修正を2回目のつもりで受け、追加の見積を出しそびれます。 仕様の変更も、修正と同じ調子で書かれているので見落とされます。

(d)記録が後回しになる。 5番目の記録は後でまとめて書こうとして忘れられ、担当が休んだ日にだれも続きを引き取れません。

  1. 【人】 クライアントのドメインから届くメールに、Gmail のフィルタで「修正依頼」のラベルが付くよう設定しておく
  2. 【自動】 ラベルが付いたことをきっかけに Zapier が動く
  3. 【自動】 差出人のドメインと件名から、案件台帳の行を引く。案件の制作物の一覧と、いまの修正の回、見積に含む修正の回数を取り出す
  4. 【自動】 AI by Zapier がメール本文を修正項目に切り分け、項目ごとに修正の種類・担当・対象の制作物を選ぶ
  5. 【自動】 修正項目を1つずつ修正台帳に1行で書き込む
  6. 【自動】 修正の回が見積の回数を超えている、または「仕様・範囲の変更」が含まれるときは、営業に知らせる
  7. 【自動】 担当ごとに、自分の行が増えたことを知らせるメールを送る
  8. 【人】 営業が修正台帳の新しい行を見て、needs_review の行と、案件を特定できなかった行を直す
  9. 【人】 範囲外の可能性がある依頼について、追加の見積を出すかを決め、クライアントに返信する

8番目で人が見るのは全行ではありません。 AIが「確信が持てない」と印を付けた行と、案件や制作物を決められなかった行だけです。残りは担当者が自分の行として受け取り、おかしければそこで営業に戻します。

6番目の判定はAIにさせません。 修正の回と見積の回数の比較は、台帳の数字を Zapier の条件分岐で比べるだけです。AIが決めるのは「この項目は仕様の変更に見えるか」までで、追加費用の話をするかどうかは営業が決めます。

02今回想定するシステム構成

構成図
クライアントからの修正依頼メール
   │  Gmail のフィルタで「修正依頼」ラベル
   ▼【トリガー】New Labeled Email
Zapier
   ├──▶ Google スプレッドシート(案件台帳)を引く
   │      差出人ドメイン・件名の案件番号 → 制作物の一覧・いまの修正の回・見積の回数
   ▼
AI by Zapier ── メールを修正項目に切り分け、種類・担当・制作物を選ぶ(line items)
   ▼
Looping by Zapier ── 修正項目ごとに繰り返す
   │   └──▶ Google スプレッドシート(修正台帳)に1項目1行を書き込む
   ▼
Paths(範囲外の可能性あり/なし)
   ├──▶ 営業へ知らせる(修正の回の超過・仕様の変更)
   └──▶ 担当ごとに新しい行を知らせる
役割想定する製品代替候補
ワークフローZapier(Gmail、Paths、Filter、Looping by Zapier)Make、Power Automate、n8n
生成AIAI by Zapier(出力項目を定めた分類)Claude、ChatGPT(OpenAI)
台帳Google スプレッドシート(案件台帳・修正台帳)Zapier Tables

新しく入れるのは Zapier だけです。 Gmail とスプレッドシートはいま使っているものをそのまま使います。最初の準備は、案件台帳に「クライアントのドメイン」「制作物の一覧」「いまの修正の回」「見積に含む修正の回数」の4つの列を足すことです。

AIの部分は AI by Zapier の1ステップです。 指示(Prompt)と、返してほしい出力項目(Output Fields)を決めて置きます。出力項目には名前と型と説明を付けられ、詳細設定で結果を一覧(line items)として返させることができます。 1通から修正項目がいくつ出てくるか分からないこの題材では、この一覧で受けるのが要です。

モデルの段階は選べます。 大量で単純な処理向けの Standard(1回の実行で1タスク)、推論の強い Advanced(3タスク)、新しく足したステップの既定である Premium(5タスク)があります。月600通なら、まず Standard で分類の精度を確かめ、足りなければ段階を上げます。 既定のままにすると、気づかないうちにタスクの消費が5倍になります。

AI by Zapier は Professional・Team・Enterprise のプランで使え、Free では使えません。 Paths も Free には含まれません。

03どうやって実装するのか

Step1

処理の起点を決める

Gmail のラベルが付いたことを起点にします。 使うのは Zapier の Gmail の「New Labeled Email」で、メールにラベルが付いたときに動きます。ラベルはクライアントのドメインごとに作った Gmail のフィルタで自動で付けます。

このトリガーは、同じ会話に返信が付いたときにも動きます。 クライアントとのやり取りが「Re:」で続くたびに、その返信も1件として流れてきます。修正依頼は返信の形で続くことが多いので、これはむしろ都合のよい動きです。ただし営業が自分で送った返信にも同じラベルが付くと、自分の「承りました」が修正依頼として分類されます。 差出人が自社のドメインのものは、最初の Filter で止めます。

「New Email Matching Search」でも組めますが、検知の対象は直近1時間のメールに限られます。 ラベルによるトリガーにはこの期限が書かれていないので、Zapier が一時止まっていた後でも取りこぼしにくい方を選びます。

Step2

入力データを集める

データ中身取得元
修正依頼のメール差出人、件名、受信日時、本文(引用部分を除いたもの)、添付ファイル名Gmail
案件の情報案件番号、クライアント名、制作物の一覧(番号と名前)、いまの修正の回、見積に含む修正の回数案件台帳(スプレッドシート)
担当の決まり修正の種類ごとの既定の担当と、例外(LP の色はコーダー、など)振り分けの表(スプレッドシート)

いちばん効くのは制作物の一覧です。 クライアントは「バナー」「あの縦長の」「先週のやつ」のように呼びます。一覧の中から番号で選ばせると、AIが勝手に新しい制作物の名前を作ることがなくなります。 一覧に無いものを指していそうなら「不明」を選ばせます。

振り分けの表は、第3章の(b)を文書にしたものです。 「文言・表記はコピー、画像の差し替えとレイアウトはデザイン、LP の上の色とボタンはコーディング、仕様の変更は営業」のように書きます。この表を作る作業そのものが、営業ごとに違っていた振り分けをそろえる場になります。

Step3

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

案件台帳はスプレッドシートの行を引く「Lookup Spreadsheet Row」で取ります。 列と値を指定して1行を探し、見つかればその行全体を返します。検索の向きは設定で選べ、False で最初の行から、True で最後の行から探します。

引くもの引き方失敗したとき
案件の行件名に案件番号(例:[A-2611])があればその列で引く次の段へ
案件の行(番号が無いとき)差出人のドメインの列で引き、補助の列「進行中」を TRUE に絞るunknown_project として営業へ
振り分けの表「Lookup Spreadsheet Rows (Advanced)」で全行(数十行)を取る既定の表を使う

順番は、案件番号が先、ドメインが後です。 1社が同時に3つ4つの案件を進めていることは普通にあり、ドメインだけで引くと、別の案件の行が返ってきます。 補助の列で「進行中」に絞っても複数残るときは、どれか1つを選ばず案件を空のまま営業に回します。

Step4

AIへ渡す前に整形する

  1. 自社からのメールを止める … 差出人のドメインが自社のものなら、Filter で止めます
  2. 引用部分を落とす … 返信で残る「〇〇様からのメッセージ:」以下の過去のやり取りを切り落とします。残すと、前回すでに対応した修正をもう一度台帳に積みます
  3. 署名を落とす … 差出人の署名にある住所や電話番号は、分類に要りません
  4. 添付ファイル名だけを渡す … 赤字入りの PDF が添付されていても、本文には「添付のとおり」としか書かれていないことがあります。ファイル名を渡し、本文に修正の中身が無いときは「添付を参照」の行を1つ作らせます
  5. 案件の情報を文字にそろえる … 制作物の一覧を「1: 秋のバナー 300×250」のように番号付きの文字にして渡します
  6. 長さを確かめる … 本文が極端に長いメール(数千字の議事録の転送など)は、分類せず営業に回します

2番目を軽く見ないでください。 修正依頼の多くは前のメールへの返信で、本文の半分以上が引用です。引用を残したまま渡すと、3週間前に直した「ロゴを小さく」が新しい修正として台帳に載り、デザイナーがもう一度直します。 返信の区切りの文字列(「-----Original Message-----」や「〇年〇月〇日 〇〇 <…> wrote:」)から後ろを落とす処理を、AI の前に1段置きます。

4番目の「添付を参照」の行は、この構成の弱いところを補う工夫です。 AI by Zapier は画像を公開された URL でしか読めず、添付の PDF の赤字を読ませる組み方は避けます。本文に書かれていない修正を、AIが推測で作らないようにするための行です。 赤字の PDF の読み取りは UC-0294 の領分です。

Step5

AIに処理させる

させるのは、本文を修正項目に切り分け、項目ごとに4つのことを選ぶことだけです。

選ぶもの選択肢決められないとき
修正の種類copy(文言・表記)/image(写真・素材の差し替え)/layout(配置・大きさ)/color(色・トーン)/spec_change(サイズ・媒体・点数の追加など)/question(質問・確認)/cancel(前の依頼の取り消し)unclear
担当copywriter/designer/coder/account(営業)振り分けの表で決まらなければ account
対象の制作物案件台帳の制作物の番号unknown
確からしさhigh/low-

切り分けの単位は「1人の担当が1回の作業で直せる単位」です。 「キャッチを変えて、背景を明るく」は、コピーとデザインに分かれるので2項目です。「キャッチと小見出しを両方『秋』に」は、同じコピーライターが1回で直すので1項目でかまいません。迷ったら分けるほうに倒させます。 分けすぎた行は人がまとめれば済みますが、まとめすぎた行の2つ目は誰にも渡りません。

させないこと理由
修正のしかたの具体化「もう少し明るく」を「明度を20%上げる」にしない。どう直すかは制作の判断
依頼文の言い換え原文をそのまま写す。言い換えると意図がずれる
修正の回の判断台帳の数字で決める。メールの言葉から「3回目」と推さない
追加費用の判断営業が決める。spec_change に分けるところまで
クライアントへの返信この構成では作らない

1行目と2行目がいちばん起きやすい失敗です。 生成AIは「もう少し高級感を」を、親切にも「フォントを明朝体に変更」と言い換えます。台帳に言い換えが載ると、デザイナーはクライアントが言っていないことを直します。 原文の欄と分類の欄を分け、原文の欄には本文の文字列をそのまま入れさせます。

Step6

指示内容を固定する

あなたは広告代理店の営業部で、クライアントから届いた修正依頼のメールを
社内の担当に振り分けるために、修正項目に切り分けて分類する係です。
修正の中身を決めたり、言い換えたりはしません。

【やること】
1. 本文から修正の依頼を1つずつ取り出してください。
   1人の担当が1回の作業で直せる単位で分けます。迷ったら分けてください。
2. 項目ごとに、次の4つを選んでください。
   - type: copy / image / layout / color / spec_change / question / cancel / unclear
   - owner: copywriter / designer / coder / account
   - deliverable_no: 下の【制作物の一覧】の番号。決められなければ "unknown"
   - certainty: high / low

【種類の決め方】
- spec_change は、サイズ・媒体・点数・ページの追加や、掲載先の変更など、
  いまある制作物を直すのではなく新しい作業を求めているものです。
  「ついでに」「追加で」「もう1つ」などの言葉があれば spec_change を疑ってください。
- cancel は、前に依頼した修正を取り消すものです。何を取り消すかを quote に写してください。
- question は、修正ではなく質問や確認です。
- owner は【振り分けの表】に従って選んでください。表で決まらなければ account にします。

【厳守事項】
- quote には、その項目の根拠になった本文の文字列を、そのまま写してください。
  言い換え、要約、具体化をしないでください。
- 「明るく」「高級感を」のようなあいまいな依頼を、具体的な数値や手法に直さないでください。
- 本文に書かれていない修正を作らないでください。
  本文が「添付のとおり」だけで中身が無い場合は、type を unclear、
  quote を「添付を参照」とした項目を1つだけ作ってください。
- 何回目の修正か、追加費用がかかるかは書かないでください。
- 制作物の一覧に無い名前を作らないでください。
- 迷ったときに high を選ばないでください。

【案件】{project_name}
【制作物の一覧】{deliverables}
【振り分けの表】{routing_table}
【添付ファイル名】{attachment_names}
【本文(引用と署名は除いてあります)】{body}

「迷ったら分けて」を書かないと、1通が1項目にまとまります。 生成AIはメールを要約しようとする癖があり、「バナーとLPの色味の調整」のような1行にまとめます。まとめた1行は、コーダーとデザイナーのどちらにも自分の仕事に見えません。

「ついでに」「追加で」を手がかりに挙げているのは、仕様の変更が修正の調子で書かれるからです。 言葉の手がかりを与えないと、「ついでに縦長も」を layout に入れます。取りこぼすより、spec_change に寄せて営業が外すほうが安全です。

Step7

出力形式を固定する

AI by Zapier の出力項目を次のように定め、line items(一覧)として受け取ります。

{
  "items": [
    {
      "seq": 1,
      "type": "copy",
      "owner": "copywriter",
      "deliverable_no": "2",
      "quote": "キャッチを「秋の新作、入荷しました」に変えてください",
      "certainty": "high"
    },
    {
      "seq": 2,
      "type": "spec_change",
      "owner": "account",
      "deliverable_no": "unknown",
      "quote": "あと、ついでにインスタ用の縦長も作れますか",
      "certainty": "low"
    }
  ],
  "mail_kind": "revision | question_only | not_revision"
}

1つ目の理由は、項目の数が決まっていないからです。 一覧で受け、後の段で1項目ずつ書き込みます。

2つ目は、seq を AI に振らせることです。 後の段の繰り返し(Looping by Zapier)は、すべての回が同時に並んで動き、順番どおりには進みません。 台帳に書き込まれる順もばらばらになるので、メールの中での順番を seq で残し、台帳の側で並べ直せるようにします。

3つ目は、mail_kind で修正依頼でないメールを早めに分けることです。 「お世話になっております。来週の打合せの件ですが」のようなメールにもラベルが付きます。not_revision なら台帳に書かず、営業への一覧にだけ残します。

修正台帳に書く行の形は次のとおりです。

列中身
受付IDGmail のメッセージ ID + seq
受信日時・差出人トリガーから
案件番号・制作物案件台帳から引いたもの、または unknown
修正の回案件台帳の「いまの修正の回」をそのまま写す
種類・担当・原文AI の出力
状態new(担当が着手したら doing、終われば done)
要確認certainty が low、または案件・制作物が unknown なら needs_review
Step8

システムへ連携する

つなぎ先方式内容
GmailZapier の Gmail(New Labeled Email)ラベルの付いた修正依頼を受け取る
案件台帳Google スプレッドシート(Lookup Spreadsheet Row)案件・制作物・修正の回を引く
AI by ZapierZap の中のステップ切り分けと分類
修正台帳Google スプレッドシート(行の作成)を Looping の中で1項目1行で書き込む
営業・担当への知らせGmail(Send Email)を Paths の先で範囲外の可能性と、担当ごとの新しい行

繰り返しは Looping by Zapier で行います。 一覧(line items)を入力にして、項目ごとに後のステップを回せます。1回の Zap で回せるのは500回までで、ループの入れ子はできません。 修正項目が500を超えるメールはまずありませんが、ループは1つの Zap に1つだけと決めて組みます。

Looping by Zapier は公開ベータです。 ループそのものはタスクを使いませんが、ループの後ろのステップは1回ごとに1タスクを使います。1通8項目なら、書き込みだけで8タスクです。

範囲外の判定は Paths で行います。 1つの Paths のまとまりに分岐は10本まで置け、条件は数値の「Greater than」などで書けます。数値の条件は数字の値にしか効かないので、修正の回は「2回目」ではなく 2 という数字で台帳に持たせます。 分岐は2本です。

分岐条件行き先
範囲外の可能性いまの修正の回が見積の回数より大きい、または spec_change を含む営業へメール
通常上に当たらない(Fallback)担当ごとに知らせる

spec_change を含むかは、AI の出力の種類の列を文字の条件「Contains」で見ます。 文字の条件は大文字と小文字を区別しません。

案件台帳には書き込みません。 「いまの修正の回」を進めるのは営業です。AI がメールの言葉から「再校です」と読んで回を進めると、クライアントの言い間違い1つで、追加の見積の根拠がずれます。

Step9

人が確認する

人が確認するのは、修正台帳で needs_review の付いた行と、営業に届いた範囲外の知らせだけです。 全行を営業が見直す設計にすると、第10章の20.0時間には収まりません。

  1. unknown の案件・制作物を埋める … 多くは件名に案件番号が無いメールです。埋めたら、そのクライアントに件名の案件番号のお願いをもう一度します
  2. certainty: low の行を確かめる … 種類と担当を見直し、必要なら行を分けるかまとめます
  3. spec_change の行を判断する … 追加の見積を出すか、サービスとして受けるかを決めます。決めた結果を台帳の「範囲の判断」の列に書きます
  4. 修正の回を進める … 1つの回の依頼が出そろったら、案件台帳の「いまの修正の回」を1つ上げます

担当者の側にも確認の役目があります。 自分の行として届いた修正が自分の仕事でなければ、状態を returned にして営業に戻します。戻ってきた行は、振り分けの表を直す材料になります。

Step10

例外に対処する

起きること対応
案件を特定できない案件を unknown にして台帳に書き、needs_review で営業へ
1つのドメインで進行中の案件が複数どれか1つを選ばず unknown にする
本文が「添付のとおり」だけunclear・「添付を参照」の1行を作り、営業が添付を見て分ける
修正依頼でないメールnot_revision は台帳に書かず、営業への日次の一覧にだけ残す
前の依頼の取り消しcancel の行として書き、取り消された元の行は消さない。営業が元の行の状態を cancelled にする
AI のステップが失敗するZap の実行履歴に残る。ラベルを「修正依頼-未処理」に付け替える手順を営業の朝の作業に入れる
修正項目が極端に多い(20以上)議事録の転送などを疑い、分類はそのまま台帳に書いたうえで営業へ知らせる
同じメールが二度流れる受付ID(メッセージ ID + seq)で台帳を引き、あれば書かない

5行目の「元の行を消さない」が大事です。 「やはり赤はやめて」という取り消しを受けて元の行を消すと、デザイナーがすでに赤に直していた場合に、何を戻せばよいかが台帳から分からなくなります。 取り消しも1行の依頼として残します。

Step11

記録を残す

  • 修正台帳の全行(受付ID、原文、種類、担当、制作物、修正の回、状態、要確認)
  • 人が直した記録 … 種類・担当・制作物を、何から何に変えたか
  • 範囲外の判断の記録 … 追加の見積を出したか、サービスとしたか
  • returned になった行と、戻した担当者
  • AI の出力の全文(line items)。Zap の実行履歴とは別に、台帳の別シートへ写しておく
  • 月ごとの、修正の種類別・担当別・クライアント別の件数

04実装レベルの3段階

最小構成:修正依頼のメールを手で生成AIの画面に貼り、項目の切り分けと分類をさせる / 1通ごとの切り分けと分類
半自動化:上記+Zapier で Gmail のラベルを起点に動かし、案件台帳を引いて修正台帳に1項目1行で書き込み、範囲外の可能性を営業に知らせる / 受付・分類・記録・知らせ
本格構成:上記+担当ごとの作業の割り当てを制作管理のツールに作り、修正の回の締めと次の版の送付を台帳から追う / 修正の受付から次の版の送付までの追跡

本記事の想定は半自動化です。 受付から記録までが自動になり、営業に残るのは needs_review の行と範囲外の判断です。1通6分が2分になる見込みはこの段階のものです。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
6 名
月間件数
600 件
1件あたり現在時間
6 分
1件あたり導入後時間
2 分
現在  600件 × 6分 ÷ 60 = 60 時間/月
導入後 600件 × 2分 ÷ 60 = 20 時間/月
月間削減時間
40h
削減率
67%
年間削減時間
480h
年間金額換算(時間単価4,000円)
192万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 1人の営業担当が10社前後のクライアントを持ち、バナー・チラシ・LP などの制作物の修正依頼がメールで日に何通も届く広告代理店・制作会社。修正の内容を営業が読み解いて社内の担当へ振り分けており、振り分けと記録に時間がかかっている場合。見積に修正の回数を書いているのに、回数を超えた修正の追加費用を言い出せずにいる場合。
向いていない
  1. 修正依頼がすべて校正ツールや制作管理のシステムの上で受け付けられ、メールで届かない場合。クライアントが数社で、修正依頼が月に数十件にとどまる場合。修正の内容そのもの(どう直すか)の判断を自動化したい場合は、この構成では扱いません。

07最小構成で試す方法

  1. 先月の修正依頼のメールから30通を選ぶ(1通に3つ以上の修正が入っているもの、仕様の変更が混ざっているもの、取り消しを含むものを必ず入れる)
  2. 30通について、当時の修正の記録に何行書いたかを数えておく
  3. 案件の制作物の一覧と、振り分けの表を文字で用意する
  4. 手元の生成AI(ChatGPT、Claude、Gemini など)の画面に、第7章のプロンプトと1通ずつの本文を貼り付ける
  5. 出てきた項目の数・種類・担当を、当時の記録と突き合わせる

見るのは、項目の数が当時の記録より多いか少ないかです。

出てきた内容判断
当時の記録より項目が多く、増えた分が本文に実際にある修正だった当時の取りこぼしが見つかった。 Zapier への組み込みに進む
1通が1項目にまとめられる「迷ったら分けて」の指示を強める
「ついでに」の依頼が layout に入る種類の決め方の手がかりを増やす

08実装時につまずきやすいポイント

問題対策
1通が1項目にまとめられる「迷ったら分けて」を指示に書く。最小構成で粒度を固める
自分の返信が修正依頼として流れる自社のドメインからのメールを最初の Filter で止める
ドメインで引くと別の案件が返る件名の案件番号を先に引く。複数残ったら選ばず unknown
「ついでに」の依頼が修正扱いになる言葉の手がかりを指示に入れ、spec_change に寄せる
原文が言い換えられる原文の欄と分類の欄を分け、「そのまま写す」を明記する
Looping の書き込みの順がばらばらすべての回が並んで動く。seq を持たせて台帳で並べ直す
Paths の数値の条件が効かない数値の条件は数字にしか効かない。修正の回を 2 のように持つ
Human in the Loop を書き込みの後に入れたいLooping の中や後には置けない。 人の確認は台帳の上で行う
取り消しで元の行を消してしまう取り消しも1行で残し、元の行は状態を変えるだけにする

上の2行が、運用に乗るかを分けます。 どちらも「台帳の行が、実際の修正と1対1で対応しているか」の問題で、行が多すぎても少なすぎても、担当者は台帳を見なくなり、元のチャットに戻ります。

下から2行目は、組んでから気づくことが多い制約です。 Zapier の Human in the Loop(承認を待つステップ)は、Looping のステップの中や後ろに置けません。この構成では、人の確認を Zap の途中で止める形にせず、台帳の needs_review の列で行います。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: クライアントの担当者の氏名とメールアドレス、案件の名前、発表前のキャンペーンや新商品の情報、物件の広告なら物件の所在地や価格です。

  1. 発表前の情報が外部の AI に渡ることを、契約で確かめる … クライアントとの秘密保持の取り決めに、外部のサービスでの処理が許されるかを確かめます。許されない案件は、案件台帳に印を付けて Filter で止め、従来どおり人が仕分けます
  2. AI に渡すのは本文の必要な部分だけにする … 前処理で署名と引用を落とすのは、精度のためだけでなく、渡す情報を減らすためでもあります
  3. クライアントへの返信を自動で送らない … この構成はクライアントに何も送りません。範囲外の話は特に、営業が言葉を選んで伝えるものです
  4. 追加費用の判断を AI に寄せない … spec_change は「新しい作業に見える」という分類で、請求できるかどうかの判断ではありません。 見積書の文言と、それまでのやり取りを見て営業が決めます
  5. 台帳の共有範囲を絞る … 修正台帳には全クライアントの案件が載ります。制作の担当者には自分の行が見えれば足ります。 共有の設定で、クライアントの担当者の連絡先の列は営業だけが見られるようにします

誤りが起きた場合のリスクは、修正が担当に渡らないことと、追加費用の相談の根拠を誤ることの2つです。 前者は切り分けの粒度、後者は修正の回の扱いから起きます。修正の回を AI に判断させず台帳の数字で持つのは、後者を防ぐためです。

10まず何から始めるか

1週目:振り分けの表を作る

営業6名で集まり、修正の種類ごとにだれへ頼んでいるかを書き出します。食い違ったところが、そのまま決めるべき点です。 「LP の色」「バナーの中の文字の大きさ」のような境目の例を10個ほど並べて、1つずつ決めます。

2週目:30通で試す

先月のメールから30通を選び、手元の生成AIで切り分けと分類をさせます。当時の記録と項目の数を突き合わせ、取りこぼしがあったかを最優先で見ます。

3週目:案件台帳を整える

案件台帳に「クライアントのドメイン」「制作物の一覧」「いまの修正の回(数字)」「見積に含む修正の回数(数字)」の列を足します。進行中の案件から埋め、同時に、主なクライアントに件名の案件番号のお願いをします。

4週目:営業1人分の Zap を作る

修正依頼の多い営業1人の受信箱で、Gmail のラベルから修正台帳への書き込みまでを作ります。この時点では範囲外の知らせを出さず、台帳に積まれた行を本人と制作の担当者が毎日見ます。

2か月目: Paths で範囲外の知らせを足し、6名分に複製します。needs_review と returned の行を毎週数えます。3か月目以降: 人が直した記録をもとに振り分けの表とプロンプトを見直し、1通6分が何分になったかを実測します。営業が修正の記録を自分で書かなくなり、制作の担当者が台帳から仕事を拾うようになった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-28/最終更新:2026-10-29
確認した内容情報源確認日
AI by Zapier が指示と出力項目(名前・型・説明・必須)で動き、詳細設定で結果を line items の一覧で返せること。モデルの段階が Standard(1タスク)・Advanced(3タスク)・Premium(5タスク、新しいステップの既定)であること。Professional・Team・Enterprise で使え Free では使えないこと。画像は公開された URL のみで、Web サイトや URL から取り出せないことZapier: Use AI by Zapier to analyze and return data2026-10-28
Gmail の New Labeled Email がラベルが付いたときと会話に返信が付いたときに動くこと。New Email Matching Search などの検知の対象が直近1時間であること。Send Email・Create Draft などの操作Zapier: How to get started with Gmail on Zapier2026-10-28
Lookup Spreadsheet Row が列と値で1行を探し、検索の向きを選べること、補助の列で絞れること。Lookup Spreadsheet Rows (Advanced) が最大500行を返すことZapier: Find and update spreadsheet rows in Google Sheets2026-10-28
Looping by Zapier が最大500回で、すべての回が並んで動くこと。ループの後ろのステップが1回ごとに1タスクを使うこと。ループの入れ子ができないこと。公開ベータであることZapier: Understanding Looping by Zapier2026-10-28
Paths が1つのまとまりに最大10本の分岐、Fallback を1本置けること。Free に含まれないことZapier: Add branching logic to Zap workflows with Paths2026-10-28
条件の種類(文字の Contains など、数値の Greater than など)。文字の条件が大文字と小文字を区別しないこと、数値の条件が数字の値にしか効かないことZapier: Filter and path rules in Zaps2026-10-28
Human in the Loop が Looping の中や後に置けないこと。Professional では承認の依頼を自分にしか送れないことZapier: Request approval with Human in the Loop2026-10-28

追加費用を請求できるかどうかは、見積書と契約の文言、それまでのやり取りで決まります。 本記事は Zapier の公開情報で確認できた範囲の構成を扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-2202)についてのご相談はこちらから。

AI活用について相談する
目次