CLAUDE.md ベストプラクティス：Claudeに無視されないための9つのルール（2026年）

CLAUDE.mdベストプラクティス：Claudeに無視されなくなる9つのルール（2026年）

CLAUDE.mdベストプラクティスを扱う記事の大半は、テンプレートを提示して終わりだ。しかし、あなたが先週書いたそのファイルは、おそらくすでに無視されており、理由もわからないままだ。解決策が「ルールを追加する」ことであるケースはまれで、大抵はその逆である。私たちは最近のすべてのクライアントプロジェクトでClaude Codeを導入してきたが、実際に成果を動かしているのが、この9つのルールだ。Claudeのファイル読み込みの仕組みに合った階層構造、絶対に破れない指示の予算、AGENTS.mdに関する判断、そしてClaudeがセッション中にあなたのファイルをそっと無視し始める6つの理由である。

主なポイント

• CLAUDE.mdはClaude Codeのコンテキストに読み込まれるプロジェクトメモリです。200行以内に抑えないと、ルールの脱落が始まります。
• ファイルは上から順に読み込まれます：グローバル、プロジェクトルート、サブディレクトリ（遅延読み込み）、そしてCLAUDE.local.md（個人用、gitignore対象）。
• CursorやCopilotも使っている場合はAGENTS.mdを使用してください。CLAUDE.mdからAGENTS.mdへのシンボリックリンクで両方に対応できます。
• Claudeがファイルを無視する場合、90%は長すぎる、曖昧、または「なぜ」が欠けているのが原因です。

CLAUDE.mdが実際にしていること（そして、なぜそれが重要なのか）

要するに： CLAUDE.mdとは、Claude Codeが毎セッションの開始時にプロジェクトメモリとして読み込むMarkdownファイルのことです。これはシステムプロンプトでもフックでもスキルでもなく、Claudeをチームの規約へとそっと導くための助言的なコンテキストです。ドキュメントというよりも、AIペアプログラマーが実際に読み込む設定ファイルだと捉えてください。

多くのチームはCLAUDE.mdをREADMEのように書いてしまいます。これが最初の間違いです。READMEは、ざっと読んだり読み飛ばしたりできる人間に向けてプロジェクトを説明するものです。CLAUDE.mdはセッション開始時にClaude Codeによって丸ごと消費され、一行一行がトークンと遵守のコストになります。これはドキュメントというよりも、設定ファイルやテストのフィクスチャ群に近いものです。

また、Claudeを導く方法はこれだけではありません。フックは決定的なアクション（フォーマットやコミットのブロック）を実行します。スキルは再利用可能なワークフローをまとめます。CLAUDE.mdはその中間に位置する助言的なコンテキストであり、Claudeはそれを評価し、時には上書きし、書きすぎれば確実にその一部を忘れます。この区別は以下すべてを支える土台であり、CLAUDE.mdが銀の弾丸ではなく、コンテキストエンジニアリングというより広い実践の中の一つのツールである理由です。

ルール #1：ドキュメントではなくコードとして扱う。 バージョン管理し、PRでレビューし、肥大化したモジュールをリファクタリングするのと同じように削ぎ落としてください。AnthropicのCLAUDE.mdガイドによれば、このファイルは他のシステム指示と同じ優先度で読み込まれます。つまり、6か月前の古いルールが、今もなおすべての応答を能動的に形作っているということです。

CLAUDE.md の読み込み方法：4段階の階層構造

要するに： Claude Code は CLAUDE.md を4つの階層から読み込みます。グローバル（~/.claude/CLAUDE.md）、プロジェクトルート、個人用の上書きに使う CLAUDE.local.md、そして Claude がそのディレクトリ内のファイルを読み取ったときに初めて**遅延読み込み（レイジーロード）**されるサブディレクトリファイルです。兄弟関係にあるサブディレクトリ同士は互いの CLAUDE.md を参照しないため、claude code memory のスコープは厳密に保たれます。

