Claudeはあなたの働き方に合わせて動作するように構築されており、Claude Codeではそれをカスタマイズすることができます。

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

それぞれの方法は以下を制御します：

• 指示がいつコンテキストに読み込まれるか
• 長いセッションの間、指示が維持されるかどうか（コンパクション時の挙動）
• 指示がどれだけの強制力（権限）を持つか

以下の表は、各方法の主な違いを簡単にまとめたものです。本文では、それぞれのClaudeへの指示をどこに配置すべきかを判断するための詳細な情報と意思決定フレームワークを提供します。

指示を与えるための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.mdを配置することで、チームが自分たちの規約のみを読み込むようにし、開発者は claudeMdExcludes 設定を使用して、触ることのないチームのコードを除外できます。

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

CLAUDE.mdの設定方法の詳細は、ブログ記事「CLAUDE.md files: Customizing Claude Code for your codebase」を参照してください。

ルール (Rules)

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

スコープの制限がないルールは、セッション開始時に常に読み込まれ、コンパクション時に再注入される点でCLAUDE.mdと同様に動作します。これは、手元のタスクに関連していない場合でもコンテキストをロードするため、トークンを無駄に消費する可能性があります。

パス制限ルール（Path-scoped rules）を使用すると、paths フィールドを追加して読み込みタイミングを制御することで、ルール指示を関連する場面でのみ読み込むことができます。

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

設定例は以下のようになります：

---
paths:
  - "src/api/**"
  - "**/*.handler.ts"
---
すべてのAPIハンドラーは、処理を行う前にZodで入力を検証しなければなりません。

ヒント: 「マイグレーションは追記専用にする」といったファイル固有の制約は、フロントマターの paths: に指定したルールとして配置するのが最適です。指示が、コードベースの複数（ただしすべてではない）の場所に現れる横断的な関心事やファイルに関するものである場合は、ネストされたCLAUDE.mdファイルよりもパス制限ルールを使用してください。

スキル (Skills)

スキルは、.claude/skills/ に、Claudeが動的に読み込む指示、スクリプト、リソースのフォルダとして保存されます。各スキルには、名前、説明、および本文を含む SKILL.md ファイルがあります。

セッション開始時には名前と説明のみが読み込まれ、本文全体はClaudeがスラッシュコマンド（/code-review）を使用するか、タスクに自動マッチしたときに呼び出されて読み込まれます。

スキルはシステムプロンプトを介してトリガーされます。

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

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

ヒント: デプロイのワークフロー、リリースチェックリスト、レビュープロセスといった手順的な指示は、CLAUDE.mdではなくスキルに記述すべきです。

Claude Codeにはあらかじめいくつかのスキルが同梱されていますが、独自のカスタムスキルを作成することも可能です。作成方法は「complete guide to building skills for Claude」を参照してください。

サブエージェント (Subagents)

サブエージェントは、.claude/agents/ にあるMarkdownファイルで、特定のサイドタスク向けに分離されたアシスタントを定義します。各ファイルはYAMLフロントマター（名前、説明に加え、モデルやツールへのアクセス制御などのオプションフィールド）を使用し、その後にサブエージェント의システムプロンプトとなる本文が続きます。

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

Claude Codeのコンテキストウィンドウには、Claudeがセッションについて知っているすべての情報が保持されます。こちらのインタラクティブタイムラインでは、何がいつ読み込まれるかを確認できます。

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

サブエージェントは独自のクリーンなコンテキストウィンドウで実行され、メインセッションに返されるのはサブエージェントの最終メッセージ（多くのサブタスクの集計結果であることが多い）とメタデータのみです。

このパターンは拡張可能です。サブエージェントは最大5レベルまでネストでき、ダイナミックワークフローにより、サブエージェントのアーキテクチャを個別に指定することなく、数十から数百のバックグラウンドエージェントを調整できます。オーケストレーション計画と中間結果は、Claudeのコンテキストウィンドウではなくスクリプト変数に保存されるため、指示の忠実度を損なうことなくスケールさせることができます。

ヒント: この「隔離性」こそが、スキルではなくサブエージェントを選択する主な理由の1つです。ディープサーチ、ログ分析、依存関係の監査などのサイドタスクによって、二度と参照しない中間結果でメインの会話が乱雑になってしまうのを防ぎたい場合は、サブエージェントを使用してください。手順が進行する様子をメインスレッドで確認し、各ステップを制御したい場合は、スキルを使用してください。

フック (Hooks)

フックは、ユーザーが定義するコマンド、HTTPエンドポイント、またはLLMプロンプトであり、ファイルの編集、ツールの呼び出し、セッションの開始といったClaudeのライフサイクルにおける特定のイベントで実行されることで、Claudeの動作をより決定論的に制御できます。

フックが実行される可能性のあるClaude Codeセッション内のイベントマップ。

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

フックには、コマンド、HTTP、mcp_tool、プロンプト、エージェントのいくつかのタイプがあります。すべてのフックは決定論的にトリガーされます。最初の3つは決定論的に実行されますが、後ろの2つ（プロンプトとエージェント）は、出力の決定にルールセットではなくClaudeの判断を使用します。

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

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

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

このため、これらのフックタイプはCLAUDE.md、ルール、スキルとは根本的に異なります。詳細はブログ記事「how to configure hooks」を参照してください。

ヒント: 編集後のリンターの実行、完了時のSlackへの投稿、実行前の特定コマンドのブロックなど、決定論的に発生させるべきことにはすべてフックを使用してください。PreToolUse フックは、ツール呼び出しを検査し、終了コード2を返してそれを拒否することができます。

