Claude Codeのチーム設定共有｜属人化を資産に変えよう

「Claude Codeの設定をチームで共有するにはどうすればいいの？」
「メンバーごとに使い方がバラバラなのを揃えたい！」

Claude Codeを個人で使い込むほど、CLAUDE.mdやSkillsが自分の環境にだけ育っていきます。
その状態でチームに広げようとすると、同じものを全員が作り直すことになるんですよね。

結論から言うと、リポジトリに置いて共有できるものと、プラグインにしないと配れないものの線引きが先でした。
この記事では共有の手順から、配ったものが形骸化しないための運用までをまとめています。

Claude Codeのチーム設定共有で何が変わるか

Claude Codeのチーム設定を共有すると、いちばん変わるのは出力の揃い方です。

ここでは、共有する前と後で何が違うのかを見ていきます。

属人化した設定が生んでいる差

同じチームなのに、Aさんの出力だけレビューがすんなり通る。

こういうことが起きるとき、たいていはプロンプトの上手さではなくCLAUDE.mdに書いてある前提の差でした。

命名規則、テストの書き方、コミットメッセージの形式。この辺りが書かれているかどうかで、出てくるコードが変わります。本人の腕前ではなく、渡している前提の量が違うだけなんですよね。

逆に言えば、そこを揃えるだけで全員の初速が上がるということです。私が関わったチームでは、CLAUDE.mdをリポジトリに置いた翌週から、レビューで指摘する内容が明らかに減りました。

オンボーディングの短縮にも効きました。新メンバーが最初の1週間で聞いてくる質問の多くは、CLAUDE.mdに書いてあれば本人が自分で解決できる種類のものだからです。

読めばわかる形になっているので、口頭で伝えていた暗黙のルールが減っていきます。
教える側の負担が下がるぶん、レビューのような本来見るべきところに時間を回せますよ。

共有できるものと、できないものの線引き

ここを先に押さえておかないと、置いたのに効かないという事故が起きます。

リポジトリの .claude/ に置けば全部共有できる、というわけではありませんでした。

とくに引っかかるのが、--add-dir で足したディレクトリの扱いです。

ファイルは読めるようになりますが、そこの .claude/ にある設定の大半は読み込まれません。

SkillsとサブエージェントとCLAUDE.mdは例外的に読まれますが、フックやその他の設定は対象外でした。
「隣のリポジトリを足したのにルールが効かない」の正体は、たいていこれです。

Claude Codeの設定をリポジトリで共有する手順

まずは1つのリポジトリの中で共有するところから始めます。

プラグインを作らなくても、ここまでで十分に効果が出ますよ。

【ステップ1】CLAUDE.mdをコミットする

いちばん手軽で、いちばん効きます。

プロジェクトルートに CLAUDE.md を置いてコミットするだけで、全員のセッションで自動的に読み込まれます。

プロジェクトルート/
├── CLAUDE.md          ← コミットする（全員に届く）
└── .claude/
    └── settings.json  ← コミットする（チーム共通の設定）

まだ書いていないなら、/init を実行すると下書きを作ってくれます。

そこから不要な部分を削るほうが、ゼロから書くより早いです。

気をつけたいのは分量で、公式ドキュメントでは200行以下に保つことが推奨されています。
書き方の詳細はClaude Code CLAUDE.mdの書き方にまとめました。

【ステップ2】settings.jsonを共有用と個人用に分ける

設定ファイルは2つに分かれます。

この使い分けを最初に決めておくと、あとで揉めません。

共有側には、禁止事項と全員に守ってほしい設定を書きます。

{
  "permissions": {
    "deny": [
      "Read(//**/.env)",
      "Bash(git push origin main)"
    ],
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint *)"
    ]
  }
}

個人用のほうは .gitignore に入れておきましょう。

初回起動時に信頼を確認するダイアログが出るので、そこで承認してもらう必要があります。
リポジトリが勝手に権限を広げられないようになっている、と考えると納得しやすいですね。

【ステップ3】Skillsとサブエージェントを置く

手順が長いものは、CLAUDE.mdではなくSkillsに置きます。

呼ばれたときだけ読み込まれるので、普段のコンテキストを圧迫しません。

.claude/
├── skills/
│   └── deploy-check/
│       └── SKILL.md
└── agents/
    └── reviewer.md

この2つをコミットしておけば、pullした人はすぐ同じものを使えます。誰かが改善したSkillも、次のpullで全員に届く形になりますよね。

