Reliability and Routing2026年9月9日Flatkey Team

本当に重要な LLM API 指標

LLM API の信頼性、レイテンシー、コスト、リトライ、フォールバック、コンテキスト効率、監査可能性を測定するための実践的なスコアカード。

LLM API は、悪い測定の仕方がとても簡単です。リクエスト数は増え、トークン使用量は増え、ダッシュボードは派手になっていきますが、それでもチームは本当に重要な問いに答えられません。ユーザーは使える回答を得られたのか、レイテンシは製品の約束の範囲内に収まっていたのか、リトライはプロバイダー側の問題を隠していなかったか、そして受け入れられた結果のコストは想定どおりだったのか、という問いです。

適切な LLM API 指標は、モデル呼び出しを製品成果につなげます。これにより、エンジニアリング、プロダクト、そして財務が、AI 機能がスケールに十分な信頼性を持つのか、維持できるほど安価なのか、そしてデバッグ可能なほど可観測なのかについて合意しやすくなります。

このガイドは、本番の LLM API 運用のための実践的なスコアカードを提供します。LLM API とは何かを理解したあと、プロバイダーへの直接アクセスとゲートウェイを比較しているとき、あるいはチームがプロトタイプの呼び出しから実トラフィックへ移行しているときに使ってください。

簡潔な答え: API の動作だけでなく、受け入れられた成果を測る

よくある間違いは、ワークフローではなくラッパーを測定してしまうことです。200 レスポンス、トークン数、モデル名、総支出は有用ですが、それだけでは製品が LLM API 呼び出しから価値を得たことは証明できません。

本当に重要な指標は次のとおりです。

指標グループ	何に答えるか	なぜ重要か
受け入れられた応答率	アプリケーションは使える回答を受け取れたか?	生の HTTP 成功では、スキーマ失敗、誤ったツール呼び出し、拒否、ユーザーによる再生成を見落とします。
ユーザーパスごとのレイテンシ	そのワークフローに対して、回答は十分速く届いたか?	チャット、コーディングエージェント、バッチジョブ、ツールワークフローでは、それぞれ異なるレイテンシ目標が必要です。
受け入れられた出力あたりのコスト	有用な出力の実コストはいくらか?	トークン単価だけでは、リトライ、フォールバック、却下された回答、長文コンテキストの無駄を無視してしまいます。
リトライとレート制限の健全性	実際の需要下でシステムは安定しているか?	隠れたリトライは、全体の成功率が変わる前に、レイテンシ、コスト、障害リスクを増加させる可能性があります。
フォールバック品質	バックアップ経路は契約を壊さずに問題を回復できたか?	フォールバックが有用なのは、最終回答がワークロードの品質、スキーマ、ポリシー要件を満たしている場合だけです。
監査の完全性	チームは 1 件の不正なリクエストを素早く説明できるか?	デバッグには、リクエスト、キー、ワークロード、モデル、ルート、トークン、コスト、レイテンシ、エラーの文脈が必要です。

これが運用上の見方です。目的は LLM API がトラフィックを受け取ったことを証明することではありません。API レイヤーが、製品のある経路をより信頼性高く、より速く、より安く、あるいはより運用しやすくするのに役立ったことを証明することです。

指標 1: 受け入れられた応答率

受け入れられた応答率から始めてください。これはユーザー価値に最も近い指標だからです。

accepted_response_rate =
  accepted_outputs / user_or_job_requests

accepted_output はアプリケーションレベルで定義します。サポート要約ツールでは、要約が長さ、トーン、引用チェックを通過したことを意味するかもしれません。コーディングエージェントでは、パッチが適用されテストに合格したことを意味するかもしれません。抽出ワークフローでは、JSON がスキーマと信頼度ルールに一致したことを意味するかもしれません。チャット機能では、ユーザーがすぐに再試行、エスカレーション、または離脱しなかったことを意味するかもしれません。

LLM API リクエストごとに、少なくとも次のフィールドを追跡してください:

