部門予算の消化状況を毎月点検して、使いすぎと余り、期末の着地見込みを部門へ返す

処理の起点を決める

月次の締めが完了したことを起点にします。会計システムの締め処理が終わった日に、経理から完了の連絡が来る運用であれば、その連絡をきっかけにして構いません。日付を固定すると、締めが遅れた月に未確定の数字で処理してしまいます。

Make のシナリオは、スケジュールで動かします。既定では15分ごとに実行される設定で、一定間隔・1日1回・平日・週次・月次・日付指定・オンデマンドから選べます。この用途では「日付指定」または「オンデマンド」が合います。 シナリオは有効化しないと動かないため、設定後に有効化を忘れないでください。

締めの完了フラグをどこかに置く運用を先に決めてください。 スプレッドシートの1セルでも構いません。「締めが終わったら経理がチェックを入れる」という一手間を入れるだけで、未確定データでの処理を防げます。

入力データを集める

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

実績と予算： 会計システムから月次でエクスポートします。APIがあれば使いますが、CSVの定期エクスポートで十分です。リアルタイム連携は不要です。 見ているのは締めた後の数字です。

発注残： ここが効きます。購買システムの発注残を科目へ割り当てられるかどうかで、この構成の価値が変わります。 発注済みで検収前の金額は、会計上の実績には出ていませんが、実質的に確定した支出です。これを含めない消化率は、実態より低く出ます。

割り当てが難しい場合は、発注時に科目を入力してもらう運用を先に整えてください。 購買依頼の画面に科目の欄がなければ、そこから始める必要があります。

過去2年の月別実績： 科目ごとの執行パターンを読むために使います。「修繕費は10月と3月に集中する」「旅費交通費は4月と10月が多い」といった傾向が、ここから見えます。2年あれば足ります。3年以上さかのぼると、組織変更で部門が対応しなくなります。

科目の性質： 財務部が定義します。35科目を「固定的」「変動的」「随時」の3つに分けるだけです。この分類が、着地の見積もり方を決めます。

AIへ渡す前に整形する

1. 部門の名寄せ … 組織変更で部門コードが変わっている場合、過去の実績を現在の部門へ対応づけます。ここを怠ると、執行パターンが読めません
2. 科目の統合 … 会計システムの科目が細かすぎる場合、管理上の単位へまとめます。1部門35科目で足り、それ以上細かくしても読み手が追えません
3. 発注残の科目割り当て … 購買データの科目コードを会計の科目へ対応づけます。科目が未入力の発注は「未分類」として別に集計します
4. 異常値の除外 … 前年度の未払い計上の戻しなど、一時的な処理を執行パターンの計算から外します。これが混ざると、パターンが歪みます
5. 金額の単位の統一 … 千円単位と円単位が混在することがあります。取り込み時にそろえます

AIに処理させる

計算処理にさせること：

AI（Gemini API）にさせること：

「ずれの理由を断定させない」ことが重要です。 AIが出せるのは候補までです。「9月に発注残が計上されているため、修繕の発生が理由と考えられます」は言えますが、「設備が故障したためです」は言えません。データに書かれていない事情を書かせないでください。

指示内容を固定する

あなたは財務部の予算統制を支援する担当者です。
下の部門について、勘定科目ごとの期末の着地を見積もり、
予算とのずれが大きい科目を指摘してください。

【厳守事項】
- 金額の四則演算をしないでください。下に与えた計算済みの値を使ってください。
  着地の見積もりは、与えられた「単純按分の着地」を基準に、
  執行パターンに応じた補正の割合（例：0.85倍、1.2倍）で示してください。
- 執行パターンは、下の「過去2年の月別実績」に現れている範囲でのみ読んでください。
  一般的な傾向（「年度末は費用が増える」など）で補わないでください。
- ずれの理由は「候補」として書いてください。断定しないでください。
  データに現れていない事情（故障、人員の増減、外部環境）を書かないでください。
- 発注残が着地に与える影響を必ず考慮してください。
  発注残がある科目で「消化率が低いので余裕がある」と書かないでください。
- 部門向けの要点は3〜5行にしてください。
  すべての科目に触れず、注意すべき科目だけを挙げてください。
  注意すべき科目がない場合は「特に注意が必要な科目はありません」と1行で返してください。
- 予算の増額・減額の是非を書かないでください。判断は財務部が行います。

