AIエージェントシステム観測の基本構造：費用・遅延・品質をつなぐ

AIエージェントシステムの観測とは、「いくら使ったか」だけでなく、次の問いに答えられるようにすることです。

• どの機能で費用が増えたのか
• 一つの処理で、LLMやツールを何回呼び出したのか
• モデル、検索、ツール、アプリケーションのどこで時間がかかり、どこで失敗したのか
• 費用の変化と、処理結果の品質にはどのような関係があるのか

月次請求から分かるのは、最終的な支払額です。請求額だけでは、長い入力、モデルやツールの反復、再試行など、費用が生じた経路までは分かりません。反対に、アプリケーションの実行記録だけでは、契約割引や税を含む支払額を確定できません。

この記事では、AIエージェントの一回の実行を、利用者の操作、アプリケーションの実行経路、モデルとツールの呼び出し、提供元の集計、請求明細へ分けます。軸になるのは、一回ごとの実行記録と、提供元が集計した請求データは別の層に属するという考え方です。前半では観測データの意味を説明し、後半では2026年8月22日時点の公式情報をもとに、製品が担う役割と代表的な構成を整理します。

基本用語

観測データの五つの層

AIエージェントシステムの観測データには五つの層があります。同じ費用や処理を扱っていても、取得できる時刻と細かさが異なります。

リアルタイムの原因調査と、遅れて届く請求データを同じものとして扱わない。

API応答の利用量は、応答と同時に取得できます。一方、請求データは後から届き、一回の呼び出しまで分解できないことがあります。利用量からすぐに計算できる「推定額」と、後から確定する「請求額」は、発生時刻も粒度も異なる値です。

操作・実行・API呼び出しという三つの単位

利用者の一回の操作が、一回のLLM API呼び出しで終わるとは限りません。検索、LLM、tool実行を繰り返したり、失敗時に再試行したりするからです。観測データには、次の三つの異なる単位が現れます。

request_idごとにAPI呼び出しを数えると、一つの結果を作るためにLLMを何回呼んだかが分かります。run_idがあれば、同じtoolを繰り返した経路も追えます。提供元が返すrequest IDは、自社で付けるmodel_call_idとは別物です。両方を残すと、提供元への問い合わせと自社の実行記録を対応付けられます。

各API呼び出しのmetadataは、機能やteamと利用量を結びます。値の種類が際限なく増える項目は、集計軸として扱いにくい性質があります。

{
  "request_id": "req_...",
  "run_id": "run_...",
  "model_call_id": "call_...",
  "feature": "document_qa",
  "team": "knowledge-platform",
  "environment": "production",
  "requested_model": "standard-policy",
  "billed_model": "model-version-b",
  "provider": "provider-a",
  "region": "global",
  "retry_index": 0,
  "release": "2026-08-22.1",
  "experiment": "context-pruning-v2"
}

feature、team、environmentは集計軸になります。生のemail、API key、prompt全文を同じ場所へ入れると、閲覧権限や削除の管理範囲が広がります。利用者単位の識別子を含む記録には、利用量だけの記録とは異なる閲覧権限や保持期限が関係します。

モデルのToken以外にも観測する対象がある

Tokenは、LLMが文章を処理するときの単位です。日本語では一文字前後が一つのtokenになることが多いものの、文字やmodelによって変わります。Token数は費用の大きな手掛かりですが、処理が完了したか、ツールが成功したか、なぜ遅いかまでは分かりません。AIエージェントシステムの挙動には、費用、速度、安定性、処理結果という複数の観点があります。

費用と利用量

• 入力と出力のtoken数
• Cacheから読んだtokenと、cacheへ書いたtoken
• Reasoning・thinkingに使われたtoken
• Web検索、File Search、Code Interpreter、画像、音声、storageなどの利用量
• 一回の操作当たりのAPI呼び出し回数と費用
• 再試行、時間切れ、キャンセル、重複処理に使われた費用

同じtokenでも、提供元によって項目の意味が異なります。たとえばOpenAI Responses APIのoutput_tokens_details.reasoning_tokensは、output_tokensの一部です。両方を合計すると二重計上になります。公式API referenceで包含関係を確認できます。

Geminiではprompt、cache、回答候補、tool、thoughtの項目が分かれています。Vertex AIのresponse schemaには、totalTokenCountを構成する項目が示されています。複数の提供元を一つの表へまとめた値は、項目名だけでなく「どの利用量を含むか」という定義にも依存します。

