酒類の輸入商社が英国の樽の保管業者から毎月届く英文の樽の在庫・保管料の明細を読み取り、樽ごとの台帳と保管料の請求との照合表を作る

処理の起点を決める

受付フォルダ（Amazon S3 のバケット）に明細か請求書のPDFが保存されたことを起点にします。 明細と請求書は月初に口座ごとに届きます。支払の期日の前に照合表を出せば、食い違いを問い合わせてから支払えます。

ファイル名の先頭に、保管業者の略号と口座番号と書類の種類（明細か請求書か）を付けます。 保管業者が分かれば、列の対応表と料金表を最初から正しく選べます。明細と請求書は口座と月で組にし、 両方がそろってから照合を始めます。片方だけのときは、そろうまで待ちます。

終わったファイルは処理済みの場所へ移します。 移すのは成功したときだけで、受付フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、列の対応表の「量の列の種類」です。 見出しが「Bulk Litres」「LPA」のように書かれていればそれに従い、略号だけなら対応表に従い、どちらでも決まらなければ決めません。

樽番号の書き方も、対応表に1列持たせます。 蒸留所の番号に年を付けるもの、保管業者の通し番号を付けるもの、両方を書くものがあります。台帳の樽番号に、保管業者ごとの書き方を並べておけば、同じ樽を2つの番号で数えずに済みます。

作業の依頼の記録は、メールから一覧に移しておきます。 依頼の日と樽番号と作業の種類だけの一覧で足ります。一覧に無い作業料が請求されたら、それが問い合わせの候補です。

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

明細と請求書は、非同期の StartDocumentAnalysis に S3 の場所を渡し、FeatureTypes に TABLES・FORMS・QUERIES を指定して読みます。 返った JobId を控え、完了の知らせが Amazon SNS に届き、状態が SUCCEEDED であることを確かめてから GetDocumentAnalysis で結果を取ります。

問い（Queries）は英語の文書でだけ使えます。 英国の明細は英語なので使えます。問いは対象のページを指定しないと1ページ目にしか当たりませんが、口座番号と明細の期間は1ページ目の上に書かれるので、あえて1ページ目だけに当てます。 すべてのページに当てると、ページごとに同じ答えが返り、照らす手間が増えます。

同じ ClientRequestToken で読み取りを始めれば、同じ JobId が返ります。 ファイル名から作った値を渡しておけば、Lambda が再試行しても同じファイルを二度読まずに済みます。JobId は7日間だけ有効なので、 結果は取った時点で S3 に残します。

AIへ渡す前に整形する

1. 形式の確認 … JPEG・PNG・PDF・TIFF のいずれかであることを確かめます。XFA 形式の PDF は読めないので、印刷し直した PDF を頼みます
2. パスワードの確認 … パスワードで保護された PDF は読めません。解除した版を保管業者に頼みます
3. ページの大きさ … PDF の縦横は40インチ・9,000ポイントまでです。表計算のソフトから横長に書き出した明細は、この範囲に収まるかを見ます
4. 文字の大きさ … 文字の高さは15ピクセル（150 DPI で8ポイント相当）が下限です。1ページに多くの行を詰めた明細は、文字が小さくなりがちです
5. 組の確認 … 同じ口座・同じ月の明細と請求書がそろっているかを見ます。片方だけなら照合を待ちます
6. 重複の確認 … 口座と明細の期間が同じものは重複として外します。差し替えの版が届いたときは、両方を残して人が選びます

4番目を省かないでください。 小さな文字の「3」と「8」の読み違いは、樽番号なら台帳に無い樽として、量なら大きな減りとして出ます。 どちらも検算で拾える仕組みを後段に置いていますが、元の画像の質がいちばん効きます。

AIに処理させる

させるのは、明細と請求書から決まった項目の値を取り出し、列の見出し・信頼度・ページの位置を添えることだけです。 列の対応、検算、台帳との突き合わせ、量の減り方、料金の照合は、取り出した後に Python の規則が行います。

1行目がいちばん起きやすい失敗です。 「Litres」とだけ書かれた列を、隣の列と同じ種類だと決めつけると、検算が合わないまま台帳の値が書き換わり、量が急に減った樽が並びます。

指示内容を固定する

文書の解析そのものには指示を書く場所がありません。AWS Textract に渡すのは文書と問い（Queries）で、判定の指示にあたるものは読み取った後の規則として持ちます。 問いは明細の1ページ目に当てる次の4つです。

【問い（Queries。明細の1ページ目）】
1. Alias: ACCOUNT_NO    Text: What is the account number?
2. Alias: PERIOD_FROM   Text: What is the statement start date?
3. Alias: PERIOD_TO     Text: What is the statement end date?
4. Alias: CUSTOMER      Text: What is the customer name?

【読み取った値の扱いの決まり】
1. 値が空の項目は missing とする。0 や前の行の値で埋めない。
2. 信頼度が決めた値を下回る値は unreadable とし、値は参考として残す。
3. 列の見出しは、その保管業者の列の対応表だけで共通の項目
   （cask_no, distillery, cask_type, fill_date, bulk_litres, abv,
     litres_alcohol, regauge_date, location）に直す。
   表に無い見出しは unknown_column とする。
4. 量の列の種類は、見出しの語、無ければ対応表で決める。
   どちらでも決まらなければ照らさず needs_review とする。
