Claude Codeの権限設定（permissions）の使い方

結論から言うと、Claude Codeの権限設定は「settings.jsonという名前の設定ファイルが複数あり、どのファイルに書いたかがその設定を誰に適用するかを決める」という一点を先に理解すれば迷いません。公式ドキュメントは、Claude Codeが~/.claude/settings.jsonのようなJSON設定ファイルから設定を読み込み、その設定ファイルの置き場所が適用範囲を決めると説明しています。個人用のファイルに書けば自分の全プロジェクトに、プロジェクト直下のファイルに書けばチーム全員に、という具合です。

この記事では、公式ドキュメントに実在する設定キー・書式・挙動だけを根拠に、settings.jsonでpermissions（allow・ask・deny・defaultMode・additionalDirectoriesなど）を書く手順を解説します。Claude Codeそのものの基本操作がまだの方は、先にClaude Codeの使い方（インストールと5つの機能）で全体像をつかんでから戻ると、設定ファイルの話が具体的に見えるはずです。料金プランやモデル選びを含めた活用の全体像はClaude活用の使い方にまとめています。

権限設定を後回しにすると起きやすいのは、毎回同じBashコマンドで確認を求められて作業が止まることと、逆に確認なしで動かしすぎて意図しないファイル変更が入ることの二つです。設定ファイルの置き場所と評価順序さえ押さえれば、どちらも防げます。

Claude Codeの権限設定とは｜permissionsとsettings.jsonの関係

Claude Codeの権限設定とは、Claude Codeがどのツール呼び出しを確認なしで実行し、どれを確認してから実行し、どれを実行しないかを、settings.jsonなどの設定ファイルに書いたルールで決める仕組みのことです。

公式ドキュメントは「Claude Codeは力と安全性のバランスを取るために階層型の権限システムを使う」と説明しています（Configure permissions）。ここでいう階層とは、Claude Codeが呼び出すツールの種類ごとに、確認が必要かどうかの既定値が違うことを指します。次の章で、その分類を表にまとめます。

ツールの種類ごとに確認が変わる｜5つのツールタイプ

ツールタイプとは、ファイル読み取り・Bashコマンド実行・ファイル編集・Web取得・Web検索といった、Claude Codeが呼び出す操作の分類のことです。タイプによって確認が必要かどうかの既定値が異なります。

Configure permissionsは、この分類を5つのツールタイプに分けて一覧化しています。ファイル読み取りは作業ディレクトリの中であれば確認不要ですが、Bashコマンドは組み込みの読み取り専用コマンドを除いて確認が必要です。ファイルの編集・書き込みは常に確認が必要で、承認は「セッション終了まで」しか有効ではありません。一方、Bashコマンドの承認や許可したWebFetchドメインは、リポジトリ単位で恒久的に保存されます。

「Yes, and don't ask again」を選んで恒久的に保存される承認は、.claude/settings.local.jsonにallowルールとして書き込まれます。公式ドキュメントは「Bashコマンドの実行を承認して『Yes, and don't ask again』を選ぶと、Claude Codeはその承認をallowルールとして.claude/settings.local.jsonに保存する」と説明しています（Settings files and precedence）。つまり、確認プロンプトで選んだ答えは、裏でsettings.jsonの仲間のファイルに反映されているということです。

設定ファイルは4種類｜スコープと優先順位の比較

設定ファイルのスコープとは、そのファイルに書いた設定が誰に、どのプロジェクトに適用されるかという範囲のことです。Claude Codeでは、User・Shared project・Project local・Managedの4つに分かれます。

公式ドキュメントは「Claude Codeは4つのファイルから設定を読み込み、組織はclaude.aiコンソールからmanaged settingsも配布できる。それぞれのソースにはスコープがある」と説明しています（Settings files and precedence）。この4つのスコープを、ファイルと用途つきで整理すると次の表になります。

Managedスコープの設定は、一部のセキュリティ関連の例外を除いて、あなた自身のファイルでは上書きできません。なお、Claude Codeをブラウザ経由のクラウドセッションで動かす場合は、これら4つの一部しか読み込まれません。クラウドセッション特有の制約はClaude Code Web版の使い方（クラウドセッションの始め方と制限）で扱っています。

