Skip to main content

概要

Market は FIM One のリソースマーケットプレイスです。ユーザーが構築したリソースを公開し、他のユーザーがそれらを発見して購読し、購読したリソースは購読者のワークスペースに自分のものであるかのように表示されます。システム全体は、単一のアーキテクチャ上の洞察に基づいて構築されています:Market は組織である — システムが管理するシャドウ組織で、特別な信頼ルールを持ちます。 このページでは、Market の内部アーキテクチャについて説明します。公開と購読のユーザー向け概要については、Market (Features) を参照してください。購読したリソースがツールセットに読み込まれる方法については、エージェント & リソース発見 を参照してください。

2段階分類

マーケットプレイスは、リソースがどのように実装されているかではなく、リソースが何をするかに基づいて、リソースを2つのカテゴリに整理しています。

ソリューション

ソリューションはあなたのために機能するものです。ユーザーはソリューションを購読し、すぐに使用できる機能を取得します。 ソリューションは他のリソースに依存する場合があります。エージェントは API 呼び出し用の特定のコネクタと取得パイプライン用のナレッジベースが必要な場合があります。マーケットプレイスは購読時にこれらの依存関係を自動的に処理します (依存関係の解決を参照)。

コンポーネント

コンポーネントは開発者向けの再利用可能なビルディングブロックです。ソリューションが消費する機能を提供します。 コンポーネントはサブスクライブが簡単です。内部依存関係がなく、認証情報の要件のみがあります。

Knowledge Basesが独立してリストされない理由

Knowledge Basesは共有できません——Marketでも、organizationでも。KBは、共有されたAgentの内部依存関係としてのみ他のユーザーに到達します。実行時にAgentが所有者のコンテンツを委譲するため、購読者はKB購読を保有せず、KBを個別に検索、評価、または管理する必要がありません。
2層分類(SolutionsとComponents)は表示層の概念です。クエリ時にresource_typeから派生し、別のフィールドとして保存されません。基盤となる購読メカニズム、可視性フィルター、およびレビュープロセスは、すべてのリソースタイプで同じです。

統一されたアーキテクチャ

マーケットプレイスをシャドウ組織として

マーケットプレイスの最も重要なアーキテクチャ上の決定は、それが独立したサブシステムではないということです。それは組織です — システム管理の組織で、固定ID(MARKET_ORG_ID)を持ち、プラットフォーム初期化時に自動的に作成されます。 これは以下を意味します:
  • 同じ可視性フィルターbuild_visibility_filter())が、個人、組織、およびマーケットプレイスのリソースを単一クエリで処理します。マーケットプレイス検索用の特殊なコードはありません。
  • 同じサブスクリプション機構ResourceSubscription)が、組織とマーケットプレイスの両方のリソースに適用されます。組織リソースへのサブスクリプションとマーケットプレイスリソースへのサブスクリプションは、同じレコードを作成します。
  • 同じ認証情報処理(フォールバック、ユーザーごとのオーバーライド)が両方のコンテキストで機能します。コネクターとMCP サーバーのallow_fallbackフラグは、ソースに関わらず同じように動作します。
  • 同じレビュープロセスapply_publish_status())が、組織レベルとマーケットプレイスレベルの両方を処理します。唯一の違いは、マーケットプレイス組織がすべてのレビューフラグをtrueにロックしていることです。
通常の組織とマーケットプレイス組織の主な違い:
マーケットプレイスは特別なルールを持つ単なる組織であるため、組織向けに構築されたすべての機能 — レビューワークフロー、認証情報管理、リソースライフサイクル — は、追加の実装なしで自動的にマーケットプレイスで機能します。

可視性フィルターの処理方法

Market orgにはメンバーシップを持つユーザーがいません。ユーザーは Market に「参加」するのではなく、個別のリソースをサブスクライブします。つまり、MARKET_ORG_ID はユーザーの user_org_ids リストに存在することはなく、org メンバーシップの可視性条件は Market リソースに対して自然にスキップされます。 代わりに、サブスクライブされた Market リソースは build_visibility_filter()subscribed_ids パスを通ります: この 3 つの条件の OR 句が可視性モデル全体です。個人用リソース、org 共有リソース、Market サブスクライブリソースは 1 つのクエリで解決され、リソースの出所に応じた分岐ロジックはありません。

スコープベースのブラウジング

