海外の仕入先から届く英文の支払督促と入金確認のメールを訳し、買掛金と送金の記録に照らして英文の回答案を作る

処理の起点を決める

共有メールボックスに新しいメールが届いたことを起点にします。 Office 365 Outlook コネクタの「共有メールボックスに新しいメールが届いたとき (V2)」で、財務部の共有メールボックスを監視します。1日1回まとめて処理する形にはしません。 督促のメールは、返事が遅れるほど2通目が早く来ます。

添付ファイルは、トリガーでは取らないようにします。 コネクタの既知の問題として、新着メールのトリガーで添付を含める設定にすると、添付の多いメールが同時に届いたときにタイムアウトすることがあり、添付を含めずに「添付ファイルの取得 (V2)」アクションで別に取る回避策が示されています。このアクションは共有メールボックスのアドレスを指定できます。未払いの一覧が付いたメールは添付が大きくなりがちなので、最初からこの形にします。

フローに入れるメールを絞ります。

1. 差出人のドメインが、仕入先マスタに登録されたドメインか
2. 件名か本文に、payment・remittance・invoice・overdue・statement などの語があるか
3. 自動返信（不在通知など）でないか

1番目に当たらないメールも捨てません。 登録外のドメインから支払の話が来ることは、それ自体が詐欺の兆しになりうるからです。回答案を作らない「登録外」の区分に入れ、担当者が見ます。

入力データを集める

質を決めるのは、送金の記録の「対象の請求書番号」です。 1回の送金で複数の請求書をまとめて払っていると、送金の明細からはどの請求書の分か分かりません。送金のときに対象の請求書番号を記録に残す運用が無いと、「支払済み」かどうかを機械的に決められません。

回答履歴を持つのは、第3章の（a）を止めるためです。 同じ請求書について2回目の問い合わせが来たら、前回いつ何を答えたかを確認の一覧に並べます。

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

請求書番号は、仕入先コードと組にして引きます。 仕入先が振る請求書番号は、別の仕入先の番号と重なることがあります。番号だけで引くと、別の会社の請求書の状況を返信に書くことになります。

請求書番号の表記ゆれは、引く前に整えます。 「INV-2026-0815」「INV20260815」「No. 2026/0815」のように、同じ番号が書き方を変えて届きます。記号と空白を除いた形で引き、当たらなければ表記を変えずに「未受領」とし、人の確認に回します。

AIへ渡す前に整形する

1. 引用部分を除く … 返信の繰り返しで下に付いた過去のメール本文を切り離し、最新の本文だけを渡す
2. 署名を除く … 差出人の署名と、定型の免責文を除く
3. 添付を文字にする … 表計算のファイルは表として、PDFは文字として取り出す
4. 口座番号を伏せる … 本文と添付に口座番号・IBAN・SWIFTコードらしき文字列があれば、伏せ字にし、その事実だけを印として残す
5. スレッドをまとめる … 同じスレッドのIDで24時間以内に届いた続きのメールは、1件にまとめる
6. 登録外のドメインを分ける … 仕入先マスタに無いドメインは、AIに回答案を作らせない区分に入れる

4番目が、この構成でいちばん大事な前処理です。 口座の番号そのものは、問い合わせに答えるのに要りません。一方で、口座の情報が書かれていること自体は、振込先の変更の依頼である可能性を示します。 伏せ字にしたうえで「口座の情報あり」の印を付け、次の段階の判定に使います。

AIに処理させる

AIは2回呼びます。 1回目は訳と取り出し、2回目は回答案の作成です。あいだに、フローが記録を引いて状況を決める段階を挟みます。

1回目にさせること：

フローが決める状況：

2回目にさせること： 状況の一覧を受け取り、請求書ごとに英文で答える回答案を作ります。paid なら送金日・送金額・参照番号を、scheduled なら支払予定日を書きます。overdue ・ partially_paid ・ on_hold ・ not_received は、事実だけを書き、理由や約束は書かずに「確認して改めて連絡する」とします。

3行目の「差額の理由を書かない」は、起きやすい失敗です。 外貨の送金では、差額の多くは銀行の手数料か為替に見えます。AIはもっともらしい理由を書きますが、実際には検収の差異で一部を保留していることがあります。 理由を書くのは、経理部が確かめてからです。

指示内容を固定する

2回目（回答案の作成）の指示の例です。

あなたは商社の財務部で、海外の仕入先からの支払の問い合わせに英文で返信する担当者です。
渡された「照合の結果」だけを根拠に、返信の案を英語で書いてください。

【書き方】
- 仕入先の問い合わせに対し、請求書ごとに1段落で答えてください。
- status ごとに、次の情報だけを書いてください。
  - paid ............ 送金日、送金額と通貨、送金の参照番号
  - scheduled ....... 支払予定日
  - partially_paid .. 送金日、送金額と通貨、参照番号。差額があることだけを書く
  - overdue ......... 請求書を確認したことと、社内で確認して改めて連絡すること
  - on_hold ......... 社内で確認中であることと、改めて連絡すること
  - not_received .... その請求書番号が当社の記録に見当たらないことと、写しの送付の依頼
- 丁寧で簡潔な業務の英文にしてください。

