Claude Code ルール設定ガイド:CLAUDE.mdと自動メモリの使い分け

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

公開日

Claude Code ルール設定ガイド:CLAUDE.mdと自動メモリの使い分け

Claude Code ルール設定の基本は、チームの作業ルールを一度まとめてClaude Codeに渡しておくことです。そうすれば、次のセッションも適切なコマンドや規約、作業範囲を踏まえて始められます。チームで決めたことは短いCLAUDE.mdにまとめ、役立つ修正は自動メモリに残します。ただし、昨日だけの例外が明日の誤った助言にならないよう、保存された内容は見直しましょう。

これにより、同じ前提を何度も説明する手間を減らせます。仮に、開発者4人がそれぞれ週に5回のセッションを開き、毎回3分かけて前提を説明しているとすれば、合計で週60分を費やしている計算です。共有の指示ファイルがあれば、その前提を一か所で管理できます。説明の繰り返しがどれだけ減ったかを、ファイルのメンテナンスにかかる時間と比べて判断してください。必ず時間を節約できるというわけではありません。

Claude Code ルール設定の基本:CLAUDE.mdとは

CLAUDE.mdは、プロジェクトや個人のワークフロー、組織向けの指示を記述するMarkdownファイルです。Claude Codeはこのファイルを読み込みます。チームの共通方針をまとめた指示書と考えるとわかりやすいでしょう。一方、自動メモリはClaudeが傍らで書き留める作業ノートです。指示書を管理するのは人、ノートを書くのはClaudeです。どちらも判断に使うコンテキストになります。Anthropicのメモリガイド

使い分けの基準は、セッションが変わっても守るべきことかどうかです。必須のテストコマンドは指示書に書きます。「説明が詳しすぎた」というフィードバックは、学習した好みとして残せます。そして、今取り組んでいるタスクは会話の中で伝えます。

保存先・設定先ここに置くべき内容
CLAUDE.md承認済みのマイグレーション手順など、ほかのメンバーにも必要な継続的な指示。
.claude/rules/APIハンドラーなど、特定のファイルだけに関係する指示。
自動メモリ次の会話でも役立ちそうな修正やプロジェクトの背景情報。
権限設定またはフックツールの操作に技術的な制御が必要な場合。

この分類は公式のディレクトリガイドに沿っています。最初から大きな.claudeフォルダーを用意する必要はありません。まずは指示書を作り、別のファイルに明確な役割ができたときに追加します。

CLAUDE.mdと自動メモリがセッションのコンテキストに取り込まれる構成図。ツール操作の前には独立したPreToolUseのゲートが置かれています。
指示と学習したメモは、セッションの判断材料になります。操作を止める仕組みは、PreToolUseフックとして別に設けます。

CLAUDE.mdはどこに置く?プロジェクト・個人・組織の使い分け

小規模なチームなら、リポジトリのルートにプロジェクト用のファイルを一つ置き、コミットするところから始めます。個人の好みはユーザー用のファイルに入れ、ほかのメンバーへ意図せず適用されないようにします。

適用範囲ファイルの場所主な用途
プロジェクト./CLAUDE.mdまたは./.claude/CLAUDE.mdコマンド、規約、チームの決定事項を共有し、バージョン管理に含めます。
ユーザー~/.claude/CLAUDE.md自分のマシン上で、複数のプロジェクトに共通する好みを指定します。
プロジェクト内の個人用./CLAUDE.local.mdそのプロジェクトに関する個人用メモです。.gitignoreに追加してください。
組織・macOS/Library/Application Support/ClaudeCode/CLAUDE.md組織で一元的に配布する指針を置きます。
組織・LinuxまたはWSL/etc/claude-code/CLAUDE.md組織で一元的に配布する指針を置きます。
組織・WindowsC:\Program Files\ClaudeCode\CLAUDE.md組織で一元的に配布する指針を置きます。

これらは公式に記載された適用範囲と保存場所です。管理された組織用ファイルを個人の設定で読み込み対象から外すことはできません。ただし、そこに書かれた文章も、あくまで行動の指針として扱われます。

