Claude Codeのセキュリティ設定ガイド：settings.jsonを実際に書き換える手順

Claude Codeのセキュリティ設定、まず何から手をつければいいか

設定ファイルには何段階かの層があり、優先順位を先に把握してから上の層に近い側から触っていくのが遠回りにならない。個人開発者であれば、まずは自分の端末とプロジェクトに関わる層だけを見ておけば十分で、法人・企業のチーム全体に関わる層は後半で扱う。

Claude Codeの設定は次の4層に分かれている。下にいくほど個人の裁量が大きく、上にいくほど強制力が強い。

レイヤー	主な用途	個人で編集するか	配置例（目安）
組織管理設定（managed settings）	会社・組織全体に強制する制限	編集不可、IT管理者が配布	macOS: `/Library/Application Support/ClaudeCode/managed-settings.json`、Linux: `/etc/claude-code/managed-settings.json` など
プロジェクト共有設定	チームでリポジトリと一緒に共有する制限	編集する（Gitで管理）	`.claude/settings.json`
プロジェクトローカル設定	自分専用の一時的な上書き	編集する（Git管理外）	`.claude/settings.local.json`
ユーザー設定	端末全体で使う個人の既定値	編集する	`~/.claude/settings.json`

優先順位は「組織管理設定 > プロジェクトローカル設定 > プロジェクト共有設定 > ユーザー設定」の順で、上の層が下の層を上書きする。OSごとの正確な配置パスやバージョンによる差分は変わることがあるため、実際に触る前に手元の環境で claude --help や公式ドキュメントの表記を確認しておくと迷わない。

以降のH2-2からH2-8は、この4層のどこを触っているかを示しながら進める。読み終えたときに、この地図のどこを自分が触ったかを説明できる状態を目指す。

機密ファイルをClaude Codeに読ませないためには

読ませたくないファイルやディレクトリは、permissions.deny に Read() パターンを追加して明示的に拒否するのが基本の対処だ。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Read(./**/*.pem)"
    ]
  }
}

環境変数ファイルや鍵ファイルなど、うっかり読まれると困るものを列挙する形で書く。プロジェクト全員に適用したい拒否ルールは、4層のうち共有設定にあたる .claude/settings.json（配置や優先順位の全体像はsettings.jsonの全体像を扱った記事を参照）に、自分の端末だけの個人的な拒否ルール（ローカルにしか存在しないシークレットなど）は .claude/settings.local.json に分けて書くと、Gitにコミットする範囲を誤らずに済む。

危険なコマンドを実行前に止めるには（permissions設定）

permissions には allow・deny・ask という3種類の配列があり、コマンドやツールを許可・拒否・都度確認のいずれかに振り分けられる。同じ対象が複数のルールに一致した場合は deny が常に優先される。

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Bash(npm run build:*)"
    ],
    "ask": [
      "Bash(git push:*)"
    ],
    "deny": [
      "Bash(curl:*)",
      "Bash(rm -rf:*)"
    ]
  }
}

ワイルドカードは範囲を狭く書くほど安全だ。たとえば Bash(npm:*) と書くと npm publish のような意図しないサブコマンドまで許可してしまうため、Bash(npm run test:*) のように実行したいスクリプト単位まで絞り込む方が事故を防ぎやすい。どこまで自動化し、どこから人間の確認に戻すかという判断軸は、操作ルールの考え方を扱った記事で詳しく扱っている。

実行環境そのものを隔離するには（サンドボックス）

コマンド実行そのものをOSレベルの隔離環境で囲み、ファイルシステムやネットワークへのアクセス範囲を制限する仕組みがサンドボックス機能だ。

サンドボックスとは、実行中のプログラムがアクセスできる範囲をOSの機能であらかじめ制限しておく仕組みのことで、macOSではSeatbelt、Linuxではbubblewrapのような技術が使われる。Claude CodeのBashツール実行をこの仕組みで囲むことで、想定外のディレクトリへの書き込みや外部ネットワークへの通信を、コマンド単位のルール設定に頼らずに防げる場面が増える。有効化のための設定キーやCLIオプションの正確な表記はバージョンによって変わることがあるため、設定する直前に claude --help や公式ドキュメントの最新表記を確認してから書き換えたい。サンドボックス以外にコンテナやVMも含めた隔離方法まで比較したい場合は、Dockerを使った隔離実行の比較記事で比較している。

bypassPermissionsはいつ使ってよいのか

