「デモでは完璧に動いたのに、本番に出したら壊れた」——AIエージェント導入の現場でいま最も多く聞かれる声だ。海外の実践レポートは、本番投入されたエージェントの約8〜9割が想定通りに機能しないと報告している。原因は技術力ではなく、設計フェーズで決めておくべきことを決めていない点にある。今日はその典型的なつまずきパターンと、着手前に潰しておきたいチェックポイントを整理する。
「デモは動く、本番で壊れる」という共通パターン
AI活用支援を手がけるBusiness+AIのレポートによれば、デモや検証環境で成功したエンタープライズ向けAIエージェントのうち、約88%が実際の業務に投入された段階でうまく機能しなくなるという。同記事が引用するGartnerの予測では、2027年までにエージェント型AIプロジェクトの4割以上が中止に追い込まれるとされ、失敗した1プロジェクトあたりの直接コストは平均で34万ドルにのぼるとも報告されている。
テスト環境とは、入力がきれいに整い、担当者も慣れていて、既知の手順しか通らない「都合の良い世界」だ。Accelirateの分析でも、テストは「エンジニアが想定した使われ方」を検証しているに過ぎず、本番で起きる曖昧な指示・API障害・長時間セッションでの文脈喪失までは再現できていないと指摘されている。つまり「テストに通った」ことと「本番で壊れない」ことは別の問題であり、この落差こそが導入つまずきの正体になる。
現場で繰り返される、8つのつまずきパターン
Business+AIとAccelirateの2本のレポートに共通して挙がる失敗パターンを、原因と対策のセットで整理した。
| つまずき | 何が起きるか | 対策の方向性 |
|---|---|---|
| デモと本番の環境ギャップ | 整った入力でしか検証しておらず、曖昧な指示や欠損データで挙動が崩れる | 意地悪な入力・エラー条件・想定外の指示を含めて事前に評価する |
| スコープの静かな拡大 | 「この業務も」「あのシステムにも」と誰も承認しないまま対象範囲が広がる | 変更のたびに設計レビューを挟み、拡張を正式な意思決定にする |
| データ品質の軽視 | 誤った前提が複数ステップにわたって連鎖し、下流のシステムまで汚染する | 着手前にデータの完全性・鮮度を監査し、パイプライン側で直す |
| 人による承認ポイントの省略 | 1回の判断ミスが誰にも止められないまま実行され続ける | 不可逆・高リスクな操作にだけ承認ゲートを設ける「統治された自律性」 |
| コンテキストドリフト | 会話や処理が長くなるほど、初期の指示や制約が「忘れられて」いく | 重要な制約を定期的に再注入し、コンテキストを圧縮・整理する |
| ガバナンス・権限設計の不足 | 最小権限になっておらず、想定外のデータアクセスや操作が起きる | 最小権限から始め、所有者と権限範囲を明文化する |
| 「動いている」と「達成した」の混同 | コミットや更新は発生しているが、目的自体は達成できていない | 検証可能な成功基準を先に定義し、途中経過ではなく結果を確認する |
| 監視・観測性の欠如 | 再試行ループや暴走コストが誰にも気づかれないまま続く | タスク完了率・コスト・エスカレーション率を最初から計測する |
特に見落とされやすいのが「コンテキストドリフト」の数学的な効いてくる部分だ。1ステップあたり85%の精度でも、10ステップの連続処理では成功率はおよそ20%まで落ち込む。95%の精度でも10ステップでは60%程度にしかならない。ステップごとの精度とワークフロー全体の成功率はまったく別の数字であり、この違いを混同することが最も高くつく誤解の一つだと報告されている。
着手前に埋めておく――エージェント設計8項目チェックリスト
プロダクトマネジメントの視点でエージェント設計を整理したShareuhackのガイドは、仕様書に落とし込むべき8つの観点を提示している。通常のPRD(要求仕様書)には出てこない項目が多く、エンジニア任せにすると本番後に問題が表面化しやすい。
| 観点 | 確認すべき問い |
|---|---|
| 信頼性テスト | 本番に近い環境で検証したか。具体的な遅延・スループット目標はあるか |
| ガードレール | どの操作が不可逆か。その操作に承認ゲートはあるか |
| 成功基準 | タスク完了率の目標値は何%か。「良い」を定義できているか |
| ツール連携 | 各ツールの境界は何か。タイムアウト・リトライ戦略はあるか |
| コスト・遅延予算 | タスクあたりのトークン予算は。上限を超えた場合の代替策は |
| 人間による確認 | どの条件で人にエスカレーションするか。SLAは決まっているか |
| エラー復旧 | 失敗時のフォールバックは。ロールバック手段は用意されているか |
| 監視・観測性 | エンドツーエンドのトレースはあるか。ローンチ後に最初に見る指標は何か |
さらに同ガイドは、そもそもエージェントを作るべきかを3つの質問で先にふるいにかけることを勧めている。①タスクは複数ステップ・分岐判断を伴うか、②ツール利用や複数セッションをまたぐ記憶が必要か、③実行経路が文脈によって大きく変わるか——これらのうち2つ以上が「いいえ」なら、多くの場合は固定的なワークフローやRAG+プロンプトで十分であり、無理にエージェント化する必要はない。
現場で効く3つの実践ルール
個々のつまずきへの対処法を積み上げると、実務でまず押さえるべきルールは次の3つに集約できる。
- まずは「提案止まり」から始める。 最初のバージョンは実行権限を持たせず、提案・下書き作成までに留める。タスク完了率が目標水準に達してから、段階的に自律度を上げていく「オートノミー・ラダー」の考え方が、拙速な全自動化より結果的に近道になる。
- コンテキストを設計する。 Anthropicが公開しているcontext engineeringの解説は、コンテキストウィンドウに詰め込みすぎるほど性能が緩やかにではなく、ある閾値を超えた途端に崩れる「コンテキスト・ロット」を指摘している。エージェントの振る舞いを固定する仕様は、口頭やSlackの記憶ではなくAGENTS.mdのようなファイルに書き出しておく。
- 最初から観測性を組み込む。 タスク完了率・ツールエラー・コスト・エスカレーション率をローンチ初日から計測対象にしておけば、問題が起きたときに「どこで壊れたか」を数分で特定できる。後から観測性を足そうとすると、原因調査そのものに膨大な時間を取られることになる。
主な情報源
- Business+AI: AI Agent Failures: Common Mistakes and How to Avoid Them
- Accelirate: What Makes AI Agents Fail in Production Even After Successful Testing?
- Shareuhack: What Does a Good Agent Spec Look Like? A PM’s Framework for Designing AI Agents
- Anthropic: Effective context engineering for AI agents
- AGENTS.md — an open format for guiding coding agents
各ツールは提供元の規約に従ってご利用ください。情報は各情報源の公開時点のものです。収集・要約はAI、公開判断は人。