Claude Code Plugins

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

マーケットプレイス内に古い形式や不明な形式のプラグインが1つでもあると、マーケットプレイス全体のリストが読み込めず、利用できなくなる問題がありました。

変更後

問題のある項目のみをスキップしつつ、ユーザーにアップデートが必要であることを通知し、他のプラグインは正常に利用可能になります。

ユーザーへの恩恵

プラグインリスト全体の可用性が高まり、一部の不整合によってツール全体が機能不全に陥るリスクが軽減されます。

変更前

管理設定で特定のマーケットプレイスをブロックするために hostPattern や pathPattern を指定しても、一部の条件下で強制力が不十分であったり、正しく評価されなかったりする可能性がありました。

変更後

設定された正規表現パターンに基づいてホストやファイルパスが厳密にチェックされ、ネットワーク通信やファイル操作の前にブロック対象かどうかが正しく判断されるようになりました。

ユーザーへの恩恵

組織の管理者が信頼できないプラグインソースをより確実に制限できるようになり、開発環境のセキュリティガバナンスを強化できます。

変更前

Windows 環境でプラグインのインストール直後などに、一部のツールが正常に読み込まれないことがありました。

変更後

キャッシュの状態に左右されず、プラグインのコンポーネントが正しく初期化されるように改善されました。

ユーザーへの恩恵

Windows ユーザーはプラグイン経由で提供される新機能を、より安定した状態で利用できます。

変更前

ユーザー設定で任意（Optional）となっている項目を空欄にしていると、プラグイン全体がエラーで動かなくなることがありました。

変更後

空の設定値が適切に処理され、必須でない設定がなくても正常に起動します。

ユーザーへの恩恵

プラグインのカスタマイズ性が向上し、必要最小限の設定だけでツールを使い始めることができます。

変更前

意図的に無効化したプラグインであっても、設定のリロード時や診断コマンドの実行時に、それらの読み込み失敗がエラーとして表示され、ユーザーを混乱させていました。

変更後

無効化されたプラグインは診断やリロードの対象から適切に除外され、不要なエラーメッセージが表示されないようになります。

ユーザーへの恩恵

必要なエラーのみが通知されるようになり、開発環境の健康状態を正しく、ノイズなしに把握できるようになります。

変更前

プラグインのリリース時に適切なバージョン管理やgitタグの作成を手動で行う必要があり、バージョンの不一致や人為的なミスが発生する可能性がありました。

変更後

claude plugin tag コマンドを使用して、plugin.json のバージョン情報に基づいた適切なgitタグを自動生成できるようになりました。

ユーザーへの恩恵

プラグイン開発者がリリースタグの作成ミスを防げるようになり、プラグインマーケットプレイスへの配布ワークフローがより安全かつ効率的になります。

変更前

あらかじめ用意されたプリセットのテーマから選択するだけで、ユーザー独自のカラー配色を作成したり、コミュニティが作成したテーマをプラグイン経由で手軽に導入したりする方法が制限されていました。

変更後

/theme メニューからカスタムテーマを管理できるほか、JSONベースでの柔軟な色の定義が可能になり、プラグインを通じて共有された特定のブランドテーマなども利用可能になりました。

ユーザーへの恩恵

開発環境の好みに合わせてCLIの配色を自由に変更できるため、視認性が向上し、お気に入りのエディタやターミナル設定と調和した快適な作業空間を作ることができます。

変更前

他のプラグインとのバージョン競合で更新がスキップされた場合、なぜ更新されないのかという理由が不透明で、トラブルシューティングが困難でした。

変更後

スキップの事実と具体的な理由が /doctor コマンドの結果や /plugin メニューのエラー詳細に明示されるようになりました。

ユーザーへの恩恵

プラグイン環境の不整合にいち早く気づき、適切なバージョン調整をユーザー自身で行えるようになります。

変更前

UI要素の一部でテキストと背景の色の組み合わせが悪く、視認性が低下している箇所がありました。

変更後

バッジや通知ボタンの配色が改善され、重要なステータス情報がはっきりと読めるようになりました。

ユーザーへの恩恵

インターフェースの使い心地が向上し、AI からの通知やプラグインの状態を素早く認識できます。

変更前

プラグインが既にある状態で再試行しても、以前の古い（または間違った）バージョンの依存パッケージがそのまま残ってしまうことがありました。

変更後

再インストール時に依存関係のチェックが改めて走り、正しいバージョンに更新されるようになりました。

ユーザーへの恩恵

プラグインのトラブル時に、再インストールによって問題を確実に解決できるようになります。

変更前

プラグインが一部壊れていたり、依存する他のプラグインが不足していても、本体がインストール済みだと「既に存在します」と表示され、修復が困難でした。

変更後

再インストールを試みるだけで、不足しているパーツや依存関係を自動的に検出し、補完してくれます。

ユーザーへの恩恵

プラグイン環境の不整合を簡単に解消でき、手動でのトラブルシューティングの手間を削減できます。

変更前

依存するプラグインが足りない場合、単にエラーが表示されるだけで、ユーザーが手動で必要なプラグインを探してインストールする必要がありました。

変更後

不足しているプラグイン名とインストール方法が明示され、さらにマーケットプレイスの追加に合わせて依存関係が自動的にセットアップされます。

ユーザーへの恩恵

複雑な依存関係を持つ高度な拡張機能も、最小限の操作で確実に導入できるようになります。

変更前

一部のプラグイン操作において、管理者によって制限された未承認のマーケットプレイスからの取得が完全に防げない可能性がありました。

変更後

インストールから自動更新に至るすべてのライフサイクルにおいて、承認済みのソースのみが許可されるよう厳格にチェックされます。

ユーザーへの恩恵

企業環境などにおいて、セキュリティポリシーに基づいた安全なプラグインのみが利用されることを保証します。

変更前

プラグインを更新したり再読み込みしたりする際、そのプラグインが必要とする別のプラグイン（依存関係）が不足していると、手動での対処が必要になることがありました。

変更後

既に追加済みのマーケットプレイス内に依存先が存在する場合、再読み込みや更新のタイミングで不足分が自動的にインストールされるようになりました。

ユーザーへの恩恵

複雑なプラグイン構成を導入している場合でも、依存関係の欠如によるエラーを防ぎ、常にプラグインが正しく機能する状態を維持できます。

変更前

プラグイン管理画面の「Installed」タブを表示した際、そのプラグインが「要注目」や「お気に入り」といった他のセクションの条件にも合致していると、リスト内に同じプラグインが2回並んで表示されていました。

変更後

各プラグインの状態やカテゴリにかかわらず、インストール済みリスト内では各項目が一度だけ適切に表示されるようになります。

ユーザーへの恩恵

プラグインの管理画面が整理され、現在インストールされている拡張機能の構成を正確かつ迅速に把握できるようになります。

変更前

既にインストール済みのプラグインと、新しく入れようとするプラグインの依存バージョンが矛盾していても、そのままインストールが進行して失敗することがありました。

変更後

インストール前に依存関係の整合性をチェックし、不可能な組み合わせについては明確な理由（バージョン競合）を表示して停止するようになりました。

ユーザーへの恩恵

プラグインの導入による環境破壊を防ぎ、常に安定した拡張機能を利用できます。

変更前

自動化スクリプトなどから実行した際、特定のプラグインがなぜ動作していないのかをプログラム的に検知して対処するのが困難でした。

変更後

プラグインの読み込み失敗理由がJSONストリームから直接取得できるようになり、デバッグや自動エラー報告の構築が容易になりました。

ユーザーへの恩恵

CI/CDや自動化ツールとの連携において、環境構築の問題を早期に発見して自動的にリトライや通知を行う仕組みが作りやすくなります。

変更前

プラグインの導入に失敗しても詳細な理由が分からず、またアップデート後も古いバージョンが参照されたり、失敗したインストールがゴミとして残ることがありました。

変更後

エラーメッセージが具体的になり、インストールのトラブルも自動的に修復される可能性が高まり、管理の信頼性が向上しました。

ユーザーへの恩恵

便利なプラグインを安心して追加・更新でき、環境構築のトラブルに悩まされる時間が減少します。

変更前

インストール済みのプラグイン一覧が増えると、重要なプラグインや頻繁に使用する項目を見つけるのが難しくなり、無効化したプラグインも混ざって表示されていました。

変更後

対応が必要なプラグインやお気に入りが上部に優先表示されるようになり、無効化されたプラグインは整理されて隠されます。さらにfキーによるショートカットでお気に入りの切り替えが可能になりました。

ユーザーへの恩恵

多数のプラグインを導入していても管理が非常に簡単になり、必要な機能に即座にアクセスできるため、開発環境のカスタマイズ性が向上します。

変更前

プラグインが他のライブラリや機能を必要としている場合でも、管理側のデータに不備があると依存関係が解決されず、インストール後にプラグインが動かないことがありました。

変更後

プラグイン自身の定義ファイル（plugin.json）を優先して読み込み、不足している依存関係を自動的にリストアップしてインストールするようになりました。

ユーザーへの恩恵

プラグインの導入がより確実になり、複雑な機能を持つ拡張機能もワンクリックで安心して利用開始できるようになります。

変更前

プラグインがバックグラウンドでシステムの状態や特定のイベントを継続的に監視する標準的な仕組みが不足していました。

変更後

プラグインのマニフェストに「monitors」キーを定義することで、セッション中ずっと動作し続けるバックグラウンドプロセスを簡単に管理できるようになりました。

ユーザーへの恩恵

CIの結果待ちやログの監視など、開発者が手動で確認しなくてもClaudeがバックグラウンドで状況を把握し、必要な時に通知してくれるようになります。

変更前

プラグインを導入しても、その動作に必要なNode.jsパッケージが自動でセットアップされず、手動での対応が必要になるケースがありました。

変更後

インストールまたはアップデート時に依存関係が自動的に解決されるようになり、導入後すぐにプラグインが利用可能になります。

ユーザーへの恩恵

プラグインの導入が簡単になり、セットアップの失敗による時間の浪費を防げます。

変更前

組織のポリシーでユーザーによるフックの追加を制限していると、IT管理者が配布したプラグイン内の必要なフックまでブロックされてしまうことがありました。

変更後

管理者が承認したプラグイン由来のフックは、制限下でも適切に実行されるようになります。

ユーザーへの恩恵

セキュリティを確保しつつ、組織で推奨される自動化ツールを確実に動作させることができます。

変更前

通信エラーなどでマーケットプレイスが更新できなかった場合、古い情報に基づいたまま静かに処理が完了してしまい、更新に失敗したことに気づけませんでした。

変更後

更新不可であったことが警告として明示されるようになり、最新版の確認が必要な際に適切に対処できます。

ユーザーへの恩恵

プラグインが古いバージョンのまま放置されるのを防ぎ、意図した通りの更新作業が行えます。

変更前

SDK利用時に処理を途中で中断すると、Claudeが起動した一時ファイルやプロセスが残留し、リソースを圧迫することがありました。

変更後

ループの中断などの終了処理に合わせて、不要になったリソースが即座に解放されるようになります。

ユーザーへの恩恵

Claude Agent SDKを使用した自動化ツールの信頼性とリソース効率が向上します。

変更前

特定のOS環境において、言語サーバーの場所を特定する際の処理を悪用されるセキュリティ上のリスクが存在しました。

変更後

外部からの入力に対してより堅牢なパス検出ロジックに変更され、安全性が向上しました。

ユーザーへの恩恵

悪意のあるバイナリ名等を通じた不正なコード実行のリスクが排除され、より安全に開発が行えます。

変更前

プラグインの管理やカスタムスキルの実行において、特定の高度な設定が正しく反映されなかったり、更新処理がOSの制限に抵触することがありました。

変更後

プラグイン・スキルの読み込みと実行エンジンが刷新され、複雑なカスタマイズも意図通りに動作するようになります。

ユーザーへの恩恵

独自のワークフローをプラグインとして構築・配布する際の信頼性と柔軟性が大幅に向上しました。

変更前

プラグインを更新したり新しくインストールした際、その変更を適用するために Claude Code 自体を立ち上げ直す必要がありました。

変更後

セッションを維持したまま、コマンド一つで最新のプラグイン機能を注入できるようになりました。

ユーザーへの恩恵

新しいツールを試したり開発中のプラグインを調整したりする際のデバッグサイクルが大幅に短縮されます。

変更前

プラグイン名によっては、/ メニュー自体が表示されなくなる不具合が発生していました。

変更後

名前が適切に文字列として処理されるようになり、あらゆる名称のプラグインを安定して利用できます。

ユーザーへの恩恵

プラグイン開発者が自由な命名を行えるようになり、ユーザーは予期せぬメニューの不具合に悩まされなくなります。

変更前

プラグインの作者が新機能をリリースしていても、CLI側でそれを検知できず、古いバージョンを使い続けてしまうことがありました。

変更後

リモートの更新が正しく検出され、常に最新のプラグイン機能を利用できるようになりました。

ユーザーへの恩恵

手動で再インストールする手間がなくなり、コミュニティやチームが提供する最新の改善を即座に享受できます。

変更前

「true」という名前のプラグインなど、特定の名称を持つプラグインをインストールすると、コマンド入力補完が機能しなくなるという珍しいが致命的な不具合がありました。

変更後

YAMLの特殊な単語が名前として使われても、型が正しく解釈され、UIが正常に動作するようになりました。

ユーザーへの恩恵

プラグインの命名規則に左右されず、常に安定したコマンド入力体験が得られます。

変更前

カスタム出力スタイルを適用すると、標準のコーディング指示（テストによる検証など）が除外されてしまい、特定のアドバイザー役をさせつつコーディングのベストプラクティスを維持させることが困難でした。

変更後

フロントマテリアルで keep-coding-instructions: true を設定することで、カスタムスタイルを適用したままClaudeの基本的なコーディングガイドラインを保持できるようになりました。

ユーザーへの恩恵

「解説重視」などの特定の役割を与えつつ、コードの品質や検証手順は妥協させないといった柔軟なカスタマイズが可能になります。

変更前

プラグイン内のスキルをディレクトリ参照で読み込む際、スラッシュコマンド名がディレクトリ名に依存していたため、インストール方法や配置によってコマンド名が変わってしまうリスクがありました。

変更後

