YouTubeダウンローダー Yt-dlp、ダウンロードにDenoのインストールが必須へ変更

 (github.com/yt-dlp)
27 ポイント 投稿者 GN⁺ 2025-09-25 | 1件のコメント | WhatsAppで共有
  • yt-dlpで YouTubeダウンロードを引き続き正常に利用するため、まもなく Deno（または対応するJavaScriptランタイム） のインストールが必須条件に変更される
  • YouTube側の 最近の変更 により、内蔵JavaScript「インタープリター」だけでは JSチャレンジを解けなく なった
  • PyInstaller実行ファイル利用者 はDenoだけ用意すればよいが、PyPIパッケージ利用時 は追加のJavaScriptコンポーネントのインストールが必要
  • 他のJavaScriptランタイム（Node、Bunなど）の対応可能性も残されているが、Denoだけがセキュリティとサンドボックス の面で適している
  • Denoおよび関連依存関係のインストール方法、パス指定について 別途オプションと案内 が提供される予定

yt-dlpのYouTubeダウンロード変更点と新しい要件の発表

新しい要件導入の背景

  • 近いうちに YouTubeダウンロード機能を正常に利用 するには、必須で Deno またはその他の対応JavaScriptランタイムのインストールが必要になる
  • これまでyt-dlpは 内蔵JavaScriptインタープリター を使ってYouTube側のJSチャレンジを解決してきたが、最近の YouTubeの内部ロジック変更 により、既存方式だけではもはや対応できなくなった
  • 変更の規模が非常に大きく、yt-dlpが正常動作するには、必ず 正式なJavaScriptランタイムベースのアルゴリズム を使わなければYouTubeへのリクエストを通過できない

利用者別の準備と対応方法

  • Deno（または対応JSランタイム）のインストール
    • FAQなどで追加対応ランタイムが案内される予定
  • yt-dlpが必要とする一部の JavaScriptコンポーネント のインストールが必要になる可能性
    • インストール方法やyt-dlpの配布形態によって、追加作業が必要かどうかが異なる

公式配布ごとのチェックリスト

  • PyInstallerで提供される公式実行ファイル（yt-dlp.exe、yt-dlp_macos、yt-dlp_linux など）
    • Denoだけインストールすればよく、追加コンポーネントはすでに実行ファイルに含まれている
  • PyPIパッケージ（pip、pipx など）
    • yt-dlpを default オプション依存関係グループ付きでインストールし、最新バージョンへアップグレードする必要がある
    • 例: pip install -U "yt-dlp[default]"
  • 公式zipimportバイナリ（Unix向け yt-dlp）
    • Denoがnpm依存関係をダウンロードできるようフラグを追加する必要がある
    • または、yt-dlp向けの別個のJS solvingパッケージをPython環境にインストールする必要がある（オプション名とパッケージ名は後日告知）
  • サードパーティーパッケージ（pacman、brew など）
    • 対応は各ディストリビューションの方針によって異なる可能性があるが、zipimportバイナリ利用者向けの対処方法を使える可能性がある

ランタイムとセキュリティに関する議論

  • Node、Bunなど代替JSランタイム の対応可能性はあるものの、現時点ではこれらのランタイムはDenoほどの セキュリティおよびサンドボックス機能 を提供していない
  • 今後ほかのJSランタイムを対応するかどうかは議論中であり、最終確定までは Denoを基準 に案内が進められる

Denoインストールに関する追加案内

  • yt-dlpと同様に DenoはGitHubで提供される単一実行ファイル を取得してパス上に置くだけで利用できる
  • 今後 yt-dlpに --js-runtimes オプション が導入され、Deno実行ファイルのパスを指定できるようになる予定（オプション名と使い方は変更される可能性あり）
  • DenoをCurlなどでダウンロードした後、yt-dlp実行ファイルと 同じフォルダーに置けば 正常に動作できる

