プラグインの詳細メニューに「Configure options」だけが表示され、「Configure」が表示されない場合、何を意味しますか？
このプラグインが内蔵 MCP サーバーをバンドルしておらず、自身の userConfig 設定項目のみを宣言していることを意味する。この場合「Configure options」を完了すれば十分で、もう一つの設定を見落とす心配はない——そもそも2つ目の設定は存在しないからだ。
逆に「Configure」のみが表示され「Configure options」が表示されない場合は、プラグイン自体はカスタム設定項目を公開していないが、接続設定が必要な内蔵 MCP サーバーを含んでいることを意味し、その場合「Configure」が唯一対処すべき入口となる。
claude Plugin configure というシェルコマンドは、/plugin パネルに入って「Configure」をクリックするのと実質的にどう違いますか？
両者が最終的にトリガーするのは同じ設定ロジックであり、違いはインターフェースと使用シナリオにある。/plugin パネルはインタラクティブで、実行中の Claude Code セッション内で手動でメニューを操作する必要がある。一方 claude plugin configure はインタラクティブセッションに入らずシェルから直接実行できるコマンドで、デプロイスクリプトや CI パイプライン、手動でのインターフェース操作が不便な自動化シナリオでより実用的である。
日常的にインタラクティブに Claude Code を使う個人開発者にとっては、どちらの方法でも目的は達成でき、どちらを選ぶかは主にその時点で既にインタラクティブセッションにいるかどうかによる。
プラグインの更新で userConfig に新しいフィールドが追加された場合、既存の設定値は保持されますか、それとも再度入力し直す必要がありますか？
公開ドキュメントにはこのシナリオについての明確な説明はないが、既存のフィールドの値は通常保持される（設定ファイルに保存されており、プラグインのコード更新自体が設定ファイルに触れることはないため）と合理的に推測できる。新しく追加されたフィールドのみ別途入力が必要になる。より慎重なアプローチは、プラグイン更新後に能動的に一度「Configure options」を開き、新しいフィールドが現れていないか、既存の値が今のニーズに合っているかを確認することであり、更新後も全て変わらないと想定しないことだ。
プラグインに bundled MCP server が含まれているかどうかを、インストール後ではなく事前に知る方法はありますか？
インストールフローの2番目のステップ（プラグインが追加するものの確認）でこの情報を確認できる——詳細ペインの「Will install」セクションには、プラグインが追加するコマンド、エージェント、スキル、フック、MCP および LSP サーバーがリストされる。このリストに MCP サーバーの項目が現れれば、そのプラグインは bundled MCP server を含んでおり、後で「Configure」という入口が必要になる可能性が高い。
ローカルまたはカスタムマーケットプレイスからインストールしており、パネルが具体的なリストではなく「Components will be discovered at installation」と表示する場合、事前に知る方法はなく、インストール完了後のサマリーメッセージか「Installed」タブの詳細情報を確認するしかない。
Claude Code のプラグインをインストールした後、API キーやカスタムパス、機能の切り替えなどユーザー入力が必要な場合、「Configure options」と「Configure」という似た名前の2つの選択肢が表示されることがある。最近のリリースで追加されたシェルコマンド claude Plugin configure <plugin> により、インタラクティブなパネルを開かずにこれを実行できるようになったが、より理解すべきなのは、この2つの「Configure」ボタンが全く異なる基盤メカニズムに対応している点だ。間違った方をクリックしてもエラーにはならないが、意図した効果は得られない。
プラグインのマニフェストファイルに userConfig フィールドが宣言されていると、/plugin パネルのそのプラグインの詳細情報に「Configure options」という項目が表示される。これはプラグインの作者自身が定義した設定項目のセットに対応しており、ブール型の切り替え（サブ機能を有効にするかどうか）、文字列入力（カスタム出力フォーマットの好み）、あるいはプラグイン自体のロジックが読み取るその他のパラメータかもしれない。どのフィールドを公開するかは完全にプラグイン作者が決め、ユーザーが見るインターフェースもプラグイン自体が定義したもので、外部サービスとは無関係である。
もう一つの選択肢「Configure」は、プラグインが「bundled MCP server」（プラグイン自体にパッケージされた MCP サーバー）を含む場合にのみ表示され、この内蔵 MCP サーバー自身の user_config 設定に対応する——通常はこの MCP サーバーが外部サービスに接続するために必要な認証情報、例えば API キー、アカウント ID、サービスのエンドポイント URL などである。インストール概要に「Plugin is now active, but its bundled MCP server needs configuration before it can start」というメッセージが表示された場合、この MCP サーバーがまだ設定されていないことを示しており、「Configure」を完了しない限りこのサーバーは起動できず、それに依存するプラグインの機能は使えない。
これが最も混乱を招きやすい点だ：あるプラグインが userConfig を宣言し、かつ bundled MCP server を含んでいる場合、詳細情報メニューには「Configure options」と「Configure」の両方が同時に表示される。表面上は「options」という言葉の違いだけだが、背後では全く異なる2組の設定に対応しており、それぞれプラグイン自体の動作ロジックと、内蔵 MCP サーバーが外部サービスに接続できるかどうかに影響する。両者を同じものと誤解してどちらか一方だけ設定すると、「プラグインは正常にインストールされているように見えるが、外部データに依存する特定の機能が全く反応しない」という状況が起こり得て、原因究明に無駄な時間がかかりやすい。
これまではどちらの設定も完了するにはインタラクティブな /plugin パネルを開く必要があった。新しく追加された claude plugin configure <plugin> シェルコマンドにより、完全なインタラクティブセッションを立ち上げてメニューを手動でクリックする前に、スクリプトや非インタラクティブ環境から直接この設定フローを実行できるようになった——CI や自動デプロイスクリプトでプラグインを事前設定する必要があるチームにとって、これまで手作業でしかできなかったステップを省略できる。
ユーザー設定と bundled MCP server の両方を持つプラグインをチームが使っている場合、インストール後最初に確認すべきは両方の入口が入力を必要としているかどうかである——プラグインが「Active now」と表示されているだけですべて準備完了だと思い込んではいけない。特にインストール概要に「needs configuration before it can start」のような文言が含まれている場合、まだ完了していないステップがあることを示している。claude plugin configure コマンドをチームのプラグインデプロイスクリプトに組み込むことで、このステップを各自がパネルを手動で開くことに頼るのではなく、再現可能でバージョン管理可能なプロセスに変えられる。