ランタイムアーキテクチャ

接続する各ランタイムで、Solo Enterprise for agentregistry のコントロールプレーンコンポーネントがどのように現れ、統合されるかを確認します。

単一の Solo Enterprise for agentregistry インストール、つまり 1 つのレジストリコントロールプレーンは、多数のランタイムを同時に管理し、それらすべてにまたがる AI アーティファクトを統制するように設計されています。接続するランタイムに関係なく、コントロールプレーンは同じコンポーネントセットです。1 つの PostgreSQL データベースと 1 つの ClickHouse データベースを背後に持つレジストリサーバー、トレース取り込み用の 1 つ以上の OpenTelemetry Collector、そして ID プロバイダーに委任された認証で構成されます。ランタイムごとに変わるのは、それらのコンポーネントがどこで実行されるか、そしてレジストリがランタイムにどのように到達するかです。このページでは、各ランタイムの対応関係を示します。コンポーネント自体については、アーキテクチャを参照してください。

ランタイム	種類	レジストリの接続方法
Solo Enterprise for kagent	検出とデプロイ	独自の OIDC サービス ID で kagent controller の管理 API を呼び出します。
AWS Bedrock AgentCore	検出とデプロイ	ユーザーのアカウントで IAM ロールを引き受け、クラスター内に管理対象ゲートウェイをプロビジョニングします。
Azure AI Foundry	検出のみ	Microsoft Entra アプリ登録を使って Foundry project API を読み取ります。
Microsoft Copilot Studio	検出のみ	Microsoft Entra アプリ登録を使って Dataverse Web API を読み取ります。
Solo Enterprise for agentgateway	仮想ランタイム	インストール済みの agentgateway proxy 上にルートを作成します。

Note

このページの統合詳細は現在の実装を反映しており、リリース間で変更される可能性があります。

Solo Enterprise for kagent

Kubernetes では、レジストリはクラスター内で実行される Solo Enterprise for kagent コントロールプレーンと統合します。1 つのレジストリは、多数の kagent クラスターに同時に接続できます。

コンポーネントの対応関係: 図ではコンポーネント間の関係を読みやすくするため、すべてを 1 つのクラスターにまとめています。ただし、各部分は独立しています。PostgreSQL、ClickHouse、ID プロバイダーは外部マネージドサービスにできます。また、レジストリコントロールプレーンと kagent ランタイムを別々のクラスターで実行することもできます。

