> ## Documentation Index
> Fetch the complete documentation index at: https://enterprise-docs.dify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# プラグイン管理

プラグイン管理は、エンタープライズ向け AI 機能拡張の中核となるコンソールです。**エンタープライズ・プラグインのライフサイクル管理センター**として設計されており、統合管理によって、プラグインのバージョン断片化、運用の「ブラックボックス化」、高いセキュリティガバナンスコストといった課題を解決します。これにより、プラグインの集中インストール、統一的な運用監視、全体（グローバル）セキュリティポリシーの制御が可能になります。

## 1. 機能概要

エンタープライズ向け Web アプリケーションでは、プラグインが LLM、ツール、Agent 戦略、データソース、トリガーなどの拡張性の中核を担います。プラグイン管理は主に次の課題を解決します。

* **バージョンの断片化**：同一プラグインがワークスペースごとに異なるバージョンで動作し、トラブルシューティングが困難になる。
* **運用のブラックボックス化**：稼働中のプラグインインスタンス（Pod リソース、環境変数、負荷など）を集中して可視化・監視する手段がない。
* **ガバナンス不足**：グローバルなポリシー制御がなく、信頼できないソースからのインストールを制限しにくい。

### 1.1 価値

* **集中型ライフサイクル管理**：管理者は管理コンソールで、プラグインのワンクリック導入、バージョン切り替え、ワークスペース横断の一括配布／アンインストールを実施できます。
* **インストールしてすぐ使える体験**：ワークスペースに事前インストールしておくことで、各チームの重複設定を削減します。
* **可視化された運用監視**：K8s 環境向けに、プラグインのインスタンス単位でのリソース監視（CPU、メモリ、ネットワーク）を提供し、動的なスケールにも対応します。
* **セキュリティリスク制御**：ポリシーエンジンにより、インストール元と発行者（Publisher）の身元を厳格に制御します。

### 1.2 適用シーン

* **共通基盤の標準化**：IT 部門が全チームに標準ツールセット（例：Google Search、社内 API ツール）を統一して提供したい。
* **リソース最適化**：高頻度で利用されるプラグイン（例：LLM プラグイン）の負荷を監視し、ピーク時に備えて Pod 数を調整したい。
* **セキュリティ／コンプライアンス**：「公式」または「パートナー」提供のプラグインのみ許可し、任意のローカルファイルアップロードを禁止したい。

### 1.3 コア概念

**プラグイン種別**

* **モデル（LLM）プラグイン**：例：OpenAI、Claude、Gemini
* **ツール（Tool）プラグイン**：例：Google Search、GitHub、Web スクレイピングツール
* **Agent 戦略プラグイン（Agent Strategy）**：例：Function call、ReAct などの思考・実行戦略
* **拡張（Extension）プラグイン**：例：センシティブコンテンツ審査、外部 DB コネクタ
* **データソース（Datasource）プラグイン**：例：Notion、Google Drive などのデータ接続元
* **トリガー（Trigger）プラグイン**：例：Gmail Trigger、Outlook Trigger

**実行（ランタイム）エンティティ**

* **インスタンス（Instance）**：システム内で稼働するプラグインの実体です。インスタンス同士は分離されており、再起動／再ビルド／ロールバックが可能です。
* **Pod**：K8s 環境における最小の実行単位です。プラグインコンテナ（Container）を保持し、CPU／メモリ／ネットワークの観測指標を持ちます。

## 2. 操作手順

### 2.0 クイックスタート

プラグイン管理の典型的な運用フローは次のとおりです：**プラグインを導入（マーケット／ローカル） > ワークスペースへ割り当て（インストール） > 監視・運用 > アンインストール／回収**

1. **新しいプラグインを導入**\
   「プラグイン管理」ページで【プラグインをインストール】をクリックし、マーケットからダウンロードするか、ローカルのパッケージをアップロードしてプラグインを登録します。
2. **ワークスペースへ割り当て**\
   プラグイン一覧で【インストール管理】をクリックし、［インストール先を追加］で対象ワークスペースを選択します。システムが対象ワークスペースへ自動的にデプロイし、「入れてすぐ使える」状態になります。
3. **稼働状況を監視（K8s のみ）**\
   プラグイン右側の【···】>【インスタンスを表示】で負荷監視グラフを確認します。性能ボトルネックがある場合は、【リソース設定】で CPU／メモリ上限や Pod 数を増やしてください。

### 2.1 プラグインのインストール

システムは 2 つのインストール方法をサポートします。利用できる方法は、デプロイ環境とセキュリティポリシーに依存します。

