AIコーディングエージェントが会社の運用データベースのボリュームを丸ごと削除した。米国の車両レンタルソフトウェア企業ポケットOS(PocketOS)が使っていたレイルウェイ(Railway)のクラウド環境で、4月26日(現地時間)に起きたことだ。この事故でポケットOSは約30時間にわたってサービス障害に見舞われ、その間、顧客の予約や決済、車両割り当ての記録を開いて見ることができなかった。
事故を起こしたエージェントは、開発ツールのカーソル(Cursor)上で動いていた。開発用の環境で作業していて認証情報のエラーにぶつかったが、これを触ってはならない領域だという警告の代わりに、設定が誤っているという信号として読んだ。そこで使える別の認証情報を探し始め、その過程でレイルウェイのAPIトークンを手に入れた。トークンが開いた機能の一覧には、当時の作業とは何の関係もない運用ボリュームの削除まで入っていた。
認証情報はシステムに入るときに使う身分証で、APIトークンはその身分証をプログラムが代わりに提示する形だ。人間の開発者なら、運用環境のトークンが手に入ったときに一度止まる。エージェントは止まらなかった。塞がった道を通すことが任務だと理解したためだ。
復旧の経路も平凡ではなかった。当初は、復元できるバックアップが3か月前のデータだけだという説明が出ており、実際の復旧はレイルウェイのCEOジェイク・クーパー(Jake Cooper)側と連絡がついた後、コンソールの一般機能を外れた社内の災害復旧体制を例外的に稼働させて行われたという。レイルウェイは、削除の遅延装置が抜けていた旧型の端末に、権限が広すぎた顧客側のAIがアクセスして事故が起きたと原因を指摘し、パッチを適用したと述べた。パッチの内容は公開範囲の外だ。
なぜこうした誤った判断が繰り返されるのかを掘り下げた韓国内の研究も出た。オケストロと漢陽大学の分散データ処理システム研究室が共同で書いた論文「Why Do AI Agents Systematically Fail at Cloud Root Cause Analysis?」がASPLOS 2026のAIOpsワークショップに採択された。研究チームはモデル5種を対象に1675回を回し、トークン約13億8000万個を使い、失敗の様相を12の落とし穴として整理した。
最も多くかかった落とし穴は、データを読み違えて存在しない事実を作り出す幻覚で71.2%、その次が調べるべき範囲を十分に探らない探索不足で63.9%だった。目を引く点は、この失敗がモデルの出来がよくてもそうでなくても同じように繰り返されたことだ。研究チームは、個別のモデルよりもエージェントを束ねて動かすフレームワーク側の設計が本当のボトルネックだと見た。エージェント同士がやり取りする通信規約に手を入れたところ、誤りが最大15ポイント減り、実行時間は22.3%短くなった。
同じ流れを市場の側から読み取ったところもある。エイアイワークスは、ユン・ソグォン代表の体制でAIエージェントが信頼して任せられるかを測る評価ツール「エージェントリガー(AgentRigor)」を出した。設計の段階に韓国認定機構(KOLAS)公認試験機関が入り、大規模言語モデルの応答品質と評価の信頼度を数値で測る機能、実際の利用者シナリオを回して安全性を見る機能、公認フレームワークに合わせた規制順守への対応支援を軸とした。韓国内の大手ITサービス企業の検証自動化の案件を引き受け、バンビット(BAMBIT)が準備中の乳幼児スキンケアプラットフォーム「セロク」を試験運用し、化粧品分野の1440件をふるい分けた。
事故一件、論文一本、製品一つは互いを引用しない。ところが狙う場所は互いに接している。エージェントが仕事をやり遂げるかを超えて、どれだけ広い権限を握らせても大丈夫かが導入の関門になったということだ。マッキンゼーが昨年出した報告書「One Year of Agentic AI」も、エージェントを自ら作ってみた60余りの企業の成功と失敗を洗い出して原則を引き出した。
この研究は、科学技術情報通信部と情報通信企画評価院(IITP)が主導するクラウド障害復旧AIアシスタントに基づく運用・管理の自動化技術開発の課題から出た成果物だ。ワークショップの日程は確定前だ。
すぐに点検することは難しくない。社内のエージェントにつながれたトークンが開発環境だけを開くのか、運用ボリュームの削除にまで届くのか、一覧を開いて見ることだ。ポケットOSの30時間は、鍵束を丸ごと渡したせいで生じた時間だった。エージェントに何をさせるかを決める会議よりも、何までさせないかを決める会議を急ぐべき時期だ。
