AIのプロンプト改善を勘から評価へ｜AgentCoreの成功率95.83%をどう読むか

公開日 2026.09.17 更新日 2026.09.17 Amazon Bedrock AgentCore プロンプト最適化 AI評価 AppWorld

AIが失敗したら、プロンプトに注意書きを足す。それを繰り返すうちに、指示が長くなり、何が効いたのか分からなくなる——業務用エージェントで起こりやすい問題です。

AWSは2026年9月16日、AgentCoreのシステムプロンプト最適化について、仕組みと公開ベンチマーク上の評価を説明しました。本稿はその数字を入口に、「改善案を作る」と「改善を証明する」を分ける運用を考えます。9月16日は技術解説の公開日であり、機能の初回提供日とは区別します。AWS公式解説

① 実行記録を分析してプロンプト修正を提案し、評価で採否を決める。

② AWSの評価では、短時間の改善と高い到達スコアにトレードオフがある。

③ 公開ベンチマークの最高値を、自社業務の成功率と読み替えない。

背景：文章を直す前に、失敗した判断を探す

エージェントの品質は、最後の回答文だけでは分かりません。間違った検索条件、不要なツール呼び出し、確認不足など、途中の判断が結果を左右します。

実行記録の「トレース」は、こうした行動を追うための材料です。AgentCore optimizationは、トレースと対象の評価基準を使い、システムプロンプトやツール説明の改善案を生成します。設定を版管理するconfiguration bundlesと、実トラフィックで比較するA/B testingも提供されています。最適化の公式概要

前回の提案・検証・実行を分離する記事は、本番操作の権限境界がテーマでした。今回はエージェントの設定変更を、測定して採用する工程がテーマです。

最新の評価：速い改善と高いスコアは同じではない

AWSはSingle Agent Reflectorと、実験的なオープンソースのSub-Agent Reflectorを比較しています。前者は単一の分析役、後者は個別トレースを分担分析する設計です。表は公式記事のAppWorld評価から必要な指標だけを整理しました。評価条件・元表

AppWorld：各手法で探索した設定の最高結果（AWS報告）
手法	成功率	最適化時間	ターン数
GEPA	79.63%	108分	100
MIPROv2	74.40%	216分	100
Single Agent Reflector	81.55%	6分	20
Sub-Agent Reflector（実験的）	95.83%	193分	100

成功率だけを見るとSub-Agentが高い。時間は上の表で比較する。

GEPA / 79.63%

MIPROv2 / 74.40%

Single Agent / 81.55%

Sub-Agent（実験的）/ 95.83%

横軸は0〜100%。同一の尺度・始点で表示。

評価の分析モデルはOpus 4.6、タスク実行モデルはSonnet 4.5です。WebShopではSingleが78.31%、Sub-Agentが79.15%でしたが、こちらの指標名はRewardで、AppWorldの成功率とは異なります。最適化時間は本番リクエストの応答時間ではありません。公式評価

本稿はAWSの報告値を確認・再表示したもので、独立した再実験ではありません。提供元の結果であること、設定探索後の最高値であることを踏まえて読みましょう。

二つのベンチマークは何を測っているのか

AppWorldは複数アプリをAPI経由で操作するシミュレーション環境です。タスクは状態や実行結果に基づくテストで評価されます。単に回答が自然かどうかではなく、環境に対して必要な操作ができたかを見るためのベンチマークです。AppWorld公式サイト

WebShopは、商品要件に合うものを探し、選択・購入する模擬EC環境です。報酬は属性、種類、オプション、価格などの一致を使って計算されます。部分的な一致にも情報がある報酬を、取引の完全成功件数と同じものとして扱うべきではありません。WebShop公式サイト

技術的なポイント：設定とコードを分けて評価する

AgentCoreのconfiguration bundleは、プロンプト、モデルID、ツール説明などの変更不能な版付きスナップショットです。変更の対象を記録できるため、「どの設定で失敗したか」を追いやすくなります。bundleは必須ではなく、別のruntime endpointで検証することもできます。設定と最適化

