AIコーディングが同じ間違いを繰り返すとき、指示・文脈・設定のどこを直すか

まず押さえる前提:ルールは「強制」ではなく「文脈」

Claude Code の公式ドキュメントは、各セッションが新しいコンテキストウィンドウから始まること、そしてCLAUDE.mdは設定による強制ではなく文脈として扱われることを説明しています。特定の操作を確実に止めたいなら、PreToolUse フックを使うよう案内もあります。指示は具体的で簡潔なほど守られやすい、とも書かれています(Claude Code: How Claude remembers your project)。

つまり、ルールファイルに書いたのに破られるのは、書き方の問題かもしれませんし、そもそも仕組み上「お願い」でしかない領域かもしれません。この区別が診断の出発点です。

症状別の診断表

次の表は、公式仕様から言えることを土台にした編集上の整理です。「最初に試すこと」を上から順に行ってください。

• 新しいセッションでは守るが、長い作業の後半で崩れる、原因候補(層)：文脈:やり取りが長く、初期の指示が埋もれている、最初に試すこと：区切りの良いところで新規セッションにし、要点だけ渡し直す、直す場所：作業の分割、依頼文
• 毎回、新しいセッションでも同じ書き方をする、原因候補(層)：指示:ルールとして残っていない、最初に試すこと：禁止事項と代わりの書き方をルールファイルに1行で書く、直す場所：ルールファイル本文
• ルールに書いてあるのに無視される、原因候補(層)：設定:読み込まれていない(適用範囲・種類・配置)、最初に試すこと：AIに「今適用されているルールを列挙して」と聞く、直す場所：ルールの種類、対象パターン、配置場所
• ルールを増やすほど守られなくなる、原因候補(層)：設定:長すぎる、または内容が競合、最初に試すこと：重複・矛盾する項目を消し、分割する、直す場所：ルールの量と構成
• 特定のファイルだけ間違える、原因候補(層)：文脈:参照すべき手本や型定義が渡っていない、最初に試すこと：手本ファイルを明示して「これに合わせて」と頼む、直す場所：依頼文、ファイル参照
• ルールは読んでいると答えるが、実際には破る、原因候補(層)：強制:守らせる仕組みがない、最初に試すこと：テスト・リンター・フックで機械的に検出する、直す場所：テスト、CI、フック
• 修正を頼むと別の箇所が壊れる、原因候補(層)：指示:変更範囲と確認方法が未指定、最初に試すこと：触ってよい範囲とテスト実行を指定する、直す場所：依頼文

層1:指示を直す(曖昧さと「一度言っただけ」)

「きれいに書いて」「いつものスタイルで」は、AIにとって判断材料になりません。同じミスの多くは、どう直すかが具体的に書かれていないことから生まれます。また、チャットで一度注意しただけでは、次のセッションには引き継がれません。Claude Code には、修正内容から自分でメモを残す auto memory もありますが、確実に残したい決まりごとは人が書くCLAUDE.mdに置くほうが管理しやすいでしょう。

ルールは「禁止+代替+理由または確認方法」の形にすると効きます。以下は説明用の例で、実際の案件で動作を確認したものではありません。

## 日付の扱い
- `new Date()` を直接使わず、`src/lib/clock.ts` の `now()` を使う
  (テストで時刻を固定するため)
- 確認: `npm test` が通ること

悪い例は「日付は適切に扱うこと」です。何が適切か、AIには決められません。

層2:文脈を直す(渡した情報の過不足)

指示が明確でも、判断に必要な情報が文脈に入っていなければ間違えます。逆に、直前に失敗した古い案が会話に残っていると、それに引きずられることもあります。

渡すべきものは次の3点です。

• 手本になる既存ファイル(「src/api/users.ts と同じ構成で」)
• 失敗時のエラー全文とコマンド(要約ではなく原文)
• やってはいけない変更範囲

同じ失敗を3回続けたら、その会話で粘らず、新しいセッションで次のように頼み直すのが切り分けとして有効です。

目的: ○○関数のバグ修正
現状: 以下のテストが失敗する(エラー全文を貼る)
触ってよい範囲: src/foo/ 配下のみ
試して失敗した方法: 戻り値を null にする案(型エラーになった)
手本: src/foo/bar.ts の書き方に合わせる
完了条件: npm test が通る。通らなければ原因を報告して止まる

新しいセッションで直るなら、原因は文脈の汚れや長さにあった可能性が高い、という見立てになります。

層3:設定を直す(読み込まれているか、競合していないか)

ルールが「ある」ことと「効いている」ことは別です。ツールごとに適用の条件が違います。

• Cursor:プロジェクトルールには「常に適用」「エージェントが説明から判断して適用」「特定ファイルのパターンで適用」「手動で@指定したときのみ適用」の4つの適用方法があります。公式は、1つのルールを500行未満に抑え、分割することを推奨しています(Cursor Rules)。「手動」は@指定したとき、「特定ファイル」はパターンに一致するファイルが文脈に入ったときに適用されます。
• GitHub Copilot:リポジトリ全体の指示(.github/copilot-instructions.md)、パス別の指示(.github/instructions/ 内の *.instructions.md)、AGENTS.md などのエージェント指示があります。対応する指示の種類は利用環境や機能で異なります。GitHub.com の Copilot Chat では優先度は個人、リポジトリ、組織の順ですが、多くのクライアントでは一般的な優先順位を定めず、適用される指示を併せて渡します。競合する指示は避けるよう案内されています(GitHub Docs: カスタム指示)。「2ページ以内」は、クラウドエージェントに指示ファイルを生成させる公式の依頼文例にある条件です(GitHub Docs: リポジトリのカスタム指示)。
• Claude Code:CLAUDE.md と auto memory は、どちらも会話開始時に読み込まれます。auto memory は先頭の200行または25KBまでが対象です(前掲の公式ドキュメント)。

確認には、AI自身に聞くのが手軽です。

このリポジトリで今あなたに適用されている指示・ルールのファイル名を列挙してください。
そのうえで、日付の扱いに関するルールがあれば該当箇所を引用してください。

引用できなければ、読み込まれていないか、書き方が伝わっていません。ただし、AIの自己申告は誤ることもあるため、ツールの設定画面やファイル配置でも確認してください。ルールが複数あって矛盾している場合は、片方を消して一本化します。

層4:守らせる仕組みを足す(テスト・リンター・フック)

ルールを読んでいても破るケースがあります。ルールは文脈である以上、避けられません。そこで、守られなかったことを機械が検出する形にします。

• 書式や禁止APIの使用は、リンターの規則に落とす
• 挙動の誤りは、再現するテストを先に書いて「通るまで直す」と依頼する
• 絶対に実行させたくない操作は、Claude Code なら PreToolUse フックで止める(公式がこの用途を案内しています)

「同じミスが3回目」になったら、ルールを書き足す前に、そのミスを検出するテストやリンター規則を1つ足せないか考えてください。人が毎回目視するより確実です。

診断の進め方(10分で終わる手順)

1. 同じ依頼を新しいセッションで1回やり直す。直れば文脈(層2)を疑う。
2. 直らなければ、適用中のルールを列挙させる(層3)。載っていなければ配置・種類・対象パターンを直す。
3. 載っているのに破るなら、ルール文を「禁止+代替+確認方法」に書き換える(層1)。
4. それでも再発するなら、テストやリンターで検出する(層4)。

人が確認するのは、AIが「直しました」と報告した後の差分とテスト結果です。報告文だけを信じず、再発しやすい箇所は差分で見てください。なお、ルールに書く例は実際のコードに置き換え、社外秘の情報やキーは貼らないようにしてください。