LLM時代のフェルミ推定は「勘」より「監査可能性」が価値

LLM時代のフェルミ推定は「勘」より「監査可能性」が価値 cover image

フェルミ推定って、雑に言うと「ざっくり妥当な数字を出す技術」です。市場規模、工数、必要人員、処理能力みたいな話で、まだ正確なデータが揃っていない時にかなり便利です。

ただ、LLM（Large Language Model: 大規模言語モデル）にこの手の仕事を任せると、別の問題が出ます。数字自体はそれっぽく見えても、「何を根拠にその数字になったのか」が残らないと、あとから見直せません。

そこで、自作スキル fermi-estimation を作りました。狙いは、フェルミ推定をうまくやることそのものではなく、推定結果をあとから監査できる形で残すことです。ここで言う監査可能性とは、あとから見直せる、反論できる、再計算できることです。

何がつらいのか

人間が雑に見積もるだけなら、紙やスプレッドシートでも十分です。でも、LLMやAIエージェント（AI agent: LLMが外部ツールを使って作業を進める仕組み）に概算をやらせると、次の3つがすぐ問題になります。

仮定が暗黙のままで、数字だけが出てくる
どの入力が一次情報で、どこからが推測なのか分からない
あとから条件を変えて再計算したい時に、元の思考過程を再利用できない

この状態だと、数値の精度以前に運用がしんどいです。特に仕事で使うなら、「当たっていそう」より「どこが怪しいか説明できる」の方が大事です。

fermi-estimation でやりたかったこと

fermi-estimation は、フェルミ推定のワークフローをエージェントに持たせるスキルです。 README にある説明を要約すると、以下を重視しています。

推定対象のスコープを先に固定する
いきなり仮定を置かず、まず一次情報を探す
low / base / high で幅を持たせる
最後に sanity check（妥当性確認）と sensitivity analysis（感度分析）を入れる

個人的に重要だと思っているのは、「推定すること」より「推定の材料と弱点を外に出すこと」です。この方針なら、数字が少し外れても改善できます。逆に、根拠が残っていないと改善のしようがありません。

このスキルは「まず推定しない」

少し逆説的ですが、fermi-estimation はフェルミ推定スキルなのに、まず推定しない設計にしています。

SKILL.md では、先に exact lookup（その場で直接調べられる一次情報の確認）を優先し、それでも足りない時だけ推定に進む方針です。たとえば以下のようなものは、推定より先に探すべきです。

公式統計
企業の公開資料
料金表
規制当局や公的機関のデータ

これは地味ですが大事です。「調べれば分かる数字」を推定してしまうと、もっともらしい誤差をわざわざ作るだけだからです。

フェルミ推定は、データが無い時の代用品ではありますが、同時に 不完全な情報を前提に意思決定するためのフォーマット でもあります。なので、推定を乱用しないこと自体が品質管理になります。

どんな形で監査可能にしているか

fermi-estimation には、補助スクリプトとして factor_model.py を入れています。これは additive（加算）、multiplicative（乗算）、sum-of-products（セグメントごとの積を足す形）のモデルを扱うためのものです。

大きいポイントは、各要素に値だけでなく文脈を持たせられることです。

low / base / high
basis_type（sourced / derived など、どの種類の根拠か）
source や source_url
geo / period / currency
sanity_checks

これで何が嬉しいかというと、「その数字はどこから来たのか」と「どの前提が効いているのか」を一緒に保存できます。単に最終合計だけ出すより、あとで圧倒的に扱いやすいです。

実際にどう使うか

まずは README の通り、npx skills add でスキルを入れます。 Node.js が入っていて npx が使える前提です。

1
npx skills add tumf/skills --skill fermi-estimation

次に、細かい試算を再利用したいなら、Python （汎用プログラミング言語）の補助スクリプトをそのまま叩くのが楽です。以下の例は、「月間のサポート対応工数」をざっくり見積もる最小例です。

この例でやっていることは単純で、