速度と安定性

• 操作を始めてから結果が完成するまでの時間
• 最初の文字が表示されるまでの時間（TTFT）
• 結果が完成するまでの時間と、一秒当たりの生成token数
• Client error、server error、時間切れ、利用制限
• 再試行率、別の提供元への切り替え率、処理待ち時間

応答時間とtoken数を組み合わせると、2,000 tokenを返した5秒と、50 tokenしか返していない5秒を区別できます。前者は生成量、後者は処理待ちや通信などを調べる手掛かりになります。Azureの公式資料も、応答時間と生成token数を組み合わせるよう案内しています。

品質と利用者成果

• 処理の完了率、再質問率
• 正確性、根拠との一致、tool選択、指定形式への適合
• 拒否、権限違反、安全性違反
• 利用者の評価と人による確認結果
• Prompt、model、検索方法、release別の評価差

HTTP 200はAPIが正常に応答したことを示します。しかし、必要な資料を作れたか、予約を完了できたかといった処理結果までは示しません。「完了一件当たりの費用」の意味は、各機能で何を完了と定義しているかによって変わります。

利用経路によって得られるデータが異なる

LLMを直接利用する場合、cloud経由で利用する場合、Gateway経由で利用する場合では、記録が作られる場所が異なります。

OpenAIとAnthropicを直接利用する場合

OpenAIのOrganization Usage APIとCosts APIは役割が異なります。Usage APIはmodel、project、user、API key、service tierなどで利用量を分析できます。OpenAIは財務用途では、invoiceへ整合するCosts endpointまたはUsage DashboardのCosts tabを使うよう説明しています。

AnthropicのUsage & Cost Admin APIも、token利用量とUSDの費用を別endpointで提供します。Workspace、model、service tier、context windowなどで集計できますが、通常のAPI keyではなくAdmin API keyが必要です。Claude Platform on AWSではprogrammaticなUsage and Cost APIを利用できず、契約経路によって取得方法が異なります。

どちらも、組織全体の集計だけでは「自社のどの機能から呼び出したか」を完全には復元できません。API応答の利用量と、自社の機能名やrequest_idが同じ記録に存在すると、提供元の利用量とアプリケーションの処理を対応付けられます。

AWS

Amazon BedrockはCloudWatchへ、呼び出し回数、応答時間、error、利用制限、入力・出力・cache token、TTFTなどをCloudWatch metricsとして送ります。CloudWatch metricsは集計値です。Model invocation logのrequestMetadataには、機能別のAPI呼び出しを表す情報を含められます。

Model invocation loggingでは、request ID、model ID、IAM identity、token数、任意のrequestMetadataをCloudWatch LogsまたはS3へ記録できます。requestMetadataへteam、feature、environmentを入れるとcall単位で集計できます。

入力と出力の本文も保存できるため、有効化する項目によって保存dataの範囲が変わります。また、2026年8月時点ではbedrock-runtimeの対象APIと、bedrock-mantleのResponses APIでlogging対応が同じではありません。

AWS請求の分析にはCost and Usage Report（CUR 2.0）を利用できます。CURはtoken種別やservice tierなどの費用を扱えますが、一回ごとのrequest IDはなく、時間単位に集約されます。一回ごとの推定額とCURの費用は粒度が異なり、model、利用種類、時間帯などが両者に共通する集計軸です。

GCP

GeminiとVertex AIはresponseのusageMetadataからcall単位の利用量を取得できます。promptTokenCountにはcached contentを含むため、cachedContentTokenCountを再加算すると二重計上になります。Thinkingやtoolの内訳にはthoughtsTokenCount、toolUsePromptTokenCountがあります。

Vertex AIではCloud Monitoringのaiplatform.googleapis.com/publisher/online_serving/token_countで、input／output、modality、shared／dedicated trafficなどを集計できます。このmetricは2026年8月時点でBetaであり、schemaが変わる可能性があります。このようなmetricをそのまま永続保存すると、保存側のschemaも変更の影響を受けます。

請求データはCloud BillingのBigQuery exportへ出力できます。Standard exportはservice、SKU、project、label、location、cost、credit、currencyなどを含みます。Call単位のtraceとproject単位の請求には粒度の差があります。Project、model、region、service tierなどは、両方のデータに現れることがある対応軸です。

Azure

Microsoft FoundryはAzure Monitorにrequest数、status、input・output token、latency、cache hit率、provisioned utilizationなどをmodel deployment metricsとして提供します。Diagnostic settingsからLog Analytics、Storage、Event Hubsへ送り、Application Insightsのtraceと結べます。

