2026年、AIエージェントが本番で壊れる理由｜海外の事故報告を読む

共通していたのは「道具は正しく動いていた」という一点でした。壊れたのはAIではなく、AIを載せる土台のほうです。

この記事はかなり専門的な内容です。エンジニア・技術職の方向けに書いています。用語をかみ砕かずにそのまま扱いますので、読みにくければ遠慮なく閉じてください。「業務でAIに何ができるのか」を平易に知りたい方には、別の記事のほうがお役に立てると思います。

2026年に入ってから、英語圏で「Why AI agents fail in production（AIエージェントはなぜ本番で壊れるのか）」というテーマの記事が急増しています。

3月から7月にかけて、ベンダー、実践者、インフラ企業が相次いで自分たちの失敗を公開しました。

面白いのは、それらがほとんどモデルの話をしていないことです。「GPTが賢くないから失敗した」「もっと良いモデルを待つべきだ」といった論調は、ほぼ見当たりません。代わりに書かれているのは、リトライ、権限、記録、そして「何を渡すか」の話です。

この記事では、公開されている事故報告をいくつか読み解きながら、2026年の議論がどこに移ったのかを整理します。日本語圏ではまだあまり紹介されていない領域だと思うので、原典の媒体名と公開日は本文中に明記します。

議論の中心は、モデルから運用層へ移った

2024年ごろ、エージェントがうまく動かないときの対処法は、ほぼプロンプトの改善に集約されていました。指示文を書き直す。例を足す。トークンを削る。ここを詰めれば、たいていの問題は改善しました。

2026年の記事を読んでいると、その前提が明確に崩れています。ある技術記事（DEV Community、2026年7月16日公開）では、インフラチームの声としてこう紹介されていました。

プロンプトを良くすれば解決すると思っていたが、実際に戦っていたのはまったく別のもの、つまりエージェントが毎回の呼び出しで何を見ているかだった、と。

この変化には、いくつかの技術的な背景があります。コンテキストウィンドウが桁違いに広くなり、会話履歴も状態も判断ログもまとめて入るようになりました。

メモリが、RAGに後付けした検索の仕組みではなく、名前のついた更新可能なブロックとして扱われるようになりました。推論能力の向上で、多段のチェーンを組まずに一回の呼び出しで済む場面が増えました。

結果として、勝負どころが移ります。ウィンドウが小さいときは、プロンプトの文面を最適化する。ウィンドウが広く、エージェントが状態を持つようになると、毎ターン何を入れるかを最適化する。後者は文章術ではなく、設計と運用の問題です。

事故① リトライは正しく動き、顧客に43通の重複メールが飛んだ

ここからは具体的な事故報告を見ていきます。まずはRed Hatが2026年7月13日に公開した記事から。サポートチケット、請求調整、顧客への回答を担当していた1つのエージェントが、一晩で3つの無関係な障害を起こした、という報告です。

1件目は重複です。エージェントの応答が失敗と判定され、フレームワークがリトライを実行しました。ここまでは仕様どおりです。問題は、元の要求がすでに成功していたかどうかを、誰も追跡していなかったことでした。

この報告で私が重要だと思ったのは、書き手が「フレームワークは正しく処理した」とはっきり書いている点です。リトライのロジックにバグはありません。失敗を検知して再実行する、というのは、まさにそのために書かれたコードです。

欠けていたのは、その下の層でした。同じ要求が再送されたときに「これはすでに処理済みだ」と答えられる仕組みが、どこにもなかった。結果として、朝までにチケットが積み上がり、顧客には同じ内容のメールが43通届きました。

冪等性（べきとうせい／idempotency）：同じ操作を何度実行しても、結果が1回実行したときと変わらない性質。

決済、チケット発行、メール送信のように「2回起きたら困る」処理では、要求ごとに一意な鍵を持たせ、同じ鍵の要求には新規作成せず既存の結果を返す、という形で担保します。

ここは非決定的な相手を扱ううえで、最初に押さえるべき性質だと思います。人間が操作するシステムなら、二重送信は連打を防げばだいたい収まります。しかしエージェントは、失敗したと判断すれば躊躇なく再実行します。しかも、その判断が正しいとは限りません。

