先に要点
- 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 製ツールにまとめた』</strong> プロジェクトです。 速度・設定の薄さ・統一感を売りにしていて、これ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』</strong> という構図です。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 を入れるか』 の判断材料です。
一気にゼロから移行』 ではなく、<strong> 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. 概ね互換だが、細部に違いがあります』</strong>。Biome 公式もPrettier 互換を目標にしている』 とアナウンスしていて、実際に大半のケースで差が出ません。`改行位置やラップ方式が違う』 箇所があるので、移行時に一度全体を再 format するのが基本です。
Q. ESLint を完全に置き換えられますか？
A. recommended 中心の構成なら可能、特殊プラグイン依存なら困難』</strong>です。@typescript-eslint / react-hooks / import』 程度の典型構成は Biome でカバーできますが、`Tailwind や独自社内ルール』 を多用しているなら、ESLint の併用 / 残存が現実的です。
Q. Vue / Svelte / Astro でも使えますか？
A. 対応は限定的です』</strong>。.vue』 .svelte』 .astro』 ファイルの完全サポートはまだ発展中で、scripts 部分だけ Biome、template は Prettier』 のような分担になります。React 中心』 のプロジェクトでは問題なく使えます。
Q. CI に組み込むときの推奨は？
A. biome ci』 コマンドを使うのが推奨です。CI 向けに最適化された出力形式と終了コードを返すサブコマンドで、`format / lint / import 整理』 をまとめて1コマンドで検証できます。
Q. ESLint と Biome を併用する場合の注意点は？
A. Format は片方に統一する』</strong> のが鉄則です。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: 公式