2026 年、Sora・Runway など AI 動画生成を Clash の分流ルールとノード選びで安定させる

対話型 AI との違い：動画生成は「帯域と待ち時間」が主役

チャット型生成はトークンストリームと短い HTTP が中心ですが、AI 動画はプレビュー用メディア、長めのポーリングや WebSocket、参照素材のアップロード、成果物のダウンロードが同時に走ります。経路のどこかが細いと、エラーコードより先に無言の待機・スピナー・途中で止まるプログレスとして現れます。

• 下り帯域：プレビューやサムネイル取得が CDN や別リージョンに分散し、ホスト名がチャット用途と揃わないことがあります。
• 上り負荷：参照画像や長尺素材を投げると、アップロードがボトルネックになりキューが進まないように見えます。
• 長いセッション：生成完了まで数分かかると、中間プロキシのアイドルタイムアウトやノードのフラップが効きやすいです。

したがって「速いノード一つ」より、動画用ドメイン群をまとめたポリシーグループと、揺れにくい url-test／フォールバックが効きます。Clash のルールベース分流は、まさにそのための道具です。

実際の症状：モデル以前に疑うべき経路のサイン

課金や再ログインの前に、次のパターンをメモしておくと切り分けが速いです。

Clash の Connections で、失敗時にどのホスト名がどのポリシーに入ったかを確認します。動画用途はホスト名の種類が多いので、思い込みの GEOIP よりログで拾ったドメインを上に書く方が安全です。

まず DNS：名前解決が二系統だと「半分だけ壊れる」

ブラウザの DoH と OS／Clash の解決が分岐すると、同じサービスでもエッジの国や CDN ルートが変わります。fake-ip 利用時は、アプリによっては一時的に認識がズレることもあります。

• 検証中は解決経路を揃える：切り分けが終わるまで、極端な多層 DoH を避ける。
• LAN とキャプティブは DIRECT：ルータ管理や社内名は確実に直結へ。
• IPv4 / IPv6 の片系だけ遅い：動画 CDN はどちらか一方に寄ることがあり、症状が「たまにだけ」になります。

ドメインルール：Sora（OpenAI 系）と Runway を「動画用」に束ねる

Rule モードで、AI 動画関連を専用のプロキシグループ（例：🎬 AI-VIDEO）へ寄せます。以下は設定例のイメージであり、実際のホスト名はクライアントのログや開発者向けドキュメントで更新してください。サービス側のドメインは変わり得ます。

ルールの順序が命です。粗い GEOIP より、狭い AI 動画用ルールを上に。リモートルールセットは更新間隔を現実的にし、巨大リストを無批判に足して SaaS を壊さないようにします。

# Example snippets — adjust to your profile and provider naming
proxy-groups:
  - name: "🎬 AI-VIDEO"
    type: url-test
    proxies: [Node-A, Node-B, Node-C]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

rules:
  - DOMAIN-SUFFIX,runwayml.com,🎬 AI-VIDEO
  - DOMAIN-SUFFIX,openai.com,🎬 AI-VIDEO
  - DOMAIN-SUFFIX,chatgpt.com,🎬 AI-VIDEO
  # ... MATCH

上記の 🎬 AI-VIDEO 等の名前は購読ファイルの書き方に合わせて置き換えてください。例は構造理解用です。

ポリシーグループ：url-test・フォールバックで「揺れ」を抑える

動画生成は数分単位の待機が普通なので、数秒おきに出口が変わるグループはセッションを壊しやすいです。

• 間隔と許容差：interval を短くしすぎない。tolerance で「同点の行き来」を抑える。
• プローブ URL：ダウンロード向けの軽いプローブが、生成 API のレイテンシと一致するとは限りません。実際の失敗パターンに合わせて調整。
• フォールバック：地域全体が不安定なときの退避先を別グループに。

チャット向けに作った AI-CHAT 用グループと動画用を分けると、帯域の食い方が違うノードを選べます。同一ノードに全部載せると、片方の混雑がもう片方の体感を汚染します。

