IntelliJ IDEAの深淵へ：カスタムインスペクションでチームの「規約」をコードへと昇華させる
多くの現場で、コードレビューは「人間がしなくてもいい指摘」に忙殺されている。`Optional`の扱いや、特定のドメインクラスを直接参照してはいけないという暗黙のルール。これらを人間が指摘し続けるのは、知的生産性をドブに捨てる行為だ。
真のDevOpsアーキテクトは、ルールをドキュメントに書かない。IDEの抽象構文木（PSI）に刻み込むのだ。 本稿では、IntelliJ Platform SDKを用いて「チームの規約を強制する」カスタムインスペクションを構築し、それをCIパイプラインと同期させる究極の運用術を伝授する。
—
1. なぜ「設定」ではなく「SDK開発」なのか？
`EditorConfig`や標準の`Checkstyle`では限界がある。特に「特定のプロジェクト内でのみ許される、コンテキスト依存のコード構造」をチェックする場合、サードパーティ製ツールではコンテキストが掴めない。
IntelliJのインスペクションは、ソースコードを解析して生成されるPSI (Program Structure Interface)ツリーを直接操作する。これを利用すれば、`if`文の中に特定のメソッド呼び出しがある場合のみ警告を出すといった、セマンティックな解析が可能になる。
カスタムインスペクション作成の要諦
プラグイン開発の入り口は `LocalInspectionTool` クラスだ。ここで重要なのは、`PsiElementVisitor` を継承して「どのノードに反応するか」を定義することである。
// 独自のインスペクションロジック
class SensitiveDomainInspection : LocalInspectionTool() {
override fun buildVisitor(holder: ProblemsHolder, isOnTheFly: Boolean): PsiElementVisitor {
return object : JavaElementVisitor() {
override fun visitMethodCallExpression(expression: PsiMethodCallExpression) {
// コンテキスト解析: 特定の「禁忌」クラスのメソッド呼び出しを検知
val methodExpression = expression.methodExpression
if (methodExpression.referenceName == “unsafeLegacyMethod”) {
holder.registerProblem(expression, “このレガシーメソッドは使用禁止です。代わりにDomainServiceを使ってください。”)
}
}
}
}
}
このコードをプラグインとしてパッケージ化し、チームのIDEに配布するだけで、コーディング規約は「ドキュメント」から「エディタのリアルタイム警告」へと進化する。
—
2. CI/CDパイプラインとの高度な同期：ヘッドレス解析の真髄
IDEで警告を出しても、CIをすり抜けてしまえば意味がない。しかし、IDEのGUIをCI環境で動かすのは愚の骨頂だ。ここで登場するのが IntelliJ Inspections CLI である。
JetBrainsが提供する `idea-inspections` Dockerイメージを活用し、IDEと同じ検査エンジンをコマンドラインから叩く。
インスペクションをCI環境で実行するシェルスクリプトの断片
docker run –rm -v $(pwd):/project \
jetbrains/intellij-platform-cli:latest \
inspect /project /project/.idea/inspectionProfiles/CustomRules.xml \
/project/build/reports/inspections –format xml
実行後、生成されたXMLを解析し、深刻な違反があればexit 1でビルドを落とす
python3 scripts/parse_inspection.py build/reports/inspections/report.xml
ポイントは、IDE上の設定とCIの設定を完全に同一にすることだ。`.idea/inspectionProfiles/`配下の設定ファイルをGitで管理し、IDEとCIが同じルールセットを参照する「Single Source of Truth」を構築せよ。
—
3. アーキテクトの深淵：パフォーマンスとメモリの最適化
カスタムインスペクションを導入すると、巨大なプロジェクトではIDEが重くなる。これを防ぐには「構文解析のスコープ」を最小化する思考が必要だ。
1. visitorの絞り込み: `visitElement`をオーバーライドして全ノードをなめるな。`visitMethodCallExpression`など、必要な型に限定することでCPU負荷を劇的に抑えられる。
2. キャッシュの活用: インスペクションの計算結果が重い場合、`PsiModificationTracker` を使ってキャッシュ戦略を立てる。
3. バックグラウンドスレッドの強制: 複雑な解析は `ApplicationManager.getApplication().executeOnPooledThread` を利用し、UIスレッドを絶対に止めない。
—
4. なぜこれが「計り知れない利益」をもたらすのか
エンジニアの集中力を削ぐ「規約の再確認」をゼロにすれば、フロー状態を維持できる時間が1日あたり平均20%向上する。月換算で数日分の生産性向上だ。
さらに、このアプローチには副次的なメリットがある。「規約の自動化」は、新人のオンボーディングコストを劇的に下げる。 規約を学ぶ必要はない。IDEが「正しい道」を常に指し示してくれるからだ。
結び：技術至上主義の果てに
ツールに振り回されるな。IDEのAPIを深く理解し、自分たちの開発プロセスに合わせて「拡張」する。それが、真の意味で「最高峰の開発環境」を構築するということだ。
さあ、明日からの開発で、チームの「暗黙のルール」を1つだけコードに書き換えてみてほしい。その瞬間に、あなたのチームは単なる開発者集団から、洗練されたエンジニアリング組織へと一歩足を踏み入れることになる。
—
Next Step for Experts:
次は、このインスペクションに「クイックフィックス（Alt+Enterで修正する機能）」を追加せよ。警告を出すだけではなく、自動修正まで実装して初めて、真の自動化と言える。