Claude Code を操る：CLAUDE.md ファイル、スキル、フック、ルール、サブエージェントなど

2026年6月22日

(元記事）　Steering Claude Code: CLAUDE.md files, skills, hooks, rules, subagents and more
https://claude.com/ja/blog/steering-claude-code-skills-hooks-rules-subagents-and-more

（翻訳）

Claude はあなたの働き方に合わせて動くように作られており、Claude Code ではそれをカスタマイズできます。

Claude の挙動を指示する方法は7つあります。CLAUDE.md ファイル、ルール、スキル、サブエージェント、フック、出力スタイル、そしてシステムプロンプトへの追記です。

それぞれの方法は次の3点を制御します：指示がいつコンテキストに読み込まれるか、長いセッションを通じて維持されるか（コンパクション時の挙動）、そしてどれだけの権限（影響力）を持つか。

下の表は各方法の主な違いを簡単にまとめたもので、記事本文では各方法をどこで使うべきかを判断するための詳細と意思決定の枠組みを示しています。

1. 各方法の比較表
2. 指示を伝える7つの方法
3. Claude Code カスタマイズの簡単なヒント
4. はじめに

各方法の比較表

方法	読み込まれるタイミング	コンパクション時の挙動	コンテキストコスト	使うべき場面
CLAUDE.md（ルート）	セッション開始時。セッション中ずっと維持される	メモ化される。一度読まれてセッション中キャッシュされ、コンパクション後に再読み込み	高。関連の有無に関わらず全行がトークンを消費	ビルドコマンド、ディレクトリ構成、モノレポ構造、コーディング規約、チームの慣習
CLAUDE.md（サブディレクトリ）	オンデマンド。そのサブディレクトリ配下のファイルを読むとき	当該サブディレクトリに再度触れるまで失われる	低。関連サブディレクトリで作業中のみ消費	特定サブディレクトリ固有の規約
ルール	セッション開始時（ユーザーレベル）または該当ファイルに触れたときのみ（パススコープ付き）	コンパクション時に再注入される	中。パススコープ付きでない限り常時オン	特定の制約や規約（例：すべてのAPIハンドラはZodで入力検証する）
スキル	名前と説明はセッション開始時、本体は呼び出し時に読み込まれる	呼び出されたスキルは共有予算の範囲内で再注入され、古いものから削除	低。本体は呼び出し時のみ読み込み、複数スキル間の共有トークン予算の対象	手続き的なワークフロー（デプロイやリリースのチェックリスト）
サブエージェント	名前・説明・ツール一覧はセッション開始時、本体はAgentツール経由で呼ばれたときのみ	最終メッセージ（要約＋メタデータ）のみがメインセッションに返る	低。呼ばれるまでメインコンテキストでのコストはゼロ。独立したコンテキストウィンドウで実行	分離して実行し要約だけ返すべき並列作業やサイドタスク（詳細検索、ログ解析、依存関係監査）
フック	ライフサイクルイベント発火時	コンパクションを完全にバイパス	低。設定はメインコンテキスト外に存在。一部出力は返る場合あり（例：ブロックエラー）	確定的な自動化：リンター実行、完了時にSlack投稿、コマンドのブロック、PreCompact時のチャット履歴バックアップ
出力スタイル	セッション開始時。システムプロンプトに注入	コンパクションされない	高。コンテキストウィンドウを占有するが、デフォルトのシステムプロンプトを上書き	大きな役割変更（コードアシスタント→汎用アシスタント）
システムプロンプトへの追記	セッション開始時。CLIフラグとして渡される	コンパクションされず、その呼び出しのみに適用	中程度。セッション内の最初のリクエスト後はキャッシュされる	トーン、応答の長さ、書式の好み

指示を伝える7つの方法

CLAUDE.md ファイル

CLAUDE.md はプロジェクトのルートにある Markdown ファイルです。セッション開始時にコンテキストに読み込まれ、セッション中ずっと残ります。

ビルドコマンド、ディレクトリ構成、モノレポ構造、コーディング規約、チームの慣習などがここに自然に収まります。

2種類あり、読み込まれ方が異なります：

常時読み込み: 1つ目はルートの CLAUDE.md ファイルで、共有リポジトリ内、もしくはプロジェクト固有の個人的な好みとしてローカル保存されます。これらはすべてセッション開始時に読み込まれ、長いセッションでも失われたり劣化したりしません。Claude Code が会話をコンパクション（圧縮）する際、これらのファイルを再読み込みします。

オンデマンド: セッションを初期化したフォルダより下のサブディレクトリにある CLAUDE.md ファイルです。たとえば app/api/CLAUDE.md は、セッション開始時ではなく Claude が app/api 配下のファイルを読むときに読み込まれます。パススコープ付きルールと同じコンパクション挙動を持ち、当該サブディレクトリに再度触れるまで失われます。

cwd 配下のすべてのサブディレクトリ CLAUDE.md ファイルは、Claude がそのディレクトリ内のファイルを読むときに読み込まれます。

共有リポジトリでは、CLAUDE.md は所有者のいない設定ファイルと同じように肥大化します。各チームが自分の指示を追記し、何も削除されません。規模が大きくなるとコストが積み重なります。

すべての行が、リポジトリで作業するすべてのエンジニアのすべてのセッションに、そのタスクに関連するか否かに関わらず読み込まれます。これはトークンを消費し、本当に重要な指示への遵守を薄めてしまいます。ファイルが大きくなったら、チーム固有の規約はパススコープ付きルールに、手順はスキルに移し、関連するときだけ読み込まれるようにしましょう。

ヒント: CLAUDE.md は200行未満に抑え、所有者を決め、コードと同じように変更をレビューしましょう。このファイルは Claude にコードベースの概要を与えるもの、あるいは必要に応じて Claude が詳細情報を見つけられる他のファイルへの索引と考えてください。

モノレポでは、各チームのディレクトリにそれぞれサブディレクトリ CLAUDE.md を持たせ、チームが自分の規約だけを読み込むようにします。開発者は claudeMdExcludes 設定を使って、触れることのないチームのファイルをスキップできます。

組織内のすべてのリポジトリに適用すべき基準（セキュリティポリシー、コンプライアンス要件など）については、中央管理された CLAUDE.md を MDM や構成管理で開発者のマシンに配布でき、個々の設定では除外できません。

ルール

ルールは .claude/rules/ にある Markdown ファイルで、Claude に特定の制約や規約を与えます。

スコープなしのルールは CLAUDE.md と同様に振る舞い、セッション開始時に常に読み込まれ、コンパクション時に再注入されます。これは、目下のタスクに関連しなくてもコンテキストを読み込むためトークンを浪費しかねません。

パススコープ付きルールでは、paths フィールドを追加して読み込みタイミングを制御することで、関連するときだけルール指示を読み込めます。

たとえば、src/api/** にスコープされたルールは、ドキュメントのみのセッション中はコンテキストに入りません。Claude が src/api/ ディレクトリ内のファイルを読むときにだけ読み込まれます。

記述例：

---
paths:
  - "src/api/**"
  - "**/*.handler.ts"
---
すべてのAPIハンドラは処理前にZodで入力を検証しなければならない。

ヒント: 「マイグレーションは追記のみ」のようなファイル固有の制約は、paths: フロントマターに置くルールが最適です。横断的な関心事や、コードベースの複数（だが全部ではない）箇所に現れるファイルに関する指示なら、ネストした CLAUDE.md ファイルよりパススコープ付きルールを選びましょう。

スキル

スキルは .claude/skills/ に、指示・スクリプト・リソースのフォルダとして存在し、Claude が動的に読み込みます。各スキルには名前・説明・本体を持つ SKILL.md ファイルがあります。

セッション開始時に読み込まれるのは名前と説明だけで、本体は Claude がスキルを呼び出すとき（スラッシュコマンド /code-review 経由、またはタスクの自動マッチング）に読み込まれます。

スキルはシステムプロンプト経由でトリガーされます。

たとえば /code-review は組み込みスキルで、現在の差分をレビューしファイルを編集せずに結果を報告します。スキルがプレイブックを定義するため、呼び出すたびに Claude は同じ構造化されたアプローチに従います。

コンパクション時、Claude Code は呼び出されたスキルを、すべての呼び出し済みスキルにまたがる合計予算の範囲内で再注入します。セッション中に多くのスキルを呼び出していた場合、古いものから削除されます。

ヒント: デプロイのワークフロー、リリースチェックリスト、レビュープロセスなど手続き的な指示は、CLAUDE.md ではなくスキルに属します。

サブエージェント

サブエージェントは .claude/agents/ にある Markdown ファイルで、特定のサイドタスク向けに分離されたアシスタントを定義します。各ファイルは YAML フロントマター（名前、説明、モデルやツールアクセスの任意フィールド）に続いて、そのサブエージェントのシステムプロンプトとなる本体を持ちます。

サブエージェントは、名前・説明・ツール一覧がセッション開始時に読み込まれる点でスキルに似ていますが、エージェント本体内のより大きなコンテキストは自動呼び出しされません。Claude はプロンプト文字列を渡して Agent ツール経由で呼び出します。

サブエージェント本体内の大きな指示コンテキストは自動呼び出しされないだけでなく、親の会話には一切入りません。

サブエージェントは自身の新しいコンテキストウィンドウで実行され、メインセッションに返るのはサブエージェントの最終メッセージ（多くの場合、多数のサブタスクの集約結果）とメタデータだけです。

このパターンはスケールします。サブエージェントは最大5階層までネストでき、動的なワークフローは、各詳細を指定しなくても数十から数百のバックグラウンドエージェントを編成できます。編成計画と中間結果は Claude のコンテキストウィンドウではなくスクリプト変数に存在するため、指示の忠実さを失わずにスケールできます。

ヒント: この分離こそ、スキルではなくサブエージェントを選ぶ主な理由の一つです。詳細検索、ログ解析、依存関係監査のようなサイドタスクが、二度と参照しない中間結果でメインの会話を散らかすような場合に、サブエージェントを使いましょう。手順をメインスレッド内で展開させ、各ステップを見て操舵したい場合はスキルを使います。

フック

フックは、ユーザー定義のコマンド、HTTPエンドポイント、またはLLMプロンプトで、ファイル編集、ツール呼び出し、セッション開始などライフサイクルの特定イベントで発火することで、Claude の挙動をより確定的に制御します。

フックは settings.json、管理ポリシー設定、またはスキル/エージェントのフロントマターに登録します。

フックにはいくつか種類があります：command、HTTP、mcp_tool、prompt、agent。すべてのフックは確定的にトリガーされます。前者3つは確定的に実行され、後者2つ（prompt と agent）はルールの集合ではなく Claude の判断を使って出力を決めます。

フックは、設定や指示がメインのコンテキストウィンドウの外に存在するため、コンテキストコストが低いです。ハーネスがハンドラ（command、http、mcp_tool）を実行するか、フックの種類に応じて別ウィンドウでモデル呼び出し（prompt、agent）を行います。

一部のフックは出力がメインコンテキストに保存されることがあります。たとえば、ブロックフックの標準エラーはコンテキスト内に保存され、Claude が呼び出しが拒否された理由を把握できます。

ただしほとんどのフックは、設定が明示的に返さない限り出力がメインウィンドウに保存されません。PreCompact イベントを使い、コンパクション前にチャット履歴を別ファイルにバックアップした場合、Claude はどのファイルに履歴が保存されたか分かりません。

この点で、これらのフックは CLAUDE.md、ルール、スキルとは根本的に異なります。

ヒント: 確定的に起きるべきこと（編集後のリンター実行、完了時のSlack投稿、特定コマンドの実行前ブロックなど）にはフックを使いましょう。PreToolUse フックは任意のツール呼び出しを検査し、終了コード2で拒否できます。

これらは Claude に読み込まれる指示ではなくハーネスが実行するコードなので、コンテキストコストが低いです。

出力スタイル

出力スタイルは .claude/output-styles/ にあるファイルで、システムプロンプトに指示を注入します。コンパクションされず、毎セッション開始時に読み込まれ、セッション内の最初のリクエスト後にキャッシュされるため、中程度のコンテキストコストがあります。

システムプロンプト内に位置するため、出力スタイルはここまで扱ったどの方法よりも高い指示遵守の重みを持ち、慎重に使うべきです。

出力スタイルの変更はデフォルトの出力スタイルを置き換えます（スタイルのフロントマターで keep-coding-instructions: true を設定しない限り）。

Claude Code では、これにより Claude がソフトウェアエンジニアリングのタスクを支援していると伝える指示や、その他の重要なデフォルト指示が削除されます。たとえば、変更の範囲をどう絞るか、コードコメントをいつ追加・省略するか、セキュリティ上の懸念にどう対処するか、作業完了を宣言する前にテストを実行する検証習慣などです。

デフォルトでは、カスタム出力スタイルはこれらすべてを失わせ、Claude Code はソフトウェアエンジニアアシスタントというより汎用アシスタントに近くなります。

ヒント: カスタム出力スタイルを書く前に、組み込みスタイルを確認しましょう。Proactive、Explanatory、Learning が最も一般的なニーズ（自律性、教育モード、協調的コーディング）をカバーし、スタイルファイルを保守する必要がありません。

システムプロンプトへの追記

出力スタイルを変更する代わりの方法が append-system-prompt フラグです。出力スタイルファイルの変更は Claude の挙動に大きく意図しない変化をもたらしうるのに対し、追記フラグは元のシステムプロンプトに対して加算的なだけです。Claude の役割を変更せず、デフォルトの役割に指示を追加します。

また、呼び出し時に渡され、その呼び出しのみに適用されるため、ファイルとしてセッションをまたいで永続化されません。

システムプロンプトへの追記は、他の指示方法に比べてコンテキストコストが高くなる場合があります。入力トークンが増えますが、プロンプトキャッシュによりセッション内の最初のリクエスト以降はこのコストが下がります。より冗長で長いスタイルを指示すると出力トークンも増えます。

ヒント: システムプロンプトへの追記は、特定のコーディング基準、出力書式、ドメイン固有の知識を加えるのに最適です。ただし、追記は遵守について逓減効果があることに留意してください。一般に、この方法で多くの指示を与えるほど、特に矛盾がある場合、Claude の遵守は緩くなります。

Claude Code カスタマイズの簡単なヒント

以下のことをしていると気づいたら、指示の置き場所を別に検討するとよいでしょう：

CLAUDE.md に「Xのたびに必ずYをする」と書く。 その挙動が確実に起きるべきなら（毎編集後の prettier 実行、完了時のSlack投稿など）、代わりに settings.json のフックを使いましょう。モデルがフォーマッタを実行することを選ぶのと、フォーマッタが自動で実行されるのとは別物です。

CLAUDE.md に「これは絶対にするな」と書く。 絶対に起きてはならないことがある場合、指示は適切な手段ではありません。Claude は大抵その指示に従いますが、長いセッションや曖昧な状況下のプレッシャー時、あるいはタスクの一環でアクセスしたファイル内のプロンプトインジェクションにより、プロンプトされたルールに従えないことがあります。本物のガードレールは確定的である必要があり、その強制手段はフックと権限です。PreToolUse フックは呼び出しを検査し終了コード2でブロックできます。管理設定はさらに踏み込んでおり、管理者が配布し、ユーザーのローカル設定で上書きできず、組織全体の確定的なガードレールを強制する唯一の方法です。

CLAUDE.md に30行の手順を書く。 手順はスキルに属します。CLAUDE.md は Claude が常に保持すべき事実（ビルドコマンド、モノレポ構成、チーム規約）のためのものです。デプロイの手順書やセキュリティレビューのチェックリストは .claude/skills/ に置き、本体は呼び出されたときだけ読み込まれるようにすべきです。

paths なしの API 固有ルール。 ルールが src/api/** にのみ適用されるなら、paths: でスコープすることで無関係な作業中はコンテキスト外に保てます。スコープなしのルールは、内容を CLAUDE.md に置くのと機構的に同一です（常に読み込まれ、常にトークンを消費）。

個人的な好みをプロジェクトレベルの CLAUDE.md に書く。 すべてのファイルベースの方法には、どのリポジトリにいても毎セッション読み込まれるユーザーレベルの対応物があります。個人的な好み（常にセマンティックなコミットメッセージを使う、など）にはローカルファイルを使い、プロジェクトレベルのファイルはチーム全体だが特定コードベース固有の好みのために使いましょう。