レジストリサーバーとその状態ストア。 レジストリサーバーはコントロールプレーンです。UI と API を提供し、エージェント、MCP サーバー、デプロイ、ポリシーのカタログを保持し、接続済みランタイムに対するすべての操作を駆動します。この状態は PostgreSQL に永続化されます。図ではクラスター内に示されていますが、外部マネージドデータベースとして扱えます。一方、ランタイムは内部的には接続としてモデル化されます。これにより、1 つのレジストリで多数の kagent クラスターを同時に統制できます。
ID プロバイダー。 Keycloak はこのランタイムの単一の OIDC ID プロバイダーです。Registry UI、arctl CLI、REST API クライアントをレジストリに対して認証し、ランタイム自体が信頼する issuer でもあります。この ID は、レジストリがアクセス制御を適用するために使用します。各呼び出し元の JWT group claim をロールにマッピングし、定義した AccessPolicy リソースに対して、ユーザーが読み取り、公開、デプロイ、またはチャット UI 経由の呼び出しを実行できるかを認可します。標準準拠の OIDC プロバイダー (Okta、Auth0) であれば、クラスター内でも外部でも代替として使用できます。
kagent controller。 レジストリサーバーは kagent controller の管理 API を呼び出してワークロードを作成、管理します。各カタログエントリをランタイムのネイティブリソース、つまりエージェントの場合は kagent Agent、MCP サーバーの場合は MCPServer に変換し、controller がそれらをチーム namespace 内の Pod として実体化します。これらの呼び出しは、独自の OIDC サービス ID で認証されます。これは IdP から発行される client-credentials サービストークンで、kagent の RBAC がロールにマッピングする group claim (たとえば agentregistry → global.Writer) を含みます。デプロイや管理操作ではエンドユーザーの認証情報は使用されません。この関係は双方向です。レジストリはデプロイをプッシュするだけでなく、定期的に、また各デプロイ直後にランタイムのインベントリをポーリングして、別の手段でデプロイされたエージェントを検出し、カタログと実際に実行されているものとの差分を検出します。
ワークロードイメージ。 kagent では、エージェントと MCP サーバーのイメージを自分でビルドし、任意のコンテナレジストリへプッシュします。デプロイ時には、プライベートレジストリ用にランタイムへ設定した image-pull secret を使って、クラスターの kubelet がそこからイメージをプルします。レジストリも kagent もイメージをビルドまたは保存しません。これは、プラットフォームがコンテナをビルドするクラウドランタイムとの重要な違いです。
ワークロード (エージェント Pod と MCP サーバー Pod)。 これらは、デプロイ済みエージェントと MCP サーバーとしてチーム namespace で実行されるユーザーのコードです。ランタイムが実際に実行する対象であり、図のその他すべてはそれらをデプロイ、保護、または観測するために存在します。
ランタイム認可 (agentgateway waypoint)。 デプロイ済みワークロードがランタイムで何を実行できるか、つまりどのエージェントがどの他のエージェント (A2A) を呼び出せるか、どの MCP ツールを呼び出せるかを統制するために、kagent は agentgateway waypoint を通じてデータプレーンでポリシーを適用します。レジストリの AccessPolicy は kagent AccessPolicy に変換され、デプロイ済みワークロードは waypoint に登録されてトラフィックが捕捉され、ポリシーは xDS 経由の設定として waypoint にプッシュされます。これにより、すべての agent-to-agent 呼び出しと agent-to-MCP 呼び出しは waypoint を通過し、ターゲットに到達する前に許可または拒否されます。これはデータプレーンで実行されるため、Solo Enterprise for Istio (waypoint をホストする ambient mesh) と Solo Enterprise for agentgateway が必要です。これは任意で有効化するレイヤーであり、ベースの kagent ランタイムはこれなしでもエージェントをデプロイして実行します。
テレメトリ (OTel Collector → ClickHouse)。 デプロイ済み Pod は OTLP トレースを OTel Collector に送信し、Collector はそれらを ClickHouse に書き込んで Tracing ビューを支えます (破線の戻り矢印)。kagent ではワークロードが Collector と同じ場所で実行され、外部公開を必要としないため、Collector は通常のクラスター内 ClusterIP Service です。

AWS Bedrock AgentCore

AWS の場合、レジストリはユーザーの AWS アカウントに接続し、エージェントと MCP サーバーを Bedrock AgentCore ランタイムとしてデプロイします。コントロールプレーンと管理対象ゲートウェイは EKS クラスターで実行され、AgentCore ランタイムだけがクラスター外の AWS アカウント内で実行されます。

コンポーネントの対応関係: Solo Enterprise for agentregistry コントロールプレーンは、AWS アカウント内の Kubernetes (EKS) クラスターにデプロイされます。図を簡潔にするため、PostgreSQL と ClickHouse はそのクラスター内に示していますが、Amazon RDS 上の PostgreSQL など、外部の管理サービスにすることもできます。このランタイムに固有なのは、ワークロードが AWS Bedrock AgentCore で実行される点です。デプロイするエージェントと MCP サーバーは AgentCore ランタイムとして実行され、レジストリはそれらのトラフィックを仲介するため、同じクラスター内に Kubernetes デプロイメントとして管理対象ゲートウェイをプロビジョニングします。AgentCore ランタイムは EKS クラスターと同じ VPC 内で実行されますが、クラスター自体の外側で実行されます。

