【ITニュース解説】Reverse Engineering YouTube's Web API: Why I Ditched Selenium and the Official Data API
2026年10月07日に「Dev.to」が公開したITニュース「Reverse Engineering YouTube's Web API: Why I Ditched Selenium and the Official Data API」について初心者にもわかりやすく解説しています。
ITニュース概要
YouTubeスクレイピングで公式APIやSeleniumの制限を回避するため、開発者はYouTube内部API「InnerTube」をリバースエンジニアリングした。これにより、高速かつ軽量なデータ取得が可能になった。未公開API利用には、認証情報や無限スクロール対応、複雑なデータ構造の解析が必要だったが、これらを解決し、非同期処理で効率的なスクレイピングを実現した。
ITニュース解説
システムエンジニアを目指す皆さんにとって、ウェブサイトから特定の情報を自動で取得する技術は非常に興味深い分野だろう。YouTubeのような巨大なサービスからデータを取得する際、開発者が直面する一般的な選択肢は二つある。一つはYouTubeが公式に提供するAPIを利用する方法、もう一つはブラウザをプログラムで操作する「ブラウザ自動化」と呼ばれる方法である。
しかし、これらの選択肢にはそれぞれ課題がある。公式APIは、YouTubeのデータにアクセスするための正規の手段だが、データを取得するまでの応答が遅い(レイテンシが高い)という問題がある。また、利用できるデータ量には厳格な制限(クオータ)があり、例えば10,000単位という割り当てがあっても、これはあっという間に消費されてしまう。さらに、利用を開始するためのGoogle Cloudプロジェクトの登録プロセスも煩雑である。一方、ブラウザ自動化は、SeleniumやPlaywrightといったツールを使い、プログラムでブラウザを操作してウェブページを閲覧し、表示された情報を抽出する方法だ。この方法は、ウェブページの見た目から情報を取得するため、非常に重く、動作が遅い。さらに、YouTubeのウェブサイトのデザインや構造が少しでも変更されると、プログラムが正しく動作しなくなる可能性があり、脆いという欠点がある。
このような状況に対し、筆者は「速く、軽く、Google Cloudプロジェクトの登録も不要な第三の方法」を求めた。その結果、たどり着いたのがYouTubeの内部APIである「InnerTube」のリバースエンジニアリングだった。InnerTubeとは、実はYouTubeのウェブアプリ、モバイルアプリ、さらにはスマートテレビに至るまで、あらゆるYouTubeサービスを動かしている根幹のAPIである。これは「/youtubei/v1/...」という統一されたURLエンドポイントを持ち、JSON形式のデータを受け取ると、非常に巨大で深くネストされた構造のデータを返す。ただし、このInnerTubeには公式のドキュメントが存在しないため、その利用方法を理解するには、その仕組みを分析し、利用できるようにする「リバースエンジニアリング」が必要となるのだ。
筆者は、このInnerTubeを直接利用するライブラリ「ytscrape」を開発し、その性能を既存の方法と比較した。ある動画から100件のコメントをスクレイピングするテストでは、ブラウザ自動化のSelenium(ヘッドレスモード、つまり画面表示なし)が約8.5秒かかり、メモリも約450MB消費した。公式APIは比較的速く約1.2秒、メモリも約40MBと効率的だったが、クオータ制限という課題が残る。それに対し、ytscrapeは驚くべき結果を示した。わずか約0.4秒で処理を完了し、メモリ使用量も約35MBと非常に少なかったのだ。これは、ブラウザがウェブページを描画するための複雑な処理(レンダリングエンジン)を完全にスキップし、直接データ層と通信することで、ブラウザ自動化よりも約20倍も高速にデータを取得できることを意味する。
しかし、このInnerTubeをリバースエンジニアリングし、使いこなすまでにはいくつかの技術的な障壁があった。
第一の課題は「コンテキストオブジェクト」である。InnerTubeは、クライアントのバージョン情報、利用可能な機能を示すフラグ、そして訪問者のデータといった複雑な情報を含む「コンテキスト」オブジェクトがなければ、正常な通信ができない。このオブジェクトは時間とともに変化する可能性があったため、筆者はYouTubeのホームページからこの情報を動的に抽出し、ytscrapeライブラリが常に最新の有効なコンテキストを利用できるようにする仕組みを構築した。これにより、ライブラリの安定性と持続性を確保したのだ。
第二の課題は「継続トークン」と呼ばれる仕組みである。YouTubeのコンテンツ、例えばコメントリストなどは、一般的な「ページ番号」方式ではなく、「無限スクロール」のように、次のデータチャンクを取得するための特別な暗号化された文字列(継続トークン)を使用する。各レスポンスには次のデータ取得に必要となるこのトークンが含まれており、これを再度リクエストに含めて送信することで、残りのデータを順次取得できる。筆者はこの複雑なトークン交換を、Pythonの「ジェネレーター」という機能を使って透過的に実装した。これにより、ytscrapeの利用者は、内部でトークンがどのように交換されているかを意識することなく、あたかも通常のリストを扱うかのように、無限に続くコメントデータなどを取得できるようになった。
第三の課題は、InnerTubeから返されるJSONデータの「型付け」である。InnerTubeが返すデータは非常に巨大で、動画のタイトル一つを取得するだけでも、データ構造が8階層も深くネストされているといった具合に、非常に複雑で扱いづらいものだった。例えば、data['contents'][0]['item']['text']のように、何度も辞書のキーを指定してアクセスする必要があるのだ。これでは開発者がデータを扱う際のコードが複雑になり、エラーも発生しやすくなる。筆者はこの問題を解決するため、Pythonの「Dataclasses(データクラス)」という機能を利用し、これらの複雑なJSON構造を、開発者がより直感的で使いやすいPythonのオブジェクト(モデル)にマッピングした。これにより、データの取得と利用が格段にシンプルになったのだ。
また、ytscrapeが純粋なHTTP通信に特化しているため、Pythonの非同期処理ライブラリである「asyncio」との相性が非常に良い点も特筆すべきだ。もし複数の動画IDに対して同時にデータをスクレイピングしようとすると、公式APIではすぐに利用制限(スロットリング)がかかる可能性がある。また、ブラウザ自動化のSeleniumでは、多数のブラウザインスタンスを同時に起動する必要があるため、コンピューターのメモリがすぐに枯渇してしまうだろう。しかし、ytscrapeとasyncioを組み合わせたAsyncYouTubeを使うことで、例えば同時に10個のリクエストを並行して処理するような高並行なデータ取得も、最小限のリソース消費で実現できるのである。
このプロジェクトを通じて筆者は、時には最高のAPIが、Webブラウザの開発者ツールにある「ネットワーク」タブの裏側に隠されている、既にある内部APIであるという教訓を得た。公式に公開されているSDK(開発キット)やAPIだけに縛られず、サービスの内部動作を深く理解し、その内部APIをリバースエンジニアリングして利用することは、既存の課題を解決し、より高性能で効率的なシステムを構築するための強力な選択肢となり得るのである。