海上コンテナの搬出入でターミナルが発行する機器受渡証（EIR）の損傷記録を読み取って台帳にそろえ、返却時に増えた損傷を拾って修理費の請求に備える

処理の起点を決める

保管場所にEIRの画像が置かれたことを起点にします。 運転手はゲートを出たところで、業務用のスマートフォンから撮影して送ります。送り先は運転手ごとのフォルダではなく1つの受信用の場所にし、ファイル名に運転手のコードと撮影の日時を入れます。

1日の終わりのまとめ処理にはしません。 返却時に損傷が増えていたとき、その日のうちに運転手に聞けるかどうかで、残る記録の質が変わります。 届くたびに1枚ずつ処理し、処理が終わった画像は処理済みの場所へ移します。移すのは成功したときだけにし、受信用の場所に残っている数を、そのまま未処理の数として扱います。

入力データを集める

質を決めるのは、下の2つです。 損傷の記号はゲートや船会社によって書き方が違うことがあり、凡例が無ければ、生成AIは記号を「それらしい意味」に読み替えます。 凡例はゲートごとに分けて持ち、読み取り結果と一緒に、そのゲートの凡例だけを渡します。

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

読み取りは、レイアウトモデル（prebuilt-layout）を呼ぶだけです。出力の形式は Markdown を指定し（outputContentFormat=markdown）、図の切り出しも指定します（output=figures）。v4.0 では表が HTML のテーブルとして出力され、結合されたセルや複数行の見出しも表現できます。 EIRの損傷の欄は「面」「位置」「記号」が横に並ぶ表になっていることが多く、この形のほうが生成AIに渡したときに列を取り違えにくくなります。

記号の信頼度は、セルではなく単語で見ます。 表のセルの文字列は返りますが、信頼度は単語ごとに返ります。セルの範囲に入る単語の信頼度のうち、いちばん低いものをそのセルの信頼度として扱います。

手書きかどうかの判定が、空欄の見分けに効きます。 様式に「損傷記録」「DAMAGE」と印刷された欄があり、その下に何も書かれていなければ、手書きの行は見つかりません。印刷された文字だけがある欄は、書き込みが無い欄として扱います。

AIへ渡す前に整形する

1. 大きさの確認 … 画像の大きさは50×50ピクセルから10,000×10,000ピクセルの間である必要があります。スマートフォンの写真はこの範囲に収まりますが、縮小して送る設定になっていないかを確かめます
2. 文字の大きさの確認 … 抽出するテキストの最小の高さは、1024×768ピクセルの画像で12ピクセルとされ、150dpiで約8ポイントの文字に当たります。EIRの記号は小さく書かれることが多く、遠くから撮るとこの下限を割ります
3. 1枚に1枚の確認 … 2枚のEIRを並べて1枚の写真に撮ったものは、ページが分かれず読み取り結果が混ざります。表が2つ以上あり、コンテナ番号が2つ読めたものは、撮り直しを頼みます
4. 運転手と日時の特定 … ファイル名から運転手のコードと撮影日時を取ります。撮影日時は、EIRの日付を確かめる手がかりにします
5. 配車の候補の絞り込み … その運転手の、撮影日の前後1日の案件だけを候補にします。全部を渡すと、番号の似た別のコンテナに紐づけます
6. 重複の検知 … 同じ運転手から、同じコンテナ番号・同じ日付のEIRが2回届いたら、撮り直しとして新しいほうを使います

2番目を軽く見ないでください。 ぶれた写真や影のかかった写真で記号が読めないものは、「損傷なし」と区別がつきません。

AIに処理させる

させるのは、ゲートごとにばらばらな様式の読み取り結果を、台帳の決まった項目と損傷の記録にそろえることだけです。

1行目がいちばん起きやすい失敗です。 何も書かれていない欄を渡すと、生成AIは「損傷は記録されていない」と読み、stated_none にします。その瞬間、記入が省かれたEIRと、損傷なしを確かめたEIRの区別が消えます。

指示内容を固定する

あなたは海上コンテナの陸送会社の業務課で、ゲートで受け取った
機器受渡証（EIR）を台帳の項目にそろえる担当です。
OCRの読み取り結果だけを見て作業してください。推測で埋めないでください。

【やること】
1. 基本項目（コンテナ番号、サイズとタイプ、受け渡しの日時、ゲートの名称、
   搬出か搬入か、実入りか空か、シール番号、車両番号）を対応づける
2. 損傷の欄の状態を、次の4つから1つ選ぶ
   - recorded ..... 損傷の記号が1つ以上書かれている
   - stated_none .. 「損傷なし」「異常なし」「NIL」「NO DAMAGE」などと
                    書かれている、または「なし」に印が付いている
   - blank ........ 手書きの書き込みが何も無い
   - unreadable ... 書き込みはあるが、文字として確定できない
3. recorded のとき、記号が書かれた行ごとに、面・位置・記号・寸法を写す
4. 【凡例】にある記号には意味を付ける。凡例に無い記号は meaning を空にする
5. 但し書き・備考は、そのまま写す

【厳守事項】
- 何も書かれていない損傷の欄を stated_none にしないでください。
  「損傷なし」と書かれていない限り、blank です。