この階層構造は CLAUDE.md の中で最も誤解されている部分であり、SERP の上位5件中0件しか深く掘り下げていないポイントです。実際に内部で何が起きているのかを見ていきましょう。

押さえておきたい用語が2つあります。レイジーローディング（遅延読み込み）と兄弟ディレクトリの分離です。

レイジーローディングとは、サブディレクトリの CLAUDE.md が、Claude が実際にそのディレクトリ内のファイルを開くまで Claude のコンテキストに入らないことを意味します。「ログインのバグを直して」と依頼して Claude が backend/ にしか触れない場合、frontend/CLAUDE.md は一切読み込まれません。これは良いことで、コンテキストウィンドウをクリーンに保てますが、重要なルールをサブディレクトリに置いて常に適用されると期待しているチームにとっては落とし穴になります。

兄弟ディレクトリの分離はその帰結です。frontend/CLAUDE.md と backend/CLAUDE.md は互いを読み込むことがありません。共有するのはプロジェクトルートにあるものだけです。そのため、フロントエンドのルールとバックエンドのルールが矛盾していても問題ありません。規約を共有する必要がある場合は、ルートファイルに引き上げてください。

CLAUDE.local.md は逃げ道（エスケープハッチ）です。読み込まれますがコミットされないため、「自分は pnpm を使いたいが、チームは npm に標準化している」といったスタイルの上書きに最適です。注意点として、自動では Gitignore されません。自分で追加する必要があります。それを忘れると、個人用のルールをチームのリポジトリにコミットしてしまうことになります。 ルール #4：指示は Claude が実際に読み込む場所に配置する。 React コンポーネントのスタイルルールはルートではなく frontend/CLAUDE.md に記述すべきである。データベースマイグレーションのルールは backend/ に記述すべきである。Anthropic Memory のドキュメント（2025年11月更新）でもこれが確認されており、遅延読み込みの動作は意図的かつ不可欠なものである。

CLAUDE.md に何を書くか（そして何を書かないか）

要するに： CLAUDE.md に書くのは、Claude がコードから推測できない事柄です。ビルドコマンド、命名規則、チームが過去に痛い目を見たアンチパターン、そして各ルールの理由です。書かなくていいのは、README にある内容、package.json にある内容、そして毎週変わるルールです。Claude Code の指示は、テスト可能かつ具体的であるべきです。

以下は、実際に力を発揮する最小限の CLAUDE.md です：

# プロジェクト：techsy-app
## コマンド
- ビルド: `pnpm build`(Turbopack — Webpack のフラグは適用されません)
- テスト: `pnpm test --run`(Jest ではなく Vitest を使用しています)
- Lint: `pnpm lint`(エラーだけでなく警告でも CI が失敗します)
## 規約
- サーバーコンポーネントをデフォルトとする。`'use client'` は本当に必要なときだけ追加する。
  理由：前四半期、過度なクライアント化により LCP が 8 秒に達したため。
- データベースアクセスは `lib/db/` のヘルパー経由でのみ行う — ルート内で生の SQL は絶対に使わない。
  理由：行レベルセキュリティのポリシーはこれらのヘルパー内に実装されているため。
- テストは `*.test.ts` としてテスト対象ファイルの隣に配置する。
## やってはいけないこと
- 先に PR にコメントを投稿せずに、新しい依存関係を追加しないでください。
- `any` は使わないでください — `unknown` を使って絞り込んでください。
## 確認する場所
- スキーマ: `db/schema.ts`
- 認証フロー: `lib/auth/README.md`

Now compare that to the anti-pattern version most teams ship:

# プロジェクトのルール

- きれいで保守しやすいコードを書く。
- ベストプラクティスに従う。
- TypeScriptを適切に使う。
- テストが通ることを確認する。
- 既存のパターンと一貫性を保つ。
- 複雑なロジックにはドキュメントを書く。

