実行環境 — ローカルから Docker・クラウドまで 7 バックエンド

これは何か

「エージェントに shell を渡す」と聞いて身構えるのは自然な反応だ。Hermes のエージェントはターミナルツール経由で実際にコマンドを実行できるが、そのコマンドが物理的にどこで動くかを選べるのが、この章で扱う「ターミナルバックエンド」という仕組みである。

設定の入口は 1 つで、~/.hermes/config.yaml の terminal.backend キーである。

terminal:
  backend: local    # local | docker | ssh | modal | daytona | vercel_sandbox | singularity

変更は第 3 章で紹介した hermes config サブコマンドで行う。

hermes config get terminal.backend
hermes config set terminal.backend docker

2026-09 時点（v0.21.0）で選べるバックエンドは 7 種類。数え方には公式ドキュメント内でも表記のゆれがあり、アーキテクチャ図の注記は今も古い「6 backends」のままだが、設定リファレンス本文は「seven terminal backends」と明記している。本章では後者の 7 を正としたうえで、内訳を次節以降で見ていく。

バックエンドが決めるのは「コマンドがどこで動くか」だけではない。terminal ツール、ファイル操作ツール、execute_code の RPC（第 9 章）もすべて同じバックエンド上で実行される。バックエンドを Docker に切り替えると、これらのやり取りはすべて同じコンテナの中に閉じ込められる。

いつ使うのか

典型的な選び方は次のような問いに集約できる。

• 「とにかく手元で素早く試したい・隔離のコストを払いたくない」→ 隔離なしの local
• 「危険なコマンドの実行結果を人間の権限から切り離したい・安全なサンドボックスで CI/CD を回したい」→ docker
• 「手元にない強力なマシン（GPU サーバーなど）で作業したい」→ ssh
• 「評価やベンチマークを使い捨てのクラウド計算資源で回したい・管理されたクラウド開発環境やスナップショット保存が欲しい」→ modal / daytona / vercel_sandbox

Docker デーモンが使えない環境（HPC クラスタや、root 権限のない共有マシンなど）では singularity（Apptainer）が代わりになる。迷ったときの目安を表にまとめる。

7 つに共通する軸は「隔離の強さ」と「使い捨てかどうか」である。次節ではこの 2 軸に沿って、リスクの段階として整理する。

リスクの段階で見る 7 バックエンド

「エージェントに shell を渡すのが怖い」という感覚に対する Hermes の答えは、隔離をオール・オア・ナッシングにしないことだ。ホスト直実行からクラウドの使い捨て環境まで、隔離の強さを段階的に選べる。

各段階で何が変わるかを言葉でも確認しておく。local はエージェントに自分のユーザー権限をそのまま渡す。ssh は物理的に別のマシンへ実行を移すが、隔離の仕組み自体はそのマシンの通常のシェルと変わらない——ネットワークの向こう側にあるという境界だけが頼りになる。docker と singularity は OS のネームスペース機能でプロセスを閉じ込める箱を作り、docker はさらに Linux capability を丸ごと剥奪したうえで一部だけ復元する分だけ隔離が強い。modal / daytona / vercel_sandbox はクラウド上の VM・コンテナ・マイクロ VM そのものを使い捨て、セッションが終わればファイルシステムをスナップショットしてから消す。

次節では、初心者が最初に手を出しやすい docker の中身を詳しく見ていく。

Docker バックエンドの中身 — ハードニングと永続コンテナ

Docker バックエンドは、Hermes プロセスが動くホストの上で1 つの永続 Docker コンテナを起動し、以降のすべてのターミナル呼び出しをそのコンテナへの docker exec として実行する。「1 つ」という点が重要で、同じセッションだけでなく、/new による新規会話、/reset、delegate_task によるサブエージェント（第 9 章）まで、すべて同じコンテナを共有する。

この共有ぶりは徹底している。作業ディレクトリの変更、apt install や pip install で入れたパッケージ、/workspace 以下のファイル、そしてバックグラウンドで動かしたプロセスまで、次のツール呼び出しへ、さらには次の Hermes プロセスへとそのまま持ち越される。次に起動した Hermes プロセスは、コンテナに付いたラベル（hermes-agent / hermes-task-id / hermes-profile）による検索でこの同じコンテナを見つけ、数ミリ秒で再接続する。

コンテナが実際に止まる（docker rm -f される）のは次の場合に限られる。

• プロセスをまたぐ永続化を明示的に切っている — docker_persist_across_processes: false に設定している場合、毎回のクリーンアップで停止・削除される
• アイドルリーパー — 既定 300 秒。ただし persist_across_processes: false のときだけ働く
• 次回起動時のオーファンリーパー — Exited 状態のまま「アイドルリーパー秒数 × 2」（既定 600 秒）を超えたコンテナを掃除する
• ユーザーによる明示操作 — docker rm -f、docker system prune など

