2026年8月1日／株式会社東京ネット工務店 海老沢敦
① 事実
ソフトウェアの世界で、記録が出ました。
2026年5月、「Bun」というツールが、11日間で丸ごと作り直されました。
Bunは、ウェブのプログラムを動かすための土台にあたるソフトです（土台＝パソコンでいえばWindowsのような、他のソフトを動かすための下地。世界中の開発現場で使われています）。それが、中身の言語を丸ごと入れ替えるという工事を受けました。家でいえば、住んだまま基礎を全部やり直すような作業です。
数字を並べます。
- 書き直した量：535,496行（1,448ファイル）
- かかった日数：11日
- 使ったAI：64体のClaudeを並列で
- 記録された作業回数：6,500回
- 費用：約16万5,000ドル（日本円でおよそ2,500万円）
人間は、一人です。
そして、その一人がやったのは、最初の3時間でした。AIと相談しながら「どう移すか」の手引きを600行書いた。それが準備のすべてです。
作った本人が、理由をこう説明しています。
別の言語への書き換えは、少人数のチームで丸1年かかる。ユーザーに何の変化も届かない1年は、我々が選べる現実的な選択肢ではなかった。
タグ＝開発, 運用
1年を、11日で買ったわけです。
ここまでは、成功の話に見えます。実際、技術的には成功でした。
ところが、そのあとに起きたことのほうが重要です。
使う側が、離れました。
ここで、Bunが何なのかを、もう少し正確に書きます。
ウェブページを動かしている言語に、JavaScriptがあります。もともとは、ブラウザの中だけで動く言語でした。それをブラウザの外——サーバーや手元のパソコン——でも動かせるようにした仕組みが、20年ほど前に生まれます。Node.jsといって、いまや世界中のシステムの土台になっています。
Bunは、そのNode.jsと同じ場所に立つ、後から出てきた仕組みです。 役割は同じで、「もっと速い」ことを売りにしていました。
つまり、入れ替えのきく部品です。
そして「yt-dlp」。動画を取り込むための道具で、世界中で使われています。
この道具自体は、JavaScriptで書かれていません。 では、なぜJavaScriptを動かす仕組みが要るのか。
相手が、JavaScriptで隠しているからです。
動画サイトの側は、動画の実際の置き場所を、その場で計算して出すようにしています。<strong>その手順書はJavaScriptで書かれたうえ、</strong><strong>人が読んでも分からないように、わざと崩して書いてある。</strong> だから、<strong>手順書を読んで真似ることはできない。実際にその手順書を動かして、出てきた答えを受け取るしかない。</strong>
だからyt-dlpは、JavaScriptを動かす仕組みを、外から借りてきます。
借り先の候補は、いくつかあります。 Deno、Node.js、そしてBun。yt-dlpにとってBunは、その候補の一つでした。
2026年5月20日、そのyt-dlpの開発チームが、こう発表しました。Bunを、候補から外していく。
理由が書いてあります。
Bunは最近、ClaudeでRustに書き換えられた。そして開発が、完全に「雰囲気で書く」方向へ舵を切ったように見える。これは警戒すべきであり、失望させられる。
「雰囲気で書く」というのは、AIに任せて出てきたものを、人が中身を確かめずにそのまま採用する作り方を指す、この業界の言い方です。
そして、対応を続けるバージョンに上限を設けました。
サポートの上限をバージョン1.3.14とする。それが、元のコードベースから作られた最後のリリースだからだ。
<strong>「AIが書き直す前の、最後の版で止める」</strong>と、はっきり書いています。
もう一つ、作り手の側からも声が上がりました。
書き換え前の言語（Zig）を作った本人が、出来上がったものを<strong>「誰のレビューも通っていない粗悪品」</strong>と呼びました。ソフトの世界では、書いたものを別の技術者が読んで検証する工程（レビュー）があります。
この書き換えには、それを通っていない部分が大量に残っている、という指摘です。開発者が集まる掲示板では800近い書き込みが並び、賛否が真っ二つに割れました。
ここで、背景を一つ足します。Bunは2025年12月に、Anthropic——Claudeを作っている会社——に買収されています。 同社にとって初めての買収でした。
つまり、AIを作っている会社が買った道具を、自社のAIで作り直し、そして使う側の一部が離れた、という順序です。
並べます。
- 作るのは、速くなった（1年 → 11日）
- テストは、通っている
- それでも、使う側は離れた
- 理由は、品質ではなかった
出典：
- 【一次に近い・2026-08-01 確認済】The Pragmatic Engineer「What can we learn from Bun's rapid Rust rewrite with AI?」（535,496行／1,448ファイル／11日／64並列のClaude／6,500コミット／約16.5万ドル／非キャッシュ入力59億トークン・出力6.9億トークン・キャッシュ読み込み720億トークン／コンパイルエラー約16,000件を修正／準備＝3時間の相談と600行の手引き「PORTING.md」）
- Jarred Sumner（Bun作者）の言葉：「A rewrite in another language would take a small team of engineers a full year. A year of zero user-facing impact is not a realistic option we could consider.」
- https://blog.pragmaticengineer.com/the-pulse-what-can-we-learn-from-buns-rapid-rust-rewrite-with-ai/
- 【一次・2026-08-01 確認済】yt-dlp「[Announcement] Bun support is now limited and deprecated」（GitHub Issue #16766／2026年5月20日）
- 「Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. This is alarming and disappointing.」
- 「adding a support ceiling of version 1.3.14, as that is the last release built from the original zig codebase」（＝AIが書き直す前の最後の版で止める）
- サポート範囲は 1.2.11〜1.3.14 に限定。次のメジャーバージョンで完全に落とす可能性も明記。
- https://github.com/yt-dlp/yt-dlp/issues/16766
- 【一次・2026-08-01 確認済】yt-dlpがJavaScriptランタイムを必要とする理由（YouTube側が配信URLをJavaScriptによる難読化で保護しており、署名〈signature〉とnパラメータ〈throttling parameter〉を解くにはplayer JavaScriptの実行が要る。内蔵インタプリタでは不十分になったため、2025年11月12日リリース〈2025.11.12〉から外部ランタイムが必須に）
- 対応ランタイム＝Deno（2.0.0以上）／Node.js（20.0.0以上）／QuickJS／Bun（1.0.31以上）。デフォルトで有効なのはDenoのみで、他はセキュリティ上の理由で既定では無効。 ＝Bunは「候補の一つ」であって、代替が存在する。
- 実行を担うのは
yt-dlp-ejs（yt-dlpのJS実行用パッケージ。公式配布物には同梱） - https://github.com/yt-dlp/yt-dlp/issues/15012 ／ https://github.com/yt-dlp/ejs ／ https://github.com/yt-dlp/yt-dlp/wiki/EJS
- Zig作者による「unreviewed slop」の評（The Register フォーラム／2026年7月13日） https://forums.theregister.com/forum/all/2026/07/13/202622/#c_5301048 （※フォーラム投稿。配信前に、より確かな出典があれば差し替える）
- AnthropicによるBun買収（2025年12月2日／同社初の買収。Bunはオープンソースのまま継続と明記） https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone
- ※起点は海老沢の持ち込み（
メモ/2026-08-01_生産と受容の分離.md）。元になったX上の解説記事は本文で使っていない（著者がNFT・コピートレード系の発信者で、記事末尾が誘導になっているため。数字は上記の一次で取り直した）。
② 構造 — 作れる速さと、受け取れる速さ
この件を「AIはまだ信用できない」と読むと、たぶん間違えます。
テストは通っているからです。動いている。技術的な達成としては、本物でした。
では、なぜ離れられたのか。
答えは、受け取る側にあります。
コードを書く速さは、11日まで縮みました。では、それを読んで、理解して、責任を持って抱え続ける側の速さは、どれだけ縮んだか。
一行も縮んでいません。
yt-dlpの開発チームは、Bunを「使う側」です。使う以上、何かあれば自分たちが対応します。利用者から問い合わせが来るのは、彼らのところです。つまり、彼らは中身を抱える側にいる。
抱える側から見ると、53万行が11日で入れ替わるというのは、一晩で他人の家に建て替わられるのと同じです。建物としては新しくて立派かもしれない。ですが、どこに何があるかを、もう誰も説明できません。
だから彼らは、「元のコードベースから作られた最後の版」で線を引きました。 新しいほうが性能はいいかもしれない。それでも、自分たちが抱えられる範囲で止めたわけです。
これは品質の判断ではありません。受け取れるかどうかの判断です。
経営者の方なら、一度は見たことがあると思います。コンサルティング会社に頼んで、立派な報告書が届いて、そのまま使われずに終わる。
あれが起きた理由を、報告書の出来のせいにしてきたでしょうか。たいていは違います。
読んで、噛み砕いて、自社の仕事に落とし込む人が、社内にいなかった。あるいは、いたけれど、その時間がなかった。 作る側の能力と、受け取る側の吸収する力は、まったく別のものです。 そして発注という行為は、この二つを橋渡ししません。
棚で眠る報告書と、今回の書き換えは、同じ病気の別の症状です。
作る力だけが跳ね上がり、受け取る力は据え置かれた。そして作る力が上がるほど、この差は開きます。
そして、これは外から買ったものだけの話ではありません。
自分の会社の中を、思い浮かべてみてください。誰も受け取っていない作業が、たいてい残っています。
毎月出している報告書。誰かが読んでいますか。 転記している数字。その先で、使われていますか。 回している承認。その承認で、何かが変わったことがありますか。
受け取り手のいない作業は、無駄です。 しかも、はっきりした無駄です。やめたほうがいい。
ですが、まず気付きません。
理由は単純です。受け取られていないことは、事故として表面化しないからです。
報告書が読まれなくても、エラーは出ません。誰も困らない。締切に遅れるわけでもない。作っている人だけが、毎月きちんと作っています。 そして、きちんとやっているぶん、問題として上がってきません。
Vol.07で「エラーは出ない」と書きました。あれはAIの話でしたが、同じことが、人のやっている作業でも起きています。
Vol.09では、誰も読まない報告書や、順番の逆になった承認フローが、組織の中で自然に生まれ続けるという話を書きました。あれは「決めていないことが溜まる」側から見た形です。受け取る側から見ると、こうなります——作る人はいるのに、受け取る人がいない。作業だけが残っている。
さて、ここにAIが入ると、どうなるか。
速くなります。
誰も受け取らない報告書が、これまで半日かかっていたとします。それが5分で作れるようになる。効率化として、正しく成功します。
そして——やめる理由が、さらに消えます。
手間がかかっていたころは、まだ「これ、本当に要りますか」と言い出す人がいたかもしれません。半日かかるから、文句が出た。 5分で終わるなら、誰も何も言いません。
形骸化した作業を自動化するのは、いちばん悪い投資です。 無駄が、無駄のまま、安く固定されます。 そして安いぶん、もう二度と見直されません。
ここで、順序をひとつ確かめてください。
書き換えが終わった日は、ゴールに見えます。 実際、記事にもなりました。11日、2,500万円、53万行。
ですが、抱える側から見ると、その日は違う意味を持ちます。
その日から、誰かが53万行を持ち続けなければならない。 精読した人間は、一人もいません。
つまり——
完成した日は、負債を計上した日でもあります。
設備を入れた日は、資産が増えた日であると同時に、減価償却と保守費が始まる日です。
ソフトウェアも同じで、作った瞬間の値段しか見ないと、判断を誤ります。
仮に、全部を人間が読めばいい、という話にしてみます。53万行を、誰かが精読する。
できません。 時間の問題ではなく、量の問題です。
AIは、人間が読める速さを、はるかに超えて出力し続けます。では、出したものを使うにはどうするか。読むしかない。 ここに、逃げられない矛盾があります。
道具を速くしても、それを受け取る人間の側は速くなりません。
この問題自体は、実は新しくありません。工場の警報や、サーバーの監視が同じ形をしています。機械は毎秒データを吐き続けますが、人間はそれを全部読みません。読むのは、決めておいた線を超えたときだけです。正常なぶんは、機械が見て、捨てる。
つまり、全部を見ることは最初から諦めて、それで回しています。
ただし、ここには代償があります。線を引いて絞るということは、絞られたほうを誰も見ないということです。 減った負担は消えたのではなく、見落としに姿を変えて残ります。
これは解消できません。できるのは、どれだけ見落としているかを、数字で持っておくことまでです。
大きな会社なら、人を増やせます。 読む作業、検査する作業、分けて整理する作業。人を雇ってもいいし、AIにやらせることもできます。資本があるほうが有利なのは、そのとおりです。
ですが、増やせない部分があります。
最後に「これでいく」と決める人の数です。
どれだけ検査を厚くしても、その結果を引き受けるのは、社長なり、ごく少数の決裁者です。 大企業でも変わりません。役員が何人いても、その件について最後に腹をくくる人は、たいてい一人か二人です。
つまり——規模で変わるのは、社長の机に届くまでに何人が読んで、要約して、絞り込んでいるか。その段数だけです。決める人の数のほうは、変わりません。
そして、ここに逆の効果があります。
絞り込みが厚いほど、決める人は「絞られた後のもの」しか見ません。
中小企業では、絞り込みが薄い。社長のところに、生のまま来ます。 整理されていない、雑なままの情報です。ですが「絞られる前」を見ているという点では、そちらのほうが実態に近い。
Vol.09で「決定の所在」の話を書きました。同じことが、ここでも起きています。 組織の話にすると、大企業が有利に見える。決める人の話にすると、条件はほとんど変わりません。
そのうえで、道が二つに分かれます。
一つは、決める人に届くまでの絞り込みを厚くする道です。監視の仕組みを作り、専任を置き、検査を自動化する。出す量は減らさずに、届く量のほうを減らす。
もう一つは、受け取れる量に合わせて、出す量のほうを決める道です。
どちらも、最後に決める人の容量が動かせないという点では同じです。 違うのは、その動かせない数字に合わせて、何を調整するか。前者は絞り込みを、後者は生産量を動かしています。
そして、受け取れないものを作っても、それは資産になりません。棚で眠る報告書と同じで、作った瞬間だけが成果に見えて、実際には何も動かない。
AIをどれだけ動かすかは、目標ではなく、逆算で決まる数字です。 何をどれだけ受け取れるか、を先に置く。そこから稼働量が出てくる。
「AIを動かし続けること自体に価値がある」という前提を外すと、矛盾は消えます。
作れるようになったことと、使えるようになったことは、別です。
Vol.01でこの媒体が掲げたのは、累積とはストックが溜まることではなく、ループが回り続けることだという話でした。
作る → 使われる → 反応が返る → 直す。このループが回って、はじめて溜まります。
使われなかったものは、量としては存在します。 53万行、報告書200ページ、導入したシステム。ですが、回っていません。 積み上がっているように見えて、実際には抱える側の負担だけが増えています。
③ 経営者の自分事
この件を最初に聞いたとき、私が思い出したのは、AIの話ではありませんでした。
コンサルティング会社に頼んで、成果物が来て、実際には使われない。 そういう場面を、これまでいくつも見てきました。
だから今回も、同じ匂いがしたというだけの話です。勘ではありません。何度も見た形だから、分かるというだけのことです。
そして、その「使われなかった」は、たいてい誰のせいでもありませんでした。 頼んだ側に悪意はない。作った側の手抜きでもない。受け取って、噛み砕いて、自分の仕事に載せる人が、その会社にいなかった。 それだけです。
ここで、自分の場合を、順に辿ってみます。
私は一人でやっています。AIに作業を渡せば、渡した分だけ返ってきます。では、返ってきたものを全部読めるか。