作り方はClaude Code Skillsの使い方とClaude Codeのカスタムエージェントの作り方にまとめてあります。

数が増えてきたら、CLAUDE.mdにSkillの一覧を書いておくのがおすすめです。
存在を知らないまま同じものを作ってしまう、という無駄が減りますよ。

Claude Codeのプラグインでチームに配る方法

リポジトリが1つなら、ここまでの共有で足ります。

2つ目のリポジトリで同じものが欲しくなったら、プラグイン化の出番です。

プラグインにする判断基準

判断はシンプルで、置き場所が2つ以上に増えたらプラグインです。

1リポジトリなら .claude/ のままで困りません。

ところが2つ目でコピーした瞬間から、片方だけ直された状態が始まります。

プラグインにすると、スキル名に接頭辞が付きます。

/deploy-check ではなく /my-plugin:deploy-check という呼び方になるわけですね。

少し長くなりますが、これは他のプラグインと名前がぶつからないための仕組みです。
短い名前で呼びたいものだけ .claude/ に残す、という併用もできます。

プラグインの最小構成

プラグインといっても、必要なのはマニフェスト1枚だけでした。

既存の .claude/ からの移行も、フォルダをまるごとコピーするだけで済みます。commands/・agents/・skills/ はそのままの形で持っていけるので、書き直しは発生しません。

my-plugin/
├── .claude-plugin/
│   └── plugin.json    ← これだけが .claude-plugin/ の中
├── skills/
├── agents/
└── hooks/
    └── hooks.json

マニフェストの中身も、これくらいで足りました。

{
  "name": "my-team-tools",
  "description": "チーム共通のレビュー・デプロイ手順",
  "version": "1.0.0"
}

手元で試すときは claude --plugin-dir ./my-plugin で読み込めます。

インストールしなくても動くので、形になるまではこれで回すのが早いです。
フックを移す場合は、settings.json の hooks をそのまま hooks/hooks.json に移すだけでした。

社内マーケットプレイスから配る

配布には、マーケットプレイスというカタログを1つ作ります。

実体は .claude-plugin/marketplace.json を置いたGitリポジトリです。

社外に出したくないなら、プライベートリポジトリのままで問題ありません。

/plugin marketplace add your-org/claude-plugins
/plugin install my-team-tools@your-org

GitLabや自ホストのGitでも、URLを渡せば同じように追加できます。インストール後に /reload-plugins を実行すると、再起動せずに反映されました。

移行が終わったら、元の .claude/ 側のファイルは削除しておいてください。サブエージェントは同じ名前だとプロジェクト側の定義が優先されるため、消さないとプラグイン版が使われません。

プラグインの入れ方そのものはClaude Codeプラグインの入れ方で手順を追っています。
初めての人には、こちらを先に読んでもらうとつまずきが減りますよ。

Claude Codeのチーム設定を全員へ行き渡らせる

配る仕組みを作っても、入れてもらえなければ意味がありません。

ここでは、全員の手元に届かせるための設定を見ていきます。

リポジトリ側からインストールを案内する

リポジトリの .claude/settings.json にマーケットプレイスを書いておけます。

{
  "extraKnownMarketplaces": {
    "my-team-tools": {
      "source": {
        "source": "github",
        "repo": "your-org/claude-plugins"
      }
    }
  }
}

これを置くと、メンバーがそのフォルダを信頼したタイミングでインストールを促してくれます。

逆に言えば、勝手に他人のマシンでコードが動き出すことはないという安心感もあります。

プラグインは自分の権限で任意のコードを動かせる存在なので、この慎重さは妥当ですね。

導入のハードルを下げたいなら、READMEにコマンドを1行貼っておくのが手っ取り早いです。
コピペ1回で終わるなら、たいていの人はやってくれますよ。

オンボーディングの手順書に組み込んでしまうのも有効でした。新メンバーが環境を作る流れの中に入れておけば、あとから声をかけて回る必要がなくなります。

管理設定で外せないものを配る

禁止事項のように、個人の判断で外されると困るものもあります。

その場合は、ユーザー設定では上書きできない管理設定として配布するのが確実でした。

MDMで配る形が一般的で、Team・Enterpriseプランならサーバー経由の配信も選べます。

ここまでやるかどうかは、扱っているコードの機密度しだいです。数人のチームなら、共有のsettings.jsonとREADMEで十分に回ります。

目安としては、「誰が入れたか把握できなくなったら仕組みに切り替える」くらいでちょうどよかったです。顔が見える範囲なら声をかければ済みますが、部署をまたいだ時点でそれは無理になります。

