Bun 1.4.3のbun checkはtscの代わりになるか並べて試した

CIで tsc --noEmit を回していると、プルリクエストのたびに型チェックの待ち時間が積み重なります。Bunに入った型チェッカーの bun check に替えれば速くなるかもしれませんが、CIの担当者が先に確かめたいのは、「同じエラーが出るか」「エラーがあったときに確実にジョブが落ちるか」です。

Bunは2025年12月にAnthropicが買収したJavaScriptの実行環境です。2026年10月10日（UTC）に公開された1.4.3で、型チェックの bun check と、実行・ビルド・テストの前に型チェックをする --check フラグが加わりました（Bunのブログのリリースノート。リポジトリの文書も1.4.3のタグで加わり、1.4.2のタグにはありません）。本記事では、編集部の検証環境で Bun 1.4.3 と TypeScript 7.0.2 の tsc を同じプロジェクトに対して実行し、置き換えの判断材料を整理します。

Bun 1.4の全体の変化（Rustへの書き直し）と業務システムで採用するかの判断は、Bun 1.4の記事で扱っています。

bun check は何をするコマンドか

Bunの文書（docs/runtime/check.mdx）は、bun check を次のように説明しています。

tsconfig.json を読み、「reports the same errors as tsc from TypeScript 7」（TypeScript 7の tsc と同じエラーを出す）。CPUのコアをすべて使う
エラーがあれば終了コード 1、なければ 0。「It never writes files」（ファイルを書き出さない）
typescript パッケージは不要。lib.*.d.ts はBunに組み込まれている。どの版に合わせているかは bun -p process.versions.typescript で分かる
置き換えの対応表は tsc --noEmit → bun check、tsc --noEmit && bun test → bun test --check など。.d.ts の生成には引き続き tsc を使う

1.4.3の実行ファイルで bun -p process.versions.typescript を実行すると 7.0.2 が返りました。npmの typescript の最新版（latest）も7.0.2です。TypeScript 6・7で変わった既定値（strict が既定で有効、types が空など）は bun check にもそのまま当てはまるため、TypeScript 5の設定のままのプロジェクトでは、まず TypeScript 7への移行の整理が先になります。

Bunのブログのリリースノートは、bun check がTypeScript 7.0.2の適合性テスト（conformance test suite）をすべて通ると説明しています。わざと設定を崩した72のオープンソースのリポジトリで tsc と出力を比べた結果も載っていて、1,103の設定（エラーは計286,267件）のうち、出力が一致しなかったのは1つ（vuejs/core）でした。速さについては、16コアのApple siliconのMacで、VS CodeやNext.jsなど実在のプロジェクトに対して「3x to 6.4x faster than tsc 7.0.2」としています。報道の「3倍以上高速」はこの数字によるものです。本記事では、条件の異なる編集部の測定値もあわせて示します。

tsc 7.0.2 と並べて実行した結果

検証環境は Linux（x86_64、4コア）、Node.js v22.22.0。Bunはnpmの @oven/bun-linux-x64@1.4.3（1.4.3+c6da4a4d3）、比較相手は typescript@7.0.2 の tsc です。strict を有効にした3ファイルの小さなプロジェクトで試しました。

条件	bun check（1.4.3）	tsc —noEmit（7.0.2）
エラーなし	終了コード 0	終了コード 0
型エラー2件（TS2322・TS7006）	同じ2行、終了コード 1	同じ2行、終了コード 1
削除されたオプション（`baseUrl`、`moduleResolution: node`）	TS5102・TS5108、終了コード 1	TS5102・TS5108、終了コード 1
`include` に該当するファイルがない	TS18003、終了コード 1	TS18003、終了コード 2
ファイル名を指定（`src/index.ts`）	`tsconfig.json` を使って検査、終了コード 1	TS5112（設定ファイルを読まない）、終了コード 1
`outDir` を指定し `rootDir` なし	エラーなし、終了コード 0	TS5011、終了コード 2

パイプで受けた標準出力は、型エラーの2行が tsc と diff で差分なしでした。要約の行は標準エラーに出ます。後述の2,000ファイルの合成プロジェクトに型エラーを1件入れた場合も一致しました。

TS18003の終了コードは1と2で違いますが、どちらも0以外なのでCIのジョブは失敗します。内容に差が出たのは表の最後の2行です。ファイル名を渡したときに tsconfig.json を使うのは、文書に「intentional」（意図した違い）として書かれている挙動です。一方、outDir を指定して rootDir を書かない設定では、tsc はTS5011（共通のソースディレクトリを rootDir で明示するよう求めるエラー）を出し、bun check は何も報告しませんでした。出力を書き出さない bun check では、出力の配置に関するこの検査が行われないとみられます（編集部の見立て）。tsc でビルドもしているプロジェクトでは、bun check が通っても tsc のビルドが落ちることがあります。

速さは編集部の合成プロジェクトで約2.6倍

速さは、編集部が生成した2,000ファイルの合成プロジェクト（各ファイルが直前の2ファイルをimportし、ジェネリクスのクラスやマップ型を含むもの、型エラーなし）で測りました。1回ずつ準備運転をしたあと、bun check と tsc --noEmit を交互に10回ずつ実行し、開始から終了までの時間を測っています。

bun check: 中央値 573ミリ秒（最短506、最長739）
tsc --noEmit: 中央値 1,502ミリ秒（最短1,319、最長1,834）

