AIREITER

OpenClawのマルチプレイヤー共有エージェント：2台のデバイスで1つのコンテキストを使う

最終更新日: 2026-11-05 19:46:50

2台のデバイスから1つのOpenClawエージェントを安全に使うことはできます。ただし、キューはあくまでテキストの待ち行列、永続化は別の仕組みだと理解しておく必要があります。共有セッションがコンテキストを保持し、active-tasks.mdのようなファイルが「何をやるか」を残します。

この切り分けがポイントです。OpenClaw 2.0（リリース v2026.8.1、2026年8月30日発表）は、1つの共有信頼ドメインで動くGatewayにマルチプレイヤー共有セッションを追加しました。これにより、2台のスマートフォン、2台のノートPC、あるいは2人のユーザーが、別々のプライベートな分岐を作らずに同じ実行を操作できます（docs.openclaw.ai）。ただし公式ドキュメントも明記しているとおり、所有者、プレゼンス、ロールはあくまで協調作業のための補助機能であり、悪意のあるユーザー同士を隔離するセキュリティ機能ではありません（docs.openclaw.ai）。実際に問題になりやすいのは、ドキュメントの概念説明よりも、キューの挙動、セッションの寿命、そしてメモリの扱いです。

ソファのスマホと机のノートPC――実際に起きる問題

現実によくある「2台構成」は、2人で使うケースとは限りません。Telegramを介し、スマートフォンをリモコン、Mac MiniやVPSをホストとして使う1人構成も多く見られます。あるユーザーは、Telegramから「my openclaw agent Monica」に「my mac mini」へmem0をローカルインストールするよう頼んだ、と説明しています（x.com）。

同じエージェントに2台目のデバイス、または2人目のユーザーが入ると、次の4つの問題が起こりがちです。

  1. メッセージが黙って消える。コミュニティで特に重視されているのが、queue mode enabled so messages never silently dropという設定です。これに加えて、クラッシュ復旧用の永続状態としてactive-tasks.md as persistent state for crash recoveryを使い、再起動時に読み直すBoot.mdを用意します（x.com）。この組み合わせがなければ、エージェントの処理中に送ったメッセージは保存済みの作業項目ではなく、消える可能性のある会話テキストです。
  2. コンパクションや再起動で指示が消える。Redditユーザーは、問題を次のように端的に表現しています。

「永続的なタスクキューがない。エージェントが『それに取りかかります』と言っても、それは会話上の約束にすぎない」――u/Brave_Nobody_6909、r/openclaw

同じスレッドでは、コンパクションや再起動の後に約束が消え、保存していたランブックも無視されたと報告されています。別のメンテナーによる解説も、メモリの扱いを誤ると、エージェントが「20分間は完璧に動く」のに、その後「指示を黙って忘れて暴走する」という構図を指摘しています（x.com）。

  1. セッションが途中でリセットされる。Telegramチャンネルのデフォルトには、thread: { mode: "idle", idleMinutes: 180 }が含まれる場合があります。数時間アイドル状態になるとセッションがリセットされる設定です。スマートフォンをセカンドスクリーンとして使っていて物忘れに悩まされたユーザーは、これを4日に変更しました（x.com）。コンテキストのあふれも状況を悪化させます。ツールを使いすぎると最後のメッセージが再投入され、エージェントが「同じことに何度も答え続け」、その後「静かに劣化する」ことがあります（x.com）。
  2. マルチプレイヤー以前にペアリングでつまずく。あるアップデート後、ペアリング済みのデバイスからoperator.read/operator.writeスコープが失われ、ツールが使えないまま無限のペアリングループに陥った事例があります。創業者は「潜在的なセキュリティ問題を直そうとして、やりすぎた」と返答しました（x.com）。中国語圏のユーザーも1008: pairing requiredに遭遇しており、ローカルデバイスがPendingキューに止まった場合は、openclaw devices listに続けてdevices approve <UUID>を実行する必要があります（x.com）。

プレゼンス機能を見れば誰かが入力中かどうかは分かります。しかし、キューに入ったメッセージを保存済みのタスクへ変えてくれる表示はありません。

1つのGateway、1つの信頼ドメイン――共有セッションと分離エージェントの違い

OpenClaw 2.0の目玉は共有セッションです。別のユーザーが、コンテキストを保ったまま進行中の作業に参加できます。複数のレビューでは、これを単独操作から共同作業への転換と位置づけています（eesel.ai）。設定を決めるうえでは、公式ドキュメントにある2つの概念が重要です。

