変更要約: 各節に図（figure）を追加＝cert-figure-retrofit。AI-200 第2章を新規作成（コンテナ＝ACR/Container Apps/AKS の使い分け、スケールとサーバーレス＝KEDA イベント駆動オートスケール/Azure Functions トリガー・バインディング/コンテナ vs 関数の選択）
2.2スケールとサーバーレス関数
イベント駆動でコンテナ/関数を自動スケールする KEDA、サーバーレスの Azure Functions（トリガーとバインディング）、そしてコンピュートの選択基準を、AI バックエンドの文脈で理解します。
AI ワークロードは負荷が大きく変動します（バッチ処理、キューに溜まったタスク、ピーク時のリクエスト等）。これに合わせて自動でスケールさせるのが KEDA（Kubernetes Event-driven Autoscaling）で、Azure Container Apps や AKS が内部で利用します。KEDA は「キューの長さ」「イベント数」などの外部メトリクスに応じてレプリカ数を増減し、負荷ゼロ時はゼロまで縮小できます。これによりコスト効率の高いイベント駆動処理を実現します。
2.2.1サーバーレス関数（Azure Functions）
小さな単機能の処理（ファイル到着で埋め込み生成、メッセージ受信で要約など）は Azure Functions が向きます。Functions は トリガー（実行のきっかけ：HTTP・キュー・タイマー・Blob 等）と バインディング（入出力リソースへの宣言的な接続）でイベント駆動処理を簡潔に書け、従量課金（使った分だけ）で動きます。常駐サーバーの管理が不要なため、断続的・イベント駆動の AI 処理に適します。
頻出：
①「キュー長やイベント数に応じてゼロスケール含め自動スケール」＝KEDA（イベント駆動オートスケール）。
②「ファイル到着やメッセージ受信をきっかけに単機能処理を従量課金で」＝Azure Functions（トリガー＋バインディング）。
③Functions の「実行のきっかけ」＝トリガー、「入出力への宣言的接続」＝バインディング。
混同・注意：
①トリガー（実行のきっかけ）とバインディング（入出力接続）を取り違えない。
②Functions（小さな単機能・断続的）とコンテナ（常時稼働の API・複雑なワークロード）を要件で選ぶ。
③KEDA はスケールの仕組みであり、コンピュート本体ではない。
④ゼロスケールはコスト効率が良い一方、コールドスタートの遅延に注意。
2.2.2この節のまとめ
- KEDA＝キュー長/イベント数など外部メトリクスでイベント駆動オートスケール（ゼロスケール可）
- Azure Functions＝トリガー＋バインディングでイベント駆動の単機能処理、従量課金
- 使い分け：単機能・断続的＝Functions／常時 API・複雑＝コンテナ
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. キューの長さやイベント数などの外部メトリクスに応じて（ゼロスケール含め）自動スケールする仕組みはどれですか？
Q2. ファイル到着やメッセージ受信をきっかけに単機能の処理を従量課金で実行するのに適した Azure サービスはどれですか？
Q3. Azure Functions で「実行のきっかけ（HTTP・キュー・タイマー等）」を表すのはどれですか？
Q4. Azure Functions で入出力リソースへの宣言的な接続を表すのはどれですか？
Q5. コンテナ（常時 API）とサーバーレス関数の使い分けとして適切なものはどれですか？