広告主から届く修正の指示をメールとチャットから拾い集めて、制作チームへ渡す修正指示書にまとめる

処理の起点を決める

トリガーは2段に分けます。 1段目は「ためる」、2段目は「まとめる」です。

1段目は、メールとチャットが届くたびに動きます。 Gmail Trigger は設定した間隔で新着を確かめ、Slack Trigger はチャンネルへの投稿のたびに動きます。どちらも、届いた内容を案件ごとの受付の一覧へ1行ずつ書き足すだけで、AIは呼びません。 この段で要約を始めると、指示が出そろう前の中途半端な下書きが何度も届きます。

2段目は、ディレクターの締めの合図で動きます。 共有チャンネルの広告主の「まとめて送りました」の投稿に、ディレクターが決めた絵文字のリアクションを付けます。Slack Trigger の「リアクションの追加」のイベントで、特定の絵文字が付いたときだけワークフローを進めます。リアクションは広告主から見えてしまうので、社内チャンネルに転送した投稿の側に付ける運用も選べます。

締めをディレクターの手に残すことで、締めた後に届いた指示は次の回に入る、という線引きがはっきりします。 未処理の行が48時間以上たまった案件はチャットで知らせますが、自動で締めることはしません。

入力データを集める

質を決めるのは、下の3つです。 制作物の一覧が無いと、AIは「上のバナー」「2枚目」のような言い方を、どの制作物のことか決められません。担当者の一覧が無いと、食い違いがあったときに、誰と誰の指示が食い違っているのかを示せません。

前回の修正指示書は、「前回の件、まだ直っていません」という指示を読むために渡します。 電話の内容は社内チャンネルへの転送メモだけを入力にし、メモが無い電話の指示はこの構成からは見えないことを、全員の取り決めにします。

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

案件コードの判定が、取得の段でいちばん大事な作業です。 メールは件名に案件コードを入れてもらう取り決めにし、無ければ送信者のドメインと、スレッドの過去のメールから引きます。チャットはチャンネルで案件が決まります。判定できなかったものは「案件不明」の行としてため、締めの前にディレクターに振り分けてもらいます。 推測で案件に入れると、別の広告主の指示が混ざります。

Slack Trigger の登録には、Slack のアプリとイベントの購読の設定が要ります。 必要なスコープとして少なくとも conversations.list と users.list が挙げられています。Slack はアプリごとに webhook を1つしか登録できないとされているため、テスト用と本番用のワークフローを同時には動かせません。検証のあいだは本番のワークフローを止めるか、アプリを分けます。

スレッドの親投稿も取ります。 「こちらもお願いします」だけの投稿は、親投稿が無いと何への指示か分かりません。

AIへ渡す前に整形する

1. 署名とあいさつを落とす … メールの末尾の署名、「いつもお世話になっております」などの定型文を落とします。本文の中の指示を消さないよう、落とすのは決まった型に当てはまる部分だけにします
2. 引用を落とす … 返信メールに含まれる前のメールの引用部分を落とします。引用を残すと、同じ指示が何通分も重複して数えられます
3. 時刻順に並べる … メールとチャットを1本の時系列にします。メールは送信日時、チャットは投稿日時を使います
4. 発言者と経路の印を付ける … 各行に「誰が」「どの経路で」を付け、担当者の一覧の役割を添えます
5. 添付ファイルの名前を残す … 修正を書き込んだPDFや画像が添付されていれば、その名前を指示の行に付けます。中身は読みません（例外処理を参照）
6. 前回の締め以降に絞る … 前回の締めの時刻より後のものだけを渡します
7. 分量を確かめる … 1回分のやり取りが極端に長い場合は、制作物ごとに分けて渡します

2番目を軽く見ないでください。 5往復のスレッドでは同じ指示が5回現れ、どれが元の発言か分からなくなって発言者と時刻がずれます。 打ち消しの判定は時刻で決まるので、一番大事な判定が崩れます。

AIに処理させる

させるのは、やり取りを指示の単位に分け、それぞれに制作物と箇所を付け、4種類の印を付けることです。 指示の中身を言い換えることはさせません。

打ち消しと食い違いを分けているのが、この表の要点です。 同じ担当者が「やはりやめて」と書いていれば打ち消しで、後の指示が残ります。別の担当者が逆のことを言っているだけなら食い違いで、どちらが残るかは決めません。 責任者の一言が担当者の指示より優先されるのか、法務の指摘が常に優先されるのかは、広告主ごとの取り決めで、文面からは分からないからです。

1行目がいちばん起きやすい失敗です。 要約の指示を出すと、AIは読みやすい文章にしようとして、あいまいな指示を具体的な言葉に置き換えます。読みやすくなるほど、広告主の言ったことから離れます。

指示内容を固定する

あなたは広告代理店の制作ディレクターの補助として、広告主から届いた
修正の指示を整理する立場です。
渡すやり取りだけを見て整理してください。推測で補わないでください。

【やること】
1. やり取りを読み、修正の指示を1件ずつに分けてください。
   1つの投稿に複数の指示があれば、分けてください。
2. 各指示に、制作物の一覧のコード（target_code）と、
   直す箇所（location）を付けてください。
   一覧のどれに当たるか決められなければ target_code を "unknown" にしてください。
3. 指示の部分の文字列を、original_text にそのまま写してください。
   言い換え、要約、補足をしないでください。
