ツールの断片化がもたらす意思決定リスク：同じ計算が3つのツールで行われ、回答が8.7%乖離する

ステアリングコミッティは、ある数字を根拠に予算を承認する。その数字は式から出てきたもので、式はツールが計算したものだ。そして組織が複数のツールを使っているなら、数字は1つではない。複数あり、その差は自分から名乗り出てはくれない。

私たちは自分たちのデータの中に、まったく別の作業をしている最中にそれを見つけた。

要約：同じ数字を複数のツールが持つとき、意思決定の対象は「誰も幅を測っていない範囲」になる

結論と推奨。 意思決定に届くすべての数字について、正本を1つ決めること。他の実装は、その正本から生成した検証データで突き合わせること — 境界値を意図的に含めて。そして、どの集計方法を使ったかを報告のたびに明示すること。これだけで、食い違いは議論ではなく参照で片付くようになる。それまでは、ステアリングコミッティの前にあるのは数字ではなく範囲であり、その幅を知っている人は室内に1人もいない。

問題。 同じ1つの事実を、管理台帳が持ち、表計算が持ち、ダッシュボードが持ち、業務アプリが持ち、PMO が手作業で転記した資料が持ち、そしていまは状況要約を頼まれた AI エージェントも持っている。どれも断片であり、どれも正本ではなく、突き合わせる仕組みもない。突き合わせていない断片の上で下した判断は、口調がどれだけ自信に満ちていても、すでに事実から離れている。

分析。 自分たちの見積りと実績の組29件を、自分たちの較正ツールに通した。28件は台帳と 0.011 以内で一致した。1件だけ 8.7% ずれた。どの実装にもバグはない。端数処理の「方式」の違いである。さらに、端数処理を一切必要としない16%のずれもあった。見積り傾向は、どの集計を取るかで 1.12倍 とも 1.30倍 とも読め、どちらも正しい。

評価。 半日の作業1件なら些細な話だ。ポートフォリオの積み上げでは「1割ほど超過」と「3割ほど超過」の差になり、この2文は違う予算を生む。しかも算術はフィードバックループの内側にあるため、ずれは1度報告されて終わらない。ループを回って戻り、データとして学習し直される。連鎖は、間違いを深めながら自信を増していく。

問題：計算の連鎖には実装が複数あり、誰も突き合わせていない

重要な数字を1度しか計算していない組織は、ほとんどない。ある数値は表計算の計算フィールドで生まれ、ダッシュボードのために BI ツールが再計算し、同じデータを使うアプリケーションがもう1度計算し、いまでは状況をまとめてほしいと頼まれた AI エージェントが4度目の計算をする。1つの定義に対して4つの実装が、別々の人によって、別々の言語で、別々の時期に保守されている。

そしてたいてい5つ目があり、これは誰も数に入れない。報告資料を作る PMO の手作業だ。台帳から数値を表計算に写し、列幅に合わせて丸め、元のシステムが計算したことのない小計を作り、資料に貼る。これも立派な実装である。セル参照とキー操作で書かれ、誰のレビューも通らず、報告のたびに一から作り直される。

これが放置される理由は、誰もが犯しやすい分類上の間違いにある。表計算や台帳の計算フィールドは、実装に見えない。 データに見える。突き合わせ対象の一覧に載らないのは、それがシステムの顔をしていないからだ。私たちは Python と TypeScript の間ではこの教訓をすでに学び、自社の技術規約にも書いていた。それでも台帳を見落とした。理由はまさにこれだった。

生き延びるもう1つの理由は、境界値がめったに出ないことだ。端数処理の方式だけが違う2つの実装に現実的な値を100件通せば、99件は一致する。100件に1件しか現れない不具合は、不具合には見えない。ばらつきか、誰かが資料に打ち間違えたかのように見える。

算術の下にあるのは、インテリジェンスの問題である

小数点から少し離れて眺めると、これはデータを意思決定に変える過程の問題であり、まさに PMO の本業にあたる。データは文脈に置かれて情報になり、情報は突き合わされ理解されて知識になり、意思決定はその知識の上に載るはずのものだ。断片化はこの梯子を最初の段で折る。複数のツールが同じ事実の断片をそれぞれ持ち、どの2つも厳密には一致しないとき、知識を組み立てるための「突き合わせ済みの現状」がどこにも存在しない。