**方法 1：Marketplace からインストール（推奨）**

1. 【プラグインをインストール】>【Marketplace】をクリックします。
2. ポップアップまたは新しいタブでマーケットを閲覧します。
3. プラグインと必要なバージョンを選択します。
4. 【インストール】をクリックします。システムが自動で取得し、バックグラウンドでベースインスタンスをデプロイします。

**方法 2：ローカルプラグインのインストール**

1. 【プラグインをインストール】>【ローカルプラグイン】をクリックします。
2. プラグインパッケージファイルをアップロードします。
3. システムが署名とポリシーを検証します。要件を満たさない場合、設定に応じて警告が表示されます（ポリシーの強制はワークスペース側で有効になり、管理コンソールは警告表示のみでインストール自体はブロックしません）。

### 2.2 インストール管理（割り当て・バージョン管理）

管理者は、各ワークスペースへの配布状況と利用バージョンを制御できます。

1. プラグイン一覧で対象プラグインを見つけ、【インストール管理】をクリックします。
2. このバージョンをより多くのワークスペースへ導入：［インストール先を追加］をクリックし、一覧からワークスペースにチェックを入れます。
3. このバージョンをワークスペースから削除：一覧で対象ワークスペースを選んでアンインストールアイコンをクリックするか、［インストール先を追加］で該当ワークスペースのチェックを外します。
4. **バージョン変更の表示**：システムは色で変更内容を示します。
   * **グレー（インストール済み）**：すでにインストール済みです。
   * **グリーン（新規）**：初回インストールです。
   * **ブルー（アップグレード）**：低いバージョンから現行バージョンへ更新（例：1.0.0 -> 1.2.0）。
   * **オレンジ（ダウングレード）**：高いバージョンから現行バージョンへ戻す（例：1.3.0 -> 1.2.0）。
   * **水色（上書き）**：同一バージョンの上書き（プラグインのバージョン checksum を表示。例：1.2.0 SHA-256: 3db71aca）。
5. ダイアログ下部に、今回の変更内容のプレビュー（新規、アップグレード、ダウングレード、上書きインストール、アンインストール）が表示されます。【確認】をクリックすると即時反映されます。

### 2.3 プラグインの実行監視と設定（K8s のみ）

K8s デプロイ環境では、管理者は高度な運用機能を利用できます。Docker Compose 環境では現時点で本セクションはサポートされません。
プラグイン一覧で【...】>【インスタンスを表示】をクリックして詳細ページへ移動します。

**1. 負荷監視**
直近 1 時間／1 日／1 週間の Pod／コンテナ実行データを可視化します。

* CPU 使用状況
* メモリ使用状況
* ネットワークのアップロード／ダウンロードレート
* 注意：クイック操作で、異なる Pod における同種コンテナを比較できます。グラフにはリソース制限線（Limit）が表示されます。

**2. リソース設定**
各コンテナの最大リソース上限を調整できます。

* **CPU コア数**：1 コア未満の値も設定可能です。
* **メモリ容量**：最大メモリ上限を設定します。
* 変更後は【保存して適用】をクリックしてください。反映のためインスタンスが再起動されます。
* 注意：操作前にクラスタリソースが十分であることを確認してください。リソース不足の場合、変更が反映されないことがあります。

**3. インスタンス管理とスケール**

* **スケール（増減）**：インスタンス一覧で「Pod 数」にホバーし、トラフィック変動に応じて Pod 数を手動で増減できます。
* **インスタンス再起動**：すべての Pod を再起動します。短時間、性能が低下する場合があります。
* **インスタンス再ビルド**：基盤依存パッケージを最新化し、新しいインスタンス環境を構築します。
* **インスタンスをロールバック**：現在の実行状態を過去のインスタンスバージョンへ戻します（注意：現在のインスタンスは失われます）。
* 注意：スケールアウト前にクラスタリソースが十分であることを確認してください。リソース不足の場合、Pod の追加が反映されないことがあります。

**4. 環境変数**
インスタンス単位の環境変数を設定できます。デフォルトではグローバル設定を継承しますが、上書きも可能です。

* 注意：操作前にクラスタリソースが十分であることを確認してください。リソース不足の場合、変更が反映されないことがあります。

### 2.4 プラグインのアンインストール

アンインストールは「ワークスペースからのアンインストール」と「グローバルアンインストール」に分かれます。

**安全なアンインストールチェック**：
誤操作による業務停止を防ぐため、アンインストール時に依存関係チェックを行います。

