海外の物流倉庫（3PL）から毎月届く英文の在庫報告書を読み取り、SKUごとの在庫数・入出庫数を自社の在庫台帳と照らして、差異と滞留在庫を拾う

処理の起点を決める

倉庫ごとの受け取りの場所（S3 のフォルダ）にPDFが保存されたことを起点にします。 フォルダは 3pl-report/<3PLの記号>/<倉庫の記号>/<対象月>/ の形にし、どの倉庫のどの月の報告かを、保存した場所で決めます。 報告書の中の倉庫名を読み取って決めると、同じ3PLの別の倉庫と取り違えます。

読み取りを始めるとき、ClientRequestToken に「倉庫の記号＋対象月＋ファイルの版」を入れます。 公式のページでは、同じトークンで StartDocumentAnalysis を呼ぶと同じ JobId が返り、同じジョブを誤って二度始めるのを防げるとされています。担当者が同じPDFを二度保存しても、読み取りは一度で済みます。

完了は Amazon SNS の通知で受けます。 通知の状態が SUCCEEDED であることを確かめてから GetDocumentAnalysis を呼ぶ、と公式のページにあります。JobTag に倉庫の記号を入れておくと、通知だけでどの倉庫の報告かが分かります。 JobId は7日間だけ有効なので、結果は受け取ったその場で S3 に保存します。

入力データを集める

質を決めるのは、3行目の倉庫ごとの設定です。 「Qty On Hand」「Closing Stock」「End Bal」は同じ月末在庫で、「Adj」「Stock Adjustment」「Inv Correction」は同じ調整です。設定表に倉庫ごとの対応を持ち、毎月の照合はその設定で読みます。 AIが毎月その場で対応づけを考えるのではありません。

数の書き方も、倉庫ごとに設定します。 桁区切りがコンマか点か、小数点があるかを、倉庫ごとに1行で決めます。 報告書を見て推し量らせると、「1.250」を1.25と読む誤りが出ます。

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

表は、CELL のブロックの RowIndex と ColumnIndex で組み立てます。 公式のページでは、表は TABLE のブロックとして返り、各セルは CELL のブロックで、表の中の位置の情報を持つとされています。結合されたセルは MERGED_CELL として別に示されます。見出しが2段になっている報告書は、結合されたセルを先に展開してから見出しを決めます。

セルには、見出し・合計・表題などの種類が付きます。 公式のページでは、セルの EntityTypes に TABLE_TITLE、TABLE_FOOTER、TABLE_SECTION_TITLE、COLUMN_HEADER、TABLE_SUMMARY があるとされています。見出しの判定と合計の行の判定に、この種類を使います。

結果は MaxResults の1,000ブロックずつ返ります。 NextToken が返る限り呼び続け、全ページ分のブロックをそろえてから表を組み立てます。 途中で組み立てると、ページの境目でSKUの行が落ちます。

報告の期間は、QUERIES で取ります。 公式のページでは、問い合わせ（クエリ）は英語の文書でだけ使え、非同期の処理では1ページあたり30件までとされています。表の外にある報告日や期間を取るのに使います。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のどれかであることを確かめます。XFA の形式のPDFは扱えないとされています
2. パスワードの確認 … パスワードで保護されたPDFは扱えません。 3PLに保護を外して送ってもらいます
3. 大きさの確認 … 非同期ではPDFが500MB・3,000ページまで。超えることはまず無いので、超えたら読み取らずに人へ回します
4. スキャンの確認 … 紙を読み込んだものは、文字の高さが15ピクセル（150DPIで8ポイント相当）以上であることを確かめます
5. ページをまたぐ表の連結 … 各ページの表の見出しが同じなら1つの表として続け、ページごとに繰り返される見出しの行は落とします
6. 数と日付の読み替え … 倉庫ごとの設定で、桁区切りと小数点、日付の順を読み替えます
7. 品目コードの対応づけ … 対応表で自社のSKUにそろえます。対応の無いコードは「対応なし」として残します

