本文へスキップ
Pathrule

コンテキストレイヤー

AIコーディングの
コンテキストレイヤー。

コンテキストレイヤーは、チームのメモリ、ルール、スキルをパスごとに索引化し、チームが使うエージェントに、当てはまる部分だけを最初のツール呼び出しより前に届けます。チームが実践している5つの方法と、どれが合うかの見分け方を紹介します。

「注文に割引を追加して」ひとつのタスク、2つのやり方

コンテキストレイヤーなし

  1. アシスタントは注文モジュールを開き、スキーマを読み、importをたどって価格と税の処理に入り、割引のハンドラーを読んで、クーポンがどこに付くのかを推測します。
  2. 割引を注文の合計に付ける、もっともらしい変更を書きます。差分はコンパイルが通ります。そして、チームがすでに知っているとおりのかたちで間違っています。
  3. レビュアーが気づいて明細行の規約をもう一度説明し、同じことが繰り返されます。ナレッジは1人の頭の中にとどまったままです。
  4. 大量のファイルの読み込み、大量のツール呼び出し、長い入力ウィンドウ、そしてレビュー1回分を無駄にする回り道。

コンテキストレイヤーあり

  1. 注文のパスに一致する部分が、フックの時点で、最初のツール呼び出しより前に届きます。モデルは、クーポンが明細行に付くことをすでに知っています。
  2. 最初の一回で、割引を明細行に適用します。始める前から、そのルールがコンテキストにあったからです。
  3. 強制ルールなら、割引を間違った場所に付ける変更を、反映される前にブロックできます。修正はレビューの後ではなく、前に行われます。
  4. 短く焦点の絞られたコンテキストウィンドウと、狙いを定めた変更。このパスのルールだけが注入されたからです。

エージェントにコンテキストを渡す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権限があれば誰でも編集でき、構造化されたレビューはありません。
  • ナレッジは暗黙知として口伝えで受け継がれます。
AIコーディングのコンテキストレイヤーこのパス向け
  • モデルが作業しているディレクトリに絞った一部分。
  • トークンのコストは、ルール全体ではなく、関係する部分に応じて決まります。
  • 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は個人での利用は無料です。

2つ目のエージェント?
それが、そのときです。