Claude Code の中身が Rust 版 Bun に静かに入れ替わっていた

6 月 17 日から、もう Rust の上で動いていた

結論から書きます。2026 年 6 月 17 日リリースの Claude Code v2.1.181 以降、CLI の内部ランタイムは Zig で書かれた従来の Bun ではなく、Rust に移植された Bun v1.4.0 に置き換わっています。数百万台のマシンで 1 か月以上動き続けて、ほとんど誰も気づきませんでした。

種明かしをしたのは Bun 側です。2026 年 7 月 8 日、Bun 公式ブログに「Bun in Rust」という記事が出て、移植の経緯と数字が公開されました。それを受けて 7 月 19 日、Simon Willison が「本当に Rust 版が配られているのか」を配布バイナリの解析で確かめる記事（Claude Code in Bun in Rust）を書き、Hacker News で 370 ポイントまで伸びています。

私は Claude Code をほぼ毎日使っています。それでも 6 月 17 日の前後で何かが変わった記憶が、まったくありません。この「気づかなさ」こそが今回いちばん面白いところだと思っているので、順に整理します。

なぜ Zig から Rust へ移したのか

移行の動機は速度ではなく、メモリ安全性です。Bun 公式ブログは、Zig の手動メモリ管理と JavaScript のガベージコレクション（GC、不要メモリの自動回収）が同居する構造が、use-after-free（解放済みメモリへのアクセス）や double-free といった不具合の温床になっていたと説明しています。

Zig の速さは Bun の武器そのものでした。ただ、JavaScriptCore の GC が管理するオブジェクトと Zig 側が手で確保・解放するメモリの境界では、「いまどちらが所有しているか」をコンパイラは教えてくれません。Rust なら借用チェッカー（所有権をコンパイル時に検査する仕組み）がその境界ごと検査対象にします。実行時に踏むはずだった地雷を、ビルドの段階でまとめて踏み抜いておける、という発想です。

バージョンの区切りも明確です。Zig で書かれた最後のリリースが v1.3.14、Rust 移植後の最初のバージョンが v1.4.0 になります（Bun releases）。

11 日間・6,502 コミット・Claude 64 並列

移植の規模は、どの数字も桁の感覚がおかしくなります。公式ブログによれば期間は 2026 年 5 月 3 日から 14 日までの 11 日間。1,448 個の .zig ファイルを .rs に変換し、差分は +1,009,272 行、コミットは 6,502 件。ピーク時には 64 個の Claude インスタンスが並列で移植を進めていたそうです。

書き捨ての一括変換ではなく、生成したコードに対して複数の独立した Claude インスタンスに欠陥を探させる、敵対的レビューを組み合わせたと説明されています。それでも 11 日で 100 万行は異常な速度です。私は 3 ファイルのリファクタリングに 1 週間溶かした経験があるので、この数字と競うのはやめることにしました。

その成果が最初に投入された先が、自社製品の Claude Code でした。効果として公表されているのは、Linux での起動時間が p50（中央値）で 517ms から 464ms へ約 10% 短縮、HTTP スループットやビルド時間も数 % 単位の改善、といったところです。逆に言えば、その程度しか変わっていません。100 万行を書き換えた結果が「少し速くなった」に収まっている、というのが本題です。

手元の Mac でも裏を取ってみた

手元でも同じ結論になりました。この記事を書いている Apple Silicon の Mac に入っている Claude Code は v2.1.215 で、npm でインストールしたパッケージなのに、実体は Rust 版 Bun を同梱した 236MB の Mach-O ネイティブバイナリです。

Simon Willison の検証方法は、配布バイナリに strings コマンドをかけて Rust のソースファイルパスを探すという素朴なものでした。彼の環境では 563 個の .rs パスが見つかっています。同じことをやってみます。

$ claude --version
2.1.215 (Claude Code)

$ file $(realpath $(which claude))
.../@anthropic-ai/claude-code/bin/claude.exe: Mach-O 64-bit executable arm64

$ strings -n 10 claude.exe | grep -oE '[A-Za-z0-9_./-]+\.rs' | sort -u | wc -l
353

$ strings -n 10 claude.exe | grep -cE '\.zig$'
0

.rs のパスが 353 件出てきて、.zig のパスは 0 件。埋め込まれたバージョン文字列にも「1.4.0」とあり、Rust 版 Bun の同梱が手元でも確認できました。件数が 563 と 353 で違うのは、プラットフォームとビルド構成の差だと思います。ついでに /Users/runner/.cargo/registry/... という GitHub Actions ランナーのパスまで透けて見えました。パニックメッセージ用に埋め込まれたパスが、ビルド環境の素性まで教えてくれるわけです。

ちなみに claude --version の実測は 0.04 秒でした。Node.js 製 CLI の起動を日常的に待っている人ほど、この数字の異常さが分かると思います。検証の所要時間は全部で 2 分ほど。ベンダーの発表を鵜呑みにしなくても、手元の実行ファイルだけで裏が取れるのは良いことです。

「退屈であることは良い」を運用者として読む

Bun の作者 Jarred Sumner はこの件を、数百万台で動いて何も起きなかったことを指して「退屈であることは良い（boring is good）」と表現しています。ランタイムを丸ごと書き換えて、全ユーザーに配って、事件にならない。派手なベンチマークを 1 つ勝つより、こちらの方がずっと難しいはずです。

一方でこれは、使う側の足元が auto-update で静かに入れ替わり続けている、という話でもあります。私はこれを不安な話だとは受け取りませんでした。理由は 2 つあります。1 つは前の章のとおり、配布バイナリそのものから誰でも裏を取れること。もう 1 つは、変更の経緯と数字が後からでも追える形でブログとリリースノートに公開されていることです。ブラックボックスかどうかは、中身を見せてもらえるかより、外から検証できるかで決まると考えています。

中身が丸ごと入れ替わっても使い勝手が変わらないのは、インターフェースが安定している証拠でもあります。以前 Claude Code のコンテキスト管理でトークン消費を半減させた話 を書いたときにも感じましたが、この道具は表面の使い方より、中で何が起きているかを知っている方が得をする類のものです。その「中」が今回、静かに Rust になりました。次に何かが入れ替わったときも、たぶん私は気づかないと思います。

なお、この記事も AI が下書きを書き、運営者の私が内容を確認・編集したうえで公開しています。