Skip to main content
このガイドでは、独自のプラグインエコシステムを構築する方法を説明します。これは、組織が所有するプラグインのリポジトリを、管理対象のマニフェストを通じてすべてのDevinセッションとCLIユーザーに配布し、必須・任意・禁止の各プラグインをガバナンスの制御手段として使う構成です。 このガイドには、2つのテンプレートリポジトリが付属しています。
  • plugin-template — 単一のプラグイン (または少数のプラグイン) を作成するためのスターターテンプレートです。
  • team-marketplace-template — 完全なエコシステムの構成パターンです。プラグインのモノレポに加え、マニフェストでベースラインとポリシーを定義するメタプラグインも含まれています。

1. プラグインを作成する

プラグインとは、.devin-plugin/plugin.json マニフェストを含むディレクトリのことです。それ以外はすべて任意です。
まずは plugin-template をフォークし、完全なフォーマットについては CLI プラグイン リファレンス を参照してください。AGENTS.md は短く保ってください。そのプラグインを使う全員のすべてのセッションで前提情報を消費してしまうためです。

2. ローカルで検証とテストを行う

どちらのテンプレートにも、バリデーター (node scripts/validate-template.mjs) と、すべてのPRでこれを実行するCIワークフローが含まれています。実際に試すには、Devin CLIを使ってローカルフォルダーからインストールします:
また、Customize → プラグインからプラグインフォルダーまたは.zipを個人スコープにアップロードし、クラウドセッションで試すこともできます。

3. 1つのリポジトリで管理する

組織のすべてのプラグインを1つのリポジトリ内のサブフォルダ (plugins/<name>/) に配置し、それぞれを固有のgit-subdirソースで参照します。リポジトリは非公開のままでも問題ありません。クラウドセッションはGit統合を通じてこれを取得し、CLIユーザーは各自のgit認証情報で取得します (そのため、リポジトリへのアクセス権も必要です) 。 この構成には、team-marketplace-template をフォークし、そのメタプラグインのgit-subdir URLが自分のforkを指すように更新してください。テンプレートでは、メタプラグインはリポジトリのルートにあるため、リポジトリ自体がインストール可能な単位になります。つまり、your-org/your-marketplaceを指定すると、ベースライン全体がインストールされます。

4. メタプラグインでベースラインを定義する

メタプラグインパターンを使うと、エコシステム全体を1つのインストール可能な単位として扱えます。これは、それ自体にはほとんど、またはまったく内容を持たないプラグインで、マニフェストがその役割を果たします。リポジトリ 自体がメタプラグインになるように、リポジトリ のルートに配置します:

5. Customize から配布する

管理者は、Customize → プラグイン → Add plugin → From repository から、組織または Enterprise スコープで marketplace リポジトリをインストールします。詳しくはプラグインガイドを参照してください。これにより、そのスコープの管理対象のマニフェストに項目が 1 つ追加されます。
marketplace リポジトリを必須にすると、そのルートのメタプラグインがインストールされ、ベースライン全体が再帰的に取り込まれます。その後 Customize がスコープをインデックス化し、取り込まれたすべてのプラグインを、そのスキル・MCP・フック・ルールとあわせて一覧表示します。 これでスコープ内の全員が、クラウドセッション、Devin CLI、Devin Desktop で自動的にベースラインを利用できるようになります。スコープは慎重に選んでください。
  • enterprise マニフェストは、その enterprise 内のすべての組織に適用されます。
  • 組織 マニフェストは、その組織のクラウドセッションと、その組織を主たる組織とするメンバーの CLI/Desktop に適用されます。
ベースラインに認証情報が必要な MCPサーバーが含まれている場合は、インデックス化後に MCPs タブでセットアップを完了してください。Organization アクセスの OAuth サーバーでは、メンバーが共有するサービスアカウントを接続します。Personal アクセスの場合は、各メンバーが自分のアカウントを接続します。ベースラインの内容が反映されていない場合は、インデックス化の問題を解決するを参照してください。

6. ガバナンス

3 つのリストが、すべてのレベル (管理対象マニフェスト、リポジトリ config、プラグイン マニフェストs) で共通のポリシー言語です。競合する場合は、より上位のレベルが優先されます。つまり、enterprise/account は 組織 より、組織 は リポジトリ より、リポジトリ は user より優先され、上位レベルで禁止されたものを下位レベルで再び許可することも、上位レベルで必須とされたものを禁止することもできません。 account を承認済みのもののみに制限するには:
マニフェスト 自身の 必須/任意 エントリは、その マニフェスト 自身の "*" による禁止の対象外ですが、それ以外は対象外ではなく、下位レベルでこの例外範囲を広げることもできません。この例外が適用されるのは 直接列挙された エントリだけであり、必須 プラグイン の推移的な依存関係は対象外になりません。したがって、ロックダウン下では、メタプラグイン が取り込むもの (ここでは engineering-baselinesecurity-guardrails) をすべて明示的に列挙してください。完全な仕様については dependencies and governance を参照してください。

7. 発展

  • プラグインリポジトリのデフォルトブランチにマージすること自体がリリースです。新しいセッションには自動的に反映されます。詳しくは、更新のロールアウト方法 を参照してください。
  • チームは marketplace リポジトリに PR でプラグインを追加し、テンプレートの CI が各 PR でレイアウトを検証します。
  • 既存の Claude プラグインはそのままインストールできます (Devin は .claude-plugin/plugin.json にフォールバックします) 。そのため、optionalPlugins ではコミュニティプラグインをリポジトリに取り込まずに推奨できます。

現在の制限事項

  • プラグインはクラウドセッション、Devin CLI、および Devin Desktop (Devin Local を利用する場合) で読み込まれます。クラシックな Cascade エージェントには適用されません。
  • サブエージェント (agents/<name>.md または agents/<name>/AGENT.md) はローカルの Devin エージェント (CLI と Devin Desktop) でのみ読み込まれ、クラウドセッションでは読み込まれません。
  • フックは現在、ベストエフォートかつフェイルオープンです。つまり、フックの読み込みや実行に失敗してもセッションは停止しません。そのため、現時点では重要なガードレールとして依存しないでください。ローカルでの設定については CLI フックリファレンス を参照してください。
  • ガバナンスはフェイルオープン: セッション開始時に管理対象のマニフェストを取得できない場合、そのレベルのプラグインはインストールされず、そのセッションでは禁止するも適用されません。
  • 非公開リポジトリのプラグインコンテンツは、Git 統合がそのリポジトリにアクセスできる組織でのみ Customize に表示されます。それ以外では、Settings → Repositories でリポジトリへのアクセスが許可されるまで表示されません。

詳細はこちら