フィールド	重要な理由
`request_id`	サポート、エンジニアリング、財務が同じイベントについて話し合えるようにします。
`workload`	チャット、エージェント、抽出、エンリッチメント、バッチの各パスを分離します。
`requested_model`	アプリが何を要求したかを記録します。
`final_model`	実際に回答を生成したものを記録します。
`status`	成功、タイムアウト、レート制限、プロバイダーエラー、検証失敗、ポリシーブロックを分離します。
`accepted_output`	結果が実際に製品価値として利用可能だったかを示します。
`retry_count`	1つの可視リクエストの背後にある隠れた作業量を示します。
`fallback_count`	復旧によってモデルまたはプロバイダーパスが変更されたかを示します。

HTTP 200 / total requests を主要な信頼性指標として扱わないでください。これはインフラのシグナルです。LLM API は、技術的には成功していても製品としては失敗する応答を返すことがあります。たとえば、JSON の形式不備、誤った関数呼び出し、引用の欠落、安全上の拒否、幻覚したフィールド、不完全な回答、または到着が遅すぎる応答です。

指標 2: 平均レイテンシではなく、パス別レイテンシ

平均レイテンシは通常、適切な指標ではありません。ユーザーが体感するテールレイテンシや、運用担当者が診断すべきルーティング問題を隠してしまいます。

インタラクティブな LLM API パスでは、次を追跡してください:

指標	最適な用途
最初のトークンまたは最初のチャンクまでの時間	ストリーミングチャット、コパイロット、コーディングエージェント、そして進捗が重要なあらゆる UI。
エンドツーエンドの所要時間	非ストリーミング応答、構造化出力、ツール呼び出しチェーン、バッチジョブ。
p90 レイテンシ	大多数のユーザーに対する製品体験のレビュー。
p99 レイテンシ	インシデントレビュー、プロバイダーの不安定性、ロングテール回帰の検出。

バックグラウンドワークロードでは、スループットも追跡してください:

指標	最適な用途
1 秒あたりのトークン数	長い生成、要約、コーディングのワークロード。
1 分あたりの完了ジョブ数	キューのサイズ調整とワーカーの健全性。
再試行調整後のスループット	失敗と再試行を含めて شمارった実際の容量。

OpenTelemetry の GenAI セマンティック規約では、トークン使用量、オペレーション時間、最初のチャンクまでの時間、出力チャンクごとの時間、サーバーリクエスト時間、最初のトークンまでの時間、ワークフロー時間、エージェント時間、推論呼び出し、ツール呼び出し、ツール時間といった有用なプリミティブが定義されています。すべての指標を一度に実装する必要はありませんが、早い段階で安定した名前を使っておけば、LLM API のテレメトリが後で一回きりのスプレッドシートになってしまうのを防げます。

レイテンシは次の軸で分割します。

ワークロード;
ストリーミングか非ストリーミングか;
要求したモデル;
最終的なモデル;
プロバイダーまたはルート;
リトライ回数;
フォールバック回数;
プロンプトサイズまたはコンテキストウィンドウのバケット。

このセグメント化により、モデルが遅くなったのか、プロンプトが大きくなったのか、ルートが変わったのか、プロバイダーが制限に達したのか、あるいはリトライポリシーが働きすぎているのかを把握できます。

指標 3: 採用された出力あたりのコスト

トークン単価は本番コストと同じではありません。低コストのモデルでも、何度もリトライが必要だったり、却下される回答を生成したり、低信頼度の出力を人手で確認させたりすると高くつくことがあります。プレミアムモデルでも、より少ない呼び出しで採用可能な回答を返せるなら、あるワークロードでは安くなることがあります。

この LLM API のコスト指標を使います。

cost_per_accepted_output =
  total_workload_cost / accepted_outputs

次に、コストを分割します。

コスト構成要素	示しているもの
初回試行コスト	最初の呼び出しがうまくいった場合のベースラインコスト。
リトライコスト	ユーザーから見える 1 回のリクエストの背後に隠れたコスト。
フォールバックコスト	復旧経路にかかるコスト。
却下出力コスト	実際に使える製品価値を生まなかった支出。
長文コンテキストの無駄	繰り返しの、または不要なコンテキスト送信によるコスト。
ツールまたはメディアのコスト	ワークフローに関連する、有料ツール、画像呼び出し、動画呼び出し、ブラウザー操作、またはエンリッチメント手順のコスト。

