AIエージェントの費用、どう比べる？ トークン単価ではなく「仕事1件を成功させる総費用」で比べる記録表と計算例

「Aのモデルは、Bの3分の1の値段らしい」

じゃあAを使えば、費用は3分の1になる？　ならないんです。

エージェントは1回の質問で終わりません。調べて、試して、失敗して、やり直します。しかも、最後に人が直すこともあります。請求書に載るのは単価じゃなくて、その全部の合計です。

この記事はAIエージェントの費用を「仕事1件を成功させるのに、結局いくらかかったか」で比べるための手引きです。記録表と計算の型まで用意したので、自分の業務で試せます。

先に、ひとつお断りを。ぼくはこの記事のために、エージェントを走らせる独自実験はしていません。 公式の料金・usage仕様、論文の本文、公開コードに直接あたって整理しました。計算例の数字はすべて架空です。公式料金の表とは、はっきり分けて書いています。

01先に結論

• 比べる単位は「同じ仕事を、同じ成功条件で、期限内に完成させるまでの全費用」です。 成功した試行の請求額だけを集めてはいけません。
• 式は 全件の費用 ÷ 成功した件数 です。 分子には失敗した仕事の費用も入れます。「成功した仕事の平均費用」とは別の数字です。
• 単価が3倍でも、呼出し全体では安くなることがあります。 逆もあります。単価表は消費量を教えてくれません。
• 「安いモデルを何度も回せば得」は、成功を正しく判定できて、試行が独立なときだけの話です。 現実の再試行はそんなに素直に成功しません。
• 平均だけで予算を決めない。 100件中5件が高い仕事なら、その5件で総費用の8割以上を占めることもあります（この記事の架空例では84%）。
• 請求の足し算はAPIごとに違います。 OpenAIのinput_tokensは読込・書込を含みますが、Claudeのinput_tokensは含みません。同じ式を使い回すと、気づかないうちに計算を間違えます。

02誰向けの記事？

エージェントを仕事で動かし始めて、「結局これ、安いの？高いの？」と迷っている人向けです。非エンジニアの人は、「ふたつの構成を、同じ100件の仕事で比べる」という考え方を持ち帰れば十分です。エンジニアの人は、後半の記録表とusageの読み方が、そのまま使えます。

03まず用語をそろえる：仕事・試行・呼出し

費用は、仕事・試行・呼出しの親子関係に沿って積み上がります。ここを曖昧にすると、あとで必ず数字が合わなくなります。

• 仕事（job）：利用者が頼んだ成果ひとつ。やり直しても、同じjob_idです。
• 試行（attempt）：その仕事を完成させようとする一連の実行。再生成や別モデルへの切替を別attemptにするなら、そのルールを固定します。
• 呼出し（request）：モデルAPIやツールの実際のリクエスト。SDKが裏で再送した分も、別の呼出しです。
• 並列分岐・子エージェント：同じ仕事のために動く作業。採用されなかった分岐も元の仕事に集計します。

runという言葉がjobを指す製品もあれば、attemptを指す製品もあります。ツールの表示に任せず、自分の台帳で単位を決めてください。

04「成功」を決めてから数える

「回答が返った」は成功ではありません。請求書の転記などではこんな具合に決めます。

この表は条件の作り方の例で、実際に測定した結果ではありません。

そして「成功率」は3種類あります。ここは混ぜないでください。

1. 試行成功率：成功した試行 ÷ 全試行
2. 初回成功率：初回だけで完了した仕事 ÷ 受け付けた仕事
3. 最終業務成功率：再試行・検証・修正を経て、品質と期限を満たした仕事 ÷ 受け付けた仕事

費用の比較に使うのは、3番です。

さらにもうひとつ。検証器が合格にしても、あとで誤りが見つかることがあります。観測期間のあいだに誤りが見つかった仕事は、最終成功から外します。人が全面的に引き継いで完成させた仕事はどうでしょう？　「エージェント単独の成功」と「人を含む業務プロセスの成功」は、分けて集計します。人の費用を足しながら、人の救済を成功件数から黙って外す（あるいはその逆）と、比較の意味が変わってしまいます。

05費用の台帳：何をどこまで入れる？

直接費

ここでひとつ、大事な話です。「再試行費」という請求科目はありません。 再試行で使ったLLM・ツール・環境の費用に、「再試行の分」というラベルを付けて、使った理由を示すだけです。全部を合計した後で「再試行費」をもう一度足してはいけません。検証費も同じです。「用途別」と「課金先別」は別の切り口です。

