本連載のスコープ

AIエージェントを本番運用する際には、開発・検証フェーズで品質管理を行い、品質ゲートを通過したものをデプロイする運用が一般的です。AIエージェントがRAGとして利用するベクトル検索データベースやハイブリッド検索データベース（以降、検索データストア）も同様に、開発・検証フェーズにて品質管理を行い、品質ゲートを通過したものをデプロイする運用を取ります。これらの品質管理のしくみは、アーキテクチャ設計の初期段階から組み込むことで、より効果的に機能します。

一方、本連載が焦点を当てるのは本番運用フェーズです。公開以降、Amazon Bedrock AgentCoreのRuntimeやGatewayを用いて、複数のAIエージェントが複数の検索データストアをツールとして適宜利用する構成が主流となりつつあります。

こうした構成の本番環境では、ワークロードを通してAIエージェントの回答品質と検索データストアの検索品質を統合的に監視し、低品質な回答・検索が観測された際には、原因切り分けから次期評価データセットへの取り込みまでを一気通貫で管理する運用が求められる傾向があります。

こういったLLMOps、DataOpsに関する基盤を構築する際、OSSを用いたセルフホスト形態は柔軟性が高い一方、インフラの設計・保守やAWSサービスとの統合を個別に行う必要があり、マネージドサービス中心のAWSネイティブ構成と比べると運用負荷が増えるトレードオフが存在します。

本連載では、原則としてセルフホストの追加基盤を持たない（=AWSのマネージドサービス中心）形で実現する、AWSネイティブ構成のアーキテクチャを扱います。

第一回である本稿ではDataOpsとLLMOpsの統合に焦点を当てます。第二回ではAIエージェントのObservabilityへ焦点を当てます。第三回ではAIエージェントのセキュリティ・ガバナンスへ焦点を当てます。

本記事のスコープ

本記事は、複数のAIエージェントと複数の検索データストアが本番稼働する環境を対象とし、LLMOps(AIエージェントの品質管理)とDataOps(検索データストアの品質管理)の統合運用に焦点を当てます。本番運用を支える一連のしくみを除き、開発・検証フェーズの実験管理・プロンプト管理などの詳細は本記事の対象外となります。本記事のゴールは、本番環境における統制や運用負荷、AWS基盤連携などを重視した際に、AWSネイティブでどう組み立てることができるか、に関する判断材料と実装例を提示することです。

1.対象アーキテクチャの概要

1.1 マルチAIエージェント × マルチ検索データストアの構成

本記事で念頭に置くアーキテクチャは、AgentCore Runtime上で動作する複数のAIエージェントが単一のAgentCore Gatewayエンドポイントを共有しており、AgentCore Gatewayを介して複数の検索データストアへアクセスする構成です。以下はこの構成の概略図です。

リクエストがAgentCore Runtimeへ到達した際、各宛先AIエージェントが推論を開始します。AIエージェントは推論の過程で各々AgentCore Gatewayを呼び出し、GatewayにMCPサーバーやLambdaを介して登録された検索データストア群からコンテキストに合ったものを自律的に選択して情報を取得し、回答作成へ利用します。

1.2 本記事で扱う課題

複数のAIエージェントと、AIエージェントからツールとして呼び出される複数の検索データストアが運用されている状況において、AIエージェントの回答品質が低下する場合があります。その際、原因がAIエージェントの推論にあるのか、ツールとして呼び出された検索データストアの検索精度にあるのかなどを迅速に調査し、改善施策へ繋げることが重要です。

一般に、検索データストアは各々異なるバージョンと評価データ、評価指標を持ち、AIエージェント側とは独立にバージョン管理されます。AIエージェントの品質管理と検索データストアの品質管理が分断されている場合、原因調査に時間がかかり、改善サイクルが遅延する傾向があります。

本記事では、この課題に対してLLMOpsとDataOpsを統合しTrace単位で品質を管理するAWSネイティブサービス中心のアーキテクチャを、一例として紹介します。

2. DataOps: 検索データストアのバージョン管理と検索品質管理

