> ## Documentation Index > Fetch the complete documentation index at: https://docs.devin.ai/llms.txt > Use this file to discover all available pages before exploring further. # Devin CLI プラグイン > Devin CLI におけるプラグインのインストール、作成、管理: プラグインの形式、devin plugins コマンド、マニフェスト、継承レベル。 **プラグイン**は、[スキル](/ja/cli/extensibility/skills/overview)と任意のルール、フック、MCPサーバー、またはカスタムサブエージェントをまとめたバンドルで、GitHub リポジトリ、git URL、リポジトリのサブフォルダー、またはローカルフォルダからインストールできます。 プラグインは、以下で説明する対象ごとの制限に従い、Devin クラウドセッション、[Devin CLI](/ja/cli/index)、および Devin Desktop で利用できます。プラグインをインストールすると、そのスキルを `/:` スラッシュ コマンドとして利用できます。このページでは CLI におけるプラグインについて説明します。web app — Customize ページ、組織および Enterprise のスコープ、インデックス作成、MCP 接続 — については、 [プラグインガイド](/ja/product-guides/plugins)を参照してください。 **プラグインはインストールの単位です**。プラグインをインストールすると、そのすべての スキルと `requiredPlugins` もインストールされます。プラグインから個別のスキルをインストールすることはできません。 スキルを個別に提供するには、別々のプラグインに分割してください。 プラグインとは、次の内容を含むソースのことです: ``` my-plugin/ ├── .devin-plugin/ │ └── plugin.json # マニフェスト ├── AGENTS.md # 任意の常時適用ルール ├── rules/ # 任意のトリガーされるルール ├── agents/ │ └── reviewer.md # 任意のカスタムサブエージェント（reviewer/AGENT.md も使用可） ├── hooks.json # 任意のライフサイクルフック ├── .mcp.json # 任意のMCPサーバー └── skills/ └── review/ └── SKILL.md # 通常のスキル ``` `skills/` ディレクトリには通常のスキルが格納されます。プラグインによって新しいスキルの 形式が追加されることはありません。`SKILL.md` の形式については、[Creating Skills](/ja/cli/extensibility/skills/creating-skills) を参照してください。 1 つのリポジトリ (または 1 つの `git-subdir` サブフォルダー) が 1 つのプラグインです。1 つのリポジトリで 複数のプラグインをサブフォルダーとしてホストでき、それぞれを独自の `git-subdir` ソースで参照できます。 スキルに加えて、プラグインには次のものを含めることができます: * **ルール** — プラグインルートにある `AGENTS.md` は、プロジェクト独自のルールとあわせて、すべてのセッションで常時適用 ルールとして読み込まれます。`rules/` フォルダー内の Markdown ファイルも読み込まれ、 [Windsurf rules](/ja/cli/extensibility/rules#rules-from-other-tools) と同じ `trigger` frontmatter と [activation types](/ja/cli/extensibility/rules#rule-activation-types) を使用します。 * **カスタムサブエージェント** — `agents/.md` または `agents//AGENT.md` プロファイル (プロジェクトの サブエージェントと同じ [custom subagent format](/ja/cli/subagents#custom-subagents)) で、 `:` として利用できます。現在、プラグインのサブエージェントが読み込まれるのはローカルの Devin エージェント のみ、つまり CLI と Devin Desktop で、cloud Devin セッションでは読み込まれません。 * **フック** — プラグインルートにある `hooks.json` は、プラグインがインストールされている ローカルの Devin セッション (CLI と Devin Desktop) で [ライフサイクルフック](/ja/cli/extensibility/hooks/lifecycle-hooks) を登録します。プラグインフックは 現在**ベストエフォートでフェイルオープン**です。フックの読み込みまたは実行に失敗しても、 セッションはフックなしで継続するため、重要な ガードレールにはまだ依存しないでください。 * **MCPサーバー** — プラグインは、セッションの開始時に起動する任意の [MCPサーバー](/ja/cli/extensibility/mcp/overview) を提供できます。 そのツールは Devin で利用できます。CLI では、プラグインの OAuth サーバーを [`devin mcp login`](/ja/cli/extensibility/mcp/configuration#troubleshooting) で認証します。 クラウドセッションでは、web app で作成された接続が使用されます ( [MCPs](/ja/product-guides/plugins#mcps) を参照)。プラグインの MCP 設定では OAuth クライアント ID とスコープを設定できますが、クライアントシークレットは設定できません。クライアントシークレットを含むサーバー設定は 有効化時に拒否されます。シークレットは `${NAME}` として参照してください。 設定に直接書き込まれたリテラル値は削除されます。
### 互換形式
上記のレイアウトはDevin独自のプラグイン形式です。Devinは、以下のマニフェスト優先順位でパッケージ化された、他の2つのレイアウトのプラグインも読み込みます。 `.devin-plugin/plugin.json` > `.claude-plugin/plugin.json` > ルートの `plugin.json`: * **Claudeプラグイン** — `.devin-plugin/plugin.json` がない場合、Devinは `.claude-plugin/plugin.json` にフォールバックします。Claudeプラグインでは、ルートの `.mcp.json` と マニフェストの `mcpServers` フィールドが使用され、サーバー設定内の `${CLAUDE_PLUGIN_ROOT}` は プラグインルートに展開されます。 * **Agentプラグイン** — オープンな [Agent Plugins 1.0.0](https://github.com/agentplugins/agent-plugins-spec) 仕様 (プラグインルートに `plugin.json` マニフェスト、ルートの `mcp.json` にMCPサーバー、`skills/` 配下にスキル) に従ってパッケージ化されたプラグインも読み込まれます。これらのプラグインでは、ルートの `mcp.json` は通常のMCPソースとして読み取られます (サーバー名が競合した場合は `.mcp.json` が優先されます) 。レガシーなDevin/Claudeレイアウトのプラグインでは、 マニフェストで明示的に宣言されない限り読み取られません。MCPエントリでは、 `transport` の代わりに仕様の `type` フィールド (`stdio`、 `streamable-http`、または `sse`) でトランスポートを指定でき、サーバー設定内の `${PLUGIN_ROOT}` は `${CLAUDE_PLUGIN_ROOT}` と同様にプラグインルートに展開されます。 認識されない `$schema` バージョンについては警告が表示されますが、プラグインは可能な限り読み込まれます。 AgentプラグインのMCPサーバーには、仕様で定められたランタイム規約も適用されます (これらは マニフェストがルートの `plugin.json` であるプラグインにのみ適用されます。Devinおよび Claudeレイアウトはこれまでどおり動作します) : * `args`、`env` の値、`cwd` 内の `${PLUGIN_DATA}` は、 永続的で書き込み可能なプラグインごとのデータディレクトリに展開されます。このディレクトリは バージョンではなくプラグインIDをキーとするため、その内容はプラグインの更新後も保持され、 プラグインをアンインストールすると削除されます。 * `stdio` サーバープロセスは、設定で指定された `env` に加えて `PLUGIN_ROOT` と `PLUGIN_DATA` 環境変数を受け取ります。 * サーバーは `cwd` (プラグインルートからの相対パス) を設定できます。デフォルトは プラグインルートです。`./` で始まる `command` はプラグインルートを基準に解決されるため、 プラグインは独自の実行可能ファイルを同梱できます。どちらもプラグインルートまたはデータディレクトリの 内部に収まるよう検証されます。 ***
## プラグインのインストール
プラグインのソースには、GitHub の `owner/repo`、git URL、またはローカルパスを指定できます。 プラグインがリポジトリルートより下の階層にある場合は、`#path/to/plugin` を 末尾に追加します。 ```bash theme={null} # GitHubから devin plugins install acme/review-tools # リポジトリのサブフォルダにあるプラグイン devin plugins install acme/plugins#plugins/review # 任意のgitホストから devin plugins install https://gitlab.com/acme/review-tools.git # ローカルフォルダから（作成時に便利） devin plugins install ./my-plugin # このマシンのみにインストールし、Devin Cloud の個人プラグインには同期しない devin plugins install --local ./my-plugin ``` インストール前に、Devin はそのプラグインで追加される内容 (提供される スキル、自動的にインストールされる必須プラグイン、追加されるポリシー (たとえば、他のプラグインを禁止するポリシーなど) ) を表示します。確認 プロンプトをスキップするには、`-y` / `--yes` を指定します。 プラグインは **ユーザー** レベルでインストールされ、すべての プロジェクトで利用できます。既定では、`install` はプラグインを Devin Cloud 上の個人用マニフェストに記録するため、サインインしたすべてのマシン (および クラウドセッション) で同じプラグインが読み込まれます。現在のマシンにのみ インストールする場合は `--local` を指定します。プラグインの管理にはサインイン (`devin auth login`) が必要です。Enterprise はメンバーに対して CLI プラグインを 無効化できます。その場合、インストール済みのプラグインは適用されません。 ***
## プラグインの管理
```bash theme={null} # インストール済みプラグインとそのバージョン、ポリシーによってブロックされているものがあるかを一覧表示 devin plugins list # プラグインのスキル、フック、ルール、および必須/任意/禁止の一覧を表示 devin plugins info review-tools # プラグイン（またはすべてのプラグイン）を最新バージョンで再取得 devin plugins update review-tools devin plugins update # 個人のプラグインからプラグインを削除（自動インストールされた必須プラグインはそのまま残る） devin plugins remove review-tools # このマシンからのみ削除（個人のプラグインに含まれるプラグインの場合は失敗する） devin plugins remove review-tools --local # ディスク上に存在しなくなったリポジトリのプラグイン要件を破棄し、未使用のプラグインコンテンツを回収 devin plugins prune ``` `remove --force` は、他のプラグインやガバナンスマニフェスト がまだそのプラグインを必要としている場合でも削除します。ガバナンスで必須とされているプラグインは、要求元の scope における次回セッションで再インストールされ、CLI はどの enterprise、組織、またはリポジトリの configuration がまだそれを必要としているかを警告します。 ローカルフォルダのプラグインはソースフォルダに直接リンクされるため、編集内容は即時に反映されます。 `devin plugins install --local ./my-plugin` → `skills//SKILL.md` を編集 → 次のセッションで変更が適用され、`update` は不要です。 CLI にはプラグインがあるのに Customize では内容が欠落している、または古いままになっている場合は、[インデックスの問題を解決する](/ja/product-guides/plugins#resolve-indexing-issues)を参照してください。 `devin plugins update` はローカルのプラグイン内容を更新し、Customize の **Reindex plugins** は Web 上の一覧を更新します。`--local` で行ったインストールは、このデバイス内にとどまります。 ***
## マニフェスト
`.devin-plugin/plugin.json` はプラグインを定義します。必須なのは `name` のみで、 インストール済みプラグイン内で一意である必要があります (`/:…` 名前空間になります) 。 名前は小文字の英数字を単一の `-` または `.` で区切った形式です (例: `review-tools`、`acme.tools`)。 ```jsonc theme={null} { "name": "review-tools", "version": "1.0.0", "description": "Code-review skills for our team", "requiredPlugins": [ "acme/secure-base", { "source": "github", "repo": "acme/audit-logging" } ], "optionalPlugins": [ "acme/deploy-tools", { "source": "url", "url": "https://gitlab.com/acme/extra.git" } ], "forbiddenPlugins": ["sketchy-org/bad-plugin", "acme/*", "*"] } ```
### メタデータ
`name`、`version`、`description`、`author` (`{ name, email }`)、`homepage`、 `repository`、`license`、`keywords`。プラグインの プラグインIDと名前空間に使用されるのは `name` のみです。その他は説明用であり、 `devin plugins info` に表示されます。
### スキルとルール
`skills` フィールドでは、デフォルトの `skills/` ディレクトリの代わりに、スキルの読み込み元を指定します。プラグインルートからの相対パスを1つ、またはその配列を指定できます。 ```jsonc theme={null} { "skills": "custom-skills" } { "skills": ["skills", "extra/skills"] } ``` 空の配列 (`"skills": []`) を指定すると、スキル の読み込みは完全に無効になります。パスは プラグイン内に限定する必要があります。絶対パス、`~`、`..` を使ったディレクトリトラバーサルは拒否され、 無効なエントリが 1 つでもあるとマニフェスト全体が無効になります。 ルールは `skills` とは独立して読み込まれます。プラグインルートの `AGENTS.md` は 常時適用され、`rules/` ディレクトリ内の Markdown ファイルはトリガーされる ルールとして読み込まれます。有効化の詳細については、[ルール](/ja/cli/extensibility/rules)を参照してください。
### MCP サーバー
`mcpServers` フィールドでは、[MCPサーバー](/ja/cli/extensibility/mcp/overview)の 宣言を追加できます。プラグインでは、慣例的なルート `.mcp.json` (Agent Plugins のルートマニフェストレイアウトを使用するプラグインの場合は `mcp.json`) も使用できます。以下の 4 つの形式が使用できます。 ```jsonc theme={null} // 宣言ファイルが1つの場合 { "mcpServers": "config/mcp.json" } // 複数の場合、記載順に読み込まれる { "mcpServers": ["config/mcp.json", "config/extra.json"] } // これらのファイルのみ — ルートの .mcp.json / mcp.json の規約を無効化する { "mcpServers": { "paths": ["config/mcp.json"], "exclusive": true } } // インラインのサーバーマップ（空でない場合はルートの規約を無効化する） { "mcpServers": { "linear": { "command": "npx", "args": ["-y", "linear-mcp"] } } } ``` 宣言されたパスには `skills` と同じ包含ルールが適用されますが、安全でない エントリはプラグイン全体を失敗させるのではなく除外されます。`mcpServers` フィールドが無効な場合は MCP の読み込みのみが無効になり、スキル、ルール、フックは引き続き使用できます。 空の配列では宣言ファイルは追加されませんが、root の規則は抑制されません。 空のインラインマップでも同様に、root の規則は有効なままです。同じ サーバー名が複数のソースに含まれる場合は、最初のソースが優先されます。
### 依存関係
依存関係のエントリは**ソース**です。文字列の短縮形式またはオブジェクトのいずれかです。 | 形式 | 意味 | | ------------------------------------------------------------------ | ----------------------------- | | `"owner/repo"` | GitHub リポジトリ | | `"https://…"`, `"git@…"`, `"ssh://…"` | あらゆる git URL | | `{ "source": "github", "repo": "owner/repo" }` | GitHub、オブジェクト形式 | | `{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }` | git URL、オブジェクト形式 | | `{ "source": "git-subdir", "url": "…", "path": "sub/dir" }` | 共有リポジトリのサブフォルダ内にあるプラグイン | | `{ "source": "github", "repo": "owner/repo", "sha": "3f2a9c1…" }` | 特定のコミットに固定 — 項目を編集しない限り変わりません | | `{ "source": "github", "repo": "owner/repo", "ref": "v2" }` | ブランチまたはタグを追跡 — 更新のたびに再解決されます | `sha` と `ref` はすべてのオブジェクト形式 (`github`、`url`、`git-subdir`) で利用でき、どちらか一方しか指定できません。`sha` は固定を意味し、`ref` は変動します。どちらも指定しない場合、ソースはリポジトリのデフォルトブランチを追跡します。 同じリポジトリを指すすべての GitHub 形式 (`owner/repo`、HTTPS URL、`.git` URL、SSH 形式) は、同じプラグインの識別子として扱われます。 プラグインでは3つのリストを定義でき、これにより1つのプラグインを、他のプラグインを厳選して管理するコレクションとして機能させることができます。
#### `requiredPlugins`
プラグインのインストール時に、自動的に (再帰的に) インストールされます。必須プラグインがポリシーによってブロックされている場合、インストール全体が失敗し、部分的にインストールされることはありません。
#### `optionalPlugins`
このプラグインが許可するプラグインの**許可リスト**です。これらが自動的にインストールされることは**ありません**。このリストが意味を持つのは、禁止項目に対する例外としてのみです (以下を参照) 。
#### `forbiddenPlugins`
プラグイン ID と glob パターンの**禁止リスト**です。 `forbiddenPlugins` の各エントリは、プラグインの識別子に対して照合されます。 * **完全一致の識別子**。`owner/repo` または git URL 形式で記述します。同じリポジトリを指す GitHub の各形式 (`owner/repo`、HTTPS URL、`.git` URL、SSH 形式) は、いずれも同じ識別子として扱われます。 * **glob パターン** — `*` を含む任意のエントリです。`*` は `/` を含む任意の文字列に一致します。たとえば、`acme/*` は `acme` の GitHub リポジトリすべてに一致し、`*/secrets` は任意のオーナー配下の `secrets` という名前のリポジトリに一致し、`https://gitlab.com/acme/*` はそのパス配下の任意のリポジトリに一致します。 * 単独の `"*"`。これはそれ以外のすべてに一致します (完全なロックダウン) 。 これらのリストは、deny 優先で組み合わされます。 * **Deny wins.** アクティブなマニフェストまたはインストール済みプラグインのいずれかで禁止されている場合、そのプラグインはブロックされます。何も禁止されていなければ、何もブロックされません。 * **Self-override.** マニフェスト (またはプラグイン) 自身の `requiredPlugins` と `optionalPlugins`、およびプラグインの場合はそのプラグイン自身は、その**自身の**禁止リストの適用対象外です。したがって、`"forbiddenPlugins": ["*"]` と `"optionalPlugins": ["acme/approved"]` を組み合わせると、「このマニフェストに列挙されたものだけを許可し、それ以外はすべて禁止する」という意味になります。この例外が適用されるのは、それらの直接のエントリだけであり、required plugin の推移的な依存関係には適用されません。ロックダウン時は、それらも明示的に列挙してください。 * **No cross-scope re-permitting.** あるマニフェストまたはプラグインの許可リストで、**別の**マニフェストまたはプラグインが禁止したものを再び許可することはできません。`"forbiddenPlugins": ["*"]` によるロックダウンは、より低いスコープからは回避できません。 適用は次の 2 つの時点で行われます。 * **Install time** — ブロックされたプラグイン (または required plugin の要件を満たせないプラグイン、あるいはインストール済みプラグインと名前が競合するプラグイン) のインストールは拒否されます。 * **Load time** — プラグインがすでにインストールされた後でブロックされた場合でも、ディスク上には残りますが、そのスキルはセッション開始時にスキップされ、どの禁止元によるものかを示す警告が表示されます。 禁止対象の ID には、上記の `owner/repo` 形式や git URL 形式に加えて、**ローカルパス** (ローカルフォルダからインストールするプラグイン用) も指定できます。 ***
## 継承とレベル
プラグインは1か所で宣言されるわけではありません。自身でインストールしたものに加えて、プラグインはリポジトリや組織の管理者によって 必須、推奨、または禁止にされることがあります。 それぞれのソースは**レベル**であり、レベルは**権限の強さ**に従って 高いものから順に並びます。 1. **Enterprise** — enterprise管理者が設定する、アカウント全体で管理される 管理対象マニフェスト。 2. **Org** — enterpriseの下位に重ねられる、orgレベルの管理対象マニフェスト (orgは enterpriseが宣言した内容に追加できますが、それを上書きすることはできません) 。クラウド セッションではそのセッションの組織のマニフェストが使われ、CLIとDevin Desktopでは主要な組織のマニフェストが使われます。 3. **Repo** — checkoutの`.devin/config.json`内にある`requiredPlugins` / `optionalPlugins` / `forbiddenPlugins`で、 作業ディレクトリ (クラウドセッションでは、クローンされた各リポジトリ) から上位へたどって検出されます。 4. **User** — `devin plugins install` (個人マニフェストを通じて同期されます) または このマシン上での`--local`を使って自身でインストールするプラグイン。 CLIはサインイン時にDevin Cloudからenterprise、org、個人の各マニフェストを取得します。 最初の2つは管理者がweb appから管理します ([プラグインガイド](/ja/product-guides/plugins#the-manifest)を参照) 。 どのレベルでも同じ3つのlistを宣言し、同一レベル内では 単一のマニフェストと同様に、同じ[deny優先・自身による上書きルール](#dependencies)で結合されます。 レベルによって追加されるルールは1つだけです。**より高い権限が優先される** ということです。
### より高い権限が優先されます
* 下位レベルでは、上位レベルで禁止されているものを**再び許可する**ことはできません。 * 下位レベルでは、上位レベルで必須とされているものを**禁止する**ことはできません — その禁止は 無視され、プラグイン は引き続き読み込まれます。 したがって、管理者 は リポジトリ や user がオプトアウトできない プラグイン を必須にでき、また、 下位レベルでは再度有効にできない プラグイン を禁止できます。
### denylist は定義されたレベルでのみ上書きできます
allowlist はレベルをまたいで適用されないため、denylist に例外を設ける**唯一**の方法は、 それを定義したのと同じレベルで設定することです。あるレベルの `forbiddenPlugins` は、 同じマニフェスト内の `optionalPlugins` (または `requiredPlugins`) によってのみ上書きでき、下位レベルのリストで上書きされることはありません。 たとえば、Enterprise レベルの管理対象マニフェストを使うと、アカウントで利用できる プラグインを承認済みの 1 つのみに制限できます。 ```jsonc theme={null} // Enterpriseレベルの管理マニフェスト { "forbiddenPlugins": ["*"], "optionalPlugins": ["acme/approved"] } ``` これは、"アカウント全体で `acme/approved` のみを許可し、それ以外の すべてのプラグインを禁止する。"という意味です。org、リポジトリ、user のいずれも、この許可リストを 広げることはできません。プラグインをインストールしても、下位レベルの `optionalPlugins` に追加しても 同様です。 この例外は、このマニフェストに直接記載されているエントリにしか適用されません。必須 プラグイン自体の推移的依存関係は免除されないため、ロックダウン下ではそれらも 明示的に列挙してください。
### 競合と依存関係
* 同じプラグインに対する require と 禁止する が**同じレベル**で、しかも **異なるマニフェスト** (たとえば個別にインストールされた 2 つのユーザーレベル プラグイン) から指定されている場合は、禁止する が優先されます。許可リスト が除外できるのは *そのマニフェスト自身* のエントリだけなので、別のマニフェストで 禁止する された プラグインを覆すことはできません。 (1 つのマニフェスト内では、そのマニフェスト自身の required / optional は、[前述のとおり](#a-denylist-is-only-overridden-at-its-own-level)、そのマニフェスト自身の forbids の 対象外のままです。) * ガバナンスによってブロックされたプラグインは **soft-fails** します。セッション開始時に、その スキルは 禁止する を指定した主体を示す警告とともにスキップされ、セッションは中断されません。 * 依存先であることによる除外はありません。推移的依存関係としてのみ取り込まれた プラグインであっても、それに適用されるすべての 禁止する の対象であり続け、さらにそれを require するプラグインのうち、最も高い権限レベルを継承します。 * **pin の競合** (2 つのマニフェストが同じプラグインを異なる `sha` に pin している場合) は、 pin をそろえるか、pin をより高い権限レベルに委ねることで解決してください。 * セッション開始時に管理対象マニフェストを取得できなかった場合、そのレベルは **open** に フェイルします。そのレベルからは何もインストールされず、そのセッションではそのレベルの forbids も適用されません。