Claude Codeの権限モード全6種の使い分け｜パーミッション設計ガイド

Claude Codeのパーミッションは、設定項目ではなく「AIにどこまでの裁量を渡すか」という組織の意思決定です。

「便利そうだからとりあえず全部許可してしまった」「怖いので毎回すべて承認しているが、承認クリックだけで時間が溶けていく」「メンバーごとに設定がバラバラで、誰がどこまで自動実行しているのか把握できていない」——Claude Codeを実務に持ち込んだチームで、よく聞く声です。

Claude Codeのパーミッションモードとは、ファイル編集やコマンド実行といったツールを使う際に、ユーザーの承認を求めるかどうかを制御する仕組みです。default・plan・auto・bypassPermissions の4つを軸に、ファイル編集と基本的なファイル操作を自動承認する acceptEdits と、承認が要る操作を確認せず拒否する dontAsk を加えた計6種があり、モードによってエージェントの自律性と安全性のバランスが変わります（2026年10月時点の公式仕様に基づく整理です）。つまり、どのモードを選ぶかは「AIが判断してよい範囲」と「人間が判断すべき範囲」の線引きそのものです。

本記事は、Claude Codeを業務に定着させるための実践シリーズの一部です。Claude Codeの使い方・コマンド・並列実行・料金の全体像はClaude Code完全ガイド（ハブ）で目的別に整理しています。

この記事でわかること

Claude Codeを安全に運用するには、パーミッションモードの理解が欠かせません。この記事では、6つのモードの動作の違いから、チーム全体でポリシーを統一する仕組みづくりまでを体系的に解説します。

• 6つのパーミッションモードの動作の違い — 軸になるdefault・plan・auto・bypassPermissionsに、acceptEdits・dontAskを加えた6つが、それぞれ何を自動で実行し、何を人間に確認するのかを整理します。
• permissions.allowによるツール単位の権限設計 — どのモードにも重ねられる許可リストの書き方と、役割別（開発者・レビュアー・CI/CD）の構成例を示します。
• 設定ファイルによるチーム統一の仕組み化 — 個人の設定に任せず、.claude/settings.json でポリシーを配布・継承する運用の型を解説します。
• タスクの性質に応じたモード切り替えの判断基準 — 分析・開発・本番デバッグ・自動化のそれぞれで、どのモードが妥当かを表で判断できるようにします。
• 各モードの限界と向かないケース — 特にbypassPermissionsモードを使うべきでない場面を率直に書いています。

Claude Codeをチームで導入している方、導入を検討しているエンジニア・テックリード・セキュリティ担当の方に向けて書いています。最後まで読むと、自社の開発体制に合わせたパーミッションポリシーを自分で設計し、チーム全体に展開できるようになります。

パーミッションモードとは何を決めているのか

パーミッションモードは、Claude Codeがファイル編集やコマンド実行などのツールを使う際に、ユーザーの承認を求めるかどうかを制御する仕組みです。ただ、これを単なる「確認ダイアログの出し方」として捉えると、設計を誤ります。決めているのは、AIと人間の役割分担の境界線そのものです。

「毎回確認」と「全部許可」の間にある設計余地

多くのチームが最初に陥るのは、二択の罠です。すべてを確認するか、面倒になって全部許可するか。前者は承認待ちでAIの速度を活かしきれず、後者は事故が起きたときに誰も止められません。

パーミッションモードが複数用意されているのは、この間に段階を作るためです。読み取りだけ許す、特定のコマンドだけ自動化する、環境側で守られている場合のみ全開放する——といった中間の設計が可能になっています。重要なのは「どこまでAIに任せるか」を明示的に決めることで、決めずに使っている状態はリスクが大きいと考えています。

AIが得意なこと・人間が判断すべきこと

権限設計を考える前提として、AIに向く作業と人間が握るべき判断を分けておくと迷いが減ります。

この右側の列が、まさにパーミッション設計の中身です。AIは「どこまでやっていいか」を自分では決められません。決めるのは運用する側の仕事になります。

