Amazon Bedrock AgentCoreのスキル評価が、流暢なエージェントが隠す問題を明らかにする
Amazonは9月22日、洗練された最終回答の枠を超えてエージェントの振る舞いを検証する3つのチェックを追加し、Amazon Bedrock AgentCoreのスキル評価を導入した。このリリースは、テストにおいて根強く残る盲点を対象としている。エージェントは、誤ったスキルを選択したり、必須の手順を飛ばしたり、業務プロセスを即興で処理したりしても、正しそうに聞こえる場合がある。
新しい評価器は、チームがしばしば単一のスコアにまとめてしまう2つの問いを分離する。エージェントは適切なスキルを選択したか、そして読み込んだ後にそのスキルに従ったか。Strands Evalsは、テストで呼び出すべき名前付きスキルがすでに分かっているチーム向けに、3つ目の決定論的チェックを加える。
この区別は、回答品質だけを中心に据えた評価システムに再考を迫る。有用性、関連性、正確性は依然として重要だが、ルーティングや実行に関するすべての失敗を明らかにできるわけではない。現在の本質的な対立は、最終回答の採点と、エージェントがその回答に至るまでの軌跡に関する証拠との間にある。
Amazon Bedrock AgentCoreのスキル評価、1つの失敗を3つに分解
AWSはスキル利用を、最終回答だけを成功の十分な証拠と見なすのではなく、測定可能な一連のプロセスへと変えつつある。
スキルとは、エージェントに専門的な手順を教える再利用可能な指示パッケージである。通常は、その目的、起動に関するガイダンス、必須のステップを記したSKILL.mdファイルを含む。ハーネスが利用可能なスキルを提示し、エージェントがリクエストに対してどのスキルを読み込むかを決定する。
この構造により、開発者は詳細な手順を肥大化するシステムプロンプトから切り出せる。企業は、請求書照合、契約書の秘匿化、インシデントのエスカレーション、プルリクエストレビューなどに、それぞれ別のスキルを作成できる。エージェントは、すべての対話であらゆる手順を保持するのではなく、必要なときに関連する指示を読み込む。
移植性も魅力の一部だ。オープンなAgent Skills形式は、互換性のあるエージェント環境に、専門的な指示をパッケージ化する共通の方法を提供する。したがって、スキルは単一のモデル呼び出しに結び付いたプロンプト断片ではなく、運用上の成果物として機能できる。
ただし、モジュール化された指示は一連の判断を導入する。エージェントはユーザーの意図を認識し、適切なスキルを見つけ、それを呼び出し、内容を読み、定められた手順を完了しなければならない。優れた最終段落だけでは、この連鎖が機能したことを証明できない。
AWSとStrandsチームは現在、この連鎖を3つの評価器に分割している。9月22日のスキル評価リリースによると、その内容は以下の通りだ。
Skill Selection Accuracyは、呼び出された各スキルがタスクに適していたかを問う。呼び出されたスキルごとに二値の結果を返す。これにより、エージェントが別のワークフロー向けの指示を読み込んだ際のルーティングミスが可視化される。
Skill Instruction Followingは、エージェントが呼び出したスキルで規定されたステップをどの程度完全に実行したかを検証する。評価はFully Followed、Mostly Followed、Partially Followed、Minimally Followed、Not Followedの5段階である。文書化された数値は、1.0から0.0まで0.25刻みで設定されている。
Skill Invokedは、Strands Evals内でより限定的かつ決定論的なアサーションを提供する。エージェントが名前付きスキルを正常に読み込んだかを確認する。他の2つの評価器とは異なり、適切性や遵守度をモデルに判断させない。
これらの指標は異なる問いに答える。必須の給与計算スキルが一度も読み込まれなければ、ルーティング失敗となる。無関係な出張リクエストに対して読み込まれれば、選択失敗となる。正しく読み込まれても承認ステップを省略すれば、指示遵守の失敗となる。
この分離こそが中心的な変更だ。チームは、成果が弱いすべてのケースを曖昧なエージェント品質の問題として解釈する必要がなくなる。それぞれのパターンを異なるコンポーネントと、より焦点を絞った修正に結び付けられる。
呼び出しが欠けている場合は、検出ルール、説明、またはルーティングロジックに注意を向けるべきだ。不適切な呼び出しは、スキルの適用範囲が重複していることを示唆する。正しく選択されたスキルの遵守度が低い場合は、そのステップ、構造、利用可能なツール、または基盤モデルに注目することになる。
このリリースは既存の品質評価を置き換えるものではない。動的に読み込まれる手順に動作が依存するエージェント向けに、別のレイヤーを追加するものだ。出力の正確性は依然として不可欠だが、より大きなテスト記録の一部になる。
流暢な回答だけでは、もはや十分な証拠にならない
軌跡評価を支持する最も強い論拠は単純だ。異なる内部的な失敗でも、同じように説得力のある文章を生み出し得る。
外部共有の前に契約書を秘匿化するよう、従業員がエージェントに依頼する場面を考えてみよう。エージェントは明白な氏名を削除し、整った見た目の文書を返すかもしれない。しかし、承認済みのスキルでは、メタデータ、非表示コメント、変更履歴、添付ファイルへの参照も確認することが求められている可能性がある。
最終文書だけを見るレビュー担当者は、こうした省略されたチェックを見落とすかもしれない。組織の実際の取り扱い手順に違反していても、回答は有能に見えることがある。Skill Instruction Followingは、記録された行動を各規定ステップと比較するために設計されている。
同じ問題は財務業務にも現れる。請求書照合エージェントは、非公式な推論によって正しい合計額を出すかもしれない。スキルがベンダーの身元と購買承認の検証を求めているなら、その結果は手順上なお不完全である。
この区別は、コンプライアンスの観点で特に重要になる。組織が重視するのは、1つの回答がたまたま許容可能だったかどうかだけではない。再現可能な統制が、必要な順序と文脈で適用されたという証拠も必要とする。
従来のソフトウェアテストでは、決定論的な関数に対して正確な期待値を設定できる。エージェントは、同じプロンプトでも異なる文章、ツール呼び出し、推論経路につながり得るため、異なる振る舞いをする。AWSは以前、1回の成功実行が示すのは起こり得ることにすぎず、通常起こることではないと主張していた。
こうしたばらつきは、集約された回答スコアを魅力的に見せる。チームはデータセット全体の正確性や有用性を平均し、その数値が上昇しているかを追跡できる。しかし平均値は、ワークフローのどこで失敗したか、同じステップが繰り返し抜け落ちているかを隠してしまう。
スキル単位の結果は、より有用な診断単位を提供する。エージェントが1つのセッション中に複数のスキルを呼び出す場合、評価器は呼び出しごとに結果を返す。そのため、弱い集計結果を、それを押し下げた特定のスキルまで追跡できる。
このアプローチは、チームによるスキルの書き方も変える。曖昧な段落は人間の作成者には理解できても、一貫して評価するのは難しい。番号付きで観測可能なステップは、判定器により明確な証拠を与え、漏れの特定も容易にする。
これは、すべての内部思考が利用可能になるという意味ではない。評価は、可視のメッセージ、スキル読み込みアクション、ツール呼び出しを含む、記録された軌跡とトレースに依存する。プライベートなモデル推論は、必要とされず、公開もされない。
重要なのは運用上の証拠だ。エージェントはスキルを読み込んだか。どのスキルを選んだか。記録されたアクションは、規定のチェックを完了したことを示しているか。この証拠は、隠された推論に関する推測よりも実行可能性が高い。
この変化は、完成した計算を確認することと、その周囲の統制を監査することの違いに似ている。どちらの視点も重要だが、答える問いは別だ。一方は成果物を測定し、もう一方はそれを生み出したプロセスを測定する。
社内向けエージェントを構築するチームにとっては、多くの場合、プロセスの方が組織上のリスクが大きい。流暢な回答は一度だけユーザーを満足させられるかもしれない。だが、承認、開示、検証のステップを省略すれば、同じ条件が再発するたびにワークフローが損なわれる可能性がある。
新しい評価器により、この手続き上の隔たりをより明確に言語化できるようになる。また、他のエージェントプラットフォームにも、互換性のある軌跡を公開するよう圧力をかける。観測可能なスキルイベントがなければ、チームは呼び出し漏れと抽出失敗を確信を持って区別できない。
Strands Evalsが開発工程にチェックを導入
Strands Evalsは、スキルのルーティングと実行を、本番トラフィックがテストスイートになる前に検証するローカルテストレイヤーを開発者に提供する。
Strands Evalsは、エージェントおよび言語モデルアプリケーションを評価するためのオープンソースフレームワークである。公開されている機能には、出力採点、軌跡分析、ツール評価、シミュレーション、実験、トレースベース評価が含まれる。
プロジェクトの評価リポジトリでは現在、3つすべてのスキルチェックが文書化されている。開発者は、記録済みのセッションまたは生のメッセージ軌跡に対して、Skill Selection AccuracyとSkill Instruction Followingを実行できる。
判定器ベースの評価器は、エージェントを再実行するのではなく軌跡を読む。これにより、失敗後の調査や保存済みセッション間の比較が可能になる。また、高コストなエージェント実行と、同じ記録に対する反復分析を分離できる。
Skill Invokedは別のテストニーズに対応する。回帰ケースに既知のルーティング要件が1つある場合、開発者は期待されるスキルが読み込まれたことをアサートできる。このチェックは決定論的であり、判定モデルを必要としない。
そのため、リリースゲートに適している。アカウント閉鎖に関するカスタマーサポートのリクエストでは、承認済みの閉鎖スキルが一貫して読み込まれるべきだ。改訂された説明によって呼び出しが妨げられた場合、回帰テストはデプロイ前に失敗させられる。
複数のスキルが妥当に適用できる場合でも、選択精度は有用であり続ける。単一の固定名との比較だけではなく、呼び出されたスキルがタスクに適合するかを問う。この柔軟性は、関連する手順が並ぶカタログや、正当なルーティングのばらつきに対応する。
続いてInstruction Followingが次の段階を検証する。評価器は、読み込まれたスキル内の規定ステップを特定し、それぞれを実施済み、一部実施、または省略としてラベル付けする。これらの判断を用いて、5段階の総合評価を算出する。
この組み合わせにより、コンパクトなテストマトリクスが生まれる。
選択スコアが高く、指示遵守が弱い場合、ルーティングは機能したが実行は機能しなかったことを意味する。エージェントは正しい手順を見つけたものの、その要件を省略した、または一部しか完了しなかった。
選択が弱く、指示遵守が強い場合、エージェントは読み込んだ手順には従ったが、その手順はリクエストに対して誤っていたことを意味する。スキル内部の文言を改善しても、そのルーティングエラーは解決しない。
呼び出し漏れには特別な対応が必要だ。AWSは、スキルが1つも呼び出されなかった場合、2つの判定器ベース評価器はスコアを返さないと説明している。名前付きスキルが必須の場合、チームはそれらをSkill Invokedと組み合わせるべきだ。
この挙動により、誤解を招く成功判定を防げる。評価器は、一度も読み込まれなかった指示への遵守を判断できない。ただし、テストスイートが非呼び出しを明示的に失敗として扱わない限り、空の結果がダッシュボード内で見えなくなる可能性がある。
Strandsはハーネスにも計装上の負担を課す。その抽出器は、軌跡から利用可能なスキルと選択されたスキルを認識しなければならない。プロジェクトは複数の既知の環境に加え、SKILL.mdファイルを読み取る汎用パターンをサポートしている。
スコアを信頼する前に、開発者は抽出を検証すべきだ。スキルシグナルを認識できないハーネスは、エージェントがスキルを利用していても空の結果を生成する可能性がある。それは正しい振る舞いの証拠ではなく、可観測性の欠落だ。
この注意点は、カスタムオーケストレーションレイヤーを統合するチームにとって重要である。評価品質は、イベントが忠実に記録されることに依存する。チームが最初にテレメトリー契約を検証しなければ、欠落したトレース属性が、エージェントアクションの欠如に見える可能性がある。
したがって、開発ワークフローは2段階で構成されます。まず、評価器がカタログ、呼び出し、スキルの内容、その後のアクションを確認できることを確かめます。次に、それらのアクションがタスクに適合し、指示を満たしているかを測定します。
ローカルの技術ワークフローを維持するエンジニアリングチームにとって、この変更は、検索可能なエンジニアリング・ナレッジベースの価値もあらためて示しています。スキルは手順をエンコードでき、維持管理されたソース資料は、その手順が扱う事実を提供します。
AgentCore、スキル評価を本番トレースへ拡張
AgentCoreは、厳選されたテストで扱われてきたルーティングと指示遵守の問題を、段階的なセッションおよびサンプリングされたライブトラフィックへ拡張します。
Amazon Bedrock AgentCore Evaluationsは、開発環境と本番環境におけるエージェントの挙動を評価するマネージドサービスです。モデル呼び出し、ツール使用、エージェント操作といった構造化イベントを記録するOpenTelemetryトレースを取り込みます。
OpenTelemetryが重要なのは、単一のエージェントフレームワークへの依存を減らせるためです。AgentCoreのドキュメントによれば、このサービスはOpenTelemetryおよびOpenInferenceのインストルメンテーションを通じて、StrandsやLangGraphを含む統合をサポートしています。
このアーキテクチャにより、このリリースはStrands専用機能を超えた役割を持ちます。Strands Evalsはテストケースと記録された開発トラジェクトリを扱います。一方、AgentCoreはStrandsフレームワーク外で生成されたセッションを含め、デプロイ済みエージェントからの互換トレースを評価できます。
AWSは3つの評価モードを提供しています。オンデマンド評価では、選択したセッションを調査したり、直近の変更を検証したりします。バッチ評価では、複数の保存済みセッションを処理し、ベースラインの確立やカタログ改訂版の比較を行います。
オンライン評価では、本番トラフィックを継続的にサンプリングします。チームは評価器、データソース、フィルター、サンプリング率を選択します。その後、AgentCoreは該当するトレースが到着するたびに評価を適用します。
評価モードは、それぞれ異なる運用上の問いを支えます。開発者は失敗した1つのセッションを調査し、保存済みの母集団をスコアリングし、実際のユーザーの間でのみ現れる挙動を監視できます。
この進展は、エージェントテストでよく見られるギャップに対応します。厳選されたプロンプトは、設計者が人々に尋ねられると想定した内容を反映します。本番のリクエストには、略語、欠落したコンテキスト、特殊な言い回し、テスト作成者が想定しなかった組み合わせが含まれます。
スキルカタログも時間とともに変化します。新しいスキルが古い説明と重複すると、どちらのスキルの内部手順も変わっていなくてもルーティングが変化する可能性があります。AWSはこれをカタログドリフトと説明しています。
オンライン評価は、選択スコアの低下を通じて、そのドリフトを明らかにできます。チームはその後、どのスキルが不適切なリクエストを引き寄せ始めたのかを調査できます。修正には、ある説明の対象を狭めたり、近接するスキル間の境界を明確にしたりすることが考えられます。
長いセッションでは別の懸念も生じます。エージェントは会話の序盤ではスキルを確実に実行していても、コンテキストが蓄積するにつれて手順を見失うかもしれません。本番トレースは、孤立したテストプロンプトよりも自然にこうした状況を捉えます。
このマネージドサービスは、対象を絞ったサンプリングにも対応します。AWSのドキュメントによれば、チームは一定割合のセッションを評価するか、条件付きフィルターを適用できます。これにより、すべてのインタラクションを処理せずに、センシティブなワークフローへ重点を置けます。
ただし、サンプリングはダッシュボードの意味を変えます。低ボリュームまたは限定的にフィルターされた評価では、まれな失敗を見逃す可能性があります。チームは対象となったトラフィックを記録し、サンプリングされたスコアを完全なカバレッジとして提示しないようにする必要があります。
本番経路は、正しいテレメトリーにも依存します。AgentCoreはインタラクションをセッション、トレース、スパンに整理します。セッションには会話が含まれ、トレースは1回のやり取りを扱い、スパンは個々の操作を表します。
スキル評価には、何が利用可能だったか、何が読み込まれたか、その後何が起きたかを再構築できる十分な情報が必要です。インストルメンテーションがスキルの内容や呼び出しシグナルを省略すると、評価器は妥当な結果に必要な証拠を得られません。
AWSのAgentCoreガイダンスでは、モデルベースの評価器でスコアリングされる統一トレース形式が説明されています。この標準化は運用を簡素化しますが、アプリケーションが記録しなかったイベントを復元することはできません。
セキュリティチームもトレース内容を精査する必要があります。スキルのテキストには内部手順が含まれる可能性があり、会話記録にはセンシティブなユーザーデータが含まれる場合があります。評価はテレメトリーの価値を高める一方で、アクセス制御と保持方針の重要性も増します。
その結果、単一のテストではなくライフサイクルモデルが生まれます。開発者はローカルで決定論的なゲートを確立し、リリース前に保存済みセッションを比較し、デプロイ後にサンプリングされた挙動を監視できます。各レイヤーは異なる種類の失敗を捉えます。
新たなスコア自体にも評価が必要
モデルベースの評価器は診断の詳細を加えますが、手順への準拠を客観的事実に変えるわけではありません。
Skill Selection AccuracyとSkill Instruction Followingは、ジャッジモデルに依存します。ジャッジはタスク、利用可能な証拠、スキルの指示を読み取ってから評価を出力します。その出力は依然として、記録されたトラジェクトリに対する解釈です。
その解釈は、曖昧な手順によって変わる可能性があります。たとえば、スキルに「続行する前に顧客のステータスを確認する」とある一方で、許容される確認証拠が定義されていない場合があります。あるジャッジはデータベース検索で十分と判断するかもしれませんが、別のジャッジは明示的な確認を期待するかもしれません。
5段階の遵守スケールはニュアンスを提供しますが、誤った精密さを生むこともあります。0.75という評価は、Mostly FollowedとPartially Followedの根底にある区別が判断に依存していても、正確に見えます。
したがってチームは、人によるレビュー済みの例を基準に評価器をキャリブレーションすべきです。目標は、すべてのエッジケースで完全に一致することではありません。組織の実際の手続き上の優先事項を反映する、安定したルーブリックです。
スキルでは重要な手順を観測可能にすべきです。「関連するポリシーを考慮する」は検証が困難です。「現行ポリシーを取得し、リクエストを3つの適格性条件と比較し、結果を記録する」であれば、より明確な証拠が生まれます。
ネガティブケースはポジティブケースと同じくらい重要です。選択ベンチマークには、スキルの領域に似ていても呼び出すべきではないリクエストを含める必要があります。そうしなければ、広すぎる説明が近いタスクすべてで起動することで高スコアを得られてしまいます。
カタログレベルのテストも不可欠です。1つのスキルを単独で評価しても、類似した選択肢が10個並んだ場合のルーティングについてはほとんど分かりません。関連するテスト環境は、エージェントが実際に目にするカタログに似ている必要があります。
決定論的なSkill Invokedチェックにも限界があります。これは、指定されたスキルが読み込まれたことを証明するだけであり、その読み込みが適切または有用だったことを証明するものではありません。チームは、誤ったリクエストに対してスキルを選択していても、完璧な呼び出し率を達成できます。
同様に、強い指示遵守は正しい回答を保証しません。欠陥のあるスキルは誤った手順を規定する可能性があります。エージェントはその手順を忠実に実行しても、安全でない、あるいは不正確な結果を出す可能性があります。
そのため、レスポンスレベルの評価はスキル評価と並行して維持しなければなりません。チームには依然として、正確性、忠実性、有害性、ツールパラメーターのチェック、ドメイン固有の検証が必要です。手順の遵守は、信頼性の1つの側面にすぎません。
公式のプロンプトテンプレートにより、スコアリングロジックを確認できます。そこでは、遵守評価器が手順を特定し、裏付けとなる証拠にラベルを付け、結果を5段階の評価に対応付けることが示されています。
透明性はチームの評価器理解に役立ちますが、検証に取って代わるものではありません。組織は、センシティブなリリース判断にスコアを用いる前に、ジャッジの結果を専門家レビューと比較すべきです。
コストとレイテンシーも本番利用を左右します。ジャッジベースの評価には、元のエージェント実行後に追加のモデル処理が必要です。サンプリングとフィルターはその負荷を抑えられますが、カバレッジも低下させます。
チームは、すべての評価器を1つの見出しスコアに集約することを避けるべきです。単一の複合スコアは、このリリースが取り除こうとしている曖昧さを再び生み出します。選択、呼び出し、遵守、出力品質は、別々のシグナルとして可視化されたままであるべきです。
このリリースでは、ガバナンス上の問題も対象外となっています。誰がスキルを作成できるか、誰が改訂を承認するか、どの手順を必須と定義するかは決定しません。評価は、組織が信頼できるベースラインを確立した後にのみ、逸脱を明らかにできます。
成熟したワークフローでは、テストやルーブリックの変更とともにスキルをバージョン管理します。そうしなければ、スコアが動いた原因がエージェントの変更、指示の変更、評価器の変更のいずれなのかをチームは判断できません。
Amazonはこれらのチェックを、独立したコンプライアンスの証明ではなく診断ツールとして提示しています。それが適切な境界です。これらはエージェントの挙動をよりレビュー可能にしますが、説明責任は依然としてワークフローを定義し検証する人々にあります。
スキル評価が機能しているかを示す3つのシグナル
次の検証点は、チームがスキル単位の証拠を、より安全なリリース、迅速な診断、より優れたスキルカタログへ変えられるかどうかです。
第1のシグナルは、開発段階における決定論的ルーティングゲートの採用です。チームは、指定された1つのスキルが必須となるワークフローを特定し、回帰テストスイートにSkill Invokedのアサーションを追加すべきです。
こうしたゲートがデプロイ前にカタログ変更を捉えるなら、スキル認識型テストの有用性はより強まります。抽出の問題によって空の結果が頻繁に出るなら、インストルメンテーションが引き続き当面の障害となります。
第2のシグナルは、本番の選択スコアがカタログドリフトを明らかにするかどうかです。新しいスキルは、作成者が確実に起動させたいと考えるため、広すぎる説明を伴って追加されることがよくあります。そうした説明は、既存の手順からリクエストを奪う可能性があります。
有用な本番システムは、カタログ更新後にどの呼び出しが不適切になったかを示すべきです。その後チームは、低下を特定の説明、重複、またはリクエストパターンへ結び付けられる必要があります。
再現可能な診断の証拠が得られれば、AWSの中核的な主張は強化されます。影響を受けたスキルを特定せず、集計スコアの低下だけを示すダッシュボードでは、その主張は弱まります。
第3のシグナルは、Skill Instruction Followingと専門家レビューの一致です。組織は、ジャッジの手順レベルのラベルを、その手順を理解している人々の判断と比較する必要があります。
一貫した一致は、リリースゲートやオンライン監視でより広く使う根拠になります。頻繁な不一致は、スキル手順、トレース証拠、または評価器のルーブリックにさらなる改善が必要であることを示します。
チームは小規模なカタログと、意図的に多様化したテストセットから始めるべきです。明確に一致するケース、ニアミス、スキルを必要としないリクエスト、複数スキルを使うワークフローを含めます。エージェントの挙動は依然として非決定的であるため、各シナリオを複数回実行します。
4つの結果を別々に記録します。期待されるスキルが読み込まれたか、すべての呼び出しが適切だったか、必須手順が実行されたか、最終結果が正しかったかです。この構造により、新しい評価器が持つ診断上の価値が保たれます。
次に、不一致を平均化して消すのではなく調査します。手順を省略して正しい答えに至った場合、潜在的な運用リスクが明らかになるかもしれません。忠実な実行後に不十分な答えが出た場合、弱いモデルではなく欠陥のあるスキルが原因である可能性があります。
本番監視は、センシティブまたは高ボリュームのワークフローから始めるべきです。フィルターとサンプリングを意図的に使い、スコアの母集団から除外される対象を文書化します。重大な失敗や評価が争われるケースでは、専門家レビューを利用可能な状態に保ちます。
Amazon Bedrock AgentCoreのスキル評価が重要なのは、何を証拠として数えるかを変えるためです。流暢な出力は依然として価値がありますが、エージェントが組織の手順に従ったかどうかを、それだけで判断することはできなくなります。
実務上の問いは、いまやあなたのものです。チームは、エージェントがどのスキルを選択したのか、なぜその選択が適切だったのか、そしてトレースがどの必須ステップの完了を証明しているのかを説明できるでしょうか。できないなら、スキルを追加する前に、次のテストサイクルへその証拠を組み込んでください。
