Claude Codeをチームで使い始めると、最初に差が出るのはモデル選択ではなく「プロジェクトの前提をどれだけ正確に渡せているか」です。CLAUDE.mdは、コーディング規約、実行してよいコマンド、レビュー観点、禁止事項、リポジトリ固有の設計判断をClaude Codeに共有するためのプロジェクトメモリです。2026年9月時点では、CLAUDE.mdに加えてAGENTS.md、.claude/rules/、auto memoryも併用できるため、単一ファイルにすべてを書き込むより、用途ごとにスコープを分ける設計が重要になっています。
CLAUDE.mdとは？Claude Codeの動作を制御する設定ファイル
CLAUDE.mdは、Claude Codeがセッション開始時や関連ディレクトリを読むときに参照する永続的な指示ファイルです。ビルド手順、テストコマンド、命名規則、設計思想、レビュー時の観点など、毎回チャットで説明したくない情報をまとめておくことで、出力のばらつきを抑えられます。ただしCLAUDE.mdは「強制設定」ではなく、モデルに渡されるコンテキストです。絶対に止めたい操作はCLAUDE.mdだけに頼らず、権限設定やPreToolUse hookでブロックするのが安全です。
現在のClaude Codeでは、組織管理のCLAUDE.md、ユーザー単位の~/.claude/CLAUDE.md、リポジトリ直下または.claude/配下のプロジェクトCLAUDE.md、個人用のCLAUDE.local.mdなど、複数の場所にメモリを置けます。さらに、CLAUDE.mdがないプロジェクトではAGENTS.mdをプロジェクト指示として読む挙動も追加されています。既にCodexや他のエージェント向けにAGENTS.mdを整備しているチームは、二重管理を避けるために「共通ルールはAGENTS.md、Claude Code特有の運用はCLAUDE.md」のように役割を明確にすると管理しやすくなります。
CLAUDE.mdの主要設定項目を徹底解説
コーディング規約の設定
最初に書くべきなのは、フォーマットではなく判断基準です。「TypeScriptはstrict前提」「UI変更時は既存コンポーネントを優先」「DBマイグレーションは手書きSQLではなく既存CLIを使う」のように、コードベース固有の選択を具体的に書きます。インデント幅や命名規則も有効ですが、prettierやruffなど機械的に検証できるものはツールに任せ、CLAUDE.mdには「どのコマンドで検証するか」「失敗時にどこを見るか」を書くと実務で効きます。
禁止操作の明示
禁止事項は抽象的に「危険な操作をしない」と書くより、実際の事故につながる行動を列挙します。例として、本番DBへの直接UPDATE、既存slugの変更、認証情報の出力、ユーザー未確認の外部送信、破壊的なgit操作などです。Claude CodeにはManual mode、auto mode、Accept Edits modeなど複数の権限モードがあるため、CLAUDE.mdには「なぜ禁止か」と「代替手順」を添えると、モデルが安全なルートを選びやすくなります。
プロジェクト固有ルールの設定
プロジェクト固有ルールでは、ディレクトリ構成、ドメイン用語、テストデータ、リリース手順、所有権境界を整理します。大規模リポジトリではCLAUDE.mdを200行以内に保ち、フロントエンド、API、インフラのような領域別ルールは.claude/rules/に分けるのが現実的です。Claude Codeのルールは対象ファイルやパスに応じて読み込めるため、全セッションに不要な情報を詰め込まず、必要なときだけ効く形にできます。
チーム共有のベストプラクティス
チームで共有するCLAUDE.mdは、個人の好みではなく、レビューで指摘されるレベルのルールに絞ります。新メンバーが最初に読む開発ガイドとしても機能するように、セットアップ、よく使うコマンド、PR前チェック、障害時の確認先を短くまとめましょう。逆に、個人のショートカット、ローカルURL、未共有の実験設定はCLAUDE.local.mdやユーザーCLAUDE.mdに分離します。
運用面では、CLAUDE.mdを「一度書いて終わり」にしないことが大切です。Claude Codeが同じ誤りを繰り返したとき、コードレビューで前提不足が見つかったとき、オンボーディングで同じ説明が発生したときに更新します。更新時は、曖昧な表現を避け、「npm testを実行」ではなく「pnpm test:unitとpnpm lintを実行し、失敗したら変更箇所に近いテストから直す」のように検証可能な文章にします。
実践的な設定例3パターン
パターン1：フロントエンド開発（React/Next.js）
React/Next.jsのプロジェクトでは、コンポーネント分割、状態管理、アクセシビリティ、デザインシステムの利用ルールを明確にします。たとえば「新規UIは既存のButton、Dialog、FormFieldを使う」「サーバーコンポーネントを優先し、クライアントコンポーネントは必要な境界だけに限定する」「表示文言はi18nファイルに追加する」といったルールです。加えて、UI変更時に実行するスクリーンショット確認やPlaywrightテストのコマンドを記載しておくと、見た目の回帰も検出しやすくなります。
パターン2：バックエンド開発（Python/FastAPI）
Python/FastAPIでは、APIスキーマ、例外処理、DBセッション、認可境界をCLAUDE.mdに書くと効果があります。「Pydanticモデルをレスポンス契約の唯一の定義にする」「マイグレーションはalembicで作成する」「外部API呼び出しはtimeoutとリトライ方針を明示する」などです。セキュリティ上は、.envやシークレットを読ませない方針、ログに個人情報を出さない方針、管理者権限のテストケースを必ず追加する方針も書いておくと安心です。
パターン3：データ分析（Python/Jupyter）
データ分析では、再現性とデータ保護のルールが中心です。「元データは上書きしない」「notebookの最終セルに結論と次アクションを残す」「個人情報を含む列は集計前に匿名化する」「可視化は保存先とファイル名規則を統一する」などを明記します。Claude Codeはコード生成だけでなく調査手順の整理にも使われるため、分析仮説、除外条件、指標定義をCLAUDE.mdに書いておくと、次回セッションでも同じ前提で進められます。
hooksとの連携でさらに強力に
CLAUDE.mdは「何を大事にするか」を伝える場所で、Hooksは「必ず実行する処理」を定義する場所です。PostToolUse hookで保存後にformatterを走らせる、PreToolUse hookで本番向けコマンドを止める、Notification hookで入力待ちを通知する、といった形で役割を分けます。Claude CodeのHooksはsettings.jsonに定義し、イベントごとにmatcherとcommandを設定します。判断を伴う場合はprompt-based hooksやagent-based hooksも選択肢になりますが、まずはフォーマット、テスト、危険コマンドのブロックのような決定的な処理から始めるのが安全です。
2026年時点の実務では、CLAUDE.md、.claude/settings.json、Hooks、権限モードをセットで設計するのが標準になりつつあります。たとえばCLAUDE.mdに「公開記事のslugは変更しない」と書き、PreToolUse hookでslug更新SQLをブロックし、PostToolUse hookでJSON検証を走らせる、といった多層防御です。モデルへのお願いと機械的なガードを分けることで、チーム全員が安心してClaude Codeを使えるようになります。
CLAUDE.md導入時の注意点とトラブルシューティング
CLAUDE.mdが効かないと感じるときは、まず読み込み対象と優先順位を確認します。作業ディレクトリの外に置いたファイル、長すぎるファイル、矛盾した指示、サブディレクトリ側のルールによる上書きが原因になりがちです。Claude Codeでは/contextで読み込まれているメモリを確認できるため、期待したファイルが入っているかをチェックしましょう。
もう一つの注意点は、CLAUDE.mdを万能なポリシー管理ツールにしないことです。強制力が必要なルールはsettings、Hooks、CI、権限設定に寄せます。CLAUDE.mdには「なぜそのルールがあるか」「迷ったときに何を優先するか」を書き、機械的な検証はツールに任せる。この分担ができると、Claude Codeは単なる補助ではなく、チーム標準に沿って動く開発パートナーとして安定します。
