グループ会社への貸付の残高と利率から毎月の利息を計算し、各社への利息請求の通知文を下書きして、財務の責任者の承認に回してから送る

処理の起点を決める

毎朝9時に動く Recurrence のトリガーを起点にし、その日が第2営業日のときだけ先へ進めます。 Recurrence で頻度を月にすると、毎月同じ日付に動くとされています。第2営業日は月によって日付が変わるので、毎日動かして営業日のリストで判定します。 タイムゾーンは日本時間にします。

先へ進む前に、基準金利が入っているかを確かめます。 変動金利の契約がある限り、前月の基準金利が基準金利のリストに入っていなければ計算できません。入っていなければ計算を始めず、Teams で財務担当に知らせ、翌日にもう一度確かめます。 古い基準金利で計算して請求するより、1日遅れるほうがずっと軽く済みます。

第2営業日の判定は、営業日のリストで「今月の営業日を数えて2番目か」を見るだけです。 年末年始や大型の連休の後は、第2営業日が月の5日以降になることもあります。請求の時期を日付で決めず営業日で決めておくと、連休の月に慌てずに済みます。

期中の動きの記録も、同じ時点で確かめます。 前月中の返済・追加の貸付・利率の改定は、財務担当が会計の入出金と照らしてリストに入れ、月末の締めの後に「前月分 確認済み」の印を付けます。 印が無ければ、基準金利と同じく止めて知らせます。

入力データを集める

質を決めるのは、台帳の「日数の数え方」と「端数の処理」の列です。 1年を365日とするか、初日を数えるか、円未満を切り捨てるか。契約書に書かれた定めを、契約ごとに列として持たせます。 ここが担当の記憶に頼っている限り、計算をフローに移せません。

期中の動きは、AIへの入力にも使います。 計算に使うだけでなく、通知文の「期中の動きの説明」の材料として、日付と種類と金額をそのまま渡します。

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

リストは、SharePoint コネクタの Get items で読みます。 期中の動きは、Filter Query で前月の日付の範囲に絞って取ります。台帳は60行ほどなので全件を取り、状態が「完済」の契約は前月中に完済したもの以外を外します。

利息はフローの式で計算します。 契約ごとに、前月の初日から末日までを期中の動きの日付で区切り、区間ごとに「残高 × 利率 × 区間の日数 ÷ 1年の日数」を計算して足し合わせます。 端数の処理は、台帳の列の定めに合わせて最後に1回だけ行います。

米ドル建ての貸付は、米ドルのまま計算し、米ドルで請求します。 円に直すのは会計の計上の側の仕事で、この構成では為替の換算をしません。1年の日数を360日とする契約が混ざることもあるので、日数の数え方の列は通貨にかかわらず契約ごとに持ちます。 明細の表の金額の桁と小数の扱いも、通貨の列で切り替えます。

返済の日を、前の区間に入れるか後の区間に入れるかは、契約の定めで決まります。 ここを契約ごとに確かめないまま式を組むと、1日分の利息がずれます。最初の月は、フローの計算と財務担当の手計算を全件で照らします。

AIへ渡す前に整形する

1. 基準金利と期中の動きの確認 … 前月分がそろっていなければ止めます
2. 変動金利の契約の利率を決める … 基準金利に上乗せの幅を足し、契約の利率の列とは別に「今月の適用利率」として持ちます
3. 区間に分けて計算する … 上の表のとおりに計算します
4. 前月と比べる … 契約ごとに、前月の利息額との差を計算します。期中の動きも利率の改定も無いのに差が大きい契約に印を付けます
5. 会社ごとにまとめる … 契約を貸付先ごとにまとめ、明細の表と合計を作ります
6. AIに渡す材料を作る … 会社名、言語、対象の月、契約番号の一覧、期中の動き、利率の改定の有無を渡します。金額は渡しません

6番目で金額を渡さないのが、この構成の安全装置です。 AIが金額を知らなければ、文の中に金額を書きようがありません。金額の表はフローが後から差し込みます。

4番目の印は、計算の誤りに気づくためのものです。 日数の数え方の列が空だった、期中の動きの日付を入れ間違えた、という誤りは、前月との差で見えることが多いからです。

AIに処理させる

させるのは、会社ごとの通知文の文章を組み立てることだけです。

期中の動きの説明が、AIに任せる価値のいちばん大きいところです。 動きの組み合わせは会社ごと・月ごとに違い、定型の文では書き切れません。日付と種類だけを材料に、子会社の経理が読んで分かる文にします。

2行目を外すと、請求の通知が詐欺の入口になりえます。 振込先の口座がAIの出力に含まれる構成では、入力に紛れた文や誤りから口座が変わる余地が残ります。振込先はフローが定型で差し込み、AIの文には一切出させません。

指示内容を固定する

あなたは親会社の財務部で、グループ会社への貸付の利息を請求する
通知文の下書きを作る担当です。

【入力】
- company：宛先の会社名と担当部署
- language：ja または en
- target_month：対象の月
- loans：契約番号の一覧
- events：期中の動き（契約番号、日付、種類）
- rate_changed：利率の改定があった契約番号の一覧

【書くもの】
subject、opening、body、event_notes、closing を作ってください。
明細の表を入れる位置には {{DETAIL_TABLE}}、
振込先の文を入れる位置には {{PAYMENT_INFO}} を、それぞれ1回だけ書いてください。

【厳守事項】
- 金額、利率、日数、残高の数字を一切書かないでください。
  数字は {{DETAIL_TABLE}} に入ります。
