一元化されたポリシーと分散ロジック: Eventarc Advanced の概要

※この投稿は米国時間 2026 年 2 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

エンタープライズ アーキテクトは、開発者のアジリティと組織の管理のどちらを優先するかという根本的なジレンマに直面することがよくあります。開発チームは、迅速に作業し、許可を待つことなく独立したマイクロサービスをデプロイする必要があります。セキュリティ チームとコンプライアンス チームは安全を確保し、データフローが可視化され、ポリシーによって管理されるようにする必要があります。

そこで、Google はサーバーレスのイベント処理プラットフォームである Eventarc Advanced を構築しました。これは Eventarc Standard の進化版です。Eventarc Advanced は、一元化されたポリシーと分散されたロジックを組み合わせることで、最新のクラウド向けに改善された アーキテクチャ パターンを提供します。Eventarc Advanced では、ガバナンス レイヤ（「バス」）と処理レイヤ（「パイプライン」）を明確に分離することで、SecOps チームが求める可視性と制御を実現する一方で、開発者が AI エージェントを調整してイベント ドリブン アプリケーションを自律的に構築できるようにしています。Eventarc Advanced は 2025 年 8 月に一般提供されました。

この投稿では、インテグレーション アーキテクチャの変遷（サービスバスから、マイクロサービス、現在に至るまで）について見ていくとともに、実例を挙げながら解説します。それでは詳しく見ていきましょう。

インテグレーション アーキテクチャの進化

新しいパターンの価値を理解するために、これまでの経緯と、以前のアーキテクチャ パターンで妥協を余儀なくされた点について確認しておきましょう。

エンタープライズ サービスバスにおける集中的なボトルネック

インテグレーション アーキテクチャの初期のアプローチの一つに、エンタープライズ サービスバス（ESB）があり、これは、一元管理を優先していました。ESB は、ポイントツーポイントのインテグレーションにおける「スパゲッティ アーキテクチャ」を解決するために登場しました。具体的には、異種システム間のやり取りを標準化する一元化された通信レイヤを提供します。しかし、多くの場合、重大な落とし穴がありました。

主な問題は、一元化されたロジックのトラップと呼ばれるものです。変換やオーケストレーションなどの複雑なビジネス ロジックがガバナンス レイヤに直接埋め込まれることが多く、その結果、ミドルウェア レイヤが不透明になり、サービスを所有する開発者側から重要なビジネスルールが見えない状態になりました。

そのため、インテグレーションの変更に、中央のミドルウェア チームが介入しなければならないのが一般的でした。開発チームは自律性を失い、インテグレーション スペシャリストの順番待ちを強いられ、小さな機能でさえリリースに数週間かかることがよくありました。

マイクロサービスのガバナンスの盲点

これに対処するため、業界はマイクロサービス（通称「スマート エンドポイントとダムパイプ」）へと移行し、ロジックを分散してチームが求めていた自律性を実現しました。同期トラフィック（REST、gRPC）では、API ゲートウェイやサービス メッシュなどのツールによってインフラストラクチャ レベルで認証やレート制限などのポリシーを適用することで、ガバナンス レイヤを復元できます。

しかし、アーキテクチャがレジリエンスと分離を強化するためにイベント ドリブン アーキテクチャ（EDA）へと移行するにつれ、新たな課題が生じました。分散された非同期環境では、一元管理が失われることがよくあり、SecOps チームが秩序を維持するのに苦労するというガバナンス上の課題が生まれたのです。問題となったのは、以下の 3 点です。

• 可視性の欠如: 一元的なポリシーがないと、シャドー IT サービスが検出されずに機密性の高いイベントをひそかにサブスクライブする可能性があります。

• ポリシーの問題: ブローカーが個々のメッセージを不透明な blob として扱う場合、データ所在地や PII マスキングを適用することはほぼ不可能です。

• 依存関係のリスク: 明示的な取り決めなしにイベント スキーマを変更すると、ダウンストリーム側の不明なコンシューマーがいつのまにか破損されるリスクがあります。

新しいパターン: ポリシーは一元化、ロジックは分散

Eventarc Advanced は、一元化されたポリシーと分散ロジックという新しいアーキテクチャ パターンにより、制御とスピードの両立という課題に対処しています。

