Claude Code Plugins

変更前

バックグラウンドセッション(claude --bg)で作業中に、プラグインのLSPサーバーが終了したり標準入力を閉じたりすると、バックグラウンドセッション自体が終了してしまっていた。

変更後

プラグインが提供するLSPサーバーが終了した場合や標準入力を閉じた場合でも、バックグラウンドセッション(claude --bg)はそのまま動作し続けるようになった。

ユーザーへの恩恵

プラグインのLSPサーバーが落ちてもバックグラウンド作業が中断されなくなり、ユーザーは長時間タスクを安心して任せられるようになった。

変更前

`/plugin`コマンドのインストール済みタブで、プラグインの更新失敗のエラーメッセージなどにターミナル制御文字が含まれたまま表示されていた。

変更後

`/plugin`コマンドのインストール済みタブに表示されるメッセージから、ターミナル制御文字が取り除かれるようになった。

ユーザーへの恩恵

エラーメッセージが読みやすくなり、プラグインの更新失敗などの問題をすみやかに把握できるようになる。

変更前

プラグイン経由でインストールされた MCP サーバーが、/plugin の Installed 一覧でそのプラグインから切り離された形で単独の行として表示されていたため、そのサーバーがどのプラグインに由来するのか一覧上からは分からなかった。

変更後

/plugin の Installed タブで、プラグインに属さず単独で表示される MCP サーバーにカーソルを合わせると、そのサーバーがどのプラグインから提供されているかが行内に表示されるようになった。

ユーザーへの恩恵

MCP サーバー名だけでは出どころを特定できなかったユーザーが、一覧上で即座にどのプラグインがそのサーバーを提供しているかを判別できるようになる。

変更前

既にインストール済みのプラグインに対して claude plugin install を実行すると、マーケットプレイスに新しいバージョンが存在する場合にはそのことが表示され、更新方法として claude plugin update コマンドの名前も併せて示されるようになりました。

変更後

既にインストール済みのプラグインに対して claude plugin install を実行しても、そのプラグインの新しいバージョンがマーケットプレイスで提供されているかどうかは分からず、単に既にインストールされている旨だけが伝えられていました。

ユーザーへの恩恵

ユーザーはプラグインの新バージョンの有無をすぐ把握でき、更新が必要な場合にどのコマンドを実行すればよいか分かるようになりました。

変更前

npm ソースからプラグインを取得する際、パッケージの install scripts(preinstall / install / postinstall)が実行される可能性があった

変更後

npm ソースのプラグイン取得には npm pack --ignore-scripts を使い、取得したパッケージを検証してから導入する

ユーザーへの恩恵

悪意あるスクリプトが付属したパッケージでも、スクリプトを実行させずにプラグインを導入できる

変更前

プラグインの hooks/hooks.json のトップレベルに $schema を書くと、ドキュメントに記載のないキーとして unknown key の警告が出ていた。

変更後

hooks/hooks.json のトップレベルに $schema を書いても unknown key の警告が出ず、スキーマ参照をそのまま残せる。

ユーザーへの恩恵

hooks.json にエディタ補完用の $schema をそのまま置けるようになり、警告を気にせずスキーマ検証を活用できる。

変更前

VS Code 拡張の「Manage plugins」ダイアログで、プラグインの有効/無効を切り替えるトグルや、MCP サーバーダイアログの行がフォーカスできず、キーボードだけでは到達・操作できなかった。

変更後

VS Code 拡張の「Manage plugins」ダイアログで、プラグインの有効/無効を切り替えるトグルや、MCP サーバーダイアログの各行をキーボード操作で選択・操作できるようになった。

ユーザーへの恩恵

マウスを使わずにキーボードだけでプラグインの有効化や MCP サーバーの管理操作を完了できるようになる。

変更前

誰も待機していない場合、安全フィルターによる停止が Slack スレッドのコンテキストを黙ってリセットし、実行中のバックグラウンド処理がキャンセルされていた。

変更後

安全フィルターによる停止が発生した際、Claude が必ずその旨を伝えるようになり、まだ実行中のバックグラウンド処理をキャンセルしなくなった。

ユーザーへの恩恵

ユーザーはバックグラウンド処理の結果が失われる心配なく、安全フィルターによる停止がいつ発生したかを確実に把握できる。

変更前

inode 0 を報告する仮想ドライブ(Electric Drive などの暗号化ボリュームを Windows ドライブとしてマウントしたもの)から、最初のカスタムエージェント、スラッシュコマンド、出力スタイルは読み込めるが、2つ目以降は読み込まれなかった。

変更後

仮想ドライブ上に置かれたカスタムエージェント、スラッシュコマンド、出力スタイルが、最初の1つ以降もすべて読み込まれるようになった。

ユーザーへの恩恵

暗号化ボリューム上に複数のカスタムコンポーネントを置いても、すべて正しく読み込まれ、設定どおりに使えるようになる。

変更前

セッション終了時に Claude Code は LSP サーバーへ shutdown リクエストを送っていた。shutdown パラメーターを拒否するサーバー(例: rust-analyzer)ではこのリクエストが失敗し、その後の exit リクエストは送られないままだった。

変更後

セッション終了時に LSP サーバーへ shutdown リクエストを送り、サーバーが shutdown パラメーターを拒否して失敗した場合でも、続けて exit リクエストを送るようにした。これにより rust-analyzer のような LSP サーバーがプロセスを終了できず、セッション終了後も動き続けることがなくなった。

ユーザーへの恩恵

rust-analyzer など shutdown を拒否する LSP サーバーがセッション終了後もバックグラウンドで動き続けることがなくなり、不要なプロセスが残らなくなる。

変更前

claude plugin install、uninstall、update、enable、disable コマンドは人間が読めるテキスト出力のみを返しており、スクリプトから結果を機械的に判定するには出力をパースする必要があった。また、claude plugin list --json の各行にはエラーや注意の詳細を示すフィールドがなく、問題の内容を JSON から把握できなかった。

変更後

claude plugin install、uninstall、update、enable、disable に --json オプションが追加され、各コマンドの実行結果を JSON 形式で取得できるようになった。また、claude plugin list --json の各行に errorDetails と noteDetails フィールドが追加された。

ユーザーへの恩恵

プラグイン管理コマンドの成否や詳細を JSON で直接受け取れるため、CI やスクリプトからの自動化でプラグインの状態確認とエラーハンドリングを容易に行えるようになる。

変更前

ディレクトリ名が「..」で始まるプラグインパスを claude plugin validate に渡すと、実際にはプラグインローダーが受け入れるにもかかわらず、検証が誤って拒否していた。

変更後

「..example-plugin」のようにディレクトリ名が2つのドットで始まるパスでも、claude plugin validate が有効なプラグインとして正しく検証して通すようになった。

ユーザーへの恩恵

「..」から始まるディレクトリ名のプラグインでも、検証で不当に拒否されずにすむ。

変更前

VSCode拡張のManage pluginsダイアログでプラグインのインストール・有効化・無効化・アンインストールを行った場合、変更を開いているセッションに反映するには再起動が必要だった。

変更後

Manage pluginsダイアログで実行したインストール・有効化・無効化・アンインストールが、開いているセッションに即座に反映されるようになった。再起動なしで変更を適用できる。

ユーザーへの恩恵

プラグインの変更をセッションを中断せずにそのまま適用できるため、作業を続けながらプラグインを管理できる。

変更前

Artifact 公開時にページファイルが有効な UTF-8 でない、または置換文字 (U+FFFD) を含む場合、役に立たないエラーで公開に失敗していた。

変更後

Artifact 公開時にページファイルが UTF-8 として不正だったり置換文字 (U+FFFD) を含む場合でも、エラーに行番号と列番号が表示されるようになった。

ユーザーへの恩恵

ユーザーはエラーメッセージから修正すべき箇所を特定しやすくなり、問題を迅速に解決できる。

変更前

修正後は plugin.json にのみ存在する description や displayName も参照して補完するようになり、Discover/Browse 画面や claude plugin list --json --available の出力に、これらのプラグインの説明や表示名が正しく表示される。

変更後

/plugin の Discover/Browse 画面と claude plugin list --json --available コマンドが、marketplace.json のエントリにはメタデータがなく plugin.json のみに description や displayName が記載されているマーケットプレイス・プラグインの情報を、UI やコマンド出力に表示しないという不具合があった。マーケットプレイス側のメタデータだけを見ていたため、プラグイン本体の plugin.json にしか description や displayName が存在しない場合、空欄のまま表示されていた。

