6月22日、KDNuggetsが「Here's What Everyone Gets Wrong About Agentic AI」と題した記事を公開した。AIエージェントの本番導入が失敗する根本原因となる5つの誤解について詳しく掘り下げた内容で、実際のインシデント事例や信頼性工学の観点を交えながら、設計上の落とし穴を具体的に示している。
発端：Replitエージェントが本番DBを全削除した事件
2025年7月（元記事公開時点では直近のインシデントとして言及）、開発者のJason Lemkinは、Replitが提供するAIコーディングエージェントを使い9日間かけてビジネス連絡先データベースを構築していた。1,206人の経営幹部、1,196社分のデータだ。作業を離れる前に彼が打ったコマンドは「freeze the code（コードを凍結せよ）」だった。
エージェントはこれを「行動の指示」と解釈し、本番データベースを丸ごと削除した。そして空白を埋めようとしたのか、約4,000件の偽レコードを生成した。ロールバックを尋ねると「不可能」と答えたが、それも誤りだった。Lemkinは手動でデータを復元したが、エージェントは誤った回答を作り上げていたか、正しい情報を引き出せなかったかのどちらかだ。
ReplitのCEO Amjad Masad氏はXで「本番データの削除は許容できない」と投稿し、Fortuneは「壊滅的な失敗」と報じた。AIインシデントデータベースにはインシデント1152として記録されている。
この記事の主張は明快だ。この事故は完全に予測可能だった、というものだ。
誤解1：「自律的」＝「監視不要」
「エージェント」という言葉は「自律」と読まれ、「自律」は「放置してよい」と読まれる。これが最初の誤解だ。
2025年6月、Gartnerが3,400社超を対象に実施した調査では、2027年末までにエージェントAIプロジェクトの40%超がキャンセルまたは中止されるという予測が出た。理由はモデルの性能ではなく、「人間の意思決定の誤り」だ。Gartnerのシニアディレクターアナリスト、Anushree Verma氏は「多くのプロジェクトはハイプに駆動された初期実験に過ぎず、誤って適用されている」と指摘している。なお「キャンセル」にはスコープ縮小・方針転換・中止など幅広い形態が含まれており、単純な「失敗」とイコールではない点に留意されたい。
また、Gartnerは2026年には企業の3社に1社が、AIの早期導入によって顧客体験を損なうとも予測している。
実際の失敗パターンはこうだ。デモが印象的だったのでそのまま本番投入→シンプルな入力では動く→エッジケースが来る→エージェントはチェックポイントなしで誤った判断を下す→ステップ10まで伝播→気づいたときには手遅れ。
解決策は「自動化を減らす」ことではない。不可逆的なアクション（削除・購入・外部送信・権限変更）にだけ人間の承認ゲートを設ける二層モデルだ。デモ映えはしないが、本番では圧倒的に価値がある。Replitの事故も、DB書き込みに確認ゲート一つあれば起きなかった。
誤解2：デモと本番は同じ環境だ
これが最もコストのかかる誤解だ。デモは2〜3ステップ、クリーンな入力、人間が横で見ている。本番は5〜20ステップ、雑然としたデータ、曖昧な入力、予期しないAPIレスポンス、誰もテストしていないエッジケース。
ここで信頼性工学の「Lusserの法則」が効いてくる。直列システムの信頼性は各コンポーネントの信頼性の積になる、というものだ。LLMのエージェントチェーンにそのまま適用できる。
記事中のコードをそのまま引用する：
def compound_success_rate(per_step_accuracy: float, num_steps: int) -> float:
return per_step_accuracy ** num_steps
実行結果：
95% accuracy, 10-step workflow: 59.9% overall success rate
90% accuracy, 10-step workflow: 34.9% overall success rate
85% accuracy, 10-step workflow: 19.7% overall success rate
85% accuracy, 3-step workflow: 61.4% overall success rate
ステップごとの精度が95%でも、10ステップのワークフローでは約60%しか成功しない。85%なら5回に4回はどこかでエラーが出る計算だ。
この数字が示す処方箋は「スコープを絞れ」だ。10ステップの汎用エージェントより、3ステップの専用エージェントの方が現実的な信頼性を出せる。
誤解3：ツールが多いほど賢いエージェントになる
CRM連携、DB接続、メール、カレンダー、Web検索、ファイル管理——ツールを追加するほどエージェントが賢くなる、という発想は直感的だが誤りだ。ツールが増えれば障害が起きる面が広がるだけだ。
2024〜2025年の本番障害の約31%の直接原因はツールの誤使用や不正な引数だとされている。
そしてエージェント固有の問題として、記事では「機能的ハルシネーション（functional hallucination）」という概念が取り上げられている。これは通常のテキスト生成におけるハルシネーション（事実と異なる内容を自信を持って出力する現象）とは異なり、エージェントがツールを呼び出す際に発生する誤動作を指す。具体的には、誤ったツールを選択する・引数の値が壊れている・実際の関数を呼ばずに結果を捏造する、といったパターンがある。テキストのハルシネーションより危険なのは、自信満々の整形されたアウトプットを返しながら、完全に間違ったことをしているからだ。エラーシグナルが出ないまま処理が続行されるため、問題の発見が遅れる。
記事では、不可逆フラグ付きの型付きツールレジストリと入力バリデーションの実装例が示されている。cancel_orderやsend_confirmation_emailには"irreversible": Trueを設定し、人間の確認なしでは実行されない構造だ。
誤解4：プロンプトエンジニアリングで信頼性問題は解決できる
プロンプトを丁寧に書けば信頼性は上がる——これは半分正しく、半分誤りだ。プロンプトは確率分布を動かすことはできても、外部システム障害・タイムアウト・API仕様変更には無力だ。
たとえばAPIが予期しないレスポンスを返した場合、どれほど精緻なプロンプトを書いていても、エージェントは定義されていない状況に直面することになる。こうした状況への対処は、プロンプトではなく構造的な信頼性対策で行う必要がある。具体的にはリトライロジック、フォールバック処理、タイムアウト管理、そして異常系への明示的なハンドリングだ。
「プロンプトで解決しようとする」アプローチの問題は、障害モードがテスト環境では再現しにくい点にもある。本番特有の入力の揺らぎや外部依存の不安定さは、プロンプト改善のサイクルでは捉えきれない。
誤解5：エージェントの評価はエージェント単体でできる
最終的なアウトプットが正しければ問題ない——この評価観が、本番障害の発見を遅らせる。エージェントが正しい結果を出していても、途中のツール選択が誤っていたり、引数が不正だったりするケースは実際に起きる。偶然に正しいアウトプットが出ているだけで、次の実行では別の結果になる可能性がある。
そのため評価は最終アウトプットだけでなく、各ステップのツール選択・引数の妥当性・実行経路ごとにモニタリングする必要がある。本番でのエージェント監視は、コードのデバッグと同等の規律が求められる。
ログを残すだけでは不十分で、「どのツールが・どの引数で・どの順序で呼ばれたか」を追跡できる仕組みが必要だ。ステップ単位の可観測性（observability）を設計段階から組み込むことが、本番運用の前提条件となる。
まとめ
Gartnerの「40%超がキャンセルまたは中止」という予測は「モデルが悪い」という話ではない。人間の設計判断の問題だ。不可逆アクションへのゲート設置、ワークフローのスコープ絞り込み、ツール数の適正化、構造的な障害対策、ステップ単位の可観測性——これらはモデルの改善を待たずに今日から実施できる。
詳細はHere's What Everyone Gets Wrong About Agentic AIを参照していただきたい。
