Claude Codeにおけるルールとスキルが実際にどう機能するか

AI コーディングエージェントを設定するための作業を少しでもしたことがあるなら、ルールとスキルが別物であることに気づいているはずです。ルールは常に読み込まれます。スキルは必要に応じて呼び出されます。ルールは認識を扱い、スキルは手順を扱います。

この違いを理解して、それを前提に組み立て始めた後に、面白い問題が始まります。私は 2 年以上、AI コーディングツールに取り組んできました。Windsurf から始めて、Claude Code で次第により洗練されたシステムを構築してきました。最近、実装レベルでこれらの仕組みが実際にどう動いているのかを理解するために、Claude Code のソースコードを調べました。そこで見つけたことは、トレードオフの捉え方を変えるものでした。

ルールとスキルは、単に読み込みのタイミングが異なるだけではありません。システム上の異なる位置を占めており、そのためモデルはそれらを異なるものとして扱います。

The Failure Modes Tell You Everything

基本的な区別は役に立ちますが、それを失敗モードという観点で捉えると強力になります。

行動するタイミングを逃した場合、それはルールの問題です。トリガーが発火したときにルールがコンテキストに存在しなかったため、エージェントは何かが起きるべきだと認識できませんでした。その瞬間は何事もなかったかのように過ぎていきます。トリガーが発火したときに存在しないルールは、存在しないのと同じです。

行動の手順のどこかを見落とした場合、それはスキルの問題です。エージェントは状況を認識しましたが、詳細な手順が利用できませんでした。スキルには、何かをどうやって行うかの指示が含まれており、その「何か」が実際に起きている最中に存在していれば十分です。

2 つの失敗モードに対して、2 つの異なるツール。すべての設定判断は、「どの失敗モードから守るのか」という問いになります。

How Your Agent Actually Processes Input

ライフサイクルを説明する前に、エージェントがあなたの設定を読み取るときに裏側で何が起きているのかを理解しておくと役立ちます。

Claude Code がモデルにリクエストを送るたびにいくつかのものを送りますが、あなたの設定がどこに存在するのかを理解するうえで重要なのは主に 2 つです。システムプロンプトとメッセージのリストです。これらはアーキテクチャ上別の入力であり、モデルはそれらを異なるものとして扱うよう訓練されています。

システムプロンプトには、Anthropic が Claude Code 用に書いた行動指示が含まれます。ツールの使い方、権限の扱い方、出力のフォーマット方法などです。これは指令レイヤーです。あなたはここを書きません。これはすべての Claude Code ユーザーに共通です。

あなたのルールはこのシステムプロンプトに入るものだと思うかもしれませんが、違います。メッセージにはそれ以外のすべてが含まれます。会話履歴、あなたの質問、ツールの結果、そして重要なのがあなたの CLAUDE.md とルールの内容です。あなたのルールは、この会話における最初のメッセージとして注入されます。さらに、「これはユーザーの質問ではなくコンテキストだ」ということを示す特別なタグで包まれます。スキルは、呼び出されると会話の後のほうで追加メッセージとして到着します。

つまり、あなたのルールは Anthropic の指示のようなシステムレベルのディレクティブではありません。ルールは会話の中で最初にモデルが読むものなので、位置として大きな優位がありますが、同じレイヤーの中にあり、あなたがこれまでに述べた他の内容と同じ層で扱われます。この区別を理解することは、設定の設計方法に影響します。

Rules: The Stable Prefix

ルールはセッション開始時に読み込まれ、コンパクションが行われるまでキャッシュされます。.claude/rules/ 配下の各ルールファイルと CLAUDE.md の内容を読み取り、それらを結合して、会話の最初のメッセージとして注入します。これはあなたが何かを入力する前に行われます。

この最初のメッセージの位置が重要な理由は 3 つあります。

位置による優位性。 モデルはすべてのターンでコンテキスト全体を読み取りますが、注意は一様ではありません。研究では、U 字型のパターンが文書化されています。コンテキストの始まりと終わりが最も強い注意を集め、途中が最も弱いというものです。これは「真ん中で失われる（lost in the middle）」効果と呼ばれます。現在のモデルはこの影響を緩和するよう訓練されているため、2023 年のときほど劇的ではありませんが、それでも位置による優位性は現実のものです。

Anthropic 自身の長文脈ドキュメントでは、参照資料の後に長いコンテキストの末尾へクエリや指示を置くことが推奨されています。同じ注意のダイナミクスを前提に設計しているのです。

