AIエージェントを複数動かす前に分けるもの|プロファイルとサンドボックスの違い
「仕事用」と「個人用」のエージェントを同じ PC で動かしても、名前を変えただけでは分離できません。片方がもう片方の記憶や鍵を読める状態なら、見た目が 2 体でも権限は 1 人分です。
複数運用では、プロファイルとサンドボックスを別の仕組みとして考えます。前者は状態を分け、後者はアクセスできる範囲を狭めます。
プロファイルが分けるもの
Hermes Agent のプロファイルは、エージェントごとのホームディレクトリです。各プロファイルに、次の状態を持たせます。
config.yaml.envSOUL.md- 記憶
- セッション履歴
- Skills
- cron ジョブ
- ログ
- 状態データベース
たとえば、coderというプロファイルは次のコマンドで作れます。
hermes profile create coder
coder setup
coder chat
これで、通常の Hermes とは別の設定と記憶を持つエージェントができます。コード作業用とブログ運用用で、文体やモデル、定期処理を混ぜずに済みます。
同じプロファイルを2体で共有しない
公式資料は、2 つのプロセスを同じ Hermes ホームへ向けないよう警告しています。どちらも記憶を自動更新するためです。
片方が保存した内容を、もう片方が次のセッションで自分の記憶として読み込みます。更新が重なると、誰が書いた情報なのか分からなくなります。
同じ利用者について知る必要があっても、エージェントの状態まで共有する必要はありません。各エージェントに別プロファイルを割り当て、共有したい知識は外部の記憶基盤や Git 管理の資料へ置きます。
プロファイルは防火壁ではない
ここが最も誤解しやすい点です。プロファイルを分けても、ファイルへのアクセス権は分かれません。
デフォルトのローカル実行では、エージェントは OS 上の利用者と同じ権限を持ちます。coderプロファイルから個人用ディレクトリを読める可能性があります。terminal.cwdで開始場所を変えても、移動を禁止する境界にはなりません。
SOUL.mdへ「ほかのフォルダを読まない」と書く方法も、強制力のある制限ではありません。モデルへの指示と、OS が適用する権限は別物です。
サンドボックスが制限するもの
ファイルやネットワークへのアクセスを狭めたい場合は、サンドボックスを使います。
Hermes Agent は、ローカル以外に Docker、SSH、Modal、Daytona、Vercel Sandbox、Singularity などのターミナル実行先を選べます。Docker では、コンテナ内へ作業場所を閉じ込め、不要な権限を落とせます。
OpenAI Codex も同じ考え方を採ります。Codex CLI のデフォルト構成では、書き込みを作業領域へ制限し、ネットワークを無効にします。領域外の編集やネットワーク利用には承認を求めます。
プロファイルは机の引き出しを分ける仕組みです。サンドボックスは部屋の鍵に近い仕組みです。片方だけでは、状態の混同と権限の広がりを同時に防げません。
資格情報もプロファイル単位で考える
.envを分けても、ローカルで動く外部コマンドは、通常のホームディレクトリにある設定を見つける場合があります。
GitHub CLI、SSH、クラウド CLI、パッケージ管理ツールは、~/.configや~/.sshを使います。Hermes Agent のterminal.home_modeがデフォルトのautoなら、ホスト上では OS 利用者のホームを保ちます。既存の CLI がそのまま動く一方、プロファイル間で資格情報を共有します。
厳密に分けたいプロファイルでは、専用のホームを使います。必要な CLI だけを設定します。さらに、シークレットを会話へ直接書かず、実行時に参照します。
実運用で使う境界
私は、影響の大きさで実行場所を変えます。
読むだけの調査は、ネットワークと書き込み先を必要な範囲に絞ります。コード変更は Git 管理された作業ディレクトリで行い、テストを通します。公開、削除、送信は承認または明示的なジョブ設定を必要にします。
複数エージェントには別プロファイルを与えます。未確認の報告は、そのまま事実として共有しません。コミット ID、ファイル、CI 結果など、別の証拠で確認してから引き継ぎます。
エージェントの名前や人格を分けるだけでは、事故の範囲は変わりません。状態はプロファイルで分け、権限はサンドボックスで絞り、外部への操作は承認境界で止める。この 3 つを重ねると、複数運用が現実的になります。