Claude Codeをチームで使う設定の置き場所と権限設計の基本

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

チーム展開でつまずく設定の置き場所

Claude Code を一人で使い込むと、自分用のメモを書いた CLAUDE.md や、許可するコマンドをまとめた settings.json が手元に育っていきます。問題は、その個人用の便利設定をそのままチームに配り始めたときです。

各自が自前のファイルを別々に持つと、出てくる答えの質も揃わず、安全のラインもバラバラになります。誰かが危険なコマンドを許可していたり、CI 設定や秘密ファイルを勝手に書き換えられたりする事故が、いちばん怖いところです。

この記事は、その不安を次の4つの判断軸に分けて答えていきます。

読み進める順番は、個人の手元 → チームでの共有 → 法人での強制、と段階を上げていきます。まずは自分一人の設定を整理し、次にそれをチームに配れる形へ、最後に会社として外せないルールへと広げていく流れです。

CLAUDE.mdとsettings.jsonの役割分担

チーム運用でまず線引きしておきたいのが、CLAUDE.md と settings.json の役割の違いです。名前が似ているうえ同じ .claude/ 配下に置けるので混同しがちですが、担当する仕事はまったく別物です。

CLAUDE.md は Claude が起動時に読み込む「指示とコンテキスト」を書くファイルです。公式ドキュメントでは Memory(メモリ)と呼ばれ、チームの作法やプロジェクトの前提をまとめた「プレイブック」として扱われます。コーディング規約、よく使う手順、避けてほしいこと、用語の定義など、人間が日本語や英語の文章で書く内容がここに入ります。

一方の settings.json は Claude Code の動作そのものを決める「設定」です。公式の settings リファレンスでは、このファイルが許可・拒否のルール(permissions)、環境変数(env)、自動実行のフック(hooks)を保持すると定義されています。つまり「何を読ませ、どう振る舞わせたいか」を文章で伝えるのが CLAUDE.md、「何を許し、何を禁じるか」を機械的なキーで定めるのが settings.json です。

迷ったときは、書きたい内容がどちらの形式かで振り分けると間違えません。下の対応をおさえておけば十分です。

なお CLAUDE.md は @パス の記法で別ファイルを読み込んで分割でき、共通のプレイブックを部品として共有しやすくなっています。役割さえ掴めれば、次に問題になるのは「同じ CLAUDE.md と settings.json を、チーム全員で共有する分と個人だけに残す分でどう置き分けるか」です。これは続く2つの章で順に見ていきます。

①CLAUDE.mdに書くチームの前提

プロジェクト直下に置く CLAUDE.md は、リポジトリに commit してチーム全員で共有するプレイブックです。コーディング規約や命名、レビューの約束といったチームの前提を言語化してここに置きます。

気をつけたいのは、各メンバーが自分の端末に持つ個人用の設定ファイルは、他のメンバーには共有されないという前提です。手元だけにある前提に頼って書くと、他の人の環境では意味が通らなくなります。

そのため共有用の CLAUDE.md は、単体で読んで分かる状態にします。ビルドやテストの実行コマンド、触ってはいけないファイル、守ってほしい書き方の決まりを、外部の前提なしで書き切ります。

内容が増えてきたら、@パス の記法で別ファイルを読み込ませて分割できます。共通のプレイブックをテーマごとのファイルに分け、CLAUDE.md から参照すれば、肥大化を防ぎつつ全員に同じ前提を配れます。

チームでよく使う指示の型をまとめておくと、新しいメンバーの立ち上がりが早くなります。定型を整理する考え方は、後ほど候補として案内する関連記事も参考にしてください。

②settings.jsonとprojectとuserの置き分け

settings.json は、ツールの使用許可(permission)、環境変数(env)、フックの設定(hooks)をまとめておくファイルです。CLAUDE.md がチームの「やり方」を書くメモなら、settings.json は「何を許すか・どう動かすか」を決める設定ファイルだと考えると線引きしやすくなります。

置き場所は2つに分かれます。プロジェクト直下の .claude/settings.json は commit してチーム全員で共有するもので、ここに書いた設定はリポジトリを clone した全員に同じく適用されます。一方の ~/.claude/settings.json は各自のホームにある個人用で、commit されず本人の環境にだけ効きます。

複数の場所に同じ設定があると、どれが優先されるかが気になります。Claude Code は優先度の高い順に次の4階層で設定を読み、上の層が下の層を上書きします。

この並びが意味するのは、commit したプロジェクト設定がチームの「最低ライン」になるということです。個人の ~/.claude/settings.json でゆるく許可しても、プロジェクト側の設定が上にあるため、チームで決めたガードレールが各自の手元設定で勝手に崩れません。

逆に、自分の環境だけで一時的に挙動を変えたいときは .claude/settings.local.json を使います。これは gitignore されるので他の人には共有されず、個人の上書きとして安全に分けられます。法人の管理設定はさらにその上に立ち、組織として強制したい最低ラインを個人任せにしない仕組みになっています。

