yt-dlp: YouTubeの完全サポートに外部JavaScriptランタイムが必須に

 (github.com/yt-dlp)
12 ポイント 投稿者 GN⁺ 2025-11-13 | 2件のコメント | WhatsAppで共有
  • yt-dlpは、数千のサイトから音声・動画をダウンロードできるコマンドラインベースのダウンロードツールで、youtube-dlのフォーク版
  • YouTubeのn/sig復号のため、新たに追加されたyt-dlp-ejsモジュールとともに外部JavaScriptランタイム（例: Deno、Node.js、Bun、QuickJS）が必要
  • Denoがデフォルトランタイムに設定されており、ユーザーは--js-runtimesオプションで別のランタイムを指定可能
  • この変更により、YouTube関連機能を完全に利用するにはyt-dlp-ejsとJSランタイムのインストールが必須
  • 外部ランタイム依存の追加は、YouTubeの暗号化構造の変化に対応するための不可欠な措置であり、今後の保守の中核要素として機能

yt-dlp 概要

  • yt-dlpはyoutube-dlのフォークで、すでにメンテナンスされていないyoutube-dlcをベースに開発されたプロジェクト
  • 数千のウェブサイトから音声および動画をダウンロードでき、さまざまな形式選択・後処理・字幕・プラグイン機能をサポート

YouTubeサポート関連の変更

  • YouTubeのn/sig値の復号のためにyt-dlp-ejsパッケージが必要
    • このパッケージはUnlicenseの下で配布され、MITおよびISCライセンスの構成要素を含む
  • yt-dlp-ejsの実行にはJavaScriptランタイムが必須
    • 対応ランタイム: deno（推奨）、node.js、bun、QuickJS
    • 関連設定は--js-runtimesオプションで指定可能
  • --no-js-runtimesオプションを使うと、デフォルトのランタイム設定を初期化可能

インストールと依存関係

  • yt-dlpはPython 3.10+ (CPython) および 3.11+ (PyPy) をサポート
  • 強く推奨される依存関係:
    • ffmpeg / ffprobe: 音声・動画の結合および後処理用
    • yt-dlp-ejs: YouTubeの暗号解除用
    • JavaScriptランタイム: yt-dlp-ejs実行用
  • 任意のネットワーク依存関係としてcertifi、brotli、requests、curl_cffiなどがある

主なコマンドオプション

  • --js-runtimes RUNTIME[:PATH]: 使用するJSランタイムを指定
  • --no-js-runtimes: すべてのJSランタイムを無効化
  • --remote-components COMPONENT: 外部JSコンポーネントを許可できるオプション
  • --no-remote-components: リモートコンポーネントの読み込みをブロック

重要性

  • 今回の変更により、yt-dlpはYouTubeの最新の暗号化構造を完全にサポートするため、外部JSランタイムを必須要件とする
  • これはYouTubeの継続的なセキュリティ・暗号化アップデートに対応するための構造的転換であり、今後の保守および機能拡張における重要な変化である

関連記事

2件のコメント

 
kimjoin2 2025-11-14

うわ…防ぐのもすごいし、それを突破するのもすごいと思います。どうやって分析して突破しているんでしょうか
 
