Newsfeed / なぜほとんどのAI製品は失敗するのか:50以上のエンタープライズ導入からの教訓
Lenny's Podcast·January 11, 2026

なぜほとんどのAI製品は失敗するのか:50以上のエンタープライズ導入からの教訓

OpenAIとGoogleの経験者であるAishwarya RantiとKiriti Bhattamが、顧客の信頼を損なわず、際限ないホットフィックスを必要としないAI製品を構築するためのCCCDフレームワークを紹介します。

なぜほとんどのAI製品は失敗するのか:50以上のエンタープライズ導入からの教訓

従来のプロダクト開発を破壊する2つの根本的な違い

Aishwarya RantiはAlexaとMicrosoftでAI研究に従事し、35以上の研究論文を発表しています。Kiriti BhattamはGoogleとKumoで10年間AIインフラを構築した後、現在OpenAIでCodexを率いています。2人は合わせて50以上のAI導入を支援し、Mavenで最高評価のAIコースを教えています。彼らの核心的なメッセージは、AI製品にはまったく異なる思考が必要だということです。

1つ目の違いは非決定性です。 "You don't know how your user might behave with your product and you also don't know how the LLM might respond to that."(ユーザーが製品でどのように振る舞うかわからないし、LLMがそれにどう応答するかもわからない)。従来のソフトウェアでは、明確にマッピングされた意思決定エンジンを構築します。Booking.comにはボタンとフォームがあり、意図を予測可能なアクションに変換します。しかしAIでは、入力(自然言語は同じ意図を無数の方法で表現できる)と出力(LLMは確率的なブラックボックス)の両方が予測不能です。完全には理解できない入力、出力、プロセスを扱うことになります。

2つ目の違いはエージェンシーとコントロールのトレードオフです。 "Every time you hand over decision-making capabilities to agentic systems, you're kind of relinquishing some amount of control on your end."(エージェントシステムに意思決定能力を委ねるたびに、ある程度のコントロールを手放すことになる)。Ashは、これについてもっと多くの人が議論していないことに驚いています。AIコミュニティは自律型エージェントの構築に夢中ですが、自律性はコントロールを失うことを意味します。AIエージェントにより多くのエージェンシーを与える前に、実証された信頼性を通じて信頼を獲得したことを確認する必要があります。

74%の信頼性問題は現実です。 UC Berkeleyの論文では、74-75%の企業が信頼性を最大の問題として挙げています。これが顧客向け製品を導入することに消極的な理由です—システムを信頼できないのです。これは、現在のエンタープライズAIのほとんどが、エンドツーエンドのワークフロー置き換えではなく生産性ツールに焦点を当てている理由を説明しています。

CCCDフレームワークが壊滅的なAI障害を防ぐ理由

ゲストたちは、痛みを伴う経験の後にContinuous Calibration, Continuous Development(継続的キャリブレーション、継続的開発)フレームワークを開発しました。彼らは、あまりにも多くのホットフィックスが必要になり、シャットダウンせざるを得なかったエンドツーエンドのカスタマーサポートエージェントを構築しました。Air Canadaのチャットボットは存在しない払い戻しポリシーをハルシネーションし、法的にそれを履行しなければなりませんでした。これらの災害は防ぐことができます。

高いコントロールと低いエージェンシーから始めましょう。 "It's not about being the first company to have an agent among your competitors. It's about have you built the right flywheels in place so that you can improve over time."(競合他社の中で最初にエージェントを持つ会社になることが重要ではない。時間とともに改善できるよう、適切なフライホイールを構築できたかどうかが重要だ)。カスタマーサポートエージェントの場合:V1はチケットを部門にルーティングするだけ(人間がまだ判断する)。V2は人間が編集できる返信案を提案し、どのような変更を加えたかを記録する。V3はV1とV2の信頼性が証明された後でのみ、エンドツーエンドの解決を処理する。

コーディングアシスタントにも同じパターンが適用されます。 V1:インライン補完とスニペットを提案。V2:テストやリファクタリングなどのより大きなブロックを人間のレビュー用に生成。V3:自律的に変更を適用し、PRをオープン。マーケティングの場合:V1はコピーを下書きし、V2は承認を得てキャンペーンを構築・実行し、V3はローンチしてチャネル全体で自動最適化。

カスタマーサポートの進化がすべてを教えてくれます。 ルーティングでさえ—一見シンプルに見えますが—エンタープライズでは信じられないほど複雑になり得ます。タクソノミーは乱雑で、重複したカテゴリや2019年からのデッドノードがあります。人間のエージェントは経験からこれらの癖を知っていますが、AIは知りません。ルーティングから始めることで、より野心的な自動化を妨害する前にデータの問題を修正できます。フライホイール効果により、各バージョンが次のバージョンのトレーニングデータを生成します。

