変更要約: 初版: ドメイン1（FM統合・データ管理・コンプラ）の5節を作成
1.1要件分析と基盤モデルの選定・構成
GenAI ソリューションの設計と、用途に合う 基盤モデル（FM） の選定・構成を学びます。Amazon Bedrock でのモデル評価、Cross-Region Inference による回復性、プロビジョンドスループット、ファインチューニング／LoRA、Well-Architected Framework（生成 AI レンズ） を押さえます。
プロの GenAI 開発は 「どの基盤モデルを、どんなアーキテクチャで、本番にどう載せるか」 の意思決定から始まります。モデル開発（学習）は範囲外で、既存 FM を統合する側面が問われます。
1.1.1モデル選定と構成
- Amazon Bedrock：複数プロバイダの FM（Anthropic Claude・Amazon Nova/Titan・Meta Llama 等）に単一 API でアクセスするマネージドサービス。モデル切替をコード変更なしで行える設計の土台。
- モデル選定：ベンチマーク・能力分析・制約評価（コンテキスト長/対応モダリティ/レイテンシ/コスト）で用途に最適な FM を選ぶ。万能の1モデルでなく用途別に選ぶ。
- 動的モデル選択：Lambda＋API Gateway＋AWS AppConfig で、再デプロイなしにモデル/プロバイダを切り替える抽象化レイヤーを作る。
- FM カスタマイズ：ファインチューニング や LoRA（低ランク適応）でドメイン適応し、SageMaker Model Registry でバージョン管理・ロールバックする。
「複数 FM へ単一 API＝Bedrock」「コード変更なしのモデル切替＝AppConfig による動的選択」「リージョン障害/容量に強い推論＝Cross-Region Inference」「安定スループット確保＝プロビジョンドスループット」「軽量なドメイン適応＝LoRA」 は AIP-C01 で頻出です。
回復性の高い設計では Amazon Bedrock Cross-Region Inference（推論プロファイルで複数リージョンへ自動振り分け＝容量不足やリージョン障害を吸収）と、Step Functions による サーキットブレーカー、フォールバックモデルへの graceful degradation を組み合わせます。スループット要件が厳しい本番では プロビジョンドスループット（モデル単位で容量を予約）を選び、バースト主体ならオンデマンドのまま 指数バックオフ で 429 を捌きます。設計レビューは AWS Well-Architected Framework の 生成 AI レンズ で、コスト・運用・セキュリティ・責任ある AI の観点を体系化します。PoC は Amazon Bedrock 上で素早く実現性・性能・ビジネス価値を検証してから本番化します。FM カスタマイズは「プロンプトで足りるか→RAG か→ファインチューニング/LoRA か」の順で最小コストの手段から検討します。
| 要件 | 選ぶもの | 理由 |
|---|---|---|
| 安定した高スループット | プロビジョンドスループット | 容量を予約しレイテンシ/可用性を確保 |
| リージョン障害/容量不足に強い | Cross-Region Inference | 複数リージョンへ自動振り分け |
| 再デプロイなしのモデル切替 | AppConfig＋Lambda 抽象化 | 設定でモデルIDを切替 |
| ドメイン特化 | ファインチューニング/LoRA | プロンプト/RAG で不足する場合 |
シナリオ： あるチャットアプリは特定リージョンのモデル容量不足で断続的に 429 が出る。可用性を上げたい。→ Bedrock の Cross-Region Inference（推論プロファイル）で複数リージョンへ自動振り分けし、クライアントは指数バックオフで再試行。安定容量が要るピーク帯はプロビジョンドスループットを併用します。
ひっかけ： 「精度を上げるならまずファインチューニング」は誤りです。コスト順ではプロンプト最適化→RAG→ファインチューニング/LoRAで、最小コストの手段から検討します。また「Cross-Region Inference はデータを別リージョンに常時複製する DR 機能」も誤り（推論リクエストのルーティングであり、データレプリケーションではありません）。
1.1.2この節のまとめ
- 単一API＝Bedrock／用途別にベンチマークで選定／切替はAppConfig 抽象化
- 回復性＝Cross-Region Inference＋サーキットブレーカー／適応はプロンプト→RAG→LoRAの順
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 本番のチャットアプリで、再デプロイせずに使用する基盤モデル（プロバイダ）を切り替えられる設計にしたい。最適なのはどれ？
Q2. 特定リージョンのモデル容量不足で断続的にスロットリングが発生している。コード変更を最小に可用性を高めたい。何を使う？
Q3. 社内文書の語彙にモデルを軽量に適応させたいが、フルのファインチューニングはコストが高い。最小コストで試すべき順序として正しいのは？