「前提条件タブのセルを一つ変えたとき、損益・貸借・CF・FCFFが全部連動して更新されるか」
これは、DuckDBのSQL速度よりも、多くのFP&Aチームが本当に知りたいことです。
Monkey AI（ModelMonkey）はGoogleのスプレッドシートエンジンの上で動作します。つまり、タブ間の参照連鎖と再計算そのものはGoogle Sheetsの計算エンジンが処理します。ModelMonkeyが行うのはセルへの値の書き込みであり、その後の計算伝播はスプレッドシートのネイティブ動作に委ねられます。前提条件!B3 を書き換えれば、そのセルを参照している下流数式は通常通り再計算されます。
三表連動＋WACCの循環参照がある場合
より慎重な確認が必要になるのは循環参照を含むモデルです。たとえば、以下のような構成を想定してください：
前提条件タブ：売上成長率・WACC・割引率などのハードコード値P&Lタブ：営業利益を前提条件から参照して計算BSタブ：有利子負債残高をP&Lの純利益から導出CFタブ：フリーキャッシュフローをP&L・BSから参照FCFFタブ：WACCを参照してDCF評価。WACCの計算式がBSタブの負債/資本比率を参照している
このような構成では、BS → WACC → FCFF → BS の循環が発生します。Google Sheetsの繰り返し計算（設定→計算→反復計算を有効化）を使ってこの循環を解いているモデルでは、ModelMonkeyが特定セルに値を書き込んだ後、繰り返し計算の収束プロセスが意図した通りに走るかどうかは、モデル固有の構造に依存します。
事前に確認すべき点：
- 繰り返し計算が「有効」になっているか（無効の場合、循環参照はエラーになります）
- 書き込み対象セルが循環の起点（例：負債残高）になっていないか
前提条件!B3（WACC）を手動で変更したときと、ModelMonkeyが書き込んだときで、FCFFタブの評価額が同じ値に収束するかを単純なケースで確認する
循環参照を含む8タブ以上のモデルに初めて適用する場合は、本番ファイルのコピーで、一つの書き込み操作ずつ動作を確認してから本番に移行することを強くお勧めします。これは警告ではなく、複雑なモデルに新しいツールを導入するときの標準的な手順です。
データ取込後の確認コストを込みで試算する
ModelMonkeyのROI試算でよく見落とされるのが、データ搬入後の検証工数です。
Stripeから数字を引っ張り、人事システムから人員データを取り込み、HubSpotからパイプラインを更新する——この搬入作業が2時間から30分に短縮されたとします。ただし、取り込んだ後にモデル全体の整合性を確認する工程が別途発生するなら、その工数も試算に含める必要があります。
実務的な試算例（売上30億円規模、財務アナリスト2名体制の想定）：
| 工程 | 現状 | ModelMonkey導入後 |
|---|---|---|
| データ搬入・突合 | 2時間 | 30分 |
| 搬入後の整合性確認 | （搬入と一体で実施） | 20〜30分（別途） |
| 実質削減 | — | 60〜70分/回 |
| 月次適用・年間削減（12回） | — | 約12〜14時間 |
| 四半期のみ適用・年間削減（4回） | — | 約4〜5時間 |
月次レポートに適用している場合、年間12〜14時間の削減は稟議の数字として提示しやすい水準です。四半期ベースのみなら年4〜5時間となり、月額10,500円・年間約12万6千円のコストに対して費用対効果の説明が難しくなります。自社の適用頻度（月次か四半期か）を先に確定させてから、費用対効果を算出してください。
「確認込みで年間何時間削減できるか」という数字が出てから、稟議の費用対効果として提示するのが現実的です。
Monkey AIのSQLレイヤーが効くケース、効かないケース
DuckDBによるインメモリSQL処理は、行数がボトルネックになっているケースでは明確に効果があります。5万行規模のデータを3秒以内で集計できる処理速度は、大量のSKUデータや取引明細を扱うワークフローで威力を発揮します。
SELECT region, SUM(revenue) as total_rev, COUNT(*) as deal_count
FROM sheet_range('P&L!A2:F500')
WHERE close_date >= '2026-01-01'
GROUP BY region
ORDER BY total_rev DESC
12製品ラインのSKU別貢献利益を集計する場合や、数万件の取引データをリージョン別に集計する四半期資料の作成など、「行のスキャンと集計」が主な作業になっているケースで有効です。
一方、タブ間の参照連鎖が複雑なモデルでは、速度よりも整合性の問題が先に来ます。前述の三表連動モデルやLBO・WACC分析では、「データを正しく入れる」こと自体よりも「連鎖が正しく更新されているかを確認する」ことが難しい。Monkey AIはその確認プロセスを代替するツールではありません。
自分の作業時間のボトルネックが「行数のスキャン」か「タブ間の伝播確認」かを先に整理してから、SQLレイヤーの有効性を判断することをお勧めします。
使い始めるタイミングについて
四半期決算の準備期間中に本番モデルで初めて試すのは、リスクが高すぎます。最初に触るなら：
- 決算期外の比較的モデルが安定しているタイミングで
- 本番ファイルのコピーに対して
- 一操作ずつ動作を確認しながら
この順序が守れるタイミングが来たら、まず外部ソース接続（Stripe・HubSpot等）を一つ設定し、取り込み結果と既存の手動データを突き合わせてみてください。「搬入は正しく動いたか」「下流の数式は壊れていないか」の2点が確認できれば、次の工程に進む判断ができます。
Monkey AIで最も効果が出るユーザー像
以下に当てはまる場合、費用対効果が出やすいです：
- データの搬入・突合に1回あたり1.5時間以上かけており、月次以上の頻度で実施している
- Stripe・HubSpot・SalesforceなどのSaaSが複数あり、それぞれからCSVエクスポートしている
- モデルのデータ列と数式列が整理されている（またはこれを機に整理できる）
以下に当てはまる場合は、費用対効果を慎重に見積もる必要があります：
- データはすでにGoogle Sheetsに揃っており、搬入工数が少ない
- 適用頻度が四半期のみで、年間削減時間が5時間未満になる
- モデルの主なボトルネックが行数ではなくタブ間の計算チェーンの確認作業
- LBO・WACCなど、数式構造そのものがツールの外で管理されている
ModelMonkeyのプランを選ぶ — Google SheetsおよびExcel対応
よくある質問
Q. Monkey AIとModelMonkeyは別サービスですか？ 同じサービスです。ModelMonkeyが正式名称で、「Monkey AI」はユーザーが口語的に使う検索キーワードです。
Q. 三表連動モデルで循環参照があっても動作しますか？ Google Sheetsの繰り返し計算が有効になっていれば、書き込み後の再計算はスプレッドシートのエンジンが処理します。ただし、BS→WACC→FCFFのような循環を含むモデルでの挙動は構造に依存するため、本番適用前に「手動入力時と同じ結果に収束するか」をコピーファイルで確認することを推奨します。
Q. 書き込み時に確認プロンプトは毎回出ますか？ はい。セル範囲への書き込みのたびに確認が求められます。数式を無断で上書きしないための設計ですが、ライブレビュー中は摩擦になる場面もあります。
Q. 投資家向け資料や上司への報告資料に使えますか？ データの搬入と整形を担うツールとして使い、取り込み後の数値はアナリスト自身が検証・判断するプロセスを前提とすれば問題ありません。ツールが出した数値をそのまま提出する想定では使えません。
Q. サブスクリプションなしでも使えますか？ はい。買い切りクレジットを購入すれば月額プランなしでも利用できます。継続的に使う場合は月額プランも選べます。