JavaScript Oxidation Compiler を読み解く

Oxc（JavaScript Oxidation Compiler）は、Rust で書かれた高性能な JavaScript / TypeScript ツール群です。共通のパーサーと AST の上に構築されているため、linter、formatter、transformer、minifier、resolver がそれぞれ独立してコードを再パースすることがありません。

大規模なモノレポで lint を走らせ、コーヒーを淹れに行き、戻ってきてもまだ終わっていない——そんな経験があるなら、JavaScript ツールチェーンの Rust による書き直しがこれほど注目された理由はすでにお分かりでしょう。その待ち時間が開発者の数と CI ジョブの数だけ積み重なること、それが Oxc が存在する理由のほとんどです。

Oxc は VoidZero のツールチェーンを支えるコンパイラ層であり、Vite 8 以降はすべての Vite ビルドの内部で実際の言語処理を担う機構となっています。

ESLint / Babel / Prettier のパイプラインが遅く、Rust ツーリングの波（esbuild、SWC、Biome、Oxc）を横目で追ってきた人にとって、実務的な問いは「Oxc は速いのか？」ではありません。「今日の時点でどの部分が本番投入に耐えるのか、そして今動かしているものとどう位置づけられるのか」です。本記事はそれに答えます。Oxc とは何か、何が含まれるのか、いま安心して採用できるものは何か、そして代替手段との比較です。

JavaScript Oxidation Compiler、Oxc とは何か

Oxc は、単一のパーサーと AST を共有する Rust ネイティブな JavaScript / TypeScript ツール群です。そのため挙動の一貫性が保たれ、どのツールもパース処理を重複して行いません。名前は Rust にちなんでいます。錆（rust）とは金属が酸化（oxidise）してできるものだからです。ここでの速度は、心地よい副産物ではなくプロジェクトが必ず届けなければならないものとして扱われています。その根拠は、linter が速ければローカルでの編集・確認ループが締まり、CI の請求額も小さくなる、という理屈です。

Oxc が自身の CLI を超えて重要な理由は、それがモダンな Vite スタックの下層にあるコンパイラだという点です。Rolldown は Rust 製のバンドラーであり、パースや minify を含む言語レベルの処理を Oxc に委ねています。Vite 8 以降は、3 つの層すべてが歩調を合わせたチームによって開発されています。ビルドツールとしての Vite、バンドラーとしての Rolldown、そしてその両方の下にあるコンパイラとしての Oxc です。つまり、Oxc のパッケージを一度もインストールしない開発者でさえ、ビルドごとにそのパーサーと transformer を動かしていることになります。

パイプラインを賭ける前に知っておく価値のある、所有権に関する背景もあります。2026 年 6 月 4 日、Cloudflare が VoidZero を買収したと発表しました。VoidZero は Vite とその周辺ツール（Oxc を含む）をメンテナンスするオープンソース企業です。双方は、プロジェクトはオープンソースかつベンダーニュートラルのまま維持され、Vite、Vitest、Rolldown、Oxc、Vite+ はいずれも MIT ライセンス下に留まると述べており、Cloudflare は Vite のメンテナーとコントリビューターのための独立した基金に 100 万ドルを拠出しています。VoidZero 自体は、Vue.js の作者である Evan You によって 2023 年に設立されました。

各コンポーネントと置き換え対象

Oxc は独立して組み合わせ可能なパーツとして提供されるため、他を採用せずに 1 つだけ導入できます。それぞれが、既存の遅い JavaScript 製ツールを標的にしています。

パーサーが土台です。他のすべてのコンポーネントがその出力を読み取ります。だからこそ Oxc は、たまたま Rust で書かれた 6 つのツールではなく、1 つのツールチェーンだと名乗れるのです。

Oxc はなぜ速いのか

Oxc の速さはマイクロ最適化ではなくアーキテクチャから来ています。主に 3 つの選択が効いています。第一に、インタープリタ実行の JavaScript ではなくコンパイルされた Rust であるため、ホットパスがネイティブ速度で動き、ガベージコレクションによる停止も避けられます。第二に、すべてのツールが 1 つの共有 AST 上で動作するため、ESLint、Prettier、Babel が同じファイルを別々にパースするような冗長な再パースが排除されます。第三に、AST ノードはメモリアリーナに確保されて一括で安価に破棄でき、解析は CPU コア間で並列化されます。

その効果は計測されていますが、数字はプロジェクト自身のベンチマークなので、そのように受け取ってください。VoidZero は Oxlint が ESLint の 50〜100 倍高速、Oxfmt が Prettier のスループットの 30 倍以上、キャッシュなしの初回実行では Biome の 2〜3 倍程度、Rolldown が Rollup より最大 10〜30 倍高速なビルドと報告しています。Biome との比較が幅を持つのは、Oxc 自身の情報源が食い違っているためです。formatter のドキュメントは 2 倍、ベータ発表は 3 倍と記しています。ベンチマークもマシンも異なれば結果も変わります。優位性の形は本物ですが、正確な倍率は自分のリポジトリで実行するまではマーケティングの数字です。

現時点で Oxc のどこが本番投入に耐えるか

Oxc の成熟度は、各ツールをどう利用するかによって変わります。Oxlint とパーサーは単体で真に本番グレードです。transformer と minifier は CLI としては 1.0 未満ですが、Rolldown と Vite 8 の内部ではすでに本番稼働しています。Oxfmt はベータです。

