shirokuronoir

複数AI運用で先に測る4つの指標

複数AI運用で先に測る4指標

複数のAIエージェントへ仕事を分けると、モデルごとの得意分野や費用を生かせます。一方で、全体の成功率だけを見ると、遅い経路や失敗が集中する担当を見落とします。

AWSが公開したSageMaker AIとBedrock AgentCoreの構成を確認すると、本番導入で先に必要なのはモデル数ではなく、経路ごとの計測です。

先に結論

複数AIを本番へ入れる前に、完了率、p95遅延、1リクエスト当たりのトークン量、人への引継ぎ率を経路別に残してください。

総平均だけでは原因を特定できません。セッションIDに加えて、担当エージェント、モデル、処理結果を同じトレースへ記録し、単一モデル構成より本当に改善したかを比較するのが先です。

AWSの構成から読み取れること

AWSの公式ブログ「Building agentic workflows with SageMaker AI and Bedrock AgentCore」では、AgentCore Runtime上のオーケストレーターが依頼を専門エージェントへ振り分けます。一方はAmazon Bedrockのモデル、もう一方はSageMaker AIのOpenAI互換エンドポイントを使う構成です。

ここで重要なのは、SageMaker AI側のモデル呼び出しでは、Strands Agentsの標準計装だけではトークン情報が自動取得されない点です。公式ブログは、利用量を含めた応答と独自のOpenTelemetryスパンでその欠落を補う方法を示しています。

AgentCore Observabilityの公式ドキュメントでは、セッション数、遅延、処理時間、トークン使用量、エラー率をCloudWatchで確認できると説明されています。つまり、異なるモデルをつなげただけでは運用完成ではなく、経路をまたいで比較できる状態までが実装範囲です。

今回試したこと

AWS環境は構築せず、監視設計だけを先に確かめるため、plannerとexecutorの2経路に固定した架空10リクエストを用意しました。各経路5件について、完了、遅延、トークン量、人への引継ぎをPowerShellで集計しました。

  • planner: 完了率100%、p95遅延830ミリ秒、平均1,026トークン、引継ぎ率0%
  • executor: 完了率80%、p95遅延1,600ミリ秒、平均1,672トークン、引継ぎ率20%

件数が少ないため性能評価には使えませんが、必要な計測項目を確認するには十分でした。全体平均だけなら「おおむね動く」で終わりますが、経路別にするとexecutorへ遅延、失敗、引継ぎが集中していることが一目で分かります。

本番前に残す4指標

  • 完了率: 業務上の完了条件を満たした件数を全リクエスト数で割る。HTTP 200だけを成功にしない。
  • p95遅延: 平均値では隠れる遅い5%を監視する。経路、モデル、ツールごとに分ける。
  • 平均トークン量: 入力と出力を分け、再試行分も含める。成功1件を得るための費用比較に使う。
  • 人への引継ぎ率: 停止条件や承認待ちで人へ戻した割合を残す。ゼロを目標にせず、安全に止まれたかを見る。

実装はこの順番にする

  • すべての処理へ`session.id`を付ける
  • `agent.route`、`model.id`、`tool.name`、`result`をスパン属性としてそろえる
  • 正常、タイムアウト、対象不一致、承認待ちの固定シナリオを流す
  • 経路別の完了率とp95を単一モデル構成と比較する
  • 悪化した経路はモデルを増やす前に、入力、再試行、ツール呼び出しを直す

最初から大量の本番ログを集める必要はありません。まず固定シナリオで欠けている属性を見つけ、その後に少量の実トラフィックでしきい値を決めるほうが、原因を追いやすくなります。

判断基準

複数モデル構成は、品質、費用、データ配置のいずれかに明確な利点がある場合に採用します。専門エージェントを増やしても、完了率が上がらずp95と引継ぎ率だけが悪化するなら、単一モデルへ戻す判断が必要です。

ブラウザ操作を伴うAIでは、確定前に人へ戻す境界も先に決めてください。具体例は「古いWeb業務をAI化する前の5確認」で整理しています。

出典

執筆・検証: しろのあ。一次情報、実行範囲、未検証部分を分けて記載しています。