一言で
Amazon Bedrockでプロンプトの作成・テスト・バージョン管理・共有をアプリコードから切り離して行える機能。
なぜ要るか / 背景
プロンプトをアプリのソースコードに直書きすると、変更のたびにデプロイが必要になり、プロンプトエンジニアとアプリ開発者の分業がしづらい。Prompt Managementはプロンプトを独立したリソースとして管理することで、この結合を解消する。
主要概念
- Prompt Builder：コンソール上のGUI。JSONを手書きせずにプロンプトを作成・編集・テストできる
- プロンプト（Prompt Management文脈での意味）：一般的な「ユーザーがアプリに投げる入力」や「システムプロンプト単体」とは違い、システムプロンプト＋user/assistantメッセージ例＋ツール設定＋推論パラメータをまとめた1つのリソースを指す。用語が重複していて紛らわしいので要注意
- プロンプトのARN：保存したプロンプトに割り当てられる識別子。Converse/InvokeModel APIから呼び出す際に使う
- バージョン：プロンプトリソースの特定時点のスナップショット。デプロイ対象を固定できる。2バージョン間の差分比較も可能
- バリアント：モデルや指示文を変えた別パターンのプロンプト。並行テスト・最適化に使う
-
変数（プレースホルダー）：
{{variable_name}}の形式で、実行時やテスト時に値を差し込める - Foundation Model向けとAgent向け：どちらのプロンプトも保存対象にできる
- カスタムメタデータ：作成者・チーム・部署などをSDK経由でプロンプトに付与できる
基本の流れ
- コンソールでPrompt Managementを選択し「Create prompt」
- Prompt Builderでシステムプロンプト・メッセージ・ツール設定・推論パラメータを構成
- Builder上でテスト実行し出力を確認
- 問題なければバージョンを作成（スナップショット化）
- アプリからはプロンプトのARN（バージョン指定可）を使ってConverse/InvokeModel APIで呼び出す
用途整理（誤解しやすいポイント）
- バージョン＝改善の履歴管理が本命：同じ目的のプロンプト（例：カスタマーサポート応答）を段階的に改良し、問題があればすぐ前バージョンに切り戻せる、というのが主眼。コード変更・再デプロイ不要で切り戻せる点が刺さりどころ
- 用途違いの複数プロンプトの使い分け（例：関西弁版／北海道弁版）は技術的には可能だが別軸の話。この場合はバージョン違いというより別プロンプトリソースとして管理するのが自然
具体例（改善の流れのイメージ）
- v1：システムプロンプトに「語尾は北海道弁で回答して」とだけ指示してデプロイ。結果、「そだねー」「なまら寒いっしょ」「したっけ」を多用した回答が返ってきて、ユーザーから「何言ってるか分からない」とクレーム。訛りが強すぎて意味不明になったのが原因と判明
- v2：システムプロンプトを「基本は標準語、語尾に軽く北海道らしさを一言添える程度」に調整し、few-shotの回答例（user/assistantメッセージ）も1〜2個追加して再デプロイ。トーンは保ちつつ意味が通じる回答に改善
- 切り戻し：もしv2でも別の問題（例：北海道らしさが薄すぎてつまらない、等）が出れば、コードは一切変えずにアプリ側の呼び出しをv1に戻すだけで即座にロールバックできる
関連
- Bedrock Prompt Flows：プロンプトやKnowledge Base、Lambdaなどをビジュアルに繋いでワークフロー化する別機能。Prompt Managementと名前が似ているが役割が異なる
- Advanced Prompt Optimization（2026-05〜）：最大5モデルに対しプロンプトを最適化・比較できるツール
- Bedrock Agents：Prompt Managementから呼び出せる対象の一つ
試験ポイント（AIP-C01）
- 「プロンプトをコードから分離する仕組み」という位置づけを問われやすい
- Prompt ManagementとPrompt Flowsの役割の違いを区別できるようにしておく
- APIからの呼び出しは「プロンプトのARN／識別子」を指定する方式、という点を押さえる
- バージョン管理の主目的は「改善履歴の追跡と切り戻し」であり、単なる複数プロンプトの切り替え機能ではない点に注意
- Prompt Managementでいう「プロンプト」はシステムプロンプト単体ではなく、メッセージ・ツール設定・推論パラメータを含むリソース単位である点に注意