Claude Code JetBrainsプラグインが「IDEを検出できない」原因を、公式ドキュメントとGitHub Issue実例で全部洗い出した
JetBrains（Rider・RustRover・PyCharm等）でClaude Codeの「No available IDEs detected」「Cannot launch Claude Code」が出る原因を公式トラブルシューティングとGitHub Issue実例から整理。WSL2ファイアウォール設定、CLAUDE_CONFIG_DIRの罠、IntelliJ 2026 devcontainerの非対応まで症状別にまとめた。
エンジニアのゆとです。
JetBrains系IDE（IntelliJ IDEA、PyCharm、Rider、RustRoverなど）でClaude Codeプラグインを入れたのに、統合ターミナルでclaudeを実行すると「No available IDEs detected」と出て終わる。あるいはIDE右上のClaude Codeボタンを押すと「Cannot launch Claude Code」の通知だけが表示されて何も起きない。
VS Code拡張機能なら情報がそこそこ出てくるが、JetBrains側は検索してもセットアップ手順の記事ばかりで、「動かなくなったときにどう切り分けるか」を書いたものがほとんど見当たらなかった。実際にAnthropicの公式GitHub Issueを漁ると、Rider・RustRover・PyCharmそれぞれで似たような報告が独立して上がっている。この記事では公式ドキュメントのトラブルシューティング項目を軸に、それぞれの症状に対応する実際のIssue報告を突き合わせて整理する。
結論 — 症状別の原因早見表
| 症状 | 主な原因 |
|---|---|
claude実行時に「No available IDEs detected」 | プラグイン未有効化／IDE未再起動／統合ターミナルを使っていない |
| WSL2環境で同上のエラー | WSL2のNATネットワークかWindowsファイアウォールが接続をブロックしている |
CLAUDE_CONFIG_DIRを設定した状態でのみ検出失敗 | プラグインがカスタム設定ディレクトリのロックファイルを見つけられない既知の不具合 |
| PowerShellからは検出できるのにプラグインだけ失敗 | CLIとプラグインでIDE検出ロジックの実装が食い違っている |
| Rider・RustRoverなど特定IDEでだけ「Cannot launch」 | プラグインのバージョンがIDE側の新しいビルドに追随できていない |
| DevContainer上のIntelliJ 2026で丸ごと動かない | IntelliJ 2026の新DevContainer構成にJetBrainsバックエンドが存在しない（既知の非対応） |
| Claudeアイコンを押すと「command not found」 | claudeがPATHにない、またはプラグインが実行ファイルを見つけられていない |
まずは自分がどのパターンに近いかをここで確認してから、該当する見出しに飛んでほしい。
前提 — プラグインはCLIを「呼び出す」だけの存在
まず押さえておきたいのが、JetBrainsプラグインは独自のClaude Code実行ファイルをバンドルしていないという点だ。プラグインがやっているのは、IDEの統合ターミナルでclaudeコマンドを実行し、そのプロセスに接続するところまで。つまり「プラグインが動かない」というトラブルの半分近くは、実はプラグイン自体ではなくCLI側のインストール状態やPATHの問題に起因する。
インストール手順自体は2ステップしかない。
claudeコマンドをCLIとして先にインストールしておく（PATHに通っていないとプラグイン側で「Claude Code を起動できません」という通知が出る）- JetBrainsマーケットプレイスから
Claude Code [Beta]プラグインを入れ、IDEを完全に再起動する
この前提を踏まえたうえで、症状別に見ていく。
症状1｜「No available IDEs detected」— IDEが検出されない
もっとも報告数が多いのがこのパターンだ。公式ドキュメントのトラブルシューティングでは、まず以下の4点を確認するよう案内されている。
- プラグインがインストールされて有効になっているか
- IDEを完全に再起動したか（複数回の再起動が必要なケースがある）
- IDEの統合ターミナルから
claudeを実行しているか（外部ターミナルからは/ideコマンドでの明示的な接続が必要） - リモート開発の場合、プラグインをリモートホスト側にインストールしているか
ここまでは基本チェックだが、実際のGitHub Issueを見ていくと、この基本チェックだけでは説明がつかないケースがいくつも報告されている。
WSL2環境での「No available IDEs detected」
Windows + WSL2の組み合わせでJetBrains IDEを使っている場合、原因は高確率でネットワークにある。公式ドキュメントには、WSL2のNATネットワークまたはWindowsファイアウォールが、WSL2側とWindowsホスト側で動くIDE間の通信をブロックしていることが原因だと明記されている（WSL1はホストのネットワークを直接使うため影響を受けない）。
対処法は2通りある。1つ目はWindowsファイアウォールにWSL2内部トラフィックを許可するルールを追加する方法で、既存のWSL2ネットワーク設定を変えずに済む分こちらが推奨されている。
# WSLシェル内でIPアドレスとサブネットを確認
hostname -I
# 例: 172.21.123.45 → サブネットは 172.21.0.0/16# PowerShellを管理者として実行
New-NetFirewallRule -DisplayName "Allow WSL2 Internal Traffic" -Direction Inbound -Protocol TCP -Action Allow -RemoteAddress 172.21.0.0/16 -LocalAddress 172.21.0.0/16ルール追加後、IDEとClaude Codeの両方を再起動すれば反映される。2つ目の方法はWSL2をミラーリングネットワークに切り替えることで、こちらはWindows 11 22H2以降が前提になる。ユーザーディレクトリの.wslconfigに以下を追加し、wsl --shutdownで再起動する。
[wsl2]
networkingMode=mirroredWindows 10環境ではミラーリングネットワークが使えないため、ファイアウォールルールの追加を選ぶことになる。
CLAUDE_CONFIG_DIRを設定していると検出が壊れる（Issue #6100）
2025年8月に報告されたIssueでは、環境変数CLAUDE_CONFIG_DIRを設定した状態でclaudeを起動すると、JetBrainsプラグインがIDEの検出に失敗し、claudeコマンド自体もIDEの位置を特定できなくなる現象が報告されている。報告者は仕事用と個人用でClaude Codeの設定ディレクトリを切り替えるためにCLAUDE_CONFIG_DIRをラップするシェルスクリプトを使っていたが、これを噛ませた途端にJetBrains連携だけが機能しなくなったという内容だった。このIssueは「対応予定なし」でクローズされており、根本的な修正は入っていない。複数のClaude Codeアカウントを設定ディレクトリの切り替えで使い分けている場合、JetBrains連携がうまくいかないときはまずこの環境変数の存在を疑ったほうがいい。
PowerShellでは検出できるのにプラグインだけ失敗する（Issue #13752）
2025年12月に報告された別のIssueでは、Windows + PyCharmの環境で興味深い非対称性が報告されている。Windows PowerShellから直接claudeを実行するとPyCharmが正しく検出されるのに、PyCharm統合ターミナルからJetBrainsプラグイン経由で実行すると「No available IDEs detected」になるというものだ。これはCLIそのものの検出ロジックとプラグイン側の検出ロジックが独立して実装されており、両者の間にズレが生じることがあるのを示している。切り分け方としては、まず外部のPowerShell/ターミナルからclaudeを起動して/ideコマンドでIDEが見えるかを確認し、見えるのにプラグイン経由だけ失敗する場合はプラグイン側の不具合を疑う、という順番が有効だ。
症状2｜「Cannot launch Claude Code」/ プラグインが動作しない
インストール済みのはずなのにIDE右上のClaude Codeボタンを押すと起動自体に失敗するケースは、プラグインとClaude Code CLIのバージョンの組み合わせに起因することが多い。
JetBrains Riderでの非互換事例（Issue #22549）
2026年2月に報告されたIssueでは、JetBrains RiderでClaude Codeプラグインが最新のCLIバージョンと噛み合わず、/ideコマンドがRiderを認識しない、claude doctorでもRiderが検出済みIDEとして表示されないという症状が報告されている。CLI側のIDE検出の仕組みに変更が入ると、プラグイン側のアップデートが追いつくまでの間、こうした一時的な非互換が起きることがある。対処としては、プラグインをJetBrainsマーケットプレイスの最新版に更新したうえで、それでも直らない場合はCLI側を1つ前の安定版に固定して様子を見るという手が現実的だ。
RustRover EAPでの再現例とMCPサーバーのノイズ（Issue #31938）
2026年3月に報告されたIssueは、RustRover 2026.1 EAP（Early Access Program、いわゆる先行体験版）でプラグインが「Cannot launch Claude Code」を表示し、/ideでも検出されないという内容だった。このIssueで興味深いのは、報告されたログの中にGitHub MCP用の環境変数GITHUB_PERSONAL_ACCESS_TOKENが未設定であることによるエラーメッセージが複数含まれていた点だ。これは直接の原因ではなく無関係なノイズである可能性が高いが、IDE検出のトラブルを調べているとMCPサーバー関連のエラーメッセージが紛れ込んでいて混乱する、というのは実際によくある。EAP版のIDEを使っている場合はそもそも動作保証の対象外になりやすいので、安定版のIDEで再現するかどうかを先に確認したほうが切り分けが早い。
対処の基本フロー
Rider・RustRoverに限らず、「プラグインが動作しない」系の症状全般に対して公式ドキュメントが挙げているチェック項目は次の4つだ。
- Claude Codeをプロジェクトルートディレクトリから実行しているか
- JetBrainsプラグインがIDE設定で有効になっているか
- IDEを完全に再起動したか（1回で直らなければ複数回試す）
- リモート開発の場合、プラグインがリモートホストにインストールされているか
Issueを見る限り、この4項目で解決しないケースの多くはIDEのEAP/ベータ版か、プラグインとCLIのバージョンのズレに行き着く。
症状3｜「command not found」— コマンドが見つからない
Claudeアイコンをクリックして「command not found」が表示される場合、これはIDE検出以前の問題で、プラグインがclaude実行ファイルの場所を特定できていない。対処は次の順番で進める。
# 1. ターミナルでインストール状態を確認
claude --versionclaude --versionが通るなら、CLI自体は正常にインストールされている。この場合はプラグイン設定側の問題なので、Settings → Tools → Claude Code [Beta] を開き、「Claude command」の項目にフルパスを設定する。claude、/usr/local/bin/claude、npx @anthropic-ai/claude-codeのいずれかの形式で指定できる。
WSLユーザーの場合はこの欄に直接claudeと書いても見つからないことが多い。公式ドキュメントではWindows側のプラグインからWSL内のClaude Codeを呼び出すコマンドとして、次の形式が案内されている（Ubuntuの部分は自分のディストリビューション名に置き換える）。
wsl -d Ubuntu -- bash -lic "claude"
DevContainer環境での既知の非対応（IntelliJ 2026、Issue #42774）
これは現時点で回避策が見当たらない、やや厄介なケースとして知っておいたほうがいい。2026年4月に報告されたIssueによると、IntelliJ IDEA 2026.1のネイティブDevContainerサポート（JetBrains Gatewayとは別の、コンテナを直接開く機能）を使ってプロジェクトを開いた場合、コンテナ内からClaude Codeを実行しても~/.claude/ide/にIDEのロックファイルが一切生成されず、/ideコマンドは常に「No available IDEs detected」を返す。
原因として報告されているのは、IntelliJ 2026がDevContainer内でJetBrainsバックエンドプロセスを実行しなくなったというアーキテクチャ変更そのものだ。これまでバックエンドプロセスが担っていたIDEブリッジ機能（ロックファイルの書き込みやIDE Bridge SSEエンドポイントの公開）が、この新方式では存在しなくなっている。このIssueは「対応予定なし」としてクローズされており、報告時点では再現性のある回避策は見つかっていない。
DevContainer上でJetBrains IDEとClaude Codeの連携を試すなら、ネイティブDevContainerサポートではなく従来のJetBrains Gateway経由でリモート開発する構成のほうが、現状は連携が機能する可能性が高い。
リモート開発（JetBrains Gateway）特有の罠
リモート開発を使っている場合、公式ドキュメントが明確に注意を促しているポイントがある。プラグインはローカルのクライアントマシンではなく、リモートホスト側にインストールする必要があるという点だ。Settings → Plugin (Host) からリモートホスト側にプラグインを入れないと、いくらローカル側で設定をいじっても連携が機能しない。ローカルとリモートの両方に別々にプラグインを入れてしまい、どちらが有効になっているか分からなくなるというのも報告としてはよくあるパターンなので、リモート開発環境でうまくいかないときはまずどちら側にプラグインが入っているかを確認したほうがいい。
セキュリティ面の注意 — acceptEditsモードとIDE設定ファイル
これは不具合ではないが、JetBrainsプラグインを使う上で公式ドキュメントが明示的に警告している点なので触れておく。Claude CodeをacceptEdits権限モード（ファイル編集を自動承認するモード）でJetBrains IDE上に実行すると、IDEが自動的に読み込むIDE設定ファイルまで無警告で書き換えられる可能性がある。IDE設定ファイルの変更はIDEによって自動的に実行されることがあるため、これがacceptEditsモードでのbash実行に対する権限プロンプトを事実上バイパスする経路になり得る、というのが公式の指摘だ。JetBrains IDE上でClaude Codeを使う場合は、少なくとも編集に対して手動承認モードを使うか、Claudeが信頼できるプロンプトでのみ動いていることを確認してからacceptEditsを使う、という運用が推奨されている。
それでも直らないときに集める情報
ここまでの症状に当てはまらない、あるいは対処しても直らない場合は、次の情報を揃えたうえでGitHub Issueを検索するか新規報告したほうが早い。
claude --version
claude doctorclaude doctorはインストール状態や検出まわりの内部診断を行うコマンドで、IDE検出に関する問題の一次切り分けに役立つ。加えて以下の情報も揃えておくと、既存Issueとの一致を確認しやすい。
- OS（macOS/Windows/Linux）とバージョン
- 使っているJetBrains製品名とバージョン（EAP版かどうかも重要）
- Claude Codeプラグインのバージョン
- WSL・DevContainer・リモート開発など、特殊な実行環境を使っているかどうか
CLAUDE_CONFIG_DIRなどの環境変数を設定しているかどうか
FAQ
PyCharm・WebStorm・GoLandでも同じ対処法でいい？
公式に対応が明記されているIDEはIntelliJ IDEA、PyCharm、Android Studio、WebStorm、PhpStorm、GoLandで、いずれも同じプラグインで動く。この記事で紹介した「No available IDEs detected」や「Cannot launch Claude Code」の切り分け手順は製品固有の話ではなく、プラグインとCLIの連携部分の問題なので、基本的にはどのJetBrains製品でも同じ順番で確認していけばいい。ただしRustRoverのようなEAP版が存在する製品では、安定版に比べて非互換が起きやすい点は考慮したほうがいい。
プラグインを一度アンインストールして入れ直せば直る?
「プラグインが動作しない」系の症状では有効なことが多い。ただし「No available IDEs detected」がWSL2のネットワークやDevContainerのアーキテクチャに起因している場合は、プラグインの再インストールでは直らない。まず自分の症状がどのパターンに近いかをこの記事の早見表で確認してから、再インストールで直る類のものかどうかを判断したほうが時間を無駄にしない。
JetBrains純正のAIアシスタントとClaude Codeプラグインは何が違う?
JetBrains純正のAI Assistant（Junieなど）はIDEに内蔵されたAI機能で、JetBrainsのサブスクリプションに紐づいている。一方Claude Codeプラグインは、あくまで外部のClaude Code CLIをIDEから呼び出して連携させるための橋渡し役で、Anthropicの有料サブスクリプション（Pro・Max・Team・Enterprise）またはConsoleアカウントが必要になる。この記事で扱っているトラブルはすべて後者、つまりCLIとIDEの連携部分の話だ。
まとめ
JetBrainsプラグインの「動かない」は、突き詰めると「IDE検出（No available IDEs detected）」「起動失敗（Cannot launch Claude Code）」「コマンド未検出（command not found）」の3系統に分かれる。公式ドキュメントのトラブルシューティングはこの3系統それぞれに基本チェック項目を用意しているが、それでも直らない場合はWSL2のネットワーク、CLAUDE_CONFIG_DIR環境変数、EAP版IDEとの非互換、DevContainerのアーキテクチャ変更といった、より個別性の高い原因に当たっていることが多い。エラーメッセージだけで検索する前に、まずclaude doctorと公式のトラブルシューティング項目を確認し、それでも一致しなければGitHub Issueで同じ環境の報告を探すのが結局は一番早い。
VS Code拡張機能との使い分けやMCP連携も含めたIDE周りの全体像は別記事にまとめているので、あわせて読んでほしい。