マルチユーザーモードは、複数の信頼できるユーザーが1つのエージェントを操作する仕組みです。共有セッションには、変更できない作成者（createdActor、一度だけ書き込まれる）、GitHubのassigneeのようにいつでも変更できる所有者、実際にプロンプトを送ったユーザーの参加履歴という3つの層が記録されます（docs.openclaw.ai）。プレゼンスには閲覧者や入力者が表示されますが、入力途中のドラフトはモデルにもトランスクリプトにも届きません。また、複数人の操作が1つのターンに統合されることがあるため、ターンの帰属は明確に保証されず、あくまでベストエフォートです（docs.openclaw.ai）。実際には、エージェントがツールを実行している最中に別チャンネルからフォローアップを送ると、その内容はトランスクリプトには入ります。しかし実行中のターンが先に完了するため、2つ目の指示は割り込みではなく、次の操作への補足指示として扱われます（docs.openclaw.ai）。

マルチエージェントモードは、1つのGatewayプロセスで複数の分離されたエージェントを動かす仕組みです。エージェントごとにワークスペース、agentDir（認証プロファイルやモデルレジストリ）、<agentDir>/openclaw-agent.sqliteにあるSQLiteセッションストアを持ちます（github.com）。バインディングは受信したチャンネルイベントをエージェントへ振り分け、最も具体的な一致が優先されます。エージェント間で同じagentDirを使うと、それぞれのauth-profiles.jsonを上書きするため、絶対に共有しないでください（stack-junkie.com）。最小構成の例では、{ agentId: "coding", match: { channel: "telegram", accountId: "coding-bot" } }により、1つのボットを1つのエージェントへルーティングします。

覚えておきたい原則は、「1つのGatewayは1つの信頼ドメイン」ということです（docs.openclaw.ai）。ロール、所有者フィルター、アバターがあっても、悪意のあるユーザー同士を隔離することはできません。互いに信頼できないユーザーを扱うなら、Gatewayを分け、できればOSユーザーやホストも分離してください。

項目1つの共有エージェント（マルチユーザーセッション）分離エージェント（マルチエージェント）
会話トランスクリプト共有。両方のデバイスで同じスレッドを見られるエージェントごとのSQLiteストアに分離
コンテキストウィンドウ共有。操作指示は実行中のターンに統合される分離。デフォルトではエージェント間のトランスクリプト検索は行われない
メモリ／ワークスペースファイルエージェント単位で範囲を分けない限り、AGENTS.md、メモ、Wikiを共有ワークスペースは分離。共有スキルは~/.openclaw/skillsまたはextraDirs経由のみ（github.com）
モデル認証情報個人アカウントを設定可能。ただし表示はラベルだけで、請求には共有のフォールバックアカウントが使われる場合もある（docs.openclaw.ai）エージェントごとのagentDir。OAuthのリフレッシュ情報はデフォルトでは持ち運べず、共有には明示的なオプトインが必要（github.com）
Cron／自動化Gatewayから見える。operator.adminを持つ管理者は他ユーザーのジョブも管理できる（docs.openclaw.ai）agentToAgentと可視性の設定が許可すれば、エージェント間から到達可能（github.com）
保留中のキューセッションごとに1つエージェントごとに別のキューとルーティング

1人が2台のデバイスで使うなら左側です。2人で使い、互いの履歴を日常的に見せたくないなら右側を選びます。アクセス制御を信頼できないユーザーに対して実効性のあるものにする必要がある場合は、Gatewayを2つに分けてください。1つのボットをカップルで共有する場合のReddit上の助言も、「2つのエージェントを作り、同じ認証プロファイルを使う。ただし片方は自分向け、もう片方は妻向けにする」という方向に集約されています（u/mr-cto-apps、r/openclaw）。1つのTelegramボットを共有する別スレッドでも、「あなたの状況なら、たいていの人は2つのインスタンスを動かす」という助言があります（u/dertobi、r/openclaw）。2.0で共有セッションが追加された後も、個別のプライベート作業にはこの考え方が当てはまります。

エージェントが忙しいとき、2つ目のメッセージはどこへ行くのか

ユーザーが混同しやすく、作業を失いやすい境界には3つの入れ物があります。

1つ目：セッションキュー。エージェントの処理中に送ったテキストは、現在のセッションに追加されます。キューモードを有効にすると、メッセージは捨てられずに待機します。プレゼンスで処理中かどうかも確認できますが、メッセージは実行中のターンを中断せず、次のターンを操作する指示になります。入力中のドラフトは一時的なもので、コンテキストには入りません（docs.openclaw.ai）。2台目のデバイスから送るメッセージは、「これが終わったらXを実行し、Yは再起動しない」のように短く明確にしましょう。複数人の入力が操作指示として統合される場合、ターンの帰属はベストエフォートだからです（docs.openclaw.ai）。