人の作業・固定費・損失

人件費を入れるなら、時給の定義もそろえます。給与だけか、福利厚生や間接費も含むか。「もう雇っているから追加の現金支出はゼロ」という見方と、「作業時間には機会費用がある」という見方は、どちらも成り立ちます。ただし、ひとつの比較の中で切り替えないでください。

自前のローカル推論も無料ではありません。ハードウェアの償却、電力、GPUの占有、遊休時間、保守にも費用がかかります。

06成功1件あたりの総費用の式

ここからが本題です。

N  = 受け付けた仕事の数
Yj = 仕事jが最終成功なら1、失敗なら0
S  = ΣYj（成功件数）

Cdirect,j   = 仕事jの全LLM・全ツール・全実行環境などの直接支出
Chuman,j    = Σ（実作業分 ÷ 60 × 時間単価）
Crecovery,j = 上の二つに入っていない復旧の追加支出

成功率              = S / N
直接費 / 成功       = ΣCdirect,j / S
運用総費用 / 成功   = Σ(Cdirect,j + Chuman,j + Crecovery,j) / S

分子に入れるのは、失敗した仕事の費用を含む全件の費用です。ここを「成功した仕事だけの平均」にすると、失敗にかかったお金が計算から消えます。

ちなみに、(平均費用)÷(成功率) は、同じ母集団なら ΣC/S と等しくなります。(ΣC/N)/(S/N) ですから、ただの算数です。仕事ごとの費用と成功が独立である必要もありません。ただし、別々の実験で測った平均費用と成功率を割っても、この等式の意味は保てません。 同じ仕事集合から出した数字どうしで割ってください。

もうふたつ、約束事です。

• S=0なら、成功単価は定義できません。 「$0/成功」にはしません。Nと費用と「成功ゼロ」を、そのまま報告します。
• 未確定の仕事は成功にも失敗にも勝手に振り分けません。 確定済みの集計に、未確定の件数と費用を併記します。

初期費用を入れる場合

期間総費用     = 期間内の運用総費用 + 初期費用の当該期間への配賦 + 共通費の配賦
期間の成功単価 = 期間総費用 / 同期間・同対象の最終成功件数

最適化の初期費用がF、1件あたりの節約額がd、利用件数がMなら、成功率と保守負担が変わらないという前提で、M×d > F が回収の目安です。

安さは、品質ゲートを通った構成の中でつける

成功率が低い構成は、難しい仕事を早く諦めることで安く見えます。順位は品質条件を満たした構成の中でだけつけます。

07架空の計算例：単価が3倍でも安くなる

この節の構成A/B、単価、トークン量、成功率、時間は、すべて架空です。 特定の製品の性能や料金を表しません。計算の追い方を見せるための例です。

同じ100件の仕事を、AとBで処理します。成功条件・期限・最終監査は同じ。結果は、同じ90件が成功、同じ10件が失敗とします。

まず、本体生成に使った全試行の合計です。

Bの単価はどれもAの3倍です。それでも、この架空のusageではBのほうが安くなります。なぜでしょう？　使ったトークンの量が違うからです。Bは1回で決まることが多く、やり直しが少ない、という設定です。「高単価のモデルが必ず安い」という一般則ではありません。

次に、検証や人の時間まで入れます。

計算は 680 ÷ 90 と 294 ÷ 90 です。失敗した10件の費用も分子に入っています。本体の表は再試行ぶんを含んでいるので、「追加attempt数×単価」をさらに足してはいけません。

図の赤い部分を見てください。このくらいの人の時間単価だと、人の作業が費用の大部分を占めます。 「API代の節約」だけを追っていると、一番大きな費目を見ないまま終わります。もちろん、これは架空の設定です。自分の業務で、人の作業がどれくらいを占めるかは、記録して初めて分かります。

待ち時間と初期費用を足すと

同じ100件で、人が「拘束されて待った」時間はAが120分、Bが30分。評価単価は仮に$30/時とします。この時間は上の人の実作業と重ならない区間だけです。

A：拘束待ちの評価額 = 120/60 × 30 = $60
B：拘束待ちの評価額 =  30/60 × 30 = $15

参考シナリオの成功単価：
A = (680 + 60) / 90 = $8.22
B = (294 + 15) / 90 = $3.43

