本記事は 2025 年 2 月 25 日に公開された Dr. Tomasz Zemojtel、Christopher Gatsch、Dr. Manuel Delpero、Zhan Ying、Dr. Mueller Michael による “ Enhanced Genomic Data Storage and Workflows with MGI, Sentieon, and AWS ” を翻訳したものです。 ゲノム研究の分野はかつてないスピードで進化しており、データストレージと解析に堅牢かつスケーラブルなソリューションが求められています。MGI、Sentieon、Amazon Web Services (AWS) は協業により、ゲノム研究を支援する機能を提供します。研究者や臨床医は、AWS HealthOmics と Sentieon のワークフローを活用することで、MGI のシーケンシング技術の能力を最大限に引き出せるようになりました。これにより、効率的なデータの保管、取得、整理と、大規模で高精度なゲノム解析が可能になります。 本記事では、この統合的な協業のソリューションアーキテクチャ、ワークフローの選択肢、そして研究ラボにおけるハイスループットなゲノム解析の実装の詳細をご紹介します。 ベルリンのMGI 欧州本社におけるハイスループットなゲノムデータ解析 ハイスループットシーケンシング施設は、膨大なデータ量と解析ワークフローの管理に大きな課題を抱えています。ローカルストレージや計算基盤を利用する従来のアプローチでは、データ生成の規模に対応しきれず、処理のボトルネック、高いメンテナンスコスト、複雑なデータセキュリティ要件などが発生しがちです。ラボには、データストレージをシームレスに扱い、スケーラブルな計算リソースを提供し、セキュリティコンプライアンスを維持しつつ、予測可能なコストで利用できるソリューションが必要です。 MGI-tech はバイオテクノロジーイノベーションのリーダーであり、次世代シーケンシング (NGS) とラボオートメーション技術を開発・提供しています。同社のフラッグシップである DNBSEQ プラットフォームは、精密医療、農業、ヘルスケア分野に向けて、高精度かつハイスループットな遺伝子解析ソリューションを提供します。 ベルリンにあるMGI 欧州本社には 3 台のハイスループット T7 シーケンサーが設置されており、週あたり合計で最大 63 テラベース (Tb、テラ塩基) のゲノムデータを生成しています。3 台の T7 シーケンサーが生成したデータは AWS へ安全に転送され、ゲノムデータ向けにスケーラブルかつコストを最適化したストレージソリューションである AWS HealthOmics Sequence Store に取り込まれます。AWS HealthOmics 内では、Sentieon の高性能なプライベートワークフローが実行され、高速かつ高精度なデータ解析が行われます。 この統合型のハイスループットソリューションにより、MGI 欧州本社の研究者や臨床医は、重要なアプリケーションに向けて複雑なゲノムデータから価値ある知見を引き出せます。具体的には、遺伝性疾患の診断、がん研究、医薬品開発、大規模な集団ゲノミクスの研究などが含まれます。 AWS HealthOmics と Sentieon AWS HealthOmics は、ゲノムデータの保管、処理、解析のためのセキュアでスケーラブルなサービスです。HealthOmics Sequence Store は、大量のシーケンシングデータをコスト効率よく保管する手段を提供し、HealthOmics ワークフローとのシームレスな統合によって、下流解析ですぐに利用できる状態を保ちます。保存時の機密性の高い顧客データを保護するため、HealthOmics は AWS Key Management Service (AWS KMS) の AWS 所有のキーを用いてデフォルトで暗号化を行います。カスタマーマネージドキーもサポートされています。 Sentieon は 2014 年から AWS パートナーであり、高速かつ高精度なゲノムデータ処理のために最適化されたバイオインフォマティクスアルゴリズムを開発してきました。HealthOmics ワークフローでは、Sentieon の DNAscope および TNseq パイプラインを、あらかじめ定義された Ready2Run ワークフローとしても、カスタマイズ可能なプライベートワークフローとしても実行できます。 アーキテクチャの概要 図 1 – ベルリンのMGI 欧州本社で実装されたワークフローアーキテクチャ。 図 1 は次の流れを示しています。 MGI DNBSEQ-T7 シーケンサーが 1 週間で最大 21 Tb (テラベース) のデータを CAL 形式 (MGI シーケンサーのベースコールソフトウェアが生成するバイナリファイル形式) で出力します。 MGI ZTRON Lite Pro が CAL ファイルを FASTQ ファイルに変換し、データの受け渡しを可能にします。 FASTQ ファイルは AWS 上の Amazon Simple Storage Service (Amazon S3) に安全に転送されます。 これらのファイルは AWS HealthOmics Sequence Store にインポートされます。また、 HealthOmics Transfer Manager を通じて、ローカルストレージから FASTQ ファイルを HealthOmics Sequence Store に直接アップロードすることもできます。 DNAscope や TNseq パイプラインなどの Sentieon Genomics ソフトウェアは、HealthOmics ワークフロー上で Ready2Run ワークフローとしても、カスタマイズ可能なプライベートワークフローとしても実行できます。 ワークフロー実行の最後に、AWS HealthOmics は生成された BAM および VCF ファイルを S3 バケットへ転送します。 結果は臨床研究者などのユーザーによって参照されます。 Ready2Run ワークフロー: 迅速かつ簡単なセットアップ 迅速でシンプルなソリューションを求める研究者向けに、Sentieon の Ready2Run ワークフローは、あらかじめ構築・最適化されたパイプラインを提供します。数クリックまたはシンプルな API 呼び出しでデプロイでき、固定料金かつ予測可能な実行時間で動作します。これらのワークフローは、次のようなさまざまなゲノム解析タスクに対応するよう設計されています。 DNAscope : MGI シーケンシングプラットフォーム向けに最適化された、生殖細胞系列バリアントコール用パイプライン。 TNseq : 体細胞バリアントコール用パイプライン。GATK の Mutect2 と同等の精度を達成しながら、MGI データではより短い実行時間を実現します。 AWS HealthOmics ワークフローを利用することで、研究者は Sentieon の Ready2Run パイプラインから選択でき、さまざまな解析ニーズ、リファレンスゲノム、シーケンシングプラットフォームに対応する柔軟な選択肢を得られます。これらのワークフローは実行単位で課金されるため、コストを予測しやすく、ハイスループットなゲノミクスプロジェクトに必要なスケーラビリティを提供します。 プライベートワークフロー: 高度なユーザー向けの完全なカスタマイズ より高度な制御やカスタマイズを必要とするチーム向けに、Sentieon は AWS HealthOmics 上でパイプラインをプライベートワークフローとして実行することもサポートしています。これらのワークフローは完全な柔軟性を提供し、研究者が固有のニーズに合わせてワークフローをカスタマイズ・最適化できるようにします。 Sentieon のプライベートワークフローを実行することで、ユーザーは次のことが可能になります。 AWS 向けの Sentieon コンテナイメージを独自に構築する。 パラメーター、リファレンスゲノム、解析結果の出力内容をカスタマイズする。 パイプライン構成を制御しつつ、AWS HealthOmics のインフラストラクチャを活用する。 プライベートワークフローを始めるには、 Sentieon GitHub リポジトリ で提供されている詳細なセットアップ手順に従ってください。このリポジトリには、コンテナイメージ、セットアップスクリプト、WDL および Nextflow の両エンジン向けのワークフローサンプルなど、カスタマイズしたワークフローの構築とデプロイに必要なものがすべて含まれています。プライベートワークフロー向けに Sentieon ライセンスサーバーを有効化する手順については、 Requesting Sentieon licenses for private workflows を参照してください。 まとめ MGI、Sentieon、AWS の協業は、ゲノミクスラボ向けの堅牢なソリューションを提供します。MGI のシーケンシング技術を活用することで、合理化された、かつカスタマイズ可能なワークフローを AWS インフラストラクチャとシームレスに統合して利用できます。また、Sentieon の Ready2Run ワークフローを実行する場合でも、プライベートワークフローをセットアップする場合でも、研究者は AWS HealthOmics を活用して、セキュアでコンプライアンスに準拠した環境で大規模にゲノムデータを保管・解析できます。これにより、より迅速かつ高精度な発見が可能になります。 AWS KMS 暗号化などの組み込みのセキュリティ機能により、コンプライアンスに準拠した環境でのデータ保護が確保されます。また、固定料金の Ready2Run ワークフローは、予測可能なコストと自動化されたリソース管理を提供します。 MGI、Sentieon、AWS のこの協業は、MGI シーケンシング技術を活用するゲノミクスラボ向けに堅牢なソリューションを提供し、より迅速かつ高精度な発見を可能にします。このソリューションは、ハイスループットシーケンシング業務に一般的に伴う処理のボトルネックの解消に役立ちます。 この統合ソリューションをゲノム研究や臨床アプリケーションに実装する方法について詳しくは、 AWS HealthOmics のウェブページや Sentieon GitHub リポジトリ をご覧ください。また、この技術がお客様のゲノム解析ワークフローをどのように加速できるかについて、個別のご相談を承ります。 AWS 担当者 までお問い合わせください。 謝辞 本ブログの作成にご協力いただいた MGI-tech のバイオインフォマティクスサイエンティスト Dr. Liene Astica、フィールドバイオインフォマティクスサイエンティスト Ying Zhan、フィールドアプリケーションサイエンティスト Ongeziwe Mbhele の各氏に感謝申し上げます。 参考資料 AWS for Genomics Solutions AWS Healthcare & Life Sciences Blog Collection AWS Healthcare & Life Sciences – Security and Compliance Genomics Unlocked: MGI-tech の最新ウェビナーシリーズを視聴できます 著者について Dr. Tomasz Zemojtel Dr. Tomasz Zemojtel は、AWS の EMEA 地域におけるヘルスケアビジネス開発マネージャーです。ヘルスケアとテクノロジーのバックグラウンドを持ち、ヘルスケア組織や研究・臨床機関がクラウドサービスを活用してイノベーションを推進できるよう支援することを専門としています。Tomasz は、クラウドコンピューティングを通じて大規模な臨床データセットの可能性を引き出し、個別化医療や統合型ヘルスケアソリューションを前進させることに情熱を注いでいます。仕事以外では、ジョギングや山歩き、海辺で過ごす時間を楽しんでいます。 Christopher Gatsch Christopher Gatsch は MGI のフィールドバイオインフォマティクスサイエンティストで、顧客ワークフローの最適化や BIT 製品体験・ワークフロー効率の向上に注力しています。読書、アウトドア活動、さまざまな国への旅行に情熱を注いでいます。 Dr. Manuel Delpero Dr. Manuel Delpero は MGI のアプリケーションサイエンティスト部門のアソシエイトマネージャーで、顧客ワークフローの最適化と、バイオインフォマティクスとコマーシャル戦略の橋渡しを専門としています。分子遺伝学およびバイオインフォマティクスの博士号を持ち、バイオテクノロジーの技術面とビジネス面の両方において幅広い業界経験があります。ウェイトトレーニング、旅行、新しいビジネス機会の探求に情熱を注いでいます。 Zhan Ying Zhan Ying は人工知能のバックグラウンドを持つ IT スペシャリストで、包括的な BIT ソリューションを提供しています。マシン統合、ユーザーラボのネットワーキング、販売後のトラブルシューティングなど、BIT 関連の IT サポートを担当しています。 Dr. Mueller Michael Dr. Michael Mueller は AWS のシニアゲノミクスソリューションアーキテクトです。ゲノミクスとクラウドコンピューティングの力を組み合わせてヘルスケアを改善する取り組みを支援することに情熱を注いでいます。ロンドンの大都会の探索と、イギリスやヨーロッパのアウトドアの両方を楽しんでいます。 翻訳は Solutions Architect の吉村が担当いたしました。

