Claude Code ルール設定ガイド:CLAUDE.mdと自動メモリの使い分け
Claude CodeのルールをCLAUDE.mdにまとめ、チームで同じ説明を繰り返す手間を減らしましょう。小規模チーム向けのひな形を使い、指示ファイルの置き場所、パス別ルール、AGENTS.mdとの使い分け、自動メモリの保存範囲と月次整理まで解説します。チームで共有する指示と、個人の学習メモを無理なく管理できます。
公開日

Claude Code ルール設定の基本は、チームの作業ルールを一度まとめてClaude Codeに渡しておくことです。そうすれば、次のセッションも適切なコマンドや規約、作業範囲を踏まえて始められます。チームで決めたことは短いCLAUDE.mdにまとめ、役立つ修正は自動メモリに残します。ただし、昨日だけの例外が明日の誤った助言にならないよう、保存された内容は見直しましょう。
これにより、同じ前提を何度も説明する手間を減らせます。仮に、開発者4人がそれぞれ週に5回のセッションを開き、毎回3分かけて前提を説明しているとすれば、合計で週60分を費やしている計算です。共有の指示ファイルがあれば、その前提を一か所で管理できます。説明の繰り返しがどれだけ減ったかを、ファイルのメンテナンスにかかる時間と比べて判断してください。必ず時間を節約できるというわけではありません。
Claude Code ルール設定の基本:CLAUDE.mdとは
CLAUDE.mdは、プロジェクトや個人のワークフロー、組織向けの指示を記述するMarkdownファイルです。Claude Codeはこのファイルを読み込みます。チームの共通方針をまとめた指示書と考えるとわかりやすいでしょう。一方、自動メモリはClaudeが傍らで書き留める作業ノートです。指示書を管理するのは人、ノートを書くのはClaudeです。どちらも判断に使うコンテキストになります。Anthropicのメモリガイド
使い分けの基準は、セッションが変わっても守るべきことかどうかです。必須のテストコマンドは指示書に書きます。「説明が詳しすぎた」というフィードバックは、学習した好みとして残せます。そして、今取り組んでいるタスクは会話の中で伝えます。
この分類は公式のディレクトリガイドに沿っています。最初から大きな.claudeフォルダーを用意する必要はありません。まずは指示書を作り、別のファイルに明確な役割ができたときに追加します。

