Palo Alto Networks のファイアウォール（PAN-OS）には、ルールごとに「優先度」の数値を付ける仕組みはなく、セキュリティポリシーは一覧の上から順に評価され、最初に一致したルールだけが適用されます。つまり優先度の設定とは、ルールの並び順を正しく設計して動かすことです。この記事では、評価の仕組み、並べ方の原則、Web 画面と CLI での移動方法、変更後の確認までを順に説明します。運用全般（更新・バックアップ・ログ転送）は別記事で扱い、ここではルール順序に絞ります。
セキュリティポリシーの評価順を理解する
PAN-OS はセッションの最初のパケットを受け取ると、送信元ゾーン・宛先ゾーン・送信元/宛先アドレス・ユーザー・アプリケーション・サービス（ポート）などの条件でルールベースを上から照合し、最初に一致したルールの動作（許可・拒否など）を適用して照合を終えます。下にもっと具体的なルールがあっても、上の広いルールに一致した時点でそれが使われます。
一覧の最下部には、既定のルールとして次の2つがあります。
- intrazone-default：同じゾーン内の通信を許可
- interzone-default：異なるゾーン間の通信を拒否
この2つは既定ではログを記録しない設定になっていることが多く、「どのルールにも一致せず拒否された通信」が見えない原因になります。既定ルールの設定を上書きしてログを有効にしておくと、順序の誤りに気付きやすくなります（設定方法はバージョンにより画面が異なるため、管理画面のヘルプで確認してください）。
NAT ポリシーとの関係
順序で混乱しやすいのが NAT です。NAT ポリシーも上から最初に一致したものが使われる点は同じですが、セキュリティポリシーの照合では「NAT 前のIPアドレス」と「NAT 後のゾーン」を使います。たとえば外部から公開サーバーへの宛先 NAT では、セキュリティルールの宛先アドレスにはグローバル側（変換前）のアドレスを、宛先ゾーンには変換後のサーバーが属するゾーンを指定します。ここを取り違えると、ルールを上に移動しても一致しないため、順序の問題と誤解しやすくなります。
Panorama で管理している場合
Panorama からポリシーを配布している場合は、評価順にもう一段の階層があります。おおまかには、Panorama のプレルール（共有 → デバイスグループの上位から下位）、ファイアウォール本体のローカルルール、Panorama のポストルール（デバイスグループの下位から上位 → 共有）、最後に既定ルールの順です。プレルールに広い許可を置くと、現場でローカルに追加したルールが効かなくなるため、全社共通の拒否や必須の許可だけをプレルールに置くのが一般的です。
並べ方の原則
順序を決めるときは、次の考え方で上から並べます。
- 明示的な拒否（ブロックリスト）を上に置く：既知の不正な送信元、外部への利用禁止アプリなど、例外なく止めたい通信
- 具体的なルールを、広いルールより上に置く：特定のサーバーや特定ユーザー向けの許可は、ゾーン全体向けの許可より上
- 利用頻度の高いルールを、意味が変わらない範囲で上に寄せる：照合の効率と見通しのため。ただし安全性より優先しない
- 最後に明示的な拒否ルールを置いてログを取る：既定ルールの前に「any → any 拒否・ログ有効」を置く運用もよく使われます
「具体的なものを上に」が守られていないと、下のルールが一度も使われない「シャドウ（隠れた）ルール」が生まれます。たとえば次の並びでは、2番目のルールに一致する通信はありません。
1. trust → untrust 送信元:any アプリ:any 動作:allow
2. trust → untrust 送信元:10.0.5.0/24 アプリ:bittorrent 動作:deny2番目を1番目より上に移動すると、意図どおり特定のセグメントからのアプリだけが拒否されます。PAN-OS はコミット時にシャドウになっているルールを警告として表示するため、警告を読み飛ばさないことが大切です。
Web 画面でルールを移動する
管理画面では、セキュリティポリシーの一覧（Policies → Security）で対象ルールを選び、移動の操作から「最上部へ」「上へ」「下へ」「最下部へ」などを選ぶか、ドラッグで並べ替えます。ボタンの表記や配置はバージョンによって異なるため、目的の操作が見当たらないときは画面のヘルプを参照してください（2026年10月現在）。
作業の流れは次のとおりです。
- 変更前に、現在の設定を名前付きのスナップショットとして保存する（問題があればそこから戻せるようにする）
- ルールを移動する
- 「検証（Validate）」でエラーやシャドウの警告を確認する
- コミット時に変更内容の説明を入力し、コミットする
- 後述の方法で、実際の通信が意図したルールに一致しているか確認する
CLI でルールを移動する
台数が多い場合や手順を記録に残したい場合は CLI が便利です。設定モードで move を使います。ルール名は環境に合わせて置き換えてください。
> configure
# move rulebase security rules "deny-p2p-lab" before "allow-trust-to-internet"
# move rulebase security rules "block-known-bad" top
# validate full
# commit description "deny-p2p-labを広い許可ルールの上へ移動"top／bottom／before／after を使い分けると、一覧上の位置を正確に指定できます。マルチ vsys 環境では対象の vsys を選んでから操作します。
変更後に一致するルールを確認する
並べ替えた結果が正しいかは、実通信を流す前に test security-policy-match で確認できます。条件を指定すると、どのルールに一致するかが表示されます。
> test security-policy-match from trust to untrust source 10.0.5.20 destination 198.51.100.10 protocol 6 destination-port 443 application sslアプリケーションの指定を変えると結果が変わることがあります。App-ID はセッションの最初の数パケットを見てからアプリを特定するため、アプリ条件付きのルールは「ポートだけで判断できる段階」と「アプリが特定された段階」で一致するルールが変わる場合があります。アプリ条件を使うルールでは、サービスを application-default にして、そのアプリの標準ポート以外では一致しないようにしておくと、順序による想定外の一致を減らせます。
運用中の確認には、ルールごとのヒット数（Hit Count）と、トラフィックログの「ルール」列を使います。一定期間ヒット数が増えない許可ルールは、上のルールに隠れているか、不要になっている可能性があります。Policy Optimizer の機能（バージョンにより名称や画面が異なります）を使うと、未使用ルールやアプリ指定のないルールの洗い出しに役立ちます。
よくあるつまずき
- ルールを上げても一致しない：ゾーンの指定（特に NAT 後のゾーン）や、アドレスオブジェクトの中身を確認する
- 既存セッションに反映されない：ルール変更は新しいセッションから効くことが多い。既存セッションを確認・クリアする場合は影響範囲を確認してから行う
- Panorama の配布後にローカルの変更が効かない：プレルールに一致していないか、評価順の階層を確認する
- QoS の優先度と混同している：帯域の優先制御は QoS ポリシーとプロファイルのクラスで設定するもので、セキュリティポリシーの順序とは別の仕組み
まとめ
- PAN-OS のセキュリティポリシーは上から評価され、最初に一致したルールだけが適用される
- 優先度の設定とはルールの並び順の設計。拒否と具体的なルールを上に、広いルールを下に置く
- 既定ルールの前に明示的な拒否とログを置くと、順序の誤りに気付きやすい
- 移動は Web 画面または CLI の
moveで行い、検証の警告（シャドウ）を確認してからコミットする test security-policy-matchとヒット数で、意図したルールに一致しているか確かめる