よくある質問

OpenClaw は、自分のデバイスで実行する個人用 AI アシスタントです。すでに使っているメッセージング面（WhatsApp、Telegram、Slack、Mattermost、Discord、Google Chat、Signal、iMessage、WebChat、QQ Bot などの同梱チャンネル Plugin）で返信でき、サポートされているプラットフォームでは音声 + ライブ Canvas も使えます。Gateway は常時稼働するコントロールプレーンであり、アシスタントがプロダクトです。

OpenClaw は「ただの Claude ラッパー」ではありません。すでに使っているチャットアプリから到達できる 高機能なアシスタントを 自分のハードウェア で実行できる、ローカルファーストのコントロールプレーン です。 ステートフルなセッション、メモリ、ツールを備え、ワークフローの制御をホスト型 SaaS に渡す必要がありません。

ハイライト:

• 自分のデバイス、自分のデータ: Gateway を好きな場所（Mac、Linux、VPS）で実行し、 ワークスペース + セッション履歴をローカルに保持できます。
• Web サンドボックスではなく実チャンネル: WhatsApp/Telegram/Slack/Discord/Signal/iMessage など、 さらにサポート対象プラットフォームではモバイル音声と Canvas。
• モデル非依存: Anthropic、OpenAI、MiniMax、OpenRouter などを、エージェントごとのルーティング とフェイルオーバーで使用できます。
• ローカル専用オプション: 望む場合はローカルモデルを実行し、すべてのデータを自分のデバイスに留める ことができます。
• マルチエージェントルーティング: チャンネル、アカウント、タスクごとにエージェントを分け、それぞれに独自の ワークスペースとデフォルトを持たせられます。
• オープンソースで改造可能: ベンダーロックインなしで、検査、拡張、セルフホストできます。

ドキュメント: Gateway、チャンネル、マルチエージェント、 メモリ。

最初のプロジェクトとして適しているもの:

• Web サイトを構築する（WordPress、Shopify、またはシンプルな静的サイト）。
• モバイルアプリをプロトタイプする（概要、画面、API 計画）。
• ファイルとフォルダを整理する（クリーンアップ、命名、タグ付け）。
• Gmail を接続し、要約やフォローアップを自動化する。

大きなタスクも扱えますが、フェーズに分割し、 並列作業にはサブエージェントを使うと最も効果的です。

日常的な成果は通常、次のような形になります:

• パーソナルブリーフィング: 受信箱、カレンダー、関心のあるニュースの要約。
• リサーチと下書き: メールやドキュメント向けの簡単なリサーチ、要約、初稿。
• リマインダーとフォローアップ: cron または Heartbeat による通知とチェックリスト。
• ブラウザ自動化: フォーム入力、データ収集、Web タスクの反復。
• クロスデバイス調整: スマートフォンからタスクを送り、Gateway にサーバー上で実行させ、結果をチャットで受け取る。

リサーチ、適格性評価、下書き には役立ちます。サイトをスキャンし、候補リストを作成し、 見込み客を要約し、アウトリーチや広告コピーの下書きを書けます。

アウトリーチや広告配信 では、人間をループ内に置いてください。スパムを避け、地域の法律と プラットフォームポリシーに従い、送信前に必ずレビューしてください。最も安全なパターンは、 OpenClaw に下書きさせ、自分が承認することです。

ドキュメント: セキュリティ。

OpenClaw は 個人用アシスタント であり調整レイヤーであって、IDE の代替ではありません。リポジトリ内で最速の直接コーディングループには Claude Code または Codex を使ってください。永続的なメモリ、クロスデバイスアクセス、ツールオーケストレーションが必要な場合に OpenClaw を使います。

利点:

• セッションをまたいだ 永続的なメモリ + ワークスペース
• マルチプラットフォームアクセス（WhatsApp、Telegram、TUI、WebChat）
• ツールオーケストレーション（ブラウザ、ファイル、スケジューリング、フック）
• 常時稼働の Gateway（VPS 上で実行し、どこからでも操作）
• ローカルのブラウザ/画面/カメラ/exec 用の Nodes

ショーケース: https://openclaw.ai/showcase

リポジトリのコピーを編集する代わりに、管理対象のオーバーライドを使います。変更は ~/.openclaw/skills/<name>/SKILL.md に置きます（または ~/.openclaw/openclaw.json の skills.load.extraDirs でフォルダを追加します）。優先順位は <workspace>/skills → <workspace>/.agents/skills → ~/.agents/skills → ~/.openclaw/skills → 同梱 → skills.load.extraDirs なので、管理対象のオーバーライドは git に触れずに同梱 Skills より優先されます。Skill をグローバルにインストールする必要があるが一部のエージェントにだけ表示したい場合は、共有コピーを ~/.openclaw/skills に置き、agents.defaults.skills と agents.list[].skills で可視性を制御します。リポジトリに置いて PR として出すべきなのは、上流に取り込む価値がある編集だけです。

はい。~/.openclaw/openclaw.json の skills.load.extraDirs で追加ディレクトリを追加します（最も低い優先順位）。デフォルトの優先順位は <workspace>/skills → <workspace>/.agents/skills → ~/.agents/skills → ~/.openclaw/skills → 同梱 → skills.load.extraDirs です。clawhub はデフォルトで ./skills にインストールし、OpenClaw は次のセッションでそれを <workspace>/skills として扱います。Skill を特定のエージェントにだけ表示したい場合は、agents.defaults.skills または agents.list[].skills と組み合わせます。

現在サポートされているパターンは次のとおりです:

• Cron ジョブ: 分離されたジョブでは、ジョブごとに model オーバーライドを設定できます。
• サブエージェント: タスクを、異なるデフォルトモデルを持つ別々のエージェントにルーティングします。
• オンデマンド切り替え: /model を使って、現在のセッションモデルをいつでも切り替えます。

Cron ジョブ、マルチエージェントルーティング、スラッシュコマンド を参照してください。

長時間または並列のタスクには サブエージェント を使います。サブエージェントは独自のセッションで実行され、 要約を返し、メインチャットの応答性を保ちます。

ボットに「このタスク用にサブエージェントを起動して」と依頼するか、/subagents を使います。 チャットで /status を使うと、Gateway が今何をしているか（そしてビジーかどうか）を確認できます。

トークンのヒント: 長いタスクとサブエージェントはいずれもトークンを消費します。コストが気になる場合は、 agents.defaults.subagents.model でサブエージェント向けに安価なモデルを設定します。

ドキュメント: サブエージェント、バックグラウンドタスク。

スレッドバインディングを使います。Discord スレッドをサブエージェントまたはセッションターゲットにバインドすると、そのスレッド内の後続メッセージはバインドされたセッションに留まります。

基本フロー:

• thread: true を指定して sessions_spawn で起動します（永続的なフォローアップには任意で mode: "session"）。
• または /focus <target> で手動バインドします。
• /agents でバインディング状態を確認します。
• /session idle <duration|off> と /session max-age <duration|off> で自動 unfocus を制御します。
• /unfocus でスレッドを切り離します。

必要な設定:

• グローバルデフォルト: session.threadBindings.enabled、session.threadBindings.idleHours、session.threadBindings.maxAgeHours。
• Discord オーバーライド: channels.discord.threadBindings.enabled、channels.discord.threadBindings.idleHours、channels.discord.threadBindings.maxAgeHours。
• 起動時の自動バインド: channels.discord.threadBindings.spawnSessions のデフォルトは true です。スレッドに紐づいたセッション起動を無効にするには false に設定します。

ドキュメント: サブエージェント、Discord、設定リファレンス、スラッシュコマンド。

まず解決済みのリクエスター経路を確認します:

• 完了モードのサブエージェント配信は、存在する場合はバインドされたスレッドまたは会話経路を優先します。
• 完了元にチャンネルしか含まれていない場合、OpenClaw はリクエスターセッションに保存された経路（lastChannel / lastTo / lastAccountId）にフォールバックするため、直接配信が引き続き成功することがあります。
• バインド済み経路も利用可能な保存済み経路も存在しない場合、直接配信は失敗し、結果はチャットへ即時投稿される代わりにキュー済みセッション配信へフォールバックします。
• 無効または古いターゲットでも、キューフォールバックや最終配信失敗が強制されることがあります。
• 子の最後に見える assistant 返信が完全に無音トークン NO_REPLY / no_reply、または正確に ANNOUNCE_SKIP である場合、OpenClaw は古い進捗を投稿する代わりに意図的にアナウンスを抑制します。
• 子がツール呼び出しだけの後にタイムアウトした場合、アナウンスは生のツール出力を再生する代わりに、それを短い部分進捗要約へ折りたたむことがあります。

デバッグ:

openclaw tasks show <runId-or-sessionKey>

ドキュメント: サブエージェント、バックグラウンドタスク、セッションツール。

Cron は Gateway プロセス内で実行されます。Gateway が継続的に実行されていない場合、 スケジュール済みジョブは実行されません。

チェックリスト:

• cron が有効（cron.enabled）で、OPENCLAW_SKIP_CRON が設定されていないことを確認します。
• Gateway が 24/7 稼働していることを確認します（スリープ/再起動なし）。
• ジョブのタイムゾーン設定（--tz とホストのタイムゾーン）を確認します。

