プログラミング ソフトウェア AI 公開日 2026.04.21 更新日 2026.05.14

AIがルールのmdファイルを無視する原因は?AGENTS.md・CLAUDE.md・Rulesの対応策

AIがAGENTS.mdCLAUDE.md、Rulesを無視しているように見えるときの原因と対応策を、ツール別の読み込み仕様と実務の直し方から整理します。

先に要点

  • AIが `.md` ルールを無視しているように見える原因は、そもそも読まれていない別の指示に負けている長すぎて効きが弱い適用範囲がズレている重要度が曖昧 のどれかであることが多いです。
  • AGENTS.mdCLAUDE.mdCopilot instructions、Cursor Rules は、同じように見えて読み込み方が違います。まずは対象ツールがどの場所のどのファイルを読むかを確認するのが先です。
  • 対策として効きやすいのは、短く具体的にする禁止事項より優先順位を書く1ファイル1論点に分けるチャットでも最重要ルールを再指定するどのルールが実際に読まれたか診断する ことです。
  • `.md` ファイルは強制設定ではなく、AIに渡す文脈です。だからこそ、ルールの書き方と読み込まれ方をセットで設計する 必要があります。

AGENTS.md を置いたのに守られない CLAUDE.md に書いたのに別の流儀で直される Cursor Rules が効いていない気がする
この悩みはかなりよくあります。

しかも厄介なのは、AIが勝手だから仕方ない で片づけると、同じ失敗が何度も続くことです。
実際には、ファイルの置き場所、読み込み範囲、競合、長さ、指示の曖昧さなど、原因はかなり分解できます。

この記事では、2026年4月21日時点で OpenAI CodexClaude CodeVS Code / GitHub CopilotCursor の公式情報を確認しながら、AI がルール用の .md ファイルを無視しているように見えるときの原因と対応策を整理します。
既存の AIコーディングで使うmdファイルとは?何を書くか の記事だとしたら、今回は 書いたのに効かないときどう直すか に寄せます。
特に AGENTS.md を長くしすぎると、なぜ崩れやすくなるのか だけを深掘りしたい場合は、AGENTS.mdが長すぎるとAIコーディングはなぜ崩れる?指示の埋もれ方と直し方を整理 もつながります。

まず大前提:mdファイルは魔法の強制設定ではない

ここを最初に押さえたいです。
AI向けの .md ファイルは、アプリケーション設定ファイルというより、自動で読み込まれる追加コンテキスト に近いです。

つまり、

  • 読み込まれないことがある
  • 別の指示と衝突することがある
  • 長すぎると効きが弱くなることがある
  • 作業内容によっては優先されないことがある

という前提があります。

この性質を無視して ここに書いたから絶対守るはず と考えると、かなりつらくなります。

なぜ無視されるのか

1. そもそも読まれていない

これが一番多いです。

ツールごとに読む場所が違います。

ツール 代表的なルールの場所 注意点
OpenAI Codex AGENTS.md ルートからカレントディレクトリまで探索
Claude Code CLAUDE.md AGENTS.md はそのままでは読まない
VS Code / Copilot .github/copilot-instructions.mdAGENTS.mdCLAUDE.md.instructions.md 設定やファイル位置、適用条件を確認する必要がある
Cursor .cursor/rulesAGENTS.md Rules と AGENTS.md は別物

OpenAICodex ドキュメントでは、CodexAGENTS.md を作業前に読み、~/.codex/AGENTS.md のようなグローバル指示と、プロジェクト配下の指示をレイヤーとして扱うと説明されています。
一方で Claude Code の memory ドキュメントでは、Claude Code reads CLAUDE.md, not AGENTS.md と明記されています。

つまり、ツールが違うのに同じファイル名だけ置いている と、普通に効きません。

2. 読み込み範囲がズレている

同じファイル名でも、どこから起動したかで変わることがあります。

CodexAGENTS.md ガイドでは、プロジェクトルートから現在の作業ディレクトリまでをたどって instructions file を読むと説明されています。
Claude Code も、現在の working directory から上方向に CLAUDE.md を探し、さらにサブディレクトリの CLAUDE.md はその subtree のファイルを読んだときに取り込まれると案内されています。

つまり、次のようなズレが起きます。

  • 期待しているディレクトリから起動していない
  • サブディレクトリのルールをまだ読んでいない
  • モノレポで別チーム用のルールまで拾っている

ルールはあるのに効かない のではなく、その瞬間のスコープに入っていない ことがあります。

3. ルール同士が衝突している

ルールファイルは1枚だけとは限りません。
グローバル、プロジェクト、サブディレクトリ、ユーザー設定、個人メモが重なっていることがあります。

