TypeScriptを用いた開発において、コードの品質を維持し、チーム全体でのコーディング規約を統一することは極めて重要です。

その中心的な役割を担うのが、静的解析ツールのESLintと、コードフォーマッタのPrettierです。

しかし、これら2つのツールは役割が重なる部分があり、適切に設定しないと「ESLintが修正した箇所をPrettierが再修正する」といった競合が発生してしまいます。

2026年現在のモダンなフロントエンド開発では、ESLintのFlat Configへの完全移行や、ESLint側でのフォーマットルールの非推奨化が進んだことにより、共存設定のベストプラクティスが以前とは大きく変化しています。

本記事では、TypeScriptプロジェクトにおいて、PrettierとESLintを最も効率的に共存させるための最新の推奨設定と、トラブルを防ぐためのポイントを詳しく解説します。

目次 [ close ]
  1. TypeScript開発におけるESLintとPrettierの役割分担
    1. ESLintの役割：コードの「質」を担保する
    2. Prettierの役割：コードの「見た目」を整える
  2. 2026年最新の競合回避戦略：フォーマットルールの完全委譲
    1. なぜ「eslint-plugin-prettier」を使わないのか
  3. 推奨されるパッケージ構成とインストール
  4. Prettierの詳細設定（.prettierrc）
  5. ESLintの最新設定（eslint.config.js）
    1. 競合回避の鍵「eslint-config-prettier」
  6. エディタ（VS Code）での自動整形設定
  7. Git Hooksによる強制：lint-stagedとhuskyの活用
    1. 必要なツールの導入
    2. package.jsonの設定
  8. トラブルシューティング：競合が発生したときは
    1. 1. 競合ルールの特定
    2. 2. 拡張機能の優先順位
    3. 3. TypeScriptのバージョン不一致
  9. 2026年のトレンド：Biomeという選択肢
  10. まとめ

TypeScript開発におけるESLintとPrettierの役割分担

設定の細部に入る前に、まず2つのツールの本質的な役割の違いを再確認しておく必要があります。

この役割分担を正しく理解することが、競合を回避するための第一歩となります。

ESLintの役割：コードの「質」を担保する

ESLintは主にコードの論理的な誤りや潜在的なバグ、ベストプラクティスからの逸脱を検知するためのツールです。

TypeScript環境では、型安全性の確保や、未使用変数の防止、非推奨なAPIの使用制限などを担当します。

以前のESLintは「セミコロンの有無」や「インデントの深さ」といったスタイルに関するルールも多く持っていましたが、現在はこれらのフォーマットに関わるルールの多くが非推奨となっており、外部のフォーマッタに任せることが推奨されています。

Prettierの役割：コードの「見た目」を整える

Prettierは、コードの整形（フォーマット）に特化したツールです。

「どこで改行するか」「スペースをいくつ入れるか」といったスタイルに関するルールを強制し、誰が書いても同じ見た目のコードに変換します。

Prettierの最大の特徴は「Opinionated（意見が強い）」であることです。

細かい設定をユーザーに許さない代わりに、決定的なフォーマットを提供し、チーム内での不毛なスタイル論争を終結させます。

比較項目ESLintPrettier
主な目的バグの防止、コード品質の向上コードスタイルの統一
チェック内容未使用変数、Promiseの扱い、型安全インデント、改行、引用符、セミコロン
修正の性質論理的な変更を含む場合がある見た目の変更のみに限定される
TypeScript対応typescript-eslintが必要標準で対応済み

2026年最新の競合回避戦略：フォーマットルールの完全委譲

以前はeslint-plugin-prettierを使用して、Prettierの実行結果をESLintのエラーとして報告させる手法が一般的でした。

しかし、2026年現在の推奨構成は、「ESLintのフォーマットルールを完全に無効化し、整形はPrettierに一任する」というシンプルな形に集約されています。

なぜ「eslint-plugin-prettier」を使わないのか

eslint-plugin-prettierは、ESLintの実行中にPrettierを内部で動かすプラグインです。

これを導入すると、フォーマットの違反も赤い波線でエディタに表示されます。

一見便利に思えますが、以下のデメリットがあります。

  1. パフォーマンスの低下: ESLintの処理が重くなり、エディタのレスポンスが低下する。
  2. ノイズの増加: コードを書いている最中に、スペース一つないだけで大量のエラーが表示され、本質的なロジックの修正に集中できなくなる。
  3. ルールの衝突: ESLintのルールとPrettierが内部で衝突し、無限ループに近い挙動をすることがある。

