月次決算を D+1 で締めても、稟議残の突合・共通費配賦・KPI データソースの監査という後工程は残る。この 3 業務を AI エージェントに任せた匿名化案件では、数字が合わない原因の 4 件がいずれも AI 以前の構造問題だった。マスタの参照設計、規程と実務運用に分かれた決裁ルート、検算式の不在、要件が曖昧なままの分業である。
締め後に残る 3 業務では、何を先に直すのか
管理会計における「締め後工程」とは、締めた数字を経営報告に耐える形へ仕上げる工程を指し、稟議残の突合・共通費配賦・KPI データソースの監査が中心になる。直す順番は、①マスタの参照構造を「1 操作で過去が壊れない」形にする ②決裁ルートの正本を規程原本と権限委譲文書で確定する ③配賦原資に検算式を常設する ④その上で AI に渡す、である。例外は要件がまだ固まっていない工程で、そこは分業させず 1 体に任せて境界を先に確定させる方が速い。
月次決算そのものを D+1 で締める仕組みは別記事で扱った。だが経営管理の現場では、決算が締まった後にもう一段の作業が残る。稟議の残高が数字と合っているか、共通費の配賦は正しい向きで計算されているか、経営会議に出す KPI の元データは信頼できるか。この 3 つは地味だが、ここでの静かなズレが経営報告の数字を直接歪める。
本記事は、大手 IT 企業のエンタメ事業（グループの経営管理部門が管轄）で、この 3 業務を AI エージェントに監査・再構築させた実装ログにもとづく。出典は匿名化した支援案件の実装ログで、観測主体は当社、観測範囲は対象 3 業務のスプレッドシート群と関連規程、観測期間は 1 四半期。案件が特定されないよう、業種・組織名・実施時期は抽象化し、金額そのものは公開していない。したがって以下は一般則ではなく、この条件下で確認した 4 件の観察である。
落とし穴 1 — マスタの参照構造がそもそも壊れている
四半期切替の 1 セルで過去の紐づけが読めなくなるマスタ設計
稟議番号と予算管理番号を紐づけるマスタに、四半期切替用のセル（当期を示すラベル）が置かれていた。このセルを書き換えると、全行の照合数式（INDEX/MATCH 系の検索式）の参照先が当期側へ一斉に切り替わる。数式そのものは残るが、参照先が当期データに揃うため、過去四半期の対応関係が表示上たどれなくなる。さらに参照タブが 6 段連鎖しているため、途中の 1 段でも列構成が変わると #REF!（参照切れエラー）が下流へ連鎖した。
これは AI が起こした障害ではない。AI エージェントにマスタの整合性チェックを任せる前に、「四半期をまたいでも過去の紐づけが失われない」データの持ち方へ直しておかないと、AI がどれだけ正確に転記しても土台が毎期崩れる。採用したのは、履歴を四半期キー付きの追記型テーブルとして保持し、当期の表示はその上のビューとして分離する構成である。列を増やして期を横に並べる持ち方は、集計と監査の両方を難しくするため採らなかった。
| 症状 | 原因 | 対処 |
|---|---|---|
| 過去四半期の稟議番号がたどれなくなる | 四半期切替セルの書き換えで全行の参照先が当期へ一斉に移動 | 履歴は四半期キー付きの追記型テーブルに保持し、表示はビューへ分離 |
参照タブ 6 段連鎖で #REF! が下流に伝播 | 正本タブの列・タブ構造の変更が下流へそのまま流れる | 正本タブの列構成を変更禁止とし、変更は追加列のみに限定 |
落とし穴 2 — 決裁ルートは「規程原本」と「実務運用」の二層に分かれている
規程を読むだけでは決裁者が確定しない
稟議の決裁ルートを AI に判定させようとして、まず規程原本（PDF）を読み込ませた。ところが規程の文言上は上位本部の責任者との合議が定められているだけで、実際に誰が承認するのかは特定できなかった。実務では金額帯に応じて課長級・部長級へ承認が委譲されており、それは規程本文には現れない運用として存在していた。
ここで注意が要るのは、正本の置き方である。正本は規程原本と正式な権限委譲文書であって、過去の承認実績ではない。過去に承認された事実は、権限委譲が行われた証拠にはならず、規程からの逸脱である可能性を同じだけ含む。したがって実績は「正本と突き合わせて差分を見つけるための材料」として扱い、規程と実績が食い違う箇所は断定せず、規程主管部門・法務・内部監査へ照会する運用にした。AI に一次資料を集めさせても、どれを正本とするかの判断は人間側に残る。
| 情報源 | 位置づけ | 食い違ったときの扱い |
|---|---|---|
| 規程原本・権限委譲文書 | 正本 | これを基準に判定する |
| 過去の承認実績 | 差分検出の材料 | 逸脱の可能性を含むため、単独で正本にしない |
| 改定メモ・関係者の記憶 | 参考（日付が新しくても同じ） | 正本と一致しない限り採用しない |
「一番新しい文書が正しい」とは限らない点にも注意が要る。改定の履歴を遡ると、ある時点のメモが承認実績とも規程原本とも矛盾しているケースがあった。日付の新しさではなく、正本との整合で採否を決める運用にしないと、AI は矛盾した情報のうち最後に読んだものを採用してしまう。
落とし穴 3 — 配賦原資の手貼り転記が「静かなズレ」を生む
検算式がなければ人も AI も同じ転記ミスを繰り返す
共通費の配賦計算では、原資となる金額をスプレッドシートへ手作業で貼り付ける運用が続いていた。月次の系列を 5 か月分並べて突き合わせたところ、直近月だけ集計符号の誤りに起因する差が残っていた。過去 4 か月は 1 円単位で一致していたため、指標定義の違いではなく、その月の転記だけが誤っていたと切り分けられた。差額そのものは非公開情報のため、本記事では金額もその比率も示さない。
厄介なのは、この種のズレが外形上は正常に見えることだ。数式は動いているし、シートはエラーを出さない。差分に気づけたのは、複数月の系列を並べて突合するという作業を、人か AI のどちらかが意図的に行った時だけだった。恒久的な対策は、「配賦原資として貼った値」と「正本データから独立に算出した同じ値」の一致を機械的に判定する式を、貼り付けセルの隣に常設することである。これがあれば、転記の担当が人でも AI でも、次にシートを開いた時点でズレが見える。AI 導入の効果は「ミスをしない」ことではなく「検算を毎回確実に回すこと」にある、という実感がここにあった。配賦側の符号規約と検算式の組み方は配賦計算に監査可能性を組み込む設計で扱う。
落とし穴 4 — 要件が曖昧なまま分業させると検証ループが空転する
境界の定まらないタスクを分割すると検証コストが跳ねる
KPI 監査とダッシュボード構築を複数の AI エージェントに分担させた回では、見積りを大きく超えるトークンと実行時間を費やしながら、肝心の機能が未完成のまま検証ループだけが繰り返された。原因は、ある工程を担当したエージェントの出力形式が後続の期待と食い違い、検証工程がそのズレを検出できないまま同じチェックを回し続けたことにある。最終的に分業を解き、統括役（司令塔となるセッション）が直接実装したところ、1 時間程度で完成した。
| 指標 | 複数エージェントに分担した回 | 統括役が直接実装した回 |
|---|---|---|
| 実行時間 | 100 分超 | 約 60 分 |
| 完成状況 | 未完成（検証ループが継続） | 完成 |
| トークン消費 | 見積りを大幅に超過 | 見積り水準 |
この 2 回は、対象機能・データソース・完了条件が同じで、実行の組み方だけが違う。トークンの超過倍率は、想定値の置き方によって値が変わるため本記事では示さない。ここで残るのは倍率ではなく、**分業に価値があるのは「独立に検証できる作業単位が実在する時だけ」**という判断基準の方である。要件が固まっていない工程を分割すると、成果物ではなく検証コストが増える。
補足 — データソースを切り替える前に、何を全件突合で確認したか
うまくいった例もある。KPI レポートのデータソースを旧集計タブから新集計タブへ切り替えた際は、切替前後で報告済みの数値が 1 セルも変わらないことを全セル突合で確認してから本番へ移した。サンプルチェックではなく全件にしたのは、経営報告に使う数値だからである。
加えて、経営側のレビューで「新しく追加した指標は、既存データから計算し直しているだけではないか」という確認があった。これに対しては、既存指標の単純な再構成では新指標の値を説明できないことを過去の月次データで確認し、あわせて別データソースの取得経路・定義書・更新ログを照合した。再構成できないこと自体は「独立したデータ由来である」ことの証明にはならない（計算式の誤り、粒度差、欠損でも再現不能になる）ため、経路と定義の照合まで含めて初めて説明可能な状態になる。
まとめ — 4 つの落とし穴と、AI を入れる前にやること
| 落とし穴 | AI を入れる前にやること |
|---|---|
| ① マスタの参照設計 | 「1 操作で過去データが読めなくなる」構造を、履歴の持ち方から直す |
| ② 決裁ルートの二層構造 | 正本を規程原本＋権限委譲文書に置き、実績との差は主管部門へ照会する |
| ③ 配賦原資の手貼り | 原資と正本データの一致を判定する検算式を、貼り付けセルの隣に常設する |
| ④ 要件が曖昧なままの分業 | 境界が定まるまでは分割せず、1 体に任せて入出力形式を先に固定する |
次に読む診断チェック — 自社で 7 項目を確認する
締め後工程に AI を入れる前に、次の 7 項目を自社のシートと規程で確認すると、着手順が決まる。
- マスタの期切替セルを実際に書き換えたとき、過去期間の紐づけがそのまま読めるか。
- 参照タブの連鎖が何段あり、どのタブが正本かを担当者が即答できるか。
- 決裁ルートの正本（規程原本＋権限委譲文書）が特定でき、実務運用との差分が一覧化されているか。
- 配賦原資を貼り付けているセルの隣に、正本データから独立に算出した値との一致チェックがあるか。
- 直近 5 か月の配賦原資を並べたとき、定義差では説明できない差が残っていないか。
- 経営報告に使う指標のデータソースを切り替える手順に、切替前後の全件突合が含まれているか。
- AI に任せる工程の入出力形式が文書化され、未完成のまま検証ループが回り続けないための停止条件があるか。
7 項目のうち 3 つ以上が「確認できない」であれば、AI の導入より先に、マスタと検算式の整備に着手した方が結果的に早い。mixednuts では、この締め後工程の設計と実装を 戦略・経営管理支援 として提供している。
FAQ
Q. 稟議管理や配賦計算のような地味な業務に AI を入れる価値はどこにあるか？ A. 価値の中心は作業の代替ではなく、「毎回同じ検算・突合を確実に回すこと」にある。ただし LLM はモデル更新や入力の差で出力が変わるため、「毎回同じ精度」は保証できない。固定ルール・検算式・実行ログと組み合わせ、確認工程を省略しにくくする使い方が現実的。
Q. スプレッドシートの構造欠陥はどう見つけるのか？ A. 「あるセルを 1 つ変更したとき、他のどの行・タブが影響を受けるか」を実際に変更して確認するのが最も早い。期切替やステータス変更など、担当者が頻繁に触る操作から検証すると欠陥が見つかりやすい。
Q. 社内規程は外部の AI サービスにどこまで読ませてよいか？ A. 先に決めるのはセキュリティ条件である。学習利用の有無、データ保持期間、アクセス権と監査ログ、未公表の経営情報・個人情報の取り扱い、閉域または法人契約の可否を確認し、満たせない場合は規程本文を投入せず、匿名化した抜粋や要約に限定する。そのうえで、規程の文言だけでは実務の承認者が特定できないことが多い点も織り込んでおく。
Q. 配賦計算の検算式はどう設計すればよいか？ A. 最小構成は、「配賦原資として貼った値」と「正本データから独立に集計した同じ値」を突き合わせ、一致すれば 0、しなければ差分を表示する式を、貼り付けセルの隣に常設すること。検知できるのは、比較元が別経路・別集計である場合の転記差であり、双方が同じ誤データを参照している場合は検知できない。
Q. 複数の AI エージェントに分業させるかどうかの判断基準は？ A. 独立に検証できる作業単位が実在するかどうか。要件が固まっていない機能開発やダッシュボード構築のように試行錯誤が要る工程は、まず 1 体に任せて入出力形式と完了条件を確定させてから分業を検討する方が、結果的に速い。
Q. データソース移行での「表示が変わらないこと」の確認はどこまで厳密にやるべきか？ A. 経営報告に使う数値であれば、サンプルチェックではなく全セル突合が前提。切替前後のスナップショットを保存しておけば、後から差分の有無を機械的に再現でき、訂正が必要になった場合の説明もできる。
参考文献 / Sources
経営管理・データ整合性:
- Bain & Company: CFOs Funded the AI Revolution. Now They're Joining It. — 財務・経営管理部門への AI 導入で先に整える論点
- Google SRE Book[1] — Monitoring Distributed Systems — 「壊れたら自動で気づける」監視の設計原則
- 12factor.net — Config — 設定と正本データを分離する設計思想
AI エージェント運用:
- Anthropic: Building effective agents — 分業の境界とワークフロー設計
- Anthropic: How we built our multi-agent research system — 複数エージェント運用のコストと失敗モード
関連記事:
知見を、事業の実装へ。
60分の無料相談で、貴社に適した論点と次の一手を整理します。