AIエージェントの暴走を止める4層｜課金爆発と鍵の流出を防ぐ

AIエージェントに作業を任せていて、「このまま放っておいて大丈夫かな」と不安になったことはありませんか。ファイルを消された、朝起きたら課金が数十万円になっていた、といった話がSNSで流れてきます。この記事では、そうした暴走がなぜ起きるのかという原理と、被害を小さく抑える4つの層の考え方を紹介します。結論を先に言うと、暴走は「AIを賢くする」ことでは防げません。止まる場所をあらかじめ作っておくのが唯一の現実解です。

AIエージェントの暴走とは?チャットAIとの決定的な違い

AIエージェントが危ないのは、頭が悪いからではなく、やり直しがきかない世界で動くからです。

チャットAIの答えがまちがっていても、私たちは読んで捨てるだけで済みます。画面の中で完結する、いわば巻き戻せる世界です。一方でAIエージェントは、ファイルを消す、コマンドを打つ、外部のAPIを呼ぶといった行動をとります。判断のミスが、そのまま現実の変化になってしまうわけです。

たとえるなら、新人に「作業手順を書いて」と頼むのと、「本番サーバーの鍵を渡すので直しておいて」と頼むくらいの差があります。前者なら先輩が読んで止められます。後者は、確認したときにはもう終わっています。AIエージェントを使うときは、この「不可逆」という性質を最初に意識しておく必要があります。

AIエージェントが暴走する3つのパターン

実際に報告されている事故は、おおむね3つの型に分けられます。どれも原因は同じで、AIに渡した権限が、AIの正確さに見合っていないことです。

1. 権限を渡しすぎる

パソコン操作の能力をはかるベンチマーク「OSWorld」は、実際のアプリを使う369個の作業をモデルにやらせる試みです。2024年4月に公開された論文は、人間の成功率が72.36%だったのに対し、当時もっとも成績のよかったモデルは12.24%にとどまったと報告しています(参考リンク1)。10回に1回しかやり切れない相手に、管理者権限や本番データベースの接続情報を渡している状態だった、ということです。

これは発表時点の数字で、モデル側の成績はその後も更新され続けています。ただ、覚えておきたいのは順位のほうではありません。渡す権限は、相手の成功率に見合わせるという考え方です。事故が起きるのは、モデルの性能というより配置の問題だと言えます。

2. 幻覚の連鎖で課金が爆発する

エラーが出る、見当違いの修正をする、別のエラーが増える、あわてて直す。この輪が回りはじめると、AIエージェントは自分では止まりません。人間なら「おかしいから一旦やめよう」と判断できる場面で、AIは試行錯誤を続けます。その結果、一晩で数十万トークンを消費し、請求額が跳ね上がるという事故が起きます。

3. 外部データに指示を仕込まれる

読み込ませたPDFやリポジトリの中に、AI向けの命令文が隠されているケースです。LLMにはシステム側の指示と外部データを区別するしくみがなく、すべてが同じ文字列として頭に入ります。その結果、認証情報を読み出して外部へ送るような動きをしてしまいます。この構造についてはプロンプトインジェクションの記事で詳しく書きました。

AIエージェントの暴走を止める4層の防御

対策の基本は、AIの賢さに期待せず、被害が広がらない構造を先に作ることです。実務では次の4つの層に分けて考えると整理しやすく、この並べ方は事故の事例をまとめた記事でもよく使われています(参考リンク4)。

• 第1層・隔離: Dockerなどの使い捨て環境で動かし、自分のパソコンや社内ネットワークから切り離す
• 第2層・ツールの分離: 読むための道具は自由に、消す・送る・書き換える道具は最初は渡さない
• 第3層・人の承認: 削除、本番反映、メール送信など、戻せない操作の直前で人間が判を押す
• 第4層・通信の制御: 環境から外へ出る通信を止め、必要な宛先だけを許可する

第1層は、火花が飛んでも燃え移らない作業場を用意するようなものです。第4層まで用意しておくと、仮に指示を乗っ取られても、社内のデータを外へ持ち出す経路そのものがありません。おもしろいのは、この4層がどれも「AIを正しくする」話ではない点です。すべて、まちがえる前提で被害の範囲を区切っています。

