TypeScript ESLint設定の最適解：Flat Config対応と実用的な推奨ルール解説

2026年5月5日2026年5月8日

静的解析・リンター

TypeScriptを用いたモダンなフロントエンド開発において、コードの品質と一貫性を維持するためにESLintは欠かせない存在です。

2024年後半から2025年にかけて標準となったFlat Config（フラットコンフィグ）は、2026年現在の開発現場において完全に定着しました。

かつての複雑な extends や plugins の依存関係から解放され、より直感的で柔軟な設定が可能になった一方で、新しい記法への戸惑いを感じているエンジニアも少なくありません。

本記事では、最新の typescript-eslint を活用した最適解となる設定方法を、具体的なコード例とともに解説します。

目次 [ close ]

TypeScriptとESLintの現状（2026年版）

2026年現在、TypeScriptの静的解析エコシステムは大きな転換点を過ぎ、非常に成熟した状態にあります。

以前の .eslintrc.js 形式（Legacy Config）は非推奨となり、すべての新規プロジェクトは eslint.config.js もしくは eslint.config.mjs を使用する Flat Config への移行が完了しています。

TypeScript本体の進化に伴い、型情報を利用したリント（Type-Checked Linting）のパフォーマンスも劇的に向上しました。

typescript-eslint バージョン8以降で導入された Project Service 機能により、従来のような煩雑な tsconfig.json のパス指定を最小限に抑えつつ、IDEの動作を妨げない高速な解析が可能になっています。

現在のTypeScript開発においてESLintに求められる役割は、単なる構文エラーの検知だけではありません。

チーム全体のコーディング規約を強制し、実行時のバグを未然に防ぐ強力なガードレールとしての機能が期待されています。

ESLint Flat Configの基本構造

Flat Configは、設定を「配列」として定義するのが最大の特徴です。

各要素が特定のファイル形式やディレクトリに対する設定オブジェクトとなっており、上から下へと評価される仕組みになっています。

設定ファイルの基本構成

基本的な eslint.config.mjs の構造は以下のようになります。

TypeScript

// @ts-check
import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  // 全ファイルに適用される無視設定
  {
    ignores: ['dist/**', 'node_modules/**', 'coverage/**'],
  },
  // 基本となる推奨ルール
  eslint.configs.recommended,
  // TypeScript向けの推奨ルール（型情報を利用しないもの）
  ...tseslint.configs.recommended,
  // 特定のファイルに対する個別設定
  {
    files: ['**/*.ts', '**/*.tsx'],
    rules: {
      'no-console': 'warn',
      '@typescript-eslint/no-unused-vars': 'error',
    },
  },
);

この新しい形式では、従来の extends キーワードによる複雑なネスト構造がなくなり、どのルールがどの順番で適用されているかが一目瞭然になりました。

tseslint.config() ヘルパー関数を使用することで、TypeScriptの型補完を受けながら設定ファイルを記述できる点も大きなメリットです。

推奨される基本設定の手順

最新の環境でTypeScript ESLintを導入するための手順を整理します。

必要なパッケージのインストール

まずは、コアとなるパッケージをインストールします。

2026年時点では、個別のプラグインを細かく入れるよりも、typescript-eslint が提供する統合パッケージを利用するのが一般的です。

Shell

npm install --save-dev eslint typescript-eslint

最小構成の設定ファイル作成

プロジェクトのルートに eslint.config.mjs を作成し、以下の内容を記述します。

TypeScript

import tseslint from 'typescript-eslint';
import js from '@eslint/js';

export default tseslint.config(
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    languageOptions: {
      parserOptions: {
        // 2026年推奨のProject Serviceを利用した設定
        projectService: true,
        tsconfigRootDir: import.meta.dirname,
      },
    },
  },
);

この設定により、標準的なJavaScriptのルールと、TypeScript向けの基本的なルールが適用されます。

projectService: true を指定することで、個別の tsconfig.json を手動で列挙する必要がなくなります。

プロジェクトを強固にする推奨ルールセット

ESLintを導入する真の目的は、コードの堅牢性を高めることにあります。

typescript-eslint には、用途に応じた複数のプリセットが用意されています。

プリセット名	推奨度	概要
`recommended`	高	広く一般的に推奨される基本的なルールセット
`strict`	最高	型の安全性を最大限に高める厳格なルールセット
`stylistic`	中	コードの書き方の好みに焦点を当てたルールセット

型情報を活用したルール（Type-Checked Rules）の重要性

TypeScriptのESLint設定において、最も価値があるのが型情報を利用したルールです。

これらは「変数にどのような型が入っているか」をリンターが理解した上でチェックを行います。

例えば、以下のルールは型情報があって初めて機能します。

@typescript-eslint/no-floating-promises: Promiseを返す関数を呼び出す際、await や catch を忘れている場合に警告します。
@typescript-eslint/restrict-template-expressions: テンプレートリテラル ${} 内に、意図しないオブジェクトや型を埋め込むのを防ぎます。

これらを有効にするには、strictTypeChecked プリセットを使用するのが最適解です。

TypeScript

