はじめに

Andrej Karpathy 氏が、ここ数週間 Claude を使ってコーディングして感じたことを X に長文で投稿していました。冒頭は「A few random notes from claude coding quite a bit last few weeks.」と軽い書き出しですが、内容は コーディングワークフローのフェーズシフト・LLM の失敗パターン・レバレッジの効かせ方・スキルの萎縮・2026年の slopacolypse までを横断する濃いものでした。

Karpathy 氏は、OpenAI の創設メンバーの一人で、Tesla では AI / Autopilot 部門を率い、Stanford の深層学習講義「CS231n」を設計・担当したことでも知られる研究者・エンジニアです。近年は「Software 2.0」や「vibe coding」といった言葉の発信源としても語られることが多く、AI とソフトウェア開発の関わり方について発言が注目されやすい人物です。今回の投稿も、そうした立場からの「現場でひとしきり使ってみた所感」として読むと、温度感がつかみやすいと思います。

この投稿で Karpathy 氏が指摘した「LLM の癖」を、CLAUDE.md という1枚の Markdown ファイルとして落とし込んだ OSS が GitHub で注目されています。multica-ai/andrej-karpathy-skills というリポジトリで、2026年6月末時点で 約 18.5万スター・約 1.9万フォーク（数値は変動するため、最新は GitHub 側で確認してください）。実行コードはほぼなく、CLAUDE.md・CURSOR.md・EXAMPLES.md などの Markdown と、Claude Code / Cursor 用のプラグイン設定ファイルが中心 のリポジトリです。

このリポジトリの GitHub 上のパスは、現在 multica-ai/andrej-karpathy-skills です。旧パス forrestchang/andrej-karpathy-skills でアクセスすると新パスへリダイレクトされます（git・raw 取得とも旧名のまま動作します）。本記事では新しい multica-ai/... を正として表記しますが、後述のとおり公式 README のインストールコマンドには旧オーナー名が残っている箇所があります。

本記事では、

Karpathy 氏が投稿で実際に何を書いていたのか
そこから抽出された「LLM の3つの癖」とは何か
それを抑制する4原則（Think / Simple / Surgical / Goal）の中身
自分のプロジェクトに導入するときに考えたほうがよいこと

を、原文と OSS のドキュメントを参照しながら整理していきます。Claude Code や Cursor を業務で使っていて「diff が膨らみすぎる」「頼んでいない箇所まで触られる」と感じている方に、何かしらの手がかりになれば幸いです。

なお、断定的な書き方は避けています。原則自体が「速さより慎重さを優先する設計思想」なので、すべてのプロジェクトに合うわけではありません。あくまで「こういう設計の OSS がある」「自分のチームで部分的に取り入れる価値があるかも」という温度感で読んでいただけたらと思います。

1. Karpathy 氏の投稿、何が書かれていたのか

最初に投稿全体を俯瞰しておきます。4原則の話だけ取り上げると、Karpathy 氏が出した文脈の半分くらいを落としてしまうためです。

投稿はテーマごとにラベリングされていて、おおまかに次のような構成でした。

セクション	大意
Coding workflow	11月までは「手作業+補完が8割、エージェント2割」だったが、12月には逆転して「エージェント8割、編集と仕上げ2割」になった。"programming in English" の感覚
IDEs / agent swarms / fallability	「IDE はもう要らない」「エージェント群でいける」というハイプは行き過ぎ。LLM の間違いは、もはや構文エラーではなく、雑なジュニア開発者がやりそうな概念ミス
Tenacity	エージェントは疲れない・腐らない・諦めない。スタミナがボトルネックではなくなった
Speedups	速くなるというより、これまで「割に合わなかった」コードまで書けるようになる "expansion"
Leverage	LLM は「成功条件を満たすまでループする」のが非常に得意。命令ではなく成功基準を渡せ
Fun	退屈な穴埋めが減って創造的な部分が残るので、むしろ楽しい
Atrophy	自力でコードを書く能力は確実に落ちている。生成と読解は別の能力
Slopacolypse	2026年は GitHub・Substack・arxiv・X / Instagram でスロップが氾濫する年になりそう
Questions	10X エンジニアの分散はさらに広がるか、ジェネラリストはスペシャリストを上回るか、社会の何割が知的労働で詰まっていたのか
TLDR	Claude と Codex の整合性が2025年12月あたりで「ある閾値」を超えた。インテリジェンスは進んだが、統合・組織プロセス・拡散はまだ追いついていない

