5 人のチームが新しい AI agent を試した。AI agent とは、複数のステップを自分で続けて実行する AI アシスタントのことだ。競合他社の発表資料 20 件を整理させ、要点を社内ドキュメントにまとめさせた。モデルの価格は魅力的で、入力 token（モデルが文章量と料金を数える単位）100 万あたり 2 ドルだった。ところが 1 週間後の請求額は、見積もりの数倍になっていた。誰も無駄遣いはしておらず、タスクを動かしたのも十数回にすぎない。

お金はどこに消えたのか。大半は「20 件の発表資料を読んだこと」ではない。長時間タスク特有の二種類の繰り返しに使われていた。ステップごとにコンテキスト全体を送り直すことと、失敗した後に最初からやり直すことだ。どちらも料金表には出てこないが、長時間タスクの請求額を決めているのはこの二つである。だから長時間タスクの上限は、プロンプトに書くだけでは足りない。モデルの外側にあるプログラムが、タスク全体で共有する一つの予算として管理する必要がある。

単価は下がっても、請求額は下がらない

今年 7 月、イーロン・マスク傘下で旧 xAI の SpaceXAI が、新モデル Grok 4.5 を発表した。価格は入力 token 100 万あたり 2 ドル、出力 token 100 万あたり 6 ドルだ。TechCrunch は Anthropic のフラッグシップモデル Opus 4.7 と比べており、こちらは 5 ドルと 25 ドルである。SpaceXAI は、同じ種類のプログラミング作業でライバルより少ない出力 token で済む、token 効率の高さも強調した。

こうした数字を見ると、以前は高すぎると思えた長時間タスクの多くが試す価値のあるものに見えてくる。大量の資料の整理、多数のファイルにまたがるコード修正、サポート記録をまとめて読んでの分類などだ。問題は、料金表が答えるのは「100 万 token を読むといくらか」なのに対し、長時間タスクの請求額は「全部で何回読んだか」で決まることだ。

お金の行き先：呼び出しのたびにコンテキスト全体を読み直す

長時間タスクとは、agent が何ステップも続けてようやく終えられる作業のことだ。ファイルを読み、ツールを呼び、結果を見て、次の一手を決める。Anthropic のドキュメントは、ツールを使う agent についてはっきり書いている。各ステップは通常、新しい API 呼び出し、つまりプログラムからモデルへの新しいリクエストになる。モデル自身は前の呼び出しの内容を覚えていないため、呼び出しのたびに、それまでの会話、読んだファイル、ツールの返した結果をすべて送り直す必要がある。

つまり費用はステップ数に比例して均等に増えるわけではない。仮の例で計算してみよう。1 ステップごとにコンテキストが 2,000 token 増えるとすると、1 ステップ目で送るのは 2,000 token、10 ステップ目で 20,000 token、30 ステップ目には 1 回で 60,000 token になる。30 ステップを合計すると、モデルが読み込んだ入力は約 93 万 token で、そのうち本当に「新しい」内容は 6 万 token にすぎない。

各社はこの繰り返しを和らげるためにキャッシュを提供している。Anthropic を例にとると、キャッシュから読み出す token は基本の入力価格の 10 分の 1 で済む一方、キャッシュへの書き込みは 25% 割高になる。ただしキャッシュの保持期間は初期設定で 5 分しかなく、使うたびにタイマーがリセットされる。この細部は実務で効いてくる。agent が人の確認を待って止まり、その人が 20 分の会議に出ていれば、戻ったころにはキャッシュが切れていて、次のステップでコンテキスト全体をもう一度書き込むことになる。

広告

二つ目の費用：失敗したら最初から

二つ目の繰り返しはやり直しだ。長時間タスクが 25 ステップ目で、あるファイルの形式が想定外だったために失敗したとする。よくある対応は、最初からやり直すことだ。それまでの 24 ステップで積み上がった入力すべてに、もう一度お金を払うことになる。「失敗したら自動で 2 回まで再試行」と設定していれば、最悪の場合、同じ作業に 3 回払い、3 回とも失敗する。

この費用の厄介なところは、目に見えないことだ。請求書に出るのは使った token の量だけで、そのうちどれだけがやり直しだったかは教えてくれない。チームに見えるのは「今月はなんだか高い」という感覚だけで、どの種類のタスクのどのステップで費用が膨らんだのかはわからない。

なぜプロンプトに書いた上限は数に入らないのか

多くのチームが最初にやるのは、agent のシステムプロンプトに「費用が 5 ドルを超えたら止まること」と一行加えることだ。問題は、モデルには請求書が見えないことにある。モデルはここまでに何 token 使ったかも、今回の呼び出しがいくらかも知らない。せいぜい「控えめにしよう」と自分に言い聞かせることしかできず、予算が尽きたときに実際に止まることはできない。

上限を確実に守らせられるのは、モデルを呼び出す側のプログラムだけだ。呼び出しのたびに、API はその回に使った入力と出力の token 数を返す。プログラムはそれを足し上げ、次の呼び出しを送る前に残りの予算を確認する。足りなければ送らず、その時点の結果と止めた理由を担当者に渡す。

