OpenClaw 2.0 が「マルチプレイヤー」AI コーディング時代を宣言

今年前半、Telegram、iMessage、WhatsApp、Discord などの好きなチャネルからユーザーがメッセージを送信できるオープンソースの AI ハーネス「OpenClaw」を巡る熱狂は、2026 年 3 月のピーク時と比べると大幅に落ち着きました。

しかし先週末、OpenClaw の創設者である Peter Steinberger と現在の共同開発チームが、企業を含む世界中に対し改めて注目する理由を提供しました。それが「OpenClaw 2.0」の発表です。これは同ハーネスおよび周辺プラットフォームにとって迄今为止で最も重要なアップデートとして位置づけられています。

OpenClaw 2.0 は、当初は主に個人向けのエージェント用ハーネスとして始まったものを、チームでの利用や共有インフラ、そして企業ワークフローに最適化されたものへと変革することを目指しています。

OpenClaw 2.0 では、会話、ファイル、承認手続き、設定、およびリアルタイムのエージェント活動を一元的な作業スペースに集約する再構築されたブラウザインターフェースが導入されました。さらに、共有クラウドセッションや複数ユーザーによる共同編集機能も追加されています。セキュリティモデルも強化され、より強力なサンドボックス化、ロールベースの権限管理、承認コントロール、シークレット（機密情報）の扱い、監査機能が備えられました。

これらの新機能により、OpenClaw は単に個人開発者がローカル環境で運用する強力なエージェントという枠を超え、組織が従業員のために導入できるインフラへと近づいています。

同時に、このプロジェクトを取り巻く競争上の問いも鮮明になりました。つまり、OpenClaw が「NanoClaw」のような新たな代替手段の登場を促したセキュリティや分離に関する懸念に対し、十分な対策を講じたのかどうかという点です。

機能レベルではその答えはますます「イエス」になりつつありますが、デフォルトでそうなるわけではありません。

OpenClaw は共有エージェント層へと進化しようとしています。

公式バージョン名 v2026.8.1 としてリリースされた今回のアップデートは、インストール、メッセージング、メモリ、スキル、モデル、自動化、ブラウザおよびネイティブアプリ、プラグイン、セキュリティにまたがる広範な改善を含んでいます。

Steinberger 氏は OpenClaw 2.0 の開発を「製品を使って自身を構築する」という試みとして説明しました。

「2 ヶ月前、『OpenClaw を OpenClaw で構築する』というミッションを開始しました」と、Steinberger 氏は 8 月 31 日の早朝に X（旧 Twitter）で投稿しています。

その期間中、同氏によると、OpenClaw チームは個々のローカルコーディング環境から離れ、チームメンバーが何に取り組んでいるかを認識する共有エージェント環境である team.openclaw.ai へと移行していきました。

「マルチプレイヤー・コーディングとノードおよびクラウドセッションによる無限の計算リソースは、私たちの構築方法に革命をもたらしました」と Steinberger 氏は書き加え、ローカルな開発環境は今や「過去の遺物のように感じられる」と述べています。

この主張は、OpenClaw の企業向け提案における最も重要な変化の一つを指し示しています。

現在の AI コーディングエージェントの主流モデルは、個人利用が中心です。開発者がターミナル、IDE、またはデスクトップアプリケーションでエージェントを実行し、リポジトリへのアクセス権を与えて、その環境内で作業を実行させるという形が一般的です。

OpenClaw 2.0 は、従来の枠組みを超えた新たな方向性を示しています。エージェントのセッションは、単一のターミナルや特定の従業員に依存しない「永続的な作業スペース」として機能します。これらは同僚と共有でき、他のマシンやクラウドワーカー上で実行することも可能で、ブラウザを通じて監視も可能です。

企業にとってこれは、エージェントを個々の従業員の生産性向上ツールから、組織全体で共有される運用基盤へと昇華させる可能性を秘めています。

新 UI が OpenClaw の利用層を広げる

この戦略の中心となるのが、刷新されたコントロール UI です。

