yt-dlp が Bun を切った本当の理由 — 1.3.14 という分岐点と 'vibe-coded' の政治学
yt-dlp が Bun を切った本当の理由 — 1.3.14 という分岐点と ‘vibe-coded’ の政治学
2026-05-22、yt-dlp の単一の GitHub Issue がその週の話題となった。Bun のサポート範囲を 1.2.11 〜 1.3.14 の狭い区間に強制的に限定し、それ以後のいかなる Bun も使うなという明示的シグナルだ。その決定の本当の重みは、1.3.14 という小さな数字ではなく、AI がコードを書く時代の OSS 信頼モデルがどこへ向かうのかにある。
導入 — 単一の Issue が可視化した分岐点
2026 年 5 月 22 日、yt-dlp の GitHub リポジトリに単一の Issue が立った。Issue 番号 16766、タイトルは “Bun support is now limited and deprecated”。本文は 2 段落に過ぎないが、決定の重みは小さくない。yt-dlp の次のリリースから Bun の公式サポート範囲は正確に 1.2.11 〜 1.3.14 の閉区間に絞られる。これまでの最小バージョンが 1.0.31 だったことを踏まえれば、広範な互換約束から狭いホワイトリストへの急激な後退である。そして 1.3.14 を超えるいかなる Bun も yt-dlp は責任を負わず、将来完全に切る権利も留保する。
同じ日に HN に立ったスレッドは、5 時間で 501 点と 514 件のコメントを集め、その週の二番目に大きな話題となった (一番目は Anna’s Archive の LLM ブロック記事)。514 というコメント数が意味するものは、単純な yt-dlp のポリシー変更ではない。Issue 本文の第二段落が矢の本当の方向を指す — 「Bun が最近 Claude を使って Rust に書き直され、その開発が完全に ‘vibe-coded’ の方向に転じたことが、警告的かつ失望的である」という断固たる表現。‘vibe-coded’ は 2024 〜 2025 年の新語で、AI に丸ごとコードを生成させ、その上に人間の深い理解なしに意思決定を載せるパターンを指す。yt-dlp の一行の決定が、一時代の信頼問題を可視化した事件だ。
本稿はその決定の事実関係と、二つの正当化 — サプライチェーンリスクと ‘vibe-coded’ による信頼の喪失 — を分離して見て、より大きな時代精神 — AI がコードを書く環境で OSS の信頼モデルがどのように再編されるか — を追っていく。
本文 1 — 1.2.11 と 1.3.14 という二つの端点の意味
Issue 本文の二つの端点は偶然の数字ではない。どちらの数字も yt-dlp の意思決定構造の中で意味を持っている。
まず下限 1.2.11。yt-dlp の JavaScript 実行環境 — Node.js / Deno / Bun — は ejs という JavaScript challenge フレームワークを通じて動作する。ejs は一部のウェブサイトのコンテンツ保護メカニズムを回避するために、小さな JavaScript コードを実行する必要がある場合のアダプターである。ejs の依存関係をインストールする際、Bun 1.2.0 未満のバージョンは lockfile を無視して新しい解決を進めてしまう。yt-dlp の Issue はこの動作が「最近の npm サプライチェーン攻撃を考慮すると、ユーザにとって重大なセキュリティ懸念」だと明記する。この表現は明確なシグナルだ。同じ 5 月初頭の tanstack/npm サプライチェーン攻撃、4 月末の chalk-utils 偽装パッケージ事件 — すべて lockfile に従わなければ直接影響を受けるカテゴリーである。1.2.11 まで引き上げた正確な理由は、その上の ejs テストスイートを動かすための最小条件である。すなわち下限はセキュリティ + 検証の二変数の積だ。
上限 1.3.14 の意味はより重い。Bun の README と公式ブログをたどれば、2026 年 4 月のある段落に答えがある。Bun チームは 2026 年春にコードベースの大部分を Zig から Rust へ移す大規模な書き直しを断行し、その書き直しは人が一行ずつ書いたのではなく、Claude を用いた大規模変換作業として進められた。公式表現は “AI-assisted port” だったが、作業の絶対多数が LLM によって生成されたコードであることは否定しなかった。1.3.14 が yt-dlp のホワイトリストで最後のバージョンとなった理由は単純だ — 1.3.14 が元の Zig コードベースでビルドされた最後のリリースだから。1.3.15 からは Rust 書き直しの成果物であり、そのコードの深い理解が Bun チーム内で誰にあるのかも明確ではない。
yt-dlp の決定構造は、二つの端点で同じ論理に従う。検証されていないコードパスを信頼ツリーから切り落とす。下限 1.2.11 は lockfile 無視という検証の不在の境界だ。上限 1.3.14 は人のレビューを経ていない (または経たと検証不能な) AI 生成コードの境界だ。二つの端点の間の狭い区間だけが、yt-dlp のメンテナが「この中なら信頼できる」と判断した領域である。
ここに二番目の重みが続く。Issue 本文は「必要であれば Bun のサポートを完全に切る権利を留保する」と明記する。1.2.11 〜 1.3.14 という狭い区間さえ永続的な約束ではなく、暫定的な合意である。その暫定合意の終わりは (a) ejs が 1.3.14 互換を維持できなくなる時点か、(b) yt-dlp チームが狭い区間維持の負担が十分大きくなったと判断する時点である。Bun の未来のどのリリースも、このホワイトリストに再び入る道はない。1.3.14 以降の Rust コードベース全体が、yt-dlp の信頼ツリーの外に永久に残る。
メンテナの bashonly が Issue の最上部にピン留めしたコメントの一行が、状況のトーンを示す — 「本当に yt-dlp で bun を使いたくてここに来たのですか、それとも HN のリンクをたどってコメントを残したいだけですか?」。すなわちこの決定は、yt-dlp ユーザ層の小さな需要 (yt-dlp の Bun 利用者比率は 1 桁 % と推定される) と、その決定が生む大きな反響との非対称を、メンテナ本人が認識しているシグナルである。小さな決定が大きな政治的声明になった。
本文 2 — ‘vibe-coded’ の定義と信頼の非対称
HN の 514 件のコメントのうち最も共感を集めたコメントの核となる文 — 共感の情緒をそのまま訳すと — はこうだ。「メンテナが自分のコードベースの大部分を直接書いていないなら、そのコードベースをどうやって理解できるのか」。この一行が yt-dlp の決定の本当の政治学を指す。コードそのものの品質ではなく、コード所有者の理解可能性 が問題なのだ。
LLM 時代以前の OSS の信頼モデルは単純だった。メンテナがコードを一行一行レビューしてマージする。マージされたコードはメンテナの理解の内にある。ユーザはメンテナの理解を信頼することで、そのコードを自分のシステムに取り込む。この信頼チェーンの核となる段階が「メンテナのレビュー」である。レビューが形式ではなく実質となっているとき、チェーンは機能する。
Bun の Rust 書き直しは、このチェーンの一つの輪を明示的に断ち切った。Claude が Zig コードを Rust に変換した結果が、一週間に数千〜数万行規模でメインブランチへマージされ、そのマージのレビュー強度は人が一行ずつ書いたものに比べられる水準ではなかった。Bun チームの公式回答は「テストカバレッジが厚く、リグレッションは見つかっていない」だったが、この回答は レビューとテストが同じ信頼を作り出すのか という、より深い問いには答えていない。テストは既知の入力に対する既知の出力の一致を検証する。レビューはコードの意図とコードの構造の一致を人の理解の内に置く。両者は信頼モデルにおいて異なる次元である。
HN の議論で両陣営の亀裂が最も鮮明に表れたのは、この次元の差をどう扱うかであった。一方の立場は「リグレッションがなければ信頼可能、テストがレビューを代替する」。この立場は結果 (output) の同等性で信頼を定義する。他方の立場は「理解されないコードはリグレッションが起きてもデバッグできない、したがって未来の危機に無防備である」。この立場はプロセス (process) の同等性で信頼を定義する。二つの定義は同じデータを見て異なる結論を出す。
yt-dlp の決定は明らかに後者の定義に手を上げた。そしてその手上げのシグナルが 514 コメントの爆発を生んだ。yt-dlp のユーザのうち Bun を使う比率は小さいが、「メンテナが自分のコードを理解しているのか」という問いは、すべての依存グラフのすべてのノードに適用される普遍的な問いだ。yt-dlp の決定は小さな一ノードを切り落とすように見えるが、その切断の論理が他のノードにも同じように適用され始めたら — つまり「この依存関係のメンテナは自分のコードを理解しているのか」という問いがすべての依存関係に適用され始めれば — OSS の信頼グラフ全体が再編される。
もう一つ微妙な非対称がある。Bun だけの問題ではない。同じ時期に Deno、Node.js、Rust 自身の cargo、Python の uv — ほぼすべての中核ツールのメインコントリビュータが、AI 補助 (assisted) または AI 生成 (generated) コードの比率を急速に増やしている。違いは程度と透明性だ。Bun の場合、単一のメジャー書き直しという可視的な事件があり、Bun チームがそれを明示的に認めたため表面的に可視化されたに過ぎない。他プロジェクトのコントリビュータは同じパターンを静かに適用している。yt-dlp の決定が、一つの特定プロジェクトへの政治的声明ではなく、AI コード比率の透明性を要求するシグナル として読まれうる理由である。
本文 3 — 信頼の新しい資本は理解可能性である
この単一の Issue が次の 12 〜 24 ヶ月で生みうる変化を整理する。三つの筋がある。
第一に、AI コード比率の開示 (disclosure) 要求の台頭。すでに GitHub の一部プロジェクトは、PR に “AI-assisted” や “AI-generated” のタグを自発的に貼る運用を試している。yt-dlp の決定がこの運用の政治的重みを上げた。6 〜 12 ヶ月のうちに、大きな依存関係を持つ中核ライブラリが「このリリースの AI 生成コード比率」や「この PR の AI レビュー水準」のようなメタデータをリリースノートに含める運用が標準になる可能性がある。これはユーザが自分の依存グラフの「AI 露出度」を計算可能にする。食品の栄養成分表のような構造の開示だ。
第二に、メンテナの ‘sole understandability commitment’ の台頭。一行で言えば「このプロジェクトの中核コードはメンテナが人の頭で理解している」という明示的な約束である。小規模プロジェクト (1 〜 3 名のメンテナ) ではこの約束は自然だが、大規模プロジェクト (10 名以上) ではこの約束を守れる領域がコアモジュールに狭まる。その狭まった領域の明示的な境界が、新しい形の SLA のように働く。「このディレクトリ内のコードは人のレビューを経る、このディレクトリ外はそうでない場合がある」というような分離。
第三に、言語／ツール選択の ‘AI 露出度’ 加重。新しい依存関係を導入する際、開発者が見る変数の中に「このツールのコードベースのうち、どれくらいが人の理解の内にあるか」が入ってくる。あるツールの ‘AI 露出度’ が高ければ、そのツールの将来の安定性／デバッグ可能性／リグレッション対応時間に対する信頼スコアが下がる。これはちょうどクラウドベンダの SOC 2 / ISO 27001 スコアのように働く、新しい評価軸だ。そしてこの評価軸は、小さなツールが大きなツールに優位を取れる変数となる — Bun (大きなツール、高い AI 露出) vs Deno (大きなツール、中位の AI 露出) vs 自前の小さなツール (小さなツール、低い AI 露出) の比較が定量的に行われる。
この三つの筋がすべて起これば、OSS の信頼モデルは人の理解可能性を新たな資本とする市場へと再編される。そしてその再編の最初の可視的事件が、yt-dlp の 2026-05-22 Issue になりうる。
ここで一つの反論を真剣に扱う必要がある。Bun の Rust 書き直しがリグレッションを生まなかったのなら、結果的にユーザに何の問題があるのか。この反論の核は、検証 (verification) と理解 (understanding) の同等性の主張だ。しかし両者を分離する理由がある。リグレッションは既知の入力に対する既知の出力の変化としてのみ測定可能である。未知の入力 (新しいユースケース、新しい結合) に対するコードの挙動は、人の理解の内でのみ予測可能だ。AI 生成コードのリスクは既知の入力でのリグレッションにあるのではなく、未知の入力で発見される未来のリグレッションにある。検証は過去を見る。理解は未来を見る。yt-dlp の決定は未来の危機に備えた事前の選択である。
結論 — 1.3.14 という数字の向こうの時代精神
冒頭の問いに戻る。yt-dlp が Bun を切った本当の理由は何か。
表面の理由は二つだった — npm サプライチェーン安全のための lockfile の正しい動作の保証と、1.3.14 までの Zig コードベースに対する信頼の維持。しかし本当の理由は、二つの表面の間を流れている。AI がコードを書く時代において、メンテナが自分のコードを理解しているということの意味が再定義されねばならないというシグナル、そしてそのシグナルを自身の依存ツリーの一つの枝を切り落とすことで明示的に発した一プロジェクトの政治的声明である。
次の 6 〜 12 ヶ月で検証される三つの指標がある。第一に、他の大きな OSS プロジェクトのうち、yt-dlp の決定にならって類似の信頼ホワイトリストを発表する場所が出てくるか。第二に、GitHub / npm / PyPI のようなパッケージレジストリが「AI 生成コード比率」または「人のレビュー水準」のメタデータ標準を提案するか。第三に、Bun チームが次のメジャーリリースでコード理解可能性 (understandability) に対する明示的な約束 — たとえば「このディレクトリ内のコードは人のレビューを経る」のような — を提示するか。三つの指標のうち二つ以上が肯定的に出れば、2026-05-22 の単一の Issue は OSS 信頼モデルの一つの分岐点として記録される。
本稿が残す一行のメッセージはこうだ。AI がコードを書く時代の OSS の信頼は、もはや結果の同等性で定義されない — 人の理解可能性が新たな資本となる。1.3.14 という小さな数字は、その資本がどこまで信頼ツリーに残っているかの境界を可視化した最初の事件である。他のプロジェクトが同じ境界を引くか、そしてその境界が累積して新しい形の OSS 信頼グラフを作り出すかが、次の 1 年の核心的観察点となる。
出典: