Clash 全プラットフォーム導入・設定ガイド｜Windows・macOS・Android・iOS・Linux対応

01 / PREPARE

導入前の共通準備：クライアント、サブスク、ネットワークの確認

まずクライアント、コア、サブスクを区別する

インストールを始める前に、混同されやすい3つの概念を整理しておきましょう。クライアントは、設定のインポート、ポリシーの切り替え、ログの確認、システムプロキシの制御を行う、ユーザーが実際に操作するGUIです。Mihomoなどのコアは設定を解析し、ルールに従ってプロキシ接続を確立します。サブスクはサービス提供者が用意する設定の入口で、通常はノード、ポリシーグループ、ルール、更新URLが含まれます。クライアントをインストールしても利用可能なノードが自動で生成されるわけではなく、コアだけをダウンロードしてもデスクトップ向けの操作画面は得られません。一般的なPCやモバイル端末ではGUI付きクライアントを、サーバー、ルーター、自動化環境ではコアの直接実行を選ぶのが適しています。

当サイトのダウンロードページでは、プラットフォーム別に選べるソフトウェアを掲載し、各プラットフォームの先頭にClash Plusを案内しています。WindowsではClash Verge Rev、FlClash、Clash Nyanpasu、アーカイブ版のClash for Windowsも選択できます。macOSではClash Verge Rev、FlClash、アーカイブ版のClashX Meta、AndroidではClash Meta for Android、FlClash、Surfboard、LinuxデスクトップではClash Verge RevとFlClashを利用できます。クライアントによってメニュー名は多少異なりますが、基本的な流れは共通です。サブスクを登録し、設定を選び、ノードをテストし、ポリシーを選択してプロキシを有効にし、接続先を確認します。

必要な情報を控え、システムのアーキテクチャを確認する

ダウンロード前に、端末のOSバージョンとCPUアーキテクチャを確認してください。Windowsではx64が一般的ですが、一部の新しい端末ではARM64を使用します。Appleチップ搭載MacではApple SiliconまたはARM版、旧来のIntel Macではx64版を選びます。Androidのインストールパッケージはarm64、arm、汎用版に分かれる場合があります。LinuxではDebian系、RPM系、圧縮形式の単体バイナリを区別します。アーキテクチャが合わないと、インストーラーが起動を拒否したり、起動後に形式エラーが表示されたりします。判断できない場合は、端末の「このデバイスについて」を確認するか、システムコマンドを使い、外観だけで推測しないでください。

# Windows PowerShell
$env:PROCESSOR_ARCHITECTURE

# macOS
uname -m

# Linux
uname -m
cat /etc/os-release

有効なサブスクURL、必要なログイン情報、サブスク入口へ正常にアクセスできるネットワークも準備します。サブスクURLには認証用パラメータが含まれることが多いため、パスワードと同じように扱い、公開スクリーンショット、質問掲示板、共有ログに貼り付けないでください。サービス提供者がQRコードを用意している場合、モバイル端末ではスキャンして登録できます。デスクトップでは通常、クリップボードからURLを貼り付けます。受け取ったものがローカルYAMLファイルなら、「サブスクURL」ではなく「ローカル設定をインポート」を使います。ローカルファイルはリモート更新に追従しないためです。

インストール前の基準状態を確認する

プロキシを有効にする前に、端末の時刻、ブラウザー接続、DNS名前解決が正常であることを確認します。システム時刻のずれはTLS接続失敗の原因になります。また、既存のVPN、企業向けセキュリティソフト、仮想NIC、他のプロキシソフトがポートを使用したり、ルーティングを変更したりすることがあります。同種のネットワークツールを一時終了し、元のシステムプロキシ設定を控えてからClashクライアントを導入するのがおすすめです。接続に問題が起きたとき、元のネットワーク、クライアントによる接続制御、サブスク内容のどこに原因があるかを切り分けやすくなります。

システムプロキシとTUNの選び方

システムプロキシは、OSのプロキシ設定に従うブラウザーやデスクトップアプリに主に作用します。設定が簡単で影響範囲も分かりやすいため、初回接続に適しています。TUNは仮想ネットワークインターフェースを作成し、ルーティング層からより多くの通信を取り込みます。システムプロキシを参照しないアプリ、一部のコマンドラインツール、ゲームにも対応できますが、より高い権限が必要で、他のVPN、仮想マシン、コンテナネットワーク、セキュリティソフトと競合しやすくなります。これは速度設定ではなく、通信を取り込む方式の違いです。明確な目的がなければ、まずシステムプロキシを使い、アプリがそれを回避する場合にTUNを検討してください。

準備項目	確認する内容	主な影響
CPUアーキテクチャ	x64、ARM64、Apple Silicon、armv7など	インストールパッケージまたはコアファイルを決定
サブスクの種類	リモートURL、QRコード、ローカルYAML	登録方法と更新可否を決定
通信の取り込み方式	システムプロキシまたはTUN	プロキシを適用できるアプリの範囲を決定
既存のネットワークツール	VPN、仮想NIC、他のプロキシソフト	ルーティング、DNS、ポートの競合を引き起こす可能性

02 / WINDOWS

Windowsの導入・設定：システムプロキシ、サービスモード、TUN

ダウンロードして初回インストールを完了する

WindowsユーザーはWindowsダウンロードからClash Plusを選ぶか、必要に応じてClash Verge Rev、FlClash、Clash Nyanpasuを選択できます。Clash for Windowsは開発が終了しているため、旧設定との互換性を確認するためのアーカイブとしてのみ扱い、新しい環境での長期利用は推奨しません。ダウンロード前に「設定 → システム → システム情報」でシステムの種類を確認してください。デスクトップPCの大半はx64です。インストーラーでシステムのセキュリティ確認が表示された場合は、ファイル名と入手先を確認してから、通常のアプリのインストール手順を続けます。

インストール後は、まず通常どおり1回起動し、クライアントに設定フォルダーと基本設定を作成させます。画面が開かなくても、すぐに互換モードを有効にしたり、何度も再インストールしたりしないでください。先にタスクマネージャーで同名プロセスが残っていないか確認し、バックグラウンドプロセスを終了してから再起動します。ポータブル版とインストール版ではデータフォルダーが異なる場合があります。移行時は実行ファイルだけをコピーせず、クライアントの設定フォルダー入口からprofiles、logsなどのデータを確認してください。

