OpenClaw 2.0の変更点｜共有セッションは境界ではない
「OpenClaw 2.0 が出たらしいけれど、うちのチームで使っていいものなのか」——共有機能が追加されたと聞いて、真っ先にそう考えた方は多いはずです。
結論から言うと、2.0 の目玉である Shared Cloud Sessions（共有セッション）は「一緒に作業するための機能」であって、「人ごとに権限を分けるための機能」ではありません。独立系AIメディアによる 2.0 の分析は、共有セッションの制御がテナント分離でもセキュリティ境界でもないと公式ドキュメントに明記されている、と報じています。ここを取り違えると、チーム導入の設計が最初の一歩から狂います。
株式会社Fyveは、中小企業のAI活用を月額で伴走する立場から、AIエージェントを実際に無人で走らせる運用も自社で抱えています。本記事では 2.0 の変更点を一次情報で整理したうえで、私たちが自分の運用で痛い目を見て学んだ「権限は機能ではなく分割で担保する」という判断基準を添えてお伝えします。
OpenClaw 2.0とは｜2026年8月30日公開、過去最大規模のアップデート
OpenClaw 2.0 は、オープンソースのパーソナルAIエージェント基盤 OpenClaw の大型リリースです。公式ブログでの発表は2026年8月30日、主要な技術メディアが報じたのは翌8月31日でした。バージョン表記としては v2026.8.1 が「OpenClaw 2.0」にあたります。
まず押さえておきたいのは、これが「小さな機能追加の積み重ね」ではないという点です。公式ブログは、このリリースが933人のコントリビューター（うち569人が初参加）によって作られ、16,000件を超えるプルリクエストで構成されていると述べています。
「7週間出さなかった」ことの意味
もうひとつ、開発ペースの数字が示唆的です。公式ブログによれば、OpenClaw はこのリリースの前に230日で106回のリリースを重ねてきました。単純計算で2〜3日に1回のペースです。そのプロジェクトが、2.0 のために約7週間、リリースを止めた。
頻繁に小刻みに出していたチームが意図的に手を止めるのは、通常、内部構造に手を入れていて小刻みに出せないときです。実際、後述するようにセッションの保存形式そのものが変わっています。「バージョン番号が上がっただけ」と読むと、アップグレード時に足をすくわれます。
2.0 の変更点は大きく3つ
細かな変更は膨大ですが、業務で使うかどうかを判断する観点では、次の3点に集約できます。
- ①セットアップの簡素化——すでにPCにあるサブスクリプション・APIキー・ローカルモデルを再利用して初期設定を進める
- ②ブラウザアプリの全面作り直し——会話中心のナビゲーションへ。設定もアプリ内で完結
- ③Shared Cloud Sessions（共有セッション）——チームや家族でセッションに参加・引き継ぎができる
そして、この3つとは別に、アップグレード前に必ず知っておくべき破壊的変更（SQLiteへの移行）があります。順に見ていきます。
変更点①｜セットアップは「すでにあるもの」から始まるようになった
従来、この種のエージェント基盤の初期設定でつまずく最大の原因は、モデルの接続設定でした。どのプロバイダを使うのか、APIキーはどこに入れるのか、キーが間違っていても最初は気づけない——という順序です。
既存のサインインを自動で見つけて再利用する
2.0 のガイド付きセットアップは、この順序を変えました。公式ブログは、初回インストールについて「すでにその人のコンピュータにあるもの、つまり既存の ChatGPT や Claude のサブスクリプション、APIキー、ローカルモデルから始める」と説明しています。
リリースノート側はより具体的で、「ガイド付きセットアップは、検証済みの Codex、ChatGPT、Claude の CLI サインインを再利用できる」と書かれています。つまり、すでに手元の端末でそれらのCLIにログイン済みなら、キーを手で貼り直す工程が消えるということです。
保存する前にモデル接続を検証する
地味ですが実務上は大きいのが検証の順序です。リリースノートには「選択したモデルを保存する前に検証し、接続の準備ができたらWebアプリまたはターミナルへ引き渡す」とあります。
設定を保存してから初回実行で失敗する、という構図がなくなります。私たちが自社の自動実行ジョブを組むときも、「設定した」と「実際に通った」を必ず別の工程として確認するようにしていますが、それが標準の導線に入ったかたちです。
認証なしのネットワーク公開はブロックされるようになった
セキュリティ面での実質的な改善として、リリースノートに「認証なしで OpenClaw を露出させるネットワークインストールは停止される」という記述があります。加えて macOS では「公開された平文の Gateway プロファイルを拒否する」、LAN/IP 接続では証明書ピンニングを維持、といった記載も並びます。
これは「うっかり社内LANに丸出しで立てる」事故を、製品側が止めにきたという意味です。後述する「境界ではない」という話と矛盾しませんが、混同もしないでください。うっかり露出を止めるのと、人ごとに権限を分けるのは、別の話です。
変更点②｜ブラウザアプリはゼロから作り直された
2.0 では、ブラウザで使うアプリが作り直され、公式ブログの表現では「あなたの Claw との会話に直接開く」ものになりました。設定や構成の続きもアプリ内で進められます。
会話中心のナビゲーション
リリースノートは、ナビゲーションが会話中心に再設計されたとし、「サイドバーに会話、中央に今作業している会話」という構成を示しています。また「新しい会話を始めることは、空のチャットではなく、きちんとしたセットアップ画面になった」とも書かれています。
これは細かい話に見えて、業務利用では効きます。エージェントに何かをやらせるとき、「何を渡すか」を決める場所が空白のチャット欄しかない状態は、そのまま指示の質のばらつきになるからです。開始画面が設問形式になっていると、渡す前提が揃います。
セッションの検索・グループ化・一括操作
セッション管理には、グループ化・検索・ステータス追跡・一括操作が入りました。エージェントを日常的に動かすと、セッションは驚くほど早く溜まります。「先週どのセッションで何をやらせたか」を後から引けるかどうかは、記録という意味でも重要です。
モバイルは「Full か Limited か」を明示するようになった
iOS / Android のセットアップは、リリースノートによればQRコードとセットアップコードによるペアリングが先になりました。さらに、Full アクセスと Limited アクセスのどちらなのかを明示的に表示し、権限は一括ではなく個別に要求する設計に変わっています。
権限をまとめて要求されると、人は中身を読まずに承認します。個別に、しかも今どちらのモードなのかを見せながら聞くのは、真っ当な改善です。
変更点③｜Shared Cloud Sessions（共有セッション）で何ができるのか
2.0 の目玉が、共有セッションです。公式ブログはこれをOpenClaw を「マルチプレイヤー」体験にしたと表現しています。
できるようになったこと
- 進行中のセッションに他のメンバーが途中から参加し、続きから作業できる
- 作業を文脈ごと引き継ぐ（何をやっていたかを説明し直さなくていい）
- コンテンツや自動化をリアルタイムで共同編集する
実行場所も選べます。報道によれば、セッションはローカル、ペアリング済みのハードウェア、使い捨てのクラウドマシンのいずれかで走らせられます。「ノートPCを閉じたら止まる」を避けたい用途では、クラウド実行が現実的な選択肢になります。
家族・小規模チームには素直に便利
用途がはっきりしていて、参加者全員が同じ権限で構わない場面——たとえば個人事業主と外注パートナーの2人、あるいは家族——では、共有セッションは素直に便利です。引き継ぎのたびに経緯を説明し直すコストは、実際にやってみるとかなり大きいからです。
問題は、これを「社内の複数部署で1つ立てて使い回す」という発想に拡張したときに起きます。
最重要｜共有セッションはセキュリティ境界ではない
ここが本記事で最も伝えたい点です。共有セッションの制御は、テナント分離でもセキュリティ境界でもありません。これは批判記事の解釈ではなく、公式ドキュメントの記述としてそう明記されている、と報じられています。
「1つの Gateway は1つの信頼ドメイン」
この設計を最も端的に言い表しているのが、「1つの Gateway は1つの信頼ドメイン（One Gateway is one trust domain）」という原則と、「テナントごとに別の Gateway が必要（tenants need separate Gateways）」という帰結です。
共有セッションの各種制御は1つのインストール内で働くものであり、「共有セッション機能によって、1つのインストールがマルチテナントのサービスになるわけではない」と説明されています。
言い換えると、こういうことです。同じ Gateway に相乗りしている時点で、そこにいる全員は同じ信頼レベルにいる。共有セッションのUIで「この人を招く／招かない」を操作できても、それは信頼の線引きではなく、あくまで作業の割り当てです。
エージェントは資格情報を持ち、メッセージを読み、コマンドを実行する
なぜそれが危ないのかは、エージェントというものの性質を言葉にすると分かります。「エージェントは資格情報を保持でき、メッセージを読み、コマンドを実行できる」——これがリスクの本体です。
2.0 では新しい権限モードや資格情報の保護も入っています。それでも、上の性質そのものは変わりません。権限モードが増えることと、信頼ドメインが分かれることは、別の次元の話です。
サンドボックスは既定でオフ
さらに実務上重要なのが、「サンドボックスは既定でオフであり、堅牢な構成は新しいマルチプレイヤー制御の外側にある設定に依存したままになる」という指摘です。
つまり、2.0 にアップグレードしても、隔離の設定を自分でやっていなければ隔離されていない。新機能の画面には出てこない場所に、その責任が残っています。
関連する批判として、OpenClaw の分離は「OSレベルの本当の隔離ではなく、アプリケーションレベル（許可リストやペアリングコード）であり、すべてが共有メモリを持つ1つの Node プロセスの中で動いている」という指摘も出ています。この見方に立てば、アプリ内の設定でいくら細かく制御しても、越えられない天井があることになります。
アップグレード前に必ず｜セッション保存が SQLite へ移行した
機能の話とは別に、運用上いちばん事故りやすいのがここです。リリースノートは「このリリースは、セッションとトランスクリプトの保存方法を SQLite へ移行することで変更する」と明記しています。
バックアップは「取った」ではなく「戻せる」を確認する
リリースノートは、アップグレード前に検証済みのバックアップを作るよう求めています。ここで言う「検証済み」は、コピーを取っただけでは足りないという意味です。
私たちが自動実行の仕組みを組むときに徹底しているのも同じで、バックアップは「取れているか」ではなく「戻せるか」を一度試すまで、取れていないものとして扱います。復元を試していないバックアップは、事故が起きた瞬間に初めて壊れていたと分かる、という性質があるからです。
ダウングレードは片道に近い
より注意が要るのは巻き戻しです。リリースノートには「ファイルベースの古いリリースへダウングレードする前に、現行のCLIでアーカイブされた旧トランスクリプトの成果物を復元すること。移行後に作成されたセッションは、古いリリースでは表示されない」とあります。
読み替えると、「上げてから数日使い、やっぱり戻す」をやると、その数日分のセッションは旧バージョンから見えなくなるということです。試すなら、本番の作業ログを載せる前に試すのが安全です。
アップグレード手順の最小形
- 現行バージョンでバックアップを取り、別環境で復元まで通す
- 本番ではない環境で 2.0 に上げ、普段使っているセッションが読めるかを確認する
- 共有セッションを使う予定があるなら、誰と同じ Gateway に相乗りするのかを先に決める
- サンドボックス・ネットワーク公開の設定を明示的に見に行く（既定に任せない）
- 問題がなければ本番を上げる。上げた後は巻き戻しにくい前提で運用する
私たちの運用から言えること｜権限は「機能」ではなく「分割」で担保する
ここからは、一次情報の整理ではなく、私たち自身がAIエージェントや自動処理を業務で走らせてきた中での判断です。結論だけ先に言えば、権限を分けたいなら、設定で分けるのではなく、器そのものを分けるのが確実だという一点に尽きます。
「立場ごとに権限を分ける」ためにアプリを2つに割った話
以前、複数の立場の人が同じデータベースを触る現場向けに業務システムを作ったことがあります。事務を担当する人と、現場で日々の記録を入力する人が、同じデータに別の目的でアクセスする構造でした。
当初は1つのアプリの中で、ログインした人の役割によって表示・操作を出し分ける設計を考えました。一般的なやり方です。しかし検討を進めるほど、「出し分けの条件を1つ書き忘れただけで、見えてはいけないものが見える」というリスクが消えないことが分かってきました。
最終的に採ったのは、管理側のアプリと、現場側のアプリを別々に作るという設計です。同じ機能が2つに分かれるので、作る手間は増えます。それでも、「間違えたときに何が起きるか」の最悪値が段違いに小さい。分けてしまえば、条件式の書き忘れで越境することが構造的に起こりません。
OpenClaw の「テナントごとに別の Gateway が必要」という結論は、これとまったく同じ形をしています。別の道具、別の文脈で、同じ場所に着地しているわけです。だから私は、この原則を製品の弱点というよりエージェント基盤に共通する制約として受け取っています。
無人で走らせるものには、人ではなく機械のゲートを置く
もうひとつ、自社の自動化で徹底していることがあります。人の目を通さずに外へ出るものには、必ず機械的な検査工程を挟むという運用です。
具体的には、成果物が生成された時点で自動的にチェックが走り、あらかじめ定義した基準（表記ルール、クライアントが特定できる情報が混じっていないか、数字の裏取りができているか）と照合されます。基準を満たさなければ、その成果物は外に出ません。
この設計にしている理由は単純で、「毎回ちゃんと確認する」という運用は必ず破綻するからです。忙しい日、疲れている日、うまくいっている日が続いた後の油断——人間側の確認は、条件が悪くなるほど先に緩みます。緩まないのは機械だけです。
共有セッションでチームにエージェントを開放するなら、同じ問いを先に立ててください。「誰かが確認する」ではなく「何が自動的に止めるのか」。止めるものが無いなら、それは運用ルールがあるのではなく、運用ルールを書いた紙があるだけです。
「手元で動いた」は、無人で動く保証にならない
これは苦い経験です。自動実行の仕組みを組んだとき、手元のターミナルからは完璧に動いたのに、OSのスケジューラ経由で無人実行させた途端に固まる、という現象に当たったことがあります。
原因は権限でした。スケジューラ経由で起動されたプロセスには、対話的に立ち上げたときと同じファイルアクセス権限が与えられておらず、特定の場所に置いたデータを読もうとした瞬間に処理が返ってこなくなっていたのです。最終的にはデータの置き場所そのものを、権限の制約を受けない場所へ移すことで解決しました。
ここから得た教訓は、「対話的に試して成功したこと」は、無人実行の動作保証にはならないという一点です。実行主体が変われば権限が変わり、権限が変われば結果が変わります。
共有セッションを「使い捨てのクラウドマシン」で走らせる構成は、まさにこの罠のある領域です。手元では通っている前提が、クラウド側では成り立っていない可能性を、最初から疑ってかかるべきです。
導入判断チェックリスト｜今すぐ上げてよいか、待つべきか
ここまでを、判断に使える形にまとめます。
観点 | 上げてよい | 待った方がいい |
|---|---|---|
使う人の範囲 | 自分ひとり、または全員が同じ権限で構わない少人数 | 部署・役職で見せてよい情報が違う |
扱うデータ | 公開情報・自分の作業ログ中心 | 顧客情報・人事情報・未公開の経営数字が混じる |
隔離の設定 | サンドボックス設定を自分で入れられる | 既定のまま使うことになる（既定はオフ） |
巻き戻し | 検証環境で先に試せる | 本番しかない／バックアップの復元を試していない |
共有の目的 | 作業の引き継ぎを楽にしたい | 権限を分けたい（それは共有セッションの役割ではない） |
「待った方がいい」に1つでも当たったら
そのときの正解は「導入しない」ではありません。範囲を狭めて導入するです。
たとえば、機密性の低い業務（社内向けの調べ物、下書きの生成、定型的な整形作業）だけを対象に1つ立て、顧客データに触れる業務からは物理的に切り離す。分けるコストは確かに掛かりますが、先ほどのアプリを2つに割った判断と同じで、間違えたときの最悪値が小さくなるという一点で回収できます。
中小企業の現実的な立ち位置
正直に書くと、専任の情報システム担当がいない規模の会社が、OpenClaw を業務の中心に据えるのはまだ早いと私は考えています。理由は 2.0 の出来ではなく、隔離の設定が既定から外れた場所にあるという構造そのものにあります。設定を「自分でやる」前提の道具は、やれる人がいる組織でしか安全になりません。
一方で、個人や小さなチームが、自分の作業を任せる用途で触っておく価値は十分にあります。エージェントに何をどこまで任せられるかという感覚は、記事を読むだけでは身につかないからです。
この線引きについては、OpenClaw そのものの成り立ちとリスクを整理した記事も併せて参照してください。
基盤としての位置づけや、Claude Code との設計思想の違いはこちらで扱っています。
他のエージェント基盤と迷っている段階であれば、選定軸を整理した比較記事が近道です。
Hermes Agent vs OpenClaw 徹底比較｜違い・使い分け・どっちを選ぶべきか実務者が解説【2026年版】
よくある誤解を3つ整理する
誤解1「共有セッションがあるから、チームで安全に使える」
逆です。共有セッションは同じ信頼ドメインの中で作業を分け合う機能であって、信頼ドメインを分ける機能ではありません。チームで安全に使いたいなら、分けるべきは Gateway です。
誤解2「2.0 でセキュリティが強化されたから、設定は既定のままでいい」
認証なしのネットワーク公開が止められたり、平文プロファイルが拒否されたりと、「うっかり事故」を減らす改善は確かに入っています。しかしサンドボックスは既定でオフのままです。強化された部分と、既定のままでは効かない部分を、分けて把握してください。
誤解3「バージョンが上がっただけなので、そのまま上げればいい」
セッションとトランスクリプトの保存先が SQLite に変わる破壊的変更を含みます。巻き戻すつもりなら、上げる前に手順を確認してください。
まとめ｜2.0 の評価は「何のために使うか」で割れる
OpenClaw 2.0 は、933人・16,000超のプルリクエストという規模が示すとおり、コミュニティの総力を投じた本気のリリースです。セットアップの摩擦は明確に減り、ブラウザアプリは実用的になり、共有セッションによって作業の引き継ぎという長年の面倒が解消されました。個人と小規模チームにとっては、素直に良い更新です。
同時に、企業導入という観点では評価が割れます。共有セッションはセキュリティ境界ではなく、サンドボックスは既定でオフで、テナントを分けたければ Gateway ごと分ける必要がある。この3点を理解したうえで範囲を絞れるかどうかが、そのまま導入可否の分かれ目になります。
私たちの経験から言えるのは、権限の話を設定画面で解こうとすると、たいてい失敗するということです。アプリを2つに割った判断も、無人実行に機械のゲートを置いた判断も、突き詰めれば「間違えても越境できない形にしておく」という同じ発想でした。OpenClaw の「Gateway を分けよ」という原則は、その発想と綺麗に一致します。
自社でどこまで任せられるか、どこから分けるべきかの線引きに迷ったときは、私たちの専属AI活用顧問サービスで、業務の棚卸しから一緒に整理しています。道具を選ぶ前に、任せる範囲を決めるほうが先です。
参照した一次情報
- OpenClaw 公式ブログ「OpenClaw 2.0」（2026年8月30日）——コントリビューター数・PR数・セットアップ方針・共有セッションの位置づけ
- OpenClaw 公式リリースノート v2026.8.1 ——SQLite移行・ガイド付きセットアップ・ブラウザUI・モバイルのアクセスモード・ネットワーク認証
- 独立系AIメディアによる 2.0 の分析記事（2026年8月30日）——「1つの Gateway は1つの信頼ドメイン」「サンドボックスは既定でオフ」
本記事の内容は2026年9月1日時点の公開情報に基づきます。オープンソースプロジェクトは変更が速いため、実際に導入する際は最新のリリースノートを確認してください。
AIを使う会社と、使わない会社。
その差は、開き始めています。
ここ数年でAIは急速に進化し、正しく導入できている企業とそうでない企業とでは、業務効率や人件費に大きな差が生まれ始めています。「AI導入に興味はあるが、実際に何ができて、どこから手をつければいいか分からない」——そんな方は、まずこの無料プレゼントに目を通してみてください。
