海外の現地法人から毎月届く英文の給与明細を読み取り、赴任者給与の台帳に転記して、規程の手当との食い違いを拾う

処理の起点を決める

現地法人の人事が、明細のPDFを Amazon S3 の受付の場所に置いたことを起点にします。 メールの添付で受け取る運用をやめ、国ごとに incoming/US/、incoming/UK/ のような受付の場所を分けます。S3 はオブジェクトが作られたときに Lambda を呼び出せます。

ここで気を付けるのは、同じバケットへの書き戻しです。 AWS の公式の説明では、関数を起動したバケットに関数が書き込むと、関数が自分自身を呼び出す繰り返しになりうるとされ、バケットを2つに分けるか、受付用の接頭辞にだけ起動を限ることが勧められています。この構成では、起動を incoming/ に限り、読み取り結果は results/ に書きます。

ただし、1ファイルごとに照合はしません。 現地法人によっては、月の途中に追加の支給（賞与、精算）の明細を後から送ってきます。読み取りはファイルが届くたびに行い、照合と台帳の案づくりは毎月の締め日の2営業日前に、その月に届いた分をまとめて行います。 隔週払いの2枚の明細を、1か月分として並べて見るためです。

入力データを集める

質を決めるのは、費目の対応表です。 「Accommodation」が住宅の手当である、という対応を一度確定したら表に残し、翌月からは表で当たる行はAIに聞かずに当てはめます。 AIに当てはめさせるのは、表に無い新しい項目名だけです。

赴任者の情報の「家族の帯同の開始日」と「帰任日」は、第3章の（b）を拾う材料です。 手当の付く条件が変わる日を持っていないと、支給漏れも、帰任後の支給も見つけられません。

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

Lambda から StartDocumentAnalysis を呼び、FeatureTypes に TABLES、FORMS、QUERIES を指定します。 完了の通知先（NotificationChannel）に SNS のトピックを指定し、通知を受けた別の Lambda が GetDocumentAnalysis で結果を取ります。

問い合わせは、表とキーと値で取れなかったときの保険にします。 投げるのは次のような英文です。別名（Alias）を付けておくと、答えを項目名で受け取れます。

同じ手順を何度も呼ばないために、ClientRequestToken を付けます。 同じトークンで同じ処理を呼ぶと、同じ JobId が返り、処理はやり直されないとされています。Lambda が再試行されても、同じ明細を二重に読みません。

結果は既定では7日間しか取り出せません。 取得したらすぐに S3 の results/ に保存します。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のいずれかであることを確かめます。XFA の形式のPDFは対象外です
2. パスワードの確認 … パスワードで保護されたPDFは読めません。 給与明細には保護が付いていることが多いので、受付の場所に置く前に現地の人事が保護を外す運用にします（第13章）
3. サイズとページ数 … 非同期の処理でPDFは500MB・3,000ページまで。1名1〜2ページの明細なら問題になりません
4. 画像の大きさ … 各辺10,000ピクセル以下です。写真で届いたものは縮小します
5. 文字の大きさ … 検出できる文字の最小の高さは15ピクセルで、150dpiで8ポイントの文字に当たります。スキャンは150dpiを下回らないようにします
6. 複数の赴任者がまとまったPDF … 1ファイルに何名分もあるものは、ページの見出しの社員番号で分けます

2番目がいちばん止まりやすいところです。 保護を外さずに置かれたPDFは読み取りで失敗し、その赴任者の行だけが台帳の案から抜けます。 失敗は担当者の一覧に「未読」として出します。

AIに処理させる

AIの仕事は2つです。明細の行を本社の費目に当てはめることと、照会文の下書きです。

4行目がいちばん起きやすい失敗です。 控除の1行が読めないと、AIは支給の合計と差引の支給額から逆算して埋めようとします。その値が明細に書かれた額として台帳に載ると、検算が必ず合ってしまい、読めなかったことが消えます。

指示内容を固定する

あなたは日本の本社の海外人事の担当者です。
海外の現地法人が出した英文の給与明細の読み取り結果から、
明細の行を本社の費目に当てはめます。
読み取り結果に書かれていることだけを根拠にしてください。推測で埋めないでください。

【本社の費目】
支給：base_salary / housing_allowance / family_allowance /
      hardship_allowance / overtime / bonus / other_earning
控除：local_income_tax / social_security / pension /
      other_deduction

【厳守事項】
- 費目の対応表で当たる行は、表のとおりに当てはめてください。
- 表に無い項目名は、最も近い費目を選び、mapping_source を "ai" にしてください。
  どれにも当てはまらなければ other_earning か other_deduction にし、
  理由を note に書いてください。
- 「Allowance」とだけ書かれた行のように何の手当か分からないものは、
  他の行から推測せず status を ambiguous にしてください。
