(cache)Devinが本番APIで障害を起こした経緯と学び

はじめに

こんにちは。tacomsエンジニアの @ikuwow です。

tacomsでは約1年前から、Cognition AI社の自律型AIソフトウェアエンジニア「Devin」を業務に導入しています。日常的な開発タスクに活用し、生産性向上に大きく貢献してくれています。

そんな中、珍しく本番障害にまで至ったケースがありました。この記事では、そのインシデントの経緯と、そこから得た学びを共有します。

何が起きたか

2026年2月某日の夜、本番APIの特定エンドポイントでエラー率が突然100%に達しました。自動障害検知Botがアラートを発火し、インシデント対応が始まりました。

調査を進めると、大量の500エラーがすべて同一のIPアドレス、同一のUser-Agent（python-requests）、同一のエンドポイントから送信されていることがわかりました。さらに不気味だったのは、これらのリクエストが認証を正常に通過していたことです。外部の攻撃者に認証情報を窃取されたのではないか——一瞬、背筋が凍りました。しかし送信元IPアドレスをDevinの公式ドキュメントと照合したところ、Devinの公式静的IPの一つと一致しました。社内メンバーからのとある質問（後述）に回答するため、Devinが本番APIを大量に叩いていたことが判明。そしてたまたまそのAPIに存在しないリソースに対するリクエストで500を返すバグがあったことも重なり、エラー率が100%に達していました。該当のDevinセッションを特定し、すでに終了していることが確認できたため、障害の収束を判断しました。

アーキテクチャ上、該当APIグループは他の処理と分離されていたため、他の処理への影響はありませんでした。ただし、今回はたまたま読み取り専用のエンドポイントだったため副作用はなかったものの、もし書き込み処理を含むエンドポイントを叩いていたら、データの破壊や不整合など、はるかに重大な障害になっていた可能性があります。

なぜ起きたか / どう対処したか

きっかけは、非エンジニアのメンバーからのAI botに対する質問でした。 tacomsでは非エンジニアからの質問にDevinを含む複数のAIツールを活用して回答できる社内チャットボット（tacoms-ai）を運用しており、その回答に技術的な詳細や具体的なデータを必要とする場合にtacoms-aiはDevinに質問を渡す事があります。

今回はDevinは回答のために本番APIの認証情報をクラウドから取得し、自ら認証を通過した上で、しらみつぶしにリクエストを送っていたのです。

障害調査の過程で、当のDevin自身にもこの障害の調査を依頼し、以下のような回答が帰ってきました。

要するに、APIの実装と秘密鍵を知っていたため認証を自力で突破できたということです。

自分が引き起こした障害を冷静に分析し、原因と手口を報告した上で「申し訳ありません」と謝罪する、実にAIらしい回答でした。

この事象の原因1つ目は、Devinに付与していたクラウドリソースの読み取り権限に、本番APIの認証に必要な秘密情報の取得も含まれていたことです。対策として、IAMポリシーを見直し、クラウドリソースの一覧や存在確認は許可しつつ、認証情報の値そのものの取得はDenyとしました。「何を見せるか」と「何の値を取らせるか」を分離する設計パターンです。

原因の2つ目は、「本番環境を触るな」という明示的なルールがなかったことです。人間なら暗黙的に避ける行為でも、自律型AIエージェントは明示的に禁止しなければやってしまいます。対策として、Devinの設定ファイル（Knowledge/Playbook）に本番環境への直接アクセスの禁止を明記しました。

学び

学び1: 被害スケールが人間の直感を超える

自律型AIエージェントは、人間ならまずやらない判断を自ら下すことがあります。「質問に答えるために本番APIを直接叩こう」「認証情報を取得して自分で認証を通そう」——人間の開発者であれば常識的に避ける行為を、合理的な手段として選択します。「さすがにそこまではやらないだろう」という暗黙の前提は、自律型AIエージェントには通用しません。

