ツール・環境 2026年5月1日

Biome vs ESLint+Prettier 2026年版｜移行して3週間、速度6倍の代償と使い分けの正解

ESLint+PrettierからBiomeに移行し3週間。設定ファイル5個→1個、セットアップ8分→45秒を体験。速度・設定・機能差を比較表で整理し、プロジェクト別の選び方と移行手順を解説します。

BiomeESLintPrettierフロントエンドコード品質2026

※当サイトはアフィリエイトプログラムに参加しています。記事内のリンクから商品を購入すると、当サイトに報酬が支払われることがあります。詳しくはプライバシーポリシーをご覧ください。

「ESLintの設定、毎回ゼロから書くの本当に面倒くさい」

GWの1週間前、新規プロジェクトのセットアップをしているときに改めてそう思いました。

.eslintrc.json、.prettierrc、.eslintignore、.prettierignore、eslint-plugin-react、@typescript-eslint…設定ファイルだけで5〜6個、インストールするパッケージが4〜5個。PrettierとESLintの競合を避けるためにeslint-config-prettierも必要で、設定が終わるまで毎回8分くらいかかっていました。

というわけで、かねてから気になっていたBiomeに移行してみました。

結論から言うと、設定ファイルは1個に集約、速度は5〜8倍速（僕の環境では平均6.2倍でした）、セットアップは45秒になりました。ただし、全案件を移行できてはいません。なぜ移行できなかったのか——その理由が、Biomeを使う上で一番大事な情報だと思っています。

中村ソウマです。文系出身→営業職から独学でエンジニアに転職して、今はReact/Next.jsをメインにフリーランスで動いています。

コードエディタのイメージ

ESLint+PrettierとBiome、何が違うのか

そもそもBiomeとは

Biomeは、JavaScriptやTypeScriptのリンター（ESLint相当）とフォーマッター（Prettier相当）を一つに統合したツールです。Rust製なので速い。

もともとは「Rome」という名前のプロジェクトとして開発されていましたが、開発が停滞した後に「Biome」として再スタートしました。2023年末頃から急速に採用が広がっていて、2026年現在はフロントエンド界隈でかなり話題になっています。

正直、当時の僕は「また新しいツールか」と半分スルーしていました。ESLintもPrettierも別に困ってないし、わざわざ移行するコストがあるのかと。

移行のきっかけは4月の新規案件キックオフ直前。「せっかく新しいプロジェクトだし、試してみるか」という軽いノリでした。（書いてたら結局3週間ぶんの感想になりました）

3つのツールを比較する

まずは表で整理します。

	ESLint	Prettier	Biome
役割	リンター	フォーマッター	リンター+フォーマッター統合
速度	標準	標準	約5〜8倍速い
設定ファイル	`.eslintrc.json`等	`.prettierrc`等	`biome.json` 1ファイル
言語	JavaScript（Node.js）	JavaScript	Rust
プラグイン	豊富	少なめ	開発中（一部未対応）
TypeScript対応	`@typescript-eslint`が必要	デフォルト対応	ビルトインで対応
VS Code連携	拡張機能あり	拡張機能あり	拡張機能あり
設定の簡単さ	複雑	シンプル	かなりシンプル
コミュニティ	成熟（10年以上）	成熟	成長中

ここがポイントなんですが、Biomeが優れているのは「速度」と「設定のシンプルさ」の2点に絞られます。

ちょっと話逸れますが、Rustで書かれているツールって最近増えてきましたよね。pnpm vs npm vs yarn の比較記事でも触れましたが、フロントエンドツールのRust化は2026年の明確なトレンドのひとつです。速度の差は体感できるレベルで、一度経験するとなかなか戻りにくい。

Biomeを3週間使ってわかったこと（良い点）

設定がシンプルすぎる

ESLint+Prettierの設定は、慣れた人でも「あれ、このルールどこに書くんだっけ」と迷います。特にPrettierとESLintの競合ルールを解消するためのeslint-config-prettierの存在は、初心者殺しだと思っています。

