導入初日に決めるべきこと
Claude Codeを個人の便利ツールから、チームの業務ツールへ引き上げるときに最初に設計すべきなのは「どのモデルを使うか」だけではありません。エンジニア組織で事故なく広げるには、どのディレクトリを読めるのか、どのコマンドを自動実行できるのか、どの操作は必ず人間が確認するのかを先に決める必要があります。
公式ドキュメントでは、Claude Codeはコードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと統合できるエージェント型コーディングツールとして説明されています。便利な一方で、端末上で動く以上、権限設計を曖昧にしたまま全社展開すると「誰かのローカル設定では通るが、別の人の環境では止まる」「一部のリポジトリでだけ危険なコマンドが許可される」「CIや社内プロキシ越しの挙動が再現できない」といった運用差分が出ます。
本記事では、Claude Code概要、組織向けセットアップ、Permissions、Settingsなどの一次情報をもとに、業務導入したいエンジニア向けの権限設計を整理します。数値効果やベンチマークは、公式に確認できないものを置かず、現場で実装できるルール、レビュー観点、設定例に絞ります。
なお、既に基本的な設定ファイルの読み方を把握している場合は、先にsettings.json設定ガイドと法人導入セキュリティチェックリストを確認してから、本記事の権限テンプレートに進むと理解しやすくなります。
権限設計の全体像
Claude Codeの権限設計は、大きく分けると四つの層で考えると扱いやすくなります。第一層は利用者の操作モードです。既定の確認型で使うのか、編集だけ自動承認するのか、計画だけ立てるのか、より手放しで進めるのかを決めます。第二層はpermission rulesです。Bash、Read、Edit、Write、WebFetch、MCPツールなど、ツール単位またはコマンド単位でallow、ask、denyを設計します。
第三層はsettingsのスコープです。公式ドキュメントではManaged、User、Project、Localといったスコープが示され、Managedが最も強いポリシーとして扱われます。組織として必ず守らせたいルールはユーザー個人の設定に任せず、managed settingsやOSレベルのポリシー、ファイルベースのmanaged-settings.jsonで配布する方が安全です。
第四層は実行環境の境界です。permission rulesでWebFetchを拒否しても、Bashが許可されていればcurlやwgetから外部にアクセスできる可能性があります。公式の組織向けドキュメントでも、permissionsとsandboxingは別レイヤーだと説明されています。つまり「ツールを拒否したからネットワークも閉じた」と誤解せず、必要であればネットワーク許可ドメインやファイルシステム境界も別途設計します。
エンジニア組織での実務では、この四層を一枚の導入設計書にまとめるのがおすすめです。たとえば、標準モードはdefault、既存リポジトリの小修正ではacceptEdits、危険な移行作業ではplan、機密情報を含むリポジトリではautoやbypassPermissionsを使わない、といった運用ルールを決めます。そのうえで、Project設定には開発体験に関わるルールを置き、Managed設定には抜け道を塞ぐルールを置きます。
権限モードを業務別に使い分ける
Claude Codeのpermission modeは、チーム導入時の最初の教育ポイントです。公式のsettings referenceでは、defaultModeの有効値としてdefault、acceptEdits、plan、auto、dontAsk、bypassPermissionsが示されています。ただし、これらを単純に「強いほど便利」と捉えると失敗します。業務の危険度と、変更の可逆性に合わせて使い分ける必要があります。
defaultは、読み取り中心の調査や小さな修正の開始点として向いています。Claude Codeが追加アクションを必要とするときに確認が入るため、新人や初回導入チームでも挙動を学びながら進められます。acceptEditsは、ファイル編集を素早く回したいが、任意のBashコマンドは人間が見たいケースに向いています。公式のsecurity documentationでも、Accept Edits modeは作業ディレクトリ内の編集や一部のファイルシステム操作を自動承認し、その他のBashやスコープ外パスは確認対象になると説明されています。
planは、設計レビュー、影響範囲調査、移行方針の整理に向いています。いきなりコードを書かせるのではなく、対象ファイル、変更順序、テスト方針、ロールバック方針を出してから人間が承認する流れにできます。既存の大きなリファクタリング、認証まわりの変更、課金ロジックの修正では、最初から実装モードに入るよりplanを標準にした方がレビューしやすくなります。
autoやbypassPermissionsは、業務導入初期の標準設定にしない方が無難です。特にbypassPermissionsは、公式設定にもdisableBypassPermissionsModeが用意されているほど、組織ポリシー上の扱いに注意が必要です。使う場合でも、孤立した検証用リポジトリ、捨てられるコンテナ、ネットワークと秘密情報を切り離した環境に限定し、本番リポジトリではmanaged settingsで無効化するのが現実的です。
導入設計書には「どの業務でどのモードを使うか」を表にします。例として、README修正はacceptEdits、障害調査はdefault、DB migrationはplan、検証用サンドボックスでの一括整形はauto候補、本番秘密情報に触れる作業はdefaultまたはplanのみ、といった粒度です。ルールが明文化されていると、レビュー担当者も「この作業でなぜそのモードなのか」を確認しやすくなります。
allowとdenyは最小権限から始める
permission rulesの基本は、便利なコマンドを無制限にallowすることではなく、頻繁に使う安全な操作だけを明示的に許可し、危険な操作や機密ファイルへのアクセスはdenyに寄せることです。公式のsettings referenceでは、permissions.allow、permissions.ask、permissions.denyが説明されています。denyは機密情報を含むファイルをClaude Codeから除外する用途にも使えます。
業務導入の初期テンプレートでは、まず読み取り系のGitコマンド、テスト実行、静的解析、フォーマッタなど、開発フロー上の定型操作を候補にします。たとえばgit status、git diff、npm test、pytest、pnpm lint、go testなどは、チームの言語やリポジトリに合わせて整理します。ただし、rm、mv、curl、scp、ssh、kubectl、terraform apply、aws、gcloudなどは、状況次第で大きな副作用を持つため、askまたはdenyから始める方が安全です。
ここで大事なのは、Bashのワイルドカードを広くしすぎないことです。Bash()のような許可は、実質的に端末を開放するのに近い扱いになります。業務導入では、Bash(npm test)のような具体的なコマンド、Bash(pnpm lint:)のような限定的なパターン、Bash(git diff:*)のような読み取り中心のコマンドから始め、チームの運用実績に応じて少しずつ広げる方が監査しやすくなります。
deny側では、.env、秘密鍵、認証トークン、顧客データのCSV、ローカルDBダンプ、バックアップディレクトリを明示します。Claude Codeは開発支援ツールであり、秘密情報を読ませるほど賢くなるわけではありません。むしろ、プロンプトやログ、ツール実行の中に不要な機密情報が混ざるリスクが増えます。機密情報は読ませない、必要な場合はダミーデータやスキーマ情報だけを渡す、という運用に寄せます。
また、permission rulesはプロジェクト設定とユーザー設定、managed settingsで重なります。公式ドキュメントでは、配列設定はスコープ間で結合され重複排除されると説明されています。これは便利ですが、下位スコープが許可を追加できる構成にもなり得ます。組織としてユーザーやプロジェクトにpermission ruleの追加を許したくない場合は、allowManagedPermissionRulesOnlyのようなmanaged-only設定を検討します。
managed settingsで社内標準を配る
個人利用では~/.claudeやプロジェクトの.claude/settings.jsonで十分でも、チーム導入ではmanaged settingsが重要になります。公式の組織向けセットアップでは、managed settingsはローカル開発者設定より優先され、ツール、コマンド、サーバー、ネットワーク宛先を制御できると説明されています。また、サーバー管理、plistまたはregistry、ファイルベース、Windows user registryなどの配布経路が示されています。
サーバー管理のmanaged settingsはClaude管理コンソールから配布され、アクティブセッション中に定期的に更新されると説明されています。一方、Claude.ai以外のプロバイダを混在させる組織や、端末管理の事情がある組織では、OSポリシーやファイルベースのmanaged-settings.jsonも候補になります。ここで重要なのは、配布経路の優劣を理解し、誰がどの設定を変更できるのかを運用ルールに落とすことです。
Managedに置くべき設定は、開発体験の好みではなく、組織として守りたい境界です。たとえばbypassPermissionsの無効化、全社共通denyリスト、許可済みMCPサーバー、許可済みplugin marketplace、HTTP hook URLの制限、managed hooksのみの読み込みなどが候補になります。逆に、テーマ、表示モード、個人のショートカットのような設定はユーザー設定に残して構いません。
組織導入の失敗例は、Project設定に強いセキュリティルールを置いただけで安心してしまうことです。Project設定はリポジトリに入るため共有しやすい一方、悪意あるリポジトリや古いテンプレートが混ざると想定外の設定になる可能性があります。全社で必ず守るルールはManagedへ、リポジトリごとの開発体験はProjectへ、個人の作業効率はUserやLocalへ、という分離を徹底します。
検証手順も設計に含めます。公式ドキュメントでは、Claude Code内の/statusでEnterprise managed settingsのソースを確認できると説明されています。初回展開時は、代表的なmacOS、Windows、Linux、WSL環境で/statusを確認し、意図したソースが表示されるか、denyが効くか、許可済みコマンドだけが自動実行されるかをチェックします。
hooksで安全確認を自動化する
権限設計だけでは、コード品質や運用ルールの確認までは完結しません。そこでhooksを組み合わせます。公式のhooks guideでは、PostToolUseで編集後にPrettierを実行する例、PreToolUseで編集前に確認を入れる例、SessionStartでコンテキストを再注入する例などが紹介されています。hooksは権限の代替ではなく、権限で許された操作に対して追加の検査や整形を行う層として扱います。
業務導入で最初に入れやすいのは、編集後のフォーマットと静的解析です。TypeScriptならprettier、eslint、tsc、Pythonならruff、mypy、pytestの一部、Goならgofmtとgo testなど、チームで既に使っている検査をClaude Codeの編集後に走らせます。ここで新しい品質基準をいきなり増やすより、既存CIと同じコマンドをローカルでも早く回す方が受け入れられやすくなります。
次に有効なのは、機密ファイルや危険なパスへの編集を止めるPreToolUse hookです。たとえば.env、secrets、terraform state、本番用manifest、顧客データを含むfixturesなどは、permission denyで読ませない設計に加えて、編集イベントでも検査します。permissionの設定ミスや新しいファイルパターンの追加漏れがあっても、hookが二重のガードになります。
ただし、hookにも運用リスクがあります。ユーザーやプロジェクトが自由にhookを追加できると、外部URLへPOSTするhook、秘密情報をログへ出すhook、レビューを迂回するhookが混ざる可能性があります。公式のsettings referenceにはallowManagedHooksOnlyやallowedHttpHookUrlsといった管理設定があり、HTTP hookのURL制限やmanaged hooksのみの読み込みに使えます。チーム導入では、hookを「便利な自動化」だけでなく「実行されるコード」として扱い、レビュー対象にします。
既にhooks運用を詳しく知りたい場合は、内部リンクのClaude Code Hooks実践ガイドも合わせて確認してください。本記事の権限設計と組み合わせると、許可、確認、拒否、検査、記録という流れを一貫して設計できます。
サンドボックスとネットワーク境界
Claude Codeを業務導入するエンジニアが見落としやすいのが、ツール権限とOSレベル境界の違いです。公式の組織向けドキュメントでは、WebFetchをdenyしてもBashが許可されていればcurlやwgetが外部に到達できる可能性があるため、sandboxingが別レイヤーとして必要になると説明されています。これは、セキュリティレビューで必ず確認すべき観点です。
権限設計のレビューでは、まずリポジトリの種類を分類します。OSSやサンプルアプリのように秘密情報がない環境、社内業務ロジックを含むが顧客データはない環境、本番資格情報や顧客データに近い環境では、許容できる自動実行範囲が異なります。秘密情報に近い環境では、Bashのallowを絞るだけでなく、ネットワーク、ファイルシステム、追加ディレクトリの扱いも確認します。
特にadditionalDirectoriesは便利ですが、設定したディレクトリのファイルアクセス範囲を広げます。複数リポジトリをまたぐモノレポ調査では役に立つ一方、ホームディレクトリや共有ダウンロードフォルダを広く許可すると、想定外のファイルが読まれる可能性があります。業務導入では、追加ディレクトリはプロジェクト単位で理由を明記し、不要になったら削除する運用にします。
ネットワークについても同様です。パッケージインストール、APIドキュメント参照、社内MCPサーバー接続など、開発に必要な通信はあります。しかし、任意の外部サイトへ自由にアクセスできる必要はありません。社内プロキシ、許可ドメイン、パッケージレジストリ、ソースコードホスティング、監視基盤などを洗い出し、許可リストを作ります。許可リストの運用が重い場合でも、少なくとも本番データに近い環境では外部通信を絞る方が安全です。
このレイヤーの詳細は、内部リンクのサンドボックスで安全に自動実行するガイドと、公式のSecurity documentationを参照しながら、自社の端末管理やCI環境に合わせて設計してください。
リポジトリに置く設定例
ここでは、業務導入初期に使いやすいProject設定の考え方を示します。実際の設定はチームの言語、CI、端末管理、managed settingsに合わせて調整してください。重要なのは、この設定が「全社セキュリティの最終防衛線」ではなく、「リポジトリごとの開発体験を揃える共有設定」だと位置づけることです。
{
"permissions": {
"defaultMode": "default",
"allow": [
"Bash(git status)",
"Bash(git diff:*)",
"Bash(pnpm test:*)",
"Bash(pnpm lint:*)"
],
"ask": [
"Bash(pnpm install:*)",
"Bash(curl:*)",
"Bash(git push:*)"
],
"deny": [
"Read(.env*)",
"Read(**/secrets/**)",
"Read(**/*credential*)",
"Bash(rm -rf:*)"
]
}
}この例では、読み取り中心のGit確認と既存のテスト、lintを許可し、パッケージインストール、curl、git pushは確認対象にしています。秘密情報らしいファイルや危険な削除コマンドはdenyに寄せています。実務では、pnpmをnpm、yarn、pytest、go test、cargo testなどに置き換えます。重要なのは、最初から広く許可せず、チームで合意した定型操作だけを許可することです。
Project設定には、なぜそのルールを置いたのかをCLAUDE.mdやdocsに書いておくと運用しやすくなります。新しいメンバーは、単に「このコマンドは許可されている」と覚えるのではなく、「このコマンドは読み取りまたは検査であり、副作用が限定的だから許可されている」と理解できます。ルールの理由が分かれば、将来の追加申請もレビューしやすくなります。
一方で、bypassPermissionsの無効化、全社共通deny、許可済みMCPサーバーだけを使う方針、HTTP hookのURL制限などは、Project設定ではなくManaged設定に置く候補です。Project設定はリポジトリの一部なので、リポジトリごとの事情に引っ張られます。組織として譲れないものは上位スコープへ、プロジェクト固有の便利設定はリポジトリへ、という分担を保ちます。
導入レビューのチェックリスト
権限設計は、設定ファイルを書いて終わりではありません。導入前レビューでは、少なくとも以下の観点を確認します。第一に、標準モードが業務リスクに合っているか。第二に、allowが広すぎないか。第三に、denyが機密情報の実態に合っているか。第四に、managed settingsで上書きすべき項目がProjectやUserに残っていないか。第五に、hooksが社内レビュー済みか。第六に、ネットワークとファイルシステム境界がpermissionsだけに依存していないか。
レビューでは、実際に代表的なタスクを流して確認します。たとえば、README修正、テスト追加、依存関係更新、APIクライアント変更、DB migration作成、環境変数追加、外部APIドキュメント参照などを小さく試します。どの操作で確認が出るのか、どの操作が拒否されるのか、どのhookが走るのかを記録します。設定を見ただけでは、現場でのプロンプト疲れやブロックされすぎる箇所は分かりません。
次に、失敗時の運用を決めます。Claude Codeがdenyで止まったとき、開発者が勝手にProject設定を緩めるのか、チームのレビューを通すのかで安全性は大きく変わります。おすすめは、許可追加を軽量なPull Requestにし、理由、対象コマンド、想定副作用、代替手段を書かせることです。PRレビューで承認されたものだけProject設定へ入れ、全社共通の価値があるものはManaged側へ昇格します。
最後に、月次またはリリース単位で棚卸しします。導入初期は確認が多く、運用が固まると許可が増えがちです。半年後に見たとき、古いコマンド、使われていないhook、既に不要な追加ディレクトリ、広すぎるワイルドカードが残っていないかを確認します。権限設計は一度作ったら固定するものではなく、開発フローの変化に合わせて細く保つものです。
よくある失敗と避け方
一つ目の失敗は、便利さを優先してBashを広く許可することです。短期的にはプロンプトが減りますが、エンジニアが何を承認しているのか分からなくなり、監査しづらくなります。避け方は、読み取り、検査、生成、破壊的操作を分け、破壊的操作はaskまたはdenyから始めることです。
二つ目の失敗は、秘密情報の保護をプロンプト運用に任せることです。「Claudeに秘密を読ませないで」と口頭で伝えるだけでは不十分です。.env、鍵、顧客データ、ローカルダンプは設定でdenyし、必要ならサンプルファイルを用意します。Claude Codeに渡す情報は、実データではなくスキーマ、ダミーデータ、再現用の最小ケースに寄せます。
三つ目の失敗は、権限と品質を混同することです。権限でEditを許可しても、品質が担保されるわけではありません。テスト、lint、型チェック、セキュリティスキャン、レビュー観点は、hooksやCI、PRテンプレートと組み合わせます。権限は「してよい操作」の設計であり、品質は「出てきた変更をどう検証するか」の設計です。
四つ目の失敗は、ManagedとProjectの役割分担を曖昧にすることです。全社で必ず守るルールをProjectに置くと、リポジトリごとの差分や古いテンプレートの影響を受けます。逆に、すべてをManagedに置くと、プロジェクト固有の開発体験が硬直します。組織ポリシーはManaged、リポジトリ標準はProject、個人の好みはUserまたはLocalという分担を守ります。
五つ目の失敗は、導入後の棚卸しをしないことです。Claude Codeの機能、チームの言語、CI構成、社内セキュリティ要件は変わります。導入時に安全だった設定も、ツール追加やリポジトリ分割で過不足が出ます。設定ファイルはプロダクトコードと同じくレビュー対象にし、変更履歴を残し、使われていない許可を削る運用にします。
30日で展開する実践手順
小さく始めるなら、30日を一つの単位にすると進めやすくなります。最初の週は、対象リポジトリを一つ選び、defaultまたはacceptEditsで試験導入します。README修正、テスト追加、軽微なバグ修正のような低リスクタスクを選び、どのコマンドで確認が必要になったか、どのファイルをdenyすべきだったかを記録します。
二週目は、Project設定の初期テンプレートを作ります。allowは最小限にし、denyは秘密情報と危険操作を中心に置きます。同時にCLAUDE.mdへ、プロジェクトの構成、テストコマンド、禁止事項、レビュー観点を書きます。ここで、権限設定と作業指示を混ぜすぎないことが大切です。権限はsettingsへ、開発ルールはCLAUDE.mdへ、詳細手順はdocsへ置くと見通しが良くなります。
三週目は、hooksとCIの接続を整えます。編集後のformat、lint、軽量テストをPostToolUseで回し、重い統合テストやセキュリティスキャンはCIに残します。全てをローカルhookで実行すると開発体験が重くなるため、ローカルでは早い検査、CIでは網羅的な検査という分担にします。hookの実行ログや失敗メッセージも、開発者が次に何をすべきか分かる文面にします。
四週目は、managed settingsと横展開の準備です。試験導入で見つかった全社共通deny、bypassPermissionsの扱い、MCPやpluginの方針、HTTP hook URL制限を管理設定へ移すか検討します。代表端末で/statusを確認し、設定が意図通りに適用されていることを確認します。最後に、導入ドキュメント、FAQ、トラブルシューティング、許可追加の申請手順を整備します。
この進め方なら、最初から全社一斉に強い制約を配るより、現場の摩擦を見ながら安全側へ寄せられます。Claude Codeはエンジニアの作業を大きく変えるツールですが、導入の成否はモデル性能だけでは決まりません。権限、設定、hook、レビュー、教育がつながって初めて、業務導入の再現性が生まれます。
まとめ：安全性は開発速度の前提条件
Claude Codeの業務導入で目指すべきなのは、何でも自動実行できる環境ではなく、エンジニアが安心して任せられる境界を持った環境です。default、acceptEdits、planなどのモードを業務リスクに合わせ、allowとdenyを最小権限で設計し、Managed、Project、User、Localの役割を分け、hooksとsandboxingで追加の安全層を作る。この順番を守るだけで、導入後の混乱はかなり減らせます。
特に、Claude Codeを「個人の端末で動くAI」ではなく「組織の開発プロセスに入る実行主体」として扱う視点が重要です。実行主体には権限、監査、レビュー、ロールバックが必要です。人間の新人エンジニアにいきなり本番DBの操作権限を渡さないのと同じく、AIにも作業範囲と承認フローを設計します。
次に取り組むなら、自社の主要リポジトリを一つ選び、現在のテストコマンド、秘密情報の場所、危険操作、外部通信、レビュー必須ファイルを棚卸ししてください。その結果をもとにProject設定の初期版を作り、必要なものだけManagedへ昇格します。設定の作り込みに迷う場合は、お問い合わせ・無料相談から、対象リポジトリの前提を整理したうえで相談できます。今日から始めるなら、まずは「許可するコマンド」ではなく「許可しないもの」を書き出すところからで十分です。
運用台帳に残す項目
権限設計を継続運用するには、設定ファイルだけでなく運用台帳を持つと便利です。台帳には、許可したコマンド、拒否したパス、追加ディレクトリ、導入したhook、managed settingsで固定した項目、設定変更の承認者、次回見直し予定を残します。これは形式的な監査資料ではなく、半年後に「なぜこの許可があるのか」を思い出すための実務メモです。
特にallowに追加したBashルールは、追加理由が消えると危険度を判断できなくなります。読み取り専用の調査なのか、テスト実行なのか、外部通信を伴うのか、ファイル削除やデプロイに近い副作用があるのかを分類しておきます。分類があれば、新しいリポジトリへ横展開するときにも、単純コピーではなくリスクごとに再評価できます。
また、Claude Codeのバージョンや公式仕様が変わったときの確認手順も台帳に入れます。公式ドキュメントのpermission modes、settings、hooks、securityの更新を確認し、社内テンプレートとの差分を見ます。変更があれば、まず検証リポジトリで挙動を試し、問題がなければProject設定やManaged設定へ反映します。この小さなメンテナンス習慣が、導入後の設定肥大化を防ぎます。
よくある質問
最初からauto modeを標準にしてもよいですか？
業務導入初期の標準にはしない方が安全です。まずdefaultやacceptEditsで挙動を学び、検証環境や低リスク作業に限定して段階的に使う方が、設定ミスやプロンプト疲れを発見しやすくなります。
Project設定だけで社内ポリシーを守れますか？
Project設定は共有しやすい一方、全社で必ず守るルールの最終防衛線には向きません。bypassPermissionsの無効化、共通deny、MCPやhookの制限などはmanaged settingsで配る設計を検討してください。
権限設計とhooksはどちらを優先すべきですか？
まず権限設計で「できること」を絞り、そのうえでhooksにより整形、検査、通知、追加ガードを実装します。hooksは権限の代替ではなく、許可された操作に対する検証レイヤーです。
