Claude Codeを使っていると、「このまま承認し続けていいのか」「設定ファイルに何をどう書けばいいのか」と迷う場面が出てきます。Claude Codeの設定は、『許可（permissions）の出し方』と『設定ファイルの置き場所』という2つを押さえれば、安全に任せる範囲を自分で決められるようになります。ただし、保護されたファイルへの書き込みのように、許可のルールに書いても自動では通らない領域もあります。これは事故を防ぐための仕組みです。ここでは、ユーザー・プロジェクト共有・プロジェクトローカルという3つの設定ファイルの違いと、許可の出し方を中心に解説します。
Claude Codeの「設定」とは？許可と設定ファイルの全体像
Claude Codeの「設定」は、大きく2つの要素でできています。ひとつは操作ごとの承認ルールを決める「許可（permissions）」、もうひとつはそのルールを書き込む「設定ファイル」です。この2つを分けて理解すると、毎回出てくる確認画面の意味も、どこに何を書けばいいかも見えてきます。
「設定」が指す2つのこと：許可の範囲と設定ファイルの中身
許可は、Claude Codeがファイルを読んだり書き換えたり、コマンドを実行したりする前に、承認を求めるかどうかを決めるルールです。どの操作が自動で進み、どの操作で確認が出るかは、次の章で説明します。
設定ファイルは、この許可のルールやその他の挙動を書いておく場所です。保存先は用途ごとに分かれていて、自分専用のユーザー設定、チームで共有するプロジェクト設定、自分だけが使うプロジェクトローカル設定の3種類があります（Settings files and precedence）。これとは別に、組織が配布する管理設定もあります。
| 要素 | 役割 |
|---|---|
| 許可（permissions） | どの操作を自動で進め、どの操作で確認を求めるかのルール |
| 設定ファイル | そのルールやその他の挙動を書き込む置き場所 |
この記事で扱うこと・扱わないこと
この記事では、許可がいつ自動で進み、いつ確認が必要になるのかという仕組みと、設定ファイルをどこに置けば自分とチームの設定が混ざらないかという置き場所の考え方に絞って解説します。Claude Codeに読み書きさせるフォルダの切り方や、CLAUDE.mdに書く指示の中身は、それぞれ別の記事で扱います。
許可（permissions）はどう出す？自動で進む操作と確認が必要な操作
作業ディレクトリの中なら、読み取りは自動で進む
ファイルを読むだけの操作は、作業ディレクトリの中であれば承認なしで進みます。作業ディレクトリとは、Claude Codeを起動したフォルダのことです。公式ドキュメントでも、起動したフォルダの中のファイルには、デフォルトでアクセスできると説明されています（Configure permissions）。ファイルの内容を表示したり、特定のコードを探したりする操作は、この読み取りに含まれます。確認画面が出ないぶん、調べものの作業は止まらずに進みます。
書き込み・実行で確認を求められるのが「許可」
一方で、ファイルの書き換えやコマンドの実行は、Manualモード（設定ファイル上の値はdefault）では実行前に確認が求められます。公式ドキュメントでは、操作の種類ごとに次のように整理されています（Configure permissions）。
| 操作 | Manualモードでの確認 |
|---|---|
| ファイルの読み取り・検索 | 不要（作業ディレクトリと、追加したフォルダの中） |
| コマンドの実行 | 必要（組み込みの読み取り専用コマンドを除く） |
| ファイルの編集・作成 | 必要 |
| Webページの取得 | 必要（あらかじめ許可されたドキュメントのドメインを除く） |
| Web検索 | 必要 |
画面に表示される提案の内容を見て、進めてよいかどうかを自分で判断するのが本来の使い方です。
ただし、提案の中身がコードで表示されると、判断のしようがなくなる場合があります。GOROが支援先で行った研修でも、冒頭で、すでにClaude Codeを触っていた参加者がこのつまずきを話していました。
実録支援先の声
提案の中身が分からないまま承認していた参加者
参加者「提案されたものがコードとかだとマジで何言ってんのかわかんなくてなんか［脳死］で承認していくみたいな状態になっていてうん。それがちょっと今つまづいてます。」（文字起こし。誤変換「脳し」を［］で直した）
出典：研修を受けた支援先の参加者の発言（GOROの社内の記録）
研修の講師は、3つの対処を挙げました。1つめは、回答のルールをClaude Codeに指示することです。自分は誰で、どう分かりやすく説明してほしいかを伝えます。2つめは、承認を取らなくてよい作業を設定で決めておくことです。3つめは、CLAUDE.mdに「作業するときは必ず承認を取って」と書いておくことです。CLAUDE.mdの書き方は、CLAUDE.mdの書き方で扱っています。
なお公式ドキュメントでは、CLAUDE.mdの指示はClaudeがしようとすることに影響するものの、Claude Codeが何を許可するかは変えないと説明されています（Configure permissions）。確実に止めたい操作や、必ず確認を出したい操作は、次に説明する許可のルールで指定します。
許可のルールの書き方：allow・ask・deny
承認を取らなくてよい作業や、させたくない作業は、設定ファイルのpermissionsにルールとして書きます。公式ドキュメントによれば、ルールは次の3種類です（Configure permissions）。
| ルール | 働き |
|---|---|
| allow | 指定した操作を、確認なしで進める |
| ask | 指定した操作のたびに、確認を求める |
| deny | 指定した操作をさせない |
ルールは「ツール名(対象)」の形で書きます。公式ドキュメントの例では、npm runで始まるコマンドとgit commitを確認なしで実行させ、git pushで始まるコマンドを拒否しています。
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)"
],
"deny": [
"Bash(git push *)"
]
}
}Bashはコマンドの実行を指し、*は任意の文字列を表します。ファイルの読み取りを止めたいときは、Read(./.env)のように対象のファイルを指定します。
1つの操作が複数のルールに当てはまるときは、deny、ask、allowの順に判定され、最初に当てはまったルールが使われます。そのため、allowで細かく許可していても、同じ操作に当てはまるdenyがあれば拒否されます。今あるルールと、それぞれがどの設定ファイルから来ているかは、Claude Codeで/permissionsを実行すると一覧で確認でき、そこからルールを追加・削除することもできます。
確認の出方をまとめて切り替える「パーミッションモード」
ルールを1つずつ書くのとは別に、セッション全体の確認の出方を決める「パーミッションモード」もあります。公式ドキュメントでは、次の6つが案内されています（Choose a permission mode）。
| モード | 確認なしで進む操作 | 向いている場面 |
|---|---|---|
| default（画面の表示はManual） | 読み取りだけ | すべての操作を自分で確認したい作業 |
| acceptEdits | 読み取り、ファイルの編集、mkdirやmvなどのよく使うファイル操作 | 確認しながら修正を重ねる作業 |
| plan | 読み取り（autoモードが使える環境では、別のモデルが承認したコマンドも）。ソースファイルは編集しない | 変更する前の調査 |
| auto | 原則すべて。コマンドの実行などの前に、別のモデルが依頼内容に沿っているかを確認する | 長い作業、確認の多さを減らしたいとき |
| dontAsk | 作業ディレクトリ内の読み取りと、事前に許可した操作だけ。確認が必要な操作は拒否される | 制限をかけた自動実行やスクリプト |
| bypassPermissions | すべて | 隔離したコンテナや仮想マシンの中だけ |
モードの切り替えは、CLIではShift+Tab、VS Codeでは入力欄の下部にあるモード表示、デスクトップアプリではCodeタブの送信ボタン横にあるモード選択から行います。新しいセッションを始めるモードは、設定ファイルのpermissions.defaultModeで変えられます。公式ドキュメントによれば、Claude Code v2.1.283以降では、ターミナルとVS Codeで始める対話セッションは、組み込みの設定ではautoモードで始まります（autoモードが使えない環境ではManualモード）。確認画面がほとんど出ないと感じたら、まず今のモードを確かめてください。
モードは基本の動きを決めるもので、許可のルールはその上に重ねて使います。denyのルールは、bypassPermissionsを含むすべてのモードで効きます。bypassPermissionsは確認を省いて実行するため、公式は隔離したコンテナや仮想マシンの中だけで使うよう案内しています。
作業ディレクトリの外に広げたいとき
作業ディレクトリは、起動したフォルダの外にも広げられます。起動時の—add-dir、セッション中の/add-dir、設定ファイルのpermissions.additionalDirectoriesのいずれかで追加します。公式ドキュメントによれば、追加したフォルダにも元の作業ディレクトリと同じ許可ルールが適用され、確認なしで読めるようになります。編集の確認は、そのときのパーミッションモードに従います（Configure permissions）。
どこまでフォルダを広げるかは扱う情報の範囲を決めることでもあり、GOROの事例記事（Claude Code未経験だった全部門5名が、4時間の研修から1ヶ月後も毎日使い続けている事例）でも、「この仕事はこのフォルダ」と決めることがそのまま扱う情報の範囲を決めることになると紹介しています。フォルダの切り方は、Claude Codeのフォルダ構成の決め方で扱っています。
設定ファイルはどこに置く？ユーザー・プロジェクト共有・プロジェクトローカルの違い
許可のルールをどう書くかが分かったところで、次はそれをどこに書くかという問題が出てきます。個人やチームが自分で書く設定ファイルは3種類あり、どれに書くかで、ルールが効く人とプロジェクトの範囲が変わります。それぞれ誰のための設定なのかを理解しておくと、自分の好みとチームのルールを混同せずに済みます。
ユーザー設定（~/.claude/settings.json）：自分の全プロジェクトに効く好み
公式ドキュメントでは、個人の設定ファイルは~/.claude/settings.jsonに保存し、開いた全プロジェクトに適用されると説明されています（Example settings files）。~/.claudeは、自分のホームフォルダにある.claudeフォルダのことです。テーマや既定のモデル、自分用の許可ルールといった、個人の好みを書く場所です。このファイルは自分のPCの中にあり、チームメンバーの環境には届きません。そのため、ここに書いた内容は自分以外には影響しません。
プロジェクト共有設定（.claude/settings.json）：チームで揃えるルール
公式ドキュメントでは、チームで共有する設定ファイルは.claude/settings.jsonとしてリポジトリにコミットする想定が例示されています（Example settings files）。プロジェクトのフォルダの中にある.claudeフォルダに置き、gitで共有することで、同じリポジトリを使うメンバー全員に同じ内容が適用されます。チームで揃えておきたい許可のルールは、この場所に書くのが基本です。
ただし、このファイルに書いたallowのルールは、各メンバーがそのフォルダを信頼する（ワークスペースの信頼の確認を承認する）まで適用されません。denyとaskのルールは制限する方向のルールなので、すぐに効きます（Configure permissions）。
プロジェクトローカル設定（.claude/settings.local.json）：自分だけの一時的な上書き
公式ドキュメントでは、このファイルは1つのプロジェクトに対する個人的な上書き、またはチームに共有する前の試用に使うものだと説明されています（Settings files and precedence）。プロジェクト共有設定と同じ.claudeフォルダに置きますが、gitでは共有しません。Claude Codeがこのファイルを作るときは、gitの対象から外す設定も自動で行います。手で作った場合は、自分で.gitignoreに追加します。
CLIの確認画面で「Yes, and don’t ask again」を選んだコマンドの承認も、allowのルールとしてこのファイルに保存されます。チームのルールは変えずに、自分だけ許可を足したいときや、新しいルールを試したいときに使う場所です。
| ファイル | 誰のための設定か | gitでの共有 |
|---|---|---|
| ~/.claude/settings.json | 自分（全プロジェクト共通） | しない |
| .claude/settings.json | チーム全員（このプロジェクト） | する |
| .claude/settings.local.json | 自分だけ（このプロジェクト限定） | しない |
組織による管理設定も別に用意されており、企業での安全管理の考え方はClaude Codeのセキュリティ対策で扱っています。
優先順位と許可リストのマージの仕組み
公式ドキュメントによれば、設定の優先順位は、組織の管理設定、コマンドライン、プロジェクトローカル設定、プロジェクト共有設定、ユーザー設定の順に決まります（Settings files and precedence）。同じ項目が複数のファイルに書かれている場合は、優先順位の高いファイルの内容が使われます。
許可のルールには、この優先順位がそのまま当てはまりません。公式ドキュメントでは、permissions.allowのようなリストの項目は、複数のファイルの内容をまとめて適用すると説明されています（Settings files and precedence）。ユーザー設定のallowと、プロジェクト共有設定のallowは、両方とも有効になります。また、denyはどのファイルに書かれていてもallowより先に判定されるため、ユーザー設定でallowした操作でも、プロジェクト共有設定でdenyしていれば拒否されます（Configure permissions）。
実際どう使い分ける？チームで事故なく運用するための考え方
3種類の設定ファイルがあることは分かっても、実際にどれへ何を書くかで迷う場面があります。ここでは、好みと認証情報という2つの軸で判断する方法を説明します。
個人の好みはユーザー設定、チームの共通ルールはプロジェクト共有設定へ
判断の軸はシンプルです。自分だけが気持ちよく使えればいい内容か、チーム全員が同じ条件で動く必要がある内容かを分けて考えます。
| 書く内容の例 | 置き場所 |
|---|---|
| 自分がよく使う操作を自動で進めたい | ユーザー設定（~/.claude/settings.json） |
| テーマや既定のモデルなどの好み | ユーザー設定（~/.claude/settings.json） |
| プロジェクト全体で確認を必須にしたい操作 | プロジェクト共有設定（.claude/settings.json） |
| 新しいルールをチームに展開する前に試したい | プロジェクトローカル設定（.claude/settings.local.json） |
迷ったときは、「このルールが変わって困る人は自分だけか、それとも他のメンバーもか」を自問すると判断しやすくなります。自分だけならユーザー設定かプロジェクトローカル設定、他のメンバーにも関わるならプロジェクト共有設定です。
認証情報が絡む接続は、gitで共有しないスコープに登録する
好みとルールの区別とは別に、もうひとつ注意が必要な領域があります。外部ツールへの接続（MCP）に使うキーの置き場所です。
公式ドキュメントによれば、MCPサーバーは3つのスコープ（登録範囲）のどれかに登録します（Connect Claude Code to tools via MCP）。
| スコープ | 使えるプロジェクト | チームとの共有 | 保存先 |
|---|---|---|---|
| local（既定） | 登録したプロジェクトだけ | しない | ~/.claude.json |
| project | そのプロジェクト | する（gitで共有） | プロジェクト直下の.mcp.json |
| user | 自分の全プロジェクト | しない | ~/.claude.json |
公式は、バージョン管理に入れたくない認証情報を使うサーバーにはローカルスコープを使うよう案内しています。一方、.mcp.jsonはgitで共有し、チーム全員が同じツールを使うためのファイルです。なお、MCPのローカルスコープの保存先は~/.claude.jsonで、設定ファイルの.claude/settings.local.jsonとは別物です。
チーム全員が同じツールを使えるようにしたい接続は.mcp.jsonへ、個人のキーが必要な接続はローカルスコープかユーザースコープへ、という分け方になります。
GOROの例：有料ツールのMCPキーは、本人が自分のターミナルで登録する
GOROの社内の作業記録には、有料ツールのMCPを登録したときの手順が次のように残っています。
実録GOROの作業記録
有料ツールのMCPキーはgitで共有しない
キーはgit管理の
.mcp.jsonに入れず、旭が自分のターミナルでclaude mcp add --transport http ahrefs <URL> --header "Authorization: Bearer <key>" -s userを実行する。出典：GOROの社内の作業記録
-s userは、ユーザースコープの指定です。認証情報をバージョン管理に入れないという点で、公式の案内と同じ考え方です。チームにClaude Codeを展開するときも、キーが必要な接続は各自が自分の環境で登録すると最初に決めておけば、キーが.mcp.jsonに紛れ込むのを防げます。
設定でつまずきやすいポイントと対処法
ここまでの使い分けを覚えても、実際に手を動かすと止まる場面が出てきます。止まる理由が分かっていれば、慌てずに対処できます。
保護されたファイルへの書き込みは、許可リストに書いても自動では通らない
Claude Codeには、書き込みが自動では承認されない「保護されたパス」があります。公式ドキュメントでは、.git、.claude（Claude自身の作業用の一部を除く）、.vscodeなどのフォルダや、.gitconfig、.zshrc、.mcp.json、.claude.jsonなどのファイルが挙げられています（Choose a permission mode）。
公式ドキュメントによれば、保護されたパスへの書き込みは、bypassPermissionsモードなど一部の例外を除いて自動では承認されません。主なモードでの扱いは次のとおりです。
| モード | 保護されたパスへの書き込み |
|---|---|
| default（Manual）、acceptEdits | 毎回確認が出る |
| auto | 別のモデルの判定に回る |
| dontAsk | 拒否される |
| bypassPermissions | 許可される |
さらに、この安全確認は設定ファイルのallowのルールより先に実行されるため、allowに書いても事前承認はできません。公式はこの仕組みを、リポジトリの状態やClaude Code自身の設定が誤って壊れることを防ぐためのものだと説明しています。
保護された場所への書き込みで確認が出ても、設定の書き方の誤りとは限りません。何を書き換えようとしているかを読んでから判断します。
無効化されたMCPは/mcpで有効にする
外部ツールへの接続でも、似たつまずきが起きます。プロジェクトを開いたときに、以前使えていたMCPの接続が動かなくなっている場合です。
原因の1つは、そのMCPサーバーがプロジェクト単位で無効になっていることです。公式ドキュメントによれば、/mcpのパネルでサーバーをオフにすると、その選択はプロジェクトごとに~/.claude.jsonのdisabledMcpServersに記録されます。この状態のサーバーはclaude mcp listで「Disabled for this project (re-enable via /mcp)」と表示され、/mcpのパネルから再び有効にします（Connect Claude Code to tools via MCP）。
| つまずき | 原因 | 対処 |
|---|---|---|
| 保護された場所への書き込みで毎回確認が出る | 安全確認が許可のルールより先に働く仕組み | 許可のルールでは回避できない。確認内容を見て判断する |
| 使えていたMCPが動かない | プロジェクト単位で無効になっている | /mcpを開いて有効にする |
GOROの例：無効になっていたMCPを有効にした
GOROの社内の作業では、MCPの接続で止まった場面がありました。マネフォ クラウド会計の公式MCPを、Claude CodeのCLIで使えるようにしようとしたときのことです。
実録GOROの作業記録
無効になっていたMCPは、/mcpで有効にする必要があった
CLI側は
~/.claude.jsonのdisabledMcpServersに mf-accounting が入っていて「Disabled for this project」。ターミナルの /mcp で Enable が必要（Claudeによる直接編集は自動ブロックされる）出典：GOROの社内の作業記録
どちらも、先に進めるには人の明示の指示や操作が必要でした。確認画面が出たときは、何を許可しようとしているかを一度読んでから、必要な指示を出す流れに慣れておくと、チームに展開したあとも同じ判断基準で運用できます。
この記事と合わせて読みたい
- Claude Codeのフォルダ構成の決め方とは？非エンジニア向けに業務単位での切り方を解説 — 許可と設定ファイルの置き場所が分かったら、次は作業範囲そのものを決めるフォルダの切り方を知りたくなるため
- CLAUDE.mdの書き方とは？非エンジニアが最初に書くべき内容と注意点を解説 — 承認ルールを自分で決めたいと思ったとき、CLAUDE.mdに具体的に何を書けばよいかを知りたくなるため
- Claude Codeのセキュリティは大丈夫？法人導入前に知るべき安全性と対策を非エンジニア向けに解説 — 許可や設定ファイルの仕組みを理解した上で、法人導入の際のセキュリティ全体像を確認したくなるため
Claude Codeを自分の業務で試したい方へ
Claude Code マンツーマン講座は、オンラインで1対1で進める回数制の講座です。毎回、受講者の実際の業務を題材にして、作ったものを受講者のPCに残していきます。何回受けるかは、無料相談で業務の内容を伺ってから決めます。チームで導入する場合は、Claude Code法人研修をご覧ください。
