estimation-fermi

フェルミ推定

目次

• ワークフロー
• よくあるパターン
• ガードレール
• クイックリファレンス

例

質問：シカゴにはピアノ調律師が何人いますか？

分解：

1. シカゴの人口は約300万人 ÷ 1世帯あたり3人 ＝ 100万世帯
2. 約20世帯に1世帯がピアノを所有 ＝ ピアノ5万台、年1回調律
3. 調律師：年間250日 × 1日4件の調律 ＝ 年間1,000件
4. 5万 ÷ 1,000 ＝ ピアノ調律師は約50人（実際は約80〜100人で、桁は一致しています）

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Fermi Estimation Progress:
- [ ] Step 1: Clarify the question and define metric
- [ ] Step 2: Decompose into estimable components
- [ ] Step 3: Estimate components using anchors
- [ ] Step 4: Bound with upper/lower limits
- [ ] Step 5: Calculate and sanity-check
- [ ] Step 6: Triangulate with alternate path

ステップ1：質問を明確にし、指標を定義する

質問を正確に言い換えます（単位、範囲、期間）。推定によってどのような判断が左右されるのかを特定します（大まかな回答で十分か、桁の推定が必要か）。質問を明確にするためのフレームワークについては、resources/template.mdを参照してください。

ステップ2：推定可能な要素に分解する

未知の値を、把握できる値の積または商に分解します。分解方法（トップダウン、ボトムアップ、次元解析）を選びます。分解パターンについては、resources/template.mdを参照してください。

ステップ3：基準値を使って各要素を推定する

人口、物理定数、市場規模、個人的な経験など、既知の数量を基準に推定します。前提を明示します。基準値の情報源と較正については、resources/methodology.mdを参照してください。

ステップ4：上限と下限を設定する

楽観的な上限と悲観的な下限を計算し、答えの範囲を定めます。この範囲内で判断が変わるかどうかを確認します。制約に基づく範囲設定については、resources/methodology.mdを参照してください。

ステップ5：計算して妥当性を確認する

推定値を計算し、有効数字1〜2桁に丸めます。現実と照らし合わせて妥当性を確認します（直感的に納得できる答えか）。検証基準については、resources/template.mdを参照してください。

ステップ6：別の方法で三角測量する

異なる分解方法を使って再推定し、妥当性を確認します。どちらの方法でも同じ桁の値になるかを確認します。resources/evaluators/rubric_estimation_fermi.jsonを使って検証してください。最低基準：平均スコアが3.5以上。

よくあるパターン

パターン 1：市場規模の推定（TAM/SAM/SOM）

• 分解：総人口 → ターゲットセグメント → 対象市場 → 到達可能な市場 → 価格帯
• 基準値：国勢調査データ、業界レポート、類似市場、浸透率
• 範囲：楽観的（高い浸透率、プレミアム価格）対悲観的（低い浸透率、割引価格）
• 妥当性チェック：該当分野の上場企業の売上高や、VC による市場規模の推定値と比較します
• 例：E コマースの TAM ＝ 米国の人口 × オンラインショッピングの割合 × 年間平均支出額

パターン 2：インフラストラクチャの容量

• 分解：ユーザー数 → ユーザーあたりのリクエスト数 → リクエストあたりのコンピューティング／ストレージ → オーバーヘッド
• 基準値：類似サービス（Instagram、Twitter）、既知の容量（EC2 インスタンスの制限）、負荷テストデータ
• 範囲：ピーク時（ブラックフライデー）対平均負荷、成長軌道（年間 2 倍対年間 10 倍）
• 妥当性チェック：ユーザーあたりのコストは LTV 未満であるべきです。同規模のパブリッククラウドの請求額と比較します
• 例：必要なサーバー数 ＝（DAU × ユーザーあたりのリクエスト数 × リクエストあたりの処理時間（ms））÷（インスタンスの容量 × 使用率）

パターン 3：人員配置／従業員数