1.で示したアーキテクチャでは、AIエージェントがAgentCore Gatewayを介して複数の検索データストアをツールとして呼び出します。ここでは、検索データストアに焦点を当て、バージョン管理や品質ゲート、本番監視といった、検索データストア側の品質管理をDataOpsの観点から整理します。

2.1 バージョン管理

検索データストアの品質管理は、構成パラメータとデータ内容のバージョン管理に大きく分けられます。検索データストアを含め、本番環境のインフラストラクチャは一般にAWSCDKやTerraform等のIaCツールで管理します。IaCコードをGitリポジトリで管理することで、構成変更をコードレビューやプルリクエストの対象にでき、変更履歴の追跡と差し戻しが可能になります。

たとえばBedrock KBを検索データストアとして使用する場合、IaCで管理する構成パラメータには以下のようなものがあります。これらの変更はいずれも、検索品質に影響を与えるものです。

• チャンキング設定: チャンキング戦略（semantic/fixed size等⁠）⁠、チャンクサイズ、オーバーラップ率
• 埋め込みモデル: 使用するembedding modelのARN
• ベクトルストア: OpenSearch Serverless等のエンジン種別と設定

また、S3上などに配置したデータソースの追加・更新・削除や、評価用データセットの内容に依っても検索品質は変動します。開発・検証フェーズでは実験管理ツールを用いてこれらを一元的に管理し、一定の品質基準（= nDCG@KやMRR、Recall@Kなどの評価指標に対する閾値）を超えたものを新しいバージョンとして本番環境へデプロイする運用が一般的です。

2.2 品質ゲート: Bedrock KB Evaluation (Retrieve-Only)

検索データストアの新バージョンは、評価用データセットに対する検索品質が基準を上回った場合のみ採用します。検索データストアとしてBedrock KBを用いる場合、RAG評価ジョブのRetrieve onlyタイプを使用することで、LLM-as-a-judgeによる検索品質の評価を行うことが可能です。Context relevance [1] とContext Coverage [2] の二つの評価指標がデフォルトで提供されており、カスタム指標を設定することも可能です。RAG評価ジョブの詳細に関しては、多くの技術記事が世の中にあるので、詳細を確認される際はそれらをご参照下さい。

以下は、検索データストアとしてBedrock KBを用いている場合に、RAG評価ジョブのRetrieve onlyタイプを使用する品質ゲートの論理フロー例です。Step Functions内で利用するコンピューティングリソースは省略しています。

Git管理された構成パラメータやS3上などに配置したデータソースが変更されると、Step Functionsワークフローが実行されます。ワークフローではまず、Green版（新版）として新規KBを構築し、次に評価用データセットを用いて、Green版に対しRAG評価ジョブのRetrieve-Onlyタイプを実行しGreen版の検索品質の評価を行います。

評価結果が閾値を上回った場合は、AgentCore Gatewayへ登録しているMCPサーバーやLambdaに対し、参照KBをGreen版へ切り替える処理を行います。閾値を下回った場合はBlue版（現行版）を維持し、SNS等で通知を送信します。

2.3 本番ワークロード監視

検索データストアの本番ワークロードは、運用メトリクスによるツール呼び出し状況の監視と検索品質の継続的評価の2層で監視します。

① ツール別メトリクスによる運用監視

ADOT（AWS Distro for OpenTelemetry）ゼロコード計装（次回で詳述）により、AgentCore Runtime上のAIエージェントが実行するツール呼出にはOpenTelemetryの計装が自動的に適用されます。Strands Agents SDKは内部のstrands.telemetry.metricsモジュールでツール呼出の回数・実行時間・成功/失敗をOpenTelemetryメトリクスとして記録します。記録されたメトリクスはADOTによりCloudWatchのbedrock-agentcorenamespaceへEMF(Embedded Metric Format)で出力されます。AIエージェントのコードにメトリクス送信のコードを追加する必要はありません。

この層の目的は、検索データストアへの呼出頻度・レイテンシ・成功率といった運用指標を監視することです。上記のstrands.tool.*メトリクスはCloudWatchの数値メトリクスとして出力されるため、CloudWatch Alarmを設定することで、レイテンシの悪化やエラー率の上昇を自動的に検知・通知することが可能です。

