このコースでは、2〜10人ほどのチームでClaude Codeを使い始めるときに、最初に整えておくべきことを順番に扱います。設定の共有から、並行作業の混ぜない進め方、GitHub Actionsでの自動化、レビューとコストの運用まで。今回はその一番手前、設定の置き場所です。
同じリポジトリで、同じタスクを頼んでいるはずなのに、AさんのClaudeとBさんのClaudeで動きが違う。片方は毎回コマンドの実行前に止まって確認を求め、もう片方は同じコマンドを確認なしで通してしまう。片方はCLAUDE.mdに書いたチームのルールに従うのに、もう片方はまるで初めて開いたリポジトリのように振る舞う。
こういうことが起きる原因の多くは、Claude Codeの設定がリポジトリの中ではなく、各自のマシンだけに置かれていることです。設定はいくつかの場所に分かれて存在します。リポジトリに置いてGitで管理すればチーム全員に効くものと、個人のマシンにだけ置かれ、他の人には影響しないものです。この違いを最初に押さえておくと、あとから「なぜか動きが揃わない」を減らせます。
何を共有し、何を個人用に残すか
Claude Codeが読みに行く設定ファイルには、リポジトリの中に置くものと、個人のマシンに置くものの2種類があります。前者はGitにコミットすればクローンした全員に届き、後者はそのマシンでしか効きません。
まずコミットして共有する側です。
チーム共通のルール。技術スタック・命名規則・落とし穴などを書いておく場所。リポジトリのルートに置く
権限ルール・フック・環境変数などチーム共通の設定。全員が同じ権限とフックで動くための土台
チームで使うMCPサーバーの接続先を定義するファイル。社内システムや外部サービスへのつなぎ先を全員に配る
特定の作業向けに定義したサブエージェント。チームで改善しながら育てる前提のファイル
決まった手順をまとめたSKILL.md。議事録の形式やレビューの手順など、繰り返す作業を書いておく
よく使う指示をスラッシュコマンドとして登録したもの
特定のファイルを触るときだけ効く条件付きのルール。詳しくは用語辞典で扱う
これらはコードと同じ扱いにして、Gitにチェックインします。誰かが手直ししたら、他のファイルと同じようにPull Requestでレビューすればいいということです。.claude/rules/の書き方は、用語辞典のrulesとAGENTS.mdの使い分けにまとめてあります。
一方、個人用に残すべきものもあります。
そのプロジェクトでの自分だけの上書き設定。チーム共通のルールに、自分の権限だけ緩めたり厳しくしたりできる
ホームディレクトリに置く個人設定。このマシンで開くすべてのプロジェクトに効く。リポジトリの外にあるので、そもそも共有の対象ではない
“Commit `.claude/settings.json` so everyone who clones the repository gets the same permissions, hooks, and plugins. Each teammate can still override it for themselves in their own `.claude/settings.local.json`, so personal exceptions don't need a commit.”
筆者訳`.claude/settings.json` はコミットしておくこと。そうすればリポジトリをクローンした全員が同じ権限・フック・プラグインを得られる。各メンバーは自分の `.claude/settings.local.json` でそれを上書きできるので、個人的な例外はコミットしなくていい。
考え方はシンプルです。チームで揃えたい判断はリポジトリに書き、個人の好みや例外は個人の設定に逃がす。これができていれば、新しいメンバーが加わったときも、クローンした時点でチームの標準がそのまま手に入ります。
settings.local.jsonは、書いた瞬間にgitignore扱いになる
.claude/settings.local.json について、ひとつ覚えておくと安心な挙動があります。
このファイルは、自分で手を加えて先に作らない限り、Claude Code自身が最初に書き込んだ時点で自動的にgitignore相当の扱いになります。具体的には、そのリポジトリがまだこのファイルを無視していない場合、Claude Codeはグローバルなgit excludesファイルに **/.claude/settings.local.json を追記します。つまり、何もしなくても、うっかりコミットしてしまう事故は起きにくい作りになっています。
補足
手で先に作った場合だけ注意
自分の手で .claude/settings.local.json を作ってから、Claude Codeがまだ一度も書き込んでいない場合は話が別です。この場合は自動では無視されないので、リポジトリの .gitignore に自分で追記しておく必要があります。迷ったら、.gitignore に一行足しておけば確実です。
設定の優先順位そのもの、つまりどのファイルがどのファイルより強いかという細かい仕組みは、このレッスンでは扱いません。深く知りたくなったら、用語辞典の設定ファイルの優先順位にまとめてあります。
新しいメンバーが参加したときに起きること
リポジトリを共有する設計にしておくと、新しいメンバーが加わったときの流れはこうなります。
リポジトリをクローン
CLAUDE.md・settings.json・.mcp.jsonが手元に届く
そのフォルダでClaude Codeを起動
初回は「このフォルダを信頼するか」の確認が出る
.mcp.jsonの承認
プロジェクト共有のMCPサーバーごとに、使う前に一度確認が入る
共有ルールが反映される
CLAUDE.mdと権限ルールがチーム全員と同じ状態になる
ここで戸惑いやすいのが3番目です。.mcp.json に書かれたMCPサーバー（社内システムや外部サービスとClaude Codeをつなぐ設定。詳しくは用語辞典のMCP）は、対話セッションで最初に使おうとしたタイミングで、承認を求めるプロンプトが出ます。これは壊れているのではなく、セキュリティ上の理由でそう作られています。クローンしてきたリポジトリが、自分の .mcp.json に書かれたサーバーを勝手に自動承認できてしまうと、リポジトリの中身次第でどんな接続でも無条件に許可されることになってしまうからです。
注意
承認が出ないときは「信頼」が先
.mcp.json の承認プロンプトが出ない、あるいはサーバーが「承認待ち」のまま動かないときは、たいていフォルダの信頼そのものがまだ済んでいません。まずそのフォルダでClaude Codeを起動し、ワークスペースを信頼するかどうかの確認に答えてから、MCPサーバーの承認に進みます。
一度承認したかどうかの記録をリセットしたい場合は、claude mcp reset-project-choices を実行すれば、そのプロジェクトの承認選択を初期状態に戻せます。設定を変えて動作確認したいときに使える手段として覚えておいてください。
更新の担当と見直しの頻度を決める
CLAUDE.mdや.claude/settings.jsonはコードと同じように、コミットしたら終わりではありません。Claude Code公式のガイドも、CLAUDE.mdはGitにチェックインしてチームで手を入れながら、時間をかけて育てていくものだと述べています。放っておくと、書いた当時の前提と実際の運用がずれていきます。
チームで決めておくとよいのは、次の3つです。
誰が変更をPull Requestとして出すか。持ち回りでも、1人の担当固定でもよい。担当を決めないと誰も直さないまま古くなる
新しいメンバーが入ったとき、運用でつまずきが出たとき、月次の棚卸しのときなど、見直す機会を先に決めておく
CLAUDE.mdは書き足すほど毎回のセッションが重くなる。行数が増えてきたら削る前提で運用する
見直しの場では、内容を足すことよりも削ることを優先してください。読めば分かることや、標準的な作法は書かなくていい対象です。チームの判断が必要な部分だけを残す、という基準で棚卸しすると、CLAUDE.mdは長く生き続けます。
今日のまとめ
3行で振り返ります。
- リポジトリに置く設定（CLAUDE.md・settings.json・.mcp.json・agents/skills/commands/rules）は共有し、個人用の設定（settings.local.json・~/.claude）は個人のマシンに残す
.mcp.jsonの承認プロンプトとワークスペースの信頼確認は、壊れているのではなく安全のための標準動作- 設定は書いたら終わりではなく、更新担当と見直しのタイミングを先に決めておく
次のレッスンでは、複数人が同じリポジトリで同時に作業するとき、ファイルの衝突をどう避けるかを扱います。worktreeという仕組みを使って、並行作業を混ぜない進め方を見ていきます。
セルフチェック
1. チームで共有すべき設定として正しいのはどれですか。
2. .claude/settings.local.json について正しい説明はどれですか。
3. 新しいメンバーがリポジトリをクローンし、Claude Codeを起動したとき、.mcp.jsonのMCPサーバーで起きることは何ですか。