ユーザーへの恩恵

ユーザーはマーケットプレイスのエントリ側にメタデータがないプラグインでも、名称や説明を読んでインストール前に内容を把握できる。

変更前

インストール済みタブや claude plugin details で表示される表示用メタデータは、プラグイン自身の plugin.json を優先して参照していた。そのため、plugin.json に記載がない項目は表示されないことがあった。

変更後

インストール済みタブや claude plugin details で表示される名前や説明などの表示用メタデータが、まずマーケットプレイスエントリーから取得される。plugin.json にしかない項目は、これまでどおり plugin.json の値で補完される。

ユーザーへの恩恵

ユーザーはインストール済みタブや claude plugin details で、マーケットプレイスの登録情報と plugin.json の情報を組み合わせたメタデータを確認できるようになる。

変更前

バックグラウンドの Bash コマンドとして実行された CLI が stderr に <claude-code-hint /> タグを出力しても検出されず、raw タグがそのままモデルへの出力に混入していた。

変更後

バックグラウンドの Bash コマンドで実行された CLI が出力した <claude-code-hint> タグも検出され、該当プラグインのインストール候補として扱われる。raw タグがそのまま会話に漏れることはなくなる。

ユーザーへの恩恵

ユーザーはバックグラウンド実行の CLI が出したプラグインのインストール候補を見逃さず、会話にノイズが混入するのを避けられる。

変更前

headless session(non-interactive mode)では /reload-plugins コマンドが使えず、Claude Code Desktop や SDK のコマンド一覧にもこのコマンドが表示されていなかった。

変更後

ヘッドレスセッション(non-interactive mode)でも /reload-plugins スラッシュコマンドが実行できるようになり、Claude Code Desktop や SDK のコマンド一覧にもこのコマンドが表示されるようになった。

ユーザーへの恩恵

ユーザーはヘッドレスセッションでもプラグインの再読み込みを行えるようになり、Desktop や SDK のコマンド一覧でそのコマンドが確認できるようになる。

変更前

Claude Desktop などのホストアプリが URL マーケットプレイスをディレクトリとして保存している場合、そこからプラグインをインストールしようとすると 「marketplace entry path does not stay inside the marketplace directory」 というエラーで失敗していました。

変更後

URL マーケットプレイスから追加したプラグインを、ホストアプリがマーケットプレイスをディレクトリとして保存している場合でもインストールできるようになりました。これまで 「marketplace entry path does not stay inside the marketplace directory」 というエラーでインストールに失敗していました。

ユーザーへの恩恵

ホストアプリ経由でディレクトリとして保存された URL マーケットプレイスのプラグインも、エラーなくインストールできるようになります。

変更前

Claude apps ゲートウェイは、Claude Desktop が読み取れる形式とは異なる形式で orgPluginSettings を送信していたため、新しい Desktop バージョンでも組織レベルのプラグイン設定が正しく反映されない可能性があった。

変更後

Claude apps ゲートウェイが、Claude Desktop 1.15200.0 以降が読み取るリスト形式で orgPluginSettings を送信するようになった。

ユーザーへの恩恵

組織のプラグイン設定が Claude Desktop 1.15200.0 以降で正しく読み取られるようになり、古いバージョンの Desktop では単に無視されるため互換性が保たれる。

変更前

ネストされたオブジェクト内のフィールド名のスペルミスは検出されず、起動後にエラーや意図しない動作として現れていた

変更後

ネストされたオブジェクト内のフィールドのスペルミスでも、起動時にエラーで停止するようになった

ユーザーへの恩恵

設定ミスを起動時に確実に検出でき、問題の原因となったフィールド名がエラーメッセージで示されるようになる

変更前

プラグインの検証レポートは人間が読みやすい形式で出力されていました。

変更後

検証コマンドに --json オプションを指定することで、構造化された JSON データとして出力できるようになりました。

ユーザーへの恩恵

開発者はスクリプトや CI/CD パイプラインで検証結果を自動処理できるようになります。

変更前

以前のバージョンから会話を継続した際、Artifact の公開処理を実行すると「unexpected parameter note」というエラーが発生して失敗することがありました。

変更後

以前のバージョンから継続した会話でも、Artifact の公開処理が正常に動作するようになり、エラーが発生しなくなりました。

ユーザーへの恩恵

以前のバージョンから継続した会話でも、Artifact の公開を確実に行えるようになります。

変更前

GitHub のマーケットプレイスリポジトリ URL に末尾のスラッシュや ?/# が含まれていると、.git サフィックスが正しく付与されず、リポジトリのクローンが失敗していました。

変更後

GitHub のマーケットプレイスリポジトリ URL に末尾のスラッシュや ?/# が含まれていても、.git サフィックスが正しく付与され、リポジトリのクローンが正常に動作するようになりました。

ユーザーへの恩恵

マーケットプレイスの追加やプラグインのインストール時に、URL の形式に依存せず確実にリポジトリをクローンできるようになります。

変更前

ルーチン作成時にメッセージロール（system/user/assistant など）が設定されずに保存された場合、実行時にプロンプトが適用されず何も実行されない不具合がありました。

変更後

ルーチン作成時にメッセージロールが欠落していても、実行時にプロンプトが正しく適用されるようになりました。

ユーザーへの恩恵

意図せずルーチンが実行されない不具合が解消され、スケジュールされたタスクが期待通りに動作するようになります。

変更前

プラグインは宣言されたコマンドやスキルなどのパスを通じて、自身のディレクトリ外のファイルにアクセスできていました。特にシンボリックリンクを経由するパスでは、意図せず外部のファイルシステムにアクセスしてしまう可能性がありました。

変更後

プラグインが宣言したコマンドやスキルなどのパスを通じて、自身のディレクトリ外のファイルにアクセスできなくなりました。シンボリックリンクを含むパスは、セキュリティ上の理由からエラーとして拒否されます。

ユーザーへの恩恵

プラグインが意図せず外部のファイルシステムにアクセスするリスクが排除され、プラグインの隔離性とセキュリティが向上します。

変更前

バックグラウンドコマンドが timeout や setsid などのコマンドでシェルから切り離されると、親プロセスの終了やタスクの停止に関係なく実行し続けることがありました。

変更後

バックグラウンドコマンドがシェルから切り離された場合、親プロセスが終了したりタスクが停止されたりしても、そのコマンドは適切に終了するようになりました。

ユーザーへの恩恵

意図せず実行し続けるバックグラウンドプロセスが残ることを防ぎ、セッションの終了時にリソースが解放されるようになります。

変更前

Opus 4.7 以降のモデルで長い思考フェーズ中にストリームが沈黙し、バイトレベルのウォッチドッグが接続を切断していました。進捗イベントが送信されず、タイムアウトが発生していました。

変更後

ストリームが沈黙しなくなり、進捗イベントが適切に送信されるようになりました。バイトレベルのウォッチドッグが接続を切断するのを防ぎ、タイムアウトが発生しなくなりました。

ユーザーへの恩恵

長い思考フェーズ中も接続が維持され、タイムアウトによる中断が発生しなくなります。

変更前

GitLab マージリクエストに対して /code-review --comment を実行すると、対象がサポートされていない旨のエラーが報告されていました。

変更後

「glab mr note」コマンドを使用して、GitLab マージリクエストに直接コメントを投稿できるようになりました。

ユーザーへの恩恵

GitLab プロジェクトでコードレビューの結果をマージリクエストに直接コメントとして残せるようになります。

変更前

マーケットプレイスエントリで宣言されたプラグインコマンドがプラグインディレクトリ外を指すことができ、セキュリティリスクがありました。

変更後

プラグインコマンドがプラグインディレクトリ外を指すことを防ぐように修正しました。そのようなパスはパストラバーサルエラーで拒否されます。

ユーザーへの恩恵

プラグインのセキュリティが向上し、悪意のあるパストラバーサル攻撃を防げます。

変更前

別の Claude Code プロセスが同時にプラグインマーケットプレイスを更新していた場合、バックグラウンドセッションが時折プラグインスキルなしで開始され、そのままの状態で継続していました。

変更後

別の Claude Code プロセスが同時にプラグインマーケットプレイスを更新していた場合でも、バックグラウンドセッションはプラグインスキルなしで開始されることはなくなりました。

ユーザーへの恩恵