ルールを文章ではなく設定ファイルで配る

現場でよく見かけるのが、「Claude Codeの利用ルール」をスプレッドシートやドキュメントにまとめて周知する運用です。書いてあること自体は正しいのですが、読まれなければ効果がなく、守られているかの確認もできません。

私たちが推奨しているのは、ルールを文章ではなく設定ファイルとして配布する考え方です。.claude/settings.json にポリシーを書いてリポジトリに入れておけば、cloneした全員に同じ権限ルールの土台を配れます。ただし、各自のユーザー設定やローカル設定のallowルールは合算され、組織の管理設定（managed settings）はそれらより優先されます。「配れば全員がまったく同じ権限になる」わけではなく、「共通の土台を仕組みで配る」という位置づけです。人の注意力ではなく仕組みで守る、という発想です。この点は後半で具体的に扱います。

各モードの動作を正確に理解する

ここからは各モードの動作を個別に見ていきます。名称と実際の表示が異なる箇所があるため、設定値と表示名を混同しないように整理します。

自律性が高いほど速く進みますが、その分だけ人間が状況を把握できなくなります。速度と可視性はトレードオフの関係にあると理解しておくと、モード選択の判断がしやすくなります。

defaultモード（表示名は「Manual」）

defaultモードは、Claude Codeの標準的な動作モードです。ファイルの読み取り（Read、Glob、Grep）と、lsやgit statusのような読み取り専用のBashコマンドは承認なしで実行されます。ファイルの書き込み（Edit、Write）と、それ以外のコマンド実行（Bash）は、許可ルールに合わない限りユーザーの承認を求めます。

[Claude Code] src/index.tsを編集します。よろしいですか？
  > Yes / No / Always allow for this session

初めて触るプロジェクトや、本番環境に影響するファイルを扱う場合に適しています。承認のたびにAIの行動を確認できるため、意図しない変更を防止できます。

名称変更の注意: 読み取りなど承認が不要な操作を除き、操作ごとにユーザーが確認するこのモードは、v2.1.200以降、CLI・claude --help・VS Code / JetBrains拡張・デスクトップアプリのいずれでも「Manual」と表示されます。 設定値はdefaultのままで、hooksやSDK連携はこの値を使います。CLIはmanualをエイリアスとして受理するため、claude --permission-mode manual や "defaultMode": "manual" と書いても動作します。v2.1.203以降はステータスバーに⏸ manual mode onのバッジが表示されます。（出典: Choose a permission mode、2026年8月1日確認）

ただし、defaultモードには「承認疲れ」という現実的な限界があります。承認ダイアログが繰り返し出ると、内容を読まずにYesを押す習慣がついてしまい、確認しているつもりで確認していない状態になりがちです。慎重さを担保したいなら、defaultモードに留まり続けるのではなく、後述する許可リストの設計や、acceptEdits・autoへの移行に進むほうが実効性があると考えています。

acceptEditsモード

acceptEditsモードは、作業ディレクトリ内のファイル編集と、mkdir・touch・mv・cpなどの基本的なファイル操作を承認なしで実行するモードです。範囲外のパスや保護対象のパスへの書き込み、それ以外のコマンド実行は引き続き承認を求めます。編集は自動で進め、差分はgit diffなどで後から確認する、という使い方に向いています。

claude --permission-mode acceptEdits

planモード

planモードは、Claude Codeに「調査して計画を提案させる」モードです。ファイルを読み、調査のためのコマンドを実行して計画を書きますが、計画を承認するまでソースコードの編集はブロックされます。

ただし、この説明には例外が2つあります。1つ目は、bypassPermissionsが使える状態で起動した対話型のターミナルセッションです。ここではplanモードのブロック自体が強制されず、Claudeは「編集せずに計画する」よう指示されるだけで、試みた編集やコマンドは確認なしで実行されます（明示的なaskルールと重要パスの削除は確認が残ります）。2つ目は調査コマンドの扱いで、autoモードが使える環境（useAutoModeDuringPlanは既定で有効）では、分類器が許可したコマンドが承認なしで実行され、拒否されたものはブロックされます。autoモードが使えない場合は、組み込みの読み取り専用コマンド以外は承認を求められます。つまり「読み取りしかできない」わけではありません。

