AIコーディング on KnightLiブログ

Karpathy の 65 行の CLAUDE.md：AI コーディングで三つの典型的なミスを減らす

Sun, 19 Apr 2026 18:27:23 +0800

最近、AI コーディングに関する GitHub プロジェクトが注目を集めている。中心にあるのは複雑なコードではなく、およそ 65 行の CLAUDE.md ファイルだ。このプロジェクトが多くの star を集めた理由は、技術実装の複雑さではない。AI にコードを書かせるとき、多くの人が繰り返し遭遇する問題をうまく捉えているからだ。

背景には、Andrej Karpathy による AI コーディングへの観察がある。Karpathy は AI 分野で大きな影響力を持つ教育者でありエンジニアだ。スタンフォード大学の博士で、OpenAI の初期にも関わり、Tesla では Autopilot の視覚システムを担当した。その後も大規模モデル、教育、AI ツールについて発信を続けているため、彼がプログラミング手法の変化について語ると、多くの開発者が注目する。

彼は、Claude Code を数週間使ったあと、自分のプログラミングスタイルが大きく変わったと述べている。以前はおよそ 80% を手書きし、20% を AI に補助させていた。今は 80% を AI に書かせ、自分は 20% を修正する感覚に近いという。自然言語で LLM に何を書くべきか伝えるので、「英語でプログラミングしている」ようなものだと表現している。

一方で、彼は AI コーディングにありがちな問題も指摘している。

01 誤った仮定

一つ目の問題は、モデルがユーザーの代わりに勝手な仮定を置き、その仮定に沿って書き進めてしまうことだ。モデルは必ずしも自分の混乱を管理しないし、要件が曖昧なときに立ち止まって質問するとも限らない。

たとえばユーザーが「ユーザーのエクスポート機能を追加して」とだけ言った場合、モデルは全ユーザーを出力する、JSON 形式にする、ローカルファイルに書き出す、権限や項目は確認不要だ、と勝手に決めるかもしれない。コードが完成してから、ユーザーはモデルの理解が実際のシナリオとずれていたことに気づく。

よりよい進め方は、不確かな点を先に列挙することだ。全ユーザーを出力するのか、フィルタ後の結果なのか。ブラウザでダウンロードするのか、バックグラウンドジョブなのか。必要な項目は何か。データ量はどれくらいか。権限制御はあるのか。こうした点を確認しないまま速く書いても、ずれが大きくなるだけだ。

02 過度な複雑化

二つ目の問題は、モデルが簡単な問題を複雑にしがちなことだ。一つの関数で済む問題に対して、抽象クラス、ストラテジーパターン、ファクトリーパターン、設定レイヤー、将来使うかもしれない拡張ポイントを山ほど追加することがある。

こうしたコードは一見エンジニアリングされているように見えるが、実際には保守コストを増やす。AI は大量の構造を素早く生成するのが得意だが、その構造が本当に必要かを常に判断できるわけではない。その結果、100 行で済むタスクが 1,000 行に膨らむ。

判断基準はシンプルだ。経験あるエンジニアがその変更を見て、過剰設計だと感じるかどうか。答えが yes なら、余分な層を削り、今の問題を解くために必要な最小限のコードに戻すべきだ。

03 付随的な被害

三つ目の問題は、モデルが十分に理解していないコードを変更したり削除したりすることだ。小さな bug を直している途中で、ついでにコメントを変えたり、フォーマットを整えたり、未使用に見える import を消したり、現在のタスクと無関係なロジックにまで手を入れることがある。

こうした「ついでの改善」は危険だ。変更範囲を広げ、レビューを難しくするからだ。ユーザーは空の email でバリデータが落ちる問題だけを直したいのに、モデルが email 検証を強化し、ユーザー名検証を追加し、ドキュメント文字列まで書き換えると、どの行が挙動を変えたのか分かりにくくなる。

より安全な原則は、必要なコードだけを変更し、自分の変更によって生まれた問題だけを片付けることだ。もともと存在していた dead code、フォーマットの問題、歴史的な負債は、明示的に依頼されていない限り触らない。必要なら一言指摘するだけでよい。

04 不満を CLAUDE.md に変える

Karpathy の見解が広く共有されたあと、開発者の Forrest Cheung は賢いことをした。これらの不満を、実行可能な行動指針として整理し、CLAUDE.md ファイルに書き込んだのだ。

このプロジェクトには複雑なコードはない。重要なのは、AI コーディングで問題が起きやすい部分を、明確な作業ルールに変えたことだ。大きく四つの原則にまとめられる。

一つ目は、書く前に考えること。黙って仮定しない。混乱を隠さない。要件に複数の解釈があるなら列挙する。より簡単な案があるなら伝える。確認が必要なら質問し、反論すべきときは反論する。