あなたのルールは、会話の最初に置かれます。常にです。最初のメッセージと最初のアシスタントの応答も、この「会話の先頭の優位性」を受けます。会話が長くなるにつれて、呼び出されたスキルはセッションのどこにいるかに応じて着地します。長い会話では、それはちょうど真ん中、つまり最も注意が弱いゾーンになります。

プロンプトキャッシュ。 あなたのルールはターン間で変わりません。モデルは 1 ターン目でそれらを処理し、2 ターン目でも同一であるため、システムは再処理をスキップできます。これがプロンプトキャッシュです。ルールは単に永続的であるだけでなく、最初のターン以降は計算コストが安いことを意味します。会話の後半でスキルとして同じ内容が到着しても、この恩恵は得られません。なぜなら、その前の内容が変わり得るからです。

決してコンパクト化されない。 会話が十分に長くなると、Claude Code はそれをコンパクト化します。古いメッセージを要約してスペースを空けるのです。あなたのルールは、このコンパクションには決して含まれません。会話と一緒に圧縮されるのではなく、ディスクから再構築されます。セッションがどれだけ長く続いても、毎回完全な忠実性が保たれます。

その代償はあります。ルール内のすべてのトークンが、毎ターン家賃を払うことになります。500 トークンのルールは、API 呼び出しのたびにコンテキスト 500 トークン分のコストがかかります。100 ターンのセッションでは、その 1 つのルールがコンテキスト 50,000 トークンを消費しました。コストは見えませんが、実際に存在します。

Path-Scoped Rules

常に読み込まれるルールと、必要に応じて呼び出されるスキルの間には、どちらもうまく扱えない特定の問題を解決する仕組みがあります。

パススコープ付きルールでは YAML のフロントマターを使って、どのファイルに適用されるかを指定します。最初に一致するファイルを読み込んだとき、そのルールの内容はファイル読み取り結果に結び付き、その時点で会話に注入されます。これはスキルが着地するのと同じ位置です。最初に一致するまではトークンを 1 つも消費しません。一致するファイルにセッション中に一度も触れないなら、決して読み込まれません。

トリガーは機械的です。解釈のためのモデル判断は不要で、250 文字の説明も必要ありません。ファイルを読み込むとシステムが glob をチェックし、一致するルールが結び付けられます。セッション中に新しく作成したパススコープ付きルールファイルも、次に一致するファイルが読み込まれたときに反映されます。再起動は不要です。

私は、特定のディレクトリで作業するときにだけ意味を持つ慣習（コンベンション）ファイルに対してこれを使っています。projects/ にあるファイルに触れたときに、プロジェクト構造に関するルールを読み込みます。記事の投稿をいじり始めたときに、ブログのフォーマットに関するルールを読み込みます。

Skills: The Conversation Layer

スキルは小さく始まります。セッション開始時には、利用可能なスキルの一覧だけが読み込まれます。各スキルの名前と簡単な説明で、それぞれ 250 文字までです。SKILL.md の全文はディスクに残ったままです。この一覧によって、モデルはどんなスキルが存在し、いつそれらを呼び出すべきかを知ります。

スキルが呼び出されると、あなたが /skill-name と入力するか、モデルがそれが関連していると判断するかのいずれかにより、ディスクから全コンテンツが読み込まれて、メッセージとして会話に注入されます。システムプロンプトとしてではありません。先頭位置のコンテンツとしてではありません。会話の現在のポイントに到達する会話メッセージとして、他のすべてと入り混じる形で配置されます。

これが重要なアーキテクチャ上の違いです。呼び出された後は、スキルのコンテンツは会話の中に存在し、そのまま残り続けます。ターンの後に削除されることはありません。一時的ではありません。しかし、あなたのルールと同じ位置にあるわけでもありません。

会話の途中に到着します。 たとえば5ターン目で呼び出されたスキルは、4ターン目と6ターン目の間に入ります。会話が50ターンまで成長すると、そのスキルのコンテンツは長いメッセージ履歴のど真ん中に深く埋もれ、モデルの注意を45ターン分のコンテキストと競い合うことになります。一方であなたのルールは、依然として会話の最初のほうにあります。

圧縮の対象になります。 Claude Codeが会話を圧縮すると、呼び出されたスキルは保持されますが、制限付きです。各スキルは圧縮後で最大5,000トークンに上限が設けられ、呼び出されたスキルすべての合計予算は25,000トークンです。スキルは、呼び出された時刻がどれだけ最近かで並べ替えられます。予算が収容できる以上にスキルを呼び出している場合は、最も古いものから切り捨てられます。

