メインコンテンツへスキップ

​
Copilot vs Hub

アーキテクチャは2つの統合スケールをサポートしています： Copilot はホストシステムのUIに組み込まれます。ユーザーは使い慣れたインターフェースを離れることなくAIと対話できます。複数のコネクタ（ホストDB + 通知サービスなど）を使用できます。 Hub はすべてのシステムを接続するスタンドアロンポータルです。単一のシステムに組み込まれるのではなく、システムとAIが出会う中央インテリジェンスレイヤーです。 同じコネクタアーキテクチャ、異なるデリバリー方法です。Copilotはハブと同じ ConnectorToolAdapter を使用します。

​
コア原則

クライアントはコードを変更しません。 FIM One はクライアントのシステムにプロアクティブに統合されます。データベースを読み取り、API を呼び出し、メッセージバスにプッシュします。クライアントが提供するのは認証情報とネットワークアクセスのみです。

​
3層アーキテクチャ

各レイヤーは異なる責任を持ちます：
レイヤー担当変更のタイミング…
プラットフォームオーケストレーション、マルチテナント、UI新しいプラットフォーム機能がリリースされたとき
コネクタガバナンスレイヤーエンタープライズガバナンスポリシーセキュリティ/コンプライアンス要件が変わったとき
MCP Protocolトランスポート、ツールインターフェース標準なし（オープン標準）
レガシーシステムビジネスデータとロジックなし（それが目的）

​
なぜ MCP をトランスポート層として使用するのか

アダプターは MCP サーバー として実装されています。これは意図的なアーキテクチャ上の選択です：
  • 再利用性: FIM One には既に MCP クライアント (v0.3) が付属しています。レガシーシステムアダプターを追加することは、任意の MCP ツールを追加するのと同じインフラストラクチャを再利用します。
  • 標準プロトコル: MCP はオープンスタンダードです。独自プロトコルを発明または保守する必要がありません。
  • エコシステム: サードパーティの MCP サーバー（データベース、API、SaaS ツール）がそのまま動作します。
  • プロセス分離: 各 MCP サーバーは別々のプロセスとして実行されます。不具合のあるアダプターがプラットフォームをクラッシュさせることはできません。

​
MCP だけでは提供されないもの

Connector Governance Layer は、生の MCP に欠けているエンタープライズガバナンスを追加します:
懸念事項MCPConnector Governance Layer
読み取り専用の強制いいえ操作の read_only フラグ; デフォルトで書き込みをブロック
監査ログいいえすべてのツール呼び出しを記録 (タイムスタンプ、ユーザー、ツール、パラメータ、結果)
認証パススルーいいえホストシステム認証をプロキシ; エージェントはログイン済みユーザーの代わりに動作
確認ゲートいいえ書き込み操作は人間の承認が必要 (SSE confirmation_required)
サーキットブレーカーいいえ接続障害がグレースフルデグラデーションをトリガー
操作分類いいえ操作にレベルごとのポリシーを持つ読み取り/書き込み/管理者としてタグ付け

​
カスタムプロトコルを発明しない理由

プロトコルは汎用品です。技術的価値はアダプタ自体（ドメイン知識、スキーママッピング、エッジケース処理）とガバナンスレイヤー（監査、認証、安全性）にあります。トランスポートプロトコルを発明すると、機能を追加することなくメンテナンスコストが増加します。Stripeはhttpsを使用し、DockerはcgroupsとMCPを使用しています。

​
デプロイメントモデル

すべてが単一の Docker Compose デプロイメント内で実行されます。クライアントは何もインストールする必要がありません。
すべて FIM One により提供されます。クライアントが提供するのは以下のみです:
  • データベース認証情報（読み取り専用アカウントを推奨）
  • API エンドポイントとキー（利用可能な場合）
  • ネットワークホワイトリストアクセス
アクセス階層: FIM One はクライアントが提供できるアクセスに適応します:
クライアントが持つものFIM One の接続方法
ドキュメント付き APIHTTP API アダプター（最適な場合）
ドキュメントなし APIHTTP API アダプター + 手動スキーママッピング
データベースアクセスのみデータベースアダプター（直接 SQL、デフォルトで読み取り専用）
データベース + メッセージバスデータベースアダプター + メッセージプッシュアダプター

​
エージェント-コネクタの分離

エージェントはコネクタを通常のツールとして見ます。ツールが組み込みツール、サードパーティのMCP Server、またはレガシーシステムコネクタであるかどうかを知ったり気にしたりしません。 これは以下を意味します:
  • 新しいシステムを追加 = コネクタ設定を追加。エージェントコードは変わりません。
  • コネクタを削除 = 設定を削除。コード変更なし。
  • 同じエージェントが単一のタスク内で組み込みツールとコネクタを使用できます。

​
ホットプラグ進化

バージョン新しいコネクタの追加方法再起動が必要?
v0.6Connector Governance Layer を備えた Python MCP Server を作成し、docker-compose に追加再デプロイ
v0.8YAML/JSON 設定を作成し、プラットフォームが MCP Server を生成再起動
v1.0OpenAPI 仕様をアップロード、AI が設定を自動生成再起動不要（ホットプラグ）
エンタープライズデプロイメントは「一度実装したら数ヶ月間実行」という性質があります。ホットプラグは v1.0 の利便性であり、v0.6 の要件ではありません。

​
データフロー例

ユーザー: 「財務システムから期限切れの契約をすべて確認し、Larkに概要を送信してください。」 
1. User sends message via Portal / API

2. FIM One (ReAct mode):
   Think: I need to query the finance DB for overdue contracts, then push to Lark.

3. Act: contract_query(status="overdue", days_past_due=">30")
   → Connector Governance: audit log, read_only check (pass)
   → MCP Server: translates to SQL
   → Client DB: SELECT * FROM contracts WHERE status='overdue' AND ...
   ← Returns 7 overdue contracts

4. Think: Found 7 overdue contracts. I'll summarize and push.

5. Act: lark_push(message="7 overdue contracts found: ...")
   → Connector Governance: audit log, write operation → confirmation gate
   → User approves via Portal
   → MCP Server: POST to Lark webhook
   ← Push successful

6. Answer: "Found 7 overdue contracts. Summary pushed to Lark group."

​
コネクタ標準化レベル

レベルバージョンアプローチ構築者
レベル 1v0.6Python MCP Server with Connector GovernanceFIM One 開発者
レベル 2v0.8YAML/JSON config、プラットフォームが MCP Server を自動生成実装エンジニア (Python 不要)
レベル 3v1.0OpenAPI/Swagger スペックをアップロード、AI が設定を生成AI (人間によるレビュー付き)

​
既存のMCPエコシステムとの関係

FIM One の MCP クライアント（v0.3 で提供）は、すでにサードパーティの MCP サーバーをサポートしています。レガシーシステムアダプターは、Connector Governance Layer で構築されたドメイン固有の MCP サーバーであり、エンタープライズガバナンスのために設計されています。 Connector Governance Layer は MCP に置き換わるものではなく、エンタープライズレガシーシステム統合に必要なガバナンスレイヤーで MCP を拡張するものです。