たとえば、こんな経験はありませんか。同じ社内のメンバーが同じ仕事を Claude に頼んでいるのに、A さんは「コードのスタイルがちゃんと社内のルールに沿った形」で出てくるのに、B さんは「全然違う書き方」で出てくる。「同じ AI を使っているのに、こんなに違うのはなぜ？」と首をかしげる場面です。

原因はシンプルで、Claude に渡している「指示書」が人ごとに違うからです。Claude Code には、Claude にあらかじめ伝えておく文書（指示書）を置くいくつかの場所があります。誰かが個人で書いた指示書をそのままにしておくと、その人と他のメンバーの間で結果が変わってしまうのです。

これを解決するのが、GitHub にチーム共通の指示書を置く運用です。GitHub（ギットハブ、コードや文書をチームで共有するサービス）に「みんなで使う指示書」を置いておけば、メンバー全員が同じルールで Claude を動かせます。一方で「自分だけの設定」もあるので、すべてを GitHub に入れるわけではありません。「何を共有して何を共有しないか」――この判断軸を本記事で整理していきます。

細かい話に入る前に、結論を 1 枚に整理します。Claude のカスタマイズに関わるファイルは、大きく 4 種類に分けられます。

覚え方はシンプルです。「みんなで共有したいものは GitHub にコミット（共有用フォルダに保存）」「自分だけのメモは .local という名前のファイルか、自分の PC のホームフォルダ」。これさえ押さえれば、9 割の判断は迷いません。

空間的に俯瞰すると

テキストだけだとイメージしにくいので、ファイルの配置をツリー図で俯瞰します。3 つのエリアに分かれていることが視覚的にわかります。

────────────────────────────────────────────────────────
 [1] プロジェクトリポジトリ（GitHub で共有する場所）
────────────────────────────────────────────────────────
your-project/
├── CLAUDE.md                    ★ 共有する — チーム共通の指示書
├── CLAUDE.local.md              × 共有しない — 個人の作業メモ
├── .gitignore                   （共有対象を絞り込む設定）
└── .claude/
    ├── settings.json            ★ 共有する — チーム共通の安全ルール
    ├── settings.local.json      × 共有しない — 個人マシン固有
    ├── skills/                  ★ 共有する — チーム共通のショートカット集
    ├── agents/                  ★ 共有する — 専門担当のClaude
    └── rules/                   ★ 共有する — 場面別の細かいルール

────────────────────────────────────────────────────────
 [2] 個人のホームフォルダ（共有対象外 / 自分の PC の中だけにある）
────────────────────────────────────────────────────────
~/.claude/                       ← 自分のユーザーフォルダの中の隠しフォルダ
├── CLAUDE.md                    自分の好み（全プロジェクト共通）
├── settings.json                個人デフォルトの設定
├── skills/                      個人の生産性ツール
└── projects/
    └── <project-name>/
        └── memory/              ← Claude が自動で書き溜める学び

────────────────────────────────────────────────────────
 [3] 会社全体の領域（情シスが配布する／個人で除外不可）
────────────────────────────────────────────────────────
情シスが配布する OS のシステム領域
└── CLAUDE.md / managed-settings.json    全社員が必ず守るルール

この 3 つのエリアの「重ね合わせ」が Claude の動作を決めます。次の章から 1 つずつ詳しく見ていきます。

もう少しイメージしやすくするために、会社の文書管理にたとえてみます。Claude の指示書は、次の 4 つの引き出しのいずれかに入っているとイメージしてください。

Claude は、毎回の会話のはじめにこの 4 つの引き出しの中身を全部読み込みます。だから、引き出しに何を入れておくかで、Claude の振る舞いが大きく変わります。優先順位は「具体的な指示が勝つ」のが基本です。会社の規程と個人の付箋がぶつかったら、どっちを優先するべきかは状況で違いますが、Claude は会社全体ルール（4）が一番強いのが原則です（会社方針は個人で破れません）。