Eventarc Advanced では、これらの異なる責任を 2 つの特定のアーキテクチャ リソースにマッピングします。各リソースはそれぞれ、以下の異なるロールに対応しています。

• バス: このガバナンス レイヤは、イベントがルーティングされる前にプラットフォーム管理者がグローバルな制約を適用する、一元管理用のハブです。これは、従来の ESB の一元化されたルーティングと、サービス メッシュの最新のセキュリティ アーキテクチャを統合したものです。Identity and Access Management（IAM）やそのコンテンツベースのアクセス制御を処理し、誰にパブリッシュを許可するかを厳密に定義して、VPC Service Controls と連携しながらデータ引き出しを防止できます。

• パイプライン: この分散型のチーム所有リソースは、いわば、開発者のインテグレーション ロジック レイヤです。このレイヤで、AI エージェントとマイクロサービスのイベント処理パターンが自由に解放され、開発者は特定のビジネス ロジックに従ってイベントフローと配信を構成できます。データを不透明なビットとして扱う多くのサービス メッシュとは異なり、このパイプラインはコンテンツを理解します。開発者は、イベントの変換、ペイロードの形式変換（JSON から Avro など）、再試行ポリシーおよび認証の構成を独立して行うことができます。

つまり、Eventarc Advanced はこれらの役割を分離することで、ESB の制御、マイクロサービスのアジリティ、最新型のイベント ドリブン アーキテクチャのレジリエンスをすべて実現しています。

仕組み: 小売業のイベント メッシュの例

一般的な Eventarc Advanced ソリューションは最小限の構成で実装でき、管理ガバナンスと分散インテグレーション ロジックの両方で合理化されたエクスペリエンスを提供します。このモデルが実際にどのように機能するかを、 小売業のイベント メッシュの事例で見てみましょう。

例として、グローバルな小売業者のエコシステムについて考えます。4 つの自律的な部門があり、それぞれ以下のサービスを担当しています。

コマース

財務

物流

インテリジェンス（AI インサイト エージェント）

従来の方法では、これらの部門を連携させるのは困難です。インテリジェンス部門はモデルの全データにアクセスしたいと考えます。一方、財務部門はコンプライアンスのためにすべてのデータをロックする必要があります。物流チームは出荷のために安定したスキーマを求めています。コマース部門は新しい機能を即座にリリースする必要があります。

基盤: CloudEvents 上に構築

Eventarc Advanced は、オープンな CloudEvents 標準に基づくデータモデルを使用しており、あらゆる種類のペイロードに対応できます。そのため、柔軟性を維持しながら、ガバナンスおよび検出可能性を確保することが可能です。この例では、プラットフォーム管理者によって、単一イベントをパブリッシュする前に、すべてのメッセージに標準属性およびガバナンス用のカスタム拡張属性を含めることが義務付けられているものとします。

この例では、バス上のすべてのイベントに次の属性を含める必要があります。

• type: イベント インスタンスの標準識別子（例: com.retail.order.created）

• source: プロデューサーを識別する標準属性（例: //commerce/frontend）

• data_sensitivity: リスクを分類するカスタム拡張属性

さらに、この組織では 3 種類のデータ機密性レベルを定義しています。

• restricted （高）: クレジット カードのトークンや納税者番号などの高リスクデータ

• confidential （中）: 自宅住所などの個人情報（PII）

• general （低）: 注文 ID などの安全な運用データ

この標準化されたメタデータ レイヤにより、特定の属性名に基づいてバスからポリシーを適用することが可能となります。具体的には、データの送信元（source）とデータの種類（data_sensitivity）をチェックできます。

ワークフロー

このモデルは、単一の注文のライフサイクルにおいて、機密性がステップごとに変化する安全なフローとなります。

1. 注文: Commerce（コマース）サービスが order.created をバスにパブリッシュします。このイベントのデータ機密性は general とタグ付けされています。AI Insights Agent（AI インサイト エージェント）サービスは、市場のトレンドを分析するために、この情報をサブスクライブします。

2. 支払い認証: Commerce サービスが payment.authorized をパブリッシュし、restricted  タグを付けます（セキュア トークンが含まれます）。Finance（財務）サービスが、このトークン取得をサブスクライブして、請求処理を実行します。