② AgentCore EvaluationsのOnline Evaluationによる検索品質の継続的評価

①のメトリクスはツール呼出の状況を示しますが、検索品質の問題は検知できません。これに対し、AgentCore EvaluationsのOnline Evaluationを使用します。なお、AgentCore Evaluationsは執筆時点でプレビュー段階で利用可能なリージョンが限定されいます。たとえばap-northeast-1リージョンでは現状利用できません。概念検証（PoC）はus-east-1で実施しています。

Online Evaluationは、本番のTraceを自動的にサンプリングし、指定したEvaluatorでLLM-as-a-Judge方式の品質判定を実行するしくみです。前節の品質ゲート（BedrockRAG評価ジョブ）が、評価用データセットに対するバッチ評価であるのに対し、Online Evaluationは実際のユーザクエリに対する検索品質をリアルタイムに評価します。そのため、ベンチマークでカバーされていない新しいクエリパターンでの品質低下も検知することが可能です。

なお、Online Evaluationを利用する際は、IAM信頼ポリシーに注意が必要です。Online Evaluation ConfigのevaluationExecutionRoleArnに指定するIAMロールの信頼ポリシーには、bedrock.amazonaws.comに加えて bedrock-agentcore.amazonaws.com を含める必要があります。これが不足するとcreate_online_evaluation_configがValidationExceptionで失敗します。

PoCではSearchQualityというCustom EvaluatorをTOOL_CALLレベル（Trace全体ではなく、個々のTool Spanに対し評価するレベル）で作成しました。このEvaluatorはTool Span (execute_tool retrieve_from_kb)のクエリと検索結果をLLMが判定する構成です。スコア体系は簡易的に、5.0(Excellent),3.0(Adequate),1.0(Poor)としています。評価結果はCloudWatchのBedrock AgentCore/EvaluationsnamespaceにEvaluationScoreメトリクスとして、5点満点を0~1に正規化された値で出力されます。

以下はPoCで取得したCloudWatch Metricsの画面です。Bedrock AgentCore/Evaluationsnamespace配下に、EvaluationScoreメトリクスがEvaluatorごとのDimensionで出力されています。このうちCustom.SearchQualityが当該メトリクスです。Builtin.CorrectnessとBuiltin.Helpfulnessはエージェントの回答品質を評価するBuiltin Evaluatorであり、同じnamespaceに出力されるため表示されています。

本番ワークロード監視においては、この①と②のメトリクスに対して以下の様なCloudWatch Alarmを設定し、閾値を下回った場合にSNSを用いてEmailなどで通知する構成を取ることが可能です。

CloudWatch AlarmによりCustom.SearchQualityのスコア低下が検知された場合は、以下の手順で原因を特定することが可能です。

1. CloudWatch Alarmから通知を受け取り、Custom.SearchQualityのスコア低下を確認
2. GenAIObservability → Tracesで該当時間帯のTrace一覧を確認し、対象のTraceを特定
3. Trace View(Trajectory)でTree/Timeline表示を開き、Tool Span（execute_tool retrieve_from_kbなど）を選択
4. Span MetadataパネルでInput（ユーザクエリ）とOutput（KBが返した検索結果チャンク）を確認し、クエリに対して不適切な検索結果が返されていないかを判断5.必要に応じてCloudWatch Logs Insightsでaws/spansロググループを横断検索し、同様のパターン（特定のクエリ種別で検索品質が低い等）を調査

3. LLMOps:AIエージェントのバージョン管理と回答品質管理

1.で示したアーキテクチャでは、AIエージェントが検索データストアをツールとして呼び出し、ユーザへ回答を生成します。ここではAIエージェント自体に焦点を当て、コードと設定のバージョン管理、品質ゲート、本番監視といった、AIエージェント側の品質管理をLLMOpsの観点から整理します。

3.1 コードバージョン管理

AIエージェントの品質管理では、コードと設定（システムプロンプト、使用モデル、ツール定義等）をバージョン管理し、変更の追跡とロールバックを可能にすることが基本的な要件です。AgentCoreのリソース定義は、AWS CDKやTerraform等のIaCツールで管理することができます。IaCコードやAIエージェントのコードをGitリポジトリで管理することで、コードレビューやプルリクエストを通じて変更を管理するのが一般的です。