この投稿の中で、4原則 OSS が直接の足場にしているのは 「IDEs / agent swarms / fallability」 と 「Leverage」 の2セクションです。前者は「LLM がやらかす癖」を列挙し、後者は「ではどう使うのが効くのか」を提案しています。

2. Karpathy 氏が指摘した「LLM の癖」を読み解く

「IDEs / agent swarms / fallability」セクションには、現在のコーディングエージェントが起こすミスのリストが、ほぼ箇条書きのように列挙されていました。要点を抜き出すとこうなります。

勝手に仮定を立てて、確認せずに走り出す
自分の混乱を管理せず、明確化を求めない
矛盾を表面化させない
トレードオフを提示しない
押し返すべき場面で押し返さない
いまだに少し追従的（sycophantic）
コードや API を過剰に複雑化する
抽象を膨らませる
自分が書いたデッドコードを片付けない
1000行で書いた構造を、人間が「これでいいんじゃない？」と言うと、即座に100行に縮められる
タスクと直交していても、気に入らないコメントやコードを副作用的に書き換える / 削除する
これらは CLAUDE.md に多少のルールを書いたくらいでは消えない

最後の一行が個人的にいちばん刺さります。「CLAUDE.md を書いただけでは消えない」というのは、私自身も Claude Code を仕事で使っていて感じる感覚と一致していました。それでも Karpathy 氏は「ネットでは依然として大きな改善で、手作業に戻るのは想像しがたい」と締めています。

multica-ai/andrej-karpathy-skills の README は、この長いリストを 3つの癖 に丸めて要約しています。

wrong assumptions without checking（勝手な仮定）
overcomplicate code（過剰な複雑化）
unintentionally modify unrelated code（無関係なコードを副作用的に変更）

長い列挙を3点に圧縮しているので、その分こぼれているニュアンスもあります（たとえば「sycophantic」や「デッドコードを片付けない」あたりは独立した課題でもあります）。ただ、対策ルールに落とすうえでは、この3点に集約しておく整理は実用的だと感じました。

3. 4原則の全体像

リポジトリでは、上の3つの癖に対応する形で4つの原則を定義しています。

原則	日本語の意味	対応する癖
Think Before Coding	書く前に考える	勝手な仮定
Simplicity First	シンプルさ優先	過剰な複雑化
Surgical Changes	外科的な変更	無関係なコードの変更
Goal-Driven Execution	ゴール駆動の実行	レバレッジ全般（自走の質）

3つの癖に対して原則は4つで、最後の Goal-Driven Execution は「癖の対策」というよりは、Karpathy 氏の 「Don't tell it what to do, give it success criteria and watch it go.」 という Leverage の一節を運用ルールに変換したものに見えます。

導入方法は驚くほどシンプルで、CLAUDE.md を1枚プロジェクトルートに置くか、Claude Code のプラグインを入れるか、Cursor なら .cursor/rules/ に配置するかのいずれかです。コードはほぼなく、Markdown が言語インターフェースになっている点が特徴的です。

4. 各原則の中身を、Bad / Good で見ていく

ここからは原則ごとに、リポジトリが README と EXAMPLES.md で示している考え方を、自分なりの言葉で整理します。具体例については、原文の意図を踏まえつつ、こちらで言い換えています。

4-1. Think Before Coding（書く前に考える）