4. 次の印を付けてください。
   - duplicate ... 同じ内容の指示が、先に別の行で出ている
   - revoked ..... 同じ発言者が、後の発言でこの指示を取り消している、
                   または上書きしている
   - conflict .... 別の発言者が、この指示と逆の指示を出している
   - ambiguous ... 何をどう直すかが、文面からは決まらない
   迷ったときは、印を付けない側ではなく conflict または ambiguous に
   倒してください。

【厳守事項】
- あいまいな指示を具体的な修正に言い換えないでください。
  「もう少し目立たせて」は、そのまま写し、ambiguous としてください。
- 担当者どうしの指示が食い違うとき、どちらかを採用しないでください。
  両方を残し、conflict としてください。
- revoked は、同じ発言者が取り消している場合だけに使ってください。
  別の発言者の逆の指示は revoked ではなく conflict です。
- 「添付のとおり」「画像のとおり」とある指示は、添付の中身を推測せず、
  attachment_ref に添付ファイルの名前を入れ、ambiguous としてください。
- 修正が不要と思われる指示も、外さずに載せてください。
- 修正の方法を提案しないでください。
- ambiguous と conflict の指示には、広告主へ確認するための質問を
  question に1文で書いてください。質問は「AとBのどちらですか」のように、
  答えが選べる形にしてください。

【制作物の一覧】{deliverables}
【広告主側の担当者の一覧】{client_members}
【前回の修正指示書】{previous_sheet}
【今回のやり取り（時刻順）】{messages}

「迷ったら印を付ける側に倒す」のは、見落としの向きをそろえるためです。 打ち消しや食い違いの見落としは次の校正で戻り、印が多すぎる分はディレクターが外すだけで済みます。

revoked と conflict の違いを2か所に書いているのは、混ざりやすいからです。 「後の指示が優先」に寄ると、責任者の指示で担当者の指示を静かに消してしまいます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力で、このスキーマに沿った形で返させます。

{
  "project_code": "",
  "round": 0,
  "instructions": [
    {
      "id": "",
      "target_code": "",
      "location": "",
      "original_text": "",
      "speaker": "",
      "channel": "email | shared_chat | internal_chat",
      "sent_at": "",
      "flag": "none | duplicate | revoked | conflict | ambiguous",
      "related_ids": [],
      "attachment_ref": "",
      "question": ""
    }
  ],
  "previous_open_items": []
}

1つ目の理由は、修正指示書の列にそのまま入ることです。 target_code、location、original_text がそれぞれスプレッドシートの列になり、ディレクターが清書する作業がなくなります。

2つ目は、flag と related_ids で、打ち消しと食い違いの相手が追えることです。 revoked の指示には、取り消した側の指示の id が入り、conflict には逆の指示の id が入ります。ディレクターは、印の付いた行から相手の行へ飛んで、原文どうしを見比べられます。

3つ目は、自由文の要約では何が抜けたかが分からないことです。 1件1行の形なら、行の数とやり取りの中の指示の数を見比べられます。

previous_open_items には、前回の修正指示書で「保留」だったもののうち、今回のやり取りで触れられていないものを入れます。広告主が忘れている保留は、ディレクターが思い出させる役目です。

構造化出力は output_config.format に json_schema を指定して使います。数値の範囲の制約はスキーマに書けないため、round の値は n8n の側で確かめます。

システムへ連携する

修正指示書は回ごとに新しいシートとして書き込み、前の回を上書きしません。 広告主へのメールも送りません。質問の候補を書き出すまでで、送るのはディレクターです。

制作管理ツールへの登録は、この構成の外にします。 登録するならそのツールのAPIに合わせた個別の実装が要り、最初は修正指示書のURLをタスクに貼るだけで足ります。

人が確認する

ディレクターが確かめるのは、印の付いた行と、行の数です。

1. 行の数を見る … やり取りの中の指示の数と、修正指示書の行の数がおおよそ合っているか。極端に少なければ、取得か前処理で落ちています
2. conflict を判断する … 両方の原文を見比べ、広告主との取り決めでどちらに従うかを決めます。決められなければ、質問として広告主に返します
3. revoked を確かめる … 取り消した側の原文を読み、本当に同じ発言者の取り消しかを見ます
4. ambiguous の質問を直す … AIが書いた質問を、その広告主に合った言い方に直します
5. target_unknown を振り分ける … 制作物が決まらなかった指示を、正しい制作物に付け直します
6. 印の無い行を流し見る … 原文と箇所が合っているかを、上から読みます

2番目は省けません。 食い違いの扱いは広告主の中の力関係と案件の経緯で決まり、AIに任せると文面の強さで決まってしまいます。

目標は1回あたり7分です。 印の付いた行が2割を超える回が続く広告主とは、指示の出し方を相談します。

例外に対処する

2行目は、広告の仕事では多く起きます。 赤字を書き込んだPDFや丸を付けたスクリーンショットは、文字として届いていないので読みません。 赤字の位置と意味を結びつけるのは難しく、まずは「添付あり」の印を確実に付けます。

「0件」は必ず止めます。 取得の失敗で空の修正指示書が制作チームへ渡る事故を防ぎます。

記録を残す

• 受付の一覧に入ったやり取りの原文と、送信者・経路・日時
• 締めの合図を付けた人と時刻
• AIへ渡した入力の全文（前処理の後）と、返ってきたJSONの全文
• 回ごとの修正指示書のシート
• ディレクターが印を外した・付けた・判断した記録 … どの行を、どう変えたか
• 広告主へ送った質問と、その返事

締めの合図を付けた時刻を残すのは、線引きの記録になるからです。 「その指示は送ったはずです」と言われたときに、締めより前に届いていたのか、後に届いていたのかを確かめられます。

判断の記録は、プロンプトを直す材料になります。