屋外広告・交通広告の掲出写真を発注した媒体・面・期間・原稿と照らし、掲出の誤りと写真の不備を広告主への掲出報告の前に拾う

処理の起点を決める

15分おきの時間主導型トリガーで、ラベル「掲出写真」の付いた未処理のメールを探します。 媒体社からのメールには、Gmail のフィルタで送り主ごとにラベルを付けておきます。処理したメールには「処理済み」のラベルを付け、次の検索から外します。 処理済みにするのは、すべての写真の判定が一覧に書けたときだけです。

1回の実行は6分までです。 月初の月曜に数百枚が届いても、1回の実行で処理するメールの数を決めておき、残りは次の15分に回します。 トリガーの1日の合計の実行時間は Google Workspace のアカウントで6時間までです。

掲出の期間の途中で届く中間の写真は、急ぎません。 期間の途中に撮られた写真は、夜にまとめて Batch API に送る形にできます。Batch API は通常の半分の費用で、目標の完了は24時間以内とされ、48時間を超えて終わらないジョブは結果が取れません。掲出の初日の写真は、その日のうちに結果が要るので通常の呼び出しにします。

インストール型のトリガーは作った人のアカウントで動きます。 媒体社からのメールを受ける営業部の共用のアカウントで作ります。

入力データを集める

質を決めるのは、照らす文字の表です。

版を改訂したら、照らす文字も改訂した版で登録し直します。 第1版の行を消さずに残し、写真の文字が第1版と合えば「旧版が貼られている」と分かるようにします。

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

メールの本文から、面の番号と撮影日を取ります。 媒体社ごとに本文の書き方が違うので、本文から番号と日付を取り出す規則を媒体社ごとに持ちます。 規則で取れない本文は、その行を review にして営業に回します。

添付ファイルは、本文に埋め込まれた画像を除いて取り出します。 媒体社の署名のロゴが本文に入っていると、それも画像として拾われます。添付の取り出しでは、埋め込みの画像を含めない指定ができます。

撮影日は、メールの本文の記載を使います。 掲出期間の初日より前の撮影日なら、掲出の前に撮った写真が送られてきた可能性があるので review にします。

AIへ渡す前に整形する

1. 形式の確認 … PNG、JPEG、WEBP、HEIC、HEIF のどれかであることを確かめます。PDFで届いた報告は、この構成では扱わず営業に回します
2. 大きさの確認 … 近景・遠景・原稿の画像と指示を合わせて20MBを超えないよう、大きすぎるものは縮めます
3. 面ごとの組み合わせ … 1通のメールに複数の面の写真があれば、ファイル名と本文で面ごとに組にします。組にできなければ review
4. 重複の確認 … 同じ面の同じ日の写真が2通で届いたら、後のものを使います

3番目が崩れやすいところです。 媒体社によっては、1通に30面の写真を番号順に添付し、本文に面の番号を並べてきます。ファイル名と本文の並びが合わないと、写真と面の組が全部ずれます。 組を作った後に、写真の枚数と本文の面の数が合うかを必ず確かめます。

AIに処理させる

させるのは2つの段階です。 写り具合と写真の種類の確認、原稿の文字と面の番号と掲出の不良の読み取りです。

1つ目の段階：写り具合と種類

2つ目の段階：読み取り

照らす文字の比べ方が、この構成でいちばん大事です。 写真の「4月1日〜4月30日」と照らす文字の「4月1日〜4月30日」が同じなら match、写真が「3月1日〜3月31日」とはっきり読めて違うなら mismatch、反射で読めなければ not_visible です。 not_visible は写真の不備、mismatch は掲出の誤りとして、別の扱いになります。

2行目がいちばん起きやすい失敗です。 「4月?日〜4月30日」と半分読めた文字を、照らす文字に合わせて「4月1日」と読むと、本当は「4月10日」だった旧版を見逃します。

指示内容を固定する

あなたは広告会社の営業部で、屋外広告・交通広告の掲出写真を確かめる立場です。
1枚目は入稿した原稿、2枚目は掲出の近景、3枚目は掲出の遠景です。
写真に写っているものだけを見て、次を返してください。推測で埋めないでください。

【照らす文字】
{check_texts}
（項目、照らす文字 の順に並んでいます）

【読み方】
- 照らす文字の各項目について、2枚目の写真の原稿の同じ項目の文字を、
  読めたまま observed に写してください。読めない文字は「?」にしてください。
- observed と照らす文字が同じなら match、はっきり読めて違うなら mismatch、
  読めない文字が含まれるなら not_visible にしてください。
  迷ったら not_visible です。照らす文字に合わせて読まないでください。
- 2枚目か3枚目に写る面の番号の表示（番号札、管理番号）を、
  読めたまま panel_label に写してください。写っていなければ空にしてください。
