Claude Codeの権限設定｜チーム導入で許可範囲を決める方法

権限表をコマンド名から作り始めると、`npm test` は安全、`curl` は危険、といった粗い分類になりがちです。しかしテストスクリプトの内部から外部サービスへ接続することも、読み取りコマンドから秘密情報を表示することもできます。コマンドの名前だけでは、実際の影響を判定できません。

先に守る対象を棚卸しします。認証情報や個人情報を含むファイル、本番環境の資格情報、リポジトリ外のディレクトリ、外部送信先、デプロイや課金を伴う操作です。そのうえで、各ワークフローが「何を読むか」「何を変更するか」「どこへ通信するか」「人が確認せず実行してよいか」を確認します。

Claude Codeの権限ルールには allow、ask、deny があり、公式ドキュメントでは deny、ask、allow の順に評価され、最初に一致したルールが適用されます。つまり、広い allow があっても deny に一致する操作は許可されません。`/permissions` では、現在のルールと、そのルールがどの設定ファイルから来たかを確認できます。

設定の置き場所は役割で分けます。ユーザー設定は個人の全プロジェクト、プロジェクト設定はリポジトリの共同作業者、ローカル設定はその利用者の特定プロジェクトに適用されます。`.claude/settings.json` はソース管理して共有するチーム標準に向き、`.claude/settings.local.json` は個人の試行や端末固有の調整に向きます。PRレビューへ組み込むときのイベント・トークン・成果物の分離は、Claude CodeをGitHub Actionsで動かすでも確認できます。

一方、managed settings はIT管理者が配布し、ユーザーやプロジェクト設定では上書きできません。設定値には優先順位がありますが、権限ルールの配列は複数スコープから結合されます。どこかのスコープに deny があれば別のスコープの allow では解除できないため、組織禁止とチーム標準を分離できます。

ここで迷うのは、すべてを managed settings に集約すべきか、という点です。集約すると統制は強くなりますが、リポジトリ固有の安全なテストまで管理部門の変更待ちになりかねません。組織横断の最低線は managed、リポジトリ固有の追加制約と限定的な許可は project、個人差は local という責任分界が現実的です。

第一に、読み取り禁止を決めます。`.env`、資格情報、秘密鍵、顧客データの複製などは、変更を防ぐだけでは不十分です。読めれば応答やコマンド出力へ現れる可能性があるため、`Read` の deny とサンドボックスの読み取り境界を検討します。秘密を含むファイルをプロジェクト内へ置かない、短命な認証情報を使うといった既存のセキュリティ対策も前提です。

第二に、変更範囲を決めます。通常のソースコードとテストは作業ディレクトリ内に限定し、親ディレクトリ、ユーザー設定、シェル設定などへの書き込みを許可しない構成から始めます。生成物や一時ファイルの出力先を限定できれば、コマンド全体を例外扱いする必要が減ります。

第三に、外部作用を分けます。パッケージ取得、Web取得、MCPサーバー、クラウドCLI、Gitホスティングサービスへの操作は、すべて同じ「ネットワーク利用」ではありません。参照と更新、開発環境と本番環境、組織管理の接続先と任意の接続先を分け、更新系は ask または deny に残します。

第四に、権限モードを固定します。`default` は標準の確認動作、`acceptEdits` は作業領域内の編集などを自動承認し、`plan` は調査を中心に編集を行わないモードです。`auto` は安全性の分類を通じて操作を自動承認し、`dontAsk` は事前許可されていない操作を自動拒否します。`bypassPermissions` は権限確認を省略するため、公式ドキュメントもコンテナやVMのような隔離環境だけで使うよう案内しています。組織で不要な場合は、managed settings の `permissions.disableAutoMode` と `permissions.disableBypassPermissionsMode` で無効化します。

たとえば、プロジェクトの `.claude/settings.json` では、実際にチームが利用する検証コマンドだけを allow に置き、秘密ファイルの読み取りと既知の直接通信コマンドを deny に置きます。次は構造を示す例であり、コマンド名やパスは各リポジトリのスクリプトを確認して置き換える必要があります。 ```json { "$schema": "https://json.schemastore.org/claude-code-settings.json", "permissions": { "defaultMode": "default", "allow": [ "Bash(npm run lint)", "Bash(npm run test *)" ], "ask": [ "Bash(npm install *)" ], "deny": [ "Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)", "Bash(curl *)", "Bash(wget *)" ] } } ```

この例は設定検討の出発点です。許可したスクリプトの定義が変更されれば、副作用も変わります。また、コマンドのパターン一致には構文上の注意点があります。公式の権限ドキュメントでルール構文を確認し、想定したコマンドだけが一致するかをテストします。

プロジェクト設定に置いた allow と追加ディレクトリは、ワークスペースの信頼確認を受け入れるまで適用されません。リポジトリ自身が権限を要求する構造になるため、初回の信頼画面を儀式にせず、変更された許可ルールをコードレビューの対象にします。

権限ルールは、Claude Codeの各ツールに対して実行を許可するかを制御します。サンドボックスはBashとその子プロセスに対し、OSレベルでファイルシステムとネットワークの境界を設けます。一方、組み込みの Read、Edit、Write は権限システムに従います。制御対象が異なるため、両方を組み合わせます。

差が表れるのが外部通信です。WebFetch を deny にしても、Bash が許可され、`curl` や別のプログラムが通信できれば外へ到達できます。Anthropicの組織導入向け公式資料もこの差を示し、サンドボックスのドメイン許可リストでBash側の経路を制限する考え方を説明しています。

MCPも別の境界として扱います。接続先サーバーは追加のツールとデータ経路を持つため、コマンド権限だけで管理を終えません。組織で利用可能なMCPサーバーを絞る場合は、`allowedMcpServers`、`deniedMcpServers`、`allowManagedMcpServersOnly` などの管理設定を検討します。プラグインやフックにも同様に管理用の制御面があります。

設定ファイルを配布したら、検証を始めます。まず `plan` または `default` を基準に、代表的な開発作業を実行します。どの操作で確認が発生したか、拒否された操作は本当に必要か、許可した処理がどのファイルとドメインへ到達したかを確認します。

Claude Codeのチーム導入では、守るデータ、書き込み可能な場所、通信先、本番への経路を先に固定します。組織共通の deny と危険モードの禁止は managed settings、リポジトリ固有の狭い allow と追加の deny は `.claude/settings.json`、Bashの実効境界はサンドボックスに担わせます。

冒頭に残した「どこまで自動実行を許すか」への答えは、開発環境内で対象と副作用を説明でき、失敗しても戻せる定型操作までです。外部送信、権限変更、依存関係の追加、本番や共有資源の更新は、操作名が日常的でも ask または deny に残します。確認なしで許してよい影響範囲をチームで合意できた状態が、権限設定の完成条件です。

AI駆動開発の研修や導入設計では、設定ファイルに加え、既存の開発フロー、秘密情報の配置、レビュー責任も整理する必要があります。cotomuの提供範囲は、研修30万円、導入パッケージ50万円から、技術顧問15万円／月で、初回60分の相談は無料です。生産性や品質の向上は保証対象外です。また、cotomuはClaude Code、Codexなどの公式パートナーまたは認定事業者ではありません。チームごとの許可基準を具体化したい場合は、現状の開発環境と想定業務を相談時に共有してください。