settings.json（セッティングス・ジェイソン）

料理ブログ等のプロジェクトでClaude Codeを使い始めて、許可ルールや環境変数を1ファイルにまとめて管理したい人向け

そもそも settings.json は何のためにあるのか

Claude Code を毎回ターミナルで起動するたびに「このコマンドは許可しますか？」と聞かれるのは、最初は安心感があるけど、3日もするとうるさい。

料理ブログの開発中、私が git status を打つたびに毎回「実行しますか？」と確認されていたら、たぶん10分で叩き消したくなります。

そこで settings.json の出番です。「git status は毎回OK」「git push は逆に絶対ダメ」「Hugo の環境変数は dev で固定」みたいなルールを、JSON という形式の1ファイルに書いておく。Claude Code は起動するたびにこのファイルを読んで、書いてある通りに動きます。

もう1つ大事なのは、このファイルを git に乗せてチームで共有できる点です。料理ブログを共同編集している友達と「許可ルール」を揃えたいとき、settings.json をリポジトリに置いておけば、全員が同じ動作で Claude Code を使えます。

噛み砕くと

家族用と個人用で、別々の手帳に分けて書いておく感覚に近いです。

家族全員が見る冷蔵庫の貼り紙には「醤油は切らさない」「日曜は米を炊く」みたいな共通ルールを書く。これが .claude/settings.json（プロジェクト全体で共有）の役割です。

一方で「私だけの好みでデプロイは rsync を使う」みたいな個人ルールは、私だけの手帳に書く。これが .claude/settings.local.json の役割。家族には押し付けない、私のリビングだけの設定。

そしてさらに上位に、家全体の家訓として「夜10時以降は静かに」みたいなルールがあります。これが企業ポリシーとして配布される enterprise 設定。誰が来ても上書きされません。

4種類の手帳が重なっていて、後から書いた方が優先される。これが settings.json の構造です。

settings.json はどこに置くと、いつ読まれるのか

4つの置き場所と、その優先順位を表にすると次の通りです。

重ね合わせの順番は enterprise > local > project > user で、上にあるほど強い。同じキーが複数のファイルに書いてあったら、上の方が勝ちます。

ただし例外として、permissions.allow みたいな配列は「上書き」じゃなく「合体（マージ）」されます。user で許可したコマンドと project で許可したコマンドは、両方有効になる。これは公式の挙動です。

つまり、組織のIT部門が enterprise で「git push 禁止」と書いたら、私が user で「git push OK」と書いてもダメ。逆に「許可リスト」はみんなのを足し合わせる方向で動きます。

料理ブログで「許可ルール＋Hugo環境変数＋lintフック」を1ファイルにまとめる4ステップ

共通題材は「料理ブログを Claude Code で開発している」状態です。プロジェクトフォルダは ~/projects/cooking-blog。Hugo で静的サイトを生成して、ブラウザで localhost:1313 でプレビュー、最後に rsync でサーバーにデプロイ、という構成。

ステップ1: .claude/settings.json を作って許可ルールの骨格を入れる

料理ブログのフォルダで .claude/ がまだなければ、新しく作ります。

$ cd ~/projects/cooking-blog
$ mkdir -p .claude
$ touch .claude/settings.json

そこに、チーム全員で揃えたい許可ルールを書きます。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(hugo *)",
      "Bash(npm run lint)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(rm -rf *)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

allow に書いたコマンドはClaude Codeが毎回確認なしで実行する。deny に書いたコマンドは絶対に実行しない。git push は禁止しておくと、ブランチを直接本番に上げる事故が消えます。

これだけで、git status や hugo server がノンストップで通るようになる。地味だけど効きます。

ステップ2: env で Hugo の動作環境を固定する

同じ settings.json に env を足します。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": ["Bash(git status)", "Bash(hugo *)", "Bash(npm run lint)"],
    "deny": ["Bash(git push *)", "Read(./.env)"]
  },
  "env": {
    "HUGO_ENV": "dev",
    "BASH_DEFAULT_TIMEOUT_MS": "300000"
  }
}

HUGO_ENV=dev を入れておくと、Hugo がプレビューモードで動いて下書き記事も表示してくれます。BASH_DEFAULT_TIMEOUT_MS は1コマンドの待ち時間上限を5分に伸ばす設定。Hugo のビルドが大きくなると2分（初期値）では足りなくなることがあるので、最初から伸ばしておく。

ステップ3: 個人だけの設定を .claude/settings.local.json に分離する

「私のマシンだけで rsync デプロイを許可したい」みたいな個人専用ルールは、別ファイルに書きます。

