こんにちは。テックリードの私だ。
日々の開発で、こんなフラストレーションを抱えてはいないだろうか?
「既存のESLintやBiomeのルールでは検知しきれない、うちのチーム特有のアーキテクチャ制約(例: 特定のレガシーモジュールから新規ドメイン層への直接依存の禁止、社内共通APIクライアントのラッパーを通していないfetchの直叩き禁止など)がある」
「PRレビューで毎回『ここ、共通のヘルパー使ってください』と指摘するのに疲れた」
ドキュメントを読ませても誰も読まない。コードレビューで指摘しても、人間の目では必ずすり抜ける。この構造的欠陥を根本から解決する唯一の手段が、「IDEレベルでのカスタムインスペクション(静的解析)の強制」だ。
今回は、IntelliJ Platform SDK(WebStormの頭脳)の深部に踏み込み、チームの暗黙の規約を自動検知する「自分専用カスタムインスペクション」の作り方から、それをチーム全体へシームレスに配布する黄金フローまで、プロの実践テクニックを余すところなく伝授する。
—
1. WebStormの真価を引き出すキラーショートカット&神プラグイン
カスタムコードを書く前に、まず我々の開発スピードを物理の限界まで引き上げる環境設定を整えよう。これらが体に染み込んでいないうちは、WebStormを使いこなしているとは言えない。
開発スピードを3倍にする隠しキーボードショートカット (macOS / Windows)
- `Shift` + `Shift` (Search Everywhere): 迷ったらこれ。ファイル、クラス、シンボル、アクション、果ては設定項目まで、あらゆるリソースをインクリメンタルサーチで一発呼び出し。
- `⌥` + `Enter` (Mac) / `Alt` + `Enter` (Win) (Show Intentions): WebStormで最も重要なキー。エラーや警告だけでなく、リファクタリングの提案、コードの自動修正(Quick Fix)のメニューを瞬時に開く。カスタムインスペクション開発でも、このメニューに自作の修正ロジックをフックさせることになる。
- `⌘` + `Shift` + `A` (Mac) / `Ctrl` + `Shift` + `A` (Win) (Find Action): メニュー名を忘れたときに、コマンド名で機能を直接実行する。
- `⌥` + `F7` (Mac) / `Alt` + `F7` (Win) (Find Usages): 高度な型情報を加味した参照検索。文字列一致ではなく、AST(抽象構文木)ベースなので安全。
絶対に入れるべき神プラグイン
1. Key Promoter X: 操作のショートカットを画面右下にポップアップで教育してくれる鬼神ツール。マウス操作を根絶するために必須。
2. Rainbow Brackets: ネストが深いTypeScriptのJSXや複雑なオブジェクトリテラルで、対応する括弧を色分けし視認性を爆上げする。
3. String Manipulation: キャメルケース、スネークケース、JSONのエスケープなどを一瞬で変換するユーティリティ。
—
2. なぜESLintではなく「WebStormカスタムインスペクション」なのか?
「Lintでよくないか?」という声が聞こえてきそうだが、両者には決定的なレイヤーの違いがある。
| 比較項目 | ESLint / Biome | WebStorm Custom Inspection |
| :— | :— | :— |
| 実行タイミング | CLI実行、ビルド時、エディタのプラグイン連携(タイムラグあり) | タイピング中(リアルタイムAST解析) |
| コンテキスト理解 | ファイル単体、または静的解析で辿れる範囲 | プロジェクト全体の依存関係グラフ、モジュール構造を完全把握 |
| 拡張性 | JavaScript/TypeScriptでルールを書く | Java/KotlinによるIntelliJ Platform API(強力なAST操作) |
プロジェクト固有の「ドメイン駆動設計(DDD)のレイヤー違反検知」や「特定の禁止されたモジュール間インポート」をやる場合、WebStormのインスペクション機能を使う方が、IDEの強力なUI(赤波線、Quick Fix、一括修正)をそのまま利用できるため、開発者体験(DX)が圧倒的に高い。
—
3. 実践:カスタムインスペクションの開発ステップ
ここからが本題だ。今回は、「チーム内で特定の非推奨API(例: 雑な `axios.get` の直叩き)を発見したら、即座にカスタムの警告を出し、一発で共通ラッパーへ置き換えるQuick Fixを提供するプラグイン」の構築ステップを解説する。
ステップ1: 開発環境の構築(IntelliJ Platform Plugin Template)
WebStormのプラグインは、IntelliJ Platform SDKを用いてKotlinまたはJavaで開発する。公式が提供しているモダンなテンプレートリポジトリを使うのが最速だ。
GitHubの `JetBrains/intellij-platform-plugin-template` をベースにプロジェクトをクローンし、`gradle.properties` を以下のように設定する。
gradle.properties
プラグインがターゲットとするIntelliJプラットフォームのバージョン
platformType=WS
platformVersion=2023.3.4
プラグインの基本情報
pluginGroup=com.example.webstorm.inspection
pluginName=Team-Rule-Enforcer
pluginVersion=1.0.0
ステップ2: AST(抽象構文木)を走査するインスペクションの定義
TypeScriptのコード片から特定の関数呼び出し(`axios.get`)を検知するVisitor(訪問者)パターンを用いたインスペクションクラスを実装する。
IntelliJ Platformでは、JavaScript/TypeScriptファイルはJS/TSのPSI(Program Structure Interface、ASTのラッパー)として表現される。
// com/example/inspection/DirectAxiosInspection.kt
package com.example.inspection
import com.intellij.codeInspection.
import com.intellij.lang.javascript.psi.
import com.intellij.psi.PsiElement
import com.intellij.psi.PsiElementVisitor
class DirectAxiosInspection : LocalInspectionTool() {
// エディタ上に表示される警告文言の定義(Bundle化推奨だが今回は直書き)
override fun getDisplayName(): String = “Direct axios call is prohibited”
override fun getGroupDisplayName(): String = “Team Specific Rules”
override fun isEnabledByDefault(): Boolean = true
override fun buildVisitor(holder: ProblemsHolder, isOnTheFly: Boolean): PsiElementVisitor {
// JS/TSの構文木を走査するビジターを返す
return object : JSElementVisitor() {
override fun visitJSCallExpression(node: JSCallExpression) {
super.visitJSCallExpression(node)
// 呼び出しているメソッドの式を取得
val methodExpression = node.methodExpression as? JSReferenceExpression ?: return
// 例: “axios.get” の呼び出しを検知
if (methodExpression.text == “axios.get”) {
holder.registerProblem(
node,
“axiosの直接呼び出しは禁止されています。src/api/httpClient.tsを使用してください。”,
ProblemHighlightType.GENERIC_ERROR_OR_WARNING,
// 後述するクイックフィックス(自動修正)をアタッチ
ReplaceWithHttpClientQuickFix()
)
}
}
}
}
}
ステップ3: Quick Fix(自動修正)の実装
警告を出すだけでなく、開発者が `⌥` + `Enter` を押した時に、ワンタップで安全なコードへ書き換えるロジック(`LocalQuickFix`)を実装する。
// com/example/inspection/ReplaceWithHttpClientQuickFix.kt
package com.example.inspection
import com.intellij.codeInspection.LocalQuickFix
import com.intellij.codeInspection.ProblemDescriptor
import com.intellij.openapi.project.Project
import com.intellij.psi.PsiElement
import com.intellij.lang.javascript.psi.JSFile
import com.intellij.lang.javascript.psi.JSElementFactory
class ReplaceWithHttpClientQuickFix : LocalQuickFix {
override fun getName(): String = “HttpClientラッパーへ置き換える”
override fun getFamilyName(): String = “Fix axios usage”
override fun applyFix(project: Project, descriptor: ProblemDescriptor) {
val element: PsiElement = descriptor.element
// ファクトリーを使って新しいTypeScriptのAST要素(httpClient.get(…))を生成
val factory = JSElementFactory.getInstance(project)
val newExpression = factory.createExpressionFromText(“httpClient.get”, element) ?: return
// 既存のコードを新しい要素で置換
element.replace(newExpression)
}
}
このプラグインをGradleの `runIde` タスクでビルド・実行すると、デバッグ用のWebStormインスタンスが立ち上がり、実際にカスタムインスペクションの挙動を検証できる。
—
4. チーム開発で役立つ設定の共有化ルールと配布フロー
せっかく作ったカスタムインスペクションや規約を、チームメンバー全員の環境に強制適用させるための仕組みを構築しよう。個人の手動設定に頼る運用は必ず破綻する。
1. プロジェクト設定(`.idea` ディレクトリ)のGit管理
WebStorm(IntelliJプラットフォーム)は、プロジェクトの設定を `.idea` フォルダ内のXMLファイル群として保存する。
チーム全員で同じインスペクション設定やコードスタイルを共有するためには、以下のファイルをGitで厳格に管理するべきだ。
このXMLをリポジトリに含めることで、メンバーがプロジェクトをクローンしてWebStormで開いた瞬間から、同じ静的解析ルールが強制適用される。
2. プラグインの自動配布・適用フロー
作成したカスタムインスペクション(プラグイン)をチームに配布するには、以下のいずれかの方法をとる。
1. 社内プライベートPlugin Repository(ArtifactoryやGitHub Releases)の利用:
プラグインをビルドして得られる `.zip` ファイルを社内のサーバーやGitHub Releasesにアップロードする。
WebStormの「Settings -> Plugins -> ⚙️ -> Install Plugin from Disk…」から読み込ませるか、XML形式のカスタムリポジトリURLをチームメンバーのWebStormに登録してもらう。
2. プロジェクト内モジュールとしての同梱(推奨):
小規模〜中規模チームであれば、プラグイン自体をプロジェクトのサブモジュールとして開発し、CI/CDでビルド検証を回すことも可能だ。
—
5. 実用的な設定ファイル(JSON/XML)のベストプラクティス構成例
チーム開発でWebStormの真価を最大化するための、プロジェクトルートに配置すべき設定ファイルのベストプラクティス構成を提示する。
① チーム共通のコードスタイル定義 (`.idea/codeStyles/Project.xml`)
インデントや改行コード、TypeScriptのインポート順序のブレを完全にゼロにする。
② 効率的なエディタ設定 (`.idea/workspace.xml` 以外の共有設定)
保存時のフォーマット自動化や、未使用インポートの自動削除をプロジェクト単位で強制する。
—
終わりに:ツールに規約を語らせよ
人間の意思決定能力には限界がある。どれほど優秀なチームであっても、「レビューでの指摘漏れ」や「疲労による規約違反のうっかりミス」をゼロにすることは不可能だ。
だからこそ、「人間がコードレビューで指摘すべきこと」を極限まで減らし、機械的に検知・修正できる仕組み(カスタムインスペクション)をIDEの深部に埋め込むのだ。
WebStormは単なる「文字入力エディタ」ではない。チームのアーキテクチャを守り、開発スピードを劇的に高めてくれる「最強の共同開発者」である。ぜひ今回の手法を取り入れ、あなたのチームの生産性を次の次元へと引き上げてほしい。