サブスクを登録して設定を有効にする

クライアントのサブスク、設定、またはProfilesページを開き、入力欄にサブスクURLを貼り付けてインポートします。成功すると、通常は設定名、更新日時、ポリシーグループが表示されます。設定カードが表示されただけでは有効化されていません。設定をクリックするか、現在の設定として指定してください。次にプロキシまたはProxiesページへ進み、候補ノードの遅延をテストします。遅延テストに失敗しても、すぐにサブスクを削除する必要はありません。ICMP、TCP探測、実際のWeb接続では方式が異なるためです。ノードを1つ選び、実際のアクセスでも確認してください。

サブスクの更新に失敗した場合は、まずブラウザーでサブスク入口へアクセスできるか確認します。ブラウザーでは開けるのにクライアントでエラーになる場合、URL末尾のパラメータがコピー時に欠落していないか、空白が混入していないか、クライアントの更新処理が現在のプロキシを誤って経由していないかを確認します。クライアントに「直接接続で更新」や更新用プロキシの設定がある場合は、基本ネットワークが使える状態で切り替えてテストできます。リモート設定の更新では、サブスク提供元のノードとルールが上書きされます。手動変更の前に、クライアントが上書き機能を提供しているか確認してください。

システムプロキシを有効にしてモードを選ぶ

初回接続ではルールモードがおすすめです。利用可能なノードまたはポリシーグループを選び、「システムプロキシ」を有効にします。クライアントがWindowsのプロキシ設定を書き換えます。一般的なローカルアドレスはループバックアドレスで、ポートは現在の設定またはクライアント側の設定で決まります。ブラウザーは通常すぐに新しい設定を読み込みますが、起動中の一部アプリでは再起動が必要です。グローバルモードは多くのリクエストを選択したポリシーへ送るため、ルールの誤振り分けを短時間確認するのに適しています。ダイレクトモードは一時的にプロキシを回避するために使います。確認後はルールモードへ戻し、プロキシ範囲を不必要に広げないようにしてください。

システムプロキシが有効と表示されているのにブラウザーが直接接続する場合は、「設定 → ネットワークとインターネット → プロキシ」で手動プロキシが書き込まれているか確認し、企業ポリシーや他のソフトが値を上書きしていないかも確認します。複数のクライアントでシステムプロキシを同時に有効にしないでください。同じシステム設定を奪い合うことになります。クライアントが異常終了した後にWebページへまったくアクセスできない場合、停止したローカルポートをシステムが参照し続けていることがよくあります。その場合は手動プロキシを無効にすれば基本ネットワークを復旧できます。

サービスモードとTUNの権限

WindowsのTUNは通常、管理者権限またはクライアントによるバックグラウンドサービスのインストールが必要です。サービスモードは、コアやネットワークコンポーネントを管理された権限で動かすためのもので、ノードのサービスを意味するものではありません。サービスをインストールしてからTUNを有効にすると、新しい仮想ネットワークアダプターが作成され、対応するルートが追加されます。初回有効化時にセキュリティソフトがネットワークアクセスを確認する場合は、必要なネットワーク種別でクライアントの通信を許可します。サービスのインストールに失敗したら、旧バージョンのクライアントを終了し、システムサービスに同名の残骸がないことを確認してから、管理者権限で内蔵のサービスインストール操作を実行してください。

Windows固有のトラブル切り分け

ストアアプリ、コマンドラインプログラム、一部のゲームはシステムプロキシに従うとは限りません。通常のブラウザーは接続できるのに特定のアプリだけ接続できない場合は、そのアプリがWinINETまたはシステムプロキシを参照するか確認します。参照しない場合にTUNを使い、先にサブスクのルールを変更するのは避けてください。LAN上の端末だけが本機のプロキシへ接続できない場合は、「LAN接続を許可」設定、Windowsファイアウォールの受信規則、リッスンアドレスを確認します。ただし、LANからの接続を許可すると同じネットワーク上の端末がポートへ接続できるため、明確な必要がある場合だけ有効にしてください。

HTTPS証明書エラーが発生した場合は、まずWindowsの時刻とタイムゾーン、ブラウザーの証明書詳細、パケットキャプチャやフィルタリングソフトの同時実行を確認し、HTTPS証明書エラーの解決方法も参照してください。プロキシプロトコル自体のために、Webページから提供された証明書を無作為にインストールする必要は通常ありません。特定のブラウザーだけで発生する場合は、システム全体の障害と判断する前に、そのブラウザーのプロキシ拡張機能とネットワークポリシーを確認します。

03 / MACOS

macOSの導入・設定：チップの種類、システム拡張、プロキシ権限

Apple Silicon版またはIntel版を選ぶ

macOSユーザーはClash Plusを優先して選べます。Clash Verge Rev、FlClashも利用できます。ClashX Metaは開発が終了しているため、既存環境との互換性確認用として扱ってください。画面左上のAppleメニューから「このMacについて」を開き、チップ欄にApple Mシリーズと表示される場合はApple SiliconまたはARM版、Intelと表示される場合はx64版を選択します。ターミナルで uname -m を実行して確認することもできます。arm64 はAppleチップ、x86_64 はIntelに対応します。

ダウンロード後は、通常アプリを「アプリケーション」フォルダーへドラッグしてから、その場所から起動します。ディスクイメージやダウンロードフォルダーから長期間直接実行すると、自動更新、権限記録、データパスが不安定になることがあります。ネットワークから取得したアプリを初めて開くときは、システムのセキュリティ確認が行われます。Finderでアプリを指定し、システムの案内に従ってください。確認を回避するために、システム全体の安全設定を下げないでください。誤ったアーキテクチャをダウンロードした場合、Appleチップでは互換レイヤーによりx64版が動くこともありますが、ネットワーク拡張、性能、補助コンポーネントに差が出る場合があります。対応するアーキテクチャ版へ入れ替えるのが安全です。

サブスク登録とメニューバー操作