- 振込先の銀行名や口座番号を書かないでください。{{PAYMENT_INFO}} に入ります。
- event_notes は events にある契約だけについて、日付と種類を1文ずつ書いてください。
  events に無い動きを推測して書かないでください。
- 利息の減免、猶予、支払期日の変更に触れないでください。
- 税金について書かないでください。
- language が en のときは英語で、ja のときは日本語で書いてください。
- 回答に JSON マークダウンを含めないでください。

【入力】{payload}

「数字を一切書かない」は、日付の数字まで禁じるものではありません。 期中の動きの説明には「9月15日」と書く必要があります。フローの点検では、通貨の記号や「円」「%」と続く数字を探し、日付は対象にしません。

差し込み位置の印を決めておくと、点検が簡単になります。 印がちょうど1回ずつ現れるかをフローで数え、0回や2回のときは下書きを作り直させます。

英語の文面も、同じプロンプトで作ります。 言語ごとにプロンプトを分けると、片方だけ指示を直し忘れます。厳守事項は1か所に置き、言語は入力で切り替えます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "company_code": "SUB-014",
  "language": "ja",
  "subject": "2026年9月分 貸付金利息のご請求",
  "opening": "株式会社〇〇 経理部 御中\n平素より大変お世話になっております。",
  "body": "2026年9月分の貸付金利息につきまして、下記のとおりご請求申し上げます。\n{{DETAIL_TABLE}}",
  "event_notes": [
    { "loan_no": "L-2023-007", "note": "9月15日に一部ご返済をいただきましたので、同日以降はご返済後の残高で計算しております。" }
  ],
  "closing": "{{PAYMENT_INFO}}\nお支払期日までにお振込みくださいますようお願い申し上げます。"
}

event_notes をキーの付いたオブジェクトの配列にしているのは、JSON の出力の決まりのためです。 フィールドのキーの無い JSON 形式の定義はサポートされないとされているので、契約番号と文を組にして返させます。契約番号が付いていれば、events に無い契約について書いていないかをフローで確かめられます。

フローは次の点検をしてから、下書きのリストに入れます。

点検を通った下書きに、フローが明細の表と振込先の定型の文を差し込みます。 明細の表は、契約番号・区間・日数・残高・適用利率・利息額・合計を並べたもので、数字はすべてフローの計算結果です。

システムへ連携する

承認の依頼には、計算の明細を詳細の欄に載せます。 承認のコネクタでは、詳細の欄に Markdown の書式が使えるとされています。通知文とは別に、前月との差の印が付いた契約を詳細の欄の先頭に並べ、部長が先に見るべきところを示します。

承認の記録の時刻は UTC で表示されます。 コネクタの説明で、承認のタイムスタンプは常に UTC で表示されるとされています。請求の記録のリストに書くときは、日本時間に直して書きます。

送付は、財務部の共有メールボックスから行います。 このアクションは、Microsoft 365 の共有メールボックスの機能でのみ動作が想定され、個人のメールボックスから変換したものでは動かないとされています。

人が確認する

人の確認は2段です。 財務担当が計算を、財務部長が文面と計算の両方を見ます。

1. 財務担当：前月との差の印 … 印の付いた契約について、期中の動きと基準金利を見直します。理由の分からない差があれば、承認に回す前に止めます
2. 財務担当：初めての形の契約 … 新しく始まった貸付、初めて利率が改定された貸付は、手計算で1回照らします
3. 財務部長：文面 … 期中の動きの説明が事実と合っているか、宛先が正しいかを読みます。必要なら承認の画面で直します
4. 財務部長：明細 … 詳細の欄の先頭に並んだ、差の大きい契約を見ます

部長が直した文面は、そのまま送られます。 承認の結果の「Accepted text」を送付の本文に使うので、直した後に担当がもう一度手を入れる経路がありません。 承認と送付の版が一致することが、この構成の記録の要です。

部長が却下したときは、コメントの欄に理由を書いてもらいます。 却下の理由は下書きのリストに写し、担当が直して承認を出し直します。却下の理由が「期中の動きの説明が違う」なら記録の側を、「言い回し」ならプロンプトの側を直します。

目標は、60件をならして1件9分です。 動きの無い固定金利の契約は、印が付かなければ数分で済みます。動きのある契約と初めての形の契約に時間を使う配分です。

例外に対処する

AIが止まっても、請求は止めません。 「AI未処理」の会社は、計算の明細はフローが作っているので、担当が文面だけを前月から作れば承認に回せます。 利息の請求が遅れることのほうが、文面が定型になることより重いからです。

記録を残す

• 計算に使った台帳・期中の動き・基準金利の、その時点の値
• 契約ごとの区間・日数・残高・適用利率・利息額と、前月との差
• AIに渡した材料と、AIが返した JSON の全文、点検の結果
• 承認に回した文面、部長が受け入れた文面（Accepted text）、承認者、承認の日時
• 送付した日時、送り先、件名

• 部長が却下した理由と、出し直した下書き

1つ目の「その時点の値」を残すのは、台帳が後から直るためです。 契約の条件を後から直すと、過去の請求がどの条件で計算されたかが分からなくなります。 子会社から問い合わせがあったときも、当時の値で説明できます。

4つ目の承認の記録は、監査で「誰がどの版を承認したか」を示す材料になります。 メールの返信で承認していたころは追えなかった版の対応が、承認に回した文面と受け入れた文面の両方で残ります。 部長が直した箇所も、2つを比べれば分かります。