GitHubトレンド1位のKarpathy CLAUDE.mdを読んで、自分のCLAUDE.mdが膨らみすぎていた件

この記事でわかること

今日、Andrej KarpathyのCLAUDE.mdがGitHubトレンド1位になっているのを知った。読んでみたら「あ、これ自分のことだ」と思う箇所が複数あった。特に Simplicity First——必要最小限のコードだけ書けという原則を読んだとき、自分のCLAUDE.mdが600行近くに膨らんでいることに気づいた。この記事はKarpathyの4原則の解説と、SE/PMとして「自分の運用の何が違うのか」を考えた記録。

記事概要図

→ → →

出典: github.com/karpathy/dotfiles · multica-ai/andrej-karpathy-skills

Karpathyって誰？なぜCLAUDE.mdがトレンド1位になったか

Andrej Karpathyは元OpenAI共同創業者・元Tesla AIディレクター。AI研究者としての知名度は言わずもがなだが、最近は「自分のコーディングの80%がClaudeによるエージェント駆動になった」と公言しており、開発者の間で注目されている人物。

そのKarpathyが自分のdotfilesリポジトリに置いていた .claude/CLAUDE.md が、2026年初頭にGitHubトレンド1位を獲得。わずか65行のMarkdownが10万スターを超えた。

なぜウイルス的に広まったか、理由は単純で「LLMコーディングあるある失敗パターン」を4つの原則に集約しているから。読んだ開発者が「これ全部やられたことある」と感じる普遍性がある。

参考：Karpathy’s CLAUDE.md: The 65-Line File With 100K GitHub Stars / GitHub - multica-ai/andrej-karpathy-skills

4原則：65行で10万スターを集めた思想

上の図で示した4原則の詳細。日本語で整理する。

① Think Before Coding（実装前に考える）

項目	内容
コアメッセージ	仮定するな。混乱を隠すな。トレードオフを表面化せよ
具体的な指示	仮定があれば明示する／複数の解釈がある場合は提示してから進む／不明点は実装前に聞く
防ぎたい失敗	「エクスポート機能を追加して」と言われてJSON形式・対象範囲・プライバシー影響を勝手に決める

② Simplicity First（最小限で解く）

項目	内容
コアメッセージ	問題を解く最小限のコードだけ書く。投機的なコードはゼロ
具体的な指示	要求されていない機能を追加しない／単一用途の抽象化を避ける／50行で済むなら200行にしない
防ぎたい失敗	割引計算ロジックを頼んだだけなのに、Strategyパターンの複数クラスを生成される

③ Surgical Changes（必要な箇所だけ触る）

項目	内容
コアメッセージ	触るべき箇所だけ触る。自分のミス以外は掃除しない
具体的な指示	要求に直結した部分のみ変更／既存のスタイル・規約に合わせる／無関係なコードの整形・型ヒント追加をしない
防ぎたい失敗	バグ修正を頼んだのに、無関係な関数のdocstringや引用符スタイルまで書き換えられる

④ Goal-Driven Execution（成功基準を定義して任せる）

項目	内容
コアメッセージ	ステップ指示ではなく、測定可能な成功基準を渡す
具体的な指示	「バグを修正して」→「バグを再現するテストを書き、テストを通して」に変換する
防ぎたい失敗	細かい手順を指示しすぎて、LLMが自律的に問題を解けなくなる

自分のCLAUDE.mdと照らして気づいたこと

このブログを含む副業プロジェクト全体をClaude Codeで回しており、自分なりのCLAUDE.mdを運用している。Karpathyの4原則を読んで気づいた点が3つある。

① Simplicity First — 自分のCLAUDE.mdが膨らんでいる

正直に言うと、自分のCLAUDE.mdは肥大化している。ブログ運営・BGM制作・株分析・X投稿と複数チャネルを1つのプロジェクトで管理しているため、ルールが積み重なった結果がこれ。

Karpathyの65行に対して、自分の構成はCLAUDE.md本体に加え .claude/rules/ 配下に9ファイルが存在する。「多ければ多いほど良い」と思って書き続けていたが、Simplicity Firstの観点からすると逆効果になっている可能性がある。

Claudeが長いCLAUDE.mdを読む場合、後半の指示は無視されやすいという問題は実際に知られており、信号密度を高める（短く・命令形で書く）ことが重要とされている。

② Surgical Changes — dev-workflow.mdに同じ原則が既にある

.claude/rules/dev-workflow.md に「設計書なしに実装を始めることを禁止」というルールを書いている。これはSurgical Changesそのもので、「スコープ外に踏み出すな」という意図と一致している。

ただ文体が「〜すること」という説明形になっており、Karpathyのように「Touch only what you must」という命令形のほうが遵守率が高い可能性がある。

③ Think Before Coding — 不明点確認ルールは一致

CLAUDE.mdに「不明点は作業前に確認する（曖昧なまま進めない）」と書いており、これはThink Before Codingと同じ思想。ここは問題なし。

これから試すこと

今日の気づきとして、以下を近々やってみる。

CLAUDE.md本体のスリム化 — チャネル固有の詳細を .claude/rules/ に移し、本体は「絶対に守るべき最上位ルール」だけに絞る
命令形への書き換え — 「〜すること」を「〜せよ」「〜するな」に統一して信号密度を上げる
Goal-Driven Executionの実験 — 「記事を書いて」ではなく「読者の悩みTop1を解決する記事を、ドラフト保存まで完了させよ」という形で指示してみる

まだ書いていない人への最小テンプレ

CLAUDE.mdをまだ書いていないなら、まずKarpathyの4原則だけコピペするのが最速。

# CLAUDE.md

## Think Before Coding
- 仮定があれば実装前に明示する
- 複数の解釈がある場合は提示してから進む
- 不明点は実装前に確認する

## Simplicity First
- 要求されていない機能を追加しない
- 最小限のコードで問題を解く

## Surgical Changes
- 要求に直結した箇所だけ変更する
- 無関係なリファクタリングはしない

## Goal-Driven Execution
- 「〜を修正して」ではなく「〜が通る状態にせよ」で指示する

自分のプロジェクト固有のルール（使用技術・禁止ライブラリ・ファイル命名規則）は、慣れてきたら少しずつ追加していけばいい。最初から完璧を目指すと逆に肥大化する——これ自分の失敗例。

Claudeでの学習環境が気になる人は、Udemyのコースも選択肢になる。

Udemyで講座を探す（セール時が狙い目）

まとめ

KarpathyのCLAUDE.mdは65行・4原則のシンプルな設計で10万スターを獲得
4原則（Think Before Coding / Simplicity First / Surgical Changes / Goal-Driven Execution）はLLMコーディングの「あるある失敗」を防ぐための思想
Simplicity Firstを読んで、自分のCLAUDE.mdが肥大化していることに気づいた——これが今日の最大の収穫
まだ書いていない人は4原則のコピペから始めるのが最速

一次ソース：