ディレクトリ名に関わらず、スキルファイル内のフロントマテリアルで定義された name が一貫してスラッシュコマンド名として使用されます。

ユーザーへの恩恵

スキルの共有や配布において、ユーザーが常に同じコマンド名で機能を呼び出せるようになり、混乱を防ぎ、安定した利用体験を提供できます。

変更前

スキルファイル（SKILL.md）のフロントマテリアル内にフックを定義しても、システムに認識されず動作しない不具合がありました。

変更後

スキル定義内のフックが正しく読み込まれ、指定したイベントに応じて実行されるようになりました。

ユーザーへの恩恵

スキルのライフサイクルに合わせたカスタム動作を確実に行えるようになり、より高度なプラグイン開発が可能になります。

変更前

プラグインのインストール環境によっては CLAUDE_PLUGIN_ROOT 変数が正しく解決されず、フック内で相対パスを使用しているスクリプトなどが実行できないことがありました。

変更後

変数の解決ロジックが改善され、プラグインルートを基準としたファイル参照が安定して動作するようになりました。

ユーザーへの恩恵

プラグインの配布形式やユーザーの実行環境を問わず、フック機能が確実に動作するようになります。

変更前

自作のマーケットプレイスからプラグインをインストールした場合、起動時に ${CLAUDE_PLUGIN_ROOT} が実際のキャッシュ先ではなく、ソース側のディレクトリを指してしまうことがありました。

変更後

プラグインの読み込みプロセスが修正され、常にインストールされた実体のディレクトリを正しく参照するようになりました。

ユーザーへの恩恵

ローカルで開発・配布しているプラグインにおいて、スクリプトやリソースのパス指定ミスによるエラーを防止できます。

変更前

同じサーバー構成がWeb側とローカルプラグインの両方に存在し、Web側が未認証だと接続がスタックすることがありました。

変更後

プラグイン提供のMCPサーバーが独立して正しく初期化されるようになり、セッション開始時の待ち時間が解消されます。

ユーザーへの恩恵

ツール連携機能を備えたプラグインを導入していても、起動が遅延することなくすぐに作業を開始できます。

変更前

プラグインに独自の実行バイナリを含めても、Bashツールから呼び出すにはフルパスを指定するか、ユーザーが手動でパスを通す必要がありました。プラグイン固有のツール実行が煩雑でした。

変更後

プラグイン内の bin/ フォルダにある実行ファイルが自動的に認識され、あたかも標準コマンドのように名前だけで呼び出せるようになりました。

ユーザーへの恩恵

特定の言語やフレームワークに依存した高度な解析ツールなどをプラグインとして配布し、Claudeがそれらを自在に使いこなす環境を簡単に構築できます。

変更前

オフライン環境やネットワークが不安定な場所で git pull が失敗すると、マーケットプレイスのキャッシュが維持されず、プラグインの利用に支障をきたす場合がありました。

変更後

新しい環境変数を有効にすることで、更新に失敗しても手元のキャッシュが破棄されずに保持されます。

ユーザーへの恩恵

インターネット接続が制限された環境でも、既存のプラグイン機能を安定して使い続けることができます。

変更前

プラグインの削除時に設定やデータを残す選択をしたつもりが、正常に処理が完了しない、あるいは意図しない挙動になることがありました。

変更後

データの保持を選択してアンインストールする挙動が修正され、将来的な再インストールに備えて設定を残したまま安全に削除できます。

ユーザーへの恩恵

プラグインの整理や入れ替えを、カスタマイズした設定を失う不安なく自由に行えるようになります。

変更前

管理者がポリシーでプラグインを制限していても、ユーザーがマーケットプレイスで見つけてインストールを試みることができていました。

変更後

ポリシー設定がマーケットプレイスの表示やインストール操作に直接反映されるようになり、組織のルールを厳格に適用できます。

ユーザーへの恩恵

企業環境において、未承認のプラグインが誤って利用されるリスクを排除し、管理コストとセキュリティの安全性を高めることができます。

変更前

手動での移動や特殊なインストール構成によりパスが不一致になると、プラグインの有効化・無効化の切り替えができなくなることがありました。

変更後

インストール場所をより柔軟に解決するよう改善され、構成に差異があっても正しく状態を管理できるようになりました。

ユーザーへの恩恵

プラグイン管理操作の確実性が増し、環境構築時のトラブルに悩まされることが少なくなります。

変更前

TeamやEnterpriseプランの管理者は、どのチャンネルプラグイン（SlackやTelegram通知など）の使用を許可するかを個別に制限することができませんでした。

変更後

管理設定に allowedChannelPlugins が追加され、マーケットプレイスとプラグイン名のペアで構成される許可リストを定義できるようになりました。

ユーザーへの恩恵

組織のセキュリティポリシーに合わせて、承認済みの通信経路のみを限定して使用させることができ、安全な外部通知環境を構築できます。

変更前

