Token使用量の最適化——41%削減を達成

Joe | 2026-02-15

1日1.4M Tokensを消費

TokenはAIシステムの燃料であり、最も直接的なコストでもある。OpenClawクラスタの1日あたりのtoken消費量を初めて詳細に集計した時、その数字に驚かされた：1日1.4M tokens。

この規模が意味するものは何か？大雑把に換算すると、ClaudeのAPI標準価格で計算すれば、API呼び出しコストだけで毎月かなりの出費になる。さらに重要なのは、高消費はシステム内に大量の不要な計算が存在することを意味している——これらのtokenは一体どこに使われているのか？

3つの大口消費元を特定

ログを分析した結果、3つの高消費cronタスクを発見した。いずれも以前、特定の目的のために設定されたものだが、時間の経過とともに、すでに役目を終えたか、実行頻度が過剰になっていた。

これら3つのタスクの特徴は：実行頻度が高い（15分ごとに実行されるものもある）、毎回大量のコンテキストをロードする、そして実際の産出価値がすでに非常に低い、ということだ。典型的な「設定したら忘れてしまう」技術的負債である。

これら3つのタスクを停止した結果、日次消費は1.4Mから827K tokensに直接低下した——41%の削減だ。

この結果は嬉しくもあり恥ずかしくもあった。嬉しいのは最適化効果が即座に現れたこと、恥ずかしいのはこの無駄がこれほど長く続くべきではなかったことだ。教訓は明確だ：cronタスクのリソース消費を定期的に監査すること。無人で放置された自動タスクが静かに予算を食い潰すのを許してはならない。

弾力的な管理戦略

停止は削除を意味しない。これら3つのタスクのロジック自体に問題はなく、常に必要というわけではないだけだ。そこで弾力的な管理戦略を設計した：

• 平日通常モード：コアタスクの実行を維持し、非重要タスクは必要に応じて有効化
• 週末・外出モード：不要なタスクをすべて一時停止し、アラートと基本監視のみ維持
• 低消費モード：tokenの残高が不足した場合に自動的に切り替え、最小限の運用のみ維持

この柔軟な切り替え能力は重要だ。AIシステムの運用コストは固定ではなく、実際のニーズに応じて動的に調整すべきものだ。家に誰もいない時に電気を消すのと同じくらい自然なことだ。

Token制限の本当の原因

積極的な最適化に加えて、以前から困っていたToken制限の問題も修正した。症状としては、特定のagentが頻繁に「token limit exceeded」エラーを出すが、理屈上は単一の会話でリミットを超えるはずがない、というものだった。

調査の結果、2つの根本原因を発見した：

原因1：OAuthの期限切れ。 一部の外部サービスのOAuthトークンが期限切れになった後、システムが認証を繰り返しリトライし、各リトライがtokenを消費していた。さらに悪いことに、リトライロジックに指数バックオフがなく、短時間に大量の無効なリクエストが発生していた。修正方案は、トークン期限切れの検出とグレースフルデグラデーションの追加だ——認証失敗後は盲目的にリトライせず、サービスを利用不可とマークし、次の定期リフレッシュを待つ。

原因2：巨大なsessionファイル。 こちらはより潜在的で深刻だった。一部のagentのsessionファイルが1.2MBにまで膨張していることを発見した。agentが起動されるたびに完全なsessionコンテキストがロードされ、1.2MBのsessionは各会話の開始時に大量のtokenを消費することを意味する。

これらの巨大なsessionはどうやって生まれたのか？主に長時間稼働するagentが対話履歴を蓄積し続け、加えて構造化データ（大量のJSONレスポンスなど）がsessionに保存されていたためだ。

クリーンアップ方法は直接的だった：膨張したsessionファイルを1.2MBから90バイトに縮小した——基本的にsession IDと基本メタ情報のみを保持する。過去の対話コンテキストはsessionファイルに保存せず、必要に応じてmemoryシステムからロードする方式に変更した。

自動Sessionクリーンアップシステム

手動でのsessionクリーンアップは持続可能ではない。今日クリーンアップしても明日にはまた肥大化する。そこで自動クリーンアップメカニズムを構築した：

4時間ごとに全agentのsessionファイルをスキャンし、200KBを超えるものを自動クリーンアップする。クリーンアップは単純な削除ではなく、以下のプロセスで行う：

1. sessionのコアメタ情報（ID、作成時刻、最終アクティブ時刻）を抽出

2. 完全なsessionをログディレクトリにアーカイブ（監査能力を保持）

3. 最小化されたsessionファイルで元のファイルを置換

4. クリーンアップログを記録

200KBというしきい値は経験に基づいて設定した。正常なsessionファイルは通常10〜50KBの範囲にあり、200KBを超えていれば異常な膨張とほぼ確実に判断できる。

このクリーンアップシステムの稼働後、sessionの膨張によるtoken超過の問題は二度と発生していない。

数字が物語る

最適化前後の比較：

| 指標 | 最適化前 | 最適化後 | 改善 |

|------|----------|----------|------|

| 日次token消費 | 1.4M | 827K | -41% |

| 最大sessionファイル | 1.2MB | <50KB | -96% |

| Token超過エラー | 頻発 | ほぼゼロ | ✅ |

41%の削減はサービス品質を低下させることなく達成された。余分なcron呼び出し、無効なOAuthリトライ、膨張したsessionのロード——これらはユーザー価値を一切生まず、純粋なリソースリークだった。

リソース最適化は常に取り組む価値がある。新機能ほどのワクワク感はないが、システムを健全に長期運用するための基盤だ。節約されたtokenは、本当に重要なことに使える。