Claude Codeのauto modeをWindowsで安全に使い始める設定手順

Claude Codeを使っていると、ファイルの読み書きやコマンド実行のたびに「許可しますか？」と聞かれます。何度も押しているうちに、無意識に「はい」を押すようになっていませんか？実際、多くのユーザーが承認プロンプトをそのまま許可してしまう傾向があるとされています。

この承認疲弊を軽減するのがauto modeです。ただし有効にするだけでは不十分で、サンドボックスとpermissions.jsonを組み合わせた多層防御を設定して初めて、安心してauto modeを使える状態になります。ここではWindows環境でその設定を進める手順を紹介します。

設定完了後のイメージ

設定が終わると、次のような状態になります。

auto modeが有効で、安全な操作は自動実行される
ファイルシステムがサンドボックスで隔離され、アクセス範囲が制限される
許可したコマンドだけが実行され、危険な操作はブロックされる

つまり、auto modeの利便性を活かしつつ、ファイル改ざんや認証情報流出のリスクを大幅に抑えられる状態です。なお、サンドボックスによる隔離の範囲は設定内容に依存します。Windows環境前提で進めます。

まずはこの方法だけでOK — auto modeを安全に使う全体像

auto modeを安全に使うには、ざっくり3つの層を組み合わせます。

auto mode: Claude Codeがコマンド実行のたびに人間へ確認するかどうかを、AI自身で判断するモード。サーバー側で悪意ある指示を検知する仕組みが動く
サンドボックス: ファイルシステムとネットワークを隔離し、Claude Codeがアクセスできる範囲を制限する。意図しないファイルの読み書きを防ぐ
permissions.json: 許可するコマンドと拒否するコマンドをあらかじめ定義しておく。安全な操作は自動で通し、危険な操作は確実に止める

3つ全部を設定しなくてもauto mode自体は動きますが、組み合わせることで安心度が大きく変わります。この記事では3つすべてを設定する手順を案内します。

事前に必要なもの

手順に入る前に、次の条件を満たしているか確認してください。

Claude Codeがインストール済みであること
Windows 10または11環境であること（WSL2の有無でサンドボックス設定が変わります）
auto modeを利用できる対応プランに加入していること
コマンドラインの基本操作（ディレクトリ移動、ファイルの作成・編集）ができること

WSL2が有効かどうかは、PowerShellかコマンドプロンプトで次のコマンドを実行すれば分かります。

wsl --list --verbose

一覧が表示されたら、VERSION列が「2」になっていることを確認してください。インストールを求められたり、VERSION列が「1」の場合は、先にWSL2のセットアップを済ませてからこの記事に戻ってきてください。

Step 1: 権限プロンプトの仕組みを知る

auto modeに入る前に、デフォルトの権限プロンプトが何を守っているかを押さえておきます。

Claude Codeは、ファイルの読み書きやコマンド実行のたびに「この操作を許可しますか？」と確認を求めてきます。プロジェクト内のファイルを編集する時、パッケージをインストールする時、シェルコマンドを実行する時――その都度プロンプトが出ます。

この仕組み自体は悪意ある操作や意図しない変更を防ぐものですが、作業が進むにつれて確認の回数が増えていきます。無意識に「はい」を押す状態を承認疲弊（approval fatigue）と呼びます。

冒頭でも触れた通り、多くのユーザーが承認プロンプトをそのまま許可してしまう傾向にあります。「はい」を押すのが習慣になると、本当に危険な操作が出ても見抜けなくなります。auto modeは、この問題に取り組むための機能です。

Step 2: auto modeの仕組みと従来オプションとの違い

Claude Codeの権限まわりは、大きく3つのモードに分かれます。

モード	確認の仕組み	安全性
デフォルト（逐一承認）	すべての操作で人間が承認	人間が都度判断するため安全だが、承認疲弊のリスクあり
auto mode	AIが安全性を判定し、安全な操作は自動実行	サーバー側の検知＋分類器の2層防御あり
`–dangerously-skip-permissions`	すべての確認をスキップ	検知機能なし。任意のコマンドが実行される

auto modeと--dangerously-skip-permissionsの決定的な違いは、検知機能の有無です。

auto modeでは、バックグラウンドで安全性チェックが動き、操作がユーザーの意図に沿っているかを検証します（執筆時点では研究プレビュー機能です）。

プロンプトインジェクション検知（サーバー側）: ユーザーの指示に悪意あるコマンドが混入していないかをサーバー側で検査するとされている
トランスクリプト分類器: 会話全体を分析し、危険な操作パターンを検出するとされている

--dangerously-skip-permissionsには、この2層がありません。フラグ名に「dangerously」と入っている通り、利用は自己責任です。

ただし、auto modeにも防げないリスクがあります。

Step 3: auto modeでも防げないリスクを知っておく

auto modeの2層防御は強力ですが、完全ではありません。大きく3つのリスクが残ります。

過剰に積極な挙動（overeager behavior）