Claudeは起動時に、作業ディレクトリとその親階層にある指示ファイルを読み込みます。サブディレクトリの指示は、その中のファイルを扱う際に読み込まれます。各ファイルの内容は組み合わされるため、より限定的なファイルを追加しても、別の場所にある矛盾した指示が消えるわけではありません。ユーザー用とプロジェクト用の指示は、整合性を保ってください。読み込みの仕組み

CLAUDE.mdの書き方:小規模なプロダクトチーム向けのひな形

繰り返し起きるミスを防ぐための決定事項を書きます。以下の例は、pnpmを使うTypeScriptのプロダクトで、lint、typecheck、testスクリプトがすでに定義されていることを前提としています。コミットする前に、コマンドとパスを自分のリポジトリで動作確認済みのものへ置き換えてください。

各セクションには、設けた理由を1行で添えています。これはチーム規約の提案であり、Anthropicのデフォルト設定ではありません。

Markdown
# 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ファイルが対象になります。

Markdown
---
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.mdは起動時の読み込み口を通り、200行または25KBの先に達した上限まで取り込まれます。トピック別ファイルには、必要に応じて読み込む別の経路があります。
MEMORY.mdは短い索引にします。起動時に読み込む範囲には上限があり、トピック別の詳細ファイルは必要なときに読み込まれます。

メモリ操作の入り口には/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が次の作業へ持ち越す内容を、短時間で編集・点検する機会と考えてください。月に一度という頻度は、チームの習慣としての提案です。製品の要件ではありません。

  1. /memoryから自動メモリフォルダーを開きます。MEMORY.mdを読み、そこにある参照をたどって実際のメモを確認します。
  2. **期限切れの情報を削除します。**すでに過ぎた締め切り、取りやめた計画、適用されなくなった例外を取り除きます。判断がつかないメモは、現在のプロジェクトの状態と照合します。
  3. **重複した修正をまとめます。**少しずつ異なる記述をいくつも残さず、正確な記述に一本化します。
  4. **継続して使うチームの決定事項を移します。**全員に必要な規約は、コミット対象のCLAUDE.mdや適用範囲を限定したルールへ移し、重複する個人用メモを削除します。
  5. 索引を短くします。MEMORY.mdには短い参照を置き、詳細はトピック別ファイルに書きます。行数とバイト数の両方を、起動時の読み込み上限と照らし合わせてください。
  6. 新しいセッションで試します。/contextで指示の一覧を確認し、次の実際のタスクで古い助言が出てこないか確かめます。

自動メモリのファイルは編集可能なMarkdownです。会話履歴の保持・削除に伴って、自動的に整理されるわけではありません。不要になったメモを取り除く役割は、引き続き誰かが担う必要があります。編集と保存期間

チーム開発で効果を期待できる5つの場面

同じ修正の繰り返しで、すでにレビューが滞っているところから始めましょう。以下は、小規模なプロダクトチームで役立つ可能性が高い順に並べた、ワークフローの提案です。

場面設定・運用期待できる効果
毎回のセッションで、チームのテストコマンドを説明し直している動作確認済みのコマンドと、報告してほしい内容をCLAUDE.mdに書いてコミットします。防げる検証漏れの指摘に、レビュアーが費やす時間を減らせます。
フロントエンドとAPIを扱うチームで、規約が食い違っているAPIの指示に、API用のパスパターンを指定します。UIの作業に、無関係な指示が入り込みにくくなります。
開発者が複数のコーディングエージェントを使っているAGENTS.mdを管理し、直接読み込みか明示的なインポートを選びます。一度の編集で共有指針を更新でき、複製した内容のずれを防げます。
一人の開発者が複数のworktreeを行き来している同じリポジトリでメモリを共有することを踏まえて、自動メモリを見直します。特定のブランチだけのメモを、恒久的なルールと取り違えにくくなります。
新しいメンバーがClaude Codeを使い始めるチームの指示書をコミットし、/memoryと/contextの使い方を伝えます。過去のチャットを読み直して前提を組み立てる代わりに、開始時のコンテキストを確認できます。

この運用から考えられる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
decision model比較2026:Jevの代替7選を料金と導入条件で選ぶ

