WSL上でのOpenClawとOllamaを使用したローカルマルチエージェントAIセットアップ

アーキテクチャ概要
開発者が、Windows上のWSL Ubuntu 24.04で完全にローカル実行されるマルチエージェントAIセットアップを文書化しました。このシステムは、オープンソースのゲートウェイであるOpenClaw 2026.2.26を使用して、AIエージェントをTelegramなどのメッセージングアプリに接続し、ユーザーが完全に制御できるプライベートAIインフラを構築しています。
エージェント構成
このセットアップは、4つの専門エージェントで構成されています:
- Pluto - タスクを適切なエージェントにルーティングするコーディネーター。OpenRouter(無料ティア)で実行。
- Hermes - 調査、執筆、ウェブブラウジング、コンテンツタスク、およびYouTubeなどのAPI統合を処理。OpenRouterを使用。
- Vulcan - コーディングと自動化エージェントで、Ollama上でqwen2.5-coderモデルを使用して100%ローカル実行され、APIコストがゼロ。
- Aegis - セキュリティ監視および読み取り専用のシステム監査。OpenRouterを使用。
技術的実装の詳細
スタックには以下が含まれます:
- OpenClaw 2026.2.26
- Ollama(モデル:qwen2.5-coder、codellama、llama3.2)
- OpenRouter API
- Telegramボット(エージェントごとに1つ)
- WSL Ubuntu 24.04
- プロセス管理用のsystemd
コストと構成
総費用は0.01ドル未満で、Vulcanは完全に無料(ローカルのOllama)です。他の3つのエージェントは、最もコスト効率の高いモデルを選択するOpenRouterの自動ルーティング機能を使用しています。開発者は、安全策としてOpenRouterに月5ドルのハードキャップを設定しました。
主な学び
- WSL + systemdは、再起動後も存続するバックグラウンドサービスとしてゲートウェイを実行するのに効果的
- WSLでのOllamaモデルの自動検出には癖があり、プロバイダー設定の手動登録が必要でした
- コーディネーターの指示が適切に調整されると、エージェント間の委譲はうまく機能する
- ライブウェブアクセスのためのChromeブラウザリレーには、ゲートウェイポートではなくポート18792が必要(1時間のトラブルシューティングの原因となった)
📖 全文を読む: r/openclaw
👀 See Also

Synology NAS上のOpenClaw:Telegramメディアリクエストとコンテナ管理
あるユーザーが、Plex、Sonarr、Radarr、SABnzbdなどのメディアスタックコンテナと共にSynology NAS上でOpenClawを実行した経験を報告しています。彼らは、Telegramベースの映画リクエストやNASの自動トラブルシューティングタスクに使用しています。

実用的なAIサポートの改善:Claudeコード流出分析から
開発者がClaude Codeのソースコード流出を分析し、自身のChatbase設定に6つの具体的な変更を実装しました:テキストスニペットの見直し、感情分析の追加、構造化されたQ&Aペアの構築、敵対的テストエージェントの作成、アクションとツールの連携、トピックの相互参照です。

オブシディアンとOpenClawをセカンドブレイン設定として使用する
ある開発者が、OpenClawとObsidianをセカンドブレインシステムとして活用するセットアップを共有しました。QMDを実装することで効率的なノート検索を実現し、オンデマンドでのスキル読み込みによりトークン使用量を80〜90%削減しています。

OpenClaw Telegram組織:トピックごとのエージェント設定がチャットの混乱を解決
開発者は、専用グループ内でエージェントごとにトピックを設定する構造を実装することで、OpenClawのTelegram管理の問題を解決し、コンテキストの混在を減らし、デバッグを改善しました。この設定には、特定のトピックマッピング、メンションのみのデフォルト設定、より整理されたルーティングルールが含まれています。