2番目のファイルは間違っているわけではない。ただ、無意味なのだ。Claudeはもともとクリーンなコードを書こうとしている。「一貫性を保つ」では、どのパターンと一貫性を保つべきかClaudeに伝わらない。Anthropicのエンジニア、Boris Chernyが公開している例は、最初のスタイル、つまり具体的なコマンド、明示的なツール名、そしてコードベースだけでは読み取れない判断の理由を重視する方向に大きく振れている。

ルール #2：願望ではなく、具体的に書く。 「きれいなコードを書く」は願望だ。「デフォルトでServer Componentsを使い、本当に必要なときだけ'use client'を追加する」は検証可能だ。同じ原則が優れたプロンプトエンジニアリングの根底にもある。具体的で検証可能な指示は、プロンプトの中にあってもCLAUDE.mdの中にあっても、曖昧な願望に勝る。

ルール #3：すべてのルールの理由を説明する。 「理由」は飾りではない。Claudeがエッジケースを判断するための材料だ。理由付きのルール（「クライアントコンポーネントの多用でLCPが8秒になった」）は、類似の状況にも汎化できる。理由のないルールは、コンテキストが変わった瞬間に無視される。このパターンはBuilder.ioのCLAUDE.mdガイドでも紹介されている。

なぜClaudeはあなたのCLAUDE.mdを無視するのか？指示の予算

要するに： Claudeは悪意があるのではなく、注意力が足りなくなっているのです。おおよそ80行を超えるとルールの脱落が目立ち始め、200行を超えると大きなブロックが完全に無視され、500語を超える高密度のルールでは遵守率が崩壊します。解決策は指示の予算です。すべての行がclaude code memoryとルールごとの遵守率に対するコストだと考えてください。

最近の研究は、本番環境のユーザーが繰り返し発見してきたことを裏付けています。指示への追従性は、ルールの数に対して非線形的に劣化するということです。指示追従能力に関するarxiv論文 2507.11538は、ルールを積み重ねるほどルールごとの遵守率が低下することを示しており、本番環境におけるCLAUDE.mdについてのHumanLayerの分析も同じ知見を裏付けています。

つまり、ルールを1つ追加するたびに、他のすべてのルールが守られる確率がわずかに低下するということです。そのため、400行のCLAUDE.mdは100行のものの4倍効果があるわけではありません。むしろ効果は低くなることが多く、実際にあなたが重視しているルールが、3ヶ月前の金曜日に書いて一度も削除していないルールによって薄められてしまうのです。

私たちのCLAUDE.mdファイルでは、150行を超えたあたりから遵守率の目に見える低下が始まります。250行目までには、Claudeがセクション全体をスキップするのを見てきました。そのため、私たちは上限を設けています。

wc -l CLAUDE.md

これがツールのすべてです。実行してください。200を超えていたら、予算オーバーです。私たちがクライアントに提供している厳格なルールは次のとおりです。

CLAUDE.mdを200行の予算として扱え。すべての行が遵守率のコストになる。重要なところに使え。

ルール#1の強化：短く保て。 200行未満。高密度のルールは500語未満。自動化ルール（「編集後は必ずprettierを実行する」など）を追加したくなったら、それらはむしろClaude Code hooksに属するものである可能性が高いです。hooksは決定論的であり、指示の予算のトークンを消費しません。

CLAUDE.md、AGENTS.md、.cursorrules、copilot-instructions のどれを使うべきか？

結論から言うと： Claude Code しか使わないなら、CLAUDE.md で問題ありません。2つ以上のエージェントCLI（Codex、Cursor、Copilot、Sourcegraph）を使うなら、AGENTS.md に切り替えて、CLAUDE.md を AGENTS.md へシンボリックリンクしましょう。AGENTS.md は2025年後半にツール横断の標準として登場し、最近のほとんどのエージェントはこれにフォールバックするため、単一のファイルであらゆるエコシステムをまかなえます。

