OpenClaw 2.0（v2026.8.1）は、2026年8月31日に発表された史上最大規模のリリースです。派手な新機能を並べるのではなく、常時稼働するAIエージェント基盤の土台そのものを作り直したのが特徴でした。この記事では、Control UIの起動高速化、CPUスケール型の同時実行、そしてセッションとトランスクリプトのSQLite移行という三本柱を、実際に基盤を運用するSREやインフラエンジニアの視点で掘り下げます。数字の背景にある計測条件や、見落としがちなダウングレードの注意点まで踏み込みます。

7週間の開発停止が示すもの 基盤強化に振り切ったリリース

まず規模から確認します。v2026.8.1は933人のコントリビューターが関わり、うち569人が初参加でした。マージ済みのプルリクエストは16,000件を超え、これはリポジトリのマージ履歴のおよそ半分に相当します。数字だけでも異例のボリュームですが、注目すべきはリリースの進め方です。

OpenClawはこれまで、直近230日間で106回という非常に高頻度なリリース運用を続けてきました。ところが今回はそのペースをあえて崩し、およそ7週間にわたって新規リリースを止め、基盤の作り直しに時間を充てています。高頻度デリバリを是とするプロダクトが、あえて手を止めて足回りを固め直したという事実は、運用者にとって重要なシグナルです。日々の機能追加よりも、起動・並列・永続化といった土台の信頼性を優先したという設計思想の表れだと読み取れます。

SREの立場からは、こうした基盤リリースはアップグレード計画の優先度を一段引き上げるべき対象です。機能差分が小さく見えても、内部のデータ保存方式や並列制御が変わっている場合、運用手順やキャパシティ前提が静かに変化しているからです。

Control UIの起動が575msへ 計測条件と運用上の読み方

今回のパフォーマンス改善で最も分かりやすいのが起動時間です。Gatewayに接続する操作画面であるControl UIが刷新され、起動時間が約1.6秒から575ミリ秒へと短縮されました。あわせて、起動時のJavaScriptリクエスト数も140から45へと大きく減っています。体感で三倍近い高速化であり、頻繁に画面を開き直す運用ではストレスの軽減が期待できます。

ただし、この数字はそのまま本番環境の保証値として受け取るべきではありません。公開情報によれば、これらの値はモックしたGatewayに対して50ミリ秒のHTTP/1.1レイテンシを与えた、default-chatを想定したテストハーネス上のベンチマークです。つまり理想化された計測条件下での改善幅であり、実際のネットワーク遅延や同時接続数、ブラウザ環境によって再現される値は変わります。

とはいえ、JSリクエスト数が140から45へ減っているという事実は運用にとって本質的です。往復回数そのものが減っているため、レイテンシの大きい環境ほど相対的な恩恵は大きくなる傾向があります。SREとしては、公表値をうのみにせず、自組織の代表的なネットワーク条件で起動時間を計測し直し、改善の効きどころを見極めるのが実務的な向き合い方です。

CPUスケール型の同時実行がキャパシティ設計を変える

次に効いてくるのが同時実行の扱いです。OpenClaw 2.0では、デフォルトのトップレベル・エージェント同時実行数が、利用可能なCPU並列度から自動的に算出されるようになりました。値は8並列から16並列の範囲に収まるよう制限されます。一般的なハードウェアであれば、明示的なチューニングなしに8から16の並列実行が得られる計算です。

これはキャパシティ設計の前提を変えます。従来のように固定値を手で設定していた場合、マシンを増強しても並列度が追随しないという取りこぼしが起きがちでした。CPU連動になったことで、コア数の多いホストに載せ替えれば同時実行も自然に増えます。逆に言えば、想定より並列度が上がることでメモリやAPIレート制限に先に頭打ちが来る可能性があるため、上限16という天井を意識したリソース見積もりが必要です。

あわせて、新規のCLIインストールは Node 22.22.2 を採用しています。ランタイムのバージョン差は再現性トラブルの温床になりやすいので、既存ホストとの整合を取っておくと安全です。エージェントを常時多重で回す基盤では、この並列度の自動化とランタイム更新を前提に、監視のしきい値を引き直しておくことをおすすめします。

SQLite移行と信頼性強化パスの中身

