海外の旅行会社から毎月届く英文の手数料の精算書を読み取り、予約台帳と突き合わせて、手数料率と対象の予約の食い違いを拾う

処理の起点を決める

起点は、精算書のPDFを受付フォルダ（Amazon S3）に保存したことです。 保存のたびに1枚ずつ処理を動かします。月末にまとめて処理しないのは、問い合わせの返事を待つ時間を残すためです。 旅行会社の時差を考えると、問い合わせは早く出すほど支払日に間に合います。

受付フォルダは旅行会社ごとに分けます。 フォルダの名前から旅行会社を決め、その会社の設定（日付の書き方、通貨、基準）を処理の最初に読み込みます。精算書の中の会社名をAIに読ませて会社を決めると、ロゴだけの精算書で取り違えます。

文書分析は非同期の StartDocumentAnalysis で始めます。 同期の処理は PDF が1ページまでという制限があり、数ページにわたる精算書は非同期で扱います。 終わると Amazon SNS に完了の状態が通知されるので、それを起点に結果を取りに行きます。

入力データを集める

質を決めるのは、予約台帳に旅行会社の予約番号が入っているかです。 精算書には旅行会社の側の番号しか書かれていないことが多く、自社の予約番号だけでは突き合わせる先がありません。 予約を受けたときに、旅行会社の番号を台帳の項目に入れる運用を先に決めます。

契約の一覧は、率だけでは足りません。 「客室料金のみ」「食事を含む」「税・サービス料を除く」といった基準と、手数料を付けない料金の種類を持たせます。第3章の（b）は、ここが一覧になっていないことから起きています。

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

結果の取得には GetDocumentAnalysis を使います。 1回の呼び出しで返るブロックは最大1,000件で、それを超えると NextToken が返るため、NextToken が無くなるまで呼び続けて全部を集めます。 途中で止めると、後半のページの行が丸ごと抜けます。

問い合わせ（QUERIES）は、表の外にある値を取るために使います。 「What is the statement period?」「What is the total commission amount?」のように聞くと、答えが QUERY_RESULT として信頼度付きで返ります。公式の制限では、非同期の処理で1ページあたり30件までで、問い合わせは英語の文書でだけ使えます。 表の中身は問い合わせではなく TABLES で取ります。

状態が PARTIAL_SUCCESS のときは、照合に進みません。 一部のページが処理できていないということなので、Warnings に出たページ番号を記録し、担当者に回します。

AIへ渡す前に整形する

1. 形式とサイズの確認 … Textract が受け付けるのは JPEG、PNG、PDF、TIFF です。非同期の処理で PDF は500MB・3,000ページまでです
2. パスワード付きPDFの確認 … PDF はパスワードで保護されていてはいけません。旅行会社に保護のない版を送ってもらいます
3. XFA 形式の確認 … XFA 形式の PDF は対応していません。印刷して PDF にし直すか、旅行会社に別の形式を頼みます
4. 文字の大きさの確認 … 検出できる文字の高さの下限は15ピクセルで、150DPI では8ポイントの文字に相当します。縮小して印刷された精算書は読み落とします
5. 表の行を組み立てる … CELL の RowIndex と ColumnIndex から行列を作り、MERGED_CELL の値を対応する行に割り当てます
6. 複数ページの表をつなぐ … ページごとに分かれた表を、列見出しが同じなら1つの表としてつなぎます
7. 重複の検知 … 同じ旅行会社・同じ対象期間の精算書がすでに処理されていれば、印を付けて止めます

6番目を軽く見ないでください。 精算書は2ページ目以降に列見出しを繰り返さないことが多く、別の表として扱うと2ページ目の列の意味が決まりません。

AIに処理させる

させるのは、組み立てた表の列を共通の項目にそろえることだけです。 列見出しの文字と、各列の値の並びを見て、どの列が何を表すかを決めさせます。

右端の列が、この構成でいちばん大事な扱いです。 列の意味が1つに決まらないとき、AIは「たぶんこれ」と選びがちです。選ばせずに ambiguous で返させ、旅行会社ごとの設定に正しい対応を登録します。 2回目からは登録した対応を先に当て、AIはその検証に回します。

1行目がいちばん起きやすい失敗です。 列をそろえるついでに「この行の手数料は10％なので…」と計算を始めます。指示で計算を禁じ、出力の形にも計算結果を入れる項目を作りません。

指示内容を固定する

You map columns of a travel agent's commission statement to standard fields.
Use only the table given below. Do not calculate anything.

[Standard fields]
agent_ref, guest_name, arrival, departure, nights, room_nights,
base_amount, rate, commission, currency

[Rules]
- For each source column, choose one standard field or "unmapped".
- If two or more columns could be the same field, set status to "ambiguous"
  and list the candidate columns. Do not pick one.