仮定を勝手に置かず、必要に応じて確認や代替案の提示を行うルールです。

たとえば「ユーザー情報をエクスポートする機能を追加してほしい」という依頼が来たとします。これは一見すると明確な要望に見えますが、実装に落とすと曖昧な点がいくつもあります。

対象は全ユーザーか、現在ログイン中のユーザーか
出力はファイルダウンロードか、API レスポンスか、メール送信か
含めるフィールドは何か。機微情報の扱いはどうするか
件数や頻度はどの程度を想定するか

Bad パターンは、これらを自分で「たぶんこうだろう」と決めて、そのまま実装まで進んでしまうことです。後から「いや、それは違う」と言われると、PR をまるごと書き直すコストが発生します。

Good パターンは、実装に入る前に 不明点を箇条書きで返す、または 複数の解釈を A / B / C と並べて選ばせる ことです。さらに「それよりもっとシンプルなアプローチがあるならそれを提案する」も含まれます。

人間のシニアエンジニアが新人にレビューで求めることと同じですが、LLM はデフォルトでこれをやってくれません。だから「やる」とルールに書いておく、というのがこの原則の発想です。ただし、依頼が十分に明確な場合に毎回確認が入るのは冗長なので、依頼の曖昧さに応じてバランスを取るのが現実的だと感じています。

4-2. Simplicity First（シンプルさ優先）

要求されていない機能や抽象化を入れないというルールです。

たとえば「商品の割引額を計算する関数」を頼んだとします。本来は金額に割引率を掛けて引くだけで、数行の関数で終わります。

Bad パターンは、DiscountStrategy のような抽象基底クラスを作り、PercentageDiscount・FixedAmountDiscount を派生させ、設定ファイルから戦略を切り替える設計を一気に立ち上げてしまうケースです。一見きれいに見えるのですが、いま使われている割引方式は1種類しかなく、「将来増えるかも」という仮定だけで構造が膨らんでいます。

Good パターンは、シンプルな1関数で実装しておき、「2種類目の割引方式が実際に必要になった時点で抽象化を導入する」という判断を残しておくことです。

リポジトリの基準として印象的だったのは、「シニアエンジニアが見て『これ複雑すぎない？』と言うならシンプル化する」 という言い回しです。1人で書いていると気づきにくい複雑さを、外部の視点で測るための基準として置かれていました。

ここで気をつけたいのは、これが「常にミニマルが正解」と言っているわけではない点です。たとえば本番運用が長く、変更頻度が高く、複数の戦略が確実に必要になる領域では、最初から抽象化を入れたほうがよい場合もあります。「現時点で必要なものだけ書く」と「将来を見越して設計する」のバランス自体は、各プロジェクトの事情に依存すると考えています。

4-3. Surgical Changes（外科的な変更）

依頼された箇所だけを精密に変更するルールです。

たとえば「メールアドレスのバリデータが、空文字を渡すとクラッシュするバグを直してほしい」という依頼が来たとします。本来必要な変更は、空文字や空白文字をチェックする数行だけです。

Bad パターンは、ついでに以下のようなことをやってしまうケースです。

隣にあった username のバリデーション関数まで強化する
全体のクォートをシングルからダブルに揃える
型ヒントを追加する
1行コメントを docstring に書き換える

これらは個別には「改善」かもしれませんが、依頼と直接対応していない変更が混ざるため、レビューする側は「どれが本当のバグ修正なのか」を毎行確認することになります。

Good パターンは、

必要な行だけを変更する
既存のスタイル（クォート・命名・コメントの粒度）に合わせる
自分が触ったことで不要になった既存コードのみ削除する
触っていない既存のデッドコードは「未使用のコードがあります」と言及するだけにとどめ、削除判断は人間に渡す

という挙動です。セルフチェック基準として 「全ての変更行が、ユーザーの依頼に直接対応していると説明できるか」 を1行ずつ問う、というルールが置かれています。