財務レビューでは、コストをワークロード、キー、環境、ルートポリシー、最終モデル別に報告します。エンジニアリングレビューでは、コストの横に採用済み応答率を追加します。品質を伴わないコストチャートは、チームを「安く見えるが、より多くの製品障害を生むモデル」に誘導しかねません。

ここで Flatkey の製品面が関係してきます。Flatkey の公開ドキュメントでは https://router.flatkey.ai/v1 に OpenAI 互換の REST API があると説明されており、クイックスタートでは、リクエスト後に Usage Logs でモデル、トークン数、レイテンシ、コストを確認するよう案内しています。これにより、チームは有用なベース台帳を持てます。ただし、本番チームはその台帳に加えて、ワークロードラベル、採用出力ルール、ルートポリシーのメモも追加すべきです。

指標 4: リトライ、429、レート制限の圧力

レート制限は単なるプロバイダー側の事務手続きではありません。レイテンシ、コスト、ユーザー体験を変えます。

Flatkey の REST API ドキュメントでは、API リクエストは Bearer 認証を使用し、レート制限は API キーごとに適用され、制限を超えると 429 Too Many Requests が返されると記載されています。つまり、実運用の LLM API ダッシュボードは、プロバイダー側の障害、クライアント側の負荷、キー単位の容量問題を区別できる必要があります。

追跡する項目:

指標	式または定義	注目点
429 rate	`429 responses / total requests`	スパイクは、キー単位の容量、バースト形状、またはキュー設計の見直しが必要であることを示します。
Retry rate	`requests with retry_count > 0 / total requests`	高い再試行率は、最終的には成功していても不安定さを隠してしまう可能性があります。
Retry success rate	`accepted outputs after retry / retried requests`	再試行が価値を回復しているのか、それともコストを増やしているだけなのかを示します。
Retry latency penalty	`latency after retry - primary-success latency`	回復に伴うユーザー体験上のコストを示します。
Retry cost penalty	`cost after retry - primary-success cost`	回復に伴う請求コストを示します。

再試行には上限を設けるべきです。1 回のリクエストが静かに 3 回再試行できるなら、プロダクトは信頼性が高く見えても、p99 レイテンシーとコストが制御不能に膨らむ可能性があります。対話型の経路では、バックグラウンドジョブよりも再試行上限を厳しくすべきです。バッチ経路では、即時再試行よりもキューイングのほうが適している場合があります。

指標 5: フォールバック復旧とフォールバック不一致

フォールバックは、本来は失敗していたリクエストを救える場合に有用です。一方で、アプリケーションの契約を壊す回答を返してプロバイダー問題を隠してしまうと危険です。

OpenRouter のフォールバックに関するドキュメントでは、主要モデルのプロバイダーが停止している、レート制限されている、またはモデレーションのために応答を拒否している場合に他のモデルを試す方法が説明されています。また、価格は最終的に使用されたモデルに従うことも記載されています。OpenRouter のプロバイダールーティングに関するドキュメントでは、プロバイダーの順序、フォールバック許可、価格、スループット、レイテンシーによる並べ替え、優先パフォーマンス閾値などのルーティング制御が示されています。実装の詳細はプラットフォームごとに異なりますが、複数の経路を取りうるあらゆる LLM API にとって、運用上の問いは広く有用です。

追跡する項目:

指標	式または定義	何に答えるか
フォールバック発動率	`fallback_count > 0 のリクエスト / 総リクエスト数`	主要ルーティングがどの程度失敗するか、またはバックアップを選択するか。
フォールバック回復率	`フォールバック後に受理された出力 / フォールバック発動リクエスト`	フォールバックが実際に有用な出力を回復できているか。
フォールバック不一致率	`スキーマ、ツール、コンテキスト、モダリティ、またはポリシーの不一致により拒否されたフォールバック出力 / フォールバック発動リクエスト`	バックアップ経路が互換であるか。
フォールバックコスト増分	`フォールバック成功時のコスト - 主要経路成功時のコスト`	回復が金銭的に許容できるか。
フォールバック遅延増分	`フォールバック成功時のレイテンシ - 主要経路成功時のレイテンシ`	回復がユーザーパスに対して許容できるか。
最終ルートの可視性	`ログに最終モデルとプロバイダーが記録されたリクエスト / 総リクエスト数`	チームがルートをデバッグおよび監査できるか。

