2026年5月28日移行ガイド読了時間約9分

Clash for Windows 開発終了後の選択肢:設定移行の手順と代替クライアント比較

クライアント開発終了後の実際のリスクと、過度に心配しなくてよい部分を整理し、サブスクリプション・ルール・オーバーライド設定の完全な移行手順を提示。Clash Plus、Clash Verge Rev、FlClashの引き継ぎ能力も比較します。

開発終了が意味すること、意味しないこと

Clash for Windows(コミュニティでは通称CFW)は、開発者がアーカイブ化を発表した後、新バージョンのリリース、脆弱性の修正、新しいコア機能への対応がすべて行われなくなりました。これは明確な事実ですが、「今すぐ使えなくなる」や「設定ファイルがすべて無効になる」といった過剰な解釈をされがちで、いずれも正確ではありません。

まずリスクの範囲を明確にしましょう。開発終了による実際の影響は主に3つです。1つ目は、クライアントに内蔵されたコアのバージョンがアーカイブ時点のものに固定され、その後コア側で追加された新しいプロトコル種別(例えば新しいトランスポート層の難読化方式)やルール構文の拡張には、CFWは対応しないこと。2つ目は、クライアント自体に未修正のインターフェースや接続安定性の問題があっても、今後パッチが提供されないこと。3つ目は、OSがアップグレードされた後(特にWindowsのネットワークスタックの変更時)、旧クライアントとシステムコンポーネントの互換性問題をユーザー自身で回避するしかなく、公式のサポート窓口がないことです。

一方で、心配しなくてよい部分も明確にしておく価値があります。まず、すでに設定済みのサブスクリプションリンク、ルールセット、DNS設定はすべて自分の設定ファイルに保存されており、クライアント本体には依存しません。クライアントを変えることは、すべてを再設定することと同義ではありません。次に、mihomo(Clash Meta)コアは依然として活発にメンテナンスされており、新クライアントに新しいバージョンのmihomoコアが内蔵されていれば、以前遭遇していたプロトコル非対応やルールが効かないといった問題がついでに解決されることもあります。3つ目に、設定ファイルの構文(YAML構造、プロキシグループの書き方、ルールマッチングのロジック)は主要クライアント間で高い互換性があり、移行の核心的な作業量は設定の書き直しではなく、既存ファイルを新クライアントに正しく取り込み、少数のフィールドの差異を確認することです。

注意が必要なケース

設定ファイルに独自のルールやオーバーライドスクリプトを多数手書きしていて、これらの内容がCFW特有のフィールド記法に依存している場合は、移行前に必ず元のファイルをバックアップしてから項目ごとに確認し、旧クライアントを直接削除しないようにしてください。

移行前の準備:バックアップと棚卸し

クライアントの変更に着手する前に、既存の資産を完全にバックアップしておきましょう。この一手間で「移行後にルールが消えていた」という問題の大半を回避できます。

設定ファイルのディレクトリを特定する

CFWの設定ファイルは通常、ユーザーディレクトリ下の.config\clash、またはクライアントのインストールディレクトリ内のprofilesフォルダに保存されており、ファイル名は通常サブスクリプションから生成された文字列に.yamlや.yml拡張子が付いたものです。すべてのサブスクリプションに対応する設定ファイルを見つけて、新しく作った一時フォルダにコピーしてください。
サブスクリプションの元のリンクを記録する

設定ファイルはサブスクリプションを取得した結果生成されたものであり、より確実な移行方法は、旧ファイルをそのまま持ち運ぶのではなく、サブスクリプションリンクから再度設定を生成することです。CFWのサブスクリプション管理画面を開き、各サブスクリプションの元のURLを完全にコピーして、別のテキストファイルに保存してください。
オーバーライドスクリプトを使用しているか確認する

CFWで特定のサブスクリプションにオーバーライドルールやJavaScriptオーバーライドスクリプト(ポートの強制変更、ルールの追加、広告グループのブロックなどに使用)を追加していた場合、この内容はサブスクリプションリンクとともに自動的に移行されません。スクリプト本文を個別にコピーし、新クライアントで設定を貼り直す必要があります。
システムプロキシとTUN設定を確認する