decision model比較2026:Jevの代替7選を料金と導入条件で選ぶ

Jevの代替となるdecision modelを、料金・入力形式・ライセンス・実行環境で比較。Perplexity、Cloudflare Clef、Microsoft、OpenAI、Liquid d1、Strandsの向き不向きを整理し、月額費用の試算と移行時の確認点から、自社の判断業務に合う候補を選べます。2026年10月11日Build
OpenAI Decisions APIの使い方:問い合わせの自動振り分けと料金

OpenAI Decisions APIの使い方:問い合わせの自動振り分けと料金

OpenAI Decisions APIの使い方を、問い合わせチケットの自動振り分けを軸に解説します。三つのリクエスト例、回答拒否への対応、信頼度のしきい値、料金と制約を整理。既存のLLM呼び出しやルール処理を残すべき場面も含め、移行の手間に見合うかを実データで判断するための手順を紹介します。2026年10月11日Build
Claude Code Remote Controlの使い方:スマホ接続とエラー対処

Claude Code Remote Controlの使い方:スマホ接続とエラー対処

Claude Code Remote Controlで、パソコンの作業をスマホやブラウザから続ける方法を解説します。CLI・VS Code・Desktopの設定、対応プラン、通知、ログインや接続エラーの対処まで整理。ローカルで実行される処理と、Anthropicに保存されるセッション記録の違いも確認できます。2026年10月9日Build
Cursorのスマホ操作ガイド:iPhoneでRemote Controlを設定する

Cursorのスマホ操作ガイド:iPhoneでRemote Controlを設定する

Cursorをスマホから操作したい開発者向けに、iPhoneとPCのペアリング手順、スリープを防ぐ設定、Enterpriseの利用条件を解説します。ローカルとクラウドの実行環境、料金の考え方、Claude CodeやCodexとの違いも整理し、離席中の進捗確認や短い指示に役立つ活用例を紹介します。2026年10月9日Build
Firecrawl 料金ガイド2026:プラン別の実費とクレジットの計算方法

Firecrawl 料金ガイド2026:プラン別の実費とクレジットの計算方法

Firecrawlの料金プランを、クレジット消費と実際の処理量から比較します。通常ページの取得、JSON抽出、毎週のクロールはいくらかかるのか。月払い・年払い、追加クレジット、失敗ページの課金、無料枠、セルフホストや代替サービスまで整理し、パイプラインに合うプランと支出上限の決め方を解説します。2026年10月9日Build
Claude Code 料金比較:GitHub Copilotとの違いと2026年の選び方

Claude Code 料金比較:GitHub Copilotとの違いと2026年の選び方

Claude CodeとGitHub Copilotの料金・利用制限・対応モデルを比較。個人開発者と10人チームの費用、ターミナルとエディターでの使い勝手、チーム管理やデータの扱いまで整理します。追加利用料や上位プランへの切り替え、併用時の月額費用を押さえ、自分の開発環境に合う選び方を解説します。2026年10月8日Build
LangGraphとCrewAIを比較:承認フロー・状態管理・料金で選ぶ

LangGraphとCrewAIを比較:承認フロー・状態管理・料金で選ぶ

LangGraphとCrewAIを、企業調査から営業メールの下書き、人による承認までの同じ業務で比較します。状態管理とメモリ、MCP連携、可観測性、ホスティング料金の違いをコード例と費用試算で解説。個人開発、スタートアップ、大企業それぞれの選び方と、本番運用で必要になる復旧・移行の判断材料が分かります。2026年10月7日Build
MCPサーバーをPythonで自作する:注文照会から認証・公開まで

MCPサーバーをPythonで自作する:注文照会から認証・公開まで

PythonでMCPサーバーを自作し、読み取り専用の注文照会をMCP Inspectorで検証。Claude CodeとCursorへの接続から、OAuth認証付きHTTPサービスの構築、RenderやCloudflare Workersへの公開までを、コードと料金例で解説します。権限設計とログ管理も確認できます。2026年10月7日Build
ニュースレター

毎週日曜、一通の手紙。動くシステムの話。感想戦ではなく。

週刊。スパムなし。いつでも解除できます。