Bunという賭け — Anthropicが買ったJavaScriptランタイムの正体

2025年12月2日、Anthropicが初の企業買収を発表した。買われたのはBun。Jarred Sumnerが2021年に始めたJavaScriptランタイムだ。

これだけ聞くと「AI企業がツールチェーンを抑えにかかった」という話で終わってしまう。しかし実態はもう少し込み入っている。Claude Codeはすでに公開からわずか6ヶ月で年間ランレート10億ドル規模に到達したプロダクトであり、その配布形態がBunの単一バイナリだ。つまりBunが壊れればClaude Codeも壊れる。逆に言えば、AnthropicにはBunを最高品質に保ち続ける直接的な動機がある。

Claude Codeのヘビーユーザーなら、もはやBunは他人事ではない。今回はこのランタイムを掘り下げる。

Bunとは何か

Bunは「all-in-one」を掲げるJavaScriptツールキットだ。ランタイム、バンドラー、テストランナー、パッケージマネージャを単一バイナリに統合している。Node.jsのドロップイン代替として設計されており、初公開は2022年7月、v1.0のリリースが2023年9月8日だ。

特徴的なのは実装言語と採用エンジンの選択にある。本体はZigで書かれ、JavaScriptエンジンにはApple WebKit由来のJavaScriptCore (JSC)を採用している。Node.jsとDenoがGoogleのV8を使っているのとは対照的だ。コードベースの構成比はおよそZigが61%、C++が23%、JavaScript/TypeScriptは11%程度に過ぎない。Node.jsのコアモジュールがJavaScriptで書かれている事実と対比すると、設計思想の違いは明らかだ。

性能差の主因については、興味深い検証結果がある。CPU集約的なタスクでBunが優位に立つのはJavaScriptCoreの設計に由来し、I/Oやネットワーク処理での優位はZigによる低レベル制御に由来する。つまり「Bunが速い」のは単一の理由ではなく、エンジンとシステム層の両方で別々の最適化が効いている結果だ。

履歴を整理しておく。v1.1でWindows対応とBun Shellを追加。v1.2でNode.js互換率が90%を超え、HTMLインポートとビルトインPostgresクライアントを導入。そして2025年10月10日のv1.3で、フルスタックJavaScriptランタイムへと役割を拡張した。

ベンチマークの実像

Bunの数字は派手だ。

• 起動時間:Node.jsの約4倍速(5〜15ms vs 60〜120ms)
• HTTPスループット:Hello Worldで2.4倍(106k vs 44k req/s)
• パッケージインストール:Reactアプリ依存解決で9倍(2秒 vs npmの18秒)
• TypeScript実行:ts-nodeの24倍速(50ms vs 1200ms)

ただし「アプリケーションロジックの速度」が劇的に変わるわけではない。CPUバウンドな処理ではNode.jsとほぼ同等であることを、複数のレビューが指摘している。本当に効くのは起動速度、I/O、そしてパッケージインストールだ。CIパイプライン、CLIツール、サーバーレス関数のコールドスタート、こういった「立ち上げと立ち下げが頻繁な領域」でBunは実力を発揮する。

これはAnthropicがClaude Codeのランタイムに選んだ理由と整合する。CLIは1日に何度も起動される。1回あたり10msの起動時間と100msの起動時間では、開発者体験がまったく違う。

Anthropic買収の構造

買収のロジックを冷静に読み解いてみる。

Bunは買収以前に26百万ドル(約40億円)を調達済みで、Kleiner Perkins(シードの700万ドル)とKhosla Ventures(シリーズAの1900万ドル)が主要な投資家だった。月間ダウンロード数は2025年10月時点で720万を超え、GitHubスター数は82,000以上、Midjourneyや Lovableといった企業に採用されていた。一方で、収益はゼロ。VC調達で4年以上のランウェイは確保していたが、いずれマネタイズの問題に直面することは避けられなかった。

Sumner本人の言葉を借りれば、選択肢は「VCバックドのスタートアップとしてマネタイズに苦闘する道」と「Anthropicに参加して開発の中心で仕事を続ける道」のどちらかだった。後者を選んだ理由は、ライセンスを変えずに済むこと、チームを維持できること、そして何より「5年後10年後にBunが残っているか」という問いに「Anthropicがいる」と答えられること、だった。

買収後の確約も明示されている。BunはMITライセンスのままオープンソースを維持。GitHub上の公開開発を継続。チームとロードマップはそのまま。Node.js互換性とサーバーサイド標準化への注力も変えない。

Anthropic側のメリットも明確だ。Claude Codeは2025年5月のGA以降、わずか6ヶ月で年間ランレートで10億ドルに到達したプロダクトだ。そのインフラが第三者管理のオープンソースに依存している状態は、戦略的にリスキーすぎる。買収は依存リスクの内部化であり、ロードマップ整合性の確保でもある。Mediumのある分析者が指摘したとおり、これはコンピュート資源を買う垂直統合ではなく、「配信メカニズムを買う」垂直統合だ。

Bun 1.3 — フルスタックランタイムへの転回

技術的に2025年最大のリリースは間違いなくv1.3だ。10月10日に公開されたこのバージョンで、Bunは「速いNode.js代替」から「バッテリー同梱のフルスタックランタイム」へと立ち位置を変えた。

主な追加機能を整理する。