FAQと補足案内

  • 利用中のOSやパッケージマネージャーによっては PATH追加 などが必要になる場合がある
  • Linuxなどの環境ではDenoがPATHに自動登録されることがある
  • 追加の質問やインストール関連の問題は、FAQやコミュニティで案内される予定

その他のコミュニティ反応と今後のアップデート

  • 一部の利用者は 32bitシステム対応終了 の有無や、配布オプションなどさまざまな波及効果について質問している
  • yt-dlp開発チームは Issue登録、パッチ、コミュニティからのフィードバックをもとに、よりよい案内と支援策の整備を進めている

結論と要約

  • YouTubeのシステム構造変更により、yt-dlpの動作構造と要求仕様 が大きく変わる
  • 重要な変更として、正常なYouTubeダウンロード利用を望むならDenoなどのJSランタイム準備が必須 となる
  • 公式配布方式ごとのガイドラインに従って迅速に対応する必要がある
  • 今後も追加案内、FAQ、インストールガイドが継続的に提供される予定

関連記事

1件のコメント

 
GN⁺ 2025-09-25
Hacker Newsの意見

  • 自分は YouTube Premium の有料契約者だが、先週末に電車で見る動画をダウンロードしようとしたところ、iPad と iPhone の両方で「ダウンロード待機中..」の段階で止まってしまった。再起動しても解決せず、1時間ほど粘って諦めた。結局 yt-dlp で動画を落として USB-C フラッシュドライブに移し、そちらで視聴した。近いうちに「家族間プレミアム共有の制限」ポリシーが導入されたら、そのときは本当に解約するつもりだ。家族が広告なし環境をかなり活用しているので

    • 自分も Premium 契約者だが、iPad アプリで似たような問題に遭遇した。赤ちゃんに見せる動画をダウンロードしようとしても、一発でうまくいかない。腹が立ったので中古の Samsung Galaxy Tab A7 を買って、LineageOS のカスタム ROM を入れた。1TB の SD カードに見たいメディアを全部入れて VLC で問題なく再生している。加えて、F-Droid ストアから入れた NewPipe は公式アプリよりずっと安定して YouTube 動画をダウンロードできる。もともとは yt-dlp みたいなものでメディアを埋めるつもりだったが、今はもう不要になった

    • YouTube Premium に課金しているが、スマホでは翻訳の自動適用をオフにする必要があるので ReVanced で見ている。公式アプリでユーザーが設定を変えられないのが理解できない

    • YouTube に動画をアップしたあと、クリエイターダッシュボードからダウンロードしようとすると（たとえばライブ配信をしてローカルバックアップを取っていなかったり、PC に負荷をかけたくないときなど）、720p の低画質でしか落とせない。一方で yt-dlp なら最高画質で取得できる

    • 広告なし環境が YouTube Kids で動作しなかったので（ShieldTV 使用中）、契約をキャンセルした。たぶんバグだったのだろうが、カスタマーサポートがないのでどうにもならなかった。もともと Play Music の有料会員だったのに、YouTube へ強制移行させられたあとで、これが本当に最後の失望だった

    • 家族共有制限ポリシーの導入を待っていたなら、すでにその件の報道があることを伝えておく。自分にも YouTube からその件に関するメールが来た。今はまだ広告なしで使えているが、実際にいつ適用されるかは分からない。関連記事 を確認できる

  • yt-dlp の「JavaScript インタプリタ」に注がれたエンジニアリングの努力に感嘆する yt-dlp jsinterp.py

    • 問題解決にぴったり合ったアプローチだ。追加オーバーヘッドなしでここまで実装した点が本当に印象的だ

    • 今回の発表でいちばん隠れた核心はまさにここだと思う。すでにここまで複雑な構造になっていたとは知らず、非常に感心した

    • JavaScript の一部分だけを解釈する方式だ。関連する HN の議論は リンク を参照できる

    • コードを少し眺めてみたら、Python の ChainMap を知ることができた

    • 実際にどれほど多くの JavaScript を解釈しているのか、そして 1,000 行にも満たないコードなのに、これをコンパイラ入門の授業で使えるのか気になる

  • 30年以上デジタルメディアを収集してきた「デジタル hoarder」だ。VHS や DVD などの物理メディアはなく、すべてデジタルで保管している。珍しいものや消えそうな資料も少しある。「自宅で Netflix のように運用する」自分のシステムに妻も興味を持ち、広告なし視聴を楽しんでいた。自分は特別な人間だとは思っておらず、みんなストリーミングを使うものだと思っていた。何年も周囲には「自分の持っているメディアに君の好きな番組があったら教えて」と言ってきた。ここ2年で、家族や友人が自分の Jellyfin サーバーへのアクセスを求めたり、自分のテレビの下に小型サーバーを組んでほしいと頼んできたりするようになった。最近は Jellyfin に YouTube チャンネルのアーカイブも追加し、各チャンネルごとにディレクトリと yt-dlp コマンドを使って自動で動画を取得している。ただ、自分が欲しい h264 コーデックではダウンロードできないので再エンコードしている。YouTube 動画は AV1 コーデックで提供されるが、うちのスマート TV がまだこのコーデックをサポートしていないため、自分でエンコードしている

    • 昔は簡単なスクリプトを回していたが、今は ytdltt ytdltt GitHub を使い、Telegram ボット経由で母がオーディオブックのような YouTube 動画を欲しがるときに、ディレクトリごとに整理してダウンロードし、Jellyfin からアクセスできるようにしている。母が3年間で集めたオーディオブックは約 1.2TB だ

    • 似た目的なら tubesync も試す価値がある

    • h264 コンテンツのダウンロードができず、yt-dlp のドキュメントは難しく感じたが、今うまく動いている方法はこんな感じだ
      yt-dlp -f "bestvideo[width<800][vcodec~='^(avc|h264)']+bestaudio[acodec~='^((mp|aa))']"

    • 最近 Pinchflat Pinchflat GitHub を知ったが、*arr スタイルの Web 代替としてバックエンドで yt-dlp を使っている。ダウンロードしたい動画をプレイリストに追加すると自動で取得してくれる

    • Cookie 登録などで bot 検知回避が必要なのか、VPN も使うべきなのか気になる

  • もう Web で単純にデータを取ってくる時代は終わり、数千行の難読化された JavaScript を実行しなければならない時代になった。以前は 1kb の json ファイルを簡単に取得してキャッシュできたのに、今ではブラウザ全体を動かして 100 個のリクエストで 10MB のデータをやり取りし、解析環境もセキュリティプロファイルもめちゃくちゃになる。誰にとっても損だ

    • 前向きに見れば、こうした不便な環境のおかげで 10,000 社ものスクレイピング企業が 10MB のゴミをかき集め、それをまともな API として提供するビジネスチャンスが生まれている。でも今では Web サイトのコンテンツ品質自体も落ちてきており、こうした問題はだんだん重要ではなくなってきている

    • 今の Web は複雑化によって、スクレイピング・防止・回避が延々と繰り返されるゲームのようだ。だが AI/LLMs の登場で（コストは高いが）どんな情報でも引き出せるようになった。近いうちに LLM があらゆる CAPTCHA も突破するだろう。「アナログホール」が常に開いている時代になるかもしれない。カメラやマイクで画面や音を拾うだけで、AI が人間よりうまく解釈できる時代だ

    • 幸い、yt-dlp のような小規模スクレイピングはこれまでになく簡単だ。1〜2時間もかければヘッドレス Firefox と mitmproxy で簡単にスクリプトを作れるし、大量の VPS を回して Web サイト全体を丸ごと引っかくようなことをしない限り、自分の欲しいコンテンツをアーカイブするのは問題ない。Cloudflare も低トラフィックの一般利用者は止めない。最新のブラウザ自動化は簡単なので、単独ユーザーならサイトが SPA でも楽に取ってこられる。CAPTCHA も小規模なら自分で解ける。自分も最近は CAPTCHA が出ると Discord 通知を受け、ノート PC で解いてそのままスクレイピングを続けさせている。有料で買った Webtoon を「ワールドガーデン」アプリに管理されるのが嫌で、自分のデータは自分でコントロールすべきだと思っている

    • 1kb の json でさえ、実際には現代の Web では MB 単位の JavaScript を受け取って実行しないとデータを表示できない構造になっている。自分が欲しいのは 10〜20kb の HTML と少しの CSS、それに画像ファイルだけだ。動画も直接 mp4 でダウンロードできればそれで終わり。シンプルで効率的だが、何かを売ろうとすると話が変わる

    • こうした複雑さの理由は、すべてより多くの広告を売るためだ

  • Nsig/sig - API 呼び出しに必ず含めなければならない特殊トークンだ。base.js（プレイヤーコード）で生成され、yt-dlp などのサードパーティクライアントはこれを回避して抽出する必要がある。以前は正規表現などでコードの一部を抜き出してトークンを得ていたが、今では base.js 全体を実行してトークンを得なければならないほどコードが分散している
    PoToken - 最近 Google が強化したオリジン証明トークンだ。これがないと 403 エラーになる。Android では DroidGuard、iOS ではアプリ用組み込みモジュール、Web では JS コード（チャレンジ）の実行が必要になる。以前は外部ツールで発行する必要があったが、yt-dlp の Deno ベース更新により近く内蔵可能と予告されている
    SABR - サーバーサイド適応ビットレートストリーミング技術で、Google の UMP プロトコルと併用され、サーバーが再生位置やバッファ状況を受け取って最適なバッファリングや広告挿入まで制御する。サードパーティクライアント対応はまだ作業中だ
    Nsig/sig 抽出例:

    • Google と Cloudflare が、署名され完全性検証された少数のブラウザだけに Web を制限したがる理由が、これで分かった

    • Web の PoToken について、JS スニペットを実行するとどうやって bot ではないと証明できるのか気になる。もし単なるクライアント JS なら、ヘッドレス Chromium でも動いてしまうのでは？

    • Google が導入した直後なのに、すでに回避方法が出てきている。結局、大企業であってもクライアントにコンテンツを届ける以上は回避可能だ。だから彼らは皆、閉じた独占的エコシステムを作りたがるのだろう。そうすれば広告を最後まで見せたり、利用料を取ったりできるからだ

  • 少し前に HN に上がっていた話の中には、YouTube がダウンロードツールが動くことを望んでいる、という主張もあった 関連記事1 関連記事2。YouTube は世界 30 億人が使うグローバルサービスを運営しながら、ダウンロードを完全には塞がず、常に「ほどほど」にだけ塞いでいるように見える。世界中の利用者がみな最新の iPhone や Android を使っているなら、すぐにでも DRM をかけるだろうとも思う

    • yt-dlp は旧式スマート TV 向け API を利用している。これらの機器はもうソフトウェア更新を受けないので、このトラフィックが消えればこの機能も終了するかもしれない

    • コンテンツプラットフォームが収益モデルを壊してまでダウンロードを支援したがっている、という陰謀論はまったく筋が通らないと思う

  • YouTube のプレイヤーやページはどんどん重くなっていて、古い PC ではむしろ遅くなるという妙な状況になっている。最近は watch?v= を /embed/ に変えて 480p で見ていたが、同じ動画をダウンロードして再生すると CPU 使用率は 3% 程度で済む。だがこれすらも徐々にうまく動かなくなってきている。一方で、他のサイト（例: ポルノサイト）は体験最適化に気を配っており、ダウンロードツールの遮断にもあまり関心がない
    動画（通常）
    動画（埋め込み）

    • GitHub も同じで最適化が不十分で、i5 第8世代 PC でもほとんど使えないレベルだ。だから自分はスナップショットを取ってオフラインで見るようにしている

    • 最近の YouTube のパフォーマンス低下は、みんなに最新の重いコーデックだけを使わせようとしているせいだ。自分のノート PC は 4K h264 動画でも問題ないのに、720p の YouTube 動画を見ただけであっという間に熱くなってカクつく。ブラウザ拡張の h264ify を使えば特定コーデックをブロックできるが、なぜこういう基本動作を調整できないのか残念だ。動画をダウンロードして見るほうがむしろ楽で安定している

    • 自分だけではない。2025 年第1四半期には埋め込みプレイヤーで見られていたが、第3四半期には Google が意図的に埋め込みプレイヤーを塞いだ。今の YouTube には yt-dlp でしかアクセスできない。yt-dlp と開発者たちに永遠の栄光を

    • 自分は YouTube から離れて PeerTube や P2P ベースのプラットフォームへ移るつもりだ

  • QuickJS（軽量 JS インタプリタ）が遅すぎて、動画1本ごとに 20分以上かかるという報告がある。Deno はずっと高速だが、どうしてここまで差が出るのか気になる
    （参考 Issue #14404 / 返信）

    • QuickJS はバイトコードベースのインタプリタで（Python のように遅く）、単純さと安定性を優先している。一方 Deno は Chrome 級の高効率 JIT コンパイラを使っており、この違いによって、特にある種のコードでは実行速度に 20 倍以上の差がつくことがある。QuickJIT（QuickJS のフォークで、TCC を利用した JIT を追加）は Deno より遅いだろうが、改善の余地はある

    • パフォーマンスがここまで劇的に悪くなったのは、Google が他のインタプリタでは遅くなるよう意図的に作ったのではないかと思えて怖い

    • 面白い話だ。Minecraft（Bedrock、mod 用途）で QuickJS を使っているが、V8 より遅いとはいえ、ここまでの差ではない気がする

  • もう手軽な ripping の時代が終わろうとしている兆候は明らかだ。長期保存したい YT 動画があるなら、今すぐ tubearchivist のようなものを入れてバックアップすることを勧める

    • pinchflat Pinchflat GitHub も代替として勧めたい。完成度は tubearchivist より低いが、自分の経験ではバグが少ない

    • YT が市場を独占して得た価値ある文化・教育資産は、今が最後の保存機会だと思う。tubearchivist は面白そうだが、構築と運用がかなり面倒そうで負担が大きい。しかも発想としてはチャンネル全体からまとめてダウンロードする方向だ。自分の場合は、ダウンロード済みフォルダさえあれば、動画名を解釈してリンクページを作ってくれるとても軽いローカル Web サーバーがあれば十分だ。数クリックで入れられる超軽量な代替があれば勧めてほしい

    • YouTube 映画向けにはすでに DRM ソリューションが入っているのに、なぜまだ全チャンネルへこの技術を適用していないのかも気になる

  • Deno を選んだのは意外だったが、Deno は単一実行ファイルとして配布しやすく、インストール問題が減る。Python ベースのインタプリタは驚くべきハックだったが限界があり、このテーマは以前の Youtube-dl プロジェクトでもすでに議論されていた 過去の HN 議論

    • Node には Deno のようなセキュリティや分離機能がない。同じスレッドでメンテナの意見も見られる

    • Deno のサンドボックス機能も重要な選択理由だ。100% 信頼できるわけではないが、ないよりはましだと思う

    • yt-dlp は YouTube だけでなく、多数の他の（時には危険な）動画ストリーミングサイトにも対応している。したがって、ブラウザのような最低限のサンドボックスは必須だ。設計上、信頼できないコードを実行することになるので、基本的なセキュリティは確保しなければならない