船会社が英文の燃料受領書（BDN）と燃料の分析報告書を読み取り、性状の値を燃料台帳に転記して、注文した規格との差と硫黄分の規制値の超過を拾う

処理の起点を決める

受付フォルダ（Amazon S3）に書類が保存されたことを起点にします。 分析報告書は届いた日に照合しないと、本船が燃料を使い始めてしまいます。ガイダンスも、可能であれば分析が終わるまで燃料を使わないことを勧めています。 定時の実行ではなく、届いたその場で動かします。

ファイルは担当者が <船名>_<補油日>_BDN.pdf、<船名>_<補油日>_LAB.pdf の形にして置きます。 末尾で書類の種類を分けます。分析報告書だけが先に届いても止めず、受領書が届いた時点で結び付けをやり直します。

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

入力データを集める

質を決めるのは、上限表と項目表です。 上限表が無ければ照らす基準がなく、項目表が無ければ「Sulfur」と「Sulphur」が別の項目になります。項目表は最初は空で始め、確認のたびに1行ずつ足していきます。

上限の近くを「要注意」とする幅を持つのは、試験には精度があるからです。 ガイダンスは、燃料の試験の結果が誤っている場合があり、ISO 4259 の精度の範囲内でも規格外と判定されることがあると注意しています。幅の値は技術部が決めます。

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

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

分析の結果は質問ではなく表で取ります。 項目が数十あり、1ページ30問という質問の上限に収まらないうえ、表なら列見出しで「結果」と「上限」の列を分けて取れるからです。 表の CELL には行と列の位置と列見出しの印が付くので、列見出しが「Result」の列を結果、「Limit」「Max」の列を報告書の上限として読みます。

質問は対象のページを指定しないと、既定で1ページ目にしか当たりません。 分析報告書の封印番号は1ページ目にあることが多いですが、**2ページ目の末尾に署名と封印番号を書く書式もあるため、Pages: ["*"] を付けます。**

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であること。XFA形式のPDFは扱えません
2. パスワードの確認 … PDFはパスワード保護不可です。分析機関のポータルから落とした報告書にパスワードが付いていれば、解除したものを取り直します
3. サイズと寸法の確認 … 非同期の処理で JPEG と PNG は10MB、PDF と TIFF は500MB・3,000ページまで、画像はどの辺も10,000ピクセル以下です。本船が撮った受領書の写真は縮小します
4. 文字の大きさの確認 … 文字の高さが15ピクセル（150 DPIで8ポイント相当）を下回ると検出されません。分析の表は小さな字なので、縮小しすぎません
5. 書類の種類の確認 … ファイル名の末尾と、全文の「Bunker Delivery Note」「Test Report」「Certificate of Analysis」などの語が合うかを見ます
6. 重複の確認 … 同じ封印番号の分析報告書が既にあれば止めます。再分析の報告書のこともあるので、差し替えか重複かを担当者に聞きます

AIに処理させる

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

封印番号を両方の書類から独立して読むのが、この表でいちばん大事なところです。 船名と補油日だけで結び付けると、同じ日に2種類の燃料を補油した場合や、再分析の報告書が届いた場合に、別の試料の結果を結び付けてしまいます。

指示内容を固定する

AWS Textract への指示は、英語の質問の一覧です。分析報告書には次の質問を当てます。

QueriesConfig:
  Queries:
    - Text: "What is the sample seal number?"
      Alias: SEAL_NO
      Pages: ["*"]
    - Text: "What is the name of the vessel?"
      Alias: VESSEL
      Pages: ["*"]
    - Text: "What is the date of sampling or bunkering?"
      Alias: SAMPLE_DATE
      Pages: ["*"]
    - Text: "What is the port of bunkering?"
      Alias: PORT
      Pages: ["*"]
    - Text: "What is the fuel grade?"
      Alias: GRADE
      Pages: ["*"]
    - Text: "Which specification and edition was used for evaluation?"
      Alias: SPEC_USED
      Pages: ["*"]
    - Text: "What is the name of the laboratory?"
      Alias: LAB
      Pages: ["*"]

受領書には、船名・港・日付・供給業者・油種・数量・密度・硫黄分・封印番号の9問を当てます。SPEC_USED は、分析機関がどの版で判定したかを知るための質問です。 注文の版と違えば、報告書の判定の欄が当てにならないことが分かります。

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

