「Claudeに毎回同じ説明をしている気がする」「メンバーごとに出力のフォーマットがバラつく」 — この相談、本当に多いです。チームでClaude Codeを使い始めて1ヶ月くらいで必ず誰かが言い出します。

原因は、作業ルールの置き場所が決まっていないこと。Claude Codeは複数のファイルからルールを読み込む仕組みを持っていて、どこに何を書くかが定まると応答が一気に安定します。

この記事では、Claude Codeで作業ルールを管理する3つの仕組みと、使い分けを整理します。

3つのルール管理の仕組み

Claude Codeが起動時に読むルールファイルは、主に次の3種類です。

1. CLAUDE.md — プロジェクト全体の規約。リポジトリ直下に置く。Claude Codeが自動で読む 2. AGENTS.md — 「コードを書く前にこれを読め」レベルの注意事項。CLAUDE.mdから@AGENTS.mdで参照する形が多い 3. サブエージェント定義 (.claude/agents/{name}.md) — 特定タスク専用の小さなAI役割

順番に役割が違います。混ぜて使うと、それぞれの責務がぼやけて応答精度が落ちる。

CLAUDE.md に書くこと

CLAUDE.mdは「Claude Codeにとっての新人オリエンテーション資料」。プロジェクトに初めて触る人が知るべき情報を網羅します。

書くべき内容は次のとおり。

  • プロジェクトの目的と全体像(1〜3段落)
  • ディレクトリ構成(src/ には何が入る、tests/ には何が入る、等の表)
  • よく使うコマンド(npm run dev npm run build の正確な書き方)
  • 命名規約(snake_case か camelCase か、コンポーネントは PascalCase 等)
  • コミットメッセージのスタイル(prefix を feat: fix: 等で揃える等)
  • 触ってはいけないファイル(migrations/、自動生成ファイル等)

逆に書くべきでない内容もある。

  • 「コードを書く前に必ず読む」レベルの注意事項 → AGENTS.mdへ
  • 特定タスク専用のフォーマット指示(議事録の体裁等) → サブエージェントへ

長さは1,000〜3,000字程度が運用しやすい目安。短すぎると情報不足、長すぎるとセッション開始時のトークン消費が増えます。

私の運用では、/init でClaudeに初版を作らせて、1ヶ月かけて足りない部分を追記する流れに落ち着いています。

AGENTS.md に書くこと

AGENTS.mdは「コード変更を提案する前に必ず読むべき注意事項」。CLAUDE.mdの中から @AGENTS.md という記法で参照すると、関連ファイルとして自動で読み込まれます。

実例として media/AGENTS.md をそのまま引用する。

# This is NOT the Next.js you know

This version has breaking changes — APIs, conventions, and file structure may all differ from your training data. Read the relevant guide in `node_modules/next/dist/docs/` before writing any code.

これだけ書いておくと、Claudeが Next.js 16 のコードを学習データ通りに書こうとして壊す事故が激減します。

AGENTS.mdに書くべきものは次のとおり。

  • 学習データと現実がズレている技術スタック(Next.js 16 / React 19 のような破壊的変更)
  • 特定のセキュリティ要件(個人情報・APIキーの取扱)
  • 過去の事故からのルール(「migration中は本番DBを触らない」等)
  • 参照すべき公式ドキュメントの場所(node_modules/.../docs/ 等)

「Why」と「How to apply」をセットで書くのがコツです。理由なしのルールは Claude が状況を見て無視することがある。

私のリポジトリでは、過去にClaudeが空ディレクトリを削除して開発環境が壊れた事故から「空ディレクトリでも .gitkeep がある場合は触らない」というルールをAGENTS.mdに追加しています。事故から学んだルールは AGENTS.md が居場所。

サブエージェント定義に書くこと

サブエージェントは「特定タスク専用のAIスタッフ」。.claude/agents/{name}.md というファイルに役割を書いておくと、/agents で呼び出して特定の仕事だけを任せられます。

書く内容のテンプレは下記。

---
name: meeting-minutes-formatter
description: 議事録の文字起こしを構造化する。録音された生テキストを、決定事項・アクション・宿題に分類する。
tools: Read, Write
---

# 役割

会議の録音から起こされた生テキストを、社内標準の議事録フォーマットに整形する。

# 入力
- recording/{date}.txt の生テキスト

# 出力
- minutes/{date}.md
- 構成: 日付/参加者/決定事項(箇条書き)/アクション(担当者と期日)/次回宿題

# 規約
- 「えー」「あの」などのフィラーを除去
- 個人名は社内Wikiの表記に揃える
- 数値は半角に統一

description の書き方が肝です。「いつ呼び出すべきか」を明確に書く。あいまいだと Claude が呼び分けに失敗します。

3つのうちサブエージェントだけが呼び出し時にだけ読み込まれる仕組みなので、各エージェントの定義は3,000〜10,000字書いても問題ありません。CLAUDE.mdより詳しく書ける。

ルール競合時の優先順位

複数のルールが矛盾した時の優先順位は、おおむね以下の順番になる。

  1. 直前のユーザー指示 — 「今回はこの規則を無視して」と明示されたら最優先
  2. サブエージェント定義 — そのエージェントを呼んでいる間はその役割定義が優先
  3. CLAUDE.md + AGENTS.md — プロジェクト全体の規約
  4. Claudeの一般知識 — どれも該当しない時のフォールバック

逆向きに矛盾するルールが複数あった場合、たとえば CLAUDE.md に「日本語で」とあり、サブエージェント定義に「英語で」とあるようなケースでは、サブエージェント定義が勝ちます。

私のチームで以前、CLAUDE.mdに「常にTypeScript」と書いてあるのに、特定のサブエージェントだけJavaScriptを生成していて混乱したことがあります。原因はサブエージェント定義が古く「JavaScript」のままだったから。複数階層でルールを書くなら、定期的な棚卸しが必須です。

月1の棚卸しでルールを健全化する

ルールは書きっぱなしだと腐ります。私のチームでは月初に15分の「ルール棚卸し会」を入れて、次の3点を見直しています。

  • CLAUDE.md / AGENTS.md / 各サブエージェント定義の最終更新日
  • 過去30日のClaudeの出力で気になった事象 → ルール追記候補
  • 不要になったルール(削除候補)

長くなったCLAUDE.mdは応答精度に効いてくる(余計な文脈がClaudeを引っ張る)ので、削るのも重要です。

まとめ

  • ルール管理は CLAUDE.md(プロジェクト全体)/ AGENTS.md(注意事項)/ サブエージェント定義(タスク専用)の3階層
  • CLAUDE.md はオリエンテーション、AGENTS.md は「読む前に必ず」、サブエージェントは「専門スタッフ」
  • 競合時の優先順位は ユーザー指示 → サブエージェント → CLAUDE.md/AGENTS.md → 一般知識
  • 月1の棚卸しでルールを健全化、不要になったものは積極的に削除