- Claude Code v2.1.181から、Rustへ移植されたBunを内蔵し、Linuxの起動速度が10%高速化したが、ほとんどのユーザーは変化にほぼ気づかなかった
- 実行ファイル内の文字列を調べると、正式タグがまだない Bun v1.4.0 とRustソースファイルのパスを確認できる
~/.local/bin/claudeから、src/runtime/bake/dev_server/mod.rs などを含む 563個の .rs ファイル名が見つかったBUN_OPTIONSでTypeScriptファイルを事前に読み込み、Bun.versionを出力する方法でも、内蔵バージョンが 1.4.0 であることを検証できる- Rust版はBun canaryとして配布されており、Claude Codeを通じてすでに 数百万台のデバイスで本番実行中
Claude Codeに内蔵されたRustベースのBun
- Rewriting Bun in Rustによると、6月17日にリリースされたClaude Code v2.1.181から Rustポートを使用している
- Linuxの起動速度が10%向上
- そのほかの違いはユーザーがほとんど気づかず、Jarred Sumnerはこれを「Boring is good」と評価
- Claude Codeを通じてすでに数百万台のデバイスで本番実行中
- Claude実行ファイル内の文字列から 内蔵Bunバージョンを見つけられる
strings ~/.local/bin/claude | grep -m1 'Bun v1'
- macOS arm64環境では
Bun v1.4.0 (macOS arm64) が出力される
- 当時GitHubの最新正式リリースは5月12日の Bun v1.3.14 だったため、Claude Codeにはまだ正式リリースされていない v1.4.0プレビューが含まれていることになる
- Rust版は Bun canary として公開されており、
bun upgrade --canaryでインストールできる
Rustソースとバージョン検証
strings ~/.local/bin/claude | grep -Eo 'src/[[:alnum:]_./-]+\.rs'
src/runtime/bake/dev_server/mod.rs
src/runtime/bake/production.rs
src/bundler/bundle_v2.rs
- Ajan Rajが共有した方法は、
BUN_OPTIONSでTypeScriptファイルを事前に読み込み、Claude Codeに内蔵された Bun.version を直接出力するもの
cat > /tmp/bun-version.ts <<'EOF'
console.log("embedded bun:", Bun.version);
process.exit(0);
EOF
BUN_OPTIONS="--preload=/tmp/bun-version.ts" claude --version
- このコマンドでも
1.4.0 が出力される
- 5月17日のコミットで
package.jsonのバージョンが1.4.0に変更された後、そのまま維持されており、まだcanary以外のタグ付きリリースには含まれていない
1件のコメント
Hacker Newsの意見
なぜ TUI を JavaScript 経由でターミナル向け React 上で動かす必要があるのか理解しがたい。Anthropic が TUI 改善のためにランタイムまで買収したという事実は、エンジニアリング品質への疑念をさらに強める。もし書き換えがそれほど簡単なら、Claude Code をネイティブ言語へ移すほうがずっと安上がりだったはず
書き換えは Bun ですら簡単ではなく、API 契約とテストが明確な非 UI の開発ツールは、機能が曖昧でテスト不足の UI ツールより書き換え後に信頼しやすい
ユーザー向けコードと変化の速い UX 層は、高速な反復開発 が可能な動的システムへ、インフラ層は Rust のような安全なシステム環境へ移る可能性が高い。Java/C# は中間地帯だが、今後は UX には TypeScript/Python で十分で、システム作業には Rust のほうが適しているため立場が縮小しそうだ
https://avi.press/posts/2026-07-10-after-7-years-in-producti...
https://github.com/openai/codex/discussions/1174
Jarred の原文を見ると、Zig では手作業だった部分が Rust では自動化されることが、移行理由として明確に見える。人間もエージェントも非決定的なので、Zig のメモリ寿命と明示的解放を手動で追跡していると取りこぼしバグが長く積み上がるが、Rust はこの種のエラーを取り除くため、エンジニアリング管理の面で良い折衷案になる
とくに コンパイラエラー はコーディングエージェントに必要な決定的セーフガードであり、Claude に正確性を試す方法と「コンパイルできるようにしろ」という目標を与えるとうまく機能する。決定的テストによって確率的出力を確かな保証へ変える一般化されたアプローチは https://michael.roth.rocks/blog/verification-surface/ にまとめられている
そうすれば Zig も Rust に劣らず堅牢になりうるが、LLM が好む管理言語的な割り当てパターンを求めるなら Zig は合わない
unsafeRust が非常に多いのに、エラーの種類を自動的に排除すると言えるのか疑わしい: https://news.ycombinator.com/item?id=48967630unsafeだったと記憶しているので、その問題を自動で取り除けていない可能性が高いJarred や Simon Willison の評価とは無関係に、今回の件はかなり否定的に見ている。Anthropic の Bun 買収や AI による書き換えより大きな問題は、「自分のブランチにいるだけで過剰反応するな」という態度から始まり、100 万行超の PR を 1 か月も経たずにマージした未熟な進め方だ
コミュニケーションをひどく誤って信頼を損ない、分断を広げており、TypeScript チームが 7.0 で取ったアプローチに従うのがそんなに難しかったのか疑問だ
Claude に含まれる Bun v1.4.0 は、まだ公開されていないプレビュー版に見える。だとすれば FOSS プロジェクト Bun がひそかに別物へ変わった ように見え、調査だけ TODO に残して導入しなかったのは幸運だった
Bun のガバナンス文書が見当たらないが、今や実質的に Anthropic が作業内容もマージ可否もすべて決める構造なのか気になる
なぜここまで Bun をめぐって複雑なやり方をしたのか分からない。エージェントが Zig を Rust に移せるなら、Claude Code も JavaScript から Rust に直接書き直して、ランタイム依存をなくし性能を高められたはず
Bun には Claude Code 以外にも社外と Anthropic 社内のユーザーがいるはずで、コーディングモデルが好みうる JavaScript ランタイムとツールのエコシステムを確保できる。今後 Anthropic がこうしたアプリの実行・管理に特化したクラウドまで提供できる可能性もあり、開発者コミュニティを押さえるだけでも Claude Code 単体を Rust に移すよりはるかに大きな影響力を得られる
推測や感情を抜きにすると、実際の実行品質が気になる。起動速度だけでなく RAM・CPU 使用量、無限ループやデッドロックがどうかも確認すべきで、以前と同じかそれ以上ならかなり印象的だ
開発者として AI に仕事を奪われる可能性は嫌だが、誰もが簡単な要求だけで望むソフトウェアを作れるなら世界を良くできる。Microsoft のデータ収集が嫌なら OS を、Google の盗聴が嫌なら携帯電話を AI に作らせるという 技術的自給自足が可能になるかもしれず、その前では個人の雇用の安定性は些細なことになる
だからこそ技術をオープンソースに保つことがさらに重要で、そうでなければ既存の独占構造を繰り返しながら仕事まで失うことになる
最近 Kitty のタブ内で Claude Code を使っていて セグメンテーションフォルトに遭遇し、その後タブ全体が入力に反応しなくなった。報告リンクは表示されるがクリックできず、エンコードされていて何の情報が送られるのかも確認できない
Segmentation faultが表示されていなければ、セグメンテーションフォルトではなくフリーズの可能性が高い。実際にエラーならシェルに戻った後、画面に見えなくてもresetを入力すればタブを復旧できるunsafeRust に一行ずつ移したのなら原因となったコードもそのまま残っている。慣用的で メモリ安全な Rustにリファクタリングするまでは解決しないだろう彼らは、問題をうまく記述できてトークン予算が無制限な、大成功したがひどいエンジニアたちのように見える。トークン費用を自分で負担していたなら、ソフトウェア効率を上げる金銭的な動機が生まれたはずだ
AI データセンターの隠れた現実は、GPU クラスターの効率が **40〜60%**しかなくても、資金で機材をさらに買って埋め合わせるということだ。中国の競合を恐れる理由も、彼らのように浪費する余裕がないからかもしれない
今回の作業は トランスパイルであり、品質もよくない。生成されたコードは慣用的な Rust から遠く、醜悪と言ってよい
普通、書き換えでは既存コードベースから得た教訓を反映するが、エージェントでファイルごとに移植するとそうした利点がない。どちらにせよ非慣用的な翻訳にはなるが、LLM を使うと非決定性と莫大なコストまで加わる
最近 Claude Code は以前よりはるかに不安定で、TUI レンダリングの不具合で会話履歴が壊れることがよくある
バックグラウンドに送ってから
resetを実行し、再びフォアグラウンドに戻せば直る。Claude に診断を頼むと、自分にはそんなバグはなく別のプログラムのせいだと言ったが、動かしていたのは tmux と Claude だけだった。最近 Rust 版を適用したなら、品質低下の時期とはおおむね一致する