Claude Codeの暴走を止めるCLAUDE.md｜4ルールと3失敗の対応表（Karpathy式・65行）

この記事はClaude Code を毎日触っている個人開発者・副業エンジニア向け（CLAUDE.md という単語を聞いたことがあれば読めます）。

Karpathy式CLAUDE.mdって何？普通のCLAUDE.mdと何が違う？

正式名は forrestchang/andrej-karpathy-skills というリポジトリ（GitHub上のプロジェクトの保管庫）の中の CLAUDE.md ファイル1枚です。
65行あって、
実コンテンツは44行、
残りはスペース・フォーマット。

普通の CLAUDE.md は「使ってる言語は Python」「テストは pytest」みたいな環境情報が中心になります。
これに対して Karpathy式は環境情報をゼロにして、
AI への行動原則だけを書いてる。
これが面白い。

READMEの自己紹介はこう書いてある。

A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls.

（出典: forrestchang/andrej-karpathy-skills README）

キーワードは "derived from"。
Karpathy本人が書いたわけではなく、
Karpathy が観察した失敗パターンを別の開発者（Forrest Chang）がCLAUDE.mdに翻訳したという位置付け。
ここは混乱しやすい。

個人的には、
ここを最初に押さえておかないと「Karpathy 公認の最強テンプレ」みたいな誤解が生まれる気がする。
事実は「Karpathy の観察を Forrest Chang がCLAUDE.md化した OSS」。

リポジトリの数字は？（85.5k★・MIT・65行）

2026-04-25時点の数字を出典付きで並べる。

公開から1週間で 43,000★ という記録もある（star-history.com 集計時点で 78.2k 段階のグローバルランキング 171位）。
65行のテキストファイル1枚でこの伸びは異常です。

ちなみに Cursor 用ファイル（.cursor/rules/karpathy-guidelines.mdc）も同梱されているので、
Claude Code 専用ではない。
Cursor 派にも届く設計になっている。

Karpathyが観察した「LLMコーディング3大失敗」って？

このリポジトリの根拠になっているのが、
Andrej Karpathy が 2026年1月26日前後に投下した観察ノート。
READMEに3つの失敗パターンとして英語原文が引用されている。

失敗1: 仮定先行・確認省略

The models make wrong assumptions on your behalf and just run along with them without checking. They don't manage their confusion, don't seek clarifications, don't surface inconsistencies, don't present tradeoffs, don't push back when they should.

（出典: README.md）

要するに「分からないところを質問せず、
勝手に解釈してそのまま走る」現象。
私はここが一番刺さりました。

失敗2: 過剰複雑化

They really like to overcomplicate code and APIs, bloat abstractions, don't clean up dead code... implement a bloated construction over 1000 lines when 100 would do.

（出典: 同上）

100行で済む機能を1000行で書いてくる、
抽象化を盛りすぎる、
必要のない柔軟性を足してくる。
これは Claude Code 触ってる人なら全員心当たりあるパターンです。

失敗3: 直交的コード改変

They still sometimes change/remove comments and code they don't sufficiently understand as side effects, even if orthogonal to the task.

（出典: 同上）

「バグ修正お願い」と頼んだら、
頼んでない箇所までリファクタしてくる現象。
私の見立てでは、
これが一番手戻りを生む。

背景として、
Karpathy の元投稿の文脈は「11月までは80%手動コーディング+autocomplete、
20%エージェント運用だったのが、
80%エージェント運用+20%手直しに急転換した時の観察」だと READMEに位置付けられている。
エージェント比率が増えた瞬間、
この3つが目立ち始めた、
という温度感。

4ルールの中身は？（英語原文＋日本語訳）

CLAUDE.md本体には、
上の3大失敗を抑える4つのルールが書かれている。
原文と要約をそのまま並べる。

Rule 1 — Think Before Coding（書く前に考える）

Don't assume. Don't hide confusion. Surface tradeoffs.

実装前に前提を明示し、
複数解釈があるなら全部出し、
もっとシンプルな代替案があれば言及し、
不明点があれば走らずに立ち止まれ、
という指示です。
「分からないまま進めるな」を一行で言い切ったルール。

Rule 2 — Simplicity First（最小コード優先）

Minimum code that solves the problem. Nothing speculative.

要件外の機能、
不要な抽象化、
頼まれていない柔軟性、
起こり得ないシナリオへのエラーハンドリングを禁じる。
ここが効くと出力行数が一気に減る。

Rule 3 — Surgical Changes（外科的変更）

Touch only what you must. Clean up only your own mess.

既存コードを編集するときは、
無関係な箇所を改善しない、
動いているコードをリファクタしない、
頼まれていない限り既存のデッドコードを消さない。
スタイルは既存に揃え、
その変更で不要になったものだけ削る。
私から見るとここが一番ありがたい。

Rule 4 — Goal-Driven Execution（ゴール駆動の実行）

Define success criteria. Loop until verified.