• 分解：必要な作業（機能、チケット、顧客）→ 1 人あたりの生産性 → オーバーヘッド（会議、サポート）
• 基準値：業界ベンチマーク（ユーザー X 人あたりのエンジニア数、顧客 Y 人あたりのサポート担当者数）、チームのベロシティ、採用期間
• 範囲：経験豊富なチーム（高い生産性）対新しいチーム（立ち上がり期間）、積極的なスケジュール（短期集中）対持続可能なペース
• 妥当性チェック：従業員数の増加は売上高の成長曲線に見合うべきです。同規模の同業他社と比較します
• 例：必要なエンジニア数 ＝（ロードマップのストーリーポイント ÷ エンジニアあたりのベロシティ）＋ 20％のオーバーヘッド

パターン 4：財務予測

• 分解：売上高 ＝ ユーザー数 × コンバージョン率 × ARPU、コスト ＝ 売上原価 ＋ 営業／マーケティング ＋ 研究開発 ＋ 一般管理費
• 基準値：コホートデータ、業界の CAC／LTV ベンチマーク、比較対象企業の指標、過去の成長率
• 範囲：強気シナリオ（高成長、効率的な拡大）対弱気シナリオ（低成長、コスト増加）
• 妥当性チェック：規模拡大に伴い、利益率は業界標準に近づくべきです。成長率は永続的な指数関数ではなく、S 字カーブを描くべきです
• 例：2 年目の売上高 ＝ 1 年目の売上高 ×（1 ＋ 成長率）×（1 − 解約率）

パターン 5：影響評価

• 分解：総影響 ＝ 影響を受ける単位数 × 単位あたりの影響 × 期間
• 基準値：排出係数（kg CO2/kWh）、転換率（プログラム → 行動変容）、先行研究
• 範囲：保守的（採用率が低く、効果が小さい）対楽観的（採用率が高く、効果が大きい）
• 妥当性チェック：影響は線形または劣線形（逓減リターン）で拡大するはずです。類似の介入策と比較します
• 例：削減できた炭素量 ＝（乗り換えたユーザー数 × 年間走行距離 × 1 マイルあたりの排出量）− ベースライン

ガードレール

1. 前提を明示する：フェルミ推定はすべて前提に基づきます。前提を明らかにしてください（「年間250営業日と仮定する」「コンバージョン率を約3％とする場合」など）。前提を明示しないと、実際以上に精密な印象を与えてしまいます。

2. 精度ではなく桁を目指す：目標は10^Xであり、X.XXではありません。有効数字1〜2桁に丸めます（47.3ではなく50、2,847,291ではなく3M）。意思決定に精度が必要なら、実際のデータを取得してください。

3. 推定可能な要素に分解する：知識や経験から推定できる数量にたどり着くまで分解します。ある要素について、まだ「どうすれば分かるのか？」と思うなら、さらに分解してください。

4. 複数の方法を使う（三角測量）：異なる分解方法（トップダウンとボトムアップ、供給側と需要側など）で同じ数量を推定します。推定値が3倍以内で一致すれば、信頼度が高まります。10倍以上異なる場合は、どの分解方法に問題があるかを調べてください。

5. 答えに幅を持たせる：楽観的なケースと悲観的なケースを計算し、現実的な範囲を挟み込みます。その範囲内で意思決定が変わらないなら、上下限はさほど重要ではありません。意思決定が変わるなら、より良い推定に投資してください。

6. 現実と照らし合わせて妥当性を確認する：既知の数量と比較し、次元解析を使い（単位が正しく相殺されるか）、極端なケースも確認します（全員がXをしたらどうなるか？物理法則に反しないか？）。

7. 答えが分かっている問題で調整する：検証可能な答えがある問題で練習し、個人的な偏り（過大評価？過小評価？アンカリング？）を特定します。

8. 不確実性の範囲を認める：適切な場合は、推定値を範囲で示します（「ユーザー数は1万〜10万人」「おそらく100万〜500万ドル」など）。

よくある落とし穴：

