この記事の対象読者

• 開発チームに Claude Code の導入を検討している CTO・テックリード

• 複数チーム・複数プロジェクトで AI コーディングアシスタントの標準化を図りたい方

• SIer として顧客案件ごとに開発ルールを管理したい方背景：AI コーディングアシスタントの「野良運用」リスク

  Claude Code をはじめとする AI コーディングアシスタントをチームに導入する際、個々のエンジニアが自由に使い始めると、次のような問題が生じがちです。

• コーディング規約の逸脱（命名規則やディレクトリ構成の不統一）

• セキュリティポリシーの未遵守（機密ファイルの誤操作、危険なコマンド実行）

• チーム間での品質のばらつき（あるプロジェクトでは丁寧、別のプロジェクトでは雑）

CLAUDE.md は、Claude Code に対する指示書（プロンプト）をファイルとして管理する仕組みです。リポジトリにコミットすることでチーム全体で共有でき、AI の振る舞いをコードと同じようにバージョン管理できます。

本記事では、この CLAUDE.md が階層的に読み込まれる仕組みを解説し、組織・チーム開発での活用パターンを紹介します。CLAUDE.md の階層的読み込み

親ディレクトリ方向（起動時に自動読み込み）

Claude Code は起動時に、ワーキングディレクトリから親ディレクトリ方向へ再帰的に CLAUDE.md を検索し、見つかったファイルをすべてコンテキストに含めます。

/Users/dev/projects/myapp/  ← ここで Claude Code を起動
├── CLAUDE.md               ← 読み込まれる（プロジェクトルート）
└── ...

/Users/dev/projects/
├── CLAUDE.md               ← これも読み込まれる（親ディレクトリ）
└── ...

たとえば開発ディレクトリの上位に組織共通の CLAUDE.md を配置しておけば、どのプロジェクトで Claude Code を起動しても自動的にその指示が適用されます。

サブディレクトリ方向（オンデマンド読み込み）

一方、サブディレクトリの CLAUDE.md は起動時には読み込まれません。Claude がそのディレクトリ内のファイルにアクセスしたタイミングで動的に統合されます。

myapp/
├── CLAUDE.md          ← セッション開始時に読み込み
├── frontend/
│   ├── CLAUDE.md      ← frontend/ のファイルを読む時に追加
│   └── src/
└── backend/
    ├── CLAUDE.md      ← backend/ のファイルを読む時に追加
    └── src/

この構成の場合、処理の流れは次のようになります。

1. セッション開始時: myapp/CLAUDE.md が読み込まれる

2. frontend/src/app.ts を編集する時: frontend/CLAUDE.md が追加で統合される

3. backend/src/server.ts を編集する時: backend/CLAUDE.md が追加で統合される

frontend の作業をしている間は backend の CLAUDE.md は読み込まれないため、不要な指示でコンテキストウィンドウが圧迫されない効率的な設計です。メモリの種類と優先順位

Claude Code には複数階層のメモリが存在し、それぞれスコープと管理者が異なります。

上位の階層が先に読み込まれて基礎となり、下位のファイルがそれに積み重ねられる形で統合されます。競合する指示がある場合、より具体的（下層）な指示が優先されます。各メモリの使い分け

管理ポリシー（優先度1）は OS のシステムディレクトリに配置され、MDM 等で配布します。個々のエンジニアが変更できないため、セキュリティポリシーの強制に適しています。

プロジェクトメモリ（優先度2）はリポジトリのルートに置き、Git で管理します。チーム全員が同じ指示を共有でき、Pull Request でレビュー可能です。

プロジェクトルール（優先度3）は .claude/rules/ ディレクトリに個別の .md ファイルとして配置します。CLAUDE.md が肥大化した場合に、関心ごとに分割して管理できます。

.claude/rules/
├── coding-style.md    # コーディング規約
├── testing.md         # テストに関するルール
├── security.md        # セキュリティ要件
└── git-workflow.md    # Git 運用ルール

ユーザーメモリ（優先度4）はホームディレクトリ配下に置く個人設定です。「日本語で回答してください」「コミットメッセージは Conventional Commits 形式で」といった個人の好みを全プロジェクト共通で適用できます。

プロジェクト個人用（優先度5）は CLAUDE.local.md として配置し、.gitignore に含めます。ローカル環境固有のパスや個人的な作業メモなど、チームに共有しない設定に使います。組織・チーム開発での活用パターン

パターン1：モノレポのガバナンス

モノレポ構成では、ルートに共通ルール、各パッケージに固有の技術指示を配置します。

monorepo/
├── CLAUDE.md                    # 共通ルール
├── packages/
│   ├── web/
│   │   └── CLAUDE.md            # フロントエンド固有
│   ├── api/
│   │   └── CLAUDE.md            # バックエンド固有
│   └── shared/
│       └── CLAUDE.md            # 共有ライブラリ固有
└── .claude/
    └── rules/
        ├── testing.md           # テスト方針
        └── security.md          # セキュリティ要件

ルートの CLAUDE.md には全パッケージ共通のルールを書きます。

# プロジェクト共通ルール

- TypeScript strict mode を必須とする
- テストカバレッジ 80% 以上を維持する
- コミットメッセージは Conventional Commits に従う
- ESLint / Prettier の設定に従うこと

各パッケージの CLAUDE.md にはフレームワーク固有の指示を書きます。