CLAUDE.mdはどこに置く?プロジェクト・個人・組織の使い分け
小規模なチームなら、リポジトリのルートにプロジェクト用のファイルを一つ置き、コミットするところから始めます。個人の好みはユーザー用のファイルに入れ、ほかのメンバーへ意図せず適用されないようにします。
これらは公式に記載された適用範囲と保存場所です。管理された組織用ファイルを個人の設定で読み込み対象から外すことはできません。ただし、そこに書かれた文章も、あくまで行動の指針として扱われます。
Claudeは起動時に、作業ディレクトリとその親階層にある指示ファイルを読み込みます。サブディレクトリの指示は、その中のファイルを扱う際に読み込まれます。各ファイルの内容は組み合わされるため、より限定的なファイルを追加しても、別の場所にある矛盾した指示が消えるわけではありません。ユーザー用とプロジェクト用の指示は、整合性を保ってください。読み込みの仕組み
CLAUDE.mdの書き方:小規模なプロダクトチーム向けのひな形
繰り返し起きるミスを防ぐための決定事項を書きます。以下の例は、pnpmを使うTypeScriptのプロダクトで、lint、typecheck、testスクリプトがすでに定義されていることを前提としています。コミットする前に、コマンドとパスを自分のリポジトリで動作確認済みのものへ置き換えてください。
各セクションには、設けた理由を1行で添えています。これはチーム規約の提案であり、Anthropicのデフォルト設定ではありません。
# Product Team Instructions
## Product Intent
Why: Keep implementation tied to the customer problem.
- Read the task's acceptance criteria before changing code.
- Ask when missing product behavior would change the solution.
## Working Commands
Why: Make verification repeatable across teammates and sessions.
- Use pnpm for this repository; keep pnpm-lock.yaml consistent.
- Run pnpm lint and pnpm typecheck for application changes.
- Run pnpm test for behavior changes; report any checks not run.
## Change Boundaries
Why: Keep reviews small and dependencies deliberate.
- Follow nearby patterns before adding a new abstraction.
- Ask before adding a runtime dependency or changing public APIs.
- Keep unrelated cleanup out of the change.
## Data and Migrations
Why: Make data changes reviewable and reversible where possible.
- Add schema changes through the existing migration workflow.
- Describe compatibility and rollback concerns in the handoff.
- Use synthetic data in examples and tests.
## Quality
Why: Catch user-visible regressions before review.
- Add a focused regression test when fixing a behavior bug.
- Check loading, empty and error states when changing UI flows.
- State remaining uncertainty instead of calling unchecked work done.
## Project References
Why: Point to maintained decisions without copying the whole wiki.
- Read docs/product-decisions.md when product behavior is unclear.
- Read docs/release-checklist.md before preparing a release.この例にあるドキュメントへの参照は、必要なときに読むよう促す通常の指示です。該当するドキュメントを作るか、パスを置き換えてください。ここでは意図的に、自動インポートを使っていません。
ファイルを保存したら、リポジトリからセッションを開始し、/contextで起動時のメモリ一覧を確認します。指示ファイルを開いて編集するには/memoryを使います。その後、実際の小さなタスクをClaudeに任せ、コマンドや作業範囲の指定が役立っているか確かめてください。メモリの確認方法
ファイルの種類ごとのルールは、共通の指示書から分ける
ほとんどのタスクで必要にならないルールは、.claude/rules/へ移します。たとえば、フロントエンドの変更に、APIハンドラーの規約をすべて持ち込む必要はありません。
pathsヘッダーを付けた.claude/rules/api.mdを作成します。globはファイル名に一致させるパターンです。src/api/**/*.tsなら、そのディレクトリとサブディレクトリ内のTypeScriptファイルが対象になります。
---
paths:
- "src/api/**/*.ts"
---
# API Rules
- Validate external input before passing it to application logic.
- Use the existing error response format.
- Add a focused test when changing an endpoint's behavior.このパターンによって、指示をコンテキストへ取り込むタイミングが決まります。pathsがなければ、そのルールは起動時に無条件で読み込まれます。長い指示書を複数のルールファイルへ分割するだけでは、コンテキストの節約にはなりません。読み込む対象を限定して初めて効果が出ます。パスを指定したルール
インポートは文章を共有する仕組み。コンテキストの量は減りません
CLAUDE.md内に@docs/team-conventions.mdのようなインポートを書くと、起動時にそのファイルもコンテキストへ取り込まれます。相対パスの起点は、インポートを書いたファイルです。実際にインポートさせる記述は、Markdownのバッククォートやコードフェンスの外に置いてください。その内側では、単なる文字列として扱われます。プロジェクトのインポート先が作業ディレクトリの外にある場合は、承認を求められます。インポートの書式
別のチームが管理する短い規約を毎回のセッションで使うなら、インポートが適しています。長いリリースチェックリストには、ひな形で示したような通常の参照を使いましょう。インポートで指示書の構成は整理できますが、Claudeが起動時に読む量は減りません。
AGENTS.mdがすでにある場合、指示の管理元を一つにするには?
Claude Codeは、バージョン2.1.277以降で対応機能が利用できる場合、CLAUDE.mdの代わりにAGENTS.mdを直接使えます。ただし、デフォルトの動作には重要な条件があります。作業ディレクトリとその親階層に、CLAUDE.md、.claude/CLAUDE.md、CLAUDE.local.mdのいずれも存在しないことです。ユーザー用と組織用の指示ファイルは、この代替読み込みを妨げません。AGENTS.mdの読み込み
そのため、CLAUDE.local.mdは混乱の原因になりやすいファイルです。個人用のプロジェクトメモを追加しただけで、自分の環境で読み込まれる共有指示ファイルが変わることがあります。
両方のファイルが必要なら、/configを開き、Project instructionsをclaude-md-and-agents-mdに設定します。または、同じディレクトリにあるCLAUDE.mdへ@AGENTS.mdと記述します。このインポートは、AGENTS.mdの直接読み込みに対応していない環境でも使えます。チームのルールを複製し、二重に管理するのは避けてください。選び方はAGENTS.mdの設定ガイドで詳しく解説しています。
Claude Codeのメモリ機能:学習したメモは自動メモリへ
自動メモリを使うと、Claudeは役立つ好みや修正、プロジェクトの背景情報を会話の間で保存できます。何を残すかはClaudeが判断するため、何も保存しないセッションもあります。ローカルのセッションでは、デフォルトで有効です。自動メモリについて
デフォルトの保存先は~/.claude/projects/<project>/memory/です。同じマシン上では、同一リポジトリのworktreeとサブディレクトリがこのメモリディレクトリを共有します。worktreeは、そのリポジトリの別のチェックアウトです。そこでブランチの作業を始めても、独立したノートが用意されるわけではありません。また、これらのファイルは、チームのほかのメンバーや別のマシン、クラウド環境へ自動的には共有されません。保存場所
索引になるのがMEMORY.mdです。セッション開始時にClaudeが読み込むのは、先頭から200行または25KBの、先に達した上限までです。トピックごとの詳細ファイルは、必要に応じて読み込まれます。この上限は、起動時に読み込む索引の量を示すものであり、保存できるメモリ全体の容量ではありません。自動メモリの読み込み方

