目次

あるプルリクエストで、共有のTypeScriptインターフェースが変更された。アプリケーションはローカルで起動し、テストも通ったため、開発者はブランチをプッシュする。ところがCIで失敗する。リポジトリ内の別のパッケージが、まだ古いインターフェースを使っていたのだ。

TypeScriptのコードが正常に実行できても、型が正しいとは限らない。チームには別途型チェックが必要であり、その所要時間は、開発者がどれだけ頻繁にチェックを実行するかに影響する。

2026年10月10日にリリースされたBun 1.4.3は、この問題をリリースの中心に据えている。提供されたレポートによると、AnthropicのJavaScriptランタイムに、bun checkで利用できるTypeScript型チェッカーが組み込まれた。その主張は大きい。TypeScript 7の3倍を超える速度で動作し、メモリ使用量はおよそ半分から4分の1、あるいはそれ以下だという。

これらの数値には、評価するだけの価値がある。ただし、数値だけを根拠に既存のCIチェックを置き換えるべきではない。

Bun 1.4.3で追加されたもの#

Bunはすでに、TypeScriptの読み込み、JavaScriptへのトランスパイル、そして変換結果の実行に対応している。型チェックは、それらとは異なる役割を担う。

トランスパイルは、プログラムを実行できるようにTypeScriptの構文を取り除いたり変換したりする処理だ。一方、型チェックは、プログラムが宣言された型の関係に従っているかを調べる。テストした実行経路では正常に動くプログラムでも、別の箇所に型エラーを含んでいる場合がある。

Bun 1.4.3で注目される追加機能は、この後者の処理を行う組み込みコマンドだ。

snippet.txt
bun check

提供されたレポートでは、このコマンドはTypeScriptファイルを受け取り、その型を検証すると説明されている。既存のプロジェクトに導入する前に、対応する実行方法、設定の扱い、コマンドラインオプションをリリースドキュメントで確認しておこう。

導入を考えるうえでは、この区別が重要になる。すでにスクリプトの実行にBunを使っているチームには、型をチェックする便利な方法が新たに加わる可能性がある。別のランタイムを使っているチームも、プロジェクトの要件がサポートされていれば、型チェッカーを個別に評価できる。ソースコードをチェックするツールを変更しても、アプリケーションを実行するランタイムまで変更する必要はない。

したがって、確認すべき問いは具体的だ。この型チェッカーは、必要な時間とメモリを削減しながら、自分たちのリポジトリを正確に検証できるだろうか。

速度の主張には注目する価値がある。ただし、比較条件の明確化が必要だ#

レポートによると、Bunの型チェッカーは、Goで実装されたTypeScript 7より3倍以上高速だという。

これは、従来のJavaScript実装の型チェッカーを上回るよりも厳しい比較だ。TypeScript 7のGoへの移行自体が、性能向上を目的としていた。Bunは、その新しい比較対象に対して、さらに大幅な時間短縮を主張している。

規模感をつかむために、現在90秒かかるチェックを考えてみよう。速度がちょうど3倍になれば、同じ処理は30秒で終わる。これは説明のための例であり、Bunのリリースで測定された結果ではない。

メモリの節約も、同じくらい重要かもしれない。使用メモリが半分になる型チェッカーなら、CIランナー上でテストやビルドと並行して実行しやすくなる。さらに削減できれば、現在ランナーのメモリ上限に近づいているリポジトリにも役立つ可能性がある。

ただし、提供された資料からは、ベンチマークに使われたハードウェア、対象プロジェクトの全体、キャッシュの状態、測定手順は分からない。また、報告された優位性が、小規模なアプリケーション、大規模なモノレポ、複雑なジェネリック型を使うプロジェクトに等しく当てはまるかどうかも示されていない。

リリースで示された数値は、試すきっかけとして捉えよう。自分たちのワークフローにとって重要な結果は、自分たちのリポジトリで得られる。

「適合率100%」が実際に示すこと#

性能に価値があるのは、チームが検出を期待するエラーを、型チェッカーが実際に検出できる場合に限られる。

提供されたレポートでは、2種類の互換性検証が説明されている。まず、BunはTypeScript 7.0.2の適合性テストを100%通過したとされている。次に、チームはエラーを含むオープンソースのTypeScriptファイルを72個選び、TypeScriptとBunの結果を比較したところ、相違が1件見つかったという。

言語実装の適合性テストスイートを通過したことは、有意義な根拠になる。そのテストが対象とする言語の挙動について、広く一致していることを示唆するからだ。

それでも、結果が示す範囲には限界がある。テストスイートに含まれるケースは有限だ。すべてに合格しても、ソースファイル、コンパイラ設定、パッケージの宣言、依存関係の構造をどう組み合わせても同じ挙動になると証明されたわけではない。

72ファイルの比較は、適合性テストスイート以外の、選ばれたソースコード例でも結果が一致したという、別の種類の根拠を加えている。ただし、報告された相違は調べる必要がある。提供された文章では、診断の見落としなのか、診断が余分に出たのか、それともエラーの表示方法の違いなのかが説明されていない。

これらは、それぞれ影響が異なる。メッセージの変更なら、ツールを少し調整すれば済むかもしれない。エラーの見落としなら、リリース判定の信頼性を損なう可能性がある。

実務上の基準は、プロジェクトが依存する挙動が一致することだ。実際に使っている設定のもとで、不正なコードを拒否し、正しいコードを受け入れることの両方が含まれる。

型チェックの高速化はワークフローを改善できる#

型チェッカーが速くなる直接の利点は、待ち時間が減ることだ。さらに大きな価値が生まれるかどうかは、実行の負担が減ることで開発者の行動が変わるかにかかっている。

