チェックポイントと`/rollback` — 破壊的操作のためのセーフティネット

AIエージェントがrm -rfのようなコマンドを実行したり、ファイルを上書きしたりするのを見て、「本当に分かってやってるのかな…」と思ったことはありませんか？Hermes Agent v2では、リスクのある操作の前にプロジェクトのスナップショットを取得し、たった1つのコマンドで復元できるチェックポイント機能が追加されました。

何より嬉しいのは、これが完全にオプトインであること。ほとんどのユーザーは/rollbackを使うことはありませんし、シャドーストアのストレージは時間とともに肥大化する可能性があるため、デフォルトではオフになっています。でも、必要なときには命綱になってくれます。

チェックポイントの有効化

セッション単位で簡単なフラグを付けるだけで有効化できます：

hermes chat --checkpoints

または、~/.hermes/config.yamlでグローバルに有効化：

checkpoints:
  enabled: true

これだけです。有効化すると、破壊的な操作が発生する前にHermesが自動的にプロジェクトのスナップショットを取得します。

チェックポイントが作成されるタイミング

Hermesは以下の操作の前に自動的にチェックポイントを作成します：

ファイルツール — write_file と patch
破壊的なターミナルコマンド — rm、rmdir、cp、install、mv、sed -i、truncate、dd、shred、出力リダイレクト（>）、git reset/clean/checkout

エージェントは1ターンにつきディレクトリごとに最大1つのチェックポイントを作成するため、長時間のセッションでもスナップショットが乱立してストレージを圧迫することはありません。

内部での仕組み

この魔法は、~/.hermes/checkpoints/store/に単一の共有シャドーgitリポジトリを維持する内部のチェックポイントマネージャーによって実現されています。実際のプロジェクトの.gitには一切触れません — すべてはこの別のストアに格納されます。

処理の流れは以下の通り：

Hermesはツールが作業ツリー内のファイルを変更しようとしていることを検出します。
会話のターンごとに（ディレクトリごとに）、適切なプロジェクトルートを解決します。
共有シャドーストアを初期化または再利用します。
プロジェクトごとのインデックスにファイルをステージし、ツリーを構築して、プロジェクトごとのref（refs/hermes/<project-hash>）にコミットします。

すべてのプロジェクトが同じストアを共有するため、gitのコンテンツアドレス型オブジェクトデータベースがプロジェクト間・ターン間で重複排除を行います — つまり、同一コンテンツでストレージを無駄にすることはありません。

セッション内での`/rollback`の使い方

チェックポイントが有効なセッションでは、以下のスラッシュコマンドが使えます：

コマンド	説明
`/rollback`	変更統計付きの全チェックポイントを一覧表示
`/rollback <N>`	チェックポイントNに復元（手動編集は保持、直前のチャットターンも取り消し）
`/rollback <N> --all`	完全復元 — 手動編集も上書き
`/rollback diff <N>`	チェックポイントNと現在の状態の差分をプレビュー
`/rollback <N> <file>`	チェックポイントNから単一ファイルを復元

/rollbackを実行すると、次のような整形されたリストが表示されます：

📸 /path/to/project のチェックポイント:

  1. 4270a8c  2026-03-16 04:36  before patch  (1 file, +1/-0)
  2. eaf4c1f  2026-03-16 04:35  before write_file
  3. b3f9d2e  2026-03-16 04:34  before terminal: sed -i s/old/new/ config.py  (1 file, +1/-1)

シェルからのストア管理

セッション外では、CLIコマンドでチェックポイントストアの確認・管理ができます：

コマンド	説明
`hermes checkpoints`	合計サイズ、プロジェクト数、プロジェクトごとの内訳を表示
`hermes checkpoints status`	素の`checkpoints`と同じ
`hermes checkpoints list`	`status`のエイリアス
`hermes checkpoints prune`	強制スイープ：孤立・古いエントリの削除、GC、サイズ上限の適用
`hermes checkpoints clear`	チェックポイントベース全体を削除（確認あり）
`hermes checkpoints clear-legacy`	v1マイグレーションの`legacy-*`アーカイブのみ削除

設定オプション

~/.hermes/config.yamlでチェックポイントの動作を細かく調整できます：

checkpoints:
  enabled: false              # マスタースイッチ（デフォルト: false — オプトイン）
  max_snapshots: 20           # プロジェクトごとの最大チェックポイント数
  max_total_size_mb: 500      # ストア全体のサイズ上限
  max_file_size_mb: 10        # このサイズを超える単一ファイルはスキップ
  auto_prune: true            # 起動時にスイープ（デフォルトでオン）
  retention_days: 7           # これより古いエントリを削除
  min_interval_hours: 24      # 自動プルーンの最小間隔

重要な注意点：自動プルーンのスイープでは「孤立」エントリ（作業ディレクトリが見つからないもの）は削除されません。起動時に作業ディレクトリが見つからない場合、それはプロジェクトが削除されたことを意味するかもしれませんが、まだマウントされていない外部ボリュームやネットワーク共有の可能性もあります。孤立エントリのクリーンアップは、明示的なhermes checkpoints pruneコマンドでのみ実行され、その際には確認が求められます。

すべてを無効化するには：

checkpoints:
  enabled: false
  auto_prune: false

enabled: falseの場合、チェックポイントマネージャーは何もせず、git操作を試みることもありません。auto_prune: falseの場合、手動でhermes checkpoints pruneを実行するまでストアは増え続けます。

まとめ

チェックポイントを使えば、常に既知の正常な状態にロールバックできるという安心感を持って、Hermesを自由に作業させることができます。リファクタリングの実験、危険なコマンドのテスト、あるいは単に安心感が欲しい場合でも、/rollbackコマンドがあなたを守ってくれます。

次のセッションでぜひ試してみてください — あなたのワークフローに欠かせない存在になるかもしれません。