ただし、これも「絶対に触るな」ということではなく、「触るなら依頼として明示する」という運用に近いと理解しています。リファクタや整形を依頼した場合は、もちろんやってくれます。

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

タスクを「検証可能な成功条件」に変換してから動くルールです。Karpathy 氏の「Don't tell it what to do, give it success criteria and watch it go.」を最も直接的に体現する原則です。

Bad パターンは、「コードをレビューして問題を見つけて改善して」のような、何をもって完了とするかが不明な依頼の出し方です。LLM はこれを受けると、無限に「改善らしきもの」を出し続けることがあり、止め時がわかりません。

Good パターンは、

まず失敗するテストを書く
そのテストを通す形で実装する
テストが通り、既存のテストが落ちていないことを確認する
必要に応じて再帰的にループを回す

という流れをセットで指示することです。

成功条件が明確だと、LLM は得意の「ループしてゴールに収束する」モードに入ります。Karpathy 氏が Leverage セクションで挙げていた「素朴で正しいアルゴリズムを先に書かせ、その後正しさを保ったまま最適化させる」「ブラウザ MCP と組み合わせてループに入れる」も、根は同じ発想です。

この原則は、自分で書く分には書きやすいプロンプトとして使えます。一方、初心者にとっては「成功条件をテストとして書く」自体が学習コストになる側面もあるので、テストを書く文化が薄いプロジェクトでは、まず最小限のスモークテストから始めるのが現実的かもしれません。

5. 「成功条件を渡す」というアイデアの重み

4原則の中で、自分が一番噛みごたえがあると感じたのは Goal-Driven Execution です。

Karpathy 氏の投稿の Leverage セクションは、リポジトリの 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."

要旨をかみ砕くと、次のような関わり方の提案になります。

LLM は「特定のゴールに到達するまでループする」のが非常に得意
何をするかを細かく命令するのではなく、成功条件を渡して走らせる
まずテストを書かせ、それを通す形で実装させる
関わり方を、命令型（imperative）から宣言型（declarative）へ寄せていく

これは、コーディングエージェントに対する関わり方を、命令型（imperative）から宣言型（declarative）へシフトせよ という提案でもあります。なお最後の2点は README 上では Karpathy 氏の引用そのものではなく、原則「Goal-Driven Execution」として運用ルール化された形（命令を宣言的なゴールへ変換する等）で示されています。

これまでは「次にこれをして、次にこれをして」と手順を細かく指示するのが、エージェントを安全に動かすコツでした。しかし、エージェントの整合性が一段上がった現在では、手順より ゴールと制約条件 を渡すほうが、自走のレバレッジが効きやすくなっている、という観察です。

実装ルールとして見たときの Goal-Driven Execution は、「タスクを受けたら、まず検証可能な成功条件に変換してから動く」という運用に翻訳されています。素朴ですが、自分で運用してみると、依頼を出す側のスキルも問われる原則だと感じています。何が完了なのかをこちらが言語化できないタスクは、エージェントにも完了できない、という当たり前の事実を突きつけられる原則です。

6. 導入方法

リポジトリが提供している導入経路は3つです。いずれも CLAUDE.md か、それと同等のルールファイルをプロジェクトに置く形で完結します。

6-1. Claude Code プラグインとして入れる

/plugin marketplace add multica-ai/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

プラグインとして入れると、すべての Claude Code セッションで自動的に有効になります。プロジェクトごとに設定をやり直す必要がない反面、合わないプロジェクトでは個別に外す運用が必要です。

上記の新オーナー名でのマーケットプレイス追加は、手元で multica-ai/andrej-karpathy-skills への到達を確認しています。公式 README には旧オーナー名の /plugin marketplace add forrestchang/andrej-karpathy-skills が記載されたままですが、旧URLは新リポジトリへリダイレクトされるため、どちらでも同じものが入ります。マーケットプレイス名 karpathy-skills とプラグイン名 andrej-karpathy-skills は変わっていません（プラグイン定義ファイル内の author 表記は旧オーナー名のままです）。