1 人で Claude を使っているうちは、引き出し 1 と 2 と 3 が混ざっていても気になりません。チームで使い始めると「これはみんなで共有するもの？それとも自分専用？」を意識する必要が出てきます。これがうまくできていないと、人によって Claude の動きがバラバラになるという冒頭の問題が起きるわけです。

4 つの引き出しのうち、もっとも頻繁に使うのが「CLAUDE.md（クロード ドット エムディー）」というファイルです。プロジェクトのリポジトリ（GitHub にあるそのプロジェクト用のフォルダ）の直下に置くチームの取扱説明書のような役割を持ちます。

何を書くか

新人が入ってきたとき、その人に「最初に読んでほしい」と思うようなレベルのことを書きます。具体的には次のような内容です。

• このプロジェクトの目的・対象ユーザー
• 使っている技術スタック・主要な外部サービス
• 命名規則・ディレクトリ構成のルール
• レビューで毎回指摘されるような共通の決まり
• 業務ドメイン特有の用語集

逆に「個人の好みのレベル」「特定のメンバーしか関わらない手順」は書きません。それは引き出し 2 や 3 に入れるべき内容です。

サイズの目安は 200 行以内

Anthropic 公式は「1ファイルにつき 200 行以内」を推奨しています。長すぎると Claude が一度に読み込む情報量が増えて、肝心な指示が薄まってしまうからです。これを超えそうな場合は、後述の「rules（ルール集）」に分けて、必要なときだけ読み込ませる工夫をします。

どこに置く？

2 つの場所から選べます。どちらも公式に有効で、チーム内で統一しておけば OK です。

• ./CLAUDE.md ― プロジェクトのルート直下（こちらが多い）
• ./.claude/CLAUDE.md ― 隠しフォルダ .claude/ の中（設定系をひとまとめにしたい派向け）

このファイルは必ず GitHub にコミットします。コミットしないとチームメンバーに共有されないので、せっかく書いた取扱説明書が無駄になります。

続いて、自分のデスクの付箋に相当するのが「CLAUDE.local.md」（クロード ドット ローカル ドット エムディー）です。プロジェクトのルート直下に置きますが、こちらはGitHub には入れないのがポイントです。

何を書くか

自分の作業中に出てくる「自分だけの事情」をここに書きます。例えば次のようなことです。

• 自分のローカル環境（自分の PC 上で動かしているもの）の URL や設定値
• 個人の検証用のテストデータ・パス
• 「今週はこの実験中」のような一時的な作業メモ
• 自分専用のショートカットや好みの書き方

これらは他のメンバーには関係ない情報なので、共有してもノイズになるだけです。Claude は CLAUDE.md と CLAUDE.local.md を両方読むので、「チーム共通の指示書 + 自分だけの補足」という重ね方が自然にできます。

なぜ GitHub に入れない？

GitHub は基本「みんなで共有するための場所」です。個人の事情をそこに混ぜると、他のメンバーから見るとノイズになりますし、誤って機密情報（自分用の URL や ID）が公開リポジトリに出てしまうリスクもあります。これを防ぐために、.gitignore という「共有しないファイルを指定するリスト」に CLAUDE.local.md を加えておきます。

3 つ目の引き出しは、自分のすべてのプロジェクトで共通する個人ルールです。プロジェクトを問わず常に守りたい自分の癖や好みを置きます。場所は ~/.claude/CLAUDE.md（自分の PC のホームフォルダ配下）です。

何を書くか

「Python よりも TypeScript で書いてほしい」「日本語の文章は『です・ます調』で書いてほしい」「変数名は短くしすぎないでほしい」のような、自分の作業スタイルに関する好みです。

これは自分の PC のホームフォルダにあるので、特定のプロジェクトのリポジトリには入りません。誰とも共有されず、自分の全プロジェクトで自動的に効きます。新しいプロジェクトに参加するたびに同じことを書き直す必要がなくなります。

ここに書いてはいけないのは「特定プロジェクトでだけ使うルール」。それはあくまで引き出し 1（CLAUDE.md）に書くべき内容です。引き出し 3 は「どのプロジェクトでも変わらないこと」に限定するのが鉄則です。