メモリ操作の入り口には/memoryを使います。保存場所の一覧表示、エディターでのファイル表示、自動メモリフォルダーへのアクセス、有効・無効の切り替えができます。起動時にどのCLAUDE.mdやルールファイルが読み込まれたかを確かめるには、/contextを使ってください。メモリの操作
保存先は明確に伝えましょう。「作業の引き継ぎは短めが好みだと覚えておいて」は、学習したメモを残す依頼です。「必須のテストコマンドをCLAUDE.mdに追加して」は、管理対象の指示を更新する依頼です。チーム全員に必要なルールを、一人の開発者のホームディレクトリにあるメモへ依存させてはいけません。
通常のサブエージェントにも、このノートが渡るとは考えないでください。メインの会話の自動メモリは、通常のサブエージェントには読み込まれません。ただし、親の会話を引き継ぐフォークは例外であり、サブエージェントに専用のメモリを設定することもできます。エージェント間で作業を分担する際は、Claude Codeのサブエージェントガイドも参照してください。サブエージェントでのメモリの動作
自動メモリを無効にするには?
目的に合った方法を選んでください。
- ユーザー単位の設定:
/memoryを開き、自動メモリをオフにします。この切り替えは、~/.claude/settings.jsonのautoMemoryEnabledに保存されます。 - **特定のプロジェクト:**そのプロジェクトの設定に
"autoMemoryEnabled": falseを指定します。共有設定には.claude/settings.json、自分の環境だけで上書きする場合は.claude/settings.local.jsonを使います。 - 環境変数で制御して起動:
CLAUDE_CODE_DISABLE_AUTO_MEMORY=1を設定します。
これらは、公式に記載された無効化の方法と設定ファイルの場所です。自動メモリを無効にしても、別の仕組みであるCLAUDE.mdの指示は引き続き使えます。過去のメモも消したい場合は、該当するMarkdownファイルを確認し、明示的に削除してください。
月に一度、自動メモリを整理する
Claudeが次の作業へ持ち越す内容を、短時間で編集・点検する機会と考えてください。月に一度という頻度は、チームの習慣としての提案です。製品の要件ではありません。
/memoryから自動メモリフォルダーを開きます。MEMORY.mdを読み、そこにある参照をたどって実際のメモを確認します。- **期限切れの情報を削除します。**すでに過ぎた締め切り、取りやめた計画、適用されなくなった例外を取り除きます。判断がつかないメモは、現在のプロジェクトの状態と照合します。
- **重複した修正をまとめます。**少しずつ異なる記述をいくつも残さず、正確な記述に一本化します。
- **継続して使うチームの決定事項を移します。**全員に必要な規約は、コミット対象の
CLAUDE.mdや適用範囲を限定したルールへ移し、重複する個人用メモを削除します。 - 索引を短くします。
MEMORY.mdには短い参照を置き、詳細はトピック別ファイルに書きます。行数とバイト数の両方を、起動時の読み込み上限と照らし合わせてください。 - 新しいセッションで試します。
/contextで指示の一覧を確認し、次の実際のタスクで古い助言が出てこないか確かめます。
自動メモリのファイルは編集可能なMarkdownです。会話履歴の保持・削除に伴って、自動的に整理されるわけではありません。不要になったメモを取り除く役割は、引き続き誰かが担う必要があります。編集と保存期間
チーム開発で効果を期待できる5つの場面
同じ修正の繰り返しで、すでにレビューが滞っているところから始めましょう。以下は、小規模なプロダクトチームで役立つ可能性が高い順に並べた、ワークフローの提案です。
この運用から考えられる2つの小さな事業アイデア
最も有望なのは、リポジトリの指示ファイルを監査するサービスです。コマンドを検証し、指示の矛盾を見つけ、短い指示書と適用範囲を限定したルールを提案するレビューなら、小規模なチームがお金を払う可能性があります。最小限の成果物は、レビュー済みのプルリクエストと、繰り返し使える監査チェックリストです。DataForSEOの推計では、「claude project instructions」の米国での月間検索数は260件です。ただし、この広い検索語にはClaude Code以外への関心も含まれます。見つけてもらう余地を示す数値であり、購入者数ではありません。汎用テンプレートは簡単にコピーできるため、有料サービスとしての価値は、そのリポジトリに即した判断に置く必要があります。
ローカルのメモリを点検するレポートは、多数のリポジトリを並行して扱うチームに役立つ可能性があります。初期版では、大きすぎる索引、参照先が見つからないトピック、古くなった可能性のあるメモを指摘し、修正内容は開発者が確認する形が考えられます。DataForSEOの推計では、「claude code memory」の米国での月間検索数は1,300件です。これは課題への関心を示すもので、このツールへの需要を示すものではありません。大きな難点もあります。ファイルの古さだけでは、ある決定がすでに無効かどうかはわかりません。内容を踏まえた判断は、プロジェクトを知る人に委ねてください。
どちらの推計も、2026年10月11日に、当サイトのDataForSEOリサーチ連携を通じて取得した、米国・英語のキーワード概要データに基づいています。ここで挙げたものは製品のアイデアであり、Claude Codeに搭載された機能ではありません。小さなリポジトリが一つなら、どちらかを購入・開発する前に、まずはファイルと月次レビューで運用を始めましょう。
メモリは判断材料。操作を強制的に止める仕組みは別に用意する
CLAUDE.mdに「絶対にしない」と書いても、その操作が実行不可能になるわけではありません。自動メモリや組織全体の指針も同じです。Claudeは曖昧な指示を誤解することも、矛盾する指示に出会うこともあります。Anthropicの注意事項
Claudeの判断にかかわらず操作を止める必要があるなら、ツール操作の前に実行される制御であるPreToolUseフックを使います。保護対象のファイルについて注意書きを添えれば、チームの意図は伝えられます。ただし、実際に操作を止めるには、制御の実装が必要です。設定方法はClaude Codeのフック設定ガイドで解説しています。
コンテキストの量を考えるときは、人が管理し続けられる短さを目指してください。Anthropicは、個々のCLAUDE.mdを200行未満に収めることを推奨しています。ただし、これはMEMORY.mdの起動時の読み込み上限とは別の話です。決まった分量があると思い込んでひな形を水増ししたり、すべてをインポートへ移して読み込みコストが下がったと考えたりしないでください。効果的な指示の書き方
小規模チームでよくある疑問
使いやすいCLAUDE.mdには、何を書けばよいですか?
動作確認済みのコマンド、Claudeが繰り返し見落とす規約、レビュー上の制約、継続的に管理されているプロジェクトの決定事項への参照から始めます。上のひな形を自分のリポジトリに合わせて調整してください。実際のミスを防ぐ役割のないセクションは削除します。
個人の好みは、ユーザー用とプロジェクト用のどちらのCLAUDE.mdに書くべきですか?
複数のプロジェクトに共通する好みは~/.claude/CLAUDE.mdへ、リポジトリで共有する指針はコミット対象のプロジェクトファイルへ書きます。プロジェクト固有の個人用メモにはCLAUDE.local.mdを使います。ただし、このファイルはデフォルトのAGENTS.mdへの代替読み込みに影響することを忘れないでください。
Claude Codeのメモリは、別のセッションやworktreeにも引き継がれますか?
自動メモリはセッションをまたいで保持され、デフォルトでは同じマシン上の同一リポジトリのworktree間でも共有されます。ただし、自動的にチーム共有のノートになるわけではありません。長く使うチームの指示は、プロジェクトファイルに書いてコミットしてください。
自動メモリは有効にしておく価値がありますか?
役立つ修正を何度も伝え直す必要があり、保存されたメモを見直せるのであれば、価値があります。この動作がワークフローに合わなければ、無効にしてください。自動メモリは、人が管理するチームの指示書を補うものです。プロジェクトの決定事項が変わったときは、保存内容を確認しましょう。
週明けに着手するなら、直近のセッションで伝えた修正を振り返りましょう。繰り返し登場するチームの決定事項を一つのCLAUDE.mdにまとめ、レビューしてから小さなタスクで試します。月次のメモリ見直しも、チームのカレンダーに入れておきましょう。
これらの規約を、安定した開発ワークフローに落とし込む支援が必要な場合は、AI本番運用システムの構築サービスをご覧ください。
- 公開日
- カテゴリー
- Build
- 言語







