メインコンテンツへスキップ
2 つのルールが両方とも同じツール呼び出しにマッチしうるとき、ファイアウォールルール 優先度がどちらが勝つかを決定します。ファイアウォール ポリシーはルールの順序付けられたリストです — エンジンは それらを優先度順に辿り、マッチする最初のもので停止し、その判定を適用します。順序を 正しくすれば、広いガードと狭い例外がクリーンに共存します；間違えれば、広いルールが 切り出すつもりだった例外を飲み込みます。 このページは順序付けのための焦点を絞ったリファレンスです。完全なルール文法については ファイアウォールルールを；ルールが生成できる判定については 判定を参照してください。

​
1. 順序：優先度昇順、最初にマッチしたものが勝つ

ポリシー内で、ルールは priority ASC, id ASC 順に評価されます：
  1. 低い priority が先に実行されます。 priority: 0 のルールは priority: 10 の ものより先にチェックされます。強さスコアではなく、キューの位置として考えてください — 小さい番号が最初の発言権を得ます。
  2. 同点はルール id で解決されます。 同じ priority の 2 つのルールは作成順 （ルール id 昇順）で実行されるため、古いルールが同点を勝ちます。順序が実際に重要な ときは、id の同点解決に頼るのではなく、異なる優先度を使います。
  3. 最初にマッチしたものが勝ちます。 エンジンは条件がすべて成立する最初のルールで 停止し、その判定を適用します。リストのさらに下のルールは、その呼び出しについて 決して参照されません。
  4. マッチなし → デフォルト判定。 何もマッチしなければ、ポリシーの default_verdictが適用 されます — 変更していなければ audit です。
ルールは、すべての宣言された条件が一度に成立するときのみマッチします： サーフェス、 ツール名グロブ、オプションのスキルグロブ、 オプションの引数句、そして egress スコープ （egress ルールのみ）。部分的なマッチはマッチなしであり、評価は次のルールに移ります。

​
2. 具体例 1 つ：特定を広いものの前に

典型的な順序付けの仕事は、狭い allow を広い deny から生き残らせることです。 特定のルールを低い優先度に置き、先に到達されるようにします： 
// Rule A — priority 10: trust this one exact tool.
{ "label": "allow safe shell", "priority": 10,
  "tool_name_glob": "shell.echo", "verdict": "allow" }

// Rule B — priority 20: block the rest of the shell family.
{ "label": "block shell family", "priority": 20,
  "tool_name_glob": "shell.*", "verdict": "deny" }
shell.echo への呼び出しはまず Rule A（priority 10）に当たり、マッチし、許可 されます — エンジンは Rule B に決して到達しません。shell.exec への呼び出しは A を 通り抜け（グロブがマッチしない）、Rule B に当たり、deny されます。 優先度を反転させると、priority 10 の広い shell.* deny が shell.echo をまず捕捉し、 priority 20 のあなたの allow はデッドコードになります。経験則：最も特定を先に、 最も広いものを最後に。
これに id の同点解決に頼らないでください。allow と deny が同じ priority を共有する 場合、勝者は先に作成したルールです — ルールを削除して再作成するとサイレントに反転する 脆い順序付けです。特定のルールに低い priority を与えれば、意図が明示的です。

​
3. 依存する前に順序を検証する

優先度を紙上で推論することは、ポリシーがひと握りを超えるルールを持つとエラーを 起こしやすいです。Test サンドボックスはサンプルのツール呼び出しに対して実エンジンを 実行し、判定だけでなくどのルールが勝ったかを教えます — そのため期待したルールが 実際に発火したことを確認できます：
1

ポリシーの Test タブを開く

コンソールで、ポリシーを開き Test（Developer+）に切り替えます。
2

サンプル呼び出しを送信する

ツール名（とルールが検査するなら引数）を入力して実行します。何もディスパッチ されず、何も永続化されません — ドライランです。
3

マッチしたルールを読む