4 つ目は、就業規則・社内規程に相当する会社全体ルールです。Anthropic 公式の用語ではManaged policy（マネージド ポリシー）と呼ばれます。情シス（PC 管理を担当する部署）が、社員のパソコンに一斉配布するファイルです。

これがないと困る場面

たとえば「社員が AI を使うときに、機密ファイル（顧客情報・個人情報）をうっかり開かせてはいけない」「特定の API キーをコードに直接書かせない」「特定のディレクトリへの書き込みは絶対禁止」――こういった個人の判断で破れてはいけないルールを強制するときに使います。

配置場所（OS ごとに違います）

これらはユーザーの権限では編集できない場所にあり、情シスが PC 管理ツール（MDM、Ansible のような配布ツール）で社員のマシンに一斉配布します。個人の設定では除外できないのが特徴で、これによって社内ルールが確実に守られます。

非エンジニアの方が直接編集する場面はありません。ただ「会社全体に AI 利用の安全ルールを敷きたい」という議論になったときに、こういう仕組みがあることを知っておくと、情シス／法務との会話がスムーズになります。

引き出し 1〜4 が「Claude にあらかじめ伝えておく指示書」だとすると、Skills（スキルズ）は「Claude にいつもしてもらう作業のボタン化」です。同じ依頼を何度もコピペで送っているなら、それを Skill にまとめてしまえば、次回からは /コマンド名 と打つだけで実行できます。

どんな例があるか

• /release-notes（リリースノートの自動生成）
• /migrate（データベースの構造変更を実行）
• /security-scan（依存パッケージの脆弱性チェック）
• /code-review（共通レビュー観点での自動レビュー）
• /morning-briefing（朝にメール・Slack を要約）

「いつもの依頼」をひとつにまとめておけば、メンバー全員が同じ品質で再利用できる――これが Skills の本質です。

Skills は4つのレベルで共有できる

公式ドキュメントによると、Skills の置き場所は次の 4 つに分かれています。同じ名前の Skill が複数のレベルに存在すると、上位（より組織寄り）のものが優先されます。

「local 版の Skill」はあるのか？

CLAUDE.md には CLAUDE.local.md、settings.json には settings.local.json という「個人専用の別ファイル」が用意されています。「では Skills にも SKILL.local.md のような個人専用ファイルがあるのか？」と思うところですが、公式ドキュメントには Skills の .local 相当の仕組みは用意されていません。

公式の答えはシンプルで、「個人専用の Skill は ~/.claude/skills/（自分のホームフォルダ）に置く」です。プロジェクト固有のように感じる Skill でも、自分しか使わないものなら個人領域に置きます。あなたが他のプロジェクトで使う気がないだけで、Skill 自体はあなたの全プロジェクトで読み込まれてもデメリットはほぼありません。

ユースケース ― 個人 Skill をプロジェクトに紐づけて整理したいとき

「個人 Skill が増えてきて、プロジェクト横断で使うものとそうでないものを分けて管理したい」――こうしたケースでは、~/.claude/skills/ 一本だと整理が追いつかないことがあります。たとえば「このプロジェクトでだけ使うクセの強い手順（特定 API を叩く順序、社内ツール固有の設定読み出し手順など）」を、ホームフォルダの個人 Skill に混ぜたくないような場面です。

こういうときは 「gitignore された private/ フォルダに個人 Skill をまとめる」パターンが有効です。Anthropic 公式の機能を組み合わせて実現する応用パターンで、.gitignore は 1 行追加するだけで済みます。

your-project/
├── .gitignore                      ← 「private/」を1行追加
├── .claude/
│   ├── settings.json               ★ コミット — チーム共通
│   ├── settings.local.json         × 自動 git ignore
│   │   └── { "additionalDirectories": ["./private"] }
│   └── skills/                     ★ コミット — チーム共有Skills
│       └── deploy/
│           └── SKILL.md
└── private/                        × gitignore対象（1行で除外）
    └── .claude/
        └── skills/                 個人専用Skills（自動で読み込まれる）
            └── my-private-skill/
                └── SKILL.md

