海外の開発委託先から毎月届く英文のタイムシートと請求書を読み取り、要員ごと・日ごとの工数を契約の単価と上限時間に照らして、超過と請求額の食い違いを支払の前に拾う

処理の起点を決める

受領用の保管先（Amazon S3 のバケット）にPDFが保存されたことを起点にします。 月初に3社から届くたびに動かし、3社分がそろうのを待ちません。 先に届いた委託先から照合が終わり、問い合わせを早く出せます。

保存のたびに Lambda が動き、ファイル名の規則と1ページ目の文字で、タイムシートか請求書かを振り分けます。 委託先には「<委託先コード>_<年月>_TS_<要員>.pdf」「<委託先コード>_<年月>_INV.pdf」の名前で送ってもらうよう、あらかじめ頼んでおきます。名前で決まらないものは1ページ目に「Invoice」の文字があるかで分けます。

分析の開始には ClientRequestToken を付けます。 同じトークンで呼ぶと同じ JobId が返るとされているので、ファイルのハッシュ値を使えば同じPDFを二重に分析しません。 完了の状態は Amazon SNS に届き、2つ目の Lambda が結果を取りに行きます。JobId は7日間だけ有効なので、結果はすぐに保管します。

委託先1社分のタイムシートと請求書がそろった時点で、照合を始めます。 そろったかどうかは、契約の台帳の名簿の人数と、届いたタイムシートの枚数で決めます。

入力データを集める

質を決めるのは、契約の台帳の「要員の別名」の列です。 タイムシートの名前は「Nguyen Van A」、請求書の明細は「A. Nguyen」のように、同じ人の表記が書類によって違います。 別名の列があれば、プログラムで同じ人に寄せられます。

超過の承認の記録も台帳に持たせます。 上限を超える作業を事前に承認していれば、超過は食い違いではありません。承認の記録が無いと、承認済みの超過まで全部問い合わせることになります。

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

タイムシートは GetDocumentAnalysis、請求書は GetExpenseAnalysis で結果を取り出します。

表の列の見出しは COLUMN_HEADER で見分けます。 公式の説明では、表のセルには COLUMN_HEADER（列の見出し）、TABLE_SUMMARY（合計の行）などの種類が付きます。「Hours」「Hrs」「Effort」のように見出しの言葉が委託先ごとに違っても、どの列が見出しかが分かれば、生成AIで同じ名前に寄せられます。

委託先が書いた合計の行は、照合には使いません。 合計の行の数字は委託先の計算で、それが日ごとの行の和と合っているかを確かめるのが、この構成の仕事の1つです。 合計の行は別の項目として取り、プログラムの合計との差を見ます。

請求書の明細は、公式の説明では書式によらず ITEM・QUANTITY・UNIT_PRICE・PRICE の名前で返り、ラベルの原文が LabelDetection、値が ValueDetection に入ります。 時間が QUANTITY に入るか ITEM の文に混ざるかは委託先によるので、そのそろえ直しを生成AIに任せます。

AIへ渡す前に整形する

1. 形式の確認 … StartExpenseAnalysis は JPEG・PNG・PDF を扱うとされています。Excel で届いたタイムシートは PDF にしてから入れます
2. パスワードの確認 … PDF はパスワードで保護されていてはならないとされています。保護されたものは、委託先に保護のない版を頼みます
3. 文字の大きさ … 検出できる文字の高さの下限は15ピクセル（150 DPI で8ポイント）です。表計算から縮小して印刷したタイムシートは、この下限を割ることがあります
4. 期間の確認 … タイムシートの期間が請求の月と合っているかを、ファイル名と「Period」の値で確かめます。前月分が混ざっていれば分けます
5. 名簿との突き合わせ … ファイル名の要員が契約の台帳の名簿に載っているかを先に見ます。載っていなければ、照合の前に needs_human の印を付けます

3番目は、委託先に書式を頼むほうが早く片付きます。 1枚に1か月を収めようとして縮小したタイムシートが多いので、2ページに分かれてよいと伝えます。

AIに処理させる

させるのは、読み取り結果を決まった形の行にそろえることだけです。

時間の書き方をそろえるのが、生成AIにいちばん向いている仕事です。 「7:30」「7.5」「7h30m」「7.30」が委託先によって混ざり、「7.30」が7時間30分なのか7.3時間なのかは、同じ表のほかの行を見ないと決まりません。表の中で書き方が一定しているかを見て決め、一定していなければ ambiguous にします。

指示内容を固定する

あなたは情報システム部門で、海外の開発委託先から届いた英文のタイムシートと
請求書を、照合のための行にそろえる担当です。
渡すのは AWS Textract の読み取り結果（表のセル、キーと値の組、
請求書の明細と標準の項目）だけです。書かれていないことを推測で埋めないでください。