コストの話も書かれていました。目に見える損害は「気まずい朝」だけではなく、対応に割かれたサポート担当の時間、機械的な重複メールで損なわれた信頼、そして全チケットを人手で監査し終えるまでシステムを信用できなくなったこと。開発者から見ればコードは正しかったが、その下に穴があった、という締め方でした。

事故② 権限が広すぎて、4,000ドルが違う口座に着弾した

同じ記事の2件目は、もっと静かに起きています。同じエージェントが請求調整も担当していました。

デプロイ時にサービスアカウントで請求APIへの権限が与えられていたのですが、そのアカウントは複数の請求先に到達できる状態でした。開発中に手早く動かすには、そのほうが早かったからです。

本番へ昇格させるときに、誰も権限を絞りませんでした。理由は単純で、絞るべき境界そのものが用意されていなかったからです。

報告では、従来のソフトウェアなら二重に守られていたはずだ、と指摘されています。資格情報のスコープが到達先を制限し、呼び出される側のAPIが呼び出し元ごとに妥当なパラメータを検証する。

Webアプリケーションで「1組の認証情報があれば全顧客の請求レコードを書き換えられる」設計を出す開発者はいないだろう、と。ところがエージェントでは、それが起きました。

私がここで注目したのは、「プロンプトに書いておけばいい」では解決しないと明言されている点です。指示文で「指定された口座以外は操作しないでください」と書くのは、鍵をかけずに貼り紙をするのに似ています。守られる保証がないうえに、破られたことも記録に残りません。

資格情報の側で絞れば、そもそも到達できません。試みたこと自体が拒否として記録に残ります。この違いは、事故が起きたあとに効いてきます。「何が起きたか説明できるか」が、そのまま組織の説明責任になるからです。

事故③ 存在しない返品ポリシーを、顧客に断言した

3件目は、金額では測りにくいものです。顧客が返品期限を尋ねたところ、モデルは自信を持って明快に答えました。「返品は90日以内に可能です」。実際の規定は30日でした。

回答は流暢で、丁寧で、そして完全に間違っていました。フレームワークはモデルの出力を顧客向けのチャネルに渡しました。これも仕様どおりの動作です。推論の境界、つまりモデルの出力が現実に触れる地点に、検証が何も置かれていなかったという指摘でした。

顧客は47日目に返品を求め、エージェントの回答を根拠として提示しました。会社はそれを受け入れました。返金額そのものは280ドルです。

しかし報告が問題視しているのは金額ではありません。AIが会社を代表して、承認されていない契約上の約束をしたこと。そして、それを防ぐ仕組みがあったという証跡が残っていないことです。

これは日本の事業者にとっても他人事ではないと思います。景品表示法や特定商取引法の表示、保証期間、キャンセル規定。

このあたりを顧客向けチャネルでAIに答えさせるなら、出力を外に出す前に照合する層は、あったほうがいいというより、無いと運用できない部類だと考えています。

3件に共通していた構図

3件を並べると、共通点がはっきりします。どれも道具の不具合ではありません。リトライは仕様どおり動き、API呼び出しは正常に完了し、出力の受け渡しも設計どおりでした。

元記事は、これらをフレームワークの責務ではなくプラットフォームの責務だと整理しています。アイデンティティ、ツールの統制、可観測性、安全性の担保。

どのエージェントフレームワークも、これらを解くために設計されてはいない、と。Webフレームワークに独自の認証局を期待しないのと同じで、そもそもカテゴリが違うのだ、という比喩が使われていました。

ここは立場によって読み方が変わるところだと思います。Red Hatは自社のプラットフォーム製品を持っているので、この結論に着地するのは自然ではあります。

ただ、事故の記述そのものは製品の宣伝とは独立して読めますし、フレームワークが正しく動いた上で事故が起きたという構図は、他の実践者レポートとも一致しています。

止まる理由は、だいたい4つに集約される