このパターンは 2 つの公式機能を組み合わせて成立しています。

• 仕様1 ― Claude Code は --add-dir で追加されたディレクトリ配下の .claude/skills/ を例外的に自動読み込みする（公式ドキュメントの Skills セクションに明記）
• 仕様2 ― --add-dir の指定は .claude/settings.local.json の additionalDirectories 設定として残しておけば、毎回打ち込まなくて済む（公式ドキュメントの Settings セクションに明記）

つまり、settings.local.json に "additionalDirectories": ["./private"] と書いておけば、private/.claude/skills/ 配下の Skill が毎セッション自動で読み込まれます。settings.local.json 自体は Claude Code が自動でグローバル git ignore に追加するため、これも追加で .gitignore をいじる必要はありません。結果として、プロジェクトの .gitignore に増えるのは「private/」の 1 行だけです。

3 つの選択肢の使い分け

「3 つ以上のプロジェクトで同じ Skill をコピペしている」と気づいた瞬間が、組織横断（プラグイン化）に切り替えるタイミングです。プラグインの作り方・配布方法は別記事で詳しく解説しています。

プラグインによる組織横断配布についてさらに詳しく知りたい方は、Claude Code のプラグインを社内で配布する完全ガイド｜Plugin Marketplace で組織のSkillsを横断共有もあわせてご覧ください。

ここまでに CLAUDE.md（指示書）と Skills（ボタン化）が登場しましたが、Claude Code にはほかにも Rules（場面別ルール）と Subagents（専門担当の Claude）という仕組みがあります。それぞれ「いつ働くか」と「何のために存在するか」が違います。混ぜて理解してしまうと使い分けができないので、ここでスッキリ整理しましょう。

4つの仕組みの役割分担

オフィスにたとえると一気に腹落ちします

会社で働く社員にたとえてみましょう。新入社員が出勤してから業務を進めるまでの流れがそのまま 4 つの仕組みの連動になっています。

Rules（場面別ルール）の動き

Rules は .claude/rules/ という専用フォルダに置く Markdown ファイルです。CLAUDE.md と違って、特徴的なのは「パスを指定して、そのファイル群を扱うときだけ効く」というオプションが使えることです。たとえば「フロントエンドの React コードを編集するとき」「データベースのスキーマファイルを編集するとき」「テストコードを書くとき」など、文脈ごとに別々のルールを切り替えて読み込ませられます。

これにより、CLAUDE.md を 200 行に収める努力をしながら、ファイル種類ごとに細かい規約を Claude に教えられます。CLAUDE.md が「全社共通」、Rules が「現場ごとの細則」だとイメージするのが分かりやすいです。

Subagents（専門担当の Claude）の動き

Subagents は .claude/agents/ に置く Markdown ファイルで定義する「専門担当の Claude」です。たとえば「セキュリティ専門のレビュアー」「テストデータの設計者」「ドキュメント整理の専門家」など、用途別に切り出して定義しておきます。Claude は重い調査や並列で進めたい作業に出会うと、これらの専門担当に仕事を委譲します。

大切なのは Subagent は別の作業領域を持つこと。委譲された側は独自の文脈枠で作業するので、メインの会話履歴を汚さずに大量のファイルを読み込んだり長時間の処理をさせたりできます。終わったら結果だけメインに返してきます。一人で全部抱える Claude より、専門家を呼んで分担する Claude のほうがチーム的に強い、と理解すると腹落ちします。

セッション開始から終了までの連動

4 つの仕組みは、Claude のセッション中で次のような順序で「層になって」働きます。

セッション開始
   │
   ├─ ① CLAUDE.md を全部読み込む（常駐の知識）
   │     └ プロジェクト + 個人 + 組織配布の全レイヤーを結合
   │
   ├─ ② Rules（パス条件なしのもの）を読み込む
   │     └ CLAUDE.md と同じ優先度で常駐
   │
   ↓