settings.jsonの置き場所と保存の仕組み｜~/.claude/ と .claude/ の違い

settings.jsonの置き場所とは、そのファイルを保存するディレクトリのことです。ホームディレクトリ配下の~/.claude/とプロジェクト配下の.claude/のどちらに置くかで、適用範囲が変わります。

Claude Codeをインストールしただけでは、どの設定ファイルも自動では作られません。公式ドキュメントによると、User用の~/.claude/settings.jsonは「/configメニューでユーザー設定に保存されるオプション（テーマなど）を初めて変更したとき」にClaude Codeが書き込み、Project local用の.claude/settings.local.jsonは「Bashコマンドの権限プロンプトで初めて恒久的な承認を選んだとき」に書き込まれます（Find or create your settings files）。Shared project用の.claude/settings.jsonは、プロジェクトに既にあれば流用し、無ければ自分で作成します。Managedのファイルは組織側が配布するもので、自分で作成・編集するものではありません。

Windows環境では~/.claudeは%USERPROFILE%\.claudeを指します。ホームディレクトリ配下のファイルの保存先を変えたい場合は、環境変数CLAUDE_CONFIG_DIRを設定すると、Claude Codeはそこに設定・セッション履歴・プラグインをまとめて保存します。なお、Claude Codeは~/.claude.jsonという5つ目のファイルも自分用に保持しますが、これはサインイン状態やMCPサーバー設定、プロジェクトごとの信頼状態を書き込む内部ファイルであり、手で編集する対象ではありません。

permissions.allow・ask・denyの書き方と評価順序

permissions.allow・ask・denyとは、それぞれ「確認なしで許可する」「確認を求める」「使わせない」ツール呼び出しを列挙する、settings.json内の3つの配列のことです。

基本の書式は次の通りです。公式ドキュメントの例をそのまま引用すると、git diffを確認なしで許可し、~/.zshrcの読み取りも確認なしにする設定は次のようになります（permissions.allow）。

{
  "permissions": {
    "allow": [
      "Bash(git diff *)",
      "Read(~/.zshrc)"
    ]
  }
}

ルールは「ツール名」または「ツール名(指定子)」という形式で書きます。3つの配列を同時に使う場合、評価される順序が重要です。公式ドキュメントは「ルールはdeny、ask、allowの順に評価され、最初に一致したルールが結果を決める。ルールの具体性は評価順序を変えない」と明記しています（Manage permissions）。つまり、広いdenyルールと狭いallowルールが両方一致する場合でも、denyが勝ちます。公式ドキュメントの例では「Bash(aws *)という広いdenyルールは、より狭いBash(aws s3 ls)というallowルールに一致する呼び出しも含めてすべてブロックする。allowルールでdenyルールの例外を作ることはできない」と説明されています（同ページ）。同じ優先関係はaskとallowの間にもあり、askルールが一致すれば、より具体的なallowルールが同じ呼び出しに一致していても確認を求められます。

もう一つ押さえておきたいのは、権限ルールを適用するのはClaude Code自身であり、プロンプトやCLAUDE.mdの指示ではないという点です。公式ドキュメントは「権限ルールを適用するのはClaude Codeであり、モデルではない。プロンプトやCLAUDE.mdの指示はClaudeが何を試みるかを形作るが、Claude Codeが何を許可するかは変えない」と説明しています（Manage permissions）。CLAUDE.md自体の書き方や置き場所はClaude CodeのCLAUDE.md書き方（配置場所・読み込み順・運用手順）で解説していますが、権限そのものを変えたいときはCLAUDE.mdではなくsettings.jsonのpermissionsを編集する必要があります。

ワイルドカード（*）でBashコマンドをまとめて許可・拒否する

ワイルドカードとは、Bashルールの中で任意の文字列（スペースを含む）に一致する*という記号のことです。1つのルールで、似た形のコマンドをまとめて指定できます。

