画面を二つ開いただけなのに、裏側でAIの実行基盤まで二つ立ち上がる。常時稼働のAIでは、これは小さな不具合ではありません。同じ定時処理が重複したり、片方だけ古い状態を見たり、停止したはずの処理が別のプロセスに残ったりするからです。
Hermes Agent v0.21.4（タグ名 v2026.9.21）は、1台のホストで動くバックエンドを一つに絞る仕組みを追加しました。Desktopや別プロフィールから接続しても、新しいバックエンドを勝手に起動せず、すでに動いているものへ接続します。
派手な新機能ではありません。ただ、AIをチャットではなく、定時処理や社内ツール連携を担う作業員として使う会社には効きます。今回見るべき点は「AIが何をできるようになったか」より、「同じ仕事を二重に走らせない土台ができたか」です。
何が変わったのか
公式リリースはv0.21.4をパッチ版と位置づけています。v0.21.3以降にマージされた約1,800件の変更を、Dockerイメージやホスティング環境の利用者が参照できる安定タグへまとめた版です。整理された全リリースノートはv0.22.0へ持ち越されています。
その中で、業務運用への影響が分かりやすいのが「1ホスト1バックエンド」です。実装元のPull Request #117999では、従来はプロフィールごとにロックを持てたため、複数プロフィールで別々のGatewayを起動できたと説明されています。さらに、hermes serveにはホスト全体で二重起動を止める仕組みがありませんでした。
更新後は、ホスト単位のロックと接続先を知らせる記録を使います。二つ目のhermes serveは別ポートで新しい基盤を立ち上げるのではなく、先に動いている基盤へ接続します。記録にはプロセスIDだけでなく、プロセスの作成時刻、ポート、通信仕様の版、認証情報の指紋、提供中のプロフィール集合が含まれます。
プロセスIDだけで生死を判断しない点も実務的です。OSは終了したプロセスのIDを再利用します。IDが同じでも作成時刻が違えば、前のHermesとは別物です。今回の仕組みはそこまで確認し、古い記録へ誤接続する事故を避けます。
二重起動が業務で困る理由
同じAIが二つ動いても、回答が二つ返るだけなら気づけます。厄介なのは、表から見えにくい仕事です。
- 毎朝のレポートが二重送信される
- 同じ問い合わせを別々の担当AIが処理する
- 片方が更新前、もう片方が更新後の設定で動く
- 停止や再起動の対象を取り違える
- 会話履歴や状態保存を別々の基盤が同時に触る
請求や顧客連絡につながる処理では、1回の重複でも後始末が発生します。送信前承認を入れていても、承認待ちが二つ作られれば、人がどちらを採用したか分からなくなります。
今回の更新は、こうした事故をすべて自動で防ぐものではありません。複数のVPSや別ユーザーでHermesを動かせば、それぞれにバックエンドが存在します。外部のジョブ管理側で同じ処理を二重登録していれば、1ホスト1バックエンドでも重複します。守れる境界は「同じOSユーザーが使う一台のホスト内」です。
小さな会社での使いどころ
一番効果があるのは、担当者がDesktop、ターミナル、Telegramなど複数の入口から同じHermesを使う環境です。入口が増えても、実行基盤は一つ。会話画面ごとに別のAI作業員を増やすのではなく、一人の作業員へ複数の窓口から指示を出す形に近づきます。
もう一つは、プロフィールを分けている運用です。営業用、制作用、社内用などプロフィールを分けても、ホスト上の実行基盤は一つに集約されます。プロフィール間のデータ分離が不要になるわけではありませんが、起動管理の対象は減らせます。
私はこの変更を、便利機能より「重複実行の発生源を一つ減らす修正」と見ます。定時処理を増やす前に、誰が起動し、どの基盤へ接続し、停止時に何を確認するかを決めやすくなりました。
更新後に確認する5項目
本番へ入れる前に、次の順で15分ほど確認します。
- Hermesを通常の方法で起動し、プロセスと待受ポートを記録する。
- 別プロフィールまたはDesktopから二つ目の接続を開始する。
- 新しいバックエンドが増えず、先に動いているものへ接続したことを確認する。
- 二つの入口から別々の短い作業を実行し、正しいプロフィールへ結果が戻るかを見る。
- バックエンドを正常終了して再起動し、古い接続先記録が残らないことを確かめる。
異常終了の確認もできれば入れます。公式PRでは、停止時に接続先記録を削除し、プロセスIDと作成時刻の組み合わせで古い記録を見分ける設計です。正常終了だけ通して終わると、実際の障害時に古い記録へ引っ張られる問題を見落とします。
GOとHOLDの判断
限定GOは、二つ目の入口が既存バックエンドへ接続し、プロフィールごとの会話や設定が混ざらず、再起動後も同じ確認を通せた状態です。まずは社内レポートや下書き生成など、やり直せる仕事から戻します。
HOLDは、バックエンドが二つ増えた、接続先が分からない、プロフィールをまたいで履歴が見える、停止後も古い待受へ接続しようとする、のどれかが出た状態です。外部送信や更新系の定時処理は止めたままにします。
1ホスト1バックエンドは、二重実行対策の全部ではありません。定時処理には個別の実行IDと重複防止、外部送信には承認、更新にはバックアップが要ります。その上で、実行基盤そのものが増殖しないことは、運用を読みやすくする前提になります。
参照元
更新内容の事実は上記の公式リリースとPull Requestで確認しました。業務上の影響、検査手順、GO/HOLD条件はmonobloによる運用提案です。