クライアントの赤字やメールの修正指示を1件ずつの一覧にし、次の版での反映漏れを確かめる

処理の起点を決める

Apps Script を定期的に動かし、案件フォルダの「戻し」に新しいファイルが無いかを見ます。 戻しは1日のうちに何度も届くので、夕方にまとめて処理する形にはしません。 午前の戻しを午後に書き起こしていると、その間にデザイナーが古い指示で手を動かします。

入る経路は3つです。フォルダに保存したPDFや画像、ラベルを付けたメール、チャットのスクリーンショットを保存したものです。チャットは本文をそのまま貼り付けたテキストファイルでも構いません。いずれも案件フォルダに入れた時点で、どの案件の戻しかが決まります。

メールは、担当者が案件ごとに決めたラベルを付けます。Apps Script の GmailApp には、クエリで Gmail を検索する search() と、名前でラベルを取得する getUserLabelByName() があります。処理したメールには別のラベルを付け、二度読まないようにします。

次の版の照合は、「版」フォルダに新しいファイルが入ったときに動かします。ファイル名に版の番号（_v3 など）を付ける決まりにし、番号の無いファイルは照合しません。

入力データを集める

質を決めるのは、台帳と指示者の一覧です。 台帳が無ければ、「前回の件は取り消し」と書かれた戻しの「前回の件」を指す先がありません。指示者の一覧が無ければ、担当者の指示と上長の指示が逆だったときに、どちらが優先かを人に回せません。

対象の版も一緒に渡します。 赤字の「ここ」「この写真」は、元の制作物と並べないと何を指すかが決まらないことがあります。

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

戻しのファイルは、Apps Script からGoogleドライブのフォルダを読み、Gemini API に渡します。大きいファイルや、何度も使うファイルは Files API でアップロードして参照します。 Files API は、リクエスト全体の大きさが100MBを超えるとき（PDFは50MB）に使うとされています。1ファイル2GBまで、1プロジェクト20GBまでで、アップロードしたファイルは48時間保存され、API で手動で削除することもできます。

メールの本文と添付は、1回の戻しとしてまとめて渡します。 本文に「添付のとおり」とあり、添付に赤字がある形が多いためです。分けて読ませると、本文の指示が添付の赤字と重なって二重に数えられます。

照合に渡す指示は、その制作物の open のものだけです。 完了した指示まで渡すと、照らす範囲が広がり、確かめる側の一覧も長くなります。

AIへ渡す前に整形する

1. 形式の確認 … PDFと画像（PNG、JPEG、WEBP、HEIC、HEIF）以外はPDFにします。Office形式のまま渡すと、赤字の書き込みが失われます
2. 向きの確認 … ページは正しい向きに回転させてから渡すことが推奨されています。横向きに撮った校正紙の写真が、いちばん多い原因です
3. ぼけの確認 … ぼやけたページは避けるよう推奨されています。手書きの赤字が読めないものは撮り直しを頼みます
4. サイズとページ数の確認 … PDFは50MBまたは1,000ページが上限です。カタログの全ページを1ファイルにした戻しは、赤字のあるページだけに分けます
5. メール本文の整理 … 署名、過去のやり取りの引用部分を外し、その回に書かれた本文だけを渡します
6. 版の特定 … 戻しがどの版に対するものかを、ファイル名かメールの件名から取ります。分からないものは最新の版として扱わず、人に回します

5番目を軽く見ないでください。 引用部分を残すと、3回前の指示が、今回の新しい指示としてもう一度台帳に入ります。

AIに処理させる

させるのは2つです。戻しから修正指示を1件ずつ取り出すことと、次の版でそれが反映されていそうかを見ることです。

1つ目の抽出では、1件ごとに次を返させます。

「質問」を種類に入れているのは、修正指示と区別するためです。 「この写真はどこで撮ったものですか」は直すものではなく、答えるものです。修正指示と同じ列に並ぶと、答えずに「反映済み」になります。

2つ目の照合では、未完了の指示と次の版を渡し、1件ずつ次のどれかを付けさせます。

「元気な感じに」「もう少し目立たせて」のような主観の指示は、cannot_judge に固定します。 変わったかどうかは見えても、指示どおりになったかは画像からは決まりません。

2行目がいちばん起きやすい失敗です。 「価格大きく」を「価格を大きくして視認性を高める」と書き直すと、後から読む人には、どこまでがクライアントの言葉か分からなくなります。

指示内容を固定する

1つ目（抽出）の指示：

あなたは広告制作の進行担当として、クライアントからの修正指示を一覧にします。
渡された戻し（赤字の入ったPDF・画像・メール本文）だけを見て答えてください。

【やること】
- 修正指示を1件ずつに分けてください。1つの赤字や1つの段落に
  複数の指示がある場合は、別々の要素にしてください。
- quote には、赤字やメールの文をそのまま写してください。
  言い換え、補足、要約をしないでください。
- 赤字の位置は、ページ番号と box_2d（[ymin, xmin, ymax, xmax]、
  0〜1000に正規化）で返してください。メール本文の指示は位置を空にします。
- type は text_replace / text_add / text_delete / image_replace /
  color_layout / question / other から選んでください。
- 質問や確認の依頼は question にし、修正指示として扱わないでください。

【厳守事項】
- 手書きが読めない箇所は、推測で埋めず status を unreadable にしてください。
- 指示の意図を補わないでください。書かれていないことを書かないでください。
- 【これまでの指示】を取り消す・上書きすると読める場合は、
  related_ids に候補の指示IDを入れてください。取り消しと確定はしないでください。
- 指示者が複数いて内容が食い違う場合は、両方を別の要素にし、
  conflict を true にしてください。どちらかを選ばないでください。
