メインコンテンツへスキップ
Enterprise Plugin Registryは、組織が社内全体での配布用に承認されたプラグインを管理する、中央集約型のプライベートリポジトリです。各チームが個別にプラグインを発見し検証する代わりに、レジストリは事前承認済み、保守され、すぐに使用可能な機能のキュレートされたカタログを提供します。

​
Enterprise Plugin Registryを使用する理由

課題解決策
チーム間でのツールの一貫性の欠如承認されたプラグインの単一ソースにより、全員が同じ機能を使用することを保証
各プラグインのセキュリティとコンプライアンス審査組織レベルでプラグインを一度審査し、どこでも配布
新しい開発者のオンボーディング新しいチームメンバーが承認されたすべての機能に即座にアクセス
役割固有のツールチーム機能別（セキュリティ、フロントエンド、データなど）にプラグインをパッケージ化
バージョン管理プラグインバージョンを中央管理し、組織全体でアップデートを展開

​
レジストリの設定

Enterprise Plugin Registryは、組織の承認されたプラグインとマーケットプレイスマニフェストを含むGitリポジトリです。

​
リポジトリ構造

your-org/droid-plugins/
├── .factory-plugin/
│   └── marketplace.json      # Registry manifest
├── plugins/
│   ├── security-toolkit/     # Security team plugins
│   │   ├── .factory-plugin/
│   │   │   └── plugin.json
│   │   └── skills/
│   ├── frontend-standards/   # Frontend team plugins
│   │   ├── .factory-plugin/
│   │   │   └── plugin.json
│   │   └── skills/
│   ├── data-engineering/     # Data team plugins
│   │   └── ...
│   └── platform-tools/       # Platform/DevOps plugins
│       └── ...
└── README.md

​
マーケットプレイスマニフェスト

プラグインを登録するために.factory-plugin/marketplace.jsonを作成します： 
{
  "name": "acme-corp-plugins",
  "description": "ACME Corp approved Droid plugins",
  "owner": {
    "name": "ACME Platform Team",
    "email": "platform@acme.com"
  },
  "plugins": [
    {
      "name": "security-toolkit",
      "description": "Security review, threat modeling, and vulnerability scanning",
      "source": "./plugins/security-toolkit",
      "category": "security"
    },
    {
      "name": "frontend-standards",
      "description": "React component patterns, accessibility checks, design system integration",
      "source": "./plugins/frontend-standards",
      "category": "frontend"
    },
    {
      "name": "data-engineering",
      "description": "SQL review, pipeline validation, data quality checks",
      "source": "./plugins/data-engineering",
      "category": "data"
    },
    {
      "name": "platform-tools",
      "description": "CI/CD helpers, infrastructure review, deployment automation",
      "source": "./plugins/platform-tools",
      "category": "platform"
    }
  ]
}

​
組織レベルの設定

レジストリを組織レベルで設定することで、すべてのユーザーが自動的に利用できるようになります。組織管理設定に追加します： 
{
  "extraKnownMarketplaces": {
    "acme-corp-plugins": {
      "source": {
        "source": "github",
        "repo": "your-org/droid-plugins"
      }
    }
  },
  "enabledPlugins": {
    "security-toolkit@acme-corp-plugins": true,
    "platform-tools@acme-corp-plugins": true
  }
}
フィールド目的
extraKnownMarketplacesユーザーがプラグインを閲覧・インストールできるようにマーケットプレイスを登録
enabledPluginsすべてのユーザーに特定のプラグインを事前インストール（オプション）

​
マーケットプレイスの制限

ユーザーが未承認のマーケットプレイスを追加することを防ぐには、strictKnownMarketplacesを使用します： 
{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "your-org/droid-plugins" },
    { "source": "github", "repo": "Factory-AI/factory-plugins" }
  ]
}
strictKnownMarketplacesが設定されている場合：
  • ユーザーは承認リストからのマーケットプレイスのみ追加可能
  • 未承認のマーケットプレイスからのプラグインインストールはブロック
  • 既存の未承認マーケットプレイスは動作し続けるが更新不可
この設定により：
  • ユーザーが/pluginsを実行すると、レジストリが自動的に表示される
  • 事前有効化されたプラグインは手動インストールなしですぐに利用可能
  • ユーザーは必要に応じてレジストリから追加のプラグインをインストール可能

​
ユーザーエクスペリエンス

ユーザーは/plugins UIを通じてプラグインを管理します：
  1. /pluginsを実行してプラグインマネージャーを開く
  2. ブラウズタブで組織レジストリを含む登録されたすべてのマーケットプレイスからプラグインを閲覧
  3. 組織が有効にしたプラグインは起動時に自動的に事前インストール
CLI アクセスの場合： 
droid plugin install frontend-standards@acme-corp-plugins
droid plugin update security-toolkit@acme-corp-plugins
ユーザーは公開マーケットプレイスと並んでレジストリを確認でき、組織のプラグインは明確にラベル付けされています。

​
役割別のプラグイン整理

組織のチームとワークフローに合わせてレジストリを構造化します：

​
チーム機能別

