Claude Codeのプラグインを試すとき、最初は「このフォルダを1個読み込む」で十分です。ところが、検証したいプラグインが増えると、起動コマンドに--plugin-dirを何度も並べることになります。
2026年9月8日のClaude Code v2.1.265で、この扱いが少し変わりました。--plugin-dirに「プラグインを1個置いたフォルダ」ではなく、「複数のプラグインを入れた親フォルダ」を指定できるようになったのです。親フォルダ直下の子フォルダにmanifestがあれば読み込まれ、実行中に子フォルダを追加・削除した変更も拾います。
この記事では、この変更を「何が便利になったか」「どのように配置するか」「どこで気を付けるか」の順に整理します。なお、ここで確認できたのは公式変更履歴に書かれている仕様です。実際の運用では、使用中のClaude Codeのバージョンと、プラグインのmanifestを確認してください。
--plugin-dirは何をするオプションか
--plugin-dirは、ローカルにあるプラグインをClaude Codeへ読み込ませるための起動オプションです。マーケットプレイスへ公開する前のプラグインを試したり、手元で修正したプラグインをすぐに確認したりする用途に向いています。
たとえば、単一のプラグインを読み込む場合は次のようになります。
claude --plugin-dir ./plugins/my-pluginこの方法は分かりやすい反面、プラグインが増えると起動コマンドが長くなります。さらに、似た用途のプラグインを一時的に比較したいとき、毎回パスを列挙し直すのが面倒です。
v2.1.265では、複数のプラグインをまとめた親フォルダを指定できます。
claude --plugin-dir ./pluginsこのとき、./pluginsの直下にある子フォルダのうち、manifestを持つものがプラグインとして読み込まれます。つまり「読み込ませるプラグインの集合」をフォルダとして管理できるようになりました。
フォルダ構成はどう作るか
基本形は次のような構成です。manifestのファイル名や必須項目は、プラグインの種類と現在のドキュメントに合わせて確認してください。
my-project/
├─ plugins/
│ ├─ accessibility-review/
│ │ └─ plugin.json
│ ├─ api-checker/
│ │ └─ plugin.json
│ └─ test-reporter/
│ └─ plugin.json
└─ src/
起動時は親フォルダだけを渡します。
claude --plugin-dir ./pluginsここで重要なのは、単に子フォルダが存在するだけでは読み込み対象にならないことです。公式変更履歴は、子フォルダにmanifestがある場合に読み込む、と説明しています。作業用のメモや展開途中のバックアップを同じ場所に置いても、それらが自動的にプラグインになるわけではありません。
実行中の追加と削除を拾える
今回の変更でもう一つ便利なのが、Claude Codeの実行中に子フォルダを追加・削除した変更を拾える点です。
たとえば、まず最小構成で起動します。
claude --plugin-dir ./pluginsその後、別のターミナルで検証用プラグインを親フォルダへ追加します。
Copy-Item -Recurse .\plugins-dev\new-checker .\plugins\new-checker逆に、いったん無効にしたい子フォルダを親フォルダの外へ移動する運用もできます。
Move-Item .\plugins\new-checker .\plugins-disabled\new-checkerただし、ここで「ファイルを置いた瞬間に、すべての機能が必ず同じ会話へ反映される」と考えるのは危険です。プラグインの再読み込みが必要なケースや、会話をまたぐ変更があるかどうかは、使っている機能とバージョンによって確認が必要です。追加・削除のあとにプラグイン一覧を確認し、期待したskillやcommandが見えるかを検証するのが安全です。
この変更が向いている場面
自作プラグインを複数試す
自分で作ったプラグインを何本も比較するなら、親フォルダを1つ決めておくと便利です。プラグインごとに別の起動コマンドを作る必要がなくなり、どれを有効にするかをフォルダ操作で切り替えられます。
チーム内の検証セットを共有する
共有リポジトリに検証用プラグインのフォルダを置き、manifestを持つ子フォルダだけをまとめる方法も考えられます。起動方法をREADMEに1行書けば、メンバーが同じセットを試せます。
ただし、個人の認証情報や秘密の設定をプラグインフォルダに入れて、まとめて共有する運用は避けるべきです。プラグインのソースと、環境ごとの秘密を分けて管理してください。
開発中のプラグインを差し替える
親フォルダ方式は、開発中の子フォルダを追加・削除して比べる作業にも向いています。完成版と試作版を同じ階層に置く場合は、同じ名前の機能が競合しないように分けてください。読み込まれたプラグインの一覧を確認せずに比較すると、どの実装が動いたのか分からなくなります。
気を付けたい3つの境界
便利になったからといって、親フォルダに何でも入れてよいわけではありません。少なくとも次の3点は最初に決めておくと安全です。
- 読み込み対象の境界：manifestを持つ子フォルダだけを置き、メモやバックアップは別の場所にする。
- 名前の境界：同じ名前のcommandやskillを複数のプラグインに入れず、競合したときの優先順位を推測しない。
- 秘密の境界：APIキー、トークン、個人設定をプラグインのソースへ書き込まず、環境変数や既存の秘密管理へ分ける。
特に2番目は、動いたから正しいとは限らない部分です。名前が衝突している状態で片方だけの挙動を期待すると、プラグインの読み込み順や設定変更で結果が変わる可能性があります。検証用フォルダでは、プラグイン名と提供する機能名を最初から一意にしておく方が、後から調べやすくなります。
まず試すならこの手順
最初から大量のプラグインをまとめるのではなく、空の親フォルダに1つだけ置いて動作を確認します。
New-Item -ItemType Directory -Force .\plugins | Out-Null
Copy-Item -Recurse .\my-plugin .\plugins\my-plugin
claude --plugin-dir .\plugins期待するskillやcommandが読み込まれたことを確認したら、2つ目を追加します。追加後に一覧を確認し、意図しない重複がないことを見ます。問題が出たら、最後に追加した子フォルダを外して、どのプラグインが原因かを一つずつ切り分けます。
この順番なら、親フォルダ方式の問題なのか、個別プラグインのmanifestなのか、機能名の競合なのかを分けて考えられます。
従来の複数指定との使い分け
以前から、複数の場所を個別に読み込ませたい場合は、--plugin-dirを繰り返し指定する方法が使えます。
claude --plugin-dir ./plugins/accessibility-review --plugin-dir ./plugins/api-checkerこの書き方は、読み込む場所を明示したい場合には便利です。たとえば、開発中のプラグインを1つだけ指定して、親フォルダにある他の試作品を誤って読み込みたくないときに向いています。
反対に、同じ目的の検証セットを毎回まとめて使うなら、親フォルダを1回指定する方が管理しやすいでしょう。つまり、親フォルダ方式は従来の指定をすべて置き換える機能というより、「読み込む単位をフォルダでまとめる」ための選択肢です。
私は、日常的に使う安定版と、検証中の試作品を同じ親フォルダへ混ぜない運用にします。plugins/stableとplugins/labを分け、起動時には必要な方を指定するだけにすると、トラブル時の切り分けが楽になります。公式の変更点は便利さを増やすものですが、どの集合を読み込むかという運用ルールまで自動で決めてくれるわけではありません。
まとめ
Claude Code v2.1.265では、--plugin-dirにプラグイン群の親フォルダを渡せるようになりました。manifestを持つ子フォルダが読み込まれ、実行中の追加・削除も拾えるため、自作プラグインの比較や検証セットの管理がしやすくなります。
一方で、読み込み対象・名前の衝突・秘密情報の置き場所は自分で管理する必要があります。まずは1つのプラグインで動作を確認し、追加するたびに一覧と実際の機能を検証する。この小さな手順を守るだけで、「何が有効なのか分からない」状態を避けられます。
コメント