9月17日、AWSが「Optimizing agent system prompts with Amazon Bedrock AgentCore」と題した記事を公開した。Amazon Bedrock AgentCoreのシステムプロンプト最適化機能がどのように動作するかについて、内部設計とベンチマーク結果を交えて紹介している。

AIエージェントのプロンプトチューニングは、これまで「トレースを見て、手で直して、再評価する」という泥臭いループだった。AgentCore OptimizationはそのプロセスをAIエージェント自身に委ねる仕組みで、本記事ではその内部設計とベンチマーク結果が公開されている。

システムプロンプト最適化の仕組み

システムプロンプトオプティマイザーの核心は「アジェンティック・リフレクター」と呼ばれる推論コンポーネントだ。エージェントの実行トレースを評価し、成功例と失敗例のパターンを分析した上で、システムプロンプトの改訂案を出力する。

重要な設計上の判断がある。トレースはモデルのコンテキストウィンドウに直接詰め込まない。数十件のトレースでも簡単にウィンドウ上限を超えるため、トレース群をファイルシステムに書き出し、リフレクターにシェルツール（grep、cat、diffなど）を与えてファイルを自由に探索させる設計になっている。固定のパイプラインでトレースを要約するのではなく、リフレクター自身が「どの証拠が重要か」を判断する。

2種類のリフレクター

Single Agent Reflector（現行実装）

1つのリフレクターエージェントがトレース全体を一度に処理する。スコア分布を俯瞰し、個々のトレースの重要箇所を掘り下げ、成功・失敗を対比した上で、一貫した設定変更案を返す。1エポックが「スコアリング→リフレクション→ガードレール検証」のサイクルで、エポックを重ねるほど品質が上がる。

Sub-Agent Reflector（実験的・OSSで公開）

複数のサブエージェントが各トレースを独立して分析し、オーケストレーターが知見を集約する。各サブエージェントは1トレースに対して3段階の分析を行う：

• Surface：報酬、難易度、結果の抽出
• Turn level：jqやgrepでロールアウトJSONを解析し、軌道が最適パスから外れた意思決定ポイントを特定
• Cognitive：その意思決定ポイントでなぜ失敗したかを診断し、修正ガイダンスを提示

サブエージェントが独立したコンテキストウィンドウで動作するため、他のトレースに引きずられない分析が可能になる。実験的実装はStrandsのOSSリポジトリで公開されている。

ガードレールの設計

最適化の副作用として起きがちな問題——プロンプトの際限ない肥大化、トレースフレーズの丸ごとコピー、安全制約の緩和——に対して、3つのルールベースガードレールを適用する：

• 長さ上限：前バージョンより20%超の増加は却下し、短縮を要求
• 安全チェック：安全基準に照らしたスクリーニング
• トレースフレーズの流用禁止：最適化対象トレースの文言の丸ごと再利用を禁止（訓練トレースへの過学習防止）

ベンチマーク結果

AppWorldとWebShopの2つの公開ベンチマークで評価が行われた。比較対象となったのは、プロンプト最適化手法であるGEPA（Gradient-free Evolution of Prompt Agents）とMIPROv2（DSPyのプロンプト・デモ同時最適化オプティマイザー）の2手法だ。

2つの手法でそれぞれ異なる強みが示されている。

Single Agent Reflectorはコスト効率が最良。AppWorldでGEPAと同等以上のスコアを出しながら、最適化時間はGEPA比で18倍速、MIPROv2比で36倍速の6分で完了する。速度と精度のバランスを重視する場面で有効な選択肢となる。

Sub-Agent Reflectorは最高品質。AppWorldでは95.83%と、ベースラインから23ポイント改善、次点手法からも16ポイント上回る。ただし最適化に193分を要しており、速度優先のSingle Agent Reflectorとは明確にトレードオフの関係にある。失敗モードが多様なタスクで、1回のパスでは見落とすマイノリティパターンをサブエージェント分解が拾い上げる効果が出ている。

なお、評価に使用されたモデルはリフレクターがClaude Opus 4.6、タスク実行がClaude Sonnet 4.5と記載されている（※これらのモデル名は記事公開時点で一般に広く流通しているバージョン表記とは異なる場合があるため、最新のモデル情報はAmazon Bedrockの公式ドキュメントを参照されたい）。

実運用に向けたベストプラクティス

記事では以下の指針が示されている：

• トレースセットは10〜50件から始める。多様性が重要で、推奨が狭すぎる場合にのみ拡大する
• スカラー報酬だけでなく自由記述フィードバックも活用する。評価者の根拠、人手アノテーション、ユーザーの苦情などをトレースファイルに含めることで、リフレクターがそれを読める
• システムプロンプト以外にも応用できる。ツール説明やスキル定義の改善にも同じトレース分析・検証ワークフローが使える
• 推奨案は必ずレビューとA/Bテストで検証してから本番投入する

特筆すべきは、「自由記述フィードバックも読める」という設計の含意だ。スカラー値しか受け付けない従来の最適化ループと異なり、人間のレビュアーが残したコメントや顧客サポートのログをそのままトレースに添付できる。数値化しにくい品質観点をリフレクターに伝える現実的な手段として、実運用では重要なポイントになるだろう。（※編集部の考察）

詳細はOptimizing agent system prompts with Amazon Bedrock AgentCoreを参照していただきたい。