レジストリサーバーとその状態ストア。 レジストリサーバーは、EKS クラスターで実行されるコントロールプレーンです。UI と API を提供し、エージェント、MCP サーバー、デプロイ、ポリシーのカタログを保持し、AWS ランタイムに対するすべての操作を駆動します。この状態は PostgreSQL に永続化されます。図ではクラスター内に示されていますが、Amazon RDS などの外部マネージドデータベースとして扱えます。詳細については、BYO PostgreSQL databaseを参照してください。
ID (1 つまたは 2 つの OIDC プロバイダー)。 レジストリには組み込み OIDC はありません。プロバイダー (Keycloak、Amazon Cognito、Okta/Auth0 など) に依存します。ここでは 2 つの ID ロールが関与し、1 つのプロバイダーでも 2 つの別々のプロバイダーでも構いません。registry OIDC はレジストリに到達するユーザー、CLI、UI、REST API を認証し、カタログ操作に対するアクセス制御を支えます。一方、agent OIDC はデプロイ済みエージェントへの呼び出しを認可します。これらは目的が異なります。レジストリにログインするトークンは、エージェント呼び出しを認可するトークンではありません。
AWS アクセス (OIDC ではなく IAM)。 レジストリが AWS に到達する方法は IAM ベースです。レジストリ Pod は EKS Pod Identity (または静的 IAM ユーザー認証情報) で AWS に認証し、その後、すべての AWS 操作に対してユーザーのアカウント内の IAM ロールを引き受けます。このロールは CloudFormation テンプレートから作成され、外部 ID でスコープ設定されます。これは、以降のデプロイ、ビルド、ゲートウェイの各ステップが依存する AWS 固有の基盤です。
ビルドとデプロイ (S3 → ビルド → ECR)。 デプロイするために、レジストリは引き受けたロールの下で AWS Bedrock AgentCore コントロールプレーン API を呼び出してランタイムを作成します。ソースからデプロイする場合、まずソースをパッケージ化して S3 バケットにアップロードします。AWS はコンテナイメージをビルドして ECR に保存し、AgentCore ランタイムはそのイメージをプルして VPC 内で実行します。全体を通じて、各ランタイムのステータスを追跡し、カタログでデプロイの進行状況を反映します。
ワークロード (Bedrock AgentCore runtime)。 エージェントと MCP サーバーは、運用対象の Pod ではなく、マネージド AWS Bedrock AgentCore runtime として実行されます。EKS クラスター外で実行されますが、同じ VPC 内にあります。そのため、トラフィックとテレメトリはネットワークをまたいでコントロールプレーンへ戻ります (次の 2 つの項目)。
管理対象ゲートウェイとランタイム適用。 レジストリは、EKS クラスター内の Kubernetes デプロイメントとして管理対象ゲートウェイをプロビジョニングします。これは Solo Enterprise for agentgateway プロキシと agentregistry-sts トークンサービスで構成され、すべてのエージェントから MCP へのトラフィックを運び、エージェント OIDC に照らして各呼び出し元を検証しながら、ランタイムでアクセスポリシーを適用します。これは kagent の waypoint に相当する AgentCore 側の仕組みです。同じポリシーモデルを、異なる適用ポイント (メッシュ waypoint ではなく Kubernetes でホストされるゲートウェイ、かつ Istio 依存なし) で実現します。各 AgentCore ランタイムのコンテナイメージは agent-proxy でラップされます。agent-proxy は個別コンテナではなく、エージェントと同じコンテナのエントリーポイントとして実行され、エージェントのアウトバウンドトラフィックをゲートウェイにリダイレクトします。レジストリはランタイムのルーティングとアクセスポリシーを、agent-proxy がポーリングする S3 オブジェクトに公開します。ランタイムに直接接続するわけではありません。
テレメトリ (OTLP → OTel Collector → ClickHouse)。 runtime はクラスター外で実行されるため、ネットワーク越しに OTLP トレースをコントロールプレーン内の OTel Collector へエクスポートし、Collector はそれらを ClickHouse に書き込んで Tracing ビューに使用します。そのため、Collector と ID プロバイダーは VPC から到達可能である必要があります。AWS では通常、kagent が使用するクラスター内部サービスではなく、ロードバランサー経由で Collector を公開します。

Microsoft Azure と Copilot Studio

Azure AI Foundry と Microsoft Copilot Studio では、レジストリは Microsoft テナントに接続し、そこで既に実行されているエージェントをインベントリ化します。

