AIエージェントは本番環境で失敗を繰り返し、誰もその話をしたがらない

デモを見たことがあるだろう。エージェントが起動し、いくつかのファイルを読み取り、いくつかのツールを呼び出し、PRを作成して提出する。三十秒。観客は大歓声を上げる。

それから、実際のコードベースで試してみる。

実在しない関数を幻視し、あなたのAPIを11回ループで呼び出し、なぜすべて正しく動作したのかを自信満々に説明するコミットメッセージを作成します。あなたはその混乱の片付けに45分を費やすことになる。

これは2026年のAIエージェントの現状だが、そうでないふりをするのにはもううんざりだ。

デモから現実へのギャップは甚大だ

私は十年以上、本番ソフトウェアを出荷してきました。多くの技術の盛り上がりのサイクルを観察してきました。しかし、デモで見せるAIエージェントと、本番環境で実際に何をするかの間のギャップは、これまでに見た中でも最も広いものの一つです。

現状は次のとおりです。ベンチマークとデモは慎重に構築された環境です。クリーンな入力、あいまいさがなく、横道に逸れたときにはリセットボタンがあります。対して本番は正反対です。本番は40万行のレガシーコードを6年間に9つのチームが作成したもので、その半分は文書化されておらず、誰かがもうそこにいない人物で、コメントを信じていないものも混ざっています。

エージェントはそこで失敗します。頻繁に、そして独創的な方法で。

失敗モードは、十分に見てきたら予測可能です。

コンテキストの崩壊。 エージェントは複雑な多段階タスクを始め、途中の推論で文脈を満たし、7ステップ目には元の目標を見失います。自信を持って完了しますが、あなたが尋ねた質問とはわずかに異なる質問に答えています。

ツール呼び出しループ。 ツールの応答に少し不具合が起きると — たとえば API が 429 を返したり、スキーマが1フィールドずれていたり — 停止する代わりにエージェントはリトライを繰り返します。リトライ、リトライ、リトライ。雰囲気ではなく、実際の回路ブレーカーが必要です。

検証なしの自信。 これが最も痛い問題です。エージェントは自分が知らないことを知らない。存在しない内部ライブラリのメソッドを参照するコードを生成し、構文的には自信満々、実行時のテストはゼロ、そして明るい「Looks good!」の要約を添えます。

誰も十分に迅速に解決できていないインフラの問題

これはモデルのせいばかりではありません。私たちは、単一のリクエスト/レスポンスサイクル向けに設計されたインフラ上でエージェントを動かそうとしているのです。

堅牢なエージェントが本当に必要とするものを考えてみましょう：

• セッションを跨いで照会可能な持続的メモリ（単なるコンテキストウィンドウではない）
• ツール呼び出しが副作用を持つ場合のロールバック機構
• エージェントが先に進む前に人間がレビューできる、構造化された中断ポイント
• 実際に機能するコスト管理 — 「トークン予算を設定して運任せ」ではなく

私が見た多くの本番エージェントのセットアップは、ダクトテープと祈りだけの状態だ。