$ touch .claude/settings.local.json

{
  "permissions": {
    "allow": [
      "Bash(rsync -avz public/ user@example.com:/var/www/cooking/)"
    ]
  }
}

これで私のマシンでは rsync デプロイが通るけど、共同編集者の友達のマシンでは通らない。友達は友達の settings.local.json に、その人専用のデプロイ先を書く形になります。

そして、このファイルは git に乗せたくない。次のステップで .gitignore に追記します。

ステップ4: .gitignore に追記してチームに push する

プロジェクト直下の .gitignore を開いて、次の1行を足します。

.claude/settings.local.json

これで git status しても settings.local.json はリストに出てこない。逆に settings.json（プロジェクト共有）はちゃんと候補に出てくる。

あとはコミットして push するだけです。

$ git add .claude/settings.json .gitignore
$ git commit -m "add Claude Code shared settings"
$ git push origin main

共同編集者がリポジトリを git pull すると、自動的に .claude/settings.json が降ってきて、許可ルールと env が共有される。これでようやく「全員で同じ動作」が実現します。

主要な設定キーの早見表

料理ブログ題材で具体例を入れた、よく使うキーの一覧です。

全キーは公式docs（記事末リンク）に載っています。最初は permissions と env だけで十分。

編集の3ルートをどう使い分けるか

settings.json を書き換える方法は3つあります。

• テキストエディタで直接書く。VS Code で開いて手で JSON を書き換える。$schema 行を入れておくとオートコンプリートが効くので、キー名のスペルミスが減ります。一番自由度が高い
• /permissions スラッシュコマンド。Claude Code 起動中に /permissions と打つと、許可ルールの一覧パネルが開いて、対話的に追加・削除ができる。permissions セクション専用
• /config スラッシュコマンド。同じく Claude Code 起動中に /config。設定UIが立ち上がって、permissions 以外も含めた主要な設定キーを画面から触れる。公式が推奨しているのはこのルート

私はチームで共有する .claude/settings.json はエディタで直接編集して、git diff でレビューしやすくする派。/permissions は「とりあえず1個許可ルールを足したい」みたいな軽い時に使います。

project scope と local scope を分ける運用

これが一番つまずきやすい部分です。

.claude/settings.json（project）には何を書くか。チーム全員で揃えたい動作だけ。料理ブログなら「Hugo を許可」「lint を許可」「git push を禁止」「HUGO_ENV=dev」みたいな共通ルール。これを git にコミットして配布します。

.claude/settings.local.json（local）には何を書くか。私だけのデプロイ先、私だけが使うAPIキー、私だけの好み（モデルを Opus に固定したい等）。これは .gitignore で除外して、git には乗せない。

判断の境目。「これを共同編集者のマシンに送り込んでいいか？」と自問して、迷うなら local に置く。秘密のキーや個人のサーバーアドレスを project 側に書いてコミットすると、git の履歴に永遠に残るので注意。

料理ブログ題材だと、こんな分け方になります。

料理ブログでの使いどころ3シナリオ

シナリオ1: 「hugo server を毎回確認されるのが鬱陶しい」

料理ブログのプレビューを立ち上げる時、Claude に hugo server -D を叩かせるたびに「実行しますか？」と聞かれる。1日10回叩いてたら、確認だけで5分溶けます。

project の settings.json に "Bash(hugo *)" を allow で1行入れる。これで全員が確認なしで Hugo を回せる。共同編集者にも同じ恩恵。

シナリオ2: 「下書き記事だけ見たいので Hugo の draft 指定を常に有効にしたい」

Hugo は HUGO_ENV=dev の時に下書きを表示する仕様（公式ドキュメント記載）。毎回 HUGO_ENV=dev hugo server -D と打つのは長い。

project の settings.json の env に "HUGO_ENV": "dev" を入れる。Claude Code から起動するすべてのコマンドで自動的にこの値がセットされて、もう打たなくていい。

シナリオ3: 「コミット直前に lint を必ず通したい」

料理ブログの記事HTMLが構文エラーで本番に上がる事故を防ぎたい。hooks セクションで PreToolUse を使い、Claude が git commit を叩こうとした瞬間に npm run lint を自動で走らせる設定を書きます。

lint がエラーを返したら、Claude のコミット操作はそこで止まる。この仕組みは hooks の本記事の範疇外なので、詳細は別エントリ（hooks 辞書）で扱います。settings.json の役割は「フックの定義をどこに書くか」を提供することです。

初心者が踏みやすい落とし穴

