1. はじめに こんにちは！AI事業本部の協業リテールメディアdiv.において小売アプリ向けの広告サ ...

本記事は 2026 年 1 月 15 日 に公開された「 From AI agent prototype to product: Lessons from building AWS DevOps Agent 」を翻訳したものです。 re:Invent 2025 で Matt Garman は、インシデントを解決し、事前に防止することで、信頼性とパフォーマンスを継続的に改善するフロンティアエージェントである AWS DevOps Agent を発表しました。DevOps Agent チームのメンバーとして、私たちは 「インシデント対応」 機能が有用な発見と観察結果を生成できるよう注力してきました。特に、ネイティブな AWS アプリケーションの根本原因分析が正確かつ効率的となるように取り組んでいます。内部的には、DevOps Agent はマルチエージェントアーキテクチャを採用しており、リードエージェントがインシデントコマンダーとして機能します。リードエージェントは症状を理解して調査計画を作成し、コンテキスト圧縮が有効なタスクは専門のサブエージェントに委任します。サブエージェントはクリーンなコンテキストウィンドウでタスクを実行し、圧縮した結果をリードエージェントに報告します。例えば、大量のログレコードを調査する際、サブエージェントはノイズをフィルタリングし、関連するメッセージのみをリードエージェントに提示します。 本記事では、実用的なエージェント製品を構築するために必要なメカニズムに焦点を当てます。大規模言語モデル (LLM) を使ったプロトタイプ構築は参入障壁が低く、動作するものを比較的早く見せられます。しかし、プロトタイプを超えて多様な顧客環境で確実に動作する製品へと進むのは全く別のチャレンジであり、過小評価されがちです。本記事では、AWS DevOps Agent の構築で学んだことを共有し、皆さん自身のエージェント開発に活かしていただければと思います。 私たちの経験では、エージェントの品質を継続的に改善し、プロトタイプから本番環境へのギャップを埋めるには 5 つのメカニズムが必要です。まず、 評価テスト (evals) を実施する必要があります。これにより、エージェントの失敗箇所と改善可能な領域を特定し、同時にエージェントが得意とするシナリオのタイプについて品質のベースラインを確立します。次に、エージェントの軌跡をデバッグし、どこで間違ったかを正確に把握するための 可視化ツール が必要です。3 つ目に、失敗したシナリオをローカルで再実行して反復できる 高速なフィードバックループ が必要です。4 つ目に、確証バイアスを避けるためシステムを変更する前に成功基準を確立する、 意図を持った変更 が必要です。最後に、定期的に 本番環境のサンプルを読んで 、実際の顧客体験を理解し、まだ評価されていない新しいシナリオを発見する必要があります。 評価 評価は、従来のソフトウェアエンジニアリングにおけるテストスイートの機械学習版です。他のソフトウェア製品と同様に、良いテストケースの蓄積が品質への信頼を築きます。エージェントの品質を反復的に改善することはテスト駆動開発 (TDD) に似ています。エージェントが失敗する評価シナリオがあり (テストが Red)、エージェントが合格するまで変更を加えます (テストが Green)。評価に合格することは、エージェントが正しい推論を通じて正確で有用な出力に到達したことを意味します。 AWS DevOps Agent では、個々の評価シナリオのサイズは、従来のソフトウェアエンジニアリングの テストピラミッド におけるエンドツーエンドテストに相当します。 “Given-When-Then” スタイルのテストの観点から見ると: Given – テストのセットアップ部分は、作成に最も時間がかかる傾向にあります。AWS DevOps Agent の評価シナリオの例として、 Amazon Elastic Kubernetes Service 上で動作するアプリケーションを考えます。複数のマイクロサービスで構成され、 Application Load Balancer をフロントに配置し、 Amazon Relational Database Service データベースや Amazon Simple Storage Service バケットなどのデータストアに読み書きし、 AWS Lambda 関数がデータ変換を行います。依存関係の深い部分で S3 への書き込みに必要な AWS Identity and Access Management (IAM) 権限を誤って削除するコード変更をデプロイして障害を注入します。 When – 障害が注入されるとアラームが発火し、AWS DevOps Agent が調査を開始します。評価フレームワークは、 DevOps Agent ウェブアプリケーション がレンダリングするのと同様に、エージェントが生成する記録をポーリングします。このセクションは、統合テストやエンドツーエンドテストでアクションを定義するのと根本的に変わりません。 Then – 複数のメトリクスを検証し、その結果をレポートします。基本的に、品質に対しては単一の “PASS” (1) または “FAIL” (0) メトリクスがあります。DevOps Agent のインシデント対応機能では、”PASS” は正しい根本原因が顧客に提示されたことを意味します。今回の例では、障害のあるデプロイを根本原因として特定し、依存関係のチェーンをたどって、影響を受けるリソースと S3 書き込み権限の不足を明らかにする観察結果を提示することです。それ以外は “FAIL” です。私たちはこれを ルーブリック として定義しています。「エージェントは根本原因を見つけたか？」だけでなく、「エージェントは正しい裏付けの証拠に基づいて正しい推論を行い、根本原因に到達したか？」を評価します。グラウンド・トゥルース (ソフトウェアテスト用語で “expected” や “wanted”) とシステムの応答 (“actual”) は LLM Judge を介して比較されます。LLM Judge とはグラウンド・トゥルースとエージェントの実際の出力の両方を受け取って、推論し、それらが一致しているか判定する LLM です。比較に LLM を使用するのは、エージェントの出力が非決定論的であるからです。つまり、エージェントは全体的には出力形式に従いますが、実際のテキストは自由に生成されるため、実行ごとに異なる単語や文構造を使用しながら同じ意味を伝える可能性があります。最終的な根本原因分析レポートではキーワードを厳密に検索するのではなく、ルーブリックの本質が満たされているかを評価したいのです。 評価レポートは、シナリオを行、メトリクスを列として構成されます。追跡する主要なメトリクスは、「能力」 (pass@k – k 回の試行で少なくとも 1 回合格したか)、「信頼性」 (pass^k – k 回の試行で何回合格したか、例えば k=3 で 3 回中 1 回合格なら 0.33)、「レイテンシー」と「トークン使用量」です。 評価が重要な理由 評価を行うことには複数の利点があります: 赤いシナリオは、エージェント開発チームが製品の品質を向上させるための明確な調査ポイントを提供します。 時間の経過とともに、緑のシナリオは回帰テストとして機能し、システムの変更によって既存の顧客体験が低下した場合に通知されます。 合格率が緑になったら、その他のメトリクスに基づいて顧客体験を改善できます。例えば、品質水準を維持しながらエンドツーエンドのレイテンシーを削減したり、コスト (トークン使用量で代用) を最適化したりできます。 評価の課題 高速なフィードバックループは、開発者がコードが機能するか (正しいか、パフォーマンスが良いか、安全か)、アイデアが良いか (主要なビジネスメトリクスを改善するか) を知るのに役立ちます。当たり前に思えるかもしれませんが、チームや組織が遅いフィードバックループを許容していることがあまりにも多いのです […] — Nicole Forsgren and Abi Noda、 Frictionless: 7 Steps to Remove Barriers, Unlock Value, and Outpace Your Competition in the AI Era 評価にはいくつかの課題があります。難易度の高い順に: 現実的で多様なシナリオの作成が難しい 。現実的なアプリケーションと障害シナリオを考え出すのは困難です。忠実度の高いマイクロサービスアプリケーションと障害を作成するには、業界経験を要する大変な作業です。効果的だと分かったのは、いくつかの「環境」(実際のアプリケーションアーキテクチャに基づく) を作成し、その上に 多くの 障害シナリオを作成することです。環境整備は評価のセットアップにおける高コストな部分なので、複数のシナリオで最大限に再利用します。 遅いフィードバックループ 。「Given」の評価シナリオのデプロイに 20 分かかり、その後「When」の複雑な調査が完了するのにさらに 10〜20 分かかるとしたら、エージェント開発者は変更内容を徹底的にテストしません。代わりに、1 回の合格した評価で満足して本番環境にリリースしてしまい、包括的な評価レポートが生成されるまでリグレッションを引き起こす可能性があります。また、フィードバックループが遅いと、小さく段階的な実験ではなく複数の変更をまとめて実施する傾向が強まり、どの変更が実際に効果をもたらしたかを把握するのが難しくなります。私たちは、フィードバックループを高速化するには3 つのメカニズムが効果的であると発見しました: 評価シナリオのための 長期稼働環境 。アプリケーションとその正常状態は一度作成され、稼働し続けます。障害注入は定期的に (例えば週末に) 行われ、開発者はエージェントの認証情報を障害のある環境に向けることで、テストの「Given」部分を完全にスキップできます。 重要なエージェント領域のみの 分離テスト 。私たちのマルチエージェントシステムでは、開発者はエンドツーエンドフロー全体を実行するのではなく、過去の評価実行からのプロンプトで特定のサブエージェントを直接トリガーできます。さらに、「フォーク」機能を構築しました。これにより開発者は、失敗した実行から特定のチェックポイントメッセージまでの会話履歴を保持した任意のエージェントを初期化して、残りの軌跡のみを反復できます。どちらのアプローチも「When」部分の待ち時間を大幅に短縮します。 エージェントシステムの ローカル開発 。開発者がテスト前に変更をマージしてクラウド環境にリリースしなければならない場合、ループが遅すぎます。ローカルで実行することで迅速な反復が可能になります。 軌跡の可視化 エージェントが評価や本番実行で失敗した場合、どこから調査を始めますか？最も生産性の高い方法は エラー分析 です。エージェントの完全な軌跡、つまりサブエージェントの軌跡を含むユーザー・アシスタント間のすべてのメッセージ交換を可視化し、各ステップに “PASS” または “FAIL” の注釈をつけ、何が間違っていたかメモを残します。このプロセスは面倒ですが効果的です。 AWS DevOps Agent では、エージェントの軌跡は OpenTelemetry トレースにマッピングされ、 Jaeger などのツールで可視化できます。 Strands などのソフトウェア開発キットは、最小限のセットアップでトレース統合を提供します。 図 1 – AWS DevOps Agent のサンプルトレース 各スパンにはユーザー・アシスタントのメッセージの組み合わせが含まれています。各スパンの品質を次のような表で注釈付けします: このローレベルの分析は、1 つだけでなく複数の改善点を一貫して明らかにします。1 つの評価が失敗すると、一般的に精度、パフォーマンス、コストにまたがる多くの具体的な変更点を特定できます。 意図を持った変更 私は父から意図を持って行うこと、すなわち自分が何をしようとしているのかを知り、すべての行動がその目標に向かっていることを確認すること、その重要さを学びました。— Will Guidara、 Unreasonable Hospitality: The Remarkable Power of Giving People More Than They Expect 失敗したシナリオを特定し、軌跡の分析を通して問題を診断しました。さぁ、システムを修正する時です。 この段階で最もよく見られる誤信:   過学習 につながる 確証バイアス です。前述の評価上の課題 (遅いフィードバックループと包括的なテストスイートの非現実性) を考えると、開発者は通常、合格するまでいくつか特定の失敗シナリオのみをローカルでテストします。より広範な影響を考慮せずに、1 つか 2 つのシナリオが合格するまでコンテキスト (システムプロンプト、ツール仕様、ツール実装など) を修正してしまいます。変更がコンテキストエンジニアリングのベストプラクティスに従っていないと、限られた評価では捉えられない悪影響が生じる可能性が高いです。 勤勉さと判断力の両方が求められます: 利用可能な評価と再利用可能な過去の本番環境でのシナリオを通して成功基準を確立するだけでなく、変更の指針となるコンテキストエンジニアリングのベストプラクティスを学んでください。Anthropic の プロンプティングベストプラクティス と エンジニアリングブログ 、Drew Breunig の “How Long Contexts Fail” 、 Manus 構築からの教訓 は特に参考になりました。 まず成功基準を確立する 変更を加える前に、成功とはどのようなものかを定義します: ベースライン: 現在のシステムに特定の git コミット ID を固定します。どのメトリクスが エージェントの体験 と顧客の体験の両方を改善するのかを慎重に検討し、それらをベースラインのメトリクスとして収集します。 テストシナリオ: どの評価で変更の影響を測定しますか？評価を何回再実行しますか？このテストセットが、調査している 1 つの失敗だけでなく、より広い顧客のパターンを代表していると確信を持ってください。 比較 : 同じメトリクスを使用して、ベースラインに対しての変更を測定します。 意図を持ったフレーミングにより、確証バイアス (結果を好意的に解釈する) とサンクコストの誤謬 (時間を費やしたという理由だけで変更を受け入れる) を避けられます。修正してもメトリクスが期待通りに動かない場合は、却下してください。 例えば、AWS DevOps Agent 内の サブエージェント を最適化する際、git コミット ID を固定し、同じシナリオを 7 回実行してベースラインを確立します。これにより、典型的なパフォーマンスと分散の両方が明らかになります。 各メトリクスは異なる側面を測定します: Correct observations – インシデントに直接関連する 関連 シグナル (ログレコード、メトリクスデータ、コードスニペットなど) をサブエージェントはいくつ提示したか？ Irrelevant observations – サブエージェントはリードエージェントにどれだけの ノイズ をもたらしたか？インシデントに無関係で、エージェントの調査を妨げる可能性のあるシグナルをカウントします。 Latency – サブエージェントはどのくらい時間がかかったか (分と秒で測定)？ Sub-agent tokens – サブエージェントはタスクを達成するのにどれだけのトークンを消費したか？サブエージェント実行コストの代理メトリクスとして機能します。 Lead-agent tokens – サブエージェントの入出力はリードエージェントのコンテキストウィンドウをどれだけ消費しているか？サブエージェントツールの最適化機会を具体的に特定できます。つまり、サブエージェントへの指示や返答結果を圧縮できるか？ということです。 ベースラインを確立した後、提案した変更に対して同じ測定値を比較します。これによって変更によって実際改善したかどうかが明確になります。 本番環境のサンプルを読む 幸運なことに、複数の Amazon のチームが AWS DevOps Agent を早期に採用してくれました。DevOps Agent チームのメンバーは、軌跡の可視化ツール (前述の OpenTelemetry ベースの可視化に似ていますが、根本原因分析レポートや観察結果などの DevOps Agent 固有のアーティファクトをレンダリングするようカスタマイズされています) を使用してローテーションで実際の本番実行を定期的にサンプリングし、エージェントの出力が正確であったかどうかをマークし、失敗したポイントを特定します。本番環境のサンプルは替えの効かないものです。実際の顧客体験を明らかにします。さらに、サンプルを継続的に確認することで、エージェントが得意なことと苦手なことの直感が磨かれます。本番実行が満足のいくものでない場合に反復するための実際のシナリオを持っています。エージェントをローカルで修正し、望ましい結果が得られるまで同じ本番環境に対して再実行してください。このような方法に協力してくれる重要なアーリーアダプターなチームとの信頼関係を築くことは非常に価値があります。彼らは迅速な反復のためのグラウンド・トゥルースを提供し、新しい評価シナリオを特定する機会を生み出します。本番データでの緊密なフィードバックループは、評価駆動開発と連携して機能し、包括的なテストスイートを形成します。 おわりに 現実のビジネス課題を解決できることを示すようなエージェントプロトタイプを構築することは、エキサイティングな第一歩です。より困難なのは、プロトタイプを様々な顧客環境とタスクにわたって確実に機能する製品に昇格させることです。本記事では、エージェントの品質を体系的に改善するための基盤となる 5 つのメカニズムを共有しました: 現実的で多様なシナリオでの評価、高速なフィードバックループ、軌跡の可視化、意図を持った変更、本番環境のサンプリングです。 エージェントアプリケーションを構築しているなら、今日から評価スイートの構築を始めてください。ほんの一握りの重要なシナリオから始めるだけでも、体系的に測定・改善するために必要な品質のベースラインを確立できます。AWS DevOps Agent がインシデント対応にこれらの原則をどのように適用しているかについては、 入門ガイド をご覧ください。 翻訳はソリューションアーキテクトの大西朔が担当しました。原文は こちら です。 著者について Efe Karakus AWS DevOps Agent チームのシニアソフトウェアエンジニアで、主にエージェント開発を担当しています。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。新年を迎えたと思ったら、あっという間にもう2月。今回は特に、AWS ジャパンが開始した「 フィジカル AI 開発支援プログラム 」が注目です。ロボット基盤モデル開発を支援する貴重な機会となっています。応募締め切りが2026年2月13日までとなっているのでご興味のある方は、ぜひご確認ください。 それでは今週も、生成AIを活用した開発支援プログラムやソリューション事例、そしてAmazon Bedrockを中心とした注目のサービスアップデートをお届けします。 さまざまなニュース フィジカル AI 開発支援プログラム by AWS ジャパン AWS ジャパンは2026年1月27日から、Vision-Language-Action（VLA）などのロボット基盤モデル開発に取り組む日本の企業・団体を支援する「フィジカル AI 開発支援プログラム」の応募受付を開始しました。このプログラムでは、データ収集・前処理からモデルトレーニング、シミュレーション、実環境へのデプロイまでの一連のパイプライン構築をサポートし、AWSクレジット提供に加えて、フィジカルAI領域スペシャリストによる技術支援、ロボティクス・生成AIコミュニティの形成、そしてモデル開発企業とロボット導入企業のマッチング機会を提供します。ロボティクス分野でAIを活用したい企業にとって、技術面・コスト面の両面で包括的な支援を受けながら、AIのロボティクスへの活用を加速させ、実用化に向けた開発を推進できる貴重な機会となります。プログラムの詳細な内容やスケジュール、応募方法については、ぜひブログ記事をご確認ください。 AWS生成AI事例ブログ「教育者を支援: Innovation Sandbox on AWS が学習目標の達成を加速する方法」 生成AIがテクノロジーの世界に大きな影響を与える中、大学や高等教育機関では学生にサンドボックス環境を提供し、業界が求める生成AIの専門知識を身につけることに取り組んでいますが、数千人の学生向けにサンドボックス環境のAWSアカウントを大規模に作成・管理することは困難でした。この課題を解決するため、Innovation Sandbox on AWSという安全でコスト効率に優れ、再利用可能な一時的なサンドボックス環境の管理を可能にするソリューションを利用し、管理者がサンドボックス環境のライフサイクル全体をセットアップおよび管理する方法を効率化し、技術的な負担を最小限に抑えながら、学生、研究者、教員がAWSで自由に実験できる環境を提供します。教育機関や研究機関にとって、セキュリティポリシー、承認ワークフロー、支出管理メカニズム、アカウントリサイクル設定などを直感的なユーザーインターフェースを通じて提供することで、学生のスキル習得効率が向上し、新しいアイデアやAWSのサービスを簡単に検証できる環境を構築できます。具体的な実装方法やユースケースについては、ぜひブログ記事で詳細をご確認ください。 ブログ記事「SAP JouleでAmazon Bedrock上のAnthropic Claudeモデルを使いSAPコンサルティングプロジェクトを加速」 SAPコンサルタントが複雑なクラウドトランスフォーメーションプロジェクトを進める際、膨大なドキュメントやベストプラクティスへのアクセス、SAP Knowledge Base記事の検索に多くの時間を費やしていました。この課題を解決するため、SAPチームはAWSと提携してSAP Joule for Consultants（J4C）を開発し、Amazon Bedrock上のAnthropic Claudeモデルを活用することで、コンサルタントが会話型AIを通じて独占的なSAPコンテンツに迅速にアクセスできる環境を構築しました。これにより、コンサルタントは特定のビジネスシナリオに対する技術的な実装要件を迅速にナビゲートし理解できるようになり、ジュニアコンサルタントとエキスパートの両方が顧客とのエンゲージメント効率を大幅に向上させ、専門知識をリアルタイムに活用できるようになります。具体的な実装アーキテクチャや成果については、ぜひブログ記事で詳細をご確認ください。 ブログ記事「ABAP Accelerator による AI-Assisted 開発のご紹介」 SAP S/4HANAへの移行を進める企業は、既存システムに存在する数千個のカスタムABAPプログラムのアップグレードが必要で、しかもドキュメントが不足しているという課題に直面しています。この課題を解決するために、ABAP AcceleratorというMCPサーバーベースのツールが提供され、お客様がより速く、より高いコード精度でコードの作成、テスト、ドキュメント化、変換を支援します。ABAP AcceleratorはSAP ABAP Test Cockpitに接続してコードを検証し、Kiro CLI内でお客様がハルシネーションを削減するのに役立ちます。生成AIを活用する開発者にとって、SAP ECCからSAP S/4HANAへの自動コード変換、SAP ABAP Test Cockpitとの統合による構文チェックとカスタムバリアント、そしてトランスフォーメーションのリスクを軽減するテスト駆動開発（TDD）アプローチにより、SAP開発ライフサイクル全体を大幅に最適化し、移行プロジェクトの品質基準を満たしながらビジネスロジックを保持できます。具体的な実装方法や各機能の詳細については、ぜひブログ記事で確認してみてください。 ブログ記事「Agentic workflowを使用したAmazon Nova Premierによるコード移行の効率化」 多くの企業が保守と拡張が困難になった古いテクノロジーで構築されたレガシーシステムに悩まされている中、Amazon Bedrock Converse APIとAmazon Nova Premierをagentic workflow内で使用して、レガシーコードを最新のJava/Springフレームワークアプリケーションに体系的に移行する方法を解説しています。この手法では、移行プロセスを複数の専門エージェントで分担し、堅牢なフィードバックループを実装することで、自動化により移行時間とコストを削減し、専門的な検証エージェントによってコード品質の向上と最新のベストプラクティスへの準拠を保証します。生成AIを活用する開発者にとって、レガシーシステムのモダナイゼーションという複雑な課題に対して、AIエージェントが言語パラダイムの違いやアーキテクチャの複雑性、ビジネスロジックの維持といった多くの課題を自動的に処理しながら、人間の専門家が戦略的な判断や品質保証に集中できる環境を提供し、大規模なコード移行プロジェクトを効率的かつ確実に進めることができます。具体的な実装アーキテクチャや各エージェントの役割については、ぜひブログ記事で詳細をご確認ください。 サービスアップデート Amazon Bedrockがプロンプトキャッシングの1時間保持に対応 Amazon Bedrockで、プロンプトキャッシングの保持時間が従来の5分から最大1時間まで延長できるようになりました。これにより、長時間にわたるAIエージェントとの対話や、ツール実行・データ検索を含む複雑なワークフローにおいて、同じプロンプトのプレフィックス（システムプロンプトやコンテキスト情報など）を再利用することで、コスト効率とレスポンス速度が向上します。この機能はClaude Sonnet 4.5、Claude Haiku 4.5、Claude Opus 4.5で利用可能で、すべてのAWSリージョンおよびAWS GovCloud (US)リージョンで利用可能です。なお1時間キャッシュは標準の5分キャッシュとは異なる料金体系が適用されます。 AWS が AWS MCP サーバーのデプロイエージェント SOP のプレビューを発表 AWS MCP Serverに、AIエージェントがWebアプリケーションのデプロイメントを自動実行するためのStandard Operating Procedures（SOPs）が追加されました。これにより、開発者はKiro、Cursor、Claude Codeなどのツールから自然言語プロンプトを使うだけで、AWS CDKインフラストラクチャの生成、CloudFormationスタックのデプロイ、セキュリティベストプラクティスを含むCI/CDパイプラインの構築まで、すべて自動的に実行できるようになります。従来は複雑だったDevOpsのベストプラクティスの実装やプロトタイプから本番環境への移行が、たった1つのプロンプトで完結するため、デプロイメント環境を簡単に構築できます。React、Vue.js、Angular、Next.jsなどの主要フレームワークに対応しており、現在米国東部(バージニア北部)リージョンでプレビュー版として追加コストなしで利用可能です。 Amazon BedrockがResponses APIでサーバーサイドカスタムツールに対応 Amazon BedrockのResponses APIで、OpenAI API互換のサービスエンドポイントを使用したサーバーサイドツールが利用可能になりました。従来のクライアントサイドツールと異なり、Bedrockがクライアントを経由せずに直接ツールを呼び出すため、Web検索やコード実行、データベース更新などのマルチステップアクションをリアルタイムで実行でき、レイテンシーを削減しながらAWSアカウントの組織、ガバナンス、コンプライアンス、セキュリティの境界内で安全に動作します。現在、OpenAIのGPT OSS 20B/120Bモデルで利用可能で、東京リージョンを含む複数のリージョンで提供されています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。今年はコロコロを続けたいと思います。