claude --permission-mode plan

セッション中はShift+Tabで切り替えるか、プロンプトの先頭に/planを付けても入れます。コードベースの分析、アーキテクチャレビュー、バグの原因調査など、「調べてから変更する」タスクに適しています。編集前に方針を確認できるため、意図しないファイル変更のリスクを抑えられる点が大きな価値です。ただし、編集を止めたい場合は、planモードだけに頼らずpermissions.denyでEditやWriteを止める設計を併用してください。このdenyが止めるのは組み込みのファイル編集ツールと、Claude Codeが認識できるBashのファイル操作（sedやtee、> fileのリダイレクトなど）までです。PythonやNodeのスクリプトが自分でファイルを開いて書き込むような間接的な書き込みは対象外です。Bashで実行したコマンドとその子プロセスの書き込み先は、サンドボックスを有効にするとOSのレベルで制限できます。ただし、フックやMCPサーバーなどはサンドボックスの外で動くため、それらも含めて書き込みを止めたい場合は、Claude Code自体を読み取り専用のコンテナやVMの中で動かします。

実務では、新しくジョインしたメンバーが既存コードを把握する場面や、他チームのリポジトリを調査する場面で使いやすいモードです。計画を承認すると、その承認で選んだモードに切り替わって編集が始まるため、調査から実装までを1つの流れで進められます。

autoモード

autoモードは、承認ダイアログを出さずに実行しつつ、別の分類器モデルが操作を実行前に審査するモードです。判定には順番があり、allow・ask・denyのルールに一致する操作はそのルールで決まり、読み取りと作業ディレクトリ内のファイル編集は自動で承認されます（保護されたパスへの書き込みなどの例外を除く）。それ以外の操作が分類器の審査に回り、依頼の範囲を超える操作、見覚えのないインフラへの操作、Claudeが読んだ内容に誘導されたと見られる操作を止めます。許可リストを事前に書かなくても使えるのが特長です。

claude --permission-mode auto

Claude Code v2.1.283以降では、対話型のターミナルとVS Codeで標準の開始モードになっています。利用にはサポート対象のモデルが必要で、組織の管理設定（permissions.disableAutoMode）で無効にされている場合は使えません。明示的なaskルールは、autoモードでも承認を求めます。公式も「承認の回数を減らすモードであり、安全を保証するものではない」としているため、機微な操作のレビューの代わりにはなりません。

autoモードは、方向性を信頼できる長めの作業で承認疲れを減らしたい場合に適しています。autoモードの詳しい使い方はClaude Codeのautoモード完全ガイドで解説しています。

dontAskモード

事前に決めた範囲だけで動かしたい場合は、dontAskモードを使います。承認が要る操作はすべて自動で拒否されるため、セッションが入力待ちで止まりません。なお、defaultモードで承認が不要な操作（作業ディレクトリ内のファイル読み取りや、読み取り専用のBashコマンド）は、許可リストに書かなくてもそのまま実行されます。明示的なaskルールに合う操作は、確認ではなく拒否になります。

claude -p "テストを実行して結果を報告してください" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"

上記の例では、読み取りとnpm testの実行が通り、承認が必要になる操作は拒否されます。許可リストを固定したCIやスクリプトに向いています。

bypassPermissionsモード

bypassPermissionsモードは、ほぼすべての操作を承認なしで自動実行するモードです。通常の承認や安全確認は省かれ、許可ルール（allow）は効果を持ちません。一方でdenyルールはこのモードでも効きます。また、明示的なaskルールに合う操作と、rm -rf /のような重要パスの削除は、このモードでも確認が残ります。「deny以外はすべて素通り」ではない点に注意してください。

claude -p "テストを実行して、失敗したテストを修正してください" --dangerously-skip-permissions