これらの問題を避けるため、現在は「ESLintはチェックのみ」「整形はエディタの保存時、またはコミット時のPrettier実行に任せる」という分離スタイルが標準となっています。

推奨されるパッケージ構成とインストール

最新のTypeScriptプロジェクト（ESLint v10+ / Prettier v3+）で必要となる基本パッケージをインストールします。

ここでは、パッケージマネージャとして npm を例に説明します。

Shell
# ESLint本体とTypeScript用プラグインのインストール
npm install --save-dev eslint typescript-eslint

# Prettier本体のインストール
npm install --save-dev --save-exact prettier

# 競合回避のための設定用パッケージ
npm install --save-dev eslint-config-prettier

–save-exact オプションを使用して Prettier をインストールしている点に注目してください。

Prettierはバージョンアップによってフォーマットの結果が微妙に変わることがあるため、プロジェクト内でバージョンを固定しておくことが推奨されます。

Prettierの詳細設定（.prettierrc）

Prettierの設定は、プロジェクトのルートディレクトリに .prettierrc というファイルを作成して記述します。

設定項目は最小限に抑えるのがPrettierの哲学ですが、TypeScriptプロジェクトでよく使われる推奨設定は以下の通りです。

JSON
{
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "quoteProps": "as-needed",
  "jsxSingleQuote": false,
  "trailingComma": "all",
  "bracketSpacing": true,
  "arrowParens": "always",
  "endOfLine": "lf"
}

各項目の役割は以下の通りです。

  • printWidth: 1行の最大文字数。TypeScriptは型定義で長くなりがちなため、100程度が適当です。
  • singleQuote: 文字列をシングルクォートに統一します。
  • trailingComma: allに設定することで、関数の引数やオブジェクトの末尾に常にカンマを付与し、Gitの差分を最小限に抑えます。
  • endOfLine: 改行コードをlfに固定し、OS間での挙動の差異を防ぎます。

ESLintの最新設定（eslint.config.js）

2024年以降、ESLintは Flat Config と呼ばれる新しい設定形式が標準となりました。

TypeScriptプロジェクトにおいてPrettierと共存させるための eslint.config.js の記述例を以下に示します。

TypeScript
// @ts-check
import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';
import eslintConfigPrettier from 'eslint-config-prettier';

export default tseslint.config(
  // 基本となるESLintの推奨設定
  eslint.configs.recommended,
  
  // TypeScriptの推奨設定（型情報が必要な場合は strictTypeChecked などを検討）
  ...tseslint.configs.recommended,

  // 個別のルールカスタマイズ
  {
    rules: {
      'no-console': 'warn',
      '@typescript-eslint/no-unused-vars': ['error', { argsIgnorePattern: '^_' }],
    },
  },

  // 重要：Prettierとの競合を回避する設定
  // 最後に配置することで、これまでの設定に含まれるフォーマット関連ルールをすべて無効化する
  eslintConfigPrettier,
);

競合回避の鍵「eslint-config-prettier」

上記のコードで最も重要なのは、最後に読み込んでいる eslintConfigPrettier です。

この設定ファイルは、ESLintが持つ「フォーマットに関連するすべてのルール」をオフにする役割を持ちます。

配列の最後に配置することで、それより前に定義された推奨設定（eslint.configs.recommended など）の中に含まれているスタイル関連のルールを上書きして無効化します。

これにより、「ESLintはロジックのみをチェックし、スタイルについては何も言わない」という理想的な状態が作られます。

エディタ（VS Code）での自動整形設定

ツールを導入しただけでは、手動でコマンドを叩く必要があります。

開発体験を向上させるためには、ファイルの保存時に自動的にPrettierが実行されるようにエディタを設定することが不可欠です。

VS Codeを使用している場合、プロジェクトのルートに .vscode/settings.json を作成し、以下の設定を追加してください。

JSON
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

この設定により、保存時に以下のアクションが自動で行われます。

  1. Prettierによる整形: コード全体のスタイルが整えられます。
  2. ESLintによる修正: 未使用インポートの削除など、ESLintで修正可能なロジックエラーが解決されます。

注意点として、editor.defaultFormatter に必ずPrettierを指定してください。