つまり、スキルが呼び出された後であっても、内容がまったく同じルールとスキルは同等ではありません。ルールは先頭位置に、完全な忠実度のまま、永遠に残ります。スキルは、状況の圧力のもとで切り詰められたり、落とされたりします。

分割パターン

層（レイヤー）の違いを理解すると、分割パターンの重要性がよりはっきりします。

私が見つける最も一般的な設定上の問題は、1つのルールファイルに認識と手順の両方をやらせようとしてしまうことです。冒頭に数行の認識ロジック（「この状況が起きたら、これをする」）があり、その後に50行分の手順の詳細が続く、といった形です。トリガーを拾うには、認識は常時ロードされている必要があります。手順のほうはそうではありません。

解決策：認識の関心事を取り出し、ルールとして保持します。3〜5行で、常にロードされ、位置的にも有利な形にします。手順の関心事を取り出して、呼び出されたときだけロードするスキルに移します。認識は安定したプレフィックスで発火します。手順は、会話内に「必要になったタイミングで」ロードされます。

私は自分の設定で、5つのルールにこの方法を適用しました。分割によって、だいたい120行分の「常時ロードされるコンテキスト」が削減できました。同じ振る舞いで、オーバーヘッドは劇的に少なくなります。そして今、手順は、無関係なターンのあいだコンテキストに居座り続けるのではなく、使われる地点で新鮮な状態でロードされる恩恵を得ています。

ここにはコストだけでなく、信頼性に関する議論もあります。スキル自身の説明（最大250文字で、会話メッセージのどこかに置かれる）は、モデルがそれを自動で呼び出すかどうかを判断する際にモデルが読むものです。その説明は、注意を奪い合う相手として、会話の他のあらゆるものと競合します。安定したプレフィックスにある3行のルールは、「モデル自身に状況を認識してもらえることを期待する」250文字のスキル説明よりも、より確実に発火します。確実なトリガーが重要なら、そのトリガーは、スキル説明がどれほど良いかに関わらず、ルールに属します。ルールがその瞬間を捕まえます。スキルが手順を届けます。各メカニズムが得意なことをそれぞれ担当します。

意思決定のためのフレームワーク

自分のシステムに新しいふるまいを追加するとき、私は4つの質問をします。

1. それは、呼び出される前に認識される必要がありますか？ はいなら、トリガーはルールに入ります。短く保ってください。パターンマッチングに十分なだけで構いません。

2. それは、詳細な手順ステップを必要としますか？ はいなら、そのステップは、必要になったときにロードされるスキルに入ります。

3. それは特定のファイルコンテキストに結びついていますか？ はいなら、パススコープされたルールにすると、機械的な信頼性を備えた遅延ロードが得られます。モデルの判断は不要です。初めて一致するファイルに触れるまでコストはゼロです。

4. それは、長いセッションを通して完全な忠実度で保持される必要がありますか？ はいなら、それはルールに入ります。スキルは、長い会話の圧縮後に切り詰められる可能性があります。

目標は、適切なタイミングで、適切な情報をコンテキストに置くことです。今のタスクが必要としているからこそ、すべてのトークンがそこにあるべきです。

第三のピースがある

ルールは認識を扱います。スキルは手順を扱います。そしてClaude Codeには、それらでもない第三のメカニズムがあります。これは、判断を要さず、毎回自動的に起きるべきことを扱います。認識は不要で、従うべき手順もありません。特定のイベントに対する決定論的な応答があるだけです。

それは、設定の自律神経系だと考えてください。あなたのルールは意識的な判断です。あなたのスキルは、意図して呼び出す学習された手順です。フックはあなたの反射です。つまり、あなたが考えなくても発火する応答です。もしそれを考える必要があるなら、いずれ忘れてしまうからです。

これはそれ自体で別の記事に値します。ですが今のところ、もし「Xが起きるたびに、いつもYをする」と言うルールを書いているなら、それはおそらくルールではなくフックを記述しています。「これをやることを覚える」と「それがただ起きる」の違いは、コンプライアンスとアーキテクチャの違いです。

AI設定をスケールさせるための工学的な原則に興味があるなら、別の記事でSOLIDの原則をこの問題に適用することについて書きました。コンテキストコストの議論と、関心の分離（separation-of-concerns）のパターンは、そこで詳しく扱っています。