公式記事はRulesとSkillのどちらも「特定の状況でのみ読み込まれる」ように範囲を限定できると言っているが、実際にはこの2つをどう使い分ければよいか？
重要な違いはコンテンツの性質にあり、読み込みの仕組みそのものではない。パス制限のあるRulesは、「具体的で、1文で言い尽くせる制約」を置くのに適している。例えば「移行ファイルは追記のみで、既存の内容を変更してはならない」といった一文のルールであり、frontmatter内の paths フィールドを通じていつ読み込まれるかを制御する。一方Skillは、「ステップがあり、一連のプロセスへと展開する必要がある」手順的な指示に適しており、例えば完全なデプロイのチェックリストなどである。公式記事が示す具体的な判断基準は、CLAUDE.md（あるいはRulesで無理やり）に30行の手順説明を詰め込んでいることに気づいたら、それはSkillに移すべきサインだということである。Rulesが扱うべきなのは、コードベースの複数の（ただしすべてではない）箇所にまたがって適用される具体的な制約であり、完全な操作手順ではない。
Hook内のpromptタイプとagentタイプは、他の決定的なタイプと本質的にどう異なるのか、なぜ公式は特にこれらを取り上げて説明しているのか？
公式記事は、command、HTTP、mcp_toolの3つのタイプは決定的に実行されると明確に述べている——つまり、トリガー条件が満たされる限り、これらは毎回全く同じことを行い、挙動は完全に予測可能である。それに対してpromptとagentという2つのタイプは、固定されたルールセットではなくClaude自身の判断によって出力結果を決定する。これは、これら5つがすべて「Hook」と呼ばれてはいても、実際にHookという仕組みがもともと提供しようとしていた「決定性の保証」を真に備えているのは最初の3つだけであることを意味する。後者の2つは本質的には「ライフサイクルのある時点で、追加でClaudeを呼び出して判断させる」ことに近く、その信頼性のレベルは実際にはSkillや指示に近く、真の意味での決定的なガードレールではない。
この区別が重要なのは、もしあなたのニーズが「このことは例外なく毎回必ず起こらなければならない」（危険なコマンドをブロックするなど）というものであれば、選ぶべきはcommandやHTTPといった決定的なタイプのHookである。もしあなたのニーズが「ある時点で、Claudeにその場の状況について追加の判断を1回してほしい」というものであれば、promptやagentタイプのHookが適している。しかしこの使い方は本質的には、プロセスの中に判断ステップを直接挿入することとよく似ており、真の意味で「必ず起こることが保証された」ガードレールとして扱うべきではない。
Subagentは最大5階層までネストでき、記事で言及されている動的ワークフロー（dynamic workflows）は数十から数百のバックグラウンドエージェントを協調させることができるというが、このような規模の協働はどうやってコンテキストが埋め尽くされることを防いでいるのか？
鍵となるのは、公式記事が指摘している具体的な設計にある。オーケストレーション計画（orchestration plan）と中間結果は、Claudeのコンテキストウィンドウにではなく、スクリプト変数の中に存在するのである。これは、あるワークフローが数十、あるいは数百のバックグラウンドエージェントを協調させる必要がある場合、協調を担当するメインのClaudeインスタンスは、各Subagentの完全な実行詳細を自分自身のコンテキストに読み込む必要がないことを意味する。必要なのは、現在どのSubagentが動いていて、それぞれのステータスがどうなっているかといった要約レベルの情報だけであり、実際の実行の詳細はそれぞれ独立したSubagentのコンテキストの中にとどまり、互いに汚染し合うことがない。
これこそが、Subagentの分離性が大規模な協働において特に重要である理由でもある。この分離という層がなければ、数十のSubagentを協調させる過程で、各Subagentの中間産出物をすべてメインのコンテキストに読み込むだけで、コンテキストは埋め尽くされ、本来協調のための意思決定に使われるべきスペースが圧迫されてしまう。中間結果をモデルのコンテキストではなくスクリプト変数に留めておくことは、このような大規模な協働が「指示の忠実度を犠牲にすることなく」拡張性を維持できる鍵となる設計である。
もし自分の現在のプロジェクトにすでに長いCLAUDE.mdがあり、さまざまな性質の指示が混在している場合、どこから整理を始めればよいか？
より効率的な方法は、まず公式記事が提供する判断基準の表に照らして、CLAUDE.md内の各段落を分類することである。まず「これはClaudeがほぼ毎回知っておくべき事実なのか、それとも特定の状況でのみ必要なものなのか」を問う。もし後者であれば、さらに「これは1文で言い尽くせる具体的な制約なのか、それとも複数のステップに展開する必要がある手順なのか」を問う。前者（具体的な制約）はパス制限のあるRulesに移すのに適しており、後者（複数ステップの手順）はSkillに移すのに適している。最終的に本当にCLAUDE.mdに残すべきなのは、ビルドコマンド、ディレクトリ構造、チーム全体で守るべき中核的な慣例といった、「常に知っておくべき」事実的な情報だけであるはずである。
もう1つ確認する価値のあるサインは「絶対に違反してはならない」ルールである。もしCLAUDE.mdの中に、「守られなければ実際に深刻な結果を招く」レベルのルールがあれば、そのルールは指示のレベルにとどめておくべきではなく、Hook（例えばPreToolUse型のHookは、ツール呼び出しを検査し、終了コード2で直接ブロックできる）と組み合わせるべきである。これにより、その制約は「守られることを期待する助言」から「決定的に強制執行されるガードレール」へと格上げされる。公式記事はまた、チームで共有するCLAUDE.mdによくある問題として、「このファイルを本当の意味で所有している人が誰もいない」ことを挙げており、内容は積み重なる一方で誰も整理しない、という状況になりがちである。CLAUDE.mdに担当者を指定し、コードをレビューするのと同じようにその変更をレビューすることで、際限なく膨張していくのを防ぐことが推奨される。
Anthropic公式ブログが2026年6月に公開した記事は、Claude Codeの中でClaudeの挙動を調整する7つの方法を体系的に整理している。CLAUDE.mdファイル、Rules、Skill、Subagent、Hook、出力スタイル（output styles）、そしてコマンドラインでのシステムプロンプトの追加である。これら7つの方法は一見機能が重なり合っているように見えるが、実際にはそれぞれ3つの異なる判断軸に対応している。指示がいつコンテキストに読み込まれるか、会話の圧縮（compaction）後も保持されるか、そしてその指示がどれほど強い拘束力を持つか、である。
それぞれの方法は「コンテキストコスト」（context cost）と「拘束力」（authority）の間でトレードオフを行っている。CLAUDE.mdのルートファイルはセッション開始時に読み込まれ、会話全体を通じてコンテキストを占有し続ける。現在のタスクにある行が関係なくても、その行は読み込まれる——これはコンテキストコストが高いことを意味し、ビルドコマンド、ディレクトリ構造、プロジェクトの慣例といった、Claudeがほぼ毎回知っておくべき事実的な情報を置くのに適している。それに対して、サブディレクトリ配下のCLAUDE.mdファイルは必要に応じて読み込まれ、Claudeが実際にそのサブディレクトリ配下のファイルを読み込むときにのみ読み込まれ、会話の圧縮後も保持されない。コンテキストコストははるかに低く、「そのサブディレクトリにのみ関連する」慣例を置くのに適している。
Rules（ルール）は .claude/rules/ に保存され、パス制限のないものとパス制限のあるものの2種類に分かれる。パス制限のないルールはCLAUDE.mdとよく似た挙動をし、セッション開始時に読み込まれ、会話の圧縮後は再注入される。パス制限のあるルールは、frontmatter内の paths フィールドを通じて、Claudeが実際にそのパスに一致するファイルに触れたときにのみ読み込まれ、「特定のディレクトリやファイルタイプにのみ適用される」具体的な制約を置くのに使える。例えば「すべてのAPIハンドラはZodで入力を検証しなければならない」といったルールである。
Skillは .claude/skills/ に保存され、セッション開始時には名前と説明だけが事前に読み込まれ、完全な内容はそのSkillが実際に呼び出されたとき（スラッシュコマンド経由であれ、タスクへの自動マッチングであれ）に初めて読み込まれる。会話の圧縮時には、呼び出し済みのSkillが再注入されるが、すべての呼び出し済みSkillは共通の合計予算を共有し、予算を使い切ると最も古いものから破棄される。これは、デプロイのワークフローやリリースチェックリストのような、メインスレッドの中で段階的に展開され、各ステップを自分の目で確認しながら、いつでも介入して調整したいと思うような、手順的な指示を置くのに適している。
Subagentは .claude/agents/ に保存され、表面上はSkillとよく似ている——セッション開始時に名前、説明、ツールリストだけが事前に読み込まれる点は同じである——しかし決定的な違いは、Subagentの本文にあるはるかに大きな指示内容が、自動的に読み込まれることは一切なく、メイン会話のコンテキストに実際に入ることも決してないという点にある。ClaudeはAgentツールを通じてこれを呼び出し、プロンプト文字列を渡す。するとSubagentは自身の新しい独立したコンテキストウィンドウの中で動作し、最終的なメッセージ（多くの場合は集約された結果）とメタデータだけがメインセッションに返される。この分離という特性こそが、SkillではなくSubagentを選ぶべき決定的な判断基準である。もしある付随的なタスク（深い検索、ログ分析、依存関係の監査など）が生み出す中間結果を、その後二度と参照しないのであれば、Subagentを使ってこれらの詳細を完全にメイン会話に入れないようにする。逆に、プロセス全体をメインスレッドの中で展開させ、各ステップを自分の目で見て、いつでも介入したいのであれば、Skillを使うべきである。
Hookはユーザー定義のコマンド、HTTPエンドポイント、あるいはLLMプロンプトであり、Claudeのライフサイクル内の特定のイベント（ファイル編集、ツール呼び出し、セッション開始）によってトリガーされ、settings.json、管理されたポリシー設定、あるいはSkill／エージェントのfrontmatterに登録できる。Hookにはcommand、HTTP、mcp_tool、prompt、agentの5種類があり、最初の3つは決定的に実行されるのに対し、後者2つ（promptとagent）は固定されたルールセットではなくClaude自身の判断によって出力を決定する。Hookのコンテキストコストは低い。なぜなら、設定や指示の内容そのものがメインのコンテキストの外に存在するからである。ほとんどのHookの出力は、設定が明示的にそれを返すよう指定していない限り、メインのコンテキストウィンドウには保存されない（例えば、ブロック型Hookの標準エラー出力はコンテキスト内に保存され、Claudeがなぜその呼び出しが拒否されたのかを把握できるようになっている）。
公式記事はいくつかのよくある誤用パターンを直接指摘しており、自分の設定と照らし合わせてチェックする価値がある。もしCLAUDE.mdに「Xのたびに、必ずYを行う」といった、確実に起こるべき挙動（例えば編集のたびにフォーマッタを実行するなど）を書いているなら、指示ではなくHookを使うべきである。モデルが「フォーマッタを実行することを選択する」ことと、フォーマッタが「自動的に実行される」こととは、根本的に異なるレベルの信頼性だからである。もしCLAUDE.mdに「絶対にこれをしてはならない」と書いているなら、それも間違ったツールを使っているサインである。指示はほとんどの場合守られるが、プレッシャーの下、長いセッション、あいまいな状況、あるいはタスクの一部として読み込んだファイルにプロンプトインジェクションが隠されている場合など、モデルがプロンプトによるルールに従えないことがある。本当のガードレールは決定的でなければならず、それはHookと権限設定であり、管理設定（managed settings）はさらに進んで、管理者によってデプロイされ、ユーザーのローカル設定では上書きできず、組織レベルで決定的なガードレールを実現できる唯一の方法である。もしCLAUDE.mdに30行の手順説明を詰め込んでいるなら、その内容はSkillに移すべきである。CLAUDE.mdに置くべきなのはClaudeが常に知っておくべき事実であり、特定の状況でのみ展開する必要がある手順ではない。次に指示を追加する前に、まずこの判断基準の表で素早く確認する方が、指示が確実に守られていないことに後から気づいたり、コンテキストが無関係な内容で埋め尽くされてから調整し直したりするよりも、はるかに効率的であることが多い。