JavaScriptランタイムのBunが2026年10月10日にv1.4.3を公開し、TypeScriptの型チェッカー「bun check」を本体に組み込みました。公式のリリースノートは、TypeScript 7.0.2の適合性テストをすべて通し、tscより3〜6.4倍速いと説明しています。ただし、型チェックだけを行う機能で、エディターの補完まで置き換えるものではありません。導入前に押さえたい範囲と、あわせて入った変更を整理します。
bun checkは型チェックだけを担当する
リリースノートによると、bun checkはtypescript-goを移植したもので、tsconfig.jsonを読み、tscと同じエラーを報告し、CPUの全コアを使います。typescriptパッケージを入れなくても動きます。一方で、JavaScriptや.d.tsは出力せず、言語サーバーもないため、エディターは引き続きTypeScript側を使う、と明記されています。つまり、ビルドや実行の前に型だけを速く確かめる道具です。
実行時に組み合わせるオプションも用意されています。
bun run --check：型を検査してから実行し、型エラーがあれば実行しません。package.jsonのscriptsや--watchにも使えます。bun test --check：テストファイルとそれが読み込むものを型チェックし、エラーがあればテストを走らせません。bun build --check：型チェックのあとにバンドルし、型エラーはビルドエラーとして扱われ、何も書き出されません。
速度と、公式が示した検証の範囲
公式の比較は、16コアのApple siliconのMacで、tsc 7.0.2と実行時間を比べたものです。VS Codeのsrc（9,795ファイル）は1.24秒対5.98秒で4.8倍、Next.jsのpackages/next（2,881ファイル）は0.28秒対1.82秒で6.4倍、Nuxt（839ファイル）は0.27秒対0.80秒で3.0倍でした。メモリ使用量も、VS Codeのsrcで2.14GB対7.97GBなど、2.2〜4.9倍少ないと書かれています。いずれもBun側が公表した自前の測定値なので、手元のプロジェクトとCIの環境で測り直す前提で見るのが妥当です。
正確さについて、Publickeyは、TypeScriptの適合性テストをすべて通ったことに加え、Bunが独自に用意したエラーを含む72個の主要なオープンソースのTypeScriptファイルで、TypeScriptとBunの結果を比べたところ、差異は1か所だったと紹介しています（公式の表記は72のリポジトリで、意図的に設定を崩した構成での結果です。strictをオフにした条件では差異が出た例も、公式には載っています）。公式は、自分のプロジェクトでtsc --noEmitの出力とbun checkの出力を比べて差があれば、Bunのバグなので報告してほしい、という手順も載せています。置き換える前にこの比較を一度走らせておくと、判断の材料になります。
ランタイム側の主な変更
型チェック以外にも、v1.4.3には次のような変更が入っています（用途の説明を除き、リリースノートの記載）。
- Bun.FetchSession：一群のリクエストに、独自のTLS、プロキシ、keep-alive設定と、独立した接続プールを持たせます。公式のサンプルコードは、独自のCAやプロキシを指定する例を示しています。
- fetchのプロキシ環境変数：NO_PROXYがワイルドカード、CIDR、IPv6、host:portに対応し、HTTP_PROXYとHTTPS_PROXYが未設定ならALL_PROXYが使われます。プロキシがCONNECTを2xx以外で拒否した場合、これまではプロキシの拒否応答がオリジンの応答のようにそのまま返っていましたが、今後はERR_PROXY_TUNNELで失敗します（ステータスとヘッダーは例外に含まれます）。
- –disallow-code-generation-from-strings：Nodeと同じこのフラグで、evalとnew Functionが例外になります。以前のBunはフラグを受け付けても無視していました。
- node:httpの大きな応答：16KBを超える応答を、1回のtickで1回の書き込みにまとめ、最大2.7倍速くなったとされています。
- 待機中のCPU使用率：サーバーが待機している間のCPU使用が67〜89%減ったと公式は書いています。v1.4.2との比較で、Linux x64上で30秒の負荷テストのあとに待機させた条件での測定で、Express・Fastify・Elysia・Hono・Next.jsのSSRで計測されています。
実験的な機能として、1つのプロセスで同じアプリの複数インスタンスを動かすBun.ModuleGraphも加わりましたが、セキュリティのサンドボックスではない、と公式が断っています。
どこから試すのがよいか
私見では、まずbun test --checkをローカルの安全網として入れ、公式の手順どおりtsc --noEmitとの差分を自分のリポジトリで取るのが現実的です。差分が無ければ、CIの型チェックを置き換える候補になります。ただし公式の検証でも、strictをオフにした構成では差異が出ているので、strictを緩めているプロジェクトは特に念入りに比べたいところです。出力の生成とエディター支援は従来のTypeScriptに残るため、置き換えではなく併用が前提です。社内プロキシ経由でfetchしている場合は、拒否応答の扱いがエラーに変わるので、先に検証環境で確かめておくと安心です。
参考にした情報
- Bun Blog「Bun v1.4.3」（2026年10月10日）
- Publickey「AnthropicのBun、TypeScript 7よりも3倍以上高速なTypeScript型チェッカーを搭載。Bunの新バージョン1.4.3で」
2026年10月17日時点の情報です。