OpenClaw は「概要」ファーストの Web アプリケーションという従来のアプローチから離れ、対話（コンバージョン）を主要なインターフェースへと変更しました。スレッドはサイドバーに配置され、アクティブな対話はメインワークスペースで展開されます。ファイル、承認処理、設定、そして進行中のエージェント活動も、周囲からいつでもアクセス可能です。

このデザインは意図的に、OpenAI の ChatGPT、Anthropic の Claude、Google の Gemini、その他の会話型 AI プロダクトで従業員がすでに慣れ親しんでいるインタラクションモデルに OpenClaw を近づけています。

これにより、企業導入における重要な障壁が取り除かれます。オープンソースのエージェントフレームワークは、低レベルの設定やターミナル、ツール、ランタイム制御を露出させることで強力な機能を発揮しますが、その特性ゆえにエンジニアリング組織の範囲を超えて展開するのが難しいという課題を抱えていました。

OpenClaw 2.0 は、背後にある制御機能を維持しつつ、その上に会話型インターフェースを実装しました。これにより、従業員はターミナルを主操作画面として扱うことなく、エージェントに作業を依頼できるようになります。ただし、OpenClaw は内部で何が行われているかを隠すわけではありません。

Control UI では、セッションファイルやターミナルの活動履歴、Git ベースの変更点、プルリクエストの状態、ブラウザ上の動作、そしてインタラクティブなダッシュボードなどを表示できます。

今回のリリースでは、エージェント実行中の可視性にもより重点が置かれています。ツールの呼び出しとその結果を明確にペアリングしたり、ファイル変更を焦点を絞った差分（diff）として表示したり、コマンドの活動履歴を検査しやすくしたりしています。また、長時間実行されるバックグラウンドタスクも、会話ウィンドウと並んで常に表示可能です。

これらの機能は、企業利用において非常に重要です。

従業員は作業を委任するためのシンプルなインターフェースを利用できます。技術者には、会話の背後にある成果物や実行状態へのアクセス権が維持されます。管理者にとっては、システムの設定と監視を行う一元化された場所が提供されます。

再設計された「設定（Settings）」ワークスペースでは、エージェント、メモリ、プラグイン、MCP サーバー、デバイス、通信チャネル、そしてデバイスのペアリング管理を包括的に扱えるようになりました。また、OpenClaw はモデルプロバイダーの管理機能も統合しました。これには、認証情報のステータスや、プロバイダーが公開している場合のモデル利用状況、クォータ、アカウント残高、予算、および使用料金の情報などが含まれます。

アクセス制限のあるブラウザユーザーは、自動的に特権を取得するのではなく、管理者への権限昇格をリクエストする必要があります。その際、別の管理者による承認が必要です。

派手なエージェント機能ではありませんが、数十人から数百人の従業員に AI システムを導入する企業にとっては、今回のリリースで最も重要な追加要素の一つとなる可能性があります。

マルチプレイヤースession は、エージェントのコンテキストを共有コンテキストへと変換します。

OpenClaw 2.0 では、エージェントが個人の作業スペースから共同作業の場へと拡張されます。クラウド上の共有セッションにより、他の従業員も進行中の作業に参画でき、エージェントが蓄積してきたコンテキストを保持したまま協働することが可能です。

ユーザーとエージェントをツール、ファイル、認証情報、その他のリソースへ接続する「Multi-user Gateways」サービスでは、会話の作成者や特定の参加者が送信したプロンプトを追跡できます。オーナーや管理者は、他のユーザーがセッションを閲覧できるか、変更を提案できるか、ドラフトモードで作業できるか、あるいは直接参画できるかを設定できます。

インターフェースには、セッションの所有権、参加者の特定、現在のアクティビティ（プレゼンス）、入力中の表示といった機能が追加されました。コーディングチームにとっては、従来の AI チャットよりも共同ソフトウェア開発に近いワークフローが実現されます。

ある開発者がタスクを開始し、エージェントに遠隔で作業を任せることができます。別のエンジニアは、その結果生じた変更を検証できます。シニアエンジニアや管理者は、追加の権限が必要な操作を承認することも可能です。作業は、開始時に使用したラップトップやターミナルに縛られる必要はありません。

