Claude Codeのsettings.jsonをチームで共有する設定──共有・個人・組織の4つの置き場所、permissionsのallow・ask・denyの決め方、効かないときの確かめ方
この記事は、Claude Codeの settings.json をチームで共有し、permissions（権限）のallow・ask・denyを決める方法を扱います。
同じリポジトリなのに、人によってAIの動きが違う
「Aさんの環境では確認なしでテストが走るのに、Bさんの環境では毎回聞かれる」
「新人のPCだけ、.env を読もうとした」
Claude Codeをチームで使い始めると、こうした差が出ます。
原因は、設定ファイルの置き場所が人によってばらばらなことです。
チームの設定とは、全員に効かせる決まりをリポジトリの設定ファイルに置き、個人の好みを個人のファイルに分けることである
黒字化の外科医です。Claude Codeの設定ファイルを、チームで使う目線で解剖します。
置き場所を分けるべき理由は、三つあります。
第一に、置いた場所で、効く範囲が決まるから。
同じ設定でも、自分のPCの設定に書けば自分だけ、リポジトリに書けば、そのリポジトリで作業する全員に効きます。
第二に、許可の規則は、足し算で合わさるから。
公式ドキュメントでは、`permissions.allow` のようなリストは、複数のファイルにあると上書きではなく結合されると説明されています。誰かの個人の許可が、チームの決まりの上に積み重なります。
第三に、止める規則は、許す規則より強いから。
規則は deny（止める）→ ask（確認する）→ allow（許す）の順に判定され、最初に当てはまったものが結果になります。広い deny は、より細かい allow でも外せません。
Claude Codeの設定ファイル4つ、公式で確認できたこと
2026年10月27日に、公式ドキュメント（code.claude.com/docs の Settings files and precedence、Configure permissions、Example settings files）で確認した内容です。
置き場所 効く範囲 使い道
~/.claude/settings.json 自分の全プロジェクト 個人の好み、自分用の規則
.claude/settings.json そのフォルダで作業する全員 チームの権限・hooks
（コミットすれば共有）
.claude/settings.local.json 自分の、そのプロジェクトだけ 個人の例外、共有前の試し
managed-settings.json など 組織が配布した全員 組織の方針（上書きできない）
優先順位（上が強い）：組織の管理設定 → 起動時の --settings → settings.local.json
→ .claude/settings.json → ~/.claude/settings.jsonチームで押さえる注意点は、次の5つです。
- `.claude/settings.local.json` は、Claude Codeが自分で作ったときはgitの対象から外します。手で作ったときは、自分で `.gitignore` に入れます
- 共有ファイルの allow の規則は、各自がそのフォルダを「信頼」してから効きます。deny と ask はすぐに効きます
- 設定ファイルは厳密なJSONです。`//` のコメントや末尾のカンマがあると、エラーになります
- 権限モードの `auto` と `bypassPermissions` は、共有ファイルや local ファイルの `defaultMode` に書いても効きません
- 設定が読まれたかは、Claude Codeの中で `/status` を実行し、Setting sources の行で確かめます
今すぐ試せる：自社の権限の案を作るプロンプト
私はWeb制作会社の技術責任者です。Claude Codeの共有設定（.claude/settings.json）の permissions の案を作ってください。
（顧客名や秘密情報は入力しません）
【前提】
・案件の種類（WordPress、静的サイト、Webアプリなど）：〔記載〕
・よく使うコマンド（ビルド、テスト、lintなど）：〔記載〕
・読ませたくないファイルやフォルダ（.env、鍵、顧客データなど）：〔記載〕
・人の確認を必ず挟みたい操作（push、デプロイなど）：〔記載〕
1. allow・ask・deny に分けた案を、公式ドキュメントの書き方（Bash(…)、Read(./…)）で示す。
2. deny → ask → allow の順で判定されることを踏まえ、意図と違う結果になる組み合わせがないか点検する。
3. コマンドの書き方の違いで規則をすり抜ける例を挙げ、別の手段（sandbox、hooks）が要る点を示す。共有設定工場：チームの settings.json の例
公式ドキュメントのチーム向けの例（npmのスクリプトは許し、git push は確認し、.env と secrets を読ませない）を、制作会社向けに絞った形です。
{
"permissions": {
"allow": [
"Bash(npm run lint)",
"Bash(npm run test *)"
],
"ask": [
"Bash(git push *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)"
]
}
}規則の書き方で迷う3点
① パスの起点
//path … ファイルシステムの最上位から（例：Read(//Users/alice/secrets/**)）
~/path … ホームフォルダから
/path … 設定ファイルの場所が基準（プロジェクトの設定なら、作業フォルダが基準）
./path または path … 今のフォルダから
② Write(…) のパス指定は一致しない
ファイルの書き込みを止めるときは Edit(…) で書く
③ コマンドの規則は、書かれた形にだけ当たる
Bash(git push *) は git -C . push には当たらない
Bash(rm *) は bash -c 'rm …' には当たらない③は、公式ドキュメントが自ら注意しているところです。
deny は「いつもの書き方」を止めるもので、守りの壁そのものではありません。確実に止めたい操作は、sandbox や hooks と組み合わせます。
設定を変えるときの決まり
共有ファイルの変更は、プルリクエストで技術責任者がレビューし、変更後に `/status` で読み込みを確かめます。
個人の allow はチームの allow に足されますが、deny を外すことはできません。決まりを緩めたい人は、共有ファイルの変更として提案してもらいます。
構造的なリスク
逆説を指摘しておきます。
ask を増やすほど、承認の操作が増え、人は中身を読まずに承認するようになります。
確認が多すぎる設定は、確認していないのと同じ結果になります。
だから、ask は本当に人の判断が要る操作だけに絞り、毎日何十回も承認している操作は、allow か deny に移すかを月に1回決め直します。
よくあるQ&A
Q. 組織全体で決まりを強制したい。
組織の管理設定（managed settings）は、個人やプロジェクトの設定で上書きできません。Teamプランでは、管理画面から配る方法（server-managed settings）が案内されています。
Q. 社内の作業ルールは、どこに書くのか？
決まりの文章は CLAUDE.md に書きます。ただし公式は、CLAUDE.md を「強制される設定」ではなく文脈として扱うと説明しています。止めたいことは、この記事の設定の側に入れます。
▶ CLAUDE.mdの書き方、制作会社の作業ルールをAIに渡す──置き場所4つ、書く項目と書かない項目、200行を目安にする理由、そのまま使える骨子
最後に
Claude Codeの設定は、置いた場所で効く範囲が決まり、止める規則が許す規則より強く判定されます。
全員に効かせる決まりをリポジトリに置き、個人の例外を local に分け、変更をレビューする会社だけが、AIをチームの道具として安全に使えるのです。
共有設定・個人設定・組織設定の雛形と運用の表は、導入設定キットにまとめました。
▶ Claude Code導入設定キット、制作会社がそのまま置くファイル一式──チーム共有・個人・組織のsettings.json、CLAUDE.mdの雛形、hooksの守りの設定、席の割当表と運用表
これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。
#Web制作会社 #ClaudeCode #settingsjson #権限管理 #チーム開発 #AI駆動開発 #制作会社経営 #中小企業 #開発体制 #生成AI
