見積りを壊す3つのバイアス:AIも私も外す

Claude Code に「このバグ、どれくらいかかりそう?」と聞いて「10分くらいで直ります」と返ってくる、見覚えのある光景があります。

実際には、その「10分」が平気で数時間に膨らみます。

スプリント見積りが外れる理由は、Claude が嘘をついたからではありません。その「10分」を無批判に受け取って、自分の頭にあった見積りをその数字で上書きするからです。1979年に Kahneman と Tversky が「計画の誤謬」を名付けて以来、私たちが見積りを外す仕組みはずっと研究されてきました。AI 時代の新しさは、昔からある3つのバイアスが同時に発火するようになったところにあります。見積りを外す装置が増えたこと、ではありません。計画の誤謬。楽観バイアス。自動化バイアス。この3つが、AI が「X 分」と宣言した瞬間に一緒にズレます。

3つのバイアスが見積りを壊す構造

バイアス1: 計画の誤謬

Kahneman と Tversky が1979年に名付けたバイアスです。「タスクを完了するのに必要な時間と費用を、系統的に過小評価する」癖のことを指します。厄介なのは、過去に何回見積りを外しても、次の見積りで同じ失敗を繰り返すところです。「今回は違う、ちゃんと見積もった」という感覚そのものが計画の誤謬の一部です。

なぜ起きるのか

人間は見積りをするときに「全部うまく行くシナリオ」を起点にします。PR の手戻り、CI/CD の失敗、要件の変更、メンバーの急な欠席。「何かが起きるシナリオ」はそれぞれ個別の発生確率は低いですが、少なくとも1つは高い確率で起きます。脳は、低確率のイベントを複数積み上げて確率を直観的に合算するのが苦手です。

エンジニア特有の計画の誤謬は、次のあたりに現れます。

「コードを書く時間」だけ見積もる (設計・テスト・レビュー対応・ドキュメント更新・デプロイが抜ける)
「1発でコードが動く」前提 (デバッグ時間を予算化しない)
依存タスクの遅延を考慮しない (他チーム API の遅れ、デザインのフィードバック待ち)
context switch のコストを無視 (「午前2h + 午後2h = 4h 作業」と見積るが、会議・Slack・割り込みで実効時間は半分以下)

対策: Reference Class Forecasting

Kahneman 本人が提案している対策です。目の前のタスクの詳細からは見積りません。過去の類似タスクの実測データから引きます。

直近6ヶ月の類似タスクの実測時間を一覧化する
中央値をベースラインにする (平均でなく中央値、外れ値の影響を減らすため)
状況補正は ±20% の範囲内に収める

チケットツールに「見積り」と「実測時間」の両方を記録する運用を続けていれば、Reference Class のデータセットが貯まります。半年続ければ、あとは中央値を引くだけです。

バイアス2: 楽観バイアス

計画の誤謬と重なりますが、より広い領域に効きます。「自分についての将来の出来事を、現実より好ましい方向に予測する」癖です。

エンジニアの楽観バイアスは、見積り以外の場面でもよく顔を出します。

「このリファクタリング、既存機能には影響しないはず」
「このライブラリのアップデート、breaking change はないはず」
「staging で動くから本番でも動くはず」

楽観バイアスの危険は、リスク評価そのものを歪めることです。「たぶん大丈夫」が判断の前提に入ると、テスト計画・ロールバック手順・バッファがどれも緩くなります。

対策: プリモーテム

心理学者 Gary Klein が提案した「プリモーテム (Pre-mortem)」が実務的です。

ポストモーテム (事後検証) は失敗の後に行うものですが、プリモーテムはプロジェクトが始まる前に行います。手順は単純です。

「このプロジェクトは大失敗した」と仮定する
チーム全員で「なぜ失敗したか」を考える
挙がった失敗理由ごとに対策を考える

「すでに失敗した」という前提から始めることで、楽観バイアスの重力から脱出できます。「何かが起きるシナリオ」を想像するのは楽観バイアスが効いているときには難しいですが、「すでに起きた失敗の原因を推定する」というフレームに切り替えると、脳は驚くほど多くのリスク要因を挙げられます。

バイアス3: 自動化バイアス