ゼロコンフィグのフロントエンド開発サーバー:Bun.serve()にHMR(Hot Module Replacement)、React Fast Refresh、ブラウザコンソールのターミナル転送が組み込まれた。HTMLファイルを直接bun runできるようになり、内部でJSX/TSX、CSS、TypeScriptをトランスパイル・バンドルする。Vite不要の体験だ。内部では「Bake」と呼ばれるインクリメンタルバンドラーが動いており、ファイルを編集するとそのファイルだけが再バンドル対象になる。

統一SQL API:Bun.SQLが、PostgreSQL、MySQL/MariaDB、SQLiteを同じインターフェースで扱える。タグ付きテンプレートリテラルで安全にクエリを書けるため、SQLインジェクション対策も自然に組み込まれる。

Redis/Valkeyクライアント:インメモリストアが標準同梱。HSET/HGETやLPUSH/LRANGEなど66コマンドをサポートしており、外部パッケージなしでセッション管理やキャッシュが書ける。

単一実行可能ファイル:bun build --compileでフロントエンドとバックエンドを丸ごと1つのバイナリにできる。これがClaude Codeの配布形態と直結している。

isolated installs:pnpmスタイルの隔離されたインストール方式が、ワークスペースのデフォルトになった。未宣言の依存にアクセスできなくなるため、依存ツリーの健全性が上がる。bun whyで依存チェーンを調べられるようになったのも地味に効く。

直近のv1.3.12(4月9日)、v1.3.13(4月20日)では、bun ./file.mdでMarkdownをターミナルにレンダリングする機能、Bun.WebViewによるヘッドレスブラウザ自動化、Bun.cron()のインプロセススケジューラ、テストの--parallel/--isolate/--shard/--changedオプションなど、地味だが効くアップデートが矢継ぎ早に入っている。買収後、開発速度は明らかに上がっている。

Claude Codeとの関係

Claude Codeは現在、Bunの単一実行可能ファイルとして配布されている。ネイティブインストーラー(curl -fsSL https://claude.ai/install.sh | bash)が落としてくるのは、Bunのランタイム+JavaScriptCore+Claude CodeのTypeScriptソースを丸ごとパックした約100MBのバイナリだ。

100MBは確かに大きい。比較すれば、gitのバイナリは約3MB、Goの肥大化したバイナリでも15〜20MBに収まる。それでもAnthropicがこの形式を選んだのは、Node.jsの「壊れたPATH」「壊れたnpmキャッシュ」「Nodeバージョン衝突」「800MBのnode_modules」といったサポートチケットの温床から、ユーザーを完全に解放するためだ。

これはエンジニアリング的に最もエレガントな解ではない。しかしサポートコストが最も低い解だ。Docker、Electron、そして今のBunまで、ソフトウェア配布の歴史は同じパターンを繰り返している:共有依存から始まり、互換性問題に苦しみ、最終的に「とにかく動く一塊のバイナリ」に収斂する。

ちなみに、bun build --compileはAOTコンパイル(GraalVMやWASMがやるような機械語への変換)ではない。TypeScriptはランタイムでJavaScriptCoreに解釈される。つまりインタプリタとコードを同じパッケージに入れているだけだ。それでも実用上の問題はほぼ解決する。フルスタックReactアプリをbun build --compileしたバイナリが、同じindex.htmlをnginxよりも1.8倍速く配信できるとSumner自身が示したベンチマークもある。

いつBunを選ぶか

新規プロジェクト、特にCLIツールやマイクロサービス、エッジ向けの軽量サーバーであれば、2026年現在、Bunは合理的な第一候補だ。Express、Fastify、Prismaといった主要パッケージはほぼ動く。TypeScriptがネイティブに走るのでtscもtsconfigと格闘する時間も減る。

一方、エンタープライズの大規模Node.jsアプリケーションをいきなり乗り換える理由は薄い。Node.js 22 LTSは15年分の本番運用で叩かれた、極めて堅牢なランタイムだ。「速くなった」だけでは移行の正当化にはならない。明確なボトルネック、たとえばコールドスタートが致命的なサーバーレス関数や、CIの遅さで生産性が削られている現場でこそ、Bunは効く。

本番採用するなら、"bun": "1.3.13"のように厳密にバージョンを固定すべきだという指摘もある。Bunはセマンティックバージョニングに従っているが、開発速度が速い。パッチリリース間で破壊的変更に遭遇するリスクは、まだNode.js LTSと比較すれば高い。

文化を健全に残すために

Node.jsはJavaScriptサーバーサイドの事実上の標準として15年以上機能してきた。その地位はおそらく今後も簡単には揺るがない。だがランタイムの世界が一極集中ではなくなっていくのは、エコシステム全体にとって健全なことだ。

Bunが面白いのは、単に速いからではない。「すべてを一つに」という設計判断が、現代のJavaScript開発者が抱えてきたツールチェーン疲れに対する明確な回答になっているからだ。webpack、Babel、ESLint、Vite、Jest、tsx、nodemon、npm、pnpm、yarn——これらを全部組み合わせて「Hello World」を出すまでの儀式に、われわれは慣れすぎていた。Bun 1.3が示したのは、その大半が本来不要だったという可能性だ。

そして、その判断にAnthropicが資金と長期的なコミットメントを供給することになった。これはAI時代のソフトウェアインフラを巡る大きな構造変化の、ごく初期の徴候かもしれない。OpenAIはコンシューマー向けのSky(macOS)を買収し、Anthropicは開発者向けのJavaScriptランタイムを買収した。両社の優先順位の違いが、今後のプロダクト戦略にそのまま現れてくるはずだ。

JavaScriptランタイムを選ぶことは、もはやV8かJSCかという技術選択を超えて、どのエコシステム、どの未来に賭けるかの問題になりつつある。