3表連動財務モデルとは、損益計算書（P/L）・貸借対照表（B/S）・キャッシュフロー計算書（C/F）を一本の論理でつなぎ、売上成長率や粗利率、設備投資額といった前提条件を1か所変えるだけで、3表すべてに自動反映される仕組みのことです。四半期決算報告や中期経営計画の策定、投資家向けプレゼンテーションで「数字が合わない」という事態を防ぐために欠かせない基盤です。
ただし、モデルが壊れるパターンは決まっています。運転資本の符号ミスによってキャッシュフローが狂う（しかもエラーは出ない）、負債スケジュールの循環参照でSheetsが0を返す、誰かが行を挿入したときにセル参照が静かにずれる——この3つです。いずれも対処法はあります。そして、いずれもエラーメッセージを出してくれません。
3表連動モデルが実際にやっていること
P/Lは売上から費用を引いて当期純利益を算出します。C/Fはその当期純利益を起点に、非現金項目と運転資本の増減を調整して「実際に口座に入った・出たお金」を示します。B/Sは特定時点における資産と負債・純資産を記録します。そして、B/S上の期末現金とC/F上の期末現金残高は一致しなければならない——この一文が3表モデルの本質です。
モデルが正しく連動していれば、前提条件タブの売上成長率を変えた瞬間に、EBITDA・フリーキャッシュフロー・期末現金残高がすべてのシートで同時に更新されます。連動が崩れていると、「営業活動は明らかに赤字なのに、なぜ現金が2,000万円増えているのか」と決算説明会で投資家から指摘を受ける事態になります。
2026年現在、Google Sheetsで実務に耐えるタブ構成は以下の通りです。
前提条件 → 損益計算書 → 貸借対照表 → キャッシュフロー計算書 → 負債スケジュール → 検証（Checks）
入力データが会計システムやERPから来る場合は、これらの上流に「生データ（Raw Import）」と「加工済データ（Staging）」タブを置きます。
符号ミス：3表モデルが静かに壊れる場所
ほとんどのモデルが失敗するのは、運転資本の変動処理です。基本ルールはこうです。売掛金の増加は現金の流出（まだ回収できていない）。買掛金の増加は現金の流入（まだ支払っていない）。
間接法で作成するC/F計算書では：
=-(損益計算書!売掛金_期末 - 損益計算書!売掛金_期首)
=+(損益計算書!買掛金_期末 - 損益計算書!買掛金_期首)
どちらかの符号を反転させると、営業キャッシュフローに2,000万円もの架空の利益が生まれます。P/Lにエラーは出ません。B/Sにも警告は出ません。Corporate Finance Institute（CFI）が公開している財務モデリングのベストプラクティスガイドでは、運転資本の符号ミスはLBOモデルやDCF評価における最頻出エラーとして繰り返し挙げられており、数式監査ツールでは検出できない点が特に厄介とされています。
たとえば年間経常収益（ARR）が2億4,000万円のSaaS企業を例にとります。月次解約率1.2%、新規MRR月850万円という前提では、ARRは年間解約の引き抜きが3億4,500万円を超えなければ純増します。C/Fの複雑さは前受収益（Deferred Revenue）から来ます——年間契約で前払いを受けた現金は、P/L上で収益認識される前にキャッシュとして手元にあります。ここの符号を誤ると、年間契約コホートごとに営業キャッシュフローを過小計上し続けることになります。
タブ設計：崩れないモデル構造
最もよくある構造ミスは、すべてを1シートに押し込むか、モデルの数式が生データを直接参照することです。どちらも必ず破綻します。
正しい構造は3層に分けます。
- Raw Import：ERPや会計システムから書き出したデータをそのまま置く。一切手を加えない
- Staging：型変換・重複排除・表記統一を施した、モデルが読み込める状態のデータ
- Modelタブ群：前提条件、P/L、B/S、C/F、負債スケジュール
ERPの書き出しで日付フォーマットがファイル途中から変わることは珍しくありません（会計年度の切り替えタイミングなどで頻発します）。その修正はStagingで完結し、モデルは影響を受けません。Raw ImportはそのままB/S監査の証跡になります。
Stagingタブでは、COUNTIFでルックアップテーブルと照合することで、表記ゆれをモデルに混入させる前に検出できます。売上区分がエクスポートデータ内で10種類以上の表記で存在する場合、以下の数式がそれを捕まえます。
=COUNTIF(有効カテゴリ一覧, A2)
結果が0の行はエラー行としてフラグを立てます。ルックアップと一致しないデータはモデルに入れません。
名前付き範囲はセル参照切れ問題の根本的な解決策です。=損益計算書!C14という参照は、誰かが14行目の上に行を挿入した瞬間にずれます。数式はエラーを出さず、間違った数値を返し続けます。セルは赤くなりません。=当期純利益という名前付き範囲は壊れません。タブをまたぐすべての出力セルに名前をつける30分の初期投資が、後の数時間にわたるデバッグを防ぎます。Google Sheetsでは「データ → 名前付き範囲」から設定できます。
1シート構成と多層構造の比較
| 観点 | 1シートに集約 | Raw / Staging / Model の3層構造 |
|---|---|---|
| 構築の手軽さ | ◎ すぐ始められる | △ 初期設計が必要 |
| 行挿入時の安全性 | ✕ セル参照が静かにずれる | ◎ 名前付き範囲で保護 |
| ERPデータ更新時の影響 | ✕ モデル全体に波及 | ◎ Stagingで吸収 |
| 監査証跡 | △ 元データと加工済みデータが混在 | ◎ Raw Importがそのまま証跡 |
| 複数人での編集 | ✕ 数式破損リスクが高い | ◎ レイヤーが分離されているため安全 |
| 稟議・監査対応 | △ 数字の根拠を辿りにくい | ◎ データの流れが明確 |
中期経営計画の策定や取締役会への報告に使うモデルであれば、構築コストを払ってでも3層構造を選ぶべきです。
負債スケジュールの循環参照
負債スケジュールには避けられない循環参照が存在します。支払利息は負債残高に依存し、負債残高はフリーキャッシュフローに依存し、フリーキャッシュフローは支払利息に依存する（利息は損金算入可能なため、当期純利益を経由してC/Fに影響する）というループです。Google Sheetsはこれを反復計算で処理します。
設定方法：「ファイル → 設定 → 計算」で「反復計算」にチェックを入れ、最大反復回数を100、収束しきい値を0.001に設定します。これにより、Sheetsは循環参照の値が互いに0.001以内に収まるまで最大100回再計算します。負債残高が10億円未満の規模であれば、100回・しきい値0.001の設定は実用上十分に信頼できます。
検証タブに以下の収束チェックを追加してください。
=ABS(負債スケジュール!支払利息_計算値 - 損益計算書!支払利息) < 0.01
FALSEが返る場合、反復計算が収束していません。モデルの構造的な誤りか、しきい値が緩すぎるかのどちらかです。
キャッシュフローの突き合わせ
C/Fの突き合わせは、3表モデルが正しく連動しているかを確認する最も明確なテストです。テンプレートをコピーするのではなく、数式を1行ずつ構築してください。
当期純利益 =損益計算書!当期純利益
＋ 減価償却費・償却費 =損益計算書!減価償却費
－ 売掛金の増減 =-(B/S!売掛金_期末 - B/S!売掛金_期首)
＋ 買掛金の増減 =+(B/S!買掛金_期末 - B/S!買掛金_期首)
＋ 前受収益の増減 =+(B/S!前受収益_期末 - B/S!前受収益_期首)
＝ 営業キャッシュフロー
－ 設備投資（CapEx） =-(前提条件!設備投資額)
＝ フリーキャッシュフロー
＋ 借入実行額 =負債スケジュール!借入実行額
－ 返済額 =-(負債スケジュール!返済額)
＝ キャッシュフロー純増減額
期首現金残高 =前期末現金残高
＋ キャッシュフロー純増減額
＝ 期末現金残高 → B/S!期末現金と一致すること
突き合わせチェックの数式：
=貸借対照表!期末現金 - キャッシュフロー計算書!期末現金残高
ゼロにならない場合、運転資本のどこかに誤りがあるか、財務キャッシュフローの項目が漏れているか、設備投資を二重計上しているかのいずれかです。
支払利息の節税効果（実効税率35%を使用する場合は =支払利息 * (1 - 0.35) でモデル化）は当期純利益を経由して流れます。つまり、負債スケジュール・P/L・C/Fの3つが、利息を税引前で扱うか税引後で扱うかについて一致していなければなりません。符号ミスの大半はこの接合点で発生しています。
検証（Checks）タブ
Checksタブはモデルの状態を一目でわかるようにするためのものです。各行が1つのアサーションを検証します。緑はOK、赤は何かが壊れているサインです。条件付き書式で、TRUEまたは0なら緑塗り、それ以外は赤塗りに設定してください。
主要エラーの大半を検出できる4つのチェックを以下に示します。
B/S整合チェック：
=貸借対照表!資産合計 - (貸借対照表!負債合計 + 貸借対照表!純資産合計) — ゼロになること
キャッシュフロー突き合わせ：
=貸借対照表!期末現金 - キャッシュフロー計算書!期末現金残高 — ゼロになること
利益剰余金ロール：
=貸借対照表!利益剰余金_期末 - (貸借対照表!利益剰余金_期首 + 損益計算書!当期純利益 - 前提条件!配当金) — ゼロになること
収束チェック： 上述の負債スケジュールの数式 — TRUEになること
Checksタブがすべて緑なら、モデルは内部的に整合しています。前提条件の妥当性はまた別の問いですが、少なくとも構造は正しいということです。
まとめ：3表連動モデルが成立する条件
3表連動財務モデルが機能するのは、P/Lの当期純利益がC/Fに正しく流れ、運転資本の増減の符号が正しく、C/F上の期末現金がB/Sと一致し、負債スケジュールが収束している——この4条件が揃ったときです。Checksタブはその証明です。
よくある障害とその対処法をまとめます。
- 運転資本の符号ミス → 数式を書く前に「この変化は現金の流入か流出か」を日本語で書き出す
- セル参照の静かなずれ → タブをまたぐすべての出力に名前付き範囲を使う
- 負債スケジュールの循環参照未解決 → 反復計算を明示的に有効化し、収束チェックを設ける
4つのCheckがすべてパスし、キャッシュの突き合わせがゼロに丸まれば、そのモデルは取締役会資料や稟議書の添付資料として出せる水準です。
入力データが会計システムやERPから来る場合、Raw ImportとStagingタブは省略できません。9万行のエクスポートデータに日付フォーマットの混在や勘定科目名の表記ゆれが含まれていれば、直接参照するだけでモデルは静かに壊れていきます。ModelMonkeyは、タブをまたぐ数式の配線とStagingの検証ロジックをGoogle Sheets上で処理できます。ERPデータをきれいな前提条件セットに整形する作業で特に力を発揮します。
ModelMonkeyのプランを選ぶ — Google SheetsとExcelの両方に対応しています。
よくある質問（FAQ）
Q. 3表連動財務モデルはExcelとGoogle Sheets、どちらで作るべきですか？
A. どちらでも構築は可能ですが、2026年現在、複数人での同時編集・クラウド保存・Apps Scriptによる自動化という観点ではGoogle Sheetsに優位性があります。一方、反復計算の設定はExcelの方が細かく制御できるため、負債スケジュールが複雑な場合はExcelを選ぶケースもあります。社内の標準ツールと監査対応の要件に合わせて判断してください。
Q. B/Sの貸借が一致しないとき、最初に確認すべき場所はどこですか？
A. まずChecksタブのキャッシュフロー突き合わせを確認します。=貸借対照表!期末現金 - キャッシュフロー計算書!期末現金残高 がゼロでなければ、問題は財務キャッシュフローか運転資本の符号ミスです。次に利益剰余金ロールを確認します。この2つがゼロであれば、貸借不一致の原因は資本取引の計上漏れにある可能性が高いです。
Q. 反復計算を有効にするとSheetsが重くなりますか？
A. 最大反復回数100・収束しきい値0.001の設定であれば、通常の財務モデル（行数が数千行以内）では体感できるほどの速度低下はほとんど起きません。ただし、前提条件タブをすべて揮発性関数（NOW()、RAND()など）で埋めると再計算が連鎖して重くなるため、揮発性関数の使用は避けてください。
Q. 名前付き範囲はシートをまたいで機能しますか？
A. はい。Google Sheetsの名前付き範囲はスプレッドシート全体に対して一意に定義されるため、どのタブからでも同じ名前で参照できます。ただし、名前付き範囲を削除したあとに同名で再定義すると、参照しているすべての数式が自動的に新しい範囲を指すことに注意してください。削除前に影響範囲を確認する習慣をつけることを推奨します。
Q. 年度が4月始まりの場合、C/Fのロール計算はどう組めばよいですか？
A. 日本の会計年度（4月〜翌3月）に合わせる場合、期首をQ1（4月）、期末をQ4（翌3月）と明示的に列ラベルで管理するのが最も安全です。前提条件タブに年度開始月=4というセルを設け、OFFSET関数やEDATE関数で動的に期首・期末を参照する構造にすると、年度切り替え時の修正コストを最小化できます。