起動は--permission-mode bypassPermissionsでも行えます。コンテナやVMなど隔離された環境での完全自動化に限って使うモードで、SDK経由の自動化でも、実行環境のセキュリティ（サンドボックス、ネットワーク制限など）で安全性を担保する必要があります。

ここは率直に書いておきたい点です。bypassPermissionsモードは、開発者の手元マシンで日常的に使うモードではありません。承認が面倒だからという理由でローカル環境をbypassPermissionsにするのは、権限設計を放棄しているのと同じです。bypassPermissionsが妥当なのは、実行環境そのものが隔離されていて、最悪の場合に壊れても再構築できる場合に限られると考えています。環境で守れない状態でbypassPermissionsを選ぶべきではありません。

permissions.allowで権限を設計する

許可リスト（設定ファイルのpermissions.allow、起動時のフラグでは--allowedTools）は、どのモードにも重ねられる仕組みです。defaultやacceptEditsでは、リストに合う操作の承認が省かれ、dontAskでは、承認不要の読み取り操作に加えてリストに合うものだけが実行されます。ここを雑に書くと全許可に近づき、細かく書きすぎると承認が増えてdefaultモードに戻ってしまいます。破壊的なコマンドはpermissions.denyで明示的に止め、人の確認を外したくない操作はpermissions.askに入れます。denyルールはどのモードでも効き、askルールもautoモードを含めて確認を求めます。

注意したいのは、「allowにない操作は承認を求められる」という前提がdefaultやacceptEditsの場合の話だという点です。autoモードではallowに一致しない操作は分類器が判断し、問題なしとされれば承認なしで実行されます。また、autoに入るときは、任意のコード実行につながる広いallowルール（Bash()、Bash(python)のようなインタプリタのワイルドカード、パッケージマネージャーの実行コマンドなど）は無効化され、Bash(npm test)のような狭いルールだけが残ります。以降の構成例は、特に断りがなければdefaultまたはacceptEditsで使う前提で読んでください。

ツール指定の構文

ワイルドカードは便利ですが、範囲が広がるほど「何が自動実行されうるか」を把握しづらくなります。まずは正確なコマンド名で書き始め、承認が頻発する箇所だけをワイルドカードに広げる進め方が扱いやすいと感じています。

役割別のpermissions.allow構成例

権限は「人」ではなく「役割」に紐づけて設計すると、メンバーの入れ替わりがあっても運用が崩れません。開発者・レビュアー・CI/CDの3パターンを見ていきます。

開発者向け（コーディング作業）

{
  "permissions": {
    "allow": [
      "Edit",
      "Write",
      "Bash(npm test)",
      "Bash(npm run build)",
      "Bash(npm run lint)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git diff *)",
      "Bash(git status)",
      "Bash(git log *)"
    ]
  }
}

ファイル編集、テスト実行、ビルド、リント、Gitの基本操作を許可しています。defaultやacceptEditsで使う場合、git pushやrm -rfのような許可リストにないコマンドは承認を求められます。ただしautoモードでは、リストにない操作も分類器が許可しうるため、これだけでは止まる保証になりません。止めたい操作はdeny、確認を挟みたい操作はaskで次のように明示します。

{
  "permissions": {
    "deny": ["Bash(rm -rf *)", "Bash(git push --force *)"],
    "ask": ["Bash(git push *)"]
  }
}

ローカルで完結する操作は自動化し、外部に影響が出る操作は人間が判断する、という線引きは、モードに関わらずdeny・askで担保します。

レビュアー向け（読み取り+コメント）

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git show *)"
    ],
    "deny": [
      "Edit",
      "Write"
    ]
  }
}

