【入門編】WebStormの『コードインスペクション』をカスタマイズして、チーム特有のレガシーコードを自動修正する実践術 – 総合開発環境（IDE）生産性向上バイブル

こんにちは！日々の開発、本当にお疲れ様です。
新しいプロジェクトに参加したり、歴史のあるレガシーコードベースに向き合ったりするとき、「なんでこのチーム、こんな書き方ルールにしているんだろう？」「また命名規則の指摘でプルリクエストのレビューが長引いちゃったな……」と、ため息をついた経験はありませんか？

世の中にはESLintやPrettierといった素晴らしいツールがありますが、「特定のフォルダ配下ではこのプレフィックスをつけてほしい」「この独自のデータ構造（設計パターン）に違反している箇所を根こそぎ見つけて、ワンクリックで直したい」といった、プロジェクト特有の「生々しいルール」までは、標準のLinterだけではなかなかカバーしきれませんよね。

そこで今回は、最強のIDE「WebStorm」が持つ機能、『コードインスペクション（Code Inspection）』を極限までカスタマイズし、チーム特有のレガシーコードを自動検出・自動修正する実践術を、優しく丁寧にお伝えします。

これをマスターすれば、機械的なコーディングスタイルの指摘はすべてIDEと自動化に任せることができ、あなたとチームメンバーは「より本質的なアーキテクチャの議論」に集中できるようになりますよ。毎日のコーディングが劇的に楽になる世界へ、一緒に一歩を踏み出しましょう！

—

そもそも「WebStormのインスペクション」とは何か？

WebStormをはじめとするJetBrains製品の真骨頂は、コードをテキストとしてではなく、「AST（抽象構文木）」と呼ばれるプログラムの構造体としてリアルタイムに解析している点にあります。

一般的なLinter（ESLintなど）は、ファイルを保存したタイミングやCIのビルド時に走ることが多いですが、WebStormのインスペクションは、あなたがコードを1文字タイピングしているまさにその瞬間にも背景で動き続け、コードの不審な点や設計のほころびを検知してくれます。

さらにすごいのは、見つけた問題をただ警告（黄色い波線など）するだけでなく、「Alt + Enter（macOSならOption + Enter）」のクイックフィックスで、コードを瞬時に正しい形へ自動書き換え（Intention Action）できること。この「検出から修正までのスピード感」が、開発体験を別次元へと引き上げてくれます。

—

基礎セットアップ：チーム専用のインスペクションプロファイルを作ろう

まずは、プロジェクトごとに独自のルールを定義し、それをチームメンバー全員で共有するための第一歩を踏み出します。ここがすべての土台になります。

1. 専用プロファイルの作成

1. WebStormの設定画面を開きます（Windows/Linux: `Ctrl + Alt + S`、macOS: `⌘,`）。
2. 左メニューから [Editor] > [Inspections] を選択します。
3. 上部にある「Profile」のドロップダウン横にある歯車アイコン（⚙️）をクリックし、[Copy…] を選択します。
4. プロファイル名に `[TeamName] Custom Rules` のような分かりやすい名前をつけます。

このプロファイル（設定ファイル）は、最終的にプロジェクトの `.idea/inspectionProfiles/` ディレクトリ配下にXMLとして保存されます。これをGitでバージョン管理に乗せることで、チーム全員が全く同じインスペクションルールを共有できるようになります。

—

実践：Regex（正規表現）を用いた「チーム特有のレガシーコード検出ルール」の作り方

ここでは、よくある現場の課題を例に取ってみましょう。
> 「レガシーな画面コンポーネントにおいて、古い状態管理フック `useLegacyState` を直接呼び出している箇所をすべて検出し、新しく設計された `useModernStore` へ自動置換したい」

ESLintのカスタムルールを書くのは骨が折れますが、WebStormの「Search Structurally (構造的検索)」や「General JavaScript / TypeScript inspections (正規表現ベースのカスタムインスペクション)」を使えば、数分で実現できます。

今回は、最も手軽かつ強力な、正規表現を用いたカスタムインスペクションの作成手順をステップバイステップで見ていきましょう。

Step 1: カスタムインスペクションの追加

1. [Editor] > [Inspections] の画面に戻り、検索窓に「General」または「Custom」と入力します。
2. リストの中から [JavaScript and TypeScript] > [General] > [Custom regExp search]（または類似のカスタム検索系ルール）を探し、チェックを入れます。

※もし見つからない場合は、右上の [+] (Add Profile) > [Add Structural Search inspection] を使うと、より高度なASTベースの検索も可能です。今回は直感的な正規表現で行きましょう。

3. 下部のオプションパネルで、このルールの「名前」と「警告レベル（Warning / Error）」を設定します。

Step 2: 検出用正規表現の設定

例えば、ソースコード内の `useLegacyState(/ 任意の引数 /)` という記述をピンポイントで捕まえたい場合、以下のような正規表現を設定します。

\buseLegacyState\s$[^)]$

