最近、社内外で生成AIの導入プロジェクトに関わることが増えてきました。で、気づいたことがあって。PoC（概念実証）まではサクッと進むのに、本番投入になると急にプロジェクトが止まるんですよね。
Gartnerが「2025年末までに生成AIプロジェクトの30%以上がPoC後に放棄される」と予測していたんですが、体感としてはもっと多い気がします。自分の周りだけかもしれないですけど。
PoCは「うまくいく」ようにできている
ここが地味に罠だと思っています。
PoCのデモって、基本的にうまくいくシナリオで見せますよね。「こんなことができます！」って。で、偉い人たちが「おお、すごい」ってなる。予算がつく。チームが動き出す。
でも本番環境って、ユーザーが想定外の入力をしてくるし、データは汚いし、エッジケースだらけです。デモで見せた80%の精度と、本番で求められる99.9%の精度の間には、途方もない溝がある。
これ、自分の中では「逆デモ問題」って呼んでます。デモが華やかであればあるほど、実際に動かしたときの落差がでかい。
精度95%は全然足りない
生成AIを使ったワークフローで、各ステップの精度が95%だとします。十分に見えますよね。
でもこれが10ステップのワークフローになると、全体の成功率は約60%まで落ちます。100ステップなら0.6%。ほぼ動かないのと同じです。
1ステップ: 95%
5ステップ: 77%
10ステップ: 60%
50ステップ: 8%
100ステップ: 0.6%これはChip Huyenさんが指摘していた「複合エラー問題」で、エンジニアリングでどうにかなる話じゃなく、数学的な現実です。
最近のAIエージェントブームで「自律的に複数ステップを実行」みたいなのが流行ってますけど、この数字を見ると、完全自律型のエージェントが本番で安定稼働するにはかなりハードルが高いのがわかります。
Anthropicも公式のガイドで「ワークフロー（事前定義されたパス）のほうがエージェント（動的判断）より多くのユースケースで優れている」と書いていて、ここは正直だなと感じました。
評価がないプロジェクトは迷子になる
PoC止まりになるプロジェクトを見てきて、だいたい共通しているのが「評価基盤がない」ことです。
プロンプトをいじる → なんとなく良くなった気がする → 別のケースで壊れる → またいじる → 最初のケースが壊れる
これ、あるあるですよね。Hamel Husainさんが「AIプロダクトの失敗の根本原因は、ほぼ常に堅牢な評価システムの構築の失敗」と言っていて、ほんとそれだなと。
ただ、評価を作るのが難しいのもわかります。「何をもって正解とするか」を定義するには、実際にユーザーに使ってもらって失敗するフィードバックが必要で、でも評価がないと改善できないという鶏と卵の問題がある。
自分の環境では、最初から完璧な評価を目指さず、まず「明らかにダメなケース」を10個くらい集めてそこから始めるようにしています。地味ですけど、これだけでもモグラ叩き状態からは抜け出せます。
本番に乗っているものの共通点
じゃあ実際に本番で動いている生成AIって何かというと、わりと地味なやつが多い印象です。
- 社内向けの要約・検索
- コードアシスタント（人間のレビュー付き）
- ガードレール付きの構造化データ抽出
- キーワード検索とセマンティック検索のハイブリッドRAG
逆に、まだ厳しいなと感じるもの。
- 人間の監視なしで判断する完全自律型エージェント
- スコープが広すぎるカスタマー対応チャットボット
- 純粋な埋め込みベースのRAG（固有名詞やIDの検索が弱い）
- 複雑なマルチステップの自律ワークフロー
Air Canadaのチャットボットが存在しない遺族割引ポリシーを勝手に作った事件とか、まさにスコープ制御の失敗例ですよね。
ざっくり言うと、「LLMがワークフローの一部として組み込まれている」ものは動いていて、「LLMが主体的に判断して動く」ものはまだ早い、という印象です。
日本特有のしんどさ
海外の記事を読んでいると、上の課題はグローバル共通なんですが、日本にはさらに上乗せがあると感じています。
まず、SIer依存の構造。AIの導入をSIerに委託するんですが、そのSIer自身もまだ手探りだったりする。結果、PoCを納品して終わり、みたいなことが起きがちです。
あとはリスク回避カルチャー。顧客対応にAIを使うことへの抵抗感が、海外と比べてかなり強い気がします。ハルシネーション1回で「やっぱりAIは危険」ってなりやすい空気がある。
クラウド移行もまだ途上の企業が多いので、「クラウド＋AI」の二重の壁を同時に越えないといけないケースもあって、そりゃ止まるよなと。
じゃあどうするか
偉そうに言える立場ではないですが、自分が最近意識していることをいくつか。
小さく始めて、評価から作る。 プロンプトの前に評価。最初は手動で10ケース見るだけでもいい。
自律性を下げる。 エージェントに全部やらせるんじゃなく、決定的なワークフローの中にLLMを部品として組み込む。Anthropicの言う「ワークフロー > エージェント」は実感として正しいです。
デモの期待値を下げる。 PoCのプレゼンで「80%の精度で動きます」と言うなら、「本番で99%にするには10倍のコストがかかる可能性があります」もセットで伝える。
ハイブリッドを前提にする。 全部AIで置き換えるんじゃなく、人間のレビューを前提にした設計にする。カッコよくはないけど、今のところこれが一番動く。
所感
Sequoiaが指摘していた「AIインフラ投資と実際の収益の間に$600Bのギャップがある」という話、数字としてはマクロすぎてピンとこないですけど、現場レベルの肌感覚とは一致します。お金は動いてるけど、本番で価値を出しているプロジェクトはまだ少ない。
ただ、これは「生成AIがダメ」って話じゃなくて、適用の仕方がまだこなれていないだけだと思います。スコープを絞って、評価を回して、人間との協調前提で設計する。地味だけど、たぶんこれが今の正解に一番近いんじゃないかと。
次は実際に評価基盤を構築するところを具体的に書いてみたいですね。LLM-as-Judgeの話とか、バイアスの問題とか、そのへんも掘りたい。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