今回のリリースで最も運用インパクトが大きいのが、セッションとトランスクリプトの保存先を、従来のファイルベースからSQLiteへ移行した点です。多数のセッションを長期間ため込む常時稼働基盤では、ファイル散在によるI/O効率やメタデータ管理の限界が課題になりがちでした。単一のデータベースへ集約することで、検索性や一貫性の面で扱いやすくなります。

移行と同時に、大規模な信頼性強化パスが入っている点が見逃せません。具体的には、次のような多層の保護機構が追加されています。

• スナップショット検証を独立した別プロセスで実行し、検証処理が本体の動作に巻き込まれないよう分離している
• 破損が確定したデータの隔離判定を専用ストアに保持する、いわゆる corruption quarantine により、破損検知後にさらなる破損が波及するのを防ぐ
• write-ahead-log のスプリットブレイン的なクリーンアップがデータベースを壊さないよう対策している
• 正準テーブルや制約、インデックス、トリガーが欠落したり定義がずれた現行版データベースを、compaction の前段で拒否するスキーマ検証を備える

これらはいずれも、SQLiteを本番の永続層として使う際に現場が実際に踏みがちな地雷を先回りで潰す設計です。とりわけ破損の隔離は、一部の破損が全体のデータ喪失に連鎖するのを止める安全弁として重要で、無停止で回し続ける基盤ほど恩恵が大きくなります。

アップグレードとダウングレードの実務手順

データ保存方式が変わるリリースでは、移行手順そのものが運用リスクになります。OpenClawはこの点にも手当てをしており、アップグレード前に検証可能なバックアップを作成することを公式に推奨しています。ここで使うのが専用のバックアップ機能です。

新しく用意された仕組みでは、グローバルおよびエージェント別のコンパクトなデータベース・スナップショットを、作成・一覧・検証・復元まで一貫して扱えます。実行コマンドは次のとおりです。

openclaw backup sqlite

単なるコピーではなく検証可能なバックアップである点が肝心で、いざ復元というときに中身が壊れていないことを確認できます。アップグレードのランブックには、この検証済みバックアップの取得を必須ステップとして組み込むべきです。

さらに注意したいのがダウングレードです。SQLite移行前の旧リリースへ戻す場合は、現行のCLIを使ってアーカイブ済みのレガシートランスクリプトを先に復元してから戻す必要があります。この順番を守らないと、過去の記録が旧版から見えなくなります。加えて、移行後に作成したセッションは旧リリースには一切表示されません。切り戻しを安全網と考えている運用では、この非対称性を事前に周知し、切り戻し可能な範囲を正しく認識しておくことが欠かせません。

破壊的変更3件とオンボーディング刷新

基盤リリースにもかかわらず、破壊的変更はわずか3件に抑えられています。バンドルされていたOpenProseプラグインと関連コマンドの廃止、codex系のモデル参照を openai 系へ統合する変更、そしてプラグインSDKのサブパスインポートを集約する非推奨化の3点です。いずれも影響範囲は限定的で、しかも次の修復コマンドで機械的に追従できます。

openclaw doctor --fix

破壊的変更を最小限に抑えつつ自動修復まで用意している点は、アップグレードの心理的ハードルを下げます。移行作業の大半を手作業でなくツールに任せられるため、検証済みバックアップと組み合わせれば、切り戻し前提の安全なアップグレードが現実的になります。

最後にオンボーディングです。初回セットアップが刷新され、既存のClaudeやChatGPTのサインイン、APIキー、対応プロバイダ自身のサインイン、条件を満たすローカルモデルなどを自動的に検出して再利用できるようになりました。しかも、選んだモデルと資格情報が実際に応答できることを確認してから保持する設計です。新しいホストへエージェント基盤を横展開する際の初期構築コストが下がるため、スケールアウトを前提とした運用と相性が良い改善だといえます。

総じてOpenClaw 2.0は、派手さよりも土台の堅牢さを選んだリリースです。起動高速化の数字は計測条件を踏まえて冷静に読み解きつつ、SQLite移行と信頼性強化、そして自動修復付きの安全な移行手順を活かすことが、常時稼働基盤を預かるSREにとっての最短の恩恵の受け取り方になります。