起動後にProfiles、設定、サブスクのページを開き、サブスクURLを貼り付けて保存し、インポートした設定を選択します。macOSクライアントでは、メインウィンドウとメニューバーの入口が別に用意されていることが多く、システムプロキシ、動作モード、現在のポリシーがメニューバーアイコン内にある場合があります。登録後は現在の設定名が切り替わっていることを確認してから、ポリシーグループでノードを選びます。メインウィンドウを閉じてもメニューバーにアイコンが残る場合、クライアントはバックグラウンドで動作しています。完全に終了するには、ウィンドウを閉じるだけでなく、メニューの終了コマンドを使ってください。

サブスクに複数のポリシーグループがある場合は、まず「ノード選択」またはそれに近い名前の手動選択グループを確認し、その後、自動選択やフォールバックなどのグループが正しいノードを参照しているか確認します。ルールが最終的に指定するのはポリシーグループ名であり、特定のサーバーとは限りません。特定のWebサイトで接続異常が起きた場合は、トップ画面に表示されたノードを何度も切り替えるのではなく、接続ログで適用されたルールとポリシーを確認してください。

システムプロキシの適用と復元

システムプロキシを有効にすると、クライアントは現在のネットワークサービスのWebプロキシ設定を変更します。macOSではWi‑Fi、有線、その他のネットワークサービスごとに設定を管理するため、ネットワークを切り替えた後は新しいサービスが正しく制御されているか確認してください。「システム設定 → ネットワーク → 現在のネットワーク → 詳細 → プロキシ」でWebプロキシと安全なWebプロキシの状態を確認できます。通常はクライアントに管理させ、クライアントの自動設定と別のポートを手動入力する操作を同時に行わないでください。

クライアントのクラッシュ後にSafariや他のアプリがネットワークへ接続できなくなった場合は、残ったプロセスを終了し、システムのネットワークプロキシ画面で無効になったローカルプロキシを解除します。コマンドで特定のネットワークサービスを確認することもできますが、サービス名は言語設定やユーザー変更によって異なります。先に名前を一覧表示してから確認してください。

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"

ターミナルの curl、パッケージマネージャー、開発ツールがGUIのシステムプロキシを一律に読み取るとは限りません。HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 環境変数を参照するツールもあれば、独自のプロキシ設定を持つツールもあります。GUIアプリは正常なのにターミナルのコマンドだけが直接接続する場合は、まずツールのプロキシ動作を確認してください。より多くのプロセスを対象にする必要がある場合はTUNを検討できますが、環境変数とTUNを記録なしに恒久的な対策として併用しないでください。

TUN、ネットワーク拡張、システム認証

TUNを有効にすると、macOSで管理者パスワード、VPN構成の許可、ネットワーク拡張の許可を求められることがあります。許可はシステムのダイアログに従って一度行えばよく、その後はVPNとネットワーク関連の設定で状態を確認できます。TUN有効時はクライアントが仮想インターフェースでルーティングされた通信を受け取るため、Docker Desktop、仮想マシン、企業VPN、ネットワークフィルター、ローカル開発用セグメントにも影響する可能性があります。社内ネットワークやLANサービスへ突然アクセスできなくなった場合は、ルールでプライベートアドレスを直接接続にしているか、TUNの自動ルートが専用ルートを上書きしていないか確認してください。

DNSとスリープ復帰後の接続問題

macOSはシステムDNSキャッシュを保持し、ブラウザーが独自のセキュアDNSを使うこともあります。ClashのDNS設定を変更した後も古い名前解決結果が使われる場合は、まずブラウザーを完全に終了してネットワークへ再接続します。キャッシュが原因だと確認できた場合だけ、システムのキャッシュを更新してください。スリープ復帰後に「ノードテストは成功するのにWebページが開けない」場合、仮想インターフェースが復旧していない、システムプロキシが古いプロセスを参照している、上流ネットワークのDNSアドレスが変わった、といった原因が考えられます。「接続制御を停止 → 直接接続を確認 → クライアントを再起動 → 接続制御を再開」の順に進めると、どの層で問題が起きているかを切り分けられます。

04 / ANDROID

Androidの導入・設定：VPN許可、バックグラウンド動作、アプリ振り分け

クライアントをインストールして初回認証を完了する

AndroidではClash Plusを優先して選べます。Clash Meta for Android、FlClash、Surfboardも利用できます。インストールパッケージは端末のアーキテクチャに合わせ、arm64、arm、汎用版から選んでください。近年の主流端末は通常arm64ですが、Androidのバージョンだけでは判断できません。端末情報アプリやシステムのハードウェア情報でABIを確認する方が正確です。インストールに失敗した場合は、ファイルのダウンロードが完了しているか、アーキテクチャが合っているか、現在のブラウザーやファイル管理アプリによるインストールをシステムが許可しているかを確認します。

クライアントを初めて起動して接続を有効にすると、AndroidはVPN接続のリクエストを表示します。これはローカルの仮想ネットワークインターフェースに対するシステム許可で、アプリの通信をクライアントへ渡すために必要です。許可後は、通常ステータスバーにVPNアイコンが表示されます。Androidでは通常、同時に1つの一般的なVPN接続しか利用できません。そのため、企業VPN、他のプロキシクライアント、システムの常時接続VPNとClashが競合します。接続できない場合は、起動ボタンを何度も押すのではなく、まずシステムのVPN設定で現在の接続を占有しているアプリを確認してください。

URL、ファイル、QRコードからサブスクを登録する

設定ページでは、サブスクURLを貼り付ける、ローカル設定ファイルを選ぶ、QRコード入口を使う、といった方法で登録できます。QRコードに完全なサブスクURLが含まれる場合もあるため、登録後も設定情報を保護してください。リモートサブスクの登録に成功したら、設定を選択してコアの読み込みを待ちます。YAML解析エラーが表示される場合、原因はスマートフォンのネットワーク権限ではなく、リモート側がログインページ、エラーページ、互換性のない内容を返していることが多いです。まずブラウザーでサブスク入口を開き、実際に設定データが返っているか確認してください。

モバイル通信とWi‑Fiでは、IPv6、DNS、アクセス方針が異なる場合があります。一方のネットワークでは更新に失敗し、別のネットワークでは成功する場合は、サブスク入口とノード接続をそれぞれテストし、すぐにクライアントの破損と判断しないでください。定期更新が必要なサブスクもあるため、設定ページで明示的に手動更新を実行し、更新日時とエラー表示を確認するのがおすすめです。更新後にノード名が変わった場合、以前に手動選択したポリシーが初期項目へ戻ることがあるため、ポリシーグループを再確認します。