ESLint拡張機能にもフォーマット機能が含まれていることがありますが、前述の通り「フォーマットはPrettier」という原則を守ることで、設定の競合を完全に防ぐことができます。

Git Hooksによる強制：lint-stagedとhuskyの活用

個人のエディタ設定に依存せず、リポジトリにコミットされるコードが常にフォーマット済みであることを保証するために、Git Hooks を利用するのが一般的です。

必要なツールの導入

husky（Git Hooksを簡単に扱えるツール）と lint-staged（コミット対象のファイルのみに処理を行うツール）を導入します。

Shell
npm install --save-dev husky lint-staged
npx husky init

package.jsonの設定

コミット直前に実行するスクリプトを package.json に記述します。

JSON
{
  "lint-staged": {
    "*.{ts,tsx}": [
      "prettier --write",
      "eslint --fix"
    ],
    "*.{json,md,yml}": [
      "prettier --write"
    ]
  }
}

この構成では、まず prettier --write が走り、その後に eslint --fix が実行されます。

これにより、万が一ESLintの自動修正によってフォーマットが僅かに崩れた場合でも（現代のルール構成では稀ですが）、最終的な品質が担保されます。

トラブルシューティング：競合が発生したときは

もし設定後に「エディタがPrettierとESLintの間で何度もコードを書き換えてしまう」といった現象が発生した場合は、以下の手順で確認を行ってください。

1. 競合ルールの特定

コマンドラインで以下のコマンドを実行し、現在のESLint構成でPrettierと競合しているルールがないかチェックします。

Shell
npx eslint-config-prettier path/to/main.ts

もし競合がある場合、このコマンドが該当するルール名をリストアップしてくれます。

そのルールは eslint.config.js で明示的に無効化するか、eslint-config-prettier が正しく適用されているかを確認する必要があります。

2. 拡張機能の優先順位

VS CodeでESLintとPrettierの両方の拡張機能を入れている場合、どちらがフォーマッタとして動いているかを確認してください。

ステータスバーの「Prettier」にチェックマークが入っているか、または出力パネルの「Log」でエラーが出ていないかを確認します。

3. TypeScriptのバージョン不一致

稀に、プロジェクトで使用しているTypeScriptのバージョンと、ESLintプラグインが内部で参照しているTypeScriptのバージョンが乖離していることで、構文解析エラーが発生し、フォーマットが止まることがあります。

常に typescript-eslint を最新の状態に保つようにしてください。

2026年のトレンド：Biomeという選択肢

最後に、PrettierとESLintの共存というテーマにおける「別の選択肢」についても触れておきます。

2026年現在、Biome というRust製のオールインワンツールが急速に普及しています。

Biomeは「ESLintとPrettierの両方の機能を一つのツールで提供する」ことを目的としており、設定の競合という概念自体が存在しません。

また、実行速度がPrettierよりも圧倒的に速いため、大規模なプロジェクトではBiomeへの移行を選択するチームも増えています。

しかし、エコシステムの広さやプラグインの豊富さ（例：Tailwind CSSのクラス順序整列プラグインなど）においては、依然として ESLint + Prettier の組み合わせに分があります。

既存の資産を活かしつつ、安定した開発環境を構築したい場合は、本記事で紹介した構成が引き続き最も信頼できる選択肢となるでしょう。

まとめ

TypeScriptプロジェクトにおけるESLintとPrettierの共存は、かつては複雑な設定を必要とする難所でした。

しかし、ESLintの進化と eslint-config-prettier によるルールの徹底的な分離により、現在は非常にシンプルで堅牢な構成が可能になっています。

本記事のポイントをまとめると以下の通りです。

  • 役割を完全に分ける：ESLintは論理チェック、Prettierは見た目の整形に専念させる。
  • Flat Configを活用する：最新の eslint.config.js 形式で、設定の透明性を高める。
  • 競合ルールを無効化する：eslint-config-prettier を最後に読み込み、ESLintのスタイルルールをすべてオフにする。
  • 保存時の自動実行を導入する：エディタ設定やGit Hooksを用いて、手動作業を排除する。

これらの設定を正しく行うことで、コードレビューにおいてスタイルに関する指摘をゼロにし、開発者が本質的なロジックの実装に集中できる環境を整えることができます。

技術の進化に合わせて設定を定期的に見直し、常に最適な開発体験を維持していきましょう。