本シリーズの第1部では、エンタープライズ向けエージェンティックアーキテクチャの全体像をご紹介しました。デスクトップエージェントとクラウドエージェントの違い、LLM ではなく「ハーネス」こそが本当に難しいエンジニアリング課題である理由、そしてスタックが「体験」「推論」「メモリ」「プロトコル」「データ」という関心領域を軸にどう構成されているのか。こうした内容について解説しました。あわせて、CData Connect AI が Model Context Protocol（MCP）を通じてデータへの接続を担っていることにも触れました。
本記事では、その内容を具体的にご紹介します。これらのプレーンが Google Cloud の各サービスにどう対応するのか、CData Connect AI が GCP ネイティブのエージェントランタイムにどう組み込まれるのか。そして本番環境では、GCP が管理するインフラストラクチャと CData が管理する接続性のあいだに、どんな信頼境界が引かれるのか。こうしたポイントを順に見ていきます。
Google Cloud 上のエージェンティックアーキテクチャ
Google Cloud Platform（GCP）上で各要素がどう組み合わさるのか、まずは全体像をご覧ください。図は上から下へと読み進めていきます。ユーザーはエクスペリエンスプレーンから入り、その意図は推論プレーン、メモリプレーンを経てプロトコルブリッジを越え、データプレーン内のエンタープライズデータに対して実行されます。
図 1. Google Cloud Platform 上のエージェンティックアーキテクチャ。エージェントの信頼境界（GCP 管理）、MCP プロトコルブリッジ、CData の信頼境界、そしてセキュリティ＆ガバナンスと可観測性＆評価という 2 つの横断レイヤーを示す階層ビューです。
このアーキテクチャは、5 つの水平プレーンと、2 つの垂直な横断レイヤーで構成されています。
エクスペリエンスプレーン：Apigee、Cloud CDN、Cloud Run アプリ、App Session Store
推論プレーン：Agent Supervisor、Agent Registry、4 つの Specialist Agent、Vertex AI、Model Armor
メモリプレーン：Agent Engine（Sessions、RAG Engine、Memory Bank）、Secret Manager
プロトコルプレーン：MCP サーバー（CData、サードパーティ）。MCP クライアントはこのプレーンと、その上層にあるエージェントの信頼境界の両方にまたがっています。
データプレーン：CData Connect AI、Workspaces、Connections、Configurations、Auth0、Toolkits、Tool Registry
右側にある 2 つの垂直レイヤー、つまり「セキュリティ＆ガバナンス」と「可観測性＆評価」は、横断的な関心事として並行して走ります。それぞれのレイヤーは、上半分にあたる「エージェントの信頼境界」ゾーン（GCP 管理）と、下半分にあたる「CData の信頼境界」ゾーンに分かれています。
エージェントの信頼境界
プロトコルプレーンより上にあるものはすべて、エージェントの信頼境界の内側に位置します。ここは、Google Cloud が企業に代わって管理するゾーンです。Agent Engine がオーケストレーションを担い、ADK がエージェントの構造を定義し、Gemini が推論を行います。Model Armor はプロンプトインジェクションや PII をスクリーニングし、Agent Engine Sessions が短期的な会話を保持、Memory Bank がセッションをまたいだユーザー設定を蓄えます。そして Secret Manager が、エージェントが外部と通信するために必要な認証情報を保管します。
ここで押さえておきたい実装上のポイントが、いくつかあります。
Agent Supervisor はルートエージェントです。ADK の用語でいうと、分解された意図を受け取って、どのスペシャリストに引き渡すかを決めるワークフローエージェントにあたります。スペシャリストは個々の Cloud Run サービスで、それぞれがドメイン（営業、サポート、データ品質、レポート）ごとにスコープが切られています。Agent Registry は、どんなエージェントが存在し、それぞれが何をできるのかをまとめたメタデータで、バックエンドには Firestore を使っています。Cloud API Registry のプレビュー版を組み合わせれば、その上にツールガバナンス機能を載せられます。
Model Armor は Vertex AI と直列に配置されます。Gemini に送られるすべてのプロンプトと、返ってくるすべての応答がここでスクリーニングされる仕組みです。フロア設定は組織レベルで、テンプレートはプロジェクトごとに適用されます。これによって、「責任ある AI」のポリシーは、プロンプトエンジニアが頭のなかで覚えておくものではなく、インフラストラクチャに組み込まれた強制力のある仕組みになります。
Agent Engine Sessions と Memory Bank は、エージェントの作業メモリにあたります。Sessions は短期記憶として、ひとつの会話のなかで起きたイベントを時系列のログとして保持します。Memory Bank は長期記憶として、複数のセッションをまたいで残るユーザー設定を、トピック単位で抽出して蓄えます。両機能は 2025 年後半に一般提供（GA）となり、内部では Firestore を基盤としています。
このゾーンに置かれるリソースは、すべて Google Cloud のネットワークファブリック経由でアクセスできます。境界線を引くのは VPC Service Controls です。PSC-I を使えば、Agent Engine はパブリックインターネットを経由せずに、VPC 内でプライベートにホストされているサービスへアクセスできます。
プロトコルプレーン
MCP クライアントは、信頼境界をまたぐ役割を担います。Agent Engine の内部で動いているため、アーキテクチャ上はエージェントの信頼境界に属します。とはいえその目的はただひとつ、GCP の外側にある MCP サーバーに向けて Model Context Protocol を話すことです。
ツール呼び出しが行われるたびに、MCP クライアントは次のような処理を進めます。
エージェントによるツール呼び出しを MCP JSON-RPC ペイロードにシリアライズする
Secret Manager から適切なベアラートークンを取得する
認証ヘッダーを付加し、HTTP 経由で送信する
ストリーミング応答（SSE またはチャンク化された HTTP）を処理する
呼び出されたツールに応じて、適切な MCP サーバーへルーティングする
MCP サーバー自体は、GCP の外側に置かれます。MCP サーバー（CData）のエンドポイントは CData がホストしており、ワークスペース単位でスコープが切られています。MCP サーバー（その他）は、Slack、GitHub、Jira といったサードパーティのツールプロバイダーをカバーします。エージェントのアクセス先は ADK の設定で宣言し、Cloud API Registry がそのフリート全体を一元的に管理します。
このレイヤーには、大きな意味があります。エージェントは、Salesforce の API 呼び出しを書くこともなければ、Jira の REST リクエストを書くこともありません。SaaS プラットフォームのページネーションや認証情報の更新も、自分で処理する必要はありません。エージェントが書くのは、ツール呼び出しだけです。あとは MCP プロトコルが、すべてを抽象化してくれます。
CData の信頼境界
MCP ブリッジの下からは、別の信頼ドメインが始まります。CData の信頼境界は、エンタープライズデータの仮想化が行われる場所です。350 を超える異なるデータソースを、エージェントが扱える単一の SQL ライクなインターフェースに変換するレイヤーだとお考えください。
主な構成要素は、次のとおりです。
CData Connect AI：仮想化エンジンです。MCP サーバーから SQL クエリを受け取り、配下のデータソースに向けてフェデレーション処理を行います。
Workspaces：接続セットを分離します。営業の Workspace には Salesforce と HubSpot、サポートの Workspace には Zendesk と ServiceNow、というかたちです。Workspace A 向けに構成されたエージェントは、Workspace B のなかにある接続を参照できません。これはプロンプトレベルではなく、インフラストラクチャレベルでの分離です。
Connections：個々のデータソースとのバインディングです（Salesforce 組織、Jira サイト、SAP インスタンスなど）。それぞれの Connection は、独自の認証コンテキストを持ちます。
Configurations：再利用可能な SQL テンプレート、カスタムツール、Toolkit の定義をまとめたものです。
Auth0：CData プラットフォーム自体への認証と認可を処理します。
Toolkits：ドメインごとに束ねられたツールのバンドルです。それぞれの Toolkit はエージェントに紐づけられます。Sales Toolkit は Salesforce のアカウントや商談ツールを公開し、Support Toolkit はチケット関連のツールを公開し、Customer Health Toolkit は Salesforce、Jira、Zendesk、Snowflake をまたいだマルチソース結合を公開します。エージェントが CData の MCP エンドポイントに接続すると、自分に割り当てられた Toolkit に含まれるツールだけが見えるようになります。
Tool Registry：スキーマ検証を強制します。公開される MCP ツールは、手で書かれたものではなく、Connection のメタデータから自動的に導出されます。
アーキテクチャとして大事なのは、ここです。エージェントの LLM が、配下のデータソースの生の API スキーマを目にすることはありません。LLM が見るのは、クリーンで意味のある名前がついた SQL ライクなツールだけです。CData のレイヤーが、SaaS API の設計と LLM が得意とする推論のあいだにあるインピーダンスミスマッチ（噛み合わなさ）を吸収してくれます。
セキュリティとガバナンスはどこにある？
セキュリティは、水平に並ぶレイヤーのひとつではなく、縦に貫く関心事です。「セキュリティ＆ガバナンス」のストリップは、メインのアーキテクチャと並行して走りながら、すべてのプレーンに触れています。
エージェントの信頼境界の内側では、セキュリティスタックはまるごと GCP のサービスで構成されています。
Cloud IAM：ワークロード ID とサービスアカウントを管理します。Agent Engine は、エージェントの ID 管理にデフォルトで Context-Aware Access（CAA）を使います。
Cloud Armor：Apigee や各種ロードバランサーの前に配置され、エッジで WAF と DDoS 対策を提供します。
VPC Service Controls：境界線を定義します。エージェントゾーンからパブリックインターネットへのデータ流出は、ネットワーク層でブロックされます。
Model Armor Policies：プロンプトインジェクションと PII（個人識別情報）に対するガードレールを強制します。組織レベルでフロア設定を入れておくことで、どのチームもそれより緩いテンプレートを設定できないようになります。
Cloud Billing：コストの帰属を可視化します。どのエージェントがどれだけトークンを消費したかが、明細として記録されます。
エージェントの信頼境界の外側、つまり CData の信頼境界の内側では、次のような仕組みが働きます。
この分離が大事なポイントです。エージェント側の IAM は「エージェントに何ができるか」を決め、CData 側の RBAC は「エージェントに何が見えるか」を決めます。両方そろって初めて意味を持ちます。どちらか一方だけでは足りません。
評価と可観測性はどこにある？
「可観測性＆評価」のストリップは、セキュリティのストリップの鏡写しです。縦に貫く構造は同じで、扱うテーマだけが違います。
エージェントの信頼境界の内側には、次のような仕組みが揃っています。
Cloud Logging & Monitoring：構造化ログ、メトリクス、アラートを収集します。カスタムメトリクスは Cloud Managed Prometheus が担います。
Cloud Trace：OpenTelemetry をサポートした分散トレーシングを提供します。Agent Engine には Cloud Trace がネイティブに連携しており、すべてのエージェント呼び出し、ツールの起動、LLM リクエストがスパンとして記録されます。
Cloud Audit Logs：管理者の操作とデータアクセスを、常時稼働の堅牢なログとして記録します。
SCC Threat Detection（プレビュー）：デプロイされたエージェントに対する攻撃を、専門的に監視します。
Evaluation Pipeline：意図の系譜（intent lineage）、A/B テスト、フィードバックループはここで動きます。Vertex AI Evaluation Services が、このパイプラインに評価データを供給します。
CData の信頼境界のなかには、次の仕組みがあります。
この 2 つの監査証跡が組み合わさることで、意図から結果まで完全に追跡できるトレーサビリティが手に入ります。ユーザーのプロンプト、エージェントの推論、行われたツール呼び出し、実行された SQL、返ってきた行、そして最終的にユーザーへ届いた応答。これらすべてを、ひとつの流れとしてたどれます。この証跡があるからこそ、エージェントシステムは誤動作したときにデバッグでき、規制当局から判断の根拠を問われたときに監査にも応えられます。
このパターンは一貫しています。Google Cloud が、ユーザーのクリックから MCP の境界までを担います。CData は、MCP の境界から先、エンタープライズデータに至るまでを担います。セキュリティと可観測性は、並行する関心事として両方のドメインをまたぎます。エージェントの信頼境界と CData の信頼境界が出会う場所は、API 連携ではなく、プロトコル（MCP）の上です。
この分離こそが、システム全体をコンポーザブル（差し替え可能）にする要因です。Gemini を Claude に置き換えても構いません。Agent Engine を、GKE 上の LangGraph デプロイメントに差し替えても問題ありません。CData Connect AI は、確立されたプロトコルを通じて接続性を提供します。組織がもともと持っているセキュリティと ID のポリシーに沿ったかたちで、です。だからこそ、どのコンポーネントを入れ替えても、ほかの部分はそのまま動き続けます。Connect AI をデータ層に据えることで、アーキテクチャはもう単一の製品に縛られません。縛られるのは、製品同士のあいだに交わされるインターフェースだけです。
Google Cloud で Connect AI を使い始めましょう
データプレーンを構築する準備はできましたか？CData Connect AI は、Gemini、Vertex AI をはじめとする Google スタックと連携できます。ガバナンスが効いた、リアルタイムで、MCP に対応したデータ接続です。Google Cloud 上で、データを接続してみましょう。
※本記事は CData US ブログ Building Agentic Architectures on Google Cloud Platform の翻訳です。
エンタープライズデータが、ついに AI-Ready に。
Connect AI なら、AI アシスタントやエージェントに、350 を超えるエンタープライズシステムへのリアルタイムかつガバナンスの効いたアクセスを提供できます。学習データに頼るだけでなく、実際の業務データに基づいた推論ができるようになります。