LLM API では、フォールバックは可用性だけでなく契約に基づいてテストすべきです。主要経路でツール呼び出し、JSON スキーマ、長いコンテキストウィンドウ、または特定のデータポリシーが必要な場合、フォールバック経路も同じ要件を満たすか、そのワークロードから除外される必要があります。

指標 6: コンテキスト効率

LLM API のコストは、コンテキストが増えるにつれて高くなることがよくあります。チームは、長いシステムプロンプトを投入し、繰り返しの指示を追加し、検索結果を付与し、会話履歴を含め、最大出力トークンを増やしますが、そうした変更を受理された出力と結び付けていません。

追跡する項目:

指標	重要な理由
受理された出力あたりの入力トークン数	プロンプトや検索結果の肥大化を示します。
受理された出力あたりの出力トークン数	応答が製品に必要な長さを超えていないかを示します。
コンテキスト利用率	ワークロードがモデルの実用的なコンテキスト上限にどれだけ近いかを示します。
キャッシュ可能トークン比率	プロバイダーやゲートウェイがキャッシュをサポートしている場合、繰り返しのプロンプト部分を再利用できるかを示します。
切り捨てまたはコンテキストエラー率	生成品質が評価される前に、入力サイズが失敗を引き起こしていないかを示します。

有用なレビュー質問は、「どのモデルが最も大きいコンテキストウィンドウを持っているか？」ではありません。「このワークロードが受理される回答を生成するために必要とするコンテキストはどれくらいか？」です。そうすることで、モデル選択を最大仕様ではなく成果に結び付けられます。

指標 7: 監査完全性

本番の LLM API インシデントは通常、特定の苦情から始まります。あるユーザーが悪い回答を受け取った、あるジョブが高額になった、あるプロバイダーが遅くなった、あるキーが制限に達した、あるいはあるモデルが不正な形式の出力を返した、というものです。監査完全性は、チームがその出来事を迅速に再構成できるかを測定します。

少なくとも、すべての本番リクエストは次を関連付けるべきです:

監査項目	必要な回答
`request_id`	どの正確なリクエストについて話しているのか？
`timestamp`	いつ発生したのか？
`api_key_id` or `environment`	どのアプリ、チーム、または環境から送信されたのか？
`workload`	どの製品パスまたはジョブが送信したのか？
`route_policy`	どのルールが適用されるはずだったのか？
`requested_model`	アプリは何を要求したのか？
`final_model`	何が応答したのか？
`final_provider_or_route`	リクエストは実際にはどこに送られたのか？
`status` and `error_type`	何が起こったのか？
`input_tokens` and `output_tokens`	どれだけの作業が行われたのか？
`latency_ms` and `time_to_first_chunk_ms`	どれだけ遅かったのか？
`cost`	いくらかかったのか？
`retry_count` and `fallback_count`	どれだけ回復処理が行われたのか？
`accepted_output`	アプリケーションは結果を受け入れたのか？

これらの項目が別々のツールに存在していても、LLM API は引き続き機能するかもしれませんが、運用はより遅くなります。チームは、5つのダッシュボードからプロバイダーの請求書、アプリケーションログ、キューログ、スクリーンショットをつなぎ合わせなくても、「何が変わったのか？」に答えられるべきです。

LLM API スコアカード

このスコアカードは、プロバイダー選定、ゲートウェイ移行、月次の運用レビューで使用してください。

