Market は FIM One のリソースマーケットプレイスです。ユーザーが構築したリソースを公開し、他のユーザーがそれらを発見して購読し、購読したリソースは購読者のワークスペースに自分のものであるかのように表示されます。システム全体は、単一のアーキテクチャ上の洞察に基づいて構築されています：Market は組織である — システムが管理するシャドウ組織で、特別な信頼ルールを持っています。
このページでは、Market の内部アーキテクチャについて説明します。公開と購読のユーザー向け概要については、Market (機能) を参照してください。購読したリソースがツールセットに読み込まれる方法については、エージェント & リソース検出 を参照してください。
2段階分類
マーケットプレイスはリソースの実装方法ではなく、リソースが何をするかに基づいて、リソースを2つのカテゴリに整理しています。
ソリューション
ソリューションはあなたのために機能するものです。ユーザーがソリューションにサブスクライブすると、すぐに使用できる機能が得られます。
| リソースタイプ | 機能 |
|---|
| エージェント | バインドされたツール、ナレッジ、および指示を備えた会話型AI アシスタント |
| スキル | call_agent を介して複数のエージェントをオーケストレーションできるグローバル SOP (標準作業手順) |
| ワークフロー | ビジュアル編集と決定論的実行を備えた DAG ベースの自動化フロー |
コンポーネント
コンポーネントは開発者向けの再利用可能な構成要素です。ソリューションが利用する機能を提供します。
| リソースタイプ | 機能 |
|---|
| コネクタ | API またはデータベース統合アダプタの定義 |
| MCP Server | Model Context Protocol を使用したツールサービス設定 |
ナレッジベースが独立してリストされない理由
ナレッジベースはスタンドアロンのマーケットリソースとして公開されていません。これらはソリューション内の内部依存関係です。エージェントの検索パイプラインまたはスキルの参照資料として機能します。ユーザーがナレッジベースに依存するソリューションにサブスクライブすると、KBは読み取り専用参照として自動的に含まれます。サブスクライバーがナレッジベースを個別に検索、評価、または管理する必要はありません。
2段階の分類（ソリューション対コンポーネント）は表示層の概念です。これはクエリ時にresource_typeから派生し、別のフィールドとして保存されません。基盤となるサブスクリプションメカニズム、可視性フィルター、およびレビュープロセスはすべてのリソースタイプで同じです。
統一されたアーキテクチャ
マーケットプレイスをシャドウ組織として
マーケットプレイスの最も重要なアーキテクチャ上の決定は、それが独立したサブシステムではないということです。これは組織です — システム管理の組織で、固定ID（MARKET_ORG_ID）を持ち、プラットフォーム初期化時に自動的に作成されます。
これは以下を意味します：
- 同じ可視性フィルター（
build_visibility_filter()）が、個人、組織、マーケットプレイスのリソースを単一クエリで処理します。マーケットプレイス検索用の特殊なコードはありません。
- 同じサブスクリプション機構（
ResourceSubscription）が、組織リソースとマーケットプレイスリソースの両方に適用されます。組織リソースへのサブスクリプションとマーケットプレイスリソースへのサブスクリプションは、同じレコードを作成します。
- 同じ認証情報処理（フォールバック、ユーザーごとのオーバーライド）が両方のコンテキストで機能します。コネクターとMCP Serverの
allow_fallbackフラグは、ソースに関係なく同じように動作します。
- 同じレビュープロセス（
apply_publish_status()）が、組織レベルとマーケットプレイスレベルの両方を処理します。唯一の違いは、マーケットプレイス組織がすべてのレビューフラグをtrueにロックしていることです。
通常の組織とマーケットプレイス組織の主な違い：
| 側面 | 組織 | マーケットプレイス |
|---|
| 信頼モデル | 高信頼（チームメンバーシップ） | 信頼を前提としない（グローバルコミュニティ） |
| レビュー | リソースタイプごとにオプション | すべてのタイプで常に必須 |
| アクセス | すべてのメンバーに自動 | 明示的なサブスクリプションが必要 |
| スコープ | チームまたは企業 | グローバル |
マーケットプレイスは特別なルールを持つ組織に過ぎないため、組織用に構築されたすべての機能 — レビューワークフロー、認証情報管理、リソースライフサイクル — は追加実装なしで自動的にマーケットプレイスで機能します。
可視性フィルターの処理方法
誰もMarket組織のメンバーシップを保有していません。ユーザーはMarketに「参加」するのではなく、個別のリソースをサブスクライブします。つまり、MARKET_ORG_IDはユーザーのuser_org_idsリストに存在することはなく、Market リソースの組織メンバーシップ可視性条件は自然にスキップされます。
代わりに、サブスクライブされたMarketリソースはbuild_visibility_filter()のsubscribed_idsパスを通ります:
この3つの条件のOR句が可視性モデル全体です。個人用リソース、組織共有リソース、およびMarketサブスクライブリソースは1つのクエリで解決され、リソースの出所に応じた分岐ロジックはありません。
スコープベースのブラウジング
Market ページは、2 つのブラウジング コンテキスト間を切り替えるスコープ セレクターを提供します。
| スコープ | 表示内容 | レビュー担当者 |
|---|
| Global Market | Market org に誰かが公開したリソース | プラットフォーム管理者 |
| Organization: [name] | 特定の org のメンバーが公開したリソース | org 管理者 |
org_id フィルターのみが変更されます。ユーザーの観点からは、エクスペリエンスは同じです。つまり、カタログをブラウジングして、インストールするものを選択しています。
サブスクリプションフロー
ブラウジングと検出
ユーザーはページネーション付きカタログを通じてMarketをブラウジングします。各リソースには、名前、説明、アイコン、パブリッシャーのユーザー名、およびサブスクライブボタンが表示されます。ユーザーが既にサブスクライブしているリソースは相応にマークされます。ブラウズAPI（GET /api/market）はユーザー自身のリソースを除外します — 公開したものにはサブスクライブできません。
ソリューションへのサブスクライブ
ソリューション（エージェント、スキル、またはワークフロー）へのサブスクライブには、依存関係の分析が含まれます：
- システムはソリューションの依存関係を分析します。これには、必要なコネクタ、ナレッジベース、MCP サーバー、およびスキルが含まれます。
- コンテンツタイプの依存関係（KB、スキル）は自動的にサイレントでサブスクライブされます。ユーザーはこれらを表示または管理しません。
- 接続タイプの依存関係（コネクタ、MCP サーバー）は要件として一覧表示されます。オンボーディングウィザードが認証情報を収集します。
ResourceSubscription レコードが作成され、リソースがユーザーの表示フィルターに表示されます。
コンポーネントへのサブスクライブ
コンポーネント（コネクタと MCP サーバー）はより単純なフローを持っています — 依存関係の分析は不要です。ユーザーがサブスクライブし、必要に応じて認証情報を設定すると、コンポーネントは使用可能になります。
認証情報の設定
認証情報は、利便性と柔軟性のバランスを取ったハイブリッドモデルに従います：
- サブスクリプション時に提供。 接続タイプの依存関係が認証情報を必要とする場合、オンボーディングウィザードは認証情報フォームを即座に表示します。
- スキップ可能。 ユーザーは「スキップして後で設定」を選択できます。リソースはサブスクリプションされますが、それらの認証情報を必要とするツールは呼び出し時に「認証情報を設定してください」というメッセージを返します。
- 設定の遅延。 ユーザーは設定ページからいつでも認証情報を設定または更新できます。
これは組織で使用されるのと同じ allow_fallback メカニズムです。パブリッシャーがフォールバックを有効にしてデフォルト認証情報を設定している場合、サブスクライバーは独自のキーを提供することなくリソースをすぐに使用できます。フォールバックが無効な場合、各サブスクライバーは独自のものを用意する必要があります。
認証情報フォールバックが有効になっているMarketリソースを使用する場合、APIリクエストはパブリッシャーの認証情報を通じて流れます。機密性の高い操作の場合は、独自の認証情報を提供するか、パブリッシャーの信頼性を確認することを検討してください。
購読解除
購読解除すると、ResourceSubscriptionレコードが削除されます。リソースはユーザーの可視性フィルターから消え、ツールセットに読み込まれなくなります。自動購読された依存関係を持つソリューションの場合、依存リソース（KB、スキル）もクリーンアップされます。リソースのユーザー設定認証情報は削除されます。
依存関係の解決
ソリューションが公開または購読されるとき、システムはその依存関係ツリーを分析します。依存関係は異なる処理戦略を持つ2つのカテゴリに分類されます。
コンテンツタイプの依存関係
ナレッジベースとスキルがソリューションによって参照されている場合、それらはコンテンツタイプの依存関係です。これらはソリューションが消費する読み取り専用データ（検索ドキュメント、SOP手順など）を提供します。
- サブスクリプション時: 自動的にサイレントにサブスクライブされます。ユーザーは各KBまたはスキルの個別のサブスクリプションステップを表示されません。
- アクセスモデル: 元の作成者のリソースへの読み取り専用参照。サブスクライバーはコンテンツを変更することはできません。
- サブスクリプション解除時: 親ソリューションがサブスクリプション解除されると自動的にクリーンアップされます。
接続タイプの依存関係
コネクタとMCP サーバーはソリューションによって参照される接続タイプの依存関係です。機能するには認証情報が必要です。
- サブスクリプション時: オンボーディング ウィザードで要件として表示されます。ユーザーは認証情報を設定するか、スキップするかを求められます。
- スマート マッチング: ユーザーが互換性のあるコネクタ（同じタイプ、同じベース URL）を既に持っている場合、システムは新しいサブスクリプションを作成する代わりに、それを再利用することを提案します。
- サブスクリプション解除時: サブスクリプションは削除されますが、ユーザーが作成した認証情報は保持されます（ユーザーは同じコネクタを他の場所で使用できます）。
ソリューションの公開
著者がエージェント、スキル、またはワークフローをマーケットプレイスに公開する場合:
- システムはリソースに
visibility: "org" と org_id: MARKET_ORG_ID を設定します。
- システムはソリューションの依存関係を分析し、マニフェストを構築します — 必要なコネクタ、KB、および MCP サーバーをリストアップします。
- マニフェストが著者に確認のため表示されます。
apply_publish_status() はリソースを pending_review に設定します (マーケットプレイス組織のすべてのレビューフラグは true にロックされています)。- システム管理者がリソースをレビューして承認または却下します。
コンポーネントの公開
Connectorまたはサーバーの公開はより簡単です：
- システムが上記のように可視性とorg_idを設定します。
- 認証情報スキーマが抽出されます（サブスクライバーが入力する必要があるフィールド）。
- リソースが
pending_reviewに入り、管理者の承認を待ちます。
レビュープロセス
レビュープロセスは組織で使用されるのと同じメカニズムですが、1つの重要な違いがあります:
| コンテキスト | レビュー必須? | レビュー担当者 |
|---|
| Organization | リソースタイプごとに設定可能 (review_agents, review_connectors など) | 組織管理者 |
| Market | すべてのリソースタイプで常に必須 | プラットフォーム管理者 (Market 組織所有者) |
true に設定された状態で初期化され、この設定は変更できません。Market に公開されるすべてのリソースは、ブラウズカタログに表示される前に管理者レビューに合格する必要があります。
組織所有者は自動的にレビューをバイパスします — 公開されたリソースは即座に利用可能になります。Market の場合、Market 組織所有者 (システム管理者) のみがこのバイパス特権を持ちます。
check_edit_revert() は自動的に publish_status を pending_review に戻します。これにより、ライブ Market リソースへの変更がサブスクライバーに表示される前に再度レビューされることが保証されます。
実装上の注意事項
シャドウ組織
Market組織は、よく知られた固定ID（00000000-0000-0000-0000-000000000001）とスラッグ（market）を持っています。これはプラットフォーム初期化中にensure_market_org()によって作成されます — 通常は最初の管理者ユーザーのログイン時です。この関数はべき等です。複数回呼び出しても安全です。
ResourceSubscription
ResourceSubscription テーブルは Market アクセスのコア データ構造です:
| Column | Purpose |
|---|
user_id | サブスクライバー |
resource_type | agent、connector、knowledge_base、mcp_server、skill、または workflow |
resource_id | サブスクライブされたリソースの ID |
org_id | ソース org (Market org ID または通常の org ID) |
(user_id, resource_type, resource_id) の一意制約により、重複したサブスクリプションが防止されます。org_id カラムはサブスクリプションの出所を追跡し、スコープを認識したアンサブスクリプションを可能にします。
可視性フィルター統合
resolve_visibility() 関数は単一の呼び出しで 2 つのルックアップを実行します:
- ユーザーの組織メンバーシップを取得 (
user_org_ids)
- ユーザーのサブスクリプションを取得 (
subscribed_ids)
これらは build_visibility_filter() に渡され、3 つすべての可視性レベル (自分のもの、組織共有、サブスクライブ済み) を組み合わせた単一の SQL WHERE 句を生成します。この関数はリソースがクエリされるあらゆる場所で使用されます — エージェントリスト、コネクター ドロップダウン、スキル注入、自動検出モード — プラットフォーム全体で一貫した可視性を確保します。
認証情報の暗号化
サブスクリプション中（またはその後の設定で）に設定された認証情報は、プラットフォームの暗号化キーを使用して保存時に暗号化されます。Market API は参照レスポンスで認証情報の値を公開することはありません。_*_market_info() ヘルパー関数ではメタデータ（名前、説明、アイコン、タイプ）のみが返されます。
関連項目
