Skip to main content
プラグインはクローズドベータです。アクセスをリクエストするには、support@cognition.ai までお問い合わせください。今後のリリースで、動作や設定が変更される場合があります。

プラグインとは?

プラグインは、インストールしてひとまとまりで再利用できるように、複数のskills — および任意でルール、フック、MCPサーバー — をまとめてパッケージ化したものです。skill は 1 つのリポジトリ内にありますが、プラグインは持ち運び可能なソース (GitHub リポジトリ、git URL、リポジトリのサブフォルダー、またはアップロードした .zip) であり、org または Enterprise 全体で必須にできます。 管理対象のプラグイン を使うと、管理者は Devin の Web アプリからプラグインを一元的にインストールでき、org または Enterprise 内の全員に適用できます。ユーザーごとのセットアップは不要です。これはクラウド上の Devin セッション、アカウントにログインしている Devin CLI ユーザーの両方を対象とします (Enterprise / アカウントレベルの設定は CLI にも適用されます。詳しくは クラウドセッションと CLI の違い を参照してください) 。プラグインがインストールされると、その skills は /<plugin>:<skill> コマンドとして自動的に Devin で利用できるようになります。 このページでは、プラグインのクラウド側 (Web アプリ) について説明します。プラグインのファイル形式と CLI のユーザー単位のインストール手順については、CLI プラグイン リファレンス を参照してください。

設定場所

Settings → Marketplace に移動します。このページには 2 つのタブがあります。
  • Marketplace — プラグイン (Devin の公式カタログに加え、組織または Enterprise が追加したもの) を参照してインストールできます。プラグインをインストールすると、選択したスコープの manifest に必須プラグインとして追加されるため、そのスコープ内の全員にインストールされます。
  • Configuration — プラグインの生の manifest を JSON として編集し、独自のプラグインをフォルダーまたは .zip としてアップロードできます (または Editor で作成できます) 。
アクセスは権限によって制御されます。
  • org 管理者 (組織設定へのアクセス権を持つユーザー) は、org の manifest を管理します。
  • Enterprise 管理者 (Enterprise 設定へのアクセス権を持つユーザー) は、共有の Enterprise manifest も管理します。

マニフェスト