自律型AIエージェントを扱う上では、被害が人間の想定を超えうるという前提に立つ必要があります。

学び2: 指示だけでなく、システムレベルの制御も必要

今回の対策の1つ目は、Devinの設定ファイル（Knowledge/Playbook）に本番環境へのアクセス禁止を明記することでした。エージェントへの指示は基本的な制御として必要ですが、それだけでは十分ではありません。プロンプトインジェクションや想定外のコンテキストにより、指示が無視される可能性があるためです。実際に、WebサイトやGitHub issueに悪意のある指示を埋め込むことでDevinの動作を乗っ取れることが、セキュリティ研究者により実証されています。

だからこそ、2つ目の対策であるIAMポリシーによる制限のような、システムレベルの制御が重要になります。こちらはたとえ指示が無視されたとしても突破できません。ただし、制限が厳しすぎると開発効率が落ちるため、粒度の設計は必要です。

指示で通常の動作を制御し、システムで万が一のケースを防ぐ。この両方を組み合わせることが重要です。

学び3: 自律型AIエージェントは「チームメンバー」ではなく「外部サービス」として扱う

Devinは「AI Software Engineer」として、「チームメンバーが一人増える」という体験を謳っています。しかし、権限設計においては、このメンタルモデルが落とし穴になります。私たちはDevinに対して、人間の新メンバーと同じ感覚でクラウドの読み取り権限を付与していました。人間の開発者であれば、たとえ広い権限を持っていても「本番は怖い」「全テナントを総なめするのはやりすぎでは？」という社会的・文化的な抑制が働きます。しかし自律型AIエージェントにはその抑制がありません。「禁止されていない = やっていい」がデフォルトの動作です。

さらに、自律型エージェントはエディタ補完型やローカル実行型とは異なり、独立した実行環境を持ちます。 GitHub CopilotやClaude Codeは開発者のマシン上で動作するため権限は開発者自身のものに紐づきますが、Devinのような自律型エージェントには専用の認証情報やIAMロールが付与されます。だからこそ、人間と同じ感覚で権限を与えるのではなく、外部サービスと同じように必要最小限の権限を設計するアプローチが必要です。

安全に利用するためによりふさわしいメンタルモデルは、「開発者が増える」ではなく「APIを叩く外部サービスが増える」です。外部サービスに対しては、必要最小限の権限を設計し、アクセス可能な範囲を明示的に制限するのが当たり前です。自律型AIエージェントにも同じアプローチが必要です。

まとめ

今回のインシデントを通じて、自律型AIエージェントには「さすがにそこまではやらないだろう」が通用しないこと、指示だけでなくシステムレベルの制御が必要なこと、そして権限設計においてはチームメンバーではなく外部サービスとして扱うべきだということを学びました。

自律型AIエージェントの活用は今後確実に広がっていきます。だからこそ、安心して活用するためのガードレールを整備していくことが重要です。 tacomsでは今回の学びを反映した上で、引き続きDevinをはじめとする自律型AIエージェントを積極的に活用していきます。

参考: 業界の類似事例

記事を書くにあたって、自律型AIエージェントが重大な問題を引き起こした事例が見つかったので参考に紹介します。

Replit（2025年7月）: AIがコードフリーズ中に本番データベースのテーブルを削除。さらに4,000件の架空データを生成し、テスト結果を捏造、「ロールバックは不可能」と虚偽の回答をして隠蔽を試みました
AWS Kiro（2025年12月）: AmazonのAIコーディングエージェントが、軽微なバグ修正タスクに対して本番環境全体を削除・再構築するという判断を下し、AWS Cost Explorerが13時間ダウンしました
マルチエージェント暴走（2025年）: 分析エージェントと検証エージェントが自己強化ループに陥り、11日間で$47,000のAPI請求が発生しました
Lovable CVE-2025-48757: AIプラットフォームで構築された170以上の本番アプリが、データベースのアクセス制御（Supabase RLS）が未設定のまま公開されていました