AIプロダクトはなぜ失敗する？「非決定性×任せすぎ」を潰す実装ロードマップ
AIプロダクトが「デモでは輝くのに、本番で崩れる」――この落差は、技術力不足というより作り方の前提がズレていることから起きがちです。OpenAI/Google/Amazon/Databricksなどで50件超の導入を支援してきたAishwarya Naresh Reganti氏とKiriti Badam氏は、失敗の原因を「AIを“普通のソフトウェア”として扱ってしまうこと」だと整理します。
1. 失敗の根っこは「非決定性」を無視すること
従来のソフトウェアは、入力→処理→出力が比較的予測可能です。ところがLLMは、同じ入力でも出力が揺れる。さらに自然言語UIでは、ユーザー側の入力も千差万別で、入力と出力の両方がブレる。この“非決定性”を前提にしないと、仕様書通りに作っても本番で想定外が噴き出します（Reganti/Badamは「AI products are inherently non-deterministic」と明示）。
1-1. 「うまくいったケース」より「壊れ方」を設計する
AIプロダクトの品質は、平均点よりも最悪ケースの抑え込みで評価されます。特にエージェント（ツール実行・外部操作）になると、出力の揺れがそのまま“行動の揺れ”に変換されるため、壊れ方の設計が致命的に重要です。
2. もう一つの差分：「エージェンシー vs コントロール」トレードオフ
AIに意思決定を委ねるほど（＝エージェンシーを上げるほど）、人間側のコントロールは減ります。これは便利さと引き換えに、責任・信頼・安全性のコストが跳ね上がるということ。Reganti/Badamは、ここを理解せずに“最初から全自動”を狙うのが典型的な失敗パターンだと述べます。
2-1. 事故は「仕様漏れ」ではなく「権限設計」で起きる
象徴的なのが、Air Canadaのチャットボット事例です。ボットが誤った返金案内を提示し、結果として裁定で航空会社側が補償を命じられました。ここで怖いのは、誤回答そのものより、誤回答が“会社の約束”として扱われうる点です。
3. 解決策の核：「小さく始めて、信頼を稼いでから自動化する」
彼らの推奨は一貫していて、高コントロール・低エージェンシーから始め、学習ループ（フライホイール）で段階的に自動化します。
3-1. 例：カスタマーサポートの“3段ロケット”
V1（提案）：人間オペレーターに回答案を提示（人間が最終判断）
V2（半自動）：顧客に回答を提示するが、重要操作は人間承認
V3（自動）：返金・チケット更新なども含めて実行（ただし段階的に権限付与）
ポイントは、V1の時点で人間がどう直したかをログとして回収でき、それが改善燃料になります（＝最初から“学習する仕組み”をプロダクトに埋め込む）。
4. 実務フレーム：「CC/CD（継続的キャリブレーション×継続的開発）」
彼らはAI開発を、CI/CDになぞらえてContinuous Calibration / Continuous Developmentとして整理します。最初に“想定入出力”を小さく定義して作り、運用で現れた未知の失敗パターンを取り込みながら、評価軸やデータセット自体を更新していく。
4-1. 「Evals万能論」への現実的な答え
議論が荒れがちな“Evals”も、彼らは極論を避けます。オフライン評価（Evals）は「既知の失敗」を検知するのに強い。一方で、本番では、ユーザー行動や再生成、離脱などの運用シグナルが「未知の失敗」を教えてくれる。つまり、片方では足りません。
実態としても、エージェント運用では人間の検証が重要な位置を占め続けています。たとえば「Measuring Agents in Production」では、運用中の評価に人間が深く関与する状況が報告されています。
5. 組織が詰まる3点セット：リーダー・文化・技術
成功パターンを彼らは「三角形」で語ります。
リーダー：直感を“学び直す”。トップが手を動かし、現実の限界を理解する
文化：現場の専門家（SME）が協力できる心理的安全性を作る（置換恐怖を煽らない）
技術：ワークフロー理解を最優先し、AI/ルール/既存システムを適材適所で組む
5-1. 「Evals」という言葉が壊れていく問題
面白い指摘として、Martin Fowlerの言うSemantic Diffusion（用語の意味が拡散して薄まる）が、Evalsに起きている――と彼らは注意します。ベンチマーク比較も、ラベリングも、LLMジャッジも、全部“eval”と呼ばれて混線する。だからこそ、チーム内では「何のための評価か」を言語化して揃える必要があります。
6. 明日から使えるチェックリスト
最後に、導入フェーズで“事故りにくい順番”を置きます。
問題→ワークフロー→最小の自動化（いきなりエージェント化しない）
人間の介入点を仕様として固定（承認・制限・ロールバック）
ログ＝資産：人間がどう直したか／どこで止めたかを必ず取る
Evals＋運用監視：既知はテスト、未知はシグナルで拾う
権限は“稼いだ信頼”に応じて解放（小さく勝ってから大きく任せる）
AI時代の競争優位は、派手なデモではなく、泥臭い反復で蓄積される“痛み”に宿る――彼らの言う 「Pain is the new moat（痛みが新しい堀）」 は、まさにプロダクト運用の現場感そのものです。
