ナレッジが積み重なる仕組み

Pathruleは、メモリ、ルール、スキルを手作業で整理しておく場所だと受け取られがちです。しかし、それはごく一部にすぎません。本質は、実際の作業に沿って回り、チームが使うほど良くなっていくループにあります。

ループは、配信、蓄積、スコアリングの3つの動きで構成されます。これがセッションごとに繰り返されます。

作業の前に届ける

アシスタントが動き始める前に、チームのナレッジのうちパス単位で絞り込まれた部分が、すでにコンテキストに入っています。自分で貼り付ける必要はなく、アシスタントが探しに行く必要もありません。/apps/api/paymentsで作業すれば、そこに固定されたものと、上位のパスから継承したものが提示されます。Claude CodeとCodexでは、プロンプトフックが最初のツール呼び出しの前に渡します。CursorとGitHub Copilotにはセッションフックとツールフックを通じて、WindsurfにはルールファイルとMCPを通じて届きます。多くの人が最初に目にするのはこの配信の側面で、詳しくはフックの仕組みで説明しています。

作業中に蓄積する

ナレッジを書くために別の時間を取る必要はありません。ほとんどは作業そのものから蓄積されていきます。

アシスタントは作業しながら、残しておく価値のあるものに目を配ります。たとえば、いま下した判断、何度もぶつかっていた問題の解決策、教えられて初めて知った規約、時間を無駄にした落とし穴などです。見つけると、それを該当するパスのメモリ、ルール、スキルとして保存するよう提案し、Pathruleの書き込みツールで保存します。何かを直接保存するよう頼むこともできます。

ここで重要な性質が2つあります。

• すべての書き込みを確認でき、取り消せます。 アシスタントによる書き込みはアシスタントのものとして記録され、バージョン管理され、元に戻せます。Pathruleが自らナレッジを編集したり削除したりすることはありません。古くなったナレッジや矛盾するナレッジは、あなたやエージェントが解決するためのリフレッシュタスクとして提起されます。
• メンテナンスの手間はほぼゼロです。 蓄積は通常の作業に組み込まれているため、ドキュメントを書くという別の仕事を抱えずにナレッジベースが育っていきます。もちろん、必要なときにはCLI、VS Code拡張機能、MCPクライアントから直接作成することもできます。

自動で書き込まれるものと、人の確認を待つもの

一部の書き込みは確認ステップなしで行われます。不意を突かれることがないよう、ここですべて挙げておきます。

• アシスタント自身の書き込み。 アシスタントは通常、まず提案し、あなたが同意してから保存します。Pathrule側でこれらの書き込みの前に独自の確認ステップを設けることはありません。その代わり、一つひとつの書き込みを可視化し、元に戻せるようにしています。
• 作業の記録。 何が配信されたか、アシスタントが何を参照したか、そのターンがどう進んだかは、優先度付けに使われるため、作業の進行とともに記録されます。Pathruleが計算するものを参照してください。
• Cloudワークスペースでの一度きりの初期データ。 エージェントが初めて詳細なコンテキストを求めたとき、Pathruleは直近のgit履歴から読み取ったファイルパスのペア（一緒に変更されるファイルの出発点）と、ファイル名から識別した短い技術メモリをいくつか、ワークスペースのルートに保存します。この処理でファイルの内容、差分、コミットメッセージを読むことはありません。
• プロジェクト学習。 エージェントがコードを読んでたどり着いた知見は、その根拠となるファイルとともに保存され、レビューを経ずにワークスペース内のすべてのエージェントに共有されます。知見はルールとしてではなく、検証すべき助言として届きます。また、届くのはそのチェックアウトで根拠となるファイルが変更されていない間だけです。誤りだとわかった知見は、全員に対して一度に撤回できます。プロジェクト学習を参照してください。

それ以外で、人が書いたものではなく推論されたものは、すべて人の確認を待ちます。

• プロジェクトスキャンは、プロジェクトにPathruleをセットアップするよう頼んだときにエージェントが実行するもので、メモリ、ルール、スキルを提案します。書き込まれるのは、あなたが承認したものだけです。
• Team Intelligenceは、Pathrule Cloud上でチームのエビデンスをパターンの提案にまとめます。エージェントに届くのは、人が検証したエントリだけです。
• 古くなったナレッジ、矛盾するナレッジ、重複するナレッジの修正は、あなた、またはあなたが依頼したエージェントがリフレッシュタスクを解決するまで、何も変更しません。

スコアリングで、最良のものを先に

関連する候補のうち、どれをリクエストに提示し、どの順序で並べるかは優先度付けで決まります。Cloudモードでは、似た作業で実際に役立ったナレッジもPathruleが追跡し、以降の結果の並び順に反映するため、最も価値の高いものが先に提示されます。セッションはノイズに埋もれず的確なまま保たれ、エージェントが古いと判断したエントリはレビュー用のリフレッシュタスクとしてフラグを立てられます。仕組みについては提案とセルフ監査を参照してください。

学習によって変わるのは順序であり、対象になるかどうかではありません。エントリは引き続き、現在のリクエストに関連している必要があります。複数のマイグレーションで役立ったメモリであっても、実績があるというだけで、無関係な設計のターンに入り込むことはありません。

ノイズをプロンプトに入れない仕組み

このループは、意図的に選別するように作られています。一般的なドキュメントは、デフォルトでは有効な指示として取り込まれるのではなく、レビュー対象として提示されます。推論されたナレッジは人の確認を待ち、すべての書き込みは可視化され、元に戻せます。パススコープによってエントリが提示される範囲が限定され、その範囲の中でもリクエストとの関連性が引き続き問われます。

そのうえで、配信と利用が計測されます。エージェントが古い、コードと矛盾している、重複していると判断したナレッジは、リフレッシュタスクとしてレビューに回されます。修正はバージョン管理され、元に戻せるため、チームは履歴を失うことなくナレッジを改善できます。

その結果として残るのは、リポジトリ全体のドキュメントの寄せ集めではなく、範囲を絞った、レビュー可能な判断や落とし穴の小さな集まりです。各ゲートについてはPathruleが強い主張を裏付ける仕組みで説明しています。

ループこそがプロダクトである理由

配信だけなら、静的なファイルや単一ツールに組み込まれたメモリでもできます。積み重なっていくのはループです。タスクをこなすたびにチームが少しずつ賢くなり、次のセッションはそこから始まります。

この積み重ねは抽象的なものではありません。ループを1周するごとに、次の周で使えるものが残ります。何が配信され、そのターンがどう進んだかの計測された記録、作業の種類ごとに何が役立つかのエビデンス、繰り返し同時に変更される2つのファイルの関係、パスに紐づいた失敗などです。Pathruleが計算するものでは、こうした各レイヤーと、それぞれの入力となるものを一覧にしています。書かれたエントリだけでは積み重なりません。作業がうまくいってもいかなくても、エントリ自体は何も変わらないからです。

ナレッジは特定のエージェントの外にあるため、持ち運べます。同じメモリ、ルール、スキルが、CLIやVS Code拡張機能を通じてClaude Code、Codex、Cursor、GitHub Copilot、Windsurfに届き、ローカルのMCPやRemote MCPを通じてあらゆるMCPクライアントに届きます。1つのツールに組み込まれたネイティブのメモリ機能では、これを置き換えられません。そのメモリはそのツールの中にとどまるからです。長く価値を持つのは、個々のルールやプロンプトファイルではなく、蓄積されたチームのナレッジです。