2つ目：永続化されたタスク。キューに入ったメッセージは、永続的な作業項目ではありません。Gatewayが再起動したり、セッションがコンパクションされたり、/newを実行したりすると、会話上の約束が消えることがあります。再起動後も残るコミュニティの対策は、メッセージではなくファイルを使うことです。クラッシュ復旧用の状態としてactive-tasks.mdを置き、セッションやGatewayの再起動時にエージェントが読むBoot.mdを用意します（x.com）。メモリツールでコンテキストを再投入することはできますが、読み込んだメモリ自体が要約で失われる可能性もあります。広く共有されている説明では、「メモリはディスク上に存在する。エージェントが、それをたどる能力を失っただけだ」とされています（x.com）。

3つ目：スケジュール実行。CronやAutomationsはGatewayが稼働している間に実行されます。ホストがスリープすると、スケジュールも止まります（eesel.ai）。あるユーザーは、Cronの実行中にセッション履歴がコンテキストを埋め尽くし、エージェントが「その時間帯はほぼ使い物にならなかった」と報告しています。対策として、Telegramのトピックごとにコンテキストを分けることを勧めています（x.com）。定期作業にはスケジュールジョブを使い、フォローアップ指示のキュー代わりにはしないでください。

キューの表示が実際の状態に追いつかないこともあります。あるスレッドでは、リクエストが目に見えてキューに入っているのに、/subagentsと/tasksには何も表示されなかったと報告されています（reddit.com）。再起動後も残るかを確認するときは、キューUIの表示ではなく、2つ目の入れ物にあるファイルを基準にしてください。

指示を失わない2台構成

ここでは、ノートPCとスマートフォンを1人で使う場合、または信頼できる2人のチームメンバーが1つの共有セッションを使う場合の構成を紹介します。公式のクイックセットアップと本番運用手順（docs.openclaw.ai）に、コミュニティがたどり着いた紛失防止策を加えたものです。

  1. Gatewayは常時稼働ホストに置き、本人確認ベースでアクセスする。小規模なVPS、オフィスのMac、Mac Miniなどで構いません。Gatewayはloopbackにバインドし、公開ポートや共有トークンではなく、Tailscale ServeまたはCloudflare Accessを前段に置きます。IDベースのアクセスなら、セッション内でユーザーごとの操作記録やコミットの貢献者情報を残せます。共有トークンでは、全員が同じ所有者プロファイルになります（docs.openclaw.ai）。
  2. 2台とも別々のセッションではなく、同じセッションに参加させる。各デバイスでControl UIまたはチャットチャンネルを開き、セッションの所有者を明示的に設定します。Control UIのAssign to me / Assign to、またはsessionsツールのassign_ownerを使えます。引き継ぎには@メンションを使いましょう。DMとグループルームでは許可リストを分ける必要があります（docs.openclaw.ai）。所有者を変更しても責任の所在が変わるだけで、作成者に紐づく共有設定やアーカイブ権限は変わりません。作成者は固定しておくのが安全です。
  3. キューを有効にし、再起動後も作業を残す。共有セッションをキューモードに切り替え、処理中に送ったメッセージを競合させず待機させます。これをしないと、メッセージが黙って消えることがあると報告されています。ワークスペースには、作業項目を1行ずつ、done / doing / nextの状態で記録したactive-tasks.mdを置きます。さらに起動時にこれを読むよう指示するBoot.mdを追加します（x.com）。認証情報を保存しただけでは成功確認にならないため、2台目のデバイスを頼る前にモデルが応答することも確認してください（docs.openclaw.ai）。
  4. スマートフォン側のチャンネルではセッション寿命を延ばす。Telegramをセカンドスクリーンとして使い、スレッドがthread: { mode: "idle", idleMinutes: 180 }でリセットされる構成なら、長時間の作業に合わせて値を延ばします。あるユーザーは4日に変更しました。Cronの出力で共有コンテキストが埋まらないよう、トピックも分けてください。
  5. ユーザーごとに自分のモデルアカウントを持たせる。Gatewayのプロファイルには個人の認証情報を設定できます。新しいセッションでは個人のデフォルトが優先されますが、Gateway全体のデフォルトは変わりません。他のユーザーから見えるのもメールアドレスやアカウントIDではなく、ユーザーレベルのラベルだけです（docs.openclaw.ai）。認証情報は保護されたUIか、入力内容が表示されないターミナルプロンプトから登録してください。共有トランスクリプトに残る会話へ貼り付けてはいけません。
  6. 最初から最後まで動作を確認する。2台目のデバイスから処理中にメッセージを送り、保持されたうえで現在のターンの後に処理されることを確認します。その後Gatewayを再起動し、active-tasks.mdから作業項目が復元されることも確認します。公式の本番チェックリストも、完了と判断する前に一連の流れ全体を検証するよう求めています（docs.openclaw.ai）。