• ❌ 誤った数値に引きずられる：無関係または偏った出発点を使うことです。誰かに「100万人ですか？」と言われると、そう考える理由がなくても、その数値に引きずられてしまいます。
• ❌ 二重計上：分解の中で同じ数量を2回含めることです（企業に従業員が含まれているのに、企業と従業員の両方を数えるなど）。
• ❌ 単位の誤り：日単位と年単位を混同する、百万と十億を取り違える、通貨換算を誤るなどです。必ず単位を確認してください。
• ❌ 生存者バイアス：成功事例（失敗例を含めず、ユニコーン企業の平均スタートアップ収益など）に基づいて推定することです。
• ❌ 線形外挿：指数関数的な成長（またはその逆）を線形だと仮定することです。成長率は時間とともに変化します。
• ❌ 制約を無視する：物理的な限界（光速を超えられない）、経済的な限界（市場が永遠にGDPを上回る速度で成長することはできない）などです。

クイックリファレンス

主なリソース：

• resources/template.md：前提確認のフレームワーク、分解戦略、見積もりテンプレート、妥当性確認の基準
• resources/methodology.md：アンカリング手法、範囲の設定方法、三角測量のアプローチ、キャリブレーション演習
• resources/evaluators/rubric_estimation_fermi.json：分解、前提、範囲、妥当性確認の品質基準

よく使われるアンカー：

人口統計：

• 米国の人口：約3億3,000万人、世帯数：約1億3,000万、労働力人口：約1億6,500万
• 世界人口：約80億人、都市人口：約55％、インターネット利用者：約50億人

ビジネス：

• Fortune 500の売上高：10万ドル～6,000億ドル（中央値：約300億ドル）
• スタートアップの評価額：シード：約500万～1,000万ドル、シリーズA：約3,000万～5,000万ドル、ユニコーン企業：10億ドル超
• SaaS指標：CAC：約1,000～5,000ドル、LTV/CAC比率：3超、解約率：年5％未満

テクノロジー：

• AWS EC2インスタンス：約1万リクエスト／秒、S3ストレージ：0.023ドル／GB／月
• モバイルアプリ：ユーザーあたり1日約5～10画面、セッションあたり50～100回のAPI呼び出し
• ウェブサイト：セッションあたり約2～3ページ、セッション時間は1～2分

物理的な尺度：

• 人：体重約70kg、1日2,000kcal、睡眠8時間
• 自動車：約25mpg、年間走行距離1万2,000マイル、新車価格3万ドル、寿命20万マイル
• 住宅：約2,000平方フィート、米国の中央値で30万ドル、住宅ローン期間30年

換算係数：

• 1年 ≈ 250営業日 ≈ 2,000労働時間
• 100万秒 ≈ 11.5日、10億秒 ≈ 32年
• 1マイル ≈ 1.6km、1kg ≈ 2.2ポンド、1ガロン ≈ 3.8リットル

分解戦略：

• トップダウン：総人口から始めて絞り込む（米国の人口 → 自動車所有者 → EV購入者）
• ボトムアップ：単位から始めて拡大する（店舗あたりの売上 × 店舗数）
• 率 × 時間：流量 × 期間（1日あたりの顧客数 × 年間日数）
• 密度 × 面積／体積：密度 × 空間（平方マイルあたりの人数 × 都市面積）
• 類似事例によるスケーリング：既知の類似システムを基に、規模に応じて調整する（競合他社の売上 × 自社の市場シェア）

見積もりにかかる一般的な時間：

• 簡単な質問（分解が1～2段階）：3～5分
• 市場規模の推定（3～4段階）：10～15分
• 複雑なビジネスケース（複数の指標、三角測量あり）：20～30分

エスカレーションが必要な場合：

• 意思決定に高い精度が必要（不確実性が2倍未満）
• 範囲を設定しても推定値が2桁を超える幅に及ぶ
• 妥当な分解の道筋がない（未知の要素が多すぎる）
• 関係者が信頼区間と統計的な厳密さを求めている → データ収集、詳細なモデリング、専門家への相談に取り組みます

必要な入力：

• 質問（何を推定するか？単位は？対象範囲は？）
• 意思決定の背景（この推定値はどの意思決定に関わるか？必要な精度は？）
• 既知のアンカー（関連する量のうち、何がわかっているか？）

生成される出力：

• estimation-fermi.md：質問、分解、前提、計算、範囲、妥当性確認、三角測量、信頼度の範囲を含む最終推定値