- 額は明細に書かれた文字列をそのまま amount_text に入れてください。
  桁区切りや通貨の記号を取り除かないでください。
- 読み取りの信頼度が50未満の行は status を unreadable にしてください。
- 読めない額を、合計や差引の支給額から逆算して埋めないでください。
- 金額の計算、為替の換算、規程の額との比較をしないでください。
- 税額や社会保険料が正しいかどうかを書かないでください。
- 各行に、根拠にした明細の行の文字列をそのまま evidence に写してください。

【赴任国と委託先】{country} / {payroll_vendor}
【費目の対応表（この国・委託先の分）】{mapping_table}
【読み取り結果（表・キーと値・問い合わせ、信頼度付き）】{textract_result}

「Allowance とだけ書かれた行」を名指しで書いているのは、そこが最も迷う行だからです。 何も言わないと、AIは金額の大きさから住宅の手当だろうと推測します。推測で当てはめた費目は、規程の額との照合で偶然合うことがあり、誤りに気づけなくなります。

「通貨の記号を取り除かない」も意図があります。 同じ明細に現地の通貨と米ドルの両方が出ることがあり、記号を落とすとどちらの額か分からなくなります。

出力形式を固定する

次の形のJSONで受け取ります。 Claude の構造化出力（output_config.format に json_schema を指定）を使い、項目の名前と型を固定します。

{
  "employee_local_id": "US-00412",
  "employee_hq_id": "",
  "country": "US",
  "pay_date": "2026-09-30",
  "period_start": "2026-09-16",
  "period_end": "2026-09-30",
  "currency": "USD",
  "lines": [
    { "side": "earning", "local_label": "Housing Allowance",
      "hq_item": "housing_allowance", "mapping_source": "table | ai",
      "amount_text": "$3,200.00", "status": "ok | ambiguous | unreadable",
      "confidence": 96.4, "evidence": "Housing Allowance 3,200.00", "note": "" }
  ],
  "totals": { "gross_text": "", "deductions_text": "", "net_text": "" }
}

1つ目の理由は、mapping_source で確認の重みを変えられることです。 table は確定済みの対応表で当たった行、ai は今回AIが当てはめた行です。担当者が見るのは ai の行だけで足ります。 確定した ai の行は、対応表に足していきます。

2つ目は、額を文字列で受けることです。 公式の説明では、構造化出力では数値の範囲（minimum・maximum）や文字数の制約は使えないとされています。額は文字列で受け、数値への変換と検算はプログラムの側で行います。

プログラムが規則で付ける印は、次のとおりです。

システムへ連携する

台帳は「案」の行として書き込み、確定の印は担当者が付けます。 確定した行だけが、日本払いの分の計算や税金の精算の材料になります。国内の給与計算システムには、この構成から書き込みません。

人が確認する

1. 印の付いた赴任者を先に見る … allowance_diff と condition_gap の付いた赴任者は、明細の画像と規程の表を並べて確かめます
2. ai の行を確かめる … AIが新しく当てはめた費目が正しいかを見て、正しければ対応表に足します
3. unreadable と ambiguous を確かめる … 画像で読めるなら担当者が入れ、読めなければ現地に照会します
4. 台帳を確定し、照会を送る … 下書きを直して現地の人事に送ります

1件あたり8分を目安にします。 印の無い赴任者は数分、印のある赴任者は規程の表を開いて確かめるので10分を超えます。ならして8分です。

2番目を省かないでください。 対応表が育つほど、翌月の ai の行が減り、確認が軽くなります。

allowance_diff が付いても、すぐに誤りとは限りません。 規程の額を現地の通貨で決めている国と、円で決めて毎月換算している国では、為替の動きだけで差が出ます。許容の幅は国ごとに決め、幅の中の差は印を付けずに台帳の注記に残します。 幅を狭くしすぎると、毎月ほぼ全員に印が付き、担当者は印を読まなくなります。最初の2か月は幅を広めに置き、実際に照会した件数を見ながら狭めます。

例外に対処する

2行目の注意は、この構成の前提にかかわります。 現地法人のある国の明細が英語で出ているかは、委託先しだいです。英語以外の明細が届く国は、最初からこの構成の対象から外します。

記録を残す

• 届いた明細の原本と、置かれた日時・国
• Textract が返した結果の全文（表、キーと値、問い合わせ、信頼度）と JobId
• Claude が返したJSONと、使った指示の版
• プログラムが付けた印と、そのとき使った規程の表・為替レートの版
• 担当者が案を直した記録 … どの行を、何から何に変えたか
• 対応表に足した行と、足した日

4つ目で「規程の表の版」を残すのは、規程が年の途中で改定されるためです。 改定の前の月の支給を、改定の後の表で照合し直すと、正しかった支給に印が付きます。