共有コンテキストを腐らせないためのルール

ユーザーが語る「コンテキストの劣化」の大半は、次の3つのルールで防げます。

メモリへの書き込みには必ず署名する。最も気づきにくい失敗は、誰が追加したか分からないルールが積み重なり、誰も削除できなくなることです。「共有コンテキストが6か月も経つと、誰が書いたか追跡できないルールでいっぱいになり、誰も削除してよいと思えなくなる」という指摘があり、対策として「すべてのメモリ書き込みに作成者を付ける」ことが提案されています（x.com）。共有書き込みに作成者情報がないことが問題なのです。永続化するメモには、誰がいつ依頼したかを付け、月1回整理しましょう。

信頼度の低いユーザー側はサンドボックスに入れる。ロールによって、セッションへのアクセス、利用可能なエージェント、operatorスコープを制限できます。また、ゲストセッションにworkspaceAccess: "none"を適用すれば、ファイルやシェルのツールを共有エージェントのワークスペースではなく、専用のプライベートワークスペースで実行させられます（docs.openclaw.ai）。プライベートな下書きはDraftセッションに置くと、他のユーザーのサイドバーには表示されません。ただし管理者から見えなくなるわけではありません（docs.openclaw.ai）。

共有をやめるタイミングを知る。複数のマルチエージェントを運用するユーザーは、コンテキストの混入を「実務上最大の課題」と呼び、エージェントが「互いの領域に入り込んでいく」と説明しています（u/BP041、r/openclaw）。中国語圏のビルダーからは、さらに割り切ったルールが出ています。まず1つのエージェントを調整し、その後マシンごとに複製する――つまり「新しいデバイスへのクローンを手伝わせ」、調整済みの構成を「1人1つ」にする方法です（x.com）。同期するのはメモリとdotfilesだけにして、認証情報と実行中のセッションは残します（x.com）。これは公式ドキュメントの分離策とも一致します。エージェント単位のMemory Wiki vault（vault.scope = "agent"）、エージェント間のトランスクリプト検索ではなく明示的に共有するMarkdownディレクトリ、そして本当の隔離が必要な場合の別Gatewayです（github.com）。

FAQ

2台のデバイスで、同じOpenClawエージェントのセッションを同時に共有できますか？

できます。両方のデバイスを同じセッションに参加させます。コンテキストを持つのはデバイスではなくセッションです。所有者を設定し、キューモードを有効にすれば、2台目のデバイスから送ったメッセージは待機します（docs.openclaw.ai）。

コンパクション、/new、再起動の後に指示が消えるのはなぜですか？

チャットメッセージは、保存されたタスクではないからです。コンパクションはコンテキストを要約し、/newは新しいセッションを開始し、再起動はメモリ上の状態を失わせます。作業項目はactive-tasks.mdに保存し、Boot.mdから読み直す構成にしてください（x.com）。

2人で1つのエージェントを共有すべきですか、それとも1人1つにすべきですか？

同じスレッド、メモリ、キューを使う必要があるなら、1つのエージェントを共有します。履歴、認証情報、権限を混ぜたくないなら、1人1つのエージェント、またはGatewayを分けてください。マルチユーザー機能はセキュリティ上の隔離を提供しません（docs.openclaw.ai）。GitHubの帰属設定を有効にすれば、共有操作によってCo-authored-byのコミットトレーラーを付けることもできます（docs.openclaw.ai）。

共有するか、複製するか――30秒で決める

状況選ぶ構成
1人でノートPCとスマートフォン共有セッションを1つ、キューモードをオン、active-tasks.md＋Boot.md、アイドルタイムアウトは長め
信頼できる2人のチームメンバーが1つの作業を担当共有セッションを1つ、所有者を明示、引き継ぎは@メンション、メモリ書き込みには署名、経験の浅いユーザー側はゲストサンドボックス
2人が別々の作業をするエージェントを2つ（またはGatewayを2つ）、共有スキルは~/.openclaw/skills経由、agentDirは共有しない
信頼できないユーザー、または顧客に近いアクセスOSユーザーまたはホストを分けてGatewayも分離し、Session Shareで選択したセッションを読み取り専用で公開（docs.openclaw.ai）

キューモードを使えば、2人の入力が互いに割り込むことはありません。ただし、競合する指示まで整理してくれるわけではなく、統合された入力が混ざる可能性は残ります。再起動後も指示を生かしてくれるのは、キューではなくファイルです。