この$60と$15はAPI請求でも、実際に払った人件費でもありません。機会費用を仮定した参考値です。基本の集計とは分けて表示して、「拘束がなければゼロ」のシナリオも残します。

さらに初期構築費がAは$500、Bは$1,200。同じ100件の処理を10回（計900件の成功）続けるなら、

A = (10 × 680 + 500)  / 900 = $8.11
B = (10 × 294 + 1200) / 900 = $4.60

ですが、100件の処理が1回きりなら、A=$13.11、B=$16.60 と順位が逆転します。初期投資を使う件数で割るからです。

08請求のもとになるusageを、API別に正しく読む

ここは地味ですが、一番ミスが起きやすいところです。2026年10月22日に、公式ドキュメントで確認しました。

料金（取得日：2026-10-22）

公式ページで確認した料金の抜粋です。能力や費用対効果のランキングではありません。 通貨はUSD、MTokは100万トークン。税・個別契約・地域の追加条件は含めません。

出典：OpenAI料金、GPT-6.1 Solのモデル仕様、Claude料金、Gemini料金。

Claudeのキャッシュ読込は、モデルによって通常入力に対する倍率が違います。この表のOpus 5.5とSonnet 5.5は5%ですが、Fable 5.1は$10に対して$0.25（2.5%）です。「Claudeのキャッシュは常に10%」という古い覚え方は使えません。

料金ページにはStandard、Batch、Fastなど、複数のモード表が並びます。同じモデル名だけを拾うと、別モードの価格を混ぜてしまいます。保存する料金表には必ず料金モードを付けてください。

OpenAI：input_tokens は全部入り

Responses APIでは、GPT-5.6以降の書込は、既定の30分で通常入力の1.25倍、12時間で2.5倍です。公式の説明どおり、これは「追加料金」ではなく、そのトークンに適用する単価そのものです。

I   = usage.input_tokens                       ← 読込・書込を含む全入力
R   = usage.input_tokens_details.cached_tokens ← 読込
W30 = …cache_write_tokens_details.ttl_30m_tokens
W12 = …cache_write_tokens_details.ttl_12h_tokens
W   = W30 + W12
O   = usage.output_tokens
U   = I - R - W                                ← 通常入力

LLM費用 = (U×p_input + R×p_read + W30×p_write30 + W12×p_write12 + O×p_output) / 1,000,000

output_tokens に含まれる推論の内訳を、別途もう一度足してはいけません。

Claude：input_tokens は全入力ではない

U = usage.input_tokens                  ← キャッシュ境界より後ろの、通常入力だけ
R = usage.cache_read_input_tokens
W = usage.cache_creation_input_tokens
全入力 = U + R + W

LLM費用 = (U×p_input + R×p_read + ΣTTL別(Wttl×p_writettl) + O×p_output) / 1,000,000

TTLが混在するときは、cache_creation.ephemeral_5m_input_tokens と ephemeral_1h_input_tokens の内訳があります。cache_creation_input_tokens は、この内訳の合計と等しいので、両方を足してはいけません。

フィールド名が似ているからといって、OpenAIの式（I - R - W）をClaudeに流用すると、通常入力を少なく計算してしまいます。逆も同じです。

Gemini：API面とキャッシュ方式を区別する

generateContent の usageMetadata では、promptTokenCount がキャッシュ部分を含みます。通常入力は promptTokenCount - cachedContentTokenCount で整理できます。thinkingモデルでは thoughtsTokenCount も別に残し、toolUsePromptTokenCount が出る場合は原データを保存して、請求規則と照合します。

別のInteractions APIは、total_input_tokens や total_thought_tokens など、形が違います。同じ名前の合計値を見て、別APIの内訳を足さないでください。count_tokens は実行前の推定で、実際の生成後usageの代わりにはなりません。

Gemini 4 Argonは明示的キャッシュに対応せず、暗黙キャッシュのみです。旧世代の保存料金（token-hour）を、一律に足さないでください。

ツールは、トークン以外の単位で課金される

OpenAIの料金表では、Web searchが1,000呼出しあたり$10に加えて検索内容のトークン料金、File searchが呼出しとGB日、コンテナがメモリ容量とセッション時間、といった具合に単位がばらばらです。「ツール回数×LLM単価」では計算できません。外部APIは提供元の請求明細と照合します。MCPは接続の仕組みで、接続先の利用料が無料になる理由にはなりません。

