ESLint を導入する際、多くの開発者が最初に直面するのがルールの重要度設定です。error、warn、off の 3 つの重要度レベルを適切に使い分けることで、開発効率を大幅に向上させることができます。

本記事では、ESLint の重要度設定における基本概念から実践的な活用方法まで、段階的に解説いたします。適切な設定により、コード品質の向上と開発体験の最適化を両立できる戦略をお伝えします。

背景

ESLint 重要度設定の基本概念

ESLint では、各ルールに対して 3 つの重要度レベルを設定することができます。

javascriptCopy code// .eslintrc.js での設定例
module.exports = {
  rules: {
    'no-unused-vars': 'error', // エラーレベル
    'prefer-const': 'warn', // 警告レベル
    'no-console': 'off', // 無効化
  },
};

それぞれの重要度レベルには明確な役割があります。

重要度	数値	動作	用途
error	2	ビルドを停止	必ず修正すべき重要なルール
warn	1	警告を表示	改善推奨だが開発を阻害しないルール
off	0	ルールを無効	プロジェクトに適用しないルール

この基本的な仕組みを理解することで、プロジェクトの性質に応じた最適な設定を行えるようになります。

開発チームにおけるルール統一の必要性

多人数での開発において、コーディングスタイルの統一は非常に重要です。ESLint の重要度設定は、単なるルールの有効・無効の切り替えではなく、チーム全体の開発方針を表現する手段となります。

統一された重要度設定がもたらすメリットは以下の通りです：

• コードレビューの効率化: 基本的なスタイル違反が事前に排除される
• 新メンバーの学習コスト削減: 明確なルールにより迷いが減る
• 継続的な品質向上: 段階的なルール強化により品質が向上する

以下の図は、ESLint 重要度設定によるコード品質管理のフローを示しています：

mermaidCopy codeflowchart TD
    code[コード記述] --> lint[ESLint 実行]
    lint --> error{error ルール違反?}
    error -->|Yes| build_fail[ビルド失敗]
    error -->|No| warn{warn ルール違反?}
    warn -->|Yes| warning[警告表示]
    warn -->|No| success[ビルド成功]
    warning --> success
    build_fail --> fix[修正必須]
    fix --> code

この仕組みにより、重要な品質基準は確実に維持しつつ、改善可能な部分は段階的に対応できる環境が整います。

重要度設定が開発フローに与える影響

重要度設定は開発フローの各段階に大きな影響を与えます。適切な設定により、開発者の生産性を向上させつつ、コード品質を確保できます。

開発フローにおける各段階での影響を整理すると以下のようになります：

フェーズ	error の影響	warn の影響	開発体験への効果
コーディング	即座にエラー表示	黄色の波線で警告	問題の早期発見
ビルド	ビルド停止	警告メッセージ表示	品質チェックの自動化
コミット	フックで阻止可能	メッセージ表示のみ	段階的な品質向上
デプロイ	CI/CD で停止	ログに記録	本番品質の保証

課題

過度に厳しいルール設定による開発阻害

多くのプロジェクトで見られる問題の一つが、初期設定時に過度に厳しいルールを error レベルで設定してしまうことです。

典型的な問題例：

javascriptCopy code// 過度に厳しい設定例
module.exports = {
  rules: {
    'no-console': 'error', // デバッグ時に困る
    'prefer-const': 'error', // 既存コードで大量エラー
    'no-unused-vars': 'error', // 開発中の変数でビルド停止
    indent: ['error', 2], // フォーマッター設定と競合
    quotes: ['error', 'single'], // 既存コードとの不整合
  },
};

このような設定は以下の問題を引き起こします：

• 開発速度の大幅な低下: 些細なルール違反でビルドが頻繁に停止
• 開発者のストレス増加: 本質的でない修正に時間を取られる
• eslint-disable の乱用: ルールを回避する一時的な対処が増加
• チーム内の不満: 過度な制約による開発体験の悪化

緩すぎる設定によるコード品質低下

逆に、開発の利便性を優先しすぎて、重要なルールまで warn や off にしてしまう問題もあります。

問題となる緩い設定例：

javascriptCopy code// 緩すぎる設定例
module.exports = {
  rules: {
    'no-unused-vars': 'warn', // 不要な変数が残る
    'no-undef': 'warn', // 未定義変数の使用を見逃す
    'no-unreachable': 'warn', // 到達不能コードを放置
    'no-duplicate-keys': 'off', // 重複キーによるバグリスク
    'no-redeclare': 'off', // 変数の重複宣言を許可
  },
};

