plugin-dependencies.md +0 −267 deleted
File Deleted View Diff
1> ## Documentation Index
2> Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt
3> Use this file to discover all available pages before exploring further.
4
5# プラグイン依存関係のバージョンを制約する
6
7> プラグイン依存関係のバージョン制約を宣言して、キュレーションされたプラグインセットを 1 つのインストールの背後にバンドルします。
8
9プラグインは、`plugin.json` またはマーケットプレイスエントリにリストすることで、他のプラグインに依存できます。デフォルトでは、依存関係は最新の利用可能なバージョンを追跡するため、アップストリームリリースは警告なしにプラグインの依存関係を変更できます。バージョン制約を使用すると、移動を選択するまで、依存関係をテスト済みのバージョン範囲に保つことができます。
10
11依存関係を宣言するプラグインをインストールすると、Claude Code は依存関係を自動的に解決してインストールします。ただし、マーケットプレイスエントリに [`command` ソース](/docs/ja/plugin-marketplaces#how-users-accept-the-command) または [`headersHelper`](/docs/ja/plugin-marketplaces#how-users-accept-a-headershelper-command) がある依存関係は、最初に自分でインストールします。その後、`/reload-plugins`、依存プラグインのマーケットプレイスの自動更新、依存プラグインで `claude plugin install` を再実行、および `claude plugin marketplace add` は、同じルールの下で、まだインストールされていない宣言された依存関係をインストールします。1 つが未解決のままの場合は、[依存関係エラーを解決する](#resolve-dependency-errors) を参照してください。
12
13このガイドは、`plugin.json` で依存関係を宣言するプラグイン作成者と、リリースにタグを付けるマーケットプレイス保守者向けです。ここでの依存関係は他のプラグインです。プラグイン自体が使用する npm および Bun パッケージについては、[Node.js パッケージ依存関係](/docs/ja/plugins-reference#node-js-package-dependencies) を参照してください。依存関係を持つプラグインをインストールするには、[プラグインの検出とインストール](/docs/ja/discover-plugins) を参照してください。完全なマニフェストスキーマについては、[プラグインリファレンス](/docs/ja/plugins-reference) を参照してください。
14
15<h2 id="why-constrain-dependency-versions">
16 依存関係のバージョンを制約する理由
17</h2>
18
192 つのチームがプラグインを公開する内部マーケットプレイスを考えてみてください。プラットフォームチームは、シークレットバックエンドをラップする MCP サーバーである `secrets-vault` を保守しています。デプロイチームは、デプロイ中に認証情報を取得するために `secrets-vault` を呼び出す `deploy-kit` を保守しています。
20
21`deploy-kit` は `secrets-vault` v2.1.0 に対してテストされています。バージョン制約がない場合、プラットフォームチームが MCP ツールの名前を変更するリリースにタグを付けると、次回の自動更新により、すべてのエンジニアの `secrets-vault` が新しいバージョンに移動し、`deploy-kit` が破損します。
22
23バージョン制約を使用すると、`deploy-kit` は `secrets-vault` が `~2.1.0` 範囲内にあることが必要であることを宣言します。`deploy-kit` がインストールされているエンジニアは、最高の一致する `2.1.x` パッチに留まります。デプロイチームは、より広い制約を持つ新しい `deploy-kit` バージョンを公開することで、独自のスケジュールでアップグレードします。
24
25<h2 id="declare-a-dependency-with-a-version-constraint">
26 バージョン制約を使用して依存関係を宣言する
27</h2>
28
29プラグインの `.claude-plugin/plugin.json` の `dependencies` 配列に依存関係をリストします。
30
31次のマニフェストは、1 つのバージョン指定なしの依存関係と 1 つの制約付き依存関係を宣言しています。
32
33```json .claude-plugin/plugin.json theme={null}
34{
35 "name": "deploy-kit",
36 "version": "3.1.0",
37 "dependencies": [
38 "audit-logger",
39 { "name": "secrets-vault", "version": "~2.1.0" }
40 ]
41}
42```
43
44エントリは、`deploy-kit` マニフェストの `"audit-logger"` のようにプラグイン名のみを含む単純な文字列にすることができます。これは、そのプラグインのマーケットプレイスが提供するバージョンに依存します。より詳細に制御するには、次のフィールドを持つオブジェクトを使用します。
45
46| フィールド | 型 | 説明 |
47| :------------ | :----- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
48| `name` | string | プラグイン名。宣言するプラグインと同じマーケットプレイス内で解決されます。必須。 |
49| `version` | string | `~2.1.0`、`^2.0`、`>=1.4`、または `=2.1.0` などの [semver 範囲](https://github.com/npm/node-semver#ranges)。依存関係は、この範囲を満たす最高のタグ付きバージョンで取得されます。 |
50| `marketplace` | string | `name` を解決する別のマーケットプレイス。クロスマーケットプレイス依存関係は、ターゲットマーケットプレイスがルートマーケットプレイスの `marketplace.json` の [`allowCrossMarketplaceDependenciesOn`](#depend-on-a-plugin-from-another-marketplace) にリストされていない限り、ブロックされます。 |
51
52`2.0.0-beta.1` などのプレリリースバージョンは、`^2.0.0-0` のようなプレリリースサフィックスで範囲がオプトインしない限り、除外されます。
53
54<h2 id="bundle-plugins-for-a-team">
55 チームのプラグインをバンドルする
56</h2>
57
58必須の `name` の他に、プラグインマニフェストは `dependencies` 配列のみで構成することができます。これをインストールすると、すべての依存関係がプルされます。これにより、キュレーションされたプラグインセットを 1 つのインストールの背後にパッケージ化する方法になります。
59
60例えば、プラットフォームチームは内部マーケットプレイスでロール固有のバンドルを公開できるため、エンジニアは各ツールを個別にインストールする代わりに、1 つの `claude plugin install` を実行できます。
61
62```json .claude-plugin/plugin.json theme={null}
63{
64 "name": "backend-standard",
65 "version": "1.0.0",
66 "description": "Standard plugin set for backend engineers",
67 "dependencies": [
68 "secrets-vault",
69 "deploy-kit",
70 { "name": "db-migrate", "version": "^3.0" },
71 "oncall-runbook"
72 ]
73}
74```
75
76`backend-standard` をインストールすると、4 つの依存関係すべてが解決され、インストールされます。
77
78後で標準セットにツールを追加するには、追加の依存関係を含む新しい `backend-standard` バージョンを公開します。マーケットプレイスが [自動更新](/docs/ja/discover-plugins#configure-auto-updates) しない限り、エンジニアは次の 2 つの方法のいずれかで新しいバージョンを取得します。
79
80* `/plugin` でマーケットプレイスの自動更新を有効にします。次の自動更新でバンドルが新しいバージョンに移動し、追加される依存関係がインストールされます。
81* `claude plugin update backend-standard` を実行してから、`/reload-plugins` を実行して、新しく追加された依存関係をインストールします。
82
83バンドルを組織全体にロールアウトするには、[管理設定](/docs/ja/settings-reference#enabledplugins) の `enabledPlugins` にバンドルプラグインを追加します。
84
85<h2 id="depend-on-a-plugin-from-another-marketplace">
86 別のマーケットプレイスからプラグインに依存する
87</h2>
88
89デフォルトでは、Claude Code は、それを宣言するプラグインとは異なるマーケットプレイスに存在する依存関係の自動インストールを拒否します。これにより、1 つのマーケットプレイスが、確認していないソースからプラグインを静かにプルインするのを防ぎます。
90
91これを許可するには、ルートマーケットプレイスの保守者が、ターゲットマーケットプレイス名を `marketplace.json` の `allowCrossMarketplaceDependenciesOn` に追加します。ルートマーケットプレイスは、ユーザーがインストールしているプラグインをホストするマーケットプレイスです。そのアローリストのみが参照されるため、信頼は中間マーケットプレイスを通じてチェーンされません。
92
93次の `marketplace.json` は、`deploy-kit` が `acme-shared` からプラグインに依存することを許可しています。
94
95```json .claude-plugin/marketplace.json theme={null}
96{
97 "name": "acme-tools",
98 "owner": { "name": "Acme" },
99 "allowCrossMarketplaceDependenciesOn": ["acme-shared"],
100 "plugins": [
101 {
102 "name": "deploy-kit",
103 "source": "./deploy-kit",
104 "dependencies": [
105 { "name": "audit-logger", "marketplace": "acme-shared" }
106 ]
107 }
108 ]
109}
110```
111
112フィールドが欠落しているか、ターゲットマーケットプレイスが含まれていない場合、インストールは `cross-marketplace` エラーで失敗し、設定するフィールドに名前を付けます。ユーザーは依然として依存関係を手動で最初にインストールできます。これにより、アローリストを変更することなく制約が満たされます。
113
114<h2 id="test-a-plugin-and-its-dependency-locally">
115 プラグインとその依存関係をローカルでテストする
116</h2>
117
118プラグインとそれが依存するプラグインを同時に開発している場合は、`--plugin-dir` で両方をロードします。
119
120```bash theme={null}
121claude --plugin-dir ./my-dependency --plugin-dir ./my-plugin
122```
123
124依存関係のローカルコピーは、エントリがマーケットプレイスを指定している場合でも、プラグインの依存関係エントリを満たします。そのため、マーケットプレイスから依存関係をインストールする必要はありません。Claude Code は、ローカルコピーに対して[バージョン制約](#declare-a-dependency-with-a-version-constraint)をチェックしないため、ローカルの `plugin.json` には `version` が不要です。v2.1.242 より前では、マーケットプレイスを指定する依存関係エントリはローカルコピーと一致せず、Claude Code はロード時にプラグインを無効にしていました。
125
126両方のプラグインが 1 つの親フォルダに存在する場合、そのフォルダを `--plugin-dir` に 1 回渡すことができます。フォルダ自体がプラグインでない場合、Claude Code は `.claude-plugin/plugin.json` を持つ各子フォルダをロードします。Claude Code v2.1.265 以降が必要です。
127
128マーケットプレイスから依存関係をインストールしていない場合、ローカルコピーがなくなるとプラグインのロードが停止します。
129
130* **ローカルコピーを無効にした場合**: Claude Code は次のプラグインロード時にプラグインを無効にします。マーケットプレイスを指定する依存関係エントリの場合、Claude Code は `Dependency "<name>@inline" is disabled — enable it or remove the dependency` と報告します。ベアネームエントリの場合は、依存関係をベアネームで報告します。`<name>@inline` は、Claude Code がすべての `--plugin-dir` および `--plugin-url` プラグインを識別する方法です。
131* **依存関係の `--plugin-dir` フラグなしでセッションを開始した場合**: Claude Code は依存関係がインストールされていないと報告します。フラグを再度渡すか、マーケットプレイスから依存関係をインストールしてください。
132
133<h2 id="tag-plugin-releases-for-version-resolution">
134 バージョン解決のためのタグプラグインリリース
135</h2>
136
137Claude Code は、依存関係をホストするリポジトリの git タグに対してバージョン制約を解決します。プラグイン自体のリポジトリ（`github`、`url`、`git-subdir` [プラグインソース](/docs/ja/plugin-marketplaces#plugin-sources)の場合）、またはマーケットプレイスが相対パスで参照するプラグインのマーケットプレイスリポジトリです。Claude Code が依存関係の利用可能なバージョンを見つけるには、アップストリームプラグインのリリースが特定の命名規則を使用してタグ付けされている必要があります。
138
139各リリースを `{plugin-name}--v{version}` としてタグ付けします。ここで `{version}` はそのコミットの `plugin.json` の `version` フィールドと一致します。プラグインディレクトリから、以下を実行します。
140
141```bash theme={null}
142claude plugin tag --push
143```
144
145`claude plugin tag` コマンドは、プラグインのマニフェストと囲まれたマーケットプレイスエントリからタグ名を導出します。タグを作成する前に、プラグインの内容を検証し、`plugin.json` とマーケットプレイスエントリがバージョンについて一致していることを確認し、プラグインディレクトリの下でクリーンな作業ツリーを要求し、タグが既に存在する場合は拒否します。
146
147* `--push` は `origin` リモートにタグをプッシュするため、リポジトリは設定済みの `origin` リモートが必要です。別のリモートにプッシュするには `--remote` を渡します。
148* プッシュが失敗した場合、タグはローカルで作成され、コマンドはエラーで終了します。
149* `--push` を使用すると、成功した実行は `Created tag secrets-vault--v2.1.0` と `Pushed to origin` で終了します。最後の行はプッシュ先のリモートを名前で示します。`--push` なしでは、コマンドは代わりに実行する `git push` コマンドを出力します。
150* `--dry-run` は、タグを作成せずにタグ付けされるものを出力します。
151
152`git tag secrets-vault--v2.1.0` を直接実行することは、`plugin.json` とマーケットプレイスエントリを自分で同期させておけば同等です。
153
154プラグイン名プレフィックスにより、1 つのマーケットプレイスリポジトリが独立したバージョン行を持つ複数のプラグインをホストできます。`--v` セパレータは完全なプラグイン名のプレフィックスマッチとして解析されるため、ハイフンを含むプラグイン名は正しく処理されます。
155
156`{ "name": "secrets-vault", "version": "~2.1.0" }` を宣言するプラグインをインストールすると、Claude Code は `secrets-vault` をホストするリポジトリのタグをリストし、`secrets-vault--v` で始まるものにフィルタリングし、`~2.1.0` を満たす最高バージョンを取得します。プラグイン自体のリポジトリのタグが範囲を満たさない場合、インストールは `Dependency "secrets-vault@acme-tools" has no git tag satisfying ~2.1.0` で失敗します。これは依存関係をそのマーケットプレイスと共に名前で示します。一致するタグのない相対パスプラグインの場合、Claude Code はマーケットプレイスの現在のコピーをインストールし、プラグインが読み込まれるときに制約をチェックします。
157
158マーケットプレイスが相対パスで参照するプラグインの場合、ローカルフォルダパスとして追加されたマーケットプレイスは、フォルダが git リポジトリの場合、同じ方法でタグを解決します。これには Claude Code v2.1.196 以降が必要です。2 つのケースでは Claude Code はフォルダの現在の内容から依存関係をインストールします。
159
160* 以前のバージョンはローカルフォルダマーケットプレイスからタグを読み取らないため、制約付き依存関係はそのコピーが範囲を満たす場合にのみ読み込まれます。
161* git リポジトリではないローカルフォルダには、バージョンに関係なくタグがありません。
162
163解決されたタグの semver は `plugin.json` の `version` とは別に記録されるため、制約チェックは `plugin.json` がそのコミットで古い値を持っている場合でも、実際に取得されたタグを使用します。タグ解決インストールのキャッシュディレクトリ名には 12 文字のコミット SHA サフィックスが含まれるため、メンテナーがタグを別のコミットに強制移動した場合、次のインストールは古いコンテンツを再利用する代わりに新しいキャッシュディレクトリを取得します。
164
165<Note>
166 `npm`、`archive`、または `command` [プラグインソース](/docs/ja/plugin-marketplaces#plugin-sources)を持つ依存関係の場合、タグベースの解決は git バックアップソースにのみ適用されるため、制約はどのバージョンが取得されるかを制御しません。制約は読み込み時にもチェックされ、インストールされたバージョンが制約を満たさない場合、依存プラグインは `dependency-version-unsatisfied` で無効になります。`command` ソースの場合、Claude Code は依存関係の `plugin.json` のバージョンをチェックし、コンテンツハッシュサフィックスを無視します。`plugin.json` がバージョンを設定しない依存関係は制約を満たさないため、制約する前に設定してください。
167
168 Claude Code は `command` ソースを持つ依存関係自体をインストールしないため、ユーザーは [最初にそれをインストール](/docs/ja/plugin-marketplaces#how-users-accept-the-command)します。Claude Code は依存関係のマーケットプレイスエントリで `headersHelper` を実行しないため、ユーザーは [最初にそのプラグインをインストール](/docs/ja/plugin-marketplaces#how-users-accept-a-headershelper-command)します。
169</Note>
170
171<h2 id="how-constraints-interact">
172 制約がどのように相互作用するか
173</h2>
174
175複数のインストール済みプラグインが同じ依存関係を制約する場合、Claude Code はそれらの範囲を交差させ、依存関係をすべての範囲を満たす最高バージョンに解決します。下の表は、一般的な組み合わせがどのように解決されるかを示しています。
176
177| プラグイン A が必要 | プラグイン B が必要 | 結果 |
178| :---------- | :---------- | :---------------------------------------------------------------- |
179| `^2.0` | `>=2.1` | `2.1.0` 以上の最高 `2.x` タグで 1 つのインストール。両方のプラグインが読み込まれます。 |
180| `~2.1` | `~3.0` | プラグイン B のインストールが `range-conflict` で失敗します。プラグイン A と依存関係は以前のままです。 |
181| `=2.1.0` | なし | 依存関係は `2.1.0` に留まります。プラグイン A がインストールされている間、自動更新は新しいバージョンをスキップします。 |
182
183自動更新は、制約付き依存関係を、マーケットプレイスの最新バージョンではなく、インストール済みプラグインのすべての範囲を満たす最高 git タグで取得するため、依存関係は許可された範囲内で更新を受け続けます。すべての範囲を満たすタグがない場合、自動更新はその依存関係をスキップし、スキップを `/plugin` エラータブに表示し、制約するプラグインに名前を付けます。
184
185依存関係を制約する最後のプラグインをアンインストールすると、依存関係は保持されなくなり、次の更新でマーケットプレイスエントリの追跡を再開します。
186
187<h2 id="enable-or-disable-a-plugin-with-dependencies">
188 依存関係を持つプラグインを有効または無効にする
189</h2>
190
191このセクションでは、マーケットプレイスからインストールされたプラグインについて説明します。`--plugin-dir` で読み込んだコピーについては、[プラグインとその依存関係をローカルでテストする](#test-a-plugin-and-its-dependency-locally)を参照してください。
192
193プラグインを有効にすると、それが依存するプラグインも有効になり、別の有効なプラグインがまだそれを必要としている場合、プラグインを無効にすることはブロックされます。
194
195プラグインを有効にすると、Claude Code は同じスコープでその依存関係も有効にします。依存関係が独自の依存関係を持つ場合、Claude Code はそれらも有効にします。成功メッセージは、名前を付けたプラグインと一緒に有効になったものをリストします。依存関係を有効にできない場合、コマンドは拒否され、何がブロックしているか、およびそれを修正する方法が表示されます。
196
197| 条件 | 結果 |
198| :-------------------------------------------- | :------------------------------------------------------------ |
199| 依存関係がインストールされていない | 有効化が失敗し、各欠落している依存関係の `claude plugin install` コマンドを出力します。 |
200| 依存関係が組織のプラグインポリシーによってブロックされている | 有効化が失敗し、ブロックされた依存関係に名前を付けます。 |
201| 依存関係が、ターゲットスコープより優先度の高いスコープで `false` に設定されている | 有効化が失敗します。そのスコープで依存関係を有効にするか、`--scope` を渡してそこに書き込みます。 |
202| すべての依存関係がインストールされ、許可されている | 有効化が成功し、プラグインと、ターゲットスコープでまだ有効になっていない各依存関係に対して `true` を書き込みます。 |
203
204これは、依存関係がマニフェストで [`defaultEnabled: false`](/docs/ja/plugins-reference#default-enablement) を設定している場合でも当てはまります。Claude Code はそれに対して明示的な `true` を書き込むためです。同じことがインストール時にも適用されます。アクティブなプラグインを満たすために取得された依存関係は、独自のデフォルトに関係なく `true` でインストールされます。
205
206プラグインを無効にすると、別の有効なプラグインがまだそれに依存している場合、Claude Code は拒否します。エラーはそれに依存するプラグインに名前を付け、正しい順序でそれらを無効にする連鎖コマンドを提供します。
207
208たとえば、`deploy-kit` が `secrets-vault` に依存している場合、`secrets-vault` だけを無効にすると、次のような出力で失敗します。
209
210```text theme={null}
211secrets-vault is still required by deploy-kit. Disable that plugin first, or
212disable everything together: claude plugin disable deploy-kit@acme-tools && claude plugin disable secrets-vault@acme-tools
213```
214
215エラーから連鎖コマンドをコピーして、1 つのステップで完全なセットを無効にします。
216
217<h2 id="remove-orphaned-auto-installed-dependencies">
218 孤立した自動インストール依存関係を削除する
219</h2>
220
221自動インストール依存関係は、それらをインストールしたプラグインがアンインストールされた後もディスク上に留まります。これは、依存プラグインを再インストールしたい場合や、依存関係を直接使用し続けたい場合に備えてです。それらをクリーンアップするには、`claude plugin prune` を実行して、インストール済みプラグインがもう必要としない自動インストール依存関係をリストし、確認プロンプトの後に削除します。
222
223```bash theme={null}
224claude plugin prune
225```
226
227削除対象がない場合、コマンドは `Nothing to prune` と理由を出力して終了します。これは新規インストール時の予想される出力であり、エラーではありません。
228
229デフォルトでは、prune はユーザースコープで動作し、何かを削除する前に確認を求めます。
230
231* `--scope project` または `--scope local` は別のスコープをターゲットにします。
232* `--dry-run` は削除されるものをリストし、何も変更しません。
233* `-y` は確認プロンプトをスキップします。stdin または stdout がターミナルでない場合、prune は孤立したものをリストして終了し、`-y` を渡さない限り削除しません。
234
235アンインストールの一部として prune するには、`claude plugin uninstall` に `--prune` を渡します。名前付きプラグインを削除した後、Claude Code は自動インストール依存関係をスキャンして、現在孤立しているものを削除します。自分でインストールしたプラグインは決して prune されません。別のプラグインの `dependencies` 配列を通じて自動的にインストールされたものだけです。
236
237同じ確認動作が適用されます。stdin または stdout がターミナルでない場合、アンインストールは完了しますが、prune ステップは孤立したものをリストし、`-y` を渡さない限り削除しません。
238
239たとえば、`deploy-kit` をアンインストールし、それが残す依存関係をクリーンアップするには、以下を実行します。
240
241```bash theme={null}
242claude plugin uninstall deploy-kit --prune
243```
244
245<h2 id="resolve-dependency-errors">
246 依存関係エラーを解決する
247</h2>
248
249依存関係の問題は、`claude plugin list` と `/plugin` インターフェイスに表示されます。これらはこの表の文字通りのコードではなく、説明的なエラーメッセージとして表示されます。Claude Code は、エラーを解決するまで影響を受けたプラグインを無効にします。以下の表は、最も一般的なエラーとその解決方法を示しています。
250
251| エラー | 意味 | 解決方法 |
252| :------------------------------- | :--------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
253| `dependency-unsatisfied` | 宣言された依存関係がインストールされていないか、インストールされていますが無効になっています。 | エラーメッセージに表示されている `claude plugin install` コマンドを実行してください。依存関係のマーケットプレイスがまだ設定されていない場合は、`claude plugin marketplace add` で追加すると、Claude Code が依存関係を自動的に解決します。依存関係が無効になっている場合は、有効にしてください。 |
254| `range-conflict` | 依存関係のバージョン要件を組み合わせることができません。エラーメッセージは原因に名前を付けます。バージョンがすべての範囲を満たさない、範囲が有効な semver 構文ではない、または結合された範囲が複雑すぎて交差できません。 | 競合するプラグインの 1 つをアンインストールまたは更新し、無効な `version` 文字列を修正し、長い `\|\|` チェーンを簡略化するか、アップストリーム作成者に制約を広げるよう依頼してください。 |
255| `dependency-version-unsatisfied` | インストール済み依存関係のバージョンがこのプラグインの宣言された範囲外です。 | `claude plugin install <dependency>@<marketplace>` を実行して、すべての現在の制約に対して依存関係を再解決します。 |
256| `no-matching-tag` | 依存関係のリポジトリに、範囲を満たす `{name}--v*` タグがありません。 | アップストリームが上記の規則を使用してリリースにタグを付けていることを確認するか、範囲を緩和してください。 |
257
258これらのエラーをプログラムで確認するには、`claude plugin list --json` を実行してください。問題のあるプラグインには、それらをリストする `errors` フィールドが含まれます。正常に読み込まれたプラグインはこのフィールドを省略します。
259
260<h2 id="see-also">
261 関連項目
262</h2>
263
264* [プラグインの作成](/docs/ja/plugins): スキル、エージェント、フックを使用してプラグインを構築します
265* [プラグインマーケットプレイスの作成と配布](/docs/ja/plugin-marketplaces): チーム向けのプラグインをホストします
266* [プラグインリファレンス](/docs/ja/plugins-reference#plugin-manifest-schema): 完全な `plugin.json` スキーマ
267* [バージョン管理](/docs/ja/plugins-reference#version-management): プラグイン独自のバージョンがどのように解決され、キャッシュキーとして使用されるか