結論

OpenClawは、Discordなどの入口をAIエージェントへ接続し、会話、記憶、権限、自動実行、端末、管理画面を一つの常駐Gatewayで扱うソフトウェアである。

Gateway(常に動いて依頼を受け付け、処理先へ振り分ける中核)はAIモデルそのものではない。

CodexやClaudeなどの実行環境、チャット、ツール、端末をつなぐ制御層である。

今回のWindows環境では、Gateway、Discord、会話セッション、ローカルControl UI、独自のCodex連携、Automationsの一部が導入済みである。

一方、スマートフォンからのControl UI、複数エージェント、端末Node、メディア処理など、公式に存在しても未導入または実動作未確認の機能も多い。

OpenClawの役割と機能の全体像

調査範囲

2026年9月29日に、OpenClaw公式ドキュメントの目次、llms.txtに列挙された1,351ページ、全文書を書き出したllms-full.txtを確認した。

全ページを利用者機能として数えると、同じ機能の設定例、コマンド仕様、OS別手順、変更履歴まで重複する。

そこで、公式目次と全文書から利用者が区別すべき機能を21群にまとめた。

Reference、Releases、Help、CIは既存機能の仕様、変更履歴、障害対応、開発工程なので、独立した利用者機能には数えていない。

公式ドキュメントは導入済みバージョンより新しい内容を含む。

そのため、以下では「公式が現在説明する機能」と「今回の環境で実際に確認した状態」を分ける。

OpenClawが提供する21の機能群

利用者との接点

1. チャットチャンネル。 Discord、Slack、Telegram、WhatsAppなどを一つのGatewayへ接続する。各サービスのBot、認証、権限、許可リストが必要である。公式

2. 会話セッションと配信。 会話履歴、返信先、待ち行列、長文分割、入力中表示、再試行を管理する。ダイレクトメッセージとグループ会話の分離規則を理解する必要がある。公式

3. 記憶と検索。 会話を越えた記憶、検索、利用者モデル、長い会話の圧縮を扱う。セッション履歴と永続記憶は別物であり、すべてを自動的に正しく覚えるわけではない。公式

4. Control UI。 ブラウザーで会話、セッション、設定、ログ、ノード、承認を扱う。遠隔公開には認証、暗号化、ネットワーク設計が必要である。公式

5. 画像・音声・動画・文書。 メディアの受信、解析、生成、文字起こし、読み上げ、PDF処理を行う。形式、容量、モデル、プロバイダー、料金が機能ごとに異なる。公式

6. 通話・音声会話・会議。 リアルタイム音声、Discord音声チャンネル、文字起こし、会議メモを扱う。音声権限、認識・合成サービス、録音時のプライバシー管理が必要である。公式

エージェントと実作業

7. エージェント実行環境。 モデルへ指示とツールを渡し、結果を受けて処理を反復する。指示文は安全境界ではない。権限はGateway側でも制限する。公式

8. ツールと承認。 ファイル、コマンド、メッセージ送信などを構造化した操作として提供する。ツールの存在は実行許可を意味しない。公式

9. ブラウザーとWeb検索。 ページ閲覧、フォーム操作、Web取得、検索を行う。ログイン済みブラウザーにはアカウント操作権限がある。誤送信とプロンプトインジェクションへの対策が必要である。公式

10. Skills。 繰り返し使う手順と判断基準をSKILL.mdとして再利用する。Skillは説明書であり、権限やツールそのものを追加しない。公式

11. 自動実行と監視。 Automations、Heartbeat、Background Tasks、Task Flow、Hooks、Webhooksを使う。正確な時刻、定期確認、内部イベント、外部イベントで機能を使い分ける。公式

12. 複数エージェント。 送信者や作業ごとの振分け、子エージェント、並列処理を行う。並列数、権限、結果集約、停止と復旧の管理が必要である。公式

13. Nodes。 iOS、Android、別PCのカメラ、画面、位置情報、通知、音声、端末操作を使う。端末のペアリングとOS権限が必要である。公式

拡張と外部サービス

14. Plugins。 チャンネル、モデル、ツール、Hook、音声、検索、CLI実行先を追加する。ネイティブPluginはGateway処理内で動き、OpenClawのサンドボックス対象外である。公式

15. MCPとCode Mode。 MCPサーバーを接続し、外部のツールやデータを利用する。MCP(Model Context Protocol。外部サービスがツールやデータを提供する共通規格)の接続先も独立した信頼対象である。公式

16. ClawHub。 Skillsや拡張パッケージを検索、取得、公開する。公開されていることは安全性や品質の保証ではない。公式

17. モデルとプロバイダー。 クラウドモデル、ローカルモデル、画像・音声・動画サービスを選び、切り替える。認証、料金、文脈長、ツール対応、品質はモデルごとに異なる。公式

導入・管理・安全性

18. OS・アプリ・ホスティング。 Windows、macOS、Linux、コンテナ、クラウド、小型PCで動かす。Gateway、デスクトップアプリ、Nodeは役割と対応機能が異なる。公式