これらの設定は以下のリスクを生み出します：

• 潜在的なバグの見落とし: 警告レベルでは見逃されがち
• 技術的負債の蓄積: 問題のあるコードが長期間放置される
• コードレビューの負担増加: ツールで検出できる問題も手動確認が必要
• 新人教育への悪影響: 悪いコーディング習慣が身につく可能性

チーム内での設定基準の不統一

プロジェクトが成長する過程で、異なる開発者が異なる基準でルールを追加・変更することにより、設定の一貫性が失われることがあります。

mermaidCopy codeflowchart LR
    dev1[開発者A] -->|厳格派| config1[error 重視設定]
    dev2[開発者B] -->|実用派| config2[warn 中心設定]
    dev3[開発者C] -->|緩和派| config3[off 多用設定]
    config1 --> conflict[設定の衝突]
    config2 --> conflict
    config3 --> conflict
    conflict --> confusion[チーム内混乱]

不統一による具体的な問題：

• 設定変更の頻発: 開発者ごとに設定を変更する事態
• コードレビューでの議論紛糾: ルール適用の基準が曖昧
• 新規参入者の困惑: どの設定が正しいか判断できない
• CI/CD での不整合: 環境によって異なる結果

解決策

error の適用基準と戦略

error レベルは、絶対に守らなければならないルールに適用します。明確な基準を設けることで、適切な運用が可能になります。

error レベル適用の基準

以下の条件を満たすルールを error レベルに設定することを推奨します：

基準	説明	具体例
バグの原因となる	実行時エラーや予期しない動作の原因	no-undef, no-unreachable
セキュリティリスク	脆弱性につながる可能性	no-eval, no-implied-eval
パフォーマンス重大影響	性能に深刻な影響を与える	no-constant-condition
チーム合意の必須事項	全員が守ると約束したルール	no-debugger, no-console

推奨 error 設定例

javascriptCopy code// 基本的な error レベルルール
module.exports = {
  rules: {
    // バグ防止関連（最重要）
    'no-undef': 'error', // 未定義変数の使用を禁止
    'no-unused-vars': 'error', // 使用されない変数を禁止
    'no-unreachable': 'error', // 到達不能コードを禁止
    'no-duplicate-keys': 'error', // オブジェクトの重複キーを禁止

    // セキュリティ関連
    'no-eval': 'error', // eval の使用を禁止
    'no-implied-eval': 'error', // 暗黙的な eval を禁止

    // 本番環境での問題防止
    'no-debugger': 'error', // debugger 文を禁止
    'no-alert': 'error', // alert の使用を禁止（本番では不適切）
  },
};

warn の効果的な活用方法

warn レベルは、コード品質向上のための改善提案として活用します。開発を阻害せずに、段階的な改善を促進できます。

warn レベル活用戦略

warn レベルの効果的な活用方法：

• 段階的品質向上: 既存コードに影響を与えずに新しい基準を導入
• ベストプラクティスの促進: 推奨される書き方への誘導
• 学習機会の提供: 警告を通じてより良い書き方を学習
• 将来の error 化の準備: 段階的に重要度を上げる準備期間

javascriptCopy code// warn レベルの効果的な設定例
module.exports = {
  rules: {
    // ベストプラクティス推奨
    'prefer-const': 'warn', // const の使用を推奨
    'no-var': 'warn', // var の代わりに let/const を推奨
    'prefer-arrow-callback': 'warn', // アロー関数の使用を推奨

    // 可読性向上
    'object-shorthand': 'warn', // オブジェクトの短縮記法を推奨
    'prefer-destructuring': 'warn', // 分割代入の使用を推奨

    // 将来の error 化候補
    'no-console': 'warn', // 本番前に error に格上げ予定
    'no-unused-expressions': 'warn', // 副作用のない式を警告
  },
};

warn から error への段階的移行

warn レベルで導入したルールを段階的に error レベルに移行する戦略：

mermaidCopy codesequenceDiagram
    participant Dev as 開発者
    participant ESLint as ESLint
    participant Team as チーム

    Dev->>ESLint: warn ルール導入
    ESLint->>Dev: 警告表示（ビルドは継続）
    Dev->>Team: 警告対応の実施
    Team->>Team: チーム内での対応完了確認
    Team->>ESLint: error レベルに格上げ
    ESLint->>Dev: エラーレベルで強制