フックはClaudeにロードされる指示ではなく、ハーネスが実行するコードであるため、コンテキストコストが低くなります。

出力スタイル (Output styles)

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

出力スタイルはシステムプロンプトに配置されるため、これまでに説明したどの方法よりも高い指示追従性（ウェイト）を持ち、慎重に使用する必要があります。

出力スタイルを変更すると、デフォルトの出力スタイルが上書きされます（スタイルのフロントマターで keep-coding-instructions: true を設定していない限り）。

Claude Codeにおいて、これはClaudeがユーザーのソフトウェア開発タスクを支援していることを伝える指示や、以下のような重要なデフォルト指示を削除することになります：

• 変更のスコープをどう決めるか
• コードコメントを追加または省略するタイミング
• セキュリティ上の懸念への対応方法
• 作業完了を宣言する前にテストを実行するなどの検証習慣

デフォルトでは、カスタム出力スタイルを適用するとこれらがすべてドロップされ、Claude Codeはソフトウェア開発のアシスタントというよりも、一般的なアシスタントのようになってしまいます。

ヒント: カスタム出力スタイルを作成する前に、組み込みのスタイルを確認してください。Proactive（積極的）、Explanatory（解説的）、Learning（学習用）は、スタイルファイルを維持管理することなく、最も一般的なニーズ（自律性、指導モード、協調的なコーディング）をカバーしています。

システムプロンプトの追加

出力スタイルを変更する代わりとなるのが append-system-prompt フラグです。出力スタイルファイルを変更するとClaudeの挙動に意図しない大きな変化が生じる可能性がありますが、追加（append）フラグは元のシステムプロンプトに対して追加のみを行います。Claudeの役割は変更せず、デフォルトの役割に指示を追加するだけです。

また、これは起動時に渡され、セッションをまたいでファイルとして永続化されるのではなく、その起動にのみ適用されます。

システムプロンプトの追加は、指示を渡す他の方法と比較してコンテキストコストが高くなる可能性があります。入力トークンが増加しますが、プロンプトキャッシュによりセッションの最初のベースステップの後はこのコストが削減されます。また、Claudeにより冗長または長いスタイルを使用するように指示すると、出力トークンも増加します。

ヒント: システムプロンプトの追加は、特定のコーディング標準、出力フォーマット、またはドメイン固有の知識を追加するのに最適です。ただし、システムプロンプトを追加しても、追従性が比例して高まるわけではないことに注意してください。一般的に、この方法で提供する指示が多ければ多いほど、特に指示同士が矛盾している場合、Claudeはそれらを厳密に従わなくなります。

Claude Codeカスタマイズのクイックヒント

もし以下のいずれかを行っている場合、指示の配置場所として別の選択肢を検討した方がよいかもしれません：

CLAUDE.mdに「Xのたびに、常にYを行う」と書く。 編集のたびにprettierを実行する、完了時にSlackに投稿するなど、動作を確実に実行させたい場合は、代わりに settings.json のフックを使用してください。モデルがフォーマッターの実行を選択するのと、フォーマッターが自動的に実行されるのは異なります。

CLAUDE.mdに「絶対にこれをしない」と書く。 絶対に発生させてはならないことに対して、指示（プロンプト）は適切なツールではありません。Claudeはほとんどの場合指示に従いますが、プレッシャーがかかっているとき、長いセッション、曖昧な状況、あるいはタスクの一環としてアクセスしたファイル内のプロンプトインジェクションなどにより、モデルがプロンプトで示されたルールに従わないことがあります。本物のガードレールは決定論的である必要があり、その強制手段はフックと権限（Permissions）です。PreToolUse フックは呼び出しを検査し、終了コード2を返してブロックできます。マネージド設定（Managed settings）はさらに進んでおり、管理者によってデプロイされ、ユーザーのローカル設定で上書きできず、組織全体の決定論的なガードレールを強制する唯一の方法です。

CLAUDE.mdに30行の手順（プロシージャ）を書く。 手順はスキルに属します。CLAUDE.mdは、ビルドコマンド、モノレポのレイアウト、チームの規約など、Claudeが常に保持すべき事実のためのものです。デプロイ手順書やセキュリティレビューのチェックリストは .claude/skills/ に配置すべきであり、その本文は呼び出されたときにのみ読み込まれます。

パス指定なしでAPI固有のルールを書く。 ルールが src/api/** にのみ適用される場合、paths: でスコープを制限することで、無関係な作業中にコンテキストに入らないようにできます。スコープ制限のないルールは、CLAUDE.mdに内容を書くのと機械的に同じであり、常にロードされ、常にトークンを消費します。

プロジェクトレベルのCLAUDE.mdファイルに個人の好みを書き込む。 ファイルベースのすべての方法には、どのリポジトリにいるかにかかわらず、すべてのClaude Codeセッションでロードされるユーザーレベルの対応物があります。個人の好み（「常にセマンティックコミットメッセージを使用する」など）にはローカルファイルを使用してください。プロジェクトレベルのファイルは、チーム全体で共有される、特定のコードベースに特有の好みのために残しておきます。

はじめに

環境の設定から並行セッションにわたるスケーリングまで、Claude Codeを最大限に活用するためのヒントとパターンは、best practices for Claude Code のドキュメントでさらに見つけることができます。

これらがいくつか機能するようになったら、それら（スキル、サブエージェント、フック、出力スタイル）の多くをプラグインとしてバンドルし、チームメイトやプロジェクト間で一貫したセットアップを共有できます。