Azure AI Foundry and Microsoft Copilot Studio runtime architecture: only the registry server and a PostgreSQL discovery cache are involved; using a Microsoft Entra client secret, the registry authenticates against Entra ID and lists agents from the Foundry project API and the Dataverse Web API.

コンポーネントの対応関係: これは検出統合です。レジストリは Microsoft クラウドに接続し、そこで既に実行されているエージェントを読み取ります。エージェントをデプロイしたり、実行したり、トラフィックをルーティングしたりはしません。そのため、この統合に関与するコントロールプレーンコンポーネントは 2 つだけです。レジストリサーバーと、検出済みインベントリをキャッシュする PostgreSQL です。何もデプロイまたはトレースされないため、ClickHouse と OTel Collector はこの統合には関与しません。コントロールプレーンは任意の Kubernetes クラスターで実行でき、Microsoft テナントへのアウトバウンドアクセスだけが必要です。

レジストリサーバーとインベントリキャッシュ。 レジストリサーバーはコントロールプレーンです。UI と API を提供し、カタログを保持し、検出同期ループを実行します。検出済みエージェントは PostgreSQL にキャッシュされます。PostgreSQL は状態ストアでもあり、外部マネージドデータベースにできます。この統合でアクティブなコンポーネントはこの 2 つだけです。独自のインフラストラクチャでビルド、デプロイ、運用するものはありません。
ID。 2 つの ID が関与します。レジストリ ID プロバイダー (Keycloak、Cognito、Okta/Auth0 など) は、レジストリに到達するユーザー、CLI、UI、REST API を認証し、実行できる操作を統制します。別に、Microsoft Entra アプリ登録は、レジストリが Microsoft テナントに到達するために使用するサービス ID です。アプリを作成し、対象サービスへの読み取りアクセスを付与し、その client secret をレジストリに保存します。レジストリは client-credentials grant を使用して、各同期のトークンを取得します。
検出と同期、このランタイムの中核。 レジストリはエージェントをデプロイする代わりに、Microsoft クラウドを定期的に呼び出して既存のエージェントを一覧表示し、それらを読み取り専用の Instances としてキャッシュします。各 Instance にはプロバイダーメタデータと Microsoft ポータルへのディープリンクが含まれます。ランタイムを適用すると初回同期が実行され、ランタイムステータスには直近の同期が成功したかどうかが報告されます。レジストリはこれらのランタイム上でエージェントをデプロイまたは削除できません。Microsoft が報告する内容を反映するだけです。
対象サービス – Azure AI Foundry と Microsoft Copilot Studio。 2 つのランタイムの違いは、レジストリが何を読み取るかだけです。Azure AI Foundry の場合、Foundry プロジェクト内のエージェントを一覧表示します (Entra アプリにはそのプロジェクトの Foundry User ロールが必要です)。Microsoft Copilot Studio の場合、Dataverse Web API 経由で Power Platform 環境内のエージェントを一覧表示します (Entra アプリは、bot への読み取りアクセスを持つ Dataverse application user である必要があります。これはサブスクリプションやリソースグループのロールとは別のロールです)。プロジェクトまたは環境ごとに 1 つのランタイムを登録し、単一のレジストリで多数を追跡できます。それ以外、つまり Entra ID、同期ループ、キャッシュされた読み取り専用インベントリは同じです。
エージェント (Microsoft で実行)。 エージェント自体は Azure AI Foundry または Copilot Studio 内に存在し、完全にそこで実行されます。レジストリは、それらのライフサイクルを所有せずに、プロジェクトや環境をまたいでインベントリ化および監視するための単一の場所を提供します。これにより、この統合は軽量に保たれます。

Solo Enterprise for agentgateway (仮想ランタイム)