もう 1 つ、container_persistent: false に設定すると挙動が変わる点にも触れておく。これは「セッションごとに使い捨てのコンテナを作る」モードで、チャットやセッションが終わるたびにコンテナが破棄され、ファイルシステム・マウント・バックグラウンドプロセスは何も引き継がれない。会話を跨いだ隔離をセキュリティ境界として扱いたいときはこちらを使う。ただし delegate_task のサブエージェントは、このモードでも親セッションのコンテナをそのまま共有する。

セキュリティハードニングの中身は次のとおりである。

公式イメージは nikolaik/python-nodejs:python3.11-nodejs20（Python 3.11 系・Node.js 20 系）が既定で、docker_image キーで差し替えられる。トークンやクレデンシャルは docker_env（config.yaml に直接書く固定値）と docker_forward_env（ホストのシェルや ~/.hermes/.env から値だけを引き継ぎ、値自体は config.yaml に残さない）で使い分ける。ネットワークを完全に遮断したいときは docker_network: false にすると --network=none の air-gap コンテナになる。

SSH・クラウド系バックエンドの使い分け

Docker の外側にある 5 つのバックエンドは、それぞれ必要な認証情報と永続化の仕組みが異なる。

いずれのバックエンドも container_persistent: true（既定）で「ファイルシステムを保存する」ことは約束するが、「同じライブなサンドボックス・PID 空間・バックグラウンドプロセスがそのまま動き続ける」ことまでは約束しない。ここが Docker バックエンドとの決定的な差になる。Docker は本物の永続コンテナをそのまま生かし続けるのに対し、クラウド系はいったん破棄してからファイルシステムだけを復元する方式である。

iron-proxy — サンドボックスに本物の鍵を渡さない

Docker サンドボックスの中でエージェントがプロンプトインジェクションに引っかかったとき、最悪のシナリオは「printenv | grep -i key で本物の API キーがそのまま盗まれる」ことだ。これを防ぐのが、Hermes がホスト側で動かすエッジプロキシ iron-proxy（egress credential-injection proxy）である。2026-09 時点では Docker バックエンドのみに配線されており、Modal / Daytona / SSH / Singularity にはまだプロキシ用の環境変数も CA 証明書も渡らない。

導入は hermes egress のサブコマンドで行う。

hermes egress install   # 署名済みバイナリをダウンロード
hermes egress setup     # ホスト側のCA生成 + プロバイダごとのプロキシトークンを発行
hermes egress start     # プロキシデーモンを起動
hermes egress status    # 状態確認

デフォルトで許可されているアップストリームは openrouter.ai / api.openai.com / api.anthropic.com / generativelanguage.googleapis.com / api.x.ai / api.mistral.ai / api.groq.com / api.together.xyz / api.deepseek.com / inference.nousresearch.com の 10 件で、ループバック・リンクローカル（クラウドのメタデータ API である 169.254.169.254 を含む）・RFC1918 プライベートアドレス・CGNAT といった SSRF 対策の拒否 CIDR も既定で効いている。

ただし万能ではない。リクエスト署名や SDK が発行する OAuth を使う認証方式はこの仕組みではカバーできない。AWS Bedrock / SageMaker の SigV4 署名、GCP Vertex AI のサービスアカウント OAuth がこれにあたり、該当する環境変数がサンドボックスに存在する場合は、その分だけ本物のクレデンシャルがサンドボックスの中に置かれることになる。

hermes config get terminal.backend

hermes config set terminal.backend docker

python3 --version
node --version

echo "hermes-container-test" > /workspace/marker.txt

cat /workspace/marker.txt

hermes config set terminal.backend local

docker ps --filter label=hermes-agent=1
docker rm -f <コンテナ名またはID>

つまずきポイント

理解度チェック

まとめ

• Hermes は 7 種類のターミナルバックエンドを持ち、terminal.backend の 1 キーで切り替えられる。選び方の軸は「隔離の強さ」と「使い捨てかどうか」
• Docker バックエンドは cap-drop・no-new-privileges・pids-limit・tmpfs 制限でハードニングされた単一の永続コンテナを、セッション・新規会話・サブエージェントを跨いで共有し続ける
• SSH・Modal・Daytona・Vercel Sandbox・Singularity はそれぞれ異なる認証情報と永続化方式を持ち、「ファイルシステムは残るがプロセスは残らない」という共通の限界がある
• iron-proxy はサンドボックスに本物の API キーを渡さない egress プロキシだが、現状 Docker 限定かつ署名・OAuth ベースの認証はカバーできない
• 次の第 11 章では、この実行環境の上でエージェントがブラウザと Web をどう操作するかを扱う

参考リンク

• configuration.md（Terminal Backend Configuration）
• docker.md（Hermes Docker Setup）
• egress/iron-proxy.md
• reference/cli-commands.md
• Hermes Agent 公式ドキュメント