Amazon Bedrock AgentCore Evaluation、エージェントのリグレッションを失敗したプルリクエストに変える

AmazonはAmazon Bedrock AgentCore evaluationを実運用可能なGitHub Actionsの品質ゲートへ移行し、主観的なエージェントチェックを4つのスコア付きテストに置き換えた。

このリファレンスパイプラインはAIエージェントとOAuthで保護されたModel Context Protocolサーバーをデプロイし、代表的なプロンプトでエージェントを呼び出す。生成されたトレースを採点し、必須メトリクスのいずれかが設定済みのしきい値を下回れば、プルリクエストを失敗させる。

これにより、エージェントテストを巡る論点が変わる。目下の競争はAWSと他のクラウドプロバイダーの対決ではない。多くの開発チームがエージェント変更のマージ前に依然として利用している手作業の抜き取り確認に対し、自動化され、再現可能な評価を対置することだ。

Amazonは2026年9月8日にこの実装を公開した。評価パイプラインは、AgentCore Runtime、AgentCore Evaluations、Amazon Cognito、CloudWatch、AWS CDK、GitHub Actionsを接続する。

重要なのは、また一つテストダッシュボードが増えたことではない。変更されたエージェントの挙動が共有環境や本番環境に到達する前に、失敗した応答が失敗したソフトウェアビルドになり得る点にある。

Amazon Bedrock AgentCore Evaluationがマージゲートになる

AWSはエージェント品質をレビュー時の見解から、プルリクエストの条件へと変えた。

このリファレンスワークフローは、mainブランチを対象とするプルリクエストでエージェントコード、MCPサーバーコード、インフラ、または評価スクリプトが変更された際に実行される。2つのAgentCoreランタイムを含む一時的な開発スタックを作成する。

一方のランタイムはStrandsベースのエージェントをホストする。もう一方はMCPサーバーをホストし、AIアプリケーションを外部機能と接続するための標準プロトコルを通じてツールを公開する。

共有のAmazon Cognitoユーザープールが、両方のランタイムを保護する。ワークフローはAWS Cloud Development Kitを通じてこのインフラをデプロイし、デプロイ出力からランタイム識別子と認証エンドポイントを読み取る。

GitHub ActionsはOpenID Connectフェデレーションを通じて一時的なAWS認証情報を取得する。OIDCではGitHubが短命のIDトークンをAWSロールと交換できるため、リポジトリのシークレットに恒久的なAWSアクセスキーを置く必要がない。

ワークフローは引き続きAWSロールARNをGitHubシークレットとして保存する。ただし、得られるAWS認証情報は一時的であり、ロールの信頼ポリシーと権限ポリシーによって制限される。GitHubはこのOIDCセキュリティモデルを文書化している。

デプロイ後、パイプラインは両方のランタイムが準備完了になるまで待機する。新たに作成されたランタイムは直ちにリクエストを受け付けられないため、この待機は運用上重要である。

AWSによると、早すぎる呼び出しは424 Failed Dependencyレスポンスを返す。提供されているワークフローは、テスト実行を開始する前にAgentCoreコントロールサービスをポーリングし、MCPサーバーをウォームアップする。

続いてパイプラインはOAuthアクセストークンを取得し、テストプロンプトをエージェントのHTTPSエンドポイントへ送信する。各プロンプトには固有のセッション識別子が付与され、評価プロセスは出力されたトレースを正しいインタラクションと関連付けられる。

サンプルデータセットは複数の行動パターンを対象とする。エージェントに単純な合計の計算、現在のUTC時刻の返答、Apple株価の検索、従業員数の取得を求める。

これらの例が検証するのは、回答文言だけではない。組み込み機能、公開MCPツール、保護された業務ツール、ツール選択、そして選択された各ツールへ渡すパラメーターをテストする。

評価スクリプトは4つの組み込み評価器を適用する。

• GoalSuccessRateは、セッションがユーザーの目的を達成したかを問う。

• Correctnessは、応答を利用可能な期待値またはコンテキストと比較する。

• ToolSelectionAccuracyは、エージェントが適切なツールを選択したかを確認する。

• ToolParameterAccuracyは、エージェントが適切な引数を指定したかを確認する。

