この話、派手さはないのに妙におもしろいです。
Claude CodeはAnthropicの開発補助ツールで、要するに「AIにコード作業を手伝わせるための道具」です。その内部で動く仕組みのひとつに Bun という runtime が使われています。runtime というのは、JavaScriptやTypeScriptを動かすための土台のことです。ブラウザ以外でコードを走らせるためのエンジン、と思えばだいたい合っています。
その Bun が、Rustで書き直された版に切り替わった。
しかも、ユーザーから見て劇的な変化はない。起動が少し速くなったくらい。Jarred Sumnerの「Boring is good」というコメントが象徴的で、私はかなり好きです。技術の世界では、目立つ新機能よりも「地味だけどちゃんと速い」「ちゃんと安定している」ほうが、結局いちばん価値があることが多いからです。
Simon Willisonは、この話をそのまま鵜呑みにせず、自分のClaude Codeを覗いて確かめています。こういう「自分の手で検証する」姿勢、かなり信頼できます。
まず試したのが、実行ファイルの中から文字列を抜き出す方法です。strings というコマンドでバイナリの中に埋まっている文字列を探し、grep で Bun のバージョンを拾っています。
結果として、Bun v1.4.0 (macOS arm64) という文字列が出てきたそうです。
でも記事を書いた時点で、GitHub上の最新リリースは v1.3.14 だった。ここがちょっと面白い。つまり Claude Code の中には、まだ正式公開されていない Bun の版が入っていた可能性が高いわけです。
さらに別のコマンドでは、Rustのソースファイル名らしきものが 563個も出てきたそうです。
たとえば src/runtime/bake/dev_server/mod.rs や src/bundler/bundle_v2.rs といった名前です。.rs はRustのソースファイルの拡張子です。ここまで出ると、「ああ、ほんとにRust版が入ってるんだな」とかなり納得感があります。
正直、こういう確認方法は地味ですが好きです。派手なベンチマークより、実際のプロダクトから痕跡を拾うほうが、現場感があります。
記事では Ajan Raj という人が紹介した、さらに気の利いた確認方法も載っています。
BUN_OPTIONS="--preload=/tmp/bun-version.ts" claude --version のようにして、Claude Code起動時に小さなスクリプトを読み込ませ、Bun.version を表示させるやり方です。これで出てくる値も 1.4.0 だったとのこと。
こういう「隠れた部品の正体を暴く」系の小技は、技術記事の中でもかなり楽しい部類です。ソフトウェアって、表から見える顔と、内部で動いている部品がけっこう違うんですよね。Claude Codeの表面はAIアシスタントですが、その裏では別のツールチェーンやランタイムがせっせと働いている。そういう構造が見えると、製品への理解が一段深まります。
一見すると、「BunがRustになりました」というだけの小さなニュースです。
でも、私はここに2つの意味があると思います。
ひとつは、大規模に配られるプロダクトでRust版が実戦投入されたこと。
Rustは安全性や性能で評価されることが多い言語ですが、実際に大量の端末で問題なく動かすのは別の話です。Jarred Sumnerのコメントにあるように、変更が目立たないまま本番で使われているなら、それはかなり良い兆候です。裏で静かに置き換わって、ユーザーは何も気にしなくていい。こういう移行は理想的です。
もうひとつは、AI開発ツールの裏側も、結局はかなり普通のソフトウェア工学でできているということです。
AI関連の話題は、どうしてもモデル性能とか魔法っぽい部分に目が行きがちです。でも実際には、起動時間、配布方法、内部ランタイム、ファイルサイズ、保守性みたいな、地味な要素が効いてくる。Claude CodeがBunのRust版を使うようになったのも、その延長線上にある話です。夢のあるAI製品も、最後は「ちゃんと速い」「ちゃんと壊れない」に回収される。ここが一番人間くさいし、面白いところだと思います。
この件で印象に残るのは、変化がかなり静かだということです。
ユーザーに「新しいRust版に切り替わりました！」と大々的に見せるわけでもなく、実際には少し速くなっている。こういう改善は、派手さはないけれど、プロダクトを長く使ううえではかなり効きます。
しかも、起動が速くなるというのはAIツールでは地味に重要です。
ツールを開いてから使えるまでの待ち時間が少しでも短いと、体感はかなり変わります。人は100ms単位の差を意識しなくても、積み重なると「なんとなく快適」「なんとなく鈍い」がはっきり出ます。10%改善は、誇張なしにうれしいタイプの最適化です。
私はこういう改善を見ると、技術者の仕事ってやっぱり面白いなと思います。最新モデルを入れました、より賢くなりました、だけで終わらない。裏ではランタイムをRust化して、起動を詰めて、静かに全体を底上げしている。そういう仕事は記事になりにくいですが、製品の肌触りを決めるのはむしろこっちです。
Simon Willisonの記事は、かなり短いノートなのに、ちゃんと「自分で確かめた」痕跡があるのがいいです。単なる伝聞ではなく、コマンドを打って、文字列を拾って、バージョンを照合している。こういう記録は読んでいて信用できますし、何より技術の現場っぽい。
そして、Jarred Sumnerの「Boring is good」。
これ、地味ですが名言だと思います。盛り上がりより、退屈なくらい安定していること。そういうものが、結局は大規模な実運用を支えます。AIの時代だ、生成AIだ、と騒がれていても、最後に勝つのは案外こういう静かな改善なのかもしれません。