ユーザーがファイルを編集 / 質問する
   │
   ├─ ③ そのファイルにマッチする Rules があれば追加で読み込む
   │     例: src/api/**/*.ts を編集 → API 開発ルールが効き始める
   │
   ├─ ④ ユーザーが /skill-name と打つ or Claude が「これは Skill だ」と判断
   │     └ Skill の本文がそこで初めて文脈に入る
   │
   ├─ ⑤ Skill の中で「Subagent に委譲」と書いてあれば、専門担当に処理を渡す
   │     └ Subagent は独自の作業領域で実行 → 結果だけ返ってくる
   │
   ↓
セッション終了

ポイントは 「常時オン」と「呼ばれたとき」の使い分けです。

• CLAUDE.md と Rules は「常に背景に流れている知識」。書いた瞬間からあらゆる作業に影響する
• Skills と Subagents は「呼ばれたら登場する役者」。書いてあるだけでは何も起きない。トリガーされて初めて動く

だから「迷ったら CLAUDE.md にとりあえず書く」運用は危険です。常駐コストが上がって他の指示が薄まりますし、特定のときだけ思い出してほしいことは Rules や Skills に分けたほうが、Claude の集中力が上がります。

どれを使うか判断する3つの問い

新しいルールや手順を書こうとしたとき、次の 3 つの問いで置き場所を決められます。

この4つの問いを順に当てはめれば、「とりあえず CLAUDE.md に書いてどんどん肥大化していく」よくある失敗を避けられます。

判断に迷ったら、次の早見表を見ながら考えます。実務で出会う頻度が高い順に並べました。

よくある間違い ― .claude/ ごと共有対象から外してしまう

プロジェクトの .gitignore は基本的に書き足さなくていい

Claude Code 関連で .gitignore に手動で書き足すべきものは、実はほとんどありません。CLAUDE.local.md も settings.local.json も、Claude Code が自動でグローバル git ignore（~/.config/git/ignore）に登録してくれます。プロジェクトの .gitignore 側は何もしなくても、これらのファイルはコミット対象から除外されます。

チームの新メンバーが clone した直後にうっかり個人ファイルをコミットしてしまうのが心配であれば、念のためプロジェクトの .gitignore にも CLAUDE.local.md と .claude/settings.local.json の2行だけ書き足しておくのが安心策です。個別の Skill ディレクトリを .gitignore に書き足す運用は不要なので、.gitignore が個人ファイルで膨れ上がることはありません。

ここまでの仕組みを実際にどう組み合わせるか、現場でよく見られる運用パターンを 5 つに分けて整理します。どれも特定のサービスに依存しない汎用的な型です。

パターン1 ― CLAUDE.md にドメイン知識を集約する

各リポジトリのルートに CLAUDE.md を置き、リポジトリ固有のドメイン知識を 100〜180 行に収めるのが定番です。「このプロジェクトの目的」「ビルド・テスト・デプロイのコマンド」「主要テーブル・命名規則」「外部 API のエンドポイント一覧」「業務用語集」などを書いておくと、Claude が定型的なミス（必須項目の記入漏れ、規約違反の命名、想定外の API 呼び出し）をほぼ起こさなくなります。

パターン2 ― .claude/skills/ にチーム共通のショートカット

チーム全員が使うショートカット（Skill）は .claude/skills/ に置いて GitHub にコミットします。例えば「リリースノートの自動生成」「DB マイグレーション実行」「シードデータ投入」といった業務固有の Skill を Skills 形式に寄せていくのが今後の主流です。

パターン3 ― CLAUDE.local.md は個人別のメモに

各メンバーの CLAUDE.local.md には「自分のローカル環境のサービス URL」「個人の検証用環境変数」「自分だけが使うショートカット集」などを置き、.gitignore でコミット対象から外します。これによりチーム共通の指示書は安定して共有しつつ、個人の試行錯誤は誰の邪魔にもならない形で保てます。