そのときステアリングコミッティに届くのは、筋の通った物語である。内部では整合し、自信を持って語られ、事実からどれだけ離れているかは誰も知らない。これは目に見える形では失敗しない。物語が首尾一貫しているからだ。一貫性は、根拠の代わりにそこにあるものである。その上で下された判断は、証拠の語彙を保ったまま、証拠から離れている。

経営層や事業責任者、助言する立場のコンサルタントにとって、この露出は端数処理の違いとしては現れない。報告に混入した統計の誤りとして、持っていない精度を主張する AI の要約として、そしてその両方に基づく戦略判断の誤りとして現れる。 3つの別々の事故報告になるが、根は1つだ。1つの定義に複数の実装があり、その間に権威が定まっていないことである。

見積りがこの問題の最も痛い場所である理由は、はっきり書いておく価値がある。経営層は、多めに積んだのに結局遅れる見積りを長く見てきた。安全のために膨らませた数字、それでも超過する作業、対応として増える人員と日常化する火消し。外部に委託する形では、上積みは供給側が単独で負うリスクへの合理的な備えでもある。誰かの怠慢ではなく、仕事の買い方が生む構造であり、その帰結として提示工数と実際の工数は「割合の差」ではなく「倍数の差」になりうる。見積りは予算の周期、納期、市場投入の時機と直結しているので、膨らんだ見積りは無害な余裕ではない。金と日付を動かす。つまり見積りという計器は、資料のなかで最も信用されない数字として室内に持ち込まれる。その計器が静かに偏っていることは、最も避けねばならない事態だ。

そしてこの問題は、計算が AI エージェントに移るにつれて和らぐどころか鋭くなっている。エージェントがデータを読み、数値を計算し、説明文まで一息に書くとき、算術はその連鎖のなかで最も検査されない層になる。レビューする側は文章を読む。読めるからだ。数字のほうは、すでに整形され、すでに文の中に収まり、すでに「計算された」という権威をまとって届く。LLM の出力を監査する時代において、算術は最も検査が薄く、最も信用が厚い場所だ。

分析：同じ1件に、2つの正解、1.15 と 1.25

私たちはベイズ推定による見積り較正の層を製品として出しているが、つい先ごろまで、それは自分たちのデータを1度も見たことがなかった。ログは0件のまま、台帳のほうには何年分もの見積りと実績の組が入っていた。そこで読み込ませた。完了した29組すべてを、台帳から取り出して入れた。

主要な結果は安心できるものだった。

遅延係数が 1.0 を下回るのは、見積りが過大だという意味だ。作業は言ったより速く終わる。1件あたり約 1.12倍 の過大評価になる。分類別では次のとおり。

次に、1件ごとの比率を台帳側の同等の列と突き合わせた。28件は 0.011 以内で一致した。1件だけ、しなかった。

境界値と、それを割る2つの筋の通ったやり方

その1件の楽観値・最頻値・悲観値は 0.05、0.1、0.3 セッションだった。PERT の期待値は (O + 4M + P) / 6 なので、

(0.05 + 4(0.1) + 0.3) / 6  =  0.75 / 6  =  ちょうど 0.125

0.125 は境界値だ。0.12 と 0.13 のちょうど中間にあり、しかも2進の浮動小数点が誤差なく表せる数少ない小数の1つなので、この境界は浮動小数点の副作用ではなく本物である。

• 台帳は0から遠ざかる側に丸める。学校で習うほうの四捨五入だ。0.125 は 0.13 になる。
• Python は偶数丸めをする。IEEE 754 の既定で、何度も丸めたときに上振れが積み上がらないよう選ばれている方式だ。0.125 は 0.12 になる。
• TypeScript の移植版は 0.13 に至るが、経路が違う。100倍して丸め、また割り戻している。ここでは台帳と偶然一致するが、それでも誤りだ。桁をずらす操作は、元の浮動小数点が持っていなかった境界値を作り出してしまう。

実績は 0.15 セッションだった。したがって同じ1件の較正比は、

0.15 / 0.13 = 1.15        0.15 / 0.12 = 1.25

端数処理の方式だけで 8.7% の差が出る。しかも丸めそのものより差が大きい。割る前に丸めたからだ。分母の小数第2位1桁のずれが、答えの1割近くにまで育っている。