5番目を軽く見ないでください。 20ページの報告書は20個の表として返ります。見出しの行をそのまま残すと、「SKU」という名前の品目が19件並びます。 表の連結は、プログラムで決まった手順にします。

7番目の「対応なし」は、3PLが自社の知らない品目コードを付けた場合です。 多くは、セット品をばらして入庫したか、ラベルを貼り替えたものです。推し量って近いSKUに寄せないでください。

AIに処理させる

させるのは、言葉を扱う3つの仕事だけです。 数の読み取りは Textract、数の計算と照合はプログラムが行います。

1行目がいちばん大事です。 数をAIの出力の文字として受け取ると、元の報告書の数と一致しているかを、どこかでもう一度確かめる必要が出ます。 セルの数をプログラムが直接読めば、その確かめが要りません。

見出しの対応づけを承認待ちにするのは、3PLが報告書の書式を予告なく変えるからです。 「Shipped」の列が「Shipped (Net of Returns)」に変われば、返品を差し引いた数になります。AIは対応の案を出し、担当者が意味を確かめてから設定に足します。

指示内容を固定する

見出しの対応づけの案（見出しが変わったときだけ呼ぶ）の指示です。

あなたは物流部の担当者を手伝い、海外の物流倉庫の在庫報告書の列の見出しを、
自社の在庫台帳の項目に対応づける案を作る立場です。
渡された見出しの一覧と、その倉庫の前回までの対応だけを見てください。

【自社の項目】
opening（月初在庫）／received（入庫）／shipped（出庫）／adjusted（調整）／
closing（月末在庫）／days_in_storage（保管日数）／remarks（備考）／none（対応なし）

【厳守事項】
- 見出しの言葉だけで判断してください。表の中の数を見て推し量らないでください。
- 見出しに「Net」「Incl.」「Excl.」「Returns」などの条件が付いていれば、
  対応の案に加えて、条件をそのまま note に写してください。
- 2つの項目に当たりうる見出しは none とし、note に理由を書いてください。
- 前回までの対応と違う案を出す場合は、changed を true にしてください。

備考の区分と問い合わせの下書きの指示です。

あなたは物流部の担当者を手伝い、海外の物流倉庫（3PL）への在庫の差異の問い合わせを
英文で下書きする立場です。渡された差異の一覧と、報告書の備考欄の原文だけを見てください。

【備考の区分】
qc_hold（品質保留）／damaged（破損）／return_receipt（返品の入庫）／
count_correction（棚卸の訂正）／other（その他）
備考の原文は、区分と一緒にそのまま残してください。

【問い合わせの書き方】
- SKUごとに、差の種類、報告書の数、自社の記録の数、根拠（ASN番号・出荷番号・報告書のページ）を並べてください。
- 数は渡された値をそのまま書いてください。足したり引いたりしないでください。
- どちらの誤りかを書かないでください。確認をお願いする形にしてください。
- 差の種類が unknown のものは、事実だけを書き、原因の推測を書かないでください。

「表の中の数を見て推し量らない」と書くのは、 見出しが曖昧なとき、AIは数の大きさから「これは出庫だろう」と当てにいくからです。当たっていても、根拠が見出しに無い対応は、次に書式が変わったときに崩れます。

問い合わせに「どちらの誤りかを書かない」と入れるのは、3PLとの関係のためです。 差異の半分は自社の記録の遅れから出ます。最初の1通で3PLの誤りと書けば、自社の誤りだったときに取り消しにくくなります。

出力形式を固定する

照合の結果は、プログラムがJSONで出します。 生成AIの出力も、Claude API の構造化出力で形を決めて受けます。公式のページでは、output_config.format に JSON スキーマを渡すと、スキーマに合う JSON が返るとされ、正式提供の機能です。