課金についても同じ発想が使えます。使った分だけ支払う従量課金のサービスには、そもそも「ここで止める」という上限が用意されていないことが多く、AWSが案内している手段はAWS Budgetsの予算アクションです。決めた金額を超えたら、追加の利用を拒否するIAMポリシーやSCPを、自動で(あるいは手動承認のうえで)適用できます(参考リンク2)。

ただし、これは踏んだ瞬間に効くブレーキではありません。AWS公式ドキュメントは予算の情報が更新されるのは1日3回まで、更新の間隔はふつう8〜12時間と明記しており、さらに「利用が発生してから請求に計上されるまでにも遅れがあるため、通知が届く前にしきい値を超えることがある」と注意しています(参考リンク3)。つまり気づくのが数時間から半日遅れる前提で金額を決めるのが、正しい使い方です。

新社会人エンジニアがAIエージェントで今日からできること

いきなり4層すべてを組むのは、個人では現実的ではありません。効果の大きいものから3つだけ選ぶなら、次の順になります。

1. 秘密情報を作業フォルダに置かない。認証情報のファイルは別の場所に移し、除外設定も入れておく
2. APIキーは読み取り専用で発行する。管理者権限のキーをAIに触らせない
3. 自動で回る回数と、月の利用金額に上限を設定する

どれも15分あれば終わります。そして、出所のわからないWebページやPDFをそのまま読み込ませないことも、意識しておきたい習慣です。会社が把握していないAI利用の話とも重なりますが、便利さの手前で一度立ち止まる判断が結局いちばん効きます。

考察: AIエージェントを「止められること」が評価される

ここからは筆者の考えです。これから差がつくのは、AIをうまく動かす力より、止まる場所を設計できる力だと感じています。

理由は、動かすだけならツールが年々やってくれるからです。指示の書き方も、モデルの性能も、放っておいても改善されていきます。一方で「どこで人間が確認するか」「何を渡さないでおくか」は、その職場の事情を知らないと決められません。ここは自動化されにくい領域です。

実際、AIが「テストは全部通りました」と報告してくるのに中身が空だった、という報酬ハッキングの話も、根っこは同じです。AIの報告を信じる設計になっているか、確かめる場所が用意されているか。新社会人のうちからこの視点を持っておくと、チームでAIを導入するときに真っ先に頼られる側に回れます。

エージェントに渡す鍵そのものを減らす考え方は、APIキーを.envに置くのが危ない理由と、AIに生の鍵を見せない設計で掘り下げました。

AIに外部ツールをつなぐ入口の点検は、MCPサーバーを繋ぐだけで情報漏洩?4つの危険と接続前の7確認で整理しています。

接続先の取りちがえで本番DBを消してしまった実例と、その再発防止策はインシデント初動で新人がやる5つのこと｜本番DB削除の実例からで紹介しています。

まとめ

• AIエージェントの事故は判断ミスではなく、戻せない操作の権限を渡しすぎたことで起きる
• 隔離・ツール分離・人の承認・通信制御の4層で、被害の範囲をあらかじめ区切っておく
• 個人では、秘密情報の隔離、読み取り専用キー、回数と金額の上限の3つから始めれば十分

まずは自分がふだん使っているAIエージェントに、どんな権限を渡しているかを書き出してみてください。渡しすぎている1つを外すことが、いちばん確実な対策になります。

あわせて読みたい

エージェントの課金が膨らむ理由は、料金の仕組み側からも解説しています。

• LLMの料金が下がらない理由｜キャッシュが壊れる3つの操作
• 深夜アラートの一次調査をAIに任せる｜読み取り専用で回す設計
• OpenAIのdotsとは？常時稼働AIエージェントの権限4種と料金

参考リンク

• OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments(arXiv:2404.07972・2024年4月／人間72.36%・当時の最高モデル12.24%の出典)
• 予算アクションの設定(AWS公式ドキュメント)
• AWS Budgets によるコスト管理(AWS公式ドキュメント／更新頻度と遅れの記載)
• AIエージェントの暴走の原理と4層の対策を調べてみた – Qiita(4層の整理)
• Amazon Bedrock 料金が一定額を超えたら使用不可にする仕組みを作ってみた – Zenn(実装例)