プラグインスキルが正しくロードされ、セッションの機能が完全に利用可能になります。

変更前

以前は、入力した内容を送信またはクリアする前に、プラグイン/LSP のインストール提案や自動モードのデフォルト提案が表示されていました。そのため、Enter キーでプロンプトを送信すると、それらの提案に応答してしまうことがありました。

変更後

現在は、入力した内容を送信またはクリアしてから、プラグイン/LSP のインストール提案や自動モードのデフォルト提案が表示されるようになりました。これにより、Enter キーでプロンプトを送信しても、それらの提案に応答してしまうことはなくなりました。

ユーザーへの恩恵

入力中に誤って提案に応答してしまうことを防ぎます。

変更前

GitHub CLI トークンに workflow スコープがない場合でも警告は表示されませんでした。

変更後

トークンに必要なスコープがない場合に警告が表示されるようになりました。

ユーザーへの恩恵

ワークフロー設定の失敗を未然に防げます。

変更前

セッションレジストリの更新に失敗したとき、/rename は黙って確認していました。

変更後

セッションレジストリの更新に失敗したとき、/rename は黙って確認するのではなく、他のセッションが古い名前を表示している可能性があることを通知するようになりました。

ユーザーへの恩恵

プラグインの名前変更後に、他のセッションが古い名前を表示し続ける問題をユーザーが認識できるようになります。

変更前

バージョン指定のないマーケットプレイスプラグインのライブキャッシュディレクトリが、2回目のスコープインストール時に削除・再作成されていました。これにより、実行中のセッションに影響を与える可能性がありました。

変更後

バージョン指定のないマーケットプレイスプラグインのライブキャッシュディレクトリが、2回目のスコープインストール時に削除・再作成される問題が修正されました。これにより、実行中のセッションに影響を与える可能性がなくなりました。

ユーザーへの恩恵

プラグインのインストール中に実行中のセッションが中断されるリスクがなくなります。

変更前

プラグインマーケットプレイスでは、制御文字や不可視文字を含む名前が許可されていました。また、マーケットプレイス提供テキストがそのまま出力されるため、セキュリティリスクが存在していました。

変更後

プラグインマーケットプレイスでは、制御文字や不可視文字を含む名前が拒否されるようになりました。また、マーケットプレイス提供テキストはエスケープ安全になり、出力が安全になりました。

ユーザーへの恩恵

プラグインのセキュリティが強化され、悪意のあるプラグインや不正なテキストによるリスクが軽減されます。

変更前

プラグインキャッシュで、同じプラグインに対して重複した SHA 名のディレクトリが作成されていました

変更後

プラグインキャッシュで、同じプラグインに対して重複した SHA 名のディレクトリが作成されなくなりました

ユーザーへの恩恵

プラグインのキャッシュ管理が正確になり、ディスク容量の無駄遣いがなくなりました

変更前

プラグインスキルのフロントマター name にすでに <plugin>: プレフィックスが含まれている場合、スラッシュメニューでそのプレフィックスが重複して表示されていました

変更後

プラグインスキルのフロントマター name にすでに <plugin>: プレフィックスが含まれている場合、スラッシュメニューでそのプレフィックスが重複して表示されなくなりました

ユーザーへの恩恵

プラグインスキルのコマンド名が正しく表示されるようになり、使い勝手が向上しました

変更前

インストール済みプラグインに対して、ベア名（完全修飾名以外）を指定して claude plugin update を実行すると失敗していました

変更後

インストール済みプラグインに対して、ベア名（完全修飾名以外）を指定して claude plugin update を実行できるようになりました

ユーザーへの恩恵

プラグインの更新コマンドが使いやすくなり、管理の手間が軽減されました

変更前

UTF-8 のバイト順マーク (BOM) を含む plugin.json でプラグインのインストールが失敗していました。

変更後

UTF-8 のバイト順マーク (BOM) を含む plugin.json でもプラグインのインストールが正常に動作するようになりました。

ユーザーへの恩恵

BOM を含む plugin.json でもプラグインを正常にインストールできるようになります。

変更前

skills/*/SKILL.md でスキルを定義しているプラグインに対し、/reload-plugins がスキル数を 0 と報告していました。

変更後

skills/*/SKILL.md でスキルを定義しているプラグインに対し、/reload-plugins が正しいスキル数を報告するようになりました。

ユーザーへの恩恵

正しいスキル数を確認できるようになります。

変更前

フックのエラーメッセージに解決されたプラグインパスではなく、リテラルの ${CLAUDE_PLUGIN_ROOT} が表示されていました。

変更後

フックのエラーメッセージに解決されたプラグインパスが正しく表示されるようになりました。

ユーザーへの恩恵

エラーメッセージから正しいパスを確認できるようになります。

変更前

claude.ai から同期されたプラグインの OpenTelemetry プラグインイベントで、plugin_id_hash が正しく反映されていなかったり、enabled_via が適切に設定されていなかったりしていました。

変更後

claude.ai から同期されたプラグインの OpenTelemetry プラグインイベントで、plugin_id_hash がプラグインの実際のマーケットプレースを反映するようになり、enabled_via は管理者インストールされたプラグインの場合は admin-install となります。

ユーザーへの恩恵

プラグインの監視データが正確になり、プラグインの管理とトラッキングが正確に行えるようになります。

変更前

両方のプラグインが --plugin-dir で読み込まれた場合、marketplace フィールドで宣言された依存関係が解決されないことがありました。

変更後

依存関係が正しく解決されるようになりました。

ユーザーへの恩恵

プラグインの読み込みエラーが減り、開発環境の安定性が向上します。

変更前

LSP プラグインが無効化された後も LSP ツールが保持されたままでした。

変更後

LSP ツールが正しく解放され、変更の前に警告が表示されるようになりました。

ユーザーへの恩恵

不要なリソースの保持が防止され、メモリ使用量が最適化されます。

変更前

claude.ai から同期されたプラグインと、手動でインストールした同名のローカルプラグインが競合した場合に上書きされる懸念がありました。また、同期されたプラグインを明確に区別して有効化・無効化する手段が提供されていませんでした。

変更後

同期されたプラグインは name@synced の形式で明確に識別され、claude plugin enable/disable <name>@synced で個別に制御できます。ローカルに自身でインストールしたプラグインが勝手に上書きされることもありません。

ユーザーへの恩恵

自分で導入したプラグインの設定を壊される心配をすることなく、同期プラグインとローカルプラグインを安全に共存させることができます。

変更前

カタログ取得時のヘッダーは静的な値のみ利用可能でした。

変更後

コマンドを実行し、その出力を認証用ヘッダーとして利用できるようになります。

ユーザーへの恩恵

認証が必要な非公開カタログへのアクセス時に、トークンの手動更新が不要になります。

変更前

インストール時以外でもバックグラウンドで headersHelper が再実行される可能性がありました。

変更後

コマンドの実行前に内容が表示され、ユーザーの承認が必要になりました。

ユーザーへの恩恵

知らない間にプラグインの認証用コマンドが勝手に実行されることを防げます。

変更前

管理者が strictKnownMarketplaces で特定の信頼された Git ホストのみにプラグインの取得元を制限していても、SCP スタイルの接続文字列を偽装することで、制限をバイパスして意図しないホストからプラグインを導入できてしまう抜け穴がありました。

変更後

SCP 形式の Git URL に対しても厳密なホストチェックが入り、接続先が管理ポリシーで許可されたマーケットプレイスに正確に合致するかどうか、ネットワーク通信の前に厳密に強制検証されます。

ユーザーへの恩恵

組織内の開発者が、管理者の意図しない非公式の外部サーバーから悪意あるプラグインを誤って取り込んでしまうセキュリティリスクについて不安を抱く必要がなくなります。

変更前

プロジェクト側で独自に作成した review スキルなどが優先される際、Claude Code 組み込みの /review などのショートカット用エイリアスまで連動して無効化され、「不明なコマンド」としてエラーになっていました。

変更後

ユーザー定義スキルが同名の同梱スキルを上書き（シャドウイング）している場合でも、組み込みエイリアスは衝突せずに正常に動作を維持します。

ユーザーへの恩恵

プロジェクトごとに同名のカスタムスキルを作成しても、慣れ親しんだ組み込みのショートカットコマンドをそのまま併用できます。

変更前

開発中のスキル定義ファイル（SKILL.md）のフロントマター（メタデータ部分）に構文エラーがあっても、事前に検証する手軽な方法がなく、実際に実行してロードエラーになるまで不具合に気づきにくい状態でした。

