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

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

Cursor の .cursor/rules、GitHub Copilot の .github/copilot-instructions.md、Codex CLI の AGENTS.md でも事情は同じで、読み込み場所と適用条件はツールごとに違う。ファイルが読み込まれることと、モデルがその指示を守ることは別の問題だ。

結論から言うと、手順は3段階だ。まず読み込まれているかを見る。読み込まれているのに守られない規則は、守ったかを後から確かめられる文に書き直す。それでも毎回必ず実行させたい処理はHooksやCIに移す。Claude Code公式も、CLAUDE.mdは「強制される設定ではなくコンテキスト」であり、Claudeの判断に関係なく操作を止めたいならフックを使うよう案内している。

本記事では、読み込み・圧縮後の復帰・指示の衝突など5つの確認ポイント、切り分けの手順、規則の書き換え例を順に示す。

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

① ファイルが長く、規則が埋もれる

Claude Code公式はCLAUDE.mdを1ファイル200行未満にするよう勧めており、理由を「長いファイルは文脈を多く消費し、遵守を下げる」と説明している。200行は読み込みの打ち切り位置ではなく、4 MiBまでのCLAUDE.mdは全文が読み込まれる（4 MiBを超えるファイルは読み飛ばされる）。長いファイルで起きるのは、途中から読まれなくなることではなく、読まれたうえで個々の規則が守られにくくなることだ。

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

Claude Codeの /compact は会話を圧縮するが、プロジェクトルートのCLAUDE.mdは圧縮後にディスクから再読み込みされ、文脈へ戻る。一方、サブディレクトリのCLAUDE.mdやパス指定ルールは、対象ファイルを読むときに再読み込みされる。公式によれば、compact後に消えた指示は、①会話の中だけで伝えた、②まだ再読み込みされていないサブディレクトリのCLAUDE.mdにある、③まだ対象ファイルに触れていないパス指定ルールにある、のいずれかだ。会話で決めたことを残したいなら、CLAUDE.mdに書き足す。

③ 指示の衝突と適用範囲

「テストしてからコミット」と「今回はテストを省略」が併存すると、どちらを適用するかはモデルの判断になる。Claude Code公式は、2つの規則が矛盾するとClaudeはどちらかを任意に選ぶことがあると説明している。プロジェクト共通・個人用・ディレクトリ別の指示を定期的に読み比べて矛盾を消し、例外を認めるなら「誰が・どう指示したときか」まで書く。操作そのものを止めたいなら、CLAUDE.mdではなく権限設定やHooksを使う。矛盾や古くなった指示を Claude に探させるなら、/doctor prompt-audit が使える（使い方と実際にかけた結果）。

④ ルールの曖昧さ・矛盾

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

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

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

サブディレクトリに置いた CLAUDE.md・AGENTS.md がいつ読まれるか（Claude Code と Codex で違う）と、モノレポで決まりを自動の確認で守らせる方法は、サブディレクトリの CLAUDE.md・AGENTS.md の記事で詳しく扱っています。

ここまでのClaude Codeの仕様は、Claude Code公式のメモリ仕様（2026年9月21日時点）による。

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

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

「読んだ」「理解した」という返答は、読み込みの証拠にも、適用した証拠にもならない。証拠になるのは、読み込みの表示と実行後の成果物だ。

原因を切り分ける4段階

1. 入口を見る。 Claude Codeなら /context のMemory filesに、対象のCLAUDE.mdとルールが並んでいるかを見る。無ければ、ファイルの置き場所と除外設定（claudeMdExcludes）を調べる。AGENTS.mdを直接読み込ませている場合、そのAGENTS.mdはこの一覧に出ない。既定の設定なら、起動時に表示される no CLAUDE.md found; AGENTS.md loaded: … の行が出ているかを見る（CLAUDE.mdからインポートしたAGENTS.mdは一覧に出る）。
2. 適用条件を発生させる。 パス指定ルールなら対象のファイルを読ませる。compact直後にまだ対象を読んでいないなら、そのルールは再読み込みされていない。いつ何が読み込まれたかを残したいときは、InstructionsLoaded フックでCLAUDE.mdとルールの読み込みをログに記録できる（直接読み込んだAGENTS.mdでは発火しない）。
3. 無害な小さい作業で試す。 たとえば「変更前に対象ファイル名を示す」「変更後にテストコマンドと終了コードを報告する」という規則で、使い捨てのサンプルを修正させる。本番データの削除や公開操作を検証の題材にしない。合言葉で試すなら、合言葉は指示ファイルにだけ書き、質問には含めない。
4. 結果を外から確かめる。 ファイル差分に想定外の変更がないか、報告されたテストが実行されたか、対象件数が足りるかを調べる。試したときの設定・ツールのバージョン・対象ファイルを記録しておき、どれかが変わったらもう一度試す。