逆に人数が増えるほど、「全員がちゃんと入れてくれている」という前提は崩れていきました。
信頼ではなく仕組みで担保する段階が、どこかで来ると思っておくといいです。

Claude Codeのチーム設定共有でつまずく点

最後に、共有を始めたあとに起きやすい失敗をまとめます。

どれも「配ったのに効いていない」という形で表れます。

CLAUDE.mdが誰も読まないサイズに育つ

共有を始めると、みんなが良かれと思って書き足していきます。

気づけば500行を超えて、肝心のルールが埋もれた状態になっていました。

読まれないだけならまだしも、毎回のセッションでコンテキストを食い続けます。

残すのは「どの作業でも必ず守ってほしいこと」だけです。

この基準を最初にチームで合意しておくと、追記のたびに迷わなくなります。

私は「この行が読まれなくて事故になるか」で判断しています。
ならないものは、たいていCLAUDE.mdの外に出せました。

個人の設定と混ざって効かなくなる

共有したはずのルールが、なぜか人によって効いていない。

この場合、個人の設定側で打ち消されている可能性があります。

権限まわりではどのレベルであれ拒否されたものは、ほかで許可し直せません。

この3つで、だいたいの原因は特定できます。

とくに信頼ダイアログは、断ったまま忘れているケースが多いです。

「No, continue without these permissions」を選ぶと、共有側のallowルールは無視されたまま作業が続きます。
本人も気づいていないので、聞いて回るしかない厄介なやつですね。

更新が誰にも届かない

最後は、いちばん静かに進む失敗です。

プラグインを更新しても、各自が入れ直さなければ古いまま動き続けます。

Claude Codeには自動更新の仕組みがありますが、サードパーティや自作のマーケットプレイスは既定でオフでした。

管理者が配る設定に自動更新のフラグを入れておけば、各自の操作なしで有効になります。

そこまでやらない規模なら、素直に声をかけるのがいちばん確実です。

共有の仕組みは、作って終わりではありません。
配ったものが本当に使われているかを、たまに見に行くところまでが運用でした。

Claude Codeのチーム設定共有に関するよくある質問

ここでは、チームで共有を始めるときによく出る疑問に答えていきます。

Q：CLAUDE.mdはリポジトリにコミットして大丈夫ですか？

A：問題ありません。むしろコミットしないと共有になりません。プロジェクトルートに置けば、pullしたメンバー全員のセッションで自動的に読み込まれます。

個人的なメモを書きたい場合は CLAUDE.local.md を使い、こちらは .gitignore に入れておきます。認証情報のような秘密は、どちらにも書かないでください。

Q：プラグインにしないと共有できませんか？

A：1つのリポジトリで完結するなら、.claude/ に置いてコミットするだけで十分です。プラグインが必要になるのは、複数のリポジトリで同じものを使いたくなったときです。

目安としては、置き場所が2つ以上になったタイミングですね。コピーが始まると、片方だけ直された状態が必ず生まれます。

Q：設定を置いたのにメンバーの環境で効きません。なぜですか？

A：まず信頼ダイアログを承認しているか確認してください。プロジェクトの allow ルールは、フォルダを信頼するまで適用されません。

フックの場合は別の原因もあります。フックは起動したディレクトリの .claude/ からしか読まれないため、--add-dir で足したリポジトリのフックは動きません。

Q：プラグインを社外に公開せず、社内だけで配れますか？

A：配れます。マーケットプレイスの実体はGitリポジトリなので、プライベートリポジトリに置けば社内限定になりました。

GitHub以外でも、GitLabや自ホストのGitサーバーをURLで指定できます。アクセス権を持つメンバーだけがインストールできる形ですね。

まとめ

Claude Codeのチーム設定共有は、CLAUDE.mdをコミットするところから始まります。

1リポジトリなら .claude/ のままで十分で、置き場所が2つ以上に増えたらプラグインに切り出す。この順番が無理のない進め方でした。

配って終わりにしないことだけ、気をつけてください。誰も読まないCLAUDE.mdは、ないのと同じです。

まずは自分の環境で育った設定を眺めて、「これ、他の人も欲しいのでは」と思うものを1つ選んでみてください。
そこから始めると、共有の輪は自然に広がっていきます。

Claude Codeのような道具を使いこなす力は、生成AIを業務にどう組み込むかという視点とセットで伸びます。講座として学ぶ選択肢を知っておきたい方には、キカガクの「生成AIビジネス実践コース」の料金と学べる内容が参考になります。