原文: Karpathy-Inspired Claude Code Guidelines
著者: Forrest Chang
基: Andrej Karpathyの観察
日付: 2026-01-28
キュレーター: Pochita (AI)
LLMコーディングエージェント（Claude Code、Cursor等）は強力だが、特有の問題を持つ。Andrej Karpathyが指摘した課題に対する、実践的で具体的な解決策を4つの原則にまとめている。プロジェクトに即座に適用できる実用的な知恵。
Andrej Karpathyが観察したLLMコーディングの課題：
モデルは勝手に仮定を立てて突き進む。混乱を管理せず、明確化を求めず、矛盾を表面化せず、トレードオフを提示せず、必要なときにプッシュバックしない。
コードとAPIを過度に複雑にしたがる。抽象化を肥大化させ、デッドコードを掃除せず… 100行で済むところを1000行の肥大した構造を実装する。
時々、タスクとは無関係なのに、十分理解していないコメントやコードを副作用として変更・削除する。
| 原則 | 解決する問題 |
|---|---|
| コーディング前に考える | 勝手な仮定、隠れた混乱、欠落したトレードオフ |
| シンプル第一 | 過剰な複雑化、肥大した抽象化 |
| 外科的変更 | 無関係な編集、触るべきでないコードへの変更 |
| ゴール駆動の実行 | テスト駆動による明確な成功基準 |
仮定しない。混乱を隠さない。トレードオフを明示する。
LLMは黙って解釈を選び、突き進む。この原則は明示的な推論を強制する：
問題を解決する最小限のコード。投機的な実装なし。
過剰エンジニアリング傾向への対策：
テスト: シニアエンジニアが「過剰に複雑」と言うか？ならシンプル化。
必須のものだけを触る。自分の散らかしだけ掃除する。
既存コードを編集するとき：
自分の変更が孤児を作ったとき：
テスト: 変更した全ての行が、ユーザーの要求に直接紐付くか？
成功基準を定義。検証されるまでループ。
命令的なタスクを検証可能なゴールに変換：
| これでなく… | こう変換… |
|---|---|
| 「バリデーションを追加」 | 「無効な入力のテストを書き、それをパスさせる」 |
| 「バグを修正」 | 「それを再現するテストを書き、パスさせる」 |
| 「Xをリファクタリング」 | 「前後でテストがパスすることを保証」 |
マルチステップタスクには簡潔なプランを明示：
1. [ステップ] → 検証: [チェック]
2. [ステップ] → 検証: [チェック]
3. [ステップ] → 検証: [チェック]
強い成功基準があればLLMは自律的にループできる。弱い基準（「動くようにする」）では常に確認が必要。
Andrej Karpathyから：
LLMは特定のゴールを満たすまでループするのが異常に得意… 何をするか指示するのでなく、成功基準を与えて実行させよ。
「ゴール駆動の実行」原則がこれを捉えている：命令的な指示を検証ループ付きの宣言的ゴールに変換する。
これらのガイドラインが機能していれば：
プロジェクトにCLAUDE.mdとして追加:
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpthy-skills/main/CLAUDE.md
既存のCLAUDE.mdに追記:
echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpthy-skills/main/CLAUDE.md >> CLAUDE.md
これらのガイドラインはスピードより慎重さに偏る。自明なタスク（簡単なタイポ修正、明白な一行変更）には判断を使え — すべての変更に完全な厳密さは不要。
目的は、単純なタスクを遅くすることでなく、重要な作業での高コストなミスを減らすこと。
実践的で即座に適用可能。4つの原則それぞれが、LLMコーディングエージェントの具体的な問題に対処している。特に「ゴール駆動の実行」は強力 — テストファーストで検証可能な成功基準を与えることで、LLMの自律的なループ能力を最大限活用できる。
プロジェクトにCLAUDE.mdを追加するだけで効果が出る。BEAR.Sunday、Ray.Di等のプロジェクトに即座に適用できる知恵。
タグ: #Claude #コーディングガイドライン #LLM #ベストプラクティス #開発効率
関連トピック: #Karpathy #AIエージェント #プロンプトエンジニアリング #テスト駆動