pmo.run

なぜAIはあなたの見積もりミスから学べないのか

2026年3月24日

「認証まわりのタスク、だいたい見積もりの1.3倍かかるんだよね」

どの現場にも、こう言えるベテランがいる。10年の経験から体感で分かっている。問題は、その知見がその人の頭の中にしかないことだ。

属人化の本質は、暗黙知が個人に閉じ込められていることにある。見積もりの補正値も例外ではない。ベテランPMが退職したら、その「1.3倍」という知見は消える。後任は同じ失敗をゼロからやり直す。

この記事では、その暗黙知を数式に変換する方法を説明する。AIチャットではなく、決定論的な数学で。

見積もりデータは眠っている

SIerのどのプロジェクトにも、予定と実績の工数データがある。Excelの奥底に。WBSの完了報告書に。Redmineのチケット履歴に。

ほとんどの組織は、このデータを振り返りに使わない。使っても「平均1.2倍でした」で終わる。

平均値の問題は3つある。

必要なのは、観測するたびに賢くなるシステムだ。それがベイズ更新である。

ベイズ更新の仕組み

考え方はシンプルだ。タスクが完了するたびに「遅延係数」を計算する。見積もり10日、実績13日なら、遅延係数は1.3。

この遅延係数の「真の値」をガウス分布でモデル化する。最初は「よく分からない」という広い分布（事前分布）から始めて、観測ごとに更新する。

更新規則は精度（分散の逆数）を使う。精度は足し算できる：

τ_事後 = τ_事前 + τ_観測

事後平均は、精度で重み付けした平均：

μ_事後 = (τ_事前 × μ_事前 + τ_観測 × r) / τ_事後

これが共役正規-正規更新だ。観測ごとに分布が狭くなる。n番目の事後分布が、n+1番目の事前分布になる。知識が複利で蓄積する。

Pythonでは6行で書ける：

def update_belief(prior, observations, observation_noise=0.15):
    noise_variance = observation_noise ** 2
    tau_obs = 1.0 / noise_variance

    mu = prior.mean
    tau = 1.0 / prior.variance

    for obs in observations:
        r = obs.actual / obs.estimated  # 遅延係数
        tau_new = tau + tau_obs
        mu_new = (tau * mu + tau_obs * r) / tau_new
        tau = tau_new
        mu = mu_new

    return Posterior(mean=mu, variance=1.0 / tau)

ニューラルネットワークもGPUも不要。純粋な数学だ。

実例：認証タスクの見積もり補正

あるSIer案件で、認証関連タスクが6件完了したとする。いずれも見積もりより長くかかった：

タスク見積もり実績遅延係数
ログインフロー5日7日1.40
OAuth連携10日13日1.30
セッション管理3日4日1.33
トークン更新8日10日1.25
RBAC実装15日19日1.27
MFA対応6日8日1.33

「よく分からない」という事前分布 N(1.0, 0.25) から始めて、1件ずつ更新する：

観測後事後平均標準偏差σ95%信用区間
1件目1.3670.144[1.09, 1.65]
2件目1.3350.104[1.13, 1.54]
3件目1.3340.085[1.17, 1.50]
4件目1.3140.074[1.17, 1.46]
5件目1.3050.067[1.17, 1.43]
6件目1.3090.061[1.19, 1.43]

6件の観測で、システムは確信を持つ。認証タスクはPERT見積もりの約131%かかる。誤差±6%。95%信用区間は [0.02, 1.98] から [1.19, 1.43] に収束した。

これを次の見積もりに適用する。PERTが12日と言ったら：

同じチームのインフラタスクは遅延係数1.027。同じPERT計算式、同じチーム。しかし10日の見積もりに対して、認証タスクはインフラより2.8日多くかかる。

ベテランPMの「認証は1.3倍」という体感値が、数学的に裏付けられた。しかも、この数字は誰でも再現でき、チームを超えて共有できる。属人化していない。

なぜLLMにはこれができないのか

2026年、Qiu et al. がNature Communicationsに発表した研究で、LLMが確率的推論——特に逐次的なベイズ信念更新——をできるかどうかを検証した。

核心的な発見：LLMは1回の観測で学習が頭打ちになる。1つの証拠は取り込めるが、複数の観測にわたって信念を段階的に洗練する——つまり精度の蓄積——はできない。

LLMの動作原理を考えれば当然だ。推論のたびにステートレスで実行される。内部に確率分布を保持して徐々に狭めていくメカニズムがない。ベイズ推論に「見える」テキストは生成できるが、実際の精度蓄積は起きていない。

2026年のStanford Digital Economy Labの論文も別の角度からこれを裏付ける。FOMC（米連邦公開市場委員会）の政策決定シミュレーションで、LLM審議トラックとモンテカルロ/ベイズトラックを並列に走らせている。我々のモジュールとまったく同じ共役正規-正規更新式を使って。LLMは自然言語での審議を担当し、ベイズトラックは数学を担当する。どちらも相手の仕事をしない。

2層アーキテクチャ

両方の論文から、そして我々自身の設計から浮かび上がるパターンは明確だ。

第1層：決定論的な数学。 ベイズ更新、PERT推定、EVM指標。純粋なPython。LLMなし。監査可能で、再現可能で、蓄積する。精度の蓄積はここに住む。

第2層：LLMによる解釈。 モデルは構造化された事後分布を読む——「遅延係数1.31、σ=0.061、信頼度：良好」——そして自然言語の洞察を生成する。「認証タスクは一貫して約30%超過しています。認証系の見積もりには3日のバッファを加えるか、OAuth連携パターンが繰り返される原因を調査してください。」

LLMは境界で価値を発揮する。数字を意思決定に変換し、推奨を生成し、文脈に沿って異常を説明する。しかし数字そのものは決定論的ロジックから来なければならない。

# 第1層：決定論的 — これは正確でなければならない
posterior = update_belief(prior, observations)

# 第2層：LLMによる解釈 — 構造化された出力を読む
prompt = f"""
ベイズ分析の結果：
- 遅延係数：{posterior.mean:.3f}
- 信用区間：{posterior.credible_interval_95}
- 観測数：{posterior.n_observations}件

プロジェクトマネージャーは何をすべきか？
"""

LLMは更新式に触れない。結果を読むだけだ。

その先にあるもの

ベイズ見積もり補正モジュールは、logicツールキットの一部としてオープンソースで公開している。Performanceファミリーの4番目のモジュールだ。PERTが工期を見積もり、ベイズ補正がPERTの誤差を学習し、次に来るモンテカルロシミュレーションがその不確実性をプロジェクト全体のスケジュールに伝播させる。

主な機能：

数学はMITライセンス。APIは稼働中。特定の業界向けの現場補正係数——それはコンサルティングレイヤーだ。

あなたのAIツールが見積もり履歴から学ばずに単一値を出しているなら、最も価値のあるデータをテーブルに置き去りにしている。解決策はプロンプトの改善ではない。その下にある決定論的モジュールだ。

ベイズ見積もり補正モジュールは github.com/lemur47/logic で公開中。数学的定式化は、Kazinnik & Sinclair (2026) のFOMC政策シミュレーションで検証された共役正規-正規フレームワークに基づく。LLMのベイズ更新における限界は Qiu et al. (2026) がNature Communicationsで確立した。

PERTツールを試す

現実の調整がどう見積もりを変えるか、試してみてください。

PERTツールを試す →