AIがルールを無視する原因と対応策——CLAUDE.md・Cursor Rules・AGENTS.md の読み込み確認と仕組み化

Claude Code に「CLAUDE.md を読んだか？」と聞くと「読みました」と答えるのに、指定したテストを実行しない。こうしたときは、指示が入力に届いていないのか、届いているが行動に反映されていないのかを分けて調べよう。「読んだ」という返答だけでは、どちらも確定できない。

Cursor の .cursor/rules、GitHub Copilot の .github/copilot-instructions.md、Codex CLI の AGENTS.md も、読み込み場所や適用条件を確かめる必要がある。ツールごとの読み込み仕様と、モデルが指示を守るかどうかは別の問題だ。

本記事では、読み込み・圧縮後の復帰・指示の衝突など5つの確認ポイントを整理し、手元で切り分ける順序と改善例を示す。文章を短くするだけで遵守を保証することはできない。機械で判定できる条件はHooksやCIへ移し、人の判断が必要なものはレビューに残す。

1. なぜAIはルールを無視するのか——5つの確認ポイント

① 長さと読み込み上限の混同

長い指示は文脈を消費し、重要な条件を見つけにくくする。Claude Code公式はCLAUDE.mdを1ファイル200行未満にすることを推奨しているが、200行目で読み込みが切れるという意味ではない。読み込み上限と、読み込まれた指示への遵守は区別しよう。「150行なら確実」「200行を超えると中盤が消える」という境界は示されていない。

② 長いセッションでの auto-compact

Claude Codeの /compact は会話を圧縮するが、プロジェクトルートのCLAUDE.mdは圧縮後にディスクから再読み込みされ、文脈へ戻る。一方、サブディレクトリのCLAUDE.mdやパス指定ルールは、対象ファイルを読むときに再読み込みされる。会話だけで決めた内容、まだ再読み込みされていない入れ子の指示、読み込まれたのに守られない指示を混同しないこと。

③ 指示の衝突と適用範囲

「テストしてからコミット」と「今回はテストを省略」が併存すると、どちらを適用するかの判断が必要になる。単に新しい指示ほど優先、と時系列だけでは説明できない。プロジェクト共通・個人用・ディレクトリ別の指示を読み比べ、例外を誰が許可できるかまで明記する。CLAUDE.mdに禁止と書いても、実行権限そのものが取り上げられるわけではない。

④ ルールの曖昧さ・矛盾

「丁寧に書く」「適切に処理する」のような主観的・抽象的な指示は AIが自分の判断で解釈するため、人間の期待とズレやすい。「3行以内で書く」「Slack APIを使う場合はchat.postMessageを使う」のように、検証可能な形に落とし込む必要がある。

⑤ ルールファイルの長大化・分散

CLAUDE.mdからSPEC.mdへ通常のリンクを張っただけで、参照先の全文まで起動時に読み込まれるとは限らない。Claude Codeの @path インポートは起動時に展開されるが、その分も文脈を使う。整理のためのファイル分割と、必要時だけ読み込む仕組みは別だ。重複した規則が食い違う場合は、正本と適用範囲を決め直そう。

この区別は、Claude Code公式のメモリ仕様に基づく。2026年9月21日に原文を確認した。ファイルを短くする目安と、compact後に何が戻るかを別の項目として読むと、原因を取り違えにくい。

2. ルールが守られているか診断する方法

まず現状把握から。以下の質問をAIに投げて応答を観察する:

「読んだ」「理解した」とAIが答えても、実際に適用するかは別問題。読み込みの証拠と、実行後の成果物をそれぞれ確認しよう。

原因を切り分ける4段階

1. 入口を確認する。 Claude Codeなら /context のMemory filesでCLAUDE.mdとルールの読み込みを確認する。ファイルが対象ディレクトリにあるか、除外設定に入っていないかも見る。AGENTS.mdの直接読み込みはこの一覧に出ない例外があるため、一覧にないだけで未読と決めつけない。
2. 適用条件を発生させる。 パス指定ルールなら対象のファイルを読ませる。compact直後にまだ対象を読んでいないなら、ルールが再読み込みされていない可能性がある。起動時に読む指示と、作業対象に応じて読む指示を分けて記録する。
3. 無害な小さい作業で試す。 たとえば「変更前に対象ファイル名を示す」「変更後にテストコマンドと終了コードを報告する」という規則で、使い捨てのサンプルを修正させる。本番データの削除や公開操作を検証の題材にしない。最初から合言葉を質問に書くと、指示ファイルを読まなくても答えられるので読み込みの検証にならない。
4. 結果を外から確かめる。 ファイル差分に想定外の変更がないか、報告されたテストが実行されたか、対象件数が足りるかを調べる。1回成功しても将来のすべての操作を保証しない。変更した設定・ツール版・対象ファイルを記録し、条件が変わったら再確認する。

