Cloud Service
メッセージング
Service Bus / Queue Storage / Event Grid / Event Hubs の使い分けを一枚で。疎結合キュー・イベント配信・ストリームの違いを即断。
基礎
最終更新: 2026-06-04
ひと目で使い分け
| やりたいこと | 選ぶもの |
|---|---|
| バッファして1対1で確実に処理（順序・トランザクション） | Service Bus（キュー） |
| とにかく安く単純なキューが欲しい | Queue Storage |
| 1イベントを複数へプッシュ配信（ファンアウト） | Service Bus（トピック/サブスク） |
| 状態変化イベントの配信・内容で振り分け・SaaS/Azure連携 | Event Grid |
| 毎秒大量のログ/テレメトリを取り込み・再読み込み・分析 | Event Hubs |
詳細比較
| 観点 | Service Bus | Queue Storage | Event Grid | Event Hubs |
|---|---|---|---|---|
| モデル | キュー/トピック(Pub/Sub) | シンプルキュー | イベントルーティング(Pub/Sub) | ストリーム(取り込み) |
| 配信方式 | プル(ロングポーリング) | プル(ポーリング) | プッシュ(Webhook等) | プル(パーティション読取) |
| 順序 | セッションで保証(FIFO) | ベストエフォート | 保証なし | パーティション内で保証 |
| 再読み込み | 不可(完了で削除) | 不可(削除で消える) | 不可 | 可(保持期間内に再読取) |
| スループット規模 | 高(エンタープライズ) | 中(〜数百万メッセージ) | 高(イベント単位) | 超高(毎秒数百万件) |
| 代表用途 | 業務処理の疎結合/順序保証 | 安価な簡易バッファ | イベント駆動の通知/連携 | ログ/IoT/分析の取り込み |
キューは2系統：Service Bus か Queue Storage か
| 観点 | Service Bus キュー | Queue Storage |
|---|---|---|
| 位置づけ | 高機能なエンタープライズ messaging | Storage アカウント付属の簡易キュー |
| メッセージサイズ | 標準256KB / Premium 100MB | 最大64KB |
| 順序(FIFO)・重複排除 | セッション/重複検出で対応 | 非対応 |
| トピック/サブスク・トランザクション | 対応 | 非対応 |
| デッドレター | あり | なし(自前実装) |
| コスト/向き | やや高め・業務要件が厳しい時 | 非常に安価・大量で要件が緩い時 |
迷ったらこの順で考える
- 状態変化を「○○が起きた」と多数の購読者へ知らせたい → Event Grid（リアクティブなイベント配信）
- 送信側と処理側を切り離し、順序・トランザクション・デッドレターが要る → Service Bus
- とにかく安く単純なキューでバッファするだけ → Queue Storage
- 同じメッセージを複数の処理系へ確実に配りたい（ファンアウト） → Service Bus トピック＋複数サブスクリプション
- 毎秒大量のイベントを取り込み、複数コンシューマで再生・分析したい → Event Hubs
Event Grid と Service Bus トピックの違い
どちらも 1 対多ですが役割が違います。
- Event Grid＝「何かが起きた」という軽量イベントをプッシュで広く配信（HTTP/Webhook、Azure リソースの状態変化、SaaS 連携）。AWS の EventBridge/SNS に近い。
- Service Bus トピック＝アプリ間のコマンド/業務メッセージをプルで確実に渡す（順序・重複排除・デッドレター）。AWS の SNS→SQS ファンアウトに近い。
Event Hubs は「キュー」ではなく「ストリーム」
Event Hubs は取り込んだイベントを保持期間中はパーティションに残し、各コンシューマが**オフセット（チェックポイント）**を持って好きな位置から読みます。消費しても消えないため、リアルタイム処理とバッチ再処理を併存できます（AWS の Kinesis に相当）。Kafka プロトコル互換のエンドポイントも提供。
よくある取り違え
- 「大量ログのリアルタイム取り込み」を Service Bus で受けるのは不向き。スループット重視なら Event Hubs。
- 「Azure リソースの作成/削除をトリガーに処理」したいなら Event Grid（Blob 作成イベントなどがネイティブ対応）。
- Queue Storage には順序保証・トピック・デッドレターが無い。要件が出たら Service Bus へ。
アンチパターン
接続文字列（SAS キー）をアプリにハードコードしないこと。Microsoft Entra ID + マネージド ID で認証し、キーは Key Vault で管理する。Event Grid/Service Bus/Event Hubs いずれも Entra ID 認証に対応しています。
AWS との対応
| 役割 | Azure | AWS |
|---|---|---|
| 疎結合キュー(高機能) | Service Bus | SQS |
| 簡易キュー | Queue Storage | SQS(標準) |
| ファンアウト/同報 | Service Bus トピック | SNS |
| イベントルーティング | Event Grid | EventBridge / SNS |
| ストリーム取り込み | Event Hubs | Kinesis |
Azure Service
メッセージングを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
cheatsheets
比較で見る軸
クラウド: Azure / カテゴリ: cheatsheets / 難易度: basic
導入後に効く点
導入後の運用手順、権限、監視、更新方法まで含めて評価します。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
数字・仕様の読み方
- クラウド
- Azure
- カテゴリ
- cheatsheets
- 難易度
- basic
- 関連資格
- —
- 設計柱
- —
判断チェックリスト
- 自社の用途が「cheatsheets」に近いか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
次に確認する観点
cheatsheets