ESLintの「JSON出力」を武器にせよ：CI/CDの向こう側へ至る品質可視化アーキテクチャ
多くのエンジニアがESLintを「CIでエラーが出たら落とすためのゲート」としてしか見ていない。それはあまりにも勿体ない。ESLintの `–format json` は、単なるログ出力ではなく、チームの技術的負債を数値化し、コードの健康状態を時系列で追跡するための「動的な資産」である。
今回は、ESLintの実行結果をRawデータとして抽出し、それを自前のダッシュボードへ流し込み、さらには「負債の偏り」を検知して自動的に改善チケットを切るまでのアーキテクチャを設計する。
—
1. なぜ「標準出力」ではなく「JSON」なのか
CLI上で流れるテキストログは人間が読むためのものであり、機械が解析するにはあまりにも不安定だ。一方、`–format json` はESLintの内部AST（抽象構文木）走査の結果を構造化データとして吐き出す。
このJSONには、単なるルール違反のメッセージだけでなく、以下の情報が含まれる。
- Rule ID: どのルールが最も違反を誘発しているか
- Severity: 警告(1)かエラー(2)か
- Line/Column: コードのどの位置に負債が集中しているか
これを活用すれば、「どのコンポーネントが最も負債を抱えているか」というヒートマップを、CIパイプラインの中で瞬時に生成できる。
—
2. CI/CDパイプラインにおけるデータ抽出の最適化
コンテナ環境でのパフォーマンスを担保するため、ESLintの実行は「差分のみ」あるいは「キャッシュ利用」が基本だが、ダッシュボード用には全量解析が必要になる。ここで、コンテナのメモリ消費を抑えつつ、JSONを効率的に抽出するパイプラインを組む。
.github/workflows/lint-analysis.yml
jobs:
lint-metrics:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: ’20’
cache: ‘npm’ # 依存関係のキャッシュ
- name: Generate Lint JSON
# –cache を有効にしつつ、JSONファイルを生成。
# –output-fileで書き出すことで、標準出力のバッファ溢れを防ぐ
run: |
npx eslint . –format json –output-file ./lint-report.json –max-warnings=-1
continue-on-error: true # JSONを収集したいので終了コードで止めない
- name: Upload Metrics
# ここで自作の集計スクリプトまたはAPIへデータをPOSTする
run: node ./scripts/process-lint-metrics.js ./lint-report.json
—
3. 内部解析：JSONを「意味あるデータ」へ変換する
生成された `lint-report.json` は巨大になりがちだ。これをそのままDBに突っ込むのは愚策である。アーキテクトは、ここで「ルールの重み付け」と「集計」を行う必要がある。
以下は、収集したJSONから「負債スコア」を算出するNode.jsスクリプトの断片だ。
// scripts/process-lint-metrics.js
const fs = require(‘fs’);
const report = JSON.parse(fs.readFileSync(‘./lint-report.json’, ‘utf-8’));
// 負債の集計用オブジェクト
const metrics = {
totalErrors: 0,
ruleFrequency: {},
fileSeverity: {} // ファイルパスごとの違反数
};
report.forEach(file => {
metrics.fileSeverity[file.filePath] = file.messages.length;
file.messages.forEach(msg => {
metrics.totalErrors++;
// ルールごとの発生回数をカウント
metrics.ruleFrequency[msg.ruleId] = (metrics.ruleFrequency[msg.ruleId] || 0) + 1;
});
});
// このmetricsをInfluxDBやGoogle Sheets APIに流し込むことで、
// Grafanaで「チームの品質推移グラフ」が描画できる
console.log(JSON.stringify(metrics, null, 2));
—
4. 現場で震えるほど役立つ「負債検知」の知見
単にエラーを可視化するだけではエンジニアは動かない。私が推奨するのは、「ホットスポット（修正頻度が高いが負債も多いファイル）の自動特定」である。
`git log` の統計結果と、先ほどのESLint JSONの結果をマッピングするのだ。
1. Gitのコミット頻度が高い上位10ファイルを抽出する。
2. ESLint JSON内のエラー数と突き合わせる。
3. 「変更頻度が高いのに、Lintエラーも多いファイル」を「リファクタリング対象」としてSlackのチャンネルに自動通知する。
これにより、「なぜここを直さなければならないのか」という議論が不要になる。データが「今、ここを直すべきだ」と雄弁に語ってくれるからだ。
—
5. パフォーマンスとメモリ管理の極意
ESLintを大規模プロジェクトで回す際、JSON出力を含めてメモリが枯渇することがある。
- `–cache` オプションの徹底: 変更のないファイルは解析させない。これは必須だ。
- ワーカーの制御: `–parallel` を活用しつつ、コンテナのCPUコア数に合わせて `eslint` の並列数を調整する。
- 不要なルールの無効化: CI専用のconfigを用意し、実行に時間がかかる重いルール（型チェックを伴うものなど）は、必要に応じて切り離す。
結論：ツールを「使われる」側から「使いこなす」側へ
ESLintの真の価値は、エラーを指摘することではなく、プロジェクトの「コードの品質傾向」というメタデータを生成し、開発組織の意思決定を支援することにある。
JSONという共通言語を手に入れた今、君たちのパイプラインは単なる「テスト実行環境」ではなく、「ソフトウェアの健全性を測定する観測所」へと進化する。さあ、今すぐビルドログを捨てて、データを収集し、可視化せよ。そこにこそ、真のDevOpsの境地がある。