たとえば「コミット前にテストする」という指示を読み込んでいるのに実行しなかったなら、ファイルの場所だけを変えても原因に届かない。どのテストかを明記し、実行結果がない場合はコミット工程を完了にしない。さらに必須のCIチェックをマージ条件にすれば、AIの自己申告以外にも判断材料を持てる。

一方、対象のCLAUDE.mdが読み込み一覧にない場合は、文章を強調する前に起動場所と設定を直す。読み込み後に違反が残る場合だけ、指示の具体性や検査の仕組みを見直す。この順序なら、すべてを「AIが忘れた」で片付けずに済む。

3. 即効性のある対応策（5分でできる）

① 毎回必要な規則と、必要時だけ読む詳細を分ける

Claude Code公式の200行未満という目安を出発点に、行数を合わせるより、重複と不要な説明を減らす。たとえば次のように役割を分ける:

• 必ず守る掟（10〜20行）→ CLAUDE.md の冒頭
• サービス別の詳細仕様 → SPEC-xxx.md に分離
• 過去の経緯・背景 → docs/ ディレクトリへ

別ファイルへ移したら、「どの作業の前に、何を読むか」を起点に書く。毎回必要な内容をインポートする場合は、分割しても起動時の文脈量は減らない。条件付きの規則を必要時だけ読む設計にしたいなら、パス指定ルールやスキルを使う。

② 優先度マーカーを付ける

重要度のラベルは人にもAIにも意図を伝えるための整理法だ。ラベル自体に実行を強制する機能はない。たとえば次のように定義して使う:

• CRITICAL / 致命的: 違反すると本番障害が起きるレベル
• MUST / 必須: 必ず守る
• SHOULD / 推奨: 通常守る
• NICE TO HAVE / 任意: 余裕があれば

「CRITICAL: 本番DBへの破壊的クエリは事前承認必須」なら、承認が必要な対象と条件を具体的に示せる。許可されていない操作を実際に止めるには、権限設定や実行前検査も必要だ。

③ チャット内で再強調

セッション開始時に「最重要ルール3つを宣言してから作業を始めて」と一文添える。宣言は確認のきっかけになるが、テスト実行を保証するものではない。作業後に結果も確認する。

④ 作業計画に確認条件を入れる

AIエージェントのタスク管理機能に「ルール確認」を含め、各ステップの完了条件を見えるようにする。「テスト済み」だけでなく、コマンド・終了コード・未検査範囲を記録させる。完了マークがあっても、その根拠が空なら作業は未確認のままだ。

4. 中長期の仕組み化——Hooks・レビュー・スキル

判定できる条件はスクリプトにし、操作権限は設定で制御する。Hooks・CI・AIレビュー・スキルは役割が違う。すべてを「自動強制」と呼ぶと、検査していない部分を見失う。

① Claude Code Hooks で機械的に強制

Claude Code の Hooks 機能を使えば、特定のツール呼び出し前後に任意のスクリプトを実行できる。「AIがルールを忘れても、システムが止める」仕組みを作れる。

例えば PreToolUse フックで:

• Bash ツール実行前に危険コマンド（rm -rf, git push --force）を検出 → 拒否
• Edit ツール実行前に対象ファイルの権限・ロック状態をチェック
• コミット前にプロジェクト固有のテストを実行、失敗なら阻止

阻止が必要な PreToolUse では、フックが拒否の終了コード 2、または適切な拒否JSONを返すようにする。テストが失敗して 1 を返しても、通常の文字列出力だけなら非ブロッキングのエラーとなり、操作が続く。PostToolUse は実行後なので、済んだ操作を取り消す仕組みではない。

ただし阻止できるのは、設定したイベントでスクリプトが判定した範囲だけ。Edit だけを監視しても、シェル経由の書き込みは別経路になる。危険な文字列の単純一致も万能ではない。権限・サンドボックス・CIと組み合わせ、通す入力と拒否する入力の両方で試す。

② サブエージェントで責務分離

Claude Agent SDK や Cursor のサブエージェント機能を使い、「ルール監査専用のエージェント」を作る。メインのエージェントが書いたコードを監査エージェントがレビューする二段構えにすると、別の観点から見落としを探せる。ただし、同じ誤解や見落としを繰り返す可能性は残る。

監査担当には、確認する規則・変更差分・期待する証拠を渡す。短いプロンプトなら認識率が高いと保証されるわけではない。報告の各指摘を実際のファイルやテスト結果と突き合わせ、担当外の範囲は未確認として残す。