Market ページは、2 つのブラウジング コンテキスト間を切り替えるスコープ セレクターを提供します: 同じ UI、同じタブ (Solutions / Components)、同じサブスクリプション フローが両方のスコープに適用されます。スコープを切り替えると、ブラウズ クエリの org_id フィルターのみが変わります。ユーザーの観点からは、エクスペリエンスは同じです。つまり、カタログをブラウジングして、インストールするものを選択しています。

サブスクリプションフロー

ブラウジングと検出

ユーザーはページネーション付きカタログを通じてマーケットをブラウジングします。各リソースには、名前、説明、アイコン、パブリッシャーのユーザー名、および購読ボタンが表示されます。ユーザーが既に購読しているリソースは、それに応じてマークされます。ブラウズAPI(GET /api/market)はユーザー自身のリソースを除外します。公開したものは購読できません。

ソリューションへのサブスクリプション

ソリューション(Agent、Skill、または Workflow)へのサブスクリプションには、依存関係の分析が含まれます:
  1. システムはソリューションの依存関係を分析します——どの Connector、Knowledge Base、MCP Server、および Skill が必要かを確認します。
  2. コンテンツタイプの依存関係はユーザーに確認することなく処理されます。Skill は自動的にサイレントでサブスクライブされます。Knowledge Base は決してサブスクライブされません——Agent は実行時に所有者の KB を委譲するため、サブスクライバーはプロビジョニングする必要がありません。
  3. 接続タイプの依存関係(Connector、MCP Server)は要件として一覧表示されます。オンボーディングウィザードが認証情報を収集します。
  4. ResourceSubscription レコードが作成され、リソースはユーザーの表示フィルターに表示されます。

コンポーネントへのサブスクライブ

コンポーネント(コネクタと MCP サーバー)はより単純なフローを持っています — 依存関係分析は不要です。ユーザーがサブスクライブし、必要に応じて認証情報を設定すると、コンポーネントは使用可能になります。

認証情報の設定

認証情報はハイブリッドモデルに従い、利便性と柔軟性のバランスを取ります:
  • サブスクリプション時に提供。 接続タイプの依存関係が認証情報を必要とする場合、オンボーディングウィザードは認証情報フォームをすぐに表示します。
  • スキップ可能。 ユーザーは「スキップして後で設定」を選択できます。リソースはサブスクライブされますが、これらの認証情報が必要なツールは呼び出し時に「認証情報を設定してください」というメッセージを返します。
  • 遅延設定。 ユーザーは設定ページからいつでも認証情報を設定または更新できます。
これは組織で使用されるのと同じallow_fallbackメカニズムです。パブリッシャーがフォールバックを有効にしてデフォルト認証情報を設定している場合、サブスクライバーは独自のキーを提供することなくリソースをすぐに使用できます。フォールバックが無効な場合、各サブスクライバーは独自のものを用意する必要があります。
認証情報フォールバックが有効になっているMarketリソースを使用する場合、APIリクエストはパブリッシャーの認証情報を通じて流れます。機密性の高い操作の場合は、独自の認証情報を提供するか、パブリッシャーの信頼性を確認することを検討してください。

購読解除

購読解除により、ResourceSubscription レコードが削除されます。リソースはユーザーの可視性フィルターから消え、ツールセットに読み込まれなくなります。自動購読依存関係を持つソリューションの場合、依存リソース(KB、スキル)もクリーンアップされます。リソースのユーザー設定認証情報が削除されます。

依存関係の解決

ソリューションが公開または購読されると、システムはその依存関係ツリーを分析します。依存関係は2つのカテゴリに分かれており、異なる処理戦略があります。

コンテンツタイプの依存関係

ナレッジベーススキルは、ソリューションによって参照されるコンテンツタイプの依存関係です。これらは読み取り専用データ——検索ドキュメント、SOP手順——をソリューションが消費します。
  • スキル——サブスクリプション時: 自動的にサイレントサブスクライブされます。ユーザーは個別のサブスクリプションステップを表示されません。
  • ナレッジベース: サブスクライブされません。バインドされたKBは実行時に所有エージェントによって委譲されるため(所有者委譲)、サブスクライバー側でプロビジョニングやクリーンアップを行う必要はありません。
  • アクセスモデル: 元の作成者のリソースへの読み取り専用参照。サブスクライバーはコンテンツを変更できません。
  • サブスクリプション解除時: 親ソリューションがサブスクリプション解除されると、自動サブスクライブされた依存関係は自動的にクリーンアップされます。

