グループ会社から届く資金の申請メールから金額・時期・使途・返済の予定を読み取り、グループの資金計画表に転記して、規程の上限を超える申請を財務担当に示す

処理の起点を決める

財務部の共有メールボックスに、件名に「資金申請」を含むメールが届いたことを起点にします。 子会社には、件名の先頭に「【資金申請】」と会社コードを付けて送ってもらいます。件名の決まりが無いと、子会社からの普通の問い合わせまで申請として読むことになります。

添付は、トリガーで一緒に取らずに、Get Attachment (V2) で取ります。 コネクタの説明では、トリガーで添付を含める設定にすると、添付のある多くのメールが同時に届いたときに添付のダウンロードで時間切れになることがあるとされ、添付を含めずに Get Attachment (V2) で取る方法が示されています。

取りこぼしに備えて、毎朝8時に別のフローで突き合わせます。 前日に共有メールボックスに届いた「【資金申請】」のメールと、資金計画表のリストにある申請のメールの識別子を比べ、リストに無いものを本体のフローに回し直します。 月末の集中日に1件落としても、翌朝には拾えます。

入力データを集める

質を決めるのは、規程の上限のリストです。 資金管理規程の別表を、区分ごとに数字の列で持たせます。規程の文書をそのままAIに渡して「上限はいくらか」と読ませる作りにはしません。 規程を改定したときは、このリストを直すだけで判定が変わります。

申請中の行を足して見るのが、第3章の（b）への答えです。 同じ会社から月に2件届いたとき、2件目の比較には、1件目の申請中の金額が自動で入ります。

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

リストの読み取りは、すべて SharePoint コネクタの Get items で、OData のフィルター クエリで絞ります。 書き込みは Create item で行い、財務担当の「確認済み」と、実行後の「実行済み」は Update item で状態を変えます。

社内のレートは、申請を受けた月のものを使います。 実行の希望日が翌月でも、比較の時点では受けた月のレートで直し、どの月のレートで直したかを行に残します。 決裁の時点でレートが動いていれば、決裁の資料を作るときに直し直します。比較の目的は、上限に近い申請を早く見つけることで、円に直した金額を確定させることではありません。

AIへ渡す前に整形する

1. 件名の確認 … 「【資金申請】」と会社コードがあるかを見ます。無ければ申請として扱いません
2. 送り主の確認 … 子会社の一覧で、その会社の申請してよい担当のアドレスかを確かめます。違えば読まずに財務担当へ回します
3. 添付の確認 … PDF・画像以外の添付（表計算のファイルなど）は、プロンプトに渡さずに財務担当へ回します
4. 本文の整理 … 引用された過去のやり取りと署名を除き、今回のメールで新しく書かれた部分だけを残します
5. 同じ申請の再送の確認 … 同じ会社・同じ金額・同じ希望日の行が直近にあれば、「再送の疑い」として印を付けます

2番目を省かないでください。 資金の申請は、なりすましのメールで振り込ませる手口と同じ形をしています。 登録の無いアドレスからの申請は、内容を読む前に人へ回します。

3番目は、プロンプトの入力の制限によるものです。 ドキュメント入力は通常 PNG、JPG、JPEG、PDF に限られ、Word・Excel・PowerPoint のファイルは、プロンプトの設定でコード インタープリターを有効にしたときに対応するとされています。最初はPDFにそろえてもらうよう、子会社に頼みます。

AIに処理させる

させるのは、本文と申請書から決まった項目を拾い、書かれていない項目を「不明」と示すことだけです。

「来月末」を日付にさせないのは、どの月の末かの基準がメールの受信日か申請書の日付かで変わるからです。 書かれたまま写させ、日付に直すのはフローの式で、受信日を基準に行います。 直した結果は、元の文と並べて計画表に残します。

4行目が、いちばん起きやすい失敗です。 「運転資金として」とだけ書かれた申請を渡すと、AIは「売掛金の回収により返済」とそれらしい返済の予定を書きます。その瞬間、子会社に問い合わせるべき不足が消えます。

指示内容を固定する

あなたは親会社の財務部で、グループ会社から届く資金の申請を受け付ける担当です。
メールの本文と申請書を読み、決まった項目を拾ってください。
書かれていないことを推測で埋めないでください。

【拾う項目】
- request_type：新規の借入 / 期日延長 / 返済の変更 / 不明
- amount と currency：書かれた金額と通貨
- desired_date_text：実行の希望日として書かれた文をそのまま
- purpose_text：使途として書かれた文を60字以内で
- purpose_category：運転資金 / 設備資金 / 借入の返済 / その他 / 不明
- repayment：返済の期日、回数、返済の原資
- original_due_date：期日延長の場合の元の期日

【厳守事項】
- 記載が無い項目は「不明」としてください。他の記載から推し量って埋めないでください。
- 返済の予定が書かれていないときに、回収や利益から返すと推測して書かないでください。
- 金額は書かれたとおりに返してください。単位（億・千円・百万円）を数字に直すときは
  amount_text に元の書き方も残してください。
