急速に進化するAI支援コーディングの世界において、あるGitHubリポジトリが、AIコーディングエージェントのための最も人気のある行動指針として浮上しました。 forrestchang/andrej-karpathy-skills。開発者の Forrest Changは、Andrej KarpathyによるLLMコーディングの落とし穴に関する話題の考察を、1つの実行可能な CLAUDE.md ファイルに集約したものです。私たちは GitHub、Twitter/X、Reddit、ウェブ記事、そしてソースコード自体 — を徹底的に調査し、決定版ガイドを作成しました。
Get the latest on AI, LLMs & developer tools
New MCP servers, model updates, and guides like this one — delivered weekly.
🎬 解説動画を視聴する
読み物の方がお好みですか？コード例を含む完全なガイドについては、このままスクロールしてください。
1. なぜ話題になったのか
まず、なぜこのリポジトリが重要なのかを説明しましょう。これはGitHubで最も急速に成長しているリポジトリの1つとなりました — 最初の数週間で数万のスターを獲得しました — 本質的に含まれているのは 1つのファイルだけです。
フレームワークでも、ライブラリでも、アプリでもありません。AIコーディングエージェントのための単一の行動指針です。作成日は 2026年1月27日、 MIT licenseの下で公開され、今も成長を続けています。これは、業界がどこに向かっているのかについて、重要な何かを物語っています。
なぜこれが重要なのか
何千人ものコントリビューターと長年の開発期間を持つ多くの人気オープンソースツールでさえ、このリポジトリよりスター数が少ないほどです。このリポジトリは、 わずかなコミットとランタイム依存関係ゼロという状態でバイラルしました。その価値はコードにあるのではなく — それは アイデアにあります。
2. 誕生の背景
このリポジトリの起源は、以下の人物によるバイラルしたツイートに直接遡ります。 Andrej Karpathy — OpenAIの共同創設者であり、元TeslaのAIリード、そして“vibe coding”という言葉の生みの親です。彼の投稿で、Karpathyはツールやリポジトリを共有したわけではありません。彼が共有したのは 洞察 — LLMがコードを書く際の挙動に対する不満のリストでした。
ここ数週間、Claudeでかなりのコーディングを行って得られた、いくつかのランダムなメモ。
— Andrej Karpathy (@karpathy) 2026年1月26日
コーディングワークフロー。LLMのコーディング能力の最近の向上により、他の多くの人々と同様に、私も11月時点の「約80%の手動+オートコンプリート、20%のエージェント」から、急速に「80%のエージェントによるコーディング、20%の編集+仕上げ」へと移行しました…
開発者の Forrest Chang はこれらの洞察を読み、実用的な行動を起こしました。彼はそれらを構造化され、マシンリーダーブルな CLAUDE.md に変換したのです。 ファイル。曖昧なブログ記事でも、Twitterのスレッドでもない、 設定ファイルです。 AIエージェントが実際に読み取り、それに従うためのものです。
重要な洞察はこうです。Karpathyが問題を特定し、Forrest Changが解決策をコード化しました。そしてコミュニティがその両方を検証した結果、GitHubで最も多くのスターを獲得したAIワークフローリポジトリの一つとなりました。
3. Karpathyが特定した問題点
Karpathy'sの観察は、単なる曖昧な不満ではありませんでした。それは、AIコーディングエージェントを使用するすべての開発者が経験したことのある、具体的で再現可能なパターンでした。彼の言葉をそのまま引用します：
問題1：隠れた前提
“モデルは勝手に間違った前提を置き、確認もせずにそのまま進めてしまいます。混乱を管理せず、明確化を求めず、矛盾を表面化させず、トレードオフを提示せず、本来すべき反論もしません。”
問題2：オーバーエンジニアリング
“彼らはコードやAPIを過度に複雑にし、抽象化を肥大化させ、デッドコードをクリーンアップしないことを好みます... 100行で済むところに1000行を超える肥大化した構造を実装してしまいます。”
問題3：意図しないサイドエフェクト
“タスクとは無関係であっても、十分に理解していないコメントやコードをサイドエフェクトとして変更したり削除したりすることがあります。”
Claude Code、Copilot、Cursor、あるいはその他のAIコーディングエージェントを使ったことがあるなら、これを実感したことがあるはずです。バグの修正を依頼すると、ファイルの半分を書き換えてしまう。機能の追加を依頼すると、抽象化レイヤーを丸ごと構築してしまう。助けを求めると、間違った前提のまま自信満々に突き進んでしまう。
Redditコミュニティ（特にr/ClaudeAIやr/ClaudeCode）では、この挙動を表す広く使われている言葉があります： “自信満々なジュニア開発者” AIは高速で知識も豊富ですが、監視がないと初歩的なミスを犯しがちです。優秀ですが信頼性に欠ける — まさに明確なガードレールを必要とするエンジニアのような存在です。
4. 4つの原則
Forrest ChangはKarpathyの観察を4つの原則にまとめました。それぞれが、特定の種類のLLMの失敗に直接対処するものです。
| 原則 | 対処内容 |
|---|---|
| コーディングの前に考える | 誤った前提、潜在的な混乱、トレードオフの欠如 |
| シンプルさの優先 | 過度な複雑化、肥大化した抽象化、憶測に基づく機能 |
| 最小限かつ的確な変更 | 直交的な編集、不必要なコードへの接触、スタイルの逸脱 |
| ゴール駆動の実行 | 曖昧な実装、検証の欠如、不十分な成功基準 |
それぞれを詳しく見ていきましょう。
原則1：コーディングの前に考える
“思い込みを排除する。混乱を隠さない。トレードオフを明確にする。”
これは最も根本的な原則です。LLMは解釈を勝手に決めつけて進めてしまう傾向があります。この原則は、明示的な推論を強制します：
- 前提条件を明示する — 不確かな場合は、推測せずに質問する
- 複数の解釈を提示する — 曖昧さがある場合、勝手に判断しない
- 必要に応じて異議を唱える — よりシンプルなアプローチがある場合は、それを伝える
- 混乱したときは立ち止まる — 不明な点を特定し、説明を求める
例：隠れた前提の罠
ユーザーのリクエスト： “Add a feature to export user data”
def export_users(format='json'):
users = User.query.all()
# 全ユーザー、ファイルの保存場所、フィールドを勝手に想定
# CSVのフィールド名 — 何も質問せずに実行
実装する前に、以下の点を確認する必要があります：
1. スコープ：全ユーザーをエクスポートしますか、それともフィルタリングされたサブセットですか？
（プライバシーへの影響）
2. フォーマット：ファイルをダウンロードしますか？それともバックグラウンドジョブで実行しますか？
API endpointは？
3. フィールド: どのユーザーフィールドが必要ですか？
(機密性の高いものが含まれる可能性があります)
4. ボリューム: 通常、ユーザー数はどのくらいですか？
最もシンプルなアプローチ: 次のようなAPI endpointを追加します
ページネーションされたJSONを返します。ご希望はありますか？
原則 2: シンプルさ優先
“問題を解決する最小限のコード。推測による実装はしない。”
これはLLMのオーバーエンジニアリングの傾向を抑制するためのものです。ルールは厳格です:
- 要求された以上の機能は追加しない
- 一度しか使わないコードを抽象化しない
- 要求されていない“柔軟性”や“設定可能性”は持たせない
- 起こり得ないシナリオに対するエラーハンドリングは行わない
- 200行のコードが50行で済むなら、書き直す
判定基準: シニアエンジニアが「これは複雑すぎる」と言うでしょうか？ もしそうなら、簡素化してください。
例：過剰な抽象化の罠
ユーザーのリクエスト： “割引を計算する関数を追加して”
class DiscountStrategy(ABC):
@abstractmethod
def calculate(self, amount): ...
class PercentageDiscount(DiscountStrategy): ...
class FixedDiscount(DiscountStrategy): ...
class DiscountConfig: ...
class DiscountCalculator: ...
# 1つの計算に50行以上
# 使用するために30行以上のセットアップが必要
def calculate_discount(amount, percent):
"""割引を計算します。percentは0-100です。"""
return amount * (percent / 100)
# 使用例
discount = calculate_discount(100.0, 10.0) # 10ドル引き
リポジトリからの重要な洞察
“「複雑すぎる」例は、明らかに間違っているわけではありません — それらはデザインパターンやベストプラクティスに従っています。問題は、 タイミング：必要になる前に複雑さを持ち込んでしまうからです。” 優れたコードとは、明日の問題を早まって解決するのではなく、今日の問題をシンプルに解決するものです。
原則3：外科手術のような変更
“必要な箇所だけに手を加えること。自分が散らかしたものだけを片付けること。”
これは、LLMが無関係な変更を加えてしまうというKarpathy'sの不満に、最も直接的に対処する原則です。既存のコードを編集する際は：
- 隣接するコードやコメント、フォーマットを“改善”しないこと
- 壊れていないものをリファクタリングしないこと
- 自分のやり方とは異なっていても、既存のスタイルに合わせること
- 無関係なデッドコードに気づいた場合は、指摘するにとどめ — 削除はしないこと
変更によって孤立したコードが発生した場合：
- 以下のインポート、変数、関数を削除してください： 「自分」の変更によって 未使用になったもの
- 指示がない限り、以前から存在していたデッドコードは削除しないこと
テスト基準： 変更されたすべての行が、ユーザーのリクエストに直接紐付いている必要があります。
例：「ついで」のリファクタリングという罠
ユーザーのリクエスト： “空のメールアドレスでバリデーターがクラッシュするバグを修正して”
15行を変更:
- docstringを追加（指示外）
- ユーザー名のバリデーションを追加（指示外）
- コメントを変更（指示外）
- メールアドレスのバリデーションロジックを“改善”（指示外）
- 各所に .strip() の呼び出しを追加（指示外）
3行を変更:
- メールの空文字ガードを追加
- クラッシュ回避のため変数参照を変更
- 他には一切手を加えていません。
例：スタイルドリフトの罠
ユーザーのリクエスト: “アップロード関数にロギングを追加して”
The LLM adds logging — but also changes single quotes to double quotes, adds type hints nobody asked for, adds a docstring, reformats whitespace, and restructures the boolean return logic. The correct approach: add 既存のスタイルを 使用したロギング行 のみ (single quotes, no type hints, same spacing).
原則4：ゴール駆動の実行
“成功基準を定義し、検証されるまでループする。”
この原則は、KarpathyがLLMを活用する上で最もレバレッジが高いと考えている洞察を捉えています。
Karpathy's 重要な洞察
“LLMは特定の目標を達成するまでループを繰り返すことが非常に得意です... 何をすべきかを指示するのではなく、成功基準を与えて、あとは任せましょう。”
この原則は、命令的なタスクを宣言的な目標へと変換します。
| 次のように指示するのではなく... | 次のように変換します... |
|---|---|
| “バリデーションを追加して” | “無効な入力に対するテストを書き、それをパスさせて” |
| “バグを修正して” | “バグを再現するテストを書き、それをパスさせて” |
| “Xをリファクタリングして” | “リファクタリングの前後でテストがパスすることを確認して” |
複数のステップを伴うタスクの場合、モデルは簡潔な計画を提示すべきです。
1. [ステップ] → verify: [チェック内容]
2. [ステップ] → verify: [チェック内容]
3. [ステップ] → verify: [チェック内容]
Strong success criteria let the LLM loop
独立して。曖昧な基準（“動くようにして”）は、
絶え間ない説明を必要とします。
5. 実際のCLAUDE.mdファイル
リポジトリにある、完全で省略のない CLAUDE.md ファイルです。意図的に短く — 70行未満に抑えられています。この簡潔さは制限ではなく、一つの機能です：
LLMのコーディングにおける一般的なミスを
減らすための行動指針です。必要に応じてプロジェクト固有の
指示とマージしてください。
トレードオフ： これらのガイドラインは、速度よりも
慎重さを優先しています。些細なタスクについては、各自の判断で対応してください。
## 1. コーディングの前に考える
勝手な推測をせず、不明点を隠さないこと。トレードオフを明確にすること。
実装前に：
- 前提条件を明示する。不確かな場合は質問する。
- 複数の解釈が存在する場合は、それらを提示する。
- よりシンプルなアプローチがある場合は、その旨を伝える。
- 不明な点があれば中断し、何が混乱の原因かを特定する。
## 2. シンプルさ優先
問題を解決する最小限のコード。推測に基づいた実装は行わない。
- 要求された以上の機能は追加しない。
- 1回限りのコードに抽象化を導入しない。
- 要求されていない“柔軟性”を追求しない。
- 起こり得ないシナリオに対するエラーハンドリングを行わない。
- 200行のコードを50行に短縮できるなら、書き直す。
## 3. ピンポイントな変更
必要な箇所のみに手を加える。自分が出したゴミ（不要なコード）のみをクリーンアップする。
- 隣接するコードやフォーマットを“改善”しない。
- 壊れていないものをリファクタリングしない。
- 自分の手法と異なる場合でも、既存のスタイルに合わせる。
- デッドコードに気づいた場合は指摘に留め、削除はしない。
## 4. ゴール駆動の実行
成功基準を定義し、検証されるまで繰り返す。
タスクを検証可能なゴールに変換する：
- “バリデーションを追加” → “テストを書き、それをパスさせる”
- “バグを修正” → “テストで再現させ、その後修正する”
- “Xをリファクタリング” → “実行前後でテストがパスすることを確認する”
以上がファイルの内容すべてです。このファイルの強みはその簡潔さにあります—プロジェクト固有の指示を妨げることなくエージェントのコンテキストウィンドウに収まるほど短く、かつ重要な行動指針（ガードレール）を定義するのに十分な長さです。
6. 実践的な例
このリポジトリには以下が含まれています： EXAMPLES.md 詳細な Before/After 比較を含むファイルです。ファイル内の主要な “アンチパターン・サマリー” は以下の通りです：
| 原則 | アンチパターン | 修正方法 |
|---|---|---|
| コーディングの前に考える | ファイル形式、フィールド、スコープを暗黙的に想定している | 前提条件を明示し、不明点を質問する |
| シンプルさ優先 | 単一の割引計算に Strategy パターンを適用している | 実際に複雑さが必要になるまでは、1つの関数に留める |
| サージカルな変更 | Reformats quotes, adds type hints while fixing a bug | 報告された問題を修正する行のみを変更する |
| ゴール駆動 | “コードをレビューして改善します” | “バグ X のテストを作成 → パスさせる → デグレードがないことを確認する” |
7. インストール方法
このリポジトリでは、2つのインストール方法を提供しています：
オプション A: Claude Code プラグイン（推奨）
ガイドラインを Claude Code プラグインとしてインストールし、そのスキルを すべてのプロジェクトで利用可能にします:
/plugin marketplace add forrestchang/andrej-karpathy-skills
# 次に、プラグインをインストールします
/plugin install andrej-karpathy-skills@karpathy-skills
オプション B: CLAUDE.md (プロジェクト単位)
単一プロジェクトの場合:
curl -o CLAUDE.md https://raw.githubusercontent.com/
forrestchang/andrej-karpathy-skills/main/CLAUDE.md
echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/
andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
カスタマイズ
これらのガイドラインは、 プロジェクト固有の指示とマージされることを想定して設計されています。TypeScriptの設定、API規格、テスト規約など、プロジェクトに必要なセクションを自由に追加してください。4つの原則は動作のベースラインを提供し、プロジェクト固有のルールはその上に構築されます。
8. CLAUDE.md とは何ですか？
このコンセプトに馴染みがない方へ: CLAUDE.md は、 プロジェクト・メモリーカード AIコーディングエージェント向け。セッション開始時にClaude Codeによって自動的に読み込まれ、会話をまたいで持続的なコンテキストを提供します。
新しい開発者向けのオンボーディング・ドキュメントのAI版と考えてください — ただし、それを読み込むのはAIです 毎回欠かさず、 プロジェクトでの作業を開始するたびに。
CLAUDE.md のベストプラクティス (2026)
| セクション | 内容 |
|---|---|
| プロジェクトの概要 | プロジェクトの目的を2〜3文でまとめたもの |
| 技術スタック | 言語、フレームワーク、主要なライブラリ |
| アーキテクチャ | コードベースのマップ（source、components、config） |
| コマンド | dev、build、test、lint コマンド |
| コーディング標準 | 命名規則、パターン、スタイルルール |
| 安全ルール | “APIキーをハードコードしないこと”、“/config を編集しないこと” |
階層構造
CLAUDE.md(プロジェクトルート) — Gitにコミットされる共有コンテキストCLAUDE.local.md(プロジェクトルート) — 開発者個別のプライベートなメモ（.gitignoreに追加）~/.claude/CLAUDE.md— すべてのプロジェクトに適用されるグローバルな設定- サブディレクトリ
CLAUDE.mdファイル — そのディレクトリで作業している時のみ読み込まれるコンテキスト
経験則： チャットで同じ指示を2回以上繰り返す必要がある場合は、それを CLAUDE.mdに反映させましょう。
9. コミュニティの反応
以下のプラットフォームでの議論を調査しました： Reddit (r/ClaudeAI, r/ClaudeCode)、Twitter/X、および技術ブログ。コミュニティの意見は以下の通りです：
“自信満々なジュニア開発者” というコンセンサス
Redditコミュニティでは、Claude Codeは「優秀だが時として信頼性に欠ける」と評されることがよくあります。 “ジュニアデベロッパー” それは高速で知識も豊富ですが、監視がないと危険なショートカットをしたり、ハルシネーションを起こしたり、初歩的なミスを犯したりしがちです。Karpathyのskillsファイルは、ジュニアデベロッパーが必要とするガードレールを追加することで、この問題に直接対処します。
“スキル不足（Skill Issue）” 論争
Redditでよく見られる意見：AIが生成するコードの品質は、 ユーザー自身のエンジニアリング判断力と、 “コンテキストエンジニアリング”スキルに正比例します。プロンプト構造、コンテキスト管理、検証ループをマスターした高度なユーザーは、劇的に高い成功率を報告しています。Karpathyのskillsファイルは、最も人気のある“コンテキストエンジニアリング”ツールの1つです。
“AIサイコシス（AI Psychosis）” 論争
Karpathyによる“永続的なAIサイコシス（perpetual AI psychosis）” — 常に超生産的でありながら、エージェントへの指示に消耗し続ける状態 — という表現は、大きな共感を呼びました。AIエージェントを、無視できない競争上の優位性と捉える人もいれば、メンテナンス不可能なコードを量産しながらスピード感だけを味わう“生産性シアター（productivity theater）”と呼ぶ人もいます。skillsファイルはその中間に位置し、AIエージェントの強力さを認めつつも、それらには 規律ある制約が必要であると主張しています。
人間側のボトルネックの変化
コミュニティのコンセンサス：AIは、 コードを 書くことへのハードルを下げました。しかし、真のボトルネックは実装から アーキテクチャと評価へと移行しました。課題はもはや“どう書くか”ではなく、“エージェントが構築したものを、メンテナンスできるほど十分に理解しているか”ということです。
10. 大局的な視点
“バイブコーディング（Vibe Coding）”から“エージェンティック・エンジニアリング（Agentic Engineering）”へ
2025年初頭にKarpathyが“バイブコーディング”という言葉を造語したとき、それはAIに対する緩く会話的なプロンプト手法を指していました。2026年までに、コミュニティはこれを “エージェンティック・エンジニアリング”へと成熟させました。 — 開発者がAIを、明確な目標、定義された境界、そして厳格なテストを必要とするパートナーとして扱う規律です。
この andrej-karpathy-skills リポジトリはこの進化を象徴しています。それはAIができることを制限することではありません。それは、 AIの能力を方向付け、 より良い成果を生み出す原則を通して導くことです。
“Idea File” パターン
このリポジトリは、Karpathy氏が呼ぶところの “idea file” パターン — 実装ではなくアイデアを共有するという手法を体現しています。 CLAUDE.md ファイルは、誰かがインポートするライブラリではありません。それは誰でも適応できる一連の原則です。受け取り側のエージェントが、それぞれの特定のニーズに合わせてカスタマイズします。これは新しい形のオープンソースです。オープンなコードではなく、 オープンなアイデアです。
効果を確認する方法
リポジトリのREADMEによれば、以下のような状況であれば、これらのガイドラインが機能していると言えます：
- diff内の不要な変更が減少する — 要求された変更のみが表示される
- 複雑化による書き直しが減少する — 最初からシンプルなコードが生成される
- 実装前に、不明点を解消するための質問を行う — ミスが起きた後ではなく
- クリーンで最小限のPR — ついでに行うリファクタリングや“改善”は避ける
トレードオフに関する注記
このリポジトリは、そのトレードオフを率直に示しています： “これらのガイドラインは、スピードよりも慎重さを重視しています。” 些細なタスク（単純なタイポの修正や明らかな1行の変更など）については、自身の判断で行ってください — すべての変更に厳格なプロセスが必要なわけではありません。目的は、重要度の高い作業におけるコストのかかるミスを減らすことであり、単純なタスクを遅らせることではありません。
11. すべての情報源とリンク
この記事は、以下のリサーチに基づいて作成されました 複数の情報源によるリサーチ GitHub、Twitter/X、Reddit、ウェブ記事、そしてソースコード自体を対象としています。以下がすべての一次情報源です：
一次情報源
- GitHub: forrestchang/andrej-karpathy-skills — リポジトリ本体
- CLAUDE.md — 実際のガイドラインファイル
- EXAMPLES.md — 実例に基づいたBefore/Afterの例
- Karpathy's オリジナルのツイート — LLMコーディングの落とし穴を指摘したバイラルポスト
コミュニティディスカッション
- Reddit r/ClaudeAI — Claude Codeのワークフローと“confident junior dev”というコンセンサスに関するコミュニティの議論
- Reddit r/ClaudeCode — CLAUDE.mdのベストプラクティスとspecシステムに関するスレッド
- Twitter/X — 開発者の反応、ワークフローの共有、および導入レポート
ウェブソース
- Medium — テクニカルレビューと実装ガイド
- dev.to — 開発者コミュニティによるチュートリアル
- Forbes — “vibe coding”から“agentic engineering”への進化に関する報道
- VentureBeat — コンテキスト管理におけるKarpathyの“compiler”の比喩に関する分析
- Analytics Vidhya — skillsファイルの設計手法に関するテクニカル分析
ドキュメント
- Claude Code ドキュメント — 公式 CLAUDE.md リファレンス
- HumanLayer.dev — CLAUDE.md 設定のベストプラクティス
このサイトの関連記事
- Karpathy's LLM ナレッジベース：元のツイートの解説
- Karpathy's LLM Wiki：彼のアイデアファイルの完全ガイド
- AI IDE でスキルをセットアップする方法
- AI エージェントのためのシステムプロンプト完全ガイド
Get the Ultimate Antigravity Cheat Sheet
Join 5,000+ developers and get our exclusive PDF guide to mastering Gemini 3 shortcuts and agent workflows.