ルールモード、グローバルモード、アプリ振り分け

Androidでも初回接続はルールモードがおすすめです。ノードを選んでVPNを起動し、ブラウザーで接続先を確認します。グローバルモードは、特定のルールが直接接続の原因か短時間確認する場合に使い、テスト後はルールモードへ戻します。アプリ振り分けでは、プロキシを通すアプリと通さないアプリを指定できますが、クライアントによって「選択したアプリのみプロキシ」と「選択したアプリを除外」という正反対の意味を持つ場合があります。保存前に現在のモードを必ず確認し、プロキシが必要なアプリを誤って除外リストへ入れないでください。

アプリ振り分けは、通信をクライアントへ入れるかどうかだけを決めます。クライアントに入った後は、ドメイン、IP、ポリシーのルールに従ってさらに処理されます。1つのアプリが公開API、LAN端末、プッシュサービスへ同時にアクセスする場合、アプリ全体を単純にプロキシへ送るとログインに失敗することがあります。まずアプリをルールモードで処理し、接続ログを見ながら特定ドメインのルールを追加する方が安全です。銀行、決済、LAN制御、通信事業者のサービスはローカルネットワーク環境に依存しやすいため、実際の利用目的に合わせて直接接続ルールを決めてください。

バックグラウンド制限と接続の回収

Android端末メーカーは、バックグラウンドアプリにバッテリー制限を適用することがあります。画面ロックから数分後にVPNアイコンが消える、通知が消える、接続を再起動する必要がある、といった場合は、クライアントのバッテリー最適化、バックグラウンド動作、自動起動、通知権限を確認してください。アプリを「制限なし」にするとバックグラウンドで動き続けやすくなりますが、消費電力も増える可能性があります。端末の設定項目に沿って必要なものだけ調整し、関係のない権限まで一度に許可しないでください。常駐通知はフォアグラウンドサービスの状態の一部であり、通知権限を無効にするとシステムによるサービス管理に影響する場合があります。

Wi‑Fiからモバイル通信へ切り替えると、既存接続の送信元アドレスとルートが変わります。クライアントは通常自動的に接続を再構築しますが、一部の長時間接続ではアプリが再接続を開始する必要があります。ネットワーク切り替え後に一部のアプリだけが停止した場合は、そのアプリを強制終了して再起動します。すべての通信が失敗する場合は、クライアントの接続を再起動してください。頻繁な自動切断が続く場合は、省電力モード、データセーバー、メーカー独自のスリープ対象アプリ一覧も確認します。

プライベートDNS、IPv6、テザリング

AndroidのプライベートDNSは暗号化された名前解決を使うため、クライアントのDNSリダイレクトやfake-ip方式と2つの解決経路を作ることがあります。ドメイン解析に失敗する、ブラウザーは使えるのに他のアプリが使えない、といった場合は、比較テストとしてプライベートDNSを一時的に自動へ変更します。競合が確認できたら、システムのプライベートDNSを残すか、Clashに解析を統一させるかを決めてください。IPv6もノード、通信事業者、設定の対応状況に応じて有効化します。単純に無効化するのではなく、ログから失敗したリクエストがIPv4とIPv6のどちらを使ったか確認してください。

スマートフォンでテザリングを行っても、下流端末の通信がAndroid本体のVPNへ自動的に入るとは限りません。テザリング通信を取り込めるかどうかは、システムの実装、クライアントの機能、端末の権限に左右されます。他の端末へプロキシを提供する必要がある場合は、クライアントでLAN接続を許可し、下流端末にスマートフォンのLANアドレスとプロキシポートを手動入力する方が明確です。信頼できるネットワークでのみ使用してください。共有の必要がなければ、LANリッスンを無効にして露出範囲を減らします。

05 / IOS

iOSの導入・設定：App Store、VPN構成、オンデマンド接続

App Storeから入手してシステム権限を確認する

iPhoneとiPadではApp StoreからClash Plusを入手できます。インストール後に初めて接続を確立すると、iOSはVPN構成の追加を求め、端末パスコード、生体認証、システム確認によって許可を完了します。許可後、クライアントはローカルネットワークトンネルを作成して通信を処理できるようになります。この権限はシステムが一元管理しており、「設定 → 一般 → VPNとデバイス管理」またはバージョンに応じたVPN設定で確認できます。学校や企業が管理する端末では、新しいVPN構成がポリシーによって制限される場合があるため、先に端末の利用規則を確認してください。

iOSでは、同時に1つの主要なVPN構成だけがアクティブになります。他のVPN、企業向けセキュリティクライアント、コンテンツフィルター、プライベートリレー系機能が実際の通信経路を変えることもあります。接続をタップするとすぐ切断される場合は、まずシステムのVPN画面で競合する構成がないか確認し、その後クライアントのエラー情報を読みます。すべてのネットワーク設定を削除するとWi‑Fiなど他の設定にも影響するため、最初のトラブル解決手段にはしないでください。

サブスクを登録して現在の設定を選ぶ

クライアントで設定またはサブスク入口を開き、サービス提供者のURLを貼り付けるか、QRコードをスキャンします。チャットアプリからリンクをコピーした場合は、改行、前後の空白、途中で切れたクエリパラメータがないか確認してください。登録後に設定を選び、ポリシーページでノードを指定します。登録後に自動読み込みを行うクライアントもありますが、手動ポリシーグループの選択まで自動で決めるとは限りません。初回接続前に、主要ノードグループと最終フォールバックポリシーを少なくとも確認してください。

「ファイル」アプリからYAMLを登録する場合、ファイルがiCloud Driveまたはローカルストレージにあることがあります。クラウドからのダウンロードが完了していないと、クライアントが読み込めない場合があります。先に「ファイル」で開けることを確認してから、共有またはインポートを実行してください。リモートサブスクとローカルファイルでは更新方法が異なります。リモートサブスクは上流へ再リクエストできますが、ローカルファイルは変更後の版を再登録する必要があります。サブスクが生成したノード項目を直接編集しないでください。次回更新で上書きされることが多いためです。

接続、ルールモード、オンデマンド起動

