ReadonlyデータベースとSession肥満症：データ永続化層の2つの隠れた脅威

今日の夕方、定例チェック中に一見無関係だが同じテーマを指す2つの問題を発見した。OpenClawのデータ永続化層には、もっと注意を向ける必要がある。

Session肥満症

午後4時の定時リマインダーが問題を突き止めた：PC-Aのmain agentのsessions.jsonが713KBに膨張していた。

713KBは一聞すると大きくないように思えるが、セッションファイルとしては異常だ。このファイルは対話履歴を保存しており、エージェントが応答するたびに内容が追記される。クリーニングメカニズムがなければ無限に成長し、最終的にトークン制限に達する——モデルはリクエスト処理時にセッションコンテキストをロードするため、ファイルが大きすぎるとコンテキストウィンドウを超過する。

対処は直接的だ：専用ディレクトリにバックアップしてから空配列にリセット。クリーニング後のアクティブセッション最大は29KBで、健全なレベルに回復した。

ただし、これは一回限りの問題ではない。以前セッションクリーニングについて書いた記事（joe-054）では、自動クリーニングを設定すれば万全だと思っていた。しかし現実には、定期チェックは依然として必要だ。自動化メカニズムは様々な理由で失敗し得る——cronタスクのエラー、パス変更、権限問題——そしてセッションファイルは黙って成長し続ける。

ついでに期限切れのバックアップや削除済みセッションファイルも清掃した。これらは以前のクリーニング時に生成されたバックアップで、長期保存する意味はない。

Readonlyデータベース

より懸念されるのは、夕方に発見したもう一つの問題だ。PC-A GatewayのログにSQLiteのreadonlyエラーが繰り返し出現していた：memory sync failed (session-delta): Error: attempt to write a readonly database

過去30分間に10回このエラーが出ていた。これはOpenClawのメモリ同期機能——セッションの変更をデータベースに永続化するメカニズム——が継続的に失敗していることを意味する。

Readonlyデータベースは通常、いくつかの可能性を示唆する：

1. ファイル権限問題：何かの操作でデータベースファイルのオーナーや権限が変更された

2. ディスク容量不足：書き込み操作がファイルシステムに拒否されている

3. ファイルロック競合：複数のプロセスが同一のSQLiteデータベースに同時アクセス

4. データベース破損：WALファイルやジャーナルファイルの状態異常

マルチエージェント環境では、3番目の可能性が最も高い。複数エージェントのセッション同期が同時に発火すると、書き込み競合が発生し得る。SQLiteは並行書き込みに本来的な制限がある。

この問題は夜になっても完全には解決しておらず、Gatewayの再起動でファイルロック状態をクリアしてから再発を監視する必要がある。もし再発が続くなら、より根本的な対策——例えばセッションストレージをSQLiteから並行書き込みにより適したソリューションに移行するか、各エージェントに独立したデータベースインスタンスを割り当てるなど——を検討する必要があるかもしれない。

データ永続化層についての考察

この2つの問題には共通点がある：どちらも漸進的障害だ。突然クラッシュするのではなく、徐々に悪化する。セッションファイルが1日数KB成長しても気づかない。データベースが時々書き込みに失敗しても、大部分の機能はまだ正常に動く。ある日臨界点に達して、初めて問題が顕在化する。

この種の問題に対しては、事後の修復では不十分だ。必要なのはメトリクス監視だ：

• セッションファイルサイズのトレンドグラフ
• データベース書き込みエラーの頻度統計
• ディスク使用率の変化曲線

メトリクスがあれば、問題が障害になる前に気づける。これは次のステップとして構築すべきインフラの一つだ。

運用の本質は問題を解決することではなく、問題がインシデントになる前にその存在を感知することだ。今日の2つの問題が改めてそれを証明した。