リファレンス構成では、受け入れしきい値として0から1のスケールで0.8を使用する。必須スコアがこの水準を下回ると、スクリプトは失敗として終了し、GitHubはジョブを失敗とマークする。

ワークフローは評価結果をプルリクエストに投稿することもできる。レビュアーは、ログやローカルでの会話からエージェントの挙動を再構築する代わりに、コード変更と並んで測定された失敗を確認できる。

最後に、クリーンアップステップは評価が失敗した場合でも実行される。失敗したプルリクエストによって開発用ランタイムが無期限に稼働し続けないよう、一時的なCDKスタックを破棄する。

この一連の流れが中心的な緊張関係を生む。手動テストは明白な問題を見つけられるかもしれないが、関連するすべてのプルリクエストが満たすべき再現可能なルールを提供することはまれだ。

手動エージェントテストはいま圧力を受けている

このパイプラインは、エージェントの応答をソフトウェアデリバリーで検証すべき成果物ではなく、単に確認するものとして扱うチームに圧力をかける。

従来のアプリケーションテストには明確な出力がある。関数が期待値を返す、APIがスキーマに一致する、あるいはデータベース操作が不変条件を維持するといったものだ。

AIエージェントはこのモデルを複雑にする。応答は変動し得るため、最終的な文が正しいだけでは、エージェントが許容可能な経路をたどった証明にはならない。

ツールを使うエージェントは、誤ったサービスを選択したり、権限のない結果を開示したり、不正な形式のパラメーターを送信したりする可能性がある。また、コストが高い、あるいは安全でない呼び出しの連鎖を通じて、もっともらしい回答に到達することもある。

プロンプトの変更も別の問題を生む。システム指示をわずかに調整するだけで、無関係なシナリオにわたってツール選択、拒否動作、応答の詳細度、タスク完了状況が変化し得る。

モデル更新や依存関係の変更も同様のリスクをもたらす。従来のユニットテストはアプリケーションが動作することを確認できる一方、挙動の重大な低下を見逃す可能性がある。

チームはしばしば手動のプロンプトセットで補う。開発者がいくつかの馴染みのある質問を入力し、回答を読み、明らかに問題がなければマージする。

この手法はカバレッジが弱く、判断も一貫しない。また、2つのリビジョンの間でどの挙動が変わったのかについて、ほとんど証拠を残さない。

AWSのパイプラインは、関連するすべてのプルリクエストに共通の評価経路を追加する。提案されたコードをデプロイし、そのコードを実行し、テレメトリーを収集して、同じ評価器を適用する。

AgentCoreはOpenTelemetryスパンを利用する。これは、インタラクション内のモデル呼び出し、ツールアクティビティ、その他の操作を構造化して記録したものだ。AgentCore ObservabilityはこれらのトレースをCloudWatchへ送信する。

オンデマンド評価では、パイプラインは特定のセッションからスパンを選択し、評価サービスに渡す。評価モードには、オンライン監視と非同期バッチ分析も含まれる。

この違いはデリバリーチームにとって重要だ。オンデマンド評価は、小規模で制御されたインタラクション群を対象に詳細なスコアを返すため、プルリクエストに適している。

オンライン評価は別の目的を担う。デプロイ済みのトラフィックをサンプリングし、テストデータセットが想定しなかったリクエストを実際のユーザーが生成するリリース後の挙動を追跡する。

バッチ評価はより大規模なセッション群を処理する。ベースライン比較、定期監査、変更前後の分析により適している。

プルリクエストゲートは、これらのモードを置き換えるものではない。最も早く測定可能なチェックポイントを、コード変更により近づけるものだ。

このアプローチは、リグレッションへの対応者も変える。ゲートがなければ、品質チームやユーザーがデプロイ後に問題を発見することが多い。

必須のGitHubチェックがあれば、作成者はマージ前に失敗した挙動へ対処しなければならない。関連するコードやプロンプトの判断がまだ記憶に新しいうちに、フィードバックが届く。

これは共有エージェントを保守するチームに特に有用だ。ある開発者には問題なく見える応答変更が、別グループが所有するツールワークフローを壊す可能性がある。

厳選された評価データセットは、こうした期待を維持できる。エージェントが継続して実行すべきタスクの実行可能な記録となる。

開発者は、こうした期待の背景にある補足コンテキストにもアクセスする必要がある。エンジニアリングナレッジベースは、チームが評価ケースを仕様、インシデント、設計判断と結び付ける助けになる。

