変更要約: 各節に図（figure）を追加＝cert-figure-retrofit。AI-300 第3章を新規作成（ドメイン3「GenAIOps インフラ」: Foundry 環境=プロジェクト/RBAC/マネージド ID/プライベートネットワーク/Bicep・CLI、基盤モデルのデプロイ=サーバーレス API エンドポイント vs マネージド コンピューティング/ユースケース別モデル選択/バージョン管理・デプロイ戦略/PTU、プロンプトのバージョン管理=設計・開発/バリアント比較/Git）
3.1Foundry 環境とプラットフォーム構成
Microsoft Foundry のリソースとプロジェクト環境の作成・構成、マネージド ID と RBAC による ID とアクセス管理、ネットワークセキュリティとプライベートネットワーク構成、そして Bicep テンプレートと Azure CLI によるインフラのデプロイを理解します。
生成 AI の運用化（GenAIOps）は、MLOps の考え方を生成 AI に広げたものです。基盤となるのが Microsoft Foundry（旧 Azure AI Foundry／Studio）で、モデルの選択・デプロイ・アプリ/エージェントの構築・評価・監視を一貫して行います。本節はそのインフラの構成を扱います。
3.1.1Foundry リソースとプロジェクト環境
Foundry では プロジェクト単位で作業を分離・整理します。リソースとプロジェクト環境を作成し、モデルカタログ・デプロイ・評価・監視を集約します。アクセスは RBACで最小権限に割り当て、Foundry やアプリが他リソース（Storage・Key Vault・Azure OpenAI 等）へアクセスする際は マネージド IDでシークレットを持たずに認証します。MLOps と同じ「最小権限＋シークレットレス」の原則が GenAIOps にも当てはまります。
3.1.2ネットワークセキュリティと IaC
Foundry のインフラも プライベートネットワーク（プライベート エンドポイント／マネージド仮想ネットワーク）でパブリック露出を制限し、モデルやデータへのアクセスを保護します。環境構築は Bicep テンプレートと Azure CLIでコードとしてデプロイし、再現可能・監査可能にします。これにより、開発から本番まで一貫した GenAIOps 基盤を素早く展開できます。
| 目的 | 手段 | 要点 |
|---|---|---|
| 作業の分離・整理 | Foundry プロジェクト | モデル/デプロイ/評価/監視を集約 |
| 最小権限のアクセス | RBAC | 組み込み/固有ロール |
| シークレットレス認証 | マネージド ID | 他リソースへ安全に接続 |
| パブリック露出の制限 | プライベート エンドポイント/マネージド VNet | モデル/データを保護 |
| 環境のコード化 | Bicep / Azure CLI | 再現可能・監査可能 |
「要件 → 手段」：例「作業をプロジェクトで分離」＝Foundry プロジェクト、「最小権限で付与」＝RBAC、「シークレットなしで Storage/Key Vault へ」＝マネージド ID、「Foundry をパブリックに晒さない」＝プライベート エンドポイント、「環境をコードで再現可能に」＝Bicep/Azure CLI。
3.1.3この節のまとめ
- GenAIOps の基盤＝Microsoft Foundry。プロジェクトで作業を分離・整理
- アクセスは RBAC で最小権限、認証はマネージド ID（シークレットレス）
- プライベートネットワークで保護、Bicep/Azure CLI でコード化
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 生成 AI の運用化（GenAIOps）の基盤として、モデル選択・デプロイ・構築・評価・監視を一貫して行うプラットフォームはどれですか？
Q2. Foundry で作業を分離・整理し、モデル/デプロイ/評価/監視を集約する単位はどれですか？
Q3. Foundry やアプリが Storage や Key Vault へシークレットを持たずに認証するために使うのはどれですか？
Q4. Foundry のインフラをパブリックに晒さず、モデルやデータへのアクセスを保護するにはどうしますか？
Q5. Foundry のリソースや環境をコードとして再現可能にデプロイするために使うのはどれですか？
Q6. GenAIOps のインフラ構成に当てはまる原則として正しいものはどれですか？