AIエージェントが本番環境で動き始めた後、最初にガバナンス上の問題として顕在化するのがシステムプロンプトの管理です。「誰がいつ書いたプロンプトがあのエージェントに使われているか」「先週の変更から挙動が変わったが変更内容が記録されていない」——こうした状況は、ソースコードには当然存在する変更管理プロセスをプロンプトに適用していないことから生まれます。
システムプロンプトはなぜガバナンス対象になるのか
システムプロンプトはエージェント挙動を決定するコード相当の制御命令であり、変更ごとに追跡・承認・テストを適用することが技術的ガバナンスの最低要件です。
システムプロンプトはエージェントの挙動を規定する「設定値」ではなく、事実上の「コード」として扱う必要があります。
プロンプト変更は本番挙動に即座に影響する
システムプロンプトを変更すると、次のリクエストからモデルの応答パターンが変わります。ソフトウェアコードと同様に、意図しない変更が本番障害を引き起こします。しかしコードと異なり、プロンプトをテキストファイルとして管理すると変更履歴が残りにくく、「いつ・誰が・なぜ変えたか」がトレースできなくなります。
コンプライアンス要件がプロンプト変更の証跡を要求する
ISO/IEC 42001は「AIシステムの変更管理手順の文書化」を要求しており、EU AI Actの高リスクシステム義務（2026年8月適用）は「変更ごとの適合性の再評価」を求めます。プロンプトはAIシステムの中核構成要素であり、変更証跡のない運用は監査対象になります。
マルチエージェント構成でプロンプトの依存関係が複雑化する
サブエージェント・オーケストレーションでは、オーケストレーターのプロンプトを変更するとサブエージェントへの委譲パターンが変わります。個別エージェントのプロンプト変更がシステム全体の挙動に波及する依存関係を、事前に把握する仕組みが必要です。
プロンプトのバージョン管理はどう設計すればよいか
プロンプトをGitリポジトリで管理し、変更履歴と対応モデル名をメタデータに記録することが、再現性ある版数管理の基本設計です。
GitOpsモデルによるプロンプト管理
最もシンプルかつ拡張性の高いアプローチは、プロンプトをGitリポジトリで管理するGitOpsモデルです。ファイル構成の例を示します。
``
prompts/
customer-support-agent/
system-prompt.v2.3.txt # 現行本番バージョン
system-prompt.v2.2.txt # 前バージョン（ロールバック用）
metadata.yaml # 対応モデル・更新日・承認者を記録
qa-review-agent/
system-prompt.v1.0.txt
metadata.yaml
metadata.yaml には最低限以下を記録します。
``yaml``
version: "2.3"
model: "claude-sonnet-4-6"
model_version_pinned: true
approved_by: "security-review-team"
approved_at: "2026-06-20T10:00:00Z"
change_reason: "カスタマーデータ照会ツール追加に伴う権限範囲の明示"
regression_test_id: "test-run-2026-06-19-001"
セマンティックバージョニングの適用
プロンプトのバージョン番号はセマンティックバージョニング（MAJOR.MINOR.PATCH）で管理することを推奨します。
| バージョン種別 | 変更内容の例 | 承認レベル |
|---|---|---|
| PATCH（例: 1.0.1） | 誤字修正・表現の微調整 | 担当エンジニアのレビュー |
| MINOR（例: 1.1.0） | 新しいツール／制約条件の追加 | チームレビュー |
| MAJOR（例: 2.0.0） | エージェントの役割・権限の根本変更 | セキュリティ／法務レビュー |
このルールにより、変更の影響範囲を版数番号だけで把握できます。
承認フローとテスト統制の実装パターンはどれが有効か
変更の影響度をMAJOR/MINOR/PATCHに分類し、段階別の承認ゲートを設けることがプロンプト変更管理における速度とリスクのバランス設計です。
CIパイプラインへの統合
プロンプト変更をGitにコミットした時点でCIが起動し、以下のゲートを順に通過させます。
``
[PR作成] → [自動静的検査] → [回帰テスト実行] → [レビュー承認] → [ステージングデプロイ] → [スモークテスト] → [本番マージ]
自動静的検査の内容:
- 禁止キーワードリスト照合（個人名・機密情報の誤混入を検出）
- トークン数の上限チェック（モデルのコンテキストウィンドウ超過を事前防止）
- バージョンメタデータの必須フィールド確認
回帰テストの内容:
- ゴールデンデータセット（100〜500件の入力/期待出力ペア）で変更前後の精度を比較する（詳細は回帰テスト設計を参照）
- LLM-as-a-judgeで品質劣化を自動検出する
ステージング環境でのA/Bテスト
本番前にステージング環境で旧バージョンと新バージョンを並行稼働させ、以下の主要KPIを比較します。
- タスク完了率: エージェントが意図した手順を最後まで実行できた割合
- ハルシネーション率: 事実誤認または根拠のない推論の割合
- 平均応答トークン数: 不必要に長い応答はコスト増加と処理遅延の兆候
- ツール呼び出しエラー率: 権限不足・スキーマ不一致の発生頻度
閾値を下回るKPIが1つでもあればステージングで差し戻し、原因が特定されるまで本番にマージしない運用ルールを設定します。
ロールバック手順の事前定義
プロンプト変更後に本番で異常が検知された場合のロールバックは、CI上で前バージョンのタグを指定して即座に再デプロイできる手順を事前に整備しておく必要があります。「誰がどの操作をすれば何分以内に元に戻せるか」を事前に文書化し、定期的に演習しておくことが、障害対応時の判断遅延を防ぐ実践的な対策です。
規模別の留意点（SMB / エンタープライズ）
SMBの場合
エンジニアリングリソースが限られる環境では、フルCI/CDパイプラインの構築よりも「GitHub Actionsによる差分検出 + Slackへの承認通知」という軽量実装から始めるのが現実的です。プロンプト変更PRがマージされると自動でSlackに通知が飛び、担当者がレビューするシンプルなフローでも「誰も変更に気づかない」状態は防げます。Kuuの運用管理サービスではSMB向けの軽量プロンプトガバナンス設計を支援しています。
エンタープライズの場合
複数チームが並行してエージェントを開発・運用する規模では、プロンプトリポジトリの権限をIAMロール（開発者・レビュアー・承認者の3階層）で制御し、MAJOR変更には必ずセキュリティレビューを必須化するポリシーエンジン連携が必要です。LLMゲートウェイにプロンプトバージョンをリクエストヘッダーで渡し、監査ログにどのバージョンのプロンプトがどのモデルに渡ったかを全件記録する設計が、大規模なエージェントガバナンスの基盤となります。大企業向けの体系的なプロンプトガバナンス設計はKuuのRDEサービスで対応しています。
参考
- Prompt Governance: The Emerging Enterprise Control Layer
- Secure development practices for agentic AI systems on AWS
- Top 3 LLM Prompt Versioning Platforms 2026
まとめ
システムプロンプトはコード相当の制御命令として、GitOpsによるバージョン管理・セマンティックバージョニング・段階別承認ゲート・回帰テスト自動化を組み合わせたガバナンス設計が必要です。ISO/IEC 42001適合やEU AI Act対応を視野に入れると、プロンプト変更の証跡管理は今後の監査要件の中核になります。「MAJOR変更には必ずセキュリティレビューを通す」という1つのルールから始め、段階的に統制を厚くするアプローチが現実的な出発点です。
プロンプトガバナンス基盤の設計・実装は、Kuu株式会社のエージェントガバナンスサービスにご相談ください。