AIエージェントの暴走を止める方法｜承認ゲートの置き方

「AIエージェントが勝手に変なことをしないか」。導入をためらういちばんの理由がこれです。ただ、実際に止めるのは大きなボタンではありません。設定ファイルに書く数行のルールです。

AIが意思を持って走り出すわけではありません。決めていない操作を、人の確認なしに実行してしまう——これが実務での「暴走」です。とくに外に出る操作（メール送信・公開・課金・削除）は、走ると取り消せません。だから止め方は「どの操作の直前で人が確認するか」を先に決めることになります。

AIエージェントの暴走を止める方法｜この記事で作るもの

道具は、当社が自社の業務を回している Claude Code を例にします。設定ファイル（settings.json）にルールを書いて、外に出る操作の直前に人の確認を挟むのが今日作るものです。設定名はこの道具のものですが、「禁止・確認・許可を分けて書く」考え方はどの道具でも同じです。

準備｜止めたい操作を先に3つに分ける

ルールを書く前に、社内の操作を3つに仕分けます。仕分けが先、設定はそのあとです。

• 禁止（deny）……絶対にさせない操作。本番データの削除、外部への一括送信、課金
• 確認（ask）……人が見てから通す操作。外部サイトへのアクセス、ファイルの上書き
• 許可（allow）……確認なしで走ってよい操作。テストの実行、下書きの生成

入れてよい情報の線引きも同じ場所で決めます（生成AIの社内ルールの作り方に手順があります）。この記事のルール例は、動作を確かめたダミーです。

承認ゲートの置き方｜設定ファイルにルールを書く

ルールは3種類、順番で決まる

Claude Code の権限は settings.json の permissions に書きます。ルールは3種類です。

• allow……確認なしで実行してよい
• ask……実行の直前に人へ確認を求める
• deny……実行そのものを禁止する

いちばん大事なのは照合の順番です。公式ドキュメントは「ルールは deny、ask、allow の順に評価され、最初に当たったもので結果が決まる」と書いています。禁止が先、許可が最後です。

最小の承認ゲート

たとえば「テストは自由に流す、コミットは自由、でもプッシュだけは止める」なら、こう書きます。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

末尾の * は続く任意の文字列に当たり（Bash(git push:*) も同じ）、git push origin main も git push --force もブロックされます。git push を allow に足しても無駄です——公式ドキュメントは「広い deny は、より細かい allow が同じ呼び出しに当たってもブロックする。allow は deny の例外を作れない」と明記しています。

「止める」ではなく「確認を挟む」なら ask

完全には禁止せず、人が見てから通したいものは ask に書きます。WebFetch を ask にすると、外部サイトへアクセスする直前に確認を求めます。ask は allow より優先されるので、うっかり広い allow を書いても、ask の操作は必ず確認で止まります。

ツールごと外す

ある道具を丸ごと使わせたくないときは、deny にツール名だけを書きます。公式ドキュメントによれば、Bash のようにツール名だけを deny に書くと、そのツールはエージェントから見えなくなります（Bash(rm *) のように絞れば、ツールは残したまま当たった呼び出しだけを止めます）。

人が止める場所｜承認・確認・ログの3つ

承認は上のルールそのものです。外に出る操作を deny か ask に置けば、そこが承認ゲートになります。

確認は、動いたあとに人が1行で見る仕組みです。指示文に「処理した件数と、止めた操作の件数を3行で報告する」と書かせておくと、毎回の数字だけで異常に気づけます。

ログは、後から数えられる形の記録です。ここで注意が1つ——実行一覧が「成功」でも、タスクが正しく終わった意味ではありません。返るのは起動の成否です。「緑だから正しく動いた」と読まないでください（詳しくはAIエージェントの作り方に書きました）。

うまくいかないときの直し方

• deny に書いたのに実行された……別の書き方で呼ばれています。公式ドキュメントは「Bash ルールはコマンド文字列への照合で、プログラムを囲む安全境界ではない」と書いています。確実に止めたい範囲は、後述のサンドボックスと併用します
• ask にしたのに確認が出ない……許可モードが bypassPermissions になっていないか確認します。このモードは確認を飛ばします
• 確認が多すぎて進まない……確認は「外に出る操作」だけに絞ります。読み取りやテストまで ask にすると、毎回止まって回りません
• 自律実行で承認が効かない……スケジュール実行のような自律の経路には、そもそも確認モードの選択がありません。その場合は指示文の側にゲートを書きます（次の節）

判定表｜どの操作を、どのルールに置くか

当社が承認ゲートを組むときの表です。軸は「取り消せるか」の1つにしています。

×の操作は「今は難しい」ではなく、ルールで止めたうえで権限そのものを渡さないという意味です。ルールは道具に承認機能があるときの話で、自律実行で承認機能が無い経路では、指示文に「送信・公開・課金・削除はしない。手前で止めて報告する」と書き、外に出る連携を最初から渡さないほうが確実です。

確実に止めたい範囲は、文字列一致のルールだけでなく通信とファイルを遮断するサンドボックスと併用します。公式ドキュメントも、コマンドの書き方に依存しない遮断にはサンドボックスを使うよう案内しています。

自社でやるのが大変なときの頼み先

最初の1本は自社でも組めます。難しくなるのは、業務が増えて「どの操作にどのゲートが要るか」の判断が積み上がってからです。作る側を外に頼むならAIエージェント開発会社の比較、運用ごと頼むならAI導入の伴走支援サービスの比較に、公式サイトの記載だけで並べています。当社も自社の業務をこの形で回しています。

止める場所を決める前に、任せてよい業務かを確かめておく

承認ゲートは、任せる業務が決まってから置けます。決まっていない段階でいちばん危ないのは、取り消せない操作を最初の1本に含めてしまうことです。

AI適合度診断は10問で、どこから手を付けるべきかを点数にします。連絡先の入力は要りません。 作りたいものが決まっているならAI見積もりに書くと約3分で概算が出ます。

出典

• Configure permissions｜Claude Docs（2026年9月22日閲覧）——allow / ask / deny の意味、deny → ask → allow の評価順、Bash(...) の書式と *・:*、ツール名だけの deny、Bash ルールが安全境界ではないこと、サンドボックス併用
• Settings files and precedence｜Claude Docs（2026年9月22日閲覧）——settings.json の permissions の書き方、defaultMode、bypassPermissions の扱い