* **ツール／Agent 戦略／トリガー系**：当該プラグインを利用している「アプリ」と「ナレッジパイプライン」の一覧を表示します。
* **モデル／データソース／拡張系**：当該プラグインを利用している「ワークスペース」の一覧を表示します。

管理者は【一覧をエクスポート】をクリックして影響範囲をバックアップし、問題がないことを確認してからアンインストールを実行してください。

### 2.5 プラグインのインストールポリシー

管理者はポリシーにより、企業のプラグインセキュリティ境界（許容範囲）を制御できます。

アクセスパス：プラグイン管理ページ上部 > 【プラグインインストールポリシー】

* **許可するインストール元**：「すべて」「公式とパートナー」「公式のみ」「なし（すべて禁止）」から選択できます。
* **マーケットからのインストールに限定**：有効にすると、ローカルアップロードによるインストールを禁止し、悪意あるコード注入を防ぎます。
* [詳細は「プラグインインストールポリシー」を参照](/versions/3-0-x/zh-cn/administrator-guide/plugins-management)

## 3. トラブルシューティング

* **インストール失敗**：一覧上部の【インストールログ】アイコンをクリックして、詳細なエラーログを確認します。よくある原因は、ネットワークタイムアウト、チェックサム不一致、依存関係の競合です。
* **インスタンスが Building のまま**：再ビルドや新規作成時の中間状態です。長時間 Running に遷移しない場合は、K8s クラスタリソースが十分か確認してください。
* **監視データが表示されない**：デプロイ環境が K8s であることを確認してください。Docker Compose モードでは Pod メトリクス表示はサポートされません。
* **ロールバックできない**：現在稼働中のものが対象インスタンスと同一の場合、ロールバックボタンは無効になります。
* **追加した Pod が起動しない**：クラスタリソース不足の可能性があります。K8s のリソース状況を確認し、クラスタの増強または他プラグインの削除を検討してください。
* **環境変数の更新に失敗する**：クラスタリソース不足の可能性があります。K8s のリソース状況を確認し、クラスタの増強または他プラグインの削除を検討してください。
* **リソース設定の更新に失敗する**：クラスタリソース不足の可能性があります。K8s のリソース状況を確認し、クラスタの増強または他プラグインの削除を検討してください。

## 4. よくある質問（FAQ）

### Docker Compose 環境と K8s 環境では機能にどんな違いがありますか？

K8s 環境では、インスタンスのリソース監視（CPU／メモリ）、Pod のスケール、ローリング更新、上級運用機能を含むフル機能を利用できます。Docker Compose 環境では、【インスタンスを表示】、【リソース設定】、Pod 関連の監視機能は利用できず、基本的なインストール／アンインストール／バージョン管理のみが利用可能です。

### プラグインをアンインストールすると、アプリはどうなりますか？

管理者が、アプリが依存しているプラグインを強制的にアンインストールすると、そのアプリは実行時に “The plugin is not installed and cannot be used!” というエラーになり、業務が中断する可能性があります。アンインストール前に、必ずダイアログで影響範囲を確認してください。

### 「インスタンスのグローバル環境変数」とは何ですか？

管理コンソール上部で設定する変数です。新しく起動するプラグインインスタンスは、デフォルトでこれらのグローバル変数を継承します。個別プラグインでは【インスタンスを表示】>【環境変数】から上書き設定が可能です。

### 一部プラグインの更新が表示されないのはなぜですか？

【プラグインインストールポリシー】を確認してください。ポリシーが「公式のみ」を許可している場合、非公式チャネルの更新は表示またはインストールできないことがあります。また、Marketplace への接続が正常であることも確認してください。

## 5. ベストプラクティス

* **本番環境ではインストール元を厳格に制限**：本番ではポリシーを「公式のみ」に設定し、「マーケットからのインストールに限定」を有効化して、セキュリティリスクを最小化してください。
* **リソースの予約と監視**：重要な LLM モデルプラグインは、リリース前に負荷テストを行い、監視グラフを基に Min/Max Pod 数とリソース上限（limit）を適切に設定して、ピーク時の応答遅延を防いでください。
* **スムーズなアップグレード**：プラグインのバージョンを更新する際は、まずテスト用ワークスペースで「カナリア（段階）リリース」（そのワークスペースだけに新バージョンを導入）を行い、互換性を確認した上で【インストール管理】から全社へ一括展開してください。
* **失敗履歴の定期クリーンアップ**：インストールログから失敗した過去の記録を定期的に削除し、運用ビューを整理してください。