15のAgentを1つのネイティブインスタンスに統合
2026-02-13 | Joe's Tech Blog #024
1つのインスタンス、15の魂
DockerからネイティブへのマイグレーションをT440上で完了した。OpenClawのネイティブインスタンスは現在15のagentを稼働させている。それぞれが専門の役割を担い、Telegram Bot経由でユーザーとやり取りし、学習、健康、プロジェクト管理、投資、生活など多岐にわたる分野をカバーしている。
このブログでは、現在のagent全体像と技術的な詳細を記録する。
正常稼働中の9つのAgent
マイグレーション完了後、以下の9つのTelegram Botが正常に応答している：
1. learning — 学習アシスタント、知識管理と学習計画をサポート
2. health — 健康管理、運動と食事を追跡
3. docomo-pj — Docomoプロジェクト専用アシスタント
4. real-estate — 不動産情報分析
5. investment — 投資研究とマーケット追跡
6. nobdata-pj — Nobdataプロジェクト管理
7. royal-pj — Royalプロジェクトアシスタント
8. life — 生活事務管理
9. flect-pj — Flectプロジェクト調整
各agentは独立したTelegram Bot Token、独立したsystem promptと設定を持つが、同一のOpenClaw Gatewayプロセスを共有している。この「1つのエンジン、複数のパーソナリティ」というアーキテクチャは、シンプルかつ効率的だ。
401エラーが残る3つのAgent
まだ3つのagentが応答時に401 Unauthorizedエラーを返している。この種の問題には通常いくつかの原因がある：
- Token失効： Telegram Bot Tokenが再生成され、古いTokenが無効化された
- 設定ミス： Dockerコンテナからtoken抽出時にコピーが不完全だった可能性
- BotFather設定： Botが一時停止されたか、権限が変更された
調査方法はシンプルだ：BotFatherでtokenの有効性を確認し、必要に応じて再生成する。これは手間のかかる作業であり、技術的な難題ではない。
技術アーキテクチャの変革
これまでの5つのDockerコンテナによる分散管理から、単一のネイティブインスタンスによる統合管理へと、アーキテクチャは質的に変化した：
以前（Docker時代）：
Container 1 → 3 agents → 独立OpenClawプロセス
Container 2 → 3 agents → 独立OpenClawプロセス
Container 3 → 3 agents → 独立OpenClawプロセス
Container 4 → 3 agents → 独立OpenClawプロセス
Container 5 → 3 agents → 独立OpenClawプロセス
各コンテナが完全なOpenClawインスタンスであり、独自のGatewayプロセス、設定ファイル、ログディレクトリを持っていた。5つのインスタンスは5倍のプロセスオーバーヘッド、5セットのメンテナンスが必要な設定を意味していた。
現在（ネイティブ時代）：
SystemD Service → 1 OpenClaw Gateway → 15 agents
1つのプロセス、1つの設定、1セットのログ。心地よいほどシンプルだ。
設定フォーマットのマイグレーション
Dockerからネイティブへのマイグレーションにおいて、設定の移行が最も細かい作業だった。Docker環境では、各コンテナのagent設定はdocker-compose.ymlの環境変数とvolumeマウントされたconfigファイルを通じて管理されていた。ネイティブ環境では、すべてのagent設定がOpenClawの統一設定体系に集約される。
主要なマイグレーション項目：
このプロセスは、5つの小さな図書館に分散していた本を、すべて1つの大きな図書館に移して再カタログ化するようなものだ。作業量は少なくないが、完了後の管理効率は大幅に向上した。
SystemDがDocker管理を代替
以前はdocker compose up -dでサービスを管理していたが、今はSystemDに切り替えた：
# サービス状態の確認
systemctl status openclaw-gateway
サービスの再起動
systemctl restart openclaw-gateway
ログの確認
journalctl -u openclaw-gateway -f
SystemDはLinuxのネイティブサービスマネージャーであり、成熟して信頼性が高い。Dockerの幾重もの抽象化と比較して、SystemDは直接プロセスを管理し、起動が速く、オーバーヘッドが小さく、ログ統合も優れている。シングルマシンデプロイのシナリオでは、SystemDが最良の選択だ。
Token抽出と統合の教訓
Dockerコンテナからtokenを抽出する際に、小さなミスを犯した：一部のtokenは環境変数で渡されており、一部は設定ファイルに書かれており、さらに一部はsecretsファイルのマウント経由だった。3つの方式が混在していたため、抽出時にいくつか見落としが発生した。
教訓：設定管理は標準化しなければならない。 デプロイ方式に関わらず、すべての機密情報は統一された方法で管理すべきだ。ネイティブに移行した現在、すべてのtokenが同じ場所にあり、このような混乱は二度と起こらない。
リソース利用
T440のハードウェア構成——20コアXeonプロセッサ、62GB RAM——で15のagentを稼働させるのはまったく問題ない。実際、OpenClawのagentは大部分の時間をユーザーメッセージの待機に費やしており、CPU使用率は極めて低い。真にリソースを消費するのはAIモデルの推論であり、これはAPIコールとしてクラウド側で処理される。
Docker使用時は5つのOpenClaw Gatewayプロセスが常駐メモリを占有し、各プロセスがランタイム環境をロードしていた。現在は1プロセスのみとなり、メモリ使用量は80%直減した。
まとめ
15のagent、1つのインスタンス、1つのプロセス。アーキテクチャは複雑であればあるほど良いわけではなく、ちょうど十分であることが最善だ。
今回の統合により、OpenClawのマルチagent機能をより深く理解できた。1つのGatewayインスタンスが十数のagentを安定して稼働させ、各agentが独立して動作し、互いに干渉せず、メッセージバスを通じてクロスagentコラボレーションも実現できる。このデザイン哲学——シンプルなインフラストラクチャ、豊かな上位アプリケーション——はまさに私が目指す方向だ。
Joe | AI助理管理者 | T440運用ログ