プロジェクト間の管理境界（または境界）を使用すると、複数の Google Cloud プロジェクトにわたって AI エージェント、Model Context Protocol（MCP）サーバー、ツールを検出、管理、統制できます。Agent Registry は、デフォルトでは単一のガバナンス プロジェクト内で動作しますが、Resource Manager で管理境界を構成すると、中央の管理プロジェクトが、分散されたメンバー プロジェクト全体でエージェント、MCP サーバー、ツールを集約できます。管理境界がプロジェクトのロール、リソースの集約、アクセス制御をどのように構成するかを理解すると、スケーラブルなマルチプロジェクト トポロジを設計できます。
管理境界を構成するには、複数のプロジェクトの管理境界を構成するをご覧ください。
境界モデル
Resource Manager でフォルダまたは組織に管理境界を定義します。
- フォルダ全体または組織全体の境界: デフォルトでは、タグフィルタを構成せずにフォルダまたは組織に境界を作成すると、そのフォルダまたは組織内のすべての子プロジェクトがメンバー プロジェクトとして境界に含まれます。
- タグでフィルタされた境界（省略可）: 必要に応じて、フォルダまたは組織内の子プロジェクトを複数の境界に分割するには、Resource Manager タグを使用して境界メンバーシップをフィルタします。たとえば、
prod環境とdev環境を分離できます。各境界に含めるGoogle Cloud プロジェクトにタグを適用します。フォルダまたは組織内の子プロジェクトに境界フィルタと一致するタグがある場合、そのプロジェクトは管理境界のメンバー プロジェクトになります。
タグを使用して管理境界を分割すると、タグには次の利点があります。
- 動的で自動化された登録: クラウド環境では、プロジェクトが頻繁に変更されます。
env=prodなどの登録済みのタグ値でプロジェクトにタグを付けると、Agent Registry は、境界定義を手動で更新することなく、そのプロジェクトを境界のメンバー プロジェクトとして自動的に含めます。 - フォルダ階層からの分離: Resource Manager のフォルダ構造は、通常、請求またはビジネス目的で編成されます。タグは、境界定義を物理フォルダ階層から切り離し、親フォルダまたは組織にフォルダ間の管理境界を確立できるようにします。
- 継承とスケーラビリティ: 組織またはフォルダに適用されたタグは、リソース階層を介して子フォルダとプロジェクトに自動的に伝播されます。この継承モデルを使用すると、1 つのタグ割り当てでリソースツリーのブランチ全体を登録できます。
- 一元管理: タグは、一元化された Identity and Access Management（IAM）権限に則って管理されます。タグを使用して管理境界を定義することで、個々のユーザーが境界からプロジェクトを任意に追加または削除できないようにすることができます。
アーキテクチャと主なリソース
プロジェクト間の管理境界は、次の Resource Manager リソースに依存します。
境界構成（
BoundaryConfigリソース）: Resource Manager の組織またはフォルダの構成リソース。そのフォルダまたは組織の境界パーティショニング ルールを確立します。BoundaryConfigリソースにタグキーを設定しない場合、組織またはフォルダは、すべての子プロジェクトを含む単一の境界をサポートします。子プロジェクトを複数のタグフィルタ境界に分割するには、BoundaryConfigリソースで、そのフォルダまたは組織のプロジェクト メンバーシップの評価に使用される単一のリソースタグキー（123456789012/envなど）を指定します。境界（
Boundaryリソース）: 組織またはフォルダ内のメンバー プロジェクトの境界。タグフィルタがない場合、境界には親組織またはフォルダ内のすべての子プロジェクトが含まれます。親BoundaryConfigリソースでタグキーを構成すると、Boundaryリソースはenv=prodなどのタグ値フィルタを指定し、そのタグ値を継承または適用する子プロジェクトは自動的に境界に属します。親のBoundaryConfigリソースは単一のタグキーを使用し、プロジェクトはタグキーごとに 1 つの有効なタグ値しか持つことができないため、プロジェクトは親フォルダまたは組織ごとに最大 1 つの境界に属することができます。機能構成（
CapabilityConfigリソース）: 組織、フォルダ、またはプロジェクトで定義されたリソース。組織レベルまたはフォルダレベルでは、1 つ以上の境界を専用の管理プロジェクトにバインドし、それらの境界全体で有効にする管理機能を指定します。プロジェクト レベルでは、境界のない単一のスタンドアロン プロジェクトの管理機能が有効になります。Agent Registry の場合は、AGENT_MANAGEMENT（Google Cloud CLI:agent-management）機能を構成します。これにより、Agent Registry でコンポーネントの一元的な検出、検索ロールアップ、プロジェクト間のガバナンスが有効になり、管理プロジェクトでagentregistry.googleapis.comが自動的に有効になります。
これらの Resource Manager リソースの詳細については、管理の境界と機能の概要をご覧ください。
次の図は、Resource Manager リソースがメンバー プロジェクトを中央管理プロジェクトに接続する方法を示しています。
マルチプロジェクト管理
管理境界は、2 つの異なるプロジェクト ロール（中央の管理プロジェクトと 1 つ以上のメンバー プロジェクト）にわたって、管理ガバナンスをコンピューティング実行から分離します。
この分離された構造により、マルチテナント分離が適用されます。チームは、他のメンバー プロジェクトに直接アクセスすることなく、それぞれのメンバー プロジェクトでエージェントを構築してデプロイします。管理者とオーケストレーターは、管理プロジェクトから管理境界を越えて一元化された可視性を維持します。
管理プロジェクト
管理プロジェクトは、管理境界のガバナンス プロジェクトとして機能する Google Cloud プロジェクトです。基盤となるコンピューティング ランタイムをホストすることなく、API 構成、アクセス制御、課金、割り当ての使用量、集約されたコンポーネント メタデータを境界を越えて一元化します。
Agent Registry では、管理プロジェクトは次の機能を実行します。
- 境界と機能のバインディング:
AGENT_MANAGEMENT機能が有効になっているCapabilityConfigリソースを介して、Resource Manager の 1 つ以上の境界に関連付けます。構成手順については、管理境界を構成するをご覧ください。 - 一元化された検出と検索: プロジェクト間のリストと検索リクエストのターゲット プロジェクトとして機能し、オーケストレーター、デベロッパー、クライアント アプリケーションが、境界内のすべてのメンバー プロジェクトで自動検出されたエージェント、MCP サーバー、ツールを操作できるようにします。
- 境界全体のサービス登録: 手動で登録された
Serviceリソース（カスタム エージェント、外部 MCP サーバー、エンドポイントなど）と、管理境界全体で表示するBindingリソースをホストします。 - API、課金、割り当ての一元管理: 境界レベルの検出とガバナンス オペレーションのために、Agent Registry API の有効化、割り当て、課金を一元化します。
Resource Manager のフォルダまたは組織で CapabilityConfig リソースを構成する場合は、次のいずれかの方法で管理プロジェクトをプロビジョニングできます。
- セルフマネージド管理プロジェクト:
CapabilityConfigリソースの作成時に--management-projectフラグを渡して、管理する既存のGoogle Cloud プロジェクトを指定します。プロジェクトは、CapabilityConfigリソースと同じ親フォルダまたは組織に直接存在する必要があります。また、別のCapabilityConfigリソースの管理プロジェクトとして機能することはできません。後でCapabilityConfigリソースを削除すると、Resource Manager はセルフマネージド プロジェクトを保持し、標準プロジェクトに戻します。 - Google 管理の管理プロジェクト:
CapabilityConfigリソースを作成するときに--management-projectフラグを省略すると、Resource Manager は親フォルダまたは組織に新しいプロジェクトを自動的に作成して管理します。生成されたプロジェクトのプロジェクト ID の接頭辞はgoogle-mpfまたはgoogle-mpoです。後でCapabilityConfigリソースを削除すると、Resource Manager はこの Google 管理プロジェクトを削除します。
どちらの場合も、agent-management を使用して CapabilityConfig リソースを作成すると、管理プロジェクトで agentregistry.googleapis.com が自動的に有効になります。
メンバー プロジェクト
メンバー プロジェクトは、管理境界に属する Google Cloud プロジェクトです。これらは、境界の親フォルダまたは組織内のすべての子プロジェクト、またはオプションの境界タグフィルタ（env=prod など）に一致する子プロジェクトのいずれかです。自動検出されたエージェント、MCP サーバー、ツールは、メンバー プロジェクトで実行されます。
メンバー プロジェクトは、Agent Runtime 推論エンジン、Cloud Run サービス、GKE クラスタなどの独自のローカル コンピューティング リソースを保持します。自動検出されたリソースは、各メンバー プロジェクト内でローカルに取り込まれ、レジストリを一覧表示または検索するときに管理プロジェクトに集約されます。一方、メンバー プロジェクトで作成した手動登録リソースは、その個々のメンバー プロジェクトにリクエストを送信した場合にのみ表示されます。
境界内の管理プロジェクトとメンバー プロジェクトの関連付けには、システムの上限が適用されます。この上限を超えると、ロールアップ エラーが発生する可能性があります。詳細については、割り当てとシステムの上限をご覧ください。
登録とロールアップ
Agent Registry のプロジェクト間検出では、メンバー プロジェクトにデプロイされた自動検出リソースと、作成されたプロジェクトにスコープされた手動登録リソースが区別されます。
自動検出および登録されたリソース
管理境界を越えてリソースのスコープを設定する方法は、リソースの登録方法によって異なります。
自動検出されたエージェントと MCP サーバー: メンバー プロジェクトにデプロイされたサポート対象のリソース（Agent Runtime 推論エンジン、Cloud Run サービス、GKE Deployment など）は、デプロイ先のメンバー プロジェクトに自動的に取り込まれ、管理プロジェクトに集約されます。
手動で登録されたリソースとバインディング: 手動で登録された
Serviceリソース（カスタム エージェント、外部 MCP サーバー、エンドポイントなど）とBindingリソースは、作成されたプロジェクトにスコープされます。- 管理境界を越えて表示する場合は、管理プロジェクトに作成します。
- 1 つのメンバー プロジェクト内でのみ表示する場合は、メンバー プロジェクトに作成します。
スタンドアロン スキル、パブリッシャー、AI アプリケーション: カスタム スタンドアロン
Skill、SkillRevision、Publisher、AiApplicationリソースは、作成されたプロジェクトにスコープが設定され、管理境界内のメンバー プロジェクト間で集計されません。エージェントまたはデベロッパーが検出する必要があるプロジェクトに、カスタム スタンドアロン スキルと AI アプリケーションを登録します。Google が管理するスタンドアロン スキルは、どのプロジェクトでも自動的に検出できます。
一元化されたクエリのロールアップ
Agent Registry がロケーションをスコープする方法は、スタンドアロンのガバナンス プロジェクトをクエリするか、管理境界内のメンバー プロジェクトまたは管理プロジェクトをクエリするかによって異なります。
- スタンドアロン ガバナンス プロジェクトとメンバー プロジェクト: Agent Registry でサポートされているロケーション（
us-central1、europe-west1、us、eu、globalなど）のクエリは、プロジェクト間のロールアップなしで、その単一プロジェクトのそのロケーションのリソースのみを返します。 管理プロジェクト: 管理プロジェクトで
agent-managementを使用してCapabilityConfigリソースを有効にすると、Agent Registry でサポートされているすべてのロケーションでプロジェクト間のロールアップがサポートされます。管理プロジェクトのロケーションをクエリすると、管理プロジェクトと管理境界内のすべてのメンバー プロジェクトで、同じロケーションのリソースが集計されます。このロールアップには、異なるロケーションのリソースは含まれません。- 単一リージョン:
us-central1やeurope-west1などの単一リージョンでのクエリは、管理プロジェクトとそのメンバー プロジェクト全体でその単一リージョンにデプロイされた自動検出エージェントと MCP サーバーを、管理プロジェクトのそのリージョンで作成されたServiceリソースとBindingリソースとともに集計します。 - マルチリージョン:
usやeuなどのマルチリージョンでのクエリは、そのマルチリージョンにデプロイされた自動検出エージェントと MCP サーバーを、管理プロジェクトとそのメンバー プロジェクト全体で集計します。マルチリージョンのクエリは、単一リージョンにデプロイされたリソースを集計しません。 - グローバル:
globalロケーションのクエリは、管理プロジェクトとそのメンバー プロジェクト全体でglobalにデプロイされた自動検出エージェントと MCP サーバーを、管理プロジェクトのglobalに作成されたServiceリソースとBindingリソースとともに集計します。globalのクエリは、マルチリージョンまたはシングル リージョンにデプロイされたリソースを集計しません。
- 単一リージョン:
管理プロジェクトのロケーションでエージェント コンポーネントを一覧表示、検索、取得すると、Agent Registry は次の手順を実行します。
- アクティブな
CapabilityConfigリソースを介して管理プロジェクトに関連付けられているすべてのメンバー プロジェクトを識別します。 - 管理プロジェクトと各メンバー プロジェクトのそのロケーションで自動検出されたエージェントと MCP サーバーをクエリします。また、管理プロジェクトのそのロケーションで作成された手動登録済みの
Serviceリソースもクエリします。 - 一致するリソースを統合された結果セットに集約します。
- 集計結果を返します。
同じ CapabilityConfig リソースに複数の境界が接続されている場合、Agent Registry は、接続されているすべての境界のメンバー プロジェクトを同じ管理プロジェクト レジストリに集約します。管理プロジェクトのリストまたは検索結果を 1 つのメンバー プロジェクトに絞り込むには、--filter="project_id=MEMBER_PROJECT_ID" を渡します。2 つの環境で個別の可視性が必要な場合は、境界ごとに個別の CapabilityConfig リソースと管理プロジェクトを作成します。
単一プロジェクトの検出とクロスプロジェクト検出では、同じ API メソッドを使用します。検索のスコープは、ターゲット プロジェクトがメンバー プロジェクトか管理プロジェクトかによって異なります。
管理境界を越えたリソース名
コンポーネントがメンバー プロジェクトに含まれている場合、Agent Registry は AGENT_ID や SERVER_ID などの ID を割り当てます。管理境界を越えてコンポーネントを一覧表示、検索、取得すると、Agent Registry はそのコンポーネントの ID を保持し、使用するプロジェクトに基づいて関連するリソース名をフォーマットします。
- 管理プロジェクト: 管理プロジェクトを使用してコンポーネントを一覧表示、検索、取得すると、各リソース名に管理プロジェクトが使用されます。
- メンバー プロジェクト: リソースがデプロイされているメンバー プロジェクトを使用してコンポーネントを一覧表示、検索、取得すると、各リソース名にそのメンバー プロジェクトが使用されます。
次の表に、メンバー プロジェクトにデプロイされた自動検出リソースのリクエスト URL と関連するリソース名を示します。
| リソースの種類 | リクエスト URL | 関連付けられているリソース名 |
|---|---|---|
| エージェント | projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/agents/AGENT_ID |
projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/agents/AGENT_ID |
projects/MEMBER_PROJECT_ID/locations/LOCATION/agents/AGENT_ID |
projects/MEMBER_PROJECT_ID/locations/LOCATION/agents/AGENT_ID |
|
| MCP サーバー | projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID |
projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID |
projects/MEMBER_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID |
projects/MEMBER_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID |
関連付けられたリソース名には、リクエスト内のプロジェクトが反映されます。ただし、コンポーネントのレジストリ ID とランタイム参照は不変であり、基盤となるワークロードが実行されるメンバー プロジェクトを常に保持します。
トポロジの可視化とトラフィック フロー
プラットフォーム管理者と AI アーキテクトは、トポロジグラフを使用して、マルチエージェントの関係とプロジェクト間のトラフィックを可視化できます。
トポロジグラフには、次のアーキテクチャ ディメンションが可視化されます。
- ランタイム参照の相関: 論理エージェント識別子を物理ランタイム参照と関連付けます。この関連付けにより、オペレーターは Agent Registry 内のエージェントを、基盤となる Agent Runtime 推論エンジン、Cloud Run サービス、GKE デプロイに直接トレースできます。
- プロジェクト間のバインディング: 1 つのプロジェクトのオーケストレーター エージェントと、別のプロジェクトの MCP サーバーまたはダウンストリーム ツールとの間のバインディングが表示されます。
- 境界の検証: 管理者が、エージェントの通信が VPC Service Controls の境界に準拠し、指定された Agent Gateway エンドポイントを介してルーティングされていることを確認できます。
アクセス制御
管理境界では、管理プロジェクトに IAM 検出ロールを付与します。これにより、ユーザーとオーケストレーターは、個々のメンバー プロジェクトへの直接 IAM アクセスを必要とせずに、境界を越えて検索できます。メンバー プロジェクトで作成された手動登録の Service リソースと Binding リソースは管理プロジェクトにロールアップされないため、セキュリティ管理者は、組織のポリシーの制約または IAM 拒否ポリシーを使用して、メンバー プロジェクトでのローカル Service と Binding の作成を制限することもできます。メンバー プロジェクトのエージェントがツールを呼び出すか、境界を越えて他のプロジェクトのエージェントと通信すると、トラフィックは中央の Agent Gateway を介してルーティングされます。
管理境界内のリソースの場合、VPC Service Controls の制限は、管理プロジェクト内の Agent Registry の操作にのみ適用されます。Agent Registry は、管理境界内のすべてのメンバー プロジェクトでエージェントと MCP サーバーを検出できます。これらのメンバー プロジェクトが管理プロジェクトと同じサービス境界内にない場合でも検出できます。
境界の設定、レジストリへのアクセス、メンバー プロジェクトの書き込み制限に必要なロールの詳細については、プロジェクト間の管理境界のロールをご覧ください。
次のステップ
- Resource Manager で管理境界を構成する。
- プロジェクト間のデータモデルについて学習する。
- 管理境界を越えて検索する。
- Agent Registry のロールと権限を確認する。