• JSON のカンマ忘れ・末尾カンマで丸ごと壊れる。{"a": 1, "b": 2,} の最後のカンマで Claude Code が起動時にエラーを吐く。$schema 行を入れておくとエディタが赤線を引いてくれるので必ず入れる
• .claude/settings.local.json を .gitignore に入れ忘れて秘密をコミットする。一度公開リポジトリに上がった API キーは履歴から消すのが地獄。最初に .gitignore 1行を入れる作業を絶対飛ばさない
• permissions.allow に "Bash(curl *)" みたいな広いルールを書く。一見便利だが、Claude が任意のURLにアクセスできてしまう。公式も「URLでフィルタしたい場合は WebFetch を使え」と警告している
• user と project で同じキーを書いて挙動が混乱する。model を user で "opus"、project で "sonnet" と書いたら project の方が勝ちます。「あれ？モデル変わってる」となったら project の settings を疑う
• enterprise の deny を user で上書きしようとして失敗する。組織管理の deny は誰も上書きできない。会社支給マシンで「git push できない！」と詰まったら、IT部門に管理ポリシーを確認
• Read/Edit の deny は Bash の cat をブロックしない。"Read(./.env)" を deny に書いても、Claude が cat .env を Bash で叩いたら通る。Bash の方も deny で塞ぐか、サンドボックス機能を使う
• パスのルールが直感と違う。Read(/secrets/**) はファイルシステムの絶対パス /secrets/ ではなく、プロジェクトルートからの相対パスを意味する。本物の絶対パスは // から始める。これは公式が「混乱しやすい」と注意を出している部分
• settings.local.json をチームに展開しようとする。設計上、local は個人専用。チーム全員に同じ設定を配りたい時は project の方に書く

関連するコマンド・ツールへの動線

• /permissions（パーミッションズ） － settings.json の permissions セクションを対話的に編集するスラッシュコマンド
• Hooks（フックス） － settings.json の hooks セクションでフック定義を書く。コミット前 lint などの自動化
• CLAUDE.md（クロード・エムディー） － 「やってほしくないこと」の自然言語ルールは CLAUDE.md、機械的に強制したい許可・禁止は settings.json と使い分け
• Bash（バッシュ） － permissions.allow / deny で Bash(...) ルールを書く対象
• /init（イニット） － プロジェクト初期化時に .claude/ フォルダや雛形が作られる
• Edit（エディット） － Edit(content/**) のような許可・拒否ルールの対象ツール
• Read（リード） － Read(~/secrets/**) で読み取り禁止を書く対象
• Write（ライト） － ファイル作成系の許可ルール対象
• Glob（グロブ） － ルールパターンで使う ** のワイルドカード文法そのもの
• Grep（グレップ） － Read 系の deny ルールが効く対象
• /memory（メモリ） － CLAUDE.md を編集するスラッシュコマンド、settings.json と用途を分ける
• /agents（エージェンツ） － エージェント別の動作上書き
• MCP（エムシーピー） － disabledMcpjsonServers / enabledMcpjsonServers で個別ON/OFF
• /clear（クリア） － 会話履歴のリセット
• /compact（コンパクト） － 会話履歴の要約圧縮
• Skills（スキルズ） － スキル定義、settings.json とは別の .claude/skills/ フォルダ管理

参考リンク

• Claude Code 公式: Settings
• Claude Code 公式: Configure permissions
• Claude Code 公式: Environment variables
• 公式 JSON Schema

書き方

プロジェクトフォルダ直下の `.claude/settings.json` または `.claude/settings.local.json` に JSON で書く。トップレベルの主要キーは `permissions` `env` `hooks` `model` `defaultShell` `cleanupPeriodDays` など

やってみるとこうなる

入力

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": ["Bash(hugo *)", "Bash(npm run lint)"],
    "deny": ["Bash(git push *)", "Read(./.env)"]
  },
  "env": {
    "HUGO_ENV": "dev"
  },
  "model": "claude-sonnet-4-6"
}

出力例

Claude Code を次回起動した時から、`hugo server -D` や `npm run lint` は確認なしで通るようになり、`git push origin main` は実行を止められる。`HUGO_ENV=dev` がセッション中ずっとセットされた状態になり、Hugo が下書き記事を含めてプレビューしてくれる

関連項目

• /permissions（パーミッションズ）
• Hooks（フックス）
• CLAUDE.md
• Bash（バッシュ）
• /init（イニット）
• /memory（メモリ）
• .claude Directory（ドット・クロード・ディレクトリ）
• /fewer-permission-prompts（フューワー・パーミッション・プロンプツ）

公式ドキュメント

https://code.claude.com/docs/en/settings