AI製品で成功する企業を分けるもの

ゲストたちは、優れたリーダー、良い文化、技術の進歩という3つの次元を持つ「成功の三角形」を見ています。どれも単独では機能しません。

リーダーは直感を再構築する必要があります。 "Leaders have to get back to being hands-on... You must be comfortable with the fact that your intuitions might not be right and you probably are the dumbest person in the room."(リーダーは実践に戻る必要がある...自分の直感が正しくないかもしれないこと、そしておそらく自分がその部屋で最も無知な人間であることを受け入れる必要がある)。Ashが一緒に仕事をしたあるCEOは、毎朝4時から6時を「AIのキャッチアップ」のためにブロックしていました—会議なし、信頼できるソースから学ぶだけ。彼はAI専門家に質問を投げかけるために戻ってきました。10-15年かけて直感を構築したリーダーは、今それを学び直す必要があります。

エンパワーメントの文化がFOMOへの恐怖に勝る。 主題専門家は重要です—彼らはAIが実際に何をすべきかを理解しています。しかし多くの企業では、自分の仕事が置き換えられると思っているため、協力を拒否します。リーダーはAIを置き換えではなく、10倍の生産性のための拡張として位置づける必要があります。組織全体がAIを有用にするために協力するようにしましょう。

ツールではなくワークフローへの技術的な執着。 成功するチームは、技術を選ぶ前にワークフローを深く理解しています。"80% of so-called AI engineers, AI PMs spend their time actually understanding their workflows very well."(いわゆるAIエンジニア、AI PMの80%は、実際にワークフローを非常によく理解することに時間を費やしている)。エージェントはワークフローの一部だけを処理するかもしれません。機械学習が別の部分を処理するかもしれません。残りは決定論的なコードが処理します。ワークフローの理解なしにツールに執着すると失敗につながります。

なぜEvalsは誤解されているのか、そして代わりに何をすべきか

「eval」の議論は意味の拡散になっています—誰もが異なる意味でこの用語を使っています。データラベリング会社は専門家のアノテーションを「evals」と呼びます。受け入れ基準を書くPMはそれを「evals」と呼びます。モデルベンチマークの比較は「evals」と呼ばれます。あるクライアントはAshに「evalsをやっている」と言いましたが、それはLM Arenaのランキングをチェックすることを意味していました。

evalsも本番監視も、どちらか一方だけでは不十分です。 Evalsは、テストデータセットにエンコードされた信頼できる製品知識です—エージェントが絶対に間違えてはいけないこと。本番監視は暗黙のシグナルをキャッチします:ユーザーが回答を再生成する(不満の表れ)、サムズダウン、または機能を完全にオフにする。Evalsは既知の障害モードをキャッチし、本番監視は予測できなかった新たなパターンをキャッチします。

プロセスは:デプロイ、監視、分析、反復。 すべての障害モードを事前に予測することはできません。本番監視は、調べる価値のあるトレースをアラートします。エラー分析はパターンを明らかにします。その後初めて決定します:これは一回限りの修正なのか、新しい評価基準を必要とするシステム的な問題なのか。早すぎる段階で多くのevalsを構築すると、実際の問題をキャッチせずにメンテナンス負担が生じます。

実際に機能するAI製品を構築するための5つのポイント

  • 常に問題を最優先に - 小さく始めることで、実際の問題を定義することを強いられる;ソリューションの複雑さは滑りやすい坂道
  • 痛みが新しい堀になる - 成功している企業は何がうまくいくかを学ぶ痛みを経験した;まだプレイブックや教科書はない
  • ワンクリックエージェントはマーケティング - 即座の自律的デプロイメントを売り込む人は誤解を招いている;エンタープライズデータは乱雑でキャリブレーションが必要
  • マルチエージェントは誤解されている - 人間のオーケストレーションなしにピアエージェント間で責任を分割することは、コントロールが極めて困難
  • コーディングエージェントは依然として過小評価されている - Twitter/Redditの話題にもかかわらず、ベイエリア外での普及率はまだ低い;今後の大きな価値創造が見込まれる

AIエージェントを導入する組織にとっての意味

核心的な洞察:AI製品開発は、AIを入れ替えた従来のソフトウェア開発ではありません。非決定性とエージェンシー・コントロールのトレードオフは、動作を予測できず、結果を完全にコントロールできず、段階的に信頼を獲得しなければならないことを意味します。CCCDフレームワーク—高いコントロールから始め、信頼性が証明されるにつれて徐々にエージェンシーを増やす—は、シャットダウンを強いられ、顧客の信頼を損なう壊滅的な障害を防ぎます。AIで勝っている企業は最も速く動いているのではなく、時間とともに改善が複合するフライホイールを構築しています。

Related