Sora／OpenAI の動画プレビューが延々バッファ？Clash（Mihomo）で oai 系ドメインとメディア CDN を分流する実測手順（2026）

検索意図：会話は速いのに「動画だけ」遅い理由

ここでいう AI 動画は、生成結果の短いループ、サンプルのストリーミング、製品内ヘルプの解説 clip など、ブラウザ内プレーヤで再生される帯域の大きい取得を想定します。Clash 利用者の典型的な違和感は、(1) 会話欄の応答は即時なのに、同じ画面の動画プレーヤだけが回転したまま、(2) 低画質のまま固定され、帯域は余っているのに上がらない、(3) 一度止めて再開すると通る、の三つにまとまりやすいです。

これは「ノードの RTT だけが悪い」より、ドメインごとに通っている出口ポリシーが食い違うほうを先に疑う価値があります。とくに HLS や DASH では、プレイリスト用の小さな JSON／m3u8と、実体の .ts 断片、プレビュー用サムネイルが、それぞれ別名に割り当てられることが多く、ルール一筆書きの openai キーワードでは隠しきれないホストがログに出ます。

通信の層：oai 系・openai 系・メディア CDN

大雑把に、OpenAI 周辺のブラウザ体験は次の層に分かれます。(A) 会話とアカウント（chatgpt.com、auth.openai.com 周辺）、(B) oai 系のホスト（oai.com 傘下の短縮体験、キャンペーン、静的アセット。実名は随時更新されます）、(C) API・開発者向け（api.openai.com など。Codex やツールの更新系は既稿参照）、(D) 帯域の大きいメディアと CDN。本稿の主眼は (B) と (D) です。(A) は会話用ルールの塊のまとまり、(C) は開発者用の塊、として同じ Clash プロファイルの中で別行に分けて観測すると切り分けが速くなります。

重要な注意として、ホスト名はプロダクト更新で入れ替わるため、下に示す断片はあくまで接続ログに出た実名を上に乗せ替えるイメージです。ルールは購読セットに「OpenAI / ChatGPT / AI サービス」等のタグ付きカテゴリがあれば、それを手掛かりにし、不足分だけ DOMAIN-SUFFIX や DOMAIN-KEYWORD を足す運用が安全です。

症状と接続ログでの見え方

再現中に、クライアントの接続ビューで oai、openai、akamai、cloudfront、fastly 等をフィルタし、同じ操作直後に出ている行の Policy（DIRECT か何番のプロキシ群か）を横並びで見ます。ここで片方だけ帯域制限付きのノードに載っている、あるいは 同じ TLD なのに片方だけ DIRECT になっている、が見つかると、UI 上の「テキストは速いが再生だけ鈍い」が説明しやすくなります。

逆に、ログに 想定外の新しいサブドメインが一瞬だけ出て消える場合は、初回の計測用ビーコンや短い有効期限の URL です。断続的失敗のときは、fake-ip による解決と実体の不整合も併せて疑い、後述の DNS 節に進んでください。

DNS：fake-ip、redir-host、クライアント解決

動画系は 多数ホストに並列でコネクションを張る典型です。Mihomo 系では、該当ドメイン帯に redir-host 相当や nameserver-policy を当て、fake-ip のまま通すより解決と転送の対応を取りやすい構成に寄せる手法が有効なことがあります。ポイントは暗記した設定名ではなく、「ブラウザと OS が実際に握っている IP」とClash 側の策略が一致しているかを一連の再現手順の中で確認することです。

ブラウザの開発者ツールのネットワーク欄に出る 本当の Host ヘッダと、Clash ログの 行末の SNI 相当を突き合わせ、ズレる場合は トラブルシューティング記事の DNS 節の手順に戻ると、原因が「ノード品質」か「解決系」かに二分しやすくなります。

Mihomo ルール順：会話用とメディア用を同一段に畳まない

よくある失敗は、広い DOMAIN-KEYWORD,openai 行が上に来て、下に書いた oai 専用の細行が一生マッチしないことです。対策は、(1) ログで実際に出た大容量側の FQDNを上に積む、(2) キーワード行の掛かり方を確認し、意図しないホストを飲み込んでいないかを見る、(3) GEOIP や FINAL が早すぎないか、の三つです。同一サービス内でも帯域最適化のため DIRECT に落とすメディア行と、義務的に通すプロキシ行の両方を使うと、セッション整合とスループットのトレードオフが出ます。まずは出口を揃え、再現率が下がったあとに帯域最適化を入れる方が失敗を追いにくいです。

策略グループ（例：PROXY 配下の複数国ノード、あるいは遅延計測付き）を分ける場合、会話層用と帯域層用の二階建てにすると、ルール行は増えても意図が崩れにくいです。どちらを選んでも、同じ FQDN 列が矛盾した Policy を指していないことをログで最終確認してください。

