Bun 2は公開済み？現行バージョンを公式情報で確認する方法

この記事の訂正

このページでは以前、「Bun 2.0が公開された」と説明していました。しかし、その内容はBun公式の公開情報と一致していませんでした。

2026年7月25日にBun公式サイトを確認した時点では、案内されている安定版はBun 1.3系列です。Bun 2を公開済みの製品として扱うべきではありません。

技術記事では、将来のメジャーバージョンを予想で説明すると、存在しない機能や移行手順を読者へ案内してしまいます。このページでは特定の将来版を予測せず、現在使えるBunと、バージョン確認の方法を整理します。

現在のBunとは

Bunは、JavaScript、TypeScript、JSXを実行できるランタイムです。ランタイムだけでなく、パッケージマネージャー、テストランナー、バンドラーなどを1つのツールとして提供しています。

Node.jsのプロジェクトでも、すべてを一度に置き換える必要はありません。たとえばbun installだけを試す、テストだけをbun testで動かす、といった段階的な導入ができます。

# 依存パッケージをインストール
bun install

# package.jsonのスクリプトを実行
bun run dev

# テストを実行
bun test

公式サイトもBunを「incrementally adoptable」、つまり段階的に採用できるツールとして説明しています。

バージョンはコマンドで確認する

記事タイトルや検索結果だけで、インストール済みのバージョンを判断しないようにします。手元では次のコマンドを実行します。

bun --version

安定版へ更新する場合は、公式のインストールガイドを確認したうえで更新します。

bun upgrade

HomebrewやScoopなど、パッケージマネージャー経由でインストールした場合は、そのパッケージマネージャーで更新することが公式ドキュメントで案内されています。

# Homebrew
brew upgrade bun

# Scoop
scoop update bun

プロジェクトでバージョンを固定している場合は、勝手に最新版へ上げず、CIと開発メンバーの利用バージョンも合わせます。

安定版とcanaryを混同しない

Bunは、安定版に加えて最新コミットを反映したcanary buildも提供しています。

# canaryへ切り替える
bun upgrade --canary

# 安定版へ戻す
bun upgrade --stable

canaryは新機能や修正を早く試せる一方、未検証の変更を含みます。本番環境や授業の共通環境では安定版を使い、canaryは検証用の環境に限定するのが安全です。

Bunを導入する前の確認項目

Bunが高速だという一般的な評価だけで、本番採用を決めるべきではありません。自分のプロジェクトで次を確認します。

利用パッケージが動くか

BunはNode.js互換性の向上を続けていますが、Node.js固有API、ネイティブアドオン、インストールスクリプトに依存するパッケージでは差が出る可能性があります。

まず既存のテストをBunで実行します。

bun install
bun test

テストがない場合は、起動、認証、DB接続、ファイル操作、外部API連携など、失敗すると影響の大きい経路から確認します。

lockfileとCIを確認する

開発者ごとにnpm、pnpm、Bunを混在させると、lockfileや依存関係の解決結果がずれることがあります。採用するパッケージマネージャーとlockfileをチームで決め、CIでも同じコマンドを使います。

性能は自分の処理で測る

公式サイトや第三者のベンチマークは、比較条件を理解するための参考情報です。HTTPサーバー、依存関係のインストール、テスト、バンドルでは測っている処理が異なります。

本番に近い依存関係、データ量、同時接続数で測り、平均値だけでなくエラー率やメモリ使用量も確認してください。

Node.jsとBunの役割を整理する

Node.jsとBunは、どちらもサーバー側でJavaScriptを実行できます。しかし、採用判断では単純な速度順位よりも、プロジェクトが何に依存しているかを見る必要があります。

Bunはオールインワンのため、設定ファイルや依存ツールを減らせる場合があります。一方、既存のNode.jsプロジェクトでは、長く使ってきたCI、監視、デバッグ手順が資産になっています。移行によって減るものと、新しく検証が必要になるものを両方数えます。

小さく試す手順

既存プロジェクトでBunを評価する場合は、元の環境を消さずに比較します。

1. Gitで作業ブランチを作る
2. 現在のNode.jsバージョンとテスト結果を記録する
3. Bunの安定版をインストールし、bun --versionを記録する
4. 依存関係のインストール結果とlockfile差分を確認する
5. lint、型チェック、test、buildを順に実行する
6. 外部APIやDBを使う結合テストを行う
7. 問題があれば、再現条件と未対応APIを記録する

bun install
bun run lint
bun run typecheck
bun test
bun run build

コマンド名はプロジェクトのpackage.jsonに合わせてください。既存環境へ戻せる状態を保つと、評価と本番移行を混同せずに済みます。

将来版の記事を読むときの注意

メジャーバージョン名が含まれる記事を見つけたら、公式ブログ、公式ドキュメント、GitHub Releasesの順に確認します。検索結果の日付だけでなく、そのページが正式版、beta、canary、提案のどれを扱っているかも見ます。

ロードマップに書かれた項目は、公開時期や最終仕様を保証するものではありません。コード例を試す前に、現在の安定版ドキュメントに同じAPIが掲載されているか確認してください。

初学者は何から試すか

Bunを初めて使う場合、最初からWeb serverやdatabaseを含む作品を移行する必要はありません。短いTypeScript fileを実行し、次にpackage script、test、依存関係のinstallを順番に試すと、どの役割をBunが担当しているか理解しやすくなります。

const message: string = "Hello, Bun";
console.log(message);

bun run hello.ts

この例で確認できるのは、BunがTypeScriptのsyntaxを処理して実行できることです。project全体の型が正しいことを保証する型checkとは異なります。学習時も、実行、型check、test、buildを別の作業として区別してください。

次に既存の小さなprojectを複製し、Node.jsでの結果とBunでの結果を比較します。元のprojectを直接上書きしないことで、lockfileや生成物の差を確認できます。

Bun 2を待つべきか

未公開のメジャーバージョンを待つことを前提に、学習や導入を止める必要はありません。現行の安定版に必要な機能があり、互換性テストを通過するなら、小さな範囲から試せます。

反対に、現在のNode.js環境が安定しているなら、Bunへ移行すること自体を目的にしない方がよいでしょう。ランタイム変更には、パッケージ互換性、CI、監視、障害対応の確認が必要です。

将来のBun 2について判断するのは、公式リリースノートが公開されてからで十分です。

まとめ

• Bun 2を公開済みとしていた以前の内容は誤り
• 2026年7月25日時点の公式案内はBun 1.3系列
• バージョンはbun --versionと公式サイトで確認する
• canaryと安定版を分け、本番では互換性テストを行う
• 未公開機能を予想せず、公開済みの仕様で採用を判断する

参考リソース

• Bun公式サイト
• Bun Installation
• Bun Runtime
• Bun Roadmap

×

PR

×

PR