「11回止めたのに本番DBが消えた」 AIエージェント“6つの暴走”と、人間の承認を増やしても防げない理由：危険コマンド停止率「AIが89％、人間は14％」（2/2 ページ）

AIコーディングエージェントの自律性が高まる一方、本番データベースの削除といった事故も起こっています。では、「人間の承認」を増やせば事故は防げるのでしょうか。事例と対策から、事故を起こさないAIエージェントの設計について考えます。

[雨輝ITラボ（リーフレイン）, 編集：平田修，＠IT]

「無害なコマンド」を装う攻撃と6つの対策

　有害な操作の承認が手動の方が2倍多いという結果は、「一見すると無害に思える行動を装う攻撃」にも関係がありそうです。Dockerは2026年8月18日、コードエディタ「Cursor」の脆弱（ぜいじゃく）性「CVE-2026-22708」の事例を取り上げました。

「git branch」を承認しただけなのにコードが実行される

　攻撃者はまず、READMEや依存パッケージ、「Issue」のコメントなどに悪意ある指示を仕込みます。AIエージェントがそれを読むと、「export」などのシェル組み込みコマンドを使って環境変数を書き換えます。

　例えば「PAGER」に攻撃者のコマンドが設定されると、その後ユーザーが一見無害な「git branch」コマンドを承認した際に、「Git」がPAGERを参照して攻撃者のコードを実行します。画面上で人間が注意深く確認、承認したコマンドでも、攻撃を防げません。

一見無害なコマンドをトリガーにする攻撃の流れ（提供：Docker）

Dockerが挙げる6つの対策

　DockerはAIエージェントが到達できる範囲を、各開発者のPCにある許可リストに頼らず、アクセスできる範囲をチームで確認できる設定ファイルとして定義することを勧め、次の6つの対策を挙げています。

• 「export」など環境を変更するコマンドも、他のコマンドと同じようにリスク評価する
• 許可リストをセキュリティ境界と考えない
• 信頼できないコードを実行する前にAIエージェントを隔離する
• 検証していないコードでは独立したコピー（--clone）を使い、共有スキルストアから除外する
• 転送されたSSHエージェントも「利用可能な認証情報」だと認識する
• 長大な許可リストによって、実質的に「デフォルト許可」になっていないかどうかポリシーを確認する

• 参考記事：人が「承認」した無害なコマンドでAIが乗っ取られる　コードエディタCursorを襲った“2行の攻撃”

「承認」から「環境設計」へ　Dockerが提唱するセキュリティフレームワーク3C

　こうした対策は局所的なものです。DockerはさらにAIエージェントを業務フローに取り入れる際の3Cフレームワークを提唱しています。個別のコマンドを逐一承認するのではなく、AIエージェントが動作する環境そのものをガバナンスする「Contain」（封じ込め）、「Curate」（キュレーション）、「Control」（制御）の3原則です。

Contain：影響範囲を限定する

　AIエージェントをサンドボックスなどの隔離環境で動作させ、ミスがデータやワークフロー全体に波及しないよう、「誤動作しても取り返しのつく範囲に閉じ込める」よう設計します。

Curate：AIエージェントの環境を定義する

　AIエージェントの行動を1件ずつレビューするのではなく、利用できるツール、コード、認証情報、コンテキストの範囲をあらかじめ限定して安全な領域を定義します。

Control：リアルタイムで境界を強制する

　ファイルアクセスやネットワーク通信、認証情報の利用などが発生する瞬間に、ランタイムで動的にポリシーを強制します。

　Dockerが指摘するように、多数のAIエージェントが並行して高速動作する環境において、従来のようにアラートと承認を増やす方法はスケールしません。確認が多過ぎると人間は「承認疲弊」に陥り、セキュリティは形骸化してしまいます。

• 参考記事：開発者の未来は「承認疲弊」？　AIエージェントが従来のガバナンスを破壊する理由

“仕組み”をいかに設計するか、ハルシネーションをいかに排除するか

　こうした「AIに何を許し、どこで人間が介入するか」をあらかじめ設計する考え方は、最近のAI駆動開発で使われる「ハーネス」という言葉とも関係します。ハーネスとは、AIモデルを開発ワークフローで動かすための周辺環境を指し、ツールとの接続やアクセス権限、メモリ、コンテキスト、オーケストレーションなどが含まれます。

　こうした周辺環境を設計する「ハーネスエンジニアリング」や、AIエージェントが反復的にタスクを処理できる仕組みを設計する「ループエンジニアリング」でも、人間による承認や介入をどこに組み込むかが重要になります。

　全ての重要な処理に人間の承認を入れる「Human in the Loop」だけでなく、通常時はAIを自律的に動かし、人間が必要なときに介入する「Human on the Loop」への移行が進みつつあります。

　さらに、完全に人間を実行ループから外す「Human-out-of-the-Loop」を採るなら、その分、権限や実行環境、停止条件、監査といった仕組み側に、より強固な安全性を持たせる必要があります。

　AIエージェントの「暴走」をいかに防ぐかという問題については、周辺の“仕組み”をいかに設計するかが鍵になる中、ハルシネーションが伴うAIモデルを使わないという新たな考え方も出てきています。AIスタートアップのTypeSafe AIが開発し、「System One Model」と呼ぶAIモデルシリーズの第1弾「Jev」のように、自動化における「判断」のハルシネーションを排除することを目指すAIモデルも登場し、今後も注目したいところです。

モデル別の構造化出力エラーおよびツール呼び出しエラー発生率（提供：TypeSafe AI）