設定とノードを選んで接続を有効にすると、ステータスバーまたはコントロールセンターにVPN状態が表示されます。まずSafariで普段使うサイトへアクセスし、その後ほかのアプリを確認します。ルールモードでは、設定内のルールに従って直接接続かプロキシかが決まります。グローバルモードはルールの問題を短時間切り分けるために使い、ダイレクトモードはプロキシを無効にした基本ネットワークを確認するために使います。Safariは正常なのに特定のアプリが失敗する場合は、サーバーを切り替えるだけでなく、そのアプリのドメインが拒否、直接接続、不適切なポリシーグループのどれに該当したか確認してください。

オンデマンド接続ではネットワークの変化に応じてVPNを自動起動できますが、条件が広すぎるとすべてのWi‑Fiやモバイル通信で接続し続け、狭すぎるとネットワーク切り替え後に起動しないことがあります。初回導入時はまず手動接続で、サブスク、ノード、DNSが正常であることを確認してからオンデマンドルールを設定してください。信頼できる家庭内ネットワークでは停止したい場合、ネットワーク識別子で例外を設定し、ルーター名を変更した後も条件が一致するか定期的に確認します。

iOSのネットワーク変化とバックグラウンド動作

iOSはバッテリー残量、ネットワーク状態、システムスケジュールに応じてバックグラウンド動作を管理します。ただし、確立済みのVPNトンネルはシステムのネットワーク拡張が維持するため、通常のアプリが前面に残り続ける状態とは異なります。画面ロック後に接続が頻繁に切れる場合は、クライアントログの停止理由、低電力モード、ネットワーク切り替えの状況を確認します。モバイル通信とWi‑Fiの切り替えでは送信元アドレスが変わるため、既存のTCP接続が切れることがあります。これは正常な挙動で、影響を受けたアプリを再度開けば新しい接続が作られることが多いです。

Wi‑Fiによっては、最初にWebページで認証する必要があります。このようなネットワークでVPNが自動起動していると、認証ページが表示されないことがあります。一時的にクライアントを切断し、任意の非暗号化ページを開いて認証画面を表示し、完了後に接続してください。ホテル、空港、公共Wi‑Fiでは特定のプロトコルが制限されることもあります。モバイル通信では正常なのに公共Wi‑Fiですべて失敗する場合は、設定を何度も削除する前にネットワーク側の制限を確認します。

DNS、LAN、プッシュサービス

iOSアプリは、LAN端末、システムのプッシュサービス、地域別APIへアクセスすることがあります。ルール設定では、プライベートアドレスとローカルドメインを直接接続にし、家庭用ストレージ、プリンター、スマート機器が遠隔プロキシへ送られて接続できなくなるのを防ぎます。LANへ初めてアクセスすると、システムがローカルネットワーク権限を尋ねることがあります。拒否してもクライアント自体はインターネットへ接続できる場合がありますが、LAN検出や共有機能は制限されます。システムのプライバシー設定で権限を再確認してください。

通知が遅れるのにWebアクセスは正常な場合は、プッシュ関連の接続に適用されたポリシー、ノードの安定性、システム通知設定を確認します。プッシュの異常だけを理由にグローバルモードへ変更しないでください。より多くのアプリの出口が変わるためです。DNSの問題は、同じドメインをSafari、アプリ内、異なるネットワークで開いた結果を比較して確認します。DNSの出口とfake-ipの判定については、ClashのDNSリーク検出と修正も参照してください。

06 / LINUX

Linuxの導入・設定：デスクトップクライアント、コアサービス、権限

デスクトップクライアントと単体コアの使い分け

LinuxデスクトップユーザーはLinuxダウンロードからClash Verge RevまたはFlClashを選べます。サブスク管理、ポリシー切り替え、ログ画面が用意されており、日常のデスクトップ環境に適しています。サーバー、ソフトウェアルーター、GUIのない端末ではMihomoコアを直接実行できますが、設定ファイル、起動パラメータ、権限、サービスのライフサイクルを自分で管理する必要があります。2つの方式で同じポートを同時にリッスンしないでください。起動に失敗したり、通信が誤ったプロセスへ入ったりします。

インストールパッケージはディストリビューションに合わせる必要があります。Debian、Ubuntuとその派生システムでは通常deb、RPM系のパッケージ管理を使うディストリビューションではrpmを使用します。単体の圧縮パッケージは、実行ファイルを手動で配置し、依存関係も管理する必要があります。CPUアーキテクチャは uname -m で確認でき、x86_64 はAMD64、aarch64 はARM64に対応します。ルーターではARMv7やMIPS系が使われることもあり、誤った版を選ぶと「バイナリファイルを実行できない」といったエラーが表示されます。

デスクトップ環境のシステムプロキシ

GNOME、KDEなどのデスクトップ環境では、システムプロキシの保存方法が異なります。クライアントの「システムプロキシ」スイッチがすべての環境を制御できるとは限りません。有効化後は、デスクトップのネットワーク設定でHTTP、HTTPS、SOCKSプロキシがクライアントのリッスンポートを指しているか確認してください。ブラウザーがデスクトッププロキシを読む場合もあれば、独自設定を使う場合もあります。ターミナルのプログラムは環境変数に依存することが多いため、GUIアプリは正常でコマンドラインだけ失敗しても、すぐにノードの問題とは判断せず、対象プログラムがどの設定を読むか確認します。

# 現在のターミナルセッションだけに適用。ポートはクライアントの実際のリッスン値に合わせる
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7891

# テスト後に元へ戻す
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

変数名に大文字と小文字の形式が同時に存在する場合、ツールによって読み取り順が異なることがあります。一時的なテスト変数をすべてのshell起動ファイルへ書き込まないでください。クライアントを終了しても、パッケージマネージャーや開発ツールが停止したポートを参照し続けます。長期的に設定する場合は、有効化用と無効化用のスクリプトを分け、ポートの出所を明確にしてください。

Mihomoをサービスとして実行する

単体コアでは通常、-d で設定ディレクトリ、-f で設定ファイルを指定します。初回実行前にファイル権限と作業ディレクトリを確認してください。特にsystemdから起動する場合、サービスユーザーのホームディレクトリ、相対パス、対話型ターミナルは通常の実行時と異なります。設定と実行データは専用ディレクトリに保存し、サービスユーザーには必要な読み書き権限だけを与えるのがおすすめです。すべての機能を最高権限で長期間実行しないでください。TUNの作成やルートの書き込みなど、追加権限が必要な操作だけに限定します。

