変更要約: 各節に図（figure）を追加＝cert-figure-retrofit。AI-200 第3章を新規作成（メッセージング＝メッセージ(コマンド)vsイベント(通知)、Service Bus キュー/トピック・デッドレター、Event Grid、イベント駆動 AI パイプライン＝イベント→関数/コンテナ→AI サービス、回復性＝再試行/冪等性/デッドレター、各段の独立スケール）
3.1メッセージングによる非同期・疎結合
AI バックエンドを疎結合・回復性のある形でつなぐメッセージング——Azure Service Bus（キュー／トピック）と Azure Event Grid——の役割と使い分けを、開発者の視点で理解します。
AI パイプライン（取り込み→埋め込み生成→インデックス化→通知 など）は、各処理を直接呼び合うと、片方の障害や負荷が全体に波及します。これを避けるのが メッセージング による非同期・疎結合化です。送信側はメッセージを送って即座に解放され、受信側は自分のペースで処理します。これにより、負荷の平準化（バッファ）、障害時の再試行、スケールの独立が得られます。
3.1.1メッセージ（コマンド）とイベント（通知）
大きく2種類あります。メッセージ（message）は「この処理をして」という送信側の意図（コマンド）を、特定の受信側に確実に届けて処理してほしいもの。イベント（event）は「何かが起きた」という事実の通知で、関心のある任意の購読者に軽量に配信します。前者の代表が Azure Service Bus、後者の代表が Azure Event Grid です。
3.1.2Service Bus：キューとトピック
- キュー（queue）：1対1。1つのメッセージを1つの受信側が取り出して処理（ワーカー分散）。
- トピック／サブスクリプション：1対多。1つのメッセージを複数の購読者がそれぞれ受け取る（ファンアウト）。
- 配信保証・順序・デッドレター：確実な配信、順序、処理失敗メッセージの隔離（dead-letter）など業務向けの信頼性機能。
頻出：
①「コマンドを確実に届けて処理（信頼性・順序・デッドレター）」＝Azure Service Bus。
②「何かが起きた事実を軽量に多数へ通知」＝Azure Event Grid。
③Service Bus のキュー＝1対1、トピック/サブスクリプション＝1対多（ファンアウト）。
④メッセージングで非同期・疎結合・回復性を得る。
混同・注意：
①メッセージ（コマンド・確実に処理）とイベント（通知・軽量配信）を取り違えない＝Service Bus と Event Grid の選択。
②キュー（1対1）とトピック（1対多）を区別。
③メッセージングは非同期——即時の同期応答が要る場面とは異なる。
④デッドレターは「捨てる」ではなく失敗メッセージの隔離・後処理。
3.1.3この節のまとめ
- メッセージングで非同期・疎結合・回復性（負荷平準化・再試行・独立スケール）
- Service Bus＝コマンドを確実に処理（キュー=1対1／トピック=1対多）／Event Grid＝イベント通知を軽量配信
- 信頼性機能：配信保証・順序・デッドレター（失敗メッセージの隔離）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. コマンド（この処理をして）を特定の受信側に確実に届けて処理させ、順序やデッドレターなどの信頼性機能を備えるサービスはどれですか？
Q2. 「何かが起きた」という事実を、関心のある多数の購読者へ軽量に通知（配信）するのに適した Azure サービスはどれですか？
Q3. Service Bus で1つのメッセージを複数の購読者がそれぞれ受け取る（ファンアウト）のに使うのはどれですか？
Q4. AI パイプラインをメッセージングで疎結合にする主な利点はどれですか？
Q5. 処理に失敗したメッセージを隔離して後で調査・再処理できるようにする仕組みはどれですか？