より大きな変化は組織的なものだ。エージェント品質は、誰かに十分な時間があるときに実施される任意のレビューではなく、マージ可能な変更の定義の一部となる。

OAuthによりエンドツーエンドテストはスコアリング以上に難しくなる

難しいのは評価スコアを要求することではない。保護されたエージェントの完全なツール経路を、ヘッドレスCIランナー内で再現することだ。

リファレンスアーキテクチャでは、エージェントとMCPサーバーの両方をCognitoの背後に配置する。対話型ユーザーは認可コードフローを通じて認証し、スコープとカスタムロールクレームを含むトークンを受け取る。

これらのロールが、ユーザーがアクセスできるMCPツールを決定する。財務部門のユーザーと人事部門のユーザーが、同じ業務機能を自動的に受け取るべきではない。

GitHub Actionsには対話型ユーザーがいない。認可画面を開き、ブラウザログインを完了し、個人のロールコンテキストをテストに引き継ぐことはできない。

AWSは、この不一致を扱う3つの方法を示している。それぞれがシステムの異なる部分を検証する。

第1のアプローチは、保存済みトレースを評価する。ステージングプロセスが事前にエージェントを呼び出し、代表的なテレメトリーを取得して、それらのトレースをテストフィクスチャとして保存する。

プルリクエストジョブは、ライブのエージェントやMCPサーバーを呼び出さずにフィクスチャを評価する。このアプローチは予測可能であり、CIの認証問題を回避できる。

ただし、重大な制約がある。スコアが示すのは以前に取得された挙動であり、必ずしも現在のプルリクエスト内のエージェントコードではない。

保存済みトレースは、評価器の変更を検証したり、履歴的なベースラインを維持したりできる。新たに変更されたランタイムコードが、依然として期待どおりの軌跡を生み出すことを証明することはできない。

第2のアプローチでは、専用のサービスアカウントを使用する。運用担当者が一度だけ対話型認可を完了し、そのリフレッシュトークンをシークレットマネージャーに保存する。

これによりCIは、定義済みのロールを持つ既知のユーザーとして振る舞える。特定のIDに対する認可境界とツールアクセスをテストできるようになる。

リフレッシュトークンは期限切れになったり、無効になったりする。チームにはローテーション、再認可、そしてアカウント権限の慎重な管理が必要となる。

AWSの実装は第3の方法、すなわちマシンツーマシン認証を選択している。CognitoはOAuth client_credentials grantを通じてトークンを発行する。

評価スクリプトは、クライアントID、クライアントシークレット、要求するスコープをCognitoのトークンエンドポイントに送信する。その後、返されたベアラートークンを使って、HTTPS経由でAgentCore Runtimeを呼び出す。

MCPミドルウェアは、これらのトークンをユーザートークンと区別する。マシントークンにはスコープがある一方でカスタムロールクレームがないため、サンプルではすべてのツールへの到達を許可している。

対話型トークンには引き続きロールが含まれ、MCPサーバーはそれらのユーザーに対してツールレベルの制限を適用する。そのため、同じCognitoプールがCIアクセスと人間の認可の両方をサポートする。

この設計により、プルリクエスト内のコードに対するライブのエンドツーエンドテストが可能になる。エージェントはデプロイ済みのMCPサーバーを呼び出し、評価用の新しいトレースを生成できる。

ただし、ロール適用をテストするものではない。CI IDは設計上、それらのロールチェックをバイパスする。

その境界こそが、このアーキテクチャにおける最も重要な注意点です。パイプラインの成功は、マシンIDが評価対象タスクを完了できることを示します。FinanceUserとHRUserがそれぞれ異なる認可済みの結果を受け取ることまでは示しません。

両方の保証が必要なチームは、認可テストを別途追加する必要があります。特定のロールを持つサービスアカウント、またはMCPミドルウェアに対する直接テストを利用できます。

マシン認証情報も機密資産になります。AWSは、取得できるのはCIパイプラインとエージェントランタイムだけであるべきだとしています。

この主張は実装の詳細に左右されます。リポジトリ権限、ワークフロー承認、IAMポリシー、シークレットの露出、フォーク時の挙動、ログのマスキングはいずれも実際のセキュリティ境界に影響します。

