画廊が海外のオークションハウスから受け取る英文の落札明細を読み取り、ロットごとの落札額・手数料・追及権料・輸送費を仕入台帳に転記して、入札の記録との食い違いと支払・引取の期限を拾う

処理の起点を決める

受付フォルダ（Amazon S3）に明細が保存されたことを起点にします。 支払と引取の期限は落札から数週間のことが多く、届いた日のうちに期限を予定表に入れておく必要があります。 定時の実行ではなく、届いたその場で動かします。

ファイルは <ハウス略称>_<セール番号>_INV.pdf、輸送の請求書は <輸送業者略称>_<請求番号>_SHIP.pdf の形で置きます。末尾で書類の種類を分けます。 担当者がメールから保存するだけで済むよう、名前の付け方は1つに決めておきます。

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

入力データを集める

質を決めるのは、入札の記録と料率表です。 入札の記録が無ければ照合ができず、料率表が無ければ検算ができません。料率表には、表を作ったときに見たハウスの販売条件の版と日付を必ず書きます。 料率は改定されるため、セールの日付で表を選びます。

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

読み取りは2段にします。1段目は StartExpenseAnalysis、2段目は1段目で取れなかった項目だけを StartDocumentAnalysis の QUERIES で読み直します。

明細の行は、列の見出しで読みます。 オークションの明細の表は「Lot」「Description」「Hammer Price」「Premium」「VAT」などの列が並ぶ形が多く、EXPENSE_ROW の中の各項目に、その列の見出しの文字列が LabelDetection として付く想定で組みます。付き方はハウスの書式で変わりうるため、最小構成の15通で必ず確かめます。

2段目の質問は、対象のページを指定しないと既定で1ページ目にしか当たりません。 引取の期限は最後のページの注記にあることが多いので、Pages: ["*"] を付けます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であること。XFA形式のPDFは扱えません
2. パスワードの確認 … PDFはパスワード保護不可です。ハウスのマイページから落とした明細にパスワードが付いていれば、解除したものを保存し直します
3. サイズと寸法の確認 … 非同期の処理で PDF と TIFF は500MB・3,000ページ、JPEG と PNG は10MBまで、画像はどの辺も10,000ピクセル以下です
4. 文字の大きさの確認 … 文字の高さが15ピクセル（150 DPIで8ポイント相当）を下回ると検出されません。期限の注記は小さな字なので、縮小しすぎません
5. 書類の種類の確認 … ファイル名の末尾と、全文の「Invoice」「Statement」「Pro forma」などの語が合うかを見ます。見積の段階の書類を本番の明細として写さないためです
6. 重複の確認 … 同じハウス・同じ請求番号が既にあれば止めます。訂正の明細のこともあるので、差し替えか重複かを担当者に聞きます

AIに処理させる

させるのは、明細から決まった項目の値を、見出しの言い方と位置と信頼度を添えて読み取ることだけです。 項目のそろえ方、照合、検算は、読み取りの後にプログラムの規則が行います。

手数料が「行ごと」か「まとめ」かを区別するのが、この表でいちばん大事なところです。 行ごとに書くハウスとまとめて書くハウスがあり、両方に同じ金額が書かれている明細もあります。 区別せずに足すと、手数料を二重に台帳に載せます。

指示内容を固定する

1段目の請求書・領収書の分析には、質問のような指示はありません。2段目で、1段目で取れなかった項目だけに当てる質問を英語で用意します。

QueriesConfig:
  Queries:
    - Text: "What is the sale number?"
      Alias: SALE_NO
      Pages: ["*"]
    - Text: "What is the date of the sale?"
      Alias: SALE_DATE
      Pages: ["*"]
    - Text: "By what date must the purchased lots be collected?"
      Alias: COLLECTION_DEADLINE
      Pages: ["*"]
    - Text: "From what date will storage charges apply?"
      Alias: STORAGE_FROM
      Pages: ["*"]
    - Text: "What is the payment due date?"
      Alias: PAYMENT_DUE
      Pages: ["*"]

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

【読み取り結果の扱いの決まり】
1. 値が空の項目は not_found とする。入札の記録や合計から逆算して埋めない。
2. 信頼度が決めた値を下回る項目は unreadable とし、値は参考として残す。
3. 明細の行の項目は、Type ではなく LabelDetection の文字列で項目を決める。
   項目表に無い見出しは unmapped とし、似た見出しに寄せない。