{
  "warehouse": "US-EAST-01",
  "period": "2026-09",
  "summary_check": "matched | mismatch",
  "lines": [
    { "sku": "CS-30117", "tpl_code": "CS30117-EA",
      "opening": 420, "received": 600, "shipped": 512, "adjusted": -8, "closing": 500,
      "ledger_closing": 520,
      "variance": { "type": "received | shipped | adjusted | carried_over | unknown",
                    "qty": -20, "evidence": "ASN-0912-03 shipped 620, received 600" },
      "remarks_raw": "8 units damaged on receipt", "remarks_class": "damaged",
      "min_cell_confidence": 92.4, "days_in_storage": 35 }
  ],
  "slow_moving": [ { "sku": "", "days_in_storage": 0, "shipped_90d": 0 } ],
  "needs_human": [ { "sku": "", "reason": "low_confidence | no_mapping | summary_mismatch" } ]
}

1つ目の理由は、差異の種類を1列で持てることです。 variance.type が received なら入庫の担当、shipped なら出荷の担当へ、問い合わせる相手が列で決まります。 例のSKUでは、ASNで送った620個に対して3PLの入庫が600個で、差の20個は入庫で生じています。

2つ目は、summary_check を照合の手前に置けることです。 mismatch の報告書は lines を作らずに人に回します。

3つ目は、remarks_raw を残せることです。 区分は担当者が読む手がかりで、原文が残っていれば区分の誤りに気づけます。 例の備考の「8 units damaged on receipt」は、調整の8個と結び付きます。

システムへ連携する

在庫台帳には書き込みません。 差異の一覧を見て、台帳を直すか、3PLに訂正を求めるかを決めるのは担当者です。この構成から台帳を直すと、3PLの誤りに自社の台帳を合わせることになります。

Claude を Amazon Bedrock から使う場合は、構造化出力の対応を先に確かめます。 公式のページでは、Bedrock では構造化出力が旧来の Bedrock の連携でだけ使え、Claude in Amazon Bedrock では使えないとされています。

人が確認する

人が見るのは、差異のあるSKUと、needs_human の行だけです。 差の無いSKUは倉庫ごとの件数を見て終えます。

1. summary_mismatch の報告書を先に見る … 合計が合わない報告書は照合に進んでいません。多くは表の連結か、見出しの行の落とし忘れです
2. 信頼度の低いセルを原本で見る … セルの位置からPDFの該当箇所を開き、数を確かめます
3. 差異の根拠を確かめる … evidence のASN番号・出荷番号を台帳で開き、自社の記録の遅れでないかを見ます
4. 問い合わせを直して送る … 下書きの数と根拠を確かめ、送信は担当者が行います
5. 滞留在庫を販売の担当と見る … 保管日数と出荷の実績を並べて、扱いを決めます

3番目を省かないでください。 入庫の確認の登録が月をまたいで遅れると、自社の記録のほうが少なく見えます。 3PLへ問い合わせる前に、自社の記録を見ます。

例外に対処する

上から2行目と3行目が、最初の数か月は多く起きます。 どちらも報告書の書式の問題で、3PLに合計の行を入れてもらうだけで減ります。

記録を残す

• 報告書の原本と、保存した場所（倉庫・対象月・版）
• Textract が返したブロックの全文と、組み立てた表
• 倉庫ごとの設定（見出しの対応・数と日付の書き方）の、その月に使った版
• 照合の結果（lines、slow_moving、needs_human）
• 担当者が直した箇所 … どのセルの数を、どう直したか
• 3PLへの問い合わせと回答、差異の解消の記録
• 倉庫ごとの差異の件数と種類の推移

3つ目で設定の版を残すのは、見出しの対応が後で変わるためです。 対応を直すと過去の照合の意味が変わり、当時の設定が無いと、どの月から差異の読み方が変わったかが分かりません。

最後の行は、3PLとの定例の材料になります。 入庫差が続く倉庫は検品の手順に、出庫差が続く倉庫は出荷の記録に理由があります。