6-2. プロジェクトの `CLAUDE.md` として置く

新規プロジェクトに新しく置くだけなら、

curl -o CLAUDE.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md

既存の CLAUDE.md がある場合は、上書きせずに追記する運用にしたほうが安全です。たとえば既存の運用ルールがある場合、プロジェクト固有の章を上に置き、その下に4原則のブロックを足す、という構成にしておくと衝突が起きにくいです。

6-3. Cursor 用のルールとして置く

Cursor を使っている場合は、リポジトリ内の Cursor 用ルールファイルを .cursor/rules/ 以下に配置します。Cursor は同ディレクトリ配下のルールを自動的に読み込むので、こちらも導入はファイルを置くだけで完了します。

6-4. チームでの運用

CLAUDE.md や Cursor のルールファイルをリポジトリにコミットしてしまえば、チームメンバー全員が同じガイドラインで Claude Code / Cursor を動かすことになります。「人によってエージェントの書き方が違う」という現象を、ルールファイルの共有である程度抑えることができます。

ただし、チームによっては「ルールが厳しすぎてエージェントが質問ばかり返す」と感じるメンバーが出るかもしれません。その場合は、章単位で緩める / 個別プロジェクトで上書きする、という運用が現実的だと思います。

7. 効いているかを判断する目安

リポジトリの README は、効果測定の指標として概ね次のようなものを挙げています。これは公開された指標というより、運用上のヒューリスティクスとして読むのがよさそうです。

不要な diff 変更が減る
初回の実装からシンプルなコードが出るようになる
実装に入る前に確認の質問が出るようになる
PR が小さく、目的が読み取りやすくなる

実務に当てはめると、以下のような変化として現れる可能性があります。

バグ修正の PR で、修正対象と無関係な行の変更が減っている
「将来の拡張のために」という理由で持ち込まれる抽象化が減っている
「対象は全ユーザーですか、ログイン中ユーザーだけですか？」のような確認が、依頼の最初に返ってくるようになっている

ただし、依頼の出し方や対象コードの性質によって効き方は変わります。たとえば、依頼そのものが既に十分に明確で、対象も狭い小さな修正だと、4原則を入れる前と挙動はあまり変わりません。差が大きく出るのは、曖昧で広めの依頼を投げたときだと感じています。

8. デメリットと、適用しないほうがよさそうなケース

リポジトリの README にも、デメリットとして「確認質問が増えて冗長に感じることがある」と明記されています。これは「速さより慎重さを優先する設計」のトレードオフです。

自分の感覚としては、以下のような場面では4原則をフルで適用しないほうが快適でした。

1度きりの使い捨てスクリプトを書くとき。確認のラリーよりも、暫定で動くものを早く出したい
すでに自分の頭で完全に設計が固まっていて、エージェントには定型的な実装作業を任せたいとき
ライブラリの使い方を試すための雑なスケッチを書きたいとき

逆に、以下のような場面では効きが大きく出やすいです。

本番環境のコードを触るとき
他人がレビューする前提のチーム開発
「ついでの変更」が混ざるとレビュー負荷が跳ね上がる、規模の大きな PR
ビジネスロジックの変更で、要件の解釈が複数あり得るとき

「全プロジェクトに同じルールを当てる」よりも、プロジェクトごとに章単位で取り入れる ほうが、運用としては破綻しにくいと感じています。たとえば本番系では Surgical Changes と Goal-Driven Execution を強めに、個人実験プロジェクトでは Think Before Coding を緩めに、といった調整が現実的です。

9. Karpathy 氏が投げかけた問いについて

最後に、4原則の話からは少し離れますが、Karpathy 氏が投稿の終盤で投げかけていた問いを振り返っておきたいと思います。4原則を実務で運用していると、これらの問いが他人事ではなくなってくるからです。

