Claude Codeのsettings.json完全ガイド:権限・Hooks・MCP・チーム設定を安全に使う方法

Claude Codeのsettings.json、権限設定、Hooks、MCP連携を表す青と白のテクノロジー系アイキャッチ画像 AIツール
\n\n
\n
\n

Claude Codeのsettings.json完全ガイド:権限・Hooks・MCP・チーム設定を安全に使う方法

\n

Claude Codeのsettings.jsonは、権限、環境変数、Hooks、モデル、プラグイン、チーム共通ルールを管理する重要な設定ファイルです。

\n
\n Claude Code\n settings.json\n Hooks\n 権限管理\n
\n
\n\n

この記事では、Claude Codeのsettings.jsonについて、どこに置くのか、どの設定が優先されるのか、権限設定やHooksをどう書くのか、チーム開発で何を共有すべきかまで実務向けに詳しく解説します。

\n\n
\n

前提:本記事は2026年6月9日時点のAnthropic公式Claude Code Docsをもとにしています。Claude Codeは更新が速く、設定キーや管理ポリシーの扱いが変わる可能性があります。導入前には必ず公式ドキュメントも確認してください。

\n
\n\n
\n

settings.jsonとは?Claude Codeの動作を決める設定ファイル

\n

settings.jsonは、Claude Codeの挙動をJSONで管理する設定ファイルです。たとえば、どのコマンドを自動許可するか、どのファイルを読ませないか、編集後にテストを走らせるか、標準モデルを何にするか、といった設定を書けます。

\n

混同しやすいのがCLAUDE.mdとの違いです。CLAUDE.mdは「プロジェクトの説明や作業ルールをClaudeに読ませるメモリ」、settings.jsonは「Claude Code本体の権限・ツール・環境を制御する設定」です。

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
ファイル役割
CLAUDE.mdClaudeに伝える作業方針テスト手順、コーディング規約、禁止事項
settings.jsonClaude Codeの設定権限、Hooks、環境変数、モデル、プラグイン
.mcp.jsonプロジェクト単位のMCPサーバー設定GitHub、DB、社内APIなどの外部ツール接続
\n
\n\n
\n

settings.jsonを置く場所と優先順位

\n

Claude Codeの設定は、1つのファイルだけで決まるわけではありません。ユーザー全体、プロジェクト共有、個人用ローカル、組織管理ポリシーなど複数の階層があります。

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
場所用途Gitに入れる?
~/.claude/settings.json自分の全プロジェクトに効く個人設定入れない
.claude/settings.jsonチームで共有するプロジェクト設定入れる
.claude/settings.local.jsonそのリポジトリだけの個人設定入れない
managed-settings.json会社や管理者が強制するポリシー管理者が配布
\n

優先順位は、上から「管理ポリシー」「コマンドライン引数」「ローカルプロジェクト設定」「共有プロジェクト設定」「ユーザー設定」です。つまり、~/.claude/settings.jsonで許可していても、プロジェクト側や管理ポリシーで制限されていれば、そちらが優先されます。

\n
\n

実務の考え方:チームで共通化したい設定は.claude/settings.json、個人の好みや秘密情報に関わる設定は.claude/settings.local.json、全リポジトリに効かせたい個人設定は~/.claude/settings.jsonに置くのが基本です。

\n
\n
\n\n
\n

まず入れたい基本形:スキーマ、権限、機密ファイル保護

\n

最初におすすめなのは、JSON Schema、最小限の許可、機密ファイルの読み取り拒否です。特に.env、認証JSON、秘密鍵、ビルド成果物は読ませない設定にしておくと事故を減らせます。

\n
{\n  "$schema": "https://json.schemastore.org/claude-code-settings.json",\n  "permissions": {\n    "allow": [\n      "Bash(npm run lint)",\n      "Bash(npm run test *)",\n      "Bash(git status)",\n      "Bash(git diff *)"\n    ],\n    "deny": [\n      "Read(./.env)",\n      "Read(./.env.*)",\n      "Read(./secrets/**)",\n      "Read(./config/credentials.json)",\n      "Read(./build)"\n    ]\n  }\n}
\n

$schemaを入れておくと、VS CodeやCursorなどのエディタで補完やバリデーションが効きやすくなります。ただし、公式ドキュメントに追加されたばかりの設定は、スキーマ側の更新が追いつかない場合もあります。

\n

権限設定では、便利さを優先して広く許可しすぎないことが重要です。最初はnpm run lintnpm run testgit statusgit diffのような安全な確認系から始め、必要に応じて追加していくのが現実的です。

\n
\n\n
\n

permissionsの考え方:allow・deny・defaultMode

\n