GN⁺ 2025-11-13
Hacker Newsのコメント

  • Archのリポジトリにすでに含まれているので、そのまま動作する
    yt-dlp --cookies-from-browser firefox --remote-components ejs:github ... コマンドにフラグを追加するだけでよい
    実行時に solver をランタイムへダウンロードするが、0.5秒ほどしかかからない。ダウンロード開始までの速度がかなり速くなった感じがする
    ただ、制限された環境で実行する際には、solver を別コマンドで事前取得できるとよさそう。今のままでも満足だが、パッケージングの自動化 ができればさらに便利だと思う

    • 速度が上がったのはうれしい。最近はブラウザでも YouTube がまともに動かないのに、Python スクリプトでアクセス可能な状態を維持しているチームはすごい
    • どんな環境なら Python は動くのに JS は動かないのか気になる
      セキュリティが心配なら、Deno を使う限り サンドボックス化 はしっかりしている
      もし Deno や Node が対応していない OS なら、C で書かれた QuickJS を検討してもよい。遅くはあるが、ほぼあらゆる環境で動作する
      ただしこの場合、サンドボックス化は失われる。それでも公式 YouTube ドメインから提供されるコードなら信頼できると思う
    • solver を事前に取得したいなら、適当な動画を一度ダウンロードしたあと、yt-dlp のキャッシュディレクトリ（例: /home/username/.cache）から ejs ファイルをコピーすればよい
      あるいは make yt-dlp-extra で パッケージングの自動化 を試せる
    • AUR の yt-dlp-ejs パッケージ はまさにその目的に合っているようだ
    • 自分は Deno を Chocolately で手動インストールし、yt-dlp も choco で入れていて、バージョンは v2025.10.22 だ

  • 最近 YouTube は 埋め込み動画に referrer ヘッダー を必須にし始めた
    直接 youtube.com/embed/<videoid> にアクセスするとエラーが出て、FAQ にも意図されたポリシーだと明記されている
    公式ドキュメント によれば、埋め込み側は HTTP Referer を提供する必要があり、そうでないと “error 153” の画面が表示される

    • たいていの埋め込みサービスは、だんだんこういう方向に進んでいる。目的は トラッキング強化 だ。ログインを要求するところさえある
    • 実際には、簡単な JS リダイレクタ 1 行で回避できる。実装コストは数十万ドルなのに、回避コストはゼロだ。結局のところ「その気になればいくらでも塞げる」というメッセージなのだと思う

  • 1991年に QuickTime が出たころは、動画もただコピー・貼り付け・保存できるのが当然だと思っていた
    今では DRM すらない動画でさえ ユーザー体験 がここまで悪くなったのが信じられない

    • 昔より今のほうがずっとましだ。以前は RealPlayer、Flash、コーデックパックなどを入れるうちに アドウェア でシステムが壊れることがよくあった。
      今は OS 標準プレーヤーか VLC ひとつでたいてい解決する
    • 90年代初頭は PC がいちばん面白かった時代だった。今はスマートフォンが主流になり、一般ユーザーにとって コピー/保存の概念 はスクリーンショットや画面録画としてしか残っていない
    • 動画はデータ密度が高く、ホスティングコストも大きい。だから YouTube のような大規模プラットフォームだけが残り、Nebula・PeerTube・Odysee のような代替は品質やコスト面で限界がある
    • 昔はユーザー中心の最適化が目標だったが、今は企業が 自社利益優先 で動く時代だ
    • ATSC 3 の放送規格でも DRM が後から追加され、既存受信機が互換性を失う問題が起きている

  • 自分は 2010年から yt-dlp（youtube-dl 時代を含む）を使って、お気に入りにした動画をすべて アーカイブ している
    今では数万本の動画を保存しており、そのかなりの数はすでにサイトから消えている
    NHK 相撲ハイライトのように1か月しか公開されない動画も保存している

    • いわばデジタル コレクター気質 だ。Google Memories のように、昔の動画を定期的にリマインドしてくれる機能を作ったら面白そうだ
    • チャンネル側が自分で動画を消したり削除したりすることが多いので、よいコンテンツが消える前に保存し始めた
    • インターネット上のものは何でも、いつ消えてもおかしくない。大事なものは自分で保存しておかないと、あとで見返せない
    • 相撲動画を保存している人をここで見るとは思わなかった。自分たちみたいな人はけっこういる
    • コンテンツがあふれる時代に、わざわざ全部保存する必要があるのかとも思う。昔は MP3 や映画を全部集めていたが、今は 写真だけをクラウドに保存 している

  • 広告ブロックと広告挿入の 終わりなき対決 の果てに、結局 AGI/ASI が出てくるのかもしれないと思う。
    双方が LLM を使うようになり、人間はそのあいだで財布と注意力を奪われる存在になりそうだ

  • 10年後には YouTube がブラウザから完全にアクセス不能になるかもしれない
    タブレットアプリに慣れた世代が主流になれば、Google は Web を捨てる自信を持つ気がする

    • 本当に DRM を強制したいなら、専用ハードウェア が必要だ。暗号化されたストリームを L2 認証された機器でしか再生できないようにしなければならない
    • モバイル Web アプリはバグが多すぎて、ほとんど使い物にならない。コメントもしょっちゅう消える
    • それでも Google はずっと Web 中心の戦略 を維持してきた
    • ブラウザで YouTube を見る世代も依然として多いし、中国の bilibili のような代替もある
    • とはいえ購買力のある世代がブラウザ利用者なので、Google がその市場を完全に捨てることはない気もする

  • yt-dlp issue #14404 では Selenium やヘッドレスブラウザを使おうという提案があったが、
    メンテナーチームは「それは 敗北宣言 であり、プロジェクトの精神に反する」と答えた

  • スクレイピングは本当に骨の折れる作業だ。API が頻繁に壊れ、提供側がこちらを嫌っている状況で維持するのは見事だ

    • 「提供側がこちらを嫌っている」というのが、むしろこのプロジェクトの醍醐味のようにも思える
    • 自分には yt-dlp のメンテナンスなんて絶対無理だと思う。あまりに 消耗的な作業 だ

  • YouTube がますますユーザーに 敵対的な態度 を取るようになっているのを感じる
    広告ブロッカー対策、AI 学習用のコンテンツ収集、API 制限など、競争がないことにつけ込んでいるようだ

    • 実際、Google の本当の顧客は 広告主 だ。私たちは彼らの商品にすぎない
      広告主の満足には敏感だが、ユーザーやクリエイターは 消耗品 のように扱われている
      無料で始めて競争相手を消し、独占構造を作ったのは一種の撒き餌戦略だった。
      もう新しい代替が必要だ。有料でも透明性の高いサービスならよいと思う
    • 最近は特に子ども向け動画で スキップできない広告 が増えた
    • YouTube の運営コストは非常に大きいので、広告ブロックがサービス維持に影響する可能性はあると思う
    • 結局、今の ひどい UX（enshittification） そのものがビジネスモデルの一部になってしまっている

  • yt-dlp EJS wiki によると、Deno が推奨される理由は、
    制限された権限でコードを実行でき、npm から EJS の依存関係をリモートで取得できるからだ

    • ただし Deno のサンドボックス化を セキュリティ手段として過信 すべきではない。ランタイムレベルの隔離は弱いため、
      Firecracker のような OS/VM レベルの隔離 を使うほうが安全だ
    • 以前は yt-dlp が Python だけで JS を解釈していたが、ランタイム要件が次第に複雑化し、自前インタプリタでは限界があった