質問	指標	合格条件
ユーザーは使える回答を得られているか？	受け入れられた応答率	モデルまたはルート変更後も、ワークロードごとに安定している、または向上している。
API は十分に高速か？	p90/p99 レイテンシと最初のチャンクまでの時間	各ユーザーパスの目標を満たしている。
システムは実際により安価か？	受け入れられた出力あたりのコスト	リトライ、フォールバック、却下された出力、ツールコストを含めた後で低くなる。
制限は制御下にあるか？	429 レート、リトライ率、リトライ成功率	制限圧力が可視化され、コストやレイテンシを静かに増大させない。
バックアップルートは機能するか？	フォールバック回復率と不一致率	フォールバックがスキーマ、ツール、ポリシー、品質を壊さずに障害を回復する。
コンテキストは制御下にあるか？	受け入れられた出力あたりの入力トークン数とコンテキストエラー率	プロンプトと検索の増加が測定可能な価値を生む。
エンジニアはインシデントをデバッグできるか？	監査の完全性	リクエスト、ワークロード、ルート、最終モデル、ステータス、レイテンシ、トークン、コスト、エラータイプが可視化されている。
財務は支出を配賦できるか？	キー、ワークロード、環境、ルート、モデル別のコスト	支出が所有者と製品パスに対応付けられる。

このスコアカードに必要なフィールドをツールが公開できない場合は、慎重に使ってください。実験用途として選ぶことはできても、補完的な計測なしに本番の LLM API トラフィックを運用するための制御プレーンにしてはいけません。

シンプルな30日間の計測計画

初日から完璧な可観測性スタックは必要ありません。次のルーティングやモデルの判断を計測可能にするのに十分な構造から始めましょう。

1週目: ワークロードとリクエストIDを定義する

代表的なワークロードを3〜5個選びます。

対話型アシスタントまたはチャットのパスを1つ;
コーディングエージェントまたはツール呼び出しのパスを1つ;
バッチ抽出またはエンリッチメントのパスを1つ;
高コストモデルのパスを1つ;
フォールバックに敏感なパスを1つ。

request_id、workload、environment、requested_model、statusを追加します。これらのフィールドがなければ、後の分析は推測になってしまいます。

2週目: 結果とエラーを追加する

各ワークロードに対してaccepted_outputを定義します。次に、タイムアウト、レート制限、プロバイダーエラー、バリデーション失敗、ポリシーブロック、コンテキストエラー、未知、という短い一覧でエラーを分類します。グラフが読みにくくなるほど詳細すぎるエラーレーベルは避けてください。

3週目: レイテンシ、トークン、コストを追加する

処理時間、ストリーミング呼び出しの最初のチャンクまでの時間、入力トークン、出力トークン、コストを記録します。ワークロード別のビューと最終モデル別のビューを1つずつ作成してください。これで、最初の意味のある最適化を見つけるには通常十分です。

4週目: ルートとポリシーを比較する

以下を比較します。

プロバイダー直結パスとゲートウェイ経由パス;
旧モデルと新モデル;
プライマリのみの成功とフォールバック成功;
リクエストあたりのコストと受理された出力あたりのコスト;
平均レイテンシとp90、p99レイテンシ;
同じワークロードに対するリトライ無効パスとリトライ有効パス。

レビューは、単に見栄えの良いダッシュボードではなく、ルートまたはモデルの判断を生み出すべきです。

Flatkey の位置づけ

LLM API が単一のプロバイダー呼び出しではなく共有の運用レイヤーになる必要があるとき、Flatkey は重要になります。現在の Flatkey の情報源は、次の製品事実を示しています。

Flatkey は https://router.flatkey.ai/v1 で OpenAI 互換の REST API を公開しています。
API リクエストは Bearer 認証を使用します。
同じベース URL が、エンドポイント、プロバイダー、モデルをまたいで使えます。
Flatkey の API ドキュメントには、chat completions、responses、embeddings、image generation、video generation、model listing の各エンドポイントが記載されています。
Flatkey の quickstart では、REST API、OpenAI SDK、Flatkey CLI、coding-agent の各パスが、1つのキー、1つのアカウント残高、1つのモデルカタログを共有すると説明しています。
quickstart には、Usage Logs によってリクエスト後にモデル、トークン数、レイテンシ、コストが表示されると書かれています。
Flatkey の公開サイトは、1つのキー、1つの残高、公式モデル、従量課金ツール、1つの請求書を中心に製品を位置づけています。