セッションは、広範なワークスペースを維持しつつ、実行をペアリングされたデバイスやクラウドワーカーへ移行することもできます。

長期実行型のエージェントを試行している企業にとって、これは重要な意味を持ちます。永続的なエージェントには、シフトチェンジ、エスカレーション、監督、所有権の移管といった仕組みが必要です。そうでなければ、組織は単に個々のユーザー環境に状態が消失するパーソナルエージェントの群れを作ることになります。

OpenClaw は、その状態を協働インフラへと転換しようとしています。

セキュリティがより企業向けに進化します

この変化に伴い、新たなセキュリティ課題が生じます。共有されたエージェントは、開発者のラップトップ上で動作するものよりも、広範な組織権限で行動する可能性があります。

OpenClaw 2.0 は、これに対してより細粒度の制御機能で応えます。

承認プロセスを、特定の要求、コマンド、セッション、および人物に紐付けることが可能になりました。コマンドの実行権限は、特定の引数や作業ディレクトリに制限できます。スクリプトベースでの実行においては、OpenClaw が実行中のスクリプトが当初レビューされた内容と一致しているかを確認します。

セッションは、読み取り専用、ガード付き、ワークスペース、フルアクセスモードなど、異なる権限レベルで動作可能です。ただし、最高権限レベルは管理者に限定されます。

組織はまた、特定のアイデンティティによって作成されるセッションに対してサンドボックス実行を必須とするオペレーターロールも定義できます。OpenClaw によると、これらの要件は、特権的な実行やホストのオーバーライドを用いて迂回することはできません。必要なサンドボックスが用意できない場合、実行は失敗し、ホストに静かにフォールバックすることはありません。

認証情報には追加の保護が施されます。

OpenClaw のチームスコープ Secret Store は、エージェントが利用可能な通常の環境データから保護された機密情報を明確に区別します。対応するリクエストでは、保護された認証情報をモデルに直接露出させることなく、Gateway でホストされる HTTPS リクエストに差し替えて使用できます。

OpenClaw はまた、1Password や Vault などの外部システムへの参照もサポートしています。

監査機能は、実行アイデンティティ、承認プロセス、セッション内のアクション、および送信メッセージの周辺で強化されました。プラグインのインストール時には、その特定のアーティファクトに関連する能力レビューがトリガーされます。

これらの制御措置は、エージェントを導入する際に企業が必ず直面する問いに答えるものです。「誰がアクションを開始したのか？」「どのエージェントが実行したのか？」「アクセス可能なリソースは何だったのか？」「誰がその操作を承認したのか？」そして、「業務が人間やマシン間で移行した場合、その権限はどうなるのか？」といった疑問です。

一方、NanoClaw は依然としてセキュリティに対して異なるアプローチを採用しています。

OpenClaw の変更点は、オープンソースでありながら企業向けに設計されたライバルである NanoClaw との比較をよりニュアンス豊かにしました。

NanoClaw は、「AI エージェントにはより強力な分離とシンプルなセキュリティ境界が必要だ」という考えを中心に展開された複数のプロジェクトの一つです。そのアーキテクチャでは、OS レベルでのコンテナ化が設計の中核に据えられています。

NanoClaw は Docker コンテナ内でエージェントを実行し、コンテナのアクセス権限を明示的にマウントされたファイルシステムに限定します。また、プロセスは特権を持たないユーザーとして実行されます。セッションやエージェントグループは、自動的にファイルを共有したり会話履歴を共通化したりすることなく、完全に分離した状態で維持できます。

認証情報のアーキテクチャも同じ原則に基づいています。許可された外部へのリクエストは OneCLI の Agent Vault を経由し、認証情報はエージェントコンテナ内部に直接配置するのではなく、ゲートウェイを通じて注入されます。NanoClaw はさらに、オプションの「egress-lockdown モード」を提供します。このモードではエージェントを内部 Docker ネットワーク上に隔離し、許可された外部トラフィックのみをゲートウェイ経由でルーティングします。

