Claude Codeの権限プロンプトを減らす設定 — allowlist・autoモード・sandboxの使い分け

結論

「許可 毎回」「権限 うざい」と感じる状態は、たいてい安全な操作にも一律で承認を求めているのが原因です。設定を理解すると、安全性を落とさずに承認回数だけを大きく減らせます。本記事はAnthropic公式の枠組みに沿って、3つの手段の違いと設定例を整理します。設定キーの正確な名称はバージョンで変わり得るため、不確かな箇所は概念で説明し、最終的な値は公式の settings ドキュメントで確認してください。

そもそも権限プロンプトはなぜ出る？

副作用のある操作の前に人の承認を挟む、安全装置だからです。Claude Codeはファイルの書き込み、シェルコマンドの実行、ネットワークアクセスなど「実行すると元に戻しにくい操作」の前に確認を求めます。読み取りだけの操作（ファイルの閲覧やコード検索）は基本的に止めず、状態を変える操作で立ち止まる設計です。

これは単なる利便性のためではありません。エージェントは外部から取り込んだテキスト（Web上の文書、依存パッケージのREADME、Issue本文など）に紛れた指示に引きずられることがあります。確認プロンプトは、そうした「注入された悪意ある指示」が破壊的操作に直結するのを人が止めるための防波堤でもあります。だから方針は「全部黙らせる」ではなく「安全な範囲を見極めて、そこだけ自動化する」になります。

確認を減らす3つの手段はどう違う？

allowlist・autoモード・sandboxは、それぞれ「何を信頼の単位にするか」が違います。allowlistはコマンド単位、autoモードは操作の危険度単位、sandboxは到達範囲（ファイル・ネットワーク）単位で制御します。

allowlistは「自分が安全と断言できるもの」を明示する方式なので、判断の主体はあなたです。autoモードは「危険かどうかの判断」をモデル側に委ねます。sandboxは判断を信頼せず「そもそも届かない」環境を作ります。信頼の置きどころが異なるため、組み合わせると相補的に効きます。

allowlist は settings.json でどう書く？

プロジェクトの .claude/settings.json に許可ルールを書くか、対話中に /permissions で追加します。最初は /permissions でルールを足し、固まったら settings.json に転記してチームで共有する流れが扱いやすいです。

// .claude/settings.json（概念例：キー名は公式 settings ドキュメントで確認）
{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test:*)",
      "Bash(git status)",
      "Read(./src/**)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Read(./.env)"
    ]
  }
}

ポイントは、引数まで含めて許可範囲を絞ることです。Bash(npm run lint) のように完全一致や、test:* のような末尾ワイルドカードで限定すると、「npm なら何でも実行可」のような広すぎる許可を避けられます。deny を併用すれば、.env の読み取りや rm -rf のような危険コマンドを明示的に塞げます。

autoモードの分類器は何をブロックする？

autoモードは、別の分類器モデルが操作の危険度を判定し、危険なものだけを止めて残りは自動承認する仕組みです。公式の枠組みでは、おおよそ次のような操作がブロック対象になります。

• スコープを越える操作：作業対象として想定された範囲の外に手を出そうとする操作
• 未知のインフラへのアクセス：見知らぬ外部エンドポイントや認証情報を要する接続
• 悪意あるコンテンツへの誘導：取り込んだテキストに仕込まれた指示で破壊的操作へ向かう兆候

向いているのは「方向性は任せたいが、一手ごとの承認は煩わしい」探索的な作業です。逆に、本番データや認証情報に触れ得る作業では、分類器の判断だけに依存せず後述のsandboxやdenyルールと併用するのが安全です。分類器も完璧ではないため、autoモードは「人の承認を完全に置き換えるもの」ではなく「明らかに安全な多数を素通りさせ、怪しいものだけ人に戻す」フィルタと捉えてください。

sandbox はどこに境界を引く？