GitHubのOIDC接続は、長期的なリポジトリ認証情報からAWS側を保護します。ただし、OAuthクライアントは依然としてクライアントシークレットを使用するため、すべてのシークレットを排除するものではありません。

IAMロールも最小権限の原則に従うべきです。Cognito、ECR、CDKリソース、Bedrock、AgentCoreへの広範なデプロイ権限は、通常のプルリクエストジョブに必要な範囲を超える権限を生みかねません。

環境保護によりリスクを限定できます。チームは、どのブランチとワークフローがロールを引き受けられるかを制限し、信頼できない変更には承認を要求し、デプロイ用ロールと評価用IDを分離できます。

したがって、このアーキテクチャはエージェントの挙動とCI統合をまとめてテストします。認可の正確性は、依然として別個の受け入れ目標です。

品質ゲートは回答だけでなくトレースを採点する

Amazon Bedrock AgentCoreの評価が重要なのは、最終テキストだけでなく、タスクに至るエージェントの経路も判定できるためです。

評価スクリプトはAgentCoreスターターツールキットを使用して、関連するCloudWatchトレースを収集します。その後、選択したセッションに評価器を適用します。

生のEvaluate APIは、1つのセッションに属するテレメトリスパンの集合であるsessionSpansを受け取ります。AWSは、複数セッションのスパンを混在させると検証エラーになると警告しています。

このセッション境界により、評価器は対話を再構成できます。ユーザー入力、モデル出力、選択されたツール、ツールパラメータ、生成された応答を検査できます。

GoalSuccessRateはセッションレベルで動作します。対話全体がユーザーの要求を達成したかを問います。

Correctnessはトレースレベルで応答を検査します。テストで提供されている場合は、期待される応答を使用できます。

ToolSelectionAccuracyとToolParameterAccuracyはツール呼び出しレベルで動作します。正しい操作を選択したことと、その操作を正しく呼び出したことを区別します。

この分離は、AWSの意図的なリグレッションテストで示唆的な結果を生みました。著者らはシステムプロンプトを変更し、エージェントが常に役に立たない拒否応答を返すようにしました。

GoalSuccessRateは0.0に低下しました。Correctnessも0.0、ToolParameterAccuracyも0.0でした。

一方、ToolSelectionAccuracyは1.0のままでした。エージェントは、リクエスト全体には失敗していても、適切なツールを特定できていたようです。

これが、単一の集約指標では問題を隠し得る理由です。各評価器は独立した次元を捉えるため、1つの合格スコアで他の失敗した挙動を相殺することはできません。

著者らが意図したシステムプロンプトを復元すると、GoalSuccessRateは1.0に戻りました。Correctnessは0.9に達し、2つのツール指標はいずれも1.0に達しました。

4つすべてがサンプルのしきい値0.8を上回りました。GitHubはプルリクエストのブロックを解除しました。

AgentCoreは、期待される挙動を必要とするテスト向けに参照入力も受け付けます。これらの入力には、期待される応答、自然言語によるアサーション、期待されるツール軌跡を含められます。

軌跡は、エージェントが呼び出すべきツールの順序を記述します。AWSは、異なるワークフロー制約に対応するため、完全一致順序、順序保持、任意順序の評価器を提供しています。

完全一致順序のテストは、各ステップが前のステップに依存するプロセスに適しています。任意順序のテストは、順序が正確性に影響しない独立した取得操作に適しています。

このサービスはカスタム評価器もサポートしています。チームは、ドメイン固有の要件に合わせて独自の指示、判定モデル、採点尺度を定義できます。

コードベースの評価器は、より決定論的な選択肢を提供します。AWS Lambda関数を呼び出し、スキーマ、パターン、キーワード、ビジネスルールを検査できます。

この組み合わせが重要なのは、すべての要件にモデル判定が必要なわけではないからです。JSONの有効性、禁止フィールド、最大呼び出し回数、完全一致の識別子は、多くの場合、通常のコードで検証できます。

custom evaluator guideによると、評価器はセッション、トレース、ツール呼び出しの各レベルで動作できます。カスタムロジックにはモデルまたはLambda関数を使用できます。

実用的なゲートでは、評価器の種類を要件に合わせるべきです。モデルベースの採点は、関連性、タスク達成、忠実性といった意味的な品質に適しています。