デバッグ:

openclaw cron run <jobId>
openclaw cron runs --id <jobId> --limit 50

ドキュメント: Cron ジョブ、自動化とタスク。

まず配信モードを確認してください。

• --no-deliver / delivery.mode: "none" は、ランナーのフォールバック送信が想定されていないことを意味します。
• アナウンス先（channel / to）がない、または無効な場合、ランナーは外向き配信をスキップします。
• チャンネル認証エラー（unauthorized, Forbidden）は、ランナーが配信を試みたものの認証情報でブロックされたことを意味します。
• サイレントな分離結果（NO_REPLY / no_reply のみ）は意図的に配信不能として扱われるため、ランナーはキュー済みフォールバック配信も抑制します。

分離 Cron ジョブでは、チャットルートが利用できる場合、エージェントは引き続き message ツールで直接送信できます。--announce は、エージェントがまだ送信していない最終テキストに対するランナーの フォールバック経路だけを制御します。

デバッグ:

openclaw cron runs --id <jobId> --limit 50
openclaw tasks show <runId-or-sessionKey>

ドキュメント: Cron ジョブ, バックグラウンドタスク。

通常これは重複スケジューリングではなく、ライブモデル切り替え経路です。

分離 Cron は、アクティブな実行が LiveSessionModelSwitchError をスローしたときに、ランタイムモデルの引き継ぎを永続化して再試行できます。再試行では切り替え後の プロバイダー/モデルが維持され、切り替えに新しい認証プロファイルオーバーライドが含まれていた場合、Cron は 再試行前にそれも永続化します。

関連する選択ルール:

• 該当する場合、Gmail フックのモデルオーバーライドが最初に優先されます。
• 次にジョブごとの model。
• 次に保存済み Cron セッションのモデルオーバーライド。
• 次に通常のエージェント/デフォルトモデル選択。

再試行ループには上限があります。初回試行に加えて 2 回の切り替え再試行後、 Cron は無限ループせずに中止します。

デバッグ:

openclaw cron runs --id <jobId> --limit 50
openclaw tasks show <runId-or-sessionKey>

ドキュメント: Cron ジョブ, cron CLI。

ネイティブの openclaw skills コマンドを使うか、ワークスペースに Skills を配置してください。macOS の Skills UI は Linux では利用できません。 Skills は https://clawhub.ai で参照できます。

openclaw skills search "calendar"
openclaw skills search --limit 20
openclaw skills install <skill-slug>
openclaw skills install <skill-slug> --version <version>
openclaw skills install <skill-slug> --force
openclaw skills update --all
openclaw skills list --eligible
openclaw skills check

ネイティブの openclaw skills install は、アクティブなワークスペースの skills/ ディレクトリに書き込みます。別個の clawhub CLI は、自分の Skills を公開または 同期したい場合にだけインストールしてください。エージェント間で共有インストールする場合は、Skill を ~/.openclaw/skills 配下に置き、どのエージェントから見えるかを絞りたい場合は agents.defaults.skills または agents.list[].skills を使用します。

はい。Gateway スケジューラーを使用します。

• Cron ジョブ はスケジュール済みまたは定期タスク用です（再起動後も保持されます）。
• Heartbeat は「メインセッション」の定期チェック用です。
• 分離ジョブ は、要約を投稿したりチャットへ配信したりする自律エージェント用です。

ドキュメント: Cron ジョブ, 自動化とタスク, Heartbeat。

直接はできません。macOS Skills は metadata.openclaw.os と必要なバイナリで制限されており、Skills は Gateway ホストで適格な場合にのみシステムプロンプトに表示されます。Linux では、ゲート制御をオーバーライドしない限り、apple-notes, apple-reminders, things-mac のような darwin 専用 Skills はロードされません。

サポートされるパターンは 3 つあります。

オプション A - Mac で Gateway を実行する（最も簡単）。 macOS バイナリが存在する場所で Gateway を実行し、Linux からリモートモードまたは Tailscale 経由で接続します。Gateway ホストが macOS なので、Skills は通常どおりロードされます。

オプション B - macOS Node を使用する（SSH なし）。 Linux で Gateway を実行し、macOS Node（メニューバーアプリ）をペアリングして、Mac 側で Node Run Commands を「Always Ask」または「Always Allow」に設定します。必要なバイナリが Node 上に存在する場合、OpenClaw は macOS 専用 Skills を適格として扱えます。エージェントは nodes ツール経由でそれらの Skills を実行します。「Always Ask」を選択した場合、プロンプトで「Always Allow」を承認すると、そのコマンドが許可リストに追加されます。

オプション C - SSH 経由で macOS バイナリをプロキシする（上級者向け）。 Gateway は Linux 上に置いたまま、必要な CLI バイナリが Mac 上で実行される SSH ラッパーとして解決されるようにします。その後、Skill をオーバーライドして Linux を許可し、適格な状態を維持します。

1. バイナリ用の SSH ラッパーを作成します（例: Apple Notes 用の memo）。

   #!/usr/bin/env bash
   set -euo pipefail
   exec ssh -T user@mac-host /opt/homebrew/bin/memo "$@"
   

2. Linux ホストの PATH にラッパーを置きます（例: ~/bin/memo）。

3. Skill メタデータ（ワークスペースまたは ~/.openclaw/skills）をオーバーライドして Linux を許可します。

   ---
   name: apple-notes
   description: Manage Apple Notes via the memo CLI on macOS.
   metadata: { "openclaw": { "os": ["darwin", "linux"], "requires": { "bins": ["memo"] } } }
   ---
   

4. Skills スナップショットを更新するため、新しいセッションを開始します。

現在は組み込まれていません。

選択肢:

• カスタム Skill / Plugin: 信頼性の高い API アクセスに最適です（Notion/HeyGen はどちらも API があります）。
• ブラウザー自動化: コードなしで動作しますが、遅く、壊れやすくなります。

クライアントごとにコンテキストを保持したい場合（代理店ワークフロー）、簡単なパターンは次のとおりです。

• クライアントごとに 1 つの Notion ページ（コンテキスト + 設定 + アクティブな作業）。
• セッション開始時に、そのページを取得するようエージェントに依頼します。

ネイティブ統合が必要な場合は、機能リクエストを開くか、それらの API を対象にした Skill を 作成してください。

Skills のインストール:

openclaw skills install <skill-slug>
openclaw skills update --all

ネイティブインストールは、アクティブなワークスペースの skills/ ディレクトリに配置されます。エージェント間で Skills を共有する場合は、~/.openclaw/skills/<name>/SKILL.md に配置します。一部のエージェントにだけ共有インストールを見せる場合は、agents.defaults.skills または agents.list[].skills を設定してください。一部の Skills は Homebrew でインストールされたバイナリを想定しています。Linux では Linuxbrew を意味します（上記の Homebrew Linux FAQ 項目を参照）。Skills、Skills 設定、ClawHubを参照してください。

組み込みの user ブラウザープロファイルを使用します。これは Chrome DevTools MCP 経由で接続します。

openclaw browser --browser-profile user tabs
openclaw browser --browser-profile user snapshot

カスタム名を使いたい場合は、明示的な MCP プロファイルを作成します。

openclaw browser create-profile --name chrome-live --driver existing-session
openclaw browser --browser-profile chrome-live tabs

この経路では、ローカルホストのブラウザーまたは接続済みブラウザー Node を使用できます。Gateway が別の場所で動作している場合は、ブラウザーのマシンで Node ホストを実行するか、代わりにリモート CDP を使用してください。

existing-session / user の現在の制限:

• アクションは CSS セレクター駆動ではなく、ref 駆動です
• アップロードには ref / inputRef が必要で、現在は一度に 1 ファイルのみ対応しています
• responsebody、PDF エクスポート、ダウンロードインターセプト、バッチアクションには、まだ管理ブラウザーまたは raw CDP プロファイルが必要です

はい。サンドボックス化を参照してください。Docker 固有のセットアップ（Docker 内の完全な Gateway またはサンドボックスイメージ）については、Dockerを参照してください。

デフォルトイメージはセキュリティ優先で、node ユーザーとして実行されるため、 システムパッケージ、Homebrew、バンドル済みブラウザーは含まれません。より完全なセットアップにするには:

• /home/node を OPENCLAW_HOME_VOLUME で永続化し、キャッシュを保持します。
• OPENCLAW_DOCKER_APT_PACKAGES でシステム依存関係をイメージに焼き込みます。
• バンドルされた CLI 経由で Playwright ブラウザーをインストールします: node /app/node_modules/playwright-core/cli.js install chromium
• PLAYWRIGHT_BROWSERS_PATH を設定し、そのパスが永続化されるようにします。

ドキュメント: Docker, ブラウザー。

はい。プライベートなトラフィックが DM で、公開トラフィックが グループ の場合に可能です。

agents.defaults.sandbox.mode: "non-main" を使用すると、グループ/チャンネルセッション（非メインキー）は設定済みのサンドボックスバックエンドで実行され、メインの DM セッションはホスト上に留まります。バックエンドを選ばない場合、Docker がデフォルトです。その後、tools.sandbox.tools でサンドボックス化セッションで利用できるツールを制限します。

