外航船の補油で届く英文の燃料受領書（BDN）を読み取り、発注と本船の計測に照らして、数量の差と硫黄分の超過を拾う

処理の起点を決める

受付フォルダ（Amazon S3）に受領書のファイルが保存されたことを起点にします。 補油は昼夜を問わず世界のどこかで終わるので、1日1回の定時実行にはしません。 数量の差の申し立ては早いほど通りやすく、届いたその日に差が分かる形にしておく必要があるからです。

ファイルは担当者が <船名>_<補油日>_BDN.pdf のような名前にして置きます。 船名と補油日が発注の記録を引く鍵になるため、名前の形が合わないものは処理を始める前に止めます。

S3 への保存を AWS Lambda が受け、StartDocumentAnalysis を呼びます。同期の処理では PDF は1ページまでなので、複数ページの受領書に備えて非同期にそろえます。 ClientRequestToken にファイルから作った値を入れると、二度置いても同じ JobId が返り、二重に読みません。 完了は Amazon SNS に届き、SUCCEEDED を確かめて GetDocumentAnalysis で結果を取ります。結果は既定で7日間しか取れないため、すぐ S3 に保存します。

入力データを集める

質を決めるのは、下の4つです。 発注の行が無ければ照らす相手がなく、本船の計測値が無ければ数量の差が出せません。船の情報が古いと、硫黄分の判定が間違った海域で行われます。 判定の決まりは、担当者の頭の中にあるものを表に書き出すところから始めます。

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

読み取りは StartDocumentAnalysis に FeatureTypes として QUERIES、TABLES、FORMS を指定して行います。全文の行と単語は、指定した機能にかかわらず返ります。

質問は QueriesConfig に並べ、それぞれに別名（Alias）を付けます。答えは QUERY_RESULT という種類のブロックで、信頼度と、ページ上の位置と、答えの文字列が返ります。答えが見つからないときは空になります。

質問の数には上限があります。 公式の上限の一覧では、1ページあたり同期の処理で15問まで、非同期の処理で30問までです。本記事は非同期にそろえるので30問まで使えますが、欲張らずに照合に要る項目に絞ります。

燃料台帳・発注の記録・船の情報は、Lambda から読むだけで取ります。照合は船名と補油日で発注の行を引くのが先で、書き方が受領書ごとに違う供給業者の名前は後にします。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であること。XFA形式のPDFは扱えないため、印刷し直してPDFにします
2. パスワードの確認 … PDFはパスワード保護不可。解除したものを頼みます
3. サイズとページ数の確認 … 非同期の処理で JPEG と PNG は10MB、PDF と TIFF は500MB・3,000ページが上限です。写真は10MBを超えることがあるので、縮小してから入れます
4. 画像の寸法の確認 … どの辺も10,000ピクセル以下である必要があります。高解像度の写真は縮小します
5. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。150 DPIで8ポイント相当です。受領書の数量や硫黄分は小さな字の表に書かれていることが多いので、縮小しすぎないようにします
6. 写り込みの確認 … 平面内の回転は扱えますが、斜めの写真や影のかかった数字は読み取りを落とします
7. 重複の確認 … 同じ船・同じ補油日の受領書が既にあれば止め、差し替えか重複かを担当者に聞きます

AIに処理させる

させるのは、受領書から決まった項目の値を読み取り、根拠の位置と信頼度を添えることだけです。 判定は、読み取りの後にプログラムの規則が行います。

数量の単位を独立して読むのが、この表でいちばん大事なところです。 受領書にはトンで書くもの、体積で書くもの、両方を書くものがあり、単位を確かめずに写すと体積の数字がトンの列に入ります。

指示内容を固定する

AWS Textract への指示は、英語の質問の一覧です。別名を付けて、受け取る側のプログラムが項目を取り違えないようにします。

QueriesConfig:
  Queries:
    - Text: "What is the name of the receiving vessel?"
      Alias: VESSEL_NAME
    - Text: "What is the IMO number of the vessel?"
      Alias: IMO_NUMBER
    - Text: "What is the port of delivery?"
      Alias: PORT
    - Text: "What is the date of commencement of bunkering?"
      Alias: DELIVERY_DATE
    - Text: "What is the name of the supplier?"
      Alias: SUPPLIER
    - Text: "What is the product name or fuel grade?"
      Alias: PRODUCT
    - Text: "What is the quantity delivered in metric tons?"
      Alias: QTY_MT
    - Text: "What is the quantity delivered in cubic meters?"
      Alias: QTY_M3
    - Text: "What is the density at 15 degrees C?"
      Alias: DENSITY_15C
    - Text: "What is the sulphur content?"
      Alias: SULPHUR
    - Text: "What is the viscosity?"
      Alias: VISCOSITY
    - Text: "What is the flash point?"
      Alias: FLASH_POINT
    - Text: "What is the MARPOL sample seal number?"
      Alias: SAMPLE_SEAL
    - Text: "Is there a supplier declaration of compliance with MARPOL Annex VI?"
      Alias: DECLARATION
    - Text: "Who signed for the receiving vessel?"
      Alias: SHIP_SIGNATORY