Virtual runtime では、別の場所で既に実行されている MCP サーバー、つまりクラスター内サービス URL や完全に外部の公開 SaaS MCP エンドポイントを、安定したレジストリ管理パスで Solo Enterprise for agentgateway proxy 経由に公開できます。リモートサーバーをカタログ化し、Virtual runtime に対する Deployment を作成します。レジストリはそれを、route delegation を使用したゲートウェイ上の Gateway API ルーティング (backend と route) に変換します。イメージはビルドされず、ワークロードも実行されません。レジストリは、自身がホストしないサーバーの前段でルーティングとアクセスだけを管理します。(起動時には virtual-default runtime も自動的に作成されます。)

Solo Enterprise for agentgateway virtual runtime architecture: a registry user (arctl/UI) catalogs remote MCP servers through the registry server, which runs with PostgreSQL and Keycloak in a Kubernetes cluster and writes routing config (a backend plus a child HTTPRoute) to a user-managed agentgateway proxy; separately, an MCP client calls the agentgateway, which proxies the request upstream to the remote MCP server (in-cluster or external) and enforces policy. The registry is not in the data path.

コンポーネントの対応関係: このランタイムはそれ自体では何もホストしません。別の場所で実行されている MCP サーバーの前に、管理対象の入口を置きます。ユーザー側の構成要素は軽量に保たれます。PostgreSQL カタログを持つレジストリサーバー、ID プロバイダー、そしてユーザー管理の agentgateway proxy です。レジストリはゲートウェイのルーティングを設定しますが、リクエストパスには入りません。そのため、ライブ MCP トラフィックは client → gateway → remote server と流れます。独自のイメージビルド、ワークロード、テレメトリパイプラインはありません。ClickHouse と OTel Collector が関与するのは、リモートサーバーがトレースを出力する場合だけです。

レジストリサーバーとそのカタログストア。 コントロールプレーンは、登録したリモート MCP サーバーとその Deployment からなるカタログを PostgreSQL に保持し、各エントリをゲートウェイルーティング設定へ変換する Virtual deployment adapter を実行します。任意の Kubernetes クラスターで実行できます。
ID。 レジストリ OIDC プロバイダー (Keycloak、Cognito、Okta など) は、レジストリに到達するユーザー、CLI、UI、REST API を認証し、カタログアクセスを統制します。これとは別に、任意で、ゲートウェイは公開された MCP 呼び出しに対してアクセスポリシーを適用できます (audience や email などの JWT claim)。これにより、各リモートサーバーを呼び出せるユーザーをエッジで制御できます。
公開とルーティング、このランタイムの中核。 レジストリはデプロイする代わりに、Gateway API route delegation を使用して、ユーザー管理の agentgateway 経由でリモート MCP サーバーの前段に立ちます。各リモートサーバーとその Deployment について、2 つのルーティング設定を書き込みます。1 つは agentgateway backend (upstream、つまり host、port、path。URL が https の場合は TLS。サーバーが bearer token などの認証情報を必要とする場合は header filter) で、もう 1 つは child HTTPRoute (サーバーが公開されるパス) です。サーバーは委任されたプレフィックス配下の安定したパス (たとえば /registry/github) で到達可能になり、そのパスはデプロイステータスに報告されます。リモートエンドポイントを宣言しているサーバーだけが対象になります。
agentgateway (データプレーン)。 ユーザー管理の Solo Enterprise for agentgateway proxy、つまり Gateway API Gateway と parent HTTPRoute がライブ MCP トラフィックを運びます。クライアントリクエストを受け付け、パスごとにレジストリの child route へ委任し、途中で任意のアクセスポリシーを適用しながらリモートサーバーへプロキシします。これは mesh waypoint ではなく north-south gateway であるため、Solo Enterprise for agentgateway と Gateway API CRD が必要ですが、Istio は不要です。
リモート MCP サーバー。 実際の MCP エンドポイントは、クラスター内サービスや外部の公開 SaaS MCP サーバーなど、別の場所に存在して実行されます。レジストリはそれらをホストせず、カタログ化して公開するだけです。

詳細については、Remote MCP gatewayを参照してください。

次のステップ

アーキテクチャレジストリコントロールプレーンを構成するコンポーネントを確認します。はじめにコントロールプレーンをインストールし、最初のランタイムを接続します。

アーキテクチャ OSS と Enterprise