1. 導入：コードレビューの消耗を「仕組み」で解決する
開発チームで「この古いライブラリを使わないで」「特定のAPIを直接叩かないで」といった指摘を、何度もレビューで行った経験はありませんか？ 人間の記憶や注意に頼る運用には限界があり、指摘する側もされる側も疲弊してしまいます。
これらをESLintの独自ルールとして定義することで、コードレビューのコストを削減し、チームの「暗黙知」を「システム的な強制力」へと昇華できます。本記事では、プロジェクト固有の禁止事項を静的解析で自動検知する手法を解説します。
2. 基礎知識：AST（抽象構文木）とは
ESLintの独自ルールを作成するには、AST（Abstract Syntax Tree）の理解が不可欠です。ASTとは、プログラムのソースコードを解析して、構文構造をツリー状のデータ構造に変換したものです。
例えば `const a = 1;` というコードは、「変数宣言（VariableDeclaration）」「識別子（Identifier）」「リテラル（Literal）」といったノードに分解されます。ESLintはソースコードをこの木構造として読み込み、特定のノードパターンを検知することでルールを適用します。
3. 実装：独自ルールの作成手順
独自ルールの作成には「generator-eslint」などのツールを使うのが一般的です。以下のステップで進めます。
1. ESLintプラグインのプロジェクトを作成する。
2. ルールを定義する（rule.js）。
3. テストを記述し、意図通りに検知されるか確認する。
4. `eslint-plugin-local-rules` などを用いて、プロジェクト内にローカルルールとして組み込む。
4. サンプルプログラム：特定のライブラリ使用を禁止するルール
例えば、「古いライブラリ ‘old-lib’ を import してはいけない」というルールを実装する場合のサンプルコードです。
// rules/no-old-lib.js
module.exports = {
create(context) {
return {
// ImportDeclarationノード（import文）を走査する
ImportDeclaration(node) {
// import元のソースが ‘old-lib’ であるか確認
if (node.source.value === ‘old-lib’) {
context.report({
node,
// 指摘メッセージの内容
message: “古いライブラリ ‘old-lib’ の使用は禁止です。社内共通ライブラリ ‘new-lib’ を使用してください。”,
// 自動修正案がある場合はここに記述
fix(fixer) {
return fixer.replaceText(node.source, “‘new-lib'”);
}
});
}
}
};
}
};
5. 応用・注意点：現場で陥りやすい罠
独自ルールを運用する際は、以下の点に注意してください。
・過剰なルール化の弊害
あまりに細かいルールを乱立させると、CIの通過が困難になり、開発体験（DX）を著しく低下させます。「頻出する重大なミス」に絞って導入するのが賢明です。
・AST探索の精度
`AST Explorer` というWebサイトを使うと、書いたコードがどのようなAST構造になるかを視覚的に確認できます。ルールを書く前に、対象のコードパターンがどう見えるかを確認してから実装に入るのが、手戻りを防ぐコツです。
・自動修正（Fixer）の慎重な実装
自動修正機能は強力ですが、意図しない破壊的変更を招くリスクがあります。最初は「警告（warn）」で周知し、ルールが定着してから「エラー（error）」に引き上げる、あるいは自動修正を有効にするといった段階的なアプローチを推奨します。
「指摘しなくても良い環境」を作ることは、シニアエンジニアの重要な責務です。ぜひ、チームのコードベースに眠る「暗黙のルール」をコード化してみてください。