19. Gateway・設定・秘密情報。 チャンネル、セッション、エージェント、モデル、ツール、認証情報を中央管理する。状態ディレクトリ、秘密情報、バックアップを保護する必要がある。公式

20. 遠隔接続とAPI。 別端末、Tailscale、Cloudflare Access、独自クライアント、HTTP APIから接続する。LANやインターネットへ公開する場合は、認証、TLS、Firewall、復旧手段が必要である。公式

21. セキュリティと運用監視。 許可リスト、ペアリング、承認、サンドボックス、監査、ログ、診断、更新、復旧を扱う。一つのGatewayは一つの信頼領域であり、互いに信用しない利用者を安全に同居させる境界ではない。公式

Control UIとは何か

Control UIは、OpenClaw Gatewayが配信するブラウザー用の操作・管理画面である。

単なるチャット画面ではない。

公式文書では、次の機能を一つの画面から扱う。

  • 会話、添付、音声入力、セッションの新規作成と切替
  • モデル、プロバイダー、Plugins、MCP、更新、表示名などの設定
  • Nodes、端末、実行承認、活動履歴、使用量、ログの確認
  • Gateway設定ファイルの閲覧と編集
  • 会議、タスク、ワークフローなど、導入済み拡張機能の画面

既定ではGatewayと同じポートのhttp://<Gatewayのホスト>:18789/から配信される。

ただし、同じPC内だけを示すloopback待受なら、別のスマートフォンやPCからは開けない。

別端末から利用するには、認証と暗号化を維持した安全な遠隔接続を別途構成する必要がある。

今回のWindows環境での実態

ここでは「公式機能」「独自実装」「導入状態」「実動作確認」を混ぜない。

公式機能・実動作確認済み。 Gateway、同じWindows内だけの待受、Discord接続、通常のテキスト応答、会話セッション、公式Plugin機構、ローカルControl UIのHTML配信。

公式機能・導入済みだが未検証。 週次Skill WorkshopレビューのAutomation、5件の公式Hooks、Control UIログイン後の個別操作、ロード済みのブラウザー・文書・音声などのPlugins。

公式機能・故障中。 Memory Dreaming PromotionのAutomation。直近2回がDataCloneErrorで失敗している。

公式機能・未導入または運用対象外。 Nodes、複数エージェント、Discord以外のチャット、スマートフォンからのControl UI、Tailscale、Task Flow、Webhooks、メディア実運用。

独自実装・実動作確認済み。 life-codex-cli、Codexの読取り専用実行、/life、Issue別のCodex会話対応、GitHubへの結果投稿と読戻し、二重実行防止。

独自実装・未完了。 普通のDiscord文章から対象Issueを自動選択する経路。単体試験は成功したが、実際のメッセージは通常応答へ流れ、Issue処理へ到達しなかった。

Pluginがenabledまたはloadedと表示されても、必要な認証情報、エージェントへの公開、権限、実行成功までは証明しない。

Control UIについて確認できたのは、同じWindows内のURLがHTTP 200でOpenClawのHTMLを返すところまでである。

画面へのログイン後に各操作が成功すること、設定変更が安全に反映されること、別端末から利用できることは未検証である。

Codexと何が違うのか

Codexは、指示を理解し、調査、編集、コマンド実行などの作業をするエージェント実行環境である。

OpenClawは、その実行環境を常時起動の入口、会話、権限、自動実行、端末、管理画面へ接続する制御層である。

  • 同じPCで一回だけ質問するなら、Codexへ直接依頼するほうが単純であり、OpenClawを経由する追加の利点は小さい。
  • Discordから継続して依頼するなら、OpenClawがチャンネル、返信先、会話の継続を管理できる。
  • 定刻やイベントで実行するなら、OpenClawのAutomations、Heartbeat、Hooks、Webhooksを条件に合わせて選べる。
  • 複数端末や専門エージェントを使うなら、OpenClawが接続と振分けを一つのGatewayで管理できる。
  • ブラウザーで運用状態を管理するなら、Control UIで会話、設定、ログ、承認などを扱える。

現在の利用目的が「同じWindowsの前でCodexへ単発質問する」だけなら、OpenClawを採用する価値は小さい。

Discordから常時接続したい、定期実行したい、複数の入口や端末をまとめたい場合に価値が出る。

現在の残課題

  1. 普通のDiscord文章からIssue処理へ振り分ける独自経路を修正し、実メッセージからGitHub結果の読戻しまで確認する。
  2. 失敗中のMemory Dreaming Promotionを診断し、成功または意図した停止状態を確認する。
  3. Control UIへログインし、会話、設定、ログ、承認など、採用する画面だけを一つずつ検証する。
  4. スマートフォンからのControl UIは、現在の遠隔操作経路を失わない独立した復旧手段を確保してから設計する。
  5. ロード済みPluginを「利用可能」と呼ぶ前に、認証、公開範囲、権限、実行成功を個別に確認する。

主な公式資料