Karpathyの CLAUDE.md が刺さる理由は、AIに「何を作るか」ではなく「どう働くか」を先に渡しているからです。
Xで、OpenAIの創業期メンバーとして知られるAndrej Karpathy氏の CLAUDE.md が話題になっていました。
紹介されていた中身は、ライブラリでもアプリでもありません。
AIコーディングエージェントに向けた、短い行動ルールです。
おもしろいのは、内容が新技術ではないことです。
むしろ、AIにコードを書かせた人なら一度は感じる不満を、かなり短く言語化しています。
- 曖昧なまま進む
- すぐ大げさに作る
- 頼んでいない場所まで直す
- 「直して」で終わると検証が弱い
この4つを止めるための原則として、X投稿では次の4つが紹介されていました。
Think Before Codingは、書く前に前提を出すルール
AIコーディングで一番こわいのは、間違えることそのものではありません。
前提がずれたまま、自信ありげに進むことです。
Think Before Coding は、コードを書く前に考えを出させるための原則です。
たとえば、次のような動きです。
- 何を直す依頼なのかを一文で言う
- 複数の解釈があるなら並べる
- 足りない情報があれば聞く
- いきなり大きな変更に入らない
これは「AIを遅くするルール」ではありません。
むしろ逆です。
最初の30秒で前提をそろえると、あとで1時間の手戻りを減らせます。
人間の開発でも同じです。
強いエンジニアほど、手を動かす前に「つまり今回の目的はこれですね」と確認します。
AIにも同じ癖を入れる。
それがこの原則の意味です。
Simplicity Firstは、AIの盛りすぎを止めるルール
AIは、放っておくとすぐ立派に作ります。
抽象化します。
設定を増やします。
将来使うかもしれない関数を置きます。
でも、たいていの修正に必要なのは、未来の巨大設計ではありません。
今の問題を、読める形で直すことです。
Simplicity First は、最小で解くための原則です。
ここで大事なのは、「短ければよい」ではないことです。
読みやすく、消しやすく、あとで理由を追えることが大事です。
たとえば、50行で済む処理を1000行の仕組みにしない。
1回しか使わない抽象化を増やさない。
使っていないコードを残さない。
AIに任せるほど、この原則は効きます。
AIは書く速度が速いので、過剰設計の発生速度も速いからです。
Surgical Changesは、頼まれた場所だけを切るルール
AIに修正を頼むと、たまに「ついでにきれいにしました」が起きます。
これが一番レビューしづらいです。
バグ修正のはずが、命名も変わる。
コメントも消える。
関係ないファイルも整う。
見た目はよさそうでも、どこで挙動が変わったのか追いにくくなります。
Surgical Changes は、外科手術のように必要な場所だけを変える原則です。
変更した1行が、依頼内容までたどれる。
これが強い基準になります。
「この変更はなぜ必要か」と聞かれたときに、ユーザーの依頼、再現した問題、通したテストのどれにもつながらないなら、その変更はたぶん余計です。
AI時代のレビューでは、きれいな差分より小さい差分が大事です。
小さい差分は、確認できます。
確認できる差分は、本番に出しやすいです。
Goal-Driven Executionは、命令ではなく成功条件を渡すルール
AIに「バグを直して」と言うと、AIは何かを直します。
でも、それが本当に直ったかは別です。
Goal-Driven Execution は、作業ではなく成功条件を渡す原則です。
たとえば、こう変えます。
- 「バグを直して」
- 「バグを再現するテストを書いて、そのテストが通る状態にして」
この差は大きいです。
前者は、AIが修正っぽいことをした時点で止まりやすいです。
後者は、再現、修正、検証まで進みます。
AIは、明確なゴールがあると強いです。
赤いテストを緑にする。
ページの表示崩れをスクリーンショットで確認する。
APIのレスポンスが指定どおりになる。
こういう成功条件があると、AIは自走しやすくなります。
4つの原則は、AIへの就業規則
この4原則をまとめると、AIへの就業規則になります。
- 書く前に考える
- 小さく作る
- 余計な場所を触らない
- 成功条件まで走る
派手な話ではありません。
でも、AIコーディングの失敗はだいたいこの逆で起きます。
考えずに書く。
大きく作る。
周辺まで触る。
検証せず終わる。
だから、CLAUDE.md に書くべきなのは、長い思想ではなく短い行動ルールです。
AIに毎回説明したくないことを、ファイルに固定する。
それだけで作業の質はかなり変わります。
自分のCLAUDE.mdに入れるなら、この4行からでいい
最初から完璧な CLAUDE.md を作る必要はありません。
まずは次のような短いルールで十分です。
- Before coding, restate the goal and list assumptions.
- Prefer the simplest change that solves the current problem.
- Keep changes surgical; do not refactor unrelated code.
- Define success with tests, screenshots, or verifiable output.日本語で書くなら、こうです。
- 書く前に目的と前提を短く確認する。
- 今の問題を解く最小の変更を優先する。
- 依頼と関係ないリファクタや整理をしない。
- テスト、スクリーンショット、出力などで成功条件を確認する。このくらい短いほうが効きます。
AIへの指示は、長いほど強くなるわけではありません。
短く、具体的で、作業中に何度も参照できるほうが強いです。
CLAUDE.mdの価値は、AIを賢くすることではない
CLAUDE.md の価値は、AIを急に賢くすることではありません。
AIの働き方を、毎回同じ方向にそろえることです。
人間でも、現場のルールがあると動きやすくなります。
AIも同じです。
何を勝手にしてよいか。
何をしてはいけないか。
どこまで確認したら完了か。
ここが決まると、AIはただのコード生成機ではなく、かなり扱いやすい作業相手になります。
Karpathyの CLAUDE.md が話題になった理由は、たぶんここです。
新しい道具を作ったのではなく、AIに仕事を頼むときの不満を、短いルールに落とした。
だから多くの人が「これ、自分も困っていたやつだ」と感じたのだと思います。
