Midjourney が開けないという症状は、ひとまとめに「ネットワークの問題」と片付けられがちなトラブルの代表例です。しかし分解してみると、少なくとも3つの異なる経路が関わっています。Web版のページ読み込み、Discord の常時接続、画像 CDN からのダウンロードです。3つはそれぞれ別のサーバーと別のプロトコルを使うため、切り分け方も変わります。まとめて試すと時間を無駄にするだけです。
まず切り分ける:Web版と Discord クライアントはどこで止まるか
現在の Midjourney には2つの入口があります。ひとつは midjourney.com の Web版、もうひとつは Discord でボットにタスクを送る方法です。どちらも同じアカウントを使いますが、ネットワーク経路はまったく別です。同じアカウントなのに Web版は開けてクライアントは繋がらない、という現象はここに原因があります。
Web版は標準的な HTTPS ページで、手前に Cloudflare の認証レイヤーがあります。出口 IP が多数のユーザーで共有されるデータセンターのセグメントに属していると、認証が頻繁に発動し、認証ページがぐるぐる回り続けたり、画像一覧がいつまでも読み込めなかったりします。こうした問題は暗号化プロトコルを変えても効果がなく、出口地域を変えるとすぐ改善することがほとんどです。
一方、Discord クライアントは常時接続です。ログイン後はゲートウェイまで WebSocket を1本維持し、メッセージ・コマンド・ボットの返信はすべてこの接続を通ります。回線の揺らぎやパケットロスがあると接続が切れて再接続を繰り返し、画面上は「接続中」のままになったり、メッセージがまとめて遅れて届いたりします。
画像そのものは Discord の中にはありません。生成結果は Midjourney の CDN 上にあり、プレビュー・拡大・ダウンロードは3つ目の通信で、前の2つの経路とは無関係です。つまり「開けない」には少なくとも3種類あります。ページが開かない、接続できない、画像が落とせない。まずどれなのかを確認してから、回線の話をしましょう。
| 利用する入口 | 主な接続方式 | 止まったときの典型的な症状 | まず確認する項目 |
|---|---|---|---|
| midjourney.com の Web版 | HTTPS + Cloudflare 認証 | 認証ページが回り続ける、画像一覧が真っ白 | 出口 IP が多数で共有されていないか |
| Discord デスクトップ / モバイルクライアント | WebSocket の常時接続 | 「接続中」のまま、メッセージが遅延 | 回線の揺らぎとパケットロス |
| 画像の表示とダウンロード | CDN への HTTPS リクエスト | プレビューは見えるが元画像のダウンロードに失敗 | DNS の名前解決結果と下り帯域 |
3つの段階:タスク送信、画像の受け取りと待ち時間
1回の画像生成を3つの段階に分けると、切り分けがぐっと楽になります。タスク送信、画像の受け取り、待ち時間です。3つがネットワークに求めるものは同じではありません。
タスク送信。Discord でコマンドを入力するか、Web版で送信ボタンを押すと、リクエストはまずサーバーへ届きます。この段階のデータ量はごくわずかですが、遅延と接続の安定性には敏感です。常時接続が一度切れれば、コマンドは送り直しになります。参考画像(ベース画像)を添える場合、ファイルは Discord のアップロード経路を通るため、ここで初めて上り帯域を使います。Discord でのタスク送信は、決まった書式のコマンド1行です:
/imagine prompt: paper-cut style mountain range, warm paper palette --ar 3:2
画像の受け取り。生成結果は CDN 上にあり、4分割のプレビュー画像は小さいものの、拡大版とダウンロード用の元画像ははるかに大きくなります。まとめて保存するときは、下り帯域と DNS の名前解決品質が体験を左右します。名前解決がトンネルを通っていないと、CDN が近くにある不適切なノードを指してしまい、「画像は出るのにダウンロードが遅い」という典型的な症状になります。
待ち時間。Fast モードは優先的に生成され、Relax モードはサーバー側の負荷に応じて順番待ちになります。待ち時間はサーバー側が決めるもので、回線とは関係ありません。ノードやプロトコルを変えても列は短くなりません。
順番待ちはサーバー側の挙動であって、ネットワーク障害ではありません。待ち時間を「回線が遅い」と誤解してノードやプロトコルを何度も切り替えると、ログイン環境が頻繁に変わり、かえって再認証を招きやすくなります。
3つの段階にはそれぞれ典型的な症状があります。まずは当てはまるものを探してみてください:
- ✅ コマンド送信後すぐにボットが処理を始める → 送信経路は正常で、上りに問題はない
- ✅ 4分割画像は出るが、元画像を開くと遅い → まず DNS の名前解決と下りを確認。回線は触らなくてよい
- ❌ 順番待ちのまま進まない → アカウントのモードとサーバー側の負荷が原因の可能性が高く、回線ではない
- ❌ クライアントが頻繁に再接続を表示し、メッセージがまとめて届く → WebSocket が切れている。回線の安定性を優先して確認
出口地域の選び方:よく使う6つの接続先を比較
出口地域は3つのことに影響します。Cloudflare 認証が発動する頻度、アカウントのリスク判定、そして CDN にアクセスするときに解決されるノードです。多数で共有されたデータセンターの出口は認証に引っかかりやすく、サーバーに近い接続先ほど常時接続の往復が短く、揺らぎも少なくなります。
画像生成でよく使うのは、次の6つの方向です。選ぶときに「どれが一番速いか」で悩む必要はありません。まず、アクセスしたいサービスがどちら側にあるかを見てください。
| 接続先 | 向いている用途 | 注意点 |
|---|---|---|
| シンガポール | アジア太平洋方向。常時接続の往復が短い | 既定の接続先として長く使うのに向く |
| 日本 | アジア太平洋方向。日本リージョンのサービス向け | 共有データセンターの出口は認証が発動しやすい |
| 香港 | 物理的な距離が最も近く、遅延が低い | 出口リソースが混雑しているときは接続先を変える |
| アメリカ | 米国リージョンのサービスと CDN 向け | 遅延はアジア太平洋の接続先より大きい |
| イギリス | ヨーロッパ方向のメイン用 | 米国のデータセンターまではホップ数が増える |
| イタリア | ヨーロッパ方向の予備用 | 同じく距離が遠い |
選び方には2つの経験則があります。ひとつは、しばらく同じ接続先を固定して使うことです。多くのサービスのリスク判定はログイン環境の一貫性を考慮するため、頻繁に地域をまたいで切り替えると、かえって再認証を求められやすくなります。もうひとつは、Web版が認証で止まるときは、地球の反対側に飛ぶのではなく、同じ地域内の別の接続先に変えることです。地域をまたぐ切り替えは認証の解決にはならず、そのうえ常時接続のハンドシェイクをやり直すことになります。
回線タイプとプロトコル:専用線・中継・直結はそれぞれどの区間で効くのか
回線タイプとプロトコルはよく一緒くたに語られますが、実は別の軸です。回線はデータがどの道を通るかを決め、プロトコルはその道をどう暗号化し、どう偽装するかを決めます。
直結。クライアントが海外のデータセンターに直接接続し、公共の国際出口を通ります。コストは最も低いものの、公共出口の揺らぎがそのまま常時接続に伝わります。Discord のように長時間つなぎっぱなしにする接続が最も影響を受けます。
中継。まず中国本土の入口に接続し、中継サーバーが海外の出口へ転送します。入口区間の品質は通常より良く、その代わりホップが1つ増えるため、中継ノードの負荷が高いときは追加の揺らぎが出ます。
IEPL 専用線。入口から出口までの区間を専用線で通り、公共の国際出口を経由しません。遅延のカーブがより平坦になります。Discord のようなつなぎっぱなしの接続や、参考画像のアップロード、元画像のダウンロードなど、安定性が重要な操作に向いています。コストは高めなので、通常は通信量に応じた段階制になります。
プロトコルについては、よく使われるものにそれぞれ一長一短があります。Shadowsocks は軽量でオーバーヘッドが小さく、VMess は V2Ray 系で多重化に対応します。Trojan と VLESS はどちらも TLS で偽装し、通信は普通の HTTPS に見えます。Hysteria2 と TUIC は QUIC(UDP)ベースで、パケットロスが多い回線でも揺らぎに強い反面、UDP を制限するネットワークでは速度が出ず、そうした環境では TLS 系プロトコルに変えたほうが安定します。よくある誤解は「プロトコルが速い」を結論にしてしまうことです。プロトコルはあくまでカプセル化の方式を決めるだけで、画像生成の体験を実際に左右するのは回線の安定性と出口地域です。
結論:Discord が頻繁に再接続し、コマンドを何度も送り直す必要があるなら、帯域を増やすより先に回線タイプを変えるほうが効きます(直結 → 中継 → IEPL 専用線)。元画像のダウンロードが遅いだけなら、まず DNS と下りを確認しましょう。回線に手を入れる必要はありません。
5ステップの自己診断:原因は回線かアカウントか
「開けない」ときは、次の5ステップを順に試せば、ほぼどの段階に問題があるか特定できます。速度測定ツールは一切不要で、比べるのは送信から画像が出るまでの合計時間です。自分で再現できます:
- ✅ ステップ1、入口を切り分ける。Web版が開かないなら認証ページを、クライアントが繋がらないなら常時接続を確認する。見るべき方向は別です
- ✅ ステップ2、出口 IP を確認する。接続後に任意の IP 確認サイトを開き、出口地域が想定どおりかを見ます。その IP セグメントが多数で共有されていないかも確認しましょう
- ✅ ステップ3、DNS リークを確認する。名前解決のリクエストもトンネルを通っているかを確かめます。通っていないと、CDN が近くにある不適切なノードを指してしまいます
- ✅ ステップ4、接続先を変えて再測定する。同じ prompt を2つの地域で1回ずつ送信し、ダウンロード速度だけでなく、送信から画像が出るまでの合計時間を比べます
- ✅ ステップ5、プロトコルを変えて再測定する。UDP 系(Hysteria2 / TUIC)と TLS 系(Trojan / VLESS)を1回ずつ試し、安定するほうを使います
この中で最も効果が出やすいのが分流ルールの見直しです。画像生成に関係するドメインを個別にリストアップしておくと、グローバル代理より切り分けがしやすく、他のアプリの通信速度にも影響しません:
# 国際回線を通すドメイン(ドメイン単位でグループ化し、随時追加・削除しやすくする)
discord.com
discordapp.com
discordapp.net
discord.gg
midjourney.com
cdn.discordapp.com
cdn.midjourney.com
huggingface.co
civitai.com
DNS リークの判定方法:プロキシを有効にした状態で名前解決の結果を調べ、返ってくるのが出口地域の近くのノードではなく、利用している ISP の近隣ノードであれば、名前解決がトンネルを通っていない証拠です。画像生成では、プレビューは表示できるのに元画像のダウンロードが極端に遅い、という形で現れます。
5ステップを試しても不安定なままであれば、次はアカウント側の要因を考えます。ログイン環境の頻繁な変化やサーバー側の高負荷は、「ネットワーク障害」のように見える挙動を生みますが、これはもう回線を変えても解決しない部分です。
その他の AI 画像生成ツール:ローカル環境、オンライン生成サイト、モデルのダウンロード
誰もが Midjourney を使っているわけではありません。よく使われる AI 画像生成ツールをネットワーク要件別に整理しておくと、回線を選ぶときの指針になります。
ローカル環境(Stable Diffusion WebUI、ComfyUI)。ソフト本体はネットに接続せず、モデルやプラグインをダウンロードするときだけ通信が必要です。モデルファイルは数 GB になることも珍しくなく、途中で切れて最初からやり直しになるのが一番の困りもの。レジューム機能付きのダウンロードツールを使えば、何度も接続し直すより手間がかかりません。Hugging Face と Civitai が主なモデル配布元で、ダウンロードはそれぞれの CDN ドメインを通ります。これらを分流ルールに入れておけば、ダウンロードと画像生成が互いに干渉しません。
オンライン生成サイト。Web版の画像生成サービスの多くは Cloudflare の背後にあり、認証の厳しさは出口 IP のクリーンさに左右されます。判断方法は Midjourney の Web版と同じです。
チャット型の画像生成。チャットツール上で画像を生成するサービスは、接続方式が Discord と似ており、同じく常時接続と画像 CDN の組み合わせです。遅延や切断が起きたときの確認順序も同じです。
地域制限。一部のサービスはアクセスできる地域を明確に制限しており、拒否ページをそのまま返します。こうした場合はプロトコルを変えるより出口地域を変えるほうが早く解決しますが、頻繁に地域をまたいで切り替えるのは避けましょう。理由は前述のとおりです。
画像生成の用途で回線を選ぶ:3つの結論
ここまでの内容をまとめると、画像生成の用途で回線を選ぶポイントは3つの結論に集約できます。
- 送信と画像生成では、帯域より安定性を優先する。Discord は常時接続なので、一度切れるとやり直しになります。IEPL 専用線タイプの回線の価値は、主にここにあります。
- モデルのダウンロードでは、下りとレジュームを優先する。モデル配布サイトのドメインを分流ルールに入れ、レジューム対応のダウンロードツールを組み合わせれば、グローバル代理よりずっと楽です。
- 出口地域は安定させる。しばらくは同じ接続先を固定して使います。Web版が認証で止まったときは、まず同じ地域内で接続先を変え、いきなり地球の半分をまたがないようにしましょう。
結論:「Midjourney が開けない」原因はほぼ3つに分類できます。出口 IP が認証を誘発している、常時接続が切れている、DNS の名前解決がトンネルを通っていない、の3つです。前の2つは回線と接続先の変更で解決し、3つ目は分流ルールを少し変えるだけで解決します。