マニフェストは、3つのリストを含む1つのJSONドキュメントです。
  • requiredPlugins — スコープ内の全員にインストールされます (再帰的に、依存しているプラグインも含みます) 。
  • optionalPlugins — プラグインを自動インストールせずに許可する許可リストです。禁止された項目に対する例外を設けるために利用されます。
  • forbiddenPlugins — プラグインの識別子またはグロブパターンの拒否リストです (例: acme/*、または完全にロックダウンする "*") 。
requiredPlugins / optionalPlugins の各項目は ソース で、文字列の短縮記法またはオブジェクトのいずれかです。 同じリポジトリを指すすべての GitHub 形式 (owner/repo、HTTPS URL、.git URL、SSH 形式) は、同じプラグインの識別子として扱われます。 マニフェストはそのまま保存され、エージェントはインストール時に完全なソースを検証します。

ガバナンスルール

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. マニフェスト (またはプラグイン) 自身の requiredPluginsoptionalPlugins、およびプラグインの場合はそのプラグイン自身は、その自身の禁止リストの適用対象外です。したがって、"forbiddenPlugins": ["*"]"optionalPlugins": ["acme/approved"] を組み合わせると、「このマニフェストに列挙されたものだけを許可し、それ以外はすべて禁止する」という意味になります。この例外が適用されるのは、それらの直接のエントリだけであり、required plugin の推移的な依存関係には適用されません。ロックダウン時は、それらも明示的に列挙してください。
  • No cross-scope re-permitting. あるマニフェストまたはプラグインの許可リストで、別のマニフェストまたはプラグインが禁止したものを再び許可することはできません。"forbiddenPlugins": ["*"] によるロックダウンは、より低いスコープからは回避できません。
適用は次の 2 つの時点で行われます。
  • Install time — ブロックされたプラグイン (または required plugin の要件を満たせないプラグイン、あるいはインストール済みプラグインと名前が競合するプラグイン) のインストールは拒否されます。
  • Load time — プラグインがすでにインストールされた後でブロックされた場合でも、ディスク上には残りますが、そのスキルはセッション開始時にスキップされ、どの禁止元によるものかを示す警告が表示されます。
これらのルールに加えて、管理対象マニフェストはティア構造になっています。優先順位は enterprise/account が最上位、次に org、その下に repo 単位および user-level の plugin 設定が続きます。上位の権限が優先されるため、下位ティアで上位ティアが必須としている plugin を禁止することはできず、上位ティアが禁止している plugin を再度許可することもできません。したがって、org での禁止では enterprise で必須の plugin をブロックできませんが、enterprise での禁止は org での必須指定より優先されます。

独自のプラグインを追加する

プラグインは、.devin-plugin/plugin.json マニフェストと、通常のskillsを格納した skills/ フォルダを含む、単なるディレクトリです。
skills に加えて、プラグインには次のものを含めることもできます。
  • ルール — プラグインのルートにある AGENTS.md は、クラウドセッションでも CLI でも、すべてのセッションで常時適用のルールとして挿入されます。rules/ フォルダ内の Markdown ファイルも読み込まれ、trigger frontmatter に従って適用されます — CLI プラグイン リファレンス を参照してください。
  • フック — プラグインのルートにある hooks.json は、セッション内で実行される ライフサイクルフック を登録します。クラウドセッションでは、SessionStartSessionEnd を除くすべてのイベントで command フックが実行されます — そのため、PreToolUsePostToolUsePermissionRequestUserPromptSubmitStopPostCompaction はすべて動作します。prompt タイプのフックは CLI/ローカル専用です。
  • MCPサーバー — プラグインのルートにある mcp_config.json は、プラグインがインストールされているすべてのセッションで読み込まれる MCP サーバー ("mcpServers": { "<name>": { … } }) を定義します。これらはまだ MCP 設定 UI には表示されませんが、そのツールは Devin から利用できます。プラグインの MCP 設定では OAuth クライアント ID とスコープを設定できますが、OAuth クライアントシークレットは設定できません — これを含むサーバー設定は有効化時に拒否されます。
  • カスタムサブエージェントagents/<name>.md (または agents/<name>/AGENT.md) のプロファイルです。これらは現在、ローカルの Devin エージェント — Devin CLI と Devin Desktop — でのみ読み込まれ、クラウドセッションでは読み込まれません。
プラグイン はインストールの単位です: プラグイン をインストールすると、その プラグイン に含まれるすべての skills (および requiredPlugins に含まれるもの) がインストールされます。プラグイン から個別の skills をインストールすることはできません。skills を個別に提供したい場合は、別々の プラグイン に分割してください。plugin.json の完全な形式とローカルでの作成フローについては、CLI プラグイン リファレンス を参照してください。 プラグイン の配置場所に応じて、次のいずれかの方法で追加します。 1 つの リポジトリ (または 1 つの git-subdir サブフォルダ) が 1 つの プラグイン です。1 つの リポジトリ に複数の プラグイン をサブフォルダとして配置し、それぞれを個別の git-subdir エントリで参照できます。

プラグイン バンドルのアップロード

Configuration タブの Uploaded plugin セクションでは、プラグインをフォルダーまたは .zip としてアップロードするか、Editor で直接作成できます。保存すると、必須プラグインとしてマニフェストに追加され (対象範囲内の全員にインストールされます) 、削除するとその参照も削除されます。これは、Git リポジトリでホストしたくない、またはできないプラグインに適した選択肢です。

非公開の skills リポジトリを使う

マニフェストで非公開リポジトリを直接指定します。通常は、環境スナップショットに組み込む必要はありません。Devin が Git 統合経由ですでにアクセスできる非公開リポジトリであれば、自動的にインストールされます。git URL 形式、または共有リポジトリのサブフォルダからプラグインをインストールするための git-subdir を利用してください。 (同じマニフェストを取得する CLI ユーザーは、それぞれのローカル Git 認証情報を使うため、そのユーザーにもリポジトリへのアクセス権が必要です。) リポジトリに Git 統合経由でアクセスできない場合は、バンドルとしてアップロードする (前述) か、環境セットアップ中にクローンしてローカルパスで参照してください。

更新の反映タイミング

  • マニフェストの変更 (Settings → Marketplace) は、次回のセッションから適用されます。
  • プラグインの変更 — プラグインが追跡しているブランチにマージされた変更は、数時間以内に新しいセッションへ自動的に反映されます。更新を自分で管理したい場合は、プラグインを commit SHA に固定してください。CLI では、devin plugins update を実行すると即座に更新されます。
  • 実行中のセッションでは、開始時に読み込まれた内容がそのまま維持されます。更新によって進行中のセッションが途中で変更されることはありません。

互換性

Claude プラグイン も利用できます: .devin-plugin/plugin.json がない場合、Devin は .claude-plugin/plugin.json を代わりに使用します。両方の マニフェスト がある場合は、Devin 側が優先されます。

スコープと継承

管理対象のマニフェストは、最大 2 つのレベルで存在します。
  • Standalone accounts には、全員に適用される単一の account マニフェストがあります。
  • Enterprises には、すべての子 org に継承される 共通の enterprise マニフェストがあり、その下に org ごとのマニフェストが重なります。Marketplace ビューには両方が表示され、enterprise admins は Enterprise スコープでプラグインをインストールすること (全体に適用) も、org admin は自分の org にのみインストールすることもできます。
これらは、repo ごとまたは user ごとのプラグイン設定より上位にある、プラグイン階層全体の最上位に位置します。
  1. Enterprise / account マニフェスト (このページ)
  2. Org マニフェスト (このページ)
  3. Repo レベルのプラグイン設定 (repo の .devin/config.json)
  4. User レベルのプラグイン — 各ユーザー自身がインストールした CLI のもの。各自のローカルの Devin agent にのみ適用され、クラウドセッションでは読み込まれません
上位の権限が優先されます。下位レベルでは、上位レベルで禁止されているプラグインを許可することも、上位レベルで必須とされているプラグインを禁止することもできません (governance rules を参照) 。

クラウドセッションと CLI の違い

クラウドセッションと Devin CLI はどちらも enterprise/account マニフェストを適用します。必須プラグインはインストールされ、禁止設定はそのアカウントにログインしている CLI ユーザーにも適用されます。 org マニフェストが適用されるのは クラウドセッション のみです。CLI はアカウントレベルで認証され、org の前提情報を持たないため、org レベルの必須事項や禁止事項は CLI ユーザーには適用されません。CLI で適用する必要があるもの (またはアカウント全体で適用する必要があるもの) は enterprise/account マニフェストに含め、org マニフェストはクラウドセッションへの org 固有の追加に利用してください。

詳しく知る

  • Skills — プラグインに同梱される SKILL.md の手順
  • CLI プラグイン リファレンス — プラグインのファイル形式、作成方法、ユーザーごとのインストール
  • プレイブック — セッションにアタッチされる再利用可能なプロンプトテンプレート