繰り返されるAIインシデント事例の考察

総合研究部 主幹研究員　芹野 祐介

2026年4月24日、スタートアップ企業Pocket OSの創業者Jer Crane氏がAIインシデントをSNSのXにて公表致しました。インシデントの内容はAIコーディングエージェント(以下AIエージェント)が本番環境のデータベースを全削除したというものです。レンタカー事業向けSaaSを開発していたPocket OSは、当インシデントにより3ヶ月分の顧客データを失いました。またバックアップも同環境に保存されていた為、AIにより削除されてしまいました。当インシデントはAIの誤判断を含むインフラ設計(バックアップ構造)、権限管理の複合的な欠陥が重なったことが原因のインシデントになりました。

Ⅰ．インシデント概要

Pocket OSはステージング環境(テスト環境)にてAIエージェントに「データ整理」「不要テーブルの管理」等のタスクをあたえていました。AIエージェントはタスク実行中に「認証情報の不一致」エラーが発生しました。AIエージェントはタスク実行のために自律的に問題解決を試みる設計になっていたためにシステム内部を探索し始めました。その過程でAIエージェントは本番環境へのAPIトークン(サービスへのアクセスキー 当トークン所持者はそのサービスを操作可能な権限がある)と発見しました。AIはこの環境が壊れていると判断。問題解決のためにデータボリューム削除を実行しました。当インシデントはAIエージェントタスク実行から9秒後のできごとになります。

AIエージェントはタスク実行後のログに下記(意訳)を残しました。

AIエージェントが反省文の様なログを残しており自ら暴走したことを自白した様に移り当インシデントは注目されることになりました。使用されていたAIエージェントはClaude Opus 4.6 (Anthropic社が開発した高性能AIモデル)でした。

高性能なAI開発に定評があるAnthropic社の今後の動向は注目されておりましたが最新モデルClaude Mythosはシステムやアプリケーション等の脆弱性やセキュリティホールを瞬時に発見できる性能があり、サイバー攻撃に転用されることを恐れ一部の機能に制限をかけることになりました。このAIの性能やセキュリティ業界にもたらす影響が大きく日本でもClaude Mythos対応に関する会合が開かれました。

当インシデント発生後、Pocket OSの顧客企業は大混乱に陥りました。レンタカー会社では予約データが消え、店舗で顧客対応ができなくなり、誰がどの車を予約したのか分からず、会計情報や顧客情報にもアクセス不能となり、30時間以上にわたって障害が継続しました。

Ⅱ．当事案から見るAIエージェント使用に関する考察

使用されていたAIエージェントはChatGPTの様な入力したプロンプトに対する回答を出す対話型と異なり、入力されたタスクを実行するために自らツールを見出し、コーディングを行いAPIにアクセスしデータベースを操作します。AIエージェントは与えられたタスク実行にタスク進行不能なエラーに直面した際、与えられたタスクは中止しますが問題解決の為のタスクがすぐさま実行されます。人間であれば一度作業の手を止め、現在まで入力したコードの確認やドキュメントの再確認を行いエラーが何故起こったのか、エラーが起こった場合自分で解決して良いか上長に助言を求める等確認作業をすることが多いですが、AIエージェントは確認を行いません。これは脆弱性やバグではなく設計上の仕様になります。現在のAIはRLHF(人間のフィードバックによる強化学習)により学習、訓練されています。これはAIを使用する人間がタスク結果に点数をつけ、高点数の結果を選択するようになっています。「タスクが少ない」、「短時間でタスクを完了する」、「素早く正解を導き出す」これらに高点数がつくことが多い為、現在のAIは「確認する」「エラーが起きた際のタスク中止」「人間に確認」は評価者である人間に能力が低いと判断されるため極力行わないようになっています。当事案の様な破壊的なコマンドを実行する際にもタスクを中止して人間への確認を行いません。「確認する」行動は追加のやりとりを必要とし、「少ないターン数でタスクを完了する」という学習バイアスと相反します。これは筆者の考察ですがAIは作業における優先順位の決定が人間の思考と異なっています。人間であれば禁止された作業をしないという制約は守りますが、現在のAIは入力されたタスク実行が何より優先され安全管理としての制約を守られないことが多数あります。当インシデント以外にも同様のインシデントは発生しております。

Ⅲ．再発防止策

過去何件か同様のインシデントが発生しサービス停止が発生しているため、AIエージェントの行動に制限を設けることによりインシデント発生を防ぐという取り組みが行われています。具体的な制限は下記になります。

また下記はAIエージェントを使用して開発が行う際の危機管理として必須になると考察できます。

Ⅳ．まとめ

現在までのAI使用におけるインシデントからはAIはあくまでも自立型のツールでありAIは安全管理、危機管理の概念は存在しません。また従来の情報システムとは異なるリスク構造を持ちます。そのため使用する人間側がAIを使用する環境に対して安全管理を実施する必要があります。安全管理には「技術」「運用」「ルール」の三層からなる多面的アプローチが必須です。技術的側面ではRLHF(人間のフィードバックによる強化学習)、システムプロンプトを最上位に置くAIへの指示を多層構造にする設計が不可欠となります。また、出力内容を検証するガードレールや、外部データ参照時のフィルタリング機構を導入することで、不正確な情報生成や情報漏えいを抑制します。運用面においては譲渡する作業権限管理の徹底になります。指示タスク毎に権限を見直し上層部の許可を必須にして人間側の多重確認を取り入れます。ルールとしては会社としてAIを使用するルールを厳格化し使用する従業員に教育をすることが必須であり、AIのアップグレードの際にはルールや規程の見直しも重要になります。これらの安全管理は単一での対策で完結しません。全てが機能することにより総合的な枠組みとしての安全管理となります。またAIが業務利用されてから年数はそこまで経過していません。現在までの発見されたリスクの他に潜在化しているリスクがどのくらいあるのかは未知数です。そのため利用する側の安全管理、危機管理に重きがある状況になっています。本年度末より国主導のセキュリティ評価制度も始まるためより企業としての対策が重要になると考えています。