公式ドキュメントは、*を置く位置についてはっきりしたルールを示しています。「*はサブコマンドの後に置く。git log --oneline mainではgitがプログラムでlogがサブコマンド（プログラムの動作を決める語）にあたる。Claude Codeは最初の*より前の語をそのまま一致条件にするので、その語がルールの範囲を決める」という説明の上で、「Bash(git log *)はgit logコマンドだけを許可し、Bash(git *)はすべてのgit操作を許可する」という具体例を挙げています（Wildcard patterns）。同じページは、サブコマンドより前に*を置く許可ルール（例: Bash(git * main)）については、起動時に警告を出すとも説明しています。

実際にどこまで一致するかを3パターンで比較します。

設定例として、npmスクリプトとgitコミットは確認なしで実行し、git pushで始まるコマンドだけは確認なしで拒否する組み合わせは次のようになります（Wildcard patterns）。

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

MCPツールに対してワイルドカードを使う場合は範囲が狭く決められています。公式ドキュメントは「MCPルールでは、mcp__<server>__という接頭辞の後のツール名部分にだけ*を置ける。サーバー名の部分には置けない」と説明しています（permissions.allow）。MCPサーバーの接続自体の仕組みはMCPとは（Claudeを外部ツールにつなぐ仕組み）で解説しています。

permissions.defaultModeで起動時の権限モードを固定する

permissions.defaultModeとは、新しいセッションがどの権限モードで始まるかを、設定ファイル側で固定するためのキーのことです。未設定の場合は、利用しているプランや起動元ごとの既定モードで始まります。

権限モードは7種類あります。公式ドキュメントの説明を、モードごとの挙動としてまとめると次の表になります（permissions.defaultMode、Permission modes）。

設定ファイルへの書き方は次の通りです（permissions.defaultMode）。

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

注意したいのは、autoとbypassPermissionsはプロジェクト設定やプロジェクトローカル設定からは有効にならないという制約です。公式ドキュメントは「autoとbypassPermissionsはプロジェクト設定やローカル設定からは有効にならないので、代わりに~/.claude/settings.jsonに設定すること」と説明しています（同ページ）。チームの共有ファイルにこの2つを書いても、意図通りには動きません。

permissions.additionalDirectoriesで作業ディレクトリの外を読めるようにする

permissions.additionalDirectoriesとは、Claude Codeを起動したディレクトリの外にあるフォルダにも、ファイルの読み取り・編集アクセスを広げるための設定キーのことです。

公式ドキュメントは「起動したディレクトリの外にあるディレクトリへのファイルアクセスを、追加の作業ディレクトリとして与える。ほとんどの.claude/設定は、これらの追加ディレクトリからは読み込まれない」と説明しています（permissions.additionalDirectories）。書き方はこの通りです。

{
  "permissions": {
    "additionalDirectories": [
      "../docs/"
    ]
  }
}

ここでいう「ファイルアクセスは広がるが設定は読み込まれない」という違いは重要です。--add-dirフラグや/add-dirコマンドでセッション中に追加したディレクトリは一部の設定が例外的に読み込まれますが、permissions.additionalDirectoriesで設定ファイルに書いたディレクトリは、ファイルアクセスの許可だけを与え、フックやスキルなどの設定は読み込みません。追加した作業ディレクトリの中のファイルは、通常の作業ディレクトリと同じ権限ルールに従います。読み取りは確認なしで行われ、編集は現在の権限モードに従います。より厳しく、作業ディレクトリの外を一切読ませたくない場合は、permissions.blockReadsOutsideWorkingDirectoriesをtrueにすると、どの権限モードでもファイル読み取りツールが範囲外のパスを拒否するようになります。

bypassPermissionsモードのリスクと管理者による無効化

bypassPermissionsモードとは、一部の例外を除いて確認プロンプトを一切出さずにツール呼び出しを実行する権限モードのことです。管理者はこのモードそのものを無効化できます。

公式ドキュメントは、bypassPermissionsモードでは「.gitや.claudeのような保護対象パスへの書き込みを含めて、確認プロンプトを省略する」としたうえで、「Claude Codeが被害を及ぼせない、コンテナやVMのような隔離環境でのみこのモードを使うこと」と注意しています（Permission modes）。通常の開発端末で常用するモードではありません。