二つ目は、シンプルさを優先すること。求められていない機能を追加しない。一度しか使わないコードを抽象化しない。余計な設定を増やさない。ほぼ起きないケースのために大量の防御コードを書かない。50 行で済むなら 200 行にしない。

三つ目は、正確に変更すること。すべての変更行は、ユーザーの依頼に直接結びついているべきだ。近くのコードをついでに改善しない。壊れていないものをリファクタリングしない。できるだけ既存プロジェクトのスタイルに合わせる。

四つ目は、目標駆動で進めること。モデルに曖昧な指示だけを渡すのではなく、検証可能な成功基準を与える。たとえば「bug を直す」は「bug を再現するテストを書き、それを通す」にできる。「バリデーションを追加する」は「不正入力のテストを書き、それを通す」にできる。成功基準が明確なほど、モデルは完了に向けて自分でループしやすくなる。

05 なぜ広まったのか

このプロジェクトが広まったのは、内容が難解だからではない。実際の開発に近いからだ。

AI にコードを書かせたことがある人の多くは、似た場面を経験している。モデルが自信満々に要件を誤解する。コードがどんどん複雑になる。触るべきでない場所を変更する。CLAUDE.md の価値は、こうした経験をプロジェクトに置ける協作ルールに変えたことにある。

導入の敷居も低い。複雑な連携は不要で、一つのファイルから始められる。Karpathy 本人の影響力に加え、プロジェクト内に実践的な比較例があるため、Claude Code ユーザーや AI コーディングコミュニティの間で自然に広まった。

さらに重要なのは、この種のルールが Claude Code だけに限られないことだ。どの AI コーディングツールを使っても、本質的な問題は似ている。モデルは、いつ質問すべきか、いつ単純化すべきか、いつ手を止めるべきか、どうやってタスク完了を判断するかを知る必要がある。

06 普通の開発者への示唆

普通の開発者にとっての示唆はシンプルだ。AI コーディングは、一文の要件をモデルに投げて奇跡を待つものではない。本当に有効なのは、モデルに境界を与えることだ。

要件が不明確なときは、まず仮定を表に出させる。実装が複雑になり始めたら、最小の実用解に戻らせる。コードを変更するときは、タスクの目的だけに集中させる。完了時には、テスト、コマンド、明確なチェックポイントで結果を検証する。

AI がコードを書く能力はすでに高い。それでも、よい協作上の制約は必要だ。短い CLAUDE.md がこれほど注目されたことは、開発者が求めているのはより賢いモデルだけではなく、より信頼できる作業方法でもあることを示している。

簡単にまとめると：

書く前に考え、誤った仮定を減らす。
シンプルさを優先し、過度な設計を避ける。
正確に変更し、変更範囲を制御する。
検証可能な成功基準で、目標に向かって進める。

この四つは複雑ではないが、実用的だ。AI コーディングが本当に効率を上げる前提は、モデルにより多く書かせることではない。より正確に、より少なく、より制御された形で書かせることだ。

Claude Codeの使用枠を節約する：モデル選択、コンテキスト、キャッシュ、/compact

Sun, 19 Apr 2026 15:29:06 +0800

最近、Claude Code や Claude Max を使っていて同じ問題に当たる人が増えています。Pro、Max 5x、Max 20x を契約しているのに、少し使っただけで使用量の警告が出る、あるいは次のリセットを待つ必要がある、というものです。特に大きなプロジェクトで Claude Code に大量のファイルを読ませたり、複雑な bug を修正させたり、長いタスクを走らせたりすると、この感覚はかなり強くなります。

先に結論を書くと、使用枠は「時間」で線形に減るわけではありません。モデル、コンテキスト長、添付ファイル、コードベースの大きさ、会話履歴、ツール呼び出し、現在の容量によって変わります。同じ5時間ウィンドウでも、長く使える人もいれば、十数分で上限に近づく人もいます。多くの場合、アカウントがおかしいのではなく、1回ごとのリクエストが重すぎます。

この記事では、使用枠を節約するための実用的な習慣を整理します。

01 まず Claude の使用ウィンドウを理解する

Claude Pro と Max には使用制限があります。Claude Code の使用量は、Claude のWeb、デスクトップ、モバイルアプリと同じサブスクリプション枠を共有します。公式ヘルプでは、送信できるメッセージ数はメッセージの長さ、添付ファイルの大きさ、現在の会話の長さ、使うモデルや機能に左右されると説明されています。Claude Code ではさらに、プロジェクトの複雑さ、コードベースの大きさ、自動承認設定なども影響します。

大まかにはこう考えるとよいです。

Pro：軽い利用と小さなプロジェクト向け。
Max 5x：より頻繁な利用と大きめのコードベース向け。
Max 20x：重めの日常利用や高頻度の共同作業向け。
使用ウィンドウは5時間セッション単位でリセットされる。
長いメッセージ、長い会話、大きなファイル、複雑なタスクは使用量を早く消費する。
Opus のような強いモデルは Sonnet より早く制限に近づきやすい。