ここで PERT 自体が何を持ち込んでいるかにも触れておきたい。3点見積りは分布についての判断であり、(O + 4M + P) / 6 はそれを1つの期待値に畳み込む。その値を小数第2位まで報告することは、元の判断が持っていなかった精度を主張することでもある。だからこそ小数第2位は、3つのツールの間で自由に食い違えた。担えない重さを担っていることに、誰も気づかないまま。

誰が見つけ、なぜ今まで誰も見つけなかったのか

どう見つかったかには、役割分担が効いている。29組は人が打ち直したのではない。エージェントが台帳から読み出し、較正ツールに読み込ませ、そのうえで自分の出力を台帳の同等の列と突き合わせた。この最後の一手が発見を生んだ。算術に明るかったから見つけたのではなく、自分の仕事を別の情報源と照合したから見つけたのである。

そして同じ理由が、長く見つからなかった説明にもなる。3つの実装のうち2つは、そもそも誰にもコードとしてレビューされていない。計算フィールドは画面を作った人がブラウザ上で設定するもので、差分もテストもレビュアーもなく、自分がソフトウェアを書いているとは思っていない人でも編集できる。同じことが、AI エージェントが書き、人がまとめて承認するコードにも当てはまり始めている。

端数処理がまったく関係しないずれ

この突き合わせの最中に、2つ目の、より大きな差が出てきた。こちらは計算精度の話ですらない。

• 1件ごとの比率の平均：0.891 — 約 1.12倍 の過大評価。すべての件を1件として数える。
• 合計同士の比（実績 16.15 に対し見積り 21.02）：0.768 — 約 1.30倍 の過大評価。大きな案件の影響が支配的になる。

どちらも正しい。答えている問いが違うのだ。「典型的な見積りはどれだけ外れるか」と「この一連の作業全体でどれだけ外れたか」である。どちらを使ったかを示す印はどこにもなく、同一のデータから 16% 離れた見出し数値が出る。私たちは以前「約 1.4倍」という数字を社内で回していたが、それは3件の観測から出たもので、どちらの尺度で見ても過大だった。

評価：算術はフィードバックループの内側にあるので、1度きりのずれで終わらない

これを端数処理の細部として片付けたくなる。そうしないほうがよい理由は構造にあり、層を順に見ていけば見えてくる。

出来事は、1件の較正比が2つのシステムで食い違ったことだ。

パターンは、食い違いが境界値のときだけ起きることだ。だから全体としては健全に見え、個別の件で外れる。29件中28件が一致することは、正しさの証拠ではない。故障の出方がまれだという証拠であり、それは別の、そしてずっと安心できない主張である。

構造はその下に3つ同時にある。1つの定義に対する3つの実装があり、それらを互いに突き合わせる検証用データがないこと。正本が決まっておらず、どの答えが勝つかの規則が存在しないこと。そして妥当な集計方法が2つあり、どちらを報告するかの取り決めがないこと。

前提となる考え方は、その3つすべてを生んだものだ。式は式にすぎない、端数処理は見た目の話であって論理ではない、台帳の設定欄はコードではなくデータである — という3つである。

これが技術者ではなくステアリングコミッティの関心事である理由は、この算術が置かれているループにある。見積りが意思決定に使われる。決定が実績を生む。実績が較正に入る。較正が次の見積りを調整する。算術層の偏りは1度きりの誤報ではない。ループを回って戻り、次の見積りを訓練する。 静かに一方向へ丸め続ける連鎖は、実際より較正が良好だと言い続け、標本が増えるほど自信を持ってそう言うようになる。

この図では2つのものが増幅しており、分けて考える価値がある。1つ目は算術の増幅だ。1件のずれが小計のずれになり、ポートフォリオの積み上げのずれになり、そこから導かれる予備費のずれになる。2つ目はもっと厄介で、足し算ではなく学習である。ループが1周するたびに、ずれた数値が観測値として扱われる。計器は誤って報告しているだけでなく、自分の誤りで訓練されている。報告される信用区間は、間違った値のまわりで狭くなっていく。