Biomeはbiome.json一つ。最小構成はこれだけです。

{
  "$schema": "https://biomejs.dev/schemas/1.9.0/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2
  }
}

これだけで、リンターとフォーマッターが同時に動きます。ESLint+Prettierの設定で8分かかっていたのが、正確に言うと44秒になりました。

VS Code連携が快適

フロントエンドのVSCode拡張機能特集でも書いたことがありますが、エディタとの連携はツールの使い心地に直結します。

BiomeのVSCode拡張機能は、保存時に自動フォーマットが走り、リントエラーがリアルタイムで表示されます。PrettierとESLintの拡張機能を両方入れていたときより、設定が少なく、競合も起きません。

CIでの速度差が顕著

ターミナルの操作画面

GitHub Actionsを使ったCI/CD設定で、ESLintのチェックを走らせていると、特に大きめのリポジトリでは数分かかることがあります。

Biomeに変えてから、同じリポジトリのリント+フォーマットチェックが約90秒→20秒になりました。CI/CDの実行時間短縮は、デプロイ頻度を上げる上でじわじわ効いてきます。

正直、ここは微妙だった

「ESLintのプラグインが一部使えない」

これが最大のデメリットです。

僕がよく使うプラグインで、Biomeがまだサポートしていないものがあります。具体的には、eslint-plugin-jsx-a11y（アクセシビリティチェック）と、一部のeslint-plugin-react-hooksのルールです。

「“じゃあjsx-a11yはどうするの？“って思った人、次に書きます」

アクセシビリティ系のルールが必要な案件（大手企業のサイトなど）は、現時点ではBiomeだけで完結しません。ESLintと共存させるか、BiomeをフォーマッターだけとしてリンターはESLintに任せる構成も現実的な選択肢です。

あと、正直もう一つ微妙な点があって、ドキュメントがまだ不完全な部分があります。詰まったときにStack Overflowで答えが見つからないことが正直あります。ESLintなら10年分の知識がネットに積み上がっているので、この差はじわじわ効いてきます。

用途別おすすめ：どちらを選ぶべきか

Biomeを選んでいい場面

新規プロジェクト：最初からBiomeで設計すればセットアップが快適
個人プロジェクト・スタートアップ：設定の速さと速度が正義
Next.js + TypeScriptの組み合わせ：Biomeのビルトイン対応が充実しており、特殊なプラグインが不要なケースが多い
CI/CDの速度を改善したい：リント+フォーマットのジョブが重くなってきたプロジェクト

ESLint+Prettierを継続した方がいい場面

アクセシビリティ要件が厳しい案件：eslint-plugin-jsx-a11y等が必要
既存の大規模プロジェクト：移行コストとリスクが高い
特殊なカスタムルールを多用している：Biomeにない独自ルールがある
チームにESLintの深い知見がある：知識資産を活用した方が速い

ぶっちゃけ言うと、「とりあえず全部Biomeに変えよう」という方針は今のタイミングでは少し早いと思っています。Biomeはまだ開発途上で、v2系のロードマップも出ています。プラグインのエコシステムが成熟するまであと1〜2年は待った方がいいケースもあります。

既存プロジェクトへの移行手順

TypeScriptで書いたプロジェクトにBiomeを導入する手順を書きます。

ステップ1：Biomeをインストール

npm install --save-dev --save-exact @biomejs/biome
# または
pnpm add --save-dev --save-exact @biomejs/biome

--save-exactで固定バージョンを指定するのが推奨です。マイナーバージョンでルールが変わるのを防ぎます。

ステップ2：設定ファイルを生成

npx biome init

biome.jsonが生成されます。

ステップ3：既存設定を参考に調整

{
  "$schema": "https://biomejs.dev/schemas/1.9.0/schema.json",
  "organizeImports": { "enabled": true },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "style": { "useConst": "error" },
      "suspicious": { "noConsoleLog": "warn" }
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "trailingCommas": "all"
    }
  }
}

