社内でAIエージェントを動かすなら、「最新版に追いつくこと」と「止めずに運用すること」は分けた方がいい。OpenClawが2026年10月2日に公開した2026.8.35は、そのための選択肢です。
この版は通常の最新系列ではありません。8月末のGatewayを土台に、重大なセキュリティ修正、信頼性向上、新しいモデルへの対応を戻し入れたextended-stableです。OpenClawはこれを現時点のLTS相当と説明しています。公開時点の通常最新版は2026.9.7でした。
私の判断は、売上処理、問い合わせ振り分け、定時レポートなど「止まると人が拾い直す仕事」にはextended-stableを第一候補にする、です。新機能の検証環境は通常のstableに残す。全端末を同じ更新速度にそろえる必要はありません。
古い版への後退ではなく、更新速度を選ぶ仕組み
OpenClawにはstable、extended-stable、beta、devの4つの更新チャネルがあります。公式のリリース方針では、extended-stableは直近2つの完了月のどちらかを基準にしたGateway保守系列です。通常のlatestや開発中のmainを動かさず、別の配布経路で保守されます。
バージョン番号だけを見ると2026.8.35は2026.9.7より古く見えます。ところが、これは単純な旧版ではありません。末尾33以降はextended-stable用の保守番号で、監査した修正を選んで戻し入れます。2026.8.35には、2026.8.34以降の49件のPRが収録されました。
今回の修正範囲は広いです。更新時のプラグイン設定保持、Gatewayの二重起動防止、定期処理の全文回収、子エージェント枠の解放、秘密情報ストアの種別保持、GmailとIMAPの監視復旧、Telegramの進捗表示、遠隔MCPの起動、WebChatの履歴表示などが含まれます。GPT-6.1 Solへの対応も入りました。
目新しい機能の詰め合わせというより、「運用中に消える、詰まる、二重に動く」を減らす版です。この方向は、AIを試す段階より、毎日の仕事を任せ始めた会社に効きます。
中小企業で差が出るのは復旧コスト
自動化の効果は、正常時の速さだけでは決まりません。失敗した後に、誰かがログを読み、途中の出力を探し、同じ処理を流し直す時間まで含めて見ます。
たとえば、毎朝6時に前日の問い合わせをまとめる処理を考えます。途中で応答が切れても、担当者が気づくのが9時なら3時間遅れます。再実行で同じ顧客へ二重送信すれば、時短効果は簡単に消えます。2026.8.35の「定期処理の全文を回収する」「失敗した要求が後から来た指示を食わない」「Gatewayを重複起動させない」といった修正は、この地味な損失を減らすためのものです。
ただし、extended-stableを選べば止まらないわけではありません。修正を選別して戻す以上、通常最新版にしかない機能や修正も残ります。安全性はバージョン名ではなく、自社のバックアップ、監視、停止手順と組み合わせて作ります。
stableとextended-stableを業務で分ける
全員を一斉に切り替えるより、仕事の性質で分けた方が現実的です。
- extended-stable向き：請求前チェック、定時集計、顧客連絡の下書き、受注データの整理など、仕様変更より継続稼働を優先する仕事
- stable向き：新しいモデル、プラグイン、チャネル連携を先に試し、効果と不具合を測る検証環境
- beta・dev向き：壊れたときに自分で切り分けられ、業務データから隔離した開発環境
同じ会社の中に2本の更新レーンを置くイメージです。本番は保守系列、検証は通常最新版。検証で必要性が確認できた機能だけ、本番側の採用時期を決めます。更新のたびに現場全体が実験台になる状態を避けられます。
切り替え前に確認する4点
まず、現在の導入方法を確認します。公式文書ではextended-stableはnpmなどのパッケージ導入向けで、Gitチェックアウトからの切り替えには対応していません。Git版で指定すると、チェックアウトを変えずにパッケージ導入を案内します。
次に、実行前のプレビューです。
openclaw update --channel extended-stable --dry-run --jsonここで有効なチャネル、現在版、対象版、予定される操作、ダウングレード確認の要否を見ます。実行に進む場合は、状態データ、設定、プラグイン一覧、定期処理の定義を戻せる状態にしてから切り替えます。
3つ目は、更新後の動作確認です。単にプロセスが起動したかでは足りません。テスト用の定期処理を1件流し、全文が届くか、同じ処理が二重に走らないか、GmailやTelegramなど実際に使う入口と出口が通るかを確認します。
最後に、戻す条件を先に決めます。更新後24時間で配送漏れ、二重実行、認証切れ、プラグイン消失のどれかが1件でも起きたら切り戻す。正常なら1週間観察し、その後に対象業務を増やします。
更新チャネルは機能ではなく責任分担
最新版を追う担当と、日々の仕事を守る担当は、同じ判断をしません。前者は新機能を早く試したい。後者は昨日と同じ入口から入り、同じ保存先に残り、失敗時に戻せることを優先します。
extended-stableは後者のための手綱です。機能追加を止めるのではなく、検証と本番の時間差を明示します。小さな会社ほど、この時間差が効きます。専任の運用担当がいないからこそ、更新直後の不具合を全員で踏む余裕がありません。
導入は限定GOで十分です。まず1台、止まっても顧客影響が出ない定期処理を1本だけ移す。1週間、配送成功率100%、二重実行0件、手動復旧0回なら次へ進む。この条件を満たさない場合は、stableへ戻すのではなく、原因が更新系列なのか自社設定なのかを切り分けてから決めます。
「問題なく起動した」で合格にしない
更新試験では、成功した1回より、失敗後の戻り方を見ます。処理の途中でネットワークを切る、認証を無効にする、配送先を一時的に止める。そこから再開したとき、出力が欠けず、同じ依頼が二重処理されず、担当者に失敗理由が残るかを確認します。
合格記録には、対象バージョン、実行時刻、入力件数、出力件数、再試行回数、最終状態を残します。チャット画面の「完了しました」だけでは、処理の完了証明になりません。顧客連絡なら送信履歴、集計なら保存先のファイル、定期処理なら実行ログまで照合します。
この検査に毎回何時間もかかるなら、自動化の範囲が広すぎます。入口を1つ、保存先を1つ、承認点を1つに絞り、異常時に人が拾える単位まで小さくしてください。保守系列は、その運用を支える部品です。
AIエージェントの本番運用では、賢さより先に更新経路を分ける。2026.8.35の価値は、新しいモデル対応より、会社の仕事を守る更新レーンが公式に用意されたことにあります。