---
title: コスト・容量・信頼性
url: https://doc.liz6.com/ja/ai/04-evaluation-and-production/02-cost-performance-and-reliability
locale: ja
area: ai
tags:
- 大規模モデルと Agent
- 評価と運用
date: 2026-06-30
modified: 2026-09-10
description: 品質を満たした後も、費用・配額・時間の制約内で運用する必要があります。タスク全体の費用から配額の律速と平均処理中件数へ進み、総期限内に再試行を収めます。KV とモデル内部の計算は推論資源の記事、本稿は調整と障害処理を扱います。
---
# コスト・容量・信頼性
品質を満たした後も、費用・配額・時間の制約内で運用する必要があります。タスク全体の費用から配額の律速と平均処理中件数へ進み、総期限内に再試行を収めます。KV とモデル内部の計算は推論資源の記事、本稿は調整と障害処理を扱います。
## コストは完全な実行チェーンで計算する
トークンは一般的な課金単位ですが、唯一のコスト要因ではありません。モデルリクエストには、通常の入力、キャッシュへの書き込み、キャッシュからの読み取り、出力などが区別される場合があります。また、ツール、検索、ストレージ、実行コンテナ、ネットワーク、自己ホスト型計算リソースも費用を発生させます。プロバイダーや製品によって計算基準が異なるため、「出力は入力より 5 倍高い」という一般論を適用することはできません。
**タスクコスト = すべてのモデルリクエスト費用の合計 + ツールおよび実行費用 + 関連するストレージ/検索などの費用**
あるサービスの教育用価格が入力 100 万トークンあたり 2 通貨単位、出力が 10 通貨単位であると仮定します。1 つのリクエストで入力が 20,000、出力が 2,000 の場合、モデル費用は 0.04 + 0.02 = 0.06 です。さらにツール費用が 0.01 かかり、合計は 0.07 になります。1 つのタスクで同規模の呼び出しが 3 回必要であれば、合計は 0.21 になります。失敗した追加試行も、実際に発生した費用として加算する必要があります。**これらの数字は計算例であり、現在の製品価格ではありません。**
| 最適化手法 | 節約できるもの | 同時に観察すべきもの |
|---|---|---|
| 不要な入力の削除 | 入力費用と一部処理時間 | 必要な証拠が失われないか |
| プレフィックスキャッシュ | 重複するプレフィックスの計算または費用 | ヒット条件、書き込みオーバーヘッド、有効期限 |
| モデルとエフォートの調整 | 単回計算の投入 | 完全タスクの成功率とリトライ |
| 最終的な出力長を制御 | 可視出力量 | タスク要件をカバーしているか |
| 非リアルタイムバッチ処理 | サービスのバッチ価格による | 完了期限、個々の失敗と重複送信 |
キャッシュの収益は、実際の価格を含まないモデルで試算できます。プレフィックス長を L、通常入力単価を u、書き込み単価を w、読み取り単価を r とし、N 回再利用され、他のリクエストがすべてヒットする場合、`N×L×u` と `L×w+(N−1)×L×r` を比較します。TTL 内に呼び出しが少なすぎる、またはプレフィックスが頻繁に変化する場合、書き込みのプレミアムは回収できない可能性があります。詳細なメカニズムと条件は [コンテキストエンジニアリング](/ai/02-context-and-interfaces/02-context-engineering.md) を参照してください。
安価なモデルに切り替える際も、タスク全体を計算する必要があります。単回費用が半分になっても、失敗により 3 回の追加試行が必要であれば、必ずしも節約になるとは限りません。成功したタスクあたりの総コストを報告し、失敗したタスクの消費も記録してください。1 つのリクエストの価格だけを比較しないでください。
## レイテンシとスループットの分解
エンドツーエンドの時間には、キュー待ち、ネットワーク、入力処理、推論/生成、ツール、アプリケーション検証などのフェーズが含まれます。直列依存関係は加算され、並列ブランチはクリティカルパスで計算されます。「レイテンシは主に出力長によって決まる」というのは、一部のワークロードにしか当てはまりません。
| 時間指標 | 測定範囲 | 発見できること |
|---|---|---|
| キュー待ち時間 | サービスへの到着から処理開始まで | アクセス制御またはバックエンドの容量不足 |
| 最初の可視テキスト時間 | リクエスト開始から有用なテキストの出現まで | 入力、思考、ネットワーク、表示の待機 |
| 生成フェーズ時間 | 生成開始から今回の出力完了まで | デコード、出力規模、または停止 |
| ツールフェーズ時間 | 実際のディスパッチから結果確認まで | 外部サービスと直列依存関係 |
| タスク完了時間 | ユーザーの送信から検証完了まで | ユーザーの実際の体験 |
ストリーミングは結果を段階的に配信するため、待機感覚を改善し、接続のキープアライブと組み合わせて使用できます。ただし、モデルの生成速度を自動的に向上させたり、出力上限を解除したり、すべてのエージェントやネットワークでタイムアウトが発生しないことを保証するものではありません。接続、読み取りアイドル、単一呼び出し、タスク全体の期限を個別に設定する必要があります。部分的なテキストを受信後にストリームを切断しても、途中の構造化結果を完了としてマークすることはできません。
キャッシュ、入力の短縮、バッチ処理、並列処理、探索の削減などは、特定のフェーズを改善する可能性があります。ただし、ボトルネックを特定するためにトレースを確認する必要があります。ツールクエリに 20 秒かかる場合、100 トークンの出力を削っても全体への影響は小さいかもしれません。キュー待ちが大部分を占める場合、フロントエンドのタイムアウトを個別に下げると、失敗のリトライが増えるだけです。
## クォータ、アクセス制御、有界キュー
クォータは、リクエスト数、入力トークン、出力トークン、およびトークン生成速度を同時に制限する場合があります。具体的な次元はサービスドキュメントとアカウント設定によって確認してください。[Claude Rate limits](https://platform.claude.com/docs/en/api/rate-limits) はリクエストの並列処理のみを制限しており、トークンクォータの超過を保証するものではありません。平均 RPM のみを制限しても、瞬間的なバーストは解消されません。
1 分あたり 100 リクエスト、200,000 入力トークン/分、50,000 出力トークン/分が許可されており、各リクエストの入力が平均 10,000、出力が 1,000 と仮定します。この場合、3 つの次元が示す平均上限はそれぞれ 100、20、50 リクエスト/分となり、最も厳しい制約は **20 リクエスト/分** です。
平均サービス時間が 30 秒の場合、安定してバックログがない単純化された条件下では、20 リクエスト/分は平均して約 10 の在途リクエスト数に対応します。このリトルの法則の例は平均容量の計算であり、本番環境で並列処理を 10 に設定すれば安全であるという意味ではありません。長さのばらつき、テールレイテンシ、バースト、外部共有クォータには、余裕と動的制御が必要です。
```python
from fractions import Fraction
rpm = 100
input_tpm, output_tpm = 200_000, 50_000
input_per_request, output_per_request = 10_000, 1_000
rate = min(Fraction(rpm), Fraction(input_tpm, input_per_request),
Fraction(output_tpm, output_per_request))
mean_inflight = rate / 60 * 30
assert rate == 20
assert mean_inflight == 10
assert 3 * 3 == 9 # 2 層それぞれで最大 3 回の試行の最悪増幅
print("平均リクエスト/分:", rate, "平均在途:", mean_inflight)
```
キューには長さと待機期限が必要であり、これを超えた場合はビジネスロジックに従って延期、フェイルオーバー、または拒否を行います。オンライン対話と遅延可能なオフラインタスクは別々にスケジューリングし、長時間のバッチ処理が対話リソースを枯渇させないようにします。過負荷時に受信を継続してすべてのリクエストを遅くするよりも、早期に拒否する方が回復が容易なことが多いです。容量管理は、単一のリクエスト数ではなく、実際のリソースに基づいて行うべきです。[Google SRE：Handling Overload](https://sre.google/sre-book/handling-overload/)
## リトライには期限と冪等性の境界が必要
### エラーカテゴリは数字の口実よりも有用
| カテゴリ | 処理原則 |
|---|---|
| 無効なパラメータまたはサポートされていない機能 | リクエストを修正し、そのままリトライしても意味がない |
| 認証または権限の問題 | 認証フローに従って回復または報告；権限回避を拡大しない |
| レートリミットまたは一時的な過負荷 | サービスの指示を尊重し、有限のバックオフで圧力を軽減 |
| 接続、タイムアウト、部分的なサービスエラー | まず操作を安全に再実行できるかどうかを判断 |
| 書き込みアクションの結果が不明 | ステータスを照会するか、サポートされている冪等プロトコルを使用 |
| クォータ枯渇、長期的な利用不可 | 条件の変化を待つか、明確なフェイルオーバーを使用し、無限リトライしない |
「429/5xx のみリトライ可能」や「すべての 5xx をリトライすべき」と単純化してはいけません。408、409 などがリトライに適しているかどうかは、プロトコルと操作によって異なります。プロバイダーのエラーと SDK のデフォルトポリシーもそれぞれ確認する必要があります。[Claude Errors](https://platform.claude.com/docs/en/api/errors)
### バックオフをタスクの期限内に組み込む
一般的なバックオフの上限は `min(cap, base×2^attempt)` で、区間内にジッターを導入し、複数のクライアントが同時にウェイクアップするのを防ぎます。サービスが Retry-After を返す場合は、そのセマンティクスに従ってスケジュールし、タスクの残り期限によって制約されます。もし待機後に試行を完了する時間が残っていない場合、リトライを開始すべきではありません。
例えば、タスクの残り時間が 8 秒で、サービスが少なくとも 6 秒の待機を要求し、次の操作に 5 秒の予約が必要な場合、このリトライは予算に適合しません。「各リクエストの timeout=10 秒」を設定しても、タスクが 10 秒しか待たないことを意味しません。リトライ、バックオフ、キュー待ち、ツールフェーズはすべて総時間を消費します。
呼び出し元が 3 回リトライし、SDK が内部でそれぞれ最大 3 回試行する場合、最悪の場合 9 回の基盤リクエストになります。どの階層がリトライを管理するかを明確にし、実際の試行数をカウントし、必要に応じてサービス全体のリトライ予算を設定してください。過負荷時にリトライが増幅すると、すでに不足している容量がさらに逼迫します。[Google SRE：Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/)
### 人間の確認は冪等性を代替できない
ユーザーが「注文を 1 件作成する」と確認したのは、1 回のビジネス意図を承認したに過ぎず、ネットワークのリトライによって 2 件の注文が作成されないことを保証するものではありません。冪等キーは同じビジネス操作に対応し、実際のサービスによって保存および検証される必要があります。同じキーに対して異なるパラメータを送信した場合も、サービスのセマンティクスに従って処理し、モデルのプロンプトに「重複しないように」と書くだけでは不十分です。
リクエストのタイムアウトは、サービスが実行していないことを証明するものではありません。アクションが完了したがレスポンスが届いていない場合、まず照会するか、既存の結果を再実行し、待機をキャンセルしてもアクションが自動的に取り消されるわけではありません。この境界は [エージェントループ](/ai/03-agent-systems/01-agent-loop.md) で完全なシーケンスとして展開されます。
### 要求数と token、どちらが先に尽きるか
各枠を要求率へ換算して最小値を取ります。Little の法則の L は平均処理中件数であり、推奨する固定同時実行上限や待ち時間末尾の保証ではありません。
$$
r\leq\min\left(R,\frac{I_{\max}}{\bar I},\frac{O_{\max}}{\bar O}\right),\qquad L=\frac r{60}\,\bar W
$$
**要求数と token、どちらが先に尽きるか**
持続可能な処理量は換算後の最小枠を超えず、平均処理中件数は占有時間にも依存します。
## フェイルオーバー、バッチ処理、実行検証
### フェイルオーバーでもタスクの最低要件を満たす必要がある
モデルを切り替える前に、コンテキストの長さ、構造化出力、ツールの形式、入力モーダル性、権限の境界を検証してください。テキストのみをサポートするフェイルオーバーモデルを画像タスクに静かに接続することはできません。また、代替サービスのサポート範囲が異なるからといって、重要な制約を削除して同等の結果を偽装してはいけません。
信頼できる既存の部分を返す、オフラインで完了を延期する、互換性のあるフェイルオーバーを使用する、または一時的に利用不可であることを明確に報告することを選択できます。古い結果をキャッシュする場合は、適用可能な時間とバージョンを明記し、ユーザーのアクセス範囲を確認してください。サービスが回復した後、バックログのタスクが同時に再実行されて新しいバーストを形成しないように防止する必要があります。
### バッチ送信は項目ごとにライフサイクルを管理する
非リアルタイムタスクにはバッチインターフェースを使用できますが、価格割引、完了期限、サイズ制限、キャッシュの相互作用はサービス固有のルールです。バッチの終了はすべての項目が成功したことを意味しません。各 ID ごとに成功、失敗、期限切れ、キャンセルを区別し、リトライすべき項目のみを再試行してください。[Claude Batch processing](https://platform.claude.com/docs/en/build-with-claude/batch-processing)
バッチ/並列処理の結果は順序が入れ替わる可能性があるため、リクエストマッピングを保存し、ID に対応する出力を保存してください。失敗した項目を再提出する際は、元のタスクと新しい試行の関連性を保持し、すでに成功した結果の重複書き込みを避けてください。モデルのバッチ処理自体が、ダウンストリームのビジネス操作をちょうど 1 回実行することを保証するものではありません。
### 検証の目標は制御可能な完全なサービスである
短リクエスト、長入力、長時間のツール待機、レートリミット、ストリームの切断、結果不明、フェイルオーバーの切り替えを含む実行サンプルを構築してください。成功率、p50/p95 レイテンシ、キューの長さ、実際の試行数、クォータの使用状況、項目ごとの成功コストを記録してください。
### 各層の再試行で何倍になるか
「2回再試行」と総呼出2回を混同しないよう、初回を含む試行上限を使います。SDK とワークフローの両方が再試行する場合、積で最悪量を計算し、期限と予算を共有します。
$$
N_{\mathrm{backend}}\leq A_{\mathrm{outer}}A_{\mathrm{inner}},\qquad t_{\mathrm{wait}}+t_{\mathrm{attempt}}\leq t_{\mathrm{remaining}}
$$
**各層の再試行で何倍になるか**
入れ子の最悪試行数は掛け算です。待機と次の実行を同じ期限内に収める必要があります。
次に読む：[リリース検証・カナリア・復旧](/ai/04-evaluation-and-production/03-release-and-recovery)。