組織レベルで Slack 連携などが設定されている環境で、ユーザーが個人的に同じ Slack 用プラグインをインストールすると、ツールが重複して表示されたり、挙動が不安定になったりしていました。

変更後

管理者が提供している機能と競合するプラグインが自動的に無効化され、一つの安定した接続が優先されるようになりました。

ユーザーへの恩恵

設定の競合によるトラブルが自動で回避され、常に組織の推奨設定に沿った最適な環境で作業できます。

変更前

プラグインが API キーなどの設定を必要とする場合、ユーザーが手動で設定ファイルを開いて編集する必要がありました。また、機密情報を平文の JSON ファイルに保存しなければならない場合もありました。

変更後

プラグイン有効化時に Claude Code が対話的に設定を促し、sensitive: true と指定された値はシステムのキーチェーンなどに暗号化して保存されるようになりました。

ユーザーへの恩恵

プラグインのセットアップが簡単かつ安全になり、複雑な初期設定なしで高度な拡張機能を利用し始められます。

変更前

非インタラクティブモード（-p）でスクリプトを実行する際も、通常のセッションと同様にフックの実行やプラグインの同期、メモリの読み込みが行われていました。

変更後

--bare フラグを使用することで、純粋にモデルの推論のみを高速に実行できるようになります。このモードでは OAuth 認証等がバイパスされるため、API キーの設定が必須となります。

ユーザーへの恩恵

CI/CD パイプラインや自動化スクリプトにおいて、不要なオーバーヘッドを削減し、起動速度の向上と実行の安定性を確保できます。

変更前

チャンネル機能を利用して離れた場所から Claude に指示を出している際、ツール実行の承認が必要になると、PC のターミナルに戻って操作する必要がありました。

変更後

対応するチャンネル（Telegram や Discord 等）を通じて、外出先からでもスマートフォン上でツールの実行を承認または拒否できるようになります。

ユーザーへの恩恵

PC の前にいなくても、チャットアプリを通じて安全に自律的なタスクの進行を管理・継続できる柔軟性が得られます。

変更前

プラグインを導入するには、外部のマーケットプレイスを登録するか、特定のディレクトリ構造にファイルを配置する必要があり、構成の管理が分散していました。

変更後

settings.json の plugins セクションに直接ソースを記述できるようになったため、設定ファイル一つでプラグインの有効化と構成を完結させることができます。

ユーザーへの恩恵

プロジェクトごとに必要なプラグインを settings.json に集約して記述できるため、チーム間での環境共有や設定のポータビリティが向上します。

変更前

特定のプラグインを推奨するヒント機能は、主にプロジェクト内のファイル構成（例：package.json の有無）に基づいて判断されていました。

変更後

環境にインストールされている CLI ツールの有無も検出対象に含まれるようになり、よりユーザーの作業環境に適したプラグインが提案されるようになります。

ユーザーへの恩恵

自分が普段使っているツールに最適な拡張機能を見つけやすくなり、Claude Code の機能を最大限に引き出す設定をスムーズに行えます。

変更前

プラグインの導入にはマーケットプレイスの追加とインストールという2段階のステップを意識する必要があり、初心者にはやや複雑でした。

変更後

インストール時のヒントが整理され、一つのコマンドを実行するだけで必要なセットアップが行えるようガイダンスがシンプルになりました。

ユーザーへの恩恵

新しいスキルの拡張をより手軽に行えるようになり、Claude Code を自分好みにカスタマイズするハードルが下がります。

変更前

コンテナ環境などでプラグインを事前配置するためのシードディレクトリは1つしか指定できませんでした。

変更後

Unix系では :、Windowsでは ; を使うことで、複数のディレクトリからプラグインを読み込めるようになりました。

ユーザーへの恩恵

共通のプラグインセットとプロジェクト固有のセットを組み合わせて配置するなど、環境構築の柔軟性が高まります。

変更前

プラグインが更新されると、そのプラグインが保持していたデータや状態が失われる可能性がありました。

変更後

永続的なデータディレクトリ ${CLAUDE_PLUGIN_DATA} が導入され、アップデート後も設定やデータを引き継げるようになりました。

ユーザーへの恩恵

プラグインの再設定が不要になり、長期的な利用における利便性とデータ安全性が向上します。

変更前

プラグインに含まれるサブエージェントの思考レベルや最大ターン数、使用禁止ツールの制限を詳細に制御することが困難でした。

変更後

サブエージェントの定義ファイル（frontmatter）から、これら高度なパラメーターを直接指定できるようになりました。

ユーザーへの恩恵

開発者はエージェントの挙動をより精密にチューニングしたプラグインを配布・利用できるようになります。

変更前

プラグイン開発時に YAML のパースエラーやスキーマ違反があっても、実行するまで気づけないことがありました。

変更後

バリデーションコマンドで事前に構文エラーや設定の誤りを網羅的にチェックできるようになりました。

