AIコーディングの
コンテキストレイヤー。
コンテキストレイヤーは、チームのメモリ、ルール、スキルをパスごとに索引化し、チームが使うエージェントに、当てはまる部分だけを最初のツール呼び出しより前に届けます。チームが実践している5つの方法と、どれが合うかの見分け方を紹介します。
コンテキストレイヤーなし
- アシスタントは注文モジュールを開き、スキーマを読み、importをたどって価格と税の処理に入り、割引のハンドラーを読んで、クーポンがどこに付くのかを推測します。
- 割引を注文の合計に付ける、もっともらしい変更を書きます。差分はコンパイルが通ります。そして、チームがすでに知っているとおりのかたちで間違っています。
- レビュアーが気づいて明細行の規約をもう一度説明し、同じことが繰り返されます。ナレッジは1人の頭の中にとどまったままです。
- 大量のファイルの読み込み、大量のツール呼び出し、長い入力ウィンドウ、そしてレビュー1回分を無駄にする回り道。
コンテキストレイヤーあり
- 注文のパスに一致する部分が、フックの時点で、最初のツール呼び出しより前に届きます。モデルは、クーポンが明細行に付くことをすでに知っています。
- 最初の一回で、割引を明細行に適用します。始める前から、そのルールがコンテキストにあったからです。
- 強制ルールなら、割引を間違った場所に付ける変更を、反映される前にブロックできます。修正はレビューの後ではなく、前に行われます。
- 短く焦点の絞られたコンテキストウィンドウと、狙いを定めた変更。このパスのルールだけが注入されたからです。
エージェントにコンテキストを渡す5つの方法。
- 指示ファイル
- 選ぶべきとき
- 1人、1つのリポジトリ、少ない規約
- ナレッジが届くタイミング
- 毎ターン、すべて
- ツールを変えても残るか
- 残らない。ツールごとに自分のファイルを読む
- 破綻するところ
- 2人目、または2つ目のエージェントが加わったとき。ツールごとに専用のコピーが必要になります。
- メモリAPI
- 選ぶべきとき
- 自分の製品にメモリを組み込んでいる
- ナレッジが届くタイミング
- 何かが問い合わせたとき
- ツールを変えても残るか
- 残る。呼び出し箇所を自分で管理していれば
- 破綻するところ
- 設計上、静かです。誰も尋ねなかった制約は、決して届きません。
- ベクトル検索
- 選ぶべきとき
- 答えは書かれているが、場所がわからない
- ナレッジが届くタイミング
- 何かが問い合わせたとき
- ツールを変えても残るか
- 残る。ただしインデックスの運用は自分で行う
- 破綻するところ
- どのファイルにも書かれていない決定は返せません。
- エージェントワークスペース
- 選ぶべきとき
- 並行するエージェントがボトルネック
- ナレッジが届くタイミング
- セッション単位。パス単位ではない
- ツールを変えても残るか
- 論点が違う。それ自体がツール
- 破綻するところ
- 2つ目のチェックアウトがあっても、どのナレッジがどこに属するかは決まりません。
- パス単位のレイヤー
- 選ぶべきとき
- 1人で複数のエンジンを使う、またはチームで1つのリポジトリ
- ナレッジが届くタイミング
- 最初のツール呼び出しより前に、パスに絞って
- ツールを変えても残るか
- 残る。ナレッジはすべてのツールの外にある
- 破綻するところ
- 1人が1つのエージェントを使うだけなら、やりすぎです。
このうち2つは競合ではありません。自分の製品の中のメモリAPIと、エージェントのためのコンテキストレイヤーは、同時に両立できます。
必要ないとき。
1人、1つのリポジトリ、1つのエージェント、そして1ページに収まる規約。それなら、チェックインしたCLAUDE.mdが正解で、コンテキストレイヤーは余計な負担です。分かれ目はリポジトリの大きさではなく、チームの人数でもありません。2つ目のエージェントか2人目の人、どちらか先に来たほうです。同じリポジトリでClaude CodeとCodexを動かす1人の開発者は、すでにこの問題を抱えています。片方に教えたことをもう片方は知らず、それぞれが別のファイルを読むからです。
コンテキストレイヤーが運ぶもの
- メモリチームが学んだこと「それは試したけれど、うまくいかなかった」という事実は、学んだエンジニアがいなくなると消えてしまいます。それを、当てはまるパスに紐づけます。詳しくはAIコーディングエージェントの永続メモリへ。
- ルールやるべきこと、避けるべきこと助言のルールと強制ルール。強いガードレール(
/apps/webではconsole.log禁止)から、緩やかな好み(/packages/uiでは名前付きエクスポートを優先)までを扱います。詳しくはAIコーディングエージェントのルールへ。 - スキル複数ステップの手順書チームが確立してきた手順です。マイグレーションの追加方法、フィーチャーフラグの出荷方法、セキュリティレビューの進め方など。名前で呼び出せます。詳しくはAIコーディングエージェントのスキルへ。
- パス単位の索引ナレッジは、その作業のそばにすべてのメモリ、ルール、スキルはパスに紐づけられます。
/services/billing向けのルールが、モデルが/apps/mobileで作業しているときに発動することはありません。
単一ファイル vs コンテキストレイヤー
- 標準の指示ファイルも、パスで範囲を絞り、バージョン管理で共有できます。
- トークンのコストは、チームのルールに比例して増えます。
- 1つのファイルに1つのアシスタント。ツールを替えるたびにチームのナレッジが失われます。
- push権限があれば誰でも編集でき、構造化されたレビューはありません。
- ナレッジは暗黙知として口伝えで受け継がれます。
- モデルが作業しているディレクトリに絞った一部分。
- トークンのコストは、ルール全体ではなく、関係する部分に応じて決まります。
- 1つのレイヤーに多くのアシスタント。ツールを替えても、チームはリセットされません。
- レビューできるナレッジグラフ。ワークスペースへのアクセスはサーバー側で強制され、古いルールの検出機能もあります。
- ナレッジは一度書けば、次のチームメイトのセッションに自動で届きます。
対応するAIコーディングアシスタント
よくある質問
AIコーディングのコンテキストレイヤーとは何ですか?
チームの型を持つナレッジ(メモリ、ルール、スキル)と、チームが使うAIコーディングアシスタントとのあいだにある、ルーティングのレイヤーです。ナレッジをパスごとに索引化し、関係する部分だけを、フックの時点で、最初のツール呼び出しより前にモデルへ届けます。
コンテキストレイヤーは、CLAUDE.mdやAGENTS.mdとどう違うのですか?
CLAUDE.mdとAGENTS.mdはフラットなファイルで、毎ターンすべての指示を送ります。コンテキストレイヤーはその一段上にあります。ナレッジをパスで索引化したグラフに保存し、一致するサブツリーだけをモデルに送るので、モデルが目にする指示はどれも、現在のパスで実際に意味を持つものです。
コンテキストレイヤーはAIコーディングツールですか?
いいえ。コンテキストレイヤーは、コードを生成せず、推論も実行せず、IDEの代わりにもなりません。チームと、選んだAIコーディングアシスタントとのあいだにあるレイヤーで、チームをひとつのツールに縛ることなく、各セッションを賢くします。
コンテキストレイヤーは何を運ぶのですか?
型を持つチームのナレッジを3種類運びます。メモリ(学んだこと)、ルール(やるべきこと、避けるべきこと)、スキル(複数ステップの手順書)です。ソースコードやリポジトリのインデックスは運びません。
PathruleはAIコーディングのコンテキストレイヤーをどう実装していますか?
Pathruleはチームのナレッジをパスで索引化したグラフに保存し、ひとつのMCPサーバーを公開して、各エージェントが許す方法で届けます。Claude CodeとCodexにはプロンプトフックを含むフック、CursorとGitHub Copilotにはセッションとツールのフック、Windsurfにはルールファイルです。モデルに届くのは、現在の作業ディレクトリに一致する部分だけです。
コンテキストレイヤーはソースコードを見ますか?
見る必要はありません。Pathruleは、リポジトリのソースコードを自動でアップロードしません。クラウドモードでは、Pathrule Cloudがチームの書いたメモリ、ルール、スキルを保存し、各プロンプトの冒頭部分が、当てはまるものの順位づけのために送信されます。またpathrule snapshotは、あなたかエージェントが実行したときに、ファイルツリー、マニフェスト、短いドキュメントのサンプル、最近のgitメタデータをアップロードします。ローカルモードにはアカウントがありません。詳しい内訳はセキュリティのページにあります。
どのコンテキストツールを選ぶべきですか?
実際に抱えている問題によります。1人が1つのリポジトリで1つのエージェントを動かすなら、チェックインしたCLAUDE.mdで十分です。自分の製品の中のメモリならメモリAPI。書かれてはいるが見つけにくいナレッジならベクトル検索。分離したチェックアウトで並行するエージェントなら、エージェントワークスペース。パス単位のコンテキストレイヤーは、2つ目のエンジンか2人目の人が加わったときのためのもので、たいていの人にとって、それは2つ目のエンジンです。5つのアプローチと、それぞれが破綻するところは、上にまとめています。
コンテキストレイヤーとメモリAPIの違いは何ですか?
届くタイミングです。メモリAPIは問い合わせられたときに答えるため、エージェントが尋ねようと思わなかった制約は決して届きません。コンテキストレイヤーは、エージェントがこれから作業するパスを読み取り、一致するナレッジを最初のツール呼び出しより前に届けます。エージェントが尋ねたかどうかには関係ありません。
ベクトルRAGはコンテキストレイヤーですか?
いいえ。ベクトル検索は、すでに書かれているテキストを、クエリとの類似度で順位づけして見つけます。コンテキストレイヤーは、どのファイルにも書かれていない決定を、それが管理するパスに結びつけて運び、強制することもできます。ストアが返すのはテキストですが、ルールはスコープ、優先度、強制レベルを持ちます。類似度は関連性についての推測であり、パスは関連性についての事実です。詳しくはベクトルRAGとパス単位のコンテキストへ。
1人で作業するなら、コンテキストレイヤーは必要ですか?
1人かどうかは、実はあまり問題ではありません。問題は、いくつのエージェントを動かすかです。1人で1つのエージェントを使い、規約が1ページに収まるなら、まさに指示ファイルの得意分野です。同じリポジトリでClaude Code、Codex、Cursorを動かす1人は、すでにコンテキストレイヤーが解決する問題を抱えています。ひとつに教えたことはその中にとどまり、それぞれが別のファイルを読むからです。そのためPathruleは個人での利用は無料です。