3. 決済: Finance サービスが payment.success をパブリッシュし、general タグを付けます。これが、出荷に進んでよいという合図になり、財務上の機密情報は隠されたままになります。Logistics（物流）が出荷のためにこれをサブスクライブします。また、Intelligence AI Insights Agent（インテリジェンス AI インサイト エージェント）がトリガーされて、次のサプライ チェーン サイクルの市場動向を評価します。

4. 出荷: Logistics サービスが shipment.ready をパブリッシュし、confidential  タグを付けます（お客様の電話番号が含まれます）。Logistics が自らの通知パイプラインによってこれをサブスクライブし、SMS 通知をトリガーします。

従来のアーキテクチャだと、PCI、PII、運用のデータが単一バスに混在し、コンプライアンスの面で非常に複雑になりますが、Eventarc Advanced を使用すれば、この問題は解決します。

バス: ガバナンス レイヤ

プラットフォーム管理者は、バスに安全な戦略を実装できます。たとえば、内部サービスをむやみに信頼するのではなく、グローバル ポリシーによってきめ細かなアクセス制御（FGAC）を適用し、CloudEvents 属性を検査することができます。

ソースの整合性の検証

サービスの侵害によるイベントのスプーフィングを防ぐため、バス管理者は、プロデューサー ID とソース属性の一致を求めます。

たとえば、プリンシパル sa-commerce@retail.com のみに、message.source.startsWith("//commerce/") という表記に一致するイベントのパブリッシュを許可するようにバスポリシーを設定できます。仮に Intelligence AI Insights Agent サービスが //commerce/payments からであると偽ってイベントをパブリッシュしようとすると、バスはこのリクエストを拒否します。

データ分類の検証

バス管理者は、すべてのイベントを機密性に基づいて分類できるようにするために、バスに送られるすべてのペイロードに有効な機密性属性を求めます。バスポリシーに、message.data_sensitivity が ['general', 'confidential', 'restricted'] のいずれかであるかどうかを検証するよう指定できます。これにより、イベントメッシュにはガバナンス対応の分類済みデータのみが確実に含まれるようになります。

パイプライン: ロジックレイヤと、自律的なチームのイノベーション

バスでセキュリティ ポスチャーを確立する一方で、開発チームはパイプラインを使用し、複雑なインテグレーションの課題を独自のドメイン内で解決できます。具体的にどんな課題があるのかを見てみましょう。

スキーマに対応した形式変換とペイロードの変換

物流部門は、高効率のプロトコル バッファを使って倉庫ロボットをアップグレードすることにしました。財務部門に JSON 出力の変更を強制すると、他のコンシューマーが壊れる可能性があるため、その代わりに、物流部門が独自のパイプラインを使って変換ステップを構成できます。

財務部門からの一般的な com.retail.payment.success イベントは、次のような JSON として届きます。

倉庫ロボット サービスは、次のようなバイナリの Protobuf メッセージを想定しています。

物流部門は、json を入力として受け付け、Protobuf に出力するようにパイプラインを構成します。データをマッピングするために、以下のように Common Expression Language（CEL） を使って変換を構成しています。

この変換では、入力のマッピングだけでなく、ビジネス ロジックも適用され、保険適用後の金額計算と通貨コードの正規化が行われています。物流部門は、財務部門と打ち合わせを一切することなく、このモダナイゼーションを実装できます。

エージェントのワークフロー: AI エージェントのフィルタとトリガー

Eventarc Advanced では、Agent2Agent（A2A）や Model Context Protocol（MCP）などのオープン スタンダード プロトコルを使って、パイプラインが AI エージェントと直接通信できるようにし、エージェントのワークフローを実現しています。また、フィルタなどの豊富な機能もあり、エージェントの呼び出しタイミングを最適化できます。

インテリジェンス部門は、ai-insights と名付けたパイプラインと A2A プロトコルを使用して AI インサイト エージェントに接続し、注文に基づいて市場動向をプロアクティブに分析してもらえます。エージェントの処理はリソースを大量に消費するため、フィルタを使用して、詳細な分析が必要な高額注文に対してのみエージェントを呼び出すことができます。