現在使用しているのがシステムプロキシモードかTUNモードか、またmixed-port(混合ポート)やallow-lan(LAN接続の許可)などのフィールドの値をメモしておきましょう。これらは移行後に最も見落とされやすく、しかし正常にネット接続できるかどうかに直結する設定項目です。

設定ファイル移行の具体的な手順

バックアップと棚卸しが完了したら、正式な移行作業は3つのパターンに分かれます。自分の実際の使用習慣に合わせて選んでください。

方法1:サブスクリプションリンクを再取り込みする(推奨)

新クライアントのサブスクリプション管理画面に元のサブスクリプションURLを貼り付け、新クライアント自身に取得・設定生成をさせます。この方法の利点は、設定内容が常にサブスクリプション提供者側で管理される点で、提供者が後にノードリストやルールセットを更新しても、手動で同期する必要がありません。欠点は、旧クライアントで手動修正していた内容(例えば特定のプロキシグループの戦略を調整していた場合)は引き継がれず、再設定が必要になることです。

方法2:ローカルの設定ファイルを直接インポートする

バックアップした.yamlファイルを、新クライアントの「ファイルからインポート」機能で読み込みます。この方法では手動で変更した内容がすべて保持されますが、サブスクリプション提供者側が後で更新した際、新バージョンで現在のファイルを上書きすべきかを自分で判断する必要があります。

# 典型的な Clash / mihomo 設定ファイルのトップレベル構造。移行時にフィールドが新クライアントで認識されるか確認
mixed-port: 7890
allow-lan: true
mode: rule
log-level: info
dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
proxies:
  - name: "サンプルノード"
    type: vmess
    server: example.com
    port: 443
proxy-groups:
  - name: "自動選択"
    type: url-test
    proxies: ["サンプルノード"]
rules:
  - DOMAIN-SUFFIX,example.com,自動選択
  - MATCH,DIRECT

インポート後は重点的に3か所を確認してください。1つ目はproxy-groupsで参照されているノード名がproxiesリストと完全に一致しているか(大文字小文字やスペースの違いもマッチング失敗の原因になります)。2つ目はrules内のポリシーグループ名が存在するか。新クライアントが未定義のグループについてエラーを出す場合、通常これが原因です。3つ目はDNS設定ブロックの記法です。新しいバージョンのコアはnameserver-policyやfake-ip-filterなどのフィールドの解釈が旧コアより厳格な場合があります。

方法3:混合移行

まずサブスクリプションリンクから基本設定を生成し、その後旧設定内のオーバーライドスクリプト本文を新クライアントのオーバーライド機能に個別に貼り付けます。これは多くの長期利用者が実際に採用している方法で、サブスクリプション提供者の継続的なメンテナンスを享受しつつ、自分のカスタム内容も失わずに済みます。

移行後の確認チェックリスト

切り替え完了後は、順に次を確認してください:ノードリストが正常に速度テストできる、プロキシグループの自動選択が有効になっている、指定したドメインが正しいグループを経由している(ルールに設定したドメインで実際にテストする)、DNS解決に異常がない(コマンドラインツールでドメイン解決結果を確認する)。4項目すべて正常であれば旧クライアントをアンインストールしてください。

3つの引き継ぎクライアントの比較

CFWの開発終了後、コミュニティでは徐々にいくつかの定番の引き継ぎ先が形成されました。それぞれ考え方に特徴があり、選択時には以下の観点を自分の実際のニーズと照らし合わせてください。

クライアント	技術的な方向性	インターフェースの特徴	適した利用者
Clash Plus	mihomoコアをベースに、公式が継続的にメンテナンス	CFWの元々の操作感に近く、習得コストが低い	移行後の操作ロジックの変化を最小限にしたい利用者
Clash Verge Rev	Rust製のシェル + mihomoコア、コミュニティによる活発なメンテナンス	軽量で、GUIによるルール編集とサブスクリプション管理を提供	細部をカスタマイズしたい、設定をいじり込みたい利用者
FlClash	クロスプラットフォームシェル、デスクトップとモバイルで統一された体験に対応	シンプルで、複数デバイス間の設定同期の一貫性を重視	複数デバイスを切り替えながら使用する利用者

クライアント

技術的な方向性

インターフェースの特徴

適した利用者

Clash Plus