そのため、「20分しか使っていない」という説明だけでは状況は分かりません。重要なのは、その20分で Claude がどれだけのコンテキストを読んだか、どのモデルを使ったか、大きなファイルを何度も処理したか、同じ長い会話にタスクを追加し続けたかです。

02 まずやること：最も高いモデルをデフォルトにしない

Claude 系列は、おおよそ次のように使い分けられます。

Opus：最も強力。複雑な推論、設計判断、難しい bug に向く。
Sonnet：能力とコストのバランスがよく、日常的なコーディング作業に向く。
Haiku：軽量。簡単な分類、要約、形式変換などに向く。

日常的なスクリプト作成、小さな bug 修正、ドキュメント整理、コード説明なら、多くの場合 Sonnet で十分です。Opus は次のような場面に残しておくほうがよいです。

複雑なアーキテクチャ設計。
複数ファイルにまたがる深いリファクタリング。
再現しにくい bug。
長い推論が必要なトラブルシュート。
通常モデルが明らかに詰まったタスク。

Claude Code では /model でモデルを切り替えられますし、/config でデフォルトも設定できます。安定した使い方は、普段は Sonnet、重要な局面だけ Opus に切り替えることです。最初から最後まで Opus で押し切る必要はありません。

03 次にやること：コンテキストを制御し、古いタスクを引きずらない

コンテキストが長くなるほど、Claude が毎回処理する内容が増え、使用量も増えます。Claude Code の公式ドキュメントでも、コンテキストを能動的に管理することが推奨されています。

無関係なタスクに切り替えるときは /clear で履歴を消す。
現在のタスクが一段落したが重要な文脈は残したいときは /compact で圧縮する。
何がコンテキストを使っているか知りたいときは /context を使う。
状態を常に見たい場合は status line を設定する。

使いやすいリズムは次の通りです。

小さな段階が終わった：/compact
大きなタスクが終わった：/clear
無関係な作業に切り替える：/clear
コンテキスト使用量が高くなってきた：早めに /compact

/compact は前の会話を要約し、重要なタスク状態、結論、ファイルパス、TODO を残しつつ、後続リクエストに持ち込む履歴を減らします。後ろに重点を書いてもよいです。

`1`	`/compact 変更済みファイル、テスト結果、残りTODO、重要な設計判断を残す`

自動圧縮を待つ必要はありません。公式ドキュメントでは、Claude Code はコンテキストが上限に近づくと自動圧縮すると説明されていますが、段階の区切りで手動圧縮するほうが制御しやすいです。

04 三つ目：長い会話と大きなファイルは毎回のリクエストを重くする

「もう一言聞いただけだから安いはず」と思いがちです。しかし長い会話では、その一言の背後に大量の履歴、ファイル要約、ツール定義、システムルールが付いてくることがあります。

特にコンテキストを増やしやすいものは次の通りです。

ずっと消していない長い会話。
Claude に大きなファイル全体を読ませること。
長いログ、ビルド出力、テスト出力を貼ること。
スクリーンショットや画像を一度に大量に入れること。
リポジトリ全体を何度もスキャンさせること。
長すぎる CLAUDE.md。
多すぎる MCP server。

節約するなら、ログは重要なエラーだけ、テスト出力は失敗部分だけにします。大きなファイルは、まず rg、head、tail、シンボル検索で位置を絞り、必要な部分だけ読ませます。コマンドラインで絞れる内容を、丸ごとコンテキストに入れないほうがよいです。

05 四つ目：キャッシュを理解する。ただし過信しない

Anthropic の Prompt Caching は、繰り返される prompt の前方部分をキャッシュします。デフォルトのキャッシュ寿命は5分で、1時間キャッシュもサポートされています。キャッシュがヒットすると、繰り返し使う大きなコンテキストを毎回完全に再処理せずに済むため、コスト削減や使用枠の効率改善につながります。

ただしキャッシュには制限があります。

テキストや画像を含め、内容が完全一致する必要がある。
デフォルトのキャッシュは短命。
モデル、ツール、システムプロンプト、コンテキスト構造を変えるとヒット率が下がることがある。
出力 token はキャッシュで消えるわけではなく、回答生成分は必要。
Claude Code が具体的にどうキャッシュを使うかは製品実装の詳細なので、永続的な「無料メモリ」と考えないほうがよい。

実際の利用で大事なのは、キャッシュの細部を研究することではなく、セッションを安定させることです。

同じ段階ではモデルを頻繁に切り替えない。
作業中に大量のルールを何度も書き換えない。
同じタスクの途中で新しい画像を次々追加しない。
長いタスクを長時間放置したあと、いきなり大きなリクエストを投げない。
段階が終わったら /compact する。

