AIの利用料は「作った量」でなく「コンテキストの長さ×往復の回数」で決まる

relmeaの2026-09-10の利用ログ実測（24時間・11,519リクエスト）では、費用の内訳は次の通りでした。

  • キャッシュ読み直し（過去の会話の再読込）：70.6%
  • 実際に生成した出力：11.9%
  • 入力（キャッシュに乗らない新規分）など：17.5%（残差）

70.6%と11.9%を足すと82.5%になり、残りの17.5%が新規の入力分などに相当します。この1日だけで、週次の利用上限の30%を消費しました。

「作った量」で説明できない理由

この内訳を見ると、費用の大半を占めているのは、その日に新しく生成した成果物ではありません。過去の会話を読み直す処理が7割を超えています。つまり、同じ作業量でも「1回のやり取りでどれだけの過去の文脈を読み直しているか」によって、費用が何倍にも変わる構造になっています。

作業の成果物の分量を見て費用を見積もると、この構造とは無関係な数字を見ていることになります。

なぜキャッシュの読み直しが費用の大半を占めるのか

AIエージェントとのやり取りは、1往復ごとに完結しているように見えて、実際には毎回「それまでの会話全体」を入力としてモデルに渡し直しています。10往復目のやり取りでは、1往復目から9往復目までの会話履歴と、実行したコマンドの出力、読み込んだファイルの中身がすべて入力に含まれます。

キャッシュはこの再送信そのものを無くす仕組みではありません。同じ内容を読み直す単価を下げる仕組みです。単価が下がっていても、読み直す対象そのものが増え続ければ、費用に占める比率はキャッシュ読み直し側に寄っていきます。relmeaの実測で70.6%という数字が出たのは、この「毎回、過去全体を読み直す」構造が積み重なった結果です。

短いセッションでは気づきにくい

やり取りが数往復で終わるセッションでは、読み直す会話履歴自体が短いため、この構造が費用に与える影響は小さく見えます。問題が顕在化するのは、1つのセッションを長く続けたときです。会話履歴が伸びるほど、次の1往復のために読み直す量も伸びていきます。

作業内容が変わっていなくても、セッションの長さだけで1往復あたりの費用が上がっていく理屈です。

往復の回数が費用を増幅する — 1操作が1回の再課金になる

コンテキストの長さが1往復あたりの単価を決めるとすれば、往復の回数はその単価に掛かる倍率になります。同じ長さのコンテキストでも、10往復で終わる作業と100往復かかる作業では、費用は単純計算で10倍近く変わります。

relmeaの直近14日間の実測（2026-09-10時点）では、スクリーンショットを撮って座標をクリックする操作が2,492回、複数の操作を1回にまとめて実行する操作が505回でした。1操作ごとにその時点の全文脈が再課金されるため、細かい操作に分割するほど往復の回数が増え、費用も比例して増えていきます。

どの作業をどのツールに振るか自体は、判断量と往復量の2軸で決める設計として別記事で扱っているため、ここでは深入りしません。本稿で押さえておきたいのは、往復の回数そのものがコンテキストの長さと掛け算になって効いてくる、という一点です。

セッションを分けると何が変わるか — 実測240Mから144M

コンテキストの長さと往復の回数が掛け算で効くのであれば、セッションをどこで区切るかは費用の設計そのものになります。relmeaでは2026-09-10に、この点を実測で確かめました。

150kで区切ると何が起きるか

同じ2026-09-10の利用ログについて、作業内容を一切変えず「全ターンのコンテキストを150kトークンで頭打ちにする」と仮定して再計算したところ、総トークンは240Mから144Mに減りました。

  • 実際の運用（頭打ちなし）：総トークン 240M（週次上限の32%相当）
  • 150kで頭打ちにした場合：総トークン 144M（週次上限の19%相当）

144を240で割ると0.6で、40%の減少に相当します。週次上限に対する比率で見ても32%から19%へ下がっており、この比率とおおむね一致しています（検算済み）。作業内容そのものは変えていないため、この差はすべてセッションの長さの制御によるものです。

1つのセッションが伸び切った事故

