ESLint

tool development beginner

JavaScriptのコードを静的に解析し、潜在的なバグや推奨されない書き方を検知できるリンター。

概要（サマリー）

ESLint（エスリント）とは、JavaScriptで書かれたコードを実行する前にチェックし、書き方の間違いやバグの原因となる記述を自動で見つけ出してくれる「静的コード解析ツール（リンター）」である。
設定やプラグインを追加すれば、TypeScriptやReactなどのプロジェクトでも利用できる。たとえば、プログラム内で定義したのに一度も使っていない変数があったり、宣言していない変数を勝手に使おうとしていたりすると、実行前に警告やエラーとして教えてくれる。
たとえるなら、ESLintはコードを書き進める中で、「ここにスペルミスがあるよ」「この書き方をすると後でエラーになる可能性があるよ」とリアルタイムで赤線や黄色の波線を引いて教えてくれる「校正用のルーペ（チェッカー）」である。
これにより、実行する前に一部のバグに気づいて修正することができ、バグの少ない開発を進めやすくなる。

詳細解説

リンター（Linter）としてのESLintの役割

プログラミングにおける「静的解析（Static Analysis）」とは、コードを実際に実行することなく、テキストデータをスキャンして分析する技術のことである。ESLintはこの仕組みを利用し、主に以下の3つの観点でコードを検査する。

構文エラー（シンタックスエラー）の防止:
括弧の閉じ忘れや、文法的に間違っている記述など、プログラムが動かない初歩的かつ致命的なミスを検知する。
潜在的なバグの検知:
- const で宣言した変数に値を再代入しようとしている。
- 条件分岐（if）の中で常に真（true）になるような不自然なロジックが書かれている。
- 宣言していない変数や、使われていない変数が残っている。
コード品質の維持と記述ルールの統一:
非推奨の古い記述方法（例：var の使用など）の使用を禁止したり、プロジェクト内で一貫した記述ルールを強制したりする。

ESLintの設定ファイル（eslint.config.js）

ESLintの検査ルールは、プロジェクトのルートディレクトリにある設定ファイルで細かく指定できる。現在のESLintでは、Flat Configと呼ばれる eslint.config.js が標準的な設定形式になっている。

export default [
  {
    rules: {
      "no-unused-vars": "error", // 使われていない変数の存在をエラーにする
      "no-console": "warn",      // console.log の記述に対して警告（黄色線）を出す
      "eqeqeq": "error"          // 等価演算子に「===」の使用を強制する（「==」はエラー）
    }
  }
];

"error": ルール違反を赤いエラーとして扱う。ビルドやコミット前チェックに組み込んでいる場合は、処理を止める条件にもなる。
"warn": 黄色い警告として扱い、修正を促すがプログラムの実行自体は許可する。

TypeScriptで使う場合

ESLint本体はJavaScript向けのツールだが、TypeScriptプロジェクトでは typescript-eslint を組み合わせて使うことが多い。
TypeScriptは型チェック、ESLintはコード品質や書き方のルールチェックを担当する、と分けて考えるとわかりやすい。たとえば、型そのものの不一致はTypeScript側で検出し、未使用変数やプロジェクト独自の禁止ルールはESLint側で検出する、という役割分担になる。

package.jsonやCI/CDとの連携

ESLintはエディタ上の赤線だけでなく、コマンドとしても実行できる。
多くのプロジェクトでは、package.json に lint スクリプトを用意し、npm run lint のような形でチェックを実行する。さらにCI/CDやコミット前フックに組み込むと、問題のあるコードが共有リポジトリに入る前に止められる。

AIコーディングとの関係

AIが書いたコードの品質担保とデバッグの削減

AIを使ってコードを生成させると、AIが古いライブラリの書き方を提案したり、未定義の変数を記述したり、スコープを無視した危険な変数の再代入を行ったりすることがある。
この時、プロジェクトにESLintを導入しておくと、AIが出力したコードの「どこに問題があるか」をエディタ上で即座に赤線で確認できるため、バグを未然に防ぎやすい。
また、エラー内容をそのままAIに渡して「ESLintでこのエラーが出たので修正して」と指示を出すと、原因の説明や修正案を得やすい。AIの提案をそのまま信じるのではなく、再度ESLintとテストを通して確認することが重要である。

指示を出す際のポイント

AIにESLintの設定やバグ修正を依頼する際は、以下のように指示するとよい。

「Viteで作ったReactプロジェクトにESLintを設定したい。おすすめのルール設定と必要なパッケージのインストールコマンドを教えて」
「次のJavaScriptコードをESLintに通したところ、no-undef のエラーが出た。原因と修正方法を教えて（ここにコードを貼る）」

よくある勘違い

ESLintを入れればコードスタイル（見た目）の統一も完璧？

ESLintはコードスタイルの統一も一部可能だが、現在は「バグになりやすい書き方やプロジェクトルールの検知」に寄せて使うことが多い。
インデントのスペース数や改行の位置、セミコロンの有無といった「コードの見た目（コードフォーマット）」の自動整形は、Prettier というフォーマッターに任せるのが一般的である。
通常は、見た目はPrettierに任せ、文法やバグチェックはESLintに任せるという役割分担を行い、二つが衝突しないように連携設定（eslint-config-prettier など）を導入する。

エディタの拡張機能（VS Codeなど）を入れれば、プロジェクトにESLintのインストールは不要？

エディタの拡張機能（ESLint）は、プロジェクト内にインストールされているESLintを実行して画面に波線を引くための「仲介役」に過ぎない。
そのため、プロジェクトのフォルダ（node_modules）自体にESLintがインストールされていなかったり、設定ファイルが置いていなかったりすると、エディタの拡張機能だけでは期待通りに動かないことがある。まずはプロジェクトごとにパッケージマネージャーを使ってツールをインストールする必要がある。

ESLintのエラーがあると、プログラムは1行も動かなくなる？

ESLintは「コードのチェックツール」であり、コンパイラではないため、ESLintがどれだけ大量のエラーを吐いていても、プログラム自体を無理やり実行させることは可能である。
ただし、ESLintのエラーを放置したまま本番環境に公開したり、チームの共有リポジトリにプッシュしたりすると、本番環境で予期せぬ不具合につながる可能性がある。そのため、リリース前や共有前にはESLintエラーを解消する運用にしておくのが安全である。

まとめ

ESLintは、JavaScript/TypeScriptコードの構文エラーやバグ、品質の悪化を未然に防ぐ静的解析ツールである。
未定義の変数の使用や、未使用変数、非推奨の書き方などを実行前に検知しやすくする。
チーム内で一貫した書き方のルールを強制し、コードの品質を高い水準で均一に保つことができる。
AIコーディング時にAIが生成したコードを検証するフィルターとして有効に機能する。

情報ソース

より詳しくAIに聞いてみよう

VS CodeでESLint拡張機能を導入し、ファイルを保存した際に自動でESLintの自動修復機能（eslint --fix）を走らせるための設定を教えてください。
TypeScriptプロジェクトにESLintを導入する際、JavaScript向けルールと組み合わせるための「@typescript-eslint/parser」などの設定方法を説明してください。
開発チームで一般的に使われている、GoogleやAirbnbが公開しているESLintの共有設定ルール（推奨スタイルガイド）の導入方法について教えてください。
ESLintの最新の設定システム「Flat Config（フラットコンフィグ）」と、従来の .eslintrc による設定方法の決定的な違いと移行手順を教えてください。
AIに「ESLintのエラーを検知して自動でGitプッシュを拒否するコミット前フック（Pre-commit hook）」の作り方を解説してもらいましょう。