--- title: "Eventarcとは？Google Cloudのイベントルーティングの仕組み・Standard/Advancedと料金、EventBridgeとの違いを実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/15748/" published: 2026-07-27 updated: 2026-09-27 categories: ["Google Cloud"] publisher: "株式会社一創" --- # Eventarcとは？Google Cloudのイベントルーティングの仕組み・Standard/Advancedと料金、EventBridgeとの違いを実装者目線で解説 Eventarcは、Google Cloud上で発生した状態変化（イベント）を、それに反応するサービスへ非同期に送り届けるフルマネージドなイベントルーティングサービスです。この記事では、プロバイダを問わずイベントをCloudEvents形式に揃えて配送する仕組み、フィルタを持つトリガー、Cloud Audit Logs・直接ソース・Pub/Sub・サードパーティという4系統のイベントソース、Cloud RunやCloud Functions・GKE・Workflowsという宛先、配送を裏で担うPub/Subのtransport層、そしてStandardとAdvancedという2つのエディションの違いと料金までを一次情報で整理します。時刻駆動のCloud Schedulerや点対点のCloud Tasks、AWSのEventBridgeとの違い、Eventarcを採用すべき条件と見送るべき場面の判断基準まで、イベント駆動の設計で実装者が迷う論点を具体的に示していきます。 ## まとめ：Eventarcの仕組みと採用判断の要点 Eventarcは、Google Cloudの各サービスやPub/Sub、外部システムで起きたイベントを受け取り、CloudEvents形式に揃えたうえで、指定した宛先へHTTPで送り届けるサービスです。イベントの発生源（プロバイダ）と処理する側（宛先）を直接つながず、間にEventarcを挟むことで、送り手と受け手を疎結合に保てるのが土台になります。宛先にはCloud Run、Cloud Functions（Cloud Run functions）、GKE、Workflowsなどを選べ、Googleソースからのイベントは内部でPub/Subを通って届く構造です。 エディションはStandardとAdvancedの2つで、単一のプロバイダから宛先へ素直に配送するならStandard、中央のメッセージバスに集約して変換やファンアウト、多チームでの共有まで扱うならAdvanced、という切り分けになります。用途としては、ファイルがアップロードされたら処理を起動する、監査ログの特定操作を検知して後続を走らせる、Pub/Subのメッセージを実行基盤へ橋渡しする、といったイベント駆動の連携が噛み合います。決まった時刻に起動したいならCloud Scheduler、随時湧く大量タスクを配信したいならCloud Tasks、状態変化に反応させたいならEventarc、という役割分担で考えるのが要点です。迷う実装者は、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめて選定してください。 ## Eventarcの仕組みとイベントソース・宛先を結ぶ基本モデル Eventarcを設計へ落とし込むには、まず「どこで起きたイベントを、どんな条件で拾い、どの宛先へ届けるか」という3点を、トリガーという単位で結び付ける骨格を押さえます。ここが曖昧だと、時刻で起動するスケジューラや点対点のキューとの役割を混同し、イベント駆動の連携を誤った基盤に寄せかねません。 ### CloudEvents形式とトリガーによるルーティングの考え方 Eventarcの中心にあるのがトリガーという単位です。1つのトリガーは、どのイベントを拾うかを決めるフィルタと、どこへ届けるかを示す宛先を結び付けます。フィルタでは、たとえばCloud Audit Logsのイベントなら、どのサービス（serviceName）のどの操作（methodName）に反応するかを指定する形です。拾われたイベントは、発生源がどのプロバイダであっても業界標準のCloudEvents形式に揃えられ、HTTPリクエストのバイナリコンテンツモードで宛先へ渡されます。この「形式をそろえて配る」性質により、受け取る側はソースごとに実装を作り分けず、同じ流儀でイベントを処理できるのが持ち味です。ペイロードの符号化はプロバイダに応じてJSONまたはProtocol Buffersが使われます。 ### Cloud Audit Logs・直接ソース・Pub/Sub・サードパーティの4系統 拾えるイベントの発生源は、大きく4系統に分かれます。1つ目はCloud Audit Logsで、Google Cloudの各サービスが監査ログへ書き込む管理操作やデータアクセスのイベントを、130を超えるサービスから拾えるのが特徴です。2つ目は直接ソースで、Cloud Storageのバケット更新のように、サービスが直接送り出すイベントを受け取ります。3つ目はPub/Subで、トピックへ発行されたメッセージをそのままイベントとして扱い、既存のメッセージング基盤とつなげられます。4つ目はサードパーティで、チャネル経由で外部プロバイダのイベントを取り込む形です。この4系統を押さえると、「Google Cloud内の出来事を拾う」のか「自前のメッセージを流し込む」のかで入口を選び分けられます。イベントを流すバックボーンには[Cloud Pub/Sub（メッセージング基盤）](https://www.issoh.co.jp/tech/details/12385/)が使われ、GoogleソースのイベントもこのPub/Subをtransport層として宛先へ届きます。 ### Cloud Run・Cloud Functions・GKE・Workflowsという宛先 拾ったイベントを届ける宛先には、複数の実行基盤を選べます。代表格は、コンテナをそのまま動かす[Cloud Run（サーバーレスコンテナ実行基盤）](https://www.issoh.co.jp/tech/details/15435/)と、関数単位で処理を載せる[Cloud Functions（Cloud Run functions）](https://www.issoh.co.jp/tech/details/15538/)です。Cloud Functionsのイベント駆動関数は、その裏側でEventarcのトリガーを使って起動される作りになっています。ほかにも、Kubernetes上のサービスへ届けるGKE（Workload Identity Federationの構成が前提）、複数ステップを連結して実行するWorkflows、VPC内の内部HTTPエンドポイントを宛先にできます。イベントの発生をEventarcが検知し、実処理は宛先のCloud RunやCloud Functionsが担う、という分業が設計の勘所です。届いたイベントは通常のHTTPリクエストとして受け取れるため、受信側はWebのハンドラを書く感覚で処理を実装できます。 ## EventarcのStandardとAdvancedという2エディションの違い 次に押さえるのが、同じEventarcでも性格の異なるStandardとAdvancedの2エディションです。この違いの理解が、シンプルな連携で済ませるか、中央集約した基盤へ育てるかの分かれ道になります。 ### Standardのトリガーモデルと素直な1対1のイベント配送 Standardは、フィルタ付きのトリガーを定義してGoogleのイベントを手早く受け取るトリガーモデルです。1つのプロバイダから1つの宛先へ配送する素直な構造で、イベント種別や特定の属性でのフィルタに対応します。裏側ではPub/Subがtransport層として働き、必要なトピックはEventarcが自動で作成・管理する形も取れる仕組みです。最大イベントサイズは512KiBで、64KiBを超えるイベントは複数イベントとして数えられます。トリガーは地域（リージョン）またはグローバルで作れ、イベントを生成するサービスの所在に合わせてトリガーの場所を指定するのが基本です。まずは「このバケットの更新をこの関数に届ける」といった1対1の連携から始めるなら、Standardが素直な入口になります。 ### Advancedのメッセージバス・pipeline・イベント変換 Advancedは、システムで起きたイベントを中央のメッセージバスへ集約する発想です。プロジェクトのリージョンごとにバスを1つ持ち、購読側はenrollmentでバス上の特定メッセージを受け取り、pipeline（リージョンあたり最大100）を通じて宛先へ配ります。Standardと違い、CEL式によるイベントの変換、あらゆるイベント属性でのフィルタ、多対多のファンアウト、Publishing APIを使ったカスタムイベントの発行、プロジェクトをまたいだ配信にも対応できる点が持ち味です。最大イベントサイズは1MiBで、16KiBを超えると複数として計数されます。複数チームがそれぞれのサービスからイベントを流し込み、中央で可視化・変換・振り分けまで面倒を見たい、という規模で効いてくるのがAdvancedです。ユースケースが複雑化した際に、StandardからAdvancedへ段階的に移る道筋も用意されています。 ### StandardとAdvancedのどちらを選ぶべきかの目安 選び分けの目安はシンプルです。イベントをプロバイダから宛先へ届けられれば十分、という単純な連携ならStandardが軽くて済みます。一方で、中央集約した可視性、複数チームでの共有、イベントの変換、多数のメッセージング経路の一元管理まで要るならAdvancedが向くでしょう。判断の軸は、扱うプロバイダと宛先が1対1で足りるか多対多になるか、イベントを途中で加工したいか、チームをまたいで共有したいか、の3点に集約できます。小さく始めて必要になってからAdvancedへ移行できるため、初手はStandardで疎通と運用感をつかみ、複雑さが増した段階でAdvancedを検討する進め方が現実的でしょう。 ## Eventarcの料金モデルとEventBridge・Schedulerとの違い 基盤選定の決め手になるのが、料金の積み上がり方と、混同されやすい他サービスとの役割の差です。AWSのEventBridge、時刻駆動のCloud Scheduler、点対点のCloud Tasksとの境目を条件で切り分けます。 ### StandardとAdvancedそれぞれの料金の積み上がり方 料金はエディションで構造が異なります。2026年7月時点の公式では、Standardは月あたり5万イベントまで無料で、Googleソースおよびイベント経由のPub/Subソース由来は100万イベントあたり0ドル、その他のソースは100万イベントあたり1ドル（Preview中は無料）という体系です。これに加えて、配送を担うtransport層のPub/Subは通常のPub/Sub料金で課金されるため、Eventarc単体の見かけ以上に、Pub/Subのデータ量やCloud Audit Logs・受信側のCloud Runなどの費用も合算で見積もる必要があります。Advancedはバスへの発行が100万メッセージあたり1.00ドル、pipelineが100万あたり0.50ドル、変換が100万オペレーションあたり0.40ドルで、無料枠の明記はありません。いずれも単価や無料枠は公式ドキュメントで対象時点を確認し、想定イベント量を掛け合わせて試算してください。 ### AWSのAmazon EventBridgeとの違いと共通点の整理 AWSで同種のことをするなら、[Amazon EventBridge（AWSのイベント駆動連携サービス）](https://www.issoh.co.jp/tech/details/15513/)が対応します。EventBridgeもイベントバスとルールでイベントを振り分け、Lambdaなどの宛先へ届ける発想は共通です。大枠の考え方は近い一方で、拾えるソースの種類、宛先にできるサービス群、イベント形式（Eventarcは業界標準のCloudEvents、EventBridgeは独自のイベント構造）、料金体系は各クラウドで異なります。マルチクラウドやAWS側での実装を並行検討するなら、この対応関係を押さえたうえで、それぞれの一次情報で細部を確認するのが安全です。片方の設計をそのまま持ち込むと、フィルタの書き方や配信保証の前提でつまずきやすい点に注意してください。 ### Cloud Scheduler・Cloud Tasksとの役割の違い Eventarcと混同されやすいのが、時刻駆動の[Cloud Scheduler（フルマネージドcron）](https://www.issoh.co.jp/tech/details/15746/)と、点対点の[Cloud Tasks（非同期タスクキュー）](https://www.issoh.co.jp/tech/details/15744/)です。Cloud Schedulerは「決まった時刻・間隔で起動する」スケジュール駆動、Cloud Tasksは「随時発生する個別タスクをレートを絞って配信する」点対点のキュー、そしてEventarcは「状態変化に反応して届ける」イベント駆動という違いになります。駆動のきっかけが時刻か、明示的なタスク投入か、イベントの発生か、で選ぶのが軸です。これらは競合ではなく組み合わせても機能し、Cloud Schedulerで定時にPub/Subへ発行し、そのメッセージをEventarcが拾って宛先へ配る、といった構成も取れます。 ## Eventarcを採用すべき条件と見送るべき場面を分ける判断基準 ここでは判断を言い切ります。Eventarcはイベント駆動の連携を疎結合に組むことに強い反面、あらゆる処理起動の受け皿ではありません。自社システムの連携をどの基盤へ寄せるかを、条件付きで見極めてください。 ### Eventarcの採用が効くワークロードと要件の具体的な見極め 採用が効くのは、何かの状態変化をきっかけに後続処理を走らせたい、そのために送り手と受け手を密結合にしたくない、という条件が重なるときです。具体例は、Cloud Storageへのファイルアップロードを起点にした変換・取り込み、監査ログの特定操作を検知したセキュリティ通知、Pub/Subメッセージを実行基盤へ橋渡しする連携、複数サービスの出来事を宛先へ配る非同期パイプラインなどが当てはまります。処理の実体はCloud RunやCloud Functionsに置き、その起動のきっかけだけをEventarcに任せる構成が噛み合います。こうしたGoogle Cloud上のイベント駆動アーキテクチャを自社に取り入れるなら、[AWS・Google Cloudを含むクラウドインフラ構築の相談窓口](https://www.issoh.co.jp/service/system/aws/)で、イベントソースの選定やトリガー設計、宛先の切り分けの妥当性を相談するとよいでしょう。 ### Eventarcが向かない要件と代替の他サービスへ寄せる場面 決まった時刻や一定間隔で処理を起動したいだけなら、イベント駆動のEventarcより時刻駆動のCloud Schedulerが素直です。また、リクエストごとに随時湧く大量の後処理を、配信レートを絞りながら1件ずつ届けたい要件は、点対点のCloud Tasksへ寄せるのが噛み合います。複数のサービス呼び出しを順序立てて連結し、分岐や待ち合わせを含む一連の処理として組みたいなら、Eventarcで単発のイベントを配るよりWorkflowsのオーケストレーションが向きます。イベントの発生に反応させたいのか、時刻で起動したいのか、明示的にタスクを投げたいのか、多段のフローを制御したいのかを軸に選定してください。なお、受け取る側はイベントが再送される可能性を前提に、同じイベントが二度届いても壊れないよう冪等に実装しておくのが安定運用の勘所です。 ### トリガー作成から宛先でのイベント受信までの実装フローの全体像 実装面では、まずどのイベントソースを使うかを決め、フィルタと宛先を指定したトリガーを作成する流れが基本です。Cloud Audit Logsのイベントなら反応するサービスと操作を、直接ソースならイベント種別を、Pub/Subならトピックを指定します。宛先にCloud RunやCloud Functionsを選ぶと、定義した条件のイベントが起きたときに、EventarcがCloudEvents形式でその宛先へHTTPリクエストを送ります。受け取る側は通常のHTTPハンドラとして実装し、200系の応答を返せば受信完了です。GKEを宛先にする場合はWorkload Identity Federationの構成が前提になり、Advancedを使う場合はバスとenrollment・pipelineの設計が加わります。作成後は、実際にイベントを発生させて疎通を確かめ、ログで配送の成否を追える状態にしてから本番の連携へ広げると、想定外の未達や多重配送に早く気付けるでしょう。 ## よくある質問 Eventarcの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。 ### EventarcとPub/Subはどう違い、どう関係しますか？ Pub/Subはメッセージを発行・購読するメッセージング基盤そのもので、Eventarcはそのうえでイベントを拾い、CloudEvents形式に揃えて宛先へルーティングするサービスです。GoogleソースのイベントはEventarcの内部でPub/Subをtransport層として使って配送されます。生のメッセージを自分で組み立てて流したいならPub/Sub、Google Cloudの出来事を条件でフィルタして実行基盤へ届けたいならEventarc、という関係で捉えると整理できます。 ### EventarcのStandardとAdvancedはどちらを選ぶべきですか？ 1つのプロバイダから1つの宛先へ素直に配送できれば十分ならStandard、中央のメッセージバスへ集約して変換・多対多のファンアウト・複数チーム共有まで扱うならAdvancedです。まずStandardで疎通と運用感をつかみ、複雑さが増した段階でAdvancedへ移行する進め方が現実的で、公式もStandardからAdvancedへ段階的に移る道筋を用意しています。 ### Eventarcはどんな宛先へイベントを届けられますか？ Cloud Run、Cloud Functions（Cloud Run functions）、GKE、Workflows、VPC内の内部HTTPエンドポイントが宛先になります。Cloud Functionsのイベント駆動関数は、内部でEventarcのトリガーを使って起動される仕組みです。宛先はイベントをHTTPリクエストとして受け取るため、受信側は通常のWebハンドラの感覚で処理を実装できます。 ### EventarcとCloud Scheduler・Cloud Tasksはどう使い分けますか？ 状態変化に反応させたいならEventarc、決まった時刻や間隔で起動したいならCloud Scheduler、随時発生する個別タスクをレートを絞って配信したいならCloud Tasksが基本の分岐です。駆動のきっかけがイベントか時刻か明示的なタスク投入かで選びます。3つは併用でき、Schedulerで定時にPub/Subへ発行し、それをEventarcが拾って宛先へ配る構成も取れます。 ### Eventarcの料金はどのように決まりますか？ 2026年7月時点では、Standardが月5万イベントまで無料で、Google/Pub/Sub由来は100万イベントあたり0ドル、その他ソースは100万あたり1ドルが目安です。加えて配送を担うPub/Sub transportは通常のPub/Sub料金で課金されます。Advancedはバス発行が100万メッセージあたり1.00ドル、pipelineが0.50ドル、変換が0.40ドルで無料枠の明記はありません。単価は公式で対象時点を確認し、想定イベント量から試算してください。 ## 関連記事 - [Cloud Pub/Subの基本概念とメッセージング基盤としての役割](https://www.issoh.co.jp/tech/details/12385/)：Eventarcが配送に使うtransport層のメッセージング基盤を解説した記事 - [Cloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違いを実装者目線で解説](https://www.issoh.co.jp/tech/details/15435/)：Eventarcの主要な宛先になるサーバーレスコンテナ実行基盤を解説した記事 - [Google Cloud Functionsとは？仕組み・料金とCloud Run functionsへの改称・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15538/)：イベント駆動関数の宛先で、内部にEventarcトリガーを使う関数型基盤を解説した記事 - [Cloud Schedulerとは？GCPのフルマネージドcronの仕組み・3つのターゲットとリトライ・料金、Cloud Tasksとの違いを実装者目線で解説](https://www.issoh.co.jp/tech/details/15746/)：Eventarcと使い分ける時刻駆動のスケジューラを解説した記事 - [Amazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断を解説](https://www.issoh.co.jp/tech/details/15513/)：AWS側でEventarcに対応するイベント駆動連携サービスを解説した記事 --- 出典: [Eventarcとは？Google Cloudのイベントルーティングの仕組み・Standard/Advancedと料金、EventBridgeとの違いを実装者目線で解説]()（株式会社一創）