# フォアグラウンドで設定をテストし、ログに解析エラーがないことを確認してからサービス管理へ渡す
mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml

# リッスンポートを確認する
ss -lntup | grep -E '7890|7891|9090'

systemdサービスには、明確な起動コマンド、再起動ポリシー、作業ディレクトリを設定します。設定を更新したら、まずフォアグラウンドまたは単独のコマンドで検証してからサービスを再起動し、誤設定による再起動ループを避けてください。ログはサービスマネージャーで確認するか、クライアント設定に従ってファイルへ出力します。制御インターフェースをLANでリッスンする必要がある場合は、アクセス制御を設定してファイアウォールで接続元を制限します。本機だけで管理するなら、ループバックアドレスでのリッスンが安全です。

TUN、ルーティング、DNSの権限

LinuxのTUNには /dev/net/tun が存在し、プロセスにインターフェース作成とルート変更の権限が必要です。コンテナ、制限付きVPS、一部のNAS環境ではこのデバイスがマッピングされておらず、管理者アカウントでも作成できない場合があります。自動ルートを有効にしたら、デフォルトルート、ポリシールーティングテーブル、ファイアウォールルールを確認し、ローカルネットワーク、リモート管理入口、プロキシサーバー自体の通信が再びTUNへ入り込んでループしないようにします。

DNSリダイレクトにはファイアウォールやルーティング機能が必要で、システムによってnftables、iptables、systemd-resolved、NetworkManagerなどを使います。複数のコンポーネントに /etc/resolv.conf を繰り返し書き換えさせないでください。systemd-resolvedを使っている場合は、そのインターフェースで実際の上流DNSを確認します。NetworkManagerが管理している場合は、接続設定から変更してください。変更前に現在のDNS状態を記録し、クライアント終了後にシステムの名前解決が復旧することを確認します。

Linuxでよくある起動・権限の問題

GUIクライアントが起動しない場合は、ターミナルから実行して不足しているライブラリ、表示サービス、サンドボックスのメッセージを確認します。WaylandとX11ではトレイ対応が異なることがあります。ウィンドウを閉じた後もプロセスがバックグラウンドに残っていないか確認してください。コアがポート使用中と表示したら、ss または lsof で使用者を特定します。ブラウザー、環境変数、LAN端末が古い値を参照している可能性があるため、すべてのポートを安易に変更しないでください。設定ディレクトリが読み取り専用の場合は、ディレクトリ全体を全ユーザー書き込みにするのではなく、所有者と権限を修正します。

07 / CONFIGURATION

共通設定とルール振り分け：ポート、DNS、ポリシーグループ、TUN

設定ファイルの処理順を理解する

Clashの設定は通常、基本リッスン設定、プロキシノード、プロキシグループ、ルールプロバイダー、ルール、DNS、TUNなどで構成されます。ノード定義が接続パラメータを持ち、ポリシーグループがノードまたは他のポリシーから選択し、ルールがリクエストをポリシーグループへ振り分けます。トラブル解決では「ドメイン解析 → ルールマッチ → ポリシーグループ選択 → ノード接続」の順に確認してください。ノードの遅延が正常でも、DNSやルール経路が正しいとは限りません。同様に、ルールがプロキシへ振り分けられても、対象ノードが利用できるとは限りません。

YAMLはインデントで階層を表現するため、スペースを使い、同じ階層のインデントを統一する必要があります。コロンの後にはスペースを入れ、特殊文字を含むテキストには引用符を使います。ノードのパスワード、サブスクパラメータ、制御インターフェースのキーは機密情報です。ログや設定の一部を公開する前に削除してください。サブスクファイルが上流で管理されている場合、本文を直接変更すると更新時に失われることがあります。クライアントの上書き、拡張スクリプト、ローカルルール統合機能を優先して使ってください。

リッスンポートとLANアクセス

mixed-port は同じポートでHTTPとSOCKSのリクエストを受け付けられ、一般的なデスクトップ利用に適しています。port と socks-port を個別に設定すると、プロトコルごとの管理が容易になります。allow-lan はLAN端末がリッスンポートへ接続できるかを制御し、無効時は通常本機だけが利用できます。共有する場合は、bind-address、システムファイアウォール、ルーターの端末間分離設定も確認してください。LANプロキシには自動検出機能がないため、下流端末にはClashを実行している端末のLANアドレスとポートを入力する必要があります。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: true

external-controller: 127.0.0.1:9090

外部制御インターフェースはGUIや管理ツールが状態を読み取るためのもので、通常のプロキシポートではありません。本機だけで管理する場合は、ループバックアドレスでリッスンします。リモート管理が明確に必要な場合は、アクセス制御を設定し、ファイアウォールで接続元を制限してください。制御機能を信頼できないネットワークへ直接公開しないことが重要です。ポートを変更した後は、システムプロキシ、ブラウザー拡張、ターミナルの環境変数、LAN端末もすべて更新します。

ルールモードとマッチングの優先順位

ルールは通常、上から順に評価され、最初に一致したルールがポリシーを決めます。前のルールに該当しなかったリクエストは、最後のフォールバックルールで処理します。ドメインルールは安定したサイト範囲に適し、IPルールは解析結果に依存し、プロセスルールはプラットフォームや権限の制約を受けます。広すぎるルールを上に置くと、後続の細かなルールが隠れてしまいます。例えば、トップレベルドメイン全体のルールを先に書いた後で、特定のサブドメインを直接接続にしても、後者は一致しない可能性があります。

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - DOMAIN,printer.lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,FINAL

上記の例にある PROXY と FINAL は、実際に存在するポリシーグループ名と一致させる必要があります。no-resolve は、IPネットワークをマッチさせる際に、このルールのための追加のドメイン解析を行わない指定です。プライベートアドレスのルールに適しています。実際の設定には、ループバック、リンクローカル、その他の直接接続が必要なネットワークも含めてください。ドメイン、IP、プロセスルールの書き方と並び順を体系的に理解するには、Clashのカスタムルール構文と優先順位を参照してください。

ポリシーグループの選択ロジック