パイプライン フィルタを、次のように構成します。

フィルタが渡されると、パイプラインは HTTP Message Destination Binding（MDB）の構文を使ってエージェントを直接トリガーします。CEL テンプレートを定義することによって、ネイティブな A2A SendMessage リクエストを構築して戦略担当の AI インサイト エージェントに送るという複雑な処理をパイプラインで行えます。これにより、手動で「グルーコード」を作成することなく、複雑なイベントデータから派生した会話型プロンプトをエージェントに送信することができます。

MCP などの他の一般的なエージェント通信プロトコルでも、同様のプロンプト メッセージを作成できます。

フィルタとエージェント プロトコル変換を組み合わせることで、AI リソースを本当に必要な場面で有効利用することが可能となります。インテリジェンス部門は、取り込みコードを記述したり、コマース部門や管理部門と調整したりすることなく、独自にこれを実装できます。さらに、エージェントが独自の戦略的推奨事項をバスにパブリッシュし、AI の知見を適宜活用できるようにすることで、一般的なクラウド イベントが競争に役立つインテリジェンスへと生まれ変わります。

高度な API リクエスト モデリング

出荷の準備が整うと、物流部門はパイプラインからレガシーのゲートウェイ API を使って SMS を送信します。サードパーティのレガシー API と統合するためには、リクエストの書式設定のために、「グルーコード」サービスの記述が必要となるのが一般的です。

物流部門は、レガシー サービスが想定しているリクエストを正確に記述するために専用のパイプラインを構成することで、このメンテナンスの負担を解消しています。

具体的には、HTTP Message Destination Binding の CEL 構文を使って、電話番号を標準化し、API で必須の X-SMS-To HTTP ヘッダーにマッピングします。また、以下のように SMS テキストも作成します。

最後に、パイプラインに直接、堅牢な再試行ポリシー（線形バックオフ、最大 5 回の試行）を構成して、一時的なネットワーク中断によって通知が失われないようにします。このパイプラインは、確実な配信を実現するほか、すぐに使える認証を提供します。宛先として、HTTP エンドポイントのほか、Cloud Run、Pub/Sub、バス、ワークフローや、200 以上の Google サービスがサポートされています。

アジャイルなインテグレーションに向けた未来

Eventarc Advanced は、一元化ポリシー、分散型ロジックのパターンを導入することで、イベント ドリブン アーキテクチャにおける重要な盲点に対処し、非同期通信において同期通信と同レベルの成熟度を達成しています。

• プラットフォーム チームは、バスですべてのメッセージに整合性と機密性を厳格に適用することで、あたかもサービスメッシュのようなセキュリティをイベントレイヤに導入できます。

• 開発者は、自律性を取り戻せます。パイプラインを使って、特定のニーズに応じてイベントをフィルタ、変換、形式変換、ルーティングできるため、イベントを不透明なアーティファクトではなく、重要な産物として扱うことが可能となります。

このアーキテクチャは、次世代のインテリジェント アプリケーションの基盤となります。安全で定型化された、信頼できるイベント メッシュは、生成 AI エージェントおよびリアルタイム分析の基軸となり、ビジネス コンテキストを必要とするシステムに安全に公開することが可能となります。

使ってみる

ガバナンスに足を引っ張られることなく、イノベーションを促進しましょう。Eventarc Advanced の使用を開始するにあたっては、以下のリソースをご利用ください。

• 詳細: Eventarc Advanced のドキュメントで、バスとパイプラインの全機能をご確認ください。

• 実践: 「小売業のイベント メッシュ」のシナリオを自分でデプロイしてみましょう。また、クイックスタートとチュートリアルでエンタープライズのパターンについて理解を深められます。

• 構築してみる: Google Cloud コンソールを開き、初めてのバスとパイプラインをさっそく構成してみましょう。

• ご相談ください: 複雑なエンタープライズ ユースケースがおありですか？Google Cloud の営業担当者までお問い合わせください。Eventarc Advanced がお客様の広範なインテグレーション戦略にどのように役立つかについて、ご説明させていただきます。

- スタッフ ソフトウェア エンジニア、Milen Kovachev