パターン4 ― Auto memory は学びの自動蓄積に使う

Claude Code にはAuto memory（自動メモ）という機能があります。Claude が会話の中で気づいたことを自動的にメモしてくれる仕組みで、明示的にルール化するほどではないが繰り返し起きる気づきの受け皿になります。「このスタックではこの順番でビルドコマンドを叩く必要がある」「特定のテストはローカルで Redis が立ち上がっていることが前提」といった、口頭で説明するレベルの細部を自動で蓄積してくれます。マシンローカルなのでチーム共有はされませんが、本人の作業効率は確実に上がります。

パターン5 ― 大規模リポジトリでは階層ごとに CLAUDE.md を配置

1 つの大きなリポジトリに複数プロジェクトを束ねる構成（monorepo・モノレポと呼ばれます）や、別リポジトリを取り込む構成では、CLAUDE.md を各階層に置くのが効きます。Claude は作業中の場所から親方向に CLAUDE.md を辿って、見つかったものを全部結合して読み込む仕様なので、内側で作業すると「全体ルール → プロジェクト群別ルール → 個別プロジェクトのルール」が自然に重ね合わさります。大規模化したリポジトリを段階的に整理するときの王道パターンです。

「CLAUDE.md を書いたのに反映されない」

Claude Code のセッション内で /memory と打つと、今読み込まれている CLAUDE.md ファイルの一覧が出ます。ここに目的のファイルが出ていなければ、Claude にそのファイルが見えていないということです。「.claude/CLAUDE.md と CLAUDE.md を両方作って混乱している」「期待した階層と違うところに置いた」のような原因が多いので、最初に /memory で確認するのが習慣になっていると早く解決します。

「大きなリポジトリで他チームの CLAUDE.md まで読み込まれてしまう」

1 つのリポジトリに複数プロジェクトがまとめて入っている構成（monorepo・モノレポ）では、Claude は作業中のディレクトリから親方向に CLAUDE.md を全部読みに行くため、別チームの CLAUDE.md が混ざることがあります。これは .claude/settings.local.json という個人設定ファイルに「読み込みから除外するパス」を指定すれば外せます。

「Skill を作ったのに自動で起動しない」

Skill ファイルの説明文（description）が貧弱だと、Claude が「いつ呼ぶべきか」を判断できません。「セキュリティ確認をするときに使う」「リリースノートを書くときに使う」のように、起動のきっかけになるフレーズを含めると効きます。逆に Claude が勝手に起動しすぎる場合は「自動起動を無効化する」設定（disable-model-invocation: true）を付ければ手動起動だけになります。

「コミットしたのに同僚の環境で動かない」

Claude Code はそのフォルダを最初に開いたときに、「このフォルダの設定を信頼しますか？」という確認を出します。これを承認しないと、リポジトリ内の .claude/settings.json や Skill の権限設定が効きません。新メンバー受け入れ手順に「最初の起動時に承認画面で OK する」を必ず入れておきます。

Claude のチーム導入で迷う「どこに何を置くか」は、結局のところ次の 2 つの軸で決まります。

• 誰と共有したいか（自分だけ／チーム全員／会社全員）
• どこまで厳しく守らせたいか（推奨／必須／個人で破れない）

覚え方はとてもシンプルです。

• チーム全員に共有したいもの → リポジトリの CLAUDE.md や .claude/ 配下に入れて GitHub にコミット
• 自分だけに閉じたいもの → ファイル名の末尾に .local を付けるか、自分の PC のホームフォルダに置く
• 複数プロジェクトで横断したいもの → プラグインとして配布（別記事で詳述）
• 会社全体に強制したいもの → 情シス経由で配布（PC のシステム領域に置く）

この 4 つのレイヤーを意識して配置するだけで、Claude のチーム運用は驚くほどスムーズになります。1 人で使っている間は気づきにくい違いですが、2 人目・3 人目のメンバーが入ったときに大きな差が出る領域です。最初から正しいレイヤリングをしておくことを強く推奨します。