Claude Codeが勝手にコードを変える・過剰実装する時の対策｜Karpathy式CLAUDE.mdでAIコーディングの暴走を防ぐ方法【2026年5月22日時点】
まず結論：Claude Codeが便利なのに怖いなら、最初に入れるべきは「賢いプロンプト」ではなく「暴走防止ルール」です
Claude Code、Cursor、Codex系のAIコーディングエージェントを使っていて、こんな経験はないでしょうか。
「バグ修正だけ頼んだのに、関係ないファイルまで変えられた」
「シンプルな関数でよかったのに、なぜか巨大なクラス設計にされた」
「コメントや既存スタイルまで勝手に直された」
「動いたと言われたけど、テストも再現確認も弱い」
「AIの出した差分が大きすぎて、レビューする方が疲れる」
この悩みがあるなら、最初に確認すべきなのが andrej-karpathy-skillsのGitHubページ です。
これは、Claude Codeに「もっと頑張ってコードを書け」と命令するものではありません。むしろ逆です。AIに対して、
「勝手に決めるな」
「余計な機能を足すな」
「関係ないところを触るな」
「成功条件を決めてから進め」
と、実務で本当に必要なブレーキをかけるためのガイドラインです。
GitHubのREADMEでは、このリポジトリはAndrej KarpathyのLLMコーディングに関する観察をもとに、Claude Codeの挙動を改善する単一の CLAUDE.md と説明されています。さらに、Plugin方式、CLAUDE.md方式、Cursorルール方式にも対応しています。
Claude Codeが勝手にコードを変える問題は、初心者だけの悩みではない
AIコーディングでよくある誤解は、「プロンプトの書き方が下手だから暴走する」というものです。
もちろん、依頼の仕方は重要です。しかし、問題はそれだけではありません。LLMは、曖昧な依頼を受けると、足りない情報を自分で補って先に進もうとします。その結果、ユーザーが頼んでいない前提を置き、頼んでいない実装を加え、頼んでいないリファクタリングまで始めることがあります。
Karpathyも、AIコーディングの進化を認めながら、AIが書くコードには人間の監督が必要で、膨らんだコード、コピー＆ペースト、脆い抽象化が出ることがあると指摘しています。
つまり、AIコーディングの本当の課題は「AIが書けないこと」ではありません。
むしろ今の課題は、AIが書けすぎることです。
書けるからこそ、余計に書く。
速いからこそ、間違った方向にも速く進む。
自信ありげに返すからこそ、ユーザーが気づくまでズレが拡大する。
この問題を放置すると、最初は便利だったはずのClaude Codeが、次第に「レビュー負荷を増やす存在」になってしまいます。
andrej-karpathy-skillsとは何か？
andrej-karpathy-skills は、Claude Codeの動作を改善するための行動ガイドライン集です。中核にあるのは、たった4つの原則です。
1つ目は Think Before Coding。コードを書く前に、前提・不明点・複数解釈・トレードオフを明示させる原則です。
2つ目は Simplicity First。頼まれていない抽象化、将来のためだけの柔軟性、過剰なエラーハンドリングを避け、今日の問題を最小限のコードで解決させる原則です。
3つ目は Surgical Changes。依頼された範囲だけを外科手術のように変更し、関係ないファイル、コメント、既存スタイルを勝手に直さないようにする原則です。
4つ目は Goal-Driven Execution。作業内容ではなく、成功条件を先に定義し、テストや検証で完了を確認させる原則です。
実際の CLAUDE.md でも、「不確かな場合は聞く」「200行で書いたものが50行で済むなら書き直す」「すべての変更行はユーザーの依頼に直接つながるべき」「バグ修正なら再現テストを書いて通す」といった実務向けの指示が整理されています。
なぜ普通のCLAUDE.mdより効果が出やすいのか？
Claude Codeには、プロジェクトごとの指示を CLAUDE.md に書く仕組みがあります。公式ドキュメントでも、Claude Codeは各セッションで新しいコンテキストから始まり、CLAUDE.md や自動メモリによってプロジェクト情報や指示を保持すると説明されています。
しかし、ここで多くの人が失敗します。
プロジェクトの説明、技術スタック、コマンド、コーディング規約、禁止事項、レビュー観点、デプロイ手順、すべてをCLAUDE.mdに詰め込んでしまうのです。
すると、肝心の「AIにどう振る舞ってほしいか」が薄まります。結果として、Claude Codeはプロジェクト情報は知っているのに、相変わらず余計な実装をしたり、勝手に前提を置いたりします。
andrej-karpathy-skills の強みは、プロジェクト固有情報ではなく、AIコーディングエージェントの行動原則そのものに絞っている点です。
つまり、ReactでもNext.jsでもPythonでもGoでもRustでも、共通して使える土台になります。
プロジェクト固有のルールは別途追加すればよい。
しかし、AIが勝手に暴走しないための基本姿勢は、全プロジェクトで共通化できる。
この切り分けが非常に実務的です。
具体的にどんな場面で効くのか？
たとえば、あなたがClaude Codeにこう頼んだとします。
「ログイン時にメールアドレスが空だと落ちるバグを直して」
普通のAIエージェントは、善意でメールバリデーション全体を作り直し、ユーザー名の検証を足し、関係ないコメントを書き換え、型注釈まで追加することがあります。
一見すると良い改善に見えます。しかし、実務ではこれは危険です。
なぜなら、依頼されたのは「空のメールで落ちるバグ修正」だけだからです。周辺コードまで触ると、レビュー範囲が広がり、予期しない副作用が増え、リリース判断が難しくなります。
andrej-karpathy-skills の EXAMPLES.md では、こうした「drive-by refactoring」、つまり頼まれていないついでのリファクタリングを悪い例として示し、必要な行だけを変える修正例を提示しています。
これは、個人開発よりも、チーム開発で特に効きます。
チーム開発では、差分の小ささが正義です。
レビューしやすいPRは、マージしやすい。
マージしやすいPRは、リリースしやすい。
リリースしやすいコードは、事業スピードを上げます。
AIがたくさん書くことより、AIが「必要な分だけ正確に書く」ことの方が、実務では価値が高いのです。
Claude Code Pluginとして使えるのが便利
andrej-karpathy-skills は、単にREADMEを読んで終わりではありません。Claude Code Pluginとして導入できます。
READMEでは、Claude Code内でまずマーケットプレイスを追加し、その後プラグインをインストールする方法が案内されています。プラグイン方式にすると、ガイドラインを全プロジェクトで使えるようになります。
Claude Code公式ドキュメントでも、プラグインはSkills、Agents、Hooks、MCP serversなどを含めてClaude Codeを拡張する仕組みであり、マーケットプレイスを追加して個別プラグインをインストールする流れが説明されています。
つまり、毎回プロンプトに長文を貼る必要はありません。
一度、行動原則として入れておけば、Claude Codeに対して「このプロジェクトでは余計なことをするな」「曖昧なら確認しろ」「テストで検証しろ」という基礎姿勢を持たせやすくなります。
Cursorユーザーにも意味がある
このリポジトリはClaude Code専用に見えますが、Cursorユーザーにも役立ちます。
CURSOR.md では、このリポジトリにCursor project ruleが含まれており、別プロジェクトで使う場合は .cursor/rules/karpathy-guidelines.mdc をコピーして使う方法が説明されています。また、Cursorは .claude-plugin や CLAUDE.md をデフォルトでは読まないため、CursorではCursor用ルールとして扱う必要があると整理されています。
これは重要です。
「Claude Codeで話題だからCursorでは関係ない」と思うのはもったいないです。問題の本質はClaude Code固有ではありません。AIコーディングエージェント全般が持つ、
勝手な前提
過剰設計
余計な変更
検証不足
という共通の失敗パターンへの対策だからです。
導入前に知っておくべき注意点
ただし、andrej-karpathy-skills を入れれば、AIコーディングの問題がすべて解決するわけではありません。
READMEにも、これらのガイドラインは「速度より慎重さに寄る」ため、単純なタイポ修正や明らかな1行変更では毎回フルの厳密性を使う必要はない、といったトレードオフが明記されています。
また、これはKarpathy本人が公式に配布したツールではありません。ZennやQiitaの解説でも、Karpathy本人の公式CLAUDE.mdではなく、Forrest Chang氏のリポジトリがKarpathyの観察をClaude Code向けに構造化したものだと整理されています。
そのため、正しい使い方は「盲信する」ことではありません。
まずベースルールとして導入する。
そのうえで、自分のプロジェクトに合わせて調整する。
テストコマンド、禁止事項、レビュー基準、ディレクトリ構成などは、自分のCLAUDE.mdに追加する。
この使い方が一番安全です。
どんな人におすすめか？
andrej-karpathy-skills は、特に次の人におすすめです。
Claude Codeで差分が広がりすぎて困っている人。
CursorでAIが勝手に設計を盛ることに悩んでいる人。
AIコーディングを個人開発ではなく実務に入れたい人。
PRレビューしやすいAI生成コードが欲しい人。
既存コードを壊さず、必要な箇所だけ直してほしい人。
「動きました」ではなく、テストと成功条件で完了確認したい人。
チーム全体でAIコーディングのルールを揃えたい人。
逆に、AIに自由にプロトタイプを作らせたいだけの人、速度最優先で多少の差分拡大を気にしない人、毎回ゼロから作る使い捨てコードが中心の人には、少し慎重すぎると感じるかもしれません。
最短の使い方
一番おすすめなのは、まずGitHubページを開いてREADMEを確認することです。
→ andrej-karpathy-skillsのGitHubページはこちら
そのうえで、Claude Codeを使っているならPlugin方式、特定プロジェクトだけで試したいならCLAUDE.md方式、Cursorで使いたいなら .cursor/rules 方式を選ぶのがよいです。
導入後は、すぐに大規模な本番コードで試すより、まず小さなバグ修正や軽いリファクタリングで効果を見るのがおすすめです。
確認すべきポイントは単純です。
差分が小さくなったか。
勝手な前提を置かなくなったか。
実装前に確認が出るようになったか。
余計な抽象化が減ったか。
テストや成功条件を先に出すようになったか。
READMEでも、ガイドラインが効いている状態として「不要な差分が減る」「過剰実装による書き直しが減る」「実装前に確認質問が来る」「きれいで最小限のPRになる」と説明されています。
まとめ：AIコーディングで本当に必要なのは、アクセルだけでなくブレーキである
Claude CodeやCursorの進化によって、AIはかなりコードを書けるようになりました。
しかし、実務で必要なのは「たくさん書けるAI」ではありません。必要なのは、必要なところだけ、必要な理由で、検証可能な形で書けるAIです。
andrej-karpathy-skills は、そのための非常に現実的な出発点です。
勝手に前提を決めない。
余計な機能を足さない。
関係ないところを触らない。
成功条件を決めて検証する。
この4つをClaude CodeやCursorに徹底させるだけで、AIコーディングの体験はかなり変わります。
Claude Codeが便利なのに、どこか怖い。
AIに任せたいけれど、レビュー不能な差分は困る。
チーム開発でも安心してAIを使いたい。
そう感じているなら、まずは andrej-karpathy-skillsのGitHubページ を開き、READMEと導入手順を確認してみてください。これは、AIコーディングを「速いけれど危ない道具」から「実務で使える相棒」に近づけるための、かなり費用対効果の高い一手です。