もう1本、実践者側のレポートを紹介します。tsukumo氏が2026年7月23日に公開した記事です。自社のソフトウェアを日常的にエージェント群で動かしている立場から、本番で止まる理由を4つに整理しています。

信頼性、可観測性、コンテキスト、コスト。そして重要なのは、これらが独立していないという指摘です。「1つの問題が4つの顔を持っている」という表現が使われていました。

因果の向きも明確に書かれています。信頼性は他の3つの下流にある、と。古い前提を渡されたエージェントは、構造上どうやっても信頼できない。

モデルの出来は関係ない。そして観測できないエージェントは、実務上信頼できない。正しくやったことを証明できないし、間違えたことを捕まえられないからです。

コストについての記述も的確でした。トークン代が膨らむのは単価が上がったからではなく、毎セッションで同じものを読み直し、不要な情報を抱え込み、古い前提で動いた結果をやり直しているからだ、と。

コストは独立した問題ではなく、他の3つが解けていないことの計測器だという整理です。

そして、片側だけ直すと失敗が移動するだけだ、とも書かれています。人の確認を増やして信頼性を上げれば、人が全工程に入るのでコストが悪化する。

コストを下げるために渡す情報を削れば、判断材料が減って精度が落ちる。自分の側に複利で効く手は、根にあたるコンテキストを正すことだけで、その間ずっと計測できる状態にしておく必要がある、という結論でした。

コンテキストは、大きくすれば解決するものではない

「入るなら入れればいい」という発想が通用しないことは、複数の記事で共通して指摘されています。文脈が長くなるほど、必要な情報を正確に拾う能力が落ちていく。context rot（コンテキストの腐敗）という呼び方が定着しつつあります。

context rot：投入する情報量が増えるほど、モデルが必要な情報を正確に想起・利用する精度が下がる現象。

人間のワーキングメモリと同様に、注意を割ける量に上限があり、無関係な情報がその予算を食いつぶす、という説明のされ方をします。20万トークン級のウィンドウを持つモデルでも、重要な情報がノイズに埋もれれば劣化する、と報告されています。

対処として挙げられているのは、just-in-time な取得です。全部を先に積み込むのではなく、必要になった時点で取りに行かせる。

人間がすべてを暗記せずファイルシステムと検索を使うのと同じで、エージェントも情報を動的に辿るほうが性能が出る、という考え方です。

コンテキストを有限の予算として扱う、という原則も繰り返し出てきます。追加するトークンには、API料金だけでなく注意力のコストがかかる。無関係な情報は、重要なものに集中する能力を削る。この観点は、コスト削減の話としてよりも、精度の話として語られていました。

複数セッションにまたがる場合の手当ても具体的でした。古いやり取りを、決定事項と未解決の論点を残したまま要約して畳む。

コンテキストの外に構造化されたメモを置き、必要な分だけ引き込む。処理済みの生のツール出力は捨てる。いずれも「捨て方」の設計であって、詰め込み方の話ではありません。

ツールは何個まで持たせてよいのか

もう1つ、実務に直結する指摘があります。1つのエージェントに20〜30個のツールを持たせている構成をよく見かけるが、結果は判断の麻痺だ、というものです（inkeep、2025年11月7日公開）。

この記事では、LangGraphの調査として5〜10個を超えると性能が劣化するという数字が紹介されていました。

機能が重複するツールがあると、判断の分岐が曖昧になる。そして印象的だったのが、次の一文です。人間がどちらを使うべきか断言できないなら、エージェントにも断言できない。

対処は、ツールを減らすことではなく分けることだとされています。30個のツールを持つ1体を作るのではなく、5〜7個ずつを持つ専門のエージェントを用意し、振り分け役が委譲する。人間のチーム編成と同じ形です。

ツールの設計そのものについても、示唆がありました。良いツールは、単に動くだけでなく、最小限で情報密度の高い戻り値を返す。一覧をすべて返すのではなく、まず件数と要約を返し、必要なら詳細を取りに行かせる。ここでもjust-in-timeの考え方が一貫しています。

日本の中小企業にとって、この話は何を意味するか

ここまで紹介したのは、いずれもそれなりの規模で運用している組織の話です。では、数人から数十人の会社には関係ないかというと、私はむしろ逆だと考えています。

