世界を動かす技術を、日本語で。

YouTubeの新しいアンチ広告ブロック対策

2025年6月21日原文(iter.ca)

概要

YouTubeは最近、広告ブロッカー対策として「フェイクバッファリング」を含む新たなA/Bテストを実施中。 uBlock OriginやBrave向けに一部回避フィルターが既にデフォルトリストに追加済み。 フェイクバッファリングは広告時間の80%分だけ動画開始時に遅延を発生させる仕組み。 「isInlinePlaybackNoAd」プロパティを利用することで広告・バッファリング回避が可能。 YouTube側のスクリプトロック対策やフィルターの応用方法も解説。

YouTubeのフェイクバッファリング対策の現状

  • YouTube は2025年6月時点、 広告ブロッカー利用者 に対して 新たな対策 をA/Bテスト中
  • 試験的なアカウントでは 「フェイクバッファリング」 現象が発生
  • フェイクバッファリングは 動画開始時のみ 発生、中盤以降には影響なし
  • バッファリング時間は 本来表示される広告の80% に相当
  • 例:15秒広告なら 12秒バッファリング、6秒+15秒広告なら 16.8秒バッファリング
  • 広告ブロック利用者 でも、結果的に 広告を視聴するより短縮 される場合が多い

技術的背景(InnerTubeとGVS)

  • InnerTube :YouTube公式の内部API、動画データやストリーム情報の取得に利用
  • /youtubei/v1/player エンドポイント:動画再生時のデータ取得に使用
  • GVS(Google Video Services) :YouTubeやGoogle Drive等の動画ストリーム配信サービス
    • GVSのURLは署名付きで有効期限あり(通常6時間)
    • 一部ISPは Google Global Cache を設置し、ネットワーク外に出ず動画配信が可能
  • SABR(Server ABR) :YouTube独自のバイナリプロトコル、バッファリング回避性能向上
    • SABRはクライアントに「一定時間待機(backoff)」を指示可能

フェイクバッファリングの正体

  • InnerTube がGVSストリームに「backoff」を設定
    • 最初の再生リクエスト時、広告の80%分の待機時間を指示
  • サーバーサイド広告挿入 とは異なり、広告と本編は別ストリーム
  • 「Experiencing interruptions」ダイアログは、長時間のbackoffが原因
  • A/Bテスト対象なら 広告ブロック有無に関係なくbackoff発生
    • 広告未ブロック時は、広告再生中に本編プリロードされるため気づきにくい
  • 「CPU使用率がスパイクしPCが壊れる」との噂は 事実無根

広告・バッファリング完全回避方法

  • isInlinePlaybackNoAd プロパティを true に設定することで 広告表示・backoff回避 が可能
  • フィルタールール例(uBlock Origin/Brave対応):
    • www.youtube.com##+js(trusted-replace-outbound-text, JSON.stringify, 'contentPlaybackContext":{', 'contentPlaybackContext":{"isInlinePlaybackNoAd":true,', condition, 'contentPlaybackContext')
  • このプロパティは Protocol Buffers定義 から抽出可能
    • req2proto 等のツールでAPI定義を解析

制限事項と注意点

  • この方法は ウォームナビゲーション (SPA内移動時)のみ有効
  • コールドロード (直URLアクセス時)は ytInitialPlayerResponse が直接埋め込まれ、プロパティの挿入が不可
    • 無理やり初期データ削除で対応可能だが
      • ライブ配信が壊れる
      • プレイヤーが一瞬点滅
      • ページ読み込みが遅くなる
      • 推奨されない

スクリプトロック(ロッカースクリプト)対策

  • YouTubeは Object.definePropertyグローバルオブジェクトのロック をA/Bテスト中

    • 例:JSON.stringifyfetch等を上書き不可に
  • uBlock Origin のスクリプトレットが JSON.stringify をフックできない場合が発生

  • Firefox はHTMLフィルターでロッカースクリプト自体を除去可能

    • Chromium系 はAPI未対応で不可
  • 現状の回避策: Object.assign のフックに切り替え

    • uBO用フィルター例(やや複雑):

      (() => {
        const e = {
          apply: (e, n, arguments) => {
            let t = Reflect.apply(e, n, arguments);
            return 3 === arguments.length && t?.body && "string" == typeof t.body && !t.body.includes(`"isInlinePlaybackNoAd":true`) && (t.body = t.body.replace(`"contentPlaybackContext":{`, `"contentPlaybackContext":{"isInlinePlaybackNoAd":true,`)), t
          }
        };
        window.Object.assign = new Proxy(window.Object.assign, e)
      })();
      
  • uAssetsメンテナ からの協力に感謝