sandboxは、Claude Codeが触れられるファイルと到達できるネットワークをOSレベルで制限する仕組みです。allowlistやautoモードが「操作を承認するか」を制御するのに対し、sandboxは「そもそも届く範囲」を物理的に狭めます。

境界の典型は2つです。1つはファイルシステムで、作業ディレクトリの外への書き込みを禁じる、特定ディレクトリを読み取り専用にするといった制限です。もう1つはネットワークで、外部への通信を遮断する、または許可したホストだけに限定します。境界内であればモデルは自由に動けるため、結果的に承認の数も減ります。「逸脱しようとしても環境的に不可能」という保証が、信頼の前提を一段下げてくれる点がsandboxの価値です。/sandbox などのコマンドや設定で有効化できますが、利用可能性や正確なオプションはOSと版で異なるため公式ドキュメントで確認してください。

非対話モード（claude -p）では何に注意する？

claude -p（print/非対話）やCIでの自動実行では、プロンプトに応答する人がいない点を前提に設計します。許可されていない操作に当たったとき、対話モードのように承認待ちで止まるのではなく、失敗や中断として扱われ得ます。つまり「実行中に手で許可する」逃げ道がありません。

# 非対話実行：必要な許可は事前に明示する想定
claude -p "lint と test を実行して結果を要約して" \
  --allowedTools "Bash(npm run lint) Bash(npm run test:*)"

CIや自動実行では、(1) 必要な許可をallowlistに事前明示し、(2) 危険操作はsandboxで囲い、(3) 取り込む外部入力を最小化する、の3点を揃えておくのが基本です。フラグ名やオプションは版で変わり得るので、自動化を組む前に公式の settings / CLI ドキュメントで現行の指定方法を確認してください。

「全部許可」はなぜ危険？最小権限の考え方

すべてを無条件に許可すると、安全装置をまるごと外すことになるからです。問題は「自分のミス」だけではありません。エージェントは外部テキストの指示に引きずられ得るため、全許可状態では注入された悪意ある指示がそのまま削除・送信・認証情報アクセスへ直結します。

実務での指針は「最小権限」です。デフォルトは確認ありのまま、安全と確認できた操作だけを順にallowlistへ昇格させ、削除・外部送信・認証情報アクセスは承認を残します。承認の多さは「設定不足のサイン」と捉え、毎回出るコマンドが安全と確認できたらallowlistへ、探索作業が多いならauto + sandboxへ、と段階的に整えるのが、安全性を落とさず確認を減らす近道です。

よくある質問

Q. Claude Codeの権限プロンプトが毎回出るのはなぜですか？ A. ファイル書き込み・コマンド実行・ネットワークアクセスなど、副作用のある操作の前に承認を求める設計だからです。これは「意図しない破壊的操作を人が止められる」ための安全装置で、無効化するより範囲を絞って許可するのが基本です。

Q. 確認を安全に減らすにはどれを使えばよいですか？ A. 安全と分かっている個別コマンドはallowlist、方向性は任せたいが毎手承認したくない時はautoモード、ファイルやネットワークの境界自体を制限したい時はsandboxが向きます。3つは排他ではなく組み合わせて使えます。

Q. 「全部許可」してはいけないのですか？ A. すべてを無条件に許可すると、誤った操作や外部から注入された悪意ある指示をそのまま実行してしまう余地が生まれます。許可は安全と確認できた範囲に限定し、削除・送信・認証情報アクセスなどは承認を残すのが安全です。

Q. 非対話モード（claude -p）では権限はどう扱われますか？ A. 非対話実行ではプロンプトに応答する人がいないため、許可されていない操作は承認待ちで止まるのではなく失敗扱いになり得ます。CIや自動実行では、必要な許可を事前にallowlistへ明示し、危険な操作はsandboxで囲っておく設計が前提になります。

関連記事

• Claude Code セットアップガイド
• Claude Code公式ベストプラクティス全訳＋実例補完
• hooks と MCP でエージェントの安全性を高める
• AIエージェントでよくある5つの失敗

AEO観点の設定見直しには AEOチェッカー も活用してください。