- 様式に印刷された欄の名前（例：「損傷記録」「DAMAGE」「凡例」）は
  書き込みではありません。印刷された文字だけを根拠に recorded や
  stated_none にしないでください。
- 凡例に印刷された記号の一覧を、損傷の記録として写さないでください。
- コンテナ番号は読み取った文字列をそのまま写してください。
  桁を補う、似た文字（0とO、1とI、8とB）を入れ替えることをしないでください。
- 凡例に無い記号の意味を推測しないでください。
- 展開図の印の位置を文字に直さないでください。図があることだけを
  has_diagram に書いてください。
- 損傷の原因、責任の所在、修理の要否は書かないでください。
- EIRでない書類（送り状、搬入票、伝票）と判断したときは、
  document_type に種類を書き、項目を作らないでください。

【ゲートの名称と様式】{gate_profile}
【凡例】{damage_legend}
【配車の候補】{candidate_jobs}
【読み取り結果（Markdown）】{ocr_markdown}

「印刷された欄の名前は書き込みではない」を明記しないと、blank が拾えません。 読み取り結果には「損傷記録」という文字が確かにあるので、何も言わなければ欄が埋まっているものとして扱います。styles の手書きの判定と組み合わせ、書き込まれた文字があるかで見ます。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力で、response_format に json_schema を strict: true で渡し、形を固定します。すべての項目を必須にし、additionalProperties を false にする必要があるので、値が無い項目も空文字で返させます。

{
  "document_type": "eir",
  "container_no": "ABCU1234560",
  "size_type": "40HC",
  "direction": "gate_out",
  "load_status": "full",
  "gate_name": "○○コンテナターミナル",
  "datetime": "2026-10-08 09:42",
  "seal_no": "SL0458812",
  "chassis_no": "",
  "damage_field_status": "recorded",
  "damages": [
    { "face": "左側面", "position": "後ろ寄り下段", "code": "D",
      "meaning": "凹み", "size": "20cm", "evidence": "左側 D 20cm" },
    { "face": "扉", "position": "右扉", "code": "SC",
      "meaning": "", "size": "", "evidence": "R/DOOR SC" }
  ],
  "remarks": ["既存"],
  "has_diagram": true,
  "job_id": "J-2610-0318",
  "job_match_reason": "コンテナ番号と日付が配車の記録と一致"
}

検算と突き合わせの結果は、プログラムが次の形で足します。

not_comparable の決め方が、この構成でいちばん大事な規則です。

blank の側を「損傷なし」として比べると、返却時に書かれた損傷が全部 new_at_return になります。 実際には搬出時に記入が省かれただけのことが多く、それを自社の責任として受け入れる材料を、自分で作ることになります。

コンテナ番号のチェックデジットは、プログラムで計算します。 コンテナ番号は、所有者を示す英字3文字、機器の区分を示す英字1文字、6桁の数字と、記録と伝送の正確さを確かめるための1桁の数字でできています。最後の1桁が計算と合わなければ、どこかの文字を読み違えています。 invalid のものは台帳に載せる前に人に回します。

システムへ連携する

台帳へは「行の追加」だけにします。 撮り直しのEIRが届いたら新しい行として足し、古い行に「撮り直しあり」の印を付けます。 配車システムには書き込みません。

台帳は、コンテナ番号で引けば搬出時と返却時の2行が並ぶ形にします。 請求が届いたら、番号で引くだけで2枚の記録と展開図が出てきます。

人が確認する

人が見るのは、印の付いたものだけです。 一覧には、搬出時と返却時の損傷の記録と、2枚の展開図の画像を並べて出します。

1. invalid を先に直す … コンテナ番号の読み違いです。画像と見比べて直すと、配車の記録との照合と突き合わせをやり直します
2. new_at_return を確かめる … 2枚の展開図を見比べ、本当に搬出時には無かった損傷かを目で確かめます
3. 運転手に聞く … 増えた損傷が確かなら、当日のうちに事情を聞き、台帳の備考に残します
4. not_comparable の扱いを決める … 搬出時が blank なら、そのゲートでの受け取り方を見直す材料にします
5. 直した記録を残す … どの項目を何から何に直したかが自動で記録されます

2番目を省かないでください。 new_at_return は、記号の書き方の違いでも出ます。搬出時に「D」、返却時に「DT」と書かれた同じ凹みは、プログラムには別の記号に見えます。展開図の印の位置を見れば、同じ損傷かどうかが分かります。

目標は、1,200枚をならして1枚1分です。 印の付くものが2割を超える月は、撮り方か、凡例の整備に理由があります。

例外に対処する

記録を残す

• EIRの画像と、運転手のコード・撮影日時
• Document Intelligence が返したJSONの全文と、展開図の切り出し画像
• 生成AIに渡した指示と凡例、返ってきたJSON
• チェックデジットの結果と、突き合わせの結果（diff）
• 人が直した記録（直す前の値、直した後の値、その項目の信頼度、直した人）
• 運転手への聞き取りの内容と日時
• ゲートごとの blank と unreadable の件数

3つ目で「そのときの凡例」を残すのは、凡例が後から変わるためです。 ゲートが様式を改めると記号の意味が変わり、当時の凡例が残っていないと、過去の記録の読み方が決まりません。