AIエージェントが作成した指示ファイルを無視する理由 (2026)

1. ファイルがロードされなかった

最も一般的であり、エラーが表示されないことが多いため、最も気づきにくい原因です。

Cursorのドキュメントには、最も顕著な例が記載されています。「.cursor/rules 内のプレーンな .md ファイルは、description、globs、および alwaysApply を指定するフロントマターがないため、ルールシステムによって無視されます。」ファイルは正しいディレクトリに適切な名前で配置されているにもかかわらず、警告なしにスキップされます。これは、プレーンなMarkdownをルールとして使用していた別のツールから移行した直後に最も発生しやすく、フォルダをコピーして一見すべて正しく見えても、実際には何も適用されません。

Zedには、同じ結果をもたらす別の罠があります。Zedのプロジェクト指示書は、.rules、.cursorrules、.windsurfrules、.clinerules、.github/copilot-instructions.md、AGENT.md、AGENTS.md、CLAUDE.md、GEMINI.md などのファイル名リストから取得されますが、ドキュメントには「Zedはこのリストの中で最初に一致したファイルを使用する」と記載されています。マージされるわけでも、最も具体的なものが選ばれるわけでもなく、「最初の一致」です。半年前の実験で残された .cursorrules ファイルが、昨日作成した AGENTS.md よりも優先されてしまいます。

GitHub Copilotは、配置場所でユーザーを混乱させます。ドキュメントによると、リポジトリ内の任意の場所にある AGENTS.md ファイルがサポートされ、ディレクトリツリーで最も近いファイルが優先されますが、代替ファイルとしての CLAUDE.md や GEMINI.md はリポジトリのルートにある必要があります。モノレポ構成の場合、この違いにより、ルートのファイルは正常に動作しても、ネストされた CLAUDE.md ファイルはCopilotから認識されなくなります。

これら3つすべてに共通するチェック方法は同じです。コンテンツを編集する前に、ファイル名、配置場所、そしてツールが必要とする場合はフロントマターを確認することです。

2. ロードされたが、現時点でコンテキストに含まれていない

これはより厄介です。ファイルは有効で読み込まれているにもかかわらず、必要な瞬間にコンテキストに存在していないからです。

スコープ付きルールは、一致する作業にのみ適用されます。 Cursorの4つの適用モードは、ルールがいつコンテキストに入るかを決定します。常に適用される alwaysApply: true、インテリジェントに適用するための description、特定のファイル用の globs、および明示的な@-メンションを必要とする手動ルールです。手動に設定されたルールが自動的に挿入されることはありません。Claude Codeの .claude/rules/ も同様に動作し、paths: フロントマターフィールドを持つルールは、Claudeが一致するファイルを処理するときに適用され、「paths フィールドのないルールは無条件でロードされます」。Clineの条件付きルールも同様に機能し、開いているファイル、表示されているタブ、言及されたパス、編集中のファイルなど、現在の作業に対して評価されるフロントマターのglobパターンに基づいてアクティブになります。

