輸出入のコンテナの封印と扉の写真からシール番号を読み取り、船荷証券・パッキングリストと照らして番号の食い違いと封印の異常を拾う

処理の起点を決める

Google Apps Script の時間主導型トリガーで、10分ごとに受け取り用フォルダを見ます。 写真が届いたらすぐ処理するのが理想ですが、業者は3枚を数分かけて1枚ずつ入れてきます。1枚目が届いた瞬間に動かすと、2枚目と3枚目がそろう前に判定してしまいます。

そこで、同じコンテナの写真が最後に届いてから10分たったものを「そろった」とみなします。 10分ごとに起動したとき、最後の写真の保存時刻から10分以上たっていれば処理し、たっていなければ次の起動に回します。

輸出では、もう1つのトリガーを足します。 船積みの指示の訂正の期限の前日の朝に、その期限を迎えるコンテナで写真がまだ届いていないものを一覧にして担当者に知らせます。写真が届かないこと自体を拾わないと、点検は「届いたものだけ」になります。

処理が終わった写真は、処理済みのフォルダに移します。移すのは判定まで終わったときだけにします。 受け取り用フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

AIに渡すのは、上の3行の写真だけです。 台帳の行と異常の基準は、Apps Script の側で照合と判定に使います。台帳の番号をAIに見せないことが、入力の設計でいちばん大事な点です（第5章の4番目）。

台帳にB/LとP/Lのシール番号を別の列で持たせるのは、両者が食い違うことがあるからです。 1つの列にまとめると、どちらの書類が間違っているのかが分からなくなります。写真の番号が片方とだけ一致したら、もう片方の書類が誤りの候補です。

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

ファイル名の付け方を、業者と最初に取り決めます。 「ブッキング番号_写真の種類_連番.jpg」のように、台帳の行を引ける番号を先頭に置いてもらいます。 写真の種類は seal、door、cntr の3つにします。業者ごとにフォルダを分けておけば、業者名はフォルダから分かります。

ファイル名で引けなかった写真は、AIが読んだコンテナ番号で引き直します。 ここだけは読み取りの結果を使って行を探しますが、行が見つかったあとの照合は、改めて1文字ずつ行います。 引けた行が複数あれば、自動では決めずに担当者に回します。

メールで届いた写真は、担当者が受け取り用フォルダに移すところだけ手で行います。 業者にフォルダへの置き方を案内し、メールで届く割合を減らしていきます。

AIへ渡す前に整形する

1. 形式の確認 … PNG、JPEG、WEBP、HEIC、HEIF のいずれかであることを確かめます。それ以外は JPEG に変換します
2. 向きの補正 … スマートフォンの写真は向きの情報だけを持っていることがあるので、回転してから渡します。横倒しの番号は読み違いのもとです
3. 大きさの調整 … 封印の拡大写真は細部を残し、扉の全体の写真は長い辺を縮めます。リクエスト全体で20MBを超えないようにします
4. そろっているかの確認 … seal、door、cntr の3枚がそろっているかを見ます。seal が無ければAIに渡さず、撮り直しの依頼に回します
5. 重複の検知 … 同じコンテナで同じ日に二度届いたものは、新しいほうだけを使い、古いほうに印を付けます
6. 輸出か輸入かの確認 … 台帳の行から、点検の向きを決めます。輸入は封印を切る前の写真であることが前提なので、撮影日時がデバンニングの開始より後なら印を付けます

4番目で封印の拡大写真が無いものを止めるのは、扉の全体の写真から番号を読ませないためです。 遠くから写った札の番号は、ほぼ読めないか、読めたように見えて違います。読めないと分かっている写真を読ませる必要はありません。

AIに処理させる

させるのは、写真に写っている番号を1文字ずつ読み、封印と扉の状態を決まった区分で答えることだけです。

右端の列で ? を使わせるのが、この表の要です。 確かでない文字を「たぶんこれ」で埋めると、照合で一致してしまうことがあります。? が1つでもあれば、照合の結果は unreadable になり、撮り直しに回ります。

1行目がいちばん大事です。 書類の番号を一緒に渡して「一致しているか」を聞くと、AIはほぼ必ず「一致」と答えます。一致を確かめる仕事を、一致を前提にした読み取りにすり替えてしまいます。

指示内容を固定する

あなたは物流部門で、海上コンテナの封印の写真を点検する立場です。
渡された写真に写っているものだけを答えてください。推測で埋めないでください。

【写真】
1枚目：封印の拡大（seal）
2枚目：扉の全体（door）
3枚目：コンテナ番号の表示（cntr）
写真がそろっていない場合は、ある写真だけで答えてください。

【答えること】
1. シール番号：札に刻まれた英字と数字を、写っているとおりに書く
2. シールの数：写っている封印の数
3. コンテナ番号：英字4文字と数字7桁
4. 封印の状態：intact／cut／bent／tampered_suspected／not_visible
5. 扉の状態：取っ手とロックの棒が閉じた位置にあるか。目立つ傷や隙間があるか
6. 写真の質：blur／glare／dark／too_far のうち当てはまるもの

【厳守事項】
- 確かでない文字は「?」にしてください。似た文字に寄せないでください。
  特に 0 と O、1 と I、8 と B、5 と S、2 と Z は、形がはっきりしない限り「?」です。
- 番号の桁を補ったり、数え直して桁数を合わせたりしないでください。
- 封印が写っていない場合は、扉の全体の写真から番号を読もうとしないでください。
  seal_number は空にし、seal_state を not_visible にしてください。