こうすると、繰り返しのコンテキストを再利用しやすくなり、後続リクエストも軽くなります。

06 ピーク時間について：避けられるなら避ける。ただし固定公式にしない

ネット上では、特定の時間帯は使用枠が厳しいという話をよく見かけます。公式ヘルプの表現はもっと慎重で、送信可能数は Claude の現在の容量、会話の長さ、添付ファイル、モデル、機能に影響されるとされています。つまり、ピーク時の容量は体験に影響する可能性がありますが、特定地域の特定時間を永続的な固定ルールとして扱うべきではありません。

実用的には次のように考えます。

大きなリファクタリングや重い分析は、自分のネットワークとサービスが安定している時間に行う。
すぐ離席する直前に超長タスクを始めない。
長時間離れる予定があるなら、先に /compact または /clear する。
小さな修正なら、長いコンテキストのまま Opus で強引に走らせない。

固定の「何時から何時は使わない」というルールを覚えるより、このほうが安定します。

07 CLAUDE.md、rules、MCP、skills を軽くする

Claude Code はセッション内でプロジェクトルール、ツール情報、一部の環境コンテキストを読み込みます。公式ドキュメントでも、汎用ルールと専用ルールを分け、毎回大量の無関係な内容を読み込まないようにすることが推奨されています。

おすすめの分け方は次の通りです。

CLAUDE.md：全体に常に適用される最小限のルールだけ。
rules：特定パスや特定ファイルタイプに必要なルール。
skills：投稿、デプロイ、画像生成、コードコミットなどの特定ワークフロー。
MCP：現在のタスクで本当に使う server だけ有効にする。

CLAUDE.md が何百行、何千行もあると、毎回その分を持ち込みます。たまにしか使わない手順は skill に移し、必要なときだけ呼び出すほうが軽くなります。

MCP も同じです。ツールが多いほど効率が上がるとは限りません。Claude Code のドキュメントでは、/mcp で不要な server を確認して無効化し、/context で何がコンテキストを使っているか確認できると説明されています。

08 実用コマンド一覧

日常的によく使うのは次のコマンドです。

/model

モデルを切り替える。通常は Sonnet、複雑な推論では Opus。

/clear

現在のコンテキストをクリアする。無関係なタスクに切り替えるときに使う。

`1`	`/compact`

会話履歴を圧縮する。段階が終わったが同じタスクを続けるときに使う。

`1`	`/context`

コンテキスト使用量を確認し、何が場所を取っているか調べる。

/status

現在のサブスクリプションや使用量関連の状態を見る。公式ヘルプでも残り割り当ての確認に推奨されています。

/mcp

MCP server を確認、管理し、現在使わないツールを無効化する。

API 課金で使っている場合は /cost も参考になります。ただし Pro/Max サブスクリプションでは、公式ドキュメントが /cost のドル見積もりは請求の基準ではないと説明しています。サブスクリプション利用者は /stats や /status の利用情報を見るほうが適しています。

09 使用枠を節約する作業フロー

使いやすい流れは次のようになります。

新しいタスクの前に /clear する。
デフォルトは Sonnet にする。
Claude にはまずプロジェクト構造と重要ファイルだけを読ませ、リポジトリ全体を一気に読ませない。
小さな段階が終わるたびに /compact する。
難しい詰まりどころだけ Opus に切り替える。
ログ、エラー、テスト出力は絞ってから渡す。
タスク完了後は /clear し、古いコンテキストを引きずって新しい作業を始めない。
定期的に CLAUDE.md、MCP、skills を見直し、常駐コンテキストを小さくする。

この流れの核心は、Claude に毎回「今本当に必要なもの」だけを見せることです。

10 まとめ

Claude Code の使用枠がすぐ尽きる原因は、たいてい1つではありません。高コストなモデル、消していない長い会話、多すぎるファイルやログ、重い MCP とルール、キャッシュ命中率の低下、ピーク時の容量変動が重なって起こります。

節約の要点はシンプルです。

日常作業は Sonnet を優先する。
Opus は本当に複雑な問題に残す。
段階が終わったら /compact。
タスクを切り替えるときは /clear。
/context でコンテキスト肥大化の原因を探す。
CLAUDE.md、rules、MCP、skills を軽くする。
リポジトリ全体、ログ全体、大量の画像をそのまま入れない。

同じ Pro や Max でも、どれだけ作業できるかはコンテキスト管理に大きく左右されます。コンテキストを小さくし、タスクの境界をはっきりさせると、Claude Code はかなり安定して使いやすくなります。

参考リンク

Claude Help Center：Using Claude Code with your Pro or Max plan：https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Claude Help Center：About Claude’s Max Plan Usage：https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs：Manage costs effectively：https://code.claude.com/docs/en/costs
Anthropic Docs：Prompt caching：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching