Clashオープンソース生態系まとめ:オリジナルコア・mihomo・各GUIクライアントの関係と選び方

A-01系譜の出発点:オリジナルのClashコア

今の市場に並ぶ多種多様なClash系クライアントを理解するには、まず系譜の出発点に戻る必要があります。最初のClashはGo言語で書かれたルールベースのプロキシコアで、コマンドラインプログラムとYAML設定ファイルのみを提供し、サブスクリプションの解析、振り分けルールのマッチング、プロキシノードの管理を担っていました。GUIは一切ありません。このコアが生態系全体の基本文法を定めました。proxiesでノードを宣言し、proxy-groupsでポリシーグループを構成し、rulesで振り分け順を定義する——この構成はその後ほぼすべての分岐やクライアントに引き継がれており、これが出所の異なるサブスクリプションリンクが多くのクライアント間で使い回せる理由です。

オリジナルコアの開発は2023年半ば以降停滞し、リポジトリでは長期間新バージョンがリリースされておらず、新しいプロトコルの仕様やルール記法への対応も進んでいません。これは「使えない」ことを意味するわけではなく、多くの古い設定ファイルは今でも問題なく動作しますが、もはやコミュニティ開発のメインラインではなく、新機能・プロトコル対応・セキュリティ修正がこのバージョンに反映されることはないという点は押さえておく必要があります。

A-02分岐と進化:Clash Metaとmihomoの関係

オリジナルコアの開発ペースが落ちた後、コミュニティでは複数の分岐プロジェクトが登場しました。中でも最も影響力が大きかったのがClash Metaです。この分岐はオリジナルをベースに、安定したTUNモード実装、より充実したルール文法(RULE-SETやプロセス単位ルールなど)、Hysteria・TUICといった新しいプロキシプロトコルへの対応を追加し、たちまち多くのGUIクライアントの標準搭載コアとなりました。

Clash Metaはその後、正式にmihomoと名称を変更しました。これは新規プロジェクトとして書き直されたものではなく、同じ開発系譜の継続とブランドの改称です。現在主流のGUIクライアントが標準で組み込んでいるのは、オリジナルのClashコアではなくmihomoコアであることが一般的で、クライアントの設定画面に表示される「コアバージョン」欄が「Clash」ではなくmihomoのバージョン番号になっているのはこのためです。この関係を理解しておくと、クライアントの更新履歴にある「コアをmihomo x.x.xにアップグレード」といった記述の意味がつかみやすくなります。これはクライアントUI自体の変更ではなく、内部エンジンの更新を指しています。

言い換えれば、mihomoは今の生態系全体を実際に動かしている「心臓部」であり、各GUIクライアントはその心臓部を包む「外殻」として、コアの機能をクリックや画面表示といったユーザー操作に変換する役割を担っています。この点を理解した上でこの先のクライアント比較を見ると、格段に分かりやすくなります。

A-03GUIクライアント一覧:見た目は違っても、コアは同じ系統

GUIクライアントが解決するのは、設定ファイルを直接編集する手間の高さという課題で、サブスクリプションの読み込み、ノードの切り替え、ルールの確認といった操作を画面上で行えるようにします。クライアントごとにUIフレームワークや操作感、付加機能は大きく異なりますが、内部で呼び出しているコアは基本的にmihomoかその初期形態に行き着きます。以下、代表的なクライアントの分類ごとに位置づけを整理します。

特に注意すべきなのがこの最後のカテゴリーです。Clash for Windowsは長らくWindowsプラットフォームの代名詞的な存在でしたが、このプロジェクトは開発が終了しており、リポジトリには新しいコミットが取り込まれず、内部コアも古いバージョンのままです。使い続けても即座に「壊れる」わけではありませんが、新しいプロトコルのノードを認識できない、一部のルール文法に対応していないといった問題が徐々に増え、セキュリティ面のメンテナンスが行われないこと自体も長期的なリスクです。現時点でWindows向けに活発に開発され、コミュニティの反応も多い代替候補は、mihomoコアをベースにした新世代のクライアントに集中しています。

なぜUIが違っても設定ファイルは使い回せるのか

これは前述の継承関係が働いているためです。ほとんどのクライアントが呼び出しているのは同じmihomoコアの解析ロジックであり、設定ファイルも同じYAML文法規則に従っています。そのため同じサブスクリプションリンクは、理論上Clash Verge RevとFlClashなど異なるクライアント間で切り替えて使えます。サブスクリプションを再生成する必要はなく、違いはUIの見た目や調整可能なパラメータ数程度です。だからこそクライアント選びは、UIの雰囲気とプラットフォームへの適合度を比べる話であり、「設定が使えるかどうか」を過度に心配する必要はありません。

A-04現時点での選び方:プラットフォームとニーズ別

これまでの系譜整理を踏まえ、実践的な選び方の指針をいくつか挙げます。

1. WindowsとmacOSのデスクトップでは、mihomoコアをベースにした、今も活発に更新されているクライアントを優先しましょう。UIが軽量で設定項目の露出が充実している選択肢は、ルールを手動で調整したいユーザーに向いています。
2. Androidプラットフォームでは、VpnServiceへの対応を明記し、継続的にメンテナンスされているクライアントを優先しましょう。インストール後は、システムの省電力設定がバックグラウンド接続の安定性に影響していないか確認してください。
3. iOSプラットフォームはシステム側の制約により、クライアントの形態がデスクトップ/Androidとは異なります。選定時は公式チャネルで配布されており、更新履歴が明確なバージョンを基準にしましょう。
4. 使用中のクライアントの説明ページに今も「オリジナルのClashコアベース」と記載されており、長期間更新されていない場合は、mihomoベースの代替クライアントへの移行を検討しましょう。移行作業は通常、既存のサブスクリプションリンクを再登録するだけで済みます。
5. 「新しいクライアントほど良い」とこだわる必要はありません。安定性・コミュニティの反応量・更新頻度の3点を総合的に見るほうが、バージョン番号だけを見るより信頼できます。

移行時の注意点

あるクライアントから別のクライアントに切り替える場合、多くはサブスクリプションリンクを再登録するだけで移行が完了し、手動でルールを書き直す必要はありません。ただし元の設定にカスタムのポリシーグループ、スクリプトルール、特殊なパラメータが含まれている場合は、移行後にクライアントの設定確認画面を開き、ルール数とポリシーグループ数が移行前と一致しているか確認しましょう。文法解析の違いにより一部のルールが黒っぽく無視されるのを避けられます。

curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I

移行が完了したら、上記のコマンドでローカルのプロキシポートが正常に応答しているか確認できます。HTTP/1.1 204 No Contentが返れば、新しいクライアントのプロキシサービスが正常に通信を引き継いでいることを意味します。その後、ポリシーグループの切り替えとルールのマッチングが期待通りか一つずつ確認しましょう。

A-05よくある質問