シート・モンキー脱出：AIで財務モデルを自動化する方法

ERPから吐き出されたデータを3時間かけて整形し、損益タブに合わせて組み直した経験があるなら、あなたはまさに「シート・モンキー（sheet monkey）」です。これは侮辱ではありません。それが仕事というものです。ただ、問題は、2026年においてもそれが「あなたの仕事」であり続けるべきかどうか、ということです。AIが機械的な作業を引き受けることで、本当に判断力を要する分析に時間を使えるようになるのではないでしょうか。

正直なところ、それはタスクによります。実績値の取り込み、日付フォーマットの修正、壊れた参照の修復といった機械的なクリーンアップ作業の約60〜80%はAIが対応できます（※1）。一方、コンプ（比較対象企業）と照らし合わせた前提条件の検証については、AIの貢献度はほぼゼロです。これはバグではなく、計算と判断の境界線がそこにあるということです。

タブ名変更の悪夢：ビフォー・アフター

こんなシナリオを考えてみてください。当社のファイナンスチームの田中さんが引き継いだモデルでは、前任者が3つのタブ名を変更していました。損益計算書がPLに、前提条件がインプットに、収益分析がリターン分析にそれぞれ変わり、ブック全体で約40のフォーミュラが壊れていたのです。旧タブ名を参照していたすべてのクロスタブ参照が#REF!エラーを返していました。

リターン分析タブで見られた壊れた状態：

=('損益計算書'!C15-'損益計算書'!C8)/'前提条件'!$B$3        → #REF!
=SUMIFS('損益計算書'!C:C,'損益計算書'!B:B,">="&'前提条件'!$B$3)  → #REF!
='損益計算書'!C22*'前提条件'!$D$14                   → #REF!

これが4タブにわたって40箇所。手作業での修正は検索・置換で対応できますが、それは新しいタブ名が一貫している場合に限ります。誰かが新しい名前を誤入力していたり、行挿入によって範囲がずれていたりすると、セルひとつひとつを手で直すことになります。

プロンプト例：

「3つのタブ名が変更されました。『損益計算書』は今『PL』に、『前提条件』は『インプット』に、『収益分析』は『リターン分析』になっています。ブック内のすべての壊れたクロスタブ参照を見つけ、正しいタブ名で書き直してください。」

返ってきた結果： ツールがリターン分析、LBOサマリー、デットスケジュールの3タブにわたる43箇所の壊れた参照を特定しました。そして何かを書き込む前に、変更前・変更後のフォーミュラをセルごとに示したdiff（差分）を提示してきました。最初のバッチはこのような形です：

リターン分析!B12
  変更前: =('損益計算書'!C15-'損益計算書'!C8)/'前提条件'!$B$3
  変更後: =('PL'!C15-'PL'!C8)/'インプット'!$B$3

リターン分析!B13
  変更前: =SUMIFS('損益計算書'!C:C,'損益計算書'!B:B,">="&'前提条件'!$B$3)
  変更後: =SUMIFS('PL'!C:C,'PL'!B:B,">="&'インプット'!$B$3)

43箇所すべての書き換え案を確認・承認。所要時間はレビュー込みで約4分。検索・置換による手作業なら25〜35分かかり、それでも見落としがないか監査が必要になります。

このdiffレビューで重要な発見がありました。43箇所のうち3箇所は、第3四半期に誰かが行を挿入した際に行番号もずれていたのです。AIはそれらを「手動確認が必要な可能性あり」としてフラグを立て、誤った修正をサイレントに適用することはありませんでした。これが正しい動作です。

シート・モンキーがAIで確実に時間を節約できる作業

タブ名変更のシナリオは、「ロジックは明確、パターンは反復的、そしてミスが監査コストに直結する」という一類の問題を代表しています。2026年4月現在、財務モデルにおいてAIが真価を発揮するタスクは以下の通りです：

タスク	削減時間	注意すべき失敗パターン
タブ名変更後のクロスタブ参照修復	25〜35分 → 4分	名前スキャンだけでは捉えられない行・列のずれ
日付フォーマットの正規化（Salesforceエクスポート）	45分 → 8分	ゼロパディングなしのソースによる1桁月の問題
ERPダンプから損益タブへの実績値取り込み	約60〜80%の工数削減	年度途中の勘定科目コード変更によるマッピングエラー
5,000行へのARRAYFORMULA展開	ほぼ即時	フォーミュラは正しいが前提条件が間違い
8タブモデルへのSUMIFS構築	5分 → 30秒	ヘッダー行の誤認識

