TL Terralien
Machine Learning

Amazon Bedrock Prompt Management

プロンプトを「アプリのコードに埋まった文字列」から取り出し、変数・推論設定・モデル指定ごと1つの AWS リソースにして版を切るための仕組み。アプリは ARN を呼ぶだけになります。

  • A｜GenAIの核
  • D1 FM統合・データ・コンプラ
  • D3 安全性・セキュリティ・ガバナンス
  • D5 テスト・検証・トラブルシュート

最終更新: 2026年8月18日

ひとことで言うと

プロンプト本文・変数・推論パラメータ・呼ぶモデルを1組にして、名前と版を持つ Bedrock リソースにするものです。アプリ側は文字列を持たず、Converse の modelId にプロンプトの ARN を渡して呼びます。

要するに、ストアドプロシージャです。SQL 文をアプリのコードに埋め込むのをやめて、名前付きの手続きとしてサーバ側に置き、呼び出し側は名前とパラメータだけ渡す——あの構図がそのままプロンプトに来ています。プロンプトを直したのにアプリを再デプロイする、という往復が消えるのが本質で、「プロンプトを綺麗に保管する場所」ではありません。

なぜ生まれたか

プロンプトは、動くコードのうち最も頻繁に変わるのに、最もバージョン管理から漏れやすい部分です。文字列としてアプリに埋まっていると、次のことが全部アプリ側の都合になります。

埋め込み文字列でやっていたことPrompt management に移すと
プロンプトを1文字直すたびにアプリを再デプロイプロンプトの版を切り、アプリが指す ARN のバージョンを変えるだけ
モデルID・temperature・maxTokens がプロンプトと別の場所にある同じバリアントの中に同居する（プロンプトと推論設定は一体で初めて再現する）
案A・案Bの比較が「コメントアウトして戻す」バリアントを最大3つ並べて同じ変数で走らせる
「先週の出力が良かった」に戻せないバージョンは作成時点のスナップショットとして残る

年表の形で示せる公開日付が公式ドキュメント側に無いため、ここでは経緯の構造だけ置きます。ドラフト（DRAFT）は書き換わり続け、バージョンはスナップショットとして固定される——この2層構造が、上の全部を支えている唯一の仕掛けです。

何に使うか

用途使い方関連ドメイン
プロンプトの外部化CreatePrompt で作成。応答は DRAFT 版の ID / ARN を返すD1
変数によるテンプレート化本文に {{variable}}（二重波括弧）を書き、実行時に promptVariables で埋めるD1
案の比較プロンプトビルダーの Compare variants（最大3つ）で同じ入力を流して見比べるD1 / D5
本番への切り出し満足した時点で Create version。番号は 1 から採番されるD1
アプリからの呼び出しConverse / ConverseStream / InvokeModel の modelId にプロンプト ARN（:VERSION 付き）を渡すD2
ワークフローへの組み込みAmazon Bedrock Prompt Flows の prompt ノードに promptArn で参照させるD1 / D2
エージェント向けの下書きバリアントに genAiResource（agent）を指定して、エージェント用プロンプトとして保持するD2
版の差分確認Compare versions で、どの版から挙動が変わったかを突き合わせるD5
保管時の暗号化統制プロンプト単位でカスタマー管理 KMS キーを指定（未指定なら AWS 管理キー）D3

試験でどう問われるか

プロンプトを「アプリの外に出す」要件が書かれたら、まずここです。逆に、プロンプトの中身の書き方（chain-of-thought・出力フォーマット指定）を問う設問では主役になりません。D5 では「どの版から壊れたか」の切り分け手段として出ます。

問われ方正解に寄る条件引っかけの選択肢
「プロンプト改善のたびにアプリを再デプロイしていて回らない」プロンプトと推論設定をアプリから外し、バージョンを切って ARN で参照するプロンプトを S3 / DynamoDB / Parameter Store に置いて起動時に読む案（推論設定とセットにならず、テストも比較もできない）
「複数のプロンプト案から1つ選びたい」その場で出力を見比べて選ぶ→ Compare variants（最大3つ）同じシナリオでも、スコアを付けて定量比較・回帰させたいなら Bedrock Model Evaluations 側が正解。「見比べる」か「採点する」かで割れる
「本番の応答が急に変わった。原因の切り分け」直前に切り替えたプロンプトのバージョンを比較して差分を特定する（D5.2）CloudWatch のレイテンシメトリクスを見る（品質の変化は見えない）
「プロンプトを一元管理しつつ、ガードレールも効かせたい」呼び出し時に guardrailConfig を付ける。プロンプト全体に効く（guardContent ブロックを指定した場合はその部分だけ）「Prompt management に登録しただけでガードレールが適用される」
「誰がプロンプトを変更したか監査したい」プロンプトは Bedrock のリソースなので、IAM と CloudTrail の対象になる（D1.6 / D3.3）「プロンプト本文の中に変更履歴コメントを書く」
「短いプロンプトを対象モデル向けに手早く書き直したい」プロンプト最適化（OptimizePrompt）。おおむね 1k トークン以下の単一プロンプト・単一モデル向けの発見的な書き換え「最適化が評価データを使って複数モデル横断で改善してくれる」（単純最適化は評価データを使わず、複数モデルにも対応しない）
「エージェントに使うプロンプトを Prompt management で管理して API から実行したい」バリアントに agent を指定したプロンプトはコンソールでしかテストできない。API では InvokeAgent の inputText に本文を入れる「agent 指定のプロンプト ARN を Converse の modelId に渡す」

