Andrej Karpathy Skills徹底ガイド：CLAUDE.mdでClaude Codeをどう制約するか、4つのルールでAIのコードの勝手な変更を解決

症状：Claude Codeが頼んでいないファイルまで変更するなら、CLAUDE.mdに作業範囲・事前計画・最小差分・検証のルールを明記してください。
最短の対策：ただし、CLAUDE.mdはプロジェクト指示であり、権限の遮断や実行の絶対保証ではありません。必要なら権限設定やコードレビューも併用します。

この手順は、Claude Codeの変更範囲が広すぎて困っている開発者向けです。
チームのプロジェクト指示を整えたい技術責任者や、Andrej Karpathy Skillsを参考に作業ルールを作りたいエンジニアにも役立ちます。

CLAUDE.mdでClaude Codeをどこまで制約できるか

CLAUDE.mdは、プロジェクト内でClaude Codeに守ってほしい指示や作業上の前提を伝えるためのファイルです。Claude Codeが作業時にプロジェクトの指示を参照する仕組みや、指示の書き方は、公式のメモリとCLAUDE.mdの説明で確認できます。

ここでできるのは「変更は指定した範囲にとどめる」「変更前に計画を示す」といった働き方の指定です。記述したルールが毎回必ず守られるという保証でも、指定外のファイルを技術的に編集不能にする権限設定でもありません。後者が必要なら、Claude Codeの権限設定に関する公式説明も確認してください。

この記事で紹介する4つのルールは、公式機能の保証ではなく、プロジェクト向けの実務提案です。公式のベストプラクティスも参照しながら、既存の開発手順に合わせて調整してください。

Andrej Karpathy Skillsをプロジェクト指示に取り入れる

タイトルにあるAndrej Karpathy Skillsは、関連する発信と、それをもとに公開されたSkillsのリポジトリを指しています。元の投稿はKarpathy本人の発信、リポジトリは公開されているSkillsの内容で確認できます。

ただし、この記事の4ルールをKarpathy本人の原文やClaude Codeの公式規範として扱うことはできません。リポジトリに書かれた内容をそのままプロジェクトに適用するのではなく、自分のコードベースの構成、許容できる変更、検証方法に合わせて指示を作ります。Claude CodeのSkillsも別の仕組みです。必要に応じて公式Skillsドキュメントを確認し、CLAUDE.mdと同じ設定だと混同しないようにしましょう。

4つのルールで変更を小さく管理する

第一のルール：対象ファイルと禁止事項を先に書く

作業の目的だけでは、どこまで変更してよいかは決まりません。対象とするディレクトリやファイル、触れてよい内容、依頼に含まれない変更を明記します。

たとえば、次のようなルールをプロジェクトの実情に合わせて書けます。

## 変更範囲
- 依頼に記載された機能に必要なファイルだけを変更する。
- 無関係なリファクタリングや設定変更を行わない。
- 追加のファイル変更が必要になった場合は、理由を説明して確認を求める。

特定のファイルだけで作業を完結できるとは限りません。既存コードの依存関係から別ファイルの変更が必要になった場合は、許可された範囲に黙って追加するのではなく、どの変更が必要かを示して確認を求めるようにします。

注意：対象ファイルを列挙するだけでは、そのファイル内の無関係な変更まで防げません。「何のために変更してよいか」も併記してください。

第二のルール：編集前に計画を共有する

コードに手を入れる前に、依頼の理解、変更予定の場所、検証方法を簡潔に提示するよう指示します。作業範囲が曖昧な場合や、計画に依頼外のファイルが含まれる場合は、確認を取るまで編集を始めないルールにします。

小さな修正なら、進め方は次の流れです。

• 依頼内容と変更対象を説明する。
• 予定する修正と確認方法を示す。
• 追加の変更が必要なら、理由を示して確認を求める。
• 合意した計画の範囲で編集する。

計画が提示されても、理解や実装が正しいとは限りません。差分と検証結果は別に確認してください。操作を承認・制限する方法は、公式の権限設定と照らして選びます。

第三のルール：要件を満たす最小の差分にする

「依頼を満たすために必要な変更だけを行い、既存の設計、命名、依存関係を理由なく置き換えない」と明記します。これにより、AIによるコードの勝手な変更につながりやすい無関係なリファクタリングや、個人の好みによる構成変更を抑えやすくなります。