変更後

プラグインのパッケージ化をしていないシンプルな .claude/skills ディレクトリであっても、検証コマンドを実行するだけでフロントマターの記述ミスを一括検知できます。

ユーザーへの恩恵

カスタムスキルを自作する際、実際に動かしてみることなくコマンド一発でメタデータの設定ミスを発見し、修正できるようになります。

変更前

プラグインマーケットプレイスの追加において、GitLabのリポジトリURL（ネストされたサブグループを含む）がGitHub用の形式と誤認されたり、クローン失敗時のエラーが不適切だったりしました。

変更後

https://gitlab.com から始まる裸のリポジトリURLを適切に識別してクローンでき、認証失敗時には実際のGitホスト名に応じた適切なトラブルシューティング用のヒントを表示します。

ユーザーへの恩恵

GitLabで管理されている自社専用のプライベートプラグインマーケットプレイスを、複雑なURL指定なしで簡単にインストールできるようになります。

変更前

プラグインマーケットプレイスを追加・制限するための設定項目名が複雑で長く、開発者やシステム管理者が直感的に覚えにくい状態でした。

変更後

直感的なエイリアスである additionalMarketplaces（追加用）と allowedMarketplaces（許可リスト用）がサポートされ、以前のキーと同様に解釈されます。

ユーザーへの恩恵

設定ファイルやポリシー定義を作成する際に、複雑な設定キーの綴りをドキュメントで毎回確認して記述する手間がなくなります。

変更前

ブロック対象のマーケットプレイスをURLで指定している場合、CLIの内部処理でgit clone形式に変換されたリポジトリに対してブロック制限が機能しないエッジケースがありました。

変更後

ポリシーエンジンの判定が強化され、指定されたブロックURLと実行されたgit clone操作のリレーションが確実にマッチングされ、ネットワークアクセスやクローンを防止します。

ユーザーへの恩恵

システム管理者が特定のセキュリティ規制ポリシーを定義する際、迂回経路による未承認マーケットプレイスへのアクセスを確実に遮断できます。

変更前

チームメンバーや開発元が新しいプラグインをマーケットプレイスにアップロードした後、ローカルのClaude Codeでそれをインストールしようとすると、一旦手動で /plugin marketplace update を実行しないと「プラグインが見つかりません」とエラーになっていました。

変更後

インストールコマンドがターゲットのマーケットプレイスを認識すると、インストール処理の直前にバックグラウンドで自動的にカタログをリフレッシュし、最新リリースのプラグインをそのままフェッチします。

ユーザーへの恩恵

新しく公開された便利な拡張プラグインを試す際、事前のカタログ手動更新コマンドを実行してからインストールするという2ステップの手間がなくなります。

変更前

IDE などの外部ツールでプラグインのパスが変わるたびに、Claude Code の再起動やプラグインの手動再インストールが必要でした。

変更後

ローカルコマンドを介してパスが動的に再解決され、Claude Code を再起動することなく、その場でプラグインの最新状態がリンクされて反映されます。

ユーザーへの恩恵

開発中のプラグインを書き換えるたびにインストールコマンドを実行したり、CLIを立ち上げ直したりする必要がなくなります。

変更前

対話モードに入らずにコマンドラインから直接プラグイン操作を行うと、不要になったはずの管理ファイルが削除されずに残り続け、古いキャッシュディレクトリがハードディスク上に蓄積し続けていました。

変更後

コマンド終了時に生存ファイルが即座にクリーンアップされ、バックグラウンドでの不要プラグイン削除スイープが正常に機能するようになります。

ユーザーへの恩恵

プラグインのインストールやアップデートを繰り返しても、不要な古いバージョンがディスク容量を無駄に圧迫するのを自動で防ぐことができます。

変更前

ローカル開発のためにシンボリックリンク(symlink)で作成したプラグインをテストしている際、14日間の猶予期間を管理するバックグラウンドのプラグインキャッシュクリーンアップ機能が働き、唯一のバージョンであっても開発用実体をキャッシュから誤って削除していました。

変更後

シンボリックリンクを介して配置されている開発中のプラグインが、クリーンアップ処理の対象から正しく除外され、アクティブな開発バージョンが維持されます。

ユーザーへの恩恵

プラグイン開発時に、シンボリックリンクした検証用コードがバックグラウンドクリーンアップによって勝手に削除されるのを防ぎ、開発作業に専念できます。

変更前

複数の階層(User/Project/Managed設定)をマージする際、上位の優先度を持つ設定でプラグインマーケットプレイスの定義を上書きしようとしても、下位階層の設定に記述されていたカスタムヘッダーなどの配列・オブジェクトデータの一部が部分マージされて残ってしまっていました。

変更後

マーケットプレイスの定義項目が検出された場合、マージ処理は部分的なマージを行わず、上位の定義全体で下位の定義を完全に置き換えるようになります。

ユーザーへの恩恵

管理者が設定したマーケットプレイスポリシーや認証ヘッダーが、ユーザーのローカル設定によって意図せず上書き・干渉されるのを防ぎます。

変更前

マーケットプレイスにリストされる個々のプラグインを配布する際、GitHub、gitリポジトリ、npmパッケージ、またはローカルの相対パスしか指定できませんでした。そのため、gitやnpmの環境が利用できない場合にプラグインを配信する手軽な方法がありませんでした。

変更後

HTTPS経由でダウンロード可能なzipアーカイブファイルをプラグインのソースとして指定できるようになります。また、セキュリティ確保のためにSHA-256のチェックサムを記述してバージョンを固定することも可能になります。

ユーザーへの恩恵

開発者がgitやnpmなどのパッケージマネージャーを介さずに、信頼できるWeb上のzipファイルからプラグインを安全に直接インストールできるようになります。

変更前

特定の GitHub 組織（Organization）配下にある複数のマーケットプレイスリポジトリに対して許可やブロックを制御する際、リポジトリを1つずつ個別に管理設定ファイルへ追加する必要があり、組織全体の統制を手間なく行うことが困難でした。

変更後

管理設定で "owner/*" という形式のワイルドカードを使用できるようになり、特定の GitHub 組織が所有するすべてのマーケットプレイスリポジトリを一括で許可またはブロック対象に指定できます。

ユーザーへの恩恵

組織内の開発環境におけるプラグインマーケットプレイスの利用制限を、リポジトリごとに個別登録することなく、組織単位でまとめて安全に管理できるようになります。

変更前

コロンの使用が予期せぬ名前空間の衝突を招き、プラグイン機能と競合する可能性がありました。

変更後

コロンはプラグイン専用の区切り文字として確保され、ファイル名に使用できなくなりました。

ユーザーへの恩恵

将来的な名前空間の衝突による不具合を未然に防げます。

変更前

真偽値としてtrue/falseのみがサポートされており、記述の柔軟性が低く不便でした。

変更後

yes, no, on, off, 1, 0も許容され、直感的な記述が可能になりました。

ユーザーへの恩恵

構成ファイルの作成時に、慣れた形式で柔軟にフラグを記述できます。

変更前

プラグインのスキル名が正しく表示されず、どのプラグイン由来か特定できない状態でした。

変更後

スキル名とプラグイン名の紐付けを維持し、補完時にプレフィックスが正しく適用されるようになりました。

ユーザーへの恩恵

多数のプラグインを使っている環境でも、迷わずに正しいコマンドを選択できるようになります。

変更前

Windowsのファイルパス制限により同期が不安定になることがありました。また、会話をリセット(/clear)すると、内部で使用しているWeb検索やフェッチ用のプロキシ接続が切れてしまい、検索ができなくなる問題がありました。

変更後

ディレクトリの命名がより堅牢になり、Windows環境での信頼性が向上しました。また、コンテキストをクリアしても内部プロキシの状態が維持されるようになり、一貫してWebツールを利用できます。

ユーザーへの恩恵

Windows環境やWeb検索を多用するワークフローにおいて、ツールが突然使えなくなるトラブルを避けられるようになる。

変更前

/mcp コマンドなどで設定をリロードすると、インストール済みのプラグインが提供している MCP サーバーまで誤ってシャットダウンされてしまうことがあった。

変更後

サーバーの再同期プロセスにおいて、プラグイン由来のサーバーとユーザー設定のサーバーが正しく区別され、プラグイン側の接続が維持されるようになった。

