なぜ Prime Video だけ「地域」が絡みやすいのか

Prime Video（Amazon Video）は、単一のブランド名の裏でアカウント・請求・端末登録を amazon.co.jp／amazon.com 側が握り、視聴 UI とメタデータが primevideo.com 系に散らばり、実際のセグメント取得が aiv-delivery.net や aiv-cdn.net など「aiv-」で始まるホストへ伸びる——という多層構造になりがちです。Clash／Mihomo で分流ルールを組むとき、このどこか一段だけ別のプロキシグループへ落ちると、「トップは開くが再生だけ失敗」「ログイン国とカタログの国が食い違う」といった症状が出やすくなります。

本稿は当サイトのNetflix 向けガイド、Disney+ 向けガイド、Max（HBO Max）向けガイド、YouTube 向けガイドと同じ「DNS → 分流 → ノード」の実測の骨格を踏襲しつつ、Amazon スタック特有のホスト束にフォーカスします。利用規約や提供地域は各サービスの案内に従う前提で、ネットワーク層の切り分けに限定します。

用語：YAML の rules による振り分けを「分流ルール」、再生や API を載せる出口を「プロキシグループ」、名前解決や評価経路のズレを広く「DNS まわりの不整合」と呼びます。GUI のラベルはクライアントにより異なります。

他プラットフォームとの違い（要点だけ）

Netflix は nflxvideo・Open Connect 系など、カタログと映像でホストが分かれやすく、当サイトの専用稿では画質・CDN・ノード種別まで踏み込んでいます。Disney+ はディズニー系 CDN と計測ホストの束が別構成です。Max は地域ロックとライブラリ差が前面に出やすく、当サイトの Max 稿ではDNS とノード固定を強調しています。YouTube は googlevideo.com の巨大なエッジ束が主体で、youtube.com 本体との二段一致が鍵になります。

対して Prime Video は、（1）ショッピング用 Amazon アカウントとメディア視聴が強く結びつき、（2）ブラウザ・モバイル・Fire TV でプロキシの見え方が分岐しやすく、（3）ログや接続一覧に aiv- で始まる FQDN が混ざる、という三点セットで切り分けると実務的です。ルール評価順の総論はルール分岐の詳解に譲ります。

ステップ 1：ブラウザ・アプリ・Fire TV で「同じスタックか」を確認する

PC ブラウザだけがシステムプロキシを見ていて、同じ OS の別アプリやテレビ Stick が直結していると、認証だけ成功してストリーム要求が別出口へ出ることがあります。全体を揃えるなら TUN の検討や、ルーター直下での統一なども選択肢になります。TUN モードの解説で触れたキャプチャ範囲の考え方がそのまま当たります。

Fire TV／Fire タブレットでは OS が HTTP プロキシ設定を無視する経路を取ることがあり、LAN 側で透明プロキシやゲートウェイ配置が絡む場合は、スマホ／PC だけ直しても symptoms が残ります。まず「問題が再現する視聴クライアント」を一つに絞り、そのデバイスからClash のログに実際に出たホストを読むと早いです。

メモ：Prime Video は「Amazon でログイン」と「視聴ライセンス」のレイヤーが二重

ショッピングアカウントの国・地域と、Prime／チャンネル契約の視聴権は別概念になり得ます。ネットワークだけを触っても片方がブロックしている場合は改善しないため、まず UI のエラーメッセージが地理制限なのか決済・登録まわりなのかを切り分けます。そのうえで本稿のDNS・分流ルール・ノードの順を進めてください。

ステップ 2：DNS と fake-ip を primevideo／aiv と同期させる

DNS が二系統に割れる典型は、（A）ルール評価用の名前解決と（B）OS やブラウザの暗号化 DNSが並走すること、（C）fake-ip と実接続のホスト復元が一瞬でもずれること、です。IPv6 の AAAA が返る環境では、片側だけフィルタされていると再接続ループや再生前の長い待ちが出やすくなります。

  • DoH URL：フォールバック鎖の最初のホップがプロキシ必須ドメインだと、初回だけ解決が遅延することがあります。
  • Android Private DNS／Windows の暗号化 DNS：Clash の設定と競合していないか確認します。
  • ルーター DNS：テレビや Stick がルーターのキャッシュを見ていると、PC 側だけ整えても残ることがあります。

購読ルールを大量に足す前に、まず primevideo.com とログに出た aiv-* ホストが、同一のプロキシグループ前提で名前解決されているかを確認すると手戻りが減ります。インポートの共通手順はサブスクリプション URL 追加の総合ガイドも参照してください。