決定論的なコードは二値制約に適しています。ツール軌跡のチェックは、期待されるワークフロー構造に適しています。

最も有用なシグナルは、これらの手法を組み合わせることで得られます。応答は意味的に正しくてもスキーマに違反することがあり、有効なスキーマでも無関係な回答を含む場合があります。

正解データも慎重に扱う必要があります。特に要約や自由度の高い分析では、すべての許容される回答に唯一の正確な表現があるわけではありません。

アサーションは、単一の回答を強制せずに、必ず含めるべき事実や挙動を表現できます。期待される軌跡は、文章スタイルとは独立してツールの挙動を指定できます。

これにより、テストセットは単なるプロンプトの集合ではなくなります。各シナリオは、応答、タスク、ツールの各レベルで成功の意味を定義できます。

合格スコアにも死角はある

このゲートは定義されたリグレッションを検出しますが、その信頼性はテストカバレッジ、スコアの安定性、ID設計、運用上のタイミングに依存します。

AWSによると、パイプライン全体には約10分かかります。デプロイ、ランタイムの起動、トレースの伝播、モデルベースの評価がこの時間を占めます。

この所要時間は、多くのプルリクエストでは許容できます。一方で、ローカルのpre-commitチェックには遅すぎ、更新頻度の高いリポジトリではコストが増える可能性があります。

トレースの可用性にも不確実性があります。AWSは、エージェント呼び出し後に30〜90秒の伝播遅延を観測しました。

参照スクリプトは、最長10分間、30秒ごとに再試行します。そのため、CloudWatchを直ちに照会すると、トレースがまだ存在しない段階で見かけ上の失敗になる可能性があります。

ランタイムアーキテクチャは、別の実装上の障壁を生みます。AgentCore RuntimeはARM64コンテナイメージを必要としますが、標準のGitHubホステッドランナーはx86-64プロセッサを使用します。

ワークフローでは、クロスプラットフォームのイメージ構築にQEMUとDocker Buildxを使用します。この要件はビルド時間を増加させ、エージェント品質とは無関係の新たな障害点を導入します。

最も重大な制約は、モデルベースの判定にあります。LLM評価器は、同じトレースを複数回評価した場合にわずかに異なるスコアを付けることがあります。

したがって、厳格なしきい値は、しきい値付近のプルリクエストを不安定にする可能性があります。ある実行では0.81で合格しても、意味のあるコード差がないまま別の実行では0.79で失敗することがあります。

AWSは、受け入れしきい値と目標とする信頼性水準の間に余裕を持たせることを推奨しています。チームはチェックを必須にする前に、評価器の分散も測定すべきです。

繰り返し実行すればその分散を推定できますが、評価利用量も増加します。参照例では、5つのプロンプトに4つの評価器を使用し、1つのプルリクエストで20回の判定モデル呼び出しが発生します。

ソースはこれらの呼び出しに価格を付けていません。ただし、リポジトリとデータセットが拡大するにつれてBedrockの利用状況を監視するようチームに助言しています。

テストカバレッジは、馴染み深いながらもより鋭い問題を提示します。品質ゲートが測定できるのは、そのデータセットに含まれるシナリオだけです。

手近な4〜5個のプロンプトでは、すべての本番リクエスト、認可状態、障害モード、言語、敵対的入力を表現できません。

サンプルのマシントークンは、すべてのツールにアクセスできます。その結果、エンドツーエンド実行は、ロールで制限されたツールが一般ユーザーから保護され続けることを証明しません。

広範なスコアは、性能の偏りも隠し得ます。全体平均は合格でも、重要なシナリオの1つが失敗している場合があります。

高リスクなタスクには、シナリオレベルの要件を設けるべきです。給与処理、アカウント削除、個人データ照会が、いくつもの簡単な算術プロンプトの成功によって救済されるべきではありません。

指標にも責任者が必要です。誰がしきい値の変更を承認し、新しいシナリオを追加し、評価器間の不一致を調査するのかを、開発者は把握していなければなりません。

そうでなければ、失敗したゲートはしきい値を下げる圧力を生みます。組織は測定を弱めることで、デリバリー速度を維持することになります。

誤った安心感も別のリスクです。緑のチェックは、テスト対象バージョンがある時点で指定された基準を通過したことを示します。

