Pathrule誰がどの領域の窓口か
チームメンバープロフィールは、各メンバーが携わる領域を根拠に基づいて示し、本人が自分で書く判断範囲を宣言として持ち、すべてのエージェントが最初に読む内容に短いチームブロックとしてコンパイルされます。これによりアシスタントは、本人に代わって判断するのではなく、適切な同僚を案内できるようになります。
このページの内容
コードベースを把握しているアシスタントでも、ひとつ大きな間違いを犯すことがあります。自分が決めるべきではないことを決めてしまうのです。公開フィールドの名前を変える、料金ルールを変更する、モジュールの構成を組み替える。チームの中にその領域の窓口となる人がいて、聞けば一言で答えてくれたはずだとは知らないまま、それを行ってしまいます。
チームメンバープロフィールは、このギャップを埋めるものです。組織の各メンバーには「誰がどの領域の窓口か」という1つの問いに答えるプロフィールが用意され、その答えを短くまとめたものが、すべてのエージェントが最初のツール呼び出しより前に読む内容にコンパイルされます。
プロフィールはリポジトリではなくチームに属する
プロフィールは組織単位で、ワークスペースには依存しません。決済の窓口である人は、作業がAPIのリポジトリで行われても、モバイルアプリで行われても、先月まで存在しなかったサービスで行われても、決済の窓口です。1つのワークスペースに結びつけてしまうと、同じ事実をリポジトリごとに登録し直すことになり、そうやって名簿は古くなっていきます。
2つの部分と、推測されるのはその片方だけ
プロフィールには導き出される部分と宣言される部分があり、この分け方は意図的なものです。
導き出される部分: 実際に携わっている領域。 Pathruleは作業ごとに短いエントリをすでに記録しており、どのパスで誰がどのメモリとルールを作成したかもすでに把握しています。パスに対して記録された作業と、そのパスで作成されたナレッジ、この2つの件数が根拠です。それ以外は一切読みません。コードも、コミットメッセージも、作業にかかった時間も読みません。集計期間はローリングなので、離れた領域は何年もついて回ることなく、プロフィールから自然に消えていきます。
宣言される部分: 判断範囲。 こちらは本人が入力するもので、導き出されることはありません。プロダクト上の決定権はファイルに触れたことから生じるものではなく、活動の件数からそれを推測するシステムは事実をでっち上げることになります。先月いちばん多く課金コードに触れた人が、料金ルールを決めるべき人からいちばん遠い、ということもありえます。だからPathruleは推測せずに本人に尋ねます。
表示名、代名詞、対応可能な状況についても同じルールです。自分の言葉で、自分の行に書きます。
自分のプロフィールは自分で確認し、修正できる
エージェントが自分やチームについて何を伝えられているかは、そのまま読むことができます。チームブロックは、PathruleがクライアントごとにCLAUDE.mdやAGENTS.mdなどとして書き出す指示ファイルの末尾にあるTeamセクションです。
導き出されたリストが最終的な答えではありません。本人が自分で領域やタグのリストを書いた場合は、導き出されたリストよりもそちらが優先されます。そのリストが存在すること自体が、答えが推測ではなく修正済みであることの印になるため、次の導出で黙って上書きされることはありません。
この境界を強制するのはインターフェースではなくデータベースです。本人が書けるのは自分のプロフィールの行だけで、他の人の行には書けません。
エージェントが実際に受け取るもの
受け取るのはプロフィールのテーブルではありません。エージェントが最初に読む指示ファイルに追記される短いブロックで、内容はおおむね次のとおりです。
- チーム名、そのファイルの持ち主と、その人自身の領域をいくつか
- 数人の同僚と、それぞれが窓口となっている領域を1つずつ
- 宣言された判断範囲（短いリストに限定）
- 1つの指示: ユーザーを名前で呼び、判断が他の人の領域に関わる場合は、本人に代わって判断するのではなくその領域の担当者を案内すること
この最後の行こそが、機能全体の要点です。指示のない名前の羅列は、エージェントが読み飛ばすデータにすぎません。そのため、他の何よりも先に指示の分が確保されます。そして、指示だけがあって案内できる相手が誰もいないブロックになってしまう場合は、ノイズとして出力するのではなく、ブロックを丸ごと省きます。
ブロックに書けないこと
ブロックが受け付けるのは、名前、パス、タグ、宣言された範囲だけです。成果、速さ、品質、経験年数についての記述を入れるフィールドはなく、自由記述は長さが制限され、1行にまとめられます。これはレビューの指針ではなく構造上の仕組みです。そうした文を載せる場所がそもそもないため、コンパイル済みの指示ファイルのここに、同僚についての意見が一段落分紛れ込むことはありえません。
また、ブロックは意図的に小さくしてあり、見出しを含めて小さな固定予算に収まります。予算を超える内容がある場合は、文の途中で切るのではなく価値の低い側から行単位で削るため、削られたブロックでもエージェントが行動に移せる内容として読めます。ブロックは1ファイルにつき1つだけで、2つ目が追加されることはありません。
コンパイル済みファイルに載せる理由
Pathruleがエージェントに届く経路は2つあります。セッションの開始時に一度読まれるコンパイル済みの指示ファイルと、Claude CodeとCodexでプロンプトのたびにモデルに届くターンごとのフックです。リクエストに応じて変わる内容にはフックが適しています。このブロックはリクエストによって変わらないので、長いセッションのプロンプトごとにコストを払うのは、変わらない1つの事実に何度も払うことになります。
ファイルの最末尾に置かれるのも、関連した理由からです。キャッシュされた指示のプレフィックスは、最初に変更されたバイト以降が無効になります。そしてチームのメンバー構成は、ワークスペースのナレッジよりもはるかに頻繁に変わります。変わりやすいブロックを最後に置いておけば、誰かが加わってもその上にある内容はすべてバイト単位で同一のまま保たれます。
同意
公開範囲は個人ごとに設定でき、デフォルトではチームに公開されます。非公開に設定されたプロフィールは、コンパイル済みのブロックを含むチーム向けのあらゆる読み取りから除外されるため、チームのどのエージェントにも、その人がどの領域の窓口かは伝えられません。この設定はプロフィールと同じ行に保存され、データベースがすべてのクエリに適用します。そのため、どこかの画面がフィルターをかけ忘れたせいで非公開のプロフィールが漏れる、ということは起こりません。
次に読むもの
- ロールと権限：ワークスペースで誰が何を読み、変更できるか。
- フックの仕組み：もう一方のチャネル、つまりプロンプトごとに変わる内容を運ぶ経路について。
- AIセッションが記録するもの：導き出される部分の集計元となる活動エントリについて。