【タイムシートでそろえる行】
- resource_name: 書かれた名前をそのまま写す
- date: YYYY-MM-DD
- hours: 数。"7:30" は 7.5、"7h30m" は 7.5
- task: 作業内容、ticket: チケット番号（無ければ空）

【請求書でそろえる行】
- resource_name, hours, unit_rate, amount, currency

【厳守事項】
- 時間の合計、金額の掛け算、上限との比較をしないでください。
- "7.30" のように、時間と分の区切りか小数かが決められない書き方があるときは、
  同じ表のほかの行の書き方を見て決めてください。決められなければ
  status を ambiguous にし、raw に元の文字列を写してください。
- 時間の欄が空の行は hours を null にしてください。0 にしないでください。
- 委託先が書いた合計の行は rows に入れず、vendor_total に別に写してください。
- 名前の表記をそろえたり、似た名前を同じ人とみなしたりしないでください。
- 週ごとの表で日付が無いときは、週の開始日と曜日から日付にし、
  date_source を derived にしてください。週の開始日が無ければ ambiguous です。
- evidence には、根拠にしたセルの文字列をそのまま写してください。
- confidence は OCR が返した値をそのまま入れてください。

【書類の種類】{doc_type}
【委託先】{vendor_code}
【読み取り結果】{textract_result}

「空の時間を0にしない」を書かないと、空欄が0として入ります。 0と空は合計では同じに見えますが、空はタイムシートの記入漏れで、0は作業しなかった日です。 記入漏れの日を委託先に確かめる理由が、0にすると消えます。

「似た名前を同じ人とみなさない」も同じ理由です。 同じ委託先に同じ姓の要員が複数いることは珍しくありません。寄せるのは台帳の別名の列で、生成AIの判断ではありません。

出力形式を固定する

応答は、Claude API の構造化出力で次の形の JSON に固定します。 公式の説明では、output_config.format に type: "json_schema" とスキーマを渡すと、スキーマに合う JSON が返るとされています。

{
  "doc_id": "V02_202609_TS_017",
  "doc_type": "timesheet",
  "vendor_code": "V02",
  "resource_name": "Nguyen Van A",
  "period": { "from": "2026-09-01", "to": "2026-09-30" },
  "rows": [
    { "date": "2026-09-01", "date_source": "explicit", "hours": 8.0,
      "raw": "8:00", "task": "API bug fix", "ticket": "PRJ-1182",
      "status": "ok", "confidence": 97.8, "evidence": "8:00" }
  ],
  "vendor_total": { "hours": 168.0, "raw": "168:00" },
  "approved_by": ""
}

照合の結果はプログラムが付けます。

JSON で受ける理由は、層を分けられることです。 契約の上限時間や単価が改まっても、保存した行に新しい条件を当て直すだけで、照合をやり直せます。 タイムシートを読み直す必要はありません。

システムへ連携する

会計システムへは書き込みません。 この構成が出すのは照合の結果までで、支払の承認は開発管理の担当と経理が行います。 契約の台帳にも書き込みません。超過の承認の記録を足すのは、承認した人です。

人が確認する

開発管理の担当が開くのは match 以外のものだけです。

1. needs_human を先に見る … 時間が空の日、名簿に無い名前、土日・祝日の作業を、タイムシートの原本で確かめます
2. over_cap の理由を確かめる … 事前の承認が台帳に載っていないだけなら、承認した人に記録を頼みます
3. amount_mismatch の差を確かめる … 単価の違いか、時間の読み違いかを原本で見ます
4. 問い合わせを送る … 下書きを直して委託先の窓口へ送ります。送信は人が行います

3番目を省かないでください。 金額の差の原因が、OCRが「7.5」を「75」と読んだことだった、ということがありえます。問い合わせの前に原本を見るのは、空振りの1通を避けるためです。

目標は、120件をならして1件3分です。 開くのは2〜3割という想定です。それより多い月は、台帳の別名か超過の承認の記録が足りていません。

例外に対処する

4行目と5行目は、契約の変更と書類の流れのずれから起きます。 要員の交代が台帳より先に起きると、名簿に無い人の請求と、タイムシートの無い人の請求が同じ月に出ます。

記録を残す

• タイムシートと請求書の原本と、受け取った日時・委託先
• Textract の結果の全文と JobId
• 生成AIがそろえた行の JSON と、そのときのプロンプトの版
• 照合の結果（sum_hours、cap_check、amount_check、verdict）と、そのとき参照した契約の台帳の内容
• 人が判定を覆した記録 … どの要員を、どの理由で match にしたか
• 問い合わせの日時、委託先の回答、訂正された請求書との対応

4つ目で「そのときの台帳の内容」を残すのは、契約が月の途中で改まることがあるからです。 当時の単価と上限が残っていないと、後から照合の結果を説明できません。