Claude CodeでJetBrainsプラグインを開発し、verifyPluginまで回す

JetBrains IDE向けのプラグインは、Gradleのタスクで「構成の検査 → ビルド → 互換性検証 → 実機起動」まで進められます。Claude Codeに任せやすいのは、この前半の出力で合否が読める部分です。実機でIDEを触る部分は手元に残ります。

この記事では、IntelliJ Platform Gradle Pluginのタスクを軸に、Claude Codeへ書かせて直させる反復の組み方を説明します。

前提となる環境と、Claude Codeが使えるタスク

IntelliJ Platform Gradle Plugin 2.xの最低要件は、IntelliJ Platform 2023.3、Gradle 9.0.0、Java 17です。プラグインIDは org.jetbrains.intellij.platform で、1.x系の旧プラグインとは別物になっています。ドキュメントの例では次の書き方です。

plugins {
  id("org.jetbrains.intellij.platform") version "2.19.0"
}

Claude Codeが叩くタスクは、出力が文字で返るものに絞ると扱いやすくなります。

タスク	何をするか	実行前に走るもの
`verifyPluginProjectConfiguration`	何をするかビルド設定がプラットフォーム側の要件に沿っているか検査する	実行前に走るもの`patchPluginXml`
`verifyPluginStructure`	何をするか`plugin.xml` と配布物の構造を検査する	実行前に走るもの`prepareSandbox`
`buildPlugin`	何をするか配布用のZIPを作る	実行前に走るもの`jarSearchableOptions` と `prepareSandbox`
`verifyPlugin`	何をするかPlugin Verifierで対象IDEとの互換性を調べる	実行前に走るもの`buildPlugin`
`runIde`	何をするかプラグインを載せたIDEを起動する	実行前に走るもの`patchPluginXml` と `prepareSandbox_runIde`

実行するコマンドは次のとおりです。

./gradlew verifyPluginProjectConfiguration
./gradlew verifyPluginStructure
./gradlew verifyPlugin

verifyPlugin は buildPlugin に依存するので、単独で叩けば先にZIPが作られます。一方で runIde はIDEの画面を開くため、Claude Codeの出力だけでは動作の良し悪しを判断できません。

Claude Codeに渡す指示とCLAUDE.md

Claude Codeは CLAUDE.md を毎セッションの冒頭で読みます。ここに検証タスクの順番と、公式が検査する項目をそのまま書いておくと、書き直しの方向がぶれにくくなります。たとえば次のような断片です。

# JetBrainsプラグイン開発の規約
 
## 検証の順番
1. ./gradlew verifyPluginProjectConfiguration
2. ./gradlew verifyPluginStructure
3. ./gradlew verifyPlugin
全部通るまで修正と再実行を繰り返す。runIde は実行しない。
 
## 守ること
- plugin.xml の until-build は書かない(2024.3 以降が対象のとき)
- Kotlin stdlib と Coroutines を依存に足さない(プラットフォーム側が提供)
- @ApiStatus.Internal の API は使わない
- .intellijPlatform を .gitignore に入れる
- ライブラリをメインのプラグインJARに再パッケージしない

この規約の項目は、公式が各タスクの説明に書いている内容から取っています。verifyPluginProjectConfiguration は次の点を検査します。

patchPluginXml.sinceBuild が対象プラットフォームのメジャーバージョンより低くないこと
IntelliJ Platform 2024.3(243)以降では until-build を外すこと
JavaとKotlinの互換性設定が、sinceBuild と使用中のプラットフォームが要求するバージョンに揃っていること
Kotlin stdlibへの依存を除外すること
Kotlin Coroutinesを明示的に追加しないこと
.intellijPlatform が .gitignore に入っていること

buildPlugin の説明には、ライブラリをメインのプラグインJARに再パッケージしないよう書かれています。再パッケージすると、Plugin Verifierが未解決のクラスやメソッドを誤検知するためです。

権限を絞って自走させる

検証のたびに許可を求められると反復が止まります。かといって Bash(./gradlew *) のような広い許可は、後述の publishPlugin まで通してしまいます。.claude/settings.json に完全一致のルールで並べる方法があります。

{
  "permissions": {
    "allow": [
      "Bash(./gradlew verifyPluginProjectConfiguration)",
      "Bash(./gradlew verifyPluginStructure)",
      "Bash(./gradlew buildPlugin)",
      "Bash(./gradlew verifyPlugin)",
      "Bash(./gradlew test)"
    ],
    "deny": [
      "Bash(./gradlew publishPlugin)",
      "Bash(./gradlew runIde)"
    ]
  }
}

公式の権限ドキュメントでは、Bash(npm run build) のようにコマンド全体を書くと完全一致になります。許可した検証タスクにオプションを足した呼び出しは、別のコマンドとして扱われます。許可が足りないと感じたら、ルールを広げる前に実際に出たコマンドを確認してください。権限ルールの全体像はClaude Codeの/permissionsコマンドにあります。

publishPlugin を止めているのは、このタスクがJetBrains Marketplaceなどの公開先へZIPを送るためです。公開は人間が判断する操作として残しておく方が安全です。

