Claude Code Plugins

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

--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ツールの開発が容易になります。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

新しい 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 の再起動が必要でした。

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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