手動選択グループではユーザーがノードを指定します。自動テストグループは探測結果に基づいて選択し、フォールバックグループは現在の選択肢が使えない場合に順番に切り替え、負荷分散グループは設定した方式で接続を振り分けます。自動テストの結果は、指定されたテストURLと探測時点の状態だけを反映し、すべてのサイトでの実際の使い勝手を示すものではありません。頻繁な探測はモバイル端末の電池と通信量を消費するため、テスト間隔は利用状況に合わせて設定してください。

ポリシーグループは別のポリシーグループを参照できるため、「地域選択 → 自動選択 → 特定ノード」という階層を作れます。最上位のポリシーを変更しても、実際の出口は下位グループの結果に左右されます。出口が想定と異なる場合は、現在の選択を階層ごとに展開し、接続ログで最終的にどのノードが使われたか確認してください。ポリシーグループ名を変更するとルールの参照に影響します。サブスク更新後にポリシーが見つからないと表示されたら、上流でグループ名が変更されていないか確認します。

DNSのfake-ipとredir-host

fake-ipモードでは、ドメインに予約アドレスを返し、コア内でドメインとの対応関係を保持します。後続の接続段階でもドメイン情報を維持できるため、ルールマッチングがより完全になることがあります。一部のLAN機器、ゲーム、時刻同期、実IPを必要とするプログラムはfake-ipに適さない場合があるため、フィルターリストで該当ドメインを実アドレス返却にします。redir-hostは従来の名前解決に近い方式ですが、通信を取り込む一部の場面ではドメイン情報を失うことがあります。どちらを選ぶかはアプリの互換性とログを基準にし、一方を絶対的に高速と考えないでください。

dns:
  enable: true
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

例にある公開DNSアドレスは構造を説明するためのものです。実際には、利用地域、プライバシー要件、到達性に応じて選択してください。暗号化DNSを使う場合は、そのサーバーのドメインを解決するブートストラップDNSも利用可能でなければなりません。そうでないと循環依存が起きます。ブラウザー独自のセキュアDNSはシステムの名前解決経路を迂回することがあります。DNSの出口を確認する際は、ブラウザー設定、システムの問い合わせ、クライアントログをそれぞれ確認してください。

TUN設定の重要項目

TUNの中心となるのは、仮想インターフェース、自動ルート、DNS接続制御です。対応する項目はコアのバージョンやクライアントによって異なるため、現在のクライアントが生成する設定、またはドキュメントでサポートされている設定を基準にしてください。auto-route を有効にするとコアがルートを書き込みます。strict-route はルーティング制約を強めますが、LAN、仮想マシン、複数NICの環境に影響しやすくなります。モバイルクライアントでは通常、これらの項目を画面から管理します。画面のスイッチと基盤のYAMLを、統合ルールが分からないまま同時に変更しないでください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: false
  dns-hijack:
    - any:53

有効化前にシステムプロキシの経路が正常であることを確認し、その後TUNだけを個別にテストします。有効化後に接続できなくなったら、すぐにTUNを無効にして直接接続を確認し、権限、デフォルトルート、DNSリダイレクト、他のVPNを確認してください。仮想NICの取り込み範囲とプラットフォームごとの権限差については、ClashのTUNモードと全通信の取り込みも参照してください。

08 / TROUBLESHOOTING

設定でよくある問題：サブスク、ノード、DNS、ルーティングを経路ごとに確認

階層的なトラブル解決の順序を作る

Clashのトラブルは、外側から内側へ階層的に確認します。第1層は基本ネットワークです。システムプロキシとTUNを無効にした状態で、端末がローカルネットワークとサブスク入口へ正常にアクセスできるか確認します。第2層はクライアントの状態です。設定が正常に読み込まれ、コアが動作し、ポートがリッスンしているか確認します。第3層はノード接続です。対象アドレスへの接続、認証、プロトコルパラメータが有効か確認します。第4層はルールとポリシーです。どのルールに一致し、どのポリシーグループへ入り、最終的にどのノードが選ばれたか確認します。第5層はDNSとシステムルートです。ドメイン解析が想定経路を通り、仮想インターフェースとデフォルトルートが競合していないか確認します。

一度に1つだけ変数を変更し、結果を記録してください。ノード、モード、DNS、TUNを何度も切り替えると複数の層が同時に変化し、接続が戻っても本当の原因が分からなくなります。次の3つを比較すると効果的です。接続制御を無効にした直接接続、ルールモードとシステムプロキシ、ルールモードとTUNの状態です。この3つを比べることで、問題が基本ネットワーク、アプリプロキシ、ルーティング制御のどこにあるかを素早く判断できます。

サブスクの登録に失敗する、または登録後にノードがない

サブスク登録に失敗した場合は、ブラウザーでサブスク入口を開き、ログインページ、エラーページ、CAPTCHAページへリダイレクトされていないか確認します。URLが完全か、期限切れでないか、チャットアプリによって切り取られていないか、端末時刻が正しいかも確認してください。クライアントログにHTTPステータスエラーが出る場合は、まずサブスクサービスへのアクセスを解決します。YAML解析エラーの場合は、返された内容が本当に互換性のある設定か確認します。WebページのHTMLを保存してYAMLへ名前変更しても、形式は変換されません。

登録は成功したのにノードがない場合、設定にルールだけが含まれている、providerが遅延読み込みされる、上流が空の内容を返している、といった可能性があります。設定内の proxies、proxy-providers とクライアントログを確認し、providerのアドレスへアクセスできるか確認してください。ノードは存在するのにポリシーグループが空なら、グループのフィルター式がすべてのノードを除外していないか、参照名がproviderと一致しているか確認します。リモート設定の更新後に発生した場合は、以前使えていた設定とポリシーグループの構造を比較してください。

ノードテストに失敗するのにWebサイトは時々使える

遅延テストは通常、あらかじめ設定されたURLへアクセスします。その結果はテスト先、DNS、ノードの出口、対象サイトの制限に左右されます。テスト失敗はすべての接続が失敗することを意味せず、テスト成功も対象サービスが利用できることを保証しません。ノードを選んで実際の対象へアクセスし、接続ログで状態を確認してください。すべてのノードが同時に失敗する場合は、サブスクパラメータ、基本ネットワーク、システム時刻、クライアントコアの問題である可能性が高くなります。一部のノードだけが失敗する場合は、個別ノードの状態を確認します。

