「ESLint と Prettier の設定がいつの間にか競合していた」「CI のリントに時間がかかりすぎる」「devDependencies に並ぶプラグインの数を見るたびに気が重くなる」——JavaScript / TypeScript プロジェクトを運用していると、こうした悩みに行き着くことは少なくありません。
そこで名前が挙がるのが、Rust 製のツールチェーン「Biome」です。フォーマッターとリンターを 1 つのツールにまとめ、高速に動作することで注目を集めています。とはいえ、いざ自分のプロジェクトで採用を検討すると、判断はそう簡単ではありません。「本当に ESLint + Prettier を置き換えられるのか」「同じく Rust 製で話題の oxlint（Oxc）とどちらを選ぶべきか」「将来も開発が続く健全なプロジェクトなのか」——こうした疑問に答えが出ないと、踏み切れないものです。
この記事では、Biome が何をするツールなのかという基本から、2025 年にリリースされた v2 での進化、そして ESLint + Prettier・Oxc（oxlint）との違いを、公開されているドキュメントと公式ブログをもとに整理します。実際に手元で動かした体験談ではなく、公式情報に基づく事実と選定の判断軸に絞って解説するため、「自プロジェクトで採用すべきか」を考えるための材料としてお使いいただけます。最後には、どんなプロジェクトに Biome が向くのかを条件として整理します。
Biomeとは｜ESLintとPrettierを統合するWeb向けツールチェーン
Biome は、Web プロジェクトの保守を支援することを目的としたツールチェーンです。公式の説明では「フォーマッターとリンターを提供し、CLI と LSP の両方から利用できる」と位置づけられています（Biome 公式サイト）。一言でいえば、これまで Prettier が担っていた「コード整形（フォーマット）」と、ESLint が担っていた「コード検査（リント）」を、1 つのツールにまとめたものです。
Biomeの基本情報｜言語・ライセンス・スター数・更新状況
採用を検討するうえで、まず気になるのが「そのプロジェクトは健全に運用されているか」という点でしょう。GitHub リポジトリ（biomejs/biome）の基本情報は次のとおりです（2026 年 6 月時点）。
項目 | 値 |
|---|---|
主要言語 | Rust |
ライセンス | Apache-2.0（README では MIT または Apache-2.0 のデュアルライセンス） |
スター数 | 25,138 |
フォーク数 | 1,035 |
最終更新（push） | 2026 年 6 月 20 日 |
アーカイブ / フォーク | いずれも該当なし（活発に開発中の本家リポジトリ） |
スター数は 25,000 を超え、フォーク数も 1,000 を上回っています。注目すべきは最終更新日で、本記事の調査時点でも当日にコミットが行われており、開発が止まっていないことがうかがえます。このリポジトリはアーカイブ（開発終了）されておらず、他リポジトリのフォーク（派生）でもない、独立して運用されている本家のプロジェクトです。「枯れて放置されていないか」という不安に対しては、更新頻度の高さが一定の安心材料になります。
なお、Rust で実装されているため、Biome 自体は単一のバイナリとして動作します。後述するように Node.js への依存なしで実行できる点も、ツールチェーンの軽量化につながる特徴です。
「1ツールで完結」という設計思想
ESLint + Prettier の構成では、リンターとフォーマッターが別々のツールであるため、それぞれの設定ファイル（.eslintrc と .prettierrc など）を用意し、両者が衝突しないよう調整する必要があります。整形に関するルールをどちらに任せるかで悩んだ経験がある方も多いはずです。
Biome はこの 2 つの役割を 1 つのバイナリに統合しています。これにより、エラー表示・並列処理・キャッシュ・設定といった内部の仕組みを共通の基盤の上で扱えるため、ツール間の責務分担を気にする必要がなくなります。設定は biome.json というファイル 1 つに集約され、ゼロコンフィグ（設定なし）でも妥当なデフォルトで動作します（Biome 公式サイト）。この「1 ツールで完結する」設計が、Biome を検討する最初の動機になることが多いといえます。
Biomeの主要機能｜フォーマッター・リンター・97%のPrettier互換
ここからは、Biome が ESLint + Prettier の代替になり得るかを判断するために、主要な機能を機能ごとに見ていきます。
フォーマッター｜Prettier互換97%・高速な整形
Biome のフォーマッターは、Prettier との互換性を重視して設計されています。公式 README によれば、Prettier との互換性は約 97% に達しているとされます（biomejs/biome README）。つまり、Prettier で整形していたコードを Biome で整形しても、ほとんどの場合で同じ結果が得られるということです。すでに Prettier に慣れているチームにとって、移行時の見た目の差分が小さく抑えられる点は重要な判断材料です。
速度面では、公式サイトが Prettier 比で約 35 倍高速という数値を挙げています（171,127 行 / 2,104 ファイルのフォーマット時、Biome 公式サイト）。整形にかかる時間が短くなることは、保存時の自動整形や CI での実行時間に直結します。
リンター｜500以上のルール・ESLint由来の診断
Biome のリンターは、ESLint や typescript-eslint をはじめとする既存ツール由来のルールを取り込んでおり、500 以上の lint ルールを提供しています。この「500 ルール」への到達は、後述する v2.5 のリリースで公式ブログが明記したマイルストーンです（Biome v2.5 リリースブログ）。
リンターは、潜在的なバグやコードの品質に関わる問題を検出し、診断（エラーや警告）として表示します。多くのルールは安全な自動修正にも対応しており、後述する CLI コマンドで一括適用できます。
対応言語とエディタ連携｜LSPによるリアルタイム診断
Biome が対応する言語は、JavaScript / TypeScript / JSX / TSX に加え、JSON / CSS / GraphQL です。HTML については v2 でフォーマッターが preview（試験的機能、デフォルト無効）として追加されています（Biome v2 リリースブログ）。
エディタ連携の面では、Biome はファーストクラスの LSP（Language Server Protocol）サポートを備えています。これにより、エディタ内でフォーマットやリントの結果をリアルタイムに受け取れます。ESLint + Prettier でもエディタ拡張で同等のことは実現できますが、Biome では 1 つのツールでまとめて連携できる点が違いです。
基本的な使い方｜CLIコマンドとbiome.json
Biome は npm でインストールでき、CLI から実行します。公式の Getting Started で示されているインストールコマンドは次のとおりです。
npm install --save-dev --save-exact @biomejs/biome
主要な CLI コマンドは次のとおりです。
# format files
npx @biomejs/biome format --write
# lint files and apply the safe fixes
npx @biomejs/biome lint --write
# run format, lint, etc. and apply the safe fixes
npx @biomejs/biome check --write
# check all files against format, lint, etc. in CI environments
npx @biomejs/biome ci
format は整形のみ、lint はリントのみ、check は整形・リント・インポート整理などをまとめて実行し安全な修正を適用するコマンドです。ci は CI 環境での検証用で、ファイルを変更せずチェックのみを行います。設定ファイルは次のコマンドで生成できます（Getting Started）。
npx @biomejs/biome init
生成された biome.json を編集することで、デフォルトの挙動を上書きしてルールや整形オプションを調整できます。設定が 1 ファイルに集約されるため、リンターとフォーマッターの設定を別々に管理する手間がない点が、ESLint + Prettier との運用上の違いになります。
Biome v2（Biotype）の進化｜型認識リンティングとプラグイン
「ESLint の強みである型を考慮した検査やプラグインは、Biome では使えないのでは」——これは乗り換えを検討する際に多くの人が抱く疑問です。2025 年にリリースされた Biome v2（コードネーム Biotype）は、まさにこの領域に踏み込んだメジャーアップデートです。「今採用しても将来性があるか」を判断するうえで、v2 でどこまで来たかを把握しておくことには意味があります。
tscなしの型認識リンティング
v2 の目玉機能が、型認識リンティング（type-aware linting）です。従来、型を考慮したリント（たとえば「await し忘れた Promise」を検出するようなルール）には TypeScript コンパイラ（tsc）が必要でした。Biome v2 は、tsc や typescript パッケージに依存せず、独自の軽量な型推論で型認識ルールを実行します。公式ブログは「TypeScript コンパイラに依存しない初の型認識リンター」を標榜しています（Biome v2 リリースブログ）。
第一弾のルールは noFloatingPromises（await 漏れの Promise を検出するルール）で、公式ブログによれば typescript-eslint と比較して約 75% のケースを検出しつつ、パフォーマンスへの影響はより小さいとされています（Biome v2 リリースブログ）。tsc に依存しない分、検出範囲は typescript-eslint より狭いものの、速度面では有利という位置づけです。この点は、型認識リントを ESLint に頼ってきたプロジェクトにとって、移行判断を左右する要素になります。
プラグインとマルチファイル解析
v2 では、コードスニペットをマッチングして診断を出力する第一弾のプラグイン機構が導入されました（Biome v2 リリースブログ）。プラグインのルールは GritQL という構文で記述します（Biome プラグインガイド）。ESLint のプラグインエコシステムほどの成熟度はまだありませんが、独自ルールを書く道筋が用意された点は、拡張性を重視するチームにとって前進といえます。
もう 1 つの大きな進化がマルチファイル解析です。プロジェクト内のファイルをスキャン・インデックス化することで、ファイルをまたぐルール（たとえばインポートの循環を検出する noImportCycles）を実現します。フルスキャンは速度に影響するため opt-in（必要なルールを有効にしたときのみ実行）として設計されており、速度とのバランスが配慮されています（Biome v2 リリースブログ）。
さらに 2026 年時点の最新系列である v2.5 では、lint ルールが 500 を超え、プラグインのコード修正（Plugin Code Fix）やファイルをまたぐリンティング（Cross-File Linting）が強化されています（Biome v2.5 リリースブログ）。型認識・プラグイン・マルチファイル解析という、かつて ESLint の優位性とされていた領域に Biome が着実に近づいていることが、v2 系列の進化からは読み取れます。
BiomeとESLint+Prettier・Oxcの違い｜選定の判断軸
ここがこの記事の核心です。Biome・ESLint + Prettier・Oxc（oxlint）の 3 者は、いずれも JavaScript / TypeScript のコード品質を扱うツールですが、設計思想が異なります。自プロジェクトでどれを選ぶかを判断するために、軸を整理します。
まず全体像を表で比較します。
観点 | Biome | Oxc（oxlint + oxfmt） | ESLint + Prettier |
|---|---|---|---|
提供形態 | フォーマッター + リンターを統合（単一ツール） | リンター（oxlint）とフォーマッター（oxfmt）を分離 | リンター（ESLint）とフォーマッター（Prettier）の 2 ツール |
実装言語 | Rust | Rust | JavaScript |
速度の方向性 | 統合しつつ高速（Prettier 比 約35倍） | リント特化で非常に高速（ESLint 比 50〜100倍） | 相対的に低速だが実績豊富 |
ルール / プラグイン | 500+ ルール、GritQL プラグイン（発展途上） | 約 200 ルール、ESLint プラグイン構文を再利用 | ESLint プラグイン 1000+（最も豊富） |
設定の手間 |
| oxlint + 別途フォーマッター（Prettier 併用想定） | 2 ツール分の設定調整が必要 |
数値の出典: Biome は公式サイト・v2.5 ブログ、Oxc はOxc ベンチマーク・Oxc ディスカッション。ルール数・速度は時点情報であり、各ツールの更新により変動します。
ESLint+Prettierとの違い｜統合度・速度・プラグイン
ESLint + Prettier は JavaScript / TypeScript のコード品質管理におけるデファクトスタンダードです。最大の強みは、プラグインエコシステムの圧倒的な豊富さにあります。ESLint のプラグインは 1,000 を超え、React・Next.js・各種フレームワーク・テスト・セキュリティといった幅広い領域をカバーしています。
一方で、リンターとフォーマッターが別ツールであるため設定の調整が必要で、JavaScript 実装ゆえに速度は Rust 製ツールに劣ります。Biome との違いを一言でまとめると、「統合度と速度では Biome、プラグインの網羅性と成熟度では ESLint + Prettier」という関係です。フレームワーク固有の高度な lint ルールに依存しているプロジェクトでは、現時点でも ESLint + Prettier を残す合理性があります。
Oxc（oxlint）との違い｜特化型 vs 統合型
Oxc（oxc-project/oxc）も Rust 製のツールチェーンで、リンターの oxlint とフォーマッターの oxfmt を提供します。Biome と最も対比的なのは、その設計思想です。
oxlint は「リンティングに特化」しており、フォーマットは別途 oxfmt や Prettier に任せる構成を想定しています。リント速度は ESLint 比で 50〜100 倍ともされ（Oxc ベンチマーク）、速度のボトルネック解消を最優先する場合に強みを発揮します。また oxlint は ESLint のプラグイン構文を直接再利用できる方向性を持つ一方、ルール数は約 200 と Biome より少なめです。
つまり、Biome が「フォーマット + リントを 1 ツールで完結させる統合型」であるのに対し、Oxc は「役割を分離し、それぞれを特化させる構成型」です。リント速度を極限まで突き詰めたい、あるいは ESLint からリンターだけを高速化したいなら oxlint、整形と検査を 1 つのツールでまとめたいなら Biome、という分かれ方になります。
どのツールがどんなチームに向くか
ここまでの違いを、チームの状況に置き換えて整理します。
- Biome が向くケース: フォーマッターとリンターを 1 ツールに統合し、設定をシンプルにしたい。Prettier に近い整形結果を保ちつつ高速化したい。型認識リントやプラグインの発展性にも期待している。
- ESLint + Prettier を残すべきケース: フレームワーク固有のプラグインや高度な lint ルールに強く依存している。エコシステムの成熟度・実績を最優先したい成熟コードベース。
- Oxc（oxlint）を検討すべきケース: フォーマッターは現状維持でよく、リントの速度だけを劇的に改善したい。ESLint のプラグイン資産を活かしつつ高速化したい。
このように、3 者は優劣ではなく「何を重視するか」で選び分けるツールです。自プロジェクトが「設定の統合」を求めているのか「リント速度の最大化」を求めているのか「プラグインの網羅性」を求めているのかを起点に考えると、判断がぶれにくくなります。
ESLint・PrettierからBiomeへ移行する手順と注意点
Biome の採用を決めたとして、次に気になるのが移行コストです。既存の ESLint / Prettier 設定をゼロから書き直すのは現実的ではありません。Biome はこの負担を軽減するために、既存設定を自動変換するマイグレーションコマンドを用意しています。
自動マイグレーションコマンド
公式の移行ガイドでは、ESLint と Prettier の設定をそれぞれ Biome の設定に変換するコマンドが示されています（ESLint・Prettier からの移行ガイド）。まず biome init で biome.json を生成したうえで、次のコマンドを実行します。
biome migrate eslint --write
biome migrate prettier --write
migrate eslint は既存の ESLint 設定を読み取って対応するルールを biome.json に反映し、migrate prettier は Prettier の整形設定を Biome 側に取り込みます。ESLint の移行では、--include-inspired フラグを付けると、ESLint と完全に同一ではないが着想を得たルールも移行対象に含められます（ESLint・Prettier からの移行ガイド）。これにより、手作業での設定書き換えを大幅に減らせます。
移行時の注意点｜互換性の限界と段階移行
自動変換が用意されているとはいえ、移行が完全に無痛で済むとは限りません。判断を誤らないために、いくつかの注意点を押さえておきます。
第一に、フォーマッターの Prettier 互換は約 97% であり、残りの数%では整形結果に差分が生じる可能性があります。コードベース全体に Biome を適用すると、この差分が大量の変更として現れることがあります。第二に、ESLint のすべてのルールに対応する Biome ルールが存在するわけではありません。フレームワーク固有のプラグインルールなど、Biome 側に対応がないものは移行できず、その分の検査をどう補うかを検討する必要があります。
こうした点を踏まえると、いきなり全面移行するより、まずは一部のディレクトリやフォーマッターのみを Biome に切り替えて差分を確認し、問題がないことを見極めてから範囲を広げる段階的な移行が現実的です。移行コマンドが整備されている一方で、互換性の限界を事前に把握しておくことが、移行の失敗を避ける鍵になります。
まとめ｜Biomeを採用すべきプロジェクトの条件
最後に、ここまでの判断軸を凝縮します。自プロジェクトの状況に当てはめて、結論を出すための整理としてお使いください。
- Biome が向くプロジェクト: フォーマッターとリンターを 1 ツールに統合して設定をシンプルにしたい。Prettier 互換の整形を保ちつつ高速化したい。型認識リント・プラグインといった v2 の発展にも期待できる。
- ESLint + Prettier を残すべきプロジェクト: フレームワーク固有のプラグインや高度な lint ルールに強く依存している。エコシステムの成熟度と実績を最優先したい。
- Oxc（oxlint）を検討すべきプロジェクト: フォーマッターは現状維持でよく、リント速度だけを劇的に改善したい。ESLint のプラグイン資産を活かしたい。
メンテナンスの健全性という観点では、Biome はスター数 25,000 超、最終更新も活発で、2025 年の v2、その後の v2.5 と継続的に進化しています（Biome v2 リリースブログ、Biome v2.5 リリースブログ）。「採用しても放置されるのでは」という不安は、現時点では小さいといえます。
Biome は、ESLint + Prettier を必ず置き換えるべき万能ツールではありません。しかし「設定の統合」と「速度」を重視するプロジェクトにとっては、有力な選択肢です。本記事の判断軸をもとに、まずはフォーマッターから試験的に切り替えるなど、小さく始めて自プロジェクトとの相性を確かめることをおすすめします。詳細な機能や最新の対応状況は、Biome 公式サイトで確認できます。
