youtube-transcript-api がYouTubeにブロックされる? 4つの解決策

症状: ローカルでは動くのに本番でブロックされる

Pythonライブラリ youtube-transcript-api は、YouTubeの文字起こしをプログラムから取得する方法として最も広く使われています。ローカルマシンではたいてい問題なく動きます。ところがクラウドサーバー上で実行した途端、IpBlocked、RequestBlocked、TooManyRequests といった例外が出はじめ、YouTubeにIPをブロックされていることを示すメッセージが返ってきます。

同じことは、スクレイピングに依存するあらゆる手段で起こります。Node.jsの文字起こしパッケージ、yt-dlpによる字幕取得、自作のスクレイパー——どれも同じ壁にぶつかります。原因はコードではなく、リクエストの発信元です。

AWS Lambda、Google Cloud Run、Vercel、Railway、Fly.io、あるいは任意のVPS上で動かしていれば、YouTubeからはデータセンターのIPアドレスに見えます。これらのIPレンジは公開情報であり、ボットに酷使されているため、まとめてブロックされます。自宅のWi-Fiのような一般回線のIPはほとんどブロックされません。「自分の環境では動くのに」が文字どおり真実になるのは、このためです。

なぜYouTubeはブロックするのか

YouTubeの文字起こしは、第三者の利用を想定していない内部の非認証エンドポイントから配信されています。任意の動画の文字起こしを取得できる公式の公開APIは存在しません。公式のData APIのcaptionsエンドポイントは動画所有者によるOAuth認可を必要とするため、自分の動画にしか使えないのです。

この内部エンドポイントは無料かつ認証不要であるがゆえに、AI企業、SEOツール、スクレイパーから大量のアクセスを浴びています。YouTube側が取れる手段は限られており、厳しいレート制限とデータセンターIPレンジの一括ブロック、そしてスクレイピングライブラリを一夜にして壊すエンドポイントの仕様変更という形で対応しています。

つまり、自前でホストする限り、いたちごっこは終わりません。以下の4つの解決策は、DIY寄りのものからマネージド寄りのものへと順に並べています。

解決策1: 住宅用プロキシ経由でリクエストする

定番のDIY策は、ローテーションする住宅用（レジデンシャル）プロキシ経由でリクエストを送り、YouTubeから見て一般家庭のIPに見せることです。最近のバージョンの youtube-transcript-api はこれを直接サポートしており、クライアント生成時にプロキシ設定を渡せます（WebshareProxyConfig というヘルパーが同梱されているほか、任意のHTTP/SOCKSプロキシを使うなら GenericProxyConfig を利用します）。

動作はしますが、相応のコストがかかります。住宅用プロキシの帯域は高価で（一般に1GBあたり数ドル）、品質は業者によって大きく異なります。さらに、プロキシのIPがリクエスト中にブロックされたときのリトライ処理、ヘルスチェック、業者のフェイルオーバーという新たな障害点を自分で抱えることになります。リクエスト量が少ない場合は、プロキシ網を1ホップ余分に経由するぶん、最も遅い選択肢にもなり得ます。

完全な制御が必要で、運用に割ける工数があり、初期構築を正当化できるだけの処理量があるなら、この方法を選んでください。

解決策2: 一般回線のマシンで取得する

もっと単純な変形として、文字起こしを取得する部分だけを一般回線のIPを持つ場所——自宅のRaspberry Pi、オフィスのマシン、安価なミニPC——で動かし、結果をキューやWebhook経由でクラウド側に送る構成があります。

プロキシ費用は一切かからず、個人的な小規模用途（自分用のメモ作成や小さなニュースレターのための文字起こしなど）では驚くほどうまく機能します。欠点は明白です。物理的な単一障害点であり、スケールせず、プロダクション向けのアーキテクチャとしては歪です。

解決策3: 積極的にキャッシュし、エラー時はバックオフする

どの取得方法を使うにせよ、次の2つの習慣でブロック率は大きく下がります。1つ目は、取得した文字起こしを必ずキャッシュすること。文字起こしはほとんど変化しないので、同じ動画を二度取得する理由はありません。動画IDをキーにした単純なテーブルひとつで、繰り返しのトラフィックはほぼ消えます。

2つ目は、ブロックを「即リトライすべきエラー」ではなく「シグナル」として扱うこと。ジッター付きの指数バックオフ（1秒待ち、次に2秒、4秒、8秒……）は目立たずに済みます。ブロックされた直後にエンドポイントを叩き続けるのは、IPレンジごと締め出される最短ルートです。

ただし、これは緩和策であって根本的な解決ではありません。データセンターのIPからでは、最初の1リクエストからブロックされることもあります。他の3つの解決策のいずれかと組み合わせてください。

解決策4: ホスト型の文字起こしAPIを使う（インフラ運用なし）

マネージドな選択肢は、IP問題をすでに解決しているサービスに取得を任せることです。ParseJetはエンドポイントを1つだけ公開しています。POST /v1/parse/youtube に動画URLを送ると、動画タイトル・チャンネル・再生時間とともに文字起こし全文がJSONで返ります。ブロック対策、プロキシ管理、エンドポイントの仕様変更はすべてサーバー側で吸収されるため、あなたのコードは3行のままです。

youtube-transcript-api からの移行は数分で終わります。ライブラリ呼び出しを1回のHTTP POSTに置き換えるだけです（Python、Node.js、その他HTTPを話せる環境ならどこでも動きます。ライブラリ方式が最もブロックされやすいサーバーレス環境でも同様です）。字幕の言語を指定したい場合は language パラメータを渡してください。

無料プランには月300クレジットが含まれ（YouTubeの文字起こしは1本あたり5クレジットなので60本分）、有料プランは月額$19からです。多くのプロダクトにとって、住宅用プロキシの帯域費用と、それを保守する工数の合計より安く済みます。

どの解決策を選ぶべきか

個人プロジェクトで処理量が少なく、技術的な作業を厭わないなら、解決策2（一般回線のマシン）が無料で十分に安定します。

処理量が多く、インフラを専任で見られるなら、解決策1（ローテーション住宅用プロキシ）が最も自由度の高い方法です。プロキシ費用と継続的な保守工数を見込んでおいてください。

文字起こしが本業ではなく一機能にすぎないプロダクト、エージェント、RAGパイプラインなら、解決策4（ホスト型API）です。HTTPリクエスト1回で済み、いたちごっこから降りられます。そしてどの場合でも、解決策3（キャッシュ＋バックオフ）は必ず併用してください。