タスクをテストで検証可能なゴールに変換し、
簡潔な複数ステップ計画を立て、
強い成功基準を持たせて自走させる。
READMEのキーインサイトはここ。

LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go.

（出典: README.md）

「やり方を指示するな、
成功基準を渡せ」。
Rule 4 はこの一言を65行のCLAUDE.mdに落とした、
という構造です。

なぜ4ルールが3大失敗に効くのか？（対応マトリクス）

4ルールを並べただけだと「ふーん」で終わる。
観察された失敗との対応関係で見ると、
設計の意図が見える。

ここがこのリポジトリの肝です。
失敗1だけは「確認省略」と「完了基準なし」の2側面があるので、
Rule 1 と Rule 4 の両方で受ける構造になっている。

個人的には、
Rule 3 が一番エンジニアにとってご褒美で、
Rule 4 が一番タスク完了率に効きそうな印象。
実装依頼で副作用が膨らむ問題を直接潰しにいっている。

既にCLAUDE.mdを書いてる人はどう統合する？

このリポジトリは環境情報を持たない行動原則のみのCLAUDE.md。
なので、
既にプロジェクトroot にCLAUDE.md がある人は末尾に追記する運用が向いている（READMEのインストール手順 Option B）。

Anthropic 公式ドキュメントによれば、
CLAUDE.md は「上書きではなく連結される」と明示されている。

All discovered files are concatenated into context rather than overriding each other.

（出典: code.claude.com/docs/en/memory）

そして CLAUDE.md は毎セッション冒頭に自動で差し込まれる。

CLAUDE.md content is delivered as a user message after the system prompt, not as part of the system prompt itself.

（出典: 同上）

つまり「システムプロンプトの一部」ではなく「ユーザーメッセージ扱いで毎回先頭に差し込まれる」仕様。
手動で `@CLAUDE.md` する必要はない。

1ファイル200行以内が公式の推奨サイズなので、
既存CLAUDE.md と合わせて200行を超えそうなら、
`@import` 構文（最大5ホップ）で別ファイルに分けるのが定石です。

Karpathy式CLAUDE.mdを既存プロジェクトに導入する手順は？

READMEのインストール手順を再構成して、
既存CLAUDE.md がある前提で5ステップにまとめる。

1. STEP1: プロジェクトroot に既存CLAUDE.md があるか確認する。`ls -la CLAUDE.md` か、エディタでroot を開いて目視。なければ STEP2、あれば STEP3 にスキップ。
2. STEP2: 新規導入ならOption A（プラグイン）を使う。ターミナルで Claude Code を起動し、`/plugin marketplace add forrestchang/andrej-karpathy-skills` → `/plugin install andrej-karpathy-skills@karpathy-skills` の順に実行（出典: README）。
3. STEP3: 既存CLAUDE.md がある場合は Option B（末尾追記）で統合する。`curl -o karpathy.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md` でダウンロード→ 中身を既存CLAUDE.md の末尾に貼り付け→ 重複ルールがあれば既存側を優先。
4. STEP4: Claude Code を再起動して、新しいCLAUDE.md が読み込まれるか確認する。CLAUDE.md は「セッション開始時に自動読み込み」が公式仕様（出典: code.claude.com/docs/en/memory）。手動で `@CLAUDE.md` を打つ必要はない。
5. STEP5: 仕上げに Plan mode（計画だけを先に立てる読み取り専用モード）を Shift+Tab を 2回押して有効化（Normal → Auto-Accept → Plan の順に切り替わる、出典: code.claude.com/docs/en/common-workflows）。Rule 1（Think Before Coding）と機能的に補完し合うので、最初の数タスクは Plan mode で動作確認するのが安全。

ここで引っかかりやすいのは STEP3。
既存CLAUDE.md に「とにかく行動して」「自走してOK」みたいな記述があると、
Rule 1 の「不明点で止まれ」と矛盾する。
重複・矛盾ルールがあれば、
Karpathy式を優先するか既存を優先するかを決めて1本に統合する作業が必須です。

Cursor派でも使える？

使える。
リポジトリには `.cursor/rules/karpathy-guidelines.mdc` が同梱されており、
CURSOR.md に Cursor 用の設定手順が書かれている（出典: forrestchang/andrej-karpathy-skills）。
Claude Code と Cursor を両方使う人は、
同じ4ルールを両ツール側で共有できる設計になっている。

これは地味だが大きい。
エディタを乗り換えても行動原則は同じ、
という運用ができる。

どんな場面で効かない？（限界）

READMEと派生レビューで指摘されている注意点は3つ。

• 非コード作業には不向き: 文章生成・要約・翻訳のような「外科的変更」が意味をなさないタスクには Rule 3 が逆に邪魔をする。コーディング専用と割り切る
• 確認回数が増える副作用: Rule 1 が強すぎると「これってこういう意味ですか？」を毎回聞いてくる。短い改修で会話が長くなるトレードオフがある
• モデル・バージョン依存: Opus 4.7 と Sonnet 4.6 で反応が変わるという観察がある（OSSのため、Claude Code側のアップデートに追随する必要がある）