これは、検索結果の上位5件が実際に答えている問いです。対応表は次のとおりです。

デュアルターゲットの trick はたった1行です。

ln -s AGENTS.md CLAUDE.md

これで完了です。これで Claude Code、Codex、その他 AGENTS.md 対応のツールはすべて同じファイルを読み取ります。一度更新すれば、すべてのエージェントに反映されます。AGENTS.md の仕様はオープンで、意図的にミニマルに設計されており、慣習的なセクションを持つ単なる markdown です。

実運用での注意点も2つあります。1つ目：チームに Cursor のパワーユーザーがいる場合、Cursor の .cursorrules は異なるアプローチを取ります。単一ファイルで、階層構造がなく、より厳格なフォーマットです。チームによっては両方を併用し、AGENTS.md には共有ルールを、.cursorrules には Cursor 固有の癖を記述します。2つ目：Copilot の .github/copilot-instructions.md は AGENTS.md にフォールバックしないため、Copilot を多用するチームは別途ファイルを用意する必要があります。

エージェントスタックをゼロから選ぶ場合は、Claude Code vs Cursor vs Copilot の比較記事で、ユースケースレベルのトレードオフを解説しています。要約すると：モノレポには Claude Code の階層構造が最も強力で、ソロ作業では Cursor の UX が優れ、段階的な導入のしやすさでは Copilot の IDE 統合が依然として最もスムーズです。

ルール #9：2つ以上のエージェントCLIを運用しているなら、AGENTS.md を使うこと。 同じ内容のファイルを2つ管理してはいけません。スタックの大部分が読み取るファイルを1つ選び、残りはシンボリックリンクしましょう。

CLAUDE.md vs フック vs スキル：判断のトライアングル

要するに： CLAUDE.md = 助言的なコンテキスト。フック = 決定的なアクション。スキル = バンドルされた機能。 選び間違えると、フックが処理すべきものにインストラクションバジェットを浪費したり、スキルでしか実現できないものに対して CLAUDE.md のルールを書いてしまったりします。このトライアングルは、CLAUDE.md をスリムに保つための最もコストの低い方法です。

3つのツール、3つの役割。私たちが最もよく目にする間違い：「編集後は必ず prettier を実行する」を CLAUDE.md に書くことです。Claude はそれを読みます。Claude はときどき prettier を実行します。あなたは不満を感じます。修正方法は、その行を CLAUDE.md からフックに移すことです。フックは毎回決定的に発火し、助言的な曖昧さが入り込む余地がないからです。

ルールが必ず発火する必要があるなら、それはフックに属します。Claude がコンテキストに照らして評価できるスタイル設定なら、CLAUDE.md に属します。バンドルされたアセット（テンプレート、スクリプト、プロンプト）を伴う複数ステップのワークフローなら、スキルに属します。

ルール #8：CLAUDE.md vs フック vs スキルを正しく選ぶこと。フックを CLAUDE.md に書くことは、最も一般的なインストラクションバジェットの浪費です。 決定的なアクションは Claude Code フック で設定し、再利用可能なワークフローは Claude スキル としてパッケージ化しましょう。CLAUDE.md はより短くなり、ガードレールはより強固になり、Claude は重要なルールを「忘れる」ことをやめます。

モノレポのパターン：ネストされた CLAUDE.md、@import、そして .claude/rules/

