朝、AIに昨日の続きから仕事を任せようとしたら、会話一覧が開かない。検索も動かない。最悪なのは、画面に「破損」と出ても、会話本体が壊れたのか、検索用の索引だけが壊れたのか分からない状態です。
Hermes Agent v0.21.2（リリースタグ v2026.9.11）は、会話や実行履歴を保存するstate.dbの扱いを集中的に修正しました。2026年9月11日公開の公式リリースでは、複数プロセスによる書き込み、WALの扱い、壊れた1行、複数プロフィール間の分離などが対象になっています。
機能追加の一覧として読むより、「社内AIの記録をどこまで業務データとして扱うか」を決める材料になります。AIが止まっても、誰が何を頼み、どこまで実行し、何を返したかが残れば復旧できます。そこが曖昧なまま自動化だけ増やすと、障害時に人が会話を掘り直すことになります。
何が直ったのか
公式リリースが挙げる問題の一つは、同じSQLiteデータベースを複数の処理が扱う時の競合です。プロフィール用Gateway、ダッシュボード、cronのライフサイクル確認、doctor --fixなどが、それぞれ書き込み可能な接続やチェックポイントを持つと、動作中のデータベースへ余計な圧力がかかります。
v0.21.2では、ホストされたルームの状態をshared-state.dbへ分離し、ダッシュボードは最初に読み取り専用で開くようになりました。cron側も追跡された接続管理を通り、doctor --fixは安全を確認できないチェックポイントを拒否します。何でも一つのファイルに集めるのではなく、用途と書き込み主体を分けた形です。
SQLiteの公式文書でも、WALモードでは読み取りと書き込みを並行できますが、書き込み側は同時に一つです。チェックポイントはWALの内容を本体へ戻す処理なので、実行時期と接続状態を無視できません。Hermes固有の修正ではありますが、考え方はSQLiteを使う業務システムにも通じます。
「検索が壊れた」と「記録が壊れた」を分ける
今回の修正で実務的なのは、全文検索（FTS）の不具合をデータベース全体の破損として扱わなくなった点です。FTS索引だけに問題がある場合は検索機能を縮退させ、索引を後で再構築します。会話の保存領域まで止める扱いにはしません。
この区別は運用手順にも入れておくべきです。検索結果が出ない時に、すぐ「履歴が消えた」と判断すると、担当者が不要な復元や再作成へ走ります。反対に、本体の構造破損を索引の問題だと思い込めば、状態を悪化させる操作を続けかねません。
障害表示には、少なくとも次の3段階が必要です。
- 検索索引の不調。会話本体は読める
- 一部レコードの異常。該当行を飛ばせば一覧や書き出しは続けられる
- データベース本体の構造異常。書き込みを止め、退避と診断を優先する
v0.21.2は、文字列になった日時や極端なepoch値など、壊れた1行のためにsessions list、export、insights全体が落ちる問題も修正しています。不正な行には警告を出し、他の正常な記録は読み続けます。全件成功か全件失敗かではなく、救える記録を先に救う設計です。
複数プロフィールでは「別の人の履歴を読まない」が先
複数プロフィールを同じGatewayで動かす環境では、可用性だけでなく分離も必要です。公式リリースでは、Desktop起動時の競合で別プロフィールのstate.dbへ結び付く問題や、裸のセッションIDで検索した時に全プロフィールを走査し、別プロフィールの履歴を返す問題が修正されました。
さらに、許可リスト、接続先、Vault内の秘密情報、添付ファイル、認証情報が既定プロフィールから別プロフィールへ流れないよう、複数の境界修正が入っています。会社でプロフィールを部署、顧客、担当者ごとに分けるなら、画面上で分かれているだけでは足りません。保存先、検索範囲、認証情報、添付可能なパスまで同じ境界でそろえる必要があります。
私なら、プロフィール追加時に次の隔離テストを通します。
- Aプロフィールで作った固有語を、Bプロフィールの会話検索から探す
- Aだけに登録した接続先や秘密情報が、BのMCPサーバーへ渡らないことを確認する
- BからAの
.env、認証ファイル、データベースを添付しようとして拒否されることを確認する - 同じ形式のセッションIDを使い、指定プロフィール以外を検索しないことを確認する
一つでも通らないなら、顧客データを入れる段階ではありません。便利な機能を止める必要はありませんが、プロフィールを分けた意味が実データでも保たれるまで、対象を社内の低機密業務に絞ります。
更新前後で確認する項目
今回の更新を入れるなら、バージョン番号だけ確認して終わらせない方が安全です。導入前にstate.dbと関連するWAL、設定ファイルの保存場所を特定し、Hermesを止めずにファイルだけコピーする運用になっていないか確認します。動作中のSQLiteは本体ファイルだけでは現在の状態を復元できない場合があります。
既に0.21.0または0.21.1で不調が出ている環境について、公式リリースは先にhermes doctorを実行するよう案内しています。構造破損とFTS索引の問題を分け、再構築で足りない場合は、プロフィールを固定したhermes sessions recover --inspect-onlyへ案内する設計です。検査だけの段階を挟み、いきなり復元処理を書き込まない点は妥当です。
更新後は、次の5項目を小さな受け入れテストにします。
- Gateway稼働中に会話一覧を開き、待ち時間とロック警告を記録する
- 新しい会話を保存し、再起動後に同じ本文を読めるか確認する
- 会話検索、一覧、exportを実行し、一部の異常で全体が止まらないかを見る
- 複数プロフィール間の検索と添付の隔離を試す
- バックアップから別の検証場所へ復元し、会話件数と直近記録を照合する
見る数字は、単なる起動成功ではありません。会話一覧の表示時間、ロック警告件数、復旧に使った人の時間、欠落したセッション数を更新前後で比べます。正常系だけでなく、検索索引の不調や不正な1行を含む状態でも業務が続くかを見ます。
履歴を戻せる状態にした後は、認証更新が重なった時にも処理が止まらないかを確認します。続くHermes Agent v0.21.3の認証・セッション検査では、Desktop復帰、認証遅延、定時処理を含む受け入れ手順を整理しました。
今回の判断
Hermes Agentを複数プロフィール、cron、ダッシュボードと組み合わせて常時運用しているなら、v0.21.2は更新候補です。特に0.21.0以降でstate.dbのロック、破損表示、会話一覧の停止が出た環境は、公式手順に沿って診断してから更新する理由があります。
ただし、更新だけでバックアップ設計が完成するわけではありません。今回の修正は競合や誤判定を減らしますが、ストレージ障害、誤削除、運用ミスまで消すものではないからです。最初の一手は、state.dbの場所を確認し、会話1件を別環境へ戻せるか試すこと。復元を試していないバックアップは、まだ保険として数えない方がいいと思います。
一次情報
- Hermes Agent v2026.9.11 公式リリース
- SQLite公式文書：Write-Ahead Logging
- SQLite公式文書：File Locking And Concurrency
確認日：2026年9月12日。Hermes固有の変更内容とコマンドは公式リリースを基準にしています。SQLiteの説明はSQLite公式文書を参照しました。受け入れテストと運用判断はmonobloによる提案です。