Clash ルールセット（Rule Provider）使い方ガイド

この記事は Clash 公式サイトが編集・監修しました。ルールベースの振り分けは Clash の核心機能です。ローカルサイトへの直接接続、リモートサービスへのプロキシ経由、広告ドメインのブロックはすべて、個々のルールとその背後にあるドメイン/IP リストに依存しています。何千ものルールを設定ファイルに直接書き込むと、肥大化してメンテナンスが困難になり、更新のたびに手動でマージする必要があります。Rule Provider（ルールセットプロバイダー）の登場により、ルールをノードのサブスクリプションと同様にオンラインで更新・モジュール管理できるようになりました。本記事では、ルールセットの仕組みを理解し、Mihomo / Clash Meta での実践的な設定方法を習得することを目指します。

ルールとルールセットの違い

単一ルールは DOMAIN-SUFFIX,google.com,PROXY や GEOSITE,cn,DIRECT のような形式で、「このタイプのターゲットに遭遇したときにどう処理するか」をコアに伝えます。ルールセットはルールのコレクションファイルであり、通常はコミュニティやプロキシサービスがカテゴリ別（「ローカルドメイン」「広告ブロック」「ストリーミング」など）に分割してメンテナンスしています。

Rule Provider はリモート URL またはローカルパスからこれらのコレクションを読み込み、設定した更新周期で自動同期します。設定ファイルではプロバイダー名を参照するだけで、rules セクションで RULE-SET タイプを通じて呼び出すことができ、メンテナンスコストが大幅に削減されます。

Rule Provider は「ルール版のサブスクリプションリンク」と考えると分かりやすいでしょう。コンテンツは独立して更新され、メイン設定はシンプルなままです。

behavior タイプ：domain・ipcidr・classical

各ルールセットは behavior を宣言する必要があり、ファイルの内容とマッチング方法が決まります：

domain：純粋なドメインリスト。マッチング時に DOMAIN / DOMAIN-SUFFIX ルールに変換されます。サイト振り分けに適しています。
ipcidr：IP レンジのリスト。GEOIP 以外の精細な IP 振り分けやブラックリストに使用します。
classical：完全なルール行を含み、複数のルールタイプを含めることができます。最も柔軟ですが、ファイルサイズも最大です。

日常のサブスクリプションでは、geosite 系のコレクションは多くの場合 domain behavior、geoip 系は ipcidr です。誤った behavior を選ぶとルールが読み込めなかったりマッチングに異常が生じたりするため、ルールセット作者の指定に合わせる必要があります。

Rule Provider の実践設定

YAML 設定では、rule-providers セクションでプロバイダーを定義し、rules セクションで参照します。以下の例は、オープンソースコミュニティのルールセットを取り込む典型的な書き方を示しています：

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400

  direct:
    type: http
    behavior: domain
    url: "https://example.com/rules/direct.txt"
    path: ./ruleset/direct.yaml
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,direct,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,cn,DIRECT
  - MATCH,PROXY

type: http はリモート取得を意味し、path はローカルキャッシュパス、interval は自動更新間隔（秒）です。type: file を使えばローカル専用のルールセットを参照することもでき、カスタムの小さなリストに適しています。

プロバイダーのサブスクリプションルールとの関係

多くのプロキシサービスが提供する Clash 専用サブスクリプションには、完全な rules と rule-providers がすでに組み込まれており、インポートすればすぐに使用できます。独自の Rule Provider を追加する場面としては、広告ブロックリストの追加、イントラネットの直接接続リスト、コミュニティがメンテナンスするストリーミング振り分けルールなどがあります。

マージ時はルールは上から下へ順番にマッチングされ、先にマッチしたものが有効になることに注意してください。通常は REJECT（広告・悪意あるサイト）を最初に、次に DIRECT（ローカル・イントラネット）、最後に MATCH でプロキシに送るキャッチオールという順序にします。順序を誤るとローカルトラフィックが最後の MATCH によってプロキシに送られ、アクセスが遅くなることがあります。

メンテナンスのヒント

信頼できる出所のルールセット URL のみを参照し、悪意のあるルールによるトラフィックハイジャックを避けてください。
ルールセットの数を制限してください。リモート取得が多すぎると起動と更新に時間がかかります。
サブスクリプション更新後にルールに異常が生じた場合は、クライアントのログで RULE-SET が正常に読み込まれているか確認してください。
多くの GUI クライアントは「外部リソースの更新」をサポートしており、手動でルールセットの更新をトリガーできます。

よくある問題

ルールセットの更新が失敗する：URL にプロキシ経由のアクセスが必要かどうか確認してください。一部の GitHub Raw リンクはプロキシ取得が必要な場合があり、更新トラフィックをルールに組み込むかミラーサイトに切り替えることを検討してください。

ルールが適用されない：rules に対応する RULE-SET,名前,ポリシー エントリが追加されており、名前が rule-providers のキー名と一致しているか確認してください。

GEOSITE との重複：組み込みの geosite.dat と外部の RULE-SET は共存できますが、重複マッチングによるパフォーマンス低下を防ぐため順序に注意してください。

まとめ

Rule Provider によって Clash のルール管理は「手動の積み上げ」から「モジュール式サブスクリプション」へと進化しました。behavior タイプ・参照順序・更新メカニズムを把握すれば、ローカル直接接続・広告フィルタリング・専用回線振り分けを自由に組み合わせることができ、何千ものルールを手動で編集する必要はなくなります。

クライアントと設定テンプレートが必要な方は公式ダウンロードページから Mihomo コアと GUI クライアントを入手し、セットアップガイドを参照して初回サブスクリプションのインポートを完了させてください。

関連記事