私はBunが心配だ
(wwj.dev)- Bunは高速なJavaScriptランタイムであり、TypeScript作業を楽にするツールだが、Anthropicによる2025年12月の買収以降、製品方針や運用方法の影響を受けるのではないかという懸念が強まっている
- 買収発表では、BunはオープンソースとMITライセンスを維持し、同じチームが開発を続けると説明され、Claude CodeがBun実行ファイルとして配布されているため、AnthropicにはBunを安定して維持する直接的な動機があるとされた
- 2026年4月以降、Claude Codeでは品質低下、制限的な挙動、サードパーティ製ハーネスの制限、課金の混乱、遅いコミュニケーションが問題視され、Anthropicのengineering postmortemは、デフォルトの推論努力値の低下やプロンプト変更といった製品レイヤーの問題を原因として挙げた
- TechCrunchとGigazineの報道によれば、Claude CodeはOpenClawのようなサードパーティ製ハーネスのサポートに追加料金を求めたり、git履歴に
OpenClawという記述があるだけでリクエスト拒否や追加課金を引き起こしたりする可能性があり、予想外の挙動が明らかになった - Bun自体やBunチームの品質問題ではなく、Anthropicの方針がBunに染み込む可能性が不安を生み、一部プロジェクトではパッケージ管理用途をpnpmへ移し、新しいJavaScript・TypeScriptプロジェクトでもpnpmを勧める方向に変わっている
Bunへの懸念が強まった背景
- Bunは高速で実用的なJavaScriptランタイムで、小さなスクリプト・アプリ・テスト・ツールにおけるTypeScript作業を楽にしてくれる
- 高速なインストール、高速なテスト、より良いバンドリング、削減されたツールチェーン負荷によって、Node.jsの代替として成功が期待されるツールだ
- 懸念の核心はBun自体の品質ではなく、BunがAnthropicの傘下に入った後、製品方針と運用方法の影響を受けうる点にある
Anthropicによる買収と当初の期待
- Anthropicは2025年12月にBunを買収した
- 買収発表によれば、Bunは引き続きオープンソースとMITライセンスを維持し、同じチームが開発を続け、ロードマップも高性能JavaScriptツールとNode.js互換性に集中するとされた
- 発表には「Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent.」という一文が含まれていた
- 当時はClaude CodeがBun上で動作している以上、AnthropicにはBunを高速かつ安定的に維持する直接的な動機があると考えられた
- その論理は今でも妥当だが、Anthropicのソフトウェア製品運営のやり方にほころびが見え始めているのではないかという不安が生じている
Claude Codeに対する評価の変化
- Anthropicのモデル品質そのものが主な懸念ではない
- Claude Opus 4.6と推定されるモデル群は、コーディング、文章作成、推論、一般的な開発作業において依然として優れたモデル群と評価されている
- 問題はモデルの周辺にある製品レイヤーであり、現在のClaude Codeの使い勝手が大きく悪化しているという点が重要だ
- 約1年前のClaude Codeは、プロジェクトを読み、焦点の定まった修正を行い、コマンドを実行し、ミスを修正しながら作業を継続できるツールのように感じられた
- 当時のClaude Codeは、開発者ワークフローが補完中心からエージェント中心へ移行しうるという確信を与えた初期のAIコーディングツールの一つだった
- 2025年12月の時点でもClaude Codeはすでに悪化しつつあったが、それでもまだ実用的であり、Bun買収もAnthropicがコーディングツールの未来を作っているという観点からは納得できるものだった
2026年4月以降のClaude Code問題
- 2026年4月以降、開発者たちはClaude Codeの品質、制限的な挙動、サードパーティ製ハーネスの制限、わかりにくい課金、遅いコミュニケーションを問題として挙げ始めた
- Anthropicはengineering postmortemを公開し、デフォルトの推論努力値の低下、古いセッションのバグ、コーディング品質を損ねたプロンプト変更といった製品レイヤーの問題を原因とした
- この事後分析は、何もなかったかのように済まされるよりは良く、Anthropicが自らの責任を認めた珍しい例として受け止められた
- TechCrunchの報道によれば、AnthropicはClaude Code加入者に対し、OpenClawやその他のサードパーティ製ハーネスのサポートには追加料金が必要だと通知した
- Gigazineの報道によれば、git履歴に
OpenClawがあるだけで、Claude Codeがリクエストを拒否したり追加課金を発生させたりする可能性がある - その報道はTheoの発言を引用し、JSON blob内の最近のコミットにOpenClawへの言及があるだけで、空のリポジトリで
claude -p "hi"を直接呼び出した際にも挙動がトリガーされ得たと伝えている - 関連する場面は動画クリップでも確認できる
- こうした挙動は、実際のコードレベルの利用体験を十分に社内で使い込まないまま変更を出している製品のように見えてしまう
- 外から見ると、Claude Codeはより多くの制限、不可解な課金、コミットテキスト次第で変わる予想外の挙動によって、誤った方向へ進んでいるように見える
- この流れは**エンシッティフィケーション（enshittification）**と表現されている
Bunへとつながる不安
- BunはClaude Codeの内部に深く組み込まれており、Claude Codeが悪化しているように見える以上、Bunも同じ方向へ進むのではないかという懸念が生まれる
- これはBunが悪いとか、Bunチームが関心を失ったという意味ではない
- 問題は、BunとBunチームがAnthropicにより深く統合されるほど、Anthropicの方針も一緒に持ち込まれうる点にある
- Claude Codeを壊したように見える方針がBunにも影響すれば、Bunでもチームが自分たちの製品を実際には使っていないように見える問題が現れるかもしれない
- その可能性だけでも、一部プロジェクトではBunの利用を続けるべきか自信を持ちにくくなる
当面はpnpmへ移行
- Bunはpnpmより多くの機能を一つのツールにまとめて提供している
- Bunは別個のビルド段階なしにTypeScriptをサポートし、
Viteの代わりとなるバンドラを提供し、vitestの代わりとなるテスト機能も備える - こうした機能を単一のツールチェーンとしてまとめて提供する点は、実際に大きな利点だ
pnpmはNode.jsの代替でもBunの代替でもなく、単なるパッケージマネージャーだ- ただし日常作業においてBunを最も頻繁に使う部分がパッケージ管理であるなら、高速なインストール、優れたモノレポ対応、妥当なディスク使用量はBunとpnpmの両方が提供している
- 現在Bunを使っている一部のプロジェクトでは、Bunから離れてpnpmへ移行する選択が取られている
- 今、JavaScriptやTypeScriptプロジェクトに何を勧めるかと問われれば、答えはpnpmになる
Bunを離れるべきだという勧告ではない
- 一部プロジェクトをBunから移してはいるが、これを一般的な正解として受け取る必要はない
- 新規プロジェクトにはpnpmが妥当だ
- 既存プロジェクトでは、移行するだけの十分な理由が生じるまでBunを維持するという選択も可能だ
残された可能性と結論
- Bunが引き続き優れた状態を保ち、Bunチームが良い成果を出し続け、AnthropicがJavaScriptエコシステムに合った判断を行えるよう十分な自律性を与えることが望まれている
- Anthropicには資金も配布力もあり、Bunの性能と安定性を気にかける現実的な理由もある
- Bunは今回の状況を経て、なお一層強くなる可能性もある
- ただし、2025年12月時点より現在の状況に対する信頼は低下している
- かつてのClaude CodeはAnthropicが開発者ツールを理解している証拠のように見えたが、今ではAnthropicが製品を長期的に維持し改善するために必要なことを理解していないかもしれないという警告のように見える
- Bunは今なお優れているが、今後どこへ向かうのかは見通しにくい
- 1年後には状況がまったく変わっているかもしれないため、この予測が当たっていたかどうかを改めて確認するつもりだ
3件のコメント
bunのおかげでnodeもかなり変わったのは認めますが、リポジトリでAI同士がPRで勝手に大騒ぎしているのを見ると、これまで動いていたものが動かなくなる回帰の地雷を踏みそうで怖いです。
Anthropicによる買収前はbunをメインで使っていましたが、今はまたnodeに戻りました。
sfx機能は今でもキラー機能だと思いますが、それが必要でないなら今すぐbunを使う理由はあまり分かりません。
Hacker Newsの反応
全体の前提には同意しない。買収前であっても、Bunはいずれ収益化の方法を見つける必要があったはず
親会社が別のソフトウェアであるClaude Codeで悪い慣行を見せているからといって、それがそのままBunをより悪くすると見るのは行き過ぎ。懸念は理解できるが、Bunについてはまだ楽観的
Claude CodeはAnthropicの中核製品で、成長も極端に速く、小さな変更でも課金問題につながりうる。一方でBunはJavaScriptランタイムであり、最高のランタイムになることに集中できるし、Anthropicの売上や損益に直接影響しないため、Claude Codeのように乱用を理由に慌ててパッチを出す必要も少ない
今後数年でどうなるかはまだ不確実だが、買収直後の今の時点ではそこまで心配していない
こうした研究所は、サードパーティの実行ツールが基盤LLMをコモディティ化する危険があるので、その競争を殺そうとしている。同時に、互いにどれだけ長く赤字を耐えられるかというチキンレースもしている
結局は製品価格をきちんと付けなければならず、それまでにあらゆる競争相手を潰せていることを願うしかない。だがそのゲームはすでに負けつつあるように見える。有用なモデルは年々小さくなり、実行コストも下がっているため、サブスク利用者基盤がなくてもサードパーティの実行ツール開発が続く閾値をすでに越えている
中核的な賭けだった「有用なAIには極端に高価なハードウェアが必要だ」はすでに失敗しており、ユーザーをエコシステムに囲い込んで後から収益化するという第二の賭けも失敗するだろう。結局、製品そのものの実力だけで競争しなければならず、それははるかに収益性が低い
あるチームは今やAIにすべてを賭け、コードも直接見ないほうがいいという方向に動いている。実際に見たが、結果は予想どおりだった。ある程度まではうまく回るが、特にチームごとに技術用語や理解が異なると複雑さが積み上がり、ミスも蓄積し、最終的にはソフトウェアが実際にどう動いているのかを知る人やチームがいなくなる
人がテストや品質保証をせず、単体テストや統合テストに加えてAIにブラウザやツールを操作させる流れもある。Anthropicの文化がBunチームの運営方法や考え方を変えてしまうかもしれない
こうした文化や考え方が標準になれば、モデルがずっと良くなるか、さもなくばソフトウェア品質が下がることになる
Matt Pocockの良い講演がある: https://youtu.be/v4F1gFy-hqg
「コードは安くない。悪いコードはこれまでで最も高くつく。なぜなら変更しにくいコードベースを抱えていると、AIがもたらす豊かさを活かせないからだ。良いコードベースではAIは本当に、本当によく働く。」
悪いコードが自己増殖し始めると、そこから抜け出すのは非常に難しい
人々がなぜNodeではなくDenoやBunを使うのか分からない。JavaScriptランタイムに競争相手がいるのは良いことだが、Nodeから乗り換えて得られる利点がよく分からない
BunにはREPLがなく、JavaScriptエンジンもより悪いし、Denoは制限が多く煩わしい権限システム付きのNodeのように見えるし、sqliteもないと思っていた。どちらも性能が良いと言われるが、都合よく選んだベンチマークでだけそう見えるだけで、1年ほど前に自分で試したワークロードではどちらもNodeより遅かった
ただ、以前に小さなERPツールを納品したとき、プロジェクトを
*.exeに包むツールがBunのものが最もしっかりしていたのでBunを使った記憶がある。依存関係のないJavaScriptなので全体はNodeで作り、配布だけBunにしたが、その体験は確かにNodeより良かったBunはもともとまともに運営されていたことがあまりなかった。機能ごとにバグや抜けが多く、リリースごとにいくつか直すと別のものが壊れていた
直近のパッチリリース1つに、たいていのソフトウェアならメジャーバージョン2回分で経験するような主要機能と破壊的変更が詰め込まれていた
基本的にスクリプト実行器とnpmパッケージマネージャとしてしか使っていないのに、「良い」バージョンを見つけるために必要な作業量が驚くほど多い。パッチバージョンでインストール中に突然止まったことが何度もあり、そのせいでしばらくアップグレードもできなかった
2つ前くらいのマイナーバージョンでは、trustedDependenciesとpostinstallスクリプトを完全に壊したように思える。リリースノートには一言もなく、GitHub Issueにも誰も報告していないようだった。1.1ごろにはBunにpostinstallでtrustedDependencyのビルドをさせられたが、その後はできなくなり、何か月も壊れたままだ
spawnはエラーなしで静かに停止し、スキャナはpostinstallとは別なので
--ignore-scriptsも役に立たない。少なくとも1.3.5から壊れているBunで働いているが、この記事は少し混乱している。個人的にもBunチームとしても毎日Bunを実際に使って改善しており、開発速度はむしろ上がっている。Anthropic参加後はBunの安定性も大きく向上した
次のBunバージョンに入るものとしては、Windows x64バイナリの17MB削減 [0]、Linuxバイナリの8MB削減 [1]、残った子プロセスを再帰的に終了する
--no-orphansCLIフラグ [3]、Mongoose/MongoDBのようなデータベースクライアントのメモリ使用量を大きく減らすクライアントTCPおよびUnixソケット向けのSSLコンテキストキャッシュ [4]、fetchの実験的HTTP/3およびHTTP/2クライアント [5]、Bun.serve()の実験的HTTP/3サポート [6]、内蔵画像処理ライブラリBun.Image[7] などがあるさらに
node:fs、Worker、BroadcastChannel、MessagePortの信頼性改善も入るAnthropicによる買収のおかげで、Bunはもはや売上を出す事業である必要がない。Claude CodeがBunに依存しており、多くのソフトウェアエンジニアがClaude Codeに依存して仕事をしているため、Bunをより良くする強いインセンティブがある
[0]: https://github.com/oven-sh/bun/pull/30219
[1]: https://github.com/oven-sh/bun/pull/30098
[2]: https://github.com/oven-sh/WebKit/pull/211
[3]: https://github.com/oven-sh/bun/pull/29930
[4]: https://github.com/oven-sh/bun/pull/29932
[5]: https://github.com/oven-sh/bun/pull/29863
[6]: https://github.com/oven-sh/bun/pull/30032
Bunが例外になる可能性はあるが、懸念が根拠のないものだとは言えない
AnthropicのCEOは、AIが人間プログラマーをほぼ置き換えるかのような誇張された予測を頻繁にしてきたし、Anthropicはその信念をClaude Codeに適用して保守不能なスパゲティにしていっている
ナイフ研ぎサイトのバックエンドをBunからNodeへ移すのに数時間かけたが、ロックイン効果を避けられて気分が良い。最初はBunにかなり熱心だったが、だんだん確信が薄れていった
恋しくなる機能は、タグ付きテンプレートリテラルでsqliteを問い合わせられること、
Bun.password.verifyがデフォルトでargon2を使うこと、HTMLのimport、JSX変換、.envファイルの自動読み込みだhttps://burlyburr.comからhttps://backend.burlyburr.comを呼んでいる
https://nodejs.org/api/sqlite.html#databasecreatetagstoremax...
.env自動読み込みとsqliteをサポートしているBunは買収前からうまく動いていたとは思わない。小さなスクリプトには使い続けたが、仕事でBunでサービスをデプロイすることはなかっただろう
メモリ問題や修正されない非互換性のせいで、Node.jsに改善の余地があることを示した、まずまずの玩具くらいに見ていた
たとえば https://github.com/oven-sh/bun/issues/14102 をずっと追っていたが、結局ライブラリ側が「Bunならxをする」という分岐を入れるようになり、これは互換性の正反対だ
Claude CodeとAnthropicの流れは、何かをユーザーから無理やり隠そうとする方向に見える。
xxx.yyを読む動作がファイル1つ読みから2つ読みに変わったときの騒ぎを覚えている人もいるだろうこの種の変更はさらに続き、設定できないか、設定が非常に難しかった。事業上の意図は理解できる。できるだけAIを使わせ、人間をループから外し、より多くの学習データとより多くのトークン消費を得たいのだ
だがその結果、Claude Codeははるかに悪く、はるかに信頼しにくいものになったと思う。ハンドルをユーザーからこっそり奪おうとする試みのように感じる。その論理をたどれば、ますます多くのことが正当化されてしまう
今のところ、主に不信感が大きくなっただけだ
元記事に同意するし、人によってはまだ早い反応に感じられるという点も理解できる
私たちは以前とは大きく違う世界に生きていて、人々は倫理的懸念をより強く意識し、過去の過ちを繰り返さないために踏みとどまろうとする意志も強くなっている
技術的な基準では早計かもしれないが、倫理的懸念という基準では筋が通っている。不正行為は以前のように簡単には元に戻せず、そうした決定が生む大きな影響を避けるには先手を打つ必要がある
筆者は最後に、Bunで気に入っているがpnpmにはないものを列挙している。リストはおおむねネイティブTSサポート、Vite風バンドラ、Vitest/Jest風テストランナーだ
バンドラを除けば、Nodeにもすでに全部ある。テストランナーの文法は違うかもしれないが、TypeScriptはデフォルトで「そのまま動く」し、内蔵テストランナーも十分実用的だ。Bunをそこまで惜しむ必要があるのかはよく分からない
Jarred Sumnerの巧みなソーシャルメディア・マーケティングが、現在の推進力のかなりの部分を生み出したとも言える。人々に話題にさせ、そのおかげでNodeも良くなった
さらに、BunがNode APIをできるだけ多くサポートしようと強く押し進めたおかげで、Denoも同水準の互換性へ動き、今ではほとんどのコードが実質的にランタイムへの結び付きが弱くなった。本番環境でBunを使うかは分からないが、Bunが存在しただけでJavaScriptエコシステムは大きく良くなったので嬉しい
node main.tsをそのまま実行できるのか？正直、Bunはたまにモジュールをテストする以外あまり使っていない。日常的には主にDenoを使っていて、この数年は多くのシェルスクリプトもDenoで書いてきた
最近の使い勝手はかなり気に入っているし、リポジトリ内のモジュールを直接参照するやり方はシェルスクリプトに特に向いている
ただ、機能を開いたままで十分な収益化ができるのか、あるいは少なくとも他の人が複製できる形を維持できるのかは心配だ。だから一定の懸念は理解できる
https://github.com/oven-sh/bun/issues/17723
これだけでも直してくれれば、バックエンドで一度回してみようと思うんだけど…