ノード選び 2026：スピード表示より安定と一貫性

動画用途はピーク帯域とパケット損失が効きます。数値が緑でも、ジッターが大きいとプレビューがカクつきます。

• 出口の一貫性：ログイン〜生成〜ダウンロードのあいだ、IP が頻繁に変わるとリスク判定やキュー再接続が増えがちです。
• 多段プロキシ：チェーンを重ねるほど TLS とバッファ遅延が増え、長めの API に不利になります。
• 自宅上り：クラウドに素材を送る局面では、プロキシ以前にアップロード帯域が天井になっていないかも見る。

感情でノードを総入れ替えする前に、同じ操作を三回繰り返し、ログのホスト名差分を残すと原因が見えやすいです。

アップロードとプレビュー：別ホストに分かれる典型

生成リクエストは通るが、サムネイルや短いループだけ取得できないときは、API と CDN が別ドメインになっているパターンが多いです。Connections で DIRECT のまま残っているホストがないか確認し、必要ならルールを足します。

切り分け	見え方	先に疑うこと
API は 200、画面だけ欠ける	メディア用ホストが別経路	ドメインルールの欠落、DNS 分裂
素材を足した瞬間だけ遅い	上り混雑またはプロキシ MTU	上り帯域、別タブの同期、MTU／IPv6
生成は成功したが保存に失敗	長い PUT／再試行	タイムアウト値、安定ノードへの固定

アプリと TUN：ブラウザだけ直さない

公式アプリはシステムプロキシを迂回しがちです。TUN モードで取りこぼしを減らします。企業 VPN やゼロトラストと二重に TUNを積むと競合するので、職場ポリシーが優先です。

1. システムプロキシを有効化し、Rule で動画関連ドメインをカバー。
2. アプリ独自のプロキシ設定や証明書ピン留めの有無を確認。
3. 必要なら TUN でプロセス全体をルールの対象に。

モバイル

iOS／Android はサンドボックスの制約が強く、クライアントによっては TUN の効き方が異なります。デスクトップで改善してもモバイルだけ残る場合は、OS 側の VPN スロットやプロファイル競合を疑ってください。

API と長時間ジョブ：タイムアウトは「経路」と「クライアント」の合算

サーバ側の処理時間に加え、クライアントや中間プロキシの読み取りタイムアウトが短いと、生成は継続しているのにクライアントだけ切れます。Clash 側では、不安定なノードの回避と過剰な再試行によるフラップ抑制が現実的な助けになります。アプリ側の設定値は製品ドキュメントに従ってください。

ドメインとエンドポイントは変わる

AI 動画サービスは機能追加のたびに新しいホスト名が増えます。一度決めたルールを永年固定にせず、数ヶ月おきに Connections を見直す習慣が安全です。本稿のドメイン例は出発点であり、最新の公式情報や自環境のログが正です。

既存記事との位置づけ：テキスト対話との棲み分け

当ブログの ChatGPT／Grok 向け分流や Claude 向け分流は、ストリーミングのトークンや長会話を主眼にしています。本稿はメディア・キュー・上り下り帯域にフォーカクスを移したAI 動画向けです。併読すると、ルール設計の意図が揃いやすいです。

FAQ

キューだけ進まない

長接続・DNS・ノードフラップを併せて疑う。Connections でポリシーが切り替わっていないか。

Runway と OpenAI を同じグループにしてよいか

運用が楽な場合もあるが、片方だけ遅いなら分離して測定。ログドリブンで最適化。

プレビューだけ真っ白

メディア用ドメインが別ルールに落ちていないか確認。

職場ネットワーク

許可された範囲で。セキュリティポリシーが最優先。

2026 チェックリスト

まずはメンテされたクライアントから

一度に変えるのは一要素だけにして因果を追いやすくしましょう。

Clash を無料ダウンロードし、Sora・Runway など AI 動画向けルーティング調整の土台にする