- デザインの評価や、指示に無い修正の提案をしないでください。
- メールの引用部分（「>」で始まる行や、過去のやり取り）は読まないでください。

【案件】{project}
【対象の版】{target_version}
【これまでの指示】{open_requests}
【クライアント側の指示者】{client_members}

2つ目（照合）の指示：

あなたは、修正指示が次の版に反映されているかの候補を出す立場です。
【未完了の指示】の1件ずつについて、【次の版】を見て判定してください。

【判定の選び方】
- likely_done ...... 指示どおりに変わっていそう。該当箇所を evidence に写す
- likely_missing ... 指示の対象の箇所が、元のまま残っていそう
- cannot_judge ..... 画像だけでは判断できない。理由を reason に書く
迷ったときに likely_done を選ばないでください。

【厳守事項】
- 「元気に」「目立たせて」など、見た目の印象を求める指示は、
  変化があっても cannot_judge にしてください。
- 文言の指示は、次の版の文字列をそのまま evidence に写してください。
- 反映済みと確定する言い方をしないでください。
- 指示に無い変更や誤りを見つけても、この判定には含めないでください。

「迷ったときに likely_done を選ばない」を明記しないと、ほとんどが likely_done になります。 次の版はたいてい前の版から何かしら変わっており、変わっていることを反映の根拠にしてしまいます。禁じるのは、変化を反映とみなす判断そのものです。

「引用部分を読まない」を指示にも書いているのは、前処理で外し切れないためです。 クライアントによっては、引用の記号を付けずに前のやり取りを本文の下に貼ってきます。

出力形式を固定する

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

{
  "source_id": "",
  "target_version": "",
  "requests": [
    { "quote": "", "type": "text_replace", "page": 1,
      "box_2d": [0, 0, 0, 0], "status": "ok | unreadable | split_uncertain",
      "related_ids": [], "conflict": false, "requested_by": "" }
  ]
}

照合は、指示IDごとに verdict（likely_done | likely_missing | cannot_judge）、evidence、reason を返させます。

Gemini API の構造化出力では、JSONスキーマで出力の形を指定でき、enum で値を決まった選択肢に限り、required で必須の項目を決められるとされています。type と verdict を enum にしておくと、「たぶん反映済み」のような自由な言葉が入りません。

1つ目の理由は、指示IDを台帳の側で振れることです。 AIは requests を並べるだけで、IDは Apps Script が 案件-版-連番 の形で振ります。IDをAIに作らせると、同じ指示に別の番号が付きます。

2つ目は、status と台帳の状態を別の層に置けることです。 split_uncertain や conflict は、台帳では open のまま「要確認」の印を付けます。分け方を人が直しても、原文と位置はそのまま残ります。

3つ目は、値の検証を後段で行えることです。 公式の説明でも、出力は構文として正しいJSONでも、値はアプリケーションの側で検証すべきとされています。box_2d が0〜1000の範囲か、related_ids が台帳に実在するIDかを、Apps Script で確かめます。大きく深い入れ子のスキーマは受け付けられないことがあるとされているため、形は上の程度に留めます。

システムへ連携する

台帳への書き込みは追記だけにします。 状態の変更も、元の行を書き換えず、状態の列と確定者の列を足していきます。過去の行を上書きすると、担当が替わったときに経緯が追えなくなります。

クライアントへもデザイナーへも、自動では送りません。 送るのは人で、この構成が出すのは台帳の行までです。

人が確認する

人が確かめるのは2か所です。 抽出の直後と、照合の直後です。全件を元の赤字と見比べる設計にすると、第10章の20.0時間には収まりません。

1. 抽出の直後に分け方を見る … split_uncertain、unreadable、conflict の付いた行を先に見ます。多くは1行を分けるか、2行をまとめるかで解決します
2. 取り消しの候補を確定する … related_ids の付いた行は、本当に前の指示を取り消しているかを確かめ、取り消すなら前の指示の状態を superseded にします
3. 照合の直後に likely_missing を見る … 次の版の該当箇所を開き、直っていなければデザイナーに戻します
4. cannot_judge を目で見る … 主観の指示はここに来ます。クライアントの好みを知っている担当者が判断します
5. likely_done を流し見て確定する … 位置の座標から該当箇所を開き、確定の印を付けます

3番目より5番目のほうが省かれやすいので注意してください。 likely_done と出た指示の中に、半分だけ直っているものが混ざります。 確定の印を人が付ける決まりにしておけば、少なくとも誰が確かめたかは残ります。

例外に対処する

上の2行が大半を占めます。 どちらもAIの問題ではなく、戻しの受け取り方の問題です。 撮影の向き、赤ペンの太さ、PDFへの書き込み方をクライアントと決めるほうが、指示を工夫するより効きます。

記録を残す

• 元の戻しのファイルと、受け取った日時・経路（PDF／写真／スクリーンショット／メール）
• Gemini API が返したJSONの全文（抽出と照合の両方）
• 台帳の全行（指示ID、原文、位置、種類、状態、確定者、反映した版）
• 人が分け方や判定を直した記録 … どの行を、どう直したか
• 取り消し・上書きの関係（superseded にした指示と、取り消した側の指示）
• クライアントごとの unreadable と conflict の件数

3つ目の「反映した版」が、引き継ぎの要です。 新しい担当者は台帳の1行から、いつ誰が何と言い、どの版で直し、誰が確かめたかを追えます。

Files API にアップロードしたファイルは、処理が終わったら削除します。 48時間で自動的に削除されますが、クライアントの未公開の制作物を、必要以上に外部に置かないためです。