「10X エンジニア」の分散はさらに広がるか
エージェントが共通基盤として使えるようになると、それを上手く使える人と、コピペ感覚で雑に使う人で、産出量の差が大きく開く可能性があります。4原則のような「使い方の規律」が、その差を生み出すレイヤーの一つになりそうです。
ジェネラリストはスペシャリストを上回るか
Karpathy 氏は「LLM はマクロ（戦略）よりミクロ（穴埋め）が得意」と書いていました。広い領域を浅く繋げるジェネラリストの相対的な価値が上がるとすれば、自分の仕事の組み立ても見直したいところです。
手で書く能力の萎縮（atrophy）
「生成」と「読解」は別の脳の能力で、生成の機会が減れば自然に萎縮していく、と書かれていました。読解のスキルだけは絶対に維持しておかないと、エージェントが書いたコードを評価する側のスキルまで落ちてしまいます。4原則で diff が小さくなることは、読解スキルを維持するうえでも追い風になりそうです。
2026年の slopacolypse
Karpathy 氏は2026年を「あらゆるデジタルメディアでスロップが氾濫する年」と予想しています。コードのスロップを抑える OSS が約 18.5万スターを集めていることは、その問題意識が広く共有されつつある文脈で読まれている、と見ることもできそうです（因果や代表性まで示せるわけではありません）。

10. まとめ

Karpathy 氏の「Claude コーディング雑感」は、4原則の話だけ取り出すと半分くらいの文脈が落ちる、横断的な投稿でした。LLM の失敗パターン、レバレッジの効かせ方、スキルの萎縮、2026年の slopacolypse まで触れられています。
その投稿の中で列挙された「LLM の癖」を3つに圧縮し、対策として4つの原則を CLAUDE.md 1枚に落とし込んだのが multica-ai/andrej-karpathy-skills（旧 forrestchang/...）です。2026年6月末時点で 約 18.5万スター・約 1.9万フォーク。ライセンスは README 上は MIT と記載されていますが、LICENSE ファイル自体は未コミットで GitHub のライセンス検出には表示されない状態なので、業務利用の際は最新の状態を確認してください。
4原則は Think Before Coding / Simplicity First / Surgical Changes / Goal-Driven Execution。AI に特別なことを求めているわけではなく、「人間のシニアエンジニアが新人に当たり前に求める作法」を AI 側に明文化したものに近いです。
導入はファイル1枚で済むので、まずは新しいプロジェクトで試して、合わないルールを章単位で緩める運用がやりやすいです。
ただし、「速さより慎重さ」の設計なので、すべてのプロジェクトに合うわけではありません。本番系には強めに、使い捨てスクリプトには緩めに、と使い分けるのが現実的だと思います。
そして Karpathy 氏自身が書いていたとおり、CLAUDE.md に書いただけでは LLM の癖は完全には消えません。あくまで diff の暴走を「やや穏やかにする」程度に期待値を置いておくと、付き合い方を間違えにくくなりそうです。

「200行 diff にうんざりしている」「『ついでに直しておきました』が PR レビューを重くしている」という方は、試しに新しいプロジェクトで CLAUDE.md を1枚置いてみるところから始めてみてもよいかもしれません。挙動の変化が体感できれば、そのまま本番系のリポジトリへ広げる判断もしやすくなると思います。

参考リンク

Andrej Karpathy 氏の元投稿（X）: https://x.com/karpathy/status/2015883857489522876
リポジトリ: https://github.com/multica-ai/andrej-karpathy-skills （旧 https://github.com/forrestchang/andrej-karpathy-skills からリダイレクト）
同リポジトリ README: https://github.com/multica-ai/andrej-karpathy-skills/blob/main/README.md
メンテナの関連プロジェクト Multica: https://github.com/multica-ai/multica