先に要点
- Biome(旧 「Rome Tools」 のフォーク版)は、Linter と Formatter を1つにまとめた Rust 製ツール。「ESLint + Prettier」 の置き換えを目指して開発されている。
- 最大の特徴は 圧倒的な速度。Rust 製で並列処理が効くため、「数千ファイルのプロジェクトでも数秒で lint + format 完了」 のような体感差が出る。「pre-commit が痛い」 「CI で format チェックに分単位かかる」 系の悩みを解消する。
- 1ツールで設定が完結。「.eslintrc / .prettierrc / .editorconfig が3つに分かれていた世界」 を、「biome.json 1ファイル」 にまとめられる。プラグインや preset の沼に入る必要がない。
- 万能ではない。「 ESLint の豊富なプラグインエコシステム」 と完全互換ではない。Tailwind / Vue / Svelte / 特殊な独自ルールが必要なケースでは、ESLint との併用 / ESLint 残存も視野に入れる。
Biome ってよく聞くけど、結局 ESLint と何が違うの？ Prettier はそのまま使えるの？ 「設定地獄から抜けたい」 ── JavaScript / TypeScript 開発で 「lint + format の設定で消耗する時間」 にうんざりしたチームから、急速に支持を集めているのが Biome です。
ざっくり言うと、Biome は ESLint と Prettier を1つの Rust 製ツールにまとめた プロジェクトです。 速度・設定の薄さ・統一感を売りにしていて、「これ1本で lint + format が済む」 という体験を提供します。Bun や Tailwind v4 の Oxide のように、「Web 開発の足回りを Rust で書き直す」 流れの代表的な道具のひとつです。
この記事では、2026年5月時点の Biome の状況をベースに、何ができるか・ESLint + Prettier との違い・どう使うか・採用判断軸 を整理します。
Biome が解決した問題
Biome の登場背景には、「ESLint + Prettier 時代」 の積み上がった課題があります。
①設定が散らばる
「.eslintrc.js」 「.prettierrc」 「.eslintignore」 「.prettierignore」 「.editorconfig」 …。「ファイル数が多くて、どれが何を制御しているのか分かりにくい」。
② ESLint × Prettier の衝突
「 ESLint がスタイルを直そうとして、Prettier が逆に直す」 系のループ。「eslint-config-prettier」 で抑える必要があり、Knowledgeが必要だった。
③ 速度
大規模リポジトリで 「eslint --fix」 が分単位、「prettier --write」 もそれなりに時間がかかる。「pre-commit hook が遅すぎる」 ストレス。
④ プラグインの依存地獄
「@typescript-eslint / eslint-plugin-react / eslint-plugin-import / ...」 と、「プラグインのバージョン整合に毎月時間を取られる」。
Biome は Linter と Formatter を1つに統合し、Rust で書き直し、設定を最小化する という方針で、これらをまとめて解消することを目指しました。
Biome の中身 — 速さと統合の正体
「なぜ速くて、なぜ設定が薄くなるのか」 を整理します。
Rust 製の高速パーサ
ファイル数 × ルール数で計算量が膨らむ Lint 処理を、並列処理 + ネイティブ速度 で実行。ESLint の Node.js JIT に対して数倍〜数十倍の速度が出る場面が多い。
統合されたパーサ
「 Lint も Format も同じパーサを使う」 ので、「Prettier と ESLint で別々にパースして二度手間」 が起きない。「ASTの解釈に揺れがない」 のが正確さにも効く。
単一の設定ファイル
「biome.json」(または 「.toml」)で lint + format + import 整理を全部設定。「複数ファイルを行ったり来たり」 が消える。
前提のシンプル化
「 Prettier の哲学を継承」 → スタイルは基本固定、設定で選べるのは最小限。「チームごとにルールで揉める」 時間が減る。
「設定の自由度を減らすことで、運用負担を減らす」 という Prettier 系の発想を、Linter と Formatter にまたがって徹底したのが Biome の根っこの設計判断です。
基本の使い方
導入と使い方は驚くほど短く済みます。
# インストール
npm install --save-dev --save-exact @biomejs/biome
# 初期化
npx @biomejs/biome init
# Lint と Format を実行
npx @biomejs/biome check ./src
# 自動修正
npx @biomejs/biome check --write ./src
// biome.json(自動生成される)
{
"$schema": "https://biomejs.dev/schemas/2.0/schema.json",
"files": { "ignoreUnknown": false },
"formatter": { "enabled": true, "indentStyle": "tab" },
"linter": { "enabled": true, "rules": { "recommended": true } },
"javascript": { "formatter": { "quoteStyle": "single" } }
}
「biome check」
「lint + format + import 整理」 を1コマンドで実行。「どこに問題があるか」 を見るとき。
「biome check --write」
「 自動修正可能なものをまとめて修正」。「prettier --write && eslint --fix」 の置き換え。
「使い始めて当日に効果が見える」 のが Biome の特徴で、「設定で1日かかる」 系の苦痛と無縁です。
ESLint + Prettier との比較
3つを並べると、それぞれの立ち位置がはっきりします。
| 軸 | ESLint | Prettier | Biome |
|---|---|---|---|
| 役割 | Linter | Formatter | Linter + Formatter |
| 実装言語 | JavaScript | JavaScript | Rust |
| 速度 | 普通 | 普通 | 圧倒的に速い |
| 設定ファイル | 「.eslintrc.*」 + 「.eslintignore」 | 「.prettierrc.*」 + 「.prettierignore」 | 「biome.json」 1つ |
| プラグインの豊富さ | ◎(10年以上の蓄積) | ○(各種統合) | △(発展中) |
| 独自ルールの作成 | 柔軟 | ― | 限定的 |
| 多言語サポート | JS / TS / JSON / Markdown(プラグイン経由) | JS / TS / CSS / HTML / GraphQL / YAML 等 | JS / TS / JSX / TSX / JSON / CSS / GraphQL(増加中) |
| VSCode 統合 | ○ | ○ | ○(高速) |
| 競合の解消 | 「 eslint-config-prettier」 が必要 | ― | 不要(1ツールなので衝突しない) |
要点は 速度と設定のシンプルさを取るなら Biome、プラグインの豊富さを取るなら ESLint + Prettier という構図です。 「ESLint プラグインで Tailwind や独自ルールを多数使っている」 案件では Biome に完全移行できない一方、「シンプルな TS / JS プロジェクト」 では Biome の体験が圧倒的に良い、という棲み分けが見えてきます。
どの程度 ESLint と互換性があるか
「置き換えられるか」 を判断するうえで重要なのが、ルール互換性です。
主要 ESLint ルールの大半をカバー
「@typescript-eslint」 系の核となる型関連ルール、「no-unused-vars」 などの基本ルールは Biome 側にも実装済み。` 標準的な lint 要件は満たせる ことが多い。
React / JSX 関連
「react/jsx-no-undef」 系の代表的なルールはサポートあり。Hook ルール(「react-hooks/rules-of-hooks」)もある。
特殊なプラグイン
「eslint-plugin-import」 の細かい設定、「Tailwind ESLint プラグイン」 のような特化系、独自社内ルールなどはまだ ESLint のままにすべき場合がある。
共存可能
` Biome を format + 基本 lint、ESLint を 「Biome に対応がないルールだけ」」 という併用構成も可能。「完全置き換え」 と 「併用」 を段階で進められる。
「完全に ESLint を捨てる」 までは行かないチームでも、「Format は Biome に統一、Lint は ESLint と Biome を混在」 だけで体感速度は十分改善します。
採用判断のチェックリスト
「いま Biome を入れるか」 の判断材料です。
「一気にゼロから移行」 ではなく、「 Format → 基本 Lint → 必要なら ESLint 残存」 の3段階で進めるのが現実的 です。
どこで詰まりやすいか
実務で踏みやすいポイントを挙げておきます。
①Prettier との微妙なスタイル差
「 改行位置」 「引数のラップ方式」 などで Prettier と異なる挙動の箇所がある。` 一度 「biome check --write」 でフォーマットを揃え、コミットしてから運用に乗せる」 のが安全。
② プラグイン非対応
「 eslint-plugin-tailwindcss」 のようなニッチで便利なプラグインに完全な代替はまだない。「Biome + その項目だけ ESLint」 の併用が現実的。
③ 一部のファイル形式
Vue / Svelte / Astro のコンポーネントファイル(「.vue」 「.svelte」 「.astro」)は対応が限定的。「これらを使う案件では当面 Prettier + ESLint も残す」 が現実的。
④ チームへの周知
「 ESLint + Prettier が長年標準だった」 ので、「Biome に置き換える」 提案には説明コストがかかる。「速度差の実測値」 を見せると合意形成が早い。
「既存 ESLint プラグインを完全互換にはできない」 のは、Biome の根本的な制約として認識しておくのが大事です。
AI 時代の Biome
AI 連携の文脈でも Biome の特徴は効きます。
速いフィードバックループ
AI でコードを書く → 「lint + format で即フィードバック」 を回す時代。` Biome の数倍の速度差が、開発者体験にそのまま効く。
AI で 「CI 実行回数」 が増えると、「CI 時間 × Vercel / Cloud 課金」 が積み上がる。Biome の速度はそのままコスト圧縮になる。「Vercel の高額請求対策」 でも触れた話と地続き。
AI が出すコードのスタイル統一
AI が複数回出力したコードの 「スタイルが揺れる」 のを、保存時に Biome が即整形してくれる。「AI 出力 + 即 format」 がデフォルトの開発体験になる。
「速度 × 単一設定 × Rust エンジン」 という Biome の特徴は、AI 開発の高頻度サイクルにそのままハマる、という流れがあります。
Biome に関するよくある質問
Q. Biome は Prettier の完全互換ですか？
A. 概ね互換だが、細部に違いがあります。Biome 公式も 「Prettier 互換を目標にしている」 とアナウンスしていて、実際に大半のケースで差が出ません。「改行位置やラップ方式が違う」 箇所があるので、移行時に一度全体を再 format するのが基本です。
Q. ESLint を完全に置き換えられますか？
A. recommended 中心の構成なら可能、特殊プラグイン依存なら困難です。「@typescript-eslint / react-hooks / import」 程度の典型構成は Biome でカバーできますが、「Tailwind や独自社内ルール」 を多用しているなら、ESLint の併用 / 残存が現実的です。
Q. Vue / Svelte / Astro でも使えますか？
A. 対応は限定的です。「.vue」 「.svelte」 「.astro」 ファイルの完全サポートはまだ発展中で、「scripts 部分だけ Biome、template は Prettier」 のような分担になります。「React 中心」 のプロジェクトでは問題なく使えます。
Q. CI に組み込むときの推奨は？
A. ` 「biome ci」 コマンドを使うのが推奨です。CI 向けに最適化された出力形式と終了コードを返すサブコマンドで、「format / lint / import 整理」 をまとめて1コマンドで検証できます。
Q. ESLint と Biome を併用する場合の注意点は？
A. Format は片方に統一する のが鉄則です。「Biome で format、ESLint で lint のみ」 のように役割を分けないと、「ESLint がスタイルを直そうとして Biome と衝突する」 ループが起きます。
Q. Bun や pnpm との相性は？
A. 良好です。Bun のスクリプト経由でも、pnpm のモノレポでも、「biome check」 をそのまま呼べます。「どのパッケージマネージャでも使える」 のは Biome 側の設計の良さです。
Q. 移行コストはどのくらい？
A. ` 半日〜1日で 「format だけ Biome に切り替え」 が可能です。「lint も完全移行」 までやるなら、ESLint プラグインの棚卸しで数日〜1週間かかる場合があります。「段階移行を許容できるか」 で計画が変わります。
参考リンク
- Biome: 公式サイト
- Biome: Documentation
- Biome: GitHub
- Biome: Rules reference
- ESLint: 公式
- Prettier: 公式