【答えと表の扱いの決まり】
1. 答えが空の項目は not_found とする。受領書や前回の値で埋めない。
2. 信頼度が決めた値を下回る項目は unreadable とし、値は参考として残す。
3. 封印番号は英数字と記号をそのまま比べる。1文字でも違えば結び付けず、
   船名と補油日が合っていても link_status を unmatched とする。
4. 表は列見出しで列を決める。「Result」を結果、「Limit」「Max」「Min」を
   報告書の上限・下限、「Unit」を単位とする。見出しが無い表は
   cannot_parse とし、列の位置で決めない。
5. 項目名は項目表で自社の項目にそろえる。表に無い名前は unmapped とし、
   似た名前に寄せない。
6. 結果に「<」「>」が付いた値（例：<0.10）は、記号と数値を分けて残す。
   記号を外して数値として比べない。
7. 単位を自社の単位にそろえる。密度は kg/m3、硫黄分は % m/m を基準とし、
   換算の決まりに無い単位は unit_unknown とする。
8. 上限との比較は自社の上限表の値で行う。報告書の上限の列は参考として並べ、
   比べる相手にしない。
9. 上限との差が「要注意」の幅の中なら near_limit とし、
   超えていれば over_limit とする。

3番目と8番目が、この構成の罠です。 封印番号が合わないのに船名と日付で結び付けると、別の試料の分析値で台帳が埋まります。 報告書の上限で比べると、注文と違う版で「適合」になります。

出力形式を固定する

結び付けと照合の結果を、補油1回ごとに次の形のJSONにまとめて台帳へ渡します。

{
  "bunkering_id": "VESSELB_2026-10-08",
  "order_ref": "BO-2026-1187",
  "link_status": "linked | waiting_lab | unmatched",
  "seal_no": { "bdn": "", "lab": "" },
  "spec": { "ordered": "ISO 8217:2017 RMG 380", "lab_used": "" },
  "results": [
    { "item": "sulphur", "lab_name": "Sulphur", "unit": "% m/m",
      "lab_value": 0.47, "qualifier": "", "bdn_value": 0.45,
      "limit_own": 0.50, "limit_lab": 0.50, "confidence": 0, "page": 1,
      "status": "within | near_limit | over_limit | unmapped | unreadable" }
  ],
  "declared_vs_lab": [
    { "item": "density_15c", "bdn": 0, "lab": 0, "diff": 0,
      "result": "within | over_tolerance | cannot_check" }
  ],
  "sulphur_check": { "basis": "global | eca | scrubber",
    "result": "within | over_limit | cannot_check" },
  "verdict": "confirm | review | urgent"
}

1つ目の理由は、results に自社の上限と報告書の上限を並べて持てることです。 2つがずれていれば、版の違いがその場で見えます。

2つ目は、link_status で結び付けの状態を独立して持てることです。 分析報告書がまだ届いていない補油は waiting_lab のまま台帳に置き、何日待っているかを数えられます。

urgent を分けるのは、本船が燃料を使い始めている可能性があるからです。

システムへ連携する

燃料台帳へ書くのは「確認待ち」の行まで、本船にも供給業者にも何も送りません。 本船に燃料の使用を控えるよう伝えるか、供給業者に申し立てるかは、技術部と運航管理が決めて人が連絡します。 読み違い1つで本船の運航が止まる経路を作らないためです。

人が確認する

人が開くのは review と urgent の行だけです。 全件を開く設計にすると、第10章の9.0時間には収まりません。

1. urgent を先に見る … 分析報告書の画像で、超えた項目の結果と単位を自分の目で読み直します。読み取りの誤りで urgent になっていないかを最初に確かめます
2. 版と等級を確かめる … 注文の版と分析機関の版が違えば、技術部に上限の読み方を確かめます
3. near_limit の扱いを決める … 試験の精度を踏まえ、再分析を頼むかを技術部と決めます
4. unmapped の項目名を項目表に足す … 同じ調べものを二度しないための作業です
5. 確定する … 読み取りの値と直した値の両方を残します

例外に対処する

記録を残す

• 受領書と分析報告書の元のファイル、AWS Textract の結果の全文（JSON）と JobId
• そろえた後の値とそろえ方の記録、照合の結果とそのときの上限表・項目表・航海計画の版
• 担当者が直した項目と直す前の値、urgent の扱いを決めた人と内容
• 供給業者ごと・項目ごとの near_limit と over_limit の件数

最後の行が、調達の見直しの材料になります。 ガイダンスも、燃料の試験のデータは硫黄分などの品質についての供給業者ごとの傾向を明らかにする上で有益としています。