Claude初心者がAutoModeでも安心できるセキュリティ設定をしてみた話

はじめに

Claude Codeで開発していると、コマンドを実行するたびに確認プロンプトが表示され、作業が中断してしまいがちです。この確認を減らし、開発効率を上げるのに便利なのが自動モード（auto mode）です。

自動モードには危険な操作を止めるセーフティ機能も備わっていますが、Claude Codeを使い始めたばかりの私としては「本当に危険な操作を確実に防いでくれるのか？」という不安がありました。「効率化はしたいけれど、破壊的な操作は絶対に防ぎたい」――そう考え、Claude Codeにどのようなセキュリティ機能が備わっているのかを調べてみました。

この記事では、自動モードの仕組みを整理したうえで、Claude Codeのセキュリティ機能（hooks・permissions・サンドボックス）を組み合わせた多層防御の設定内容をご紹介します。

自動モードでできること

自動モードとは、確認プロンプトを都度出す代わりに、別の分類器（Classifier）モデルが実行前の各操作をチェックする権限モードです。

ユーザーの指示範囲を逸脱した操作や、想定外のインフラに対する変更、プロンプトインジェクション（ファイルやWebページに仕込まれた不正な指示）と疑われる挙動などを検知してストップしてくれます。CLIでは Shift+Tab を押すことでモードを切り替えられます（※利用可能なプランやモデルなどの条件は公式ドキュメントをご参照ください）。

初期設定における判定例は以下のとおりです。

どこまで防いでくれるのか

非常に便利な自動モードですが、公式ドキュメントには「権限プロンプトを減らすためのものであり、安全性を保証するものではない」と明記されています。

• AIによる判定の限界：判定を行うのはAI分類器であるため、誤検知や見逃しが起こる可能性があります。
• 指示の消失リスク：会話の中で「プッシュしないで」と伝えていても、コンテキストが圧縮（要約）されると指示が抜け落ちることがあります（※確実に防ぎたい場合はdenyルールの使用が推奨されています）。
• デフォルト許可の存在：.env の読み取りなど、初期設定のままだと許可されてしまう操作もあります。

つまり、自動モードはあくまで「判断をAIに委ねる層」に過ぎません。絶対に実行されては困る操作は、ルールを明文化して決定論的（確実）にブロックする必要があります。そのための仕組みが、次に紹介する hooks・permissions・サンドボックス です。

参考：権限モードを選択する - Claude Code Docs

Claude Codeのセキュリティ機能

サンドボックスの種類と選び方

公式ドキュメントにおいて、サンドボックスはClaude Codeの実行環境を分離するアプローチの総称として扱われており、分離範囲に応じて複数の選択肢が用意されています。

下に行くほど保護できる範囲は広がりますが、そのぶん準備や運用の手間も大きくなります。

参考：サンドボックス環境を選択する - Claude Code Docs

今回「Bashサンドボックス」を選んだ理由

• ローカル環境で画面を見ながら作業するスタイルだから
  ドキュメントでも、日常の開発で確認プロンプトを減らしたい場合の第一候補としてBashサンドボックスが挙げられています。確認を一切スキップする --dangerously-skip-permissions を使う場合はコンテナ等での厳格な隔離が推奨されますが、自動モードにおけるサンドボックスは「追加の防御層」という位置付けです。そのため、今回は環境丸ごとの隔離までは不要と判断しました。
• 導入コストが低く、Dockerも不要
  macOSであれば追加のソフトウェアなしで利用でき、settings.json に数行設定を追加するだけで有効化できます。まずは仕組みを理解し、試してみたい段階に最適です。
• 管理設定でチームに強制できる
  上記の選択肢のうち、Claude Code自身の設定（managed settings）としてチーム全体に強制できるのはBashサンドボックスのみです。DevContainerもリポジトリ単位で環境を統一できますが、ローカルでコンテナ外の実行を防ぐことまではできません。

割り切ったポイント