- 本文と申請書で金額・日付が違うときは、両方を conflicts に入れてください。
  どちらが正しいかを選ばないでください。
- 「来月末」「月内」などは日付に直さず、desired_date_text にそのまま写してください。
- 外貨を円に直さないでください。
- 規程の上限を超えるか、貸し付けてよいかの意見を書かないでください。
- 資金の申請ではない書類・メールと判断したときは、項目を拾わず document_type に種類を書いてください。
- 回答に JSON マークダウンを含めないでください。

【メールの受信日】{received_date}
【メールの本文】{mail_body}
【申請書】{application_pdf}

「両方を conflicts に入れ、どちらが正しいかを選ばない」を書かないと、本文の金額か申請書の金額のどちらかを黙って選びます。 選ばれたほうが正しい保証はありません。食い違いがあること自体が、子会社に確かめる理由です。

プロンプトの温度は既定の0のまま使います。 公式の説明では、温度は0から1の範囲で、低いほど予測可能な出力になるとされています。同じ申請書の読み取りが実行のたびに変わらないことを優先します。

出力形式を固定する

次の形のJSONで受け取ります。 プロンプトの出力を JSON にし、形式をカスタムで保存します。

{
  "document_type": "funding_request",
  "company_code": "SG03",
  "request_type": "新規の借入",
  "amount": "2500000",
  "amount_text": "USD 2.5 million",
  "currency": "USD",
  "desired_date_text": "来月末",
  "purpose_text": "",
  "purpose_category": "運転資金",
  "repayment": { "due_text": "", "installments": "", "source": "不明" },
  "original_due_date": "",
  "conflicts": [ { "field": "amount", "mail": "", "document": "" } ],
  "missing": [ { "field": "repayment.source" } ]
}

JSONで受け取る1つ目の理由は、フローの式で計算に回せることです。 amount と currency を社内のレートで円に直し、残高と申請中の分を足して、区分ごとの上限と比べます。 比較の結果は、次の3つの印になります。

2つ目は、missing と conflicts で問い合わせの先が決まることです。 どちらかに要素があれば、計画表の行に「要問い合わせ」の印を付け、何が足りないか、何が食い違うかを Teams のメッセージに並べます。 返済の予定が「不明」なら、期間の上限の比較はできないので、それも印に出します。

3つ目は、形式が変わらないことです。 公式の説明では、プロンプトを保存すると形式が固定され、フローで使うときは保存された形式が使われるとされています。missing と conflicts をキーを持つ要素の配列にしているのは、キーの無い配列の形式がサポートされないためです。

システムへ連携する

子会社へは何も送りません。 受付の返信も、問い合わせも、財務担当が書いて送ります。送り主の確認を通った申請でも、返信を自動にすると、なりすましのメールに「受け付けました」と返すことになります。

貸付の実行の仕組みと会計システムにも書き込みません。 この構成が出すのは計画表の「申請中」の行までで、貸付を実行するのは決裁の後の別の手順です。

人が確認する

財務担当は、届いた申請のすべてについて、計画表の行を申請書と照らして「確認済み」にします。 ただし、時間をかけるのは印の付いた申請です。

1. 印の無い申請は、金額・通貨・希望日・返済の期日の4つを申請書と照らす … 一致していれば「確認済み」にします
2. conflicts のある申請は、子会社に確かめる … 本文と申請書のどちらが正しいかを聞きます
3. missing のある申請は、足りない項目を問い合わせる … 返済の予定が無い申請は、規程上は受け付けない旨も伝えます
4. 上限超過の申請は、決裁の資料に回す … 超過の印と、比較に使った残高・レート・上限を資料に添えます
5. 送り主の確認で回ってきたメールは、電話で子会社に確かめる … メールの返信では確かめません

1番目の4項目を省かないでください。 印が無いことは、規程の上限を超えず、項目がそろっているということで、読み取りが正しいということではありません。桁の読み違いは、印の無い申請の中に紛れます。

5番目は、メールで確かめると、なりすましの相手に確かめることになるからです。 子会社の一覧に、担当の電話番号の列を持たせておきます。

例外に対処する

上の3行で、例外のほとんどを占めます。 どれもAIの精度ではなく、申請の送り方の決まりの問題です。 子会社向けの申請の手引きに、件名の書き方、PDFで送ること、送ってよい担当の登録を1枚にまとめて配ります。

記録を残す

• 申請のメールの受信日時、送り主、件名、本文と申請書の原本
• プロンプトが返した JSON の全文
• 比較に使った数字（残高、申請中の分、社内のレート、区分の上限）と比較の結果
• 計画表の行の状態の変化（申請中、確認済み、要問い合わせ、実行済み、取り下げ）と、変えた人と日時
• 財務担当が読み取りを直した項目と、直す前の値

3つ目の「比較に使った数字」を残すのは、決裁の場で「なぜ超過なのか」を説明するためです。 残高もレートも日々変わるので、判定したときの数字が残っていないと、同じ計算を後からやり直せません。

5つ目は、読み取りの癖を見つけるためです。 特定の会社の申請書で同じ項目が毎回直されているなら、申請書の書式か指示の書き方を直す材料になります。