1問拾える境目: Converse にプロンプト ARN を渡すとき、system / inferenceConfig / toolConfig / additionalModelRequestFields は同時に指定できません。これらは「プロンプト側が持っているもの」だからです。messages だけは指定でき、その場合プロンプトに定義されたメッセージの後ろに追記されます（置き換えではありません）。「呼び出し側で system を上書きする」設計は、この経路では成立しません。

実務でどう使うか

試験ガイドの語と、実装のあいだに溝がある箇所です。公式試験ガイドのスキル 1.6.3 は「Amazon Bedrock Prompt Management to create parameterized templates and approval workflows」——承認フローと明記しています。ところが Bedrock のユーザーガイド側には、承認ワークフローという機能の記述が見当たりません。
したがって、ここは「バージョンを切って動かないものにする」＋「IAM で誰が本番エイリアスを差し替えられるかを絞る」＋「CloudTrail で変更を追う」の組み合わせを、承認フローと呼んでいると読むのが妥当です。存在しない画面を探さないでください。設問で「承認フロー」と書かれていたら、探すのは版・権限・監査の3点セットです。

  • {{variable}} は二重波括弧です。 実行時は promptVariables={"{{variable_name}}": {"text": "値"}} の形で渡します。コンソールのテスト値は保存されません（テスト用の一時値）
  • テンプレート型は TEXT と CHAT の2つ。 CHAT は Converse 対応モデル限定で、プロンプトキャッシュを使うなら CHAT が必須です。キャッシュ範囲はツールのみ／ツール＋システム指示／ツール＋システム指示＋メッセージから選びます（対応はモデルによる）
  • 比較モードで「Save as draft」を押すと、選ばなかったバリアントは削除されます。 3案並べて1つを採用した瞬間に残り2案が消えるので、捨てたくない案は先にバージョンを切っておきます
  • 基本推論パラメータは maxTokens / stopSequences / temperature / topP の4つだけ。 top_k のようなモデル固有パラメータは additionalModelRequestFields に JSON で入れます。ここに基本パラメータを書いてもコンソールで設定した値は上書きされません
  • バージョンを切っただけでは本番は変わりません。 アプリが参照する ARN のバージョン部分を切り替えて初めて反映されます。ロールバックも同じ操作です
  • プロンプト最適化は英語での実行が推奨されています。 日本語プロンプトに掛けたときの品質は公式が保証していません

アプリ側の「切り替えスイッチ」は自分で用意する必要があります。バージョンは不変のスナップショットとして積み上がりますが、どの版を使うかを指す仕組み（設定値・環境変数・AppConfig など）はアプリ側の設計です。ARN をコードに直書きすると、プロンプトを外部化した意味が薄れます——結局、版を上げるたびに再デプロイになるからです。

取り違えやすいもの

迷う相手切り分けの一言
Amazon Bedrock Prompt FlowsPrompt Management は部品1個（プロンプト＋推論設定）。Flows は部品を繋ぐ配線。Flows の prompt ノードは Prompt Management のプロンプトを参照でき、逆はない
Amazon Bedrock Model Evaluationsこちらは「見比べて人が選ぶ」。Model Evaluations は「指標でスコアを付けてジョブとして採点する」。主観の比較か、記録に残る採点か
プロンプトキャッシュ保存されるものが違う。Prompt Management は設計時の定義、プロンプトキャッシュは推論時の前置きトークン。目的も版管理とコスト削減で別
Amazon Bedrock GuardrailsGuardrails は入出力の内容を検閲する。Prompt Management は指示そのものを管理する。呼び出し時に組み合わせて使う関係
プロンプトルータールーターは「どのモデルに投げるか」を実行時に決める。Prompt Management は「何をどう聞くか」を設計時に固定する
AWS AppConfigAppConfig はコード変更なしで設定値を差し替える一般の仕組み（D1.2 のモデル動的切替）。プロンプト本文とその版は Prompt Management 側が持つ

想起チェック

Q1. 「3つのプロンプト案を比べたい」。Compare variants と Bedrock Model Evaluations、どちらが正解になりますか。

その場で出力を見て人が1つ選ぶなら Compare variants、指標でスコアを付けて記録・回帰させたいなら Model Evaluations です。設問に「評価指標」「レポート」「継続的な品質ゲート」が出たら後者に寄ります。

Q2. `Converse` にプロンプト ARN を渡すとき、同時に指定できないフィールドは何ですか。

system / inferenceConfig / toolConfig / additionalModelRequestFields です。プロンプト側の定義に含まれているためで、messages だけは指定でき、その場合は既定のメッセージの後ろに追記されます。

Q3. プロンプトのバージョンを新しく作りました。本番の挙動はいつ変わりますか。

アプリが参照する ARN のバージョンを切り替えたときです。バージョンを作るだけでは何も切り替わりません。ドラフトは書き換わり続け、バージョンは不変のスナップショットとして残ります。

Q4. エージェントを指定したプロンプトを API からそのまま実行できますか。

できません。 バリアントに genAiResource（agent）を指定したプロンプトはコンソールでのみテストでき、API ではプロンプト本文を InvokeAgent の inputText に入れる形になります。

出典（AWS公式）