Hermes Agentを壊れても戻せるようにする。Google Driveへ軽量バックアップを構築

Posted on by

Hermes Agentを使い続けていると、ある不安が出てきます。

このMacが壊れたら、タダシも一緒に消えるのではないか。

Hermes Agentはローカル環境に設定・スキル・メモリを蓄積していくエージェントです。会話を重ねるほど便利になりますが、その分だけ「この環境が失われたら困る」という依存も大きくなります。

そこで今回、Hermes Agentの重要な資産をGoogle Driveへ毎日バックアップする仕組みを作りました。

結論から言えば、通常運用ではセッション履歴を含む13GB級の全量バックアップではなく、エージェントの人格・記憶・能力を構成するファイルだけを保存する軽量バックアップで十分です。APIキーを含む.envはGoogle Driveへ置きません。

何を失うと困るのか

Hermes Agentのデータを、復旧上の重要度で分けました。

データ役割復旧上の重要度
SOUL.mdエージェントの人格・行動原則最重要
MEMORY.md継続的に蓄積した知識最重要
USER.mdユーザーのプロフィール・環境情報最重要
skills/手順・専門知識・自動化能力最重要
config.yamlモデル・ツール・プロバイダー設定重要
.envAPIキー・サービス認証情報バックアップ対象外
state.dbセッション履歴・検索インデックス優先度低

ここで重要なのは、セッション履歴とエージェントの長期的な知識は別物だということです。

過去のチャットを検索できなくなるのは不便です。しかし、重要な判断や環境情報をMEMORY.mdやUSER.mdへ整理しておけば、セッション履歴がなくてもエージェントの運用は再開できます。

一方、SOUL.mdやスキルを失うと、エージェントの性格や能力を作り直す必要があります。こちらの損失のほうが大きいと判断しました。

公式バックアップはある。ただし毎日使うには重い

現在のHermes Agentには、公式のバックアップ・復旧機能があります。

hermes backup -o ~/hermes-backup.zip
hermes import ~/hermes-backup.zip

公式方式の利点は明確です。Hermes自身が対象データをまとめ、公式のhermes importで戻せます。今後のアップデートでバックアップ機能が強化されるなら、最終的には公式方式へ寄せるのが自然です。

ただ、現在の環境で全量バックアップを確認したところ、~/.hermes全体は約13GBありました。そのうち、セッション履歴のstate.dbだけで約845MB、スキルディレクトリは約123MBあります。

この全量を毎日Google Driveへ送るのは、バックアップとしては過剰です。

そこで運用を二つに分けました。

  • 通常運用：重要ファイルだけを毎日保存する
  • システム移行時：公式の全量バックアップを手動で作成する

Macを交換するとき、システムを移行するとき、あるいはHermes Agentを大きくアップデートする前だけ、公式の全量バックアップを作成します。

Google Driveを保存先に選んだ理由

保存先にはGoogle Driveを選びました。

理由は単純です。

  • Mac本体が壊れても別の場所に残る
  • Googleアカウントから確認できる
  • 無料枠でも軽量バックアップなら十分
  • rcloneでコマンドラインからアップロードできる
  • Google Driveのデスクトップアプリに依存しない

今回はHomebrewでrcloneをインストールし、Google Cloudで自分用のOAuth Client IDを作成しました。

brew install rclone

rcloneのGoogle Drive設定には、専用に作成したClient IDとClient Secretを登録しています。アクセス範囲はdrive.fileに限定しました。

drive.fileは、rcloneが作成したファイルとフォルダだけを操作できるスコープです。Google Drive全体を読み書きできる権限よりも、バックアップ用途には適しています。

実際に保存するファイル

今回の軽量バックアップでは、次のファイルをアーカイブします。

SOUL.md
config.yaml
memories/MEMORY.md
memories/USER.md
skills/<category>/<skill>/SKILL.md
skills/<category>/<skill>/references/
skills/<category>/<skill>/assets/
skills/<category>/<skill>/templates/
skills/<category>/<skill>/scripts/

スキルはSKILL.mdだけでなく、参照資料や補助スクリプトも保存します。これを忘れると、スキルの本文は戻っても、実際に使うテンプレートや資料が欠落するためです。

一方で、以下は保存対象から外しました。

  • state.db：セッション履歴
  • Hermes Agent本体のコード
  • Python仮想環境
  • キャッシュ
  • WikiとGitリポジトリ

Hermes本体や仮想環境は再インストールできます。WikiやGitリポジトリは別のバックアップ体系で管理するため、Hermesの軽量バックアップには含めていません。

バックアップスクリプト

実際のスクリプトは~/.hermes/scripts/hermes-backup.shに置きました。

処理の流れは次の通りです。

  1. 一時ディレクトリを作成
  2. SOUL.md、メモリ、設定をコピー
  3. スキルの必要なファイルを相対パスを保ったままコピー
  4. .tar.gzへ圧縮
  5. Google Driveへアップロード
  6. 復旧手順書のWordファイルも独立してアップロード
  7. 60日より古いバックアップを削除

スクリプトの中心部分は次のような形です。

BACKUP_NAME="hermes-$(date +%Y%m%d-%H%M%S)"
BACKUP_FILE="/tmp/$BACKUP_NAME.tar.gz"

# 重要ファイルを一時ディレクトリへコピー
# スキルを相対パス付きで収集
# tar.gz化