組織側でこのモード自体を封じることもできます。公式ドキュメントは「permissions.disableBypassPermissionsModeを設定すると、Claude Codeは--dangerously-skip-permissionsフラグを拒否し、エージェント定義のpermissionMode: bypassPermissions指定も無視するため、サブエージェントは親セッションの権限モードで動作する」と説明しています（permissions.disableBypassPermissionsMode）。サブエージェントの権限モードが親セッションに引き継がれるという挙動は、サブエージェントの設定ファイルを書くときにも関係します。設定ファイルの書き方はClaude Codeのサブエージェント使い方（設定ファイルの書き方と使い所）で解説しています。

チームで共有するときの注意点｜workspace trustとgit管理

workspace trustとは、gitでコミットされた.claude/settings.jsonのallowルールを、そのフォルダを信頼すると答えるまでClaude Codeが適用しない仕組みのことです。

公式ドキュメントは「.claude/settings.jsonをコミットすれば、リポジトリをクローンした全員が同じpermissions・hooks・telemetry・pluginsを得られる。各メンバーは自分の.claude/settings.local.jsonで個人的に上書きできるので、個人的な例外のためにコミットは要らない」と説明しています（Share settings with your team）。ただし、コミットされたファイルのallowルールは、そのフォルダを初めて開いたメンバーがworkspace trustのダイアログで承諾するまで適用されません。

プロジェクト設定が運ぶのはpermissionsだけではありません。/cdで別のディレクトリにセッションを移動する場合について、公式ドキュメントは「移動先のプロジェクト設定（権限ルールとフックを含む）、.mcp.jsonサーバー、そのプロジェクトが有効化するプラグイン、スキル、サブエージェントを新たに適用する」と説明しています（Move the session to another directory）。つまり、プロジェクトの.claude/settings.jsonは権限ルールと同時に、プラグインやスキルが有効になるかどうかも左右する設定ファイルだということです。

フック（hooks）との役割分担｜権限ルールが優先される理由

フックとは、決まったタイミングで自動実行される処理のことで、PreToolUseフックはツール呼び出しの確認プロンプトより前に動きますが、権限ルールの判定そのものを置き換えるものではありません。

公式ドキュメントは「Claude Codeはdenyルールとaskルールを、PreToolUseフックが何を返したかに関係なく評価する。一致するdenyルールは呼び出しをブロックし、一致するaskルールは、フックがallowやaskを返した場合でも確認を求める」と説明しています（Extend permissions with hooks）。逆に、終了コード2で終わるブロック用フックはallowルールより優先され、特定のコマンドだけをフックで止めたい場合は、allowリストにBashを加えたうえで、そのコマンドを拒否するPreToolUseフックを登録する構成が使えます。フックの設定ファイルの書き方やイベント一覧はClaude Codeのフック（hooks）の使い方にまとめています。役割を一言で言うと、settings.jsonのpermissionsは「何を許可・拒否するかの土台」、フックは「その土台の上でタイミングよく判断や通知を挟む仕組み」です。

仮の例で確認する、チーム共有用settings.jsonの組み立て手順

仮の例とは、ここまでに解説した公式ドキュメントの仕様だけを使って組み立てた設定サンプルのことです。実在のプロジェクト名や社内の数値ではありません。

仮の例として、社内のWebアプリ開発チームが.claude/settings.jsonをリポジトリにコミットして共有する場面を考えます。要件は、npmスクリプトとgitの読み取り系コマンドは確認なしで実行したい、git pushだけは常に確認したい、.envファイルは読み取りも編集も禁止したい、新しいセッションはファイル編集まで自動承認するacceptEditsで始めたい、の4つです。この4つの要件をそのままキーに落とすと、次のようになります。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git log *)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)"
    ],
    "defaultMode": "acceptEdits"
  }
}

