ESLint v9「Flat Config」完全移行ガイド：静的解析の未来をあなたの手に
こんにちは。開発環境の設計を長年追い求めてきた身として、今日はお話ししたいことがあります。
長らくJS/TS開発者の頭を悩ませてきた「`.eslintrc`地獄」。プラグインの競合、複雑な継承（`extends`）、そして「なぜか動かない」という黒魔術的な設定に、心当たりはありませんか？
ESLint v9で導入されたFlat Config (`eslint.config.js`) は、単なる設定ファイルの変更ではありません。ESLintという巨大なアーキテクチャが、ようやく「設定の矛盾」という負債を清算し、モダンなJavaScriptのモジュールシステム（ESM）と調和した瞬間なのです。
これをマスターすれば、あなたのプロジェクトから「設定の謎解き」が消え、コーディングという本来の創造活動に集中できる時間が劇的に増えます。さあ、モダンな静的解析の世界へ足を踏み入れましょう。
—
1. なぜ「Flat Config」なのか？：設計思想の転換
これまでの`.eslintrc`は、ファイルが階層構造（ディレクトリごとに設定をマージする仕組み）を持っており、設定が深く重なると「最終的にどのルールが適用されているのか」を特定するのが困難でした。
Flat Configの核心は「単一の配列」です。
`eslint.config.js`という一つのファイルに、オブジェクトの配列として設定を記述します。これにより、以下のメリットが生まれます。
- 明示的な解決: 設定が上から順に評価されるため、「後から書いたものが勝つ」という直感的なルールで動きます。
- ESMの完全採用: `require`ではなく`import`が使えます。Node.jsのエコシステムと完全に同期しています。
- 競合の排除: `extends`による隠れた設定の継承がなくなり、すべての設定が可視化されます。
—
2. 移行への準備：まずは「敵」を知る
移行を成功させる鍵は、急がないことです。以下のステップで進めれば、開発を止めることはありません。
ステップ1: プラグインの互換性確認
Flat Configでは、プラグインの読み込み方が変わります。
- 旧: `plugins: [‘react’]` (eslint-plugin-react)
- 新: `import react from ‘eslint-plugin-react’;` して、オブジェクトとして渡す。
まずは現在の依存関係を確認しましょう。
現在のESLintのバージョンを確認（9.xであることを確認）
npx eslint –version
プラグインがv9のFlat Configに対応しているか確認
基本的に、主要なプラグイン（typescript-eslintなど）は既にv8から対応済みです
—
3. 実践：`eslint.config.js` の構築
ここでは、TypeScriptプロジェクトを想定した「最強のベース」を紹介します。これさえあれば、ほとんどのプロジェクトはカバーできます。
// eslint.config.js
import js from “@eslint/js”; // ESLintの推奨ルールセット
import tseslint from “typescript-eslint”; // TS用の強力なプラグイン
export default tseslint.config(
// 1. 基本設定を適用
js.configs.recommended,
// 2. TypeScript用のルールを適用
…tseslint.configs.recommended,
// 3. プロジェクト固有のカスタマイズ
{
ignores: [“dist/”, “node_modules/”, “coverage/”], // 除外設定
rules: {
// 個別のルールをここで微調整
“no-console”: “warn”,
“@typescript-eslint/no-unused-vars”: “error”,
},
}
);
なぜこの書き方なのか？
`tseslint.config`関数を使うことで、TypeScript特有の型情報に基づいた解析を安全に有効化できます。`…`（スプレッド構文）で配列を展開している点に注目してください。これが「Flat（平坦）」であることの証明です。
—
4. Prettierとの「平和な」共存術
かつては`eslint-config-prettier`で競合を抑え込むのが一般的でしたが、Flat Config時代にはさらにスマートな方法があります。
「Prettierは整形のみ、ESLintは静的解析のみ」 という役割分担を徹底させるのです。
設定のヒント
`.eslintrc`時代のような「eslint-plugin-prettier（ESLint内でPrettierを実行するプラグイン）」は、現在では非推奨です。VSCodeの拡張機能（Prettier ESLint）に任せるか、`lint-staged`での実行に切り替えるのが、現代的なアーキテクトの選択です。
—
5. 動作確認：HelloWorld的アプローチ
設定が終わったら、正しく動いているか確認しましょう。
1. 意図的なエラーを作る:
あえてルールに違反するコードを書いてください（例：`const a = 1;` と書き、使わずに放置する）。
2. コマンド実行:
npx eslint .
3. 結果の分析:
もし期待通りに `no-unused-vars` のエラーが出れば成功です。もしエラーが出ない場合は、`eslint.config.js` の `files` フィールドで対象パス（例: `files: [“/.ts”]`）が正しく指定されているか確認してください。
—
最後に：アーキテクトからのアドバイス
Flat Configへの移行は、最初は少し勇気がいるかもしれません。しかし、これによって得られる「設定の透明性」は、中長期的な開発体験を劇的に向上させます。
「なぜか動かない」という時間をゼロに近づけること。それが、私たちがツールを正しく理解し、設計する意味です。
まずは小さなプロジェクトや実験用リポジトリから、この新しい設定を試してみてください。もし設定で迷うことがあれば、いつでもあなたのコードはあなたに語りかけてくれます。Flat Configの構造を見れば、答えはそこに必ず書いてあるはずです。
あなたのビルドログに「エラーなし」の緑色の文字が並ぶことを祈っています。頑張ってくださいね！