- はがれ、破れ、しわ、汚れ、上下の逆、照明の消灯など、見える掲出の不良を
  defects に書き、位置を box_2d に [ymin, xmin, ymax, xmax] で
  0〜1000 に正規化して入れてください。見えなければ空の配列にしてください。
- mismatch の項目にも、写真の中の位置を box_2d で入れてください。

【厳守事項】
- 原稿の見た目が似ているかで判断しないでください。文字だけで比べてください。
- 掲出の場所の良し悪し、広告の出来は書かないでください。
- 誤りの原因や責任は書かないでください。

「照らす文字に合わせて読まない」を明記しないと、match が増えます。 照らす文字を渡すと、AIは半分読めた文字をその方向に補います。読めた文字と読めない文字の区別を ? で残させ、比べるのは読めた文字だけにします。

1枚目に入稿した原稿を並べているのは、項目の位置を教えるためです。 原稿のどこに期間や価格があるかが分かると、写真の中の同じ場所を探せます。 ただし比べるのは、原稿の画像ではなく照らす文字です。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API の構造化出力では、response_format に mime_type: "application/json" と JSON Schema を渡し、status を enum で限ります。公式の案内では、出力がJSONとして正しくても、値はアプリケーションの側で必ず検証するようにとされています。

{
  "photo_quality": { "near": "good | retake | unknown", "far": "good | retake | unknown" },
  "text_checks": [
    { "item": "period", "expected": "", "observed": "",
      "status": "match | mismatch | not_visible", "box_2d": [0, 0, 0, 0] }
  ],
  "panel_label": "",
  "defects": [
    { "type": "peeling | tear | wrinkle | stain | upside_down | light_off | other",
      "evidence": "", "box_2d": [0, 0, 0, 0] }
  ]
}

1つ目の理由は、読み取りと判断を別の層に置けることです。 text_checks と defects はAIが埋め、verdict はスクリプトが規則で決めます。

2つ目は、旧版を名指しできることです。 mismatch の observed を、照らす文字の表の第1版の行と比べ、一致すれば「旧版（v1）が貼られている」と営業に示せます。 媒体社への連絡が「違います」から「v1が貼られています。v2に貼り替えてください」に変わります。

3つ目は、報告の表がそのまま作れることです。 pass の面を広告主ごとに並べ、媒体名、面の番号、掲出期間、撮影日、近景と遠景の写真へのリンクを1行ずつ書けば、報告書の写真の貼り付けと書き写しが要らなくなります。

システムへ連携する

媒体社への連絡も、広告主への報告も、自動では送りません。 撮り直しの依頼は下書きまで作り、営業が送ります。掲出の誤りの連絡は、媒体社との関係と補償の話に関わるからです。

呼び出しの回数は1日の上限の範囲です。 外部への呼び出しは Google Workspace のアカウントで1日100,000回までで、1面あたり2回の呼び出しなら、月600面は十分に収まります。

人が確認する

営業は、posting_issue を最初に開きます。 確認の一覧には、写真に枠を重ねた表示へのリンク、照らす文字と読めた文字、旧版との一致が並びます。

1. posting_issue を見る … 枠の位置で、版違い・面違い・不良が本当かを確かめ、その日のうちに媒体社に連絡します
2. review を見る … 面の番号が取れない、撮影日が期間の外のものを、媒体社に確かめます
3. photo_issue の下書きを送る … 撮り直しの依頼を確かめて送ります
4. 報告の表を確かめる … 面の数、期間、写真のリンクを確かめてから広告主に送ります
5. 判定を覆したら記録する … mismatch を match に直したら、その理由を短く残します

1番目で版違いが本当だったら、広告主への連絡も営業が決めます。 何日間、旧版が出ていたか、貼り替えはいつか。掲出の誤りを広告主に伝える順番は、営業の判断です。

pass の面も、週に1回は数面を抜き取って見ます。 AIが見逃した版違いは posting_issue の確認だけでは見つからないので、抜き取りが見逃しを知る唯一の手がかりです。

例外に対処する

上から2行目までが大半を占めます。 どちらもAIの問題ではなく、媒体社の撮り方の問題です。 撮影の手本と番号札を写す決まりを媒体社と共有すると、photo_issue が減ります。

記録を残す

• 掲出写真の元のファイルと、受け取ったメールの日時・送り主
• 指示の全文と、返ってきたJSONの全文
• 照らした原稿の版と照らす文字
• verdict と、営業が覆した項目とその理由
• 媒体社への貼り替え・撮り直しの依頼と、貼り替えの後の写真
• 広告主に送った報告の表と、送った日時

照らした版と文字を残すのは、版が後から改訂されるからです。 改訂の後に過去の報告を見直すと、どの版で照らしたかが分からなければ、その判定が正しかったかを判断できません。

貼り替えの後の写真も同じ面の行に残します。 版違いがいつ見つかり、いつ直ったかが1行で追えると、広告主から掲出の誤りの期間を聞かれたときに答えられます。