名称変更の範囲を理解する：プロジェクト、画面、ファイル名は同時に変わらない
Mihomo Party を探して Clash Party が表示されても、アイコンやファイル名だけで別のクライアントだと判断しないでください。現在の公式な一次情報源は mihomo-party-org/clash-party 公式リポジトリで、リポジトリ名と説明には Clash Party が使われています。URL 上の組織名とリポジトリを追跡することで、第三者サイトの見出しでは分からないプロジェクトの同一性を確認できます。
名称変更はすべての表示へ同時に届くとは限りません。リポジトリ、アプリ名、インストーラー、OS のアプリ一覧、データディレクトリ、更新メタデータ、旧文書に異なる名前が残る場合があります。mihomo-party という接頭辞だけで直ちに偽物とは判断できず、clash-party も名前だけでは本物の証明になりません。同じ公式 Release に掲載され、OS と CPU が合い、対応する検証値があるかを見ます。
アプリとコアは別の層です：Clash Party はデスクトップクライアントの名前で、Mihomo は使用するコア名です。画面の名称変更を理由に設定内の Mihomo を一括置換してはいけません。
名称変更だけからライセンス、保存場所、互換性の変化を推測しません。Release やコードに明記された事実を優先します。動作中の旧版を新名称のためだけに急いで更新する必要はなく、更新理由があるときに通常のソフトウェア移行として管理します。
ファイル名検索ではなく公式リポジトリからReleaseへ進む
まず URL 上の組織名が mihomo-party-org、リポジトリが clash-party であることを確認し、その中の Releases を開きます。対象タグ、配布時の説明、アセットの完全な名前、サイズ、SHA-256 を記録します。解説記事は画面理解に使えますが、実行ファイルの唯一の配布元にはできません。
- 公式リポジトリで組織、名称、説明を確認する。
- そこから Releases を開き、明確なバージョンを選ぶ。
- OS、CPU アーキテクチャ、インストール形式で絞る。
- 対応する SHA-256 ファイルを取得し、ローカルで検証する。
- Release URL と元のアセット名を更新記録へ残す。
拡張子はパッケージ形式を表しても CPU を保証しません。Windows にはインストーラーと圧縮版、macOS には Intel と Apple チップ、Linux には複数形式と CPU があり得ます。先に端末情報を確定します。ミラーの方が速い、短い名前である、容量が小さいという理由は適合性の証拠になりません。
転載は自動的に公式ミラーにはなりません：プロジェクトが明示的に案内した場所だけが公式配布元までたどれる状態を保ちます。同名の外部ファイルにも独立検証が必要です。
1つのReleaseに2つの接頭辞がある場合、OSとハッシュで組み合わせる
公式の v2.0.2 Release は移行期の具体例です。同じ Assets に clash-party- と mihomo-party- で始まるファイルがあり、Windows、macOS、Linux と対応する .sha256 が並びます。同じ公式タグ内にあるため、接頭辞だけで無関係な2製品だとは説明できません。
| 観察 | 根拠のある理解 | 飛躍した結論 |
|---|---|---|
| clash-party | 現在名を使う配布ファイル | 必ず新しい保存場所を使う |
| mihomo-party | 移行・互換用の命名 | 必ず旧版または危険 |
| 同じ v2.0.2 | 1つの Release の一覧 | 外部の同名ファイルも信頼できる |
| .sha256 | 取得内容を検証できる | 入手元は確認しなくてよい |
先に OS と CPU を合わせ、そのタグの説明を読みます。同一環境向けに両方ある場合でも2つを重ねて試さず、Release と検証値に完全対応する1つの配布ファイルをバックアップ後に選びます。説明のない差異は公式の Issue や告知で確認し、根拠のない機能差を想定しません。
SHA-256 は中断や内容変更を検出しますが、期待値が信頼できるページから来た場合だけ有効です。元の名前を保ち、ローカルの完全な結果を一文字ずつ比較します。容量や先頭数文字だけでは不十分です。
ユーザーデータを保存し、起動成功と移行成功を分ける
名称変更後のバージョンが既存データを直接読むこともあれば、パッケージ識別子やバージョンの差で別の場所を使うこともあります。無停止で移行できるとは仮定せず、事前にディレクトリ名を変更しません。旧版で完全なバージョン、プロファイル名、モード、重要なオーバーライド設定、コア状態を記録し、内蔵のエクスポートを使います。データディレクトリをコピーするなら完全終了し、サブスクリプショントークンを機密として扱います。
プログラム復元とデータ復元を別に保存します。旧インストーラーや未変更ポータブル版はアプリを戻し、エクスポートと全体スナップショットは利用状態を戻します。新しい環境でデータを確認する前に、ユーザーデータを削除する設定で旧版をアンインストールしないでください。
- 旧表示名、完全なバージョン、元の配布 URL を記録する。
- 設定を出力し、アプリを終了した状態で実際のデータ場所をコピーする。
- プロファイル、選択グループ、オーバーライド設定の機密を除いた基準を残す。
- バックアップが空でなく、アプリ外にあることを確認する。
- OS に合う1つの配布ファイルだけを導入し、初回はサブスクリプション更新をしない。
- 基準と比較後、自動更新と通常運用を戻す。
新しい画面が空なら書き込み前に終了し、新旧が実際に読む場所を確認します。内蔵インポートか1つの完全なスナップショットを選び、別バージョンのインデックスと単独 YAML を混ぜません。混在は重複、オーバーライド設定の消失、存在しない参照につながります。
バージョン、コア、データ、通信を確認してから旧ファイルを整理する
初回起動後、About でアプリのバージョンと選択した Release を照合し、Clash Party または移行名のどちらが表示されるか記録します。次にコアバージョン、プロファイル、グループ、ログを確認します。新名称だけでは移行成功にならず、旧名称が1か所残っても誤ったパッケージを導入したとは限りません。出所を追跡でき、データと動作が揃うことが重要です。
- アプリ：バージョン、OS、CPU とアセットが一致する。
- データ：サブスクリプション、オーバーライド設定、モード、重要設定が残る。
- コア：起動を維持し、再起動ループがない。
- 通信：固定ノードと rule モードで接続を説明できる。
- 復元：旧アプリと非公開バックアップが利用可能。
更新画面に Mihomo Party と出る場合も、更新先として参照しているリポジトリとバージョンを調べます。Clash Party と書かれた画面にも同じ URL 確認が必要です。組織、リポジトリ、タグ、アセット、ハッシュの連鎖が判断材料です。
整理する条件：終了・再起動、設定の読み込み、実際の通信を通し、一定期間バックアップを残します。復元不要と判断してから重複インストーラーとテスト用フォルダを削除します。
説明するときは「旧称 Mihomo Party のプロジェクトは、現在 Clash Party という名称を使用している」と公式 URL を示します。移行期の2つの接頭辞を独立した公式クライアントと呼ばず、将来も旧名が残ると約束せず、各 Release で確認してください。
公式情報源とバージョン範囲
バージョン番号、ファイル名、画面表示は更新で変わる場合があります。作業前にリンク先の公式資料を確認してください。