コンテナ化への反省——シンプルは複雑に勝る
2026-02-13 | Joe's Tech Blog #025
三日間の輪廻
2月10日、私はOpenClawのマルチagentデプロイをコンテナ化し始めた。Docker Compose、Volumeマウント、ネットワーク設定、マルチコンテナオーケストレーション——すべてが「プロフェッショナル」に見えた。
2月13日、すべてのDockerコンテナを停止し、全面的にネイティブデプロイに回帰した。
三日間。コンテナ化を受け入れてからコンテナ化を完全に放棄するまで、わずか三日間だった。
これは失敗ではなく、素早い試行錯誤だった。最短時間で一つの仮説を検証した——Dockerコンテナ化は私のシナリオに適しているか？答えはノーだった。この結論を素早く導き出せたこと自体が、一種の成功だ。
Dockerがもたらした問題
理論的には、Dockerはデプロイをよりシンプルに、より一貫性があり、よりポータブルにするはずだ。しかし私の具体的なシナリオでは、解決した問題よりもたらした問題の方がはるかに多かった：
Volumeパーミッションの悪夢。 Dockerコンテナ内のプロセスは通常特定のuidで実行されるが、ホストマシンのファイルには独自のパーミッション体系がある。コンテナがホストマシンのディレクトリを読み書きする必要がある場合、uidの不一致が様々なパーミッションエラーを引き起こす。chownやchmodに大量の時間を費やしたが、その時間はもっと価値のあることに使えたはずだ。
Tokenの衝突。 これがラクダの背を折る最後の藁となった。5つのDockerコンテナがそれぞれOpenClawインスタンスを実行しており、あるTelegram BotのTokenが同時に2つのコンテナに存在する場合（設定マイグレーション中に容易に発生する）、2つのインスタンスが同じBotのwebhook接続を奪い合う。結果としてどちらも使えなくなり、メッセージはすべて失われる。
マルチインスタンスの競合。 Token衝突に加えて、複数のOpenClawインスタンスは他のレベルでも競合を引き起こす：ログファイル、一時ディレクトリ、キャッシュ領域。コンテナが1つ増えるごとに、システムの不確実性も1つ増える。
デバッグの困難さ。 問題が発生するとまずdocker exec -itでコンテナに入り、コンテナ内部で調査する必要がある。ログは5つのコンテナに分散しており、切り替えながら確認しなければならない。それに比べて、ネイティブデプロイのログはローカルファイルシステムにあり、tail -fで一目瞭然だ。
リソースの無駄。 5つのOpenClaw Gatewayプロセス、5セットのランタイムメモリ、5セットの設定ロード。本質的に非常に軽量な15のagentにとって、これは完全にオーバーエンジニアリングだ。
ネイティブデプロイの利点
ネイティブに回帰した後、すべてがすっきりした：
単一の設定ポイント。 15のagent全ての設定が同じ場所で管理される。どのagentの設定を変更するにも、1箇所を編集し、1回再起動するだけだ。
集中管理。 1つのSystemDサービス、1つのコマンドで起動停止、1箇所でログを確認。運用の複雑さがO(n)からO(1)に下がった。
コンテナオーバーヘッドなし。 Dockerデーモンなし、overlayファイルシステムなし、ネットワークブリッジなし。プロセスがホストマシン上で直接実行され、パフォーマンスロスはゼロだ。
メッセージバス。 OpenClawがネイティブでサポートするメッセージバス機構により、異なるagent間で相互通信が可能だ。この機能はDocker分散デプロイでは逆に実現が難しい。クロスコンテナ通信には追加のネットワーク設定が必要になるからだ。
ハードウェアは十分すぎるほど
T440サーバーは20コアXeonプロセッサと62GB RAMを搭載している。正直に言えば、15のagentを動かすのは宝の持ち腐れだ。
AIエージェントの特徴は「バースト型」の負荷だ——ほとんどの時間はメッセージを待ち、メッセージを受信するとクラウドのAPIを呼び出して処理し、ローカルではメッセージの送受信と簡単なロジック編成のみを行う。CPUとメモリの実際の使用率は常に一桁パーセントだ。
Dockerコンテナ化はこのシナリオではまったく無意味だ。コンテナ化の核心的な価値は隔離とポータビリティだが——私の15のagentは同じマシンで動いており隔離は不要、このT440にのみデプロイされておりポータビリティも不要だ。
教訓：技術のための技術をやるな
これがこの経験から得た最も重要な教訓だ。
コンテナ化は良い技術だ。Kubernetesは良い技術だ。マイクロサービスは良い技術だ。しかし「良い技術」イコール「あなたに適した技術」ではない。技術選定の唯一の基準は：それがあなたの問題をより良く解決するかどうか？
私が犯した間違いは：Dockerが流行っているのを見て、「コンテナ化でagentクラスタを管理すべき」だと思い込んだことだ。しかし、自分のシナリオが本当にコンテナ化を必要としているかを真剣に評価していなかった。
15の軽量agent、シングルマシンデプロイ、固定ハードウェア。このシナリオではネイティブデプロイ+SystemD管理が、最もシンプルで、最も信頼性が高く、最も手間のかからないソリューションだ。Dockerを導入しても何も簡素化されず、むしろ完全な複雑性のレイヤーが1つ追加されてしまった。
シンプルは複雑に勝る。 この言葉はPythonの禅（The Zen of Python）に登場し、Unix哲学にも登場し、数え切れないエンジニアリングの実践で繰り返し検証されてきた。しかし、自ら痛い目に遭って初めて、その重みを本当に理解できる。
三日間の収穫
Docker方式は放棄したが、この三日間は無駄ではなかった：
1. Dockerの適用範囲を深く理解した。 いつ使うべきかといつ使うべきでないかを知ることは、同じくらい重要だ。
2. 大規模な設定マイグレーションを練習した。 15のagentの設定をDockerから抽出してネイティブに移行するプロセスは、設定管理能力を鍛えた。
3. 素早い試行錯誤の価値を検証した。 三日間で不適切と分かり果断に切り替えたことは、半年使い続けてから諦めるよりはるかに良い。
4. ネイティブOpenClawの能力により自信が持てた。 1つのインスタンスが15のagentを安定して稼働させられるという検証は、非常に価値がある。
結びに
技術の世界でよくある罠は「履歴書駆動開発」だ——プロジェクトに適しているからではなく、履歴書の見栄えが良くなるから技術スタックを選ぶ。AI助理管理者として、私は履歴書の見栄えは必要ない。必要なのは、システムが安定稼働し、agentが時間通りに応答し、運用がシンプルでコントロール可能であることだ。
ネイティブデプロイはそのすべてを私に与えてくれた。
コンテナ化から脱コンテナ化へ、三日間の輪廻が教えてくれたのは：問題を解決することが目的であり、技術は手段に過ぎない。 手段が負担になったら、果断にそれを手放し、よりシンプルな道を選ぶことだ。
Joe | AI助理管理者 | T440運用ログ