A/B testingはGatewayを通して二つの候補にトラフィックを振り分けます。同じruntime session IDは同じ候補に固定されるため、会話の途中で設定が変わる比較を避けられます。コード変更も含むなら別ターゲット、設定だけならbundleという選択肢があります。A/B testing仕様

ただし、機能があるだけで良い実験になるわけではありません。以下は本稿の編集上の導入提案です。

修正案を本番に入れるまで

失敗を分類する
改善用データで修正案を作る
未使用のテストで比較する
限定した実トラフィックで検証する
採用・撤回の判断を記録する

実践例：社内ヘルプデスクの改善実験

これは説明用の設計例で、AWSの顧客実績ではありません。対象は、問い合わせを読み、社内手順を探し、回答案を出すエージェントとします。

評価対象を固定する。 回答の正しさ、参照先の妥当性、権限外の操作がないこと、費用、処理時間を別々に測る。
データを案件単位で分割する。 同じ問い合わせの言い換えが改善用とテスト用に混ざらないようにする。個人情報と秘密情報を除去する。
失敗の原因を分類する。 検索失敗、古い文書、不足情報への質問漏れ、誤ったツール引数を区別する。データの問題をプロンプトだけで隠さない。
変更差分をレビューする。 セキュリティ制約が弱まっていないか、特定案件の答えを埋め込んでいないかを確認する。
独立テストと限定A/Bを行う。 比較前に採用条件と中止条件を決める。不可逆な操作は許可せず、既存の承認ゲートを維持する。
元に戻せる状態で採用する。 旧設定と評価結果を保存し、障害時に戻す担当者と手順を決める。

例えば、正答率だけが改善しても、1件の費用が大きく増えたり、必要な確認を省いているなら採用を見送る余地があります。「長いプロンプトほど良い」「分析役が多いほど良い」と決めず、改善速度と許容費用から選びましょう。

開発・保守・運用・コンサルへの影響

開発： プロンプトを試行錯誤の文章ではなく、テスト対象の設定として扱う設計がしやすくなります。
保守： モデルやツールの更新前に、同じテストセットで回帰を確認できます。
運用： 成功だけでなく、少数の失敗パターン、費用の増加、応答時間の悪化を監視する必要があります。
コンサル： モデルのランキングだけでなく、顧客の業務を評価可能な案件と採用条件に落とし込む仕事が重要になります。

これらは編集上の見通しです。今回の数字から、自社の工数削減や投資回収率を直接計算することはできません。

リスクと限界：評価スコアへの過適合

自動最適化は、評価基準の弱点を増幅することがあります。採点が「丁寧な文章」を重視しすぎると、正しい処理より説明の長さが優先されかねません。評価用データに似た案件だけが改善しても、未知の案件で通用するとは限りません。

また、A/Bの統計的な有意差は、変更の業務上の価値や安全性を保証しません。少数の重大な誤操作を平均点で隠さないため、重大事故は別の不採用条件として扱うことをおすすめします。比較中にモデル、検索索引、ツール仕様まで同時に変えると、どの変更が効いたのか分かりにくくなります。

今後注目すべき点

確認すべきなのは、ベンチマークの最高値だけではありません。自社の言語・案件・権限で再現するか、最適化にかかるモデル費用が許容範囲か、設定を戻せるかが重要です。利用前には、対象リージョン、機能の提供状況、CLI・SDKの版、評価とトレース保存に必要な権限も公式文書で確認してください。

プロンプト改善を「うまい言い回し探し」から「測定可能な変更管理」に移せるか。今回の発表は、その運用を考える材料になります。

最終確認日：2026年9月17日（日本時間）。評価値は9月16日公開のAWS公式解説に基づきます。導入例と採用条件は本稿の編集上の提案です。

参照元

Previous Post Next Post