見積り・実績usage・請求を3層で残す

OpenAIにはUsage/Costs APIの例、AnthropicにはUsage and Cost APIがあります。ただし、組織・日単位の金額を取っただけでは、仕事単位に結べません。 実行ログのjob_idと結び付ける必要があります。

請求額と差が出たら、差を消して一致させず、内訳に分けます（未帰属、丸め、無料枠、料金モード、リージョン、契約割引、データの遅延）。usageが取れなかった呼出しも、「不明」として件数を残します。

比べ方は2種類あります。当時の実支払額で比べる場合と、保存した同じusageを同じ日付の料金表で再評価する場合です。後者は料金をそろえる計算であって、そのモデルを今走らせた結果の再現ではありません。

Agents APIのusageは後から変わる

OpenAIのAgents APIでは、turnごとのusageは「best-effort」で、確定前はnullにもなり、後から変わります。子エージェントはsubagent_idで区別できます。一覧を取得するときは、ページングも追います。未取得をゼロとして計算せず、親に集約済みの値と子の値を二重に足さないでください。

09再試行の算数：「安いモデルを何度も」は得？

理想的な世界

各試行が独立で、成功確率pが一定、1試行の費用cも一定、成功したら即停止、成功を完全に判定できる。最大k回なら、

最終成功確率 = 1 - (1-p)^k
期待試行回数 = [1 - (1-p)^k] / p
期待費用     = c × 期待試行回数
期待費用 / 最終成功確率 = c / p

この世界では、失敗した分まで含めた成功単価は c/p です。kを増やすと成功率は上がります。でも、成功単価は魔法のようには下がりません。これは数学の手順例で、実運用で常に成り立つ経験則ではありません。

現実の2回目は、履歴が長い、失敗理由を調べる、別モデルに切り替える、検証に費用がかかる、同じ誤りを繰り返す、という違いがあります。そのときは、段階ごとに考えます。

E[C] = Σ(i=1..k) P(段階iに到達) × E[段階iの費用 | 到達]

費用と成功を実測しているなら、この式よりも、仕事単位の全ログの集計を優先してください。

平均の成功率を式に代入してはいけない

仕事ごとの成功率をpjとすると、k回以内に一度成功する割合は、独立という仮定の下でも 平均[1-(1-pj)^k] です。1-(1-平均pj)^k とは、一般に一致しません。

架空の例。 半分の仕事は必ず成功し、残り半分は何回やっても成功しない。初回成功率は50%です。5回繰り返しても、最終成功率は50%のまま。平均p=0.5を式に入れた96.875%にはなりません。

pass@k、pass^k、最終業務成功率は別の問い

• pass@k：k個の候補のうち、少なくとも一つが正解。正解を選べるかは別問題です。
• pass^k：同じ仕事をk回やって、すべて成功する一貫性。τ-bench（タウベンチ）で提案された指標です。
• 最終業務成功率：選択・検証・打切り・期限・手戻りまで含めた、実際の成功。

τ-benchの公開コードは、各仕事でn回中c回成功したときの comb(c,k)/comb(n,k) を仕事ごとに出して平均します。全体の成功率をk乗する計算ではありません（コード）。

検証器が間違えると、再試行には限界がある

再生成してテストを通すほど、テストで見つけられない誤りが減るとは限りません。誤合格があるなら、検証器の合格件数を成功の分母に使うと、成功単価を過小評価します。独立した監査で誤合格と誤不合格を確認し、見つかった手戻りは同じ仕事の集計に戻します。

この問題を直接扱う研究が、The Limits of Inference Scaling Through Resampling（ICLR 2026）です。HumanEval+とMBPP+で、誤合格のある検証器を使った再標本化には限界があることを示しました。ただし、論文が使う「誤答の損失」は、返金額や人件費の実測ではなく、設定した便益と損失の比です。「再試行は常に10回未満が最適」とまでは言えません。

SDKの再送も数える

OpenAIのPython SDKは、一部の接続・HTTPエラーを既定で2回まで再試行します。タイムアウトも対象です。アプリに書いたループの回数だけでは、実リクエスト数になりません。

「アプリの再試行」「SDKの再送」「ツールの再送」「仕事全体のやり直し」を、別のラベルで残します。タイムアウトしたから費用ゼロ、とも推定しません。提供元のusageと請求に照らして、確定しない分は「不明」にします。

