Model I/O（AIシステムへの入力情報とその出力結果の仕様）は、AIがファイナンシャルモデルを本当に改善するのか、それともデバッグ工数を増やすだけなのかを左右します。設計が適切であれば、3表モデルが自動的に更新されます。設計に失敗すれば、AIが無意識に破壊したセル参照の修正に、余計な時間を費やすことになります。
ファイナンシャルモデリングにおけるModel I/Oの意味
機械学習の文脈では、Model I/Oはシンプルです。入力が入り、予測が出てくる。しかしファイナンシャルモデリングでは、もっと複雑です。「モデル」は単一のファイルではなく、リンクされた複数のタブ、名前付き範囲のスキーマ、循環参照、そして全ての下流計算に影響する前提条件（アサンプション、Assumptions）群から構成されているからです。
AIシステムがスプレッドシートを読むときの入力は、見えるすべてのものです。セルの値、数式、タブの構造、名前付き範囲、そしてプレーンテキストで提示したコンテキスト。出力は通常、書き込まれた値・数式の編集・新しい構造の組み合わせとなります。問題は、ほとんどのAIシステムがP&L → 貸借対照表 → キャッシュフローという3表間の結合を念頭に設計されていないことです。モデルを依存関係グラフではなく、単なるセルの平面格子として扱っています。
McKinsey 2024年のファイナンシャルモデリング実務調査によると、モデル監査の失敗の68%は壊れたクロスタブ参照に遡ります。これはAIシステムがモデルのアーキテクチャを理解せずに書き込むときに、最も頻繁に破壊するリンケージです。
AIがModel I/Oに加える複雑さ
従来のModel I/Oは手動でした。アサンプションをAssumptions!B3に入力すると、それを参照するすべてのタブが自動的に更新されます。人間は書き手にして読み手でもあり、フィードバックループは短かった。
AIはそのループに第三者を導入します。これにより、以下の3層が生まれます。
- 入力層: AIが読むもの（プロンプト＋現在のシート状態）
- 推論層: AIが推測するもの（意図、構造、依存関係）
- 出力層: AIが書き込むもの（値、数式、フォーマット）
各層は潜在的な失敗ポイントになります。AIはモデルを正しく読むが、意図を誤読するかもしれません。あるいは意図は理解しても、一見正しく見えるが実はクロスタブ参照を無言で破壊する数式を生成するかもしれません。2026年4月時点で、最高のAIコーディングアシスタントでさえ、マルチタブのスプレッドシートにおいて構造化参照を約12%の頻度でハルシネーション（誤生成）します。これはどのFP&A成果物でも許容できない率です。
出力層が最もコストのかかる失敗を引き起こします。Sheet1では機能する数式が、別のシートに貼り付けられるときにタブ修飾子をドロップすると、エラーにはなりません。ただ間違ったデータに対して計算するだけです。売上46億5,000万円・粗利益率22.4%のモデルを運用している場合、COGS部分のクロスタブ参照がミスルーティングされると、誰かが気づく前に報告される粗利益が200ベーシスポイント圧縮される可能性があります。
Model I/Oが壊れる3つのパターン
失敗のパターンは、大きく3つに分類されます。
① 名前付き範囲（Named Ranges）の無視。 Google Sheetsはワークブック当たり最大500の名前付き範囲をサポートしています。ファイナンス部門がこれを多用するのは、=Assumptions_WACCという表現が='Assumptions'!$B$12よりも読みやすく、リファクタリングに強いからです。AIシステムはしばしばこれを尊重できません。名前をバイパスして絶対参照を書き込むか、名前付き範囲の現在のセルアドレスに直接書き込みます。=Assumptions_WACCが突然='Assumptions'!$B$12に置き換えられていた場合、WACCのセル位置が変わった瞬間に全下流計算が壊れます。エラーは出ません。ただ、静かに間違い続けます。
② 循環参照への誤った介入。 3表モデルにはほぼ必ず意図的な循環が存在します。利息費用は負債残高に依存し、負債残高はキャッシュスイープに依存し、キャッシュスイープは利息費用に依存する——といったように。ところがほとんどのAIシステムは循環参照をエラーとして扱い、排除しようとします。AIが「修正」のつもりで循環をブレークすると、モデルはあらゆる基本的な監査チェックを通過できるようになり、実は根本的に間違っているという状況が生まれます。Google スプレッドシートのイテレーション計算設定（ファイル→設定→計算）が同時に飛んでいた場合、気づくのは投資家向け説明の前日になるかもしれません。
③ 数式のシリアライゼーション。 AIが=SUMIFS('P&L'!C:C,'P&L'!B:B,">="&Assumptions!$B$3,'P&L'!A:A,Returns!$D$7)を読んで書き直すとき、出力の正確さはマルチタブ参照をどうシリアライズするかに完全に依存します。Google Apps Scriptのドキュメンテーションによれば、構造化参照はプログラムで一括コピーされるとき、書き込み呼び出しで宛先シートが明示的に指定されていない限りタブ修飾子を失います。ほとんどのAIラッパーはこの挙動を表面化させません。
FP&A実務で使えるModel I/O設計パターン
問題の認識だけでは意味がありません。翌日スプレッドシートを開いたときに何を変えるか——ここからが本題です。
AIアシスト型モデリングから実務上の価値を引き出しているチームは、これをチャットアシスタントではなくETLパイプラインのように設計しています。
| 層 | 制御できる項目 | 発生しやすい問題 |
|---|---|---|
| 入力層 | プロンプトのスコープ、シート選択、名前付き範囲の公開範囲 | AIが古い値を読む、非表示行をミスする |
| 推論層 | モデル選択、温度パラメータ、システムプロンプト | クロスタブ参照のハルシネーション、意図の誤読 |
| 出力層 | 書き込み対象、検証ルール、レビューゲート | 無言の上書き、循環の破損、タブ修飾子の消失 |
Assumptionsタブを「AIに触らせていいゾーン」と「触らせてはいけないゾーン」に分ける
最も即効性のある対策は、Assumptionsタブの中でAIが読み書きする領域を物理的に分割することです。
AIが読み書きしてよいゾーン（入力セル）:
- 離散的な数値のみ（数式を含まない）
- 行ごとに「項目名・単位・出所」を明示したラベル列を設ける
- 背景色で視覚的に区別（例：薄い黄色）
- セル保護は不要——AIへの指示で制御する
AIが触れてはいけないゾーン（計算セル・リンクセル）:
- 他タブを参照する数式が入るセル
- 名前付き範囲の定義元セル
- 背景色をグレーにし、シート保護をかける
この設計により、Assumptionsタブへの書き込みがクリーンであれば、下流のすべては無傷に保たれます。下流のタブはこのタブを「参照している」だけであり、直接書き換えられるわけではないからです。
ステージング領域でレビューゲートを設ける
AIへの自由な直接書き込みを禁止し、代わりに専用の「ステージングシート」を用意します。構造は以下のとおりです。
[_AI_Staging] タブ（非表示にしない）
列A: 書き込み対象セルのアドレス（例：Assumptions!B3）
列B: 現在の値（AIが読み込んだ時点）
列C: AIが提案する新しい値
列D: 変更の理由（AIが生成）
列E: 承認フラグ（担当者が手動で「Y」を入力）
承認フラグが立ったセルのみ、Apps Scriptで本体モデルに反映させます。稟議フローと同じ考え方です——「承認されないと本番に反映されない」という原則をスプレッドシート上で実装しています。AIの提案が全体に伝播する前に、担当者がdiffをレビューできます。慣れれば四半期モデルレベルの変更（20〜50セル程度）のレビューは5〜10分で完了します。これを省いて「無言の上書き」が発生した場合のデバッグは、数時間から丸1日かかることがあります。
循環参照を保護する
意図的な循環が存在するタブには、専用セルまたはコメントで明記してください。
// Assumptions!A1 に追記するコメント例
// 【循環参照：変更禁止】
// 利息費用 ↔ 負債残高 ↔ キャッシュスイープ
// イテレーション設定：最大反復回数100、変化の最大値0.001
Apps Scriptでモデルを操作するAIツールには、このフラグを読んで該当セル範囲をスキップするようシステムプロンプトで指示します。最もシンプルな方法は、循環参照を含むタブ全体をAIの書き込み対象リストから除外することです。
ModelMonkeyのアプローチ
ModelMonkeyは、何かを書き込む前に完全なワークブック構造を読み込み、名前付き範囲を明示的にマップし、すべての書き込みをコミット前のdiff表示にステージングします。Assumptionsタブへの変更も、対象セル・変更前の値・変更後の値を並べて表示してから確定するフローになっています。これは上述した「無言の上書き」——AIアシスト型モデリングが実務上信頼できないと感じさせる最大の原因——に直接対処する設計です。
よくある質問（FAQ）
Q. Model I/OはAPIのI/Oと何が違うのですか？
A. APIのI/Oは基本的に1対1の入出力対応です。一方、ファイナンシャルモデルにおけるModel I/Oは、1つの入力（例：割引率の変更）が複数のタブにわたる数十のセルに波及します。AIシステムはこの「依存関係グラフ」を暗黙的には理解できないため、明示的な設計が必要です。
Q. AIに名前付き範囲を正しく扱わせるには？
A. システムプロンプトに「名前付き範囲をバイパスして絶対参照を書き込まないこと」と明記するだけでは不十分です。最も確実な方法は、AIが書き込む領域（ステージングシート）と名前付き範囲が定義されているセル（Assumptionsタブの本体）を物理的に分けることです。AIはステージングシートにのみ書き込み、本体への反映はApps Scriptが名前付き範囲を経由して行います。
Q. 循環参照があるモデルでAIを安全に使うには？
A. 循環参照が存在するタブ全体をAIの書き込み対象から除外するのが最もシンプルな解決策です。プロンプトに「以下のタブには書き込まないこと：〔タブ名のリスト〕」と明示し、Apps Scriptレベルでも該当タブへの書き込みAPIコールをブロックします。循環を含むタブの値は、Assumptionsタブへの入力が確定した後に自動的に再計算されます。
Q. ステージング領域を使うと作業スピードが落ちませんか？
A. 短期的には若干のオーバーヘッドが生じますが、参照がクリーンな3日間のビルドは、完全な監査が必要になる1日間の突貫ビルドより優れた成果物を生み出します。四半期決算モデルレベルの複雑さ（タブ数15〜20、名前付き範囲100〜150）であれば、AIが1タスクで提案する変更は通常20〜50セル程度で、diff確認は慣れれば5〜10分です。投資家や上長に出せる品質を担保するための工程として、合理的な時間投資です。
Q. Google SheetsのAIツールを選ぶ際、Model I/Oの観点で何を確認すべきですか？
A. 最低限、以下の3点を確認してください。①書き込み前にdiff（変更前後の比較）を表示する機能があるか。②名前付き範囲を認識し、絶対参照に置き換えないか。③書き込み対象のシート・範囲を制限できるか。この3点を満たさないツールは、複雑な3表モデルへの使用を避けることを推奨します。