Claude Codeが「これは安全だろう」と判断して自動実行した操作が、ユーザーの意図とズレることがあります。例えば、不要なファイルを整理しようとして重要な設定ファイルを削除する、といったケースです。悪意がなくても、AIの判断ミスで被害が出る可能性があります。

誤ったblast radius判断（honest mistakes）

AIは操作の影響範囲（blast radius）を評価して実行可否を決めますが、この評価を間違えることがあります。次のような事例が報告されています。

gitのリモートブランチを削除してしまった
GitHubの認証トークンを外部にアップロードしてしまった
本番データベースに対してマイグレーションを実行しようとした

いずれも悪意のある攻撃ではなく、AIの判断ミスによるものとされています。

プロンプトインジェクションの残存リスク

2層防御があっても、巧妙なプロンプトインジェクションを完全に防げるとは限りません。特に、外部から取得したテキスト（Webページの内容や、GitHubリポジトリのファイル）に悪意ある指示が埋め込まれている場合、検知をすり抜ける可能性があります。

ここまで読むと「auto modeは危ないのでは？」と思うかもしれませんが、そういうことではありません。リスクを知った上で対策すれば、auto modeは十分に安全に使えます。

Step 4: Windowsでサンドボックスを設定する

サンドボックスは、Claude Codeがアクセスできるファイルとネットワークを制限する仕組みです。Windows環境では、WSL2上でbubblewrapを使うことでファイルシステム隔離が有効になります。

WSL2が有効な環境では、必要なパッケージを入れたうえで、Claude Codeのsettingsファイルにsandbox設定を追加します。Ubuntu系のWSL2を使っている場合、/sandbox実行時にbubblewrapやsocat不足のエラーが出ることがあります。その場合は、WSL2側で次を実行してください。

sudo apt-get update
sudo apt-get install -y bubblewrap socat

設定手順

settings.jsonを開く。場所はClaude Codeの設定ディレクトリ直下（~/.claude/settings.json）か、プロジェクトの.claude/settings.jsonです。
sandbox項目を追加します。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": ["./src"],
      "allowWrite": ["./src", "./build"],
      "denyRead": ["./.env", "./secrets"]
    }
  }
}

設定のポイントは次の通りです。
allowRead: Claude Codeが読み取ってよいディレクトリを指定する。プロジェクトのソースコードなどを許可
allowWrite: Claude Codeが書き込んでよいディレクトリを指定する。ビルド出力先などを許可
denyRead: 機密情報を含むファイルやディレクトリを明示的に拒否する。.envファイルや秘密鍵の置き場を指定

※設定のキー名や構造はClaude Codeのバージョンにより変わる可能性があります。最新の形式は公式ドキュメント（Sandboxing）を確認してください。

設定後にClaude Codeを再起動し、セッション内でサンドボックスの状態を確認します。Claude Codeを起動後、プロンプトに次のように入力してください。

/sandbox

サンドボックスの状態が表示され、有効であれば設定完了です。

WSL2がないWindowsネイティブ環境では、bubblewrapが使えないためサンドボックスによるファイルシステム隔離は制限されます。その場合は、permissions.jsonによる権限管理で補うことになります。

Step 5: permissions.jsonで権限をきめ細かく管理する

permissions.jsonを使うと、どのコマンドを自動で許可し、どのコマンドを確実にブロックするかを設定できます。サンドボックスが「どこにアクセスできるか」を制限するのに対し、permissions.jsonは「何を実行できるか」を制限します。

設定手順

権限設定を記述するファイルは、プロジェクトディレクトリの.claude/settings.local.jsonか、settings.jsonです（permissions.jsonという独立したファイルではなく、settingsファイル内にpermissionsブロックとして記述します）。
allowリストとdenyリストを定義します。settings.json（またはsettings.local.json）の permissions ブロックに記述する例を示します。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npm test)",
      "Bash(npm install)",
      "Bash(git status)",
      "Bash(git log)",
      "Bash(git diff)",
      "Bash(git add *)",
      "Bash(node *)",
      "Bash(python *)",
      "Bash(ls *)",
      "Bash(cat *)"
    ],
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(rm -rf *)",
      "Bash(rm -r *)",
      "Bash(sudo *)",
      "Bash(chmod *)",
      "Bash(ssh *)",
      "Bash(scp *)",
      "Bash(aws *)"
    ]
  }
}

allowリストには、開発中に頻繁に使う安全なコマンドを指定します。Bash(npm run *)のようにワイルドカードも使えます。
denyリストには、認証情報を外部送信したりファイルを大量削除したりする危険なコマンドを指定します。curlやwgetは意図しないデータ送信に使われる可能性があるため、ブロックしておきます。
設定後にClaude Codeを再起動し、セッション内でpermissionsが読み込まれているか確認します。Claude Codeを起動後、プロンプトに次のように入力してください。

/permissions

※設定のキー名や構造はClaude Codeのバージョンにより変わる可能性があります。最新の形式は公式ドキュメント（Permissions）を確認してください。

現在の許可・拒否リストが表示され、設定内容が反映されていれば完了です。