10並列化と待ち時間

並列化は「時間」と「消費」を別々に変える

3つの候補を並列で作って1つ採用しても、残り2つにかかった料金も残ります。選別や統合にも費用がかかります。

架空の例。 各$0.20・30秒の候補を3本同時に作り、選別に$0.05・5秒かかるなら、直接費は$0.65、候補部分の経過時間は約35秒です。直列で3本作ると約95秒かかるので時間は違いますが、生成費は同じ。1本で十分だった仕事と、同じ品質で比べられるかどうかは別に確かめます。

「1つでも正解ならよい」場合の 1-(1-p)^3 は、独立性と選別器の正確さが前提です。全員が同じ資料の誤りを共有する、同じモデルが同じ失敗をする、といった相関を無視しないでください。

時間は6種類に分けて記録する

「人の実作業時間×時給」に、「仕事の全経過時間×時給」を足さないでください。複数のエージェントを見ている人の同じ1分を、全部の仕事に1分ずつ計上するのも二重計上です。

待ち時間の金額換算は仮定として添えます。夜間のバッチ業務と対面接客では、待ちの価値が違います。BatchやFlexの割引を使うときは、同じ期限条件を満たすかを確かめます。

11平均だけで予算を決めない

p95は、観測した仕事の約95%がその値以下になる境界です。費用のp95と時間のp95は、別々に計算します（同じ仕事とは限りません）。

架空の例。 100件中95件が$0.10、5件が$10なら、総費用は$59.50、中央値は$0.10、平均は$0.595。たった5件で総費用の約84%を占めます。 「普段は10セント」だけでは、予算が組めません。

エージェントの費用が特定のべき分布に従うと実証したものではありません。裾が重い可能性を確かめられる集計を残す、という提案です。

失敗を消すと、費用も成功率も歪む

エラー、打切り、タイムアウト、取消し、出力欠落、API制限を除いた「正常終了分の平均」は、業務運用の平均ではありません。原因別に分けて、全件の集計も残します。

同じ仕事を数回ずつ試すなら、呼出しを独立のデータとして扱って信頼区間を狭めないでください。jobを単位にまとめて、同じjob群を両構成で比べます。ブートストラップを使うなら、仕事ごと（または仕事のクラスタごと）に再抽出します。

期間もそろえます。今日走らせた仕事の費用と、先月完了した仕事の成功数を割らない。受付コホート、締切、監査や差戻しを追う期間を決めて、判定日時と版を残します。早く終わった仕事だけを集計すると、遅い仕事が抜けている可能性があります。

12キャッシュは何回再利用すると得？

共通のprefix（先頭の共通部分）の通常処理費をP、書込の倍率をw、読込の倍率をr、書込後の再利用回数をRとします。すべてヒットして、TTL切れも再書込も保存費もない、という単純化では、

キャッシュなし = P × (1 + R)
キャッシュあり = P × (w + r×R)
得になる条件   = R > (w - 1) / (1 - r)

w=1.25、r=0.10なら、再利用1回でprefix部分は安くなります。w=2.5、r=0.05なら、再利用が2回要ります。書込1回で再利用ゼロなら、どちらも通常より高いです。

保存費Hが別にかかるなら、条件は R > (w - 1 + H/P) / (1 - r) です。実際は、共通部分の長さ、モデルの最小サイズ、失効、prefixの変更、同時実行で変わります。現行の公式価格が似ているからといって、実際のヒット率まで同じだとは仮定しないでください。

もうひとつ。入力の読込費を90%下げても、仕事全体の費用が90%下がるわけではありません。通常入力が全費用の20%で、ほかが変わらないなら、全体の削減は最大でも 20% × 90% = 18% です（これも架空の例）。

13研究は何を教えてくれる？

以下は著者らの測定で、ぼくが再現したものではありません。古い単価や順位を、現在の費用対効果として使わないでください。

