ESLintとは？VSCodeでの設定からflat config・Prettier連携まで解説【ESLint v10対応】

ESLint（イーエスリント）は、JavaScriptとTypeScriptのコードを実行せずに検査し、バグの原因やスタイルの崩れを指摘する静的解析ツールです。読み方や役割といった基礎から、実務でつまずきやすいVSCodeでの設定、そして2026年2月リリースのESLint v10で設定形式がどう変わったかまでを、最新仕様にそろえて解説します。設定ファイルが.eslintrcのまま止まっている記事も多いため、現行のflat config（eslint.config.js）を前提に進めます。

まとめ：ESLintの要点とVSCode設定の最短手順

ESLintはJavaScript/TypeScript向けの静的解析ツールで、コードを動かす前に未使用変数・未定義参照・記述ミスなどを検出します。2026年2月のESLint v10で旧来の.eslintrc設定は完全に廃止され、設定はeslint.config.js（flat config）に一本化されました。導入はnpm init @eslint/config@latestで対話的にeslint.config.jsを生成し、npx eslint .で実行します。VSCodeでは拡張機能「ESLint」を入れ、settings.jsonに保存時自動修正を1行加えるだけで、エディタ上にエラーが表示され保存時に自動修正が走ります。コード整形はESLintではなくPrettierに任せ、両者の競合はeslint-config-prettierで無効化するのが現行の定石です。以下、定義・設定・VSCode連携・Prettier/TypeScript連携の順に具体的な手順を示します。

ESLintとは？読み方・「lint」の意味と静的解析ツールとしての役割

ESLintは「イーエスリント」と読みます。ESはECMAScript（JavaScriptの仕様）、lintは「コードのほつれ（問題箇所）を取り除く」という意味の言葉です。lintという呼び名は、1978年にベル研究所のStephen C. Johnsonが作ったC言語向けの検査プログラム「lint」に由来し、衣類から出る糸くず（lint）をその比喩としています。ESLint自体は2013年にNicholas C. Zakasが開発し、現在はOpenJS Foundation配下のオープンソースとして開発が続いています。

ESLintはコードを実行せずに解析する点が特徴です。プログラムを動かして調べるテストとは異なり、ソースコードの構文木（AST）を読み取って問題を指摘します。このアプローチ全般の考え方は静的解析とは何かを整理した記事で詳しく扱っています。

ESLintが検出する問題（静的解析でわかること）

ESLintが指摘するのは、大きく「バグにつながる記述」と「スタイルの一貫性」の2種類です。前者は未使用の変数（no-unused-vars）、未定義の変数参照（no-undef）、到達しないコード、誤った比較などで、実行前にバグの芽を摘めます。後者はインデントや引用符の統一といった見た目の規約です。ルールは"error"（エラー）・"warn"（警告）・"off"（無効）の3段階で個別に設定でき、チームの方針に合わせて厳しさを調整します。なお、見た目の整形そのものは後述のPrettierに任せ、ESLintはバグ検出に集中させる構成が主流です。

ESLint v10で設定はこう変わった（eslintrc廃止・flat configへ一本化）

ESLintの設定は近年で大きく変わりました。.eslintrc.jsや.eslintrc.jsonといった旧形式（eslintrc）の解説で止まっている情報を参考にすると、最新版では動かないため注意が必要です。要点は次の3点です。

ESLint v9.0.0（2024年4月）でflat config（eslint.config.js）が既定の設定形式になり、続くESLint v10.0.0（2026年2月6日）でeslintrc設定システムが完全に削除されました。v10では.eslintrc.*や.eslintignoreはもう読み込まれず、--envや--no-eslintrcといったCLIオプションも廃止されています。これから設定するなら旧形式を学ぶ必要はなく、flat configだけを押さえれば十分です。v10の動作要件はNode.js ^20.19.0 || ^22.13.0 || >=24で、古いNodeでは動きません。

flat configは「設定オブジェクトの配列」を1ファイルで書く形式です。eslintrc時代のextends文字列の積み重ねや暗黙の設定探索がなくなり、どの設定がどのファイルに効くかをコードとして明示します。バージョン仕様は変動するため、最新の対応Nodeバージョンは公式リリースノートで確認してください。

ESLintのインストールと初期設定（npm init @eslint/config）

ESLintはnpm経由で各プロジェクトに導入します。グローバルインストールは推奨されておらず、プロジェクトごとに開発依存として入れるのが基本です。

前提：Node.jsの準備

先にNode.jsとnpmが入っていることを確認します。ESLint v10はNode.js 20.19以上（または22.13以上、24以上）を要求するため、node -vでのバージョン確認が前提です。プロジェクト直下にpackage.jsonが無ければnpm init -yで作成しておきます。

対話セットアップで eslint.config.js を生成する

