こんにちは。コードの品質と開発体験（DX）を最大化することに人生を賭けているエンジニアです。
皆さんは、チームでコードレビューをする際、「このライブラリは特定の方法でしか使ってはいけない」「この非推奨メソッドを誤って使わないでほしい」と何度も同じ指摘を繰り返した経験はありませんか？
「ドキュメントに書いているのに…」と嘆くのはもう終わりにしましょう。ESLintのカスタムルールさえあれば、コンピュータがあなたの代わりにそれを監視し、誤用を瞬時に検知してくれます。
今回は、単なる設定ファイルのコピペを超えて、あなたのプロジェクトの「守護神」となるカスタムルールの作り方を解説します。
—
1. なぜ「設定」ではなく「ルール作成」なのか
ESLintやPrettierの標準ルールは、コードのフォーマットや一般的なバグを未然に防ぐためのものです。しかし、「ビジネス上の制約」や「複雑な社内ライブラリの正しい使い方」は、外部のプラグインには存在しません。
これをカスタムルール化することで、以下のメリットが生まれます。
- レビューの自動化: 人間は「コードの意図」や「ビジネスロジック」に集中でき、表記ゆれや禁止事項の指摘から解放される。
- オンボーディングの短縮: 新人が間違った使い方をしても、IDEがその場で警告してくれるため、自律的に正しい書き方を学習できる。
- 負債の蓄積をゼロにする: 修正すべき技術的負債が、コードを書く瞬間に可視化される。
—
2. 準備：AST（抽象構文木）という名の「地図」を読み解く
カスタムルールを作るということは、ESLintに「コードの構造を理解させる」ということです。ここで登場するのがAST（Abstract Syntax Tree）です。
ESLintは、ソースコードを解析して「これは関数定義」「これは変数代入」といったツリー状のデータ構造に変換します。私たちはこのツリーを歩き回り、「特定のパターンに合致したらエラーを出す」というプログラムを書くのです。
まずは、[AST Explorer](https://astexplorer.net/) を開いてみてください。
右側のパネルで `JavaScript` を選択し、適当なコード（例: `const x = 1;`）を入力すると、左側にそのコードがどのような構造になっているかが表示されます。この「構造」こそが、ルールを作るための鍵になります。
—
3. 実践：禁止事項を強制するルールを作ってみよう
今回は、「`console.log` は絶対に許さない（代わりに専用のLoggerを使ってほしい）」というルールを例に作成します。
プロジェクト構成
ルートディレクトリに `eslint-rules` フォルダを作成し、その中にルール本体を配置します。
/my-project
├── .eslintrc.json
└── eslint-rules
└── no-console-log.js <-- 今回作成するルール
ルール本体の実装: `eslint-rules/no-console-log.js`
module.exports = {
meta: {
type: ‘problem’,
docs: { description: ‘console.logの使用を禁止し、専用Loggerの使用を強制する’ },
fixable: null, // 自動修正を有効にするなら ‘code’
},
create(context) {
return {
// ASTの「MemberExpression（メンバアクセス）」を監視する
MemberExpression(node) {
// console.log を検知する条件式
if (
node.object.name === ‘console’ &&
node.property.name === ‘log’
) {
// 条件に一致したら警告を報告
context.report({
node,
message: ‘console.logは禁止です。代わりに my-logger を使用してください。’,
});
}
}
};
}
};
—
4. ESLintにルールを認識させる
作成したルールを有効化するために、`.eslintrc.json` を編集します。
{
“plugins”: [“local-rules”],
“rules”: {
// フォルダ内のルールを読み込んで適用
“local-rules/no-console-log”: “error”
}
}
※ 本格的な開発では、`eslint-plugin-local-rules` を導入してローカルルールを読み込む設定を行うのが一般的です。
—
5. 精度高い「HelloWorld」の動作確認
ルールが正しく動作しているか確認するために、意図的に違反コードを書いたファイルを用意します。
test.js:
console.log(“これは怒られるはずです”);
次に、ターミナルで実行します。
npx eslint test.js
実行結果（想定）:
/path/to/test.js
1:1 error console.logは禁止です。代わりに my-logger を使用してください。 local-rules/no-console-log
どうでしょうか？ あなたが設定したルールが、プロジェクトの門番として完璧に機能しました。
—
最後に：ここから先へ
このルール作成の面白さは、「チームの集合知を自動化できる」点にあります。
- ステップアップ: `context.getSourceCode().getScope()` を使って、特定の関数内でのみ許可するルールを作る。
- 効率化: `fixer` 関数を実装し、禁止された書き方を自動で推奨コードに置換するようにする。
最初は難しく感じるかもしれませんが、AST Explorerを触りながら「このノードの型は何だろう？」と探求するプロセスは、間違いなくあなたの技術力を一段上のステージへ押し上げます。
「コードレビューで同じことを言いたくない」と思ったら、迷わずカスタムルールを書いてください。それが、プロフェッショナルなDevOpsエンジニアの第一歩です。
皆さんのプロジェクトが、よりクリーンで、より堅牢なものになることを心から応援しています！