AgentCore RuntimeをAIエージェントのデプロイ基盤として使用する場合、コードや設定の変更に伴ってRuntimeを更新する度に新規の変更不能な（immutableな）バージョンが自動生成されます。各バージョンは変更不可のスナップショットとなり、その時点のAIエージェントの構成を正確に再現することが可能です。また各バージョンにはエンドポイントがアクセスポイントとして紐付きます。DEFAULTエンドポイントは最新バージョンへ自動的にトラフィックを向けますが、dev/stg/prod等のエンドポイントを別途作成し、各々が異なるバージョンを参照するよう構成することで環境分離が実現できます。既存のセッションは開始時のバージョンで継続されるため、バージョン更新時にセッションが中断されることなく、エンドポイントの参照先を旧バージョンに戻すだけで即時ロールバックすることも可能です。

3.2 品質ゲート: AgentCore On-demand Evaluation

AIエージェントの新バージョンは、評価用データセットに対する回答品質が基準を上回った場合のみ、本番環境のエンドポイントへ昇格させます。以下は、この品質ゲートのフローの一例です。

Git管理されたリソース定義やエージェントコードが変更されると、CodePipeline上でCI/CDパイプラインが実行され、検証用エンドポイントにGreen版（新バージョン）をデプロイします。次に評価用データセットを用いて検証用エンドポイントを呼び出し、生成されたTraceをAgentCore EvaluationsのOn-demand Evaluationで評価します。評価スコアが閾値以上の場合は本番用エンドポイントへGreen版をデプロイし、閾値未満の場合はBlue版（現行版）を維持してパイプラインが失敗します。エンジニアは評価結果（スコアと低スコアのTrace）を確認し、改善点を判断します。

3.3 本番ワークロード監視

2.3節では、検索データストアの品質をCustom Evaluator(SearchQuality)を用いて監視しました。ここでは、AIエージェントの回答品質をBuiltin Evaluatorで監視する構成を説明します。いずれもAgentCore EvaluationsのOnline Evaluationを利用しますが、評価対象と評価レベルが異なります。

AgentCore Evaluationsは、OpenTelemetryで収集されたTrace(Trajectory)に対し、LLM-as-a-Judge方式で品質を判定するしくみです。執筆時点では14のBuiltin Evaluatorが以下の3レベルで利用可能であり、加えてCustom Evaluatorを独自のプロンプトとモデルで作成することもできます。

Online Evaluation Configを作成し、上記のEvaluatorを指定すると、本番トラフィックのサンプリング評価が自動的に実行されます。PoCではBuiltin.Correctness（回答の正確性）とBuiltin.Helpfulness（回答の有用性）をTRACEレベルで、Custom.SearchQuality（検索品質に関するCustom Evaluator。2.3節で詳述）をTOOL_CALLレベルで同時に評価する構成としました。

2.3節の検索品質アラームと合わせて、回答品質に対しても以下のCloudWatch Alarmを設定し、閾値を下回った場合にSNSを用いてEmailなどで通知する構成を取ることが可能です。

CloudWatch AlarmによりBuiltin.CorrectnessやBuiltin.Helpfulnessのスコア低下が検知された場合は、以下の手順で原因を特定することが可能です。

1. CloudWatch Alarmから通知を受け取り、低下したEvaluatorを確認
2. GenAIObservability → Tracesで該当時間帯のTrace一覧を確認し、対象のTraceを特定
3. Trace View(Trajectory)で推論過程をTree/Timeline形式で確認し、各Spanのメタデータ（model, tokens, input/output, duration）を確認4.必要に応じてCloudWatch Logs Insightsでaws/spansロググループを横断検索し、同様のパターンを調査

4. DataOps × LLMOps統合

2.（DataOps）では検索データストアの品質を、3.（LLMOps）ではAIエージェントの回答品質を、各々独立に管理するしくみを整理しました。ここでは、これらをTrace単位で統合することで可能になる原因切り分けや継続的な改善サイクルなどを説明します。以下はここで説明するアーキテクチャ全体の概略図です。