5. ページごとに繰り返される列の見出しの行は、樽の行として数えない。
6. bulk_litres × abv ÷ 100 と litres_alcohol の差が決めた幅を超えたら
   calc_mismatch とする。どちらの値も直さない。
7. 樽の行の litres_alcohol の合計と、合計の行の値が合わなければ
   total_mismatch とする。
8. 樽番号は、対応表の書き方で台帳の番号に直してから照らす。
   直せない番号は unknown_cask とし、似た番号に寄せない。
9. 請求の行は、料金表の樽の種類・数え方・単価で金額を計算し直し、
   差が決めた幅を超えたら rate_diff とする。
10. 作業料の行は、作業の依頼の記録の樽番号と作業の種類で照らし、
    記録に無ければ not_ordered とする。

4番目と8番目が、この構成の罠です。 どちらも「たぶんこれだろう」で埋めたくなる箇所で、埋めた瞬間に、誤った値が台帳まで通ります。 決まらない明細は、保管業者ごとの対応表に書き方を足せば翌月から決まります。

6番目で値を直さないのも同じ理由です。 検算が合わないとき、原因は読み違いのこともあれば、明細の側の誤りのこともあります。どちらかは画像を見ないと分かりません。

出力形式を固定する

次の形の JSON で一覧に書き出します。

{
  "warehouse_code": "WK-03",
  "account_no": "",
  "period": { "from": "2026-09-01", "to": "2026-09-30" },
  "casks": [
    { "cask_no_raw": "", "cask_no": "", "cask_type": "hogshead",
      "fill_date": "2019-04-11", "bulk_litres": 0, "abv": 0, "litres_alcohol": 0,
      "regauge_date": "", "loss_pct_per_year": 0,
      "status": "ok | missing_on_statement | unknown_cask | transferred | calc_mismatch | needs_review",
      "confidence": 0, "page": 1 }
  ],
  "totals": { "litres_alcohol_rows": 0, "litres_alcohol_summary": 0, "check": "ok | total_mismatch" },
  "invoice_lines": [
    { "item": "storage | insurance | regauge | sampling | transfer", "cask_type": "",
      "qty": 0, "unit_price": 0, "amount": 0, "expected_amount": 0,
      "status": "match | rate_diff | count_diff | not_ordered | needs_review" }
  ],
  "verdict": "clear | query_warehouse | needs_review"
}

1つ目の理由は、元の樽番号と直した樽番号を並べて残せることです。 cask_no_raw と cask_no が並んでいれば、どの書き方をどう読み替えたかを、画像を開く前に読めます。

2つ目は、在庫と請求を1つの照合表で見られることです。 樽の数が明細と台帳で合わなければ、保管料の数も合わないはずで、 2つの差を並べると問い合わせを1通にまとめられます。

transferred は clear を妨げません。 台帳に移し替えの予定がある樽が、移し先の口座の明細に載っていれば、正しく動いた樽です。

システムへ連携する

樽ごとの台帳には自動で書き込みません。 列を取り違えた値が台帳に入ると、翌月からその樽の量の減り方がすべて狂います。 再計量の値は、人が確かめた後に取り込みます。料金表も読むだけで、変えるのは購買部です。

支払の仕組みにもつなぎません。 照合表は支払の判断の材料で、支払うかどうかは経理の担当者が決めます。

人が確認する

人が開くのは clear 以外の口座だけです。 clear の口座は一覧で流し見て、経理に回します。全件を開く設計にすると、第10章の4.0時間には収まりません。

1. needs_review を先に見る … 量の列の種類、検算の合わない樽、合計の合わない明細を、画像で確かめます。決めた書き方は対応表に足します
2. missing_on_statement を確かめる … 台帳にあって明細に無い樽が、売った樽の引き渡しか、移し替えか、本当の抜けかを、台帳の予定と照らします
3. 料金の差を確かめる … rate_diff と count_diff は、料金表の数え方の取り決めを読み直してから、保管業者に問い合わせます
4. 量の減り方の印を見る … 自社の幅を超えた樽は、再計量の値の読み違いでないかを確かめ、本当に大きく減っていれば、保管業者に樽の状態を尋ねます

2番目は、仕組みでは置き換えられません。 樽の売買と引き渡しの段取りは、台帳に書かれていない約束で動いていることがあります。

目標は、24件をならして1件10分です。 それを超える月は、列の対応表の書き方か、料金表の数え方の列が足りていません。

例外に対処する

大半は AI の精度ではなく、明細の書き方の揺れと、対応表と料金表の整い方の問題です。

記録を残す

• 元の明細と請求書、受け取った日時・保管業者・口座
• AWS Textract が返した JSON の全文と JobId
• 樽ごと・請求の行ごとの判定と、そのとき参照した対応表・料金表の版
• 人が値や判定を直した記録 … どの樽の、どの値を、どう読み直したか
• 保管業者への問い合わせの内容と返事、請求の訂正の有無
• 再計量の値の履歴（樽ごと）
• 保管業者ごとの needs_review と query_warehouse の件数

6つ目を積み重ねると、樽ごとの量の減り方が年ごとに見えてきます。 倉庫や樽の種類ごとの傾向が分かれば、量の減り方の印の幅を、自社の実績に合わせて決め直せます。