朝、担当者がAIの管理画面を開く。ログインはできたはずなのに、画面更新を何度か繰り返すとセッションが切れ、もう一度サインインを求められる。1人なら小さな不具合で済みます。複数拠点や在宅勤務で同じAIを動かしている会社では、監視も復旧も止まります。
Nous Researchは2026年9月14日、Hermes Agent v0.21.3を公開しました。中心となる修正は二つです。Remote DesktopやCloudで同時に走った認証更新をまとめて処理し、更新済みトークンの再利用判定でセッション全体が失効する問題を抑えました。もう一つは、長時間動かすプロセスがstate.dbへの書き込みハンドルを重複して持ち続ける問題の修正です。
派手な新機能ではありません。でも、社内AIを「たまに使うチャット」から常時稼働の作業担当へ移すと、こうした地味な故障が運用品質を決めます。今回の記事では、更新情報を機能紹介で終わらせず、認証と状態保存をどう受け入れ検査するかまで整理します。
何が直ったのか
公式リリースによると、問題の一つはリフレッシュトークンの競合です。Desktopがスリープから復帰した時などに複数の更新要求がほぼ同時に発生すると、先に処理された要求がトークンを更新します。後から届いた要求は、すでに使われた古いトークンを送る形になります。認証基盤がこれを不正な再利用と判定すれば、攻撃を防ぐためにセッション全体を無効化することがあります。
v0.21.3では、同じローテーション中のリフレッシュトークンを使う並行要求を一つにまとめます。Cookie経由とDesktopのBearer経由という二つの更新経路が対象です。遅い認証プロバイダーへの照会もイベントループの外へ移され、認証待ちで /api/status が固まりにくくなりました。
この設計には理由があります。IETFのOAuth 2.0 Security Best Current Practice（RFC 9700）は、公開クライアントのリフレッシュトークンについて、送信者制約かローテーションを求めています。盗まれたトークンの再利用を検知する仕組みは必要です。一方、正規クライアント自身が同時更新を起こすと、安全装置が利用者を締め出すこともある。セキュリティを弱めず、正規の競合だけを吸収する実装が要ります。
認証切れは「もう一度ログイン」で片づかない
有人のWebサービスなら、再ログインで仕事を続けられる場面もあります。夜間の集計、定時レポート、問い合わせの一次分類をAIへ委譲している場合は事情が違います。認証が切れたままなら、処理は止まります。止まったことに誰も気づかなければ、翌朝になって初めて欠損が見つかります。
管理画面へ入れるかどうかだけを監視しても足りません。会社側で見るべき対象は、少なくとも次の流れです。
認証更新から業務継続までの確認経路
入力：Desktop復帰、画面更新、定時ジョブ
↓ AI基盤：同時更新を集約し、認証状態を維持
↓ 人間確認：再ログイン要求、401、処理停止を確認
出力：管理画面、定時処理、通知が継続
例外時：自動再試行を打ち切り、担当者へ戻す
記録：更新時刻、失敗回数、停止時間、復旧操作
ポイントは、ログイン成功を合格条件にしないことです。画面更新が重なった時、端末がスリープから戻った時、認証先の応答が遅い時にも、業務処理が続くかを見ます。
state.dbのハンドル漏れも常時稼働で効いてくる
もう一つの修正は、state.dbを扱うプロセスの接続方法です。公式リリースでは、gateway、dashboard/Desktop backend、ACP、CLIの読み取り側をread-onlyで接続し、同じプロセス内の書き込み側はレジストリのハンドルを共有する形に変えたと説明しています。健全な構成なのに N live SessionDB handles という前兆が出る問題を抑えるためです。
データベース接続の重複は、短いデモでは見えにくい故障です。プロセスを数日動かし、画面やCLIを何度も開閉し、複数経路から会話履歴を読むと表面化します。接続数が増え続ければ、ロック競合やリソース枯渇の疑いが強くなります。
ただし、v0.21.3へ上げれば状態保存の心配が消えるわけではありません。前版v0.21.2ではstate.dbの破損耐性やプロフィール分離が改善されました。今回は、そのデータベースを長時間使う時の接続管理が主題です。バックアップ、ストレージ障害、誤削除、復旧手順は別に残ります。更新を災害対策の代わりにしてはいけません。
日本企業でそのまま使えない理由
公式修正は製品側の問題を直します。会社固有の運用までは直しません。
- 誰が認証切れを検知するか決まっていない
- 失敗した定時処理を再実行する条件がない
- 複数プロフィールや複数部署の状態保存先が曖昧
- 更新後の確認が「画面が開いた」で終わっている
- 障害時にAIを止める範囲と、人へ戻す業務が決まっていない
この状態で常時稼働へ進むと、AIが止まったことより、止まった後の戻し先がないことが問題になります。契約、金額、顧客への送信などを扱う業務では、自動再試行を無制限に続けるのも危険です。古い認証状態のまま同じ処理を重ね、重複送信や二重登録を起こす可能性があるからです。
更新後に行う最小テスト
- 対象を一つに絞る。 まずは管理画面と低リスクな定時ジョブ一つを対象にします。
- 正常時の記録を取る。 更新前のログイン時間、再認証回数、定時処理の完了時刻を残します。
- 同時更新を再現する。 Desktop復帰直後に画面を複数回更新し、別タブからも状態を確認します。
- 遅延時を試す。 通信を一時的に遅くした後で復帰し、管理画面と定時処理の両方を確認します。
- 長時間動かす。 24時間以上稼働させ、SessionDBのハンドル数や警告が増え続けないか見ます。
- 失敗時の戻し先を確認する。 認証が切れた時に担当者へ通知され、未処理分を特定できる状態にします。
- 継続か差し戻しかを決める。 二重処理、セッション全失効、履歴混線のどれかが出たら本番範囲を広げません。
合格条件を先に決める
私は、AI基盤の更新を「最新版になった」で完了扱いしません。今回なら、次の条件をすべて満たして初めて限定GOです。
- Desktop復帰と連続更新を5回試して、セッション全失効が0件
- 認証遅延中も状態確認APIが応答し、復帰後に処理を続けられる
- 24時間の試験でSessionDBハンドル数が右肩上がりにならない
- 定時ジョブの欠損と二重実行が0件
- 失敗時に対象処理、時刻、再実行可否を担当者が追える
これはHermes公式の保証値ではなく、社内導入時の受け入れ基準案です。5回や24時間で全条件を証明できるわけでもありません。少量で危険な壊れ方を探し、問題がなければ対象業務と観測期間を広げます。
HOLDにする条件も明確です。セッション失効で無人処理が止まる、同じ処理が二重に走る、プロフィール間で履歴が混ざる、復旧に必要なログが残らない。このどれかがあれば、更新対象を限定し、人の確認へ戻します。
今回の判断
Remote DesktopやCloudを使い、AIを長時間動かしている環境では、v0.21.3は更新候補です。リフレッシュトークンの競合と重複した書き込みハンドルは、稼働時間が長いほど避けにくいからです。
ローカルCLIを短時間だけ使い、Remote Dashboardも常時処理も使っていないなら、緊急度は下がります。公式リリースには、今回の変更窓に多数の追加機能が含まれる一方、詳細説明はv0.22.0へ持ち越すとも書かれています。未説明の変更を含む大型差分として扱い、いきなり全社更新するより検証用プロフィールから入れる方が安全です。
社内AIの安定性は、モデルの賢さだけでは決まりません。認証が切れないこと、履歴を持つ接続が増殖しないこと、止まった時に人へ戻せること。今回は、この三つを試験表に入れる更新です。
一次情報
- Nous Research: Hermes Agent v0.21.3 release（2026年9月14日公開）
- Nous Research: v2026.9.11からv2026.9.14の変更差分
- IETF RFC 9700: Refresh Tokens（OAuth 2.0 Security Best Current Practice）
確認日：2026年9月15日。製品仕様は公式リリース、認証設計の一般原則はRFC 9700を参照しました。受け入れ基準とGO/HOLD条件は、monobloによる運用提案です。