なぜ、あなたのチームのコードは「レビューの海」で溺れるのか？
こんにちは。開発環境の深淵を覗き込み、開発生産性を最大化することに人生を賭けているエンジニアです。
Javaでの業務システム開発、避けて通れないのが「コードレビュー」です。しかし、レビューで指摘する内容の8割は「命名規則の不一致」「特定のDIコンテナの誤用」「非推奨メソッドの利用」といった、本来は機械が判断できるはずの些細な指摘ではありませんか？
標準のCheckstyleやPMDで満足していては、真の開発生産性は手に入りません。IntelliJ IDEAの強みは、単なるテキストエディタではなく、コードの「抽象構文木（AST）」をリアルタイムで解釈している点にあります。
今回は、IntelliJ Platform SDKを使い、あなたのプロジェクトの「暗黙の了解」を「機械的に強制するルール」へと昇華させる、カスタムインスペクション作成の第一歩を伝授します。
—
1. インスペクションとは何か？：IDEの「専属レビュー官」を雇う
IntelliJのインスペクション（検査）とは、IDEがコンパイル前に行う静的解析エンジンのことです。通常は「未使用の変数」や「非効率なループ」を指摘しますが、これを拡張することで、「弊社独自のサービス層では、必ず`@Transactional`を付与せよ」といったビジネスロジックに近い要件を、コーディング中に警告として表示させることが可能になります。
なぜこれが必要なのか？
1. レビューの質的向上: 人間は「設計の意図」を議論する時間が増え、機械的なミスを指摘する必要がなくなる。
2. 教育コストの低下: 新人が入っても、IDEが「その書き方はダメだよ」とリアルタイムで教えてくれる。
3. 技術的負債の発生源を断つ: 不適切なパターンの混入をビルド前（＝エディタ上）で阻止できる。
—
2. 準備：最強のツールチェーンを構築する
IntelliJのプラグイン開発は、Gradleをベースとした「IntelliJ Platform Plugin Template」を使うのが現代の常識です。
最低限のセットアップ
まずは、[IntelliJ Platform Plugin Template](https://github.com/JetBrains/intellij-platform-plugin-template) をGitHubからクローン、あるいは「Use this template」ボタンでリポジトリを作成してください。
この環境には、以下のコンポーネントが最初から内包されています。
- Gradle: 依存関係とビルドの管理
- PsiViewer: これが最も重要。コードがどのような構造（AST）でIDEに認識されているかを可視化するプラグインです。
—
3. HelloWorld：特定のメソッド呼び出しを禁止する
今回は、「特定のレガシーなログ出力メソッドを禁止し、自作のロガーへ誘導する」というルールを実装してみましょう。
手順①：PsiViewerで対象の構造を解析する
IDE上で `Tools > View PSI Structure of Current File` を開きます。
`System.out.println` と書いた箇所をクリックしてください。右側のウィンドウに `PsiMethodCallExpression` や `PsiReferenceExpression` といった階層構造が表示されます。これこそが、IDEがコードをどう理解しているかの正体です。
手順②：カスタムインスペクションの実装
`LocalInspectionTool` クラスを継承して、ルールを記述します。
// 禁止事項: System.out.println を検知するルール
public class ProhibitSystemOutInspection extends AbstractBaseJavaLocalInspectionTool {
@Override
public @NotNull PsiElementVisitor buildVisitor(@NotNull ProblemsHolder holder, boolean isOnTheFly) {
return new JavaElementVisitor() {
@Override
public void visitMethodCallExpression(PsiMethodCallExpression expression) {
super.visitMethodCallExpression(expression);
// メソッド名が println かどうかを判定
if (“println”.equals(expression.getMethodExpression().getReferenceName())) {
// System クラスのメソッド呼び出しであるかを確認
if (expression.getMethodExpression().getQualifierExpression() instanceof PsiReferenceExpression) {
PsiReferenceExpression qualifier = (PsiReferenceExpression) expression.getMethodExpression().getQualifierExpression();
if (“System.out”.equals(qualifier.getText())) {
// 警告をエディタ上に表示する
holder.registerProblem(expression, “System.out.printlnは禁止です。AppLoggerを使用してください。”);
}
}
}
}
};
}
}
手順③：plugin.xmlへの登録
作成したクラスをIDEに認識させるため、`src/main/resources/META-INF/plugin.xml` に以下を追記します。
—
4. なぜこの方法が「現場で震えるほど」役立つのか？
この方法の真価は、「修正案（Quick Fix）」を提示できることにあります。
`registerProblem` メソッドに `LocalQuickFix` インターフェースを実装したクラスを渡すことで、警告が出た瞬間に `Alt + Enter` を押すだけで、「自動的に正しいメソッドへ書き換える」という魔法を実現できます。
チームのメンバーが「何が正しい書き方か」を迷う時間はゼロになります。IDEがルールを教え、IDEが修正を完了させる。これが、究極の開発生産性です。
—
最後に：アーキテクトからの助言
最初は小さな「命名規則チェック」から始めてください。次に「非推奨ライブラリの排除」、最終的には「アーキテクチャ上の境界を越えた呼び出しの禁止」まで自動化しましょう。
IDEの拡張は、単なる便利機能ではありません。「チーム全員の脳内に、共通のアーキテクチャのガイドラインをインストールする行為」そのものです。
さあ、明日からの開発で、機械に任せられることは全て任せてしまいましょう。あなたのコードは、もっと自由で創造的な領域へ向かうはずです。何か詰まったら、いつでもPSI構造を覗いてみてください。そこには常に、真実が記されています。