OpenClaw 2.0 では、こうした堅牢なモデルの多くの要素が再現可能になりました。Docker や Podman を使用したサンドボックス環境への対応に加え、エージェント単位やセッション単位のサンドボックススコープ設定、読み取り専用または読み書き可能なワークスペースアクセスの柔軟な構成、ロールベースの分離制御、リモート実行ノード、そして使い捨て型のクラウドワーカーもサポートしています。

しかし、決定的な違いは初期状態（スタートポジション）にあります。OpenClaw のドキュメントでは、サンドボックス化や実行承認がデフォルトで無効になっていることが明記されています。つまり、基本設定では信頼できる単一のオペレーターを前提とし、管理者がより強力な制限を設定しない限りホスト上での実行を許可する構成になっています。一方、NanoClaw では分離性がエージェント実行の構造そのものに根付いています。

では、OpenClaw 2.0 は NanoClaw と同等のセキュリティ水準を達成しているのでしょうか？

利用可能な制御機能の面では、以前よりも大幅に改善されました。しかし、デフォルト設定やアーキテクチャの哲学については、まだ変化していません。企業は OpenClaw を本格的に強化された環境として構成することは可能ですが、そのためには意図的な判断が必要です。

1 つのゲートウェイは 1 つの信頼ドメインであるという制約も、大規模組織にとって特に重要です。OpenClaw では、ゲートウェイを単一の信頼ドメインとして扱うべきだとされています。

新たに導入されたマルチユーザー権限機能は、信頼できる利用者間の協働を管理するために設計されています。これは、互いに信頼できないテナント間での厳格な分離を保証するものではありません。

事業部や顧客、あるいは他のセキュリティドメイン間でより強力な分離が必要な組織の場合、OpenClaw では「セル」と呼ばれる個別のゲートウェイインスタンスの使用を推奨しています。これらはそれぞれ独立した状態、認証情報、ワークスペースを持ちます。

これらのセルを管理するための Fleet ツールは、現在も実験段階にあります。

この区別は、OpenClaw を中央集権型のサービスとして検討している企業にとって、非常に重要な意味を持つ可能性があります。

1 つのゲートウェイ内でのロールベースアクセス制御は、信頼できるエンジニアリング部門や内部チームにとっては十分である場合があります。しかし、互いに敵対する可能性がある顧客やユーザーを隔離することを目的としたマルチテナントプラットフォームとは、その性質が異なります。

NanoClaw には独自の設定要件と制限があり、強力なアウトバウンドネットワークのロックダウン機能さえもオプションとなっています。しかし、その小規模なアーキテクチャとコンテナ中心の実行モデルは、より狭いセキュリティ境界を求め、管理しやすくしたい組織にとって魅力的に映るでしょう。

OpenClaw は、より広範な課題への最適化を目指しています。

OpenClaw の最大の強みは、そのコントロールプレーンにあります。

その代償として、製品としての機能の幅が問われます。

NanoClaw は比較的コンパクトなコードベースを重視し、コンテナによる分離を実現します。また、コードやスキルを通じたカスタマイズも可能です。第 2 世代アーキテクチャでは、オーナー、管理者、メンバーという役割をサポートしており、別途用意された監視ダッシュボードによってデプロイ状況の可視化が可能です。

一方、OpenClaw 2.0 ははるかに広範な運用環境の構築を目指しています。

そのコントロール UI では、従業員のインタラクション、ライブ実行、ファイル管理、承認フロー、ターミナルアクセス、コードレビュー、モデルプロバイダーの設定、デバイス連携、共有セッションなど、多様な機能を統合しています。

これにより、OpenClaw は、単にエージェントの実行を安全にするだけでなく、その周囲に使いやすいコントロールプレーンを必要とする企業にとって潜在的な優位性を持っています。

セキュリティチームは分離性を重視します。プラットフォームチームにはデプロイ、認証、モデル設定、監査、ポリシー適用といった要件があります。従業員が実際に使いこなせるインターフェースも不可欠です。管理者は稼働状況を把握できる手段を必要とします。開発者は問題発生時に、基盤となるファイルやツールへのアクセス権限を確保する必要があります。