これらはLLM API の運用を測定するための有用な基本要素です。ただし、ワークロード固有の指標の代わりにはなりません。チームは引き続き、許容される出力、レイテンシ目標、リトライ予算、フォールバック方針、監査要件を定義する必要があります。

すでに API レイヤーを比較している場合は、この記事を AI ルーティング API 指標スコアカードと組み合わせてください。取り組みの初期段階であれば、まずは統合 AI API の使い方を読み、その後、本番トラフィックを移す前にこのスコアカードに戻ってきてください。

よくある間違い

誤り 1: トークン総数で止まってしまう。
トークン総数は消費量を示します。出力が受け入れられたか、再試行で請求額が膨らんでいないか、ユーザー体験が向上したかは示しません。

誤り 2: すべてのワークロードをまとめて扱う。
コーディングエージェント、カスタマーサポートのアシスタント、夜間のエンリッチメントジョブ、画像ワークフローは、それぞれ同じ成功目標を共有すべきではありません。

誤り 3: フォールバックを自動的な信頼性として扱う。
フォールバックが信頼性を高めるのは、バックアップ経路が同じ出力契約を満たし、受け入れ可能な結果を生成する場合だけです。

誤り 4: 破棄された出力を考慮せずに定価を比較する。
より安いモデルでも、破棄される応答が増えたり、プロンプトが長くなったり、人手によるレビューが増えたりするなら、安くはありません。

誤り 5: ログをエンジニアにしか役立たないものにする。
財務には、所有者別・ワークロード別の支出が必要です。プロダクトには、受け入れられた成果が必要です。サポートには、リクエスト単位の検索が必要です。LLM API 台帳は、この3つすべてを支えるべきです。

よくある質問

最も重要な LLM API 指標は何ですか？

最も重要な LLM API 指標は、ワークロード別の受け入れられた応答率です。これは、API 呼び出しと、実際にプロダクトが実用的な回答を受け取れたかどうかを結びつけます。

トークン使用量は LLM API の品質指標ですか？

いいえ。トークン使用量はコストとキャパシティのシグナルです。受け入れられた出力、レイテンシ、ワークロードのコンテキストと組み合わせることで有用になります。

LLM API ダッシュボードは平均レイテンシを重視すべきですか？

いいえ。平均レイテンシだけでは本番のレビューには不十分です。p90 と p99 のレイテンシに加え、ストリーミング経路では最初のトークンまたは最初のチャンクまでの時間も追跡してください。

チームはプロバイダー間で LLM API のコストをどのように比較すべきですか？

トークン単価だけでなく、受け入れられた出力あたりのコストで比較してください。再試行、フォールバック、却下された応答、長文コンテキストの無駄、そしてワークフローに付随するツール呼び出しやメディア呼び出しも含めます。

LLM API ゲートウェイは、どのような場合に指標管理に役立ちますか？

複数のプロバイダーにまたがって、1つのベース URL、共有モデルアクセス、使用ログ、請求の可視性、ルートポリシー、フォールバック動作、監査コンテキストが必要な場合、ゲートウェイは役立ちます。ただし、アプリケーション側のワークロードラベルと受け入れられた出力のルールは引き続き必要です。

最終的な要点

LLM API は、デモ用エンドポイントではなく、本番インフラとして測定すべきです。リクエスト数、モデル名、トークン総数、HTTP 成功は、あくまで最初の層にすぎません。

本当に重要な指標は、受け入れられた応答率、経路別レイテンシ、受け入れられた出力あたりのコスト、再試行とレート制限の健全性、フォールバック回復力、コンテキスト効率、監査の完全性です。これらをワークロードとルートポリシーごとに追跡すれば、LLM API は調整しやすく、信頼しやすくなり、エンジニアリング、プロダクト、財務、サポートが何が変わったのかを尋ねたときにも説明しやすくなります。

まずは1つの実践的なテストから始めましょう。実際のワークロードを1つ選び、現在のプロバイダ経由と Flatkey の OpenAI 互換ベース URL 経由で送信し、受け入れられた出力、最終モデル、レイテンシ、トークン使用量、コスト、再試行、フォールバック動作を同じスコアカードで比較します。