mihomoコアをベースに、公式が継続的にメンテナンス

CFWの元々の操作感に近く、習得コストが低い

移行後の操作ロジックの変化を最小限にしたい利用者

Clash Verge Rev

Rust製のシェル + mihomoコア、コミュニティによる活発なメンテナンス

軽量で、GUIによるルール編集とサブスクリプション管理を提供

細部をカスタマイズしたい、設定をいじり込みたい利用者

FlClash

クロスプラットフォームシェル、デスクトップとモバイルで統一された体験に対応

シンプルで、複数デバイス間の設定同期の一貫性を重視

複数デバイスを切り替えながら使用する利用者

3つとも共通の基盤はmihomoコアであり、これはプロトコル対応範囲とルール構文の中核機能が一致していることを意味します。実際の差異はインターフェースの操作の深さ、サブスクリプション管理の使いやすさ、追加のGUI設定機能の有無に表れます。以前CFWで最も基本的なサブスクリプション+ルールモードを使っていた場合、どのクライアントに切り替えても機能的な不足感を感じることはほとんどありません。CFWの一部の細かい機能(特定のトラフィック統計表示方式など)に依存していた場合は、小規模なテストで新クライアントが同等の機能を提供しているか確認してから、正式に切り替えることをお勧めします。

選択時の実際的な判断ポイント

頻繁に手動でルールを変更する必要があるか:頻繁にルールを追加・削除する場合は、GUIによるルール編集画面を提供するクライアントを優先し、YAMLファイルを直接編集する際のミスの確率を減らしましょう。
複数デバイスで使用するか:同じ設定をパソコンとスマートフォンで切り替えて使う場合は、設定同期機能がより充実している方式を優先し、サブスクリプションを重複してメンテナンスする作業を減らしましょう。
コアの更新スピードを重視するか:3つとも上流のmihomoの更新に追随しますが、リリースのペースには差があります。新しいプロトコル機能への切迫したニーズがある利用者は、それぞれの更新履歴の頻度に注目してください。

移行完了後に「二度目の落とし穴」を避ける方法

クライアントを変えたからといって万事解決とは限りません。以下は実際の移行で最も見落とされやすく、後になって最も手戻りが多い細部です。

サブスクリプションの更新周期を再確認する。クライアントによってサブスクリプションの自動更新間隔の設定場所が異なります。移行後はサブスクリプションの詳細を再度開き、自動更新周期(通常は時間単位)が想定通りかを確認し、ノード情報が長期間更新されないまま接続失敗の原因が分からなくなる事態を避けましょう。

自動起動とサイレントモードを再度チェックする。これは最も忘れられやすい項目です。旧クライアントで設定した自動起動は新クライアントには引き継がれず、再インストール後にシステムを再起動すると、プロキシが自動的に起動していないことに気づくため、新クライアントのシステム設定で再度チェックを入れる必要があります。

ローカルのオーバーライドスクリプトは一項目ずつテストする。オーバーライドスクリプトにCFW特有のAPIやフィールド名に依存する記法がある場合、新クライアントが解析時にエラーを出さずに黙って無視することがあります。一部のルールをコメントアウトしてから徐々に復元し、どの部分が有効でどの部分が無効かを特定することをお勧めします。

コアのバージョン番号を確認する。移行後、新クライアントで現在使用しているmihomoコアのバージョン番号を確認し、以前遭遇していた問題と照らし合わせることで、コアのアップグレードでついでに解決されたのか、それとも追加の設定が必要なのかを確認できます。

おすすめしない対応

「手間を省く」ために、開発が終了したCFWを今後のリスクを一切気にせず長期間使い続けることはおすすめしません。プロトコルの互換性問題は時間の経過とともに徐々に積み重なり、移行が遅くなるほど、その時点で確認すべき設定の差異は多くなる傾向があります。

総じて、CFWから引き継ぎクライアントへの移行は一度限りの、管理可能な作業量です。核心となる手順は、サブスクリプションリンクとオーバーライドスクリプトのバックアップ、mihomoコアをベースとした新クライアントの選定、ルールとDNSフィールドの項目ごとの確認、そして完了後の確認チェックリストの実施です。順番通りに行えば、これまでの使用習慣と設定ロジックはほぼ無傷のまま維持できます。