正直、
この限界を最初に知らずに「全プロジェクトに置けば最強」と思って入れると、
文章系のリポジトリで Rule 3 と喧嘩する場面が出る。
私はコーディング系プロジェクトに絞るのが無難だと見ています。

必要な環境と料金は？

料金面の整理。

追加課金は一切なし。
Claude Code を既に使っている人なら追加コストはゼロ円です。

どんな場面で使える？再現可能なユースケース3つ

READMEの想定シーンと公式ドキュメントの記述から、
再現できる使い方を3つ。
各々に番号付きステップを併記する。

ユースケース1: 既存リポジトリの軽微なバグ修正で改変範囲を最小化したい

Rule 3（Surgical Changes）が主役。手順は次のとおり。

1. 該当バグのファイルパスとライン番号を Claude Code に提示する（例: `src/api/user.ts の 42行目あたりで null 参照が起きる`）
2. 「この箇所だけ修正してほしい。リファクタは不要」と明示する。Rule 3 が読み込まれていれば、無関係な箇所への手出しは抑止される
3. 修正後、`git diff` で変更行数が想定どおりか確認する。想定より多ければ Rule 3 が効いていない可能性があるので、CLAUDE.md の読み込みを再確認

ユースケース2: 仕様が曖昧な新機能を、走り出す前に詰めたい

Rule 1（Think Before Coding）と Plan mode を組み合わせる。

1. Claude Code を起動して Shift+Tab を 2回押し Plan mode に入る（出典: code.claude.com/docs/en/common-workflows）
2. 「○○機能を追加したい。前提・複数解釈・代替案を出してから着手して」と依頼する
3. 提示された計画を読んで、不明点・誤解を潰してから「進めてOK」と返す。承認後にファイル編集が走る

ユースケース3: 「とりあえず書きました」で止まる現象を潰したい

Rule 4（Goal-Driven Execution）の運用。

1. タスク依頼時に「成功基準」を明示する。例: 「`pytest tests/test_user.py` が全てパスすること」「ESLint エラー0件」「型エラー0件」
2. Claude Code に成功基準を渡し、自走させる。READMEのキーインサイト「Don't tell it what to do, give it success criteria」のとおり、やり方ではなく基準を渡すのが要
3. Claude Code 側がループして基準を満たすまで実行する。途中で「これでいいですか？」と聞かれたら、基準が曖昧だった可能性が高いので、より検証可能な条件に書き換える

3つとも、
CLAUDE.md がプロジェクトroot にあることが前提です。
私ならユースケース1（Rule 3）から試します。
差分行数の縮みが一番見えやすい。

よくある疑問

Q1. Karpathy本人が書いたCLAUDE.mdなの？

違う。
READMEに "derived from Andrej Karpathy's observations" と明記されており、
リポジトリ作成者は Forrest Chang。
Karpathy 本人はリポジトリの contributor でも author でもありません（出典: README）。
「Karpathy式」は通称で、
Karpathy が観察した3大失敗を Forrest Chang が CLAUDE.md に翻訳した、
というのが正確な説明です。

Q2. 既存CLAUDE.mdを上書きすると問題ある？

Karpathy式は環境情報（言語・フレームワーク・ファイル構成）を持たないので、
上書きすると環境情報が失われて困る。
READMEのOption B（末尾追記）が推奨される運用です。
Anthropic公式ドキュメントによれば、
CLAUDE.md は「上書きではなく連結」されるので、
上下の階層に分けて2ファイル運用するのもあり（出典: code.claude.com/docs/en/memory）。

Q3. Cursor でも使える？

使える。
`.cursor/rules/karpathy-guidelines.mdc` が同梱されている。
CURSOR.md に Cursor 側の設定手順が書かれている（出典: リポジトリ）。
Claude Code 専用ではない。

Q4. 商用プロジェクトに入れても大丈夫？

MITライセンスなので商用OK・改変OK・再配布OK。
ライセンス表記の維持だけ守ればよい（出典: LICENSE）。

Q5. Plan mode と組み合わせる必要はある？

必須ではないが、
Rule 1（Think Before Coding）と機能的に補完関係にある。
Anthropic公式ドキュメントによれば、
Plan mode はファイル読み取り・分析のみを行い、
編集・実行は承認後（出典: code.claude.com/docs/en/common-workflows）。
仕様が曖昧な依頼で Rule 1 を強く効かせたい時に組み合わせると安心です。

このページに出てきた言葉

関連記事

• Claude Code 進化年表（Opus 4.7まで）
• Claude Magazine 定期更新まとめ
• Claude エコシステム アップデート常時更新

参考リンク

• forrestchang/andrej-karpathy-skills（GitHub リポジトリ本体）
• README.md（4ルール・3大失敗の英語原文）
• CLAUDE.md 本体（65行）
• Anthropic公式: Claude Code Memory（CLAUDE.md仕様）
• Anthropic公式: Common Workflows（Plan mode含む）
• Andrej Karpathy: 2025 LLM Year in Review

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。