ユーザーへの恩恵

プラグイン開発のデバッグ効率が上がり、より高品質な拡張機能を短時間で作成できます。

変更前

モノレポ内の複数のサブディレクトリをプラグインとして利用する場合、キャッシュキーが重複して正しく読み込めない場合がありました。

変更後

サブディレクトリのパスを含めてキャッシュが管理されるようになり、モノレポ構造のプラグインが正しく識別されます。

ユーザーへの恩恵

複雑なプロジェクト構造を持つプラグインを安定して利用・配布できるようになりました。

変更前

--plugin-dir path1 path2のように指定していましたが、将来的な拡張において曖昧さが生じる可能性がありました。

変更後

--plugin-dir path1 --plugin-dir path2のように、1つのフラグに1つのパスを指定する標準的な形式に統一されました。

ユーザーへの恩恵

CLIの動作が予測可能になり、スクリプトなどでのプラグイン管理がより安全に行えるようになります。

変更前

起動のタイミングによって、プラグイン経由で導入したLSP（言語サーバー）が正しく認識されず、コード補完や定義ジャンプが機能しないことがありました。

変更後

初期化順序が最適化され、プラグイン由来のLSPサーバーが常に確実に登録されるようになりました。

ユーザーへの恩恵

GoやC#などの言語において、プラグインを導入するだけで安定したコードインテリジェンス機能を享受できます。

変更前

組織のポリシーによって使用が禁止（force-disabled）されているプラグインであっても、プラグイン管理画面（/plugin）の「Installed」タブに表示されてしまっていました。

変更後

管理者が無効化したプラグインは、インストール済みリストから適切に除外されるようになります。

ユーザーへの恩恵

利用可能なプラグインと管理制限されているプラグインが明確に区別され、ユーザーが誤って使用できない機能にアクセスしようとする混乱を防げます。

変更前

自作プラグインを開発してテストする際、マーケットプレイスから同名のプラグインをインストールしていると、どちらが動いているか分かりにくい場合がありました。

変更後

--plugin-dir で指定した開発中のコピーが優先されるようになり、マーケットプレイス版をアンインストールせずにテストできるようになります。

ユーザーへの恩恵

プラグイン開発者が自分の環境でスムーズに動作確認を行えるようになり、配布前の最終調整がより簡単になります。

変更前

対話型インターフェース（REPL）の実行中に、ローカルのソースコードを参照しているマーケットプレイス用プラグインを /plugin install コマンドでインストールしようとすると、正常に処理が完了しない場合がありました。

変更後

REPL内からでも、ローカルソースを指定したプラグインのインストールが正しく動作するようになりました。

ユーザーへの恩恵

プラグイン開発時の試行錯誤や、チーム内で共有されたローカルプラグインの導入を、Claude Codeを終了させることなくスムーズに行えるようになります。

変更前

WindowsユーザーがLSPプラグイン（TypeScriptやPython用など）をインストールしても、パスの解釈ミスによりリアルタイムのコード診断が機能していませんでした。

変更後

Windows特有のパス形式が正しくファイルURIに変換され、コード内のエラー検知や定義ジャンプが正常に動作するようになります。

ユーザーへの恩恵

Windows環境でも、IDEのような高度なコードインテリジェンス機能を活用しながら快適にコーディングを進められます。

変更前

プラグインマーケットプレイスを追加する際、URL が .git で終わる形式以外（一部のエンタープライズ向け Git サービスなど）では正しく認識されない制約がありました。

変更後

.git サフィックスの有無にかかわらず、Azure DevOps や AWS CodeCommit などの Git URL を直接利用してマーケットプレイスを登録できるようになりました。

ユーザーへの恩恵

企業独自のコードホスティング環境で作成されたプラグインマーケットプレイスを、より簡単に導入・共有できるようになります。

変更前

Windows の OneDrive 同期フォルダでの EEXIST エラーや、キャッシュディレクトリのチルダ(~)がリテラルとして扱われる問題、特定のスコープでのインストール重複など、プラグイン利用において複数の障壁がありました。

変更後

OS 固有のパス処理やスコープの優先順位、plugin.json の読み込みロジックが修正され、安定性が向上しました。

ユーザーへの恩恵

OS やインストール環境を問わず、プラグインによる機能拡張が確実に動作するようになります。

変更前

プラグインをアンインストールすると共有設定が変更されてしまい、同じリポジトリで作業している他のチームメンバーの環境からもプラグインが消えてしまう問題がありました。

変更後

アンインストール操作がユーザー個人のローカル設定に反映されるようになり、チームへの影響を避けつつ自分だけの環境をカスタマイズできます。

ユーザーへの恩恵

チームの共通設定を壊す心配をせずに、個人の好みに応じてプラグインの抜き差しが自由に行えるようになります。

変更前