off にすべきルールの判断基準

すべてのルールが全てのプロジェクトに適用できるわけではありません。プロジェクトの特性に応じて、適切に off にすべきルールを判断することが重要です。

off 設定の判断基準

判断基準	説明	判断例
プロジェクト特性と不適合	技術スタック特有の要件と競合	React での react​/​prop-types
他ツールとの重複	フォーマッターや他のツールで対応済み	indent, quotes
パフォーマンス要件	大規模コードベースでの実行コスト	重い解析を行うルール
チーム方針との不一致	開発方針と合わない制約	no-console (デバッグ重視の場合)

適切な off 設定例

javascriptCopy code// プロジェクト特性に応じた off 設定
module.exports = {
  rules: {
    // TypeScript 使用時は型チェックで代替可能
    'no-unused-vars': 'off', // @typescript-eslint/no-unused-vars を使用
    'no-undef': 'off', // TypeScript で型チェック済み

    // Prettier 使用時はフォーマット系を無効化
    indent: 'off', // Prettier で自動整形
    quotes: 'off', // Prettier で統一
    semi: 'off', // Prettier で統一

    // React プロジェクトでの特殊事情
    'react/prop-types': 'off', // TypeScript で型定義済み
    'react/react-in-jsx-scope': 'off', // React 17+ では不要

    // 開発効率を優先する場合
    'no-console': 'off', // デバッグログを許可
  },
};

プロジェクト段階に応じた設定変更

プロジェクトの成長段階に応じて、ESLint の重要度設定を調整することで、適切なコード品質管理を実現できます。

プロジェクトライフサイクル別設定戦略

mermaidCopy codestateDiagram-v2
    [*] --> 開発初期
    開発初期 --> 開発中期
    開発中期 --> 本番準備
    本番準備 --> 運用保守

    開発初期 : warn 中心設定\n迅速な開発を優先
    開発中期 : error 比率増加\n安定性を重視
    本番準備 : 厳格な error 設定\n品質確保を最優先
    運用保守 : バランス調整\n保守性と品質の両立

各段階での推奨設定：

開発初期段階（プロトタイプ・MVP）

javascriptCopy code// 開発初期: 迅速な開発を優先
module.exports = {
  rules: {
    // 最低限の error（バグ防止のみ）
    'no-undef': 'error',
    'no-unused-vars': 'error',
    'no-unreachable': 'error',

    // 多くのルールを warn で導入
    'prefer-const': 'warn',
    'no-console': 'warn',
    'no-debugger': 'warn',

    // スタイル系は基本的に off
    indent: 'off',
    quotes: 'off',
  },
};

開発中期段階（機能開発・拡張）

javascriptCopy code// 開発中期: 段階的な品質向上
module.exports = {
  rules: {
    // error ルールを拡張
    'no-undef': 'error',
    'no-unused-vars': 'error',
    'no-unreachable': 'error',
    'prefer-const': 'error', // warn から格上げ
    'no-var': 'error', // 新規追加

    // warn ルールの充実
    'no-console': 'warn',
    'object-shorthand': 'warn',
    'prefer-destructuring': 'warn',

    // 一部スタイルルールを warn で導入
    quotes: ['warn', 'single'],
  },
};

具体例

新規プロジェクトでの初期設定例

新規プロジェクトでは、将来の拡張性を考慮した設定を行うことが重要です。段階的に厳格化できる設定構造を最初から組み込みましょう。

TypeScript + React プロジェクトの推奨初期設定

javascriptCopy code// .eslintrc.js - 新規プロジェクト初期設定
module.exports = {
  env: {
    browser: true,
    es2021: true,
    node: true,
  },
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
    'plugin:react/recommended',
    'plugin:react-hooks/recommended',
  ],
  parser: '@typescript-eslint/parser',
  parserOptions: {
    ecmaFeatures: {
      jsx: true,
    },
    ecmaVersion: 12,
    sourceType: 'module',
  },
  plugins: ['react', '@typescript-eslint', 'react-hooks'],
  rules: {
    // === 必須エラールール（品質保証） ===
    'no-undef': 'error',
    'no-unused-vars': 'off', // TypeScript版を使用
    '@typescript-eslint/no-unused-vars': 'error',
    'no-unreachable': 'error',
    'no-duplicate-keys': 'error',
    'no-redeclare': 'error',

    // === セキュリティ関連エラー ===
    'no-eval': 'error',
    'no-implied-eval': 'error',
    'no-new-func': 'error',

    // === React 特有のエラー ===
    'react-hooks/rules-of-hooks': 'error',
    'react-hooks/exhaustive-deps': 'error',

    // === 品質向上警告ルール ===
    'prefer-const': 'warn',
    'no-var': 'warn',
    'object-shorthand': 'warn',
    'prefer-arrow-callback': 'warn',

    // === 開発効率重視で無効化 ===
    'no-console': 'off', // 開発初期はデバッグ優先
    'no-debugger': 'warn', // 本番前に error 化予定

    // === Prettier 使用のため無効化 ===
    indent: 'off',
    quotes: 'off',
    semi: 'off',

    // === TypeScript 使用のため無効化 ===
    'react/prop-types': 'off',
    'react/react-in-jsx-scope': 'off', // React 17+
  },
  settings: {
    react: {
      version: 'detect',
    },
  },
};

段階的厳格化のためのコメント付き設定

javascriptCopy code// ルール段階化計画をコメントで明記
module.exports = {
  rules: {
    // Phase 1: 開発初期（現在）
    'prefer-const': 'warn', // Phase 2 で error 化予定
    'no-console': 'off', // Phase 3 で warn → error
    'no-debugger': 'warn', // Phase 2 で error 化予定

    // Phase 2: 機能開発完了後（3ヶ月後目安）
    // 'prefer-const': 'error',
    // 'no-debugger': 'error',
    // 'object-shorthand': 'warn', // 新規追加予定

    // Phase 3: 本番リリース前（6ヶ月後目安）
    // 'no-console': 'error',
    // 'complexity': ['warn', 10],  // 新規追加予定
  },
};

レガシープロジェクトでの段階的改善

既存のプロジェクトでは、現在のコードベースに大きな影響を与えずに段階的に改善していく戦略が必要です。

現状分析から始める改善アプローチ

まずは現在のコードベースでの ESLint 実行結果を分析します：

bashCopy code# 現状のルール違反状況を分析
npx eslint . --format=json > eslint-report.json

# 違反件数の多いルールを確認
npx eslint . --format=compact | grep -o '\[.*\]' | sort | uniq -c | sort -nr

分析結果に基づいた段階的設定例：

javascriptCopy code// レガシープロジェクト: 段階1（導入期）
module.exports = {
  rules: {
    // 既存コードに影響しない最小限の error
    'no-undef': 'error', // 比較的違反が少ない
    'no-unreachable': 'error', // 明らかなバグ防止

    // 大量違反があるルールは warn から開始
    'no-unused-vars': 'warn', // 500件の違反があるため
    'prefer-const': 'warn', // 1000件以上の違反
    'no-var': 'warn', // 大量の var 使用あり

    // 重大な問題となりうるルールも warn から
    'no-console': 'warn', // 200件程度の console.log
    'no-debugger': 'warn', // 10件程度の debugger
  },
};

月次での段階的強化スケジュール

mermaidCopy codegantt
    title レガシープロジェクト ESLint 改善スケジュール
    dateFormat  YYYY-MM-DD
    section Phase 1: 基盤整備
    現状分析・設定導入       :done, analysis, 2024-01-01, 2024-01-15
    基本ルール warn 適用     :done, basic-warn, 2024-01-15, 2024-01-31

    section Phase 2: 段階的強化
    no-unused-vars 対応     :active, unused-vars, 2024-02-01, 2024-02-28
    prefer-const 対応       :prefer-const, 2024-03-01, 2024-03-31
    no-var 対応             :no-var, 2024-04-01, 2024-04-30

    section Phase 3: 品質確保
    no-console error化      :console, 2024-05-01, 2024-05-15
    no-debugger error化     :debugger, 2024-05-15, 2024-05-31
    最終品質チェック         :final-check, 2024-06-01, 2024-06-15

チーム規模別の設定戦略

チームの規模や経験レベルに応じて、適切な ESLint 設定戦略を選択することが重要です。

小規模チーム（2-5 人）の設定戦略

小規模チームでは柔軟性と開発速度を重視した設定が適しています：

javascriptCopy code// 小規模チーム向け設定
module.exports = {
  rules: {
    // 必須エラー（最小限）
    'no-undef': 'error',
    'no-unused-vars': 'error',
    'no-unreachable': 'error',

    // 柔軟な警告設定
    'prefer-const': 'warn',
    'no-console': 'warn', // 開発中は許容
    'no-debugger': 'warn', // デバッグ時は許容

    // スタイルは基本的に Prettier に委ねる
    indent: 'off',
    quotes: 'off',
    semi: 'off',

    // チーム判断で必要に応じて調整
    complexity: 'off', // 複雑度チェックは後回し
    'max-lines': 'off', // ファイルサイズ制限なし
  },
};

中規模チーム（6-15 人）の設定戦略

中規模チームでは統一性とコードレビュー効率化を重視：

javascriptCopy code// 中規模チーム向け設定
module.exports = {
  rules: {
    // 厳格なエラー設定
    'no-undef': 'error',
    'no-unused-vars': 'error',
    'no-unreachable': 'error',
    'prefer-const': 'error', // 統一性重視
    'no-var': 'error', // 現代的な書き方を強制

    // コードレビュー効率化のための警告
    complexity: ['warn', 15], // 複雑度制限
    'max-lines-per-function': ['warn', 50], // 関数サイズ制限
    'no-console': 'warn', // 本番前チェック用

    // チーム学習促進
    'prefer-destructuring': 'warn',
    'object-shorthand': 'warn',
    'prefer-arrow-callback': 'warn',
  },
};

大規模チーム（16 人以上）の設定戦略

大規模チームでは品質保証と保守性を最優先：

javascriptCopy code// 大規模チーム向け設定
module.exports = {
  rules: {
    // 非常に厳格なエラー設定
    'no-undef': 'error',
    'no-unused-vars': 'error',
    'no-unreachable': 'error',
    'prefer-const': 'error',
    'no-var': 'error',
    'no-console': 'error', // 本番品質を重視
    'no-debugger': 'error',

    // 保守性重視の制限
    complexity: ['error', 10], // 複雑度を厳格に制限
    'max-lines-per-function': ['error', 30], // 小さな関数を強制
    'max-depth': ['error', 3], // ネスト深度制限
    'max-params': ['error', 4], // パラメータ数制限

    // 統一性の強制
    'prefer-destructuring': 'error',
    'object-shorthand': 'error',
    'prefer-arrow-callback': 'error',

    // ドキュメント化の促進
    'valid-jsdoc': 'warn', // JSDoc の品質チェック
    'require-jsdoc': 'warn', // 公開関数にはドキュメント必須
  },
};

チーム規模別の運用方針表

チーム規模	重要度設定方針	主な考慮事項	推奨アプローチ
小規模 (2-5 人)	柔軟性重視	開発速度、個人の裁量	warn 中心、段階的導入
中規模 (6-15 人)	バランス重視	統一性、レビュー効率	error と warn の使い分け
大規模 (16 人以上)	品質重視	保守性、新人教育	厳格な error 設定

まとめ

ESLint の重要度設定（error・warn・off）は、単なる技術的な設定ではなく、チーム全体の開発方針を表現する重要な要素です。

適切な使い分けのポイントを再度整理いたします：

重要度設定の基本原則

• error: バグの原因となる、セキュリティリスクがある、チーム合意の必須事項
• warn: ベストプラクティスの促進、将来の error 化候補、学習機会の提供
• off: プロジェクト特性と不適合、他ツールとの重複、パフォーマンス要件による除外

成功への 3 つのステップ

1. 現状分析: プロジェクトの特性とチームの状況を正しく把握する
2. 段階的導入: 一度にすべてを変更せず、計画的に品質を向上させる
3. 継続的改善: プロジェクトの成長に合わせて設定を調整し続ける

長期的な品質向上戦略

ESLint の重要度設定は、コード品質向上の手段であり目的ではありません。チーム全体の開発体験を向上させ、持続可能な開発環境を構築するために活用しましょう。

適切な設定により、開発効率とコード品質の両立が実現でき、チーム全体の技術力向上にもつながります。ぜひ、皆さんのプロジェクトでも段階的に導入を進めてみてください。

関連リンク

• ESLint 公式ドキュメント - 全ルールの詳細説明
• TypeScript ESLint ルール - TypeScript 専用ルール
• ESLint 設定ガイド - 設定ファイルの詳細
• Prettier との連携設定 - フォーマッターとの併用方法
• ESLint Shareable Configs - 共有設定の作成方法