Pathruleガードレールとしてのルール
承認済みのブロックパターンを持つPathruleのルールが、規約に反する変更を書き込まれる前に止める仕組みと、それ以外のルールがコンテキストとして添えられる仕組みを説明します。
このページの内容
Pathruleのルールは、アシスタントが後で読むメモではありません。アシスタントが動く前に届くガードレールです。多くのドキュメントは、出荷された後で何がまずかったのかを教えてくれます。ガードレールなら、変更が書き込まれる前に止められます。
このページでは、ターンに情報を与えるコンテキストと、ターンをブロックできるルールの違いを説明します。フックがコンテキストを届ける仕組みについては、先にフックの仕組みをお読みください。このページで扱うのは、そのコンテキストが届いた後に厳格なルールが何をするかです。
プルは問い合わせ、プッシュは届ける
従来のモデルはプルです。アシスタントは何かを編集する前に、規約を問い合わせること、ツールを呼ぶこと、結果を読むことを自分で覚えておく必要があります。忘れれば何も知らないまま編集し、問題はレビューで見つかることになります。
フックのモデルはプッシュです。Claude CodeとCodexでは、プロンプトを送信したとき、そしてアシスタントがツールを使う直前に、アシスタントが求めなくてもコンテキストが届きます。CursorとGitHub Copilotにはプロンプト送信時のフックがないため、セッション開始フックがブートストラップを、ツールフックが操作対象のパスのルールを届けます。いずれの場合も、アシスタントがファイルを書き込もうとする時点で、そのパスに紐づくルールはすでに目の前にあります。Windsurfにはフックがありません。WindsurfはPathruleのルールファイルを読み、追加の情報をローカルのMCPサーバーに問い合わせます。そのためWindsurfでは、ルールは情報を与えるものの、ブロックはしません。
アドバイザリーとブロックの2つのレベル
すべてのルールがアシスタントを止めるべきではありません。Pathruleはルールを2つのレベルで扱います。
- アドバイザリールールはコンテキストとして添えられます。アシスタントが触れようとしているファイルの横に優先度とともに表示され、アシスタントはそれを考慮に入れられます。何かを止めることはありません。ほとんどのルールは、優先度にかかわらずアドバイザリーです。
- 厳格なルールはブロックできます。ルールが厳格になるのは、人が承認したブロックパターンを持つときです。ブロックパターンとは、内容における禁止された形（import、識別子、クラス名、CSS宣言など）、ファイルの禁止された配置場所、またはその両方です。アシスタントがこれに一致する形でファイルを編集または書き込もうとすると、フックはファイルが書き込まれる前にツール呼び出しを止め、理由を返します。アシスタントはそれを読み、今度は制約の範囲内でやり直します。
優先度とブロックは互いに独立しています。優先度（high、medium、low）は、ルールがどれだけ目立って表示されるか、そしてスペースが足りないときにどのルールが残るかを決めます。ブロックするかどうかは決めません。そのパスの厳格なルールは、優先度にかかわらずすべてチェックされます。
ルールが厳格になるまで
アシスタントが単独でブロックパターンを有効にすることはできません。
- ルールはまず平易な言葉で書かれます。書くのはあなた自身か、あなたが依頼したアシスタントです。
- アシスタントは、ルール用のMCPの書き込み・更新ツールを通じて、そのルールのブロックパターンを提案できます。推奨される形式では、禁止するテキストをルールの表記どおりに正確に示し、検出しなければならない実例と、検出してはならないニアミスの例を添えます。Pathruleはそこからパターンを構築し、両方の例でテストします。どちらかが失敗した場合、提案はパターンを緩めるのではなく、理由とともに却下されます。
- 提案はルールとともに保存されますが、適用はされません。
- 人が承認して初めてフックがブロックを始め、その提案用に書かれた対処方法が、アシスタントに表示される「代わりにこうする」の内容になります。
ルールには必須チェックを持たせることもできます。必須チェックとは、ターンが終わる前に成功していなければならない検証コマンドで、たとえばパッケージのテストスイートなどです。ブロックパターンと同様に、提案された段階では適用されず、人が承認するまで有効になりません。承認後は、Claude CodeとCodexでは、そのコマンドが成功するまで、フックが実行すべき正確なコマンドを示してターンを開いたままにします。
アシスタントに表示される内容
ブロックされた編集には、ルール名、ルールの短いプレビュー、承認済みの対処方法、ルール全文への参照が返されます。「No direct database client in UI components」という名前のルールであれば、次のようになります。
Pathrule blocked: "No direct database client in UI components"
UI components never import the database client. Data goes through the data layer hooks.
Do this instead: call the data layer hook for this resource.
Your edit matches this rule's forbidden pattern. Read the full rule via pathrule_read_rule(<id>) and retry without the violation.
Claude Code、Codex、Cursor、GitHub Copilotは、これをそれぞれのクライアント独自のフック形式で、ツール呼び出しの拒否として受け取ります。Windsurfにはフックがないため、何もブロックされません。ブロックが適用されるのはファイルの編集と書き込みです。シェルコマンドには、引き続きルールがコンテキストとして渡されます。
この区別は意図的なものです。影響の小さい編集をブロックしても、アシスタントのターンもあなたの時間も無駄になるだけです。ブロックは、違反が実際のリグレッションになり、何をもって違反とするかを誰かが正確に承認したルールのためにとってあります。
導入前と導入後
コミットされるファイルにシークレットを含めてはならない、というルールを考えてみましょう。このルールには、利用しているプロバイダーのキー形式に対する承認済みのブロックパターンがあるとします。
| ガードレールなし | ガードレールあり | |
|---|---|---|
| アシスタントの意図 | 機能を動かすために設定ファイルにAPIキーを追加する | 同じ |
| 何が起きるか | 編集が書き込まれる | ファイルが書き込まれる前に、一致するツール呼び出しをフックがブロックする |
| いつ気づくか | 後のレビューで（あるいは気づかないまま） | 同じターンのうちに。アシスタントがルールの本文を読み、環境変数を使う方法に切り替える |
| ディスク上の結果 | シークレットがコミットされる | 一致する編集は書き込まれていない |
同じ考え方は、チームが本番環境で痛い目を見て得たどのルールにも当てはまります。ユーザーで絞り込まなければならないデータアクセスポリシー、マイグレーションの規約、自動生成されるため手で編集してはならないファイルなどです。ルールは、アシスタントが読んでくれていることを期待するだけのコメントではなくなり、編集が書き込まれる前に実行されるチェックになります。ブロックパターンが検出するのは承認された形だけなので、レビューを置き換えるものではなく、レビューを補うものです。
ファイル名で適切なメモリを呼び出す
必ずしもツール呼び出しを待つ必要はありません。Claude CodeとCodexでは、紐づけられたメモリの対象となるファイルをプロンプトで名指しすると、アシスタントが何かを開く前に、プロンプトフックがそのメモリの本文を表示できます。作業中のファイル名を挙げるだけで、最初のターンから適切なコンテキストをアシスタントに渡せることがよくあります。同じファイル名に複数のメモリが一致する場合、フックは推測せずに候補を表示します。
設計としてのフェイルオープン
壊れたときにワークフローまで壊すガードレールは、ガードレールがないよりも悪いものです。Pathruleはフェイルオープンです。フックがルールを評価できない場合、エラーが起きた場合、タイムアウトした場合も、作業はブロックされません。変更はそのまま進みます。適用はセーフティネットであり、足止めされるゲートではありません。
主導権は常にあなたにあります。フックを完全にオフにしたいときは、ファイルを1つ置くだけでオフにできます。
自分で確かめる
この挙動を鵜呑みにする必要はありません。
AIクライアントにどのフックが登録されているかは、その設定ファイルを読めばわかります。Claude Codeの場合、Pathruleはプロジェクト内にフックを登録します。
cat .claude/settings.json
Cursorは.cursor/hooks.json、Codexは.codex/hooks.json、GitHub Copilotは.github/hooks/pathrule.jsonを使います。
Pathruleのすべてのフックを即座にオフにする（キルスイッチ）には、ファイルを1つ作成します。
touch ~/.pathrule/kill-hooks
次のツール呼び出しは、Pathruleを一切介さずにそのまま通過します。フックを再びオンにするには、ファイルを削除します。
rm ~/.pathrule/kill-hooks
ルールが実際にパスに紐づいているか確認するには、そのフォルダでpathrule rule listを実行するか、エディタでアシスタントのPathruleコンテキスト表示を開きます。アシスタントがそのパスで動く前にルールが優先度とともに表示され、厳格なルールは、編集が初めて一致したときにそのブロックが表示されます。