接続タイプの依存関係

コネクタMCPサーバーがソリューションによって参照される場合、それらは接続タイプの依存関係です。機能するには認証情報が必要です。
  • サブスクリプション時: オンボーディングウィザードで要件として表示されます。ユーザーは認証情報を設定するか、スキップするかを求められます。
  • スマートマッチング: ユーザーが互換性のあるコネクタ(同じタイプ、同じベースURL)を既に持っている場合、システムは新しいサブスクリプションを作成する代わりに、それを再利用することを提案します。
  • サブスクリプション解除時: サブスクリプションは削除されますが、ユーザーが作成した認証情報は保持されます(ユーザーは同じコネクタを他の場所で使用できます)。

公開

ソリューションの公開

著者がエージェント、スキル、またはワークフローをマーケットプレイスに公開する場合:
  1. システムはリソースに visibility: "org"org_id: MARKET_ORG_ID を設定します。
  2. システムはソリューションの依存関係を分析し、マニフェストを構築します — 必要なコネクタ、KB、および MCP サーバーをリストアップします。
  3. マニフェストが著者に確認のため表示されます。
  4. apply_publish_status() はリソースを pending_review に設定します (マーケットプレイス組織のすべてのレビューフラグは true にロックされています)。
  5. システム管理者がリソースをレビューして承認または却下します。

コンポーネントの公開

Connectorまたはサーバーの公開はより簡単です:
  1. システムが上記のように可視性とorg_idを設定します。
  2. 認証情報スキーマが抽出されます(サブスクライバーが入力する必要があるフィールド)。
  3. リソースがpending_reviewに入り、管理者の承認を待ちます。

レビュープロセス

レビュープロセスは、組織で使用されるのと同じメカニズムですが、1つの重要な違いがあります: Market組織は6つのレビューフラグすべてがtrueに設定された状態で初期化され、この設定は変更できません。Marketに公開されるすべてのリソースは、ブラウズカタログに表示される前に管理者レビューに合格する必要があります。
組織の所有者は自動的にレビューをバイパスします — 公開されたリソースはすぐに利用可能になります。Marketの場合、Market組織の所有者(システム管理者)のみがこのバイパス特権を持ちます。
承認されたリソースが著者によって編集されると、check_edit_revert()は自動的にpublish_statuspending_reviewに戻します。これにより、ライブMarketリソースへの変更がサブスクライバーに表示される前に再度レビューされることが保証されます。

実装に関する注記

シャドウ組織

Market組織は、よく知られた固定ID(00000000-0000-0000-0000-000000000001)とスラッグ(market)を持っています。プラットフォーム初期化中にensure_market_org()によって作成されます — 通常は最初の管理者ユーザーのログイン時です。この関数はべき等です。複数回呼び出しても安全です。

ResourceSubscription

ResourceSubscriptionテーブルはMarket アクセスのコアデータ構造です: (user_id, resource_type, resource_id)に対するユニーク制約により、重複したサブスクリプションを防ぎます。org_idカラムはサブスクリプションの出所を追跡し、スコープ対応のアンサブスクリプションを可能にします。

可視性フィルター統合

resolve_visibility() 関数は単一の呼び出しで 2 つのルックアップを実行します:
  1. ユーザーの組織メンバーシップを取得 (user_org_ids)
  2. ユーザーのサブスクリプションを取得 (subscribed_ids)
これらは build_visibility_filter() に渡され、3 つすべての可視性レベル (自分のもの、組織共有、サブスクリプション) を組み合わせた単一の SQL WHERE 句を生成します。この関数はリソースがクエリされるあらゆる場所で使用されます — エージェントリスト、コネクターのドロップダウン、スキルインジェクション、自動検出モード — プラットフォーム全体で一貫した可視性を確保します。

認証情報の暗号化

サブスクリプション中(またはその後の設定で)に設定された認証情報は、プラットフォームの暗号化キーを使用して保存時に暗号化されます。Market API は参照レスポンスで認証情報の値を公開することはありません — _*_market_info() ヘルパー関数ではメタデータ(名前、説明、アイコン、タイプ)のみが返されます。

関連項目