API・メッセージング

イベントバスいべんとばす

イベント駆動アーキテクチャPub/Subメッセージング非同期通信マイクロサービスデカップリング

イベントバスについて教えて

簡単に言うとこんな感じ！

イベントバスは「社内の放送設備」みたいなものだよ！「注文が入ったよ！」ってアナウンスしたら、在庫管理も配送管理も請求管理も、それぞれ自分に関係あると思ったら勝手に動いてくれる仕組みなんだ。送る側は誰が聞いてるか知らなくていいから、システム同士がゆるくつながれるってこと！

イベントバスとは

イベントバス（Event Bus） とは、システム内の複数のコンポーネントやサービスが「イベント（出来事）」をやり取りするための共有の通信路（バス）です。送信側（パブリッシャー）がイベントをバスに流すと、そのイベントに興味を持つ受信側（サブスクライバー）が自動的に受け取って処理します。送る側と受け取る側は互いを直接知らなくてよいため、疎結合（でかっぷりんぐ）—つまり「部品同士がゆるくつながっている状態」—を実現できます。

現代のWebアプリやクラウドシステムでは、注文・決済・通知・在庫など多くの処理が連携して動きます。それぞれが直接呼び合うと、一か所が壊れたときに全体が止まったり、変更のたびに多くの箇所を修正する必要が出てきます。イベントバスはこの問題を解決する「交通整理の仕組み」として、特にマイクロサービスアーキテクチャ（小さなサービスを組み合わせてシステムを作る設計方式）で広く採用されています。

クラウド時代には Amazon EventBridge・Google Pub/Sub・Azure Event Grid などのマネージドサービスとして提供されており、自前で構築しなくても手軽に利用できる環境が整っています。

イベントバスの構造と仕組み

イベントバスは「誰が出来事を知らせるか」「どんな出来事か」「誰が反応するか」という3つの役割で成り立っています。

役割	別名	説明	例
パブリッシャー	送信側・プロデューサー	イベントをバスに流す	注文サービスが「注文完了」を通知
イベントバス	ブローカー・バス本体	イベントを受け取り・配送する中継役	Amazon EventBridge など
サブスクライバー	受信側・コンシューマー	関心のあるイベントを受け取る	在庫サービス・配送サービス・請求サービス

イベントの流れ（シーケンス）

[注文サービス]
     |
     | ① 「注文完了」イベントを発行
     ▼
[イベントバス]
     |           |           |
     | ②配送     | ②在庫     | ②請求
     ▼           ▼           ▼
[配送サービス] [在庫サービス] [請求サービス]

イベントの構造（典型的なJSONの例）

{
  "eventType": "order.completed",
  "eventId": "evt-00123",
  "timestamp": "2026-04-09T10:30:00Z",
  "source": "order-service",
  "data": {
    "orderId": "ORD-9876",
    "customerId": "USR-001",
    "amount": 4800
  }
}

ポイント：「バス」という名前の由来

コンピューターの「バス（Bus）」はもともとCPUとメモリをつなぐ電気的な共有回路のこと。「みんなが同じ路線を使う」という意味で、イベントバスも同じ発想です。「路線バスに乗りたい人だけ乗る」イメージで覚えると◎！

歴史と背景

1990年代〜2000年代初頭：エンタープライズシステムで「メッセージキュー」（IBM MQ など）が普及し始める。サービス間の非同期通信の原型が生まれる
2003年：ESB（Enterprise Service Bus）という概念が登場。大企業のシステム統合手段として流行するが、中央集権的で複雑になりやすいという課題も
2010年代前半：Apache Kafka（2011年）・RabbitMQ などのオープンソースが台頭。スケールしやすい軽量なメッセージングが普及
2014〜2016年頃：マイクロサービスアーキテクチャの流行とともに「イベント駆動設計」が注目を集める。ESBの反省から「シンプルなバス＋賢いエンドポイント」という思想が広がる
2019年：Amazon EventBridge リリース。SaaSとのイベント連携もマネージドで実現できる時代に
2020年代〜：イベントソーシング・CQRS などの設計パターンと組み合わせた高度なアーキテクチャが標準的な選択肢になる

イベントバスと関連技術の比較

メッセージング方式の違い

方式	主な特徴	向いているケース
イベントバス	多対多・非同期・疎結合	マイクロサービス間連携・複数サービスへの通知
メッセージキュー	1対1・順序保証・確実な配送	バックエンド処理の分散・ジョブ管理
REST API（同期）	1対1・即時応答が必要	UI←→バックエンドのリアルタイムな問い合わせ
gRPC	1対1・高速・型安全	サービス間の高頻度・高性能通信

代表的なイベントバスサービスの比較

サービス名	提供	特徴
Amazon EventBridge	AWS	SaaS連携・ルーティングが豊富
Google Cloud Pub/Sub	GCP	大規模ストリーミングに強い
Azure Event Grid	Azure	Azureサービスとの統合が容易
Apache Kafka	OSS	超高スループット・ログ保持に強い
RabbitMQ	OSS	軽量・多様なプロトコル対応

規格・RFC番号	内容
RFC 3903	SIP イベント通知フレームワーク（Publish）の仕様
RFC 5989	SIPにおける新しいイベントパッケージ登録の方法論
AsyncAPI 3.0	非同期APIの記述仕様（イベント駆動設計の標準記法）
CloudEvents v1.0	CNCF策定のイベントデータフォーマット標準仕様