permissionsは、Claude Codeに何を許可し、何を止めるかを決める中心設定です。開発効率を上げるために自動許可を増やしたくなりますが、ここは「読む・書く・実行する」の3つを分けて考えると整理しやすくなります。

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
設定目的
allow確認なしで許可する操作テスト、lint、差分確認
deny常に拒否する操作機密ファイル読み取り、危険コマンド
defaultMode起動時の権限モードdefaultacceptEditsplanなど
\n

defaultModeは、Claude Codeを起動したときの権限モードを指定します。たとえば、編集は許可しやすくしつつコマンド実行は確認したい場合はacceptEditsが候補になります。作業前に設計だけさせたい場合はplanも有効です。

\n
\n

注意:bypassPermissionsのような強い権限モードを常用するのはおすすめしません。AIエージェントは便利ですが、シェルコマンドやファイル削除を広く許可すると、誤操作の影響が大きくなります。

\n
\n
\n\n
\n

env設定:環境変数は便利だが秘密情報の扱いに注意

\n

envには、Claude Codeのセッションで使う環境変数を設定できます。たとえば、テレメトリ、言語、内部ツール用のフラグなどです。

\n
{\n  "language": "japanese",\n  "env": {\n    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",\n    "OTEL_METRICS_EXPORTER": "otlp"\n  }\n}
\n

一方で、APIキーや長期トークンをそのまま.claude/settings.jsonに書くのは避けた方が安全です。チーム共有ファイルに秘密情報が混ざると、リポジトリ経由で漏えいする可能性があります。

\n

個人環境の値は.claude/settings.local.jsonやOS側のシークレット管理、必要に応じてapiKeyHelperのようなヘルパー方式を検討します。特にGoogle、AWS、GitHub、社内APIとつなぐ場合は、Claudeに認証情報の中身を読ませず、必要なコマンドだけ実行させる設計が安全です。

\n
\n\n
\n

Hooks設定:編集後のテストや危険コマンドブロックを自動化する

\n

Hooksは、Claude Codeのライフサイクルに合わせてシェルコマンド、HTTPエンドポイント、MCPツール、プロンプトなどを実行する仕組みです。代表的には、ツール実行前のPreToolUse、実行後のPostToolUse、ユーザー入力前後、セッション開始時などに使えます。

\n

たとえば、Claudeがファイルを編集した後にlintを走らせる設定は次のように書けます。

\n
{\n  "hooks": {\n    "PostToolUse": [\n      {\n        "matcher": "Edit|Write",\n        "hooks": [\n          {\n            "type": "command",\n            "command": ".claude/hooks/run-lint.sh"\n          }\n        ]\n      }\n    ]\n  }\n}
\n

また、危険なコマンドを実行前に検査するならPreToolUseが向いています。公式ドキュメントでも、Bashツールに対してrm -rfのような破壊的コマンドをブロックする例が紹介されています。

\n
{\n  "hooks": {\n    "PreToolUse": [\n      {\n        "matcher": "Bash",\n        "hooks": [\n          {\n            "type": "command",\n            "if": "Bash(rm *)",\n            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-rm.sh"\n          }\n        ]\n      }\n    ]\n  }\n}
\n

Hooksは非常に強力ですが、設定ファイルに書いたコマンドが自動実行される点に注意が必要です。プロジェクト共有のHooksを導入する場合は、スクリプトの中身をレビューし、外部通信や削除処理がないか確認しましょう。

\n
\n\n
\n

MCP・プラグイン・マーケットプレイス設定

\n

Claude Codeでは、MCPサーバーやプラグインを使って外部ツール連携を広げられます。ただし、すべてをsettings.jsonに書くわけではありません。公式ドキュメントでは、プロジェクトスコープのMCPサーバーは.mcp.json、ユーザーやローカルのMCP情報は~/.claude.json側に保存されると説明されています。

\n

settings.jsonで扱う代表例は、プラグインの有効化や追加マーケットプレイスです。

\n
{\n  "enabledPlugins": {\n    "code-formatter@team-tools": true,\n    "deployment-tools@team-tools": true\n  },\n  "extraKnownMarketplaces": {\n    "team-tools": {\n      "source": {\n        "source": "github",\n        "repo": "your-org/claude-plugins"\n      }\n    }\n  }\n}
\n

チームで使うプラグインを標準化したい場合は、.claude/settings.jsonにマーケットプレイスを登録し、必要なプラグインを有効化します。企業利用では、管理ポリシー側でstrictKnownMarketplacesを使い、許可されたマーケットプレイス以外をブロックする運用も可能です。

\n
\n\n
\n

チーム開発でおすすめのsettings.json構成

\n

チームでClaude Codeを使うなら、共有ファイルと個人ファイルを明確に分けることが重要です。特に、個人のパス、APIキー、ローカルだけのコマンド、実験的なHooksは共有設定に入れないようにします。

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
入れる場所入れてよいもの避けるもの
.claude/settings.json共通のdeny、共通テスト、共有Hooks、推奨プラグイン個人パス、秘密情報、未検証の自動実行
.claude/settings.local.json個人の許可コマンド、ローカル環境変数、実験設定チーム全員に必要なルール
~/.claude/settings.json言語、表示、個人の全体設定特定リポジトリ専用のルール
\n
\n

おすすめ構成:リポジトリには「機密ファイルを読ませない」「テストやlintの標準コマンド」「危険操作を止めるHooks」だけを共有し、便利系の自動許可は各メンバーのsettings.local.jsonに任せると運用しやすくなります。

\n
\n
\n\n
\n

設定が効かないときの確認ポイント

\n

Claude Codeの設定が効かないときは、まず配置場所と優先順位を確認します。ユーザー設定に書いた内容がプロジェクト設定で上書きされている、settings.local.jsonが存在している、管理ポリシーが効いている、というケースはよくあります。

\n
    \n
  • /statusで読み込まれている設定ソースを確認する
  • \n
  • JSONの構文エラーがないか確認する
  • \n
  • プロジェクト設定とローカル設定で同じキーを書いていないか確認する
  • \n
  • 配列系の設定は置き換えではなくマージされる点を理解する
  • \n
  • modelなど一部の設定はセッション再起動が必要な場合がある
  • \n
\n

公式ドキュメントでは、permissions.allowsandbox.filesystem.allowWriteのような配列設定は、スコープ間で連結・重複排除されると説明されています。単純に「上位が下位を完全に置き換える」と考えると、意図しない許可が残ることがあります。

\n
\n\n
\n

実用テンプレート:個人開発向けとチーム向け

\n

個人開発向け

\n
{\n  "$schema": "https://json.schemastore.org/claude-code-settings.json",\n  "language": "japanese",\n  "permissions": {\n    "defaultMode": "acceptEdits",\n    "allow": [\n      "Bash(npm run lint)",\n      "Bash(npm run test *)",\n      "Bash(git status)",\n      "Bash(git diff *)"\n    ],\n    "deny": [\n      "Read(./.env)",\n      "Read(./.env.*)",\n      "Read(./secrets/**)"\n    ]\n  }\n}
\n

チーム共有向け

\n
{\n  "$schema": "https://json.schemastore.org/claude-code-settings.json",\n  "permissions": {\n    "deny": [\n      "Read(./.env)",\n      "Read(./.env.*)",\n      "Read(./secrets/**)",\n      "Bash(rm -rf *)"\n    ]\n  },\n  "hooks": {\n    "PostToolUse": [\n      {\n        "matcher": "Edit|Write",\n        "hooks": [\n          {\n            "type": "command",\n            "command": ".claude/hooks/check-after-edit.sh"\n          }\n        ]\n      }\n    ]\n  }\n}
\n

チーム共有向けでは、全員に強制したい最低限の安全設定だけを入れるのがポイントです。プロジェクトごとにテストコマンドが違う場合は、package.jsonMakefile側に共通コマンドを用意しておくと、Claude Codeからも人間からも同じ手順で実行できます。

\n
\n\n
\n

設定ファイルを整える前に、自動更新の失敗でClaude Codeが起動しなくなっていないか確認してください。原因と再発防止策はClaude CodeのAuto-update failedで再び起動不能にをご覧ください。

まとめ:settings.jsonは「便利設定」ではなく安全な運用設計

\n

Claude Codeのsettings.jsonは、単なる好みの設定ファイルではありません。AIエージェントにどこまで作業を任せるか、何を絶対に読ませないか、編集後に何を確認するかを決める運用設計の中心です。

\n

まずは、.envや秘密情報の読み取り拒否、lint・test・差分確認の許可、必要最小限のHooksから始めましょう。チームで使う場合は、共有設定と個人設定を分け、便利さよりも再現性と安全性を優先すると失敗しにくくなります。

\n

Claude Codeを本格的に使うなら、CLAUDE.mdで作業方針を伝え、settings.jsonで権限と自動化を管理し、必要に応じてMCPやプラグインで外部ツール連携を広げる。この3点セットで整えるのがおすすめです。

\n
\n\n
\n

参考リンク

\n \n

本記事の内容は2026年6月9日時点の公式情報をもとにしています。Claude Codeの設定キー、権限モード、Hooks、プラグイン仕様は更新される可能性があります。

\n
\n
\n
タイトルとURLをコピーしました