• AI Agents That Matter（Kapoorら、2024、arXiv preprint）。正解率と推論費を同時に評価して、単純なbaselineと費用をそろえて比べる必要を示しました。最適化の固定費と変動費も分けて考えます。
• Holistic Agent Leaderboard（HAL）（2025、ICLR 2026）。9モデル・9ベンチマーク・21,730 rolloutsを約$40,000で評価したと報告しています。比較の単位はモデルだけではなく、scaffold（エージェントの枠組み）とベンチマークです。付録では、キャッシュの計上が不完全であることや、単一実行が多くて不確実性を測れないことも認めています。
• τ-bench（2024、ICLR 2025）。会話終了時のDB状態を正解と照合して、pass^kで一貫性を見ます。ただし、利用者はLLMが模擬しています。現行READMEは旧タスクが未更新と警告しています。
• Towards a Science of AI Agent Reliability（2026、ICML 2026）。正確さだけでは一貫性・頑健性・予測可能性・失敗時の影響を表せない、と整理しました。費用や行動量の変動も別に見ます。
• METRの開発者生産性研究（2025）。16人・246タスクの無作為割当で、AI許可時に所要時間が19%増えたと報告しました。感覚と実測がずれることもある、と分かる結果です。ただし、2026年2月の追跡報告では、後続の実験に選択バイアスや並列利用の時間計測の問題があると説明しています。現在どれほど加速しているかを示す証拠は弱いとしています。2025年の19%を、今のモデルに当てはめないでください。

ひとつ、実務で効く小ネタです。HALの公開コード（確認したrevision）の_normalize_usageは、OpenAI形式の入力でキャッシュ書込を0と置いています。2026年10月22日に取得した公式仕様は、GPT-5.6以降で書込の内訳が別に出ると説明しています。古いcost trackerのusage変換を、新しいAPIにそのまま使い回さないでください。これは公開コードの該当分岐と現行仕様を読み比べて確認した違いで、HAL全体の請求誤差を測ったものではありません。

14実運用の報告：Cloudflareの$2.43→$0.77

2026年10月19日、CloudflareはAIコードレビューの平均費用が、比較対象の高費用だった2週間の$2.43から$0.77に下がったと報告しました（当事者の記事）。共通promptのキャッシュ共有、不要なturnの削減、モデルと推論量（effort）の変更などを組み合わせた結果です。

ただし、同じ品質を保ったまま、全業務で68%減らした実験ではありません。 記事自身が、コード品質レビューはhigh effortで重要な指摘が保たれた一方、performanceレビューはmediumで重要な指摘が減ったと書いています。

だからここから持ち帰るのは、削減率ではなく測り方です。費用の内訳と品質を並べて確認する。「68%」を、自分の業務の予測節約率に使わない。前後の期間でタスクの構成が違い、複数の変更を組み合わせているため、どの変更が何に効いたのかも切り分けにくくなっています。

15そのまま使える記録表

以下の表とCSV列は、この記事の提案です。使うと費用が下がることを、実験で示したものではありません。

1. 比較を始める前の条件表

再試行のルールやモデルを変えること自体を比べたいなら、それらまでそろえる必要はありません。「変えた条件」として明示し、入力・成功条件・期限・評価法を固定します。

2. 仕事単位の表（1行＝1job×1構成）

jobの費用にはそのjobの全attempt、子エージェント、検証を含めます。「その他直接費」と「復旧追加費」に、同じ金額を二重に入れないでください。

3. 呼出し単位の表（usageをそのまま保存）

comparison_id,job_id,attempt_id,branch_id,parent_call_id,call_id,request_id,provider,endpoint,model_id,model_version,price_snapshot_id,billing_mode,region,start_at,end_at,status,retry_layer,retry_reason,raw_usage_ref,ordinary_input_tokens,cache_read_tokens,cache_write_tokens,cache_write_ttl,output_tokens,thinking_tokens_included,tool_billable_units,currency,estimated_cost,actual_cost,cost_status

• cache_write_tokensは、TTL別に複数行、または別の内訳表にします。
• thinking_tokens_includedは出力の内訳として記録する値で、金額を自動で足す指示ではありません。
• 未知のフィールドや未対応のモデルは、cost_status=unknown のように判別できるようにします。小さい数字を黙って返す実装は避けます。
• 同じcall_idを再取得しただけなら、二回足しません。再送で別の実リクエストが走ったなら、区別します。
• ストリーミングの途中usageと最終usageが累積値なら、全イベントを足し上げません。原JSONを残して、最終値を取ります。

4. 人の作業・待ちの表

内訳の分数の合計と「実作業分」の合計を、二重に足さないでください。並列で見ていた時間は重なる区間を除きます。

5. 料金表の記録

price_snapshot_id,fetched_at,provider,official_url,model_id,endpoint,billing_mode,context_rule,region,currency,unit,input_price,output_price,cache_read_price,cache_write_price_by_ttl,cache_storage_price,tool_prices,discount_rule,effective_until