bypassPermissions はすべての確認をスキップするモードで、日常の開発機ではまず使わず、使い捨てのコンテナやCI環境のように隔離が別途確保されている場面に限って検討したい。

このモードを有効にすると、permissions の ask や deny が機能しなくなり、破壊的なコマンドを事前に止める仕組みそのものが働かなくなる。「毎回の確認が面倒だから」という理由だけで常用のプロジェクトに設定すると、意図しないファイル削除や外部への送信を止める手段がなくなる。代替として、頻繁に使う安全なコマンドは allow に登録しておき、リスクのある操作だけを ask に残すという運用のほうが、確認の手間を減らしつつ止める仕組みを残せる。

MCPサーバーやフック、プラグインを追加するとき何を確認すべきか

拡張機能を追加したときは、まずその拡張機能が呼び出すツールを permissions.allow に1行加え、動作を確認するところから始めるとよい。

MCP（Model Context Protocol、外部サービスとClaude Codeをつなぐ拡張の仕組み）のツールは mcp__<サーバー名>__<ツール名> という形式で権限ルールに指定できる。

{
  "permissions": {
    "allow": ["mcp__github__create_issue"]
  }
}

追加したサーバーが想定外のツールまで公開していないか、この1行を書いた時点で一度動作を試して確認する。レビュー体制や信頼できるMCPサーバーの見分け方といったガバナンス寄りの論点はこの記事の範囲外だが、MCP・フック・プラグインそれぞれの仕組み自体はMCPの仕組みを扱った記事、フックの仕組みを扱った記事、プラグインの仕組みを扱った記事で個別に解説している。

設定した内容が本当に効いているか、どう確認する

Claude Codeのセッション内で /permissions を実行すると、現在有効になっているallow・deny・askのルール一覧をその場で確認できる。

設定ファイルを書き換えただけでは反映されているかどうかが分かりにくいため、次の手順で確認するとよい。

settings.json や settings.local.json を保存する
一度セッションを終了し、再度Claude Codeを起動し直す
/permissions を実行し、追加・削除したルールが一覧に出ているか確かめる
実際にdeny指定したコマンドやファイル読み込みを試し、意図どおり止まるか確認する

インストール自体の状態を確認したい場合は /doctor のような診断コマンドが用意されているので、あわせて確認しておくと、設定ミスなのか環境側の問題なのかを切り分けやすい。設定した気になって終わらせないための最後の一歩として、この確認作業までを一連の手順に含めておく。

チームで同じ設定を全員に配るにはどうする

個人のsettings.jsonをメンバーごとに配るのではなく、IT管理者がMDM（端末管理システム）などを使って managed-settings.json を配布する方法を使うと、メンバー全員に同じ制限を強制できる。

プロジェクト共有設定やユーザー設定は、あくまで個人が自分の端末上で上書きできる設定であり、うっかり緩めてしまう余地が残る。管理設定はこの優先順位の一番上に位置するため、個々のメンバーが手元で変更しても上書きされない。配布経路の設計や、どこまでを組織として強制すべきかは組織設計そのものに関わる論点であり、この記事の範囲を超える。その判断は企業向けのセキュリティガイドに譲る。

まとめ：設定を終えたら次に何をすべきか

ここまでの手順を一通り実行していれば、次のチェックリストがすべて自分の言葉で説明できる状態になっているはずだ。

自分の環境の設定ファイルが4層のどこにあり、どの優先順位で読まれるか説明できる
読ませたくないファイルを permissions.deny の Read() パターンで拒否できている
よく使うコマンドをallowに、確認したいコマンドをaskに、危険なコマンドをdenyに振り分けている
サンドボックスを使うかどうかを、隔離の必要性に応じて判断できる
bypassPermissions を常用していない、または使う場面を隔離環境に限定できている
追加したMCPサーバーやフックの許可設定を1行単位で把握している
/permissions などで設定が反映されているかを実際に確認した
チーム展開が必要な場合、個人設定と管理設定の違いを説明できる

ここまでの設定は、この記事の手順だけで自分の手で完了できる内容になっている。ただし、Claude Code自体は継続的にアップデートされるため、設定や運用の見直しも一度きりでは終わらない。そうした継続的な学びを続けたい場合の選択肢として、月額1,980円から参加できる学習コミュニティ「AI駆動ラボ」がある。自分の手で設定や運用を確かめながら学び続けるための場だ。