このテーブルにないもの：WACCの前提条件をコンプと照合する作業、ターミナルグロースレートのストレステスト、EXITマルチプルのセクター妥当性検証。これらは数字の意味を理解している人間が担う作業です。

WACC計算の実践例

ここでは、2026年における日本のSeries B SaaS企業（売上20〜50億円規模）を例に、WACC計算の実際とモデルにおけるAIの活用場面を解説します。

2026年4月時点のインプット（参考値）：

リスクフリーレート：1.5%（財務省公表の10年利付国債利回り）（※2）
エクイティリスクプレミアム：5.5%（日本市場推定値、Damodaran 2026年1月版）（※2）
ベータ：1.35（中規模SaaSのピアベータ、アンレバード後に負債比率20%で再レバード）
サイズプレミアム：1.5%（時価総額200〜500億円規模相当）
負債コスト：3.8%（現環境でのシニア担保付き融資レート）
実効税率：30%（法人税・地方税込み）

これらを組み合わせると、WACCはおよそ9〜10%になります（ベータの前提によって変動）。

ここが本題です——ピアベータを実際にどう計算するか。

コンプタブに12社分のデータが並んでいるとします：

列	内容
A列（A2:A13）	企業名
B列（B2:B13）	レバードベータ（観測値）
C列（C2:C13）	D/E比率（Net Debt ÷ Equity）
D列（D2:D13）	実効税率

目標は「各社のベータを自社の資本構成に合わせて調整した平均値」を求めることです。使うのはハマダ方程式（Hamada equation）です：

アンレバード： βU = βL ÷ [1 + (1 − T) × (D/E)]
再レバード： βL（目標）= βU × [1 + (1 − T目標) × (D/E目標)]

12社分を一括処理するARRAYFORMULA：

=AVERAGE(ARRAYFORMULA(
  ('コンプ'!B2:B13 / (1 + (1 - 'コンプ'!D2:D13) * 'コンプ'!C2:C13))
  * (1 + (1 - インプット!$C$5) * インプット!$C$6)
))

インプット!$C$5 = 自社の目標実効税率（例：0.30）
インプット!$C$6 = 自社の目標D/E比率（例：0.25 ＝負債20%・資本80%）

内側の除算がアンレバード、外側の乗算が再レバードです。AVERAGEが12社の平均を返します。このセルひとつで、コンプの追加・削除のたびに自動再計算されます。成長プロファイルによってレバードベータは1.2〜1.6の範囲に収まることが多く、EBITDA赤字のSaaS企業ではベータの前提がモデル全体のバリュエーションに大きく影響します。

このフォーミュラでAIが役立つ場面： ModelMonkeyはこのAVERAGE(ARRAYFORMULA(...))の構造を、コンプタブの列配置を読み取った上で、手入力するよりも速く書いてくれます。ただし、ピアセットが適切かどうか——成長プロファイルの類似性、EBITDA赤字企業の扱い、日本未上場企業の代替ピア選定——の判断はできません。WACCを上司や投資家に説明するとき、「なぜこの12社なのか」を問われるのはあなた自身です。

ARRAYFORMULAの日付問題

Salesforceは日付をM/D/YYYY形式でエクスポートします。ゼロパディングなしです。つまり2026年1月5日は1/5/2026であり、01/05/2026ではありません。MID(A2,4,2)で日を抽出しようとすると、1桁月の場合に文字位置がずれて正しく機能しません。

3,000行のエクスポートをYYYY-MM-DDに正規化するための堅牢なフォーミュラ：

=ARRAYFORMULA(
  IF(A2:A="","",
    TEXT(DATEVALUE(A2:A),"YYYY-MM-DD")
  )
)

DATEVALUEはM/D/YYYYをネイティブに処理します。ゼロパディングの有無を気にしません。TEXTラッパーがISO形式に変換し、損益タブ全体のSUMIFS日付比較に対応します：

=SUMIFS('PL'!C:C,
        'PL'!B:B,">="&TEXT(インプット!$B$3,"YYYY-MM-DD"),
        'PL'!B:B,"<="&TEXT(インプット!$B$4,"YYYY-MM-DD"))