結果は判定、マッチしたルール（ラベル/id で）、理由を名指しします。狭い ものを期待した場所で広いルールが勝った場合、狭いルールの priority を下げて再 テストします。
完全なサンドボックスについてはルールのテストを、 ルール順序をインプレースで編集することについては ポリシーの管理を参照してください。

​
4. スキル強制が上に乗る

ルール優先度は勝ったルールの判定を決定します — しかしそれが常に最終的な答えとは 限りません。ツール呼び出しが統制されたスキルによって 所有されている場合、スキルの強制モードが、最初のマッチ解決の後に、勝った判定の 上に適用されます：
スキルモード勝った判定への影響
allow変更なし — ルール判定がそのまま。
quarantinedeny 未満のものを pending_approval にエスカレート；既存の deny はそのまま。
blockルール判定に関わらず deny を強制。
そのため quarantine スキルはルールの allow を保留された呼び出しに変えられ、block スキルはどのルールもそのツールを名指ししなくても呼び出しを deny します。隔離は エスカレートするだけです — deny をより柔らかいものに格下げすることは決してありません。 これが、リスクありと自動検出されたスキルが、ルールがどれほど寛容でも、レビューするまで 隔離されたままになる理由です。
スキルモードはルールではないので、priority を持たず、ルールに対して再順序付け できません。それは常に勝った判定が選ばれた後に評価されます。統制されたスキルの モードが許可するつもりだった呼び出しをブロックしている場合、より高い優先度の allow ルールを追加するのではなく、スキル上でそれを修正します — ルールはモードを上書きできません。

​
5. 最初のマッチに乗らないもの

いくつかのメカニズムはルールごとの優先度の辿りの外に位置します — それらを順序付け しようとしないよう、どこに着地するかを知ってください：
上限未満の cap_cost ルールは非マッチとして 扱われるため、それを許可として最初のマッチで勝たせるのではなく、評価が次のルールに 続きます。上限を超えると deny に解決されます。それは到達されただけで低い優先度の ルールをショートサーキットすることは決してありません。
シーケンスルールは時間ウィンドウをまたいだ 呼び出しのチェーンにマッチするため、チェーンを完了する単一の呼び出しの上ではなく、 非同期マッチャによってリアクティブに強制されます。events フィードを点灯させますが、 個別の呼び出しの最初のマッチの辿りを勝ちません。
シャドウモードはどのルールが勝つかを変えません — 最初のマッチ解決の後に、勝った強制判定を audit に格下げします（理由に [shadow] would … を前置）、そのためポリシーがトラフィックを変える前にその影響を 測定できます。

​
6. まとめると

任意のツール呼び出しについて、完全な解決はこうです：
  1. ポリシーを解決する — 呼び出し元キーにアタッチされたもの、またはワークスペース デフォルト。スコープを参照。
  2. priority ASC, id ASC でルールを辿る — 最初にマッチしたものが勝つ；マッチ なし → default_verdict。
  3. スキル強制を適用する — 統制されたスキルのモードが勝った判定の上に乗る （block は deny を強制、quarantine はエスカレート）。
  4. シャドウモードを適用する — オンなら、強制判定を audit に格下げ。
  5. イベントを記録する — 判定、サーフェス、ツール、マッチしたルールが events フィードに着地。
ルールの優先度の編集は、ポリシーにアタッチされたすべてのキーで次の呼び出しから 効力を持ちます — 再デプロイなし、エージェントのコード変更なし。再順序付けの後、ライブ トラフィックがそれに依存する前に新しい勝者を確認するために Test サンドボックスを再実行します。

​
次に進む場所

判定

各勝った判定が実際に何をするか。

グロブ構文

ツール名マッチングがルールが候補かどうかをどう決定するか。

ルールのテスト

ポリシーをドライランし、どのルールが勝つかを見る。

ツール許可リスト

順序付けに最も強く頼るデフォルト deny パターン。
ルールの背後のマッチング言語については、完全な ファイアウォールルールリファレンスを；スキルが上に どう重なるかについては、ファイアウォールスキルと 強制モードを参照してください。