Copilot vs Hub
アーキテクチャは2つの統合スケールをサポートしています: Copilot はホストシステムのUIに組み込まれます。ユーザーは使い慣れたインターフェースを離れることなくAIと対話できます。複数のコネクタ(ホストDB + 通知サービスなど)を使用できます。 Hub はすべてのシステムを接続するスタンドアロンポータルです。単一のシステムに組み込まれるのではなく、システムとAIが出会う中央インテリジェンスレイヤーです。 同じコネクタアーキテクチャ、異なるデリバリー方法です。Copilotはハブと同じConnectorToolAdapter を使用します。
コア原則
クライアントはコードを変更しません。 FIM One はクライアントのシステムにプロアクティブに統合されます。データベースを読み取り、API を呼び出し、メッセージバスにプッシュします。クライアントが提供するのは認証情報とネットワークアクセスのみです。3層アーキテクチャ
各レイヤーは異なる責任を持ちます:なぜ MCP をトランスポート層として使用するのか
アダプターは MCP サーバー として実装されています。これは意図的なアーキテクチャ上の選択です:- 再利用性: FIM One には既に MCP クライアント (v0.3) が付属しています。レガシーシステムアダプターを追加することは、任意の MCP ツールを追加するのと同じインフラストラクチャを再利用します。
- 標準プロトコル: MCP はオープンスタンダードです。独自プロトコルを発明または保守する必要がありません。
- エコシステム: サードパーティの MCP サーバー(データベース、API、SaaS ツール)がそのまま動作します。
- プロセス分離: 各 MCP サーバーは別々のプロセスとして実行されます。不具合のあるアダプターがプラットフォームをクラッシュさせることはできません。
MCP だけでは提供されないもの
Connector Governance Layer は、生の MCP に欠けているエンタープライズガバナンスを追加します:カスタムプロトコルを発明しない理由
プロトコルは汎用品です。技術的価値はアダプタ自体(ドメイン知識、スキーママッピング、エッジケース処理)とガバナンスレイヤー(監査、認証、安全性)にあります。トランスポートプロトコルを発明すると、機能を追加することなくメンテナンスコストが増加します。Stripeはhttpsを使用し、DockerはcgroupsとMCPを使用しています。デプロイメントモデル
すべてが単一の Docker Compose デプロイメント内で実行されます。クライアントは何もインストールする必要がありません。すべて FIM One により提供されます。クライアントが提供するのは以下のみです:
- データベース認証情報(読み取り専用アカウントを推奨)
- API エンドポイントとキー(利用可能な場合)
- ネットワークホワイトリストアクセス
エージェント-コネクタの分離
エージェントはコネクタを通常のツールとして見ます。ツールが組み込みツール、サードパーティのMCP Server、またはレガシーシステムコネクタであるかどうかを知ったり気にしたりしません。 これは以下を意味します:- 新しいシステムを追加 = コネクタ設定を追加。エージェントコードは変わりません。
- コネクタを削除 = 設定を削除。コード変更なし。
- 同じエージェントが単一のタスク内で組み込みツールとコネクタを使用できます。
ホットプラグ進化
エンタープライズデプロイメントは「一度実装したら数ヶ月間実行」という性質があります。ホットプラグは v1.0 の利便性であり、v0.6 の要件ではありません。