解説:
`\b` : 単語の境界（余計な文字列の一部としてヒットするのを防ぐ）
`useLegacyState` : 検出したいレガシーな関数名
`\s` : 関数名と括弧の間の任意の空白
`$[^)]$` : 開き括弧から、対応する閉じ括弧までのすべて（引数の部分）

Step 3: クイックフィックス（自動修正）の仕込み

ここが魔法のような体験を生むポイントです。検出するだけでなく、「どう直すべきか」のテンプレートを登録します。

インスペクションの設定項目内にある [Replace with]（置換文字列）に、以下のように入力します。

useModernStore({ type: ‘migrated’, payload: $0 })

解説: `$0` や正規表現のキャプチャグループを使用することで、レガシーコードが持っていた元の引数や文脈を壊さずに、新しい構文へと安全に流し込むことができます。

—

精度高い動作確認：HelloWorldを試そう

正しく設定ができているか、小さなテストファイルを作って動作確認（HelloWorld）をしてみましょう。

テストコードの用意

プロジェクト内に `legacy-checker.ts` というファイルを作成し、以下のコードを貼り付けてみてください。

// legacy-checker.ts
import { useLegacyState } from ‘./hooks’;

export function UserProfileComponent() {
// ここにレガシーなフックが残っている
const [state, setState] = useLegacyState({ userId: 123 });

return (

User ID: {state.userId}

);
}

動作確認のステップ

1. ファイルを保存するか、WebStormのリアルタイム解析を待ちます。
2. `useLegacyState({ userId: 123 })` の部分に、あなたが設定した警告カラー（黄色い波線など）が表示されていることを確認してください。
3. そのコードの上にカーソルを合わせ、`Option + Enter`（macOS）または `Alt + Enter`（Windows）を押します。
4. メニューから「Replace with useModernStore…」を選択します。

【実行結果のコード】

import { useModernStore } from ‘./hooks’; // 必要に応じてインポートも調整可能

export function UserProfileComponent() {
// 自動的に新しいストア構造に置換された！
const [state, setState] = useModernStore({ type: ‘migrated’, payload: { userId: 123 } });

return (

User ID: {state.userId}

);
}

どうですか？たったこれだけの作業で、チーム特有の「古いAPIの撲滅運動」が、IDEのローカル環境で爆速かつノーミスで完了します。

—

チーム全体の開発生産性を爆発させる「共有戦略」

個人のローカル環境でこの設定が動くだけでは、まだ片手落ちです。これをチーム全体に強制力を持って浸透させるための「DevOps的戦略」を最後に伝授します。

1. `.idea` ディレクトリのGit管理

JetBrains製品の設定ファイル群は、プロジェクトルートの `.idea/` ディレクトリに格納されます。
特に、以下のファイルパスにあるインスペクションプロファイルの実体をGitに含めてコミットしてください。

.idea/
└─ inspectionProfiles/
└─ _TeamName__Custom_Rules.xml <-- これを共有する！これにより、チームメンバー全員が同じWebStormを開いた瞬間から、同じカスタムインスペクションの恩恵を受けられるようになります。

2. CI/CDパイプライン（Headless Inspection）との連携

「ローカルで直してね」と言いつつ、うっかり修正を忘れてプッシュしてしまう開発者は必ずいます。それを水際で防ぐのが、WebStormの頭脳をCLIで動かす [Qodana（コダナ）] または [JetBrains Inspector CLI] です。

GitHub ActionsなどのCI環境で以下のようなタスクを走らせます。

.github/workflows/code-inspection.yml のイメージ
name: Quality Gate by WebStorm Inspections
on: [pull_request]

jobs:
inspect:
runs-on: ubuntu-latest
steps:

uses: actions/checkout@v4
name: Run Qodana / Inspection

uses: JetBrains/qodana-action@v2023.3
with:
args: –profile-name, “[TeamName] Custom Rules”

これにより、「チーム特有のレガシーコードが混ざったプルリクエストは、CIのテストが自動で落ちる（＝マージできない）」という堅牢な品質ゲートを構築できます。

—

まとめ：ツールに雑務を任せ、私たちはクリエイティブな仕事へ

今回解説したWebStormのカスタムインスペクションと自動修正の仕組みは、単なる「コーディング規約チェッカー」の枠を超えています。

レビューの負荷激減: 「ここ、古い書き方になってますよ」という人間による指摘をゼロにできる。
移行作業の劇的な効率化: レガシーからモダンへの大規模マイグレーションが、手作業ではなく安全な一括置換で行える。
知見のコード化: シニアエンジニアの頭の中にある「こう書いてはいけない」という暗黙知を、IDEのルールとしてチーム全体に資産として残せる。

「これをマスターすれば、毎日のコーディングが劇的に楽になりますよ」。
明日からの開発で、ぜひチームのレガシーコードを一つ、このカスタムインスペクションで退治してみてください。あなたの開発ライフが、より知的でクリエイティブなものになることを、心から応援しています！