1日あたりの問い合わせ件数
1件あたりの平均対応時間
営業日数

を掛けて、月間の必要時間を出しています。それぞれに low / base / high を置いているので、単一の数字ではなく幅つきで見られます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
python3 fermi-estimation/scripts/factor_model.py --input '{
  "name": "Monthly support workload",
  "mode": "product",
  "factors": [
    {
      "name": "tickets_per_day",
      "low": 12,
      "base": 18,
      "high": 25,
      "unit": "tickets/day",
      "basis_type": "derived",
      "source": "last quarter average"
    },
    {
      "name": "minutes_per_ticket",
      "low": 8,
      "base": 12,
      "high": 18,
      "unit": "minutes/ticket",
      "basis_type": "derived",
      "source": "sampled support logs"
    },
    {
      "name": "business_days",
      "low": 20,
      "base": 22,
      "high": 23,
      "unit": "days/month",
      "period": "month",
      "basis_type": "sourced",
      "source": "calendar"
    }
  ],
  "sanity_checks": [
    {
      "label": "Headcount reality check",
      "result": "If base workload exceeds 80 hours, one part-time support owner will likely be tight."
    }
  ]
}' --format markdown

このコマンドは、low/base/high の合計だけでなく、入力表、計算過程、妥当性確認をまとめて返します。出力イメージとしては、例えばこんな感じです。

1
2
3
- Best estimate: about 57k
- Plausible range: about 23k to about 104k
- Biggest uncertainty: Monthly support workload > minutes_per_ticket

「何を変えると結果がどれだけ動くか」も見えるので、次にどのデータを取りに行くべきか判断しやすいです。

ざっくりした数字でも、見るべきは最終値より支配変数

fermi-estimation には sensitivity analysis（感度分析: どの入力が結果に大きく効くかを見る手法）や、相関つきの Monte Carlo （モンテカルロ法: ランダムサンプリングを繰り返して分布を見る方法）も入れています。

ここで大事なのは、「幅があります」で終わらせないことです。本当に知りたいのは、たとえば次のどれかです。

どの仮定が一番結果を壊すか
どの変数は雑でもよくて、どの変数はちゃんと調べるべきか
セグメント間の相関を入れると悲観側・楽観側がどこまで広がるか

実務では、全部を高精度にすることはまず無理です。なので、「まず何を観測するべきか」を決めるために推定を使う、という順番の方が自然だと思っています。

LLM時代に価値があるのは、答えを出す速さよりレビューしやすさ

LLMは、もっともらしい文章と数字をかなり速く出せます。だからこそ、これから価値が出るのは「答えを出す能力」だけではなく、「答えをレビューしやすい形にしておく能力」だと思っています。

fermi-estimation でやりたかったのは、まさにここです。

数字を出す
前提をラベル付きで残す
ソースの強さを区別する
幅を持たせる
妥当性確認で雑な破綻を見つける
感度分析で、次に取りに行くデータを決める

フェルミ推定は昔からある手法ですが、LLMと組み合わせると「思考の監査ログを作る道具」としてかなり相性が良いです。この使い方なら、単なる当て勘よりずっと実務に寄せられます。

まとめ

フェルミ推定は、正確な数字を当てるためだけのものではありません。不確実な状況でも、どの前提で、どのくらいの幅で、どこが弱いかを見えるようにするための道具です。

LLM時代だと特に、最終値のそれっぽさより、監査可能性 の方が価値になります。あとから見直せる、反論できる、改善できる、という性質の方が長持ちします。

興味があれば、まずは次の順で触るのが早いと思います。

GitHub リポジトリで README.md と SKILL.md を読む
npx skills add でスキルを入れる
小さい見積もりを1つ選んで、factor_model.py で low/base/high を付けてみる
出てきた結果から、どの入力を一次情報で置き換えるべきか確認する

Fragments of verbose memory

冗長な記憶の断片 - Web技術のメモをほぼ毎日更新