ルール例（参考スニペット）

以下は考え方の断片です。そのままのコピペ禁止。購読中のルールと必ず重複・順序を照合し、実ログのホスト名に合わせて置換してください。

# Example snippets — match what your logs show; check rule order
rules:
  - DOMAIN-SUFFIX,chatgpt.com,PROXY
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-SUFFIX,oai.com,PROXY
  - DOMAIN,auth.openai.com,PROXY
  - DOMAIN-SUFFIX,oaistatic.com,PROXY
  # If media shards land on a distinct CDN TLD, match observed FQDNs
  - DOMAIN-SUFFIX,akamai.net,DIRECT
  - DOMAIN-SUFFIX,cloudfront.net,DIRECT
  # HLS and segment hosts: prefer explicit SNI you see in logs
  - DOMAIN-SUFFIX,some-cdn.example,DIRECT
  - MATCH,PROXY

上の STATIC / CDN = DIRECT は、自宅回線のその CDN 出口が速い前提の例です。逆に、ISP 経路が遅い環境では、メディアもまとめて PROXY の方が快適なケースもあります。遅延と失敗率のログ指標で判断してください。どちらの場合も、認証系だけ飛ばしてメディアを宙に浮かせないのが本稿の趣旨です。

TUN と境界：アプリ内ブラウザと PWA

動画体験は、デスクトップの公式アプリ、ブラウザ拡張内の小さな WebView、PWA など、HTTP システムプロキシの届き方がバラつく載せ方があります。Mihomo 系では、まず TUN モードを有効にし、アプリ名ベースの除外が不要な限り、同一マシン上のトラフィックの取りこぼしを減らすのが一般的です。挙動の整理は TUN 解説に任せ、ここで強調するのは「テキスト専用の拡張が速い」状況でも、メディアは別デバッグ枠に乗る可能性がある、という点です。

初回導入は 入門ガイドの手順に沿い、同じデバイスの 同一プロファイルで、まず既稿の会話層（ChatGPT 一般）のルールで安定を確認し、その上で oai／メディア行を足すと、差分切り出しがしやすいです。

動作確認のすすめ方

手戻りを減らす順序は次の通りです。(1) 同一プロファイルで、テキスト会話に限定した小さな操作で一貫して通るか。(2) 動画を同じ品質で、別ブラウザプロファイル（拡張オフ）でも再現するか。(3) ログ上でoai 系と CDN 行の Policy を一覧し、揃っていない行を上から潰す。(4) 帯域に余裕を持たせ、同時に走らせる他アプリ（同期系・ストア更新）を一時的に切る。長時間の 4K ループを最初に試すより、数秒の短尺サンプルでルールの整合を取ると、ログが追いやすいです。

どうしても再現条件が多い場合は、一時的に直結で症状が消えるかの対照実験を行い、Clash の上か下流かの二分を先に固めると、あとの DNS／ルール調整が迷走しにくいです。対照後は元のプロキシ必須ポリシーに戻してください。

本稿の位置づけ：会話通稿・Codex 稿との重複を避ける

ChatGPT 向け一般稿は、会話体験全般の出口を扱います。Codex 稿は コンソール、CLI 更新、API エンドポイントに重点があります。本稿は メディア再生と oai 系ドメインの塊に焦点を当て、ChatGPT ページ全般や 開発者向け API 仕様の細部には深入りしません。Grok や Perplexity といった他社 AI 系の記事ともホスト集合が異なり、ルール行のまる写しは向きません。ログに出た実名に合わせる姿勢を維持してください。

規約と免責

本稿は家庭内・自席のネットワーク最適化を目的とした技術整理です。サービス利用規約の回避や、地域制限付きコンテンツの不正取得を助長する意図はありません。契約上許された範囲で、自己責任のうえ利用してください。記載のドメイン例は、将来の変更に対する保証をするものではありません。

まとめ

Sora／OpenAI 動画周辺の延々バッファは、oai 系のホストと大容量のメディア・CDN 層が、会話層と同じ出口に乗っていないと起きやすいです。接続ログで FQDN と Policy の対を揃え、DNS（fake-ip と実体）、ルールの上下関係、TUN による取りこぼしを順に潰すと、会話専用の通稿と棲み分けしつつ、事象を短時間で切り分けられます。

可視化しやすい接続ビューと、ルール編集が一画面で済むクライアントを使うと、ドメイン集合の入れ替わりの多い AI 製品群でも運用の手間を抑えやすいです。まずは手元のログを一度エクスポート相当で眺め、抜けているサフィックスの塊を足すのが近道と言えます。→ Clash を無料ダウンロードし、oai 系とメディア CDN の出口を一度に揃えてから再生を再試行する