1 イベント視聴は「複数サイトの同時負荷」になる
Keynote のメインウィンドウは多くの場合ブラウザ上の公式プレイヤーであり、視聴体験の大部分はYouTube と同等の CDN 構成に依存しています。その一方で、並行して developers.google.com でセッション表を開いたり、gstatic 経由のアイコン類を読み込んだり、ブログ連動の記事サイトを参照したりすると、画面上は一つの「カンファレンス」のように見えても名前解決と TCP は別ホストへの扇状展開になります。ここがルールセットを「広い Google と狭い Gemini」だけに割り振っていると、イベント本番だけ急にキューが増え、プロキシのスループットや DNS のキャッシュ方針にボトルネックが出やすくなります。
Gemini 単体のアプリについては別稿で細かく触れられることが多く、ユーザーが抱える課題は「API とブラウザを同じ経路へ」になりがちです。一方Google I/O ライブ視聴では、音声・映像の継続的ストリーム、トランスクリプトの更新、参加者向けウィジェット、そして周辺のマーケ素材までが複数サービスへ分散するため、YouTube と googlevideo と「公式ドキュメント系ドメイン」を同じグループへ寄せておくほうが、メンテナンスとトラブルシュートの両面で分かりやすいです。すでにテレビ端末での再生を強化したい読者には、Living room 側の共通課題をまとめた Android TV 向けガイド と合わせて読むと、ブラウザとアプリでの差分確認に役立ちます。
2026年前後の注目は「モデル単体より配信インフラ」です。開発者サイトと動画視聴を同一ポリシーにまとめると、ライブ開始直後に慌てずルールを足し替えられるようになります。
2 代表ホスト集合：動画 CDN と開発者コンテンツ
公式の一覧はイベント時期や地域で増減しますが、実務では次の束がベースになります。YouTube メイン本体の youtube.com / youtu.be、視聴品質と向きを左右する googlevideo.com、サムネイルとプレビューの ggpht.com、Android TV 視聴でよく論じられる gvt1.com 系、開発者コンテンツの developers.google.com、静的 CDN の gstatic.com と googleusercontent.com、イベント告知まわりでは blog.google などが典型です。また API コードサンプルを混ぜると googleapis.com も増えやすく、すべてを「モデルだけの例外」へ逃がしていくと一覧が増殖します。
- 動画視聴層：配信開始直後のスパイクを吸収する CDN 側が複数シャードに別れ、名前解決のばらつきで片方だけ直行してしまわないようにする。
- 開発者コンテンツ層：多言語ヘルプと自動生成された参照リンクへ追従しやすいよう、親ドメインを DOMAIN-SUFFIX で束ねておく。
- フォント・アイコン層：本文が表示できても
fonts.gstatic.comが別経路になり、体感が細切れになるケースへの備え。
「購読の巨大ルールセットに任せれば足りる」という楽観は、イベント直前のリスト更新タイミングで崩れやすいです。自分用に短くまとめるなら、この節で挙げたドメインを自分の Proxy グループ名へ向けるリストをひと繋がりとして置き、順序だけを上流の Geo / 広告リストより前へ持ってくる、という順序運用が扱いやすいです。DNS 側のフェイク IP とフィルタの整合は DoH と FakeIP のベストプラクティス稿で整理したように、リストと矛盾させないようにしてください。
3 rules における DOMAIN-SUFFIX の束ね例
次のように、自分の環境にあるプロキシグループ名（例：DIRECT_GOOGLE ではなく 🔰 PROXY-GROUP など実際のラベル）へ差し替えてください。コメントは英語のみとし、イベント専用の短いリストを上流へ置いたイメージです。
# Local cluster for I/O keynote + docs + video CDN — adjust PROXY_GROUP name.
rules:
- DOMAIN-SUFFIX,youtube.com,PROXY_GROUP
- DOMAIN-SUFFIX,googlevideo.com,PROXY_GROUP
- DOMAIN-SUFFIX,ggpht.com,PROXY_GROUP
- DOMAIN-SUFFIX,gvt1.com,PROXY_GROUP
- DOMAIN-SUFFIX,developers.google.com,PROXY_GROUP
- DOMAIN-SUFFIX,googleusercontent.com,PROXY_GROUP
- DOMAIN-SUFFIX,gstatic.com,PROXY_GROUP
- DOMAIN-SUFFIX,blog.google,PROXY_GROUP
Mihomo / Clash Meta では評価は上から順に走るため、このブロックより前に細かな GEOIP,cn,DIRECT しか置かず、広いリストを後ろへ回しているとイベント用の直行が競合しないかを確認します。競合ログは短時間だけ log-level: debug で十分ですが、その際はconnection ログの読み方に沿って、どの規則名にマッチしたかをイベントごとではなくタイムスタンプ順に追ってください。
DOMAIN-KEYWORD を併記します。リストが肥大化しないようイベント後に削除する運用でもよいです。
4 Rule Provider で更新サイクルを分ける
アップストリームのコミュニティリストは広い一方、YouTube と Google が同一カテゴリに入っていないバージョンもあります。イベント期間だけ自分用ミニセットを rule-providers 経由で引き、tunnel グループとは別タイマーで更新すると、イベント後に残骸をまとめて消しやすいです。behavior: domain のリストを単体ホストだけで並べ、その直後を rules の RULE-SET 行で読み込む、という二段構成が単純です。購読全体の読み込み順と混線させないよう、mixin と override で差し込むときは購読上書きの稿で触れた順序規則に合わせてください。またコミュニティ由来のセットを広く読むときの注意点として、ACL4SSR 系の読み込みガイドにある「behavior と precedence」の整理がそのまま当てはまります。
rule-providers:
google-live-docs:
type: http
behavior: domain
url: "https://gist.githubusercontent.com/you/google-io-mini.txt/raw"
path: ./rules_provider/google-live-docs.yaml
interval: 43200
rules:
- RULE-SET,google-live-docs,PROXY_GROUP5 カクつきと「ルールは緑でも再生が細切れ」の切り分け
典型的には次の順で疑います。第一にDNS の実 IP とフェイク IP のギャップにより、ログ上はヒットしているのにブラウザの QUIC だけ別ドメインへ抜ける。第二にSniffer と TLS SNI が一致しない状態で広いリストが逆転し、アップストリームが期待と異なるシャードへ飛んでいる。第三にイベント初日のみ大量の短命接続がバーストするため、自動 URL-Test グループが切り替わり過ぎる。順に潰していくとき、HTTPS が誤検出された場合はSniffer と SNI の詳細記事で列挙した除外パターンを見直し、開発者コンソールのネットワークタブとコア側の名前解決ログを並べます。
ライブイベントではYouTube と同等の QUIC 構成が有効になりやすく、環境によっては QUIC を抑えて HTTPS/TCP が主になる構成へ寄せたほうが安定する事例もあります。ここではアプリ側のフラグ運用より、まずクラスタが同一エグレスを共有していることを優先すると判断が楽です。またリビング環境だけ症状が強いときはテレビ端末の省電力と DNS が PC と食い違っている可能性が高いので、前文で触れた Android TV 稿のチェックリストをそのまま当てます。
6 まとめ
Google I/O 2026のような開発者注目イベントでは、注目が単一プロダクトに閉じず、公式ライブ（Keynote・セッション）・developers.google.com とその周辺の静的資産まで同時アクセスになります。そのため Gemini だけを並べた狭いリストより、YouTube と googlevideo と gstatic と docs 親ドメインをまとめる DOMAIN-SUFFIX と Rule Provider が実務では扱いやすく、名前解決とルール評価のログも一枚絵で読めます。Mihomo と GUI クライアントでは接続一覧とログの往復が速いので、ライブ開始前に一度リストを流し込み、そのままイベント本番でも追いやすいです。
オープンソースの議論や最新リリースは GitHub で追える一方、実行ファイルの安定配布経路としては本站のダウンロードページへ誘導すると、プラットフォーム差分に振られにくくなります。GUI でルールセットを差し替えながらライブ視聴品質も試せる構成は、開発者ワークステーションだけでなく、リビング端末とも同じノード評価に寄せやすく、イベント後も日常の Google Cloud 開発に流用できます。
