【ITニュース解説】Fixing "Sign in to confirm you're not a bot" for YouTube transcripts on a server

YouTubeの動画から字幕（トランスクリプト）を取得するプログラムを開発し、自分のパソコンで試したときは問題なく動いたのに、いざインターネット上のサーバー、例えばAWSやVercel、Renderといったクラウドサービスにデプロイしてみると、「ボットではないことを確認するためにサインインしてください」というエラーが出て、字幕が取得できなくなる現象について解説する。これは、プログラム自体に問題があるわけではなく、YouTube側がリクエストの送信元を「ボットからのアクセス」と判断しているために起こる。

なぜこのような問題がサーバー環境でだけ発生するのか。YouTubeは、動画の字幕などのデータにアクセスする際、リクエストがどこから来たのか、そのIPアドレス（インターネット上の住所のようなもの）を調べている。一般家庭のインターネット回線やスマートフォンの回線から来るリクエストは、ほとんどの場合、人間からのものと判断される。しかし、AWSやGoogle Cloud、Azureのような大規模なデータセンターから来るIPアドレスは、ウェブサイトから自動的に情報を収集する「スクレイパー」や「ボット」からのアクセスと見なされやすい。そのため、YouTubeはデータセンターからのリクエストに対して、「ボットではないことを証明するためにサインインしてほしい」と要求する。最初は数回のリクエストは通ることがあっても、数百回を超えるとほとんどのリクエストが失敗するようになるため、最初はランダムに失敗しているように見えても、最終的には全ての動画でエラーが発生するようになるのだ。

このエラーで厄介なのは、「LOGIN_REQUIRED」（ログインが必要です）というメッセージが表示される点にある。これは、IPアドレスがボットと判断された場合だけでなく、そもそも動画が本当に非公開設定であったり、年齢制限がかかっていたり、メンバー限定の動画であったりする場合にも表示されるため、混乱しやすい。この二つを区別するには、エラーの詳細な理由を示すテキストを確認する必要がある。「Sign in to confirm you're not a bot」という理由が表示された場合は、IPアドレスが問題であり、動画自体は問題ないため、別のIPアドレスや方法で再試行すれば字幕を取得できる可能性がある。一方、「This video is private」や「Sign in to confirm your age」などの理由が表示された場合は、動画そのものが特別なアカウントを必要とするか、アクセスできない状態にあるため、再試行しても無駄になる。この区別をすることで、無駄なリクエストを避け、時間やコストを節約できる。

この問題に対処するための解決策はいくつか存在する。無料に近いものから、より確実に解決できるがコストがかかるものまで、様々な方法がある。

まず一つ目は、yt-dlpというツールを使っている場合、これを最新バージョンに更新し、さらにJavaScriptの実行環境（Node.jsやDenoなど）を導入する方法だ。最近のyt-dlpは、YouTubeとやり取りするために外部のJavaScriptランタイムを必要とすることがあるため、これが不足していると、ボットチェックのエラーと似たような形で情報抽出に失敗することがある。この対応で解決する場合もあるが、これはあくまでyt-dlpの環境設定の問題であり、IPアドレスがブロックされている根本的な問題ではないため、IPが原因の場合は効果がない。

二つ目の方法は、YouTubeに「異なるクライアント」としてデータを要求することだ。YouTubeはウェブブラウザ向け、モバイルアプリ向け、テレビアプリ向けなど、様々なデバイス向けにデータを提供しており、それぞれでボットチェックの厳しさが異なる場合がある。あるクライアントでブロックされても、別のクライアントとしてリクエストを送ればデータが取得できることがあるのだ。yt-dlpでは--extractor-args "youtube:player_client=..."というオプションを使ってクライアントを指定できる。また、yt-transcript-cliというツールは、このクライアントの切り替えを自動的に行ってくれる。複数のクライアントを試しても全て拒否された場合は、IPアドレス自体が強くフラグ付けされているため、別のIPアドレスが必要になる。

三つ目の方法は、ログイン済みアカウントのCookieを使うことだ。YouTubeのエラーメッセージでも示唆される方法で、ログイン済みのGoogleアカウントのCookie情報を使ってリクエストを送ることで、一時的にボットチェックを回避できる。しかし、Cookieには有効期限があり、また自動利用することでそのGoogleアカウントが制限される可能性もあるため、普段使いのアカウントではなく、使い捨てのアカウントを使うのが安全だ。

四つ目の方法は、Proof-of-origin（PO）トークンを利用することだ。yt-dlpはこのPOトークンをサポートするプラグインを提供しており、Cookieなしでボットチェックをクリアできる場合がある。しかし、これもYouTubeが定期的に変更する部分であり、継続的なメンテナンスが必要になる場合がある。

五つ目の方法は、レジデンシャルプロキシを利用することだ。これは、データセンターのIPアドレスではなく、一般家庭のインターネット回線から来たように見せかけるプロキシ（代理サーバー）を使う方法だ。この方法が最も確実にボットチェックを回避できるが、レジデンシャルプロキシの利用は通常、費用がかかる。youtube-transcript-apiというライブラリは、このレジデンシャルプロキシを直接設定できるようになっている。安定した解決策ではあるものの、かなりのコストがかかる場合があり、毎月数百ドルもの費用が発生するケースも報告されている。

六つ目の方法は、ホスト型字幕APIサービスを利用することだ。これは、自前で上記の解決策を実装・維持する代わりに、すでにこの問題を解決している外部のサービスを利用する方法だ。これらのサービスは、クライアントの自動切り替え、レジデンシャルプロキシの運用、エラー理由のチェックなどをサービス側で管理してくれるため、開発者は字幕取得の仕組みをメンテナンスする手間から解放される。ApifyやRapidAPIなどで提供されているサービスが例として挙げられる。コストはかかるものの、大規模なアプリケーションで安定して字幕を取得したい場合には、自前で全てを構築・維持するよりも結果的に安価で効率的になることが多い。サービスを選ぶ際は、字幕がない動画や失敗したリクエストが課金対象にならないか確認することが重要だ。

どの解決策を選ぶべきかは、プロジェクトの規模や利用頻度による。個人的なサイドプロジェクトで1日に100本程度の動画しか扱わないのであれば、yt-dlpの環境設定や異なるクライアントとしてリクエストを送る方法で十分なことが多い。ある程度の安定した頻度で利用し、かつメンテナンスの手間をいとわないのであれば、異なるクライアントとしてのリクエストとレジデンシャルプロキシを組み合わせるのが良いだろう。もし、取得した字幕データをアプリケーションやAIエージェントに供給するような、より大規模なシステムであれば、スクレイピングのメンテナンスを外部に任せられるホスト型APIサービスを利用するのが最も効率的で確実な選択肢となる。

最後に、これらのどの解決策を選んだとしても、YouTubeがボットチェックの仕組みを数週間ごとに変更する可能性があるため、永続的に機能する保証はない。そのため、プログラムの中で「YouTubeにブロックされたので後で再試行するべきか」と「この動画にはそもそも字幕がないのか」を明確に区別できるようにしておくことが非常に重要だ。そうすることで、プログラムが黙って何も返さないのではなく、問題が発生したときにきちんとエラーを通知し、適切な対処ができるようになる。