セットアップ手順 + 設定例: グループ: 個人用 DM + 公開グループ

主要な設定リファレンス: Gateway 設定

agents.defaults.sandbox.docker.binds を ["host:path:mode"] に設定します（例: "/home/user/src:/src:ro"）。グローバルとエージェントごとのバインドはマージされます。scope: "shared" の場合、エージェントごとのバインドは無視されます。機密性の高いものには :ro を使用し、バインドはサンドボックスファイルシステムの壁を迂回することを覚えておいてください。

OpenClaw は、正規化されたパスと、最も深い既存の祖先を通じて解決された正規パスの両方に対してバインド元を検証します。つまり、最後のパスセグメントがまだ存在しない場合でも、シンボリックリンク親による脱出はフェイルクローズされ、許可ルートチェックはシンボリックリンク解決後にも引き続き適用されます。

例と安全上の注意については、サンドボックス化とサンドボックス vs ツールポリシー vs Elevatedを参照してください。

OpenClaw メモリは、エージェントワークスペース内の Markdown ファイルです。

• memory/YYYY-MM-DD.md の日次ノート
• MEMORY.md のキュレーション済み長期ノート（メイン/プライベートセッションのみ）

OpenClaw は サイレントな事前 Compaction メモリフラッシュ も実行し、モデルに 自動 Compaction 前に永続ノートを書くよう促します。これはワークスペースが書き込み可能な場合にのみ実行されます （読み取り専用サンドボックスではスキップされます）。メモリを参照してください。

ボットにその事実をメモリに書くよう依頼してください。長期ノートは MEMORY.md に、 短期コンテキストは memory/YYYY-MM-DD.md に入ります。

これはまだ改善中の領域です。メモリを保存するようモデルに思い出させると役立ちます。 モデルは何をすべきか理解します。忘れ続ける場合は、Gateway が毎回同じ ワークスペースを使用していることを確認してください。

ドキュメント: メモリ, エージェントワークスペース。

メモリファイルはディスク上に存在し、削除するまで保持されます。制限はモデルではなく、 ストレージです。セッションコンテキスト は引き続きモデルのコンテキストウィンドウに制限されるため、 長い会話は compact または切り詰められることがあります。そのためメモリ検索が存在します。関連する部分だけをコンテキストへ戻します。

ドキュメント: メモリ, コンテキスト。

OpenAI embeddingsを使用する場合のみ必要です。Codex OAuthはチャット/補完を対象とし、 embeddingsアクセスは許可しないため、**Codexでサインイン（OAuthまたは Codex CLIログイン）**してもセマンティックメモリ検索には役立ちません。OpenAI embeddings には引き続き実際のAPIキー（OPENAI_API_KEYまたはmodels.providers.openai.apiKey）が必要です。

providerを明示的に設定しない場合、OpenClawはAPIキーを解決できるときに providerを自動選択します（auth profiles、models.providers.*.apiKey、またはenv vars）。 OpenAIキーが解決できる場合はOpenAIを優先し、そうでなければGeminiキーが 解決できる場合はGemini、次にVoyage、次にMistralを優先します。リモートキーが利用できない場合、 設定するまでメモリ検索は無効のままです。localモデルパスが 設定済みで存在する場合、OpenClawは localを優先します。Ollamaは明示的に memorySearch.provider = "ollama"を設定した場合にサポートされます。

ローカルのままにしたい場合は、memorySearch.provider = "local"を設定します（任意で memorySearch.fallback = "none"も設定します）。Gemini embeddingsを使いたい場合は、 memorySearch.provider = "gemini"を設定し、GEMINI_API_KEY（または memorySearch.remote.apiKey）を指定します。OpenAI、Gemini、Voyage、Mistral、Ollama、local embedding modelsをサポートしています。セットアップの詳細はメモリを参照してください。

いいえ。OpenClawの状態はローカルですが、外部サービスには送信した内容が引き続き見えます。

• デフォルトではローカル: セッション、メモリファイル、config、workspaceはGatewayホスト （~/.openclaw + workspaceディレクトリ）上にあります。
• 必要によりリモート: モデルprovider（Anthropic/OpenAIなど）に送るメッセージは それらのAPIに送信され、チャットプラットフォーム（WhatsApp/Telegram/Slackなど）はメッセージデータを それぞれのサーバーに保存します。
• フットプリントは制御可能: localモデルを使うとプロンプトは自分のマシン上に留まりますが、channel trafficは引き続きchannelのサーバーを通ります。

関連: Agent workspace、メモリ。

すべては$OPENCLAW_STATE_DIR配下にあります（デフォルト: ~/.openclaw）:

レガシーの単一エージェントパス: ~/.openclaw/agent/*（openclaw doctorにより移行）。

workspace（AGENTS.md、メモリファイル、Skillsなど）は別で、agents.defaults.workspace（デフォルト: ~/.openclaw/workspace）経由で設定されます。

これらのファイルは~/.openclawではなく、agent workspaceにあります。

• Workspace（エージェントごと）: AGENTS.md、SOUL.md、IDENTITY.md、USER.md、 MEMORY.md、memory/YYYY-MM-DD.md、任意のHEARTBEAT.md。 小文字のルートmemory.mdはレガシー修復入力専用です。両方のファイルが存在する場合、 openclaw doctor --fixでMEMORY.mdへマージできます。
• State dir（~/.openclaw）: config、channel/provider state、auth profiles、sessions、logs、 共有Skills（~/.openclaw/skills）。

デフォルトworkspaceは~/.openclaw/workspaceで、次のように設定できます:

{
  agents: { defaults: { workspace: "~/.openclaw/workspace" } },
}

再起動後にbotが「忘れる」場合は、Gatewayが毎回同じ workspaceを使用していることを確認してください（そして注意: remote modeではローカルのラップトップではなく、 gateway hostのworkspaceが使われます）。

ヒント: 永続的な動作や設定を残したい場合は、チャット履歴に頼るのではなく、 botにAGENTS.mdまたはMEMORY.mdへ書き込むよう依頼してください。

Agent workspaceとメモリを参照してください。

agent workspaceをprivate git repoに置き、privateな場所 （例: GitHub private）にバックアップします。これによりメモリ + AGENTS/SOUL/USER ファイルが保存され、後でアシスタントの「mind」を復元できます。

~/.openclaw配下のもの（credentials、sessions、tokens、暗号化されたsecrets payloads）はコミットしないでください。 完全復元が必要な場合は、workspaceとstate directoryの両方を 別々にバックアップしてください（上の移行に関する質問を参照）。

ドキュメント: Agent workspace。

専用ガイドを参照してください: アンインストール。

はい。workspaceはデフォルトcwdでありメモリのアンカーであって、厳格なsandboxではありません。 相対パスはworkspace内で解決されますが、sandboxingが有効でない限り、絶対パスは他の ホスト上の場所にアクセスできます。分離が必要な場合は、 agents.defaults.sandboxまたはエージェントごとのsandbox設定を使用してください。 repoをデフォルト作業ディレクトリにしたい場合は、そのエージェントの workspaceをrepo rootに向けます。OpenClaw repoは単なるソースコードです。 エージェントをその中で動作させる意図がない限り、workspaceは分けておいてください。

例（デフォルトcwdとしてのrepo）:

{
  agents: {
    defaults: {
      workspace: "~/Projects/my-repo",
    },
  },
}

Session stateはgateway hostが所有します。remote modeの場合、重要なsession storeはローカルのラップトップではなくリモートマシン上にあります。Session managementを参照してください。

OpenClawは$OPENCLAW_CONFIG_PATH（デフォルト: ~/.openclaw/openclaw.json）から任意のJSON5 configを読み取ります:

$OPENCLAW_CONFIG_PATH

ファイルがない場合は、安全寄りのデフォルト（~/.openclaw/workspaceのデフォルトworkspaceを含む）を使用します。

Non-loopback bindには有効なgateway auth pathが必要です。実際には次を意味します:

• shared-secret auth: tokenまたはpassword
• 正しく設定されたidentity-aware reverse proxyの背後のgateway.auth.mode: "trusted-proxy"

{
  gateway: {
    bind: "lan",
    auth: {
      mode: "token",
      token: "replace-me",
    },
  },
}

注:

• gateway.remote.token / .passwordは、それだけではlocal gateway authを有効にしません。
• Local call pathsは、gateway.auth.*が未設定の場合にのみgateway.remote.*をfallbackとして使用できます。
• password authでは、代わりにgateway.auth.mode: "password"に加えてgateway.auth.password（またはOPENCLAW_GATEWAY_PASSWORD）を設定します。
• gateway.auth.token / gateway.auth.passwordがSecretRef経由で明示的に設定され、解決できない場合、resolutionはfail closedになります（remote fallbackによるマスクなし）。
• Shared-secret Control UIセットアップは、connect.params.auth.tokenまたはconnect.params.auth.password（app/UI settingsに保存）で認証します。Tailscale Serveやtrusted-proxyのようなidentity-bearing modesでは、代わりにrequest headersを使用します。shared secretsをURLに入れないでください。
• gateway.auth.mode: "trusted-proxy"では、同一ホストのloopback reverse proxiesに明示的なgateway.auth.trustedProxy.allowLoopback = trueとgateway.trustedProxies内のloopback entryが必要です。

OpenClawはloopbackを含め、デフォルトでgateway authを強制します。通常のデフォルトパスでは、これはtoken authを意味します。明示的なauth pathが設定されていない場合、gateway startupはtoken modeに解決され、そのstartup用のruntime-only tokenを生成するため、local WS clientsは認証が必要です。再起動をまたいでclientsが安定したsecretを必要とする場合は、gateway.auth.token、gateway.auth.password、OPENCLAW_GATEWAY_TOKEN、またはOPENCLAW_GATEWAY_PASSWORDを明示的に設定してください。これにより、他のローカルプロセスがGatewayを呼び出すのを防げます。

別のauth pathを希望する場合は、password mode（またはidentity-aware reverse proxiesではtrusted-proxy）を明示的に選択できます。本当にopen loopbackにしたい場合は、configでgateway.auth.mode: "none"を明示的に設定してください。Doctorはいつでもtokenを生成できます: openclaw doctor --generate-gateway-token。

Gatewayはconfigを監視し、hot-reloadをサポートします:

• gateway.reload.mode: "hybrid"（デフォルト）: 安全な変更はhot-applyし、重要な変更では再起動する
• hot、restart、offもサポートされています

configでcli.banner.taglineModeを設定します:

{
  cli: {
    banner: {
      taglineMode: "off", // random | default | off
    },
  },
}

• off: tagline textを非表示にしますが、banner title/version lineは維持します。
• default: 毎回All your chats, one OpenClaw.を使用します。
• random: 面白い/季節ごとのtaglineをローテーションします（デフォルト動作）。
• bannerをまったく表示したくない場合は、env OPENCLAW_HIDE_BANNER=1を設定します。

web_fetchはAPIキーなしで動作します。web_searchは選択した providerに依存します:

• Brave、Exa、Firecrawl、Gemini、Grok、Kimi、MiniMax Search、Perplexity、TavilyなどのAPI-backed providersには、通常のAPIキーセットアップが必要です。
• Ollama Web Searchはkey-freeですが、設定済みのOllama hostを使用し、ollama signinが必要です。
• DuckDuckGoはkey-freeですが、非公式のHTML-based integrationです。
• SearXNGはkey-free/self-hostedです。SEARXNG_BASE_URLまたはplugins.entries.searxng.config.webSearch.baseUrlを設定してください。

推奨: openclaw configure --section webを実行し、providerを選択します。 Environment alternatives:

• Brave: BRAVE_API_KEY
• Exa: EXA_API_KEY
• Firecrawl: FIRECRAWL_API_KEY
• Gemini: GEMINI_API_KEY
• Grok: XAI_API_KEY
• Kimi: KIMI_API_KEY または MOONSHOT_API_KEY
• MiniMax Search: MINIMAX_CODE_PLAN_KEY、MINIMAX_CODING_API_KEY、または MINIMAX_API_KEY
• Perplexity: PERPLEXITY_API_KEY または OPENROUTER_API_KEY
• SearXNG: SEARXNG_BASE_URL
• Tavily: TAVILY_API_KEY

{
  plugins: {
    entries: {
      brave: {
        config: {
          webSearch: {
            apiKey: "BRAVE_API_KEY_HERE",
          },
        },
      },
    },
    },
    tools: {
      web: {
        search: {
          enabled: true,
          provider: "brave",
          maxResults: 5,
        },
        fetch: {
          enabled: true,
          provider: "firecrawl", // optional; omit for auto-detect
        },
      },
    },
}

プロバイダー固有の Web 検索設定は、現在 plugins.entries.<plugin>.config.webSearch.* 配下にあります。 従来の tools.web.search.* プロバイダーパスは互換性のため一時的にまだ読み込まれますが、新しい設定では使用しないでください。 Firecrawl Web 取得フォールバック設定は plugins.entries.firecrawl.config.webFetch.* 配下にあります。

注記:

• allowlist を使う場合は、web_search/web_fetch/x_search または group:web を追加します。
• web_fetch はデフォルトで有効です（明示的に無効化されていない限り）。
• tools.web.fetch.provider を省略すると、OpenClaw は利用可能な認証情報から最初に準備済みの取得フォールバックプロバイダーを自動検出します。現時点で同梱されているプロバイダーは Firecrawl です。
• デーモンは ~/.openclaw/.env（またはサービス環境）から環境変数を読み込みます。

ドキュメント: Web ツール。

config.apply は 設定全体を置き換えます。部分的なオブジェクトを送信すると、それ以外はすべて削除されます。

現在の OpenClaw は、多くの意図しない上書きを防ぎます。

• OpenClaw が所有する設定書き込みは、書き込み前に変更後の設定全体を検証します。
• 無効または破壊的な OpenClaw 所有の書き込みは拒否され、openclaw.json.rejected.* として保存されます。
• 直接編集によって起動またはホットリロードが壊れた場合、Gateway はフェイルクローズするかリロードをスキップします。openclaw.json は書き換えません。
• openclaw doctor --fix が修復を担い、拒否されたファイルを openclaw.json.clobbered.* として保存しながら、最後に正常と分かっている設定を復元できます。

復旧:

• openclaw logs --follow で Invalid config at、Config write rejected:、または config reload skipped (invalid config) を確認します。
• アクティブな設定の横にある最新の openclaw.json.clobbered.* または openclaw.json.rejected.* を調べます。
• openclaw config validate と openclaw doctor --fix を実行します。
• 意図したキーだけを openclaw config set または config.patch で戻します。
• 最後に正常と分かっている設定や拒否されたペイロードがない場合は、バックアップから復元するか、openclaw doctor を再実行してチャンネル/モデルを再設定します。
• これが予期しない挙動だった場合は、バグを報告し、最後に分かっている設定またはバックアップを含めてください。
• ローカルのコーディングエージェントは、多くの場合、ログや履歴から動作する設定を再構築できます。

回避:

• 小さな変更には openclaw config set を使用します。
• 対話的な編集には openclaw configure を使用します。
• 正確なパスやフィールド形状が分からない場合は、まず config.schema.lookup を使用します。これは、浅いスキーマノードに加えて、ドリルダウン用の直下の子要約を返します。
• 部分的な RPC 編集には config.patch を使用します。config.apply は設定全体の置き換え専用にしてください。
• エージェント実行から所有者専用の gateway ツールを使用している場合でも、tools.exec.ask / tools.exec.security（同じ保護対象の exec パスに正規化される従来の tools.bash.* エイリアスを含む）への書き込みは引き続き拒否されます。

ドキュメント: 設定、設定、Gateway トラブルシューティング、Doctor。

一般的なパターンは、1 つの Gateway（例: Raspberry Pi）に ノードとエージェントを組み合わせるものです。

• Gateway（中央）: チャンネル（Signal/WhatsApp）、ルーティング、セッションを所有します。
• ノード（デバイス）: Macs/iOS/Android が周辺機器として接続し、ローカルツール（system.run、canvas、camera）を公開します。
• エージェント（ワーカー）: 特別な役割（例: 「Hetzner 運用」、「個人データ」）向けの別々の頭脳/ワークスペースです。
• サブエージェント: 並列処理が必要な場合に、メインエージェントからバックグラウンド作業を生成します。
• TUI: Gateway に接続し、エージェント/セッションを切り替えます。

ドキュメント: ノード、リモートアクセス、マルチエージェントルーティング、サブエージェント、TUI。

はい。設定オプションです。

{
  browser: { headless: true },
  agents: {
    defaults: {
      sandbox: { browser: { headless: true } },
    },
  },
}

デフォルトは false（ヘッドフル）です。一部のサイトでは、ヘッドレスの方がボット対策チェックを引き起こしやすくなります。ブラウザーを参照してください。

ヘッドレスは同じ Chromium エンジンを使用し、ほとんどの自動化（フォーム、クリック、スクレイピング、ログイン）で動作します。主な違いは次のとおりです。

• 表示されるブラウザーウィンドウがありません（視覚情報が必要な場合はスクリーンショットを使用します）。
• 一部のサイトでは、ヘッドレスモードの自動化に対してより厳しくなります（CAPTCHA、ボット対策）。 たとえば、X/Twitter はヘッドレスセッションをブロックすることがよくあります。

browser.executablePath を Brave バイナリ（または任意の Chromium ベースのブラウザー）に設定し、Gateway を再起動します。 完全な設定例は ブラウザー を参照してください。

Telegram メッセージは gateway によって処理されます。gateway がエージェントを実行し、ノードツールが必要な場合にのみ Gateway WebSocket 経由でノードを呼び出します。

Telegram → Gateway → エージェント → node.* → ノード → Gateway → Telegram

ノードは受信プロバイダートラフィックを見ません。ノード RPC 呼び出しだけを受け取ります。

短い答え: コンピューターをノードとしてペアリングします。Gateway は別の場所で実行されますが、Gateway WebSocket 経由でローカルマシン上の node.* ツール（画面、カメラ、システム）を呼び出せます。

典型的なセットアップ:

1. 常時稼働ホスト（VPS/ホームサーバー）で Gateway を実行します。

2. Gateway ホストと自分のコンピューターを同じ tailnet に置きます。

3. Gateway WS に到達できることを確認します（tailnet バインドまたは SSH トンネル）。

4. macOS アプリをローカルで開き、Remote over SSH モード（または直接 tailnet）で接続し、 ノードとして登録できるようにします。

5. Gateway でノードを承認します。

   openclaw devices list
   openclaw devices approve <requestId>
   

別個の TCP ブリッジは不要です。ノードは Gateway WebSocket 経由で接続します。

セキュリティの注意: macOS ノードをペアリングすると、そのマシンで system.run が可能になります。信頼するデバイスだけをペアリングし、セキュリティを確認してください。

ドキュメント: ノード、Gateway プロトコル、macOS リモートモード、セキュリティ。

基本を確認します。

• Gateway が実行中: openclaw gateway status
• Gateway の健全性: openclaw status
• チャンネルの健全性: openclaw channels status

次に、認証とルーティングを確認します。

• Tailscale Serve を使用している場合は、gateway.auth.allowTailscale が正しく設定されていることを確認します。
• SSH トンネル経由で接続する場合は、ローカルトンネルが起動しており、正しいポートを指していることを確認します。
• allowlist（DM またはグループ）に自分のアカウントが含まれていることを確認します。

ドキュメント: Tailscale、リモートアクセス、チャンネル。

はい。組み込みの「ボット間」ブリッジはありませんが、いくつかの信頼できる方法で接続できます。

最も簡単: 両方のボットがアクセスできる通常のチャットチャンネル（Telegram/Slack/WhatsApp）を使用します。 Bot A から Bot B にメッセージを送り、あとは通常どおり Bot B に返信させます。

CLI ブリッジ（汎用）: openclaw agent --message ... --deliver で別の Gateway を呼び出すスクリプトを実行し、もう一方のボットが待ち受けているチャットを対象にします。一方のボットがリモート VPS 上にある場合は、SSH/Tailscale 経由で CLI をそのリモート Gateway に向けます（リモートアクセスを参照）。

パターン例（対象 Gateway に到達できるマシンから実行）:

openclaw agent --message "Hello from local bot" --deliver --channel telegram --reply-to <chat-id>

ヒント: 2 つのボットが無限ループしないようにガードレールを追加します（メンション時のみ、チャンネル allowlist、または「ボットメッセージには返信しない」ルール）。

ドキュメント: リモートアクセス、エージェント CLI、エージェント送信。

いいえ。1 つの Gateway で複数のエージェントをホストでき、それぞれが独自のワークスペース、モデルのデフォルト、ルーティングを持てます。これが通常のセットアップであり、エージェントごとに 1 つの VPS を実行するよりもはるかに安価で簡単です。

別々の VPS は、強い分離（セキュリティ境界）が必要な場合や、共有したくない大きく異なる設定が必要な場合にのみ使用します。それ以外の場合は、1 つの Gateway を維持し、複数のエージェントまたはサブエージェントを使用します。

はい。ノードはリモート Gateway からラップトップへ到達するための第一級の方法であり、シェルアクセス以上の機能を解放します。Gateway は macOS/Linux（Windows は WSL2 経由）で動作し、軽量です（小さな VPS や Raspberry Pi クラスの箱で十分です。4 GB RAM で十分です）。そのため、常時稼働ホストに加えて、ラップトップをノードとして使う構成が一般的です。

• 受信 SSH は不要です。 ノードは Gateway WebSocket へ外向きに接続し、デバイスペアリングを使用します。
• より安全な実行制御。 system.run は、そのラップトップ上のノード allowlist/承認によって制御されます。
• より多くのデバイスツール。 ノードは system.run に加えて canvas、camera、screen を公開します。
• ローカルブラウザー自動化。 Gateway は VPS 上に置いたまま、ラップトップ上のノードホストを通じて Chrome をローカルで実行するか、Chrome MCP 経由でホスト上のローカル Chrome に接続します。

SSH はアドホックなシェルアクセスには問題ありませんが、継続的なエージェントワークフローとデバイス自動化にはノードの方が簡単です。

ドキュメント: ノード、ノード CLI、ブラウザー。

いいえ。分離されたプロファイルを意図的に実行する場合（複数の gateway を参照）を除き、ホストごとに実行する gateway は 1 つだけにしてください。ノードは gateway に接続する周辺機器です（iOS/Android ノード、またはメニューバーアプリの macOS「ノードモード」）。ヘッドレスノードホストと CLI 制御については、Node ホスト CLIを参照してください。

gateway、discovery、ホストされた Plugin サーフェスの変更には完全な再起動が必要です。

はい。

• config.schema.lookup: 書き込み前に、1つの設定サブツリーを、その浅いスキーマノード、一致した UI ヒント、直下の子要素の要約とともに確認する
• config.get: 現在のスナップショット + ハッシュを取得する
• config.patch: 安全な部分更新（ほとんどの RPC 編集で推奨）。可能な場合はホットリロードし、必要な場合は再起動する
• config.apply: 設定全体を検証 + 置換する。可能な場合はホットリロードし、必要な場合は再起動する
• オーナー専用の gateway ランタイムツールは、引き続き tools.exec.ask / tools.exec.security の書き換えを拒否する。レガシーの tools.bash.* エイリアスは、同じ保護対象の exec パスに正規化される

{
  agents: { defaults: { workspace: "~/.openclaw/workspace" } },
  channels: { whatsapp: { allowFrom: ["+15555550123"] } },
}

これはワークスペースを設定し、ボットをトリガーできる相手を制限する。

最小手順:

1. VPS にインストール + ログインする

   curl -fsSL https://tailscale.com/install.sh | sh
   sudo tailscale up
   

2. Mac にインストール + ログインする

   • Tailscale アプリを使い、同じ tailnet にサインインする。

3. MagicDNS を有効にする（推奨）

   • Tailscale 管理コンソールで MagicDNS を有効にすると、VPS に安定した名前が付く。

4. tailnet ホスト名を使う

   • SSH: ssh [email protected]
   • Gateway WS: ws://your-vps.tailnet-xxxx.ts.net:18789

SSH なしで Control UI を使いたい場合は、VPS で Tailscale Serve を使う:

openclaw gateway --tailscale serve

これにより gateway は loopback にバインドされたままになり、Tailscale 経由で HTTPS が公開される。Tailscale を参照。

Serve は Gateway Control UI + WS を公開する。ノードは同じ Gateway WS エンドポイント経由で接続する。

推奨設定:

1. VPS + Mac が同じ tailnet 上にあることを確認する。

2. macOS アプリをリモートモードで使う（SSH ターゲットには tailnet ホスト名を使用できる）。 アプリは Gateway ポートをトンネルし、ノードとして接続する。

3. gateway でノードを承認する:

   openclaw devices list
   openclaw devices approve <requestId>
   

ドキュメント: Gateway プロトコル、検出、macOS リモートモード。

2台目のラップトップで ローカルツール（画面/カメラ/exec）だけが必要な場合は、 ノードとして追加する。これにより単一の Gateway を維持し、設定の重複を避けられる。ローカルノードツールは 現在 macOS のみ対応だが、他の OS にも拡張する予定。

強い分離または完全に別個の2つのボットが必要な場合にのみ、2つ目の Gateway をインストールする。

ドキュメント: ノード、ノード CLI、複数の gateway。

OpenClaw は親プロセス（シェル、launchd/systemd、CI など）から環境変数を読み取り、さらに次を読み込む:

• 現在の作業ディレクトリの .env
• ~/.openclaw/.env（別名 $OPENCLAW_STATE_DIR/.env）からのグローバルフォールバック .env

どちらの .env ファイルも既存の環境変数を上書きしない。

設定内でインライン環境変数を定義することもできる（プロセス環境に存在しない場合にのみ適用される）:

{
  env: {
    OPENROUTER_API_KEY: "sk-or-...",
    vars: { GROQ_API_KEY: "gsk-..." },
  },
}

完全な優先順位とソースについては /environment を参照。

よくある修正は2つ:

1. 不足しているキーを ~/.openclaw/.env に置く。これにより、サービスがシェル環境を継承しない場合でも取得される。
2. シェルインポートを有効にする（任意の利便機能）:

{
  env: {
    shellEnv: {
      enabled: true,
      timeoutMs: 15000,
    },
  },
}

これはログインシェルを実行し、不足している想定キーだけをインポートする（上書きはしない）。対応する環境変数: OPENCLAW_LOAD_SHELL_ENV=1, OPENCLAW_SHELL_ENV_TIMEOUT_MS=15000.

openclaw models status は シェル環境インポート が有効かどうかを報告する。「Shell env: off」 は環境変数が不足しているという意味ではない。OpenClaw がログインシェルを 自動的に読み込まないという意味にすぎない。

Gateway がサービス（launchd/systemd）として実行されている場合、シェル 環境は継承されない。次のいずれかで修正する:

1. トークンを ~/.openclaw/.env に置く:

   COPILOT_GITHUB_TOKEN=...
   

2. またはシェルインポートを有効にする（env.shellEnv.enabled: true）。

3. または設定の env ブロックに追加する（不足している場合にのみ適用）。

その後 gateway を再起動して再確認する:

openclaw models status

Copilot トークンは COPILOT_GITHUB_TOKEN（および GH_TOKEN / GITHUB_TOKEN）から読み取られる。 /concepts/model-providers と /environment を参照。

単独のメッセージとして /new または /reset を送信する。セッション管理 を参照。

セッションは session.idleMinutes 後に期限切れにできるが、これはデフォルトでは無効（デフォルトは 0）。 アイドル期限切れを有効にするには、正の値に設定する。有効にすると、アイドル期間後の次の メッセージが、そのチャットキーに対して新しいセッション ID を開始する。 これは transcript を削除しない。新しいセッションを開始するだけ。

{
  session: {
    idleMinutes: 240,
  },
}

はい、マルチエージェントルーティングとサブエージェントで可能です。1 つのコーディネーター エージェントと、それぞれ独自のワークスペースとモデルを持つ複数のワーカーエージェントを作成できます。

とはいえ、これは楽しい実験として捉えるのが最適です。トークン消費が大きく、多くの場合、 セッションを分けた 1 つのボットを使うより効率が落ちます。私たちが想定している典型的なモデルは、 1 つのボットと会話し、並列作業には異なるセッションを使う形です。その ボットは必要に応じてサブエージェントを起動することもできます。

ドキュメント: マルチエージェントルーティング、サブエージェント、エージェント CLI。

セッションコンテキストはモデルのウィンドウによって制限されます。長いチャット、大きなツール出力、多数の ファイルがあると、Compaction や切り詰めが発生することがあります。

役立つこと:

• 現在の状態を要約してファイルに書き込むようボットに依頼する。
• 長いタスクの前に /compact を使い、トピックを切り替えるときは /new を使う。
• 重要なコンテキストをワークスペースに置き、ボットに読み返すよう依頼する。
• 長い作業や並列作業にはサブエージェントを使い、メインチャットを小さく保つ。
• これが頻繁に起きる場合は、より大きなコンテキストウィンドウを持つモデルを選ぶ。

reset コマンドを使います:

openclaw reset

非対話式の完全リセット:

openclaw reset --scope full --yes --non-interactive

次にセットアップを再実行します:

openclaw onboard --install-daemon

注記:

• 既存の設定がある場合、オンボーディングでも Reset が提示されます。オンボーディング（CLI）を参照してください。
• プロファイル（--profile / OPENCLAW_PROFILE）を使っていた場合は、各 state dir をリセットしてください（デフォルトは ~/.openclaw-<profile>）。
• 開発用リセット: openclaw gateway --dev --reset（開発専用。開発用設定 + 認証情報 + セッション + ワークスペースを消去します）。

次のいずれかを使います:

• コンパクト化（会話は保持しつつ、古いターンを要約します）:

  /compact
  

  または、要約の方針を指定するために /compact <instructions> を使います。

• リセット（同じチャットキーに対して新しいセッション ID を使います）:

  /new
  /reset
  

繰り返し発生する場合:

• 古いツール出力を削るために、セッションプルーニング（agents.defaults.contextPruning）を有効化または調整する。
• より大きなコンテキストウィンドウを持つモデルを使う。

ドキュメント: Compaction、セッションプルーニング、セッション管理。

これはプロバイダーのバリデーションエラーです。モデルが必須の input なしで tool_use ブロックを出力しました。通常、セッション履歴が古いか破損していることを意味します（長いスレッド やツール/スキーマ変更の後によく発生します）。

修正: /new を使って新しいセッションを開始します（単独メッセージ）。

Heartbeat はデフォルトで 30m ごとに実行されます（OAuth 認証を使う場合は 1h）。調整または無効化できます:

{
  agents: {
    defaults: {
      heartbeat: {
        every: "2h", // or "0m" to disable
      },
    },
  },
}

HEARTBEAT.md が存在していても実質的に空（空行と # Heading のような markdown 見出しだけ）の場合、OpenClaw は API 呼び出しを節約するために Heartbeat 実行をスキップします。 ファイルがない場合でも Heartbeat は実行され、モデルが何をするかを判断します。

エージェントごとの上書きには agents.list[].heartbeat を使います。ドキュメント: Heartbeat。

いいえ。OpenClaw はあなた自身のアカウントで動作するため、あなたがグループに入っていれば OpenClaw はそれを認識できます。 デフォルトでは、送信者を許可するまでグループ返信はブロックされます（groupPolicy: "allowlist"）。

グループ返信をトリガーできるのを自分だけにしたい場合:

{
  channels: {
    whatsapp: {
      groupPolicy: "allowlist",
      groupAllowFrom: ["+15551234567"],
    },
  },
}

オプション 1（最速）: ログを追尾し、グループでテストメッセージを送信します:

openclaw logs --follow --json

@g.us で終わる chatId（または from）を探します。例: [email protected]。

オプション 2（すでに設定済み/許可リスト済みの場合）: 設定からグループを一覧表示します:

openclaw directory groups list --channel whatsapp

ドキュメント: WhatsApp、ディレクトリ、ログ。

よくある原因は 2 つあります:

• メンションゲートが有効（デフォルト）。ボットを @メンションする（または mentionPatterns に一致させる）必要があります。
• channels.whatsapp.groups を "*" なしで設定しており、そのグループが許可リストに入っていない。

グループとグループメッセージを参照してください。

ダイレクトチャットはデフォルトでメインセッションに統合されます。グループ/チャンネルには独自のセッションキーがあり、Telegram トピック / Discord スレッドは別セッションです。グループとグループメッセージを参照してください。

厳密な上限はありません。数十個（数百個でも）問題ありませんが、次に注意してください。

• ディスク増加: セッションとトランスクリプトは ~/.openclaw/agents/<agentId>/sessions/ 配下にあります。
• トークンコスト: エージェントが増えるほど、同時並行のモデル使用量が増えます。
• 運用負荷: エージェントごとの認証プロファイル、ワークスペース、チャンネルルーティング。

ヒント:

• エージェントごとに アクティブ なワークスペースを 1 つに保ちます（agents.defaults.workspace）。
• ディスクが増える場合は、古いセッションを削除します（JSONL またはストアエントリを削除）。
• openclaw doctor を使って、不要なワークスペースやプロファイルの不一致を見つけます。

はい。マルチエージェントルーティングを使うと、複数の分離されたエージェントを実行し、受信メッセージを チャンネル/アカウント/相手ごとにルーティングできます。Slack はチャンネルとしてサポートされており、特定のエージェントにバインドできます。

ブラウザーアクセスは強力ですが、「人間ができることを何でもできる」わけではありません。ボット対策、CAPTCHA、MFA によって 自動化がブロックされることがあります。最も信頼性の高いブラウザー制御には、ホスト上のローカル Chrome MCP を使うか、 実際にブラウザーを実行するマシンで CDP を使います。

ベストプラクティスの設定:

• 常時稼働の Gateway ホスト（VPS/Mac mini）。
• ロールごとに 1 つのエージェント（バインディング）。
• Slack チャンネルをそれらのエージェントにバインド。
• 必要に応じて Chrome MCP またはノード経由のローカルブラウザー。

ドキュメント: マルチエージェントルーティング、Slack、 ブラウザー、ノード。

gateway.port は、WebSocket + HTTP（Control UI、フックなど）用の単一の多重化ポートを制御します。

優先順位:

--port > OPENCLAW_GATEWAY_PORT > gateway.port > default 18789

「running」はスーパーバイザー側の見え方（launchd/systemd/schtasks）だからです。接続プローブは、CLI が実際に Gateway WebSocket へ接続するものです。

openclaw gateway status を使い、次の行を信頼してください。

• Probe target:（プローブが実際に使用した URL）
• Listening:（そのポートで実際にバインドされているもの）
• Last gateway error:（プロセスは生きているがポートが待ち受けていない場合の一般的な根本原因）

サービスが別の設定ファイルで実行されている間に、別の設定ファイルを編集しています（多くの場合 --profile / OPENCLAW_STATE_DIR の不一致）。

修正:

openclaw gateway install --force

サービスに使わせたい同じ --profile / 環境から実行してください。

OpenClaw は、起動直後に WebSocket リスナーをバインドすることでランタイムロックを強制します（デフォルトは ws://127.0.0.1:18789）。バインドが EADDRINUSE で失敗すると、別のインスタンスがすでに待ち受けていることを示す GatewayLockError をスローします。

修正: もう一方のインスタンスを停止する、ポートを解放する、または openclaw gateway --port <port> で実行します。

gateway.mode: "remote" を設定し、リモート WebSocket URL を指定します。必要に応じて共有シークレットのリモート認証情報も指定できます。

{
  gateway: {
    mode: "remote",
    remote: {
      url: "ws://gateway.tailnet:18789",
      token: "your-token",
      password: "your-password",
    },
  },
}

注:

• openclaw gateway は、gateway.mode が local の場合のみ起動します（または上書きフラグを渡した場合）。
• macOS アプリは設定ファイルを監視し、これらの値が変更されるとライブでモードを切り替えます。
• gateway.remote.token / .password はクライアント側のリモート認証情報のみです。それ自体ではローカル Gateway 認証を有効にしません。

Gateway の認証パスと UI の認証方式が一致していません。

事実（コードより）:

• Control UI は、現在のブラウザータブセッションと選択された Gateway URL 用にトークンを sessionStorage に保持します。そのため、同じタブでの更新は、長期的な localStorage トークン永続化を復元しなくても動作し続けます。
• AUTH_TOKEN_MISMATCH では、Gateway が再試行ヒント（canRetryWithDeviceToken=true、recommendedNextStep=retry_with_device_token）を返した場合、信頼済みクライアントはキャッシュ済みデバイストークンで 1 回だけ制限付きの再試行を試みることができます。
• そのキャッシュ済みトークンによる再試行では、デバイストークンと一緒に保存されたキャッシュ済み承認スコープを再利用するようになりました。明示的な deviceToken / 明示的な scopes 呼び出し元は、キャッシュ済みスコープを継承せず、要求したスコープセットを維持します。
• その再試行パス以外では、接続認証の優先順位は、明示的な共有トークン/パスワードが最初、次に明示的な deviceToken、保存済みデバイストークン、最後にブートストラップトークンです。
• ブートストラップトークンのスコープチェックはロール接頭辞付きです。組み込みのブートストラップオペレーター許可リストはオペレーター要求のみを満たします。ノードやその他の非オペレーターロールには、引き続き自身のロール接頭辞配下のスコープが必要です。

修正:

• 最速: openclaw dashboard（ダッシュボード URL を出力してコピーし、開こうとします。ヘッドレスの場合は SSH ヒントを表示します）。
• まだトークンがない場合: openclaw doctor --generate-gateway-token。
• リモートの場合は、まずトンネルします: ssh -N -L 18789:127.0.0.1:18789 user@host、その後 http://127.0.0.1:18789/ を開きます。
• 共有シークレットモード: gateway.auth.token / OPENCLAW_GATEWAY_TOKEN または gateway.auth.password / OPENCLAW_GATEWAY_PASSWORD を設定し、一致するシークレットを Control UI 設定に貼り付けます。
• Tailscale Serve モード: gateway.auth.allowTailscale が有効であること、かつ Tailscale ID ヘッダーを迂回する生のループバック/tailnet URL ではなく Serve URL を開いていることを確認します。
• 信頼済みプロキシモード: 生の Gateway URL ではなく、設定済みの ID 対応プロキシ経由で来ていることを確認します。同一ホストのループバックプロキシにも gateway.auth.trustedProxy.allowLoopback = true が必要です。
• 1 回の再試行後も不一致が続く場合は、ペアリング済みデバイストークンをローテーション/再承認します。
  • openclaw devices list
  • openclaw devices rotate --device <id> --role operator
• そのローテーション呼び出しが拒否されたと表示する場合は、次の 2 点を確認してください。
  • ペアリング済みデバイスセッションは、operator.admin も持っていない限り、自分自身のデバイスしかローテーションできません
  • 明示的な --scope 値は、呼び出し元の現在のオペレータースコープを超えることはできません
• まだ詰まっていますか？openclaw status --all を実行し、トラブルシューティング に従ってください。認証の詳細は ダッシュボード を参照してください。

tailnet バインドは、ネットワークインターフェイスから Tailscale IP（100.64.0.0/10）を選びます。マシンが Tailscale 上にない（またはインターフェイスが停止している）場合、バインド先がありません。

修正:

• そのホストで Tailscale を起動します（100.x アドレスを持つようにします）、または
• gateway.bind: "loopback" / "lan" に切り替えます。

注: tailnet は明示的です。auto は loopback を優先します。tailnet 専用のバインドが必要な場合は gateway.bind: "tailnet" を使ってください。

通常はできません。1 つの Gateway で複数のメッセージングチャンネルとエージェントを実行できます。冗長性（例: レスキューボット）や強い分離が必要な場合にのみ、複数の Gateways を使います。

可能ですが、分離する必要があります。

• OPENCLAW_CONFIG_PATH（インスタンスごとの設定）
• OPENCLAW_STATE_DIR（インスタンスごとの状態）
• agents.defaults.workspace（ワークスペース分離）
• gateway.port（一意のポート）

クイックセットアップ（推奨）:

• インスタンスごとに openclaw --profile <name> ... を使います（~/.openclaw-<name> を自動作成）。
• 各プロファイル設定で一意の gateway.port を設定します（または手動実行では --port を渡します）。
• プロファイルごとのサービスをインストールします: openclaw --profile <name> gateway install。

プロファイルはサービス名にもサフィックスを付けます（ai.openclaw.<profile>、レガシー com.openclaw.*、openclaw-gateway-<profile>.service、OpenClaw Gateway (<profile>)）。 完全なガイド: 複数の Gateway。

Gateway は WebSocket サーバーであり、最初のメッセージとして connect フレームを期待します。それ以外を受信すると、コード 1008 （ポリシー違反）で接続を閉じます。

一般的な原因:

• WS クライアントではなく、ブラウザーで HTTP URL（http://...）を開いた。
• 間違ったポートまたはパスを使用した。
• プロキシまたはトンネルが認証ヘッダーを取り除いた、または Gateway ではない要求を送信した。

クイック修正:

1. WS URL を使います: ws://<host>:18789（HTTPS の場合は wss://...）。
2. 通常のブラウザータブで WS ポートを開かないでください。
3. 認証が有効な場合は、connect フレームにトークン/パスワードを含めます。

CLI または TUI を使用している場合、URL は次のようになります。

openclaw tui --url ws://<host>:18789 --token <token>

プロトコルの詳細: Gateway プロトコル。

ファイルログ（構造化）:

/tmp/openclaw/openclaw-YYYY-MM-DD.log

logging.file で安定したパスを設定できます。ファイルログレベルは logging.level によって制御されます。コンソールの詳細度は --verbose と logging.consoleLevel によって制御されます。

最速のログ追尾:

openclaw logs --follow

サービス/スーパーバイザーのログ（Gateway が launchd/systemd 経由で実行される場合）:

• macOS: $OPENCLAW_STATE_DIR/logs/gateway.log と gateway.err.log（デフォルト: ~/.openclaw/logs/...。プロファイルは ~/.openclaw-<profile>/logs/... を使用）
• Linux: journalctl --user -u openclaw-gateway[-<profile>].service -n 200 --no-pager
• Windows: schtasks /Query /TN "OpenClaw Gateway (<profile>)" /V /FO LIST

詳細は トラブルシューティング を参照してください。

Gateway ヘルパーを使用します。

openclaw gateway status
openclaw gateway restart

Gateway を手動で実行している場合、openclaw gateway --force でポートを取り戻せます。Gateway を参照してください。

Windows のインストールモードは 2 つあります。

1) WSL2（推奨）: Gateway は Linux 内で実行されます。

PowerShell を開き、WSL に入り、再起動します。

wsl
openclaw gateway status
openclaw gateway restart

サービスをインストールしていない場合は、フォアグラウンドで起動します。

openclaw gateway run

2) ネイティブ Windows（非推奨）: Gateway は Windows で直接実行されます。

PowerShell を開いて実行します。

openclaw gateway status
openclaw gateway restart

手動で実行する場合（サービスなし）は、次を使います。

openclaw gateway run

ドキュメント: Windows (WSL2)、Gateway サービス運用手順。

まず簡単なヘルスチェックから始めます。

openclaw status
openclaw models status
openclaw channels status
openclaw logs --follow

一般的な原因:

• Gateway ホストでモデル認証が読み込まれていません（models status を確認）。
• チャンネルのペアリング/許可リストが返信をブロックしています（チャンネル設定とログを確認）。
• WebChat/Dashboard が正しいトークンなしで開かれています。

リモートの場合は、トンネル/Tailscale 接続が稼働しており、 Gateway WebSocket に到達できることを確認してください。

Docs: チャンネル, トラブルシューティング, リモートアクセス.

これは通常、UI が WebSocket 接続を失ったことを意味します。確認事項:

1. Gateway は実行中ですか？ openclaw gateway status
2. Gateway は正常ですか？ openclaw status
3. UI に正しいトークンがありますか？ openclaw dashboard
4. リモートの場合、トンネル/Tailscale リンクは稼働していますか？

次にログを tail します:

openclaw logs --follow

Docs: Dashboard, リモートアクセス, トラブルシューティング.

ログとチャンネルステータスから始めます:

openclaw channels status
openclaw channels logs --channel telegram

次にエラーと照合します:

• BOT_COMMANDS_TOO_MUCH: Telegram メニューの項目が多すぎます。OpenClaw はすでに Telegram の上限まで減らし、より少ないコマンドで再試行しますが、それでも一部のメニュー項目を削除する必要があります。Plugin/skill/カスタムコマンドを減らすか、メニューが不要な場合は channels.telegram.commands.native を無効にしてください。
• TypeError: fetch failed、Network request for 'setMyCommands' failed!、または類似のネットワークエラー: VPS 上またはプロキシ配下にいる場合は、送信 HTTPS が許可され、api.telegram.org の DNS が機能することを確認してください。

Gateway がリモートにある場合は、Gateway ホスト上のログを見ていることを確認してください。

Docs: Telegram, チャンネルのトラブルシューティング.

まず、Gateway に到達でき、エージェントが実行できることを確認します:

openclaw status
openclaw models status
openclaw logs --follow

TUI では、/status を使って現在の状態を確認します。チャット チャンネルで返信を期待している場合は、配信が有効になっていることを確認してください（/deliver on）。

Docs: TUI, スラッシュコマンド.

サービスをインストールしている場合:

openclaw gateway stop
openclaw gateway start

これは 監視対象サービス（macOS では launchd、Linux では systemd）を停止/起動します。 Gateway がデーモンとしてバックグラウンドで実行されている場合に使用します。

フォアグラウンドで実行している場合は、Ctrl-C で停止し、その後:

openclaw gateway run

Docs: Gateway サービスランブック.

• openclaw gateway restart: バックグラウンドサービス（launchd/systemd）を再起動します。
• openclaw gateway: このターミナルセッションで Gateway をフォアグラウンド実行します。

サービスをインストールしている場合は、Gateway コマンドを使用してください。一度だけの フォアグラウンド実行が必要な場合は openclaw gateway を使用します。

コンソールの詳細を増やすには、--verbose を付けて Gateway を起動します。次に、チャンネル認証、モデルルーティング、RPC エラーについてログファイルを調べます。

エージェントからの送信添付ファイルには、（独立した行として）MEDIA:<path-or-url> 行を含める必要があります。OpenClaw アシスタント設定 と エージェント送信 を参照してください。

CLI 送信:

openclaw message send --target +15555550123 --message "Here you go" --media /path/to/file.png

次も確認してください:

• 対象チャンネルが送信メディアに対応しており、許可リストによってブロックされていないこと。
• ファイルがプロバイダーのサイズ制限内であること（画像は最大 2048px にリサイズされます）。
• tools.fs.workspaceOnly=true は、ローカルパス送信をワークスペース、temp/media-store、サンドボックス検証済みファイルに制限します。
• tools.fs.workspaceOnly=false は、エージェントがすでに読み取れるホストローカルファイルを MEDIA: で送信できるようにしますが、メディアと安全なドキュメント種別（画像、音声、動画、PDF、Office ドキュメント）のみに限られます。プレーンテキストやシークレットらしきファイルは引き続きブロックされます。

画像 を参照してください。

受信 DM は信頼できない入力として扱ってください。デフォルトはリスクを減らすように設計されています:

• DM 対応チャンネルでのデフォルト動作はペアリングです:
  • 不明な送信者はペアリングコードを受け取り、ボットはそのメッセージを処理しません。
  • 承認: openclaw pairing approve --channel <channel> [--account <id>] <code>
  • 保留中のリクエストはチャンネルごとに 3 件に制限されます。コードが届かなかった場合は openclaw pairing list --channel <channel> [--account <id>] を確認してください。
• DM を公開するには、明示的なオプトイン（dmPolicy: "open" と許可リスト "*"）が必要です。

リスクのある DM ポリシーを表面化するには openclaw doctor を実行してください。

いいえ。プロンプトインジェクションは、誰がボットに DM できるかだけでなく、信頼できないコンテンツに関するものです。 アシスタントが外部コンテンツ（Web 検索/取得、ブラウザページ、メール、 ドキュメント、添付ファイル、貼り付けられたログ）を読む場合、そのコンテンツには モデルを乗っ取ろうとする指示が含まれる可能性があります。これは送信者が自分だけでも起こり得ます。

最大のリスクはツールが有効な場合です。モデルがだまされて、 コンテキストを持ち出したり、あなたの代わりにツールを呼び出したりする可能性があります。影響範囲を減らすには:

• 信頼できないコンテンツを要約するために、読み取り専用またはツール無効の「reader」エージェントを使う
• ツール有効エージェントでは web_search / web_fetch / browser をオフにしておく
• デコードされたファイル/ドキュメントのテキストも信頼できないものとして扱う: OpenResponses input_file とメディア添付ファイル抽出はどちらも、抽出したテキストを生のファイルテキストとして渡すのではなく、 明示的な外部コンテンツ境界マーカーで囲みます
• サンドボックス化と厳格なツール許可リストを使う

詳細: セキュリティ.

ほとんどの設定では、はい。ボットを別のアカウントや電話番号で分離すると、 問題が発生した場合の影響範囲が小さくなります。また、個人アカウントに影響を与えずに 認証情報をローテーションしたりアクセスを取り消したりしやすくなります。

小さく始めてください。実際に必要なツールとアカウントにだけアクセスを付与し、必要になったら 後で拡張します。

Docs: セキュリティ, ペアリング.

個人メッセージに対する完全な自律性は推奨しません。最も安全なパターンは次のとおりです:

• DM はペアリングモードまたは厳格な許可リストに保つ。
• あなたの代わりにメッセージを送らせたい場合は、別の番号またはアカウントを使用する。
• 下書きを作らせてから、送信前に承認する。

試す場合は、専用アカウントで行い、分離したままにしてください。 セキュリティ を参照してください。

はい、エージェントがチャット専用で、入力が信頼できる場合です。小さいティアは 指示の乗っ取りに弱いため、ツール有効エージェントや信頼できないコンテンツを読む場合には避けてください。 小さいモデルを使う必要がある場合は、ツールをロックダウンし、サンドボックス内で実行してください。セキュリティ を参照してください。

ペアリングコードは、不明な送信者がボットにメッセージを送り、 dmPolicy: "pairing" が有効な場合のみ送信されます。/start だけではコードは生成されません。

保留中のリクエストを確認します:

openclaw pairing list telegram

すぐにアクセスしたい場合は、送信者 ID を許可リストに追加するか、そのアカウントで dmPolicy: "open" を設定してください。

いいえ。デフォルトの WhatsApp DM ポリシーはペアリングです。不明な送信者はペアリングコードを受け取るだけで、そのメッセージは処理されません。OpenClaw は、受信したチャットまたはあなたが明示的にトリガーした送信にのみ返信します。

ペアリングを承認します:

openclaw pairing approve whatsapp <code>

保留中のリクエストを一覧表示します:

openclaw pairing list whatsapp

ウィザードの電話番号プロンプト: これは自分の DM を許可するための許可リスト/所有者を設定するために使われます。自動送信には使われません。個人の WhatsApp 番号で実行する場合は、その番号を使い、channels.whatsapp.selfChatMode を有効にしてください。

ほとんどの内部メッセージまたはツールメッセージは、そのセッションで verbose、trace、または reasoning が有効な場合にのみ表示されます。

表示されているチャットで修正します:

/verbose off
/trace off
/reasoning off

それでも多すぎる場合は、Control UI のセッション設定を確認し、verbose を inherit に設定してください。また、設定で verboseDefault が on に設定されたボットプロファイルを使用していないことも確認してください。

Docs: 思考と verbose, セキュリティ.

次のいずれかを単独のメッセージとして送信します（スラッシュなし）:

stop
stop action
stop current action
stop run
stop current run
stop agent
stop the agent
stop openclaw
openclaw stop
stop don't do anything
stop do not do anything
stop doing anything
please stop
stop please
abort
esc
wait
exit
interrupt

これらは中止トリガーです（スラッシュコマンドではありません）。

バックグラウンドプロセス（exec ツールからのもの）の場合は、エージェントに次を実行するよう依頼できます:

process action:kill sessionId:XXX

スラッシュコマンドの概要: スラッシュコマンド を参照してください。

ほとんどのコマンドは、/ で始まる単独のメッセージとして送信する必要がありますが、いくつかのショートカット（/status など）は許可リストに含まれる送信者であればインラインでも動作します。

OpenClaw はデフォルトでプロバイダー間メッセージングをブロックします。ツール呼び出しが Telegram にバインドされている場合、明示的に許可しない限り Discord には送信されません。

エージェントのプロバイダー間メッセージングを有効にします:

{
  tools: {
    message: {
      crossContext: {
        allowAcrossProviders: true,
        marker: { enabled: true, prefix: "[from {channel}] " },
      },
    },
  },
}

設定を編集した後、Gateway を再起動してください。

キューモードは、新しいメッセージが実行中の run とどのように相互作用するかを制御します。モードを変更するには /queue を使用します:

• steer - 現在の run の次のモデル境界に向けて、保留中のすべてのステアリングをキューに入れる
• queue - 従来の 1 件ずつのステアリング
• followup - メッセージを 1 件ずつ実行する
• collect - メッセージをまとめて 1 回だけ返信する
• steer-backlog - 今すぐステアし、その後バックログを処理する
• interrupt - 現在の run を中止し、新しく開始する

デフォルトモードは steer です。フォローアップモードには debounce:0.5s cap:25 drop:summarize のようなオプションを追加できます。コマンドキューとSteering キューを参照してください。

OpenClaw では、認証情報とモデル選択は別々です。ANTHROPIC_API_KEY を設定する（または Anthropic API キーを認証プロファイルに保存する）と認証が有効になりますが、実際のデフォルトモデルは agents.defaults.model.primary で設定したものです（たとえば、anthropic/claude-sonnet-4-6 や anthropic/claude-opus-4-6）。No credentials found for profile "anthropic:default" が表示される場合、実行中のエージェントに対応する想定された auth-profiles.json 内で、Gateway が Anthropic 認証情報を見つけられなかったことを意味します。