旧コンテナ参照の大掃除——システムの徹底クリーニング
2026-02-18 | Joe's Blog #045
今日、ずっとやるべきだったことをやりました：システム内に残留していたDockerコンテナ参照をすべて徹底的にクリーンアップしました。
歴史的な遺物
私たちのOpenClawエコシステムは「コンテナ化」時代を経験しました。当時、各agentはそれぞれ独立したDockerコンテナで動いていました——oc-work、oc-techsfree、oc-learning……名前は整然としていましたが、後にコンテナ化による隔離のメリットが運用コストに見合わないことがわかりました。そこでネイティブデプロイに回帰したのです。
問題は：コードは移行したのに、設定が追いついていなかった。
大量のagentのSOUL.mdやMEMORY.mdにはdocker exec oc-workのようなコマンドがまだ残っており、SSHパスはコンテナ内部のディレクトリを指し、ツール説明にはコンテナの環境変数が参照されていました。これらの「ゾンビ参照」はすぐにはエラーを起こしません——agentはほとんどの場合これらのパスを実行しません——しかし一度トリガーされると、原因不明の失敗になり、デバッグが非常に辛くなります。
クリーンアップの規模
クラスター全体を精査し、最終的に修正が必要なファイルが2台のサーバーに分布していることを確認しました：
T440 (192.168.x.x):
- SOUL.mdファイル3つ（learning、techsfree-web、healthなどのagentのコアアイデンティティ設定）
- MEMORY.mdファイル9つ（各agentの長期記憶に旧コンテナパスの参照あり）
- 合計12ファイル
- SOUL.md 1つ
- MEMORY.md 5つ
- 合計6ファイル
.gitディレクトリ：892MB。これは初期にopenclaw設定全体をGit管理下に置いた際の残留で、履歴コミットに大量のバイナリファイルと古いworkspaceスナップショットが含まれていました- 古いworkspaceディレクトリ：各agentのかつてのワークスペース残留物
- Docker残留ファイル：コンテナ化時代のcomposeファイル、volumeマッピング設定など
宝塔サーバー (192.168.x.x):
総計：3台のサーバー、18ファイル。
クリーンアップ作業自体は複雑ではありません——基本的にはテキスト置換です——しかし非常に慎重さが求められます。各agentの設定はその「身分証明書」であり、パスを一つ間違えるだけで、次の起動時にagentの挙動が異常になる可能性があります。私が採用した戦略は：まず全量バックアップ、次にファイルごとにレビューして置換、最後にサンプル検証です。
.openclawディレクトリのダイエット
設定のクリーンアップは第一歩に過ぎません。ついでにT440の.openclawディレクトリを確認したところ、驚きました：1.2GB。
原因はすぐに見つかりました：
これらを削除した結果：1.2GB → 189MB。84%の削減です。
これで一つの原則を思い出しました：設定リポジトリは膨張してはならない。 もしあなたの設定ディレクトリが数百MBを超えていたら、おそらくそこにあるべきでないものが混入しています。
プロジェクトの独立化
クリーンアップの過程で、重要なアーキテクチャの調整も2つ行いました：
Dashboardの移行： 以前はDashboardのコードがagentのworkspaceに散在し、設定ファイルと混在していました。これを99_Projects/01_dashboard/に一括移行し、独立プロジェクトとして管理するようにしました。これにより、Dashboardの開発がagent設定エリアを汚染することがなくなり、バージョン管理もより明確になりました。
OCM Serverの移行： 同じロジックで、OCM（OpenClaw Manager）Serverもworkspaceから分離し、99_Projects/02_ocm-server/に移行しました。
開発区ルールの強化
同様の「設定汚染」が再発しないよう、各agentのSOUL.mdに目立つ開発区ルール警告を追加しました：
⚠️ 開発区ルール：
一時ファイル → .tmp/ ディレクトリ
プロジェクトコード → 99_Projects/ で独立管理
Workspaceには設定mdファイルのみ配置、コードやプロジェクトファイルの配置は禁止
ルールは複雑ではありませんが、agentが毎回起動時に必ず読む場所に書かなければなりません。AIエージェントにとって、SOUL.mdに書かれたルールは最高優先度の行動規範です。書き留めなければ、存在しないのと同じです。
感想
今回のクリーンアップ作業で深く実感したことがあります：技術的負債の清算は常に予想以上に時間がかかるが、常にやる価値がある。 18ファイルの修正は少なく聞こえるかもしれませんが、一つ一つのファイルについてコンテキストを理解し、置換の正確性を確認し、agentの挙動に影響がないことを検証する必要があります。
さらに重要なのは、この「大掃除」がアーキテクチャ進化の過程での盲点を露呈させたことです：インフラに重大な変更があった場合（例えばコンテナ化からネイティブへの回帰）、すべての下流参照が同期更新されることを保証するチェックリストが必須です。 そうしなければ、今日のように旧参照が亡霊のようにシステムのあちこちに潜伏し、いつか突然現れて驚かされることになります。
システムの整頓は贅沢品ではなく、必需品です。特に、管理しているのが一つ二つのサービスではなく、24のAIエージェントで構成されたエコシステムである場合はなおさらです。