Azure MonitorのlatencyはAPI gateway側の観測です。利用者が感じたend-to-end latencyにはnetwork、application、retrieval、tool処理も含まれるため、両者は同じ範囲の指標ではありません。請求はAzure Cost ManagementでFoundry resourceやmeterを確認でき、Storageへの定期exportも提供されています。

複数の提供元を表す共通形式

複数のSDKが混在すると、同じ意味の項目が別名で記録されます。OpenTelemetryのGenAI semantic conventionsは、model、operation、token利用量、処理時間、agent、tool callを共通形式で表す規約です。既存のAPMがOpenTelemetryを受け取れる場合は、通常のアプリケーションとLLMの実行経路を同じ画面で追える可能性があります。

ただし、GenAI規約は現在も更新されています。たとえば入力tokenにはcache tokenを含み、reasoning tokenは出力tokenの一部です。OpenTelemetryへ変換された値の意味は、規約のversionと、提供元固有の項目からの変換規則に依存します。

OpenInferenceはOpenTelemetry上で、LLM、agent、tool、retriever、reranker、embedding、evaluatorなどAI固有のspanを表す規約です。OpenTelemetryのGenAI規約と同じfield体系ではありません。両方が混在する環境では、同じ出来事が異なるfield名や階層で表現される可能性があります。

観測ツールの五つの役割

観測ツールは、置かれる場所と扱うデータによって五つに分けられます。これは市場で定められた分類ではなく、役割を理解するためのこの記事上の整理です。

以下は各役割に属する製品のカタログです。2026年8月22日時点の公式documentationに記載された機能を要約しています。

AI Gateway：複数の提供元に共通する入口

すべてのAPI呼び出しをGateway経由にすると、対応範囲内では提供元をまたいでtoken、応答時間、errorを記録できます。一方、本番の通信経路に中継サービスが増えます。停止時の影響、streaming対応、データが通過する地域、各APIへの対応範囲は製品ごとに異なります。

Gatewayの記録対象は、原則としてGatewayを通ったAPI呼び出しです。Browserから提供元へ直接送られた呼び出し、batch、別account、cloud内のmanaged agentなどは対象外になり得ます。

LLM専用基盤：Prompt、RAG、agentの記録

LLM専用基盤には、API呼び出しに加えて、prompt version、検索結果、tool、agent、評価用データ、利用者の評価を扱うものがあります。費用、実行経路、回答評価、prompt管理を同じデータモデルで結び付ける点が、請求集計や一般的なAPMとの違いです。

この表の製品は完全な代替関係ではありません。たとえばPhoenixやMLflowと既存APMは併用できます。一つのAPI呼び出しへ複数の自動計装を適用すると、同じ処理を表すspanが重複することがあります。

既存APM：アプリケーション全体とLLMの接続

APMのAI観測機能は、利用者の操作からWeb service、queue、検索、LLMまでを同じ実行経路として表示します。LLM専用基盤とは、アプリケーション全体を扱う範囲の広さが異なります。Promptの実験や、人による評価の機能は製品ごとに異なります。

Honeycomb、SentryなどのOTLP backendもGenAI spanを受信できます。ただし、OTLPの受信機能と、cache・reasoning tokenの内訳、model価格、conversation、evaluationの専用画面は別の機能です。

計装library：観測データの生成と送信

計装libraryは、アプリケーションから観測データを取り出すための部品です。保存や画面表示を担当する製品ではありません。製品固有SDKのほか、次の標準・libraryがあります。

OpenTelemetry Collectorをアプリケーションと保存先の間に置くと、prompt本文の削除、項目名の変換、保存する実行記録の選別、複数の保存先への振り分けを一か所で行えます。実行記録を間引くsamplingと、全件から作るtoken・error・費用の集計は異なる処理です。

観測製品が表示する費用の多くは、token数と価格表から計算した推定額です。契約割引、予約・provisioned capacity、batch割引、税、creditまで含む請求額とは別の値です。この違いは製品の優劣ではなく、一回ごとの実行記録と会計上の請求データの粒度が異なることから生じます。

三つの構成パターン

製品を置く場所によって、通信経路と管理対象が変わります。構成は大きく三つに分けられます。

一つのcloudに観測データが集まる構成

利用者 → アプリケーション → CloudのLLM
             │                    │
             └─ 実行経路          ├─ 利用量・応答時間
                                  └─ 請求データ

