緊急Sessionクリーンアップ——9.9MB→0.18MB

2026-02-16 | Joe's Tech Blog #039

危機のシグナル

今朝、main agentが突然異常に遅くなった。応答遅延が通常の2〜3秒から15秒以上に跳ね上がり、時にはタイムアウトして返答がないこともあった。

最初の反応はネットワーク問題だったが、ping遅延は正常。次にサーバー負荷を確認——CPU、メモリともに正常。最後にsessionファイルのサイズを確認したところ、その数字を見た瞬間に固まった：

main.session.json — 9.9MB

約10MBのsessionファイル。agentが応答するたびにsession全体をコンテキストとしてロードしてLLMに送信する必要があることを考えると、9.9MBのコンテキスト——遅くて当然だ。

Session肥大化の原因

OpenClawのsessionファイルは、agentとユーザー間の完全な対話履歴を記録している。すべてのメッセージ、すべてのツール呼び出しの入出力、すべての思考プロセスが、JSON形式で保存される。

通常の使用では、sessionは対話の進行とともに増え続ける。定期的なクリーンアップメカニズムがなければ、数週間で手に負えないほど膨張してしまう。

私のmain agentは約2週間クリーンアップせずに稼働しており、4040件のレコードが蓄積されていた。その多くは大量のコード出力、ログのダンプ、ファイル内容の読み取りなど——履歴コンテキストとしては何の価値もないが、大量のスペースを占有するものだった。

クリーンアップ作戦

PC-A（メインマシン 192.168.x.x）

最も緊急度が高い。main agentがこのマシン上で稼働している。

クリーンアップ前：

main.session.json     — 9.2MB, 4040件のレコード

クリーンアップ戦略：直近の100件の対話レコードを保持し、残りをすべて削除。さらに保持するレコードにはスリム化処理を実施——ツール呼び出しの詳細出力を除去し、要約のみを保持。

# まずバックアップ！
cp main.session.json main.session.json.bak-20260216

クリーンアップスクリプトを実行
node scripts/session-cleanup.js --keep 100 --slim

クリーンアップ後：

main.session.json     — 0.18MB, 101件のレコード

9.2MBから0.18MBへ、98%の削減。

効果は即座に現れた——agentの応答速度が2秒以内に回復。カクカクしていたPCのディスク容量を90%解放したような感覚で、すべてがスムーズになった。

T440（ワークサーバー 192.168.x.x）

T440には15個のagentがあり、sessionの状況も楽観的ではなかった：

クリーンアップ前:
techsfree-web.session.json    — 2.9MB
learning.session.json         — 1.8MB
docomo-pj.session.json        — 1.2MB
health.session.json           — 0.9MB
... (残り11個: 0.1-0.5MB)

クリーンアップ後:
techsfree-web.session.json    — 152KB
learning.session.json         — 98KB
docomo-pj.session.json        — 87KB
health.session.json           — 65KB
... (残り11個: 10-30KB)

techsfree-webが最も大きかったのは、このagentがWebサイト開発タスクを処理しており、大量のコードファイルの読み書きが頻繁に必要だったためだ。

バックアップによる保護

クリーンアップを行う前に、1MBを超えるすべてのsessionファイルのバックアップを作成した：

# T440上で
mkdir -p /home/linou/backups/sessions/20260216
for f in $(find ~/.openclaw -name "*.session.json" -size +1M); do
  cp "$f" /home/linou/backups/sessions/20260216/
  echo "Backed up: $f ($(du -h "$f" | cut -f1))"
done

合計6ファイル、総計約16MBをバックアップした。これらのバックアップの主な用途：

• クリーンアップ後にagentの動作が異常になった場合のロールバック
• どのタイプの対話が最もスペースを消費するかの事後分析
• 長期アーカイブとして（おそらく使うことはないが）

定期クリーンアップメカニズムの確立

今回の緊急クリーンアップで、問題が起きてから手動でクリーンアップするのでは遅いと痛感した。自動化された定期クリーンアップの仕組みが必要だ。

シンプルなcron jobを設計した：

# 毎週日曜日午前3時にsessionクリーンアップを実行
0 3   0 /opt/ocm/scripts/auto-session-cleanup.sh >> /var/log/ocm-cleanup.log 2>&1

クリーンアップスクリプトのロジック：

1. すべてのsessionファイルをスキャン

2. 2MB超のファイル：直近200件のレコードを保持、残りを削除

3. 5MB超のファイル：直近100件のレコードを保持、追加でslim処理（ツール出力の詳細を除去）

4. 10MB超のファイル：直近50件のレコードを保持、積極的なslim処理

5. 毎回クリーンアップ前に自動バックアップ

6. クリーンアップ完了後にTelegram通知を送信

通知の例：

🧹 Sessionクリーンアップ完了
📅 2026-02-16 03:00

3ファイルをクリーンアップ:
  main.session.json: 4.2MB → 0.3MB
  techsfree-web: 1.8MB → 0.1MB  
  learning: 1.1MB → 0.08MB

💾 バックアップ先: /backups/sessions/20260216/

振り返り

9.9MBのsessionファイルは、典型的な「茹でガエル」問題だった。毎日少しずつ増え、毎日正常範囲内に見えるが、ある日突然臨界点を超えてシステムが崩壊する。

核心的な教訓：継続的に増大するデータには、必ず対応するクリーンアップ戦略が必要だ。「あとでやる」ではなく、初日から用意しておくべきだ。

Session管理は些細なことに見えるが、LLMアプリケーションにおいてコンテキストサイズは応答品質と速度を直接左右する。sessionを精簡に保つことは、agentを効率的に保つことだ。これはAIシステムの運用において最も見過ごされがちだが、最も重要な日常業務の一つかもしれない。