毎月の資金繰りの計画と実績の差異を科目別に出し、入出金の明細と営業・購買の連絡から理由を拾って、経営会議に出す説明文の下書きを作る

処理の起点を決める

起点は2つあります。 1つ目は月末の予定の明細の保存、2つ目は月初の実績の明細の受け取りです。

1つ目は、Power Automate のスケジュール済みクラウドフローで動かします。 「繰り返し」のトリガーで頻度を月にすると、フローは毎月同じ日に実行されるとされています。月末の日付は月によって変わるため、毎日夜に動かし、翌日が月初かどうかをフローの中で判定して、月末の日だけ保存の処理に進む形にします。開始時刻はタイムゾーンを指定して設定できるので、日本時間で設定します。

2つ目は、実績の明細が SharePoint のライブラリに置かれたことを起点にします。 「ファイルの作成時 (プロパティのみ)」のトリガーで受け、ファイル名から対象の月を読みます。決まった日時に動かす形にはしません。 締めの日は月によって前後し、明細が置かれる前に動くと、空の実績で差異が出てしまいます。

同じ月の明細が置き直されたときは、その月を最初からやり直します。 締めの後に修正の仕訳が入ることがあるからです。やり直したことは確認リストに残し、担当者が直した説明文は上書きせず、新しい下書きを横に並べます。

入力データを集める

質を決めるのは、いちばん上の計画の元データです。 これが無いと、実績と突き合わせる相手が無く、「何が予定されていたか」をAIに推測させることになります。 この構成は、推測させないために計画の元データを残すところから始まります。

前月の説明を入れるのは、「戻る」と言った差異が本当に戻ったかを確かめるためです。 先月「回収が翌月にずれた」と説明した取引が今月入っていなければ、それ自体が今月の説明に書くべき事実になります。

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

突き合わせは、取引先コードと請求の番号の組で行います。 取引先の名前で突き合わせると、「株式会社」の有無や略称で外れます。請求の番号が無い取引（借入の返済、経費の支払など）は、事業部 × 科目 × 取引先で突き合わせます。

予定変更の連絡は、フィルター クエリで絞ってから読みます。 「アイテムを取得」は既定で全件を返す設定になっているので、絞らずに読むと過去の連絡までAIに渡ります。対象の月に関係する連絡だけを読むことで、AIに渡す量と、誤って古い連絡を根拠にする危険の両方が減ります。

AIへ渡す前に整形する

1. 金額の向きをそろえる … 入金はプラス、出金はマイナスにそろえ、差額は「実績 − 計画」で出す
2. 取引を突き合わせ、種類を決める … 下の表の規則で、取引ごとに差異の種類を1つ付ける
3. 行ごとに積み上げる … 事業部 × 科目の行ごとに、種類別の金額の合計を出す
4. 説明が要る行を選ぶ … 差額の絶対値か差異率が社内の基準を超える行と、前月に「戻る」と説明した取引を含む行
5. 根拠の候補を絞る … 1行あたり、金額の大きい順に取引を上位10件まで残す
6. 連絡を取引に結び付ける … 取引先コードと請求の番号が一致する連絡を、その取引の横に置く
7. 説明の付かない差を出す … 行の差額から、種類別に積み上げた金額を引いた残りを「未特定」として出す

2番目の規則が、第1章で書いた「戻る」と「戻らない」の区別の正体です。 timing_delay と timing_advance は翌月以降に戻る差異、amount_diff と cancelled は戻らない差異、unplanned は性質しだいです。この区別を規則で先に決めておくので、AIが「たぶん来月入る」と書く余地がありません。

いちばん下の missing_unexplained が、人に回す行の目印になります。 予定にあった入金が入らず、誰からも連絡が無いということは、遅れているのか、取引そのものに問題が起きているのかが分からないということです。

AIに処理させる

させるのは、規則が出した材料を読んで、経営会議の読み手に伝わる文章にすることです。

AIの判断が入るのは、1行目と2行目です。 どの取引を説明に入れるかと、連絡の自由記述をどう短く言い換えるか。ここは人が書いても迷うところで、書き方をそろえる意味がいちばん大きいところでもあります。

3行目と4行目が、いちばん起きやすい失敗です。 「回収が遅れた」という事実だけを渡すと、AIは読み手を安心させるために「翌月に回収予定」と書き足します。会議でその一文が読まれると、財務部が回収を約束したことになります。

指示内容を固定する

行ごとの説明文を作る指示の例です。

あなたは専門商社の財務部で、資金繰りの計画と実績の差異を経営会議に説明する文章を書く担当者です。
渡された「差異の材料」だけを根拠に、この行の説明文の下書きを作ってください。

【この行について】
事業部：{division}　科目：{account}　対象月：{month}
計画額：{plan_amount}　実績額：{actual_amount}　差額：{variance_amount}

【書き方】
- 説明文は2〜3文、全体で120字以内にしてください。
- 1文目に差額と、主な理由を書いてください。
- 主な理由は、差異の材料の中から金額の大きい順に最大3つまで選んでください。
- 各理由について、それが「翌月以降に戻る差異」か「戻らない差異」かを書いてください。
  戻るかどうかは、材料の variance_type で決まっています。
  timing_delay と timing_advance は戻る差異、amount_diff と cancelled は戻らない差異です。
  unplanned と missing_unexplained は、戻るかどうかを書かないでください。
- 取引先名は、材料に書かれた略称で書いてください。
- 金額は百万円単位、小数第1位までで書いてください（材料に百万円単位の値があります）。