4.1 Trace単位の品質統合と原因切り分け

2.3節と3.3節で述べたOnline Evaluationは、同一のOnline Evaluation Config内で複数レベルのEvaluatorを同時に実行します。具体的には、TRACEレベルのEvaluator（Correctness, Helpfulness）とTOOL_CALLレベルのEvaluator（Custom.SearchQuality）を併用します。その結果、1つのTraceに対して「AIエージェントの回答品質」と「検索データストアの検索品質」の両方の評価スコアが紐付きます。

この統合により、AIエージェントの回答品質（Correctness）と検索データストアの検索品質（SearchQuality）を同一Trace内で比較することができます。AIエージェントの回答品質のみを追跡する場合と比べ、以下の様に多くの示唆を得ることが可能です。

以下はPoCで実測したTrace View（Trajectory）のSpan階層を模式化したものです。Root Spanにはエージェント全体の評価（Correctness, Helpfulness）が、Tool Spanには検索品質の評価（SearchQuality）が、それぞれ紐付いています。

Correctness 0.83（比較的高い）に対しSearchQuality 0.72（中程度）であり、上記テーブルの3行目「高い/低い」のパターンに近い状態です。これは、KBから返される検索結果の関連性が十分とは言えないものの、LLMが推論で補完して回答品質を維持できていることを示唆しています。この状態は一見問題がないように見えますが、検索品質がさらに低下した場合にLLMの補完が追いつかなくなり、回答品質が急激に悪化するリスクがあります。

そのため、Correctnessが高い段階であってもSearchQualityの低下傾向が見られる場合は、DataOps側の改善（データソースの更新やチャンキング設定の見直し等）を先行して検討する意義があると判断できます。逆に、SearchQualityが高いにも関わらずCorrectnessが低下した場合は、検索データストアではなくAIエージェント側の問題（システムプロンプトの不備や検索ツール選択の誤り、モデルの推論能力等）が原因である可能性があり、LLMOps側の改善が優先されると判断できます。個別の詳細な分析を実施する際には、2.3節及び3.3節で述べたように、CloudWatch GenAIObservability上で対象の低品質Traceを特定し、Trace ViewでSpan階層やメタデータなどを確認することで、具体的な改善施策へ繋げることができます。

4.2 統合監視

また、CloudWatch GenAIObservabilityでは、各AIエージェントのOverview画面にて、Span名ごとのTraces数やエラー数、平均レイテンシなどの統計値を一覧することができます。以下のPoC実測例では、Bedrock Agent Runtime.Retrieve（KB検索）はエラー0・レイテンシ383msと安定しています。一方、chat（LLM呼び出し）は21 Trace中67 Errorsと高いエラー率を示しており、問題の所在がLLM呼び出し側にあることが把握できます。

また、2.3節と3.3節で設定したCloudWatch AlarmのメトリクスをCloudWatch Dashboardに集約することで、AIエージェント品質と検索データストア品質を統合的に俯瞰することも可能です。以下はPoC実測例です。この例では、回答品質と検索品質のスコア、Metric Mathによる統合スコア（複数メトリクスを重み付き合算した値⁠）⁠、バージョン別比較、評価データセット対本番環境の乖離を6パネルで一覧しています。

4.3 フィードバックループ: 低品質Traceから評価データセットへ

本番ワークロードの監視によって得た低品質評価のサンプルを分析した後は、その知見を改善へ繋げることが重要です。具体的には、品質ゲートにて利用する評価用データセットを拡充し品質ゲートのカバレッジを改善すること、そしてもう1つは、分析を通して得た示唆からリソースの根本原因を改善することです。改善されたリソースが、品質ゲートにてより網羅的になった評価用データセットで再評価されることで、本番環境のリソースを継続的に改善することができます。以下は、このフィードバックループの概略図です。

① LLMOps側の例

たとえば、4.1節でCorrectnessが低いと判定された場合、AIエージェントの推論に問題がある可能性があります。この場合、以下のような手順で改善を進めることができます。