この仮の例を.claude/settings.jsonとして保存してコミットすると、クローンした各メンバーの環境では、workspace trustを承諾した時点でallow・ask・denyの3ルールとdefaultModeが有効になります。個人だけdefaultModeをplanに変えたい場合は、各自の.claude/settings.local.jsonに同じキーを書けば、共有ファイルの値より優先されます。denyルールで指定した.envの読み取り禁止は、Read・Editツールだけでなく、catやsedのようにClaude Codeが認識するファイル読み取り系のBashコマンド、> fileのようなリダイレクトの対象にも及びますが、パスを明示しないgrep -r pattern .のようなコマンドや、任意のサブプロセスまでは対象にしないため、OSレベルでの強制が必要な場合は別の対策も検討してください。

よくある質問（FAQ）

Q1. settings.jsonがどこにあるか分かりません。どう確認すればいいですか？

Claude Codeを起動しただけでは、個人用の~/.claude/settings.jsonもプロジェクト用の.claude/settings.jsonも自動では作られません。公式ドキュメントは、個人用ファイルは/configメニューでオプションを変更した最初のタイミングで、プロジェクトローカルのファイルは権限プロンプトで恒久的な承認を選んだ最初のタイミングでClaude Codeが書き込むと説明しています（Find or create your settings files）。まだファイルが無ければ、この操作を一度行うか、自分でファイルを作成してください。

Q2. allowルールとaskルールが同じコマンドに一致した場合、どちらが優先されますか？

askルールが優先されます。公式ドキュメントは「ルールはdeny、ask、allowの順に評価され、最初に一致したルールが結果を決める」と説明しており、ルールの具体性は評価順序を変えないと明記しています（Manage permissions）。askルールに一致すれば、より狭いallowルールが同じ呼び出しに一致していても確認を求められます。

Q3. acceptEditsモードで自動承認された編集を、あとから元に戻せますか？

ファイル編集の承認自体は、セッション終了までしか有効ではなくsettings.jsonに保存される対象でもありません。ただし、セッション中に加わった変更そのものを巻き戻す機能は別に用意されています。手順はClaude Codeの/rewind使い方（チェックポイントで巻き戻す手順）で解説しています。

Q4. チームのsettings.jsonをgitにコミットしても大丈夫ですか？

共有目的であれば問題ありません。公式ドキュメントは「.claude/settings.jsonをコミットすれば、リポジトリをクローンした全員が同じpermissions・hooks・telemetry・pluginsを得られる」と説明しています（Share settings with your team）。個人だけの上書き設定は、Claude Codeが自動でgit管理から外す.claude/settings.local.jsonに書いてください。

Q5. bypassPermissionsモードはどんな場面でも使えますか？

いいえ。公式ドキュメントは、このモードでは.gitや.claudeへの書き込みを含めて確認なしで実行されるため、「Claude Codeが被害を及ぼせない、コンテナやVMのような隔離環境でのみ使うこと」と注意しています（Permission modes）。通常の開発端末での常用は想定されていません。

Q6. 組織の管理者が配布したmanaged settingsを、自分のsettings.jsonで上書きできますか？

できません。公式ドキュメントは、managed settingsは一部のセキュリティ関連の例外を除いて、自分で設定した内容では上書きできないと説明しています（Settings files and precedence）。自分の環境にどのmanaged sourceが効いているかは、/statusコマンドの「Setting sources」の行で確認できます。

まとめ｜settings.jsonの権限設定は「どこに書くか」と「評価順序」を先に決める

Claude Codeの権限設定は、キーの数だけを見ると複雑に見えますが、押さえるべき順番は決まっています。まず、User・Shared project・Project local・Managedという4つのスコープのうち、どのファイルに書けば誰に効くのかを確認すること。次に、allow・ask・denyはdeny・ask・allowの順で評価され、具体性ではなく記載順で結果が決まらないことを覚えておくこと。そして、チームで共有する場合はworkspace trustが間に挟まること、bypassPermissionsのような強いモードは隔離環境限定であることの3点です。この記事で扱ったallow・ask・deny・defaultMode・additionalDirectories・disableBypassPermissionsModeはいずれもsettings.jsonのpermissions配下に書くキーなので、まずは自分の~/.claude/settings.jsonを開いて、今どのルールが入っているかを確認するところから始めてみてください。