期間限定の割引は終了日も保存します（Gemini 4 Argonの価格は2026-11-30まで）。円換算するなら、USD実績とJPY換算を別の列にして、為替レート・日付・手数料を記録します。

6. 比較結果の表

16自分の運用で試す12ステップ

どれも未実施の手順案です。いきなり大規模なベンチマークは要りません。ただし、少数の好例だけで採用を決めないでください。

1. 仕事を1種類に絞る。 入力、成果、期限、失敗、重大誤りの条件を具体化します。
2. 測る範囲を先に書く。 APIだけか、人の時間込みか、初期投資込みか。待ちの金額換算は別枠です。
3. 同じ仕事集合を作る。 普通の例に加えて、過去に難しかった例、長文、ツールの失敗を入れます。
4. 調整用と評価用を分ける。 失敗例を見てpromptを直したなら、その同じ例の成績を最終結果にしません。
5. 全呼出しをjob_idに結ぶ。 本体、子エージェント、検証、ツール、再送。人の作業はタイマーで別に記録します。
6. A/Bの実行条件をそろえる。 可能なら順序を無作為化して、同じ時期・同じ入力で交互に走らせます。キャッシュはcold/warmを分けます。
7. 生成とは別に、受入判定する。 LLM採点を使うなら、採点モデル・prompt・誤判定を残して、費用も計上します。
8. 失敗を含む全件で集計する。 成功単価、成功率、期限超過、費用・時間の分布を同時に出します。
9. 請求と照合する。 自分のcost trackerの表示だけで確定しません。
10. 品質ゲートを先に判定する。 そのうえで費用差を比べます。差が小さくて標本が少ないときは「優劣未確定」です。「有意差がない」は「同品質が証明された」とは別です。
11. 変更は1つずつ評価する。 キャッシュの配置、出力長、ツール数、推論設定、再試行の上限、モデル切替を一度に変えると、何が効いたか分かりません。
12. 再確認の条件を決める。 料金・モデル・API・入力分布が変わったときや、再試行・p95が悪化したときに、保存した条件と比べます。

17費用を下げる施策と、一緒に見るもの

施策は候補で、効果は各運用で未検証です。「何を測れば採否を判断できるか」の表として使ってください。

トークンを減らしても、turn数が増えれば、そのたびに履歴を再入力して総費用が増えることがあります。逆に、検証費を増やして手戻りが減ることもあります。見る指標は部品の節約量ではなく、全jobの成功単価です。

18まだ分からないこと

確認できたのは、次のことです。

• 費用と正確さを同時に評価する必要は、本文と公開実装を持つ研究で検討されている。
• 現行の公式API料金は入力・出力・読込・TTL別書込・保存・ツールに分かれていて、usageの足し引きは提供元やAPI面で違う。
• pass@k、pass^k、検証器の合格、最終業務成功は別物。検証器に誤合格があれば、再試行の利益には限界がある。
• 最新の当事者の運用報告にも、費用削減と品質維持が全機能で一律には成り立たない例がある。
• 人の体感だけでは時間削減を確定できない。

一方、この記事からは次のことまでは言えません。

• 読者の業務で、どのモデルやscaffoldが一番安いか。
• 記録表や施策を使ったときの、実際の費用削減率。
• 公式料金と、読者の個別契約・無料枠・請求との一致。
• 人の確認時間や待ち時間の価値の、一般的な相場。
• エージェントの費用分布が一般に裾の重い特定の分布になるという主張。

19主な出典

論文・研究（いずれも2026年10月22日に本文を確認）：

• AI Agents That Matter
• Holistic Agent Leaderboard
• τ-bench
• The Limits of Inference Scaling Through Resampling
• Towards a Science of AI Agent Reliability
• METRの研究PDF、2026年の追跡報告

公式資料（取得日：2026-10-22）：

• OpenAI料金、Prompt caching、Agents APIのusage、Usage/Cost APIの例
• Claude料金、Claude Prompt caching、Usage and Cost API
• Gemini料金、Context caching、generateContent API、トークン計測
• openai-pythonのRetries

記憶の評価を「自分の業務で小さく回す」手順は、その記憶、本当に役に立ってる？にもまとめています。費用の比較でも、同じ「課題ごとに見比べる」考え方が使えます。