メトリクス閾値の静的解析をエディタ非依存で回す(Checkstyle / PMD / ESLint)

調査時点: 2026-06。デフォルト閾値やエディタ拡張の成熟度はこの時点のもの。

中核ツール(Java)#

IDE インスペクションの「閾値チェック」は Checkstyle + PMD でほぼ再現できる。「閾値をデフォルトより小さくする」運用は、各ルールの max プロパティを締めることに対応する。

指標	ツール / ルール	デフォルト閾値
循環的複雑度	Checkstyle `CyclomaticComplexity` / PMD `CyclomaticComplexity`	10
認知的複雑度	PMD `CognitiveComplexity`	15
メソッド長	Checkstyle `MethodLength` / PMD `NcssCount`	150 行 / method 60
ネスト深さ	Checkstyle `NestedIfDepth` / PMD `AvoidDeeplyNestedIfStmts`	1 / 3
パラメータ数	Checkstyle `ParameterNumber` / PMD `ExcessiveParameterList`	7 / 10
クラスサイズ	Checkstyle `JavaNCSS`(class 300 行) / PMD `TooManyMethods`(10)、`TooManyFields`(15)	—
NPath 複雑度	Checkstyle `NPathComplexity` / PMD `NPathComplexity`	200

役割の違うツール。

SpotBugs: バイトコードを対象にバグパターン(null 参照・型誤用・脆弱性)を検出。メトリクス閾値は本来の用途ではないので PMD と併用する
error-prone: コンパイラプラグインとしてバグパターンを検出。メトリクスは対象外
ArchUnit: パッケージ依存・レイヤ境界を JUnit テストで検証。メソッド単位のサイズメトリクスには不向き

1
# PMD CLI
2
pmd check -d src/main/java -R rulesets/java/design.xml -f text
3
# Gradle 組み込みプラグイン
4
./gradlew pmdMain checkstyleMain

PMD は XML ルールセットで閾値を上書きし、build/reports/pmd/ に HTML を出す。

二層構成(CI + LSP)#

Checkstyle / PMD / SpotBugs はすべて CLI・Gradle / Maven プラグインとして動き、JVM があれば OS・エディタを問わず同じ解析ができる。IDE 組み込みの解析は IDE のバージョンと設定に依存するが、Gradle 経由なら CI とローカルを完全に一致させられる。

1
Layer 1 (CI / PR)   : Gradle → PMD + Checkstyle + SpotBugs → GitHub Actions → PR 注釈
2
Layer 2 (エディタ)  : LSP 診断 → JDTLS(型) + SonarLint(VSCode 公式 / Zed は非公式)

GitHub Actions の例(PMD 公式 Action)。

1
- uses: pmd/pmd-github-action@v2
2
  with:
3
    rulesets: 'rulesets/java/quickstart.xml,config/pmd/custom-rules.xml'
4
    analyzeModifiedFilesOnly: true   # PR の変更ファイルのみ
5
    createGitHubAnnotations: true    # PR に行コメント注釈

違反数は violations 出力で取れ、閾値超過でビルドを失敗させられる。SARIF を GitHub Code scanning に連携できる。Checkstyle も jwgmeligmeyling/checkstyle-github-action で Check Run 注釈になる。pre-commit でも実行できるが JVM 起動コストがかかる。

この構成の利点は、再現性(ローカルと CI が同一ルール・同一バージョン)、エディタ切替への耐性、PR 上でレビューと静的解析が一体化することの 3 点。

エディタごとの状況#

Zed: Java サポートは Eclipse JDTLS。補完・リファクタ・型診断は出るが、メトリクスのインスペクション相当はない。Zed 公式の IntelliJ 移行ガイド自身が「インスペクションは別ステップで実行するか、Checkstyle・PMD・SpotBugs などのスタンドアロンツールを使う」と書いている。SonarLint(SonarQube for IDE)は公式非対応で、コミュニティ拡張(sonarqube-zed-extension、zed-sonarlint)は未成熟
VSCode: Checkstyle for Java(shengchen.vscode-checkstyle)が編集中リアルタイム診断と Quick Fix を提供。SonarQube for IDE は Java 500 超のルールをリアルタイム診断し、Connected Mode で組織の SonarQube サーバの品質ゲートを同期できる。PMD 専用の成熟した拡張は確認できなかった

TypeScript / JavaScript への応用#

ESLint がメトリクス系を網羅する。

ESLint ルール	相当する指標	デフォルト	締める目安
`complexity`	循環的複雑度	20	10 程度
`max-depth`	ネスト深さ	4
`max-lines-per-function`	メソッド長	50
`max-params`	パラメータ数	3
`max-statements`	関数内の文数	10

Biome は complexity/noExcessiveCognitiveComplexity(既定 15)を持つが、ネスト深さなどは 2026-06 時点で未実装。閾値を細かく締めたいなら ESLint になる。Python では ruff の C901(mccabe)や PLR09xx(pylint の too-many-*)が同じ役割を持つ。

更新履歴#

2026-06-19: 初版（ローカル調査ノート）
2026-10-17: Wiki へ移植、概念ページとして再構成