初期化は次のコマンド1つで行います。質問に答えると、用途（JavaScript/TypeScript、ブラウザ/Node、使用フレームワークなど）に合わせたeslint.config.jsが自動生成され、必要なパッケージも一緒にインストールされます。

npm init @eslint/config@latest

旧来のnpx eslint --initに相当する手順ですが、現在はこのnpm init @eslint/configが公式の入口です。生成後はそのまま実行できる状態になります。

eslint.config.js の最小構成例

手書きで用意する場合の最小構成は次のとおりです。@eslint/jsの推奨ルールを土台に、必要なルールだけ上書きします。

// eslint.config.js
import js from "@eslint/js";
import { defineConfig } from "eslint/config";

export default defineConfig([
  {
    files: ["**/*.{js,mjs,cjs}"],
    plugins: { js },
    extends: ["js/recommended"],
    rules: {
      "no-unused-vars": "warn",
      "no-undef": "error",
    },
  },
]);

filesで対象ファイルのパターンを指定し、extendsで推奨ルールセットを読み込み、rulesで個別調整する、という3層構造です。extendsには"js/recommended"のような文字列でも、後述のTypeScript例のようにjs.configs.recommended（オブジェクト参照）でも指定できます。どちらも公式に有効な書き方です。除外したいフォルダがある場合は、配列の先頭にglobalIgnores(["dist/"])を加えます（globalIgnoresはeslint/configからインポート）。

ESLintコマンドの実行と自動修正（CLI）

設定ができたら、プロジェクト直下でファイルやディレクトリを指定して実行します。次のコマンドはカレント以下をすべて検査します。

npx eslint .

ESLintには自動修正機能があり、--fixを付けると、機械的に直せる違反（引用符・セミコロン・並び順など）をその場で修正します。

npx eslint . --fix

毎回コマンドを打つ代わりに、package.jsonのscriptsに登録しておくとチームで共有しやすくなります。CIにnpm run lintを組み込めば、修正漏れのコードがマージされるのを防げます。

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix"
  }
}

VSCodeでESLintを設定する手順（flat config対応）

ESLintはCLIだけでも使えますが、実務での価値はエディタ連携にあります。VSCodeに組み込むと、コードを書いている最中に問題箇所へ波線が表示され、保存と同時に自動修正が走ります。ここがGSC上でも検索の多い「eslint vscode」「vscode eslint 設定」の領域です。

ESLint拡張機能のインストール

VSCodeの拡張機能ビューで「ESLint」を検索し、発行元がMicrosoft（識別子dbaeumer.vscode-eslint）の拡張をインストールします。拡張はあくまでプロジェクトにインストールされたESLint本体を呼び出す仕組みなので、前章までのeslint.config.jsがプロジェクトに用意されていることが前提です。拡張だけ入れても設定ファイルが無ければ動きません。

保存時に自動修正する設定（settings.json）

保存時の自動修正は、VSCodeのsettings.jsonに次を追加します。source.fixAll.eslintの値は、以前のようなtrueではなく現在は"explicit"を指定します（明示的な保存操作のときだけ修正を走らせる、という意味です）。整形はPrettierに任せる前提で、Prettier拡張（esbenp.prettier-vscode）も併せて導入し、既定フォーマッタに指定しておきます。

{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true
}

これで、保存のたびにESLintが直せる違反を修正し、Prettierが整形をかけます。

flat configにVSCode側の追加設定は要るか

かつてはflat configを読ませるためにeslint.useFlatConfigという設定が必要でしたが、これはESLint拡張v3.0.10より前のバージョンの話です。現行の拡張はeslint.config.jsがあれば自動でflat configとして認識するため、追加設定は不要です。ESLint v10ではflat configに固定され、eslint.useFlatConfigという設定自体が無視されます。同様に、どの言語を検査するかを手動指定していたeslint.validateも、flat configのfilesで対象を決めるため通常は書く必要がありません。設定の二重管理を避ける意味でも、検査対象はeslint.config.js側に寄せるのが妥当です。

VSCodeでESLintが効かないときの確認点

波線が出ない・自動修正が動かないときは、次の順で切り分けます。まずVSCode下部の出力パネルで「ESLint」チャネルを開き、エラーログを確認します。多いのは、プロジェクトにESLint本体やeslint.config.jsが無いケース、対象ファイルがfilesのパターンから外れているケース、Nodeのバージョンが要件を満たしていないケースです。設定変更後に反映されないときは、コマンドパレットの「ESLint: Restart ESLint Server」でサーバーを再起動すると解決することがあります。

ESLintとPrettierの違いと併用設定