1. CloudWatch Logs InsightsでCorrectnessが閾値を下回るTraceを抽出
2. Trace ViewでInput（ユーザー問い合わせ）とOutput（AIエージェントの回答）を確認3.ドメイン専門家の知見などを踏まえて期待される正解回答を作成し、評価用データセット（JSONL）へ追記:

   {"query": "...", "expected_answer": "...", "expected_source": "..."}
   

4.並行して、必要に応じてエージェントコードやリソース設定を修正5.次回のCI/CDパイプラインにて、品質ゲート（AgentCore EvaluationsのOn-demand Evaluation）により、拡充済みの評価用データセットを用いて修正済みエージェントを評価

② DataOps側の例

4.1節でSearchQualityが低いと判定された場合、検索データストアの検索精度に問題がある可能性があります。この場合も同様に、以下のような手順で改善を進めることができます。

1. CloudWatch Logs InsightsでSearchQualityが閾値を下回るTool Spanを抽出
2. Trace Viewでクエリと検索結果（返却されたチャンク）を確認し、期待と実際の乖離を分析3.ドメイン専門家の知見などを踏まえて期待される検索結果を作成し、評価用データセットへ追記4.並行して、必要に応じてデータソースや構成パラメータ（チャンキング設定、埋め込みモデル等）を修正5.次回のDataOpsパイプラインにて、品質ゲート（BedrockRAG評価ジョブ (Retrieve-Only)）により、拡充済みの評価用データセットを用いて修正済み検索データストアを評価

品質ゲートを通過した改善済みリソースは本番環境へデプロイされ、再びOnline Evaluationの監視対象となります。このように、本番監視 → 原因切り分け → 改善 → 品質ゲート → 本番反映のループをDataOpsとLLMOpsの双方を横断しつつ回すことで、本番環境の継続的な改善を行うことができます。

おわりに

本記事では、複数のAIエージェントと複数の検索データストアが本番稼働する環境において、DataOpsとLLMOpsを統合して品質管理を行うAWSネイティブアーキテクチャの一例を紹介しました。Strands Agents SDK + AgentCore Runtime上にAIエージェントをデプロイし、Bedrock KBを検索データストアとして用いる構成でPoCを実施しました。

このアーキテクチャの特徴は主に3点です。

1点目は、AgentCore Observabilityが自動生成するOpenTelemetry Traceを品質管理の共通軸としている点です。1つのTrace内にAIエージェントの回答品質（Traceレベル評価）と検索データストアの検索品質（Tool Callレベル評価）が紐付くため、品質低下の原因がAIエージェント側にあるのか検索データストア側にあるのかを突き合わせ、原因を切り分けることが可能です。

2点目は、この原因切り分けや詳細分析を元に、評価用データセットの拡充とリソースの修正を並行して進め、品質ゲートで再評価するフィードバックループを構成することで、本番環境の継続的な改善を実現する点です。

3点目は、これら全てがAWSネイティブサービスで構成されており、自前のトレーシング基盤等の追加インフラを運用する必要がなく、その他AWSサービスとの統合も容易である点です。

本記事のアーキテクチャはAgentCore EvaluationsのLLM-as-a-Judge方式を品質評価の基盤としています。LLM-as-a-Judgeは本番トラフィックに対して汎用的な品質評価を行える点で強力ですが、万能ではありません。ジャッジモデル自身が正解を持たないため、ドメイン固有の知識や事実検証には限界があり、冗長な回答を高評価するバイアスも知られています。

こうした限界を補うためには、2つのアプローチが有効です。1つは、LLMの判断に依存しない決定的メトリクス（完全一致判定や正規表現チェック、引用元の妥当性検証等）を組み込むことです。

もう1つは、ドメイン専門家が低品質Traceをレビューして正解データを拡充するHuman-in-the-loopを運用に組み込むことです。LLM-as-a-Judgeによる自動評価を第一層、決定的メトリクスを第二層、人間評価を最終層とする多層的な品質管理を構成することで、本記事のアーキテクチャをより堅牢なものにできます。

次回では、このアーキテクチャを支えるAgentCore Observabilityの技術基盤 — OpenTelemetryとADOTによるゼロコード計装のしくみなどについて記載します。