OpenClaw Foundationは2026年8月31日、v2026.8.1を「OpenClaw 2.0」として公開した。入口は導入手順とブラウザ版の作り直しだったが、開発は同じ会話を複数人で引き継ぎ、処理を別の端末やクラウドへ移す仕組みにまで広がった。会話、認証情報、作業領域はGatewayが握り、実行場所と担当者を後から差し替える。個人用AIアシスタントが、チームの仕事を受け渡す制御面へ踏み込んだ更新である。
933人と1万6000件超のPRが生んだ「2.0」
公式ブログによると、今回の更新には933人が参加し、そのうち569人は初参加だった。取り込まれたプルリクエストは1万6000件を超え、OpenClawがそれまでに統合した全PRのおよそ半分を占めるという。正式な版番号は2026.8.1であり、「2.0」は更新範囲の大きさを表す呼び名だ。
この規模は、OpenClawの従来の開発速度と比べると分かりやすい。プロジェクトはそれ以前の230日間に106回、ほぼ1〜2日おきに新しい版を出していた。今回は約7週間にわたって正式版を止め、新規導入と既存環境からの更新を同時に検証した。導入画面を作り直すには、状態の保存方法とセッション管理を改め、権限を整え、クラウドでも処理できるようにする必要があったからである。
新規利用者向けには、端末上のChatGPTまたはClaudeの購読、APIキー、ローカルモデルを見つけて初期設定へ使う。最初から全項目を埋める方式を改め、会話を始めた後に残りの設定を進められるようにした。OpenClawは入口を短くする一方、運用が大きくなったときに必要な機能を同じ会話の周囲へ集めた。
会話から作業を監督するブラウザ管理画面
Control UI（ブラウザ管理画面）は、Gatewayが配信するViteとLit製の単一ページアプリである。新版は最初から会話を開き、設定、継続中の仕事、実行状況へ同じ画面から入れる。チャットの脇に置かれたセッション進行表示には、現在の状況、計画の進み具合、プルリクエスト、経過時間が残り、ページを再読み込みしても追跡を続けられる。
補助スレッドの役割は、長時間動くエージェントの監督にある。利用者が進行中のセッションについて質問すると、Gatewayは表示可能な範囲の履歴と作業領域を読み取り、別の小型モデルに答えさせる。主実行の会話へ質問を書き込まず、エージェントも中断しない。チャット欄が命令の入力箱から、作業を見守りながら判断を差し込む画面へ変わった。
複数人で使う場合、ブラウザ管理画面は誰がセッションを作り、いま誰が担当し、誰が参加したかも表示する。閲覧者の在席や入力中の状態は一時情報として扱われ、入力途中の文は履歴にもモデルの文脈にも保存されない。会話の中身と、人が同時に見ている状態を分けた設計である。
会話はGatewayに残り、処理だけが移動する
OpenClaw 2.0では、同じセッションを3種類の場所で動かせる。普段はGatewayを実行する機械で処理し、必要なら利用者が所有するペアリング済み端末か、処理後に破棄するクラウドワーカーへ切り替える。OpenClawの通常実行とCodexの遠隔実行は、同じ配置先を利用できる。
| 実行先 | 処理する機械 | 向く仕事 | 配置に必要な権限 |
|---|---|---|---|
| Gateway | Gatewayを動かすホスト | 日常的なセッション | 追加権限なし |
| ペアリング済み端末 | 手元のMac、ビルド機、所有するサーバー | 既存機材を使う処理 | operator.write |
| クラウドワーカー | 借りた使い捨てのクラウドマシン | 一時的な並列処理、長時間処理、手元端末からの分離 | operator.admin |
3つの実行先が変えるのは会話の置き場所ではなく、処理する機械である。Gatewayは会話、整合された作業領域、モデル認証情報、配置記録を保持する。遠隔機にはコマンド、ファイル編集、ツール処理を任せるが、モデルへの問い合わせはGatewayが中継するため、プロバイダーの認証情報を遠隔機へ渡さない。
この分離は復旧方法にも表れる。クラウドワーカーが停止または破棄されても、セッションと最後に同期した作業内容はGateway側に残り、次のメッセージで代替機を用意できる。ペアリング済み端末がオフラインになった場合は配置先を覚えたまま、その端末の復帰を待つ。クラウドワーカーは設定した環境でだけ表示される任意機能であり、公式文書は処理速度、料金、復旧時間の実測値を公表していない。
ここにOpenClaw 2.0の設計変更がある。セッションを特定のPCに固定せず、Gatewayが所有する会話へ実行先を割り当てることで、人と機械の両方を途中で交代させられる。ブラウザ刷新と共有セッションは、同じ状態管理の上に成り立っている。
「マルチプレイヤー」はセキュリティ境界ではない
OpenClawのマルチユーザー機能は、信頼する複数人の共同作業を想定し、所有者表示や参加履歴を隔離境界として扱わない。公式文書は、ある人がエージェントを操作できるなら、そのエージェントが実行可能なことをその人も指示できると明記する。家族や同じチームが一つのエージェントを共有するための機能であり、互いを信用しない顧客を同じ環境へ収容する仕組みではない。
セッションには作成者、所有者、参加者という3つの記録がある。作成者は原則として変わらず、共有可否を決める権限の起点になる。所有者はGitHub Issueの担当者に近く、人またはエージェントへ付け替えられるが、担当表示を変えてもアクセス権は移らない。参加者は実際に入力した人やエージェントの履歴で、閲覧しただけの人は含まれない。
アクセス制御は別の層が担う。チーム用のロールでは、他人のセッションを読めるか、どのエージェントを使えるか、操作権限をどこまで与えるか、新しいセッションにサンドボックスを必須とするかを設定する。操作権限は閲覧中心のoperator.read、メッセージ送信やツール操作を許すoperator.write、設定変更や高リスク承認を含むoperator.adminへ広がる。
さらに、セッション権限モードがファイル操作の範囲を決める。read-onlyは読み取りだけ、guardedは作業領域内の書き込みを人が承認し、workspaceは同じ範囲の実行をモデルが審査する。fullはファイルシステムを制限せず、利用には管理者権限が要る。明示的な権限設定もサンドボックスもない環境では、既定がfullになる場合があると公式文書は説明している。
つまり、担当者のアバター、ロール、セッション権限は別の仕事をする。アバターは責任者を示し、ロールはGateway上の操作を絞り、セッション権限はファイルとコマンドの範囲を抑える。取引先や別部門を強く分離する必要があるなら、公式の推奨は別のGatewayを別のOSユーザーまたは別ホストで動かすことだ。
更新前に新機能より先に確認すること
既存利用者には2件の破壊的変更がある。一つは同梱されていたOpenProseプラグインと/proseコマンドの削除、もう一つはcodex/*とopenai-codex/*のモデル参照や保存済みセッションをopenai/*へ移す変更だ。どちらもopenclaw doctor --fixが移行手段として案内されている。
外部プラグイン開発者には2026年9月1日付のSDK移行案内もある。ただし、これは今後の削除に備えるための予告であり、v2026.8.1で対象APIが直ちに消えたわけではない。利用者がプラグインを使う場合と、開発者が配布する場合では対応の緊急度が異なる。
見落としやすいのは、追加機能より既定値の変化である。個人環境では、同じエージェントの非公開会話から関連文脈を取り出す機能、背景での記憶統合、承認済みスキルの自動適用が既定で動く。会話は日付の変わり目やアイドル時間をまたいで保持され、最上位エージェントの同時実行数はCPU並列度に応じて8から16へ設定される。更新後は、以前と同じ設定ファイルでも、エージェントが参照する記憶と同時に走らせる仕事の数が変わり得る。
状態保存もSQLite中心へ移ったため、更新前のバックアップが欠かせない。公式の更新手順は、構成と状態を保存してからdoctorを実行し、Gatewayの起動を確認するよう求める。SQLite移行後に古い版へ戻す場合、移行後に作ったセッションは古いランタイムから見えない。コードを戻す操作と、状態を過去へ戻す操作は分けて考える必要がある。
OpenClaw 2.0を共有作業基盤として採用できるかは、機能数では決まらない。信頼する人の範囲ごとにGatewayを分け、ロールとセッション権限を明示し、状態のバックアップと復旧を試したうえで、遠隔実行の費用と同期時間を実測する必要がある。その条件が揃えば、担当者や実行機が変わっても会話の文脈を失わず、長い仕事をチームで引き継げる。
