変更要約: 初版: ドメイン2（実装と統合）の5節を作成
2.4FM API 統合
FM API を堅牢に統合する技法を学びます。同期/非同期（SQS）、Bedrock ストリーミング（WebSocket/SSE）、指数バックオフ／レート制限／フォールバック、X-Ray による可観測性、モデルルーティング を扱います。
FM 呼び出しは遅く・失敗しうる・トークン課金という性質があります。同期/非同期の使い分け、ストリーミング、再試行、ルーティングで堅牢に統合します。
2.4.1堅牢な API 統合
- 同期/非同期：即時応答は同期、長時間処理は SQS で非同期化して呼び出し側をブロックしない。
- ストリーミング：Bedrock ストリーミング API ＋ WebSocket/SSE で生成テキストを逐次返し、体感レイテンシを下げる。
- 回復性：指数バックオフで 429/スロットリングを捌き、API Gateway でレート制限、障害時はフォールバックで縮退運転。
- 可観測性：AWS X-Ray でサービス境界をまたいで FM API 呼び出しをトレースする。
- モデルルーティング：内容に応じて専門 FM へ静的/動的にルーティング（Step Functions／API Gateway の変換）。
「逐次表示で体感を上げる＝ストリーミング（WebSocket/SSE）」「429/スロットリング＝指数バックオフ＋API Gateway レート制限」「長時間処理＝SQS で非同期」「FM 呼び出しの分散トレース＝X-Ray」「内容で最適モデルへ＝モデルルーティング」 は頻出です。
統合の堅牢性は「待たせない・落とさない・追える」で測ります。チャットは Bedrock ストリーミング API＋API Gateway（WebSocket/SSE・チャンク転送）で逐次表示し、長時間バッチは SQS で非同期化して Lambda ワーカーが処理。スロットリング（429）は AWS SDK の 指数バックオフ＋ジッターで再試行し、API Gateway でクライアント側のレート制限、過負荷時はフォールバックモデル/キャッシュで graceful degradation。失敗の可視化は AWS X-Ray でサービス境界をまたいでトレースし、レイテンシのボトルネック（埋め込み/検索/生成のどこか）を特定します。ルーティングは、単純なら API Gateway のリクエスト変換で静的に、文脈依存なら Step Functions で動的に最適 FM を選びます。これらにより、遅延・失敗・コストに強い API 層を構築します。
| 課題 | 対策 | 補足 |
|---|---|---|
| 応答が遅く感じる | ストリーミング | WebSocket/SSE で逐次 |
| 429/スロットリング | 指数バックオフ＋レート制限 | SDK＋API Gateway |
| 長時間処理 | SQS で非同期 | 呼び出し側を解放 |
| ボトルネック特定 | X-Ray | サービス境界をトレース |
ひっかけ： 「スロットリングはリトライ回数を即上限まで増やせば解決」は誤りです。指数バックオフ＋ジッターで間隔を空けて再試行し、根本対策は容量（プロビジョンド/Cross-Region）。また「長い生成は同期で待たせればよい」も誤り（SQS で非同期化＋ストリーミングが定石）。
2.4.2この節のまとめ
- 待たせない＝ストリーミング/SQS 非同期／落とさない＝指数バックオフ＋レート制限＋フォールバック
- 追える＝X-Ray／最適化＝モデルルーティング
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. チャット UI で、生成完了まで数秒かかる長い回答の体感レイテンシを下げたい。最適な手段は？
Q2. ピーク時に Bedrock が 429（スロットリング）を返す。クライアント側でまず取るべき適切な対策は？
Q3. 複数のマイクロサービスと Bedrock 呼び出しを横断するリクエストで、レイテンシのボトルネックがどの区間かを特定したい。最適なのは？