要するに： モノレポでは、ルートの CLAUDE.md を最小限に保ち、ポインタと共通の規約だけを記述します。具体的な内容は apps/*/CLAUDE.md に押し込み、それぞれのサブツリーがスコープの定まったルールを持てるようにします。@import を使えば、.claude/rules/ を介してモジュール化されたルールファイルを共有できます。これは段階的な情報開示（プログレッシブ・ディスクロージャー） であり、Claude は関連する部分だけをその都度読み込みます。

典型的なモノレポの CLAUDE.md ツリー：

.
├── CLAUDE.md                        # 30 lines — points to subdirs and shared rules
├── .claude/
│   └── rules/
│       ├── style.md
│       ├── testing.md
│       └── security.md
├── apps/
│   ├── web/
│   │   └── CLAUDE.md                # Next.js-specific rules
│   └── api/
│       └── CLAUDE.md                # Fastify-specific rules
└── packages/
    └── shared/
        └── CLAUDE.md                # Library author rules

@import 構文を使うと、ルートファイルは共有されるルールの断片を、それらを再記述することなく取り込めます：

# ルート CLAUDE.md

これは Turborepo です。アプリ固有のルールについては、サブディレクトリの CLAUDE.md を参照してください。

@import .claude/rules/style.md
@import .claude/rules/testing.md
@import .claude/rules/security.md
## トップレベルのコマンド
- `pnpm dev` はすべてのアプリを並行して実行する
- `pnpm test` はすべてのワークスペースのテストスクリプトを実行する

これは段階的開示を実践したものです。ルートファイルは 30 行のポインターに過ぎません。各サブディレクトリの CLAUDE.md が、50〜80 行の焦点を絞ったルールを追加します。.claude/rules/ 内のファイルは、複数のサブディレクトリが取り込める規約のまとまりを保持します。何も重複せず、何も見落とさず、そして単一のファイルが指示の許容量を超えることもありません。

先ほど述べた遅延読み込みのルールは、ここではさらに重要になります。Claude が apps/web/Button.tsx で作業するとき、ルートファイルと apps/web/CLAUDE.md、そして @import されたルールファイルだけを参照します。apps/api/CLAUDE.md は参照しません。それこそが要点です。バックエンドの規約がフロントエンドのコンテキストを汚染することはなく、コンテキストウィンドウは使える状態に保たれます。

ルール #6: ルートファイルを 200 行以内に収めるために @import を使う。 Anthropic の Claude Code ベストプラクティスガイドでは、これを標準的なモノレポのパターンとして扱っています。サブエージェントも親の CLAUDE.md のコンテキストを継承するため、ワークフローをネストさせる場合にはこの点を知っておくとよいでしょう。これがサブエージェントの設計とどのように関わるかについては、コンテキストエンジニアリングを参照してください。

Claudeがあなたのファイルを無視する6つの理由（それぞれの対処法）

要するに： ClaudeがCLAUDE.mdを無視するとき、その原因はほぼ間違いなく次の6つのうちの1つです。ファイルが長すぎる、表現が曖昧、「なぜ」が抜けている、コンテキストの圧縮、親ファイルとの競合、ファイル名の誤り。それぞれに60秒でできる対処法があります。変更するたびに新しいセッションでテストすること、これがルール #7です。

1. ファイルが長すぎる（200行超 / 500語超）

wc -l CLAUDE.md を実行してください。200行を超えていたら、思い切って削ぎ落としてください。自動化ルールは hooks に移し、ワークフローは skills に移します。共有するチャンクは .claude/rules/ に分割し、@import で読み込みます。Claude があなたのルールに「従わなくなった」最もよくある原因は、ファイルが時間の経過とともに長くなりすぎて、遵守が静かに崩壊してしまうことです。

2. 曖昧な表現（「クリーンなコードを書け」）

理想論的なルールはすべて、具体的で検証可能なものに置き換えてください。「一貫性を保つ」ではClaudeには伝わりません。「デフォルトでServer Componentsを使用し、フォームやインタラクティブなUIの場合のみ'use client'を追加する」であれば、Claudeは実際に適用できます。

3. 「なぜ」が欠けている

理由のないルールは汎用化しない。そのルールが何から守ろうとしているのかを Claude は把握できないため、いつルールを曲げるべきか推測できない。自明でないルールにはすべて、一行で理由を添える。「API レスポンスを any 型として扱ったことが原因で前期に 3 回のランタイムクラッシュが起きたため、any ではなく unknown を使う」

4. コンテキスト圧縮によって破棄された

セッションが長くなると圧縮が発動し、Claude はウィンドウに収めるため過去のコンテキストを要約するが、その過程で CLAUDE.md の内容が要約されて跡形もなく消えてしまうことがある。対処法は、コンテキストを大量に消費した後に /clear を実行するか、セッションを完全に再起動することだ。まさにこれこそが、GitHub Issue #17530 で繰り返し取り上げられている問題そのものである。

5. 親CLAUDE.mdの競合

グローバルでは「4スペースを使用」、プロジェクトルートでは「2スペースを使用」と書かれている。サブディレクトリには何も書かれていない。Claudeはどちらかを選ぶが、間違った方を選ぶこともある。~/.claude/CLAUDE.mdとプロジェクトルートを監査し、矛盾がないか確認しよう。より具体的な方が優先されるべきだが、それは明示的に指定した場合に限る。

6. ファイルの場所またはファイル名の大文字・小文字が間違っている

Linux と macOS では、Claude.md と CLAUDE.md は別のファイルです。同様に、claude.md と CLAUDE.md も別のファイルになります。パスが正確に ./CLAUDE.md（すべて大文字）であることを確認し、Claude Code をそのファイルがあるディレクトリから起動していることを確認してください。GitHub Issue #668 には、ファイルは存在するのにパスの問題で Claude から認識できなかったケースが数多く報告されています。

ルール #7：新しいセッションでテストする。 CLAUDE.md を変更した後は、必ず新しいセッションを開き、Claude に「CLAUDE.md のルールを要約して」と尋ねてください。要約に漏れがあれば、そのファイルは役割を果たしていません。

10分で始める初めてのCLAUDE.md：5ステップのスターター

要するに： /init を実行して下書きの種を作り、理由付きの実際のルールを6〜10個に絞り、Claudeに知っておいてほしいコマンドを3つ追加し、チームで遭遇したアンチパターンを2つ追加したら、新しいセッションでClaudeにそのファイルを要約させてテストします。合計時間：約10分。この5ステップのレシピは、新しいリポジトリの初日に毎回使っているものです。

1. /init を実行して下書きの種を作る。 Claude Codeの /init コマンドはリポジトリをスキャンし、スターターとなるCLAUDE.mdを書き出します。書き出されたものをそのまま使わないでください。/init の出力は出発点であり、完成されたファイルではありません。正直なところ、生成されたもののほとんどは削除できます。

2. 理由付きの実際のルールを6〜10行に絞り込む。 一般的すぎるものは削除します。READMEに書いてあるものも削除します。コード自体からClaudeが推測できないルールだけを残します。

3. Claudeが知っておくべきコマンドを3つ追加する。 ビルド、テスト、リント。正確なコマンドと、自明でないフラグを含めます。JestではなくVitestを使っているなら、その旨を明記します。

4. このチームで遭遇したアンチパターンを2つ追加する。 実際に起きたものにします。「ランタイムクラッシュが3回起きたので any は使わない」は、「TypeScriptを正しく使う」よりも常に説得力があります。

5. 新しいセッションを開いて検証する。 Claudeに「CLAUDE.mdのルールを要約して」と尋ねます。何か見落としていたら、ファイルが長すぎるか、曖昧すぎるか、「なぜ」が欠けています。修正して繰り返します。

ルール#5：/init だけで自動生成しない。 /init は出発点であり、完成されたファイルではありません。絞り込みに費やす8分間にこそ価値があります。

よくある質問

CLAUDE.md ファイルとは？

CLAUDE.md ファイルとは、Claude Code が毎セッションの開始時にプロジェクトメモリとして読み込む Markdown ファイルです。あなたのコーディング規約、コマンド、アンチパターンを Claude に伝えることで、推測に頼らずに済むようになります。このファイルは 4 つのレベルで機能します。グローバル、プロジェクトルート、サブディレクトリ（遅延読み込み）、そして gitignore に設定しておく個人用の CLAUDE.local.md です。

CLAUDE.md ファイルはどれくらいの長さにすべきか？

200行未満、かつ濃密なルールを500語未満に収めること。この閾値を超えると、Claude の指示追従性は低下する。ルールを1つ追加するたびに、他のすべてのルールが守られる可能性がわずかに下がっていく。固定の予算として扱うこと。それ以上必要になったら、サブディレクトリごとの CLAUDE.md ファイルに分割し、共有部分には @import を使うこと。

CLAUDE.md はどこに置けばいいですか？

メインのものはプロジェクトルート（./CLAUDE.md）に置き、コミットします。モノレポでは、アプリ固有のルール用にサブディレクトリへ CLAUDE.md ファイルを追加してください。プロジェクト横断的な設定は ~/.claude/CLAUDE.md に記述します。コミットしたくない個人的な上書きには CLAUDE.local.md を使いますが、手動で gitignore することを忘れないでください。

Claude が CLAUDE.md を無視するのはなぜ？

原因の 90% は次の 3 つのうちのいずれかです。ファイルが長すぎる（200 行超）、ルールが曖昧（「クリーンなコードを書く」など）、あるいは Claude がルールを適用する判断に使える「理由」がルールに書かれていない、のどれかです。wc -l CLAUDE.md を実行してから、具体性について監査してください。新しいセッションで Claude にファイルを要約させ、変更をテストしましょう。

CLAUDE.md と AGENTS.md、どちらを使うべき？

チームで Claude Code しか使っていない場合は、CLAUDE.md のままで問題ありません。2つ以上のエージェント CLI（Codex、Cursor、Sourcegraph）を使っている場合は、AGENTS.md に切り替えて、CLAUDE.md からシンボリックリンクを張ってください：ln -s AGENTS.md CLAUDE.md。最近のほとんどのエージェント CLI は AGENTS.md にフォールバックするため、1つのファイルであらゆるツールをまかなえます。

/init を実行して CLAUDE.md を生成すべき？

ドラフトとしては「はい」、完成版としては「いいえ」。/init はリポジトリをスキャンしてスターターを生成しますが、冗長で一般的です。Anthropic と HumanLayer はどちらも、/init を実行した後に積極的に削ることを推奨しています。削ったり「なぜ」の行を追加したりするのに費やす 8 分こそが、このファイルを実際に役立つものにする時間です。

CLAUDE.mdファイルはモノレポでどのように機能しますか？

ルートのCLAUDE.mdは最小限に保ち、ポインタと共通ルールのみを記載します。各アプリにはそれぞれ専用のapps/*/CLAUDE.mdがあり、スコープ付きの規約を定義します。サブディレクトリのファイルは、Claudeがそのサブツリー内のファイルを読み込んだときのみ遅延ロードされるため、兄弟ディレクトリ間は分離されたままになります。@import .claude/rules/style.mdを使えば、モジュール化されたルールの断片をアプリ間で重複させることなく共有できます。

CLAUDE.md、フック、スキルの違いは何ですか？

CLAUDE.md は助言的なコンテキストであり、Claude はそれを読み、通常はそれに従います。フックは常に発火する決定的なアクションです（フォーマットやコミットのブロックなど）。スキルは、アセットを伴う再利用可能なワークフローのための、まとめられた機能群です。スタイルの指針には CLAUDE.md を、厳格なルールにはフックを、プロジェクト間で繰り返し行う複数ステップの作業にはスキルを使用してください。

Techsy のアプローチ

Techsy では、納品するすべての Claude Code プロジェクトに、150 行以内の CLAUDE.md と AGENTS.md のシンボリックリンクを配置しています。このファイルをコードと同様に扱い、バージョン管理し、PR で変更をレビューし、マージ前に新しいセッションで再テストしています。AI エージェントを開発ワークフローに組み込むサポートが必要ですか？無料相談はこちら