OpenClawが1日で2150万トークンを消費？3つの最適化戦略でコストを大幅削減

原文タイトル：Why My OpenClaw Sessions Burned 21.5M Tokens in a Day (And What Actually Fixed It)

原文著者：MOSHIII

原文翻訳：Peggy，BlockBeats

編者注：エージェントアプリケーションが急速に普及している現在、多くのチームが一見矛盾する現象を発見しています：システムは正常に動作しているが、トークンコストは知らないうちに上昇し続けている。本稿では、実際のOpenClawワークロードを分解することで、コスト爆発の原因がユーザー入力やモデル出力ではなく、見過ごされがちなコンテキストキャッシュ再生（cached prefix replay）にあることが多いことを明らかにしています。モデルは各呼び出しで膨大な履歴コンテキストを繰り返し読み取り、大量のトークン消費を生み出します。

本稿では、具体的なセッションデータを用いて、ツール出力、ブラウザスナップショット、JSONログなどの大規模な中間生成物がどのように履歴コンテキストに書き込まれ、エージェントのループで繰り返し読み取られるかを示しています。

このケースを通じて、著者は明確な最適化の考え方を提案しています：コンテキスト構造設計、ツール出力管理からcompactionメカニズム設定まで。エージェントシステムを構築している開発者にとって、これは技術的なトラブルシューティングの記録であると同時に、真のコスト削減ガイドでもあります。

以下が原文です：

私は実際のOpenClawワークロードを分析し、多くのエージェントユーザーが認識するだろうパターンを発見しました：

トークン使用量は「活発」に見える

応答も正常に見える

しかし、トークン消費が突然爆発的に増加する

以下は、この分析の構造分解、根本原因、そして実際に実行可能な修正パスです。

TL;DR

最大のコスト要因は、ユーザーメッセージが長すぎることではありません。膨大なキャッシュプレフィックス（cached prefix）が繰り返し再生されることです。

セッションデータから：

総トークン数：21,543,714

cacheRead：17,105,970（79.40%）

input：4,345,264（20.17%）

output：92,480（0.43%）

言い換えれば：ほとんどの呼び出しのコストは、新しいユーザー意図の処理ではなく、膨大な履歴コンテキストの繰り返し読み取りに費やされています。

「待って、どうしてこうなった？」という瞬間

私は当初、高いトークン使用量は以下の原因だと考えていました：非常に長いユーザープロンプト、大量の出力生成、または高価なツール呼び出し。

しかし、実際に支配的だったパターンは：

input：数百から数千トークン

cacheRead：呼び出しごとに17万から18万トークン

つまり、モデルは毎回、同じ巨大で安定したプレフィックスを繰り返し読み取っていたのです。

データ範囲

私は2つのレベルのデータを分析しました：

1、実行時ログ（runtime logs）

2、セッション記録（session transcripts）

注意点：

実行ログは主に行動シグナル（再起動、エラー、設定問題など）の観察に使用

正確なトークン統計は、セッション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）行動集中

トークンは主に以下から発生：

toolUse：16,372,294

stop：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データブロック

長いreasoning / thinking traces

大規模なJSONスナップショット

ファイルリスト

ブラウザスクレイピングデータ

サブエージェントの会話記録

最大のセッションでは、文字数はおよそ：

toolResult:text：366,469 文字

assistant:thinking：331,494 文字

assistant:toolCall：53,039 文字

これらの内容が履歴コンテキストに保持されると、後続の呼び出しは毎回、キャッシュプレフィックスを通じてそれらを再読み取りする可能性があります。

具体例（セッションファイルより）

以下の位置で、膨大な量のコンテキストブロックが繰り返し出現しています：

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70

大規模なゲートウェイJSONログ（約3.7万文字）

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%

確かに存在しますが、主要な問題ではありません。

真の問題は：キャッシュプレフィックスの絶対的な量が大きすぎること

構造は：巨大な履歴コンテキスト、毎回の呼び出しで再読み取り、その上に少量の新しい入力が追加される

したがって、最適化の重点は重複排除ではなく、コンテキスト構造設計です。

なぜエージェントループは特にこの問題を起こしやすいのか？

3つのメカニズムが相互に作用します：

1、大量のツール出力が履歴コンテキストに書き込まれる

2、ツールループは大量の短間隔呼び出しを生成する

3、プレフィックスの変化が小さい → キャッシュが毎回再読み取りされる

もしcontext compactionが安定してトリガーされない場合、問題は急速に拡大します。

最も重要な修正戦略（影響順）

P0—巨大なツール出力を長期コンテキストに詰め込まない

超大規模なツール出力に対して：

• 要約 + 参照パス / IDを保持
• 元のペイロードはファイルアーティファクトに書き込み
• 完全な原文をチャット履歴に保持しない

以下のカテゴリを優先的に制限：

• 大規模なJSON
• 長いディレクトリリスト
• ブラウザの完全なスナップショット
• サブエージェントの完全なtranscript

P1—compactionメカニズムが実際に有効であることを確認

このデータでは、設定の互換性問題が複数回発生しています：compaction keyが無効

これは最適化メカニズムを静かに無効にします。

正しい方法：バージョン互換設定のみを使用

そして検証：

openclaw doctor --fix

起動ログをチェックしてcompactionが受け入れられたことを確認。

P1—reasoningテキストの永続化を減らす

長い推論テキストが繰り返し再生されるのを避ける

本番環境では：完全なreasoningではなく、短い要約を保存

P3—プロンプトキャッシング設計の改善

目標はcacheReadを最大化することではありません。目標は、コンパクトで安定した高価値のプレフィックスでキャッシュを使用することです。

提案：

• 安定したルールをsystem promptに入れる
• 不安定なデータを安定したプレフィックスに入れない
• 毎回大量のデバッグデータを注入しない

実践的損切り策（もし私が明日対応するとしたら）

1、cacheRead比率が最も高いセッションを見つける

2、runaway sessionに対して /compact を実行

3、ツール出力に切り捨て + アーティファクト化を追加

4、変更のたびにトークン統計を再実行

重点的に追跡する4つのKPI：

cacheRead / totalTokens

toolUse avgTotal/call

>=100k トークンの呼び出し回数

最大セッションの比率

成功のシグナル

最適化が有効であれば、以下の変化が見られるはずです：

100k+ トークンの呼び出しが明らかに減少

cacheRead比率が低下

toolUse呼び出しの重みが低下

単一セッションの支配度が低下

これらの指標に変化がない場合、コンテキスト戦略が依然として緩すぎることを示しています。

再現実験コマンド

python3 scripts/session_token_breakdown.py 'sessions' \

--include-deleted \

--top 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 \

--top 20 \

--png-out tmp/session_duplicate_waste.png \

--json-out tmp/session_duplicate_waste.json \

> tmp/session_duplicate_waste.txt

結語

もしあなたのエージェントシステムが正常に見えるのに、コストが上昇し続けているなら、まず一つの問題を確認してください：あなたが支払っているのは新しい推論なのか、それとも大規模な古いコンテキストの再生なのか？

私のケースでは、コストの大部分は実際にはコンテキスト再生から来ていました。

この点に気づけば、解決策も明確です：長期コンテキストに入るデータを厳密に管理すること。

原文リンク