なぜ私のOpenClawセッションが1日で2150万トークンを消費したのか（そして実際にそれを解決した方法）
原文作者：MOSHIII
原文編集：Peggy、BlockBeats
編集者注：エージェントアプリケーションが急速に普及する中、多くのチームは、システムの動作は正常であるにもかかわらず、トークンコストが気づかないうちに着実に上昇しているという奇妙な現象に直面している。本稿では、実際のOpenClawワークロードを分析することで、コストの急増の原因がユーザー入力やモデル出力ではなく、見過ごされがちなコンテキストキャッシュの再再生（cached prefix replay）にあることを明らかにした。モデルは各呼び出しで膨大な履歴コンテキストを繰り返し読み込むため、大量のトークンが消費される。
具体的セッションデータを用いて、ツールの出力、ブラウザスナップショット、JSONログなどの大型の中間成果物がどのようにして履歴コンテキストに継続的に書き込まれ、エージェントループ内で繰り返し読み込まれるかを示します。
この事例を通じて、著者は明確な最適化のアプローチを提案しています：コンテキスト構造の設計、ツール出力の管理、そしてコンパクションメカニズムの設定まで。Agentシステムを構築している開発者にとって、これは単なる技術的なトラブルシューティング記録ではなく、実際のコスト削減に直結する貴重なガイドです。
以下が原文です：
私は実際のOpenClawワークロードを分析し、多くのAgentユーザーがすぐに気づくであろうパターンを見つけました：
トークンの使用量が非常に「活発」に見えます
返信もとても正常に見えます
しかし、トークンの消費量が突然爆発的に増加しました
以下は、今回の分析における構造の分解、根本原因、および実行可能な修正手法です。
要約
最大のコスト要因は、ユーザーのメッセージが長すぎるということではなく、膨大なキャッシュプレフィックスが繰り返し再再生されることである。
セッションデータによると：
総トークン数：21,543,714
キャッシュ読み取り：17,105,970（79.40%）
4,345,264（20.17％）
出力：92,480（0.43%）
言い換えると、ほとんどの呼び出しのコストは、新しいユーザーの意図を処理するのではなく、膨大な過去のコンテキストを繰り返し読み取ることに費やされています。
「待って、どうしてこんなことになったの？」という瞬間
私は当初、高トークン使用量は非常に長いユーザーのプロンプト、大量の出力生成、または高価なツール呼び出しによるものだと考えていました。
しかし、実際に主導しているモデルは：
数百から数千のトークン
cacheRead：1回の呼び出しで17万～18万トークン
つまり、モデルは各ラウンドで同じ巨大な安定したプレフィックスを繰り返し読み取っています。
データ範囲
私は2つのレベルのデータを分析しました：
1. 実行時ログ（runtime logs）
2、会話記録（session transcripts）
ご注意ください：
実行ログは、再起動、エラー、設定問題などの行動シグナルを監視するために主に使用されます。
トークン統計は、session JSONL の usage フィールドから正確に取得されます。
使用されたスクリプト：
scripts/session_token_breakdown.py
scripts/session_duplicate_waste_analysis.py
生成された分析ファイル：
tmp/session_token_stats_v2.txt
tmp/session_token_stats_v2.json
tmp/session_duplicate_waste.txt
tmp/session_duplicate_waste.json
tmp/session_duplicate_waste.png
トークンは実際にどこで消費されていますか？
1）セッション集中
他のセッションよりも消費がはるかに高いセッションがあります：
570587c3-dc42-47e4-9dd4-985c2a50af86：19,204,645 テクスン
そして、明らかに急激な低下：
ef42abbb-d8a1-48d8-9924-2f869dea6d4a：1,505,038
ea880b13-f97f-4d45-ba8c-a236cf6f2bb5：649,584
2）行動の集中
トークンの主な出所：
ツール使用：16,372,294
停止：5,171,420
問題の主な原因は通常のチャットではなく、ツール呼び出しチェーンのループです。
3）時間集中
トークンのピークはランダムではなく、特定の数時間の間集中しています：
2026-03-08 16:00：4,105,105
2026-03-08 09:00：4,036,070
2026-03-08 07:00：2,793,648
巨大なキャッシュプレフィックスには何が含まれているのでしょうか？
対話内容ではなく、主に大規模な中間生成物：
巨大なtoolResultデータブロック
長いリーズニング／思考トレース
Large JSON snapshot
ファイル一覧
ブラウザがデータを収集
サブエージェントの会話履歴
最大セッションでは、文字数は約：
366,469 文字
assistant:thinking：331,494 文字
assistant:toolCall：53,039 文字
これらのコンテンツが履歴コンテキストに保持されると、以降の各呼び出しではキャッシュプレフィックスを通じて再読み取りされる可能性があります。
具体的な例（セッションファイルより）
以下の位置に、膨大なコンテキストブロックが繰り返し存在しています：
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70
大型ゲートウェイJSONログ（約37,000文字）
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134
ブラウザスナップショット + セキュアラッピング（約2.9万文字）
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219
巨大なファイルリストの出力（約4.1万文字）
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311
session/status 状態スナップショット + 大規模なプロンプト構造（約3万文字）
「重複コンテンツの無駄」vs「キャッシュリプレイの負荷」
私も単一呼び出し内の重複コンテンツの割合を測定しました：
繰り返し比率：約1.72%
確かに存在しますが、主要な問題ではありません。
本当の問題は、キャッシュプレフィックスの絶対的な量が大きすぎることです。
構造は：巨大な履歴コンテキスト、各呼び出しで再読み取り、上部にわずかに新しい入力を追加する
したがって、最適化の重点は重複排除ではなく、コンテキストの構造設計にあります。
なぜエージェントループはこの問題を特に起こしやすいのですか？
三つのメカニズムが重なり合います：
1、大量のツール出力が履歴コンテキストに書き込まれました
2、ツールのループにより、短い間隔での多数の呼び出しが発生します。
3、プレフィックスの変更が非常に小さい → キャッシュが毎回再読み取りされる
コンテキストコンパクションが安定してトリガーされない場合、問題は急速に拡大します。
最も重要な修正戦略（影響の順に並べた）
P0—巨大なツール出力を長期コンテキストに詰め込まないでください
超大ツール出力用：
- 保留要約 + 参照パス/ID
- 元のペイロードをファイルアーティファクトに書き込む
- チャット履歴に全文を残さないでください
これらのカテゴリを優先的に制限してください：
- 大規模なJSON
- 長いディレクトリリスト
- ブラウザの完全なスナップショット
- サブエージェントの完全なトランスクリプト
P1—コンパクションメカニズムが実際に有効になっていることを確認する
このデータでは、コンパクションキーが無効であるという構成互換性の問題が複数回発生しています。
これは最適化メカニズムを静かに無効にします。
正しい方法：互換性のあるバージョンの設定のみを使用してください
その後、検証してください：
openclaw doctor --fix
起動ログを確認して、コンパクションが受け入れられたことを確認してください。
P1—リーズニングテキストの永続化を削減
長い推論テキストが繰り返しリプレイされないようにしてください
本番環境では：完全な推論ではなく、短い要約を保存してください
P3—プロンプトキャッシュの設計を改善
目的はcacheReadを最大化することではない。目的は、コンパクトで安定し、高価値なプレフィックスにcacheを使用することである。
提案：
- 安定ルールをsystem promptに組み込んでください
- 不安定なデータを安定プレフィックスに含めないでください
- 毎回大量のデバッグデータを投入しないでください
実践的なストップロス方案（もし私が明日対応するなら）
1、cacheReadの割合が最も高いセッションを特定する
2、runaway session に対して /compact を実行してください
3. ツールの出力にトリミング＋アーティファクト化を追加
4. 修正ごとにトークン統計を再実行してください
重要なKPIを4つ追跡：
キャッシュ読み取り / 合計トークン
toolUse avgTotal/call
10万トークン以上の呼び出し回数
最大セッション占有率
成功のシグナル
最適化が適用された場合、以下が表示されます：
10万回以上のトークン呼び出しが明確に減少
キャッシュ読み取りの割合が低下
toolUseの呼び出し重みが低下しました
個々のセッションの支配度が低下
これらの指標に変化がない場合、あなたのコンテキスト戦略は依然として緩すぎます。
実験を再現するコマンド
python3 scripts/session_token_breakdown.py 'sessions' \
--include-deleted \
--上位20位
--outlier-threshold 120000 \
--json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt
python3 scripts/session_duplicate_waste_analysis.py 'sessions' \
--include-deleted \
--上位20位
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt
まとめ
エージェントシステムが正常に動作しているように見えても、コストが継続的に上昇している場合は、まず以下の点を確認してください：新たに課金されているのは新しい推論なのか、それとも古いコンテキストを大規模に再実行しているのか。
私のケースでは、ほとんどのコストはコンテキストのリプレイから発生しています。
この点に気づけば、解決策は明確になります：長期コンテキストへのデータ投入を厳格に制御する。