ここが AI 時代に効いてくる3つめです。1990年代の航空計器の研究から名前が付いたバイアスで、「自動化されたシステムの出力を過度に信頼する癖」のことを言います。

Claude Code や Cursor が「このタスクは約10分です」と返した瞬間、私たちの頭の中では3つのことが同時に起きます。

「分析的で感情のないシステム」からの見積りとして受け取る
自分でしていたはずの見積りが、その数字で上書きされる
「もう考えた」という感覚で、自分の検討がスキップされる

自動化バイアスは他の2つを増幅する

自動化バイアスの厄介な性質は、計画の誤謬と楽観バイアスを増幅することです。AI の見積りは学習データ上の過去タスク (「全部うまく行ったシナリオ」で記録されがち) から引かれるため、計画の誤謬をすでに内包していて、それを人間が無批判に受け取ることで、計画の誤謬が二重にかかります。楽観バイアス側も、「分析的なシステムが大丈夫と言った」で強化されます。

対策: 2つの見積りを並べる

やり方は単純です。Claude Code の見積りと、自分が先に出した見積りの両方をチケットに記録し、タスク完了後に 実測 ÷ 見積り の比率をそれぞれ計算する。計画の誤謬と自動化バイアスの重ね合わせから予想されるのは、両方の比率がズレること、しかもズレ方の方向と大きさが違うことです。

重要なのは手順です。見積りを出すときに先に自分で書いて、それから AI に聞く。順番を逆にすると、自分の見積りが AI の数字で上書きされます。

planning poker の全員同時公開 (reveal simultaneously) と同じ構造です。planning poker の効果は、アンカリングの除去にあります。見積り精度の向上、ではありません。AI 相手にも同じ仕掛けが要ります。

3つのバイアスの重ね合わせ

実際のスプリント見積りでは、3つのバイアスが同時に効きます。

PM が「2週間でできる?」と聞く (アンカリング: PM の2週間が頭に入る)
Claude Code が「ざっくり10日程度です」と返す (自動化バイアス: AI の数字で上書き)
自分で「厳しいけど10日ならいける気がする」と判断する (楽観バイアス)
「全部うまく行ったら」のシナリオで時間を積み上げる (計画の誤謬)

結果: 見積り10日、実測20日。

構造を知っていれば、「10日と思ったら20日と数える」というヒューリスティックが使えます。粗い経験則です。計画の誤謬の研究が繰り返し確認してきた「見積りは系統的に実測より下に出る」という知見と整合します。

見積り誤差の累積: 4つのステップで誤差が重なる

見積り誤差を測るためのスプリント運用

実測の運用はシンプルです。

タスクごとに2つの見積りを記録: 自分の見積り (AI に聞く前) と AI の見積り
タスク完了時に実測時間を記録し、実測 ÷ 見積り の比率をそれぞれ計算
20タスクくらいで個人の係数が出る (自分の係数と AI の係数が別々に出る)
以後のコミットメントで、両方の係数を乗せる

これは Reference Class Forecasting を「自分」と「AI」の2つに拡張した運用です。「生の見積り」をコミットメントに使うのを止めて、「係数を乗せた見積り」でコミットする。

見積りをゼロ化はできません。ただ、「自分の見積りがどちらに傾くか」「AI の見積りがどちらに傾くか」を数字で知っているだけで、扱い方はまるで変わります。「10分」と言われてそのまま走り出す前に、2つの見積りが別々にズレる構造を思い出す。それだけでスプリントの終わりの顔つきは少し変わります。

AI時代の新バイアス3選 — 自動化バイアスで見逃したバグと3ヶ月の実測対策 — 同じ自動化バイアスを「見逃したバグ」軸で切った別記事。本記事は見積り誤差軸でした
午後3時、あなたのコードレビュー承認率はほぼ0%になる — 見積り以外にも認知の劣化が判断を壊す話

本記事の内容は『エンジニアの心理トリック大全』の第4章「見積もりを狂わせる3つのバイアス」を素材に、AI 時代の自動化バイアスを前面に出して再構成したものです。計画の誤謬・アンカリング・楽観バイアス・自動化バイアスの技術者向け実装編を含む全15章をエンジニアの心理トリック大全にまとめています。