この予算は「タスク全体」を単位にする。再試行に新しい枠を与えず、最初の実行と同じ予算を共有させる。そうしないと、「再試行は最大 2 回」が実質的に上限を 3 倍に広げてしまう。

厳しい上限の代償

厳格な上限にもコストはある。9 割まで進んだところで上限に達すれば、それまでの費用で得られるのは作りかけの成果物だ。この無駄を減らすには、上限に途中保存を組み合わせるとよい。一つの段階を終えるたびに整理した中間結果を保存し、やり直すときは最後の保存地点から再開して、最初から読み直さないようにする。そうすれば失敗の代償は一段階分で済み、タスク全体にはならない。

また、すべてのタスクにこの仕組みが必要なわけではない。3〜5 ステップで終わる短いタスクなら、コンテキストはあまり積み上がらず、やり直しも安い。予算管理を設計する手間のほうが高くつく。上限を設ける価値があるのは、ステップ数が多い作業、大量のファイルを読む作業、自動で再試行しうる作業である。

まず 1 週間測ってから、上限を決める

上限をいくらにすべきかに、共通の答えはない。タスクごとにステップ数もコンテキストの大きさも失敗率も違う。他人の数字をそのまま当てはめれば、きつすぎてタスクが途中で止まってばかりになるか、ゆるすぎて上限がないのと同じになる。

より現実的なのは、チームがすでに動かしている長時間タスクを一つ選び、1 週間記録することだ。1 回の実行で何ステップ進んだか、各ステップで何 token 送ったか、何回再試行したか、キャッシュがどれだけ当たったか。1 週間たてば、このタスクが通常いくらで終わるかがおおよそわかる。上限はその通常値より少し高いところに置けばいい。上限を超えた回こそ、人が目を通す価値のある異常だ。

この記録は、どこで節約すべきかも教えてくれる。再送したコンテキストが費用の大半なら、まずキャッシュが効いているか、使わないファイルを丸ごとコンテキストに詰め込んでいないかを確かめる。確認待ちの間にキャッシュが切れることが多いなら、確認を少数の段階にまとめるか、長めのキャッシュ期間を検討する。Anthropic の場合、1 時間キャッシュの書き込みは基本入力価格の 2 倍だが、待ち時間の長いタスクでは何度も書き直すより安くつくことがある。再試行が費用の大半なら、直すべきは失敗の原因であり、上限を上げても同じ失敗に何度も払うだけだ。

この記事が扱っているのは、一つのタスクの予算だ。チーム全体で毎月の AI 費用をどう配分し、誰がどれだけ使えるかは別の層の問題で、AI の請求は、百万トークンあたりの値段ではなく、採用された成果一件あたりの費用で測るが参考になる。

その長時間タスクがコーディングなら、渡す前に小さく分けられないか確かめてほしい。その issue を coding agent に渡せるかは、最初の diff を書き出せるかで決まるも参考になる。小さく分けるほど各部分のコンテキストは短くなり、失敗したときにやり直す量も減る。

AI 整理カード

長時間タスクの本当の費用を AI に見積もってもらう このプロンプトは、まずタスクの動き方を確認し、コンテキストの再送と再試行がそれぞれどれだけを占めるかを計算したうえで、最初の予算上限と保存地点を提案する。

ある長時間の AI タスクの本当の費用を見積もり、最初の予算上限を決めたい。
背景はこの記事による：https://boosterminiclass.com/ja/posts/long-running-ai-task-token-cost-limits/
記事の見方はこうだ。長時間タスクの請求額は主に、ステップごとのコンテキスト再送と失敗後のやり直しから生じる。上限はプロンプトに書くだけでなく、モデルを呼び出すプログラムが「タスク全体で共有する一つの予算」として管理しなければならない。

まず私に 3 つ質問してほしい：
1. このタスクは平均で何ステップ進むか。各ステップでどれくらいの新しい内容を読み込むか；
2. 失敗したとき、いまはどう対応しているか。全体をやり直すか、途中から再開するか、自動で何回か再試行するか；
3. タスクの途中で人の確認を待って止まることはあるか。待ち時間はふつうどれくらいか。

私の回答をもとに、次を出力してほしい：
- 簡単な計算式で、1 回の完全な実行で読み込む入力 token の総量を見積もり、そのうち再送されたコンテキストがどれだけかを示す；
- 1 回失敗してやり直すと、どれだけ余計にかかるか；
- タスク全体の予算上限の提案と、どの段階で途中保存をすべきか；
- 上限を修正するために、これから 1 週間どの数字を記録すべきか。
見積もりにはすべて前提を明記すること。情報が足りなければ、自分で数字を補わずに私に質問してほしい。

見積もりは出発点にすぎない。実際の上限は、1 週間の実データをもとに決める。

広告

Share

このミニクラスを共有

このミニクラスが仕事の詰まりをほどく助けになったら、AI の使い方を考えている人にも共有してください。

参考資料