作業後は、変更前後の差分とファイル一覧を見て、各変更が依頼のどの要件を満たすのか確かめます。要件に結び付かない変更があれば、理由を確認し、必要のないものは戻します。一方で、要件を満たすために必要な修正まで「最小」を理由に省いてはいけません。

第四のルール：検証内容と未実施項目を報告する

CLAUDE.mdには、プロジェクトですでに使っているテスト、ビルド、静的解析などから今回の変更に合うものを実行し、結果を報告するよう書きます。コマンド名を先に決めつけず、まず既存の設定や開発ドキュメントから実際の方法を確かめてください。

報告では、実行した確認と結果、実行できなかった確認とその理由を分けます。テストを実行していないのに「問題なし」と報告させないことが重要です。タスクに適した検証が既存手順で判断できない場合は、実施前に確認を求めるルールも加えます。

補足：変更の自動チェックをワークフローに組み込みたい場合、Claude Codeの公式Hooksドキュメントも参照できます。HooksはCLAUDE.mdの文章とは役割が異なるため、実行条件や運用への影響を確認して使ってください。

よくある判断をFAQで確認する

Claude Codeに指定したファイルだけを編集させるには

対象ファイルと禁止事項を指示に書き、範囲外の変更が必要なときは理由を説明して確認を求めるよう定めます。これは作業指示であり、指定外のファイルへのアクセスを技術的に遮断するものではありません。厳密な制限には権限設定を併用します。

CLAUDE.mdにどんなルールを書くと、変更範囲を抑えられるか

変更対象の明示、編集前の計画、最小差分、検証と正確な報告を基本にします。加えて、無関係なリファクタリングや依存関係の変更を避け、範囲が不明な場合は質問するよう記します。ルールはプロジェクトの実際の構成に合わせてください。

CLAUDE.mdで確認前の変更を完全に防げるか

完全には防げません。CLAUDE.mdはプロジェクト指示であり、アクセス権や操作の許可を強制するセキュリティ境界ではありません。実行を制限したい操作は権限設定で扱い、差分レビューやバージョン管理も残してください。

コード変更後の検証をどう指示するか

プロジェクトで使っている検証方法をもとに、今回の変更に合う確認を行わせます。実行した項目と結果を報告し、未実施の項目は理由を説明させます。根拠のないテストコマンドや、実行していない検証の成功を指示に書かないようにします。

小さなタスクでルールの効き方を確かめる

CLAUDE.mdを書いたら、まず変更対象と目的を限定できる小さなタスクで確認します。作業前に示された計画、変更されたファイル、差分、実行された検証と報告を照らし合わせ、依頼と違う動きがあれば指示を修正します。

確認時は、次の項目を順番に見ます。

• 変更ファイルが依頼の範囲内に収まっているか。
• 差分に無関係な整形、リファクタリング、設定変更がないか。
• 計画から外れた変更がある場合、事前に説明と確認があったか。
• 検証結果が実際の実行内容を正しく表しているか。
• 指示同士が矛盾したり、対象範囲が曖昧になったりしていないか。

ルールが守られなかった場合は、該当する文を具体化し、再び小さなタスクで確かめます。チェック項目を増やすだけでなく、曖昧な指示や相互に矛盾する指示をなくすことが大切です。

開発環境も分けたい場合に検討すること

CLAUDE.mdを整えても、普段使いの環境と検証環境が共用されていると、依存関係や設定の違いが確認を難しくする場合があります。環境を分ける方法を選ぶときは、既存の端末、仮想環境、専用のMac環境を、継続期間や必要な物理インターフェースに照らして比較してください。日本で使えるMacの選択肢を確認する場合は、Kvmkitの日本向けサービス案内も参照できます。

一時的にMac上の作業環境を用意したいなら、Kvmkitの日本向けMac miniレンタル情報を選択肢として確認できます。購入や手元のMacでの運用が適する場合もありますが、専用機材の調達や管理は負担になります。一方、長期間の安定した高負荷処理や物理接続が必要なら、レンタルが最適とは限りません。まずは手元のCLAUDE.mdを確認し、変更範囲の明確なタスクで4つのルールを検証してから、必要な開発環境を選んでください。

よくある質問