ESLintカスタムルール：プロジェクトの「暗黙知」を「静的解析」で物理的に強要するアーキテクチャ
多くの現場で、ESLintは単なる「コードフォーマッターの補助」や「`no-console`を弾くためだけのツール」として消費されている。しかし、真に卓越したDevOpsエンジニアにとって、ESLintは「プロジェクトの品質を担保する自律的なガバナンス・エンジン」である。
今回は、単なる設定ファイルの書き換えではない。AST（抽象構文木）を操作し、プロジェクト固有の「技術的負債」をコンパイルタイムで遮断する、カスタムルールの深淵を解説する。
—
1. なぜ「既存ルール」だけでは不十分なのか？
大規模開発において、ドキュメントに「このライブラリは直接インポートせず、ラッパー経由で使ってください」と書いても、エンジニアは必ず違反する。なぜなら、「人間はミスをする生き物だから」だ。
自動化の極致を目指すなら、ルールは「規約」ではなく「物理法則」に変える必要がある。ASTを解析し、特定の関数呼び出しやモジュール依存をコンパイル時に検知するカスタムルールこそが、CI/CDにおいて「品質をゲートする」唯一無二の手段となる。
—
2. ASTの深淵：ESLintカスタムルールの心臓部
ESLintのカスタムルールは、ソースコードを解析して生成されたASTをトラバース（巡回）し、特定のノードパターンにマッチした際にエラーを投げるプラグインである。
まずは、最も基本的な「特定のメソッド呼び出しを禁止する」ルールの実装例を見てほしい。
実装例：危険なレガシー関数 `oldInternalApi()` の封印
`eslint-plugin-local-rules` を活用し、ローカルで完結するルールを定義する。
// eslint-rules/no-old-api.js
module.exports = {
meta: {
type: “problem”,
docs: { description: “禁止されたレガシーAPIの排除” },
fixable: “code”, // 自動修正を可能にする場合は記述
},
create(context) {
return {
// ASTノード ‘CallExpression’ を監視
CallExpression(node) {
// calleeがIdentifierで、名前が ‘oldInternalApi’ であるか判定
if (node.callee.type === ‘Identifier’ && node.callee.name === ‘oldInternalApi’) {
context.report({
node,
message: “警告: oldInternalApiは廃止されました。代わりに `newApiV2` を利用してください。”,
});
}
}
};
}
};
このコードの肝は `context.report` にある。ここで報告されたメッセージは、ただIDEに表示されるだけではない。CIの終了ステータスを非ゼロで終了させるトリガーとなり、デプロイパイプラインを物理的に停止させる。
—
3. パフォーマンスを極限まで引き上げるアーキテクチャ
ESLintのパフォーマンス問題は、主に「重いルール」と「ルールの無駄な重複実行」に起因する。
内部ハック：メモリ消費を抑えるVisitorの最適化
ASTを全探索する際、`CallExpression` のように頻出するノードに対して複雑な条件判定を行うと、解析コストが指数関数的に増大する。
- Visitorの絞り込み: 必要なノードタイプ以外には一切触れない。
- キャッシュの活用: `context.getFilename()` 等を使ってファイル単位の判定をキャッシュし、不要な計算を避ける。
- ワーカースレッドの検討: `eslint` の `–parallel` モードを活用するが、カスタムルールが同期処理をブロックしていないかプロファイリングすることが必須だ。
パフォーマンスボトルネックの特定（ESLintの標準機能）
TIMING=1 npx eslint . –format node_modules/eslint-formatter-table
このコマンドを叩けば、どのルールが何ミリ秒消費しているかが一目瞭然になる。上位に位置する独自ルールは、アルゴリズムの再考対象である。
—
4. CI/CDパイプラインとの高度な連携
ルールを書いて終わりではない。「どの環境で、誰のコミットでルール違反が発生したか」を可視化するパイプラインこそがDevOpsの真骨頂である。
GitHub Actionsでのゲートキーパー設定
単にエラーを出すだけでなく、違反を修正するコードを自動生成してPRにコメントするワークフローを構築せよ。
.github/workflows/lint.yml
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Lint
# –fix オプションをCIで実行し、修正済みコードをコミットバックする戦略
run: |
npm run lint:fix
# 差分があればGitでコミット＆プッシュ、あるいはPRをガードする
—
5. 伝説的アーキテクトからの提言：チームへ導入するステップ
カスタムルールは、以下の3段階で導入せよ。
1. 検知モード: `severity: “warn”` でルールを適用し、既存コードの違反箇所をレポートに蓄積する。
2. 修正期間: 開発者に修正を促し、徐々に違反をゼロにする。
3. 強制モード: `severity: “error”` に昇格させ、CIを落とす。これにより、「今日以降、このバグは二度と発生しない」という絶対的な信頼をコードベースに刻み込む。
結論
ESLintのカスタムルール作成は、単なるコードチェックではない。それは、あなたのプロジェクトの「設計思想」をコードとして実装し、未来の自分たちを束縛から解放する「自動防衛システム」の構築に他ならない。
ASTという低レイヤの武器を手に取り、IDEの波形の中に、あなただけの「規律」を埋め込んでほしい。それが真のエンジニアリングというものだ。