触らせないファイルを決める権限設計

Claude Codeにどのファイルを編集させるかは、settings.jsonのpermissionsで決めます。ルールはdeny(禁止)・ask(確認)・allow(許可)の3種類で、評価はdeny→ask→allowの順に進み、最初に一致したルールがその場で採用されます。さらにdenyは常に優先されるため、同じ操作にallowとdenyが両方当たっていても、編集は確実に止まります。つまり「触らせたくないものをdenyに書いておけば、後から許可ルールを足しても守りが崩れない」という安心できる設計になっています。

この仕組みを使った「触らせないファイル設計」は、難しく考える必要はありません。事故が起きると痛いファイル、たとえばCI設定・デプロイ用のマニフェスト・APIキーなどの秘密ファイルを思い浮かべて、それらをまとめてEditのdenyに入れるだけです。ファイルパターンで指定できるので、1行ずつ列挙しなくても、ディレクトリやファイル名のまとまりで一括して守れます。

最小の例として、デプロイ設定と秘密ファイルの編集だけを止めるなら、project側の.claude/settings.jsonにこう書きます。

{
  "permissions": {
    "deny": [
      "Edit(.github/workflows/**)",
      "Edit(deploy/**)",
      "Edit(**/.env*)"
    ]
  }
}

これでチームの誰が使っても、CIワークフロー・デプロイ配下・環境変数ファイルへの編集はdenyで弾かれます。読み取りや他のファイルの編集はこれまで通りなので、作業の自由度はほとんど下げずに、壊れたら困る一点だけを固定できます。守りたいファイルが増えたらdenyの行を足していけばよく、まずは秘密ファイルとデプロイ設定の2系統から始めれば十分です。

チームに配る.claude/配下の中身

チーム展開の最後のピースは「結局、何を配ればいいのか」です。答えはシンプルで、プロジェクト直下の .claude/ 一式と .mcp.json、そして CLAUDE.md を git に commit して全員で共有します。

commit して共有する中身は次の通りです。これらを揃えるだけで、チーム全員が同じガードレールと同じツールの上で作業を始められます。

逆に、個人だけの上書きは共有しません。.claude/settings.local.json は gitignore に入れて手元だけに留め、ユーザー全体の ~/.claude/ も各自の好みとして残します。「全員に効かせたいもの=commit」「自分だけのもの=local かユーザー設定」という線引きを徹底すると、個人の都合がチーム全体に漏れません。

git worktreeで並行作業を分ける

複数の作業を1つの作業ディレクトリで同時に進めると、ブランチを切り替えるたびに未保存の変更や生成物がぶつかり、思わぬ事故につながります。

こうした衝突を避ける一般的なやり方が git worktree です。同じリポジトリから複数のブランチを別々のディレクトリへ取り出せるため、作業を物理的に分けられます。

例えば、一方のディレクトリで自動化された処理を走らせながら、もう一方で別の機能を自分で編集する、といった並行作業がそれぞれ独立した状態で進みます。

作業が終わったブランチのディレクトリは、git worktree remove で片付けます。チームで同じリポジトリを共有していても、各自のディレクトリ構成は手元の事情に合わせて使えます。

法人で最低ラインを強制する組織管理

ここまでは個人とチームの設定を扱ってきましたが、法人で導入するなら最低ラインを個人任せにせず、組織側から強制したい場面が出てきます。Claude Code には、その強制を支える組織管理の仕組みが用意されています。

まず入口はシングルサインオン(SSO)です。会社のID基盤でログインを束ね、誰がアクセスできるかを組織側で管理します。さらに forceLoginOrgUUID を指定すると、許可した組織に所属するアカウントでしか使えないよう、組織への所属そのものを強制できます。

設定面では、サーバー側で管理する設定(server-managed settings)を配布できます。配布経路はMDM・グループポリシー・Intune・Jamfで、これらで配った設定はプロジェクトや個人の設定より優先されます。つまり組織の最低ラインを手元で緩めることはできません。

コンプライアンス面では、執筆時点ではSOC 2 Type 2とISO 27001の認証取得が示されており、監査や情報セキュリティの説明資料として使えます。導入後にチーム全員の習熟度を底上げしたい場合は、後ほど案内する学習リソースもあわせて検討してください。

チーム運用でよくある疑問

置き場所と権限設計のまとめ

設定をどこに置くかは、4つの判断軸で整理できます。役割で分けるなら、CLAUDE.md はチームのプレイブック、settings.json は権限や環境変数を持つ設定です。

残りの3つも合わせて、本記事の要点を振り返ります。

最初の一歩は、個人→チーム→法人の順で考えると迷いません。まずは自分のリポジトリで CLAUDE.md と、最小の deny ルールを入れた .claude/settings.json を commit してみてください。

この2ファイルが揃えば、チーム共有も組織での強制も同じ延長線で進められます。今日の commit から、揃った運用への土台づくりを始めましょう。