Karpathy CLAUDE.md と衝突：126Kの星（コミュニティ版）— 進階規則12条を整理

4月13日、abmediaが報じたところによると、Forrest ChangはKarpathyの1月のClaudeによるコード作成への不満を整理し、「4本のCLAUDE.mdルール」をまとめた。当時そのGitHubリポジトリには累積15,000スターが付いており、5月12日にはスター数が126,000を突破していた。1か月未満で8倍に増えた。これを受けて、コミュニティでは多くの「拡張版」が登場した。その中でも、エンジニアのMnilax（@Mnimiy）が5月9日に発表した「4本の基礎に8本を追加して12本の完成版にした」という投稿は、5,968回のいいねを獲得しており、近頃のClaude Codeコミュニティで議論されている単発記事の中でも屈指の高い注目度となっている。

4本ルールの振り返り：Forrest ChangがKarpathyの不満を実行可能なテンプレートに変換

Forrest Changの元となる4本ルール（各項目は、Karpathyが1月にXで挙げた失敗パターンに対応）：

Think Before Coding（先に考えてから書く）：暗黙の前提を置かないで、どんな前提を置いているかを明確にすること；トレードオフを広げて議論すること；不確かならすぐ質問して、決めつけないこと；より単純なやり方があるなら複雑な案に反対すること

Simplicity First（まずはシンプルに）：問題を解決できる最小限のコードを書くこと；推測に基づく機能は書かないこと；一度限りのコードに抽象化レイヤーを作らないこと；経験豊富なエンジニアは「複雑すぎる設計は簡素化せよ」と言う

Surgical Changes（外科的な変更）：動かすべきものだけを動かし、「ついでに」近くのコード、コメント、フォーマットを改善しないこと；壊れていないものはリファクタリングしないこと；既存のスタイルに合わせること

Goal-Driven Execution（目標志向で実行）：成功基準を定義して、検証できるところまで反復すること；Claudeに手順を教えるのではなく、「成功した姿」を示して自分でloopさせること

Anthropicの公式ドキュメントは実はかなり明確に書いている：CLAUDE.mdは「助言（advisory）」のファイルで、Claudeはだいたい80%の確率で従う；200行を超えると、重要なルールがノイズに埋もれて合規率が急激に下がる。Forrest Changの案は、ルールを65行・4本に圧縮し、「floor（最低ライン）」に到達させたものだ。

Mnilaxが加えた8本：2026/5月のagent時代に出てきた新しい失敗パターンを補う

Mnilaxの主張：Karpathyの1月の不満は「Claudeがコードを書く」という状況に集中していたが、5月のClaude Codeの生態系は多agentの協業、hookの接続、skillの読み込み衝突、複数ステップのワークフローがsessionをまたぐといった新しい場面へと進化している――だからルールを追加する必要がある。以下は彼が増やした8本（原文の順序で整理）：

Rule 5：Claudeは判断が必要なタスク（分類、起草、要約、抽出）にのみ使い、確定的な意思決定（503のリトライ、ルーティング、status codeの扱い、確定的な変換）は一般のコードで処理する

Rule 6：Token budgetは「推奨」ではない――単一タスク4,000 tokens、単一session 30,000 tokensを上限とし、budgetに近づいたら主導で要約して再起動し、静かに超過しない

Rule 7：衝突する2つのコードパターンは「どちらかを明示して選ぶ」（より新しく、よりテストがある方）こと、選んだ理由を説明し、もう一方は「後で整理する」とマークすること；2つを混ぜるのが最悪の選択

Rule 8：コードを書く前にまず理解する――ファイルのexports、直接のcaller、共有utilityを読むこと。「見た目は無関係（looks orthogonal）」は最も危険な言い回しで、不確かなら聞く

Rule 9：テストは「意図」を検証するのであって、「挙動」だけを検証するのではない――「業務ロジックが変わったら失敗する」テストを書けてこそ合格；そうでなければClaudeに自信を持たせるだけで、実際の保護力はゼロになる

Rule 10：多ステップのタスクはcheckpointする――1ステップ終えるごとに「何をしたか、何を検証したか、何が残っているか」をまとめること；状態を明確に説明できないなら、続行しない

Rule 11：既存のcodebaseの慣例に合わせる――たとえ納得できなくても、snake_caseはsnake_case、class componentはclass component；納得できないなら別の議論にして、単独で分岐しない

Rule 12：失敗は大きく出す――「migration完了」は、30件をスキップしていたら不適切；「テスト通過」も、どれか1つでもスキップしていたら不適切。デフォルトで「不確実性は能動的に開示する」、そして「不確実性を隠す」な

Mnilaxは、30のcodebaseで6週間以内にこの12条をテストし、誤り率が41%から3%に下がり、合規率はわずかにしか下がらなかった（78% → 76%）と自称している。本メディアの観察：これらの数字は作者自身によるテスト結果であり、独立した検証はない。しかし8本のルール自体の内容は堅実で、当時のClaude Codeにおける複数エージェントの使用状況（たとえばAgent Viewでの複数session管理、6層アーキテクチャ内のMulti-Agent Layer）における痛点に、しっかり対応している。

適用シーンと、実務的な提案

Mnilaxは、試すべきでないやり方についても率直に挙げている：

14本を超えるルール：合規率が52%まで落ちる（76%から急降下）、200行は実質的な上限

ルールの代わりに例で示す：3つの例のtokenコストは10本のルールと同等になり、Claudeは単一の例に過剰適合しやすい

「Be careful / think hard / really focus」などの抽象的な指示：検証可能性が低く、合規率はわずか30%

Claudeに「資深エンジニアとして振る舞って」と頼む：identity promptは行動の変化に対して無効で、ルール型の指示だけが有効

特定ツールへの依存：「永遠にeslintを使え」は、eslintが未導入だと黙って失敗しがち。代わりに「codebaseの既存スタイルに合わせる」といった、能力中立的な言い回しにする

本メディアが勧める実務的な取り入れ方：CLAUDE.mdは「行動契約」であって、願い事のリストではない――各ルールは「このルールがどの具体的な誤りを防ぐのか」に答える必要がある。もしあなたの仕事が多ステップのpipelineを含まないなら、Rule 10（checkpoint）は無関係だ；codebaseに既にlintで単一スタイルが強制されているなら、Rule 11（慣例に合わせる）は余計だ。12本を読んだうえで、「実際に踏んだ穴」に対応するバージョンだけ残し、それ以外は削除できる。

追跡可能な今後の出来事には、以下が含まれる：Anthropic公式がCLAUDE.mdを標準化するかどうか（現状は「advisory」だけ）、Forrest Changのrepoが公式の推奨テンプレートに入るかどうか、コミュニティに特定領域（フロントエンド／バックエンド／データエンジニアリング）向けのカスタム版が現れるかどうか、そしてClaudeモデルのバージョン更新後にルールの合規率が変化するかどうか。

この記事「Karpathy CLAUDE.mdで126Kスターに到達：コミュニティ版12本の上級ルール整理」は、最初に「リンクニュース ABMedia」に掲載された。