変更要約: 各節に図（figure）を追加＝cert-figure-retrofit。AI-200 第3章を新規作成（メッセージング＝メッセージ(コマンド)vsイベント(通知)、Service Bus キュー/トピック・デッドレター、Event Grid、イベント駆動 AI パイプライン＝イベント→関数/コンテナ→AI サービス、回復性＝再試行/冪等性/デッドレター、各段の独立スケール）
3.2イベント駆動 AI パイプラインと AI サービス統合
メッセージング・関数・コンテナを組み合わせてイベント駆動の AI パイプラインを構築し、Azure OpenAI / Azure AI services を疎結合に統合する設計と、回復性（再試行・冪等性）の考え方を理解します。
前節の部品を組み合わせると イベント駆動 AI パイプライン ができます。典型例：文書がストレージに到着→イベント（Event Grid）が発火→関数/コンテナが起動して埋め込みを生成→ベクトルストア（第1章）に格納→完了をメッセージ（Service Bus）で次段へ。各段は疎結合で、負荷に応じて KEDA（第2章）が独立にスケールします。AI サービス（Azure OpenAI、Azure AI services）はこのパイプラインの各段から呼び出して統合します。
3.2.1回復性の設計
分散・非同期のパイプラインでは失敗は前提です。AI 呼び出しはレート制限（クォータ）や一時障害で失敗しうるため、再試行（指数バックオフ）と、再試行で同じ処理が二重に起きても結果が壊れない 冪等性（idempotency）を設計します。回復不能なものは デッドレター へ隔離して可視化します。これにより、一部の失敗で全体が壊れない回復性のあるパイプラインになります。
頻出：
①「文書到着などのイベントで処理を起動」＝イベント駆動（Event Grid → 関数/コンテナ）。
②AI サービス（Azure OpenAI/AI services）は各段から呼び出して統合、疎結合を保つ。
③AI 呼び出しの失敗対策＝再試行（指数バックオフ）＋冪等性、回復不能はデッドレター。
④各段は KEDA で独立スケール。
混同・注意：
①イベント駆動（疎結合・非同期）と直接同期呼び出しを取り違えない。
②冪等性がないと再試行で二重処理の副作用が出る——設計必須。
③AI 呼び出しの失敗は例外ではなく前提（レート制限等）。
④パイプラインの各段は独立スケール——ボトルネック段だけ増やせる。
3.2.2この節のまとめ
- イベント駆動パイプライン：イベント→関数/コンテナ→AI サービス→次段、各段は疎結合で独立スケール（KEDA）
- AI サービス（Azure OpenAI/AI services）は各段から呼び出して統合
- 回復性：再試行（指数バックオフ）＋冪等性＋デッドレター（失敗は前提）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 文書がストレージに到着したことをきっかけに後続処理を起動する設計を何と呼びますか？
Q2. AI 呼び出しが一時障害やレート制限で失敗しうるパイプラインで、再試行しても結果が壊れないようにする設計概念はどれですか？
Q3. イベント駆動 AI パイプラインで Azure OpenAI / Azure AI services を扱う適切な方法はどれですか？
Q4. 分散・非同期の AI パイプラインの回復性設計として適切なものはどれですか？
Q5. イベント駆動パイプラインで負荷に応じて各段をどうスケールするのが適切ですか？