ユーザーへの恩恵

MCP ツールを使用するプラグインを有効にしている際、設定変更のたびにプラグインが動作しなくなる問題を回避できます。

変更前

Windows 環境やネットワークドライブ上でプラグインを更新・インストールする際、ファイルがロックされているとリネームに失敗し、一時ファイルが残骸として残ってしまうことがあった。

変更後

ファイルロックに対する堅牢なリトライ処理と、失敗時の一時ファイル削除が実装された。

ユーザーへの恩恵

Windows 環境でプラグインのインストールや更新が失敗して環境が汚れる心配がなくなります。

変更前

SDK を介したセッション開始直後にプラグインの自動読み込みが重なると、プログラムから渡したカスタムエージェントの定義が上書きされて消えてしまうことがあった。

変更後

初期化時のリクエストパラメータとプラグインからの情報を正しくマージして管理するように修正された。カスタム構成が予期せずリセットされることはない。

ユーザーへの恩恵

SDK を利用した高度なカスタマイズを行っている際に、原因不明のエージェント消失に悩まされることがなくなります。

変更前

ユーザー設定値をシェルの文字列として直接展開していたため、設定値に悪意のある文字が含まれていた場合に予期しないコマンドが実行されるセキュリティリスク（シェルインジェクション）がありました。

変更後

変数の展開がより安全な方法（環境変数や直接の引数渡し）に限定され、不正なコマンド実行が防止されるようになりました。

ユーザーへの恩恵

プラグインをより安全に利用できるようになり、セキュリティを維持しつつ便利なカスタマイズが可能になります。

変更前

共有のリポジトリ設定ファイルにプラグインのオプションが記述されていると、開発者ごとの個別の設定が上書きされたり、意図しない設定が強制されたりすることがありました。

変更後

プラグインの挙動を決定する重要なオプションは、ユーザー自身が管理する設定か、組織による強制設定に限定されるようになりました。

ユーザーへの恩恵

個人の好みの設定がプロジェクト共有設定によって勝手に変更されることがなくなり、各開発者に最適な環境を保てます。

変更前

実際にはバックグラウンドで動作している LSP プラグインが、誤って未使用と判定され削除を推奨されることがありました。

変更後

LSP の稼働状況を正しく判定するようになり、不適切な通知が抑制されます。

ユーザーへの恩恵

必要なツールを誤って削除してしまう心配がなくなり、正確な利用状況が把握されます。

変更前

あるプラグインのLSPサーバーが初期化に失敗すると、同一ファイル拡張子を扱う他の正常なLSPサーバーまで機能しなくなる問題がありました。

変更後

個々のLSPサーバーのライフサイクルが分離され、失敗が連鎖しないよう改善されました。

ユーザーへの恩恵

開発環境の信頼性が向上し、1つのプラグインの不具合がコーディング支援全体を止めることを防ぎます。

変更前

LSPが正しく機能していても、プラグイン自体が利用不可とみなされることがありました。

変更後

診断情報などのアクティビティを正しく検知するようにしました。

ユーザーへの恩恵

LSPプラグインの稼働状況が正確に可視化され、不要な通知がなくなります。

変更前

特定のコマンド引数の順序によって、プラグインのコンポーネントが正しく読み込まれない場合がありました。

変更後

フラグの指定順序に関わらず、プラグインが正しく認識され一覧に表示されます。

ユーザーへの恩恵

コマンド入力時の柔軟性が向上し、期待通りにプラグインを読み込めるようになります。

変更前

ローカルプラグインの検証が正しく完了せず、開発効率が低下していました。

変更後

すべてのプラグインとエラークラスが適切に検証されるようになりました。

ユーザーへの恩恵

開発中のプラグインに関するエラーを漏れなく確認でき、修正サイクルが早まります。

変更前

特定の設定ファイルで有効化されたプラグインが、パスごとに不必要にインストール同意を求めていました。

変更後

ローダーパスに関わらず、適切な権限管理下で動作するように修正されました。

ユーザーへの恩恵

プラグイン導入時の手間が削減され、スムーズに作業を開始できるようになります。

変更前

マーケットプレイス上の名称と設定ファイル内の名称が不一致だと、プラグインの管理コマンドが正常に動作しないケースがありました。

変更後

内部識別子と表示名の紐付けが最適化され、プラグイン管理が正常に行えるようになりました。

ユーザーへの恩恵

インストール済みのプラグインを確実に管理・切替できるようになり、環境構築の信頼性が向上します。

変更前

マーケットプレイス上でプラグインの名称が変更された際、ユーザー側の設定ファイル(settings.json)には古い名前が残ったままになり、依存関係の解決や更新に支障が出る可能性がありました。

変更後

マーケットプレイスの名称変更マップ(renames maps)を自動的に参照するようになり、プラグイン名が変更されるとユーザーの設定も新しい名前に自動的に追従して更新されます。

ユーザーへの恩恵

プラグインの名称変更をユーザーが手動で監視して設定を書き換える手間がなくなり、常に最新の名称で正しくプラグインを利用し続けることができます。

変更前

インストール済みのプラグインが増えると管理が煩雑になり、使わなくなった古いプラグインが残り続けていました。

変更後

最近使用していないプラグインが優先的に表面化されるようになり、不要なプラグインのクリーンアップが容易になりました。

ユーザーへの恩恵

ツールの肥大化を防ぎ、常に必要な機能だけが有効な最適な開発環境を維持できます。

変更前

インストールしたプラグインによって提供されているスキルを、プラグインの管理画面から直接確認することができませんでした。

変更後

Installedタブ内にSkillsセクションが設けられたことで、各プラグインがどのスキルを導入したのかが一目で分かるようになりました。

ユーザーへの恩恵

プラグインを通じて追加された新機能を把握しやすくなり、適切なスラッシュコマンドを選択して実行することが容易になります。

変更前

リストの先頭を表示している状態でもスクロール可能であることを示す表示が出てしまい、UIの正確性が損なわれていました。

変更後

スクロール位置を正しく判定し、適切なインジケーター表示が行われるようになりました。

ユーザーへの恩恵

UIの一貫性が向上し、リストの末端を正しく把握できるようになります。

変更前

マーケットプレイスからのプラグインインストールが失敗した際にデータを残す設定を有効にしていると、新しいプラグインの初回インストールまでブロックされることがありました。

変更後

デバッグ用の設定を有効にした状態でも、正常に新しいプラグインを導入できるようになりました。

ユーザーへの恩恵

プラグイン開発時やトラブルシューティング時でも、インストール機能を損なうことなく効率的に作業が進められます。

変更前

使用状況の表示が大まかな合計値に限られており、どのスキルや MCP サーバーがどれだけのトークンを消費しているのか詳細を把握することが困難でした。

変更後

時間枠ごとの内訳や、キャッシュ効率、さらには特定のカスタムツールごとの消費量が視覚化され、詳細なコスト分析が可能になりました。

ユーザーへの恩恵

使用量の多い要因を特定してプロンプトを最適化したり、特定のツールのコスト対効果を評価したりすることが可能になります。

変更前

/plugin コマンドからマーケットプレイスを閲覧する際、目的のプラグインを見つけるにはリストをスクロールして探す必要がありました。

変更後

マーケットプレイス内に検索バーが搭載され、プラグイン名やキーワードで素早くフィルタリングできるようになりました。

ユーザーへの恩恵

数多くのプラグインの中から、自分の作業に必要なスキルや MCP ツールを即座に見つけてインストールできます。

変更前

長いプラグインリストから戻った際にカーソル位置がリセットされたり、Esc キーを押した際に意図しないタブに戻ってしまうなど、UI 操作に不便な点がありました。

変更後

リストの閲覧状況が保持され、Esc キーによるナビゲーションも直感的な遷移に統一されました。

ユーザーへの恩恵

多くのプラグインを比較・管理する際の画面遷移ストレスが軽減され、UI 操作がより快適になります。

変更前

特定のプラグインやフックが原因で Claude Code が正常に動作しない場合、原因を特定するために設定ファイルを個別に書き換える必要がありました。

変更後

原因不明の挙動が発生した際、--safe-mode を使うことで純粋な Claude Code の状態で起動し、カスタマイズによる影響かどうかを即座に切り分けられます。

ユーザーへの恩恵

複雑な設定を維持したまま、問題発生時の原因究明を迅速に行えるようになります。

変更前