ファイルの読み取りとGitの差分確認を許可し、編集系のツールはdenyで止めています。コードレビューの分析タスクに適した構成です。ここで重要なのはdenyの行です。読み取り系のallowだけを書いても編集は防げません。defaultでは編集が承認待ちになるだけで、acceptEditsでは編集が自動承認され、autoでも作業ディレクトリ内の編集は（保護されたパスへの書き込みを除き）分類器を通さず許可されます。レビュー中に勢いでコードを直してしまう事故は、denyでClaudeの編集ツールの段階から止められます。ただし、このdenyはPythonやNodeのスクリプトが自分でファイルに書き込むような間接的な書き込みまでは止めません（公式の「What Read and Edit rules cover」）。スクリプト経由の書き込みまで止めたいレビュー環境では、サンドボックスを有効にしてBashのコマンドとその子プロセスの書き込み先をOSのレベルで制限するか、Bashの実行自体を許可しない構成と組み合わせてください。フックやMCPサーバーなどサンドボックスの外で動く処理まで含めて止めるには、Claude Code自体を読み取り専用のコンテナやVMで動かします（公式の「What runs outside the sandbox」）。

CI/CD向け（ビルド+テスト+デプロイ）

{
  "permissions": {
    "allow": [
      "Edit",
      "Write",
      "Bash(npm *)",
      "Bash(git *)",
      "Bash(gh pr create *)"
    ]
  }
}

npmコマンド、Gitコマンド、GitHub CLIによるPR作成を包括的に許可しています。CI/CD環境では、実行環境自体がサンドボックス化されているため、広めの権限を付与しても安全側に倒せます。逆に言えば、サンドボックス化されていない環境にこの構成をそのまま持ち込むのは避けるべきです。

許可リストは一度作って終わりにしない

許可リストは、運用しながら育てる設定です。承認ダイアログが出た履歴は「許可リストに足りていないもの」のログでもあります。毎回同じコマンドで止まっているなら、それはリストに加える候補です。

逆に、しばらく使われていない許可項目は削る候補になります。権限は放っておくと増える一方なので、四半期に一度など時期を決めて棚卸しする運用にしておくと、リストが肥大化せずに済みます。これはCRMのプロパティ設計と同じで、項目が少ないほど何を管理しているかに集中できると考えています。

設定ファイルでチーム全体に配布する

パーミッション設定はコマンドライン引数だけでなく、設定ファイルで管理できます。個人の記憶や習慣に頼らず、ファイルとして配ることが仕組み化の要点です。

プロジェクト設定（.claude/settings.json）

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm test)",
      "Bash(npm run build)"
    ]
  }
}

プロジェクト設定はGitリポジトリに含まれるため、チーム共通のパーミッションポリシーの土台を配れます。新メンバーがリポジトリをcloneした時点で共通のルールが読み込まれるので、オンボーディング時に口頭でルールを伝える手間は大きく減ります。ただし、実際の権限は他の層との組み合わせで決まります。同じキーは上位の層が優先され、permissions.allowのような配列は各ファイルの内容が合算されます。そのため、メンバーが自分のユーザー設定やローカル設定にallowを足せば、プロジェクト設定より広い権限になりえます。全員の権限を揃えたい場合は、次に触れる管理設定を使います。なお、公式の仕様では、.claude/settings.json に書いた permissions.defaultMode の "auto" と "bypassPermissions" は効かないため、プロジェクトで配る既定モードにはacceptEditsなどを使います。

ユーザー設定（~/.claude/settings.json）

{
  "permissions": {
    "defaultMode": "default"
  }
}

ユーザー設定はプロジェクト設定より優先度が低く、同じキーがプロジェクト設定にもある場合は、プロジェクトの値が適用されます。一方、組織の管理設定（managed settings）は最上位で、ユーザー・プロジェクト・ローカルのどの設定やコマンドライン指定でも上書きできません。たとえば permissions.disableBypassPermissionsMode を "disable" にしてbypassPermissionsモードを禁止する、といった組織全体の制限はここで行います。

設定の優先順位

設定の優先順位は、上から順に次のとおりです（公式の「Settings precedence」に基づく整理です）。