同じノードがモバイル通信では使えるのにWi‑Fiでは使えない場合、ネットワーク経路またはDNSに差があると考えられます。対象サーバーの名前解決結果、IPv4とIPv6の到達性、公共ネットワークによるプロトコル制限を比較してください。接続を戻すためにノードテストを短時間で連続実行しないでください。並列リクエストが増え、上流側の制限を受ける可能性があります。

システムプロキシを有効にすると完全に接続できない

まずクライアントのコアが動作し、システムプロキシに入力されたポートをリッスンしているか確認します。クライアントが終了しているのにシステムへ手動プロキシが残っていると、システムプロキシに従うアプリは存在しないローカルサービスへ接続しようとします。この場合はシステムプロキシを無効にするか、システム設定で手動アドレスを削除すれば復旧できます。ポートが正常にリッスンしている場合は、ダイレクトモードへ切り替えてテストします。ダイレクトモードは使えるのにルールモードが使えないなら、ルールとポリシーを重点的に確認します。ダイレクトモードも使えない場合は、ポート種別、認証設定、ローカルファイアウォールを確認してください。

ブラウザーは使えるのにコマンドラインが使えない場合は、コマンドラインツールがシステムプロキシまたは環境変数を読み取るか確認します。特定のアプリだけが使えない場合は、そのアプリがプロキシを回避していないか、QUICを使っていないか、DNSを固定していないか、TUNを必要としていないかを確認してください。1つのアプリがシステムプロキシに従わないからといって、クライアント全体の障害とは限りません。

TUN有効後にLANまたはすべてのネットワークが使えない

すぐにTUNを無効にして基本ネットワークが復旧するか確認し、仮想インターフェースがシステムから削除されたか、デフォルトルートが元に戻ったかを確認します。LANだけが使えない場合は、プライベートアドレスの直接接続ルール、自動ルートの除外項目、複数NICの優先順位を確認します。すべてのネットワークが使えない場合は、管理者権限、TUNデバイス、DNSリダイレクト、他のVPNとの競合を重点的に確認します。Linuxではファイアウォールとポリシールーティング、Windowsではサービスモードと仮想アダプター、macOSとモバイル端末ではシステムVPN構成を確認してください。

リモートサーバー上のTUN障害は、誤ったルートによって管理接続が切断されるため、より危険です。あらかじめ管理元への直接接続を残し、コンソールまたは予備セッションから復旧できるようにします。コンテナ内で実行する場合は、ホストがTUNデバイスをマッピングし、必要なネットワーク権限を付与しているか確認してください。条件が整わない場合は、TUNを無理に有効にせず、明示的なプロキシポートを使います。

ドメイン解析エラー、DNS出口の異常、fake-ipの競合

まず同じドメインをブラウザー、システムの問い合わせツール、クライアントログで比較します。ブラウザーだけ結果が異なる場合は、ブラウザーのセキュアDNSを確認します。システムの問い合わせは正常なのにアプリが失敗する場合は、アプリのキャッシュと独自の名前解決設定を確認します。すべての問い合わせが失敗する場合は、ClashのDNSが有効か、上流へ到達できるか、ブートストラップDNSが循環していないかを確認してください。システムの問い合わせ結果にfake-ipアドレスが表示されても、必ずしもエラーではありません。拡張モードの正常な動作である可能性があり、重要なのは後続の接続がコアによって元のドメインへ正しく戻されるかどうかです。

LANドメイン、プリンター、画面共有、ゲームの一部がfake-ipに対応しない場合は、対象ドメインをフィルターリストへ明示的に追加し、プライベートアドレスを直接接続にします。すべてのドメインをフィルターへ入れると、fake-ipの主な利点が失われます。変更後はアプリに名前解決をやり直させる必要があるため、必要に応じて影響を受けたアプリを再起動してください。Webページを更新するだけでは不十分な場合があります。

HTTPS証明書エラーとシステム時刻

複数のサイトで同時に「証明書がまだ有効でない」「期限切れ」「発行者が異常」と表示されたら、まずシステムの日付、タイムゾーン、自動時刻合わせを確認します。特定のブラウザーだけが異常なら、ブラウザー拡張、独自プロキシ、証明書キャッシュを確認します。特定のネットワークフィルタリングソフトを有効にしたときだけ発生するなら、中間処理コンポーネントを層ごとに無効化し、どの層が接続を変更したか特定します。公共Wi‑Fiの認証ページも見落とさないでください。認証入口へリダイレクトされ、証明書のドメインが一致しなくなることがあります。

証明書詳細に表示される対象ドメイン、発行者、有効期間は、時刻の誤り、ネットワーク認証、中間層による介入を区別する手がかりになります。詳しい手順はプロキシ経路、システム時刻、証明書信頼のトラブル解決を参照してください。

ログの確認と復旧方針

トラブル解決中は、ログレベルをinfoにすれば通常は十分です。debugは大量の内容を出力するため、短時間だけ使用してください。設定解析エラー、DNS問い合わせ、ルール適用、ポリシーグループ、接続先、基盤ネットワークのエラーを確認します。ログを共有する前に、サブスクURL、ノードの認証情報、端末アドレス、アクセス履歴を削除してください。エラー内のtimeoutはタイムアウトを示すだけで、DNS、ルート、サーバーのどれが原因かを直接示しません。connection refusedは対象が明示的に拒否したか、ポートがリッスンしていないことを示します。no such hostは名前解決失敗の可能性が高く、permission deniedはシステム権限を確認します。

何度も変更して状態が混乱した場合は、まず必要なローカルルールと設定をエクスポートし、システムプロキシとTUNを無効にしてクライアントを終了します。直接接続が復旧したことを確認してから再起動し、既知の正常な設定を1つだけ登録してください。最初からすべてのアプリデータを削除しないでください。ログ、旧設定、設定差分が原因特定の重要な手がかりになるためです。基本接続をすぐに再構築する場合はクイックスタートの手順へ戻って順番に実行します。クライアントを変更したりインストールパッケージを再取得したりする場合は、全プラットフォーム対応ダウンロードページでシステムとアーキテクチャに合う版を選んでください。