2026年1月下旬：Andrej KarpathyがXに、Claudeのコード生成に関する不満を投稿しました。3つの失敗パターン — 暗黙の誤った前提、過度な複雑化、そして触れるべきではないコードへの無関係なダメージ。Forrest Changはこのスレッドを読み、それらの不満を4つの行動ルールとして1つのCLAUDE.mdファイルにまとめ、GitHubに公開しました。 初日で5,828スター。2週間で60,000ブックマーク。2026年中盤までに120,000スターを獲得。 今年最も急速に成長した単一ファイルのリポジトリとなりました。2026年5月9日、以下のハンドルネームを持つ認証済みデベロッパーが @mnilax (Mnimiy) 今年最も鋭いエンジニアリング上の主張の1つを含む長文のX記事を投稿しました。彼らは30のコードベースで6週間にわたりテンプレートをテストし、不足を補うためにさらに8つのルールを追加しました。270万ビュー、18,800ブックマーク。これがその全容の解説です — そして、Antigravity（または他のエージェントIDE）内で GEMINI.md または AGENTS.md ファイルと共にClaudeを実行している場合に、それが何を意味するのかを説明します。
Get the latest on AI, LLMs & developer tools
New MCP servers, model updates, and guides like this one — delivered weekly.
— @Mnilax 2026年5月9日
本記事で解説する @mnilax の元のXポスト — 270万閲覧、1.88万ブックマーク、2026年5月9日
1. バイラルした瞬間
Karpathyの元のスレッドは、何かを指示するようなものではありませんでした。それは不満の吐露 — シニアエンジニアが最悪な午後を過ごした後に投稿するような類のものでした。3つの具体的な失敗パターン：
- 暗黙の誤った前提。 Claudeがあなたの意図を推測し、その誤った推測に基づいて構築を進め、それを決して伝えないこと。
- 過度な複雑化。 Claudeが抽象化、レイヤー、汎用ヘルパーを多用しようとすること。4行の修正が40行になってしまいます。
- 無関係な箇所へのダメージ。 Claudeが触れるべきではなかったコードを"改善"してしまうこと — 空白、命名、フォーマット、指示していない隣接する関数など。
Forrest Changはそのスレッドを読み、他の誰もやらなかったことを実行しました。Karpathyが暗に求めていたことを書き出したのです。4つの短く命令的なルール。1つのファイル。65行。パブリックリポジトリ。そのスピード感が重要でした — Forrestは解説を加えず、フレームワーク化もせず、収益化もしませんでした。ただルールだけを提示したのです。
これが大きな反響を呼びました。日々Claudeと格闘していたデベロッパーたちは、突然「リポジトリのルートにこのファイルを貼り付けるだけ」という、一行のインストール手順を手に入れたのです。指標がすべてを物語っています — コードが一行も含まれていないファイルに120,000スター。それらのデベロッパーの多くは、現在もその4つのルールだけを運用し続けています。
2. オリジナルの4つのルール（Karpathy、Forrest Chang経由）
これがベースとなる、作成されたままのルールです。もし現在 CLAUDE.md を持っていないなら、まずはこれらから始めましょう：
ルール 1 — コーディングの前に考える。 暗黙の前提を置かないこと。前提としていることを明示してください。トレードオフを明確にしましょう。推測する前に質問してください。よりシンプルなアプローチがある場合は、異議を唱えてください。
ルール 2 — シンプルさ第一。 問題を解決するための最小限のコード。憶測に基づいた機能は不要です。一度しか使わないコードを抽象化しないでください。シニアエンジニアが「複雑すぎる」と言うようなら、簡素化しましょう。
ルール 3 — ピンポイントな変更。 必要な箇所のみを触ること。隣接するコードやコメント、フォーマットを「改善」しようとしないでください。壊れていないものをリファクタリングしないでください。既存のスタイルに合わせてください。
ルール 4 — ゴール駆動の実行。 Define success criteria. Loop until verified. Don't tell Claude what steps to follow; tell it what success looks like and let it iterate.
Mnimiyのデータによれば、これら4つのルールが解決するのは： 非監視下の Claude Code セッションにおける失敗パターンの約40%です。残りの約60%は、オリジナルのテンプレートでは対処されていないギャップに存在します。
3. なぜ拡張が必要だったのか
テンプレートが書かれたのは2026年1月でした。2026年5月の Claude Code エコシステムは、もはや別物です。この記事では、オリジナルの4つのルールではカバーしきれない、1月以降の4つの現実を指摘しています。
- エージェント同士の衝突。 2つのエージェントが同じファイルを編集し、互いに干渉し合うマルチエージェント設定。Karpathyのルールは、単一のオートコンプリートループを想定しています。実際の マルチエージェントのオーケストレーションには、 所有権に関するルールが必要です。
- フックの連鎖（カスケード）。 Claude Code のフックは、ツールが呼び出されるたびに実行されます。予算（制限）がなければ、1つの冗長なフックが200トークンのリクエストを8,000トークンに変えてしまいます。
- スキル読み込みの競合。 複数 スキル 説明が重複しているスキルは、説明一致型のディスパッチャーを混乱させます。元のテンプレートには、曖昧さを解消する方法が記載されていません。
- マルチステップのワークフロー。 6ステップのリファクタリングにおいて、ステップ4で失敗すると、ステップ5と6は壊れた状態の上に構築されることになります。元のテンプレートでは、Claudeの各ターンをワンショットとして扱っています。
Mnimiy'sの提唱： 元の4つは基礎となるものであり、間違っているわけではありません。ただ、不完全なのです。
4. 8つの新しいルール（それぞれが策定されるきっかけとなった瞬間と共に）
これらはすべて、30のコードベースを対象とした調査における特定の事象から生まれました。この記事では、その瞬間を紹介し、次にルールを提示します。以下は、同じ構成で要約したものです。
ルール 5 — モデルに言語以外の作業をさせない
決定論的な判断は、決定論的なコードに任せるべきです。リトライポリシー、ルーティング、エスカレーションの閾値などは、LLMの呼び出しではなくコードで記述してください。モデルの判断は週ごとに変わってしまいます。
その瞬間： "503エラー時にリトライするかどうかを判断する" LLM呼び出しは2週間は正常に機能していましたが、モデルがリクエストボディを判断のコンテキストとして読み取り始めたため、挙動が不安定になり始めました。プロンプトが実質的にランダムになったことで、リトライポリシーもランダムになってしまいました。
ルール 6 — トークン予算を厳守する（例外なし）
あらゆるループは、50,000トークンのコンテキストダンプへと連鎖する可能性があります。モデルは自ら停止することはありません。予算を設定することで、明確な制限（hard floor）を設けることができます。
その瞬間： 同じ8KBのエラーメッセージを繰り返す90分間のデバッグセッション。最終的に、Claudeはユーザーが40メッセージ前に拒否した修正案を提示していました。トークン予算があれば、12分時点でこのループを強制終了できていたはずです。
ルール 7 — 競合を表面化させる（平均化しない）
コードベースの2つの部分で不一致がある場合、Claudeは両方を立てようとします。その結果、両方のパターンが混在し、どちらの状況でも正しく動作しない支離滅裂なコードが生成されます。
その瞬間： あるコードベースに2つのエラーハンドリングパターンがありました — async/awaitとtry/catch、そしてグローバルなエラーバウンダリです。Claudeはその両方を行うコードを書きました。エラーが2回握りつぶされ、原因の特定に30分かかりました。
ルール8 — 書く前に読む
Karpathy's "Surgical Changes"（外科的変更）は、Claudeに隣接するコードに触れないよう指示しますが、隣接するコードを理解するようには指示しません。このルールを追加しないと、Claudeは30行先にある既存のコードと競合する新しいコードを書いてしまいます。
その瞬間： Claude added a function next to an existing identical function it hadn't read. The new one won by import order. The original had been the source of truth for 6 months.
ルール9 — テストは必須だが、それがゴールではない
Goal-Driven Execution（目標駆動型の実行）は「テスト通過」を成功と見なします。実際には、Claudeは表面的なテストはパスするものの、本番環境の動作を壊すようなコードを書くことがあります。
その瞬間： 認証機能に対する12個のテストがすべてパスしているのに、本番環境では認証が壊れていました。テストは関数が 何らかの値を返したことを確認しただけで、正しい値を返したかどうかは見ていませんでした。関数が定数を返していたため、テストをパスしてしまったのです。
ルール10 — 長時間実行される操作にはチェックポイントが必要
元のテンプレートは1回限りのやり取りを想定しています。実際のClaude Codeの作業は、20ファイルにわたるリファクタリング、セッションを通じた機能実装、コミットをまたぐデバッグなど、マルチステップです。チェックポイントがなければ、一度のミスですべての進捗が失われます。
その瞬間： 6ステップのリファクタリングのステップ4で失敗しました。Claudeは壊れた状態のままステップ5と6を進めてしまいました。それを紐解くのは、リファクタリングを最初からやり直すよりも時間がかかりました。
ルール11 — 規約は斬新さに勝る
確立されたパターンがあるコードベースにおいて、Claudeは独自のパターンを導入したがります。たとえその方法が「より優れて」いたとしても、2つ目のパターンを導入することは、どちらか一方のパターンだけがある状態よりも悪影響を及ぼします。
その瞬間： ClaudeはクラスコンポーネントのコードベースにReact hooksを導入しました。hooks自体は動作しましたが、 componentDidMountを前提としていたコードベースのテストパターンを壊してしまいました。削除して書き直すのに半日かかりました。
ルール 12 — サイレントに失敗させず、目に見える形で失敗させる
最もコストのかかる Claude の失敗は、一見成功したように見えるケースです。関数が "動作" しているのに誤ったデータを返す、マイグレーションが "完了" したのに 30 レコードがスキップされている、テストが "パス" したのにアサーションが間違っている、といった状況です。
事例： Claude がデータベースマイグレーションを "正常に完了しました" と報告した際、実際には制約違反が発生したレコードの 14% がサイレントにスキップされていました。スキップはログに記録されていましたが、表面化されませんでした。11 日後、レポートの数値に違和感が生じたことでようやく発覚しました。
5. 数値で見る結果
Mnimiy は、30 のコードベースにおける 50 の代表的なタスクを 6 週間にわたり、3 つの構成（CLAUDE.md なし、オリジナルの 4 ルール、完全な 12 ルール）で追跡しました。ミス率とは、意図通りにするために修正や書き直しが必要となったタスクの割合を指し、7 つの異なる失敗タイプ（silent wrong assumption、over-engineering、orthogonal damage、silent failure、convention violation、conflict averaging、missed checkpoint）に基づいて算出されました。
CLAUDE.md なし： ミス率 ~41%、ベースラインの遵守なし
4 ルール： ミス率 ~11%、遵守率 78%
12 ルール： ミス率 ~3%、 遵守率 76%
ミス率の劇的な低下（41% → 3%）は、当然の結果と言えます。 興味深い のは、ルールを 4 つから 12 つに増やしても 遵守のオーバーヘッドがほとんど増加しなかった点です (78% → 76%) 一方でミス率はさらに 8 ポイント削減されました。新しいルールは、元の 4 ルールがカバーしていなかった失敗モードを対象としており、同じ注意力を奪い合うことはありません。
これこそが、ルールを 4 つ以上に増やすべき実証的な根拠です。もしルールを追加することで遵守率が比例して低下するのであれば、4 つで止めるのが正解でしょう。しかし、実際にはそうはならないのです。
6. オリジナルのテンプレートが密かに破綻するポイント
Karpathy's 4 だけでは不十分な4つのシナリオ — ルールを追加する前の段階でもそうです。この記事では、オリジナルの原則が間違っているわけではなく、2026年1月の問題領域に対処していることを明示しています。
- 長時間実行されるエージェントのタスク。 これらのルールは Claude がコードを書く瞬間を対象としています。マルチステップのパイプラインについては言及されていません。budget ルールも、checkpoint ルールも、fail-loud ルールもありません。パイプラインに乖離が生じます。
- マルチコードベース間での一貫性。 "Match existing style" は、スタイルが1つであることを前提としています。12のサービスを持つ monorepo では、Claude はどのスタイルを選ぶべきか判断しなければなりません。オリジナルのルールにはその方法が記されていないため、ランダムに選ぶか、平均的なスタイルになってしまいます。
- テストの品質。 Goal-Driven Execution は「テスト通過」を成功と見なします。テストが有意義であるべきだとは書かれていません。その結果、役立つことは何もテストしていないのに、Claude に自信だけを持たせるようなテストが出来上がります。
- Production 対 prototype。 Production コードをオーバーエンジニアリングから守るための同じ4つのルールが、方向性を探るために100行の speculative scaffolding を正当に必要とする prototype の開発速度を落としてしまいます。"Simplicity First" が初期段階のコードに対して過剰に反応してしまうのです。
7. うまくいかなかったこと（失敗した実験）
おそらくこの記事で最も有用なセクションです — 採用されたルールではなく、明示的に不採用となったパターンについてです。
- ソーシャルメディアから収集されたルール。 そのほとんどは、Karpathy's 4 を別の言葉で言い換えたものか、汎用性のないドメイン固有のルール（"always use Tailwind classes" など）でした。不採用。
- 14個を超えるルール。 Mnimiy は最大18個までテストしました。14個を超えると遵守率は76%から52%に低下しました。Anthropic がドキュメントに記載している「200行の天井」は実在します。それを超えると、Claude はルールを実際に読むのではなく、「ルールが存在する」という pattern-match を行うだけになってしまいます。
- ツールに依存するルール。 "Always use eslint" は eslint がインストールされていない場合に黙って失敗します。そのため、機能に依存しない表現である "match the codebase's enforced style" に置き換えられました。
- ルールの代わりの例示。 3つの例示は、約10個のルールと同じくらいのコンテキストを消費し、Claude はそれらに over-fit してしまいます。ルールは抽象的であり、例示は具体的です。ルールを使用しましょう。
- 曖昧な強調語。 "注意深く、" "よく考えて、" "本当に集中して。" 遵守率は約30%に留まります。これらはテスト可能ではないからです。代わりに、"前提条件を明示する"といった具体的な命令形に置き換えました。
- アイデンティティ・プロンプト。 Claudeに"シニア"になるよう伝えても機能しません。Claudeはすでに自分をシニアだと思っています。遵守率のギャップは思考と実行の間にあります。命令形はそのギャップを埋めますが、アイデンティティ・プロンプトでは不可能です。
8. メンタルモデル
この記事を最も重要な一文にまで削ぎ落とすと、次のようになります：
CLAUDE.mdはウィッシュリストではありません。それは、実際に観察された特定の失敗モード（failure modes）を解消するための行動契約です。
すべてのルールは次の問いに答えるものであるべきです： このルールはどの間違いを防ぐためのものか？
これにより、すべてが再定義されます。ほとんどの開発者はCLAUDE.mdを、時間の経過とともに肥大化するスタイルの好み（likes/dislikes）のリスト、つまり個人設定ファイルとして扱っています。この記事の主張は、設定ファイルという形式は間違いであるということです。正しい形式は、実際に遭遇した失敗モードのリストであり、1つのモードに対して1つのルールを割り当てるべきです。
また、この記事が直感に反する推奨事項で締めくくられている理由も説明されています：
実際の失敗モードに合わせて調整された6つのルールのCLAUDE.mdは、決して必要のないルールが6つ含まれた12個のルールのものよりも優れています。
Xで誰かが言っていたからといって、12個すべてを貼り付けないでください。それらを読み、自分が犯した間違いに該当するものだけを残し、残りは捨ててください。
9. Antigravityへのマッピング (GEMINI.md / AGENTS.md)
この記事はClaudeに焦点を当てていますが、その抽象化は移植可能です。Antigravityは、同じ形式の2つのファイルから手順ルールを読み取ります：
- GEMINI.md — Gemini専用のシステムプロンプトファイル。こちらの GEMINI.md guideをご覧ください。
- AGENTS.md — ツール横断的なフォーマット（Claude Code, Cursor, Antigravityで動作）。こちらの AGENTS.md ガイド.
どちらも強制ではなく推奨事項であり、200行程度で遵守率が低下し始めます。また、どちらも "ルールを明記し、例示を避け、曖昧な強調語を使わない" という同じ規律に従っています。12のルールは基本的にそのまま適用されます。Antigravity 特有の考慮事項は以下の通りです：
- ルール6（トークン予算）は、任意ではなく極めて重要になります。 Antigravity のクォータは Claude Code よりも早く消費されます。このルールを、当社の token-reduction playbook.
- ルール10（チェックポイント）は、Antigravity's Agent Manager に対応します。 マルチエージェントの実行がステップ4で失敗した場合、最初からやり直すのではなく、エージェントを停止して以前のアーティファクトから再開できるようにする必要があります。
- ルール7（コンフリクトの表面化）は、モデルの切り替えに役立ちます。 セッションの途中で Gemini と Claude Opus を切り替える場合（当社の model-swap analysis）、新しいモデルは古いモデルから古いコンテキストを継承し、互換性のないパターンの整合性を取ろうとすることがよくあります。
- ルール12（可視化された失敗）は、Autopilot において最も過小評価されています。 もし auto-acceptを実行している場合、気づく前にサイレントエラーが複数の Cmd-Enter サイクルにわたって蓄積されます。スキップされたすべてのステップをエージェントに強制的に表面化させてください。
テンプレートは同じ、ランタイムは別、ロジックは共通です。
Get the latest on AI, LLMs & developer tools
New MCP servers, model updates, and guides like this one — delivered weekly.
10. 12ルールのフルテンプレート（コピー＆ペースト可能）
これを以下として保存してください： CLAUDE.md （または GEMINI.md または AGENTS.md）をリポジトリのルートに配置してください。元の記事によると、以下のプロジェクト固有の追加分を含めて、合計ファイルサイズを200行未満に抑える必要があります。それを超えると、遵守率が低下します。
これがそのファイルです。これを使って行うべき2つのことがあります：
- 12のルールを正直に読んでください。 今月実際に犯したミスに当てはまるものはどれですか？それらを残し、残りは削除してください。自分の失敗パターンに合わせて調整された6つのルールのファイルは、決してトリガーされることのない12のルールのファイルよりも優れています。
- 以下にプロジェクト固有のルールを追記してください。 Stack-specific ("always use the Repository pattern"), test-runner ("run pnpm test:unit before reporting done"), error patterns. Keep the total under 200 lines.
11. FAQ
CLAUDE.md 12ルールテンプレートとは？
これは、Andrej Karpathyによる2026年1月のClaudeの失敗パターンに関するスレッドを基に、Forrest Changが作成した4ルールのCLAUDE.mdファイルを拡張したものです。Mnimiy (@mnilax) がオリジナルのルールを30のコードベースで6週間検証し、2026年5月に追加の8ルールを公開しました。これらは、オリジナル作成後に出現した問題（エージェント同士の競合、フックの連鎖、スキル読み込みの衝突、マルチステップワークフローの逸脱など）をカバーしています。
Karpathyとは誰か、そしてオリジナルの4つのルールをパッケージ化したのは誰か？
Andrej Karpathyは著名なAI研究者（元Tesla、OpenAI）です。彼は2026年1月下旬、Claudeのコード生成において繰り返し見られる3つの失敗パターン（「暗黙の誤った前提」、「過度な複雑化」、「無関係な箇所へのダメージ」）をスレッドに投稿しました。Forrest Changはこのスレッドを読み、不満点を4つの行動ルールとして1つのCLAUDE.mdファイルにまとめ、GitHubに公開しました。このリポジトリは初日で5,828スターを獲得し、2026年半ばまでに120,000スターに達しました。これは、その年で最も急速に成長したシングルファイル・リポジトリとなりました。
これらのルールは、実際にどの程度ミスを減らすのでしょうか？
30のコードベースと50の代表的なタスクにわたるMnimiyの測定結果によると、CLAUDE.mdがない場合のミス率は約41%でした。オリジナルの4つのルールを適用すると約11%になり、12のルールすべてを適用すると約3%まで低下しました。コンプライアンス（Claudeが関連するルールを明示的に適用した頻度）は、4つのルールと12のルールの間でほぼ横ばい（78% → 76%）でした。これは、新しいルールが、同じ注意力の枠を奪い合うのではなく、オリジナルの4つでは対処できなかった失敗パターンをカバーしていることを示唆しています。
AntigravityはClaudeではなくGeminiを使用していますが、これはAntigravityにも当てはまりますか？
はい。Antigravityは、リポジトリのルートにあるMarkdownファイル（AGENTS.mdおよびGEMINI.md）から、同様の形式で手続き的なルールを読み取ります。これらは強制ではなく推奨事項として扱われ、コンプライアンスが低下し始める前の約200行が上限となります。12のルールはほぼそのまま転用可能です。AntigravityのAGENTS.mdおよびGEMINI.mdガイド（以下にリンク）で、具体的なマッピングについて解説しています。
なぜ12個のルールなのですか？もっと増やさないのはなぜですか？
Mnimiyは最大18個のルールをテストしました。14個を超えると、コンプライアンスは76%から52%に急落しました。Anthropicがドキュメントに記載している「200行の天井」は現実のものです。これを超えると、Claudeはルールを実際に読むのではなく、「ルールが存在する」というパターンマッチングを始めてしまいます。テンプレートの規律は、すべてのルールが毎セッション読まれるように、サイズを十分に小さく保つことにあります。
12個すべてのルールを使うべきですか、それとも一部を選ぶべきですか？
選択してください。記事では明確に述べられています。「自分の実際の失敗パターンに合わせて調整された6つのルールのCLAUDE.mdは、決して必要のないルールを含む12個のルールよりも優れている」と。12個を読み、実際に経験したミスに当てはまるものを残し、残りは捨ててください。マルチステップのパイプラインを実行しないのであれば、ルール10（チェックポイント）は不要です。コードベースにリントされたスタイルが1つしかない場合、ルール11（「慣習は斬新さに勝る」）は冗長です。
オリジナルのKarpathyテンプレートが密かに機能しなくなるのはどこですか？
Mnimiy identifies four gaps: (1) long-running agent tasks — no budget, no checkpoint, no fail-loud rules; (2) multi-codebase consistency — 'match existing style' assumes one style, fails in monorepos with multiple services; (3) test quality — 'tests pass' as the only goal means Claude writes tests that test nothing; (4) production vs prototype — 'Simplicity First' overfires on early-stage code that legitimately needs speculative scaffolding.
Mnimiyが試してうまくいかなかったアプローチは何ですか？
5つのことが失敗しました：(1) ソーシャルメディアからルールを収集すること — ほとんどが言い換えか、一般化できないものでした。(2) 14個以上のルール — コンプライアンスの崩壊。(3) 「常にeslintを使用する」といったツール依存のルール — ツールがない場合に暗黙的に失敗します。(4) ルールの代わりに例示を用いること — 負荷が重くなり、モデルが過学習します。(5) 「注意深く」や「よく考える」といった曖昧なルール — 検証不可能であるため、コンプライアンスは約30%に留まりました。(6) 「シニアエンジニアのように振る舞う」といったアイデンティティ・プロンプト — Claudeはすでに自分をシニアだと思っています。命令的なルールがギャップを埋めるのであり、アイデンティティ・プロンプトでは解決しません。