同じ2026-09-10前後の運用記録には、実際に長いセッションが費用を押し上げた例が残っています。広告配信の設定作業を1本、同じセッションの中で続けたところ、往復が1,394回に達し、コンテキストは93kから892kトークンまで無圧縮のまま伸びました。この1本の作業だけで、週次の利用上限の11%を消費しています。

このとき使っていたのは、長いコンテキストを扱える1Mトークン枠のモデルでした。通常であれば一定の長さで自動的に圧縮が入りますが、枠が大きいぶん圧縮が入る前にコンテキストが伸び切ってしまいました。1本の作業を1つのセッションで続けたこと自体よりも、圧縮が効かないまま伸ばせる環境を選んでいたことが、費用を押し上げた直接の要因です。

作業の区切りとセッションの区切りを合わせる

1つのセッションを跨いで別件の作業を続けると、前の件の全文脈を、次の件のやり取りでも毎ターン読み直すことになります。前の事故の場合、広告配信の設定という1本の作業を最初から最後まで同じセッションで続けたこと自体は自然な判断でしたが、往復が1,394回にまで積み上がった時点で、途中でセッションを切って作業を引き継ぐという選択肢がありました。

作業の区切りとセッションの区切りを一致させることが、コンテキストを無制限に伸ばさないための最も単純な手当てになります。

長時間・多往復になりそうな作業には、1Mトークン枠のような大きなコンテキストを扱えるモデルを使わない、という判断も合わせて必要です。大きな枠は「一度に巨大な入力を読ませる」場面では有効ですが、往復が多い作業に使うと、圧縮が効く前提が崩れ、1ターンあたりの単価が通常より高いまま伸び続けてしまいます。

コンテキストは会話の外側でも太る — 常時読み込みの指示書

セッションの長さだけでなく、毎ターン必ず読み込まれる「指示書」の分量そのものが、コンテキストの土台を太らせることもあります。

relmeaの運用では、毎ターン読み込まれるプロジェクト設定ファイルに、125体のエージェントの名簿が23,776字、その索引が11,600字と、同じ内容が2つの場所に二重掲載されていました（relmeaの2026-09-10の運用記録）。この名簿は会話が始まる前からすでにコンテキストに乗っている分量であり、往復の回数やセッションの長さとは無関係に、すべてのやり取りに毎回上乗せされていました。

2026-09-10に、この名簿を別ファイル（参照用の索引ファイル）へ一本化し、常時読み込む指示書の側にはルールだけを残す形に整理しました。セッションの長さを制御する工夫と、常時読み込む土台そのものを軽くする工夫は別物です。往復のたびに何が再送信されているかを見直すと、会話の履歴だけでなく、会話が始まる前から乗っている分量にも目を向ける余地があります。

セッション運用として採用しているルール

ここまでの実測を踏まえて、relmeaが実際に採用しているセッション運用のルールは次の通りです。

  • コンテキストが150kトークンを超えたら、圧縮するか新しいセッションへ切る
  • 1つの作業は1つのセッションで完結させる。別件を同じセッションに続けて持ち込まない（前件の全文脈を毎ターン読み直すことになるため）
  • 往復が多くなりそうな作業には、1Mトークン枠のような大きなコンテキストのモデルを使わない（巨大な入力を一度に読ませる場面だけに使う）
  • ブラウザ操作は複数の操作を1回にまとめる。画面の文字を確認するだけなら、操作を伴わない本文取得で済ませる
  • 「どのファイルが正しいか」を毎回検索し直さない。先に索引・正典の場所を確認してから作業に入る
  • 並列で動かすセッションの本数を増やしても総量は増えず、絞っても減らない。効いてくるのはセッション1本あたりの長さと往復の回数であり、本数ではない

もう1点、同じ画面を毎回操作するような繰り返し作業では、一度だけ操作の手順をスクリプトとして保存し、以降は実行するだけにする、という運用も合わせて行っています。判断が必要なのは「何を出すか」であって、「どの画面のどこをクリックするか」ではないためです。

AIエージェントの利用料は、作った成果物の量では説明がつきません。1回のやり取りでどれだけの文脈を読み直しているか、そのやり取りが何回続くか。この2つの掛け算で決まっています。費用が読みにくいと感じたときは、まずセッションを開いたままの時間と、そこで何往復のやり取りが積み上がっているかを確認するところから始められます。