export default tseslint.config(
  ...tseslint.configs.strictTypeChecked,
  ...tseslint.configs.stylisticTypeChecked,
  {
    rules: {
      // プロジェクト固有のルール調整
      '@typescript-eslint/no-explicit-any': 'error', // anyの使用を禁止
    },
  },
);

開発効率を高める実用的なカスタマイズ

標準のルールセットだけでは、開発現場の細かなニーズに応えられないことがあります。

ここでは、生産性を向上させるための具体的なカスタマイズ例を紹介します。

未使用変数の厳格な管理

未使用の変数はコードの可読性を下げ、バグの温床になります。

しかし、関数の引数などで意図的に残したい場合もあります。

TypeScript

{
  rules: {
    '@typescript-eslint/no-unused-vars': [
      'error',
      { 
        argsIgnorePattern: '^_', // 引数名の先頭がアンダースコアなら許容
        varsIgnorePattern: '^_',
        caughtErrorsIgnorePattern: '^_'
      }
    ],
  }
}

import順序の自動整理

大規模なプロジェクトでは、ファイルの先頭にある import 文が乱雑になりがちです。

これを自動で整列させるために eslint-plugin-import-x（従来の import プラグインのFlat Config対応版）を導入します。

TypeScript

import importPlugin from 'eslint-plugin-import-x';

export default tseslint.config({
  plugins: {
    'import-x': importPlugin,
  },
  rules: {
    'import-x/order': [
      'error',
      {
        groups: ['builtin', 'external', 'internal', 'parent', 'sibling', 'index'],
        'newlines-between': 'always',
        alphabetize: { order: 'asc', caseInsensitive: true },
      },
    ],
  },
});

Prettierとの共存

コードフォーマッターであるPrettierとESLintを併用する場合、ルールの衝突を避ける必要があります。

以前は eslint-plugin-prettier を使う手法もありましたが、2026年現在は 「ESLintは論理チェック、Prettierは整形」 と役割を明確に分けるのがベストプラクティスです。

そのためには、eslint-config-prettier を使用して、Prettierと競合するESLintのルールを無効化します。

TypeScript

import eslintConfigPrettier from 'eslint-config-prettier';

export default tseslint.config(
  // 他の設定...
  eslintConfigPrettier, // 必ず配列の最後に配置する
);

モノレポや大規模プロジェクトでの最適化

現代のWeb開発では、複数のパッケージを一つのリポジトリで管理するモノレポ構成（Turbo, Nxなど）が一般的です。

Flat Configは、ディレクトリ構造に合わせた設定の適用を非常に得意としています。

ディレクトリごとの設定上書き

例えば、apps/web ディレクトリにはReact向けのルールを適用し、packages/api にはNode.js向けのルールを適用したい場合、以下のように記述できます。

TypeScript

export default tseslint.config(
  {
    files: ['apps/web/**/*.ts'],
    // React向けの設定
    extends: [tseslint.configs.recommendedTypeChecked],
    rules: { /* React固有のルール */ }
  },
  {
    files: ['packages/api/**/*.ts'],
    // APIサーバー向けの設定
    rules: { /* Node.js固有のルール */ }
  }
);

このように、files プロパティを活用することで、プロジェクト全体で一つの設定ファイル（Root Config）を持ちつつ、各サブプロジェクトに最適な制約を課すことができます。

トラブルシューティングとよくある課題

設定を高度にするほど、予期せぬエラーに遭遇することがあります。

特によくある課題とその対策をまとめました。

型情報が見つからないエラー

Parsing error: ESLint was configured to run with modules, but... というエラーが出る場合、多くは tsconfig.json の範囲外のファイルをリントしようとしていることが原因です。

解決策1: eslint.config.mjs 自体をリント対象から外すか、ignores に追加する。
解決策2: projectService の allowDefaultProject オプションを使用する。

ビルド速度への影響

型チェックを含むリントは、通常の構文チェックよりもCPUリソースを消費します。

CI/CDパイプラインでの実行時間を短縮するためには、キャッシュの活用が不可欠です。

Shell

# キャッシュを有効にして実行
eslint . --cache --cache-location .eslintcache

また、2026年のモダンな開発環境では、「変更されたファイルのみをリントする」 設定をCIに組み込むことで、フィードバックループを高速化させています。

まとめ

TypeScriptにおけるESLintの設定は、Flat Configの登場と typescript-eslint の進化により、かつてないほど強力かつ柔軟になりました。

「型情報を武器にする」という方針を軸に、strictTypeChecked などの厳格なルールセットを採用することは、長期的なメンテナンスコストの削減に直結します。

最後に、2026年におけるESLint設定のポイントを振り返ります。

Flat Configへの完全移行: 配列ベースの直感的な設定ファイルを活用する。
Project Serviceの利用: 型情報を利用したリントを低コストで導入する。
ルールの段階的な強化: recommended から始め、プロジェクトの成熟度に合わせて strict へ移行する。
ツール間の役割分担: ESLintは「論理」、Prettierは「見た目」と切り分け、eslint-config-prettier で衝突を防ぐ。

高品質なコードは、適切なツール設定から生まれます。

本記事で紹介した構成をベースに、各プロジェクトの特性に合わせたカスタマイズを行い、快適なTypeScript開発環境を構築してください。