実測した数字

セッションの長さ    17時間
ターン数           469
cache_read        108,575,962 トークン
→ 1ターンあたり    231,505 トークン

1回のやりとりごとに、23万トークンを読み直していました。

会話が長くなるほど、AIは毎回それまでの全部を読み返します。作業が進むほど、1歩の値段が上がっていく。

トークンを節約したいなら、最初に見るのはプロンプトの長さではなく、セッションの寿命です。

「AIに任せると高い」は、逆でした

同じ期間、専門の作業を別エージェントに投げた場合の数字です。

エージェントA   158,481トークン / 47回の操作 = 1回あたり 3,372
エージェントB   226,688トークン / 74回の操作 = 1回あたり 3,063
本体（1ターン）                              231,505

約69分の1です。

キャッシュ読みの単価を1/10で見積もっても、投げるほうが7倍安い計算になります。

私は逆に理解していました。「エージェントを増やすと高い」と思って、自分で抱え込んでいた。3日目の作業455分のうち、85%は本来なら投げるべきものでした。

前日に「どのエージェントが高いか」を測っていたからです。

比べたのはエージェント同士でした。「自分でやった場合」が比較対象に入っていなかった。

問いは「任せるのと自分でやるの、どちらが安いか」だったのに、測ったのは「AとB、どちらが安いか」でした。

問いに答える量ではなく、関連する別の量を測っていた。

この3日間で、私は同じ型の間違いを8回しました。

もうひとつ、構造的な失敗を書きます。

長時間動くジョブがありました。それを見張る監視をつけていた。

ジョブを止めようとする過程で、私は先に監視のほうを止めました。

その1時間後、ジョブは別の理由で異常終了しました。誰も気づきませんでした。

13:25  ジョブが異常終了
14:21  人間が「進んでる?」と聞いて、はじめて発覚
→ 57分間、何も動いていなかった

止めたい対象こそ、止まった瞬間を知る必要があります。

いま監視は機械が持っています。人もAIも持ちません。人が持つと、その人が止めた瞬間に見る目が消えるからです。

朝   「32件が未完」という記録 → 実測したら全部完了していた
夜   設定ファイルの古い記述 → 自動設定にそのまま取り込まれかけた
夜   公開物の記録が古く → 解決済みの問題を「未解決」として報告した

生成物ではなく、記録のほうが古い。

AIは書かれていることを信じます。疑いません。だから記録が古いと、AIは古い前提で正しく推論して、間違った結論に着きます。

いまは機械が毎晩、記録と実物を突き合わせています。

6,480個のファイルを検査したら、6,480個すべてが異常と出ました。

そのまま報告するところでした。

全部が同じずれ方をしている時点で、疑うべきはデータではなく検査です。

判定式が1バイトずれていました。そして本物の異常が1件だけあり、6,479件の偽陽性に埋もれて見えなくなっていました。

異常率が0%か100%に張り付いたら、それは発見ではなく実装の誤りの合図です。

1  高いのはエージェントの数ではなく、セッションの寿命
2  所有者がいる作業は投げる。内製は7〜69倍高い
3  見張りは機械が持つ。人が持つと、人が止めた瞬間に消える
4  律速は生成ではなく検証。8回の訂正のうち、生成の失敗は1つもなかった

4番目がいちばん大きい。

AIは速く作ります。問題は、作ったものが正しいかを確かめる側が追いつかないことです。

だから私は、確かめる仕組みのほうを機械にしました。 生成をAIに、検証を機械に、判断だけを人に。

この記事は note にも同じ内容で公開しています（筆者本人による転載）。

AIエージェントを実際に回して、かかった費用と壊れた箇所を測って書いています。推測は書きません。実測値だけです。

**無料記事は結論まで全部書きます。**出し惜しみはしません。

この記事は note にも同じ内容で公開しています（筆者本人による転載）。