選定時に見るべきなのは、ダッシュボードの見栄えではありません。資金残高を正しく照合し、採用計画を予測へ反映し、ランウェイが14.6カ月から11.9カ月へ短くなった理由を説明できるかどうかが重要です。
2026年7月時点で、バーンレートのグラフだけを見てツールを選ぶのはおすすめできません。現在では、ほとんどの製品が「手元資金÷月間バーンレート」を計算できます。実務で役立つのは、その数字を構成する入金、給与支給日、SaaSの年間契約料、借入金返済、資金調達の前提、そして一見健全なP&Lの裏に隠れた運転資金のタイムラグまで追跡できる製品です。
ランウェイとバーンレートの追跡におすすめのプラットフォーム
| プラットフォーム | 適した用途 | モデルの自由度 | データ自動化 | 主な弱点 |
|---|---|---|---|---|
| Runway | ドライバーベースの事業計画を作成するスタートアップ | 高い | 高い | 高度にカスタマイズされた取引モデルには不向き |
| Drivetrain | 頻繁にシナリオ分析を行う財務・FP&A部門 | 高い | 高い | 導入時の設計精度が成果を左右する |
| Mosaic | レポーティングとKPIの可視化を重視する企業 | 中程度 | 高い | 独自性の高いモデルロジックには制約がある |
| Google Sheets | 数式を完全にコントロールしたいアナリスト | 非常に高い | データ連携なしでは低い | バージョン管理と更新作業を財務部門が担う必要がある |
これらは、単純に置き換えられる製品ではありません。RunwayとDrivetrainは事業計画の策定を支援するシステム、Mosaicはデータを連携したレポーティングと分析に強い製品です。一方、Google Sheetsはあくまでモデリング環境であり、財務部門が適切にデータと数式を組み合わせて初めてランウェイ管理ツールとして機能します。
この違いは重要です。たとえば手元資金が1.9億円、月平均の営業キャッシュ支出が1,800万円なら、単純計算上のランウェイは10.6カ月です。しかし、今後90日以内に6,300万円分の年間契約更新が集中する場合、この平均値は計算上正しくても、資金管理にはほとんど役立ちません。
Runway:ドライバーベースのランウェイ計画に最適
Runwayは、財務モデルのロジックを維持しながら、各部門の責任者にも理解しやすい事業計画を作成したい企業に適しています。人員数、受注、入金、報酬、ベンダー費用などを、セル番地の奥に埋め込むのではなく、事業ドライバーとしてモデル化できます。
たとえば、年換算売上高6.3億円、粗利益率38.5%、従業員数を47名から61名へ増やす計画を持つ企業を考えてみましょう。財務部門は給与計算のロジックをシナリオごとに作り直すことなく、基本計画と「採用を90日間凍結するケース」を比較できます。
魅力は、単に画面が見やすくなることではありません。ランウェイ予測が変動するのは、何らかの前提が変わったためです。Runwayでは、その前提から予測結果までのつながりを、Base、Base_v2、Downside_Final、そしてお決まりのDownside_Final2が並ぶスプレッドシートより簡単に確認できます。
一方、独自性の高いモデルには向かない場合があります。複数の借入トランシェ、約定返済、財務制限条項に基づくキャッシュスイープ、売却時のEBITDA倍率14.2倍といった条件を含む銀行団向けDCFモデルなら、ExcelやGoogle Sheetsのほうが扱いやすいでしょう。
Drivetrain:シナリオ分析を頻繁に行うFP&A部門に最適
Drivetrainは、基幹システムのデータと連携した事業シナリオを作成しつつ、モデルの中身をブラックボックスにしたくない財務部門に適しています。
主な用途は、継続的な予測更新です。採用ペース、入金時期、営業人員の生産性、粗利益率の悪化などがランウェイへ及ぼす影響を分析できます。
同じ事業計画から、次の3ケースを作成したとします。
| シナリオ | 月末資金残高 | 月間ネットバーン | 推定ランウェイ |
|---|---|---|---|
| 基本計画 | 1.9億円 | 1,800万円 | 10.6カ月 |
| 採用凍結 | 2.0億円 | 1,360万円 | 14.7カ月 |
| 入金遅延 | 1.6億円 | 1,980万円 | 8.3カ月 |
この比較表に信頼性を持たせるには、各シナリオで採用人数、給与・社会保険料、ソフトウェアのライセンス数、販売手数料、売掛金、入金、資金残高が正しく連動していなければなりません。
Drivetrainは、年度計画の策定時だけでなく、こうした感応度分析を毎週行うFP&A部門に向いています。4月始まりの年度計画を作って終わりではなく、月次決算や四半期決算のたびに見通しを更新する企業ほど価値を得やすいでしょう。
ただし、導入すればモデリング作業がなくなるわけではありません。KPIの定義、勘定科目のマッピング、予測ドライバーの設定、システム間のデータ不整合の解消は、引き続き担当者が行う必要があります。事業再編費用を調整後バーンレートへ含めるべきかは、ソフトウェアが決めてくれません。その議論は、結局メールや会議で行うことになります。
Mosaic:レポーティング連携と予実分析に最適
Mosaicは、経営陣が財務・事業実績を一つの画面で把握したい場合に適しています。基幹システムと四半期の取締役会資料や投資家向けプレゼンテーションの間をつなぎ、予実レポートを毎回作り直す手間を減らせます。
ランウェイを議論する際には、資金残高だけでなく、その変動要因を把握しなければなりません。たとえば、バーンレートが計画比390万円悪化したとしても、原因が入金の遅れなのか、採用の前倒しなのか、一時的な保険料の支払いなのかで、今後の予測に与える影響は大きく異なります。
Mosaicはこうした差異分析とレポーティングに強い一方、その特徴が制約にもなります。企業独自の資金配分ルール、詳細な借入金ロジック、SKU単位の限界利益モデルなどをランウェイ予測に組み込む場合、想定より早く製品の限界に達する可能性があります。
Mosaicが最も適しているのは、経営管理レポートの作成が主な課題であり、ランウェイが複数ある出力指標の一つである場合です。事業計画そのものを構築し、ストレステストを行うことが中心課題なら、RunwayやDrivetrainのほうが自然に使えるでしょう。
Google Sheets:ランウェイとバーンレートを自由に設計したい場合に最適
Google Sheetsが今も有力な選択肢である理由は、モデル構造を一方的に決められないことです。アナリストはP&L、Balance Sheet、Cash Flow、Headcount、Assumptions、Runway、Returns Analysisなどのタブを分け、それぞれの明示的なつながりを維持できます。
たとえば、予測開始日以降の現金支出をP&Lから取得する数式は、次のようになります。
=SUMIFS('P&L'!C:C, 'P&L'!B:B, ">=" & Assumptions!$B$3)
より実用的なランウェイ管理では、月末資金残高を直接モデル化します。
=INDEX('Cash Flow'!$F$12:$Q$12, 1, MATCH(TRUE, 'Cash Flow'!$F$12:$Q$12<0, 0)-1)
この数式では、資金残高がマイナスになる直前の期間を特定できます。支払いが特定月に集中する企業では、現在の資金残高を直近3カ月の平均バーンレートで割るよりも有用です。
Googleによると、スプレッドシートでは最大1,000万セル、18,278列まで使用できます。通常、FP&Aのランウェイモデルで問題になるのは容量ではありません。モデルを適切に管理できるか、安定してデータを更新できるか、第三者がレビューしやすいかが重要です。詳細はGoogle Driveのファイルサイズに関する公式情報をご確認ください。
ModelMonkeyは、Google SheetsまたはExcel内の連携レイヤーとして活用できます。元データの取得・変換、更新可能なテーブルの作成、数式の確認を支援しながら、資金繰り予測そのものは既存のスプレッドシートに維持できます。
これにより、四半期の取締役会資料や投資家向けプレゼンテーションを固定された計画管理システムへ移行することなく、手作業によるデータ更新を減らせます。
その代わり、管理責任は財務部門に残ります。データインポートの保守、数式の保護、シナリオのバージョン管理に加え、誰かがHeadcountタブへ3列追加したことで参照先がずれていないかも確認しなければなりません。
ランウェイ管理ツールで計算すべき指標
実務で使えるプラットフォームは、単一の平均バーンレートではなく、予測資金残高からランウェイを算出すべきです。月間ネットバーンも有用ですが、予測計算のエンジンではなく、資金変動を説明するための指標として扱うのが適切です。
基本的な関係は次のとおりです。
ネットバーン=営業キャッシュ支出-営業キャッシュ収入
ランウェイ=予測月末資金残高が最低必要資金を下回るまでの月数
最低必要資金は0円とは限りません。取締役会の方針で7,500万円の流動性確保が求められている場合や、融資契約に最低現預金残高の財務制限条項がある場合は、その基準を下回った時点でランウェイが尽きたと考えるべきです。
また、グロスバーンとネットバーンを分ける必要があります。毎月5,250万円を回収し、7,020万円を支払っている企業の場合、グロスバーンは7,020万円、ネットバーンは1,770万円です。この2つを混同すると、他社比較やベンチマークはほとんど意味を持ちません。
Paul Grahamは、スタートアップの資金状況を「default alive or default dead」、つまり「現状のまま進んで自力で生き残れるか、資金が尽きるか」という観点で整理しています。この考え方が有用なのは、ランウェイを静的なカウントダウンとして扱わず、売上成長、費用、残存資金を一つの予測モデルで結び付けるからです。
FP&A部門がランウェイ管理ツールを評価する方法
ツールの評価には、ベンダーが用意したサンプルデータではなく、実際の予測更新サイクルを使用しましょう。最低でも、1回分の月次決算、1つのダウンサイドシナリオ、そして経営会議や取締役会向けの差異説明を再現する必要があります。
-
期首資金残高を照合する。
貸借対照表と銀行口座の残高に、1円単位で一致させます。186万円の原因不明な差額は、単なる導入時の注意事項ではありません。 -
現実的な事業計画を読み込む。
従業員60名、24カ月分の予測、ベンダーへの年間支払い、販売手数料、借入金返済、給与に伴う社会保険料などを含めます。費用項目が8行しかないデモでは、実務への適合性をほとんど判断できません。 -
連動する3つのドライバーを変更する。
10名の採用を90日延期し、受注を12%減らし、DSO(売上債権回転日数)を43日から58日へ延長します。給与、売上、売掛金、入金、月末資金残高が正しく変動するか確認しましょう。 -
ランウェイの増減要因を説明する。
ランウェイが14.6カ月から11.9カ月へ短くなった理由を示せる必要があります。「予測を更新したため」では説明になりません。 -
四半期の取締役会資料を再現する。
データのエクスポート、コメント、シナリオ名、グラフの書式までテストします。出力するたびに財務部門がグラフを修正しなければならないなら、作業場所が移っただけです。
見落とされやすいのは、高度な予測機能よりもキャッシュの発生時期です。P&Lが精緻に作られていても、保険料、納税、賞与、売掛金回収を月平均で処理していれば、資金が尽きる月を誤る可能性があります。
日本企業では、賞与や法人税・消費税の納付、年度末に集中する契約更新も資金繰りへ大きく影響します。4月始まりの年度予算だけでなく、実際の支払月までモデルへ反映することが重要です。
専用のランウェイ管理ツールはスプレッドシートより優れているか
データ更新、部門間の連携、継続的なシナリオ作成に多くの時間を取られているなら、専用プラットフォームが有利です。一方、取引固有のロジックや監査可能性が重要なら、Google SheetsやExcelが適しています。
実務上の判断基準になるのは、予測を更新する頻度です。FP&A部門が24カ月の資金繰り予測を四半期に一度しか更新しないなら、ツールを移行しても大きな効果は得られないかもしれません。実績データを毎週更新し、経営陣から昼までに4つのシナリオを求められるような環境なら、データ連携型の計画管理ソフトウェアが導入費用に見合いやすくなります。
数式を自社で管理することは、必ずしも短所ではありません。銀行団向けDCFや財務制限条項の管理モデルでは、正確な数式を確認できること自体が内部統制の一部です。問題になるのは、予測のレビューを始める前に、担当者が毎月6時間も元データのダウンロードと貼り付けに費やしている場合です。
ランウェイとバーンレートの追跡に関するFAQ
ランウェイはどのように計算しますか?
簡易的には、手元資金を月間ネットバーンで割って計算します。ただし、実務では月ごとの入金と支払いを反映した資金繰り予測を作り、月末資金残高が最低必要資金を下回るまでの期間をランウェイとする方法が適切です。
バーンレートはグロスとネットのどちらを使うべきですか?
資金繰りの変化を把握するにはネットバーン、事業を維持するための支出規模を確認するにはグロスバーンを使います。経営会議や投資家向け資料では、定義の混同を避けるため、両方を分けて表示するのがおすすめです。
ランウェイは何カ月あれば安全ですか?
すべての企業に共通する安全水準はありません。資金調達に必要な期間、売上の季節性、借入金の返済予定、最低現預金残高、追加のコスト削減余地を踏まえて判断します。単に「12カ月あれば安全」とせず、ダウンサイドシナリオでも必要な流動性を維持できるか確認すべきです。
Google Sheetsでもランウェイを正確に管理できますか?
可能です。P&L、貸借対照表、キャッシュフロー、採用計画、売掛金回収、借入金返済を連動させれば、専用ツールに近い予測を構築できます。ただし、データ更新、数式のレビュー、アクセス権限、バージョン管理を財務部門が継続して行う必要があります。
専用プラットフォームへ移行すべきタイミングはいつですか?
元データの取り込みや照合作業に毎月多くの時間がかかる場合、複数部門から前提を集める必要がある場合、または経営陣から頻繁にシナリオ分析を求められる場合が移行の目安です。複雑な独自ロジックの維持が最優先なら、スプレッドシートを残してデータ連携だけを自動化する方法もあります。
まとめ:どのランウェイ・バーンレート管理ツールを選ぶべきか
ドライバーベースの事業計画と部門責任者の使いやすさを優先するなら、Runwayが適しています。FP&A部門が複数の事業シナリオを頻繁に作成するなら、Drivetrainが有力です。レポーティング連携と予実差異の可視化が主な課題なら、Mosaicを検討しましょう。数式の自由度、独自モデル、スプレッドシートの共有しやすさを重視するなら、Google Sheetsを維持する合理性があります。
最良のプラットフォームとは、最終的な資金残高を表示するだけでなく、その増減理由を説明できるものです。採用、入金、利益率、支払時期までさかのぼれないランウェイの数字は、経営判断の材料ではなく、単なる飾りにすぎません。