【厳守事項】
- 照合の結果に無い日付・金額・参照番号を書かないでください。
- 支払予定日が照合の結果に無い請求書に、支払の時期を書かないでください。
- 差額の理由（手数料、為替、値引きなど）を推測して書かないでください。
- 支払を早める、今週中に払うなどの約束を書かないでください。
- 遅れについての謝罪は一文までにし、責任を認める表現を使わないでください。
- 口座の情報や振込先について触れないでください。
- 日付は「15 August 2026」の形で、金額は通貨の記号ではなく通貨コードを付けて書いてください。
- 返信の案とは別に、その日本語の訳を付けてください。

【仕入先の名称】{vendor_name}
【問い合わせの要点】{summary_ja}
【照合の結果】{match_results}

「照合の結果に無い日付を書かない」を2か所に分けて書いているのは、支払予定日がいちばん埋められやすいからです。 督促に答える文を書かせると、AIは相手を安心させる一文として「近日中に」「今月末までに」と書きます。書かれた日付は、相手にとって支払の約束です。

日付の書き方を決めているのは、日と月の順が国によって違うためです。 「08/09/2026」は、相手によって8月9日にも9月8日にも読めます。月を英語の語で書けば、読み違いが起きません。

日本語の訳を付けさせるのは、英文を書けない3名が確認できるようにするためです。 回答案が照合の結果どおりかを、日本語で確かめられます。

出力形式を固定する

1回目は次の形で受け取ります。

{
  "translation_ja": "",
  "summary_ja": "",
  "inquiry_type": "payment_reminder | remittance_confirmation | invoice_query | bank_detail_change | other",
  "invoices": [
    { "invoice_no": "", "amount": 0, "currency": "", "vendor_due_date": null, "vendor_claim": "" }
  ],
  "mentions_bank_details": false
}

2回目は次の形です。

{
  "reply_en": "",
  "reply_ja": "",
  "invoices_answered": [
    { "invoice_no": "", "status": "paid", "dates_used": ["2026-08-15"], "amounts_used": [12500.00], "refs_used": [""] }
  ]
}

1つ目の理由は、2回目の dates_used ・ amounts_used ・ refs_used で照合できることです。 回答案に使った日付・金額・参照番号を別の欄に書き出させ、フローがそれを照合の結果と突き合わせます。1つでも照合の結果に無い値があれば、回答案に印を付けて人の確認を強めます。

2つ目は、Azure OpenAI の構造化出力の制約に合わせやすいことです。 構造化出力では、すべての項目を必須にし、additionalProperties を false にする必要があります。任意の項目は null との組み合わせの型で表します。vendor_due_date を null にできるのは、仕入先が期日を書いていないメールがあるからです。スキーマは合計100個までの項目と5段までの入れ子に収めます。

3つ目は、種類と状況を決まった語で受け取れることです。 enum で選択肢を固定しておけば、bank_detail_change の判定をフローの条件分岐でそのまま使えます。文字列の長さや形式を指定するキーワードは使えないため、日付の形式はフローの側で確かめます。

システムへ連携する

書き込むのは下書きと確認リストだけです。 会計システムにも送金の記録にも書き込みません。コネクタには接続ごとに60秒あたり300回の呼び出しの上限があります。 月初に督促がまとめて届いても、この構成の呼び出しの数なら収まります。

人が確認する

全件を担当者が確かめて送ります。見る順と深さを状況で分けます。

1. bank_detail_change と登録外のドメインを最初に見る … 回答案はありません。メールに返信せず、登録済みの電話番号で仕入先の担当者に確かめる手順に回します
2. overdue ・ partially_paid ・ on_hold は経理部と確かめる … 遅れや差額の理由を確かめてから、回答案に書き足して送ります
3. not_received は請求書の受け取り漏れを疑う … 受領の窓口に届いていないかを確かめてから送ります
4. paid と scheduled は日本語の訳と照合の結果を見比べて送る … 照合の印が付いていなければ、多くはそのまま送れます

1番目は、どれだけ急いでいても省きません。 振込先の変更の依頼に、メールの返信で確かめるのは意味がありません。そのメールを送ってきた相手が、本物の仕入先とは限らないからです。

目標は、300件をならして1件6分です。 paid と scheduled だけのメールは数分で送れ、overdue や差額のあるメールは経理部とのやり取りを含めて10分以上かかります。

例外に対処する

上から3行目と4行目が、支払済みを誤って伝える経路です。 送金はしたが対象の請求書番号が記録に無い、送金の通貨が違う。どちらも paid に見えますが、機械的には決められません。 迷うものはすべて「要確認」へ寄せます。

記録を残す

• 受け取ったメールの本文・差出人・受信日時と、スレッドのID
• 1回目のAIの出力（訳、種類、請求書の一覧）
• 請求書ごとの照合の結果と、そのとき参照した買掛金と送金の記録の値
• 2回目のAIの出力（回答案、使った日付・金額・参照番号）と、照合の印
• 担当者が直した後の送信文と、送信した日時
• bank_detail_change と登録外のドメインのメールについての、確認の結果

3つ目で「そのときの記録の値」を残すのは、記録が後から変わるためです。 支払予定日は変わり、保留は解除されます。当時の記録が残っていないと、なぜその日付を返信に書いたのかを後から説明できません。

5つ目は、次の問い合わせのための記録です。 同じ請求書の2回目の問い合わせで回答履歴を並べるとき、AIの回答案ではなく、実際に送った文を比べます。