- 封印の状態は、見えたものだけで区分を選んでください。
  迷ったときに intact を選ばないでください。
- 異常かどうか、荷を開けるべきかは書かないでください。
- evidence には、その区分を選んだ理由を、写真の中のどこに何が見えるかで書いてください。
- 写真がコンテナの封印や扉でないと判断した場合は、photo_type に種類を書き、
  他の項目を空にしてください。

書類の番号を指示の中に1つも書いていないことが、この例の要点です。 指示の文面を後から直す人が「参考に台帳の番号も渡そう」と足しがちなので、指示の冒頭のコメントにも、渡さない理由を残しておきます。

「迷ったときに intact を選ばない」を明記しないと、ほとんどが intact になります。 写真の多くは異常が無いので、迷ったときに多いほうを選ぶのが自然な振る舞いです。禁じるのは、迷いを正常の側に倒すことです。

出力形式を固定する

Gemini API の構造化出力で、次の形のJSONを受け取ります。 response_format に mime_type: "application/json" とスキーマを入れて指定し、区分は enum で決めておきます。

{
  "photo_type": "container_seal",
  "seals": [
    { "seal_number": "", "char_uncertain": [0],
      "seal_state": "intact | cut | bent | tampered_suspected | not_visible",
      "evidence": "" }
  ],
  "seal_count": 1,
  "container_number": "",
  "door_state": { "handles_closed": "yes | no | not_visible",
                  "visible_damage": "yes | no | not_visible", "evidence": "" },
  "photo_quality": ["blur", "glare"]
}

char_uncertain には、? にした文字の位置を0から数えて入れます。どの文字が読めなかったかが分かれば、撮り直しの依頼に「左から3文字目が反射で読めない」と書けます。

1つ目の理由は、読み取りと照合を別の層に置けることです。 このJSONにはAIが埋めた読み取りだけが入り、照合の結果は Apps Script が別に持ちます。

照合の前に、番号を正規化します。 空白、ハイフン、全角の英数字をそろえ、英字は大文字にします。 正規化で 0 と O を同じものとみなすことはしません。それをすると、1文字違いを見落とした目視と同じことになります。

2つ目の理由は、構造化出力でも値の正しさは保証されないことです。 公式のページでも、JSONとして正しくても値はアプリケーションの側で検証するよう案内されています。コンテナ番号が英字4文字と数字7桁の形になっているかは、Apps Script の側でも確かめます。

システムへ連携する

台帳に書き込むのは、点検結果の列だけです。 シール番号の列は書き換えません。AIの読み取りで台帳の番号を上書きすると、書類の誤りを写真の読み違いで「直して」しまうことがあります。 台帳の番号を直すのは、書類を確かめた担当者です。

撮り直しの依頼も、送るのは人です。 下書きには業者名、コンテナ番号、どの写真のどの部分が読めないかを入れます。同じ業者から同じ日に何件も出ていれば、1通にまとめます。

人が確認する

人が開くのは mismatch と anomaly のものだけです。 ok は台帳の点検結果の列で件数を見て終わりにし、unreadable は下書きを確かめて業者に送ります。

1. anomaly を先に見る … 輸入では封印を切る前に止められるかどうかが時間で決まります。倉庫に連絡し、封印を切らずに待ってもらうかを決めます
2. mismatch の写真を自分で読む … AIの読み取りが正しいかを、拡大写真で1文字ずつ確かめます
3. どの書類が違うかを見る … 写真の番号がB/Lとだけ一致すればP/Lの誤り、P/Lとだけ一致すればB/Lの誤りの候補です。どちらとも違えば、現物の確認が要ります
4. 対応を決めて記録する … 書類の訂正、荷主への連絡、撮り直し。AIの読み取りが誤っていた場合は、どの文字をどう読み違えたかを残します

2番目を省かないでください。 mismatch の原因が、書類の誤りではなくAIの読み違いであることは珍しくありません。船会社に訂正を頼んでから読み違いだと分かると、訂正の訂正が要ります。

目標は、600本をならして1本2分です。 担当者が詳しく見るのは mismatch と anomaly と unreadable の合計で全体の2割前後という想定で、それより多い月は、写真の撮り方か、台帳の番号の入れ方に原因があります。

例外に対処する

上から3行目は、輸入でよく起きます。 写真がB/Lより先に届くことがあるからです。照合を保留したものを毎朝一覧にし、番号が入ったものから照合し直します。 保留のまま忘れられると、点検が届いていないのと同じになります。

記録を残す

• 元の写真と、撮影日時・業者名・届いた経路
• AIに渡した指示の版と、返ってきたJSONの全文
• 照合に使った台帳の行の内容（そのときのB/LとP/Lのシール番号）
• 判定（ok ／ mismatch ／ unreadable ／ anomaly）と、その規則の版
• 人が判定を覆した記録 … どの文字を、どう読み違えていたか
• 撮り直しの依頼と、撮り直された写真の対応
• 業者ごとの unreadable の発生率

写真はコンテナ番号の名前で保管し、少なくとも荷の引き渡しが終わるまで消しません。 輸入で封印の異常があった場合、切る前の状態を示すのはこの写真だけになることがあります。保険の請求や荷主との話し合いで出すことを考えて、元の写真を加工しないまま残します。

3つ目で台帳の内容を残すのは、番号が後から直されるためです。 書類の訂正が入ると台帳の番号が変わり、当時なぜ mismatch になったのかが分からなくなります。

最後の行は、業者との話し合いの材料になります。 特定の業者だけ unreadable が多いなら、撮る位置や光の当て方を一緒に決め直します。