Codex では global guidance と project-specific overrides を重ねる形です。
Claude Code では CLAUDE.mdCLAUDE.local.md、ユーザールール、プロジェクトルールがあり、CLAUDE.local.md は同じ階層では後ろに付くため、競合時に最後に読まれるものが強く見えやすい構造です。

Cursor でも Project Rules、User Rules、AGENTS.md があり、VS Code / Copilot でも always-on instructions と file-based instructions が混ざります。

つまり、守られていないのではなく、別のルールに押し負けている ことがあります。

4. 長すぎて、重要なことが埋もれている

これはかなり起きます。
ルールファイルが親切すぎて、歴史、背景、理想論、例外、補足が全部入ると、AI から見て何が最重要か分かりにくくなります。

Anthropic の memory ドキュメントでも、CLAUDE.md は full で読み込まれる一方で、shorter files produce better adherence と説明されています。
つまり、長く書けることと、守られやすいことは別です。

なんとなく良さそうな説明 を増やすほど、禁止事項や優先ルールがぼやけやすくなります。

5. 指示が抽象的すぎる

たとえば、

  • きれいに書いて
  • 安全に実装して
  • 既存の流儀に合わせて
  • 適切にテストして

だけだと、人間にも解釈幅があります。
AI だとさらに広がります。

抽象ルールは、守られていないというより、解釈がズレている ことが多いです。

ツール別に見ると、どこを疑うべきか

OpenAI Codex / AGENTS.md

CodexAGENTS.md ガイドでは、AGENTS.override.mdAGENTS.md、fallback filenames の順で、各ディレクトリごとに最大1ファイルずつ読むと説明されています。
さらに、Codex は current directory までで探索を止めるので、specialized work の近くに override を置くよう案内されています。

つまり Codex でズレるときは、

  • 今の cwd が想定と違う
  • override が root ルールを上書きしている
  • fallback filename を設定していない

あたりを疑うと早いです。

Claude Code / CLAUDE.md

Claude CodeAGENTS.md をそのままは読まず、必要なら CLAUDE.md から @AGENTS.md で import する形が公式に案内されています。
また /memory でどの memory files が loaded されているか確認できます。

Claude Code でズレるときは、

  • AGENTS.md しか置いていない
  • CLAUDE.md はあるが、起動ディレクトリが深くて別ルールが追加されている
  • サブディレクトリの CLAUDE.md がファイル読込後に入ってきている
  • monorepo で関係ない rules も拾っている

のようなケースが多いです。

VS Code / GitHub Copilot

最新の VS Code ドキュメントでは、.github/copilot-instructions.mdAGENTS.mdCLAUDE.md*.instructions.md が使え、複数ある場合は combine されて chat context に追加される一方、specific order is not guaranteed と説明されています。

さらに FAQ では、適用されないときの確認として次が示されています。

  • ファイルが正しい場所にあるか
  • applyTo が対象に合っているか
  • 関連 settings が有効か
  • Diagnostics view で loaded files と errors を見る

なので Copilot / VS Code では、書いたのに効かない ときほど diagnostics を見た方が早いです。

Cursor / Rules

Cursor の docs では、Rules は reusable で scoped な system-level instructions で、Project Rules、User Rules、AGENTS.md など複数の仕組みがあると説明されています。
また search snippet でも、CLIAGENTS.mdCLAUDE.md.cursor/rules とあわせて読むと案内されています。

Cursor でズレるときは、

  • .cursor/rulesAGENTS.md の役割が混ざっている
  • 1ファイルに全部詰め込みすぎている
  • どの Rule がどの作業に効くか分かれていない

ことがよくあります。

効きやすい対応策

1. 最重要ルールを先頭に出す

まず守ってほしいことは、先頭に短く出します。

悪い例:

  • 背景説明が長く、最後に 本番DBは触るな

よい例:

  • 本番DB・本番API・課金設定は変更禁止
  • 変更後は npm test と npm run lint を必須
  • 新規依存追加は事前確認

先頭3〜5行で 絶対に外したくないこと を見せる方が効きやすいです。

2. 1ファイル1論点に寄せる

長い総合ルールファイル1枚より、

  • testing.md
  • api-design.md
  • frontend.md

のように論点を分けた方が、どこでズレたか追いやすいです。
Claude Code の .claude/rules/VS Code.instructions.md のように、分割しやすい仕組みでは特に有効です。

3. 抽象語を具体化する

安全に ではなく、

  • .env を読まない
  • rm -rf を使わない
  • migration は提案まで、実行はしない
  • lint と unit test を通す

のように、観測できる行動へ落とした方が守られやすいです。

4. 優先順位を書く

競合しやすいなら、優先順位まで明記します。

## Priority
- Security rules override code style preferences.
- Project-specific rules override personal preferences.
- When unsure, stop and ask instead of guessing.