プラグインの起動速度が、本来不要なファイル展開処理によって遅くなっていました。

変更後

キャッシュが正しく維持されるようになり、二回目以降のプラグイン読み込みが高速化されました。

ユーザーへの恩恵

Windows 環境での Claude Code 起動からタスク開始までの待ち時間が短縮されます。

変更前

異常終了が重なると不要な一時ファイルが増え続け、場合によってはプラグインの動作を阻害する可能性がありました。

変更後

古いロックファイルが定期的に掃除されるようになり、長期間の使用でもディレクトリがクリーンに保たれます。

ユーザーへの恩恵

メンテナンスを意識することなく、プラグイン機能の安定性が長期的に維持されます。

変更前

インストールされているプラグインの状態を確認するには、タブベースの /plugin マネージャーを開いて個別に確認する必要がありました。

変更後

コマンドラインから直接プラグインを一覧表示できるようになり、有効・無効の状態に応じたフィルタリングも可能です。

ユーザーへの恩恵

開発フローを止めることなく、現在の環境に導入されている拡張機能を素早く確認・管理できるようになります。

変更前

自作のスキルやプラグインを使用する場合でも、マーケットプレイスを経由するか、特定の登録手順を踏む必要がありました。

変更後

.claude/skills ディレクトリにファイルを配置するだけで、Claude Code が自動的にプラグインとして認識し、読み込むようになります。

ユーザーへの恩恵

開発中のカスタムスキルを即座に試せるようになり、プラグイン開発のイテレーションが大幅にスピードアップします。

変更前

新しいプラグインを作成する際、ディレクトリ構造や manifest ファイルを手動で一から作成する必要がありました。

変更後

専用の init コマンドにより、推奨される構造を持つプラグインのスケルトンが瞬時に生成されます。

ユーザーへの恩恵

ボイラープレートの作成時間を節約し、スキルの実装そのものに集中できるようになります。

変更前

プラグインの管理やインストール時に、正確なプラグイン名やコマンド名を記憶に頼って入力する必要がありました。

変更後

タブ補完により、インストール済みのものや利用可能なマーケットプレイス上のプラグインをリストから簡単に選択できます。

ユーザーへの恩恵

入力ミスを防ぎ、複雑なプラグイン名の指定やサブコマンドの実行がスムーズになります。

変更前

プラグインをインストールすると、原則としてその機能が自動的に有効化されるため、特定のプロジェクトや環境でのみ使いたい機能も常にロードされてしまうことがありました。

変更後

「インストールはしているが無効」という状態をプラグイン側で定義できるようになりました。ユーザーが必要なタイミングで明示的に有効化して使い始めることができます。

ユーザーへの恩恵

多数のプラグインを管理しつつ、メインのエージェントの動作やコンテキストを不要なプラグイン機能で汚染させずに、必要な機能だけを厳選して利用できます。

変更前

マーケットプレイスに多数のプラグインがある中で、自分の現在のプロジェクト(言語やスタック)に役立つものがどれなのか、自分で探して判断する必要がありました。

変更後

ディレクトリ内のファイル構成や信号を検知し、TypeScriptプロジェクトならTypeScript LSPプラグインを、Git管理下ならコミットツールを、といった具合に自動で推奨プラグインが提示されます。

ユーザーへの恩恵

プロジェクトのセットアップに必要な拡張機能を迷うことなく導入でき、Claude Codeの能力を最大限に引き出す環境を素早く構築できます。

変更前

Git LFSを使用している大規模なリポジトリからプラグインをインストールする際、常にすべてのLFSアセットがダウンロードされていました。

変更後

マーケットプレイスの設定で skipLfs を有効にすることで、不要なバイナリファイルのダウンロードを回避し、インストール時間を短縮できます。

ユーザーへの恩恵

帯域幅の節約とプラグイン導入の高速化につながり、特にバイナリデータが多い環境での開発効率が向上します。

変更前

マーケットプレイスの削除時にスコープが指定できなかったため、他の管理コマンドとの操作感に不整合がありました。

変更後

ユーザー、プロジェクト、ローカルの各スコープを明示的に指定してマーケットプレイスを管理できるようになり、設定の対称性が確保されました。

ユーザーへの恩恵

特定のプロジェクトに紐付いたマーケットプレイスだけを確実に削除するなど、構成管理が直感的になります。

変更前

異なる設定で複数の MCP サーバーを起動しようとしても、実行コマンドが同じだと同一のものとみなされ、一部のサーバーが起動しない問題がありました。

変更後

環境変数の違いが正しく認識されるため、同一のバイナリを異なるコンテキスト(例：別々の API キーやプロジェクト ID)で並列動作させることができます。

ユーザーへの恩恵

複雑なプラグイン構成において、意図したすべての外部ツールが正しく Claude に接続されるようになります。

変更前

過去にインストールして現在は存在しないプラグインのゴミが設定に残っていると、診断コマンドが不適切なエラーを出し続けていました。

変更後

現在の環境に存在しない古い設定が適切に無視または処理されるようになり、診断結果の正確性が向上しました。

ユーザーへの恩恵

トラブルシューティング時に本来注目すべき問題に集中でき、ノイズのないクリーンな診断レポートが得られます。

変更前

利用制限の使用状況を確認する際、セッション全体のトークン消費量しか分からず、どの機能がコストを押し上げているのか特定が困難でした。

変更後

/usageコマンドの結果にカテゴリー別の詳細な内訳が追加され、スキルやプラグイン、特定のMCPサーバーが消費したコストを個別に把握できるようになりました。

ユーザーへの恩恵

どのツールが予算を消費しているかを正確に把握できるため、効率的なコスト管理や不要なMCPサーバーの停止などの最適化が容易になります。

変更前

カスタムエージェントが複数の種類のサブエージェントを使い分けるように定義しても、実際に呼び出せる種類が制限されてしまっていました。

変更後

定義したすべてのサブエージェントをエージェントが正しく認識し、タスクに応じて適切なエージェントを使い分けることが可能になります。

ユーザーへの恩恵

複雑なワークフローをプラグイン化する際、エージェント間の連携をより柔軟かつ高度に設計できるようになります。

変更前

プラグインの詳細画面で、実際の数よりも多くのスキルやエージェントが存在するように表示されることがあり、混乱を招いていました。

変更後

重複排除が正しく行われ、プラグインの内容が正確な数値で表示されるようになります。

ユーザーへの恩恵

インストールしている拡張機能の状態を正確に把握でき、管理がしやすくなります。

変更前

UIパーツが重なったり、余白が不自然だったりして、一部の画面で情報が見づらい箇所がありました。

変更後

各設定画面のレイアウトが整理され、視認性と操作性が向上します。

ユーザーへの恩恵

設定の確認や権限の管理などの管理作業を、より快適な画面でミスなく行えるようになります。

変更前

プラグインにどのような機能(コマンドやスキルなど)が含まれているかを確認するには、実際にインストールしてみるまで詳細が不明でした。

変更後

インストール前の詳細画面で、プラグインが提供する具体的なコンポーネント(スキルやフックの種類、MCPサーバー構成など)がすべて表示されます。

ユーザーへの恩恵

自分のニーズに合ったプラグインかどうかを事前に判断できるため、不要なプラグインのインストールを避け、安心して機能を拡張できます。

変更前

プラグイン開発時、スキルのパス設定に誤り(フォルダではなくファイルを指定)があってもバリデーションで見逃され、実行時に問題が発生することがありました。

変更後

バリデーションコマンドがこの誤りを検知し、親ディレクトリを指定するよう具体的な修正案を提示するようになりました。

ユーザーへの恩恵

プラグイン作成時の設定ミスを早期に発見でき、開発サイクルを短縮できます。

変更前

プラグインマネージャーで新しいプラグインを探したりインストール済みのものを管理したりする際、そのプラグインがいつメンテナンスされたものかを確認する術がありませんでした。

変更後

詳細ペインに「Last updated(最終更新日)」が表示されるようになり、プラグインの鮮度やメンテナンス状況を判断材料にできるようになりました。

ユーザーへの恩恵

より信頼性が高く、最新の機能に対応したプラグインを選択しやすくなり、安心して開発環境を拡張できます。

変更前

新しい環境をセットアップした直後や、プロジェクト固有の設定で指定されたプラグインがある場合に、プラグインがロードできず不親切なエラーメッセージが出るだけでした。

変更後

不足しているプラグインを検知し、どのようにインストールすべきかのアクション可能な解決策がユーザーに示されるようになりました。