Bashサンドボックスが保護するのはBashコマンドのみです。Claudeの組み込みツール（Read・Edit・WebFetchなど）はpermissionsのルールで制御され、MCPサーバーやhooksスクリプトはホストOS上で直接動作します。

「Bashサンドボックスでカバーできない穴は、permissionsとhooksを組み合わせて塞ぐ」というのが今回の設計方針です。将来さらに広範な安全性を求めたくなった場合は、DevContainerやサンドボックスランタイムの内側でBashサンドボックスを併用する多重化も可能です。

3つの役割分担

採用した「Bashサンドボックス」「permissions」「hooks」の役割分担を整理すると、以下のようになります。

（◎＝主な役割、○＝対応、△＝技術的には可能（自作スクリプト等が必要）、✕＝対象外）

3つは防ぐ対象も動くタイミングも違うため、どれか1つではなく組み合わせて使うことが大切です。なお、Bashサンドボックスは初期状態では無効のため、/sandbox コマンドか sandbox.enabled 設定で有効化が必要です。

実行される順番

以下は公式ドキュメントに掲載されている、Claude Codeの実行ライフサイクルです。コマンド実行に関連するステップ（PreToolUse → PermissionRequest → [tool executes]）に、今回導入した3つの機能がそれぞれ対応しています。

出典：Hooks reference - Claude Code Docs

1. PreToolUse
   hooksで設定したスクリプトが最初に評価されます。仕様上は allow / deny / ask の判定を返せますが、今回のスクリプトでは「危険なコマンドを検知したら deny で遮断、それ以外は素通りさせる」というシンプルな実装にしています。ここで deny された場合、コマンドの実行はその場で即時中断され、以降のステップには進みません。
2. PermissionRequest
   PreToolUseを通過したコマンドに対し、permissions（deny → ask → allow の優先順）が評価されます。git commit や git push など ask に指定したコマンドは、ここで確認プロンプトが表示されます。なお、仮にhooks側が allow を返していても、permissions側で ask に該当していれば確認プロンプトが出ます（hooksの allow はpermissionsの ask / deny を上書きしません）。
3. [tool executes]
   実際にコマンドが実行されるフェーズです。Bashコマンドの場合、ここでOSレベルのBashサンドボックスが機能します。.env の読み取りや未許可ディレクトリへの書き込みなどは、仮にhooksやpermissionsをすり抜けたとしても、この段階でOSレベルでブロックされます（※ReadやEditなどの組み込みツールはサンドボックス対象外のため、permissions側で保護します）。

つまり、「hooksとpermissionsは実行前に論理的に止めるフィルター」「Bashサンドボックスは実行時の物理的なアクセスを制限する最後の砦」という順序で多層防御を構成しています。

なお自動モードを利用している場合は、ステップ2（PermissionRequest）で確認プロンプトを出す代わりにAI分類器が判定を行います（ただし、明示的に ask ルールに設定した操作は自動モードでもプロンプトが出ます）。

参考：

• Hooks reference
• Configure permissions

設定ファイル

実際に ~/.claude/settings.json（グローバル設定）に記述した内容の抜粋です。

{
  "permissions": {
    "allow": [
      "Bash(gh *)",
      "Bash(git fetch *)",
      "Bash(git pull *)"
    ],
    "ask": [
      "Bash(git commit *)",
      "Bash(git push *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": [
        "**/.env", "**/.env.*",
        "~/dev/**/.env", "~/dev/**/.env.*"
        // ほかにも秘密鍵・AWS認証情報などを同様のパターンで追加（省略）
      ],
      "allowRead": ["**/.env*.example", "~/dev/**/.env*.example"]
    }
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "python3 ~/.claude/hooks/block-destructive-bash.py" }
        ]
      }
    ]
  }
}