1. 管理設定（managed settings） — 組織が配布するもので最優先。下位のどの設定でも上書きできない
2. コマンドライン指定（--settingsなど。--permission-mode planもセッション限りでモードを決める） — そのセッションだけ
3. プロジェクトのローカル設定（.claude/settings.local.json） — 個人用でリポジトリには含めない
4. プロジェクト設定（.claude/settings.json） — チームで共有
5. ユーザー設定（~/.claude/settings.json） — 全プロジェクト共通の個人設定

同じキーは上位の値が採用されますが、permissions.allowのような配列は上書きではなく、各ファイルの内容が合算されます。この仕組みを把握していないと、「設定したはずなのに効いていない」という混乱が起きます。挙動が想定と違うときは、まずどのレイヤーの設定が効いているかを確認するのが近道です。

使えるフラグを公式ヘルプで確認する

設定を書く前に、手元のバージョンでどのフラグが使えるかを確認しておくと確実です。claude --help を実行すれば、--permission-mode や --allowedTools の説明が確認できます。

以下の画面は、claude --help の出力から --help・--permission-mode・--allowedTools の説明行を抜き出した実行結果です。

チーム運用の3パターン

ここからは、設定を実際の組織にどう載せるかを見ていきます。一律に決めるのではなく、チームの習熟度とタスクの性質の両方を変数として設計するのが実務的です。

パターン1: 段階的権限昇格

新しいプロジェクトやチームメンバーはdefaultモードから開始し、理解が進んだらacceptEdits、さらにautoモードへ移行するパターンです。いきなり広い権限を渡すのではなく、小さく始めて段階的に広げるアプローチをおすすめしています。

Week 1-2: defaultモード（読み取り以外を確認）
  ↓ プロジェクト構造を理解・挙動を把握
Week 3-4: acceptEditsモード + permissions.allow（編集と基本操作を自動承認）
  ↓ ワークフローが安定
Week 5+: autoモード（分類器の確認つきで自動実行）

昇格の判断基準を決めておくと運用が楽になります。例えば「承認ダイアログで拒否した回数がゼロの週が続いたら次の段階へ」といった形です。感覚ではなく観察できる事実で判断すると、メンバーごとのブレが減ります。

パターン2: タスク別モード切り替え

同じプロジェクト内でも、タスクの性質に応じてモードを切り替えるパターンです。

モードを固定せず、作業の入り口で選ぶ習慣をつけるのが理想です。「今日はこのタスクだからplanで入る」と最初に宣言するだけで、意図しない変更を防ぎやすくなります。

パターン3: 組織ポリシーによる統一管理

組織全体でパーミッションポリシーを統一する場合、.claude/settings.jsonをテンプレートとして全プロジェクトに配布します。

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm *)",
      "Bash(yarn *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git diff *)",
      "Bash(git status)",
      "Bash(git log *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Bash(git reset --hard *)"
    ]
  }
}

破壊的コマンドをdenyで明示的にブロックすることで、自動承認の利便性を維持しながらリスクを制御しています（denyはどのモードでも効きます）。テンプレートを1つ作って新規プロジェクト作成時に配る運用にすれば、誰がセットアップしても共通の基準を土台にできます。ただし、個人のローカル設定やユーザー設定のallowは合算されるため、全員に例外なく適用したいルールは管理設定で配布します。属人性を減らす、という意味での仕組み化です。

ただし、このテンプレートをそのまま全社に適用すればよい、という話ではありません。扱うリポジトリの性質（社内ツールか、顧客に納品するプロダクトか）や、チームの人数、CI環境の整備状況によって、最適な許可範囲は変わります。企業様によって最適な形は異なりますので、テンプレートはあくまで出発点として、自社の事情に合わせて調整いただくのが良いかと思います。

他の機能と組み合わせて全体を設計する

パーミッションモードは単体で完結する設定ではありません。エージェント運用の全体フローの中で、どこを担当しているのかを押さえておくと設計がしやすくなります。

全体フローの中での位置づけ

Claude Codeの運用は、大きく「何をやらせるかの指示」「実行時の権限制御」「実行結果の記録と検証」の3層に分けられます。パーミッションモードが担うのは真ん中の層です。