ユーザーへの恩恵

新しいチームメンバーや新しい PC での作業開始時に、必要なプラグインの不足に悩まされることなく、素早く環境を整えることができます。

変更前

GitHub 等からプラグインを取得する際、セキュリティ上の理由で HTTPS を強制したい設定があっても、マーケットプレイスの操作時に無視されてしまうことがありました。

変更後

全てのプラグイン取得経路で HTTPS 優先設定が適用されるようになり、SSH キーが使えない CI 環境などでも安定して動作します。

ユーザーへの恩恵

ネットワーク環境の制限がある場所や、特定の通信プロトコルを強制したい企業のセキュリティポリシーを遵守しやすくなります。

変更前

プラグインの操作を完了した後、現在何が有効なのかを確認するために手動でタブを切り替える必要がありました。

変更後

操作完了とともに自動的にインストール済み一覧が表示されるため、変更結果をすぐに確認できます。

ユーザーへの恩恵

プラグイン管理の操作ステップが減り、環境構築をよりスムーズに進められます。

変更前

プラグイン間の依存関係が管理されておらず、依存先が不足している場合に実行時エラーが発生したり、手動での複雑な管理が必要でした。

変更後

依存関係にあるプラグインを無効化しようとすると、コピー可能なヒント付きで拒否され、逆に有効化する際は必要な依存プラグインが自動で一括有効化されます。

ユーザーへの恩恵

プラグイン構成の整合性が自動で保たれるようになり、依存関係の解決に悩むことなく拡張機能を安全に管理できます。

変更前

プラグインを導入する際、そのプラグインがどれほどコンテキストを消費し、コストに影響するかが事前に把握できませんでした。

変更後

マーケットプレイスでプラグインを探す際に、そのスキルの実行にかかるトークン量の目安を確認できるようになりました。

ユーザーへの恩恵

予算やプロジェクトの規模に合わせて、コスト効率の高いプラグインを選択するための判断材料が得られます。

変更前

プラグインが追加したカスタムエージェントを起動する際、完全な名前空間を指定しないと認識されず不便でした。

変更後

プレフィックスなしの名前でもプラグイン由来のエージェントを検索・起動できるようになりました。

ユーザーへの恩恵

カスタムエージェントの呼び出しがより短く簡単になり、コマンド入力の手間が省けます。

変更前

エージェントビュー経由でセッションを開始する際、特定のディレクトリ追加や設定ファイルを反映させることができませんでした。

変更後

--add-dir, --settings, --mcp-config, --plugin-dir フラグを claude agents で指定し、一括適用できます。

ユーザーへの恩恵

プロジェクトごとに最適化した設定で、複数のバックグラウンドタスクを効率的に並行管理できます。

変更前

セッションをバックグラウンドへ移行させると、起動時に指定していた --mcp-config や --settings などの一時的なフラグ効果が失われていました。

変更後

移行後のプロセスも元のセッションが持っていたすべての設定フラグを継承し、環境が完全に維持されます。

ユーザーへの恩恵

複雑なツール構成やディレクトリ構成のまま、安心してバックグラウンドへ作業をスイッチできます。

変更前

これまでのプラグイン構造では、スキルを定義するために必ず skills/ という特定のサブディレクトリを作成する必要がありました。

変更後

プラグインのルートディレクトリに SKILL.md を置くだけでスキルとして公開・利用できるようになり、単純なプラグイン構成がよりシンプルになりました。

ユーザーへの恩恵

小さな単一機能のプラグインを作成する際の手間が減り、より直感的に機能を拡張できるようになります。

変更前

プラグインがどのような言語サーバー(LSP)を提供しているかを確認する直接的な手段がなく、コードインテリジェンス機能の依存関係が不明確でした。

変更後

プラグインの管理画面や詳細コマンドから、そのプラグインが提供する具体的な LSP サーバー名を確認できるようになりました。

ユーザーへの恩恵

開発言語に合わせた適切なプラグインが正しくインストールされているか、また必要なバイナリが揃っているかを簡単に把握できます。

変更前

カレントディレクトリをスキルの参照先として指定すると、プラグインディレクトリ外への不正アクセスとして誤認され、エラーが発生する場合がありました。

変更後

ルートパス指定の検証ロジックが修正され、適切なスキル読み込みが可能になりました。

ユーザーへの恩恵

プラグイン開発時のディレクトリ構成の自由度が高まり、構成エラーに悩まされることがなくなります。

変更前

GitHub上のプラグインソースをインストールする際、デフォルトでSSHプロトコルが使用されていたため、SSHキーが設定されていない環境ではクローンに失敗することがありました。

変更後

環境変数CLAUDE_CODE_PLUGIN_PREFER_HTTPSを設定することで、SSHの代わりにHTTPSを使用してプラグインをダウンロードできるようになります。

ユーザーへの恩恵

Dockerコンテナ内や新規構築したばかりの開発環境など、SSHキーの管理が難しい場所でもスムーズにプラグインを導入・管理できます。

変更前

プラグイン管理画面において、キーボードによるタブ間の移動や、マウスを使ったタブの選択・検索ボックスの操作が制限されていました。

変更後

右矢印キーやTabキーでのタブ切り替えが可能になり、フルスクリーンモードではタブヘッダーや検索ボックスを直接クリックして操作できるようになりました。

ユーザーへの恩恵

多数のプラグインを導入している環境でも、目的のプラグインの検索や設定変更をより直感的かつスピーディーに行えます。

変更前

プラグインの特定のSHAをピン留めしていても、参照元のブランチ名(ref)がGitHub側で削除されているとインストールが失敗してしまっていました。

変更後

SHAによる固定が有効であれば、上流のブランチがなくても目的のバージョンのプラグインをインストールできるようになります。

ユーザーへの恩恵

外部リポジトリの構成変更に左右されず、プロジェクトで合意した特定のプラグインバージョンを安定して利用し続けられます。

変更前

プラグインが個別の設定ファイル(.mcp.json)でMCPサーバーを定義している場合、UI上のサーバー件数カウントに反映されないバグがありました。

変更後

すべての定義方法を網羅して正しくカウントされるようになり、プラグインに含まれる機能を正確に把握できます。

ユーザーへの恩恵

導入したプラグインによって「どのツールが追加されたか」の確認が容易になり、使いこなしやすくなります。

変更前

必要な環境変数が足りないなどの理由で接続に失敗した際、単純に「失敗」とだけ表示され、解決策が分かりませんでした。

変更後

「設定の問題(config issue)」として明示され、修正のためのヒントが表示されるようになります。また、一部の不正な設定が他の正常なサーバーに悪影響を与えることもなくなりました。

ユーザーへの恩恵

MCPサーバーのトラブルシューティングが格段に早くなり、開発作業を止める時間を最小限に抑えられます。

変更前

管理者によって指定された追加のプラグインマーケットプレイス設定が、ローカルの永続化ファイルに反映されず、自動更新が期待通りに動作しない場合がありました。

変更後

管理ポリシーに基づくマーケットプレイス情報が正しく保存されるようになり、配布されたプラグインの更新が継続的に行われるようになります。

ユーザーへの恩恵

組織全体で配布しているカスタムプラグインが常に最新の状態に保たれるようになり、管理の手間が軽減されます。

変更前

プラグイン構成ファイルの設定によって特定のフォルダが暗黙的に読み込み対象外になっても通知がなく、機能が動かない原因の特定が困難でした。

変更後

/doctor やプラグインリスト表示時に警告が表示されるようになり、構成上の問題にすぐ気づけるようになりました。

ユーザーへの恩恵

プラグイン開発やカスタマイズ時のトラブルシューティングが容易になり、構成ミスを素早く修正できます。

変更前

インストールされているプラグインが具体的にどのようなスキルやMCPサーバーを含んでいるのか、またそれらがどれほどコンテキスト(トークン)を消費するのか不明透明でした。

変更後

詳細コマンドにより、プラグイン内部の構造と、それがセッション開始時に消費する推定トークン数を事前に確認できます。

ユーザーへの恩恵

プラグインによるコンテキストの肥大化を防ぎ、トークンコストを意識した効率的な環境構築が可能になります。

変更前

MCPサーバーが現在のプロジェクトのルートパスを知る標準的な方法がなく、プロジェクト固有のパスを扱うのが困難でした。

変更後