verifyPluginの失敗レベルを読む

互換性検証で最も判断が分かれるのが failureLevel です。既定でタスクが失敗するのは次の3種類に限られます。

COMPATIBILITY_PROBLEMS(互換性の問題)
INTERNAL_API_USAGES(@ApiStatus.Internal のAPIの利用)
OVERRIDE_ONLY_API_USAGES(@ApiStatus.OverrideOnly のAPIの誤った利用)

非推奨APIの利用(DEPRECATED_API_USAGES)や削除予定APIの利用(SCHEDULED_FOR_REMOVAL_API_USAGES)は、既定では失敗にならず報告に出るだけです。Claude Codeに「通るまで直して」と頼んだとき、警告として残ったものは直されません。削除予定APIまで拾いたいときは、build.gradle.kts に明示します。

intellijPlatform {
  pluginVerification {
    failureLevel = listOf(
      VerifyPluginTask.FailureLevel.COMPATIBILITY_PROBLEMS,
      VerifyPluginTask.FailureLevel.INTERNAL_API_USAGES,
      VerifyPluginTask.FailureLevel.OVERRIDE_ONLY_API_USAGES,
      VerifyPluginTask.FailureLevel.SCHEDULED_FOR_REMOVAL_API_USAGES,
    )
  }
}

全部を対象にする FailureLevel.ALL もありますが、含まれる NOT_DYNAMIC(IDEの再起動なしに有効化・無効化できない可能性)は、teamCityOutputFormat = true と併用できません。両方を設定するとタスクが設定エラーで即座に失敗します。

どのIDEに対して検証するか

検証先のIDEを明示しなければ、recommended() が既定で適用されます。これは現在使っているプラットフォームに基づいて、対象のIDEを選ぶ仕組みです。固定のIDEを足すなら ides { } ブロックの中に書きます。

intellijPlatform {
  pluginVerification {
    ides {
      recommended()
      create(IntelliJPlatformType.RustRover, "2023.3")
    }
  }
}

何が対象になるか先に確かめたいときは、verifyPlugin の listIdes を使うと、検証を走らせずにIDEの一覧だけを出せます。IDEの種類を増やすほど検証の時間とダウンロード量は増えるため、まず recommended() で通し、必要な製品だけを足す順が現実的です。

ビルドが成功しても検証が通ったとは限らない

verifyPlugin は、コンソール出力ではなくPlugin Verifierのレポートファイルから合否を決めます。どの対象IDEについても結果が書かれなかった場合は、成功と見なさずタスクが失敗します。アーカイブが空のときはタスクごとスキップされるので、「緑だった」の意味を buildPlugin の成果物と合わせて確認する必要があります。

誤検知と既知の問題を扱う

レポートの出力形式は、既定でPLAINとHTMLの2種類です。MARKDOWN形式も選べるので、Claude Codeに読ませるなら verificationReportsFormats にMARKDOWNを足し、verificationReportsDirectory の出力先を指定しておくと、ファイルを開かせるだけで済みます。

直せない指摘への対処は3通りあります。

外部ライブラリのクラスが「No such class」と報告されるときは、externalPrefixes にそのパッケージの接頭辞を渡す
報告に出る問題を無視したいときは、ignoredProblemsFile に一覧を書いたファイルを指定する
特定の問題IDだけ黙らせたいときは、freeArgs で -mute と問題IDのカンマ区切りを渡す

intellijPlatform {
  pluginVerification {
    freeArgs = listOf(
      "-mute",
      "TemplateWordInPluginId,ForbiddenPluginIdPrefix"
    )
  }
}

ここで注意したいのは、Claude Codeが「通すために無視設定を足す」方向へ流れる余地があることです。CLAUDE.md に「-mute と ignoredProblemsFile は私の許可なしに変更しない」と一行足しておくと、指摘を直さずに消す変更を避けられます。

テストとビルド時間の見積もり

test タスクは、IntelliJ Platform、サンドボックス、必要なシステムプロパティが設定された状態で動くよう、プラグイン側で事前に構成されます。対象IDEの product-info.json に載っているバンドル済みプラグインも、既定でテストのクラスパスに入ります。ユニットテストの結果は文字で読めるので、verifyPlugin の前に挟むと、振る舞いの崩れを先に拾えます。

また、buildPlugin はプラグインの設定画面から検索用の索引を作る buildSearchableOptions を経由します。このタスクはヘッドレスのIDEを起動するため、軽い検査タスクと同じ感覚で何度も回すと待ち時間が伸びます。Claude Codeには、設定と構造の検査を先に済ませてから verifyPlugin へ進むよう伝えておくと、無駄なビルドを減らせます。

反復の組み立て方

タスクを一通りつなぐと、次のような流れになります。

仕様を伝えて、Claude Codeに拡張ポイントの実装と plugin.xml の登録を書かせる
verifyPluginProjectConfiguration と verifyPluginStructure を回し、設定や構造の違反を潰させる
verifyPlugin を回し、互換性の報告を読ませて直させる
人間が runIde で実機を起動し、画面と挙動を確認する

