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 クイックスタート
プラグイン管理の典型的な運用フローは次のとおりです：プラグインを導入（マーケット／ローカル） > ワークスペースへ割り当て（インストール） > 監視・運用 > アンインストール／回収- 新しいプラグインを導入
「プラグイン管理」ページで【プラグインをインストール】をクリックし、マーケットからダウンロードするか、ローカルのパッケージをアップロードしてプラグインを登録します。 - ワークスペースへ割り当て
プラグイン一覧で【インストール管理】をクリックし、［インストール先を追加］で対象ワークスペースを選択します。システムが対象ワークスペースへ自動的にデプロイし、「入れてすぐ使える」状態になります。 - 稼働状況を監視（K8s のみ）
プラグイン右側の【···】>【インスタンスを表示】で負荷監視グラフを確認します。性能ボトルネックがある場合は、【リソース設定】で CPU／メモリ上限や Pod 数を増やしてください。
2.1 プラグインのインストール
システムは 2 つのインストール方法をサポートします。利用できる方法は、デプロイ環境とセキュリティポリシーに依存します。 方法 1：Marketplace からインストール（推奨）- 【プラグインをインストール】>【Marketplace】をクリックします。
- ポップアップまたは新しいタブでマーケットを閲覧します。
- プラグインと必要なバージョンを選択します。
- 【インストール】をクリックします。システムが自動で取得し、バックグラウンドでベースインスタンスをデプロイします。
- 【プラグインをインストール】>【ローカルプラグイン】をクリックします。
- プラグインパッケージファイルをアップロードします。
- システムが署名とポリシーを検証します。要件を満たさない場合、設定に応じて警告が表示されます（ポリシーの強制はワークスペース側で有効になり、管理コンソールは警告表示のみでインストール自体はブロックしません）。
2.2 インストール管理（割り当て・バージョン管理）
管理者は、各ワークスペースへの配布状況と利用バージョンを制御できます。- プラグイン一覧で対象プラグインを見つけ、【インストール管理】をクリックします。
- このバージョンをより多くのワークスペースへ導入：［インストール先を追加］をクリックし、一覧からワークスペースにチェックを入れます。
- このバージョンをワークスペースから削除：一覧で対象ワークスペースを選んでアンインストールアイコンをクリックするか、［インストール先を追加］で該当ワークスペースのチェックを外します。
- バージョン変更の表示：システムは色で変更内容を示します。
- グレー（インストール済み）：すでにインストール済みです。
- グリーン（新規）：初回インストールです。
- ブルー（アップグレード）：低いバージョンから現行バージョンへ更新（例：1.0.0 -> 1.2.0）。
- オレンジ（ダウングレード）：高いバージョンから現行バージョンへ戻す（例：1.3.0 -> 1.2.0）。
- 水色（上書き）：同一バージョンの上書き（プラグインのバージョン checksum を表示。例：1.2.0 SHA-256: 3db71aca）。
- ダイアログ下部に、今回の変更内容のプレビュー（新規、アップグレード、ダウングレード、上書きインストール、アンインストール）が表示されます。【確認】をクリックすると即時反映されます。
2.3 プラグインの実行監視と設定（K8s のみ）
K8s デプロイ環境では、管理者は高度な運用機能を利用できます。Docker Compose 環境では現時点で本セクションはサポートされません。 プラグイン一覧で【…】>【インスタンスを表示】をクリックして詳細ページへ移動します。 1. 負荷監視 直近 1 時間／1 日／1 週間の Pod／コンテナ実行データを可視化します。- CPU 使用状況
- メモリ使用状況
- ネットワークのアップロード／ダウンロードレート
- 注意：クイック操作で、異なる Pod における同種コンテナを比較できます。グラフにはリソース制限線（Limit）が表示されます。
- CPU コア数：1 コア未満の値も設定可能です。
- メモリ容量：最大メモリ上限を設定します。
- 変更後は【保存して適用】をクリックしてください。反映のためインスタンスが再起動されます。
- 注意：操作前にクラスタリソースが十分であることを確認してください。リソース不足の場合、変更が反映されないことがあります。
- スケール（増減）：インスタンス一覧で「Pod 数」にホバーし、トラフィック変動に応じて Pod 数を手動で増減できます。
- インスタンス再起動：すべての Pod を再起動します。短時間、性能が低下する場合があります。
- インスタンス再ビルド：基盤依存パッケージを最新化し、新しいインスタンス環境を構築します。
- インスタンスをロールバック：現在の実行状態を過去のインスタンスバージョンへ戻します（注意：現在のインスタンスは失われます）。
- 注意：スケールアウト前にクラスタリソースが十分であることを確認してください。リソース不足の場合、Pod の追加が反映されないことがあります。
- 注意：操作前にクラスタリソースが十分であることを確認してください。リソース不足の場合、変更が反映されないことがあります。
2.4 プラグインのアンインストール
アンインストールは「ワークスペースからのアンインストール」と「グローバルアンインストール」に分かれます。 安全なアンインストールチェック： 誤操作による業務停止を防ぐため、アンインストール時に依存関係チェックを行います。- ツール／Agent 戦略／トリガー系：当該プラグインを利用している「アプリ」と「ナレッジパイプライン」の一覧を表示します。
- モデル／データソース／拡張系：当該プラグインを利用している「ワークスペース」の一覧を表示します。
2.5 プラグインのインストールポリシー
管理者はポリシーにより、企業のプラグインセキュリティ境界（許容範囲）を制御できます。 アクセスパス：プラグイン管理ページ上部 > 【プラグインインストールポリシー】- 許可するインストール元：「すべて」「公式とパートナー」「公式のみ」「なし（すべて禁止）」から選択できます。
- マーケットからのインストールに限定：有効にすると、ローカルアップロードによるインストールを禁止し、悪意あるコード注入を防ぎます。
- 詳細は「プラグインインストールポリシー」を参照
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）を適切に設定して、ピーク時の応答遅延を防いでください。
- スムーズなアップグレード：プラグインのバージョンを更新する際は、まずテスト用ワークスペースで「カナリア（段階）リリース」（そのワークスペースだけに新バージョンを導入）を行い、互換性を確認した上で【インストール管理】から全社へ一括展開してください。
- 失敗履歴の定期クリーンアップ：インストールログから失敗した過去の記録を定期的に削除し、運用ビューを整理してください。