これらはバグではありません。コンテキストサイズを小さく保つための仕組みです。しかし、これは「ルールが存在する」ことと「ルールがモデルの目の前にある」ことが異なる状態であることを意味します。src/api/** にスコープされたルールは、エージェントがコンポーネントを編集している間は実際にロードされません。

オンデマンドの知識は、呼び出されるまで棚に置かれたままになります。 ZedのSkillsは、関連性がある場合やユーザーが呼び出したときにエージェントがロードするフォルダです。これは効率的ですが、常に適用されていると思い込んでいたSkillが、単に一度も読み込まれていない可能性があることも意味します。これは一般的なスキル全般に言えることであり、スキルが記憶（メモリー）の代わりにならない理由でもあります。詳細な違いについては、エージェントのスキルが記憶ではない理由をご覧ください。

コンパクション（圧縮）によって、ロードされた内容の一部が脱落します。 これは、このリストの中で最も過小評価されている項目です。Claude Codeのドキュメントによると、プロジェクトルートの CLAUDE.md はコンパクション後も維持されます（ディスクから再読み込みされて再注入されます）。しかし、「サブディレクトリ内のネストされた CLAUDE.md ファイルや、paths: フロントマターを持つルールは自動的には再注入されません。これらは、Claudeが次にそのサブディレクトリ内のファイルを読み込むか、ルールのパターンに一致するファイルを読み込んだときにリロードされます。」

実際のセッションに当てはめて考えてみてください。1時間作業してコンテキストが圧縮されると、それ以降、エージェントはルートの指示に従って動作しますが、以前保持していたディレクトリごとのルールは失われます（再び一致するファイルに触れるまで）。セッションの途中で挙動が変わり、エラーは発生せず、後から確認したルールファイルは完璧に見える、という現象が起こるのです。

3. ロードされたが、別の指示と矛盾していた

これらのシステムはすべて複数のソースを重ね合わせており、競合の解決方法はそれぞれ異なります。

Clineは、置き換えるのではなく結合します。「Clineは .clinerules/ 内のすべての .md および .txt ファイルを処理し、それらを統合されたルールセットに結合します」。また、スコープをまたぐ場合、「ワークスペースルールとグローバルルールの両方が存在する場合、Clineはそれらを結合します。競合が発生した場合は、ワークスペースルールがグローバルルールよりも優先されます」。さらに、「フロントマターのないルールは常にアクティブになります」とも記載されているため、古い常時有効なファイルが新しいファイルと永久に競合し続ける可能性があります。

Claude Codeは、ファイルシステムのルートから作業ディレクトリに向かって、ディレクトリツリーを上から順に連結します。ドキュメントではその結果について直接警告しています。「2つのルールが互いに矛盾している場合、Claudeはどちらかを任意に選択する可能性があります」。そのため、CLAUDE.md、ネストされたファイル、および .claude/rules/ を定期的に見直すことを推奨しています。

Copilotは、明示された優先順位に従って複数のレイヤーを同時に提供します。「個人用の指示が最も高い優先順位を持ちます。次にリポジトリの指示、最後に組織の指示が優先されます。ただし、関連するすべての指示セットがCopilotに提供されます。」この最後の文が重要です。優先順位が低いからといって、除外されるわけではありません。組織で指示が設定されている場合、それらはコンテキストに含まれており、あなたが会ったこともない誰かが書いた指示が、あなたが設定していない出力を静かに形成している可能性があります。

Zedは、リポジトリファイルに対して逆の方法で解決します。「競合が発生した場合、プロジェクトの指示は個人用の AGENTS.md を上書きします。」

月曜日にはルールに従ったのに火曜日には従わないなど、エージェントの挙動が気まぐれに見える場合、モデルのばらつきを疑う前に、レイヤー間での矛盾を疑う方が適切な仮説です。

4. ロードされ、曖昧さもなかったが、モデルが従わなかった

これは実際に起こる問題であり、ベンダー自身のドキュメントが事前に警告している唯一の項目です。

Claude Codeのドキュメントでは、その仕組みを次のように説明しています。「CLAUDE.md の内容は、システムプロンプトの一部としてではなく、システムプロンプトの後にユーザーメッセージとして配信されます。Claudeはそれを読み、従おうと試みますが、特に曖昧な指示や矛盾する指示については、厳格な遵守は保証されません。」また、別の箇所では、指示を「強制的な設定ではなく、コンテキストである」と説明しています。Cursorも同じ考え方を肯定的に表現しています。「大規模言語モデルは、補完の間で記憶を保持しません。ルールは、プロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。」

プロンプトレベルのコンテキスト。設定でも、ポリシーでも、保証でもありません。したがって、絶対に破ってはならないルールに対する唯一の正しい対処法は、それらを指示として記述しないことです。どちらのエコシステムも同じ代替案を提示しています。特定のライフサイクルイベントでコマンドとして実行されるフック、またはCIでのチェックです。Linterのルールを説得する必要はありません。

ルールをより強調する。 すべて大文字にする、「重要：」、「必ず〜すること」と書くなど。ごく稀に効果があることもありますが、最初の3つの失敗モードに対しては何も解決せず、ノイズが増えてファイルのメンテナンスが難しくなるだけです。

ファイルをより長くする。 ルールが無視されたとき、より詳しく説明しようとするのが人間の反射的な行動ですが、これによりファイルが大きくなり、結果として遵守率が低下します。ベンダーの意見は一致しています。Cursorはルールを500行未満に抑え、大きなルールは分割することを推奨しています。Claude Codeは1ファイルあたり200行未満に抑えることを推奨し、「ファイルが長くなると、より多くのコンテキストを消費し、遵守率が低下します」と指摘しています。

すべてを「常に適用（always-apply）」に設定する。 力技で失敗モード2を解決しますが、失敗モード3を大規模に引き起こします。すべてのタスクにおいて、矛盾するものも含め、すべてのルールが常にコンテキストに含まれるようになってしまいます。

ツールごとにファイルを複製する。 .cursorrules、CLAUDE.md、copilot-instructions.md をすべて同じ内容で作成する。これは1週間は機能します。しかし、どれか1つが更新されると、目に見えない矛盾が生じます。さらに、Zedにおいては、古いファイルがリストの最初にあることで優先されてしまう可能性が非常に高くなります。

モデルのせいにしてツールを切り替える。 最もコストのかかる方法です。新しいツールには独自のロードルールがあり、同じ4つの失敗モードが異なる形で再び現れるだけです。

一歩引いて見ると、肥大化した指示ファイルのほとんどは、関連のない2つの役割を同時にこなそうとしています。コーディング規約、禁止事項、コマンドなど、ごく少数の事柄は、確かに毎回モデルの目の前にある必要があります。それ以外のすべては知識です。アーキテクチャの決定、制約が存在する理由、試行錯誤の末に却下されたアプローチ、サブシステムの挙動などです。これらの資料は、常に常駐している必要はありません。関連性があるときに検索できればよいのです。

これらを分離することで、最初の3つの失敗モードを構造的に解決できます。短い常時有効なファイルは、ロードされたかどうかの検証が容易で、矛盾が生じにくく、コンテキストに維持するコストも低く抑えられます。そして、知識はツールが読むかどうかわからないファイル内でスペースを争うのではなく、検索システムがアクセスできる場所に移動します。

MemoryLakeはその第2のレイヤーです。各ツールのファイル名規約や優先順位ルールに依存せず、エージェントが読み取ることができる単一のメモリーストアです。セットアップは3つのステップで完了します。

ステップ 1: APIキーを作成する

MemoryLakeにサインインし、APIキーを作成します。接続するすべてのエージェントで共通の認証情報を1つ使用します。各ツールでファイルの配置場所が異なるからこそ、これが重要になります。

ステップ 2: 最初の記憶（メモリー）をアップロードする

参照資料をルールファイルから移動させます。アーキテクチャの決定とその理由、コンテキストなしでは恣意的に見える制約、試したものの断念したアプローチ、何度も説明し直しているサブシステムの挙動などです。エントリは短く、単一のトピックに絞ってください。ルールファイルに残すべきなのは、コードレビューで自信を持って主張できるような短いリストだけです。

ステップ 3: AIとエージェントを接続する

ツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセス可能です。そのため、Claude Code、Codex、OpenClawなどのMCPネイティブなエージェントはMCPサーバーを指定することで接続し、その他のツールはAPIを介して同じメモリーを読み取ります。各ツールは「常に適用すべき」最小限の指示ファイルのみを保持し、5つの異なるコピーが乱立する代わりに、すべてが同じ知識ベースを参照するようになります。

ここで、本記事のテーマに関連する2つの現実的な限界についても触れておきます。メモリーレイヤーは失敗モード4を解決しません。メモリーも依然としてコンテキストであり、強制力はありません。モデルの判断に関わらず必ず遵守すべきルールは、フックやCIに記述すべきです。また、メモリーレイヤーを導入してもファイルが自動的にロードされるようにはなりません。.cursor/rules がプレーンな .md ファイルで埋め尽くされている場合、それは依然として修正が必要なフロントマターの問題です。

診断が迅速になります。 常時有効なファイルが短ければ、400行の雑多なコンテンツに埋もれることなく、「ロードされたかどうか」を一目で判断できます。

矛盾が発生しにくくなります。 ほとんどの矛盾は、異なる時期に異なる人々によって編集された長いファイルから発生します。単一の役割を持つ短いファイルでは、そのような矛盾が蓄積するペースは劇的に遅くなります。

モデルを変更することなく、遵守率が向上します。 これは直感に反する部分です。指示ファイルからテキストを削除すると、通常は遵守率が向上します。残されたルールが、参照資料と注目度を争う必要がなくなるからです。

ツール移行時にセットアップがリセットされなくなります。 知識がツール固有のファイルに依存していないため、エディタを移行する際も、新しいツールのフォーマットで短いルールファイルを1つ作成するだけで済みます。すべてを再構築する必要はありません。この違いについては、CLAUDE.mdからGitHub Copilotへの移行で詳しく解説しています。

セッション途中の挙動が安定します。 永続的な知識が、コンパクション後にたまたま残っているファイルに依存するのではなく、検索可能（レトリバブル）になれば、セッションが進むにつれてエージェントの知識が静かに失われていく現象を防ぐことができます。

ファイルがロードされているか確認する。 Claude Codeは、セッション内で /context を介してロードされたメモリーファイルを表示し、どの指示ファイルがいつ、なぜロードされたかを正確に記録する InstructionsLoaded フックを提供しています。モデルのせいにする前に、お使いのツールが提供する同等の機能を使用してください。

フロントマターが必要な場所で設定されているか確認する。 .cursor/rules では、プレーンな .md ファイルは無視されます。これは5分で確認でき、非常に高い確率で原因を特定できる監査です。

競合するファイル名をリストアップする。 特にZedでは、9つのファイル名リストを確認し、不要なファイルを削除または統合してください。警告なしに「最初の一致」が優先されます。

ルールにスコープが設定されているか確認する。 paths:、globs:、または applyTo パターンが設定されている場合、一致するファイルが処理対象になっていない限り、そのルールは存在しません。手動モードのルールは、自動的にロードされることはありません。

セッションが圧縮（コンパクション）されたか確認する。 長いセッションの途中で挙動が変わった場合、ネストされたファイルやパススコープのルールが再注入されていない可能性があります。新しいセッションを開始することで、これを素早く確認できます。

1つ上のレイヤーを確認する。 Copilotでは個人、リポジトリ、組織の指示がすべて提供され、Clineではワークスペースとグローバルのルールが結合され、Claude Codeではディレクトリツリー全体が連結されます。矛盾しているルールは、あなたが作成していないファイルに存在する可能性があります。

その後で、初めて具体性を高めるために書き直します。 抽象的な指示よりも具体的な指示が勝ります。「コードを適切にフォーマットする」ではなく「2スペースのインデントを使用する」と記述します。これが失敗モード4の解決策であり、他の3つの原因を排除した後にのみ効果を発揮します。

「エージェントがルールを無視する」というのは、同じ服を着た4つの異なる問題です。そのうち3つは設定の問題であり、明確な解決策があります。ファイル名とフロントマターを確認する、ルールにスコープが設定されているか、またはコンパクションで脱落していないかを確認する、矛盾する他の指示がロードされていないかを確認する、です。4つ目は、すべてのベンダーが事前にドキュメント化している本質的な限界（指示はコンテキストであり、強制力はない）であり、その解決策はより強い形容詞を使うことではなく、フックやCIチェックを導入することです。

この問題が繰り返される理由は、指示ファイルが知識ベースとして使用され、ファイルが長くなり、結果として4つの失敗モードすべてが同時に悪化するためです。常時有効なルールセットは検証可能なほど短く保ち、参照知識は検索可能な場所に移動し、妥協できないルールは提案ではなく強制される場所に配置してください。特定のツールでこの問題に対処している場合は、Cursor、Claude Code、Copilot、Cline、Windsurf、Zed の各ツール別ガイドを参照してください。