【部門】
{department_context}

【当期の状況（科目別：予算 / 累計実績 / 発注残 / 消化率 / 見込み消化率 / 単純按分の着地 / 経過率）】
{current_status}

【過去2年の月別実績（科目 × 年月）】
{historical_monthly}

【科目の性質（固定的 / 変動的 / 随時）】
{account_nature}

「発注残がある科目で余裕があると書かない」の1行が効きます。 これを入れないと、消化率だけを見て「順調に推移しています」という文が出ます。発注済みで未検収の金額が予算の3割あるのに「余裕がある」と書かれた報告は、読んだ部門長を誤らせます。

「予算の増額・減額の是非を書かない」も必要です。 AIに「補正を検討すべきです」と書かせると、それが独り歩きします。予算の変更は財務部と経営の判断です。

出力形式を固定する

{
  "department_code": "",
  "period": "",
  "accounts": [
    {
      "account_code": "",
      "account_name": "",
      "nature": "固定的 | 変動的 | 随時",
      "pattern_note": "",
      "estimate_multiplier": 1.0,
      "estimated_landing_basis": "単純按分の着地 × estimate_multiplier",
      "variance_direction": "over | under | on_track",
      "variance_reason_candidates": [],
      "confidence": "high | medium | low",
      "attention": true
    }
  ],
  "summary_lines": [],
  "accounts_needing_explanation": [],
  "data_gaps": []
}

Gemini API でJSONを返させる場合、response_format にオブジェクト型を指定して mime_type を application/json にし、schema にスキーマを渡します。スキーマは JSON Schema の一部（string number integer boolean object array など）に対応しています。

estimate_multiplier を返させる形にしている点に注目してください。 AIに着地の金額そのものを計算させず、「単純按分の着地に対して何倍か」という係数だけを返させます。金額は表計算側で掛け算します。 こうすると、AIが桁を間違えても検算で分かります。

data_gaps は、判断に必要なデータが欠けている箇所です。「発注残の科目が未分類のものが3件ある」といった内容が入ります。これが多い部門は、見積もり自体を信用しないという判断ができます。

システムへ連携する

出力から、予算モニタ表をスプレッドシートに作ります。構成は2層にします。

部門サマリー（40行）：

科目明細（1,400行）：

部門サマリーから展開して見る形にします。科目ごとの消化率、着地見込み、ずれの理由の候補、確度が並びます。

部門長への配信は、財務部が確定してから行います。 自動配信はしません。見積もりが明らかに外れている月に、そのまま40部門へ配信されると、この仕組み自体が信用を失います。

会計システムへの書き戻しは行いません。予算の修正は、既存の補正の手続きに従います。

人が確認する

部門へ返す前に、全件を財務部が確認します。

理由は、着地の見積もりが外れる月が必ずあるためです。大型の設備投資、組織変更、想定外の受注。こうした事情はデータに現れる前に財務部が知っていることが多く、AIの見積もりを人が上書きできる形にしておく必要があります。

確認を速くするための設計が効きます。

• 部門サマリーを、着地見込みと予算の差が大きい順に並べる
• confidence が low の部門に印を付ける
• data_gaps に項目がある部門を別に集める
• 前月の見積もりと今月の実績を並べ、見積もりがどれくらい当たったかを毎月見られるようにする
• 発注残の割合が高い科目に色を付ける

4つ目が、この仕組みを育てます。 見積もりの精度を毎月記録しておくと、「この科目の見積もりはよく外れる」という傾向が見えます。そこだけ人が手当てすればよくなります。精度を測らないまま使い続けると、当たっているのかどうか誰も分からないまま形骸化します。

例外に対処する

記録を残す

この記録は、予算統制がどう機能したかの経過になります。

• 取り込んだ実績・予算・発注残の元データ（月ごと）
• 着地の見積もり（係数と計算結果）と confidence
• ずれの理由の候補と、財務部が確定した内容
• 人が見積もりを上書きした場合、その前後の値と理由
• 部門長へ配信した内容と日付
• 部門からの回答

「見積もりと実際の着地の差」を年度末に集計してください。 これがこの仕組みの通信簿になります。科目ごとに精度を見れば、翌年度に手を入れるべき箇所が決まります。

人が上書きした理由も同じく重要です。「大型の受注があったため」という上書きが毎年同じ時期に発生しているなら、その情報をデータとして取り込む余地があるということです。