公式スキル · 財務・経理
財務モデルの前提レビュー
財務モデルの前提を出どころとともに並べ、感度を試し、実績に照らして妥当性を確かめ、結果をいちばん動かす前提を3つ挙げる。
Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。
使う場面
- モデルを取締役会、金融機関、投資家に出す前
- 予測がうますぎるのに、だれも理由を説明できないとき
AI に渡すもの
- モデル、またはその入力と出力
- 同じドライバーの実績
- 信頼できるベンチマークと出典（任意）
できあがるもの
いちばん効く3つの前提、感度の表、すべての前提の一覧、構造の問題をまとめたレビュー。
手順
- 前提をすべて並べる 入力のシートだけでなく、数式の中に直接打ち込まれた数字も含める。それぞれについて、何か、値、単位、期間、出どころ（実績、契約、計画、勘）、だれが決めたかを書く。このスキルの既定値: 出どころが空欄なら「勘」とする。
- ドライバーと結果を分ける ドライバーは入力（転換率、価格、解約率、採用計画、給与）。結果は計算されるもの（売上、バーン）。計算ではなく数字で打ち込まれた結果があれば指摘する。
- 入力を1つずつ動かして感度を試す ドライバーごとに決まった幅で動かし（このスキルの既定値: ±20%、またはユーザーが示した現実的な範囲）、主な出力の変化を記録する。その変化の大きさでドライバーを順位づける。
- 妥当性を確かめる 上位のドライバーを会社自身の実績と比べる。これまでの最高の月の2倍の成長率や、実績の半分の解約率には理由が要る。ユーザーが渡したベンチマークとも比べ、出典を書く。どちらもなければ「[要確認: 実績もベンチマークもない]」と書く。
- いちばん効く3つを挙げる 主な出力への影響がいちばん大きい3つのドライバーについて、それぞれ今の値、その根拠、悪い方向に外れたときに出力がどうなるか、確信を高めるには何が要るか（集めるデータ、行う検証）を書く。
- 構造の問題を書く 合わない単位（月次と年次）、時期（採用期間なしに計画の1か月目から入社する採用）、連動すべきなのにしていないドライバー（営業の採用は増えるのに1人あたりのノルマは同じで、売上が動かない）。
- まとめを書く 2〜3文で、モデルが何を示しているか、それを支える3つの前提、いちばん大きなリスク。
SKILL.md の全文
AI が読むファイルそのものです。 ダウンロード
---
name: model-assumptions-review
description: 財務モデルや予測の前提をレビューする。前提をすべて値、出どころ、決めた人とともに並べ、入力を1つずつ動かして感度を試し、ユーザーが渡したベンチマークと会社自身の実績に照らして妥当性を確かめ、結果をいちばん大きく動かす前提を3つ挙げる。ベンチマークを作り出すことはしない。財務モデル、事業計画、予算、資金調達の計画を渡されて、前提のレビュー、モデルのストレステスト、「何が成り立てばこの数字になるのか」を頼まれたときに使う。
---
# 財務モデルの前提レビュー
財務モデルは前提の質を超えない。そして結果の大半は、たいてい少数の前提で決まる。このレビューは、すべての前提を出どころとともに見えるようにし、どれが出力をいちばん動かすかを測り、それを実績とユーザーが渡したベンチマークに照らして確かめる。モデルを作り直しはしない。
## 使う場面
- モデルを取締役会、金融機関、投資家に出す前。
- 予測がうますぎるのに、だれも理由を説明できないとき。
- 新しい財務責任者がモデルを引き継いだとき。
- CAC と LTV の計算だけを確かめるのには使わない。unit-economics-check を使う。毎月のランウェイの数字には runway-update を使う。
## 用意するもの
- モデル、またはその前提と出力: 入力のシート、ドライバー、主な出力（売上、バーン、現預金、ランウェイ、利益）。
- 同じドライバーについての会社の実績（あれば直近6〜12か月）。
- ユーザーが信頼するベンチマークと、その出典。渡されなければ実績とだけ比べ、そう書く。記憶からベンチマークを持ち出さない。
- 判断にいちばん関わる出力（資金が尽きる月、損益分岐の月、期末の売上）。指定がなければ資金が尽きる月を使う。
## 手順
1. **前提をすべて並べる。** 入力のシートだけでなく、数式の中に直接打ち込まれた数字も含める。それぞれについて、何か、値、単位、期間、出どころ（実績、契約、計画、勘）、だれが決めたかを書く。このスキルの既定値: 出どころが空欄なら「勘」とする。
2. **ドライバーと結果を分ける。** ドライバーは入力（転換率、価格、解約率、採用計画、給与）。結果は計算されるもの（売上、バーン）。計算ではなく数字で打ち込まれた結果があれば指摘する。
3. **入力を1つずつ動かして感度を試す。** ドライバーごとに決まった幅で動かし（このスキルの既定値: ±20%、またはユーザーが示した現実的な範囲）、主な出力の変化を記録する。その変化の大きさでドライバーを順位づける。
4. **妥当性を確かめる。** 上位のドライバーを会社自身の実績と比べる。これまでの最高の月の2倍の成長率や、実績の半分の解約率には理由が要る。ユーザーが渡したベンチマークとも比べ、出典を書く。どちらもなければ「[要確認: 実績もベンチマークもない]」と書く。
5. **いちばん効く3つを挙げる。** 主な出力への影響がいちばん大きい3つのドライバーについて、それぞれ今の値、その根拠、悪い方向に外れたときに出力がどうなるか、確信を高めるには何が要るか（集めるデータ、行う検証）を書く。
6. **構造の問題を書く。** 合わない単位（月次と年次）、時期（採用期間なしに計画の1か月目から入社する採用）、連動すべきなのにしていないドライバー（営業の採用は増えるのに1人あたりのノルマは同じで、売上が動かない）。
7. **まとめを書く。** 2〜3文で、モデルが何を示しているか、それを支える3つの前提、いちばん大きなリスク。
## 出力の形式
```markdown
# 前提レビュー — [モデル名]、[日付]
**主な出力:** [例: 資金が尽きる月: [値]]
**まとめ:** [2〜3文]
## いちばん効く3つ
| # | 前提 | 値 | 根拠 | 外れたとき（悪い方向） | 確信を高めるには |
|---|---|---|---|---|---|
| 1 | [ドライバー] | [値] | [実績 / ベンチマーク / 勘] | [出力の変化] | [データか検証] |
## 感度（入力を1つずつ動かす）
| ドライバー | 基準値 | 幅 | −幅のときの主な出力 | +幅のときの主な出力 |
|---|---|---|---|---|
| [ドライバー] | [値] | [±20%] | [値] | [値] |
## すべての前提
| 前提 | 値 | 単位/期間 | 出どころ | 決めた人 | 妥当性 |
|---|---|---|---|---|---|
| [名前] | [n] | [単位] | [出どころか「勘」] | [名前] | [実績/ベンチマークとの比較、または「[要確認: …]」] |
## 構造の問題
- [問題と、モデルのどこか]
```
## 例
**入力:**
> 株式会社ケストレル（B2B SaaS）の2か年計画。期初の MRR 600万円。毎月の新規 MRR は90万円で、毎月10%ずつ増える。月次の売上解約率1%。売上総利益率80%。人員は14名 → 12か月目に30名。1人あたりの平均コストは月90万円。現預金2.4億円。モデルでは資金が尽きるのは26か月目。実績（直近6か月）: 新規 MRR は平均65万円、最高の月で81万円。売上解約率は平均2.2%。ユーザーのベンチマーク: なし。
**出力（抜粋）:**
```markdown
# 前提レビュー — ケストレル 2か年計画
**主な出力:** 資金が尽きる月: 26か月目
**まとめ:** この計画が26か月目まで資金をもたせているのは、新規 MRR がこれまでの最高の月を上回って始まり、毎月10%ずつ増え、解約率が実績の半分未満だと仮定しているから。新規 MRR と解約率が直近6か月の実績のままなら、資金はもっと早く尽きる[要確認: 実績の値でモデルを計算し直す]。
## いちばん効く3つ
| # | 前提 | 値 | 根拠 | 外れたとき（悪い方向） | 確信を高めるには |
|---|---|---|---|---|---|
| 1 | 期初の毎月の新規 MRR | 90万円 | 勘。実績は平均65万円、最高81万円 | [要確認: 65万円で計算し直す] | 90万円を支えるパイプラインを示す |
| 2 | 新規 MRR の伸び | 月10% | 勘。実績の提示なし | [要確認: 0%と5%で計算し直す] | 営業の採用計画とノルマに結びつける |
| 3 | 売上解約率 | 月1% | 実績は2.2% | [要確認: 2.2%で計算し直す] | 解約率を半分にする継続率の施策を挙げる |
## 構造の問題
- 人員は12か月目までに2倍を超えるが、新規 MRR の伸びが営業の採用と連動していない。この2つは一緒に動くはず。
```
## 送る前のチェック
- [ ] どの前提にも値、単位、出どころ（または「勘」）がある。
- [ ] 感度は入力を1つずつ動かし、幅を書いた。
- [ ] 上位3つは、意見ではなく主な出力への影響で順位づけた。
- [ ] 挙げたベンチマークはどれもユーザーから受け取ったもの。実績との比較にはユーザーのデータを使った。
- [ ] モデルか示した計算から出ていない出力の数字を書いていない。計算し直しは「[要確認: …]」とした。
## よくある失敗
- 入力のシートだけを見て、数式の中に打ち込まれた数字を見落とす。
- 複数の入力を一度に動かして、感度と呼ぶ。それはシナリオなので、シナリオと書く。
- 成長率を判断するのに、記憶から外部のベンチマークを持ち出す。
チームで使う
AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む
変更履歴
- v1.0.0 · · First release.
出典
出典は英語のページです。
- The Aqua Book (2026-11-04に確認)
- What is Sensitivity Analysis? (2026-11-04に確認)