tar -czf "$BACKUP_FILE" -C "$TMP_DIR" .
rclone copy "$BACKUP_FILE" "gdrive:hermes-backup/"

このスクリプトはHermesのLLM処理を必要としません。単純なファイル処理なので、Hermesの--no-agentジョブとして実行できます。

毎日03:00に自動実行

バックアップはHermesのcronに登録しました。

名前: hermes-backup
スケジュール: 0 3 * * *
方式: スクリプト直接実行

毎日実行する処理をLLMに依頼する必要はありません。バックアップのように処理内容が固定されているものは、スクリプトを直接実行するほうが確実です。

復旧手順書も一緒に保存する

バックアップで見落としやすいのが、復旧方法そのものです。

圧縮ファイルだけを残しても、数か月後に「どうやって戻すのか」が分からなければ復旧に時間がかかります。

そこで、次のWordファイルを作成しました。

HERMES_RECOVERY_RUNBOOK.docx

この手順書には、以下を記載しています。

  • rcloneの再接続
  • Google Driveからのバックアップ取得
  • .tar.gzの検証と展開
  • hermes doctorによる確認
  • Gatewayの再起動
  • cronの再登録
  • WikiとGitリポジトリの復元
  • 復旧後チェックリスト

このWordファイルは、バックアップアーカイブの中ではなく、Google Drive上に独立したファイルとして保存しています。

gdrive:hermes-backup/HERMES_RECOVERY_RUNBOOK.docx

これにより、アーカイブの中身を展開する前に、復旧手順書だけを先に読めます。

復旧はチャット欄への読み込みではない

ここは誤解しやすいところです。

バックアップの圧縮ファイルをHermes Agentのチャット欄に読み込ませても、それだけで環境は復旧しません。

軽量バックアップの場合は、ターミナルで次のように戻します。

mkdir -p /tmp/hermes-restore
rclone copy gdrive:hermes-backup/ /tmp/hermes-restore/ \\
  --include 'hermes-*.tar.gz'

LATEST=$(find /tmp/hermes-restore -maxdepth 1 \\
  -name 'hermes-*.tar.gz' -print | sort | tail -1)

mv ~/.hermes ~/.hermes.before-restore-$(date +%Y%m%d-%H%M%S)
mkdir -p ~/.hermes
tar -xzf "$LATEST" -C ~/.hermes
# Google Driveとは別に管理しているバックアップから.envを復元
chmod 600 ~/.hermes/.env

hermes doctor
hermes gateway restart

公式の.zipバックアップを使う場合は、公式コマンドを使います。

hermes import ~/hermes-official-YYYYMMDD.zip

つまり、今回の運用では形式によって復旧方法が異なります。

  • 公式.zip：hermes import
  • 日次軽量.tar.gz：ターミナルで展開

.envをバックアップしない理由

当初のバックアップには.envを含めていました。しかし、これは設計として変更しました。

.envにはAPIキーやサービスの認証情報が入っています。Google Driveのアカウント、OAuth token、共有設定のいずれかが破られた場合、バックアップがそのままAPIキーの流出経路になります。

そのため、日次バックアップから.envを除外します。APIキーはGoogle Driveとは別の管理領域で管理し、復旧時に再設定します。

最低限、次の管理は必要です。

  • Googleアカウントに強固なパスワードと二要素認証を設定する
  • rcloneのOAuth tokenを不用意に共有しない
  • Client SecretやAPIキーをチャットや公開リポジトリへ貼らない
  • バックアップの共有設定を確認する
  • 必要になればアーカイブ自体をGPGなどで暗号化する

今回の構成では、rcloneのアクセス範囲をdrive.fileに限定し、さらに日次アーカイブから.envを除外します。APIキーはGoogle Driveとは別の管理領域で管理し、復旧時に再設定します。

バックアップは「保存したら終わり」ではなく、復旧できる状態と秘密情報の管理まで含めて設計する必要があります。

実際の検証結果

実装後、実際にバックアップを実行しました。

ok: hermes-20260720-155604.tar.gz uploaded to gdrive:hermes-backup/

その後、Google Driveからファイルをダウンロードし直し、アーカイブの整合性を確認しています。

  • Google Driveへのアップロード：成功
  • Google Driveからのダウンロード：成功
  • .tar.gzの展開テスト：成功
  • スキルファイル：276件を確認
  • 復旧手順書Wordファイル：正常
  • WordファイルのOOXML検証：成功

バックアップは「スクリプトを書いた」だけでは完了ではありません。実際にアップロードし、ダウンロードし、展開できるところまで確認して初めて運用に入れます。

今回の結論

Hermes Agentのバックアップで大切なのは、全データを盲目的に保存することではありません。

再構築に必要な資産と、なくても運用を再開できるデータを分けることです。

通常運用では、次の軽量バックアップを毎日保存します。

  • 人格：SOUL.md
  • 長期記憶：MEMORY.md、USER.md
  • 能力：skills/
  • 設定：config.yaml
  • 認証：Google Driveとは別管理する.env
  • 手順書：HERMES_RECOVERY_RUNBOOK.docx

公式の全量バックアップは、Macの交換やシステム移行など、必要なときだけ作成します。

Hermes Agentは使い続けるほど、自分専用の環境になっていきます。だからこそ、クラッシュしたときに「またゼロから作り直す」状態だけは避けておきたい。

まずはSOUL.md、メモリ、スキルを守る。それだけでも、エージェントの再起動可能性は大きく変わります。

関連情報