- Copy cell values exactly as written. Do not convert dates, numbers,
  or currencies. Do not round.
- Do not decide the day/month order of dates. The order is given in
  [Agent settings].
- Do not compute commission, rate, or base_amount from other columns.
  If a value is missing, return null.
- If the table header says that meals, taxes, or service charges are
  included in the base amount, record it in base_note. Do not judge
  whether the commission is correct.
- If the document is not a commission statement, set document_type and stop.

[Agent settings] {agent_settings}
[Known column mapping for this agent] {known_mapping}
[Table header cells] {header_cells}
[First 10 rows] {sample_rows}
[Text outside the table] {query_results}

指示を英語で書くのは、列名を日本語に訳して返させないためです。 訳されると、後段のプログラムで列名と照らせなくなります。

「Do not compute」を2か所に書いているのは、計算を止めるためです。 手数料の列が空の行があると、率と基準額から埋めて返します。埋めた値が正しくても、精算書に書かれていないという事実が消えます。 その行は旅行会社に確かめるべき行です。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に type: "json_schema"）で形を守らせます。

{
  "statement_id": "",
  "document_type": "commission_statement",
  "agent_code": "",
  "period": { "from": "", "to": "", "source": "query | table | not_found" },
  "currency": "",
  "column_mapping": [
    { "source_column": "", "field": "agent_ref", "status": "mapped | ambiguous | unmapped",
      "candidates": [] }
  ],
  "base_note": "",
  "summary_total": ""
}

1つ目の理由は、列の対応だけを返させられることです。 出力に行の値を含めず、列の対応だけを受け取ります。 値はTextract の結果からプログラムが取り出すので、AIが値を写し間違える経路がありません。

2つ目は、照合の結果を別の層に置けることです。 プログラムは列の対応を使って行を組み立て、台帳と契約に照らして次の判定を付けます。

取消と不泊を mismatch にせず needs_human にしているのは、契約で扱いが分かれるからです。 不泊でも手数料を払う取り決めの会社もあります。判定はプログラムで機械的に出しますが、支払うかは人が決めます。

3つ目は、スキーマの制約に合わせられることです。 公式の説明では、オブジェクトには additionalProperties: false が必要で、数値の範囲（minimum など）や文字数（minLength など）の制約は使えません。金額や率の範囲の確認は、プログラムの側で行います。 なお、Amazon Bedrock 上の Claude では構造化出力の対応範囲が限られるため、この構成では Claude API を直接呼びます。

システムへ連携する

予約管理システムへは書き込みません。 取消の漏れや予約番号の入れ忘れが見つかっても、台帳を直すのは予約の担当者です。

会計システムへの登録も、人が確定したものだけです。 食い違いの行を除いた額を自動で登録すると、問い合わせの結果を待たずに支払が進みます。

人が確認する

経理課の担当者が見るのは、ok 以外の行と、合計の照合です。

1. 合計を先に見る … 明細の手数料の合計と、精算書の合計の行（TABLE_SUMMARY）が一致するかを見ます。一致しなければ、読み取りの抜けを疑います
2. needs_human を見る … 取消・不泊の行は、契約で手数料の扱いを確かめます。列の対応が ambiguous なら、正しい対応を設定に登録します
3. mismatch の理由を確かめる … 率の違いか、基準額の違いかで、問い合わせの書き方が変わります
4. not_found を予約担当と確かめる … 台帳に旅行会社の番号が入っていないだけのことが多くあります
5. 問い合わせを送る … 下書きを直して、担当者が送ります

4番目を省かないでください。 not_found の多くは、自社の台帳に旅行会社の予約番号が入っていなかったというだけです。 そのまま旅行会社に問い合わせると、相手に余計な調べものをさせます。

目標は、60枚をならして1枚15分です。 食い違いの少ない会社の精算書は数分で終わり、取消の多い月の団体の精算書は長くかかります。

例外に対処する

上から3行目は、受付の時点で止めます。 受付フォルダの設定に「英文のみ」を持たせ、例外は別の経路にします。

記録を残す

• 元の精算書と、受け取った日時・旅行会社・対象期間
• Textract の結果の全文（JobId、ブロック、Warnings）
• 列の対応（AIの出力）と、人が直した対応
• 行ごとの照合の結果と、そのとき参照した契約の率と基準
• 問い合わせの内容と旅行会社の回答、支払額の確定の記録
• 旅行会社ごとの mismatch と needs_human の件数

JobId は7日間しか有効でないため、結果は取得したその場で保存します。 後から取り直そうとしても、結果が取れなくなっています。

最後の行は、契約の見直しの材料です。 同じ会社で率の食い違いが続くなら、相手の側の設定が古いままです。 1行ずつ問い合わせるより、契約の率を確かめ合うほうが早く終わります。