明確に際立っているのは Oxlint です。2025 年 6 月に安定版 1.0 をリリースし、リリースノートには本番利用者として Shopify、Airbnb、Mercedes-Benz が挙げられています。現在は 1.x 系にあり、844 個の組み込みルールを備えています。Oxlint は型情報を利用した lint も行います。tsgolint バックエンドが TypeScript 自身の型システムを Oxlint の CLI と設定形式に接続し、typescript-eslint が提供する 61 個の型認識ルールのうち 59 個をカバーします。正直な注意点としては、オプトインであること、Oxlint とは別に oxlint-tsgolint パッケージのインストールが必要であること、そしてそのパッケージのバージョン番号が Oxlint ではなく、ビルド対象の TypeScript リリースに追随するため、両者が別のスケジュールで動くことです。またチームは、カバレッジと性能に取り組む間、typescript-eslint のセット外のルールには門戸を閉じているため、現時点でカスタムの型認識ルールは不可能です。

「transformer と minifier は 1.0 未満」を「本番投入に耐えない」と読まないでください。どちらもすでに、すべての Vite 8 ビルドの下で動いています。Vite 8 の移行ガイドは役割分担を明記しています。Oxc が esbuild から JavaScript の変換と JavaScript の minify を引き継ぎ、CSS の minify は Lightning CSS がデフォルトになりました。一方 Oxfmt はアルファからベータへ進み、Prettier の JavaScript / TypeScript 適合性テストスイート全体を通過するようになりましたが、npm 上ではまだ Beta と表示されているため、Prettier を全面撤去する段階ではなく、試験導入の対象です。

Oxc と SWC、Biome の比較

比較で最もよくある間違いは、Oxc を SWC と速度で対比させることです。両者は異なる層にいます。SWC はフレームワークが組み込むコンパイラプラットフォームです。Next.js は自身の SWC 接合部を所有しており、ベンチマークのグラフを追いかけてそれを引き剥がすべきではありません。Oxc の transformer は SWC と Babel と競合しますが、SWC には公式の linter も formatter もありません。したがって Oxlint が競合するのは ESLint と Biome であり、SWC ではありません。 より近いライバルは Biome です。1 つのバイナリで lint と format の両方を行う Rust ツールであるのに対し、Oxc は Oxlint と Oxfmt を独立して組み合わせ可能なパーツとして保っています。

以上を踏まえると、実務的な動きは Oxlint を今すぐ採用し、残りは様子を見ることです。CI では高速な一次パスとして実行し、まだカバーされていないルールやプラグインのために ESLint を残します。

{
  "scripts": {
    "lint:fast": "oxlint",
    "lint": "oxlint && eslint ."
  }
}

重複を減らすため、ドキュメントは既存の ESLint 設定を変換する @oxlint/migrate と、Oxlint が既に扱うルールを無効化する eslint-plugin-oxlint を案内しています。これにより、フルの実行で ESLint のカバレッジを犠牲にすることなく、高速パスで速度の恩恵を得られます。

Oxc は「有望な Rust プロジェクト」から、すでに数百万のビルドが依存するインフラへと踏み越えました。ただしその成熟度は全域で均一ではありません。まずは Oxlint から始め（安定していて速く、現在の linter と併走させてもリスクが低い）、Oxfmt はブランチで試験導入して差分を確認し、transformer と minifier は単体で採用するのではなく Vite 8 経由で自然に届くのを待ちましょう。1.0 未満のパーツは昇格に応じて再評価してください。進む方向は、計画を立てられるだけには明確です。

FAQ

Oxlint と ESLint は併用できますか、それともどちらかを選ぶ必要がありますか？

併用できますし、併用が推奨される採用パスです。Oxlint を CI の高速な一次パスとして使い、Oxlint がまだカバーしていないルールやプラグインのために ESLint を残してください。Oxc のドキュメントは、既存の ESLint 設定を変換する '@oxlint/migrate' と、Oxlint が既に扱う ESLint ルールを無効化する 'eslint-plugin-oxlint' を案内しており、2 つの linter を併走させながら重複作業を取り除けます。

Oxc は SWC を置き換えるものですか。Oxc を使うために Next.js から SWC を外すべきですか？

いいえ。Oxc の transformer は SWC や Babel と競合しますが、Next.js のように SWC を組み込んでいるフレームワークから、ベンチマークを追いかけて SWC を引き剥がすべきではありません。SWC はフレームワークが内部で所有するコンパイラプラットフォームであり、SWC には公式の linter も formatter もないため、Oxlint が競合するのは SWC ではなく ESLint と Biome です。安全な採用対象は Oxlint であり、フレームワーク内蔵のコンパイラの差し替えではありません。

Oxc と Biome の違いは何ですか？

Biome は lint と format の両方を行う単一の Rust バイナリですが、Oxc は linter（Oxlint）と formatter（Oxfmt）を独立して組み合わせ可能なパーツとして保ち、個別に採用できます。Oxc はより広範でもあります。Rolldown と Vite 8 を支えるパーサー、transformer、minifier、resolver を含む一方、Biome は lint と format の層に集中しています。キャッシュなしの初回実行では、VoidZero のベンチマークで Oxfmt は Biome の概ね 2〜3 倍高速とされていますが、この比較について Oxfmt のドキュメントとベータ発表は異なる数値を挙げています。

Cloudflare による VoidZero の買収で、Oxc がオープンソースのままかどうかは変わりますか？

いいえ。Cloudflare は 2026 年 6 月 4 日に VoidZero を買収しましたが、両社はプロジェクトがオープンソースかつベンダーニュートラルのまま維持されると述べています。Vite、Vitest、Rolldown、Oxc、Vite+ は MIT ライセンス下に留まり、Cloudflare は VoidZero も Cloudflare も所属しないメンテナーおよびコントリビューターのための新しい独立した Vite エコシステム基金に 100 万ドルを拠出しました。MIT ライセンスであるため、所有権に関係なく既存のフォークや利用は影響を受けません。