変更要約: AZ-305 第4章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
4.2アプリ統合とメッセージングの設計
疎結合な統合——Service Bus／Event Grid／Event Hubs、API Management、Logic Apps、Azure Cache for Redis——を理解します。コンポーネントを分離しスケーラブルに連携します。
スケーラブルな設計は疎結合から。用途に応じて Service Bus・Event Grid・Event Hubs を使い分けます。
4.2.1メッセージングと統合
- Service Bus：エンタープライズメッセージング（キュー/トピック・順序/トランザクション/デッドレター）。
- Event Grid：イベントのリアクティブ配信（pub/sub・状態変化通知）。
- Event Hubs：大量のストリーミング取り込み（テレメトリ/ビッグデータ）。
- API Management/Logic Apps/Redis：API ゲートウェイ／ノーコード統合／低遅延キャッシュ。
「順序/トランザクションのエンタープライズメッセージング＝Service Bus」「状態変化のイベント通知＝Event Grid」「大量テレメトリのストリーム＝Event Hubs」「API の公開ゲートウェイ＝API Management」「ノーコードのワークフロー＝Logic Apps」 は AZ-305 で頻出です。3 つのメッセージングの使い分けが要点です。
「確実に順序通り処理したい業務メッセージ＝Service Bus」「IoT/ログを毎秒大量に取り込む＝Event Hubs」「リソースの状態変化に反応＝Event Grid」と覚えると選びやすいです。
AZ-305 の統合設計は「メッセージ／イベント／ストリームの違いを見極め、適切なサービスで疎結合にする」ことを問います。Service Bus はメッセージ指向のエンタープライズ基盤で、キュー（1 対 1）とトピック/サブスクリプション（pub/sub）を持ち、FIFO（セッション）・重複検出・トランザクション・デッドレターキュー・スケジュール配信など信頼性機能が豊富——注文処理や決済など「確実に・順序通り・失われず」処理したい業務メッセージに使います。Event Grid はイベント（「何かが起きた」という軽量な状態変化通知）のリアクティブ配信で、Azure リソースのイベントや独自トピックを Functions/Logic Apps/Webhook へ pub/sub し、ほぼリアルタイムでサーバーレスに反応させます。Event Hubs はストリーム（テレメトリ/ログ/IoT）の大量取り込みに特化し、パーティションとコンシューマーグループで高スループットを捌き、Kafka 互換、キャプチャで Blob/Data Lake へ落とせます。これらの前段や統合として、API Management（公開 API のゲートウェイ＝認証/レート制限/バージョニング/変換/開発者ポータル）、Logic Apps（多数のコネクタを使うノーコードのワークフロー統合）、Azure Cache for Redis（低遅延キャッシュ・セッション/レート制限ストア）を組み合わせます。設計の要は、「1 件ずつ確実に＝Service Bus」「状態変化に反応＝Event Grid」「秒間大量のストリーム＝Event Hubs」の軸でメッセージング 3 種を選び分け、疎結合でスケーラブルにすることです。
| 種別 | サービス | 代表ユースケース |
|---|---|---|
| メッセージ（業務） | Service Bus | 注文/決済・順序/トランザクション/DLQ |
| イベント（状態変化） | Event Grid | リソース変化に反応・pub/sub |
| ストリーム（大量） | Event Hubs | IoT/ログのテレメトリ取り込み |
| API 公開/統合 | API Management / Logic Apps | ゲートウェイ / ノーコード連携 |
シナリオ：EC サイトで、(1) 注文を確実に順序通り処理し、(2) 在庫が変化したら関連サービスに通知し、(3) 全ユーザーのクリックストリームを大量に分析したい。→ (1) は Service Bus（キュー＋セッションで順序保証、DLQ で失敗救済）、(2) は Event Grid（在庫変更イベントを pub/sub で複数購読者へ）、(3) は Event Hubs（毎秒大量のクリックを取り込み、キャプチャで Data Lake へ）。公開 API は API Management をゲートウェイにします。
FAQ：Service Bus と Event Grid と Event Hubs の決め手は？ 「1 件ずつ確実に・順序やトランザクションが要る業務メッセージ」なら Service Bus。「何かが起きた、に軽量に反応（リソース/カスタムイベントの pub/sub）」なら Event Grid。「秒間数百万級のテレメトリ/ログを取り込んで後で分析」なら Event Hubs。メッセージ/イベント/ストリームのどれかを問題文から見極めます。
ひっかけ：「順序保証やトランザクションが要る業務メッセージ」に Event Hubs を選ぶのは誤り——Event Hubs は大量ストリーム取り込み向けで、業務メッセージの信頼性機能（セッション順序/DLQ/トランザクション）は Service Bus が担います。また「リソースの状態変化にサーバーレスで反応」を Service Bus でやろうとするのも非効率で、Event Grid が適します。
4.2.2この節のまとめ
- メッセージング＝Service Bus（業務）/Event Grid（イベント）/Event Hubs（ストリーム）
- 統合＝API Management／Logic Apps／Redis
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 注文処理など、順序保証やトランザクション、デッドレターが必要な業務メッセージングを設計したい。何を使いますか?
Q2. 何百万デバイスからのテレメトリを毎秒大量にストリーミング取り込みしたい。何を使いますか?
Q3. 外部に公開する複数の API に、認証・スロットリング・バージョニングを一元的に適用したい。何を使いますか?