理由は、被害の絶対額ではなく、復旧に使える人手が違うからです。顧客に43通の重複メールが飛んだとき、大企業ならサポート部門が総出で対応します。

数人の会社では、その対応を社長がやることになります。誤った金額が請求されたとき、監査ログがあれば経緯を説明できますが、無ければ「なぜそうなったか分かりません」と言うしかありません。

そのうえで、この4つ（信頼性・可観測性・コンテキスト・コスト）を最初から完璧に用意するのは現実的ではありません。優先順位をつけるなら、私は次の順だと考えています。

・二重実行の防止。外部に影響が出る処理（送信、発行、決済、登録）は、同じ要求が2回来ても1回分になるようにする。ここだけは最初から必要です。

・触れる範囲の限定。指示文ではなく、権限そのもので絞る。「とりあえず全部触れる状態」で本番に出さない。

・記録。何を判断し、何をしたか。事故が起きてから足しても、その事故の説明には使えません。

・出力の検証。顧客に直接届く文面と、金額・期限・数量を含む出力から始める。

逆に、後回しでよいと考えているのはモデルの選定です。事故報告を読む限り、ここまで挙げた4件はいずれもより賢いモデルに替えても防げません。むしろ賢いモデルは、より説得力のある間違いを出します。返品期限を90日と答えた事例が、まさにそれでした。

任せる範囲を決める、5つの問い

実際に業務へ組み込むかどうかを判断するとき、私が確認すべきだと考えているのは次の5つです。モデルの性能とは無関係に、これが揃っていないと本番では持ちません。

問い1：同じ処理を2回走らせても、結果は1回分か

試すのは簡単です。同じ入力で2回動かして、成果物が2つできないか見る。できてしまうなら、その処理はまだ人の手を離せません。

問い2：触れる範囲は、その仕事に必要な分だけに絞られているか

与えている権限を一覧にして、「この仕事に本当に必要か」を1つずつ確認する。開発中に広げたまま忘れている、が最も多いパターンだと報告されています。

問い3：外に出る前に、内容を確かめる関門があるか

すべての出力に検証をかける必要はありません。まず顧客に届くものと数字を含むものから始めるのが現実的です。

問い4：何を判断し、何をしたかを、後から再現できるか

サービスの死活監視では答えられません。非決定的な相手が下した判断そのものを記録する必要があります。再現できない事故が1件出た時点で、導入の話は止まります。

問い5：止まったとき、誰にどう伝わるか

自動化は、動いているときより止まったときの設計で評価が決まります。誰も気づかないまま3日止まっていた、が最も損害が大きい形です。

まとめ

2026年に公開された事故報告を読んで一貫していたのは、壊れたのはAIではなく、AIを載せる土台のほうだったという構図でした。リトライは正しく動き、APIは正常に応答し、出力は設計どおりに受け渡されていました。そのうえで事故が起きています。

だとすれば、導入を検討するときに問うべきは「どのモデルを使うか」ではなく、「二重実行を止められるか」「どこまで触らせるか」「何を記録するか」「外に出す前に誰が確かめるか」になります。

ここは技術の流行り廃りに左右されにくく、数年後も同じことを問うことになると考えています。

本記事で参照した公開情報

・Red Hat「Why good AI agents fail in production: The missing infrastructure layer」2026年7月13日公開

・tsukumo「AI agents in production: the four operating problems」2026年7月23日公開

・DEV Community「From Prompt Engineering to Context Engineering: How Production Agents Actually Work in 2026」2026年7月16日公開

・inkeep「Context Engineering: The Real Reason AI Agents Fail in Production」2025年11月7日公開

※数値や事例は各記事の記述に基づきます。見解として述べた部分は、あくまで筆者の解釈です。

「うちの業務で、どこまでAIに任せていいのか」を切り分けるところからのご相談も承っています。判断の材料が足りない段階でも構いません。現状をうかがったうえで、任せられる範囲・人が持つべき範囲・そもそも自動化しないほうがいい範囲に分けてお答えします。