AIエージェントが遅い時に見る5項目

AIエージェントが遅くなった時、最初からプロンプトを書き直すのは早計です。モデル、外部ツール、メモリ、ネットワークのどこで時間を使ったかを分けないと、改善したつもりで別の処理を悪化させることがあります。

先に結論

最初に見るのは、次の5項目です。

1. セッション数

2. レイテンシー

3. セッションの実行時間

4. トークン使用量

5. エラー率

この5項目を平均値だけで見ず、セッション、トレース、ツール呼び出しの単位まで下りて確認します。AWSのAgentCore Observabilityは、CloudWatch上でメトリクス、トレース、構造化ログを組み合わせて調査できる設計です。

今回、実際に確認したこと

このブログの公開自動化を確認すると、投稿の成否、公開URL、HTTPステータス、OGP、出典掲載は記録しています。一方で、処理ごとの所要時間、外部ツール別の失敗率、トークン使用量、同じセッション内の再試行回数は継続記録していません。

つまり、公開失敗は追えても「どこから遅くなったか」は後から説明しにくい状態です。今回の結論は、すぐにAWSへ移行することではありません。まず現在の処理にも、開始時刻、終了時刻、処理名、成功可否、再試行回数を残すことです。

なお、この記事では手元のAWS環境へAgentCoreを導入していません。画面や数値の実測結果ではなく、AWS公式ドキュメントを基に、導入前に決める監視項目を整理しています。

1. セッション数で負荷の変化を確認する

遅延が増えた時は、同じ時間帯のセッション数を先に見ます。利用者や自動実行が増えただけなら、モデル品質より同時実行数やスロットリングの影響を疑うべきです。

比較する期間は、障害直前の短時間だけでは不十分です。少なくとも通常日の同じ時間帯と比べ、急増した時刻とデプロイ時刻を並べます。

2. レイテンシーを工程ごとに分ける

応答全体が10秒でも、モデル推論が9秒なのか、外部APIが9秒なのかで対策は変わります。トレースを使い、モデル呼び出し、検索、ツール、メモリ処理のspanを分けて確認します。

平均値だけでなく、遅い側の分布も重要です。普段は速いのに一部だけ極端に遅い場合、タイムアウト、外部API、特定ツールの再試行を疑います。

3. 実行時間とループ回数を見る

エージェントは正常終了していても、同じ判断やツール呼び出しを繰り返していることがあります。AWSの解説では、明示的なエラーを出さない無限ループや誤ったツール選択も、本番エージェントの調査対象として挙げられています。

終了ステータスだけではなく、1セッションの実行時間、step数、同じツールを呼んだ回数を残します。上限を決めておけば、静かな暴走を早く検出できます。

4. トークン使用量を品質と一緒に見る

トークンが増えたからといって、必ず品質が上がるわけではありません。長い履歴、重複した検索結果、不要な再推論で増えている可能性があります。

トークン使用量は、成功率や最終回答の評価と同じ単位で比較します。コストだけを減らして失敗率が上がれば改善ではありません。セッション単位で「入力、出力、結果」を結びつけます。

5. エラー率をツール別に分ける

全体のエラー率が低くても、特定ツールだけが不安定なことがあります。モデルエラー、認証エラー、入力検証、タイムアウト、スロットリングを同じ箱へ入れないことが重要です。

ツール名、操作名、エラー種別で絞り込み、デプロイ前後を比較します。認証情報の扱いは、前回まとめたAIエージェント認証の記事と合わせて確認してください。

最初に作る監視表

導入前に、次の列を1枚の表へまとめます。

| 項目 | 基準値 | 警告条件 | 調査先 |

|—|—:|—:|—|

最初から複雑なダッシュボードを作る必要はありません。基準値、警告条件、調査先の3点が決まっていれば、異常時に迷いにくくなります。

AgentCoreで確認する流れ

AWS公式ドキュメントでは、CloudWatchのGenAI ObservabilityからAgents、Sessions、Tracesを確認できます。トレースとspanの詳細はTransaction Search、ログは対象のLog group、メトリクスはbedrock-agentcore namespaceで確認する流れです。

詳細なトレースやカスタムメトリクスが必要な場合は、ADOT SDKによる計装を検討します。AgentCore外で動くエージェントも、OpenTelemetry互換のテレメトリを既存の監視基盤へ統合できます。

今日から行う3つの作業

1. 自動処理ごとに開始時刻、終了時刻、結果、再試行回数を記録する

2. 正常日の基準値を保存し、変更前後で比較できるようにする

3. 失敗をモデル、認証、外部ツール、入力、タイムアウトへ分類する

記事制作の自動化では、モデルの出力だけでなく公開前の判断も残す必要があります。AI記事制作で人が見る3項目も、運用ログと合わせて使えます。

まとめ

AIエージェントの遅延は、モデルだけを見ても切り分けられません。セッション数、レイテンシー、実行時間、トークン使用量、エラー率を同じセッションへ結びつけ、メトリクスからトレース、ログへ順に下りる設計が必要です。

まずは現在の自動化へ処理時間と失敗分類を追加し、正常時の基準値を残します。その後、AgentCoreやOpenTelemetryを導入すると、監視ツールを入れただけで終わらず、改善へつなげやすくなります。

著者情報

しろのあ。AIとCodexを使ったWordPress、note、アプリ制作、ゲームサーバー運用の自動化を実践し、確認できた手順と判断材料を記録しています。

出典

1. Optimizing production agents with Amazon Bedrock AgentCore Observability / AWS

2. Observe your agent applications on Amazon Bedrock AgentCore Observability / AWS Documentation

3. View observability data in CloudWatch / AWS Documentation

4. Add observability to your Amazon Bedrock AgentCore resources / AWS Documentation