4. 手数料が行ごとにもまとめにもある場合は、行ごとの合計とまとめの値を比べ、
   同じなら行ごとの値だけを使う。違えば ambiguous とする。
5. 金額は通貨記号と桁区切りを外して数値にする。
   通貨が明細の頭と行で違えば currency_mismatch とする。
6. 日付は月の名前が書かれていればそのまま読む。数字だけで日と月の
   両方が12以下なら ambiguous とし、セールの日付から推し量らない。
7. 書類に「Pro forma」「Estimate」とあれば、台帳に写さず担当者へ返す。

3番目がこの構成の要です。 手数料や追及権料は標準の名前に無いため、Type は OTHER になります。OTHER の中身を見出しの言い方で分けないと、税も手数料も保管料も同じ「その他」に入ります。

照合と検算は次の決まりで行います。

【照合と検算の決まり】
A. ハウス・セール番号・ロット番号で入札の記録を引く。
   引けなければ not_in_bid_record とする。
B. 落札額が入札の上限額を超えていれば over_max_bid とする。
C. 料率表はセールの日付で選び、帯ごとの料率で手数料を計算し直す。
   明細の手数料との差が決めた幅を超えれば premium_diff とする。
D. 追及権料の行があれば金額を並べて人に見せる。計算し直さない。
E. 支払と引取の期限は、予定表の下書きに入れる。

Dで追及権料を計算し直さないのは、国によって決まりが違うからです。 英国の政府のページでは、追及権は1,000ポンド以上の転売に掛かり、帯ごとの料率と1件あたりの上限（12,500ポンド）があるとされています。オークションハウスの用語集も、料率・対象・誰が払うかは国によって違うとしています。人が見るための材料として並べるだけにします。

出力形式を固定する

読み取りと照合の結果を、明細1通ごとに次の形のJSONにまとめて台帳へ渡します。

{
  "invoice_id": "HOUSEA_26123_INV",
  "house": "", "sale_no": "26123", "sale_date": "2026-10-02",
  "currency": "GBP",
  "lots": [
    { "lot_no": "145", "description": "",
      "hammer": 0, "premium": 0, "premium_recalc": 0, "arr": 0, "tax": 0,
      "bid_record": "found | not_in_bid_record", "max_bid": 0,
      "checks": ["over_max_bid", "premium_diff"],
      "confidence_min": 0, "page": 1 }
  ],
  "charges": [ { "label": "Storage", "amount": 0, "status": "ok | unmapped" } ],
  "total": { "document": 0, "sum_of_parts": 0, "result": "match | diff" },
  "deadlines": { "payment_due": "", "collection_by": "", "storage_from": "" },
  "verdict": "confirm | review | urgent"
}

1つ目の理由は、ロットごとに金額を分けて持てることです。 作品ごとの仕入値（落札額）と付随の費用（手数料・追及権料・税）が分かれ、後で作品ごとの利益を出すときにそのまま使えます。

2つ目は、total で合計の突き合わせができることです。 明細の合計と、分けて写した金額の和が合わなければ、どこかの行を写し漏らしたか、二重に写したかのどちらかです。

システムへ連携する

会計システムと送金には、何も書き込みません。 送金は経理が確定した台帳を見て行います。読み違えた金額がそのまま送金に流れる経路を作らないためです。 ハウスへの問い合わせも人が行います。

人が確認する

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

1. urgent を先に見る … 入札の記録に無いロットは、担当の美術商が記録を書き忘れたのか、ハウスの誤りかを確かめます
2. 検算の差を確かめる … 料率表の版がセールの日付に合っているかを見ます。料率表が古いだけのことが多いです
3. unmapped の見出しを項目表に足す … 同じ調べものを二度しないための作業です
4. 確定する … 読み取りの値と直した値の両方を残します

1番目を省かないでください。 入札の記録の書き忘れをハウスの誤りとして問い合わせると、取引先との関係にひびきます。 先に社内の記録を疑います。

例外に対処する

記録を残す

• 明細と輸送の請求書の元のファイル、AWS Textract の結果の全文（JSON）と JobId
• そろえた後の値とそろえ方の記録、照合と検算の結果とそのときの料率表・項目表の版
• 担当者が直した項目と直す前の値、ハウスに問い合わせた内容と回答
• ハウスごとの review の発生率と、検算の差の傾向

料率表の版を残すのは、改定のたびに過去の検算の意味が変わるからです。