# Web パッケージ（React / Next.js）

- コンポーネントは関数コンポーネントで書く
- 状態管理には Zustand を使用する
- CSS は Tailwind CSS のユーティリティクラスを使う
- Server Components をデフォルトとし、必要な場合のみ "use client" を付与

サブディレクトリの CLAUDE.md はオンデマンドで読み込まれるため、api パッケージの作業中に web パッケージの React 固有指示がコンテキストを消費することはありません。

パターン2：SIer の案件別管理

SIer で複数顧客の案件を並行して扱う場合、ユーザーメモリに社内標準を、プロジェクトメモリに案件固有のルールを配置します。

• ~/.claude/CLAUDE.md — 社内コーディング標準、セキュリティチェックリスト、ドキュメント作成ルール

• 案件Aの CLAUDE.md — 顧客A固有の技術スタック（Java / Spring Boot）、コーディング規約、命名規則

• 案件Bの CLAUDE.md — 顧客B固有の技術スタック（Python / FastAPI）、コーディング規約、命名規則

ユーザーメモリに書いた社内標準は、どの案件のリポジトリで作業しても自動的に適用されます。案件を切り替えるたびに設定を変更する必要はありません。

# ~/.claude/CLAUDE.md（社内標準）

## セキュリティ
- .env、credentials、秘密鍵ファイルを Git にコミットしない
- SQL は必ずパラメータバインドを使用する
- 外部入力は必ずバリデーションする

## ドキュメント
- コード変更時は対応する設計書の更新箇所を指摘する
- API の変更時は OpenAPI 仕様も更新するパターン3：管理ポリシーによるセキュリティ統制

最上位の管理ポリシー（macOS: /Library/Application Support/ClaudeCode/CLAUDE.md）は、MDM（Jamf, Intune 等）で全社端末に配布することで、組織全体に統一ルールを強制できます。

# 管理ポリシー（IT管理者が配布）

## 禁止事項
- .env, .pem, credentials.json などの機密ファイルを読み取り・編集しない
- 本番環境のデータベースに対する変更クエリを生成しない
- 外部のファイルホスティングサービスへのアップロードコマンドを実行しない

## セキュリティ要件
- 認証トークンやAPIキーをハードコードしない
- OWASP Top 10 の脆弱性を含むコードを生成しない

この階層は個々のエンジニアが上書きできないため、コンプライアンス要件の担保に有効です。プロジェクトの CLAUDE.md や個人設定でこれらのルールを緩和することはできません。

パターン4：新規メンバーのオンボーディング支援

CLAUDE.md にプロジェクトのアーキテクチャや開発フローを記載しておくと、新しいメンバーが Claude Code を通じてプロジェクトの文脈を理解しやすくなります。

# プロジェクト概要

## アーキテクチャ
- フロントエンド: Next.js (App Router) + Tailwind CSS
- バックエンド: AWS Amplify Gen2 (AppSync + DynamoDB)
- 認証: Amazon Cognito

## ディレクトリ構成
- apps/web/ — フロントエンドアプリケーション
- amplify/ — Amplify バックエンド定義
- packages/shared/ — フロント・バックエンド共通の型定義

## 開発フロー
- feature ブランチを切って開発 → PR → レビュー → main にマージ
- main にマージすると staging 環境に自動デプロイ
- リリースタグを打つと production 環境にデプロイ

新しいメンバーが「このプロジェクトの構成を教えて」と聞くだけで、Claude が CLAUDE.md の内容をもとに正確な回答を返してくれます。CLAUDE.md の運用 Tips

Git でレビュー可能にする

CLAUDE.md はリポジトリにコミットして Git 管理することを推奨します。変更内容を PR でレビューすれば、チーム全員が AI への指示内容を把握でき、意図しないルール変更を防げます。

ローカル設定は .gitignore に追加する

CLAUDE.local.md は個人のローカル設定用なので、.gitignore に追加しましょう。

# .gitignore
CLAUDE.local.md

肥大化を防ぐ

CLAUDE.md が長くなりすぎるとコンテキストウィンドウを圧迫します。目安として、各ファイルは 200 行以内に収め、詳細なルールは .claude/rules/ に分割しましょう。

定期的に見直す

プロジェクトの技術スタックやルールは変化します。月に一度程度、CLAUDE.md の内容が現状と乖離していないかレビューすることをお勧めします。

まとめ

• CLAUDE.md は親方向は起動時、サブディレクトリはオンデマンドで階層的に読み込まれる

• 5段階の優先順位があり、組織ポリシー → チーム規約 → 個人設定の順で統合される

• モノレポのガバナンス、SIer の案件管理、セキュリティ統制、オンボーディングなど組織規模に応じた設計が可能

• AI コーディングアシスタントの振る舞いをコードと同様にバージョン管理することで、チーム全体の開発品質を標準化できる

CLAUDE.md の階層設計を活用することで、「AI コーディングアシスタントの野良運用」から脱却し、組織としてガバナンスの効いた AI 活用が実現できます。

参考

• Claude Code 公式ドキュメント - Memory

最後に

株式会社ピュアポムメディアラボ（PML）では、AI を活用した開発支援やプロダクト開発に取り組んでいます。Claude Code をはじめとする AI ツールを活用した開発に興味のある方、一緒に働きませんか？

• 採用情報・お問い合わせ: https://purpom-media-lab.com/