この記事は、AWS Bedrock AgentCore に追加された Optimization 機能を実際に触ってみた検証記事です。
ざっくり言うと、これは
「エージェントが実際にどう動いたか」を見て、プロンプトや設定を改善する仕組み です。
普通、LLMエージェントのプロンプト改善ってかなり泥臭いです。
「この言い回しだとダメだな」「もう少しツールの使い方を明示したいな」と、人間が何度も試行錯誤する必要があります。正直、ここはかなりしんどい。私もこういう改善作業は好きですが、沼りやすいのも事実です。
このOptimizationは、その試行錯誤の一部をAIにやらせる感じです。
しかも机上の空論ではなく、実際のトレースログ を材料にするのがポイントです。これはかなり実運用向きだと思います。
この記事では、Optimizationを次の3つに分けて説明しています。
実際のトレースログと、改善したい評価指標（Evaluator）を入力にして、
システムプロンプトやツール説明文の改善案をAIが出す 機能です。
言い換えると、
「人間が勘で直す」のではなく、
「AIに“こう直すと良さそう”と提案させる」仕組みです。
プロンプトやツール説明文をコードの外に切り出して、AgentCore側でバージョン管理 する仕組みです。
これが便利なのは、コードを毎回直して再デプロイしなくても、
設定だけ差し替えてエージェントの挙動を変えられる ところです。
A/Bテストのときにも使います。
ControlとTreatmentで別設定を持たせる、というのがやりやすくなります。
実トラフィックを2つのバリアントに分けて流し、
それぞれの結果をEvaluatorで採点して比較する機能です。
つまり、
「新しいプロンプト、本当に本番で効くの？」
をちゃんと確かめられるわけです。
この3つをまとめて、AWSは continuous improvement loop と呼んでいます。
改善案を出す → 設定として管理する → 本番で試す、という流れですね。
この流れはかなり筋が良いです。プロンプト改善って、結局「作る」「試す」「比べる」の繰り返しなので、最初からそれを機能として持っているのは強いと思います。
著者は、Strands Agentsで作った マルチエージェント構成 に対してこのOptimizationを試しています。
構成は Agents-as-Tools パターン。
これは、メインエージェントがサブエージェントを @tool のように扱い、必要に応じて呼び出す設計です。
今回の検証用エージェントは、
に分かれていて、それをメインエージェントが束ねています。
こういう構成は実際の業務でもよくありそうです。
「1つの巨大な万能エージェント」より、「役割を分けた小さなエージェントを束ねる」ほうが保守しやすい、という考え方ですね。個人的にも、この方向はかなり現実的だと思います。
A/Bテストに乗せるには、プロンプトやツール説明を agentcore.json の configBundles に外出しする必要があります。
著者が使った構造はこんな感じです。
{
"components": {
"{{runtime:agentsAsToolsLab}}": {
"configuration": {
"systemPrompt": "You are an assistant that answers questions about weather and news.",
"weather_agent": "Get weather",
"news_agent": "Get news"
}
}
}
}
ここで面白いのは、ツール説明文を toolDescriptions の下に入れるのではなく、configuration直下にフラットに置いている 点です。
理由は、Recommendations API がツール説明文の path を解決する都合に合わせるため。
つまり、CLIのデフォルト構造のままだとうまくいかず、少し形を変えたら動いた、という話です。
このあたりは正直、まだ新しい機能らしい「手触り」があります。
便利だけど、完全に洗練されきってはいない。こういうところは実際に触った人のレポートがありがたいですね。
Bundleの値をRuntimeに反映するには、Strandsの hook機構 を使っています。
著者は ConfigBundleHook を作り、
BeforeInvocationEvent で システムプロンプトBeforeToolCallEvent で ツール説明文をそれぞれ上書きしています。
ざっくり言うと、
「エージェントが動き出す直前に、設定を差し込む」
という実装です。
これも実運用ではかなり大事です。
設定をコードにベタ書きしないことで、改善サイクルを速く回せます。
このへんは地味ですが、運用しやすさに直結します。
著者は、英語クエリ8種類を5回ずつ流して、合計40セッション分のトレースをため、その後に Recommendations を実行しています。
実行したのは次の2つです。
agentcore run recommendation --type system-prompt
agentcore run recommendation --type tool-description
結果を見ると、
「call both tools in parallel」
「use news_agent to find related news」
のように、ツール呼び出しまで意識したプロンプトに改善されていたそうです。
ここはかなり面白いです。
単に「丁寧に答えましょう」みたいな一般論ではなく、このエージェントが実際に持っているツール構成を踏まえた指示 を出してくれるわけです。
これはかなり実用的ではないでしょうか。
ツール説明についても、説明を厚くするだけでなく、
Often used alongside news_agentOften used alongside weather_agentのように、他のサブエージェントと並列で使う可能性 まで書かれていたとのことです。
これも良いですね。
ツール説明って、つい「何をするツールか」だけ書きがちですが、実際には「いつ、どういう文脈で使うか」まで書くと効きやすいです。
Recommendations はそこを拾ってくれるので、かなり賢いなと思いました。
Recommendations が出した改善案を、そのまま信じるのではなく、A/Bテストで確認しています。ここがちゃんとしていて好感度高いです。
AIの提案は便利ですが、実際に効くかどうかは別問題ですからね。
Builtin.GoalSuccessRate
40セッション分の結果は次の通りです。
つまり、方向としては Treatment が良いです。
でも、サンプルが少なすぎて「本当に改善した」とまでは言えなかった、という結果です。
これはかなり健全です。
小規模検証で「改善した！」と断言してしまうより、
「傾向は見えるけど、サンプル不足で断定はできない」と言っているほうが信頼できます。
個人的にも、この結論は大事だと思います。
プロンプト改善は“雰囲気”で勝ちやすいので、A/Bテストのように比較できる仕組みがあるのは本当に強いです。
この記事のいちばん実用的な示唆はここかもしれません。
著者は、Recommendationsが得意な領域と、開発者が書くべき領域を次のように整理しています。
これはかなり納得感があります。
要するに、「プロンプトの書き方として汎用的に効く部分」はAIに任せてよいが、業務固有のルールは人間が責任を持つべき ということです。
たとえば、
みたいなものは、AIに勝手に補完させるべきではないですよね。
ここを混ぜると、便利そうに見えて事故りやすい。私はこの線引きがとても重要だと思います。
最後のおまけが、地味に衝撃的です。
著者は、日本語のシステムプロンプトを --inline で入れて Recommendation を実行すると、
prompt attack protection によって unsafe と判定されてしまったと書いています。
しかも切り分けた結果、
という挙動だったそうです。
一方で、ツール説明文のRecommendationは日本語でも通る とのこと。
これはかなり興味深いです。
日本語のシステムプロンプトだけ厳しく見られているのか、あるいは安全性検出の誤判定なのか、詳細はこの記事だけでは断定できません。
ただ、少なくとも検証上は 英語でやるのが無難 だった、というのは実務的な学びです。
こういう“製品のクセ”は、ドキュメントを読むだけでは見えにくいので、実験記事の価値が出ますね。
この記事は、Bedrock AgentCore Optimization を使って、マルチエージェントのプロンプト改善と検証を実際に回してみた レポートでした。
特に印象的だったのは、
です。
プロンプト改善って、どうしても「職人芸」になりがちですが、こうやって 改善→管理→検証 を一連の仕組みに落とせるなら、かなり運用しやすくなりそうです。
個人的には、AgentCore Optimization は「プロンプトを気合で直す時代」から少し抜け出すための、かなり実戦的な一歩だと思いました。
参考: Bedrock AgentCore Optimizationでマルチエージェントのプロンプトを改善・検証してみる