数量を2つの質問に分けているのが工夫です。 1問で聞くとトンと体積のどちらを答えるかが受領書ごとに変わるため、どちらが取れたかで単位を決めます。

受け取った答えに対して、プログラムの側で次の決まりを当てます。これが実質的な「指示」です。

【答えの扱いの決まり】
1. 答えが空の項目は not_found とする。発注の値で埋めない。
2. 信頼度が決めた値を下回る項目は unreadable とし、値は参考として残す。
3. 答えの文字列が全文の行のどこにあるかを探し、見つからなければ ambiguous とする。
4. SULPHUR は「%」「% m/m」などの記号を外して数値にする。
   数値にできなければ unreadable とする。0.5 と 0.50 は同じ値として扱う。
5. DENSITY_15C は kg/m3 を基準にそろえる。
   値が 1 前後なら g/ml、900〜1,010 前後なら kg/m3 とみなし、
   どちらにも当たらなければ unit_unknown とする。
6. QTY_MT と QTY_M3 がどちらも空なら、TABLES の表から数量の列を探す。
   それでも見つからなければ not_found とする。
7. VESSEL_NAME と IMO_NUMBER は発注の行と照らし、合わなければ mismatch とする。
   船名の表記ゆれ（前置きの「M/V」「MV」の有無）は外してから比べる。
8. 日付は日・月の順の書き方と月・日の順の書き方の両方がありうる。
   日が12以下で両方に読めるときは ambiguous とし、発注の予定日で決めない。

8番目は解釈の罠です。 「03/04」は3月4日とも4月3日とも読め、発注の予定日に近いほうを選ぶと、外れたときに誰も気づきません。

出力形式を固定する

読み取りと判定の結果を、次の形のJSONにまとめて台帳へ渡します。

{
  "bdn_id": "VESSELA_2026-10-12_BDN",
  "order_ref": "BO-2026-1041",
  "fields": [
    { "item": "SULPHUR", "status": "ok | not_found | unreadable | ambiguous | unit_unknown | mismatch",
      "value": "0.47", "unit": "% m/m", "confidence": 0, "page": 1 }
  ],
  "quantity_check": {
    "ordered_mt": 0, "bdn_mt": 0, "ship_measured_mt": 0,
    "diff_bdn_vs_ship_mt": 0, "diff_rate": 0,
    "result": "within | over_tolerance | waiting_ship_figure | cannot_check"
  },
  "sulphur_check": {
    "bdn_value": 0, "applicable_limit": 0, "basis": "global | eca | scrubber",
    "result": "within | over_limit | cannot_check"
  },
  "spec_check": { "product_match": "match | mismatch | cannot_check" },
  "verdict": "confirm | review | urgent"
}

fields には第7章「プロンプトまたは指示内容の例」の別名ごとに1要素を並べます。fields は読み取りの層、quantity_check と sulphur_check は判定の層で、別々に持ちます。

分けておけば、判定の幅や航海計画が変わっても、読み取りをやり直さずに判定だけを引き直せます。 verdict は3段階です。

urgent を分けるのは、数量の差と硫黄分の超過には申し立てと燃料の使い方の判断に期限があるからです。

システムへ連携する

燃料台帳へ書くのは「確認待ち」の行まで、供給業者へは何も送りません。 確定と申し立ては担当者が行います。読み違いが自動で精算や申し立てまで流れる経路を作らないためです。

人が確認する

人が開くのは review と urgent の行だけです。 confirm の行は、一覧で船名・数量・硫黄分を流し見て確定します。全件を開く設計にすると、第10章の9.0時間には収まりません。

1. urgent を先に見る … 受領書の画像で、数量と硫黄分の数字を自分の目で読み直します。読み取りの誤りで urgent になっていないかを最初に確かめます
2. 数量の差の中身を確かめる … 本船の計測の時刻と温度、計算に使った密度を見ます。計測の条件が違うだけの差を、供給業者への申し立てにしないためです
3. 硫黄分の基準を確かめる … basis が正しいか、航海計画が最新かを見ます
4. review の項目を直して確定する … 読み取りの値と直した値の両方を残します

例外に対処する

上の3行が大半で、どれも本船での写し方の問題です。

記録を残す

• 受領書の元のファイルと、本船から届いた日時
• AWS Textract が返した結果の全文（JSON）と JobId
• そろえた後の値とそろえ方の記録、判定の結果とそのときの決まり・航海計画の版
• 担当者が直した項目と、直す前の値
• 供給業者ごとの review の発生率と、数量の差の傾向

陸上に保存するのは写しです。 国土交通省の案内では、国際航海に従事する総トン数400トン以上の船舶は燃料油供給証明書を3年間、試料を燃料が消費されるまで（最低1年間）船舶内に備え置くとされています。