ここから、てこの効き方の順序が決まる。該当する数値を直すのは最も弱い介入で、その数値以外には何も買えない。回帰テストを足すのはましだが、思いついた場合しか捕まえられない。正本を定めるのはさらに強い。以後の食い違いが議論ではなく参照で片付くようになるからだ。最も強いのは、台帳の計算フィールドは実装ではないという前提そのものを変えることだ。そもそもそれが、突き合わせ一覧から漏れた原因だった。

リスクの見立ても、そこから直に出る。半日の作業1件での 8.7% はばらつきだ。同じ不具合がポートフォリオの積み上げ、予備費の算定、あるいは役員会に報告する信頼区間の上で働けば、それは予算の1行になる。しかも系統的ではなくまれに起きるので、ある報告期には現れ、別の期には現れない。読む側にはそれが計器の不良ではなく、実行のばらつきに見える。

提言：正本を定め、それに対して実装を突き合わせ、どの統計量かを明示する

もう1度やるとしたら、この順序で4つを行う。

1. 正本を明示的に決める。 最も精度が高いものでも、最も新しいものでもない。権威があるものだ。私たちの場合は台帳である。数字が入力され、レビューされ、実際に仕事を回すのに使われる場所だから、定義上そこが境界値を制する。それ以外は、自社の計算ライブラリを含めてすべて派生的な見方だ。この1文だけで、端数処理の標準を誰も議論せずに 1.15 対 1.25 の問いが片付く。実際、台帳の 1.15 が採用され、ツールの 1.25 が派生値となった。

2. 正本から生成した検証用データで実装を突き合わせる。 2つの実装を並べて読むのではない。その方法はもう2度失敗している。小数の桁数と丸めの方式は、紙の上ではよく似て見えるからだ。境界値を意図的に含めて、権威のあるシステムから事例を生成し、他の実装がそれを再現することを検証する。境界値は現実的な標本データには十分な頻度で現れないので、偶然に任せず、こちらから置いてやる必要がある。

3. どの統計量かを毎回明示する。 1件ごとの比率の平均と、合計同士の比は、どちらも正当で、これからも永久に違う見出し数値を出し続ける。突き合わせて一致させるのではなく、報告の中で名前を付ける。一致させるものは存在しない。違う問いへの答えだからだ。

4. 各層に仕事を1つだけ持たせ、テストは境界に置く。 私たちに合った役割分担は次のとおりだ。

• 台帳は、正本であり、参照であり、教材である。 見積りと実績はそこにだけ入力する。連鎖のなかで意図的に最も賢くない部品にしてある。
• 数理ライブラリとその MCP サーバーは、計算である。 式とベイズ更新を持ち、数字の意味については何の意見も持たず、いつでも正本から作り直せる。この性質は主張ではなく実証した。較正ログは空のデータベースから、1回のセッションで、すべて台帳から再構築されている。
• エージェントは、進行役であり分析役である。 2つの間でデータを動かし、比較を実行し、見つけたことを書く。今回でいえば、自分の2つの情報源が食い違っているという発見を含めて書いた。

この3つの境界こそ、突き合わせを置くべき場所だ。同じ問いに対する独立した答えが2つ存在し、比較できる唯一の地点だからである。

そのうえで、これからに向けた注意を1つ。圧力は逆向きに働く。連携を1つ増やすたび — 同期の仕組み、ダッシュボード、ツールを使えるようにしたエージェント — 同じ事実の断片を持つ場所が1つ増える。しかもそれは「実装が増える」ではなく「便利になる」という顔で導入される。自律的に動くエージェントは、この速度をさらに上げる。派生した数値を自分で作り、それに基づいて動き、報告するまでを、人が途中を見ないまま完結できるからだ。ツールの数ではなく実装の数を数えること。そして、誰かが意思決定に使う数字を持たせる前に、どの正本に従うのかを新しい実装ごとに宣言させることだ。

最後に、AI の監査という論点に触れておく。同じ問題が服を着替えているだけだからだ。今回この不具合を見つけられたのは、計算層が分離されていて、単体で問い質せたからである。もしエージェントが台帳を読んで「約 1.2倍 の過大評価です」と書いただけなら、その文はおおむね正しく、まったくもっともらしく、そして監査不能だっただろう。AI の出力を確かめるときは、結論ではなく算術を出させること。 結論のほうは、同意しやすいように作られている部分である。