結論：Claude Code の挙動は settings.json で決まります。設定ファイルは「ユーザー → プロジェクト共有 → プロジェクトローカル → 管理(Managed)」の階層を持ち、上位ほど優先されます。チームで揃えたいルールは .claude/settings.json に、個人だけのルールは .claude/settings.local.json に書き分けるのが基本設計です。
- 要点1：設定ファイルは User / Project(共有) / Local / Managed の4階層。優先順位は Managed が最上位で、ユーザー設定が最下位。
- 要点2：権限は
permissionsのallow/ask/denyで制御。評価順は deny → ask → allow で、deny が常に勝つ。 - 要点3：モデルは
model、環境変数はenv、自動化はhooks/statusLine/outputStyleで指定。チーム共有とローカルを使い分ける。
対象読者：Claude Code を自分やチーム向けに整えたい開発者・テックリード・SRE。
この記事で分かること：settings.json の階層と優先順位、権限ルールの書式、env・model の指定、hooks / statusLine 等のカスタマイズ、そしてチーム共有とローカル設定の安全な使い分け。本記事の設定キー・書式は code.claude.com の公式ドキュメント（2026年6月時点）で裏取りしています。
Claude Code を触り始めた頃、「権限プロンプトが毎回出てうっとうしい」「チームで権限の効かせ方がバラバラ」「--dangerously-skip-permissions を雑に常用していて怖い」——このあたりで一度 settings.json を整理したくなるはずです。実際、私が100社以上の現場で Claude Code 導入を支援してきて、最初の1週間で一番ハマるのが「設定ファイルがどこにあって、どれが優先されるのか分からない」という階層の問題でした。
正直なところ、settings.json は機能てんこ盛りで全部覚える必要はありません。重要なのは「①どのファイルに書くと誰に効くか」「②権限はどう書くと安全か」の2点です。この記事ではその2点を軸に、現行の公式仕様で整理していきます。設定キーはバージョンで増減するので、最終的には公式docsで最新を確認してください。
settings.json の階層と優先順位（最初に押さえる）
Claude Code の設定は1つのファイルではなく、複数の settings.json が階層的にマージされて決まります。公式ドキュメントによると、優先順位は高い順に以下のとおりです（上が強い）。
- Managed（管理者ポリシー）：MDM や OS レベルで配布。ユーザー・プロジェクト設定では上書き不可。
- コマンドライン引数：
--settingsや--model等。そのセッション限り。 - Local（個人・リポジトリ単位）：
.claude/settings.local.json。自分だけ・このリポジトリだけ。gitignore 対象。 - Project（チーム共有）：
.claude/settings.json。git にコミットしてチーム全員に配る。 - User（自分の全プロジェクト）：
~/.claude/settings.json。自分の全プロジェクト共通。
つまり「管理者がロックしたものは誰も外せない」「コマンドライン > ローカル > プロジェクト共有 > ユーザー」という強さ関係です。チームで揃えたい挙動は .claude/settings.json に、自分のマシンだけの好みは ~/.claude/settings.json に書くのが基本です。
Managed（管理設定）のファイルパスはOSごとに決まっています。
macOS: /Library/Application Support/ClaudeCode/managed-settings.json
Linux: /etc/claude-code/managed-settings.json
Windows: C:\Program Files\ClaudeCode\managed-settings.jsonここで重要なのが「deny は階層をまたいでも勝つ」点です。後述しますが、管理設定で deny されたツールは、ユーザーが --allowedTools を付けても解放できません。エンタープライズでの統制はこの仕組みに乗ります。Claude Code のセキュリティ統制全体は、別記事の法人導入セキュリティ完全チェックリストも併せて確認してください。
最小構成の settings.json を書いてみる
いきなり全キーを並べると迷うので、まずは実務で使う最小構成から。プロジェクトルートに .claude/settings.json を作り、次のように書きます。
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"model": "claude-sonnet-4-6",
"permissions": {
"allow": [
"Bash(npm run lint)",
"Bash(npm run test:*)",
"Read(~/.zshrc)"
],
"deny": [
"Bash(curl *)",
"Read(./.env)",
"Read(./.env.*)"
],
"defaultMode": "ask"
},
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1"
}
}$schema 行を入れておくと、VS Code / Cursor でキー補完とバリデーションが効きます。これがあるかないかで設定ミスの早期発見率がだいぶ変わるので、最初に1行入れておくのがおすすめです。あとは model・permissions・env の3つを埋めれば、日常運用の8割はカバーできます。
権限設定（permissions）— allow / ask / deny の書き方
ここが settings.json の本丸です。permissions オブジェクトには3つのリストがあります。
allow：確認なしで自動許可するツール・コマンドask：使う前に毎回確認を出すツール・コマンドdeny：完全にブロックするツール・コマンド（ユーザーが上書き不可）
公式ドキュメントによれば、ルールは deny → ask → allow の順で評価され、最初にマッチしたルールが勝ちます。だから deny は常に最強です。「allow に入れたのに動かない」という時は、たいてい別階層の deny に引っかかっています。
ルール書式：Tool(specifier)
書式は Tool または Tool(specifier)。ツール名だけ書くと全使用にマッチします。
// 全マッチ（括弧なし）
"Bash" // 全 Bash コマンド
"WebFetch" // 全 WebFetch
// 個別指定（specifier あり）
"Bash(npm run build)" // この完全一致コマンドのみ
"Read(./.env)" // カレントの .env 読み取り
"WebFetch(domain:example.com)" // example.com への fetch のみ
"mcp__puppeteer__*" // puppeteer MCP サーバーの全ツールBash はワイルドカード * が使えます。ここで一番ハマるのが「スペースの有無」です。公式docsの説明どおり、Bash(ls *) は ls -la にマッチしますが lsof にはマッチしません（スペースが語境界を作る）。一方 Bash(ls*) は両方にマッチします。意図せず広く許可しないために、末尾ワイルドカードは Bash(npm run test:*) のように :* で書くのが分かりやすいです（:* は末尾の * と等価）。
❌よくある失敗 ⭕正しい書き方
- ❌
Bash(curl http://github.com/ *)で curl を GitHub だけに縛ろうとする → オプション順・プロトコル違い・変数展開で簡単にすり抜ける。
⭕denyでBash(curl *)をブロックし、許可ドメインはWebFetch(domain:github.com)側で開ける。 - ❌
Read(/Users/alice/secret)を絶対パスのつもりで書く → これはプロジェクトルート相対で、絶対パスはRead(//Users/alice/secret)（スラッシュ2つ）。
⭕ 絶対パスは//、ホームは~/、プロジェクトルートは/、カレントは./で使い分ける。 - ❌
Bash(safe-cmd *)を許可すればsafe-cmd && rm -rf .も通ると思い込む → Claude Code はシェル演算子を認識し、複合コマンドは各サブコマンドが個別にマッチしないと許可されない。
⭕ 複合コマンドは各部分を個別に allow する前提で設計する。
補足として、Read / Edit の deny ルールは Claude の組み込みファイルツールと、Bash 上で認識される cat / head / sed 等のファイル系コマンドには効きますが、Python や Node スクリプトが内部で開くファイルには効きません。OS レベルで全プロセスを縛りたい場合はサンドボックスを併用します。詳しくはサンドボックスで安全に自動実行するガイドを参照してください。
権限モード（defaultMode）と起動時の挙動
個々のルールとは別に、全体の振る舞いを決めるのが permissions.defaultMode です。主なモードは以下のとおり。
default：各ツールの初回使用時に確認プロンプトを出す標準動作。acceptEdits：ファイル編集とmkdir/touch/mv/cp等の一般的なファイル操作を作業ディレクトリ内で自動許可。plan：Plan Mode。読み取りと read-only シェルでの調査のみ行い、ソースを編集しない。bypassPermissions：全プロンプトをスキップ。ただしrm -rf /やrm -rf ~など破壊的操作はサーキットブレーカーとして依然プロンプトが出る。
このほか research preview の auto（背景安全チェック付き自動承認）や dontAsk（事前許可以外は自動拒否）もあります。bypassPermissions はコンテナ・VM のような壊れても困らない隔離環境専用と考えてください。管理者は permissions.disableBypassPermissionsMode を "disable" にして、この危険モードを組織的に封じられます。
なお Plan Mode の安全な使い方はPlan Mode 実践ガイドで詳しく扱っています。大きな変更を任せる前に plan で読ませる運用は、事故率を下げる定番です。
モデル・環境変数・認証まわりの指定
モデルの指定（model）
使用モデルは settings.json の model で固定できます。
{
"model": "claude-sonnet-4-6"
}セッション限りで切り替えたいなら claude --model claude-opus-4-6 や環境変数 ANTHROPIC_MODEL でも指定できます。/model コマンドで対話的に変えることも可能です。組織で選べるモデルを絞りたい場合は availableModels を使います。モデル名は更新が早いので、実際に使えるIDは公式docsとリリースノートで最新を確認してください。
環境変数（env）
env に書いた変数は毎セッションに適用されます。テレメトリ有効化や独自変数の注入に使います。
{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp"
}
}代表的なフラグには DISABLE_AUTOUPDATER（自動更新停止）、CLAUDE_CODE_DISABLE_THINKING（拡張思考の停止）などがあります。利用可能な変数はバージョンで増えるので、env-vars の公式ページで都度確認するのが安全です。
認証ヘルパー（apiKeyHelper）
Vault から短命トークンを取るような動的認証では、apiKeyHelper にスクリプトパスを指定します。公式によると既定では5分ごと、または HTTP 401 応答時に再呼び出しされます。CI ではブラウザログインが使えないので、claude setup-token で発行した CLAUDE_CODE_OAUTH_TOKEN を使う方法もあります。
hooks・statusLine・outputStyle のカスタマイズ
挙動の自動化・見た目は次のキーで指定します。
hooks：ライフサイクルイベントでシェルコマンドを発火（整形・通知・ブロック等）。書式は hooks ドキュメント準拠。statusLine：プロンプト下のステータス行をカスタムスクリプトで描画。outputStyle：システムプロンプトを調整（例"Explanatory"）。/clearか再起動で反映。language：応答言語（例"japanese"）。editorModeでvimキーバインドも可。
hooks は権限の延長としても使えます。公式の説明どおり、PreToolUse フックは権限プロンプトの前に走り、ツール呼び出しを deny したり強制プロンプトに変えたりできます。ただしフックの判断は deny / ask ルールを上書きしません（deny-first の原則は維持される）。「Bash は基本許可しつつ、特定コマンドだけフックで弾く」といった運用が定番です。hooks の具体例はHooks 実践ガイドにまとめています。
また、自動化を全停止したいときは disableAllHooks、組織配布の hooks 以外を無効化したいときは allowManagedHooksOnly（管理設定専用）を使います。
チーム共有とローカル設定の使い分け（設計の勘所）
最後に、現場で一番効く「書き分けの設計」をまとめます。判断軸はシンプルで「これは全員に効かせるべきか？」です。
- 全員に強制したいルール（危険コマンドの deny、必須モデル等）→
.claude/settings.json（git コミット）。組織レベルで絶対にしたいなら Managed 設定へ。 - このリポジトリで自分だけが使う設定（個人の allow リスト等）→
.claude/settings.local.json（gitignore）。 - 自分の全プロジェクト共通の好み（
editorMode、通知設定等）→~/.claude/settings.json。
ここで CLAUDE.md（プロジェクトメモリ）との役割分担を混同しないことが大事です。settings.json は「Claude Code が何を許すか」を決め、CLAUDE.md は「Claude に何を試させるか」を方向づける——公式も明記しているとおり、プロンプトや CLAUDE.md の指示は権限ルールを変えません。だから「CLAUDE.md に書いたのに勝手に危険操作をした」を防ぐには、必ず settings.json の deny で物理的に塞ぐ必要があります。CLAUDE.md 側の設計はCLAUDE.md 設計・運用ガイドを参照してください。
追加で読み書きを許すディレクトリは permissions.additionalDirectories で指定します。ただし注意点として、settings に書いた additionalDirectories はファイルアクセスだけを許可し、そのディレクトリの .claude/ 設定は読み込みません。設定ごと読ませたい場合は --add-dir フラグや /add-dir コマンドを使います。
まとめと次のアクション
settings.json は階層さえ理解すれば怖くありません。「Managed > CLI > Local > Project共有 > User」の優先順位と、「deny → ask → allow」の権限評価順、この2つが背骨です。あとは model / env / hooks を必要に応じて足していけば、自分にもチームにも安全な環境が作れます。
今日からできる3アクション：
- 最小構成を1つ作る：本記事の最小
.claude/settings.jsonをコピーし、$schema行とdeny（.env読み取り・curl）だけ先に入れる。 - 階層を可視化する：
/permissionsを開き、どのルールがどのファイル由来か確認する。意図しない allow がないかチェック。 - 共有とローカルを分ける：チーム強制ルールを
settings.jsonへ、個人の好みをsettings.local.json/~/.claude/settings.jsonへ移す。
次回は、この設定を前提にした「チーム配布用 settings.json テンプレート集」を扱う予定です。設定キーは進化が速いので、本番投入前に必ず公式docs（code.claude.com）で最新仕様を確認してください。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。Claude Code の法人導入・個別指導を提供しています。