同じ機能を持つ MCP サーバーがプラグインと手動設定の両方から読み込まれ、同じツールが二重に表示されたり、リソースが無駄に消費されたりすることがありました。

変更後

同一のサーバー設定が検知されると自動的に片方がスキップされ、システム全体の健全性とパフォーマンスが維持されます。

ユーザーへの恩恵

ツールの重複による混乱が避けられ、メモリ消費の抑制とレスポンスの安定に繋がります。

変更前

マーケットプレイスの参照先が固定されている環境で更新を行うと、内部的な Git 操作で競合が発生し、プラグインの更新ができなくなる場合がありました。

変更後

ブランチやタグの参照が適切に処理されるようになり、固定されたリポジトリからでも安定して最新のプラグイン情報を取得できます。

ユーザーへの恩恵

チームで共有している特定のバージョンのプラグインマーケットプレイスを、エラーなく確実に運用できるようになります。

変更前

GitHub リポジトリなどを追加する際、一般的な慣習である @ を使ったバージョン指定が認識されず、設定ミスによるエラーに繋がることがありました。

変更後

@ と # の両方がリファレンス区切りとして正しくサポートされ、柔軟な指定が可能になりました。

ユーザーへの恩恵

特定のバージョンやブランチのプラグインを導入する際の手順が分かりやすくなり、導入時のトラブルが減少します。

変更前

プラグインマネージャーの画面で、実際にはインストールされていないプラグインがインストール済みとして表示され、混乱を招いていました。

変更後

プラグインのインストール状態が正確に反映され、正しい状態が確認できるようになりました。

ユーザーへの恩恵

インストール済みのプラグインを正しく把握し、無駄な再インストールや管理ミスを防ぐことができます。

変更前

プラグインのインストールや設定変更を行った後、その内容を適用するには一度セッションを終了して再起動する必要がありました。

変更後

対話型セッションを維持したまま、新しいコマンドやフック、エージェントの設定を即座に読み込み直すことが可能になりました。

ユーザーへの恩恵

プラグイン開発やカスタマイズの試行錯誤がスムーズになり、開発フローが中断されるのを防ぎます。

変更前

企業環境において、IT部門が承認したプラグインであることをユーザーに伝える公式な手段がありませんでした。

変更後

警告画面に「このプラグインはIT部門により承認済みです」といったメッセージを表示し、ユーザーに安心感を与えることができます。

ユーザーへの恩恵

組織内の開発者が、どのプラグインを安全に利用できるかを明確に判断できるようになり、ガバナンスと利便性が両立されます。

変更前

ローカルディレクトリからプラグインを読み込む際、許可された特定のディレクトリ以外からの読み込みを厳格に制限することができませんでした。

変更後

ネットワーク経由のホスト制限だけでなく、ファイルシステム上のパスに基づいた読み込み制限が可能になりました。

ユーザーへの恩恵

管理者側で、社内の標準ディレクトリ以外からのプラグインインストールを禁止するなど、より強力なセキュリティ制御が可能になります。

変更前

モノリポジトリ形式で管理されている複数のプラグインのうち、一つだけをインストールしたい場合でもリポジトリ全体を扱う必要がありました。

変更後

リポジトリ内の特定ディレクトリのみを指定して効率的にインストール・管理できるようになりました。

ユーザーへの恩恵

大規模なリポジトリでプラグインを共有している場合でも、必要なツールだけを軽量に導入でき、管理がシンプルになります。

変更前

新しいプラグインをインストールしたり、設定を変更したりした後は、一度 Claude Code を終了して再起動しなければ変更が適用されず、開発サイクルが中断されていました。

変更後

対話セッションを維持したままコマンド一つでプラグインの状態をリロードできるようになったため、作業を止めることなく新機能を追加・更新できます。

ユーザーへの恩恵

プラグイン開発時の試行錯誤や、作業中に必要なツールを即座に追加したい場合の摩擦が減り、生産性が向上します。

変更前

一つのリポジトリ内に複数のプラグインをまとめて管理（モノレポ）している場合、特定のプラグインだけをソースとして指定してインストールするのが困難でした。

変更後

リポジトリ全体ではなく、その中の特定のフォルダをプラグインとして認識させることができるようになったため、リポジトリ構成の自由度が上がりました。

ユーザーへの恩恵

複数の拡張機能を一つの Git リポジトリで効率的に管理・配布できるようになり、メンテナンス性が向上します。

変更前

プラグインのインストールや更新時に、Git操作のタイムアウトが短く、大規模なリポジトリやネットワーク環境では失敗することがありました。

変更後

デフォルトのGitタイムアウトが延長され、CLAUDE_CODE_PLUGIN_GIT_TIMEOUT_MS 環境変数でカスタマイズ可能になったことで、より安定したプラグイン管理が実現します。

ユーザーへの恩恵

プラグインのインストールや更新が、より多くの環境でスムーズに行えるようになり、開発効率が向上します。

