「更新は成功しました」と表示されたのに、翌朝スマホからつながらない。AIツールでは、こうしたズレが起きます。配布物の生成に成功したことと、自社が使う端末・経路まで動くことは別だからです。
OpenClaw 2026.9.4の公式リリースには、その違いがかなり正直に書かれています。安定版の検証は通過。npmやDockerの公開物も照合済み。一方で、TelegramとParallelsの確認は免除され、Androidのネイティブ検証は失敗、Windowsの過去版からの更新にも既知の問題が残りました。
私は、この記録を弱点とは見ません。むしろ社内AIを更新するときに必要な読み方が、そのまま載っています。緑色の「成功」を一つ見るのではなく、何を試し、何を試しておらず、自社がどこに該当するかを分けて判断する。今回はOpenClaw 2026.9.4を題材に、更新の受け入れ条件を組み立てます。
2026.9.4で確認済みの範囲
OpenClawが2026年9月11日（UTC）に公開した2026.9.4は、大きな更新です。プラグインとスキルを探しやすくする画面、過去の会話から再利用可能なスキルを作るSkill Workshop、クラウドセッションの管理、GPT Image 2.5対応、Web UIや更新処理の修正などが含まれます。
公開時の検証記録では、Full stable validationが2回目の試行で通過しました。そこでは15件の性能測定と、10種類の更新元を使ったOpenAIの実応答20件も確認されています。npmのコアパッケージは、認定済みの内容と公開物の一致、署名、provenance、新規インストールまで検査。DockerもGHCRとDocker Hubのmanifest、attestationが認定済み成果物と一致したと記録されています。
ここまで読むと「全部OK」に見えます。ただ、公式記録はそこで終わっていません。
通っていない検査も残っている
同じリリース記録には、TelegramとParallelsの確認は合格ではなく、リリース責任者が明示的に免除したとあります。Androidのネイティブ検証は失敗。Windowsの過去版からの更新とVercel mirrorには注意事項が残り、ClawHubの復旧や一部の配布作業も公開時点では未完了でした。
これは「2026.9.4は使えない」という話ではありません。検証済みの範囲が広くても、自社が依存する一点が未検証なら、その会社にとってはHOLDになり得る、という話です。
たとえばLinux上のGatewayとWeb UIだけを使う会社なら、Androidの失敗は導入を止める理由にならないかもしれません。反対に、現場スタッフがAndroidアプリを業務の入口にしているなら、コアの検証が通っていても即時更新は避けるべきです。Telegramを顧客連絡に使う会社も、免除を「問題なし」と読み替えず、自社で短い送受信試験を足す必要があります。
更新判定を3層に分ける
社内AIの更新確認は、次の3層に分けると判断しやすくなります。
- コア：起動、会話、ツール実行、履歴保存、再起動後の復帰
- 配布経路：npm、Docker、デスクトップアプリなど、自社が実際に入手する成果物
- 利用経路：Web、Telegram、Android、Windowsなど、社員が仕事で触る入口
公式検証は1層目と2層目を広く支えます。3層目は会社ごとに違うため、最後は自社で確かめるしかありません。全機能を網羅する必要はなく、毎日の仕事が通る「細い一本道」を再現します。
経理の問い合わせをTelegramで受け、社内文書を検索し、承認後に返信する運用なら、その一連をテストします。起動だけ、メッセージ送信だけを別々に試しても、権限や履歴の受け渡しで詰まる箇所を見逃します。
GO・HOLD・差し戻しの条件
私なら、更新前に判定をこう固定します。
- GO：自社の主要経路がすべて通り、履歴・権限・送信先に異常がない
- 限定GO：影響を受ける端末や経路を使わず、旧版へ戻す手順も確認済み
- HOLD：自社の主要経路が公式に未検証、免除、または失敗になっている
- 差し戻し：二重送信、別ユーザーの履歴表示、承認前の実行、復旧不能が1件でも出た
平均点は使いません。20項目中19項目が通っても、顧客への二重送信が1件あれば失格です。利便性の不具合と、会社へ損害を出す不具合を同じ1点で数えると判断を誤ります。
判定票には、製品版、更新元の版、OS、利用経路、試験日時、結果、確認者を残します。「前回は大丈夫だった」では再現できません。OpenClawの公式記録が更新元10種類を使って検証したように、どの状態から上げたかも結果の一部です。
失敗時は再実行より先に状態を見る
2026.9.4では、既存設定のインポートが最後の片付けで失敗しても、完了済みの結果を保持する修正が入りました。同じ依頼の再試行では、再インポートせず完了結果を再利用できる場合があります。ただし、その保護はGatewayを再起動すると残らないという制限も公式文書にあります。
この変更から学べるのは、画面にエラーが出たら最初からやり直す、という運用の危うさです。データコピーは完了し、最後の応答だけ失敗しているかもしれません。再実行すると重複や上書きを起こす可能性があります。
エラー時は、まずレポートと保存先を確認。完了済みと未完了を分け、それから再試行します。AIの更新作業では、プロセスの終了コードより、成果物、履歴、公開先を見た方が確実です。
未検証を放置しないための代替策
公式側で確認が免除されている経路は、自社試験で埋めます。Telegramなら、通常メッセージ、画像付き依頼、承認が必要な操作、通信断後の再送を1件ずつ確認します。見るのは回答の内容だけではありません。宛先が正しいか、同じ返答が二重に届かないか、途中まで実行した処理が再接続後にもう一度走らないかを記録します。
Androidを主要経路にしていて公式検証が失敗している場合は、問題が直るまでWebを正式な入口に固定する方法があります。社員へ「当面使わないで」と口頭で伝えるだけでは弱く、手順書とブックマークをWebへ寄せます。代替経路が業務に耐えないならHOLDです。新機能を使うために連絡経路を複雑にすると、更新で得る時間より問い合わせ対応の方が増えます。
限定GOを選ぶ場合は期限も置きます。「後で確認」のまま半年使うのではなく、次の安定版公開時か、30日後の早い方で再判定します。保留理由、避けている経路、代替手段が消えたら、限定GOはその場で無効です。
最初に作る5分の確認票
今日やるなら、自社でOpenClawを使う入口を一つ選びます。Web、Telegram、Androidのように、実際の経路名で書きます。その入口から普段の依頼を1件送り、回答、ツール実行、承認、履歴保存まで通す。最後に旧版へ戻すコマンドとバックアップ場所を確認します。
公式リリースの「passed」「waived」「failed」「pending」を、自社の利用経路と照合するだけでも更新事故は減らせます。公開済みだから入れるのではなく、自社の一本道が通ったから入れる。この順番なら、新機能を追いながら仕事を止めずに済みます。