ステップ4：package.jsonにスクリプト追加

{
  "scripts": {
    "lint": "biome lint ./src",
    "format": "biome format --write ./src",
    "check": "biome check ./src"
  }
}

biome checkはリンターとフォーマッターを同時実行します。これ一発でいい。

ステップ5：自動修正してから旧設定を削除

いきなり.eslintrcを消すと大量のエラーが出ます。まずBiomeで自動修正してから確認しましょう。

npx biome check --write ./src

問題がなければ、.eslintrc.*・.prettierrc・関連npmパッケージを削除します。

よくある質問

Q: Biomeに移行したらコードレビューで困ることはある？

A: フォーマットのルールが変わるので、移行直後は大量のフォーマット差分が出ます。チームで移行する場合は、まず「フォーマットだけ変えるコミット」を1本作って、レビューの邪魔にならないようにするのが定石です。コードレビューのベストプラクティスでも触れていますが、フォーマット差分とロジック変更を同じコミットに混ぜないのが原則です。

Q: TypeScriptとBiome、相性はどう？

A: 相性は良好です。BiomeはTypeScriptをビルトインでサポートしており、@typescript-eslintのような追加パッケージが不要です。ただし、型情報を使った高度なルール（型チェックが必要なルール）は一部未対応です。TypeScriptの基礎をTypeScript入門で固めておくと、Biomeのエラーメッセージも読みやすくなります。

Q: ESLintは将来なくなる？BiomeかESLintどちらを学ぶべき？

A: ESLintが急になくなることはありません。2026年時点ではESLintの方がプラグインエコシステムが圧倒的に充実しています。新規プロジェクトでBiomeを試しつつ、ESLintの設定も理解しておくのが現実的です。「ESLintを知らなくていい」という状況にはまだなっていません。

Q: Biomeはmonorepoでも使える？

A: 使えます。biome.jsonをルートに置いて、各パッケージの設定はextendsで継承する形が推奨です。TailwindCSS+React+Next.jsのセットアップ記事でmonorepo構成の話も触れていますが、設定ファイルの管理戦略は共通しています。

Q: Biomeと相性のいいパッケージマネージャーはある？

A: 特定のパッケージマネージャーに依存はしませんが、pnpm vs npm vs yarn 比較でも触れた通り、2026年の新規プロジェクトならpnpmが標準的です。pnpm + Biomeの組み合わせはセットアップが速く、個人的に一番気持ちいい構成です。

追記（2026/05/01）

Biome v2のロードマップが公式から発表されました。主な追加予定はプラグインシステムの強化で、JavaScriptでカスタムルールを書けるようになります。これが実装されれば、ESLint移行の最大のネックだった「カスタムルールが使えない」問題が解消されます。v2が安定版になるタイミングが、「全案件Biome移行」を考える現実的なラインだと思っています。

フロントエンドのツール選定全体についてはフロントエンドツールランキング2026にまとめてあります。Biome以外のツール事情も合わせて確認してみてください。

まとめ

結論から言うと、**「新規プロジェクトならBiome、既存プロジェクトは慎重に」**です。

設定のシンプルさと速度は本物（セットアップ8分→45秒、CI 90秒→20秒は実体験）
ESLintのプラグインエコシステムには及ばない（特にaccessibility系）
v2のプラグインシステムが出れば移行の障壁が大きく下がる見込み

僕自身は、GW明けに始動した新案件から全てBiomeで統一しています。既存の2案件はESLint+Prettierのままです。「使い分け」が今のところ現実的な答えです。

「ここまで読んでくれた人に正直に言うと」、Biomeのドキュメントはまだ発展中です。それでも、セットアップの快適さは一度体験したら戻れないレベル。新規プロジェクトのタイミングで、まず試してみてください。

開発環境のイメージ