ESLintとPrettierは役割が異なります。ESLintは「コードの正しさ（バグ・規約違反）」を検査するツール、Prettierは「コードの見た目（整形）」を統一するツールです。両者の守備範囲が一部重なるため、何も調整しないと整形ルールが衝突します。Prettier側の役割や設定はPrettierの基本をまとめた記事に詳しく、ここではESLintとの併用に絞ります。

現行の定石は、整形はPrettierに一任し、ESLint側の整形系ルールをeslint-config-prettierで無効化する方式です。まずパッケージを入れます。

npm install --save-dev prettier eslint-config-prettier

flat configではeslint-config-prettier/flatを読み込み、競合し得る整形ルールを最後にまとめて無効化します。設定配列の末尾に置くのがポイントで、これで前段のルールを上書きできます。

// eslint.config.js
import js from "@eslint/js";
import { defineConfig } from "eslint/config";
import eslintConfigPrettier from "eslint-config-prettier/flat";

export default defineConfig([
  { files: ["**/*.{js,mjs,cjs}"], plugins: { js }, extends: ["js/recommended"] },
  eslintConfigPrettier,
]);

なお、PrettierをESLintのルールとして走らせるeslint-plugin-prettierという別の方式もありますが、ESLintの実行が遅くなり、整形差分がリント警告として大量に出て読みにくくなるため、現在は推奨されていません。ESLintとPrettierは別々に動かし、責務を分けるのが扱いやすい構成です。

TypeScriptプロジェクトでのESLint（typescript-eslint）

TypeScriptを検査するには、専用パッケージtypescript-eslintを使います。これはTypeScriptの構文をESLintに解釈させるパーサーと、型を意識した推奨ルールをまとめて提供するもので、TypeScript対応のlintはこれが標準です。

npm install --save-dev eslint @eslint/js typescript typescript-eslint

flat configでは、JavaScript向けの推奨設定とTypeScript向けの推奨設定をextendsに並べます。設定ファイル名はeslint.config.mjsでも.jsでも構いません。

// eslint.config.mjs
import js from "@eslint/js";
import { defineConfig } from "eslint/config";
import tseslint from "typescript-eslint";

export default defineConfig([
  {
    files: ["**/*.{js,ts}"],
    extends: [js.configs.recommended, tseslint.configs.recommended],
  },
]);

より厳密に型情報を使ったルール（tseslint.configs.recommendedTypeCheckedなど）も用意されていますが、まずはrecommendedから始め、必要に応じて段階的に強めるのが現実的です。なお、かつてTypeScript向けに使われていたTSLintは2019年に開発が終了しており、現在はこのtypescript-eslintへの移行が前提です。

よくある質問（FAQ）

設定ファイルは .eslintrc.js のままでも動きますか？

ESLint v10（2026年2月リリース）以降は動きません。v10でeslintrc設定システムが完全に削除され、.eslintrc.*や.eslintignoreは読み込まれなくなりました。eslint.config.js（flat config）への移行が必須です。v9系も2026年8月6日でサポートが終了するため、新規・既存いずれもflat configへ寄せるのが安全です。

TSLintとESLintはどう違いますか？

TSLintはかつてのTypeScript専用リンターですが、2019年に開発が終了し、機能はESLint側のtypescript-eslintに統合されました。現在はTypeScriptでもESLintを使うのが標準で、TSLintを新規採用する理由はありません。

ESLintはJavaScript・TypeScript以外でも使えますか？

ESLintの本体はJavaScript／TypeScriptが対象です。公式プラグインによりJSONやMarkdownの検査にも対応していますが、JavaやPython、PHPなど別言語のコードは対象外で、それぞれ専用のリンター（Javaならcheckstyle、PythonならRuffやflake8など）を使います。

ESLintの設定でおすすめの構成は？

多くのプロジェクトで通用する出発点は、@eslint/jsの推奨ルールを土台に、TypeScriptならtypescript-eslintの推奨を重ね、整形はeslint-config-prettierでPrettierに委譲する構成です。最初から大量のルールを盛らず、推奨セットで始めてチームの不満点だけ調整するほうが運用が安定します。

ESLintのスキルは実務・案件で求められますか？

JavaScript／TypeScriptを扱うフロントエンド・Node.jsの開発現場では、ESLintはほぼ標準のツールです。コード規約の自動チェックやCIでの品質ゲートとして組み込まれていることが多く、設定ファイルを読み書きできること、Prettierとの併用を構成できることは実務で評価される基礎スキルです。あわせて、CodeSenseiについても解説しています。

関連記事

• 静的解析とは何か？ソースコードを実行せずに品質を確保する手法
• Prettierとは何か？開発者にとっての重要性を解説
• JSON形式とは？基本構造・データ型・書き方の基礎からTypeScriptでの扱い方まで
• VSCodeでMermaidを使ったシーケンス図の作成方法と自動コード生成