2026年10月22日、JavaScriptの実行環境「Bun(バン)」の新しいバージョン v1.4.4 が公開されました。第82回でご紹介したv1.4.3から、わずか12日後の更新です。
今回の目玉は、プログラムの見た目をきれいに整える「コード整形」の機能 bun fmt が組み込まれたことです。よく使われている整形ツール「Prettier(プリティア)」と同じ結果を出しながら、Prettierの開発元自身のプロジェクトで約286倍速かったと発表されています。
前回に続き、「Bunを使ったことがない」という方にもわかるように、基本からお話しします。
Bunは、JavaScriptやTypeScriptで書いたプログラムを、パソコンやサーバーの上で動かすための実行環境(ランタイム)です。同じ役割をもつNode.jsの新しい仲間で、Node.js向けのプログラムの多くがそのまま動くように作られています。
Bunの大きな特長は、開発に使う道具がbunという1つのコマンドにまとまっていることです。前回の記事では、これを「よく使う道具がひととおり入った、軽くて速い工具セット」にたとえました。
bun install:必要な部品(パッケージ)を集めるbun test:テストを実行するbun build:配布用にまとめる(ビルド)bun check:TypeScriptの型の間違いを見つける(v1.4.3で追加)bun fmt:コードの見た目を整える(今回のv1.4.4で追加)今回のv1.4.4で、この工具セットに「コード整形」という道具が新しく加わりました。
v1.4.4も変更点がとても多いのですが、初めての方に押さえていただきたいのは次の3つです。
bun fmt」が加わりました: Prettierと同じ整形を、Bunだけで、しかも非常に速く行えるようになりましたbun checkが、さらに速くなりました: 大きなプロジェクトでは、v1.4.3より1.4〜7.8倍速くなっていますbun installが大幅に改善されました: パッケージ管理まわりの課題133件が解決され、通信の一時的な失敗にも強くなりましたこのほかにも、データベース機能の高速化、WebSocketの互換性向上、セキュリティの修正などが含まれています。順番に見ていきましょう。
プログラムは、書く人によって見た目のクセが出ます。スペースの入れ方、改行の位置、文字列を"で囲むか'で囲むか、などです。動きは同じでも、見た目がバラバラだと読みにくく、チームで作業するときに「どこを変えたのか」がわかりにくくなります。
そこで使われるのが、決まったルールで見た目を自動的にそろえてくれる「フォーマッタ」です。たとえば、次のように詰めて書いたコードがあったとします。
// 整形する前
const user={name:"Taro",age:20}
function greet(u){return "こんにちは、"+u.name+"さん"}
フォーマッタにかけると、次のように読みやすい形にそろえてくれます(Prettierの標準設定の場合のイメージです)。
// 整形した後
const user = { name: "Taro", age: 20 };
function greet(u) {
return "こんにちは、" + u.name + "さん";
}
プログラムの動きは一切変わらず、見た目だけが整います。文章でいえば、「書いた内容はそのままに、句読点や段落を整えてくれる校正係」のような存在です。
.prettierrcなど)でルールを決めています。フォーマッタは、ファイルを保存するたびや、変更を記録(コミット)するたびに動かすことが多い道具です。そのため、速さがそのまま使い心地に直結します。
Bunの発表によると、Prettier自身のプロジェクト(2,616ファイル)で「整形が必要なファイルがあるか」を確かめた結果は次のとおりです。
| ツール | かかった時間 | 最大メモリ使用量 |
|---|---|---|
| bun fmt | 0.06秒(59.7ミリ秒) | 48MB |
| Prettier 3.9.10 | 17.1秒 | 459MB |
17秒かかっていた作業が、まばたきする間に終わる計算です。約286倍の速さで、ほかのプロジェクト(vitest、date-fnsなど)でもPrettierより234〜425倍速かったと報告されています。
すでに高速なoxfmtと比べても、すべてのプロジェクトで速いという結果でした。
| プロジェクト | ファイル数 | bun fmt | oxfmt 0.74.0 | 速さ |
|---|---|---|---|---|
| RSSHub | 7,121 | 97.3ミリ秒 | 298.5ミリ秒 | 3.0倍 |
| redocly-cli | 3,397 | 62.4ミリ秒 | 217.5ミリ秒 | 3.4倍 |
| vite | 2,537 | 65.2ミリ秒 | 406.7ミリ秒 | 6.2倍 |
| fumadocs | 2,452 | 44.6ミリ秒 | 1,395ミリ秒 | 31倍 |
※viteは16コアのM4 Max搭載MacBook Pro、それ以外は8コアに固定したIntel XeonのLinuxマシンで計測された値です。数値はBun開発元の発表で、当社では計測していません。
bun fmtは、JavaScriptやTypeScriptだけでなく、Web開発でよく使うファイルをまとめて整形できます。
HTMLの中に書かれた<style>や、Markdownの中のコード例など、ファイルの中に埋め込まれたコードも整形してくれます。
すでにPrettierを使っているプロジェクトでも、乗り換えはかんたんです。bun fmtは、Prettierの設定ファイル(.prettierrcなど)や、整形しないファイルを指定する.prettierignoreを、そのまま読み込みます。oxfmtの設定ファイルにも対応しています。
たとえばpackage.jsonの整形用スクリプトは、次のように書き換えるだけです。
"scripts": {
"format": "bun fmt"
}
さらに、Prettierでは追加のプラグイン(拡張機能)が必要だった次のような機能も、最初から入っています。
prettier-plugin-tailwindcss相当)package.jsonの項目の並べ替え(prettier-plugin-packagejson相当)prettier-plugin-svelte相当)import文の並べ替え(Bunの設定ファイルbunfig.tomlでsortImports = trueを指定)bun fmt --doctorを実行すると、Bunが設定をどう読み取ったか、そして「もうアンインストールしてよいパッケージ」はどれかを教えてくれます。
# プロジェクト全体を整形する
bun fmt
# 整形が必要なファイルを一覧表示するだけ(ファイルは書き換えない)
bun fmt --check
# コミットしようとしているファイルだけを整形する
bun fmt --staged
# メインのブランチから変更したファイルだけを整形する
bun fmt --changed
--checkは、整形が必要なファイルがあると「失敗」として終わります。そのため、GitHub Actionsなどの自動チェック(CI)に組み込めば、「見た目がそろっていないコードが紛れ込むこと」を防げます。
--stagedは、コミットの直前に自動で動く仕組み(Gitのフック)と組み合わせるのに向いています。これまではlint-stagedという別の道具を入れて実現するのが一般的でしたが、その必要がなくなります。
「速いけれど、Prettierと結果が変わってしまうのでは?」と心配になるかもしれません。Bunの発表によると、bun fmtはPrettierを移植したもので、Prettier自身のテスト9,731件のうち9,648件(99.1%)で、1文字も違わない同じ結果になったそうです。
残りの違いの多くはわざとそうしているものです。Prettierには、ごくまれな書き方で整形によってプログラムの意味が変わってしまうケースがあり、bun fmtではそうした場合に元の意味を守るようにしています。
bun fmt --checkで差分を確認するのがおすすめですbun fmtが対応していないプラグイン(例:prettier-plugin-jsdoc)が書かれていると、エラーになり、そのファイルは整形されません。Astroのように専用プラグインが必要な言語は、プロジェクトに入っているPrettierに処理を任せますbun formatとは別のコマンドです: bun formatと打った場合は、これまでどおりpackage.jsonのformatスクリプトが実行されます前回ご紹介した型チェッカーbun checkも、さっそく改良されています。大きなプロジェクトでの比較結果は次のとおりです(Linux x64、8スレッドで計測)。
| プロジェクト | v1.4.4 | v1.4.3 | 速さ |
|---|---|---|---|
MUI(docs) | 1.31秒 | 10.28秒 | 7.8倍 |
| t3code(server) | 1.62秒 | 4.59秒 | 2.8倍 |
| Supabase(studio) | 1.27秒 | 2.84秒 | 2.2倍 |
| mikro-orm | 1.82秒 | 3.30秒 | 1.8倍 |
| VS Code | 2.82秒 | 4.09秒 | 1.4倍 |
MUIでは、使うメモリも11.2GBから1.3GBへと大きく減りました。どちらのバージョンも、見つけたエラーの数は同じだったそうです。
また、たくさんのプロジェクトをまとめてチェックするbun check -bは、4,000個のプロジェクトを含む例で13.65秒から0.87秒(15.7倍)に短縮されました。
※ほかに比べた76のリポジトリのうち69件で10%以上速くなった一方、Bun自身のコードの一部(src/js)では0.11秒から0.20秒へ遅くなったことも、正直に報告されています。
今回は、パッケージを集めてくるbun installまわりの改善がとても多く、課題(issue)133件が解決されました。寄せられていた改善提案597件のうち、464件がそのまま、40件が一部取り込まれたそうです。初めての方にも関係しそうなものを中心にご紹介します。
パッケージのダウンロード先(レジストリ)が一瞬だけ混み合うことは、よくあります。これまでのBunも失敗したら5回までやり直していましたが、その5回がわずか5ミリ秒の間に終わってしまい、ほんの短い障害でもインストールが失敗していました。
v1.4.4では、やり直す間隔を50、100、200、400、800ミリ秒と、少しずつ広げるようになりました。電話がつながらないときに、すぐ5回連続でかけ直すのではなく、少し間をおいてかけ直すイメージです。これにより、1秒程度の障害なら乗り切れるようになっています。
これまでは、知らないオプションを付けても黙って無視されていました。たとえば--frozen-lockfile(ロックファイルを変更しない)を打ち間違えると、エラーにならずに通常のインストールが行われてしまい、自動チェック(CI)で気づけないことがありました。
> bun install --frozen-lockfil
error: bun install has no --frozen-lockfil flag.
(訳:bun install に --frozen-lockfil というオプションはありません)
あわせて、npm・Yarn・pnpmで使うオプションも読み替えてくれるようになりました。たとえばbun add --save-dev zod(npm流の書き方)は、これまで開発用ではない依存関係として保存されていましたが、今後は正しく開発用(devDependencies)に入ります。
yarn.lockを、Bunのロックファイルbun.lockへ、バージョンを変えずに変換できるようになりましたsharpなどには、Linuxの種類(glibc版/musl版)ごとに別の部品があります。これまでは両方をダウンロードしていましたが、今後は自分の環境に合うものだけを入れますminimumReleaseAge(公開から一定期間たった版だけを使う設定)で、"3d"(3日)のように単位を書けるようになりました。悪意のある版が紛れ込む「サプライチェーン攻撃」への備えとして役立ちますbun pm fetchが加わり、Dockerのキャッシュを生かしやすくなりましたここからは、すでにBunをお使いの方向けに、主な改善点をかいつまんでご紹介します。
Bun.SQLの高速化: PostgreSQLへの問い合わせ1回あたりのCPU使用量が、最大48%減りました。query.cancel()で実行中の問い合わせを本当に取り消せるようになり、COPYでの大量データの読み書きもストリームで扱えますtransform: SQL.camelを指定すると、データベースのfirst_nameとJavaScriptのfirstNameを自動で相互に変換してくれますbun:sqliteの機能追加: JavaScriptで書いた関数をSQLの中から呼べるdb.function()や、行の追加・更新・削除を検知するonInsertなどが加わりましたwsパッケージの互換性向上: WebSocketでよく使われるwsを作り直し、ws自身のテスト271件のうち通過する数が94件から234件に増えましたtoLocaleString("en-US")が54倍速くなりましたHeadersの読み出しが最大2.8倍、メモリ上の本文(response.body)の読み出しが最大2.6倍速くなりましたBun.Globの機能強化: !(*.test).ts(テスト以外の.ts)や{1..3}(1〜3)のような、より柔軟なファイル名のパターンが使えるようになりましたbun installなど、幅広い部分でセキュリティ上の修正が行われていますこのほかにも、Node.js互換、テストランナー、Windows固有の問題など、非常に多くの不具合が修正されています。すべての変更点は、末尾の参考資料の公式リリースノートをご覧ください。
v1.4.4では、いくつかの動きが、より正しい(ブラウザやNode.jsと同じ)方向に変わりました。該当する機能を使っている場合は、念のためご確認ください。
closeイベントは、相手との切断の手続きが終わってから届くようになりました。コードを指定せずにclose()した場合、切断コードは1000ではなく1005になります。接続に失敗したときは、errorの後にコード1006でcloseが届きますwsのerrorイベント: Node.jsと同じく、errorを受け取る処理を登録していないと、プログラム全体のエラーとして扱われるようになりました。すべての接続にerrorの処理を書いておきましょうBun.Globのパターンの意味: 先ほどの新しい書き方に対応したため、*(1).txtや{1..3}などの意味が変わりました。これまで文字どおりに一致させていた場合は、書き方の見直しが必要ですbun test --coverageの計測の誤りが直ったことで、行のカバー率(% Lines)が下がることがあります。カバー率の下限(coverageThreshold)を設定している場合はご注意くださいbun installなどで、どのパッケージ管理ツールにもないオプションはエラーになります。自動チェック(CI)のスクリプトに古いオプションが残っていないか確認しておくと安心ですBun.SQLのパスワード: 環境変数PASSWORDを読まなくなりました。PGPASSWORDやMYSQL_PASSWORD、接続URL、passwordオプションを使います業務で使っているシステムをアップデートするときは、いきなり本番に入れるのではなく、開発環境でテストを一通り流してから切り替えるのが安心です。
最後に、Windowsのパソコンでbun fmtを試す手順をご紹介します。
PowerShellを開いて、次のコマンドを実行します。
# 初めてインストールする場合
powershell -c "irm bun.sh/install.ps1|iex"
# すでにBunが入っている場合は、最新版に更新する
bun upgrade
# バージョンを確認する(1.4.4 と表示されればOK)
bun --version
※macOSやLinuxではcurl -fsSL https://bun.sh/install | bashでインストールできます。npm(npm install -g bun)やHomebrew、Scoop、Dockerイメージ(oven/bun)も用意されています。
mkdir bun-fmt-test
cd bun-fmt-test
bun init -y
index.tsを開いて、中身を先ほどの「整形する前」のコードに書き換えて保存します。そのうえで、まずは確認だけを行ってみましょう。
bun fmt --check
整形が必要なファイルとしてindex.tsが表示されるはずです。続けて、実際に整形してみます。
bun fmt
もう一度index.tsを開くと、スペースや改行が整った形に書き換わっているはずです。前回ご紹介したbun checkと組み合わせれば、「見た目をそろえる」「型の間違いを見つける」の2つを、どちらもBunだけで行えます。
bun fmtが加わりました。Prettierとほぼ同じ結果を、Prettierの約286倍の速さで出せると発表されていますbun checkは、大きなプロジェクトでv1.4.3より1.4〜7.8倍速くなりましたbun installは課題133件が解決され、通信の一時的な失敗や打ち間違いに強くなりましたコード整形は地味に見えますが、チームで開発するうえではとても大切な「お作法」です。見た目のそろえ方を道具に任せてしまえば、レビューでは「中身」の話に集中できます。生成AIにコードを書いてもらう機会が増えた今、AIが書いたコードも人が書いたコードも、同じルールで一瞬でそろえられるのは心強いことだと私たちは考えています。
BunやTypeScriptを使った開発、既存のNode.jsプロジェクトの見直しなどでお困りのことがあれば、どうぞお気軽にご相談ください。
本記事は2026年10月28日時点の公開情報に基づきます。速度・メモリ・CPU使用量・互換性の数値はBun開発元の発表によるもので、当社で計測したものではありません。導入前には公式情報と自社環境での検証をお願いします。