AWSならCloudWatchとCUR、Google CloudならCloud MonitoringとCloud Billing export、AzureならAzure MonitorとCost Managementが対応します。Cloud標準の認証、network、請求機能と観測データが同じ基盤に集まる構成です。Cloud側から見えないAgentやRAG内部、処理の完了結果は、アプリケーションの実行記録やLLM専用基盤が扱う範囲です。

Gatewayが複数の提供元の入口になる構成

利用者 → アプリケーション → AI Gateway → 提供元A／B／C
             │                 │                 │
             │                 ├─ 利用上限・経路 └─ 利用量・請求
             └─ 処理結果       └─ API呼び出し記録

すべてのAPI呼び出しをGatewayへ通すと、認証、提供元の選択、利用上限、再試行、別の提供元への切り替えを共通化できます。Gatewayは本番の通信経路に入ります。この構成では、時間切れと再試行の担当、障害時の迂回、再送時の重複処理がGatewayの動作とアプリケーション全体の性質に関係します。

通信経路と観測データの経路が分かれる構成

アプリケーション → LLM提供元
        │
        └─ OpenTelemetry → Collector → APM
                                      ├─ LLM専用基盤
                                      └─ 長期保存

LLMへの通信は提供元へ直接送り、観測データだけをCollectorへ集める構成です。Collectorは、機密情報の削除、記録の選別、保存先の振り分けを担います。通信経路には入らないため、API呼び出し前の利用上限や提供元の切り替えは扱いません。

Cloud標準の請求データ、Gateway、LLM専用基盤、APMは併用できます。請求データ、API呼び出しの入口、処理結果、実行経路をそれぞれ別の製品が保持することもあれば、一部が重複することもあります。

費用変動を構成する指標

API呼び出しごとに、入力、出力、cache、toolの単価が異なります。推定費用はそれぞれの利用量と単価から構成されます。全体の費用は、操作数、一操作当たりのAPI呼び出し回数、一回当たりの利用量、model・tool単価という複数の要素に分解できます。

P50は処理時間の中央値で、半数の処理がその値以下に収まることを表します。P95は95%の処理がその値以下に収まる境界です。平均値が全体を一つの値にまとめるのに対し、p50とp95の差は一部の遅い処理がどの程度存在するかを表します。

Prompt本文と利用量データの違い

Promptと回答本文は原因を説明する情報になりますが、個人情報、機密文書、認証情報、著作物を含む可能性があります。本文を保存すると、観測基盤も業務データと同じ管理範囲に入ります。

本文を保存しなくても、次の情報は記録できます。

• ID、時刻、機能、team、本番・検証環境、release
• 提供元、model、region、service tier
• Token内訳、tool利用量、応答時間、status、再試行、提供元の切り替え
• 処理の完了結果と回答の評価

本文の保存には、保存目的、対象範囲、機密情報の除去、暗号化、閲覧権限、保存地域、保持期限、削除方法が関係します。本文を持たない利用量記録と、機密情報を除いた一部の本文記録を分離する構成もあります。

まとめ

この記事では、AIエージェントシステムを、利用者の操作、アプリケーションの実行経路、API応答の利用量、提供元の集計、請求明細という層に分けました。三つのIDを対応付けると、長い入力、agentやtoolの繰り返し、再試行、提供元の切り替えを一回の操作までさかのぼって調べられます。

すぐに計算できる推定額と、後から届く請求額は同じではありません。期間、model、project、利用種類などは、粒度の異なる両者を対応付ける集計軸です。複数の提供元を共通形式で表す仕組みには、OpenTelemetry、OpenInference、提供元別の変換処理があります。

費用、応答時間、回答結果は、それぞれ別の性質を表す観測軸です。費用だけでは処理が完了したかは分からず、HTTP statusだけでは回答の正しさは分かりません。これらを同じ操作へ対応付けることで、利用量、挙動、結果の関係が見えるようになります。

参考資料

• OpenAI Organization Usage and Costs API
• Anthropic Usage & Cost Admin API
• Gemini／Vertex AI GenerateContentResponse
• Amazon Bedrock model invocation logging
• Microsoft Foundry model deployment monitoring
• OpenTelemetry GenAI semantic conventions
• OpenInference specification
• Langfuse token and cost tracking
• LangSmith cost tracking
• Arize Phoenix cost tracking
• Datadog Agent Observability cost
• OpenRouter usage accounting