OpenClaw 2.0 は、一つのシステムを通じて多様なステークホルダーのニーズに応えようとしています。

では、OpenAI の役割はどのようなものなのでしょうか？

OpenClaw によると、今回のリリースには 569 人の新規コントリビューターを含む 933 人が参加し、16,000 件以上のプルリクエストが提出されました。これは同プロジェクトにマージされた過去すべてのプルリクエストの約半数に相当します。

興味深いのは、このリリースを Steinberger 氏の雇用主である OpenAI が公式に共有していない点です。オーストリア出身の開発者である Steinberger 氏は、2026 年 2 月 14 日、エージェントをより広い層へ届けるために OpenAI への加入を発表しました。この動きは翌日、OpenAI の CEO サム・アルトマン氏によって公に確認されています。

しかし、OpenClaw が OpenAI に吸収されたわけではありません。当時 Steinberger 氏は、OpenClaw は財団に移管され「オープンで独立したまま」維持されると述べており、OpenAI はプロジェクトを支援する立場になると明言していました。現在、OpenClaw は独立した非営利団体である OpenClaw Foundation（501(c)(3)）によって管理されており、OpenAI のほかに Microsoft、GitHub、NVIDIA、Atlassian、Tencent などの組織がパートナーとして名を連ねています。

公開されている情報に基づけば、Steinberger 氏が OpenAI に在籍し、同社がプロジェクトに資金や組織面で支援している事実があるにもかかわらず、OpenClaw 2.0 は OpenAI の製品やソフトウェアリリースではなく、あくまで OpenClaw Foundation によるリリースとして理解すべきです。

企業での実用化には設定の重要性が増しています

OpenClaw 2.0 は自律型エージェントに伴うセキュリティリスクを完全に排除するものではなく、その公式ドキュメントでも限界が明記されています。

Secret Store の値は、保存時に暗号化されるわけではなく、ファイルシステムの保護に依存しています。機密情報の置換機能も、すべての実行パスをカバーするわけではありません。生ソケット、コンテナ、リモートノード、プロバイダー固有のハッチなど、一部の実行経路では適用されません。また、マルチユーザー権限はコラボレーション制御であり、敵対的なテナント間の完全な分離を保証するものではありません。

これらの注意点から、OpenClaw 2.0 をデフォルトで安全なエージェントインフラストラクチャと安易に解釈してはなりません。しかし同時に、このプロジェクトを取り巻く議論がどのように変化したかを如実に示しています。もはや単純に「OpenClaw と NanoClaw の対比」ではなく、「コンテナファーストで制約の厳しいシステムである NanoClaw」と、「従業員や管理者にとって大幅に使い勝手の良い環境を提供する、意図的に強化された OpenClaw 展開」を比較することが重要になっています。

攻撃対象領域を最小限に抑え、コンテナファーストでの実行とアーキテクチャの単純さを最優先する組織にとっては、NanoClaw が依然として強力な選択肢です。

OpenClaw は別の賭けに出ています。つまり、企業が機能するためには、ランタイムと職場の両方を担うエージェントプラットフォームが必要だという信念です。

OpenClaw 2.0 は、サンドボックス化、権限管理、保護された機密情報、承認フロー、アイデンティティ管理、監査ログ、隔離デプロイなど、その環境を構築するために必要な基盤機能を数多く提供します。さらに、ターミナルからエージェントを設定することのない従業員でもシステムを利用できるように設計されたブラウザインターフェースも用意されています。

残る注意点として重要なのは、企業がこれらの基本機能を実際の運用ポリシーへと落とし込む必要がある点です。OpenClaw 2.0 は自動的に企業向け製品になるわけではありませんが、導入時のセットアップを格段に容易にし、本格的なエンタープライズ環境での展開を可能にします。

Steinberger氏がOpenClawの開発プロセスについて語った内容が示唆するように、その長期的な野心はさらに大きくなる可能性があります。各従業員に新たなAIアシスタントを与えるのではなく、OpenClawはエージェント自体を共有インフラとして位置づけています。これは人々、モデル、計算リソースが同じ作業領域で協働する永続的なレイヤーなのです。