すぐに終わるチェックなら、コミット前にも実行しやすい。遅いチェックはCIまで後回しにされやすく、その場合、開発者が別の作業に移ったあとでフィードバックが届く。

次の2つの状況を考えてみよう。

  • 開発者が共有APIを変更したあと、ローカルで型チェックを一通り実行し、影響を受ける呼び出し元を修正してからプッシュする。
  • 開発者が先にプッシュしてCIを待ち、別の作業を始めたあとで、その変更に戻る。

前者のワークフローなら、関連するコードや判断の根拠が頭に残っている。型チェックの高速化は、このワークフローを維持しやすくする。

ただし、型チェッカーの高速化率が、そのままCI全体の所要時間の短縮率になるわけではない。10分のパイプラインのうち型チェックが90秒を占めるなら、それを30秒に短縮して節約できるのは1分だ。依存関係のインストール、テスト、ビルドには、引き続き残りの時間がかかる。

並列実行があると、話はさらに複雑になる。より長いテストジョブがCIの完了時刻を決めている場合、型チェックが速くなっても、リソース使用量は減る一方で、最終的な完了時刻は変わらないかもしれない。

まず型チェッカーを単独で測定し、次にパイプラインを測定しよう。

既存リポジトリで行う4段階の評価#

有用な試験導入では、別のエンジニアが検証できる根拠を残す必要がある。問題が起きたときに原因を特定できるよう、対象範囲を絞ろう。

1. 現在の構成を記録する#

TypeScriptのバージョン、Bunのバージョン、OS、利用可能なCPUとメモリを記録する。現在型チェックに使っているコマンドも、正確に残しておこう。

使用するツールが対応していれば、経過時間とピークメモリ使用量を測定する。チェックを複数回実行し、それぞれ既存のキャッシュを利用したかどうかも記録する。

一方のツールをキャッシュなしで実行し、もう一方をキャッシュありで実行して比較するのは避けよう。型チェッカー自体とは関係のない差を、大きく見せてしまう可能性がある。

2. 診断結果を比較する#

同じコミットと設定に対して、両方の型チェッカーを実行する。

まずは既存のチェックを通過するリビジョンから始める。その後、一時的なブランチで、不正な引数、互換性のない代入、解決できないインポート、誤った戻り値の型など、代表的なエラーを意図的に加える。

これらの例で完全な互換性を証明できるわけではない。それでも、チームが検出を期待するいくつかの問題を、型チェッカーが処理できるかどうかは確認できる。

結果の不一致はすべて調査する。影響を受けるファイル、設定、最小限の再現例を記録しよう。内容を理解するまでは、無害な違いと判断してはいけない。

3. リポジトリ特有の難しいケースを試す#

実際のコードベースに合わせてケースを選ぶ。モノレポでは、パッケージ間の境界やプロジェクト参照に大きく依存しているかもしれない。フロントエンドアプリケーションでは、生成された型宣言やフレームワーク固有のツールに依存している可能性がある。

特に、モジュール解決、パスエイリアス、サードパーティーの型宣言ファイル、厳格さに関する設定に注意しよう。言語仕様への適合性があらゆる連携の詳細を保証すると考えず、ドキュメントで対応状況を確認する。

既存のTypeScriptコマンドが型宣言の出力や、ほかの必須ビルド処理も担っている場合は、その役割をどう引き継ぐかを明確にする。高速な型チェックコマンドが、コンパイラのあらゆる用途を自動的に置き換えるわけではない。

4. CIで一時的に比較する#

期間を定めて、既存の必須チェックと並行してBunの型チェッカーを実行する。実行時間と診断結果を収集するあいだは、現在のリリース判定を維持する。

意図的にエラーを加えたケースに加え、通常の開発で行われる変更も確認する。切り替えを裏付ける結果が得られたら、測定した利点と残る制約を文書化し、専用のプルリクエストで変更する。

こうすれば、導入の判断も、必要になった場合の切り戻しも容易になる。

このリリースには、ほかの性能改善も含まれる#

型チェックが目玉機能だが、提供されたリリース概要には、JSON.parseの高速化、Node.js互換性の修正、サーバーのアイドル時CPU使用量の削減も挙げられている。

報告されたアイドル時CPU使用量の削減率は67%だ。この数値も、型チェッカーのベンチマークと同じように慎重に扱う必要がある。特定の測定条件で得られた結果であり、本番環境のCPU使用量全体が同じだけ減ると保証するものではない。

負荷の高いサービスでは、リクエスト処理がリソース消費の大半を占めるかもしれない。ほとんどアイドル状態のサービスでは、バックグラウンド処理の占める割合が大きくなる可能性がある。自分たちのデプロイ環境に近い条件で試そう。

このリリースではBun.FetchSessionも導入され、多数の修正が含まれている。提供された概要には、このAPIの挙動を評価したり、組み込みを勧めたりするために十分な詳細がない。採用する前にリリースドキュメントを確認しよう。

目先の目的が型チェックの高速化なら、まずその変更を評価する。対象を絞った試験導入なら、結果を解釈しやすくなる。

置き換える価値を実証する#

Bun 1.4.3は、大幅に高速なTypeScript型チェック、報告上のメモリ使用量の削減、TypeScript 7.0.2への高い適合性という、魅力的な提案を示している。

残る問いは、自分たちのリポジトリでも、チームにとって重要な診断結果の相違を生じさせずに、その利点が得られるかどうかだ。

まずは代表的なプロジェクトを1つ選ぼう。Bunを1.4.3に固定し、現在のTypeScriptチェックと並行して型チェッカーを実行し、実行時間、ピークメモリ使用量、すべての不一致を記録する。その根拠をもとに、bun checkを開発ワークフローの必須チェックに加えるべきかを判断しよう。

出典: https://www.publickey1.jp/blog/26/anthropicbuntypescript_73typescriptbun143.html

目次