こんにちは。LINEヤフー株式会社の佐野です。2026年7月6日〜9日にポーランド・ワルシャワで開催された useR! 2026 に参加してきました。私自身は初めての参加です。弊社は過去にも参加してお...

本記事は 2026 年 7 月 23 日 に公開された「 Evaluating AI Agents: A production blueprint with Strands and AgentCore 」を翻訳したものです。 本記事は、Motorway および AWS Prototyping and AI Customer Engineering (PACE) チームと共同で執筆しました。 英国を拠点とするオンライン中古車マーケットプレイスの Motorway は、最大 8,000 のディーラーが最大 2,500 台の車両に入札する日次オークションを運営しています。Motorway は AWS Prototyping and AI Customer Engineering (PACE) と協力し、AI を活用したディーラー向け在庫検索エージェントを構築しました。このエージェントによって、ディーラーの車両の探し方は大きく変わり、何時間もかかっていた手作業のフィルタリングが自然言語での問い合わせに置き換わりました。 課題 エージェントは自信ありげな応答を返します。しかし、実際のお金がかかっている状況で、それが確実に機能すると、どうやって証明すればよいのでしょうか。 ツール選択の誤り は誤った検索結果を招き、ディーラーの信頼を損ないます。 セマンティック検索の誤解釈 は、無関係な結果を返します。「5 年落ちまでのガソリン車、ハイブリッド車、電気自動車」のような問い合わせでは、エージェントが複数の条件を正しく解釈する必要があります。 複数ターンの会話での コンテキストのずれ は、ディーラーが絞り込んだ条件を失わせます。 非決定的な出力 は、1 回だけのテストを信頼できないものにします。 解決策 Motorway と AWS は共同で、エンドツーエンドの評価パイプラインを構築しました。その結果、誤った結果は 8 件に 1 件から 50 件に 1 件へと減り、問題の検知にかかる時間は数時間から数分に短縮されました。 このパイプラインは、Strands Agents SDK と Amazon Bedrock AgentCore を組み合わせています。AgentCore は、AI エージェントを大規模にデプロイして運用するためのフルマネージドサービスです。本記事では、自分のエージェント向けにこのパイプラインを構築する方法を紹介します。 2 段階の評価戦略 。ビルド時のテスト (Strands Agents 向けのオープンソース評価ライブラリ strands-agents-evals を使用) と、本番環境での監視 ( Amazon Bedrock AgentCore Evaluations を使用) にまたがります。 ツールの使い方、推論、出力品質を評価する 3 層のフレームワーク 。 品質ゲートを備えた 5 段階のデプロイパイプライン 。指標がしきい値を下回るとリリースをブロックします。 付属のリポジトリ には、自分のエージェントに合わせて調整できる、デプロイ可能な設計図が含まれています。この設計図は AWS のサービスを使っていますが、その中核となる原則は、本番運用に耐える AI エージェントであればどのようなシステムでも必要となる、システムに依存しない要件です。原則には、3 層の評価フレームワークと、一貫性を測る pass^k 指標の利用が含まれます。 前提条件 本記事の手順を進めるには、次の前提条件を満たす必要があります。 Amazon Bedrock 、 AWS Lambda 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon DynamoDB 、 Amazon EventBridge 、 Amazon CloudWatch 、 Amazon Simple Notification Service (Amazon SNS) の権限を持つ AWS アカウント 。 インストールおよびブートストラップ済みの AWS Cloud Development Kit (AWS CDK) v2。 Python 3.14 以降。 Amazon Bedrock のモデルアクセス を通じた、Anthropic Claude モデルと Amazon Titan モデルへのアクセス。 Python、AWS CDK、およびエージェントの概念 (ツール呼び出し、複数ターンの会話) に関する知識。 所要時間: 初回デプロイに 30〜45 分、自分のドメインに合わせたカスタマイズに 2〜3 時間。 想定コスト: サンプルの評価スイートの実行には、Amazon Bedrock の推論料金として約 5〜10 USD かかります。本番環境の監視コストは、サンプリングレートによって変わります。 セキュリティに関する注記: 付属のリポジトリは、最小権限の AWS Identity and Access Management (IAM) ロールを実装し、API キーを (環境変数ではなく) AWS Systems Manager Parameter Store に保存し、型付きパラメータを使ってインジェクション攻撃を防ぎやすくしています。詳細は リポジトリの README を参照してください。 実例: ディーラー向け在庫検索エージェント Motorway は、ディーラー向け在庫検索エージェントを Strands Agents SDK と Amazon Bedrock AgentCore の上に構築しました。このエージェントは 8 つのツールを公開しており、89 を超える車両属性にわたる構造化フィルタリングと、 LanceDB および Amazon Titan Text Embeddings V2 によるベクトル類似検索を組み合わせています。 これまでディーラーは、CSV と融通の利かないフィルターを使って、何時間もかけて在庫リストを見て回っていました。対話型の AI エージェントの導入により、ディーラーはエージェントに話しかけられるようになりました。たとえば「近くのディーラーにある 2 万 5,000 ポンド以下のディーゼル SUV を探して」や「家族向けのスポーティなオートマ車」のように問いかけます。 ピーク時には約 1,500 人が同時に利用するため、エージェントの挙動を正しくすることは避けて通れません。ツール選択の誤りやセマンティック検索の誤解釈は、ユーザーの信頼に直接影響します。図 1 は、エンドツーエンドのリクエストの流れを示しています。ディーラーは Web インターフェイスから自然言語の問い合わせを送信し、それが Amazon Bedrock AgentCore Runtime にルーティングされます。ランタイムは、Amazon Bedrock のモデル (推論には Claude、埋め込みには Amazon Titan) を使いながら、8 つの異なるツールへの呼び出しを調整します。ツールからの応答はランタイムを経由して戻り、ディーラーに提示する最終的な結果を生成します。 エージェントの評価が異なる理由 大規模言語モデル (LLM) の評価は、テキスト生成の品質、つまり一貫性、事実の正確さ、応答の関連性に注目します。一方、エージェントの評価は、それとは根本的に異なるものを見ます。こう考えるとわかりやすいでしょう。LLM の評価はエンジンの性能を調べるものです。エージェントの評価は、渋滞のなか、雨のなか、あるいは後部座席が乗客でいっぱいのときに、車全体がどう走るかを見るものです。 従来の LLM の指標では、Motorway のエージェントが「グレード 1 の Suzuki のモデル」に対して正しい検索ツールを呼び出したかどうかはわかりません。エージェントが LanceDB に正しいフィルターパラメータを渡したかどうかも明らかになりません。さらに、前のターンの結果を絞り込むディーラーが正しい応答を得られたかどうかも見落とします。 評価の観点 エージェントにとって重要な理由 タスクの完了 エージェントは複数ステップのワークフローを実行し、部分的な完了がよく起こる ツール使用の正確さ 誤ったツールや不正なパラメータは、ワークフロー全体を狂わせる 推論の一貫性 推論に欠陥があると、条件が変わったときに予測できない失敗につながる 信頼性と一貫性 非決定性により、同じ入力でも異なる結果が生じうる 安全性とコンプライアンス 自律的なエージェントは、現実に影響を与える行動をとりうる コストと効率 1 タスクあたり 50 回の API 呼び出しを要するエージェントは、経済的に成り立たないことがある 「7〜12 年落ちの Volkswagen Golf」のような正確な問い合わせは完璧に動くかもしれません。しかし、「古めの VW を探している」のような口語的な言い回しは、セマンティック検索の層が適切に評価されていないと失敗することがあります。 strands-agents-evals でデプロイ前に問題を検出する この設計図は、 GenAIOps のライフサイクルに対応する 2 つのフェーズで評価を実装します。ビルド時の評価はデプロイ前に問題を検出し、本番環境での評価は合成テストが見落とすものを捉えます。次の図 (図 2) は、ツールの使い方、推論、出力品質の各層が、デプロイ前にすべて合格しなければならないことを示しています。このフレームワークは、エージェントを 3 つの層で評価します。 レイヤー 1 (ツールの使い方) は、正しいツール選択とパラメータの受け渡しを、95% 超のしきい値で検証します。 レイヤー 2 (推論) は、論理的な意思決定を、85% 超のしきい値で評価します。 レイヤー 3 (出力品質) は、応答の有用性と正確さを、90% 超のしきい値で測定します。デプロイを進めるには、3 つの層すべてが合格する必要があります。 開発時、および継続的インテグレーションと継続的デプロイ (CI/CD) の際、パイプラインは strands-agents-evals フレームワークを使ってデプロイ前に問題を検出します。このフレームワークは、出力の検証、軌跡 (trajectory) の評価、複数ターンの会話のシミュレーション、実験の自動生成を提供します。いずれも、Strands Agents SDK 上に構築されたエージェントとネイティブに連携するよう設計されています。フレームワークは、3 つの基本要素 (プリミティブ) を提供します。 Experiment : エージェントに対して実行するテストケースの集まり。 Case : 入力の問い合わせ、期待される出力、期待されるツールの軌跡。 Evaluator : 採点ロジック (決定的、または LLM ベース)。 テストは層に分けて構成します。レイヤー 1 では、ツール選択の正確さを測る決定的なコードベースの採点器を実行します。レイヤー 2 と 3 では、推論と出力品質のために LLM-as-judge の評価器 (LLM を使ってエージェントの出力を採点する方式) を使います。 独自の Evaluator サブクラスは、ドメイン固有の関心事に対応します。Motorway のエージェントの場合、データの鮮度、ディーラー単位のスコープ、安全性のガードレールをカバーします。あなたのエージェントには、それ独自のドメイン制約があるはずです。 3 種類の採点器 評価フレームワークは 3 種類の採点器を使い、それぞれ異なる評価ニーズに適しています。 採点器の種類 レイヤー 測定する対象 トレードオフ コードベースの決定的採点 レイヤー 1 ツール選択、パラメータの受け渡し、軌跡の順序 高速、低コスト、再現可能 LLM-as-judge (Claude Sonnet 4.6) レイヤー 2〜3 推論の品質、出力の有用性、目標の達成 柔軟だが非決定的 (pass^k で制御) 人によるレビュー キャリブレーション エッジケースと安全性 コストが高く、LLM 判定のプロンプトの調整に使う 実際には、エージェントがたどった経路を採点するよりも、エージェントが生成した結果を採点する方が、多くの問題を見つけられます。重要なのは、ユーザーが関連性の高い結果を得られたことであって、エージェントが最初にどのツールを呼び出したかではありません。 3 層の評価フレームワーク ビルド時の評価は、3 つの異なる層で動作し、それぞれに固有の合否しきい値があります。 レイヤー 1: ツールの使い方 (しきい値 95% 超)。 エージェントは正しいツールを、正しいパラメータで呼び出したか。 「7,000〜20,000 ポンドのディーゼル車」は、型付きフィルター ( fuel_type=diesel 、 min_price=7000 、 max_price=20000 ) を指定して search_vehicles を使うべきです。 「走行距離の少ない新しめのハッチバック」は、セマンティックな埋め込みと構造化フィルターを組み合わせた hybrid_search を呼び出すべきです。 これは決定的に測定できます。 ToolSelectionGrader がどのツールを呼び出したかを確認し、 TrajectoryOrderGrader が呼び出しの順序を検証します。 レイヤー 2: 推論 (しきい値 85% 超)。 意思決定のプロセスは論理的だったか。strands-agents-evals の HelpfulnessEvaluator と TrajectoryEvaluator は、LLM-as-judge による採点を使い、エージェントの推論が筋の通ったものかを評価します。論理的でない推論で正しい応答にたどり着くエージェントは、条件が変わると予測できない形で失敗します。 レイヤー 3: 出力品質 (しきい値 90% 超)。 応答は有用で、正確で、実行に移せるものだったか。strands-agents-evals の OutputEvaluator と GoalSuccessRateEvaluator は、LLM-as-judge による評価を使い、ユーザーが有用で整った形式の応答を得られたかを評価します。 3 つの層は、デプロイ前にすべて合格する必要があります。いずれかの層で失敗すると、パイプラインはブロックされます。 非決定性への対処 LLM の出力は実行のたびに変わるため、1 回だけの試行の結果は誤解を招くことがあります。付属リポジトリの run_all_layers() 関数は、これに対処するために num_trials パラメータを受け取ります。コード生成の研究コミュニティ発の 2 つの指標が、信頼性の測定に役立ちます。 pass@k は、k 回の試行で少なくとも 1 回成功する見込みを測ります。正しい解を 1 つ見つければ十分な場合に役立つ指標です。 pass^k (pass の k 乗) は、k 回連続で成功する確率を測ります。ユーザーが毎回信頼できる挙動を期待する場合に役立つ指標です。 顧客向けのエージェントでは、pass^k が最も重要です。1 試行あたりの成功率が 75% のエージェントは、3 回連続で合格する確率がわずか 42% (0.75³) しかありません。ユーザーは、やり取りのたびに一定の品質を期待します。 付属のコードでは、 run_all_layers(task_fn, registry, num_trials=5) が複数試行に対応して評価の各層を実行し、pass^k でデプロイをゲートします。 実装の全体 を参照してください。 テストケースの管理 テストケースはカテゴリ別に整理します。 ハッピーパス : 成功するはずの一般的な問い合わせ。 エッジケース : 曖昧な問い合わせ、スラング、複数ターンでの絞り込み。 安全性/ガードレール : エージェントが拒否または誘導し直すべき問い合わせ。 本番環境の監視で問題を検出すると、そのやり取りが新しいテストケースになります。Motorway のスイートは、当初の 50 ケースから 3 か月で 150 ケースに増え、いずれも実際のユーザーの行動に基づいています。まずは 20〜50 ケースから始め、本番データでスイートを育てていきましょう。 エージェントが特定のツールを呼び出す べきでない ネガティブケースも含めます。たとえば、プロフィールの問い合わせは、検索ツールではなくプロフィールツールを呼び出すべきです。構造化された問い合わせは、生の SQL へのフォールバックではなく構造化検索を使うべきです。一方向だけの評価は、一方向だけの最適化を生みます。 複数ターンの会話のテスト 単一ターンの評価は、重要な観点、すなわち会話の一貫性を見落とします。ディーラーは、複数のターンにわたって自然に検索を絞り込んでいきます。 ターン 1: 「ディーゼルの SUV を探して」 ターン 2: 「次は、オートマだけを見せて」 ターン 3: 「かわりにステーションワゴンはどう?」 strands-agents-evals フレームワークは、現実的な複数ターンのやり取りを生成する ActorSimulator と、ターンをまたいだコンテキストの保持を採点する InteractionsEvaluator  を提供します。複数ターンのテストは、単一ターンのテストが見落とす、コンテキストのずれ、フィルターの累積エラー、代名詞の解決の失敗を捉えます。 AgentCore Evaluations で本番環境の挙動を監視する Strands Agent を Amazon Bedrock AgentCore Runtime にデプロイすると、 AgentCore Evaluations が継続的な監視を提供します。OpenTelemetry の計装 (業界標準の可観測性フレームワーク) を通じて Strands Agents と統合します。図 3 は本番環境でのアーキテクチャを示しており、可観測性のトレースは 1〜5% でサンプリングされ、指標は Amazon CloudWatch に集約されます。 2 つの監視アプローチ AgentCore Evaluations は、互いに補完し合う 2 つのモードを提供します。 オンデマンド評価 は、Amazon CloudWatch のログからスパンを選択して、特定のエージェントのやり取りを分析します。問題のデバッグや修正の検証に役立ちます。 オンライン評価 は、稼働中のトラフィックを自動的にサンプリングし、バックグラウンドで評価器を適用します。サンプリングレートを設定し (1〜5% を推奨)、最大 10 個の評価器を選んで、あとは実行させておきます。 組み込みの評価器とカスタム評価器 AgentCore は、一般的なシナリオ向けにあらかじめ構成された評価器を提供します。次の表は、組み込みの評価器と、それぞれが測定する対象を示しています。 評価器 レベル 測定する対象 Builtin.Helpfulness TRACE エージェントの応答がどれだけ有用か (7 段階で 0〜1 のスコア) Builtin.GoalSuccessRate SESSION ユーザーの全体的な目標が達成されたかどうか Builtin.ToolSelection TOOL_CALL エージェントが適切なツールを選択したかどうか Builtin.Correctness TRACE 応答の事実としての正確さ ドメイン固有の要件には、LLM-as-a-judge の構成を使ってカスタム評価器を作成できます。どのエージェントにも、組み込みの評価器がカバーしないドメイン制約があります。たとえば、データの鮮度、アクセスのスコープ、禁止された行動、レイテンシーの予算、コストの上限などです。 付属のリポジトリには、調整して使える 5 つのカスタム Evaluator サブクラスが含まれています。 評価器 検証する対象 DataFreshnessEvaluator オークションサイクルのタイムスタンプを検証し、エージェントが古い在庫を提示しないようにする SafetyGuardrailEvaluator エージェントが自動入札の操作を試みるのをブロックする DealerDataScopingEvaluator データ分離のために、ディーラー単位にスコープされた問い合わせを強制する LatencyEvaluator と CostEvaluator の例は、 付属のリポジトリ を参照してください。 追跡すべき主要な指標 付属のリポジトリには、CloudWatch のダッシュボードとアラームをプロビジョニングする AWS CDK スタックが含まれています。エージェントの健全性を監視するために、次の指標を追跡してください。 指標 目標 アラートのしきい値 タスク完了率 >95% <80% ツール選択の正確さ >95% <90% 有用性スコア (0〜1) >0.83 <0.58 応答レイテンシー P50 / P99 <2s / <10s >5s / >15s ハルシネーション率 <2% >5% やり取りあたりのコスト 傾向を監視 ベースラインの 2 倍超 品質チェックをデプロイのゲートにする 評価は、後回しにするものではなく、デプロイパイプラインの品質ゲートにすべきです。図 4 は、評価ゲートを備えたデプロイパイプラインを示しており、ビルド時の評価、ステージングでの検証、シャドウモード、A/B テスト、本番環境へのロールアウトにまたがります。失敗するとデプロイはブロックされます。 デプロイパイプラインは、5 つのフェーズで進みます。 ビルド時の評価 : ユニットテスト、ツールの正確さ ( ToolSelectionGrader 95% 超)、軌跡のテスト、LLM-as-judge による採点 ( HelpfulnessEvaluator 85% 超)。 ステージングでの検証 : ステージングデータに対する合成トラフィックを使った、オンデマンドの AgentCore 評価。 シャドウモード : 実際の本番トラフィックを、ユーザーに影響を与えずに並行して処理します。2% の乖離しきい値を設定し、少なくとも 4 時間実行します。 A/B テスト : 稼働中のトラフィックの 5% を候補のエージェントにルーティングし、実際の結果を測定します。 本番環境へのロールアウト : 継続的なオンライン評価と監視のもとで、トラフィックの 100% を移行します。 各フェーズにしきい値を定義します。ツール選択の正確さが 95% を下回るか、タスク完了率が 80% を下回ると、デプロイはブロックされます。大きなリリースでは、 num_trials=5 による複数試行の評価が pass^k でゲートし、非決定的な失敗を捉えます。 シャドウモード ステージングと本番環境の間で、候補のエージェントを、ユーザーに影響を与えずに実際の問い合わせに対して実行します。 シャドウモード は、本番トラフィックの複製を受け取り、候補のエージェントで並行して処理し、結果を比較します。A/B テストに進む前に、シャドウモードを少なくとも 4 時間実行してください。デプロイを自動的に一時停止する乖離しきい値 (2% が良い出発点です) を定義します。 シャドウモードは、ほかの段階が見落とす問題を捉えます。 同時負荷のもとでのタイムアウト処理。 合成テストに含まれていないドメイン用語。 実際のトラフィックパターンのもとでレイテンシーの急増を引き起こす、ツール呼び出しの順序。 始め方: 段階的なアプローチ フェーズ 1: テストスイートを作る。 実際のユーザーの問い合わせから抜き出した 20〜50 個のテストケースから始めます。ポジティブケースとネガティブケースの両方を含めます。エージェントが行うべきことと、拒否すべきことの両方をテストします。 フェーズ 2: ビルド時の評価を構成する。 採点器の種類を、測定する対象に合わせます。ツール選択には決定的な採点を、推論と出力品質には LLM-as-judge を使います。 フェーズ 3: 本番環境の監視を有効にする。 AgentCore Evaluations を 1〜5% のサンプリングレートで構成します。低めから始め、評価器のコストが許容範囲だと確認できたら引き上げます。 フェーズ 4: フィードバックループを閉じる。 本番環境の失敗をテストケースに変えます。失敗がリグレッションテストになると、このフィードバックループは、複数のチームで一貫して評価品質を高めてきました。 成果とインパクト この評価パイプラインを導入する前、エージェントのツール選択の正確さは 87% でした。つまり、ディーラーの問い合わせ 8 件に 1 件は誤った結果を返していたことになります。本番環境のインシデントは月に 12 件発生しており、ディーラーに影響が出始めてから問題を検知するまで、平均 4 時間かかっていました。 パイプラインを導入した後の結果は次の通りです。 指標 導入前 導入後 ツール選択の正確さ 87% 98% タスク完了率 82% 96% コンテキストの保持 (複数ターン) 71% 94% 本番環境のインシデント (月次) 12 2 問題検知までの平均時間 数時間 数分 ビジネス面のインパクトとして、ディーラーは車両の検索を数時間ではなく数分で完了できるようになり、結果が正確で最新であるという確信も得られています。 トラブルシューティング 軌跡の採点器の失敗、LLM-as-judge のばらつき、評価結果が空になる問題、コストしきい値の調整など、よくある問題の解決策は、 付属リポジトリの README を参照してください。 重要なポイント 評価パイプラインを構築するときは、次の原則を念頭に置いてください。 評価を層に分ける : ツールの使い方 (95% 超)、推論 (85% 超)、出力品質 (90% 超) は、それぞれ異なる失敗パターンを捉えます。 単一試行ではなく pass^k でゲートする : 1 試行あたりの成功率が 75% でも、3 回連続では信頼性が 42% しかありません。 本番環境の失敗をテストケースに変える : 実際のユーザーの行動で評価スイートを育てましょう。 シャドウモードは合成テストが見落とすものを捉える : 実際のトラフィックは、タイムアウト処理、まれな用語、レイテンシーのパターンを明らかにします。 監視は 1% のサンプリングから始める : 評価器のコストを管理するために、少しずつ拡大します。 まとめ ここまで、Motorway のディーラー向け在庫検索エージェントを実例として、AWS 上で本番運用の AI エージェント向けの評価パイプラインを構築する方法を見てきました。 核心となる教訓は、流暢な応答は、エージェントが正しいことをした証拠にはならないということです。ツールの選択、パラメータの正しさ、推論の一貫性、そして繰り返し実行したときの安定性を検証する必要があります。strands-agents-evals によるビルド時のテストと、AgentCore Evaluations による本番環境の監視を組み合わせることで、エージェントが設計通りに動くという裏付けを持ってデプロイできます。 これらのパターンは、複数のツールを使う顧客向けエージェントの多くに当てはまります。ナレッジベースやチケットシステムに問い合わせるカスタマーサービスのエージェント、ポートフォリオデータや市場フィードを取り込む金融アドバイザリーのエージェント、患者記録やスケジュール調整ツールにアクセスするヘルスケアのトリアージエージェントなど、いずれにも適用できます。 まずは次の手順から始めます。 付属のリポジトリをクローンします。 git clone https://github.com/aws-samples/sample-evaluating-agents-on-aws-with-strands-and-agentcore CDK プロジェクトのディレクトリに移動します。 cd sample-evaluating-agents-on-aws-with-strands-and-agentcore/examples/vehicle-auction-agent/cdk サンプルのインフラをデプロイします。 リポジトリの README のデプロイ手順 に従って、サンプルのインフラをデプロイします。デプロイが完了したら、AWS CloudFormation コンソールですべての AWS CloudFormation スタックが CREATE_COMPLETE の状態になっていることを確認し、インフラを検証します。CloudWatch のダッシュボードと Lambda 関数が、それぞれのコンソールに表示されているはずです。 サンプルの評価スイートを実行します。 付属のテストケースに対して実行し、3 層のフレームワークが動く様子を確認します。成功したかどうかは、レイヤー 1 (ツールの使い方) の合格率が 95% 超、レイヤー 2 (推論) が 85% 超、レイヤー 3 (出力品質) が 90% 超になっていることで確認します。いずれかの層が失敗した場合は、CloudWatch のログで詳細なエラーメッセージを確認してください。 評価器を自分のドメインに合わせてカスタマイズします。 DataFreshnessEvaluator と SafetyGuardrailEvaluator をテンプレートとして始めます。 さらに深く知るには、 Amazon Bedrock AgentCore のドキュメント と、GitHub 上の Strands Agents SDK を調べてみてください。 リソースのクリーンアップ 継続的な課金を避けるために、このチュートリアルで作成したリソースを削除します。 CDK プロジェクトのディレクトリに移動します。 cd sample-evaluating-agents-on-aws-with-strands-and-agentcore/examples/vehicle-auction-agent/cdk デプロイしたすべてのスタックを削除します。 cdk destroy --all プロンプトが表示されたら、削除を確定します。 AWS マネジメントコンソールで、Lambda 関数、S3 バケット、DynamoDB テーブル、CloudWatch のロググループとダッシュボード、EventBridge のルール、SNS トピックを含むすべてのリソースが、クリーンアップ処理で削除されたことを確認します。 注意: オブジェクトが入っている S3 バケットは、手動での削除が必要な場合があります。保持したい評価データやログがある場合は、クリーンアップを実行する前にエクスポートしてください。 参考資料 Evaluating AI agents for production: A practical guide to Strands Evals 。 Strands Agents SDK 。 strands-agents-evals 。 Amazon Bedrock AgentCore Evaluations 。 Evaluating AI agents: Real-world lessons from Amazon 。 著者について Amit Deol Amit は、AWS Prototyping and Cloud Engineering (PACE) のシニアプロトタイピングアーキテクトです。AWS のお客様と協力して新しいアイデアを試し、生成 AI、データ分析、リアルタイムストリーミングにわたる本番運用対応のソリューションを構築しています。プロトタイピングをしていないときは、森の中を長く散歩している姿が見られます。 Hin Yee Liu Hin Yee は、AWS のシニアプロトタイプエンゲージメントマネージャーです。AI のプロトタイプから本番運用までの道のりを速める顧客エンゲージメントを率い、チームが AWS 上で生成 AI ワークロードを構築・運用するためのベストプラクティスを取り入れられるよう支援しています。 Ryan Cormack Ryan は、Motorway のプリンシパルエンジニアであり、AWS Community Builder です。ディーラー向けの AI 活用ツールの開発を率いており、AWS Summit London で Motorway のエージェント型 AI の採用について講演しました。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。