runIde は起動時に、サンドボックス内の idea.log のパスを IDE logs: という接頭辞つきでログへ出します。実機で起きた不具合は、このログの該当箇所をClaude Codeに貼れば、再現手順なしでも原因を探させられます。

同じ考え方でVS Code拡張を作る場合はClaude CodeでVS Code拡張を自作するにまとめています。検証コマンドを編集のたびに自動で走らせたいなら、hooksでテストを自動実行する方法の構成を、Gradleの軽い検査タスクに置き換えて使えます。

公開前に人が確かめること

signPlugin は、証明書チェーンと秘密鍵、そのパスワードを intellijPlatform.signing で渡して初めて署名できます。標準の buildPlugin の成果物については、privateKey(または privateKeyFile)と certificateChain(または certificateChainFile)が指定されていれば、publishPlugin の前に自動で実行されます。署名の検証には verifyPluginSignature が使えます。

鍵やパスワードは、Claude Codeに読ませる設定ファイルへ直接書かず、環境変数やCIのシークレットで渡す構成にしておくのが無難です。Claude Codeには publishPlugin を実行させない、という上の権限設定と合わせて、公開の操作だけを人間の側に置けます。

CIで回すなら、verifyPlugin を品質チェックの1ステップとして加えるだけで統合できます。公式はIntelliJ Platform Plugin TemplateのGitHub workflow設定を参考例に挙げています。Gradleを使わないプロジェクトでは、Plugin Verifierを単体のCLIとしても使えます。

よくある疑問

完成したプラグインをClaude Code側で使いたいときは

JetBrains IDEの中でClaude Codeを使う設定は、別のガイドで扱っています。導入と設定はClaude Code JetBrainsプラグインの導入と設定を参照してください。この記事は「JetBrains用プラグインをClaude Codeで作る」側の話です。

旧Gradle IntelliJ Pluginのプロジェクトはそのまま使えるか

2.x系はプラグインIDが org.jetbrains.intellij.platform に変わっています。1.x系からの移行は公式の移行ガイドにまとまっているため、Claude Codeには先にそのガイドを読ませ、build.gradle.kts の書き換えを任せる形が取れます。

まとめ

JetBrainsプラグイン開発でClaude Codeが得意なのは、verifyPluginProjectConfiguration、verifyPluginStructure、verifyPlugin の出力を読んで直す反復です。既定の failureLevel では非推奨APIの利用が失敗にならないため、どこまで厳しくするかはプロジェクトごとに決める必要があります。publishPlugin と runIde は権限で止め、公開と実機確認を人間の側に残す構成が、境界の分かりやすい分担です。

Claude CodeでJetBrainsプラグインを開発し、verifyPluginまで回す

Claude CodeでJetBrainsプラグインを開発し、verifyPluginまで回す

前提となる環境と、Claude Codeが使えるタスク

Claude Codeに渡す指示とCLAUDE.md

権限を絞って自走させる

verifyPluginの失敗レベルを読む

どのIDEに対して検証するか

ビルドが成功しても検証が通ったとは限らない

誤検知と既知の問題を扱う

テストとビルド時間の見積もり

反復の組み立て方

公開前に人が確かめること

よくある疑問

完成したプラグインをClaude Code側で使いたいときは

旧Gradle IntelliJ Pluginのプロジェクトはそのまま使えるか

まとめ

Claude Codeとは — できること・料金・始め方と使い方の全体像

Claude CodeでZigを書く — zig build testを完了条件にする

Claude CodeでRustのWebAssemblyを作る — wasm-packとヘッドレスブラウザ検証

Claude CodeでHonoのAPIを作る — app.requestで検証して完了を判定

Claude CodeでDatabricks Asset Bundlesを書く — deployは承認制に

Claude CodeでAzure Functionsを開発する — func startとpublishの権限設計

Claude CodeでJetBrainsプラグインを開発し、verifyPluginまで回す

前提となる環境と、Claude Codeが使えるタスク

Claude Codeに渡す指示とCLAUDE.md

権限を絞って自走させる

verifyPluginの失敗レベルを読む

どのIDEに対して検証するか

ビルドが成功しても検証が通ったとは限らない

誤検知と既知の問題を扱う

テストとビルド時間の見積もり

反復の組み立て方

公開前に人が確かめること

よくある疑問

完成したプラグインをClaude Code側で使いたいときは

旧Gradle IntelliJ Pluginのプロジェクトはそのまま使えるか

まとめ

関連する記事

Claude Codeとは — できること・料金・始め方と使い方の全体像

Claude CodeでZigを書く — zig build testを完了条件にする

Claude CodeでRustのWebAssemblyを作る — wasm-packとヘッドレスブラウザ検証

Claude CodeでHonoのAPIを作る — app.requestで検証して完了を判定

Claude CodeでDatabricks Asset Bundlesを書く — deployは承認制に

Claude CodeでAzure Functionsを開発する — func startとpublishの権限設計