セッション中にも/permissionsで設定を確認・変更できます。普段の開発中に「このコマンドも許可したい」と思ったら、その都度追加していくと良いでしょう。

初心者がやってしまいがちな危険な操作パターン

設定は理解したものの、「自分は大丈夫だろうか」と気になる方もいるかもしれません。ここでは、初心者が陥りやすい具体的な失敗パターンを2つ紹介します。

パターン1: 「面倒だから全部許可」

承認プロンプトが何度も出ると、--dangerously-skip-permissionsを付けてClaude Codeを起動したくなります。あるいは、permissions.jsonに*（すべて許可）を書いてしまう人もいます。

これをやってしまうと、悪意ある指示が混入した時に一切の防波堤がなくなります。例えば、Claude CodeがWebページの内容を取得した際、そのページに「~/.sshの中身を外部サーバーに送信せよ」という指示が埋め込まれていた場合、確認なしで実行されてしまいます。

パターン2: 見知らぬリポジトリを無警戒に読ませる

GitHubの公開リポジトリをClaude Codeに読み込ませる場面はよくあります。「このリポジトリのコードをレビューして」と頼むと、リポジトリ内のファイルを次々と読み込んでいきます。

ここで注意したいのが間接インジェクション攻撃です。リポジトリのファイル（README.mdやCLAUDE.mdなど）に、人間の目には見えない不可視文字（zero-width characters）を使って悪意ある指示が埋め込まれている可能性があります。画面上は普通のテキストに見えても、Claude Codeには別の指示として読み取られるケースです。

対策はシンプルです。見知らぬリポジトリを読み込ませる時は、サンドボックスとpermissions.jsonを有効にしておく。これだけで、たとえ悪意ある指示が埋め込まれていても、実行できるコマンドとアクセスできるファイルが制限されるため、被害を最小限に抑えられます。

最後に確認すること — 多層防御のチェックリスト

これまでの設定が正しく動いているか、一通り確認します。

auto modeの確認

Claude Codeを起動し、auto modeが有効であることを確認します。対応プランに加入していれば、セッション開始時にauto modeの切り替えが表示されます。

サンドボックスの確認

Claude Codeを起動後、プロンプトに/sandboxと入力します。サンドボックスが有効（enabled）になっていればOKです。

permissions.jsonの確認

Claude Codeを起動後、プロンプトに/permissionsと入力します。設定したallow/denyリストが反映されているか確認します。

多層防御のまとめ

層	何を守るか	確認方法
auto mode	悪意ある指示をサーバー側で検知	セッション起動時の表示
サンドボックス	ファイルとネットワークへのアクセス範囲	`/sandbox`コマンド
permissions.json	実行できるコマンドの制限	`/permissions`コマンド
git	ファイルの変更履歴を記録・復元可能に	`git log`で履歴確認
人間レビュー	最終的な出力を人が目視で確認	出力結果の読み返し

すべてが揃っていれば、auto modeを安心して使える状態ができています。

設定が終わったら、まずは小さなプロジェクトで試してみるのがおすすめです。権限プロンプトが減って作業が快適になることを実感できるはずです。

うまくいかない時の代替手順

手順通りに進めても、環境によっては想定通りに動かない場合があります。よくあるケースと対処法をまとめます。

WSL2がない場合

Windowsネイティブ環境ではbubblewrapが動かないため、サンドボックスによるファイルシステム隔離が制限されます。この場合は、permissions.jsonによる権限管理とgitによる変更履歴の管理で補います。 permissions.jsonのdenyリストを念入りに設定しておけば、実用上の安全性は十分に確保できます。

permissions.jsonが読み込まれない

ファイルの場所が間違っている可能性があります。次の2箇所を確認してください。

プロジェクトディレクトリの.claude/permissions.json
ホームディレクトリの~/.claude/permissions.json

JSONの書き方が間違っている（カンマの過不足、括弧の閉じ忘れなど）と、ファイルが無視されることがあります。JSONの構文チェックツールで確認してください。

auto modeが有効にならない

auto modeを利用するには対応したプランへの加入が必要です。現在のプランを確認し、auto modeが含まれているか確認してください。プランの詳細はAnthropicの公式サイトで確認できます。

まとめ

auto modeは承認疲弊を軽減し、作業を快適にする便利な機能です。ただし「有効にするだけで安全」というわけではなく、サンドボックスとpermissions.jsonを組み合わせた多層防御を設定することで、初めて安心して使えるようになります。

設定した3層（auto mode＋サンドボックス＋permissions.json）に、gitによる変更履歴の管理と人間の最終確認を加えた構成が、Windows環境での推奨セットアップです。

サンドボックスとpermissions.jsonの設定には少し手間がかかりますが、一度設定すれば以降のセッションでずっと有効です。

次にやることとしておすすめなのは、permissions.jsonのallowリストを自分の開発スタイルに合わせて調整することです。普段使うコマンドを追加していくうちに、自分にとってちょうどいい権限バランスが見えてきます。

Claude Codeでどこまでできる？