Pathruleが強い主張を裏付ける仕組み

Pathruleの技術的な基準はシンプルです。製品としての主張には、範囲が限定された入力、根拠が欠けているときの明確な挙動、そして独立してテストできる結果が必要です。

このページでは、ナレッジがPathruleにどう取り込まれ、どう選ばれ、どう配信されるかについて、その契約をまとめています。Remote MCP接続では配信の境界が異なります。フックをインストールしないため、ナレッジはエージェントがPathruleのツールを呼び出したときに届きます。

ナレッジ品質を支える複数の関門

Pathruleは、すべてのMarkdownファイルをすべてのプロンプトに入れるわけではありません。ナレッジは互いに独立した複数の制御を通過します。

1. 選択的な検出。 エージェントがプロジェクトスキャンを実行すると、有効な指示ファイル、そのインポートチェーン、ツールのルール、意思決定記録が一般的なドキュメントと区別されます。範囲の広いドキュメントは、デフォルトで有効な指示として取り込まれるのではなく、レビュー対象として提示されます。

2. 保存前のレビューと、明示された例外。 推論されたナレッジは人の判断を待ちます。プロジェクトスキャンの候補は承認されたときにだけ追加され、Team Intelligenceの提案は人が確認して初めてエージェントに届きます。古くなったナレッジの修正はリフレッシュタスクが解決されるまで何も変更せず、エージェントがルールに対して提案した実行可能な制約は提案として保存され、人が承認するまで適用されません。アシスタント自身による書き込みはPathruleの書き込みツールを経由し、アシスタントによるものとして記録され、バージョン管理され、元に戻せます。プロジェクトの学習で得た知見はレビューなしで共有されますが、あくまで確認すべき助言としてであり、ルールとして扱われることはありません。確認なしで書き込まれるのは2つだけで、Cloudのワークスペースに限り、エージェントが初めて詳細なコンテキストを求めたときにだけ書き込まれます。最近のgit履歴から読み取った、同時に変更されるファイルを把握する起点となるファイルパスのペアと、ファイル名から認識した、ワークスペースのルートに置かれる短い技術メモリです。どちらについても、ファイルの内容、差分、コミットメッセージは読み取りません。詳しくはナレッジが積み重なる仕組みを参照してください。

3. パスの所有。 エントリは、それを所有するワークスペース内で最も狭いパスに属します。そのパスの外での作業には、同じリポジトリに存在するという理由だけで配信されることはありません。

4. リクエストとの関連性。 エントリは毎回、現在のリクエストに対して対象となる必要があります。対象になるかどうかと並び順は別々に決まり、その役割が入れ替わることはありません。一方はエントリが対象になるかどうかを決め、もう一方はすでに対象となったものの並び順を決めます。学習が影響するのは並び順だけです。実績のあるメモリを4番目から1番目に上げることはできても、対象外のものを配信対象にすることはできません。量にも上限があります。配信はプロンプトごとの上限に収まるため、配信量がナレッジベースの規模に応じて増えることはありません。

   そのため、プロンプトを静かに保つために厳密な書き方が前提になるわけではありません。曖昧なエントリや書き方の悪いエントリがノイズになることはなく、無関係なリクエストではそもそも対象にならないだけです。質の低いメモリの代償として目に見えるのは、それが表示されないことです。

5. 配信と利用の計測。 Pathruleは、何を配信し、アシスタントが何を参照したかを記録します。派生レイヤーは最後にデータを受け取った時刻を報告するため、単に静かなシステムと接続が切れたシステムを見分けられます。

   エントリが配信されなかった理由にも同じ考え方を適用しています。「対象がなかった」「優先順位付けの呼び出しがタイムアウトした」「レスポンスの形式が不正だった」「優先順位を付ける対象がなかった」は、ひとまとめにせず別々の結果として記録します。状況が異なれば対処法も異なるからです。処理が遅れた場合はそのように報告されるため、ナレッジベースが空だと誤解されることはありません。

   関連性はあるものの上限に収まらないナレッジや、本文がまだマシンにないナレッジは、破棄されずにタイトルで提示されます。アシスタントは必要に応じてそれを意図的に取得できます。置かれた場所が都合悪いという理由だけで正しい答えを捨ててしまう、という事態を避けるための設計です。

6. レビュー可能なメンテナンス。 エージェントが古い、コードと矛盾している、重複している、または不明瞭だと判断したナレッジは、リフレッシュタスクとしてレビューに回され、そのタスクが解決されるまで何も変更されません。書き込みはバージョン管理され、競合は明示され、削除は元に戻せます。

これらの関門によって、共有されたナレッジはリポジトリのための小さく検証可能なオペレーティングシステムになります。ドキュメントのアーカイブ全体をデフォルトのコンテキストにすることなく、プロジェクトが意思決定を積み重ねていけるのはそのためです。ナレッジが積み重なる仕組みと提案とセルフ監査も参照してください。

日付を明記した検証

2026年8月23日、Pathrule製品のメインリポジトリで、これらの契約を対象とした自動チェックが成功しました。対象にはナレッジの検出、インポートの順序、ノイズの多いソースの除外などが含まれます。

公開しているコンテキスト配信のベンチマークは、github.com/pathrule/benchmarksで別途再現できます。計測の方法では、その手法、生の成果物、良し悪しの混在した結果を公開しています。計測結果は計測に使った環境についてのものであり、お使いのリポジトリでの結果を保証するものではありません。

評価に役立つルール

Pathruleのどの主張についても、次の3つを問いかけてください。

1. 判断にはどのような根拠が入力されるか。
2. その根拠が欠けていたり曖昧だったりする場合はどうなるか。
3. どの結果が作業を変更または阻止することを許されているか。

上記の契約は、この3つすべてに答えています。それが機能の説明と、エンジニアリングとしての主張との違いです。