【厳守事項】
- 数字は材料に書かれた値だけを写してください。足し算、引き算、割合の計算をしないでください。
- 材料の variance_type を書き換えないでください。
- 予定変更の連絡に書かれていない理由を書かないでください。
  理由が書かれていない取引は「理由未確認」としてください。
- 「来月には回収見込み」「回復する見通し」など、材料に無い先の見通しを書かないでください。
- 取引先の経営状況や信用についての評価を書かないでください。
- 借入、支払の繰り延べなど、資金の手当てについて書かないでください。
- 説明文とは別に、使った取引の番号を used_items に、
  missing_unexplained と未特定の金額について営業・購買に聞くべきことを questions に書いてください。

【差異の材料】{variance_items}
【予定変更の連絡】{change_notes}
【前月に「戻る」と説明した取引】{prior_month_timing_items}
【説明の書き方の決まり】{style_rules}

「数字を写すだけ」と「計算しない」を両方書いているのは、どちらか片方では足りないからです。 写すように言うだけだと、3つの理由の金額を足して「合わせて12.4百万円」と書きます。その合計は材料のどこにも無い数字で、後で照らしても正しいかどうか分かりません。

金額の単位を材料の側で百万円にそろえて渡すのも、計算を避けるためです。 円単位の明細を渡すと、AIは単位を変えるために割り算をします。単位の変換はフローの側で済ませておきます。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。

{
  "row_id": "",
  "commentary": "",
  "reasons": [
    { "item_id": "", "variance_type": "timing_delay | timing_advance | amount_diff | unplanned | cancelled | missing_unexplained",
      "reason_text": "", "amount_m": 0, "source": "change_note | rule_only" }
  ],
  "reverses_next_month": "yes | no | partly | unknown",
  "used_items": [""],
  "questions": [""],
  "confidence_note": ""
}

構造化出力を使うのは、後段で数字を照らすためです。 Azure OpenAI の構造化出力は、渡した JSON Schema にモデルの出力を従わせる機能です。すべての項目を必須にし、任意の項目は null との組み合わせの型で表す決まりがあり、オブジェクトには additionalProperties: false を付けます。variance_type や reverses_next_month は enum で値を固定できます。

1つ目の理由は、reasons の amount_m と commentary の数字を突き合わせられることです。 フローが commentary から数字を抜き出し、amount_m と行の差額の中にあるかを確かめます。どこにも無い数字が1つでもあれば、その行は確認リストで「数字不一致」の印を付けます。

2つ目は、variance_type を規則の値と照らせることです。 渡した値と返ってきた値が違えば、AIが種類を書き換えたということです。その行は採らず、もう一度作らせます。

3つ目は、source で根拠のあるなしが見えることです。 change_note は営業・購買の連絡に理由が書いてあったもの、rule_only は規則で種類だけが決まり理由が分からないものです。rule_only の多い事業部は、連絡のリストが使われていないことを示します。

注意点として、文字列の長さの上限は構造化出力のスキーマでは指定できません。 maxLength は対応していない語として挙げられています。120字以内は指示で求め、超えたものはフローの側で字数を測って確認リストに印を付けます。

システムへ連携する

会計システムには書き込みません。 この構成が出すのは説明文の下書きまでで、計画の表も直しません。計画の数字を書き換える経路が無いので、誤った下書きが計画そのものを壊すことはありません。

呼び出しの回数にも上限があります。 SharePoint コネクタは接続ごとに60秒あたり600回の呼び出しが上限とされています。120行の下書きを書き込むだけなら届きませんが、明細を1行ずつ読み書きする組み方にすると届きます。 明細はファイルとしてまとめて読み、リストへの書き込みは行単位にとどめます。

人が確認する

人が見る順番を、印で決めます。

1. missing_unexplained と「未特定」のある行 … questions の文面をもとに、営業・購買へ聞きます。答えは予定変更の連絡リストに書いてもらい、その行だけ作り直します
2. 「数字不一致」と字数超過の印がある行 … 説明文を直します。多くは合計を書き足したものです
3. rule_only が多い行 … 理由が「理由未確認」のままでよいかを決めます
4. それ以外の行 … 流し読みで確かめ、確定にします
5. 総括 … 確定した行から作った下書きを直し、経営企画部へ渡します

1番目の聞き取りは、今までと違って質問が具体的です。 「A社の5月末の回収予定12.0百万円が入っていません。理由と入金の見込み日を教えてください」という形で聞けます。今までのように「この差異の理由は」と漠然と聞くより、返事が早く返ります。

4番目を流し読みにできるかが、第10章の時間を決めます。 規則で種類が決まり、連絡に理由が書かれ、数字も合っている行は、読んで違和感が無ければ確定にします。 すべての行を一から書き直す運用にすると、時間はほとんど減りません。

例外に対処する

1行目は、運用の初月にほぼ必ず起きます。 月末の保存のフローが動いていなかった、書き出しの権限が切れていた、という理由です。このときに全行を「理由不明」として下書きを作ると、経営会議の資料が「理由不明」で埋まります。 止めて知らせるほうが安全です。

記録を残す

• 月末に保存した計画の元データ（月ごとに別のファイルとして残す）
• 実績の明細と、置かれた日時・置き直しの履歴
• 突き合わせの結果（取引ごとの種類と、行ごとの積み上げ）
• AIに渡した材料と、返ってきたJSONの全文
• 数字の照合の結果と、付いた印
• 担当者が直す前と直した後の説明文
• 営業・購買への聞き取りの内容と、その答え

計画の元データを月ごとに残すのは、後から説明を問い直されたときのためです。 経営会議で「3か月前に戻ると言った差異は戻ったのか」と聞かれたとき、当時の予定と当時の説明が残っていれば、その場で答えられます。