計測の方法

Pathruleが掲げる主要な計測上の主張は1つだけです。それは速度やコストについてではなく、プロジェクトですでに分かっていたとおりに作業が仕上がるかどうかについての主張です。

このページでは全体像を示します。その主張を支えるグリッド、私たちが引用する唯一のペイロードの数値、それに付随する否定的な結果、以前の効率ベンチマークとその適用範囲、そしてそれらすべての前提条件です。

主要な結果：コンプライアンス

12タスク、24回の実行、1つのエージェント、固定した1つのモデルで計測しました。各タスクは、同じリポジトリをバイト単位で同一の状態から新しくコピーしたものに対して、同じプロンプトで2回ずつ実行しました。プロンプトにはヒントを一切含めず、スコアリング用のスクリプトはどの実行よりも前に作成して凍結しました。

• Pathruleなし：素の作業コピーです。ナレッジファイルもフックもありません。
• Pathruleあり：実際の本番デリバリー経路を、変更せずにそのまま使います。

各タスクには、有能なエージェントでもファイルからは導き出せない、隠れたプロジェクトの規約を設定しました。たとえば、環境変数へのアクセスは必ずゲートウェイを経由する、設定は返す前にバリデーションを通す、空のリクエストボディはパースの前にガードする、このデータベースは読み取り専用のレプリカである、このパーサーはあのパーサーに取って代わる、といったものです。スコアラーは2つの点を別々に確認しました。変更が動作するか、そして規約に従っているかです。

読み方

問題はエージェントにあるのではありません。 Pathruleなしの実行でも、すべて機能的に正しい実装ができていました。Claudeはどちらの条件でも作業をこなせました。違いが出たのは、ワークスペースですでに分かっていたやり方でその作業をしたかどうかです。

ナレッジの種類が違っても同じ傾向が見られます。 12タスクのうち9タスクで差が出ました。その内訳は、制約、必須のチェック、記憶された修正、コンテキスト上の事実、理由、複合ケース、優先関係と多岐にわたります。最も差がはっきりしたのは記憶された修正の2タスクです。Pathruleなしでは、保存された修正が防ぐはずのインシデントを、エージェントがそのまま再現してしまいました。

3タスクでは差が出ませんでしたが、これは除外せずに報告しています。 この3タスクでは、ナレッジがリポジトリ自体から読み取れました。コメントから好ましいやり方が分かった、エクスポートされた3つのライフサイクル関数から順序が明らかだった、採用されるべき関数の名前が不採用の関数よりもタスクによく合っていた、というものです。どちらの条件でも規約に準拠していました。これらは後退ではなく中立的な結果であり、効果の境界を示しています。Pathruleが結果を変えるのは、ナレッジが本当にコードに含まれていない場合です。コードからすでに読み取れる場合には、コンプライアンスの向上はありません。

ナレッジペイロードの数値

別のライブA/Bテストでは、タスク単位にコンパイルして渡すことで、エージェントが受け取るナレッジのサイズがどう変わるかを計測しました。

ナラティブなメモリでは、タスク単位にコンパイルした形式で同じナレッジをおよそ104から234トークンで表せました。一方、文章の形式では約3,000トークンかかりました。計測上、ナレッジペイロードが13倍から30倍小さくなったということです。

前提条件が2つあり、どちらも欠かせません。

これはナラティブなメモリでの結果です。 もともと1文で書かれた規約であるメモリは、最初からほぼ最小単位になっています。コンパイルしてもほとんど削減にならず、別の実行でまさにそのとおりの結果が出ました（文章では25から70トークン、IRでは15から59トークン）。簡潔な規約に対して13倍から30倍という数値を引用するのは誤りです。

総トークンは減りませんでした。 同じA/Bテストで両条件のエージェントの新規トークン使用量を計測したところ、注入量が13倍小さくなっても使用量は減りませんでした。削減されるのはナレッジペイロードであり、それが効いてくるのは請求額ではなくコンテキストの圧迫に対してです。

そのため、このサイトでの表現は意図的に固定しています。言うのは常にナレッジペイロードであり、総トークンではありません。Pathruleは、エージェントのトークン使用量を何パーセント削減するといった主張はしません。実際に計測したところ、減らなかったからです。

以前のデリバリー効率ベンチマーク

コンプライアンスグリッドより前に計測していたのはデリバリー効率でした。つまり、同じナレッジを1つの指示ファイルに丸ごと入れるのではなくパス単位で渡したときに、コンテキストの負荷がどう変わるかです。このスイートはオープンになっており、github.com/pathrule/benchmarksで実行できます。固定したオープンソースのリポジトリ（Fastify）をチェックアウトし、チーム的なナレッジを投入したうえで、同じ10個のプロンプトを条件ごとに1回ずつ、計2回投げます。スコアリングは機械的に行い、各セルにつき3回実行します。

主要な指標は総フットプリント、つまりモデルが1ターンごとに処理するトークン数で、難易度の高い層での結果は次のとおりです。

この比較が示すもの、示さないもの。 これは同じナレッジベースを渡す2つの方法、つまりすべてを1つのファイルに入れる方法と関連する部分だけを渡す方法の比較です。Pathruleとエージェント単体の作業を比べた計測ではなく、エージェントにかかる総コストについての主張に一般化できるものでもありません。Codexの行は結果がまちまちで、そのまま公開しています。レポートでは、Pathruleのほうがコストが高くなったセルも公開しています。プロンプトキャッシュは静的に丸ごと渡す方式のコストを割り引くため、総フットプリントと並べて、課金対象となる非キャッシュのトークンも示しています。

上のペイロードの結果と合わせて読むと、この2つは一貫したことを示しています。Pathruleが送るナレッジはずっと小さくなりますが、それが全体の使用量をどれだけ動かすかは、セッションで何が大半を占めているかに完全に左右されます。

コードスキャンでは差が埋まらない理由

Pathruleなしの実行は、ツールの不備によるものではありません。エージェントは妥当なことをしました。コードを読み、それをもとに推論したのです。見落としは構造的なものです。必要だった事実はチームの決定であってソースの性質ではなく、ファイルに記録されていない決定は、どれだけスキャンを重ねても浮かび上がりません。

コンプライアンスグリッドが本当に計測しているのはこれです。すでに存在するナレッジを、セッションのたびに再発見するコストです。ナレッジが積み重なる仕組みを参照してください。

数値が意味しないこと

• 保証ではありません。 上で説明した構成で計測した結果です。実際の結果は、タスク、コードベース、チームのナレッジがどれだけ取り込まれているか、使っているエージェントによって変わります。
• タスクに依存します。 開いているファイルにすでに答えがある変更では、コンプライアンスの向上は見られません。見落とすような隠れたものがないからです。
• コードベースに依存します。 効果は、チームのナレッジがどれだけ取り込まれているかに応じて大きくなります。
• モデルとツールに依存します。 エージェントによって、ファイルを読む頻度やツールを呼び出す頻度は異なります。
• 作業に何が届くかを表すものです。 生成されるコードのサイズや品質を表すものではありません。

公開すること、しないこと

計測した内容、条件、前提条件、中立的なセル、そしてPathruleのほうがコストが高くなったセルを公開します。

どのナレッジを提示するかをシステムがどう決めているかは公開しません。内部の仕組みではなく挙動を理解したい場合は、観察できる内容を検索が適切なナレッジを見つける仕組みで、確信が持てないときに何が起きるかを安全性とフォールバックで説明しています。