変更要約: 各節に図（figure）を追加＝cert-figure-retrofit。AI-300 第3章を新規作成（ドメイン3「GenAIOps インフラ」: Foundry 環境=プロジェクト/RBAC/マネージド ID/プライベートネットワーク/Bicep・CLI、基盤モデルのデプロイ=サーバーレス API エンドポイント vs マネージド コンピューティング/ユースケース別モデル選択/バージョン管理・デプロイ戦略/PTU、プロンプトのバージョン管理=設計・開発/バリアント比較/Git）
3.3プロンプトのバージョン管理
プロンプトの設計と開発、プロンプトのバリアント作成と性能比較、そして Git リポジトリによるプロンプトのバージョン管理を、ソース管理と実験の観点で理解します。
生成 AI アプリでは、プロンプトがコードと同じくらい重要な「資産」です。プロンプトの良し悪しが応答品質を大きく左右するため、設計・比較・バージョン管理を体系的に行います（プロンプトエンジニアリングの運用化）。
3.3.1設計・バリアント・比較
まずユースケースに合わせて プロンプトを設計・開発します（システムプロンプト・指示・例示・出力形式の指定など）。次に プロンプトのバリアント（言い回しや構成を変えた複数版）を作り、同じ評価データで性能を比較して最良のものを選びます。これは学習における「複数モデルの比較」に相当する、生成 AI の実験プロセスです。
3.3.2Git によるバージョン管理
有用なプロンプトは Git リポジトリでバージョン管理します。これにより、変更履歴・レビュー（プルリクエスト）・ロールバックが可能になり、「どのプロンプトのバージョンがどの評価結果を出したか」を追跡できます。コード・IaC・プロンプトをすべて Git で管理することで、GenAIOps を再現可能・監査可能にします。
| 段階 | 内容 | 要点 |
|---|---|---|
| 設計・開発 | システムプロンプト/指示/例示/出力形式 | ユースケースに合わせる |
| バリアント | 言い回し/構成の異なる複数版 | 同じ評価データで比較 |
| バージョン管理 | Git リポジトリ | 履歴・レビュー・ロールバック |
混同に注意：
①プロンプトは「使い捨て」ではなくバージョン管理する資産。
②バリアントの比較は同じ評価データで行う（条件をそろえる）。
③コード・IaC・プロンプトを Git で一元管理し、GenAIOps を再現可能にする。
「要件 → 手段」：例「言い回しを変えた複数のプロンプトを比較」＝プロンプトのバリアント＋同一評価データ、「プロンプトの変更履歴とレビュー」＝Git でのバージョン管理、「どのプロンプト版がどの結果か追跡」＝Git＋評価結果の対応付け。
3.3.3この節のまとめ
- プロンプトは資産：ユースケースに合わせて設計・開発
- バリアントを同じ評価データで比較し最良を選ぶ
- Git でバージョン管理（履歴・レビュー・ロールバック）し GenAIOps を再現可能に
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 生成 AI アプリにおいて、応答品質を大きく左右するため資産として体系的に管理すべきものはどれですか？
Q2. 言い回しや構成を変えた複数のプロンプトを作り、最良のものを選ぶために行うべきことはどれですか？
Q3. プロンプトの変更履歴・レビュー・ロールバックを可能にするために使うのはどれですか？
Q4. プロンプトの設計・開発で指定する要素として一般的でないものはどれですか？
Q5. GenAIOps を再現可能・監査可能にするための一貫した方針として正しいものはどれですか？
Q6. プロンプトのバージョン管理が学習における「複数モデルの比較」に相当する理由はどれですか？