yt-dlpで動画をダウンロードしようとしたら、ある日突然「Sign in to confirm you're not a bot」と表示されて止まった――そんな相談が増えている。2026年7月以降、YouTube側のbot検知とJSチャレンジ(nチャレンジ)が強化され、これまで動いていたスクリプトが軒並み失敗するようになった。本記事では、このyt-dlpのbot確認エラーとnチャレンジ失敗を、Cookie認証とEJSソルバー(deno経由)で解消する手順を、実際にYouTubeショート自動生成の運用で使っている設定をもとに解説する。
「Sign in to confirm you're not a bot」と「Only images are available」の正体
2026年7月以降にyt-dlpでYouTube動画を取得しようとすると、主に2種類のエラーに遭遇するようになった。
bot確認エラー
Sign in to confirm you're not a bot は、YouTube側がリクエスト元をブラウザではなく自動化ツールと判定したときに返すメッセージ。ログインCookieを渡さない匿名アクセスや、極端に短い間隔での連続リクエストで発生しやすい。
「Only images are available」も同じ原因
もう一つ厄介なのが Only images are available というフォーマット取得エラーだ。これは動画・音声ストリームのURLを組み立てるための「nチャレンジ」(YouTubeが配信URLに仕込むJavaScriptの難読化ロジック)をyt-dlpが解けなかった場合に出る。画面上はエラーで落ちるのではなく、サムネイル画像のフォーマットしか選べない状態になるため、原因がわかりにくいのが特徴。
2026年7月以降の直し方:Cookie認証+EJSソルバー
この2つの症状は根本原因が同じ(YouTube側のアンチボット強化)で、対処法もセットになる。実運用では以下の2つのオプションを全てのyt-dlp呼び出しに付与することで復旧した。
--cookies-from-browser chrome
ローカルのChromeで自分のGoogleアカウントにログインした状態で、そのブラウザのCookieをyt-dlpに読み込ませるオプション。ログイン済みユーザーとして扱われるため、匿名アクセスに対するbot判定を回避できる。前提として、実行環境のマシンでChromeに実際にログインしている必要がある。
--remote-components ejs:github(deno経由のEJSソルバー)
nチャレンジを解読するためのEJS(yt-dlpが参照するJSチャレンジソルバー)を、GitHub経由で取得・実行するオプション。実行にはJavaScriptランタイムのdenoが別途必要になる。macOSであれば以下のようにHomebrewで導入できる。
brew install denodeno導入後、yt-dlpのコマンドは次のようになる。
yt-dlp \
--cookies-from-browser chrome \
--remote-components ejs:github \
-f "bestvideo+bestaudio" \
"https://www.youtube.com/watch?v=XXXXXXXX"この2つを付けないままだと「Only images are available」でフォーマット取得自体に失敗し、動画・音声ストリームが一切選べなくなる。逆に言えば、このエラーが出た時点でnチャレンジ未対応が濃厚な原因と判断してよい。
関連するアンチボット回避の選択肢
- Cookie認証が使えない(ログイン用ブラウザを用意できないサーバー環境など)場合は、TLSフィンガープリンティング偽装で403を回避する手法もある。requestsベースの実装では curl_cffi 0.16.0の403対策|2026年8月版 が参考になる
- ブラウザ自動化そのものを見直すなら Selenium脱却×Playwright移行ガイド26年8月 でSelenium依存の解消も検討できる
なぜここまで対策が必要になったのか
YouTubeに限らず、Cloudflareなどのアンチボットベンダーはブラウザのフィンガープリンティング(User-Agent文字列、画面解像度、フォント構成、WebGLレンダリング特性など)を分析してbot判定の精度を上げ続けている。スクレイピング側とアンチボット側は継続的な「いたちごっこ」の関係にあり、今回のnチャレンジ強化もその一環と見てよい。
重要なのは、この手の対策は一度直したら終わりではないという点だ。EJSソルバーの取得元(GitHub)の中身が変われば再び解けなくなる可能性があるし、Cookie自体もセッション切れで失効する。yt-dlp本体・deno・Chromeのバージョンが噛み合わなくなることもある。「気づいたら止まっていた」を防ぐには、定期的な疎通確認とエラーログの監視が実質必須になる。
運用時に必ず確認すべき規約・著作権の線引き
ダウンロード対象の権利関係
yt-dlpの技術的な回避策が使えることと、それを使ってよいかは別の話だ。YouTubeの利用規約は自動化されたアクセスやコンテンツの無断ダウンロードを制限しており、他者の動画を無断でダウンロード・再配布すれば著作権侵害のリスクを負う。日本の著作権法第30条の4は「情報解析」目的での利用を認める例外規定だが、解析用データをそのまま元の市場と競合する形で公開・配信する用途は対象外とされる点に注意したい。
安全に使える範囲
- 自分が権利を持つ動画(自チャンネルのアーカイブ・素材バックアップ)のダウンロード
- ライセンスで二次利用が許可されているコンテンツの取得
- ログイン必須ページなど非公開領域への大量アクセスは不正アクセス禁止法の対象になり得るため避ける
他者のコンテンツを対象にする場合は、公式APIが提供されていないか先に確認し、無い場合でも高頻度アクセスや大量ダウンロードは偽計業務妨害のリスクがある行為だと理解した上で判断する必要がある。
自分で保守し続けるコスト
今回のようなCookie認証+EJSソルバーの組み合わせは、その場では数行の設定で直る。ただし、YouTube側の仕様変更は予告なく起き、直った対策も数ヶ月後にまた効かなくなる可能性がある。Chromeのログイン状態を維持し、denoのバージョンを追従させ、yt-dlp本体を定期更新し、エラーが出たら原因を切り分ける――この一連の保守作業を継続的に行える体制がないと、気づかないうちにデータ収集パイプライン全体が止まっていた、という事態になりやすい。
「Sign in to confirm you're not a bot」や「Only images are available」でyt-dlpが止まった場合、まずは--cookies-from-browserと--remote-components ejs:githubの組み合わせを試すのが2026年8月時点での有効な対処法だ。ただし、これは恒久対策ではなく、YouTube側の仕様変更に応じて継続的にメンテナンスが必要な性質のものである。ダウンロード対象が自分の権利物かどうかの確認も忘れずに行いたい。