それは、すべての応答を保証するものでも、プロンプトインジェクションを排除するものでも、デプロイ済みテストスタックの外側にあるインフラを検証するものでもありません。また、セキュリティレビューの代わりにもなりません。

ユーザーはキュレーションされたデータセットが見逃した組み合わせを発見するため、本番テレメトリは引き続き不可欠です。AgentCoreのオンライン評価は、ライブセッションをサンプリングし、結果をCloudWatchに公開できます。

results documentationによると、オンラインスコアはCloudWatchメトリクスとして表示されます。詳細な評価イベントは専用のロググループに保存されます。

バッチ評価では、モデル、プロンプト、ツールの変更前後で、より大きな期間を比較できます。この比較は、1回のプルリクエスト実行よりも強力なベースラインを提供します。

成熟したシステムは、これらの段階を結び付けるべきです。本番での失敗は新たな評価シナリオに変換し、CIでの繰り返しの失敗はエージェント設計に反映すべきです。

品質ゲートが最も信頼できるのは、データセットがインシデントとともに進化するときです。静的なベンチマークは、やがて信頼できる挙動ではなく、テストへの慣れを報いるようになります。

最初のGitHub Actionsゲートの後に注目すべきこと

次の試金石は、これらのゲートを安定させ、セキュリティを考慮し、必須チェックにできるほど十分に代表的なものにできるかどうかです。

最初のシグナルは、プルリクエストワークフローでの正解データと決定論的評価の採用です。4つの組み込み指標は有用な出発点を提供しますが、すべてのビジネスルールを表現するものではありません。

チームが高価値シナリオ向けに、期待される応答、アサーション、ツール軌跡を追加するか注目してください。Lambdaベースのチェックの利用が増えれば、エージェント評価が通常のソフトウェア検証になりつつあることを示すでしょう。

この進展はAmazon Bedrock AgentCore評価の有用性を強めるでしょう。1つのモデル判定への依存を減らし、一部の失敗を再現しやすくします。

2つ目のシグナルは、ロールを考慮したCIカバレッジです。AWSは、選択したフローがユーザーロールのチェックをバイパスするため、マシントークンの制約を明確に指摘しています。

チームは、脆弱なリフレッシュトークン操作を生まずに異なるユーザーIDをテストするパターンを公開すべきです。サービスアカウント、直接的な認可テスト、分離されたテストテナントが有力な経路です。

ロール固有のチェックが一般的になれば、このアーキテクチャは完全なエンドツーエンド保証に近づきます。別々のまま、あるいは存在しないままであれば、エージェントの緑のスコアは認可の正確性についてほとんど語りません。

3つ目のシグナルは、プルリクエストゲートと本番結果の接続です。実際のセッションからのフィードバックがなければ、小規模な開発データセットは代表性を維持できません。

低スコアの本番トレースをレビュー済みのリグレッションケースへ昇格させるワークフローに注目してください。オンライン監視は失敗を発見し、キュレーションされたCIテストはその失敗の再発を防ぐべきです。

AWSのデータセット評価ツールも関連する進展です。dataset runnersは、エージェントを呼び出し、テレメトリを待機し、協調したプロセスを通じてシナリオを評価できます。

より幅広く採用されれば、参照ワークフローで現在見られるカスタムオーケストレーションを減らせます。また、より大規模でバージョン管理された評価セットを維持しやすくなります。

開発者にとって、実務上の問いはもはや、エージェントの応答をテストすべきかどうかではありません。どの振る舞いがマージを阻止すべきか、どれを監視すべきか、そしてどれに決定論的な強制を求めるべきかです。

まず、ロールバック、セキュリティインシデント、あるいは重要な業務ワークフローの破綻につながる失敗から始めましょう。それぞれに明確なシナリオと、そのリスクに見合った評価方法を設定します。

次に、意図的にエージェントを壊し、想定した理由でゲートが失敗することを確認します。既知の回帰を検知できて初めて、そのチェックは信頼に足るものになります。

Amazonは、プロンプトテストから必須のGitHubステータスチェックへ至る、信頼できる道筋を示しました。次の一歩はエンジニアリングチームの手に委ねられています。出荷を許容しない振る舞いを定義し、それをコード化し、その定義を常に最新の状態に保つことです。