変更前

プラグインの SKILL.md ファイルの説明部分が予期しないデータ型(例: YAML配列)であった場合、スラッシュコマンドのオートコンプリート機能がクラッシュしていました。

変更後

スラッシュコマンドのオートコンプリート機能が、様々なデータ型の SKILL.md 説明を正しく処理できるようになりました。

ユーザーへの恩恵

プラグインの SKILL.md の説明部分のデータ型に関わらず、オートコンプリート機能が安定して動作するようになります。

変更前

以前は、プラグインを導入する際、ユーザーは個別に設定を手動で構成する必要があり、プラグインのセットアップに手間がかかることがありました。特に新しいプラグインを試す場合、設定の手間が障壁となることがありました。

変更後

プラグインのルートディレクトリにsettings.jsonを含めることで、プラグイン開発者がデフォルト設定を提供できるようになりました。これにより、プラグインが有効化された際に、スキル、エージェント、フック、MCPサーバーなどの設定が自動的に適用されます。

ユーザーへの恩恵

プラグインの導入と設定が簡素化され、ユーザーはより手軽に新しい機能を試したり、チーム全体で一貫した開発環境を構築したりできるようになります。これにより、開発効率が向上し、プラグインエコシステムの活用が促進されます。

変更前

これまでは、plugin enableやplugin disableコマンドを実行する際に、--scopeフラグを指定しないと、プラグインが常にユーザーグローバルスコープで有効化または無効化されていました。これにより、プロジェクト固有の設定を意図していた場合でも、誤ってグローバル設定が変更される可能性がありました。

変更後

今回の修正により、--scopeフラグが指定されていない場合、plugin enableとplugin disableコマンドは、現在有効なコンテキスト(例えばプロジェクト固有のディレクトリ)に基づいて適切なスコープを自動的に検出するようになりました。これにより、ユーザーは意図したスコープでプラグインを管理できるようになります。

ユーザーへの恩恵

プラグインの管理がより直感的でエラーが少なくなります。開発者は、コマンドを実行する際に常にスコープを意識して指定する必要がなくなり、意図しない設定変更を防ぐことができます。これにより、開発環境の管理が容易になります。

変更前

プラグインに含まれるエージェントスキルが、完全なプラグイン名ではなく、単純なスキル名(ベア名)で参照された場合、エラーなくロードに失敗し、スキルが利用できない状態になっていました。

変更後

プラグインエージェントスキルのロードに関する問題が修正されました。ベア名で参照された場合でも、サイレントなロード失敗がなくなり、スキルが正しくロードされるようになりました。

ユーザーへの恩恵

プラグイン内のエージェントスキルが、より柔軟な参照方法で利用できるようになり、開発者はプラグインの連携を容易にしました。

変更前

ネストされたClaudeセッション内でclaude doctorやclaude plugin validateなどの非対話型サブコマンドを実行しようとすると、それらがブロックされ実行できない問題がありました。

変更後

ネストされたClaudeセッション内でも、claude doctorやclaude plugin validateなどの非対話型サブコマンドがブロックされずに実行できるようになりました。

ユーザーへの恩恵

ネストされたセッションでも診断や検証コマンドが実行可能になり、開発者はより柔軟に環境の確認や問題解決を行えるようになりました。

変更前

Claude Code は、--add-dir オプションで指定されたディレクトリ内のプラグインやマーケットプレイスに関する設定を自動的に読み込むことができませんでした。

変更後

Claude Code は、--add-dir オプションで指定されたディレクトリ内に enabledPlugins および extraKnownMarketplaces の設定ファイルが存在する場合、それらを認識し、プラグインの有効化やマーケットプレイスの追加を自動的に行えるようになりました。

ユーザーへの恩恵

開発者は、プロジェクト固有のプラグインやマーケットプレイスを --add-dir オプションで簡単に指定できるようになり、開発環境のセットアップが容易になりました。これにより、より迅速にプロジェクト固有のツールや機能を活用できます。

変更前

プラグインをインストールしても、そのプラグインが提供するコマンド、エージェント、フックがすぐに利用できず、Claude Code の再起動が必要でした。

変更後

プラグインのインストール後、再起動することなく、提供されたコマンド、エージェント、フックが即座に利用可能になりました。

ユーザーへの恩恵

プラグインの追加や更新がよりスムーズになり、開発者はツールのセットアップ時間を短縮して、すぐに作業を開始できます。

変更前

プラグイン独自のスクリプトを「承認なしで実行可能」として定義していても、変数展開の不備により、実行のたびにユーザーに承認を求める不適切な挙動がありました。

変更後

変数が正しくパスに展開され、プラグイン作者が意図した通りに安全なツールを自動実行できるようになりました。

ユーザーへの恩恵

信頼できるプラグインを使用する際の不要な承認プロンプトが減り、ワークフローがよりスムーズになります。