これだけで衝突時の挙動がかなり安定します。

5. チャットでも再指定する

最重要ルールは、ファイルに置いたうえで最初の依頼でも再指定した方が安全です。

たとえば、

まず AGENTS.md を読んでください。
特に「本番反映はしない」「新規依存追加は要確認」「テスト必須」を守って進めてください。

のように書くと、優先度が上がりやすいです。

.md ファイルは常設ルール、チャットは今回の強調ポイント、と分けるイメージです。

6. 実際に読み込まれたか確認する

ここを飛ばすと沼ります。

  • Claude Code: /memory
  • VS Code / Copilot: Chat customization diagnostics view
  • Codex: loaded instructions を要約させる
  • Cursor: 現在の適用ルールを説明させる

守られない の前に、読まれているか を確認するのが先です。

こう直すと効きやすい例

悪い例

# Coding Rules

このプロジェクトでは品質を大切にします。
なるべく既存実装に合わせてください。
安全で読みやすく保守しやすいコードにしてください。
必要ならテストもしてください。

改善例

# Priority Rules
- Do not modify production config, billing, or deployment settings.
- After code changes, run `npm test` and `npm run lint`.
- Ask before adding any new dependency.

# Editing Rules
- Match existing naming and file structure.
- Prefer modifying current modules over adding new abstractions.

# Output Rules
- Summarize changed files and tests run.
- If blocked, stop and explain the blocker instead of guessing.

この差はかなり大きいです。
前者は方針、後者は行動レベルになっています。

よくある失敗

1. 1回書いて放置する

AI が同じミスをしたら、チャットだけで直すのではなく、ルールファイル側も直した方が再発しにくいです。

2. ルールの置き場所を混同する

Claude Code に AGENTS.md だけ、CopilotCLAUDE.md だけ、というズレは普通に起きます。

3. 例外だらけにする

基本はこう。ただしAではこう。ただしBでは逆 が増えすぎると、人間にも AI にも厳しいです。

4. 重要ルールを文章の奥に埋める

禁止事項や承認必須事項は、背景説明のあとではなく先頭へ出した方がよいです。

AIルールファイルが無視される問題のよくある質問

Q. なぜ AI はルールを無視するのですか?

A. 厳密には 無視 ではなく、複数の指示の中で優先度判断を間違える のが主因です。ルールファイルが長すぎる、矛盾している、現在の指示と衝突している、などの状況で起きます。

Q. Claude Code、Cursor、Copilot で同じ md ファイルを使えますか?

A. 形式は共通ですが、どのファイル名を見にいくか がツールごとに違います。Claude Code は CLAUDE.mdAGENTS.md、Cursor は .cursor/rules/*.md、Copilot は .github/copilot-instructions.md、と分けて配置するのが安全です。

Q. ルールファイルが長いほど効きますか?

A. 逆です。長すぎると重要ルールが埋もれて優先度が下がります。絶対守るルール は5〜10項目に絞り、先頭に置きます。背景説明や例外条件は別ファイルや末尾にします。

Q. ルール違反を検知する方法は?

A. AI 出力をテストにかける、生成コードを Linter / Formatter で検証、PR レビューで人間チェック、などです。ルールを書いた = 守らせた ではないので、検証ステップが必要です。

Q. 業務固有の制約はどう書きますか?

A. 必須: ${X}禁止: ${Y}理由: ${Z} の形で書くと AI に意図が伝わりやすいです。具体例を添えると、似たケースでの判断ミスが減ります。

Q. ルールはチームで共有すべきですか?

A. はい、リポジトリにコミットして共有するのが標準です。.cursor/rules/*.mdCLAUDE.md をチームで運用すれば、メンバー間の生成結果のばらつきが減ります。

Q. 何度言っても直らないルールはどうすればよいですか?

A. プロンプトでも毎回明示 する、Pre-commit hook で検証AI 出力を別 AI でレビューさせる、などの多重防御が効きます。AI のクセを完全に変えるのは難しいので、守れる仕組み を作るのが現実的です。

まとめ

AI がルール用の .md ファイルを無視しているように見えるときは、気まぐれ より、

  1. 読まれていない
  2. スコープがズレている
  3. 競合している
  4. 長すぎる
  5. 抽象的すぎる

のどれかであることが多いです。

対応としては、

  • ツールごとの読み込み仕様を確認する
  • 重要ルールを先頭へ出す
  • 短く具体的にする
  • 優先順位を書く
  • チャットでも再指定する
  • 実際に loaded files を診断する

この順で整えると、かなり改善しやすいです。

.md ファイルは万能な制御装置ではありません。
でも、読み込み方と書き方を合わせれば、AI のブレをかなり減らせます。


参考リンク

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。