参考リソース

  • GVS再生URLYouTube内部仕様 の詳細解説ブログ
  • Discord での質問受付:@moreloops

まとめ

  • YouTube は広告ブロッカー対策を強化中だが、 uBlock Origin/Brave の最新フィルターで 大部分回避可能
  • isInlinePlaybackNoAd プロパティの活用がカギ
  • スクリプトロック対策API仕様の理解 が今後も重要
  • 技術的・法的なリスクやYouTube規約違反の可能性には 各自注意

Hackerたちの意見

なんで広告を直接動画ストリームに入れないのか、ちょっと驚きだよね。そうすれば、すぐに問題が解決すると思うんだけど(個人的には広告はあんまり見たくないけど)。再生速度に合わせて制限をかければ、ストリームを簡単に事前ダウンロードするのも防げるし。今はHLS/DASHを使ってるから、再エンコードせずにストリームの真ん中に違うコンテンツを簡単に挿入できるんだよね。

これについてはずっと疑問に思ってた。何か難しい理由があるみたいだけど、全然想像もつかないよね。そうじゃなきゃ、やってるはずだよね?

そういうやり方をしてるポッドキャストもあるよね。時々、話の途中で広告が入ることもあるし。The Athleticのサブスクリプションを払ってるんだけど、彼らはアプリで広告なしのポッドキャストを提供してたんだ。先月、Acastと独占契約を結んで、今は広告なしでポッドキャストを聴くことができなくなっちゃった。

Twitchはどうやってるんだろう?彼らはすごく攻撃的で、広告を表示しないうまく動作するサードパーティのクライアントを使っても、時々「コマーシャルブレイク」の画面が出てきて、コンテンツも広告も流れない、「ロビーに行こう」っていう画面だけが表示されることがあるんだよね。

タイムスタンプに基づいたクラウドソーシングの広告ブロックが存在するよ(SponsorBlock、Tubular)。もうすぐ、リアルタイムでデバイス上のコンテンツに応じたAI広告ブロックが実現するだろうね。彼らは絶対に勝てないよ。

あんまり急に煮えたぎらせたくないんだろうね。最終的には、YouTubeが広告をストリームに直接埋め込むようになるだろうね。投稿にも書いてあるけど、「これはサーバーサイドの広告挿入じゃないから、広告とコンテンツのストリームはまだ別々だよ(YouTubeはサーバーサイドの広告挿入実験をしてるけど、それはフェイクバッファリングとは別の話)」って。

これはコストの問題だと思う。HLSはハードウェアレベルまでめちゃくちゃ最適化されてるから、ターゲティングのために計算を追加するとコストが爆発的に増えちゃうんだよね。もうあまり詳しくはないけど、Netflixがストリーミング用のエッジサーバーに施したすごい最適化についての素晴らしい記事がいくつかあるよ。

クライアント上で広告をスパイシングするのは、スパイシングするのと同じくらい簡単だよ。検出できるならね(スポンサー・ブロックみたいなクラウドソースのデータベースを使えばできる)。

現在、YouTubeはサーバーサイド挿入のA/Bテストを行っているらしいけど、私はSSAI広告を見てないから、詳しくはわからないんだ。

彼らはそれに取り組んでいるよ。WebのYouTubeプレーヤーは、もはやサーバーから別々の動画と音声のストリームを取得しなくなった。事前にバンドルされたものをリクエストして、サーバー側でミックスされた単一のストリームを受け取るようになったんだ。

最近、バッファの読み込み時間が長くなってきてるけど、皮肉なことにあんまり気にしてないんだ。広告のイライラは、時間がかかることだけじゃなくて、音声が流れてるのに、自分がクリックした動画じゃない映像が流れることなんだよね。実際の広告が流れたら、もう信じられないくらいイライラするけど。12秒のバッファがあると、遅い読み込み時間には十分耐性がついてるから、ついメールをチェックしたり、ちょっと考え事をしたりするんだ。特に毎回動画でそうなるとね。5本に1本くらいだったら気づくし、イラっとするけど、毎回だとそれが体験の一部になって、脳が自動的に切り替えちゃうんだよね。

そうそう、ポップアップで「再生が遅い理由を知ってください」って出る初期の遅延があるんだよね。いらないよ、もう分かってるし、そんなに悪くないから。

Hacker Newsで議論の続きを見る