③ スキルで定型手順を呼び出す

Claude Codeでは、繰り返す手順を .claude/skills/precommit/SKILL.md にまとめ、独自の /precommit として呼び出せる。これは自分で作る例で、標準搭載コマンドではない。旧 .claude/commands/ のファイルも使えるが、現在の公式説明はスキルに統合されている。手順を呼び出すことと、全項目に合格したことは別なので、最後に検査結果を確認する。

保存場所や呼び出し方は、公式のスキル説明で確認できる。スキルには手順と確認条件をまとめ、実行した証拠を報告させよう。

④ 自動検証スクリプトで検出

CIや pre-commit hook で「禁止されるパターン」を grep で検出する。例:

• console.log が本番コードに残っていないか
• ハードコードされた API キーがないか
• ファイル冒頭に著作権コメントが入っているか

スクリプトも、実装していない規則や対象外のファイルは検査できない。正常例・違反例・取得失敗を試し、何件を検査して何件を飛ばしたかを表示する。たとえば10ファイル中2件が読めなかった場合、残る8件が正常でも「全件合格」にはしない。

5. ツール別ベストプラクティス

ツール別の条件は、Cursorのルール仕様、GitHub Copilotのカスタム指示、OpenAIのAGENTS.md説明を参照。Copilotのファイル別指示は *.instructions.md を使い、機能ごとの対応も確認する。Codexの32 KiBは既定の合計バイト数で、日本語の文字数や行数とは一致しない。

共通の鉄則は 「短く・具体的に・優先度を明示」。ファイル名や置き場所はツールにより異なるが、書き方の原則は同じだ。

6. ルール設計のアンチパターン3選

① 「ベストプラクティスに従ってください」

「ベストプラクティス」が何を指すか、依頼だけでは決まらない。プロジェクトで採用している方法と確認手段を書く。「適切にテスト」なら、必要なテストコマンドと、失敗したときに止める工程まで具体化する。

② 同じルールを複数ファイルに重複記載

CLAUDE.md と SPEC.md と README.md に同じ「コミット規約」を書くと、更新時に3つの間で食い違いが生じやすい。正本（Source of Truth）を1箇所に決め、他からは参照リンクのみ。

③ 「絶対に〜してください」の連発

すべてを同じ強さで強調すると、どの条件を優先すべきか伝わりにくい。本当に致命的なものだけ「CRITICAL」を使い、ほかは普通の語調にする。強調はインフレを起こすと心得る。

まとめ

ルールが守られないときは、読み込み条件→適用範囲→指示の衝突→実行結果の順で切り分けよう。ルートのCLAUDE.mdはcompact後に再注入されるため、圧縮だけを原因と決めつけない。短文化・強調・AIレビューは補助であり、確実に判定できる条件はHooksやCIへ、操作の許可範囲は権限設定へ移す。

完了の根拠は「読みました」という返答ではなく、必要な範囲を確認できる実行結果と成果物だ。

FAQ

Q1. CLAUDE.md は何行以内が理想？

公式の目安は1ファイル200行未満。この数字は読み込みの打ち切り位置でも、遵守の保証でもない。毎回必要な規則を残し、詳細は読む条件を明記して分離する。インポートで全部戻せば、起動時の文脈量は減らない。

Q2. Cursor の .cursorrules と .cursor/rules/*.mdc はどっちを使うべき？

新規なら .cursor/rules/*.mdc 推奨。1ルール = 1ファイルでglobパターンによる適用範囲指定ができる。レガシーの .cursorrules は単一ファイルで肥大化しやすい。

Q3. ルールを長く書くほど厳格になる？

長さだけでは厳格にならない。必要な条件や例を足すことには意味があるが、重複や矛盾を増やさないようにする。読み込まれる範囲と、実際に検査できる条件を確認しよう。

Q4. 複数のAIツール（Claude Code + Cursor）で同じプロジェクトを使う場合は？

共通ルールの正本を一つにし、ツール固有の入口と設定を分ける。CodexやCursorはAGENTS.mdに対応している。Claude Codeでは読み込まれるCLAUDE.mdから @AGENTS.md をインポートする方法もある。ただし、ファイルの探索範囲や除外設定は同じではない。共通ファイルを置いただけで、全ツールに届いたと判断しない。

Q5. AIが「読んだ」と言っても本当に読んでない？

返答だけで未読とは断定できないし、読んだ証拠にもならない。本記事の診断手順で読み込み表示を確認し、変更差分・テスト結果・実行履歴も突き合わせる。