plugins/
├── security/           # AppSec team
├── frontend/           # Web/mobile teams  
├── backend/            # API/services teams
├── data/               # Data engineering/science
├── platform/           # DevOps/SRE
└── compliance/         # Legal/compliance

​
機能別

plugins/
├── code-review/        # Review and quality
├── testing/            # Test generation and validation
├── documentation/      # Doc generation and maintenance
├── migrations/         # Code and data migrations
└── security/           # Security scanning and review

​
プロジェクトタイプ別

plugins/
├── microservices/      # Service development patterns
├── monolith/           # Legacy system tools
├── data-pipelines/     # ETL and batch processing
└── ml-projects/        # ML/AI development

​
プラグインの事前インストール

全員が必要とする重要な機能については、組織管理設定でenabledPluginsを使用します： 
{
  "enabledPlugins": {
    "security-toolkit@acme-corp-plugins": true,
    "code-standards@acme-corp-plugins": true
  }
}
事前インストールされたプラグイン：
  • 初回のDroidセッションですぐに利用可能
  • orgスコープで自動的にインストール
  • /plugins UIまたはdroid plugin updateで更新可能

​
バージョン管理

プラグインはGitコミットハッシュでバージョン管理されます。プラグインが更新されると、Droidはマーケットプレイスから最新のコミットを取得します。 バージョンを制御するには、Gitブランチを使用します：
  • main - すべてのユーザー向けのプロダクション準備完了
  • staging - 早期採用者向け
  • dev - 内部テスト向け
Version pinning via the version field is not currently supported. The field is for documentation only.

​
プライベートリポジトリアクセス

プライベートGitリポジトリの場合、Droidが認証できることを確認します：

​
GitHub Enterprise

# Users authenticate via gh CLI
gh auth login --hostname github.your-company.com

​
GitLab セルフホスト

# Configure git credentials
git config --global credential.helper store

​
SSHベースのアクセス

リポジトリホスト用のSSHキーが設定されていることを確認してください。

​
ローカルマーケットプレイス

エアギャップ環境やGitアクセスが制限されている場合、ローカルディレクトリマーケットプレイスを使用できます。これは以下の場合に便利です：
  • インターネットアクセスがない環境
  • 公開前のプラグインテスト
  • 共有ネットワークドライブ経由での内部配布

​
ローカルマーケットプレイスの設定

標準的なマーケットプレイス構造でディレクトリを作成します： 
/shared/company-plugins/
├── .factory-plugin/
│   └── marketplace.json
└── plugins/
    ├── security-toolkit/
    │   └── .factory-plugin/
    │       └── plugin.json
    └── code-standards/
        └── .factory-plugin/
            └── plugin.json

​
ローカルマーケットプレイスの追加

UI経由：/plugins → マーケットプレイスタブ → 「新しいマーケットプレイスを追加」→ 絶対パスを入力 CLI経由： 
droid plugin marketplace add /shared/company-plugins

​
自動登録の設定

設定でlocalソースタイプを使用します： 
{
  "extraKnownMarketplaces": {
    "company-local-plugins": {
      "source": {
        "source": "local",
        "path": "/shared/company-plugins"
      }
    }
  }
}
When removing a local marketplace from the registry, Droid does not delete the source directory. Only Git-cloned marketplaces have their directories removed on deletion.

​
ベストプラクティス

Before adding plugins to the registry:
  • Security review for any external dependencies
  • Code review by platform team
  • Testing in isolated environment
  • Documentation requirements
Every plugin should have a README covering:
  • What capabilities it provides
  • When to use it (and when not to)
  • Any prerequisites or dependencies
  • Example usage
Use semantic versioning so teams know what to expect:
  • Major: Breaking changes to commands or behavior
  • Minor: New capabilities, backward compatible
  • Patch: Bug fixes only
Track which plugins are being used:
  • Installation counts
  • Active usage metrics
  • Feedback from teams
  • Issues and feature requests
When retiring plugins:
  • Announce deprecation timeline
  • Provide migration path to alternatives
  • Keep deprecated plugins available (read-only) during transition

​
例：金融サービス組織

金融サービス会社がレジストリを設定する場合： 必須プラグイン（全員に事前インストール）：
  • compliance-checks - PCI-DSSおよびSOXコンプライアンス検証
  • security-scanner - OWASP脆弱性検出
  • audit-logging - すべてのDroidアクションの強化された監査証跡
チーム固有プラグイン（インストール可能）：
  • trading-systems - 定量分析および取引チーム向け
  • risk-models - リスク管理チーム向け
  • regulatory-reporting - コンプライアンスチーム向け
設定 (org-managed-settings.json): 
{
  "extraKnownMarketplaces": {
    "acme-financial-plugins": {
      "source": {
        "source": "github",
        "repo": "acme-financial/droid-plugins"
      }
    }
  },
  "enabledPlugins": {
    "compliance-checks@acme-financial-plugins": true,
    "security-scanner@acme-financial-plugins": true,
    "audit-logging@acme-financial-plugins": true
  }
}
これにより、すべての開発者が初日からコンプライアンスとセキュリティツールを持ちながら、専門チームはドメイン固有の機能を追加できます。

​
関連