フックと同様にプロジェクトディレクトリ情報が渡されるため、サーバー側でプロジェクト相対パスを正確に処理できます。

ユーザーへの恩恵

プロジェクトごとに異なる設定ファイルやデータにアクセスするMCPツールの開発が容易になります。

変更前

新しいプラグインが追加されていても、手動でマーケットプレイスを更新しない限り「見つからない」とエラーになっていました。

変更後

インストール時に自動で最新のカタログを確認しに行くため、常に最新のプラグインを即座に導入できます。

ユーザーへの恩恵

不要な「カタログ更新」の手間が省け、プラグイン導入体験がよりスムーズになります。

変更前

インストール済みプラグインの情報表示が煩雑で、どのフックやサーバーが提供されているか視認しにくい状態でした。

変更後

各コンポーネントが整理された形式で表示されるため、プラグインがシステムに与える影響を一目で理解できます。

ユーザーへの恩恵

プラグインの管理が容易になり、特定の機能(フックやツール)がどこから提供されているかの混乱を防げます。

変更前

どのスキルがどのプラグインによって追加されたものか判別できず、管理や設定変更が不便でした。

変更後

コンテキスト一覧にプラグイン名が付記されるため、スキルの出所が明確になります。

ユーザーへの恩恵

特定のスキルの挙動を変更したい時に、どのプラグインを操作すべきか即座に判断できます。

変更前

アップデートを行うとプラグイン同士のリンクが壊れてしまい、共通ライブラリ等を参照しているプラグインが動作しなくなることがありました。

変更後

更新後もディレクトリ構造やリンク関係が正しく保持され、プラグインが正常に機能し続けます。

ユーザーへの恩恵

プラグインの更新を安心して行えるようになり、メンテナンスの手間が軽減されます。

変更前

VS Code拡張機能、JetBrainsプラグイン、またはAgent SDKを使用している際、セッションをクリアすると .mcp.json やプラグイン経由のMCPサーバー設定が同期されず、ツールが利用できなくなっていました。

変更後

内部的な接続管理が修正され、セッションをリセットした後も既存のMCPサーバー接続や接続済みのコネクタが正しく保持されるようになりました。

ユーザーへの恩恵

セッションを切り替えるたびに外部ツールとの再接続を待つ必要がなくなり、シームレスな開発作業を継続できます。

変更前

長時間のセッション中、バックグラウンドでクリーンアップ処理が走ると、現在実行中のフックが必要とするプラグイン資産まで削除され、エラーが発生することがありました。

変更後

実行中のセッションで使用されているプラグインバージョンのロック管理が改善され、フック実行中に必要なファイルが消失しないようになりました。

ユーザーへの恩恵

バックグラウンドのメンテナンス処理を気にすることなく、安定してプラグインや自動化フックを利用し続けることができます。

変更前

プラグイン設定の記述方法によって意図せずスキルが読み込まれなかったり、指定ミスがあってもエラーが出ずに無反応だったりするため、デバッグが困難でした。

変更後

スキルの自動検出ロジックが整理され、設定ミスがある場合にはサイレントに失敗するのではなく、明確なエラーメッセージが表示されるようになりました。

ユーザーへの恩恵

プラグイン開発時のミスに気づきやすくなり、カスタムスキルの導入がより確実になります。

変更前

/myplugin review のように引数を伴うような形式のプラグインコマンドを実行しようとしても、正しく認識されず実行できないことがありました。

変更後

コマンドのパース処理が改善され、スペースを含むカスタムプラグインコマンドも確実に実行できるようになりました。

ユーザーへの恩恵

プラグインによって追加された高度な機能を、自然なコマンド入力で利用できます。

変更前

削除のショートカットに r キーが割り当てられており、再試行(Retry)を意図して誤って削除してしまうリスクや、他のメニュー操作との不整合がありました。

変更後

削除のショートカットが d (Delete) に変更され、直感的でミスの少ないキー操作に統一されました。

ユーザーへの恩恵

キーボード操作がより予測可能になり、誤操作によるプラグイン設定の紛失を防げます。

変更前

URLから直接プラグインを読み込む手段がなかったため、一度ローカルにダウンロードしてからディレクトリを指定して読み込む必要がありました。

変更後

--plugin-urlフラグにURLを直接指定するだけで、そのセッション中のみ有効なプラグインを即座にインストールできるようになります。

ユーザーへの恩恵

自作プラグインや公開されているツールを、ローカルに保存する手間なく手軽に試用・活用できるようになります。

変更前

themesやmonitorsといった試験的な機能が、プラグイン設定ファイルのトップレベルで宣言されていました。

変更後

これらは"experimental": { ... }の中に記述することが推奨されるようになり、古い形式では検証時に警告が表示されます。

ユーザーへの恩恵

プラグインの設定構造が整理され、どの機能が安定版でどれが試験段階であるかが明確になります。

変更前

プラグインをローカルでテストしたり配布したりする際、常に解凍されたディレクトリ形式で指定する必要がありました。

変更後

zip 圧縮されたプラグインファイルを直接指定してロードできるようになりました。

ユーザーへの恩恵

プラグインの配布や共有がより簡便になり、アーカイブを解凍する手間を省いて素早く実行環境を構築できます。

変更前

プラグインの削除やキャッシュのクリーンアップ後も、内部の管理ファイルに古いパスが残り続け、実行時の環境変数 PATH に不要なディレクトリが含まれていました。

変更後

プラグインのパス管理がクリーンになり、有効なプラグインのパスのみが適切に環境へ適用されます。

ユーザーへの恩恵

システム環境をクリーンに保ち、パスの肥大化による予期せぬ挙動を防ぎます。

変更前

npm を通じてインストールしたプラグインに新しいバージョンがリリースされても、更新コマンドがそれを検知できず、古いまま使い続ける必要がありました。

変更後

npm レジストリの最新情報を正しくチェックできるようになり、最新のプラグイン機能やバグ修正を即座に適用できます。

ユーザーへの恩恵

常に最新のサードパーティ拡張機能を安全に利用し続けることができます。

変更前

自動化スクリプト等で JSON 出力を利用している際、--plugin-dir で指定した開発中プラグインの読み込みに失敗しても、その詳細なエラー情報が JSON 構造に含まれていませんでした。

変更後

依存関係の競合だけでなく、指定したディレクトリからの読み込み失敗も構造化データとして取得できるようになり、エラーハンドリングが容易になります。

ユーザーへの恩恵

CI やツール連携において、プラグイン関連のトラブルシューティングをプログラムから確実に行えるようになります。

変更前

外部からの通知やメッセージを受け取るための --channels フラグを使用して Claude Code を起動している場合、プランモードでのコード調査や計画立案に必要なツールが正しく読み込まれない不具合がありました。

変更後

チャンネル機能を利用している間も、通常時と同様にプランモードの全機能が正常に動作するようになります。

ユーザーへの恩恵

CIの結果やチャットツールからの入力を監視しながら、同時にプランモードで安全なコード変更の検討を行うことが可能になります。

変更前

/pluginコマンドでプラグインを削除した際、実際には削除されているにも関わらず、完了メッセージに「Enabled(有効化)」と誤ったステータスが表示されていました。

変更後

削除完了時に正しく「Uninstalled」と表示されるようになりました。

ユーザーへの恩恵

コマンドの結果を正しく把握できるようになり、意図した操作が確実に行われたことを安心して確認できます。

変更前

プラグインの更新やアンインストールを繰り返すと、使用されていない古い依存関係がキャッシュディレクトリに残ったままになり、ディスク容量を無駄に消費する場合がありました。

変更後

新しい prune コマンドにより、どのプラグインからも参照されていない孤立した依存関係を一括で掃除できるようになりました。アンインストール時に --prune フラグを付けることで、関連する不要なファイルも同時に削除できます。

ユーザーへの恩恵

開発環境のディスク容量をクリーンに保つことができ、不要なファイルによるストレージの圧迫を防げます。

変更前

プラグインやマーケットプレイスの設定ファイルの検証ルールが厳格すぎたため、JSON スキーマの指定やメタデータの一部の記述がバリデーションエラーの原因となっていました。

変更後

公式スキーマへの参照やバージョン情報をより柔軟に記述できるようになり、エディタでの補完機能を活用しながら正しく検証を行えるようになります。

ユーザーへの恩恵

プラグイン開発者が標準的な JSON 開発のベストプラクティスを適用しやすくなり、開発効率と設定ファイルの保守性が向上します。