たとえば「コミット前にテストする」という指示が読み込まれているのに実行されなかったなら、ファイルの場所を変えても解決しない。直すのは規則の書き方（次章の書き換え例）と、検査の仕組みだ。必須のCIチェックをマージ条件にすれば、AIの自己申告とは別に判断材料を持てる。

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

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

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

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

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

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

② 規則を「守ったか確かめられる文」に書き換える

読み込まれているのに守られない規則は、まず「何をすれば守ったことになるか」が書かれているかを見る。Claude Code公式も、指示は検証できるくらい具体的に書くよう勧め、「変更をテストする」ではなく「コミット前に npm test を実行する」という例を挙げている。これをもう一歩進めて、失敗したときの動きと例外の条件まで書くと次のようになる。

書き換え後の文なら、守ったかどうかを差分・コマンド履歴・終了コードで判定できる。判定できる形になっていれば、あとでHooksやCIに移すときもそのまま検査条件になる（4章）。

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

重要度のラベルは人にも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選

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

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

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

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

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

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

まとめ

ルールが守られないときは、読み込み条件→適用範囲→指示の衝突→実行結果の順で切り分けよう。ルートのCLAUDE.mdはcompact後も再注入されるので、compact後に消えた指示は、会話だけで伝えたものか、まだ再読み込みされていない入れ子のCLAUDE.mdやパス指定ルールだ。

• 読み込まれていない：置き場所・除外設定・AGENTS.mdの読み込み条件を直す
• 読み込まれているのに守られない：規則を、守ったかを後から確かめられる文に書き換える
• 毎回必ず実行させたい：HooksやCIで検査し、操作の許可範囲は権限設定で決める

完了の根拠は「読みました」という返答ではなく、実行結果と成果物だ。

FAQ

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

公式の目安は1ファイル200行未満で、長いファイルほど文脈を消費し遵守が下がると説明されている。200行を超えても途中で読み込みが切れるわけではない（4 MiBまでは全文を読み込む）。毎回必要な規則だけを残し、特定のファイルでだけ使う規則はパス指定ルールへ移す。@path のインポートで分けたファイルも起動時に読み込まれるので、文脈量は減らない。

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

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

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

長さだけでは厳格にならない。公式も、長いファイルは遵守を下げると説明している。足すなら、検証できる条件と具体例を足し、重複や矛盾は削る。

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

共通ルールの正本をAGENTS.mdにまとめ、ツール固有の設定は各ツールの入口に分ける。CodexやCursorはAGENTS.mdに対応している。Claude Codeもv2.1.277以降は、作業ディレクトリとその上位に CLAUDE.md・.claude/CLAUDE.md・CLAUDE.local.md のどれも無ければ、AGENTS.mdを直接読み込む。どれかがあると既定ではそちらだけが読まれ、個人用のCLAUDE.local.mdを置いただけでもAGENTS.mdは読まれなくなる。CLAUDE.mdも使うプロジェクトでは、CLAUDE.mdに @AGENTS.md の1行を書いてインポートする（/config の Project instructions を claude-md-and-agents-md にして両方を読ませる方法もある）。Amazon Bedrockなど外部プロバイダ経由やテレメトリを無効にしたセッション、インストール・更新直後の最初のセッション、disableAllHooks などでフックを止めた環境では直接読み込みが働かないので、インポートを使う。どちらの経路で読まれているかは、2章の手順1で見分けられる。

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

返答は、読んだ証拠にも読んでいない証拠にもならない。2章の診断手順で読み込み表示を見て、変更差分・テスト結果・実行履歴と突き合わせる。