この条件では中央値で約2.6倍でした。スレッド数を1にした bun check --threads 1 は約1.5〜1.6秒で、tsc --noEmit --singleThreaded は約2.4〜2.6秒（各5回）でした。4コアの検証環境で1つのプロジェクトを測った値で、コード量、型の複雑さ、CIのランナーのコア数で結果は変わります。Bunのブログの3〜6.4倍（16コアのMac、実在のプロジェクト）とは条件が違い、その数字を確かめたものではありません。コア数の少ないCIのランナーでは差が小さくなる可能性もあるため、自社のリポジトリで同じように測ってから判断してください。

なお文書のとおり bun check は .tsbuildinfo を書かず、毎回全体を検査します（「No cache to save or restore」）。tsc の incremental に頼るCIとは比べ方を合わせます。

CIに入れる前に確かめたい落とし穴

--check フラグの結果は、版と使い方によって次のように分かれました。

古いBunでは `--check` が黙って無視される

Bun 1.4.2で bun --check src/index.ts を実行すると、型エラーのあるファイルがそのまま実行され、終了コードは0でした。bun test --check も型チェックをせずにテストが成功し、bun build --check はそのまま出力ファイルを書き出しました。bun check 自体は1.4.2では「Script not found “check”」で失敗するので気づけますが、--check フラグは気づけません。CIでもローカルでも、Bunの版を1.4.3以上に固定してから使います。

`bun test --check` はテストがimportする範囲だけ

文書のとおり、bun test --check が検査するのは「The test files and everything they import」です。src/index.ts に型エラーがあっても、テストがそのファイルをimportしていなければ、1.4.3でもテストは成功し終了コードは0でした。テストがimportする src/user.ts に型エラーを入れると、テストは実行されず終了コード1になりました。プロジェクト全体の型チェックの代わりにはならないため、CIでは bun check を別の手順として残します。

package.json に check スクリプトがあると別のものが動く

package.json に check という名前のスクリプト（リンターなど）があると、bun check はそのスクリプトを実行します。mainブランチの文書と、10月20日時点の公式サイトの文書（bun.com/docs/runtime/check）には型チェッカーを強制する --no-script が載っていますが、1.4.3のタグの文書と実行ファイルにはありません。1.4.3で bun check --no-script を実行すると、--no-script がスクリプトの引数として渡され、スクリプトが成功して終了コード0になりました。1.4.3では、文書のとおり bun --check（ファイルを指定しない形）を使うと、プロジェクト全体の型チェックになりました。

環境変数で出力の形式が変わる

AGENT=1、CLAUDECODE=1、REPL_ID=1 のいずれかがあると、bun check はエラーを <error file=...> のタグ形式で出します。検証環境には CLAUDECODE=1 があったため、最初の実行は tsc 形式になりませんでした。--no-pretty を付けると1行の形式に固定されることを確かめています。また GITHUB_ACTIONS=true を設定して手元で実行すると、1行の出力に加えて、文書がプルリクエストの注記に使うと説明している ::error file=... の行が出ました（GitHub上の表示は未確認）。

置き換えるときの進め方（編集部の提案）

Bunの版を固定する: oven-sh/setup-bun@v2 の bun-version に 1.4.3 以上を指定します。latest のままだと、文書と実行ファイルの機能（--no-script など）がずれる時期があります
しばらく両方を並べて走らせる: 既存の tsc --noEmit を残したまま bun check --no-pretty を追加し、エラーの行と終了コードが一致するかを数週間見比べます。文書は、TypeScript 7の tsc と違うエラーが出たらBunの不具合として報告するよう求めています
tsc の役割を分けて残す: .d.ts の生成や outDir を使うビルドは tsc のままにします。bun check が通っても、ビルドの設定の誤り（今回のTS5011）は tsc 側でしか見つかりません

# .github/workflows/typecheck.yml（並行運用の例。GitHub Actions上では未実行）
jobs:
  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
        with:
          bun-version: 1.4.3
      - run: bun install --frozen-lockfile
      - run: bun check --no-pretty
      - run: bun x tsc --noEmit  # devDependencies の typescript。一致を確かめる期間だけ残す

まとめ

まずは手元で bun -p process.versions.typescript を実行してBunが合わせているTypeScriptの版を確かめ、自社のリポジトリで bun check --no-pretty と tsc --noEmit の出力と終了コードを diff で比べてみてください。一致を確かめられたら、版を固定したうえでCIに並べて入れ、--check フラグや bun test --check だけに型チェックを任せない構成にすると、見落としを防げます。

2026年10月20日に、Bunのブログの1.4.3のリリースノートとGitHubのリリース、公式サイトの bun check の文書、oven-sh/bun の docs/runtime/check.mdx（bun-v1.4.3 タグと main）・docs/docs.json、npm の bun・@oven/bun-linux-x64・typescript・@types/bun の公開日時と版、oven-sh/setup-bun の action.yml、AnthropicのBun買収の告知を確認しました（資料調査）。編集部の検証環境（Linux x86_64・4コア、Node.js v22.22.0）で、Bun 1.4.3・1.4.2と TypeScript 7.0.2 の tsc を、3ファイルの検証用プロジェクトと2,000ファイルの合成プロジェクトに対して実行しました（実機検証）。GitHub ActionsやGitLab CIの実際のランナー、bun check -b とプロジェクト参照、Windows・macOS、大規模な実際のコードベースでの速さは確認していません。

TypeScriptのプロジェクトのCIの見直しや、業務システムの開発・テストの自動化は、グリームハブの開発・AI・自動化のご相談で承っています。プロジェクトの構成によって進め方が変わるため、お問い合わせからご相談ください。

記事を検索

Bun 1.4.3のbun checkはtscの代わりになるか並べて試した

bun check は何をするコマンドか