ソースの形式が想定と異なる場合、20分の試行錯誤を重ねるより、AIに日付正規化パイプライン（クロスタブのSUMIFSを含む）を書かせるのに3分使う方が合理的です。

シート・モンキーがAIにフォーミュラを書かせるとはどういうことか

典型的な失敗パターンは、AIが「間違った問いに対して技術的に正しいフォーミュラ」を書くことです。機械的な部分が速いため、自分自身のモデルへの理解を超えて作業が進んでしまうことがあります。正しいセルを参照しているが集計対象が間違っているSUMIFSを承認してしまうと、差異分析が誤った状態になります。サニティチェックは通過しても、経営会議で「管理会計と4,200万円合わない」と指摘されて初めて発覚する、というケースが起きます。

解決策はAIを遅くすることではなく、プロンプトを明確にし、提案された変更をシートに反映する前にレビューする習慣を持つことです。このツールの「承認前書き込み防止」ワークフローはまさにこのために存在します。すべてのフォーミュラ変更は、シートに触れる前に確認できるdiffとして提示されます。

まとめ

2026年においてシート・モンキーであり続けることは、選択の結果です。機械的な作業——クロスタブ参照の修復、日付の正規化、複数タブにまたがるフォーミュラのテンプレート化——は、今や手作業よりもAIに委ねた方がコスト効率が高い。一方、判断を要する作業——前提条件の検証、コンプの選定、感度分析の設計——はあなたの領域です。6時間かかっていたモデル構築が2時間で終わるようになる差のほとんどは、前者の作業から生まれます。

ModelMonkeyのプランを選ぶ — Google SheetsとExcel、どちらでも動作します。

※1：機械的クリーンアップタスクの削減率は、200件以上のワークフロー分析（2025年下期）に基づく推定値です。作業環境やモデルの複雑度によって変動します。
※2：リスクフリーレートは財務省公表の10年利付国債利回り（2026年4月時点）、エクイティリスクプレミアムはAswath Damodaran教授（ニューヨーク大学）の推定値（2026年1月更新版）を参照。

よくある質問

Q. シート・モンキーとは何ですか？

スプレッドシート上の反復的・機械的な作業——データクリーニング、フォーミュラの手動コピー、フォーマット修正など——に多くの時間を費やすアナリストや経営企画担当者を指す俗語です。高付加価値の判断業務よりも作業量に縛られている状態を表します。本記事のテーマは、そのシート・モンキー的な業務をAIに委ねることで、判断が必要な分析に集中する環境をつくることです。

Q. Google SheetsでAIを活用するのに技術的な知識は必要ですか？

基本的なスプレッドシートの操作ができれば十分です。ARRAYFORMULAやSUMIFSの仕組みを理解していると、AIが提案したフォーミュラを正しくレビューできるため、より安全に活用できます。プロンプトは「このタブのこのセルにこういう計算をしてほしい」という業務レベルの指示で機能します。Apps ScriptやAPIの知識は不要です。

Q. AIに任せていい作業とそうでない作業の見分け方は？

「ロジックが明確で、パターンが反復的か」が判断基準です。タブ参照の修復、日付の正規化、フォーミュラの展開はAI向き。前提条件の妥当性検証、ピアセットの選定、シナリオ設計は人間の判断が必要です。AIが「計算を実行する」タスクは委ねられますが、「何を計算すべきか」の定義は委ねられません。

Q. ピアベータを自社のWACCに使う際、どの企業を選べばよいですか？

成長ステージ、収益規模、ビジネスモデル（ARR比率など）が類似した企業を選ぶのが原則です。日本のSaaSはまだ上場社数が限られているため、成長プロファイルが近い米国・東南アジアの上場企業を補完的に使うケースもあります。ただし地域差によるカントリーリスクの調整が必要になることと、ピアセットの選定根拠は稟議・投資家説明の場で必ず問われることを念頭に置いてください。

Q. 「承認前書き込み防止」ワークフローとはどういう意味ですか？

AIが提案した変更（フォーミュラの書き換え、セルの更新など）を、実際にシートに書き込む前にdiff形式で確認・承認できる機能を指します。「AIが勝手に書き換えた」状態を防ぎ、人間がすべての変更を最終確認してから適用するプロセスを強制します。本記事のタブ名変更シナリオで、43箇所のうち3箇所に行番号ずれが検出されフラグが立てられた動作が、その典型例です。