Agent IR
Pathruleが1つのタスクのためにコーディングエージェントへ届けるもの、意図的に含めないもの、メモリが全文またはタイトルで届く仕組み、配信後も拘束力の強さが保たれる仕組み、クライアントごとの配信経路の違いを説明します。
Agent IRは、1つのエージェントが1つのタスクのために受け取るものを指すPathruleの呼称です。Pathruleが把握しているすべてと、1つのエージェントによる1回の実行との境界にあたります。
この境界には意味があります。これはタスクに合わせて選ばれ、クライアント向けに描画されたナレッジであり、プロンプトに検索結果をつなげたものではありません。エージェントが受け取る内容は目の前の作業のために組み立てられたもので、その形は検索がたまたま返した結果ではなく、設計上の判断によって決まっています。
含まれるもの
1つのタスク、1つのスコープに対して、次のものが届きます。
- 該当するルール。ルールとして、専用のセクションに置かれます。
- パスとプロンプトにとって最も重要なメモリは全文で、該当するその他のメモリはタイトルで一覧表示されます。
- 該当するスキル。名前で示されるので、エージェントは必要になったときに手順を読み込めます。
- あなた個人の好み。プロンプトフックを持つクライアントで、ワークスペースの要件を優先する見出しの下に置かれます。User Intelligenceを参照してください。
- エージェントがコードについて記録した知見。検証すべき助言という位置づけで、エージェントが要求したコンテキストの中で届きます。プロジェクトでの学習を参照してください。
- 検証済みのチームのパターン(Pathrule Cloudの場合)。誰も検証していない提案は配信されません。
意図的に含めないもの
実行の質を高めないものはすべて除外します。
管理用のフィールド、エージェントにとって不要な内部識別子、リポジトリの別の部分にスコープされたナレッジは含めません。承認が必要な場面で人が承認していないものも含めません。提案、候補段階の好み、未承認のルール制約は配信されません。
要となる3つの性質
種類が保たれます。 過去の修正は過去の修正として、ルールはルールとして届きます。両方を「これを覚えておいて」にまとめてしまうと、それぞれを役立つものにしていた要素が失われます。
拘束力の強さは平坦化されず、表現として保持されます。 助言は、強いルールの後ろに同じ重みで連結されるのではなく、明確に下位の位置に描画されます。配信の中でどれが要件でどれが提案かが示されているので、受け取ったエージェントは両者を区別できます。Knowledge IRを参照してください。
全文はいつでも1回の読み込みで手に入ります。 プロンプトごとの予算に収まらないメモリは、捨てられるのではなくタイトルで一覧表示され、名前を指定して読めばチームが書いた内容がすべて返ります。
メモリがエージェントに届く経路
メモリがエージェントに届く経路は3つあります。
- プロンプトに対して全文で。 プロンプトフックを持つクライアント(Claude CodeとCodex)では、Pathruleがパスとプロンプトにとって重要なメモリを選んで優先順位を付け、最も関連性の高いものをプロンプトごとの予算内で、エージェントが動き出す前に全文で届けます。同じセッションですでに届けたメモリは再送しません。
- タイトルで。 該当するものの予算に収まらないメモリはタイトルで一覧表示されるので、エージェントはその存在を把握でき、
pathrule_read_memoryでどれでも読めます。 - 指示ファイルの中で。 Pathruleが各クライアント向けにコンパイルするファイルには、ワークスペースのナレッジまたはその索引が、それが適用されるパスに配置されます。そのため、フックを持たないクライアントでもそこから作業を始められます。
名前を指定してメモリを読むことは、配信ではありません。明示的な読み込みは元の内容を求めるリクエストなので、常に全文が返ります。
予算の詳細は全文で届くものと、名前だけで届くもので、選択の仕組みは検索の仕組みで説明しています。
コンパイル済みの配信が適用される範囲
エージェントが求めなくてもどこまで届くかは、クライアントのフックによって決まります。
| クライアント | 自動で届くもの |
|---|---|
| Claude Code、Codex | セッション開始時の指示ファイルに加え、プロンプトフックによるプロンプトごとの配信。 |
| Cursor、GitHub Copilot | 指示ファイルに加え、セッションフックとツールフックからのコンテキスト。プロンプトフックはありません。 |
| Windsurf | 自身のルールファイル。フックはなく、より詳しいコンテキストはMCP経由で届きます。 |
| Remote MCPクライアント | 自動で届くものはありません。エージェントがMCPツールを通じて要求します。 |
Remote MCPはホスト型のツールエンドポイントです。フックをインストールせず、ローカルにファイルも書き込みません。そのため、リモートのクライアントがナレッジを要求することと、エージェントが動くその瞬間にローカルのフックがナレッジを届けることは別物です。どの経路のエージェントでも、pathrule_get_contextでさらに多くを要求できます。
エンジン非依存
何が選ばれるかは、これから動くエージェントの種類に左右されません。同じナレッジが一度だけ描画され、各クライアントはそれぞれのネイティブな仕組み(指示ファイル、フックがあればフック、そしてMCP)を通じて受け取ります。フックの仕組みを参照してください。
これにより、エージェントからの独立は理想ではなく構造として成り立っています。Claude向けの形をしたナレッジもCodex向けの形をしたナレッジも存在せず、あるのはナレッジと、それを運ぶ入れ物だけです。クライアントごとに異なるのは、求められなくてもどれだけ届くかという点で、上の表がそれを明示しています。