ステップ 3：分流ルールで Amazon Video のホスト束を取りこぼさない

コミュニティールールセットに DOMAIN-SUFFIX,primevideo.com が入っているだけでは、実際の再生が別サフィックスへ伸びているケースで取りこぼしが残ります。ログで頻出しやすいのは aiv-delivery.net、aiv-cdn.net のような aiv- プレフィックス系です（環境によりホスト名は変化します）。またメタデータや計測が media-amazon.com や amazonvideo.com 系へ伸びることもあるため、過度に広い DOMAIN-SUFFIX,amazon.com 一本はショッピング全体まで巻き込みやすく、個人運用ではログを見ながら段階的に広げるのが無難です。

評価順は「細かいドメイン／サフィックスを上、広い GEOIP や最終 MATCH を下」に寄せると追いやすいです。YAML のイメージだけ示します（グループ名や順序は環境に合わせて置き換えてください）。

rules:
  - DOMAIN-SUFFIX,primevideo.com,STREAM_PROXY
  - DOMAIN-SUFFIX,amazonvideo.com,STREAM_PROXY
  - DOMAIN-SUFFIX,aiv-cdn.net,STREAM_PROXY
  - DOMAIN-SUFFIX,aiv-delivery.net,STREAM_PROXY

実運用では、再生試行中に接続一覧へ現れた未知の FQDN を少量ずつ足していく方法が保守しやすいです。新作やチャンネル追加のタイミングでパターンが変わることもあるため、シーズンごとに短時間だけログを見る程度でも効きます。

Sniffer／Fake-IP と Prime の相性

嗅探（sniff）や override-destination を有効にしていると、意図せず分流ルールのマッチ順が変わり、ストリームだけ別グループへ滑ることがあります。fake-ip と組み合わせたときの優先関係はSniffer とストリーミング分流の記事で手順を整理しているため、症状が重なるときは併読してください。

ステップ 4：ノード選択と帯域（地域タグを実再生で確認）

遅延テストの URL がストリーミング網と無関係だと「数値は良いが再生だけ不安定」が起きます。Prime Video でも、まず手動の select で地域タグの読み取れるノードに固定し、数分実再生してバッファとエラー表示を見るのが実務的です。過負荷ノードでは帯域が足りず自動でビットレートが落ちることもあります。

一覧が真っ赤でUDPやSTUNまで怪しいときは、ノードが全て赤に見えるときの記事で下位層を先に潰すと、本稿のストリーミング切り分けとつながります。

短いチェックリスト（再掲）

  1. 視聴デバイスが同一プロキシスタック（ブラウザのみ／TUN／ゲートウェイ）を見ているか。
  2. DNS：fake-ip、DoH、OS の暗号化 DNS、IPv6 の片道、ルーターキャッシュ。
  3. primevideo.com とログ上の aiv-*／関連 CDN が意図したプロキシグループへ揃っているか。
  4. 広すぎる amazon.com マッチでショッピング・AWSまで巻き込んでいないか（副作用）。
  5. ノードを実再生で確認し、測速値だけで判断しない。
  6. Sniffer／override-destination とルール優先の組み合わせを疑う。

運用のコツ：Prime Video はアカウントと配送 CDN が分かれているぶん、毎回ルール全集を貼り替えるより、再生ログから増分でホストを足す方が長期的にメンテしやすいです。Netflix／Disney+／Max と共用するストリーミング用プロキシグループを切っておくと、検証のたびに切り替えが楽になります。

ドキュメントと入手経路

YAML の詳細は当サイトのチュートリアル・ドキュメントも参照してください。実行ファイルは説明が一貫した配布導線としてダウンロードページから入手するのがおすすめです。

まとめ

Prime Video の地域まわりは、primevideo.com 単体では説明しきれず、aiv-delivery.net／aiv-cdn.net などの aiv-* CDN とAmazon アカウント側 API が別レイヤーで動くことが多いです。Clash では視聴クライアント→DNS→分流ルール→ノードの順に見ると、どこで出口が分岐しているかを切り分けやすくなります。

同種のクライアントでも Mihomo／Clash Meta 系はログと追記がしやすく、不足ドメインを運用で埋めやすいのが強みです。

各 OS 向けビルドはダウンロードページにまとめています。DNS とルールを一度整理したうえで環境に合ったクライアントを入れると、再生検証のループが短くなります。→ Clash クライアントを無料でダウンロードし、Prime Video 向けの分流と DNS を揃えて試す