• permissions.allow：gh・git fetch・git pull など、環境を破壊するリスクが極めて低いコマンドは確認なしで自動実行させます。
• permissions.ask：git commit・git push など、実行前に内容をレビューしたいコマンドは毎回確認プロンプトを出します。
• sandbox.filesystem：.env や秘密鍵などの機密ファイルへのアクセスを拒否します。
• hooks.PreToolUse：Bash実行直前にスクリプトを実行し、破壊的コマンドを検知します。ask による目視確認だけでは見落とすリスクのある、本当に危険な操作を一律で弾きます。

hooksがブロックするコマンド一覧

フック用のPythonスクリプトで検知・ブロックしている主なコマンドは以下のとおりです。

なお、このスクリプトはクォートで文字列を分断する、エイリアスを経由する、オプションの順序を入れ替える、sudo や eval、bash -c / sh -c などのサブシェルでラップするといった、典型的な検知回避パターンにも対応できるように組まれています。

設定手順

1. ~/.claude/settings.json を開き、安全なコマンドを permissions.allow に、確認したいコマンドを permissions.ask に追加します。
2. 同ファイルの sandbox.filesystem に denyRead（読み取り拒否パターン）と allowRead（例外許可パターン）を設定します。開発ディレクトリ配下の全プロジェクトに適用したい場合は、**/.env だけでなく ~/dev/**/.env のように起点パスを明示すると確実です。
3. ~/.claude/hooks/ ディレクトリを作成し、破壊的コマンドを検知するPythonスクリプトを配置して chmod +x で実行権限を付与します。
4. settings.json の hooks.PreToolUse に、作成したスクリプトを呼び出す設定を追加します。
5. 新しいClaude Codeセッションを立ち上げ、設定を反映させます。
6. 使い捨ての検証用リポジトリを用意し、危険なコマンドや機密ファイルの読み取りが意図通りブロックされるかテストします（※設定しただけで安心せず、必ず実機で動作確認しましょう）。

実装によって実現できたこと

• 3段階の役割分担の確立
  「安全なコマンドは自動実行」「要確認コマンドは都度チェック」「破壊的な操作は強制遮断」という明確なポリシーを、permissions.allow・permissions.ask・hooks の3つに綺麗にマッピングできました。
• permissions.deny をすり抜ける高度な危険操作のブロック
  permissions.deny は単純な文字列パターン一致で判定されるため、オプションの順序変更や bash -c でのラップ等ですり抜けてしまう弱点があります。スクリプトを用いた構文解析を挟むことで、表記揺れや回避手口にも耐えうるガードレールを構築できました。
• プロジェクト横断での機密情報アクセスの遮断
  Bashサンドボックスを活用することで、cat .env のようなコマンドによる機密情報の漏洩を、開発ディレクトリ配下の全プロジェクトに対して一括で制限できるようになりました。
• 多層防御による安全性の担保
  自動モードのAI分類器だけに依存するのではなく、決定論的な静的ルールとサンドボックスを組み合わせることで、「効率化」と「安全性」を両立させることができました。

残る限界・スコープ外としたこと

• 動的なシェル変数展開やコマンド置換の検知
  例えば CMD="reset --hard"; git $CMD のような記述は、静的解析の段階では検知できません。これはシェルスクリプトの仕様上、原理的な限界といえます。
• gitやrm以外の削除コマンド
  find -delete や Pythonの shutil.rmtree など、ファイルを削除する手段は無数に存在します。これらをスクリプトですべて網羅するのは現実的ではないため、今回は意図的にスコープ外としています。

おわりに

手作業（オーガニック）でコードを書いていた時代は「自分が打つコマンドは自分が責任を持つ」で済みましたが、AIエージェントに自律的なコマンド実行を任せる現在においては、「何をAIに任せ、どこで人間が介入し、何をシステムとして遮断するか」をあらかじめ設計しておくことが欠かせません。

Claude Codeの確認プロンプトの多さに悩んでいる方や、自動モードを導入したいけれど安全性が心配という方の参考になれば幸いです。