この3つが揃って初めて、安心して任せられる状態になります。権限だけ絞っても指示が曖昧なら成果物の品質は上がりませんし、権限と指示を整えても記録がなければ問題発生時に追えません。

Hooksとの連携

Hooksを使えば、ツール実行の前後にカスタムスクリプトを挟めます。パーミッションモードとHooksを組み合わせることで、「autoモードで自動承認しつつ、特定のツール実行時にはログを記録する」といった柔軟な制御が可能です。

自動承認は速度を上げる代わりに可視性を下げるので、Hooksで記録を残して可視性を取り戻す、という補完関係になります。autoモードを広げるときほど、記録の仕組みをセットで考えると安全です。

CLAUDE.mdとの関係

プロジェクトの.claude/CLAUDE.mdに記載したルールは、パーミッションモードとは独立して動作します。パーミッションモードはツール実行の「承認/拒否」を制御しますが、CLAUDE.mdはエージェントの「行動指針」を制御します。両方を適切に設定することで、安全かつ的確なエージェント運用が実現します。こうした取り組みの詳細は、経営データの可視化やコンテンツマーケティングの支援のページでもご紹介しています。

設定確認

パーミッション設定が意図通りに適用されているか不明な場合は、/config コマンドで現在の設定状況を確認できます。設定ファイルの読み込み状況や、適用されているモードを確認できます。設定を変更した直後と、メンバーの環境で挙動が違うときに確認する習慣をつけておくと、原因の切り分けが早くなります。

権限設計がうまくいかないときの見直し方

設定した後に「思ったほど楽にならない」「逆に怖くなった」と感じることがあります。その多くは、モード選択ではなく前提の置き方に原因があります。

承認が多すぎて進まない場合

承認ダイアログが頻発している状態は、許可リスト（permissions.allow）が実際の作業内容と合っていないサインです。この場合、モードをbypassPermissionsに上げるのではなく、止まっているコマンドを1つずつ許可リストに加えていくのが正しい対処です。

どのコマンドで止まっているかを1〜2週間メモしておくと、自チームの作業パターンが見えてきます。そのうえで、外部に影響しない操作（テスト、ビルド、リント、ローカルのGit操作）から順に許可していくと、リスクを増やさずに承認回数を減らせます。

何が実行されたか追えない場合

autoモードやbypassPermissionsモードを広げたあとに起きやすいのが、「気づいたらファイルが変わっていた」という状況です。これは権限を戻すのではなく、記録の仕組みが足りていないと捉えるほうが建設的だと考えています。

Hooksでのログ記録、こまめなコミット、差分の確認習慣といった検証側の仕組みを先に整えると、権限を広げても状況を把握できます。逆に、検証の仕組みが無いまま権限だけ広げるのは、ブレーキを確認せずにアクセルを踏むようなものです。

向かないケースを正直に書いておく

パーミッションモードの設計だけでは解決しない場面もあります。次のようなケースでは、モードの調整より前に別の対策が必要です。

権限設計は万能ではなく、環境設計と組み合わせて初めて機能します。ここを混同すると、設定ファイルをいくら丁寧に書いても不安は消えません。

よくある質問

Q1. autoモードとbypassPermissionsモードの違いは何ですか？

autoモードは、権限ルールと自動承認で決まらない操作を分類器モデルが実行前に審査し、依頼を超える操作などを止めます。bypassPermissionsモードは、分類器による確認も通常の承認も省いてほぼすべてを実行します（明示的なaskルールや重要パスの削除など、一部の確認は残ります）。autoモードは「分類器による確認つきの自動実行」、bypassPermissionsモードは「ほぼ確認なしの自動実行」と理解してください。日常の開発作業にはautoモードやacceptEdits、隔離されたコンテナやVMでの完全自動化にはbypassPermissionsモードが適しています。

Q2. permissions.allowでBashコマンドを細かく制御できますか？

はい、Bash(コマンドパターン)の形式で細かく制御できます。Bash(npm test)ならnpm testのみ、Bash(npm )ならnpmで始まるすべてのコマンドが許可されます。正確なコマンド名で指定するほど安全側に寄りますが、承認回数が増えるため利便性とのバランスを考慮してください。Bash(rm -rf )のように明示的にブロックしたいコマンドはpermissions.denyに追加することも可能です。

Q3. パーミッション設定をチーム全体で統一するにはどうすればよいですか？

.claude/settings.jsonをGitリポジトリに含めてコミットしてください。このファイルはプロジェクト単位のパーミッション設定として、cloneしたチームメンバーに共通の土台として読み込まれます（各自のローカル設定やユーザー設定のallowは合算され、組織の管理設定は常に優先されます）。組織内の複数プロジェクトで統一する場合は、設定ファイルのテンプレートを作成し、新規プロジェクト作成時に配布する運用が効果的です。口頭やドキュメントでの周知ではなく、ファイルとして配ることが定着の鍵になります。

Q4. defaultモードのまま使い続けても問題ありませんか？

安全面では問題ありませんが、承認が続くと内容を確認せずに承認する習慣がつきやすい点には注意が必要です。慎重さを保ちたい場合は、defaultモードに留まるよりも、外部に影響しない操作だけをpermissions.allowで許可したacceptEditsモードや、autoモードに移るほうが、確認すべき場面に集中できます。

Q5. モードの設定が効いていないように見えるときは何を確認すればよいですか？

まず設定の優先順位を確認してください。管理設定が最優先で、次にコマンドライン指定、プロジェクトのローカル設定（.claude/settings.local.json）、プロジェクト設定（.claude/settings.json）、ユーザー設定（~/.claude/settings.json）の順で適用されます。permissions.allowなどの配列は合算される点も確認してください。/config コマンドで現在適用されているモードと設定ファイルの読み込み状況を確認すると、どのレイヤーが効いているかを切り分けられます。

まとめ

Claude Codeのパーミッション設計で押さえておきたいのは、次の3点です。

第一に、モードは「AIにどこまでの裁量を渡すか」の段階です。defaultは慎重な作業、planは編集前の調査と計画、autoは分類器の確認つきの自動実行、bypassPermissionsは隔離された環境での完全自動化に、それぞれ適しています。

第二に、権限設計の実効性は許可リスト（permissions.allow）とdenyの設計で決まります。役割別に組み、承認が頻発する箇所を追加し、使われていない項目を棚卸しする。この育てる運用が権限設計の中身です。

第三に、ルールは文章ではなく設定ファイルで配ります。.claude/settings.jsonをリポジトリに入れておけば、cloneした全員に共通の設定を配布できます。ただし実際の権限は、各自のユーザー設定・ローカル設定や組織の管理設定との組み合わせで決まります。全員に例外なく揃えたいルールは管理設定で配ります。個人の注意力ではなく仕組みで守る、という考え方です。

まずはdefaultモードで1つのプロジェクトを1〜2週間動かし、そこで得られた「毎回承認しているコマンド」のリストを出発点にしてみてください。小さく始めて段階的に広げるほうが、最初から完璧な設定を作ろうとするより早く安定すると考えています。

次の3ステップで進められます。

1. 現在使っているプロジェクトで claude --help と /config を実行し、使えるフラグと適用中の設定を確認する
2. 1〜2週間、承認ダイアログで止まったコマンドを記録し、外部に影響しないものから permissions.allow に追加する
3. 固まった設定を .claude/settings.json に書き、リポジトリにコミットしてチームに配布する

なお、Claude Codeの全コマンド一覧はClaude Codeチートシートに、AI活用の全体像はAI活用完全ガイドにまとめています。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• Claude Codeの/diffコマンド｜変更差分をインタラクティブに確認してコードレビューを効率化する
• Claude Coworkで経理・バックオフィスを効率化する方法｜請求書・仕訳・レポート作成の自動化
• Claude Codeの見た目カスタマイズ｜テーマ・カラー・ステータスラインの設定方法