Hermes Agent profiles：複数の Agent を安全に動かす
こんにちは、Lena です。ずっと後回しにしていた問いがありました。ようやく、それに答えようとしてみました。
数週間前、私は同じマシン上で 2 つの Hermes Agent を切り替えていました。ひとつは個人的な実験用に設定したもの、もうひとつは小さなクライアント案件につながっているものです。ところが、うっかり同じ config ディレクトリを共有していました。最初は気づきませんでした。そのあと、個人用 agent の session memory が、本来出てきてはいけない会話に現れました。それを見たあと、私はかなり長く手を止めました。その agents は、本当には分離されていなかったのです。分離されているように見えていただけでした。
そこから、私は Hermes Agent profiles が実際に何をしているのかを、もう少し丁寧に読み始めました。表面上の command ではなく、何が隔離され、何が隔離されないのか。ここに書くのは、今のところ私がつなぎ合わせた理解です。まだ全体像を見られているとは思いません。ただ、手元にある断片だけでも、書き残す価値はありそうです。
これは、単一の agent を動かす段階を越えて、複数の agents を動かし始めた人に向けて書いています。ひとつでは足りないと気づく瞬間は、多くの isolation problems が始まる瞬間でもあります。ひとつの agent ではうまく機能していた defaults は、2 つになるとうまく働きません。しかも、その失敗は静かに起きます。何かが境界を越えてしまうまで、気づかないことが多いのです。
Hermes profiles は本当は何を隔離するのか
今の私の理解では、profile は名前付きの scopeです。ひとつの agent instance が「その agent らしく」振る舞うために必要なものをまとめて持っています。config、memory、sessions、登録済みの skills、gateway state、そして environment variables。profiles を切り替えるとき、変えているのは単なる設定ではありません。その agent が動作する context 全体を入れ替えています。この違いは、最初に思っていたよりずっと重要でした。
Config, memory, sessions, skills, gateway state, env
私はこのリストをもう一度見直しました。そこで意外だったのは、この scope にかなり多くの state が載っていることです。まじめな CLI tool で environment variables を使ったことがあるなら、この pattern は見覚えがあるはずです。各 profile は、それぞれ自分のものを持っています。
- Config — model selection、temperature、system prompt overrides、tool permissions
- Memory — agent が時間をかけて蓄積してきた長期 context
- Sessions — active conversation threads。resume 可能なものも含みます
- Skills — 登録済みの capabilities と、その scope 内の credentials
- Gateway state — routing rules、MCP server registrations、network policies
- Env vars — API keys、endpoints、secrets
ここで強調したいのは、これは security boundary であって、単なる整理用の境界ではないということです。OWASP が agent architectures をどう強化するかを説明するとき、sessions 間で memory と context を隔離することは最初に挙げられる防御策のひとつです。Profiles は、Hermes がその考え方を per-agent で実装する方法なのだと思います。この cheat sheet は 2 回読みました。そこでようやく腑に落ちました。
ただ、gateway state がいくつかの edge cases で profiles をまたいでどう伝播するのかは、まだ完全には分かっていません。たとえば、2 つの profiles が同じ MCP server を異なる scopes で登録する場合です。ここはもう少し見たいところです。今の推測では、registration は per-profile だけれど、下層の connection pool はそうではないかもしれません。gateway layer で stateful なことをしているなら、これは重要になります。まだ確認できていません。だから、この問いは開いたままにしておきます。
複数の profiles を作成して管理する
最初に試したとき、私は少し複雑に考えすぎていました。基本の flow は思ったよりシンプルでした。ただし、その周りに作る conventions は、commands そのものより重要です。
Naming, alias commands, switching, export and import
私が落ち着いた convention は、あくまで自分の習慣ですが、<context>-<role> です。personal-research、work-coding、client-acme-prod のようにします。命名は、最初に思っていたより重要でした。 profiles が 6 つあり、疲れているとき、test2 という profile は将来の incident 予備軍です。私はその失敗をしました。test2 を sandbox だと思い込んで destructive command を実行した日から、profiles の名前を真面目につけるようになります。
Switching は 1 つの command で終わるべきものです。Export と import を使えば、profiles をマシン間で移せます。私は一度、新しい laptop で試しました。Export bundle には config が含まれますが、raw secrets は含まれません。受け取り側で再注入する必要があります。これは正しい default だと思います。ただし、いちばん人をつまずかせやすい部分でもあります。何人かと話したところ、secrets も profile と一緒に移ると思っていて、import した agent が authenticate に失敗して驚いていました。
小さなことですが、よく使う profile-switch commands を shell level で alias にしておくと、かなり楽になりました。1 日に 3 回も 4 回も切り替えるなら、friction は積み上がります。そして friction こそが、切り替えを飛ばして間違った profile を使い回す原因になります。
profiles の現実的なユースケース
ここで一度立ち止まって考える必要がありました。実際、誰がこれを必要としているのか。agent を動かす人すべてに profiles が必要なわけではありません。ただ、次のどれかに当てはまるなら、私は必要だと思います。
Personal vs work, coding vs research, prod vs test
いちばん分かりやすいのは personal vs work です。memory が違い、skills が違い、credentials も違います。週末の side-project 用 agent に雇用主の database へ access させたいとは思いませんし、仕事用 agent に買い物リストを覚えてほしくもありません。心理的な分離も実際にあります。profiles を切り替えることは、小さな儀式のようなものです。configuration だけでなく、context を切り替える助けになります。
2 つ目は coding vs research です。Coding agent には、より強い tool permissions が役立ちます。file writes、shell execution、repo access などです。Research agent にはそれらは不要です。不要な permissions を与えると、意味もなく attack surface が広がります。ここで principle of least privilege が抽象論ではなく実務になります。各 profile には、本当に必要な permissions だけを与え、それ以上は与えない。以前の私は、楽だからという理由で広めに権限を渡していました。今はやりません。
3 つ目は prod vs test です。これは、問題が起きるまで多くの人が過小評価しがちなものです。Test agent が production credentials から 1 keystroke の距離にあってはいけません。Microsoft の agent governance に関する guidance は、これを agent contexts 間の cross-contamination を防ぐための project-level data isolation として捉えています。Profiles は、この要求を単一の workstation 上で enforce する方法です。本来軽量であるべき separation のために、VM や container を別途立てる必要はありません。
最近、予想していなかった 4 つ目のケースも出てきました。stable vs experimental です。stable profile には、テスト済みの skills と known-good configs を置きます。experimental profile では、新しい tools、prompt variations、model swaps を試します。Experimental profile はよく壊れます。Stable profile は壊れません。気軽に触っていいものが何もないからです。この分離は、思っていた以上に debugging time を減らしてくれました。
…最初に想像していたものとは少し違います。でも profiles を使うほど、これは安全な agent operation の基本単位であって、optional extra ではないように感じています。
profile でよくある間違い
私はこの大半をやっています。すぐ気づいたものもあれば、数週間かかったものもあります。
profiles 間で credentials を共有すること。 これがいちばん多く、いちばん危険です。別々の profile を作っているのに、同じ API key をすべてで使い回してしまう。profiles は隔離されています。しかし credentials は隔離されていません。ひとつの profile が compromised されると、その key を共有しているすべての profiles が compromised されます。IBM の AI agent security tutorial はここをかなり直接的に書いています。over-permissioning と shared credentials は、agent systems の主要な failure mode です。修正は地味です。profile ごとに別の key を使い、その profile が必要とする最小範囲に scope する。
session continuity への誤った期待。 profile を切り替えると active session は終わります。sessions が profiles をまたいでついてくると思っている人がいます。ついてきません。continuity が必要なら、同じ profile に留まるべきです。isolation が必要なら切り替える。そして、新しい conversation context を始めているのだと受け入れる。私はこの前提と何週間も格闘してから、ようやく腹落ちした人を見たことがあります。
tool configs の混在。 同じ skill を複数の profiles に読み込み、それぞれ異なる scopes を与えることです。その skill は、どの profile で動いているかによって振る舞いが変わります。これは debugging をかなりややこしくします。最初から skills は profile-scoped なものとして扱うのがよいと思います。多少の duplication が出てもです。Duplication は安い。profiles 間で振る舞いが一貫しない skill を debug するのは安くありません。
この最後の点は、私が少し深読みしすぎているのかもしれません。でもすでに 2 回引っかかっているので、書いておきます。
profiles が deployment と governance の判断をどう変えるか
ここはまだ考えている途中です。正直に言うと、私の理解はまだ不完全です。
profiles を真剣に扱うと、それは個人の organization tool ではなく、governance primitive になります。チームは、production agent profiles に特定の gateway configurations を使うことを要求できます。auditor は、ある action をどの profile が生成したのかを尋ねられます。そして、肩をすくめるのではなく、実際の答えを返せます。これは、NIST の AI Risk Management Framework が accountability を扱う方法と合っています。すべての action は、定義された authority scope に traceable であるべきです。Profiles は、その scope を新たに発明せずに与えてくれます。
2025 年の NIST update on agentic AI は、さらに踏み込んでいます。Cybersecurity AI Profile draft は、single-agent と multi-agent deployments を別々の risk categories として扱い、それぞれに isolation requirements を置いています。Profiles は、agent ごとに別 infrastructure を立てずに、その requirements を満たす具体的な方法のひとつです。小さなチームには、これが重要です。多くの人には、agent ごとに isolated environments を運用する予算も時間もありません。でも agent ごとに isolated profiles を走らせることはできます。
self-hosting setups や、もっと大きな team deployments に対してこれが何を意味するのか、まだ強くは言えません。私は小規模でしか試していませんし、高い load で何が壊れるのかを見られるほど長く運用してもいません。ただ、方向性は正しいように感じます。identity と isolation は machine level ではなく、agent level にあるべきです。 それが成り立つと、agents は全体として信頼しなければならない monolithic processes ではなく、組み合わせ可能な building blocks になります。
FAQ
profiles は何らかの state を共有しますか？
Profile boundary は固いものとして設計されているはずです。重なりが見える唯一の場所は、下にある Hermes binary そのものです。同じ version、同じ global defaults。ただし、私が観察した限り、stateful なものはすべて profile-scoped です。
2 つの profiles を同時に実行できますか？
できます。別々の terminal sessions で動かします。私が見た範囲では、互いに干渉しません。短時間なら 3 つ同時に走らせたことがありますが、明らかな問題はありませんでした。
新しい profile の最も安全な default は何ですか？
Minimal permissions、production credentials なし、shared API keys なし。capabilities は、本当に必要になったときだけ追加する。退屈な助言ですが、もっと早く受け入れておけばよかったと思う助言です。
すべての project に専用 profile を作るべきですか？
…まだ分かりません。小さな実験なら、おそらく不要です。ただし production、実際の client data、sensitive credentials に触れるものなら、はい。profile を作る cost は低いです。必要だったのに持っていなかったときの cost は、ときどき非常に高くなります。今回はここまでにしておきます。profiles を増やしながら、これがどう振る舞うのかを見続けます。Agent infrastructure が成熟し始める過程で、ここには何かが起きています。まだ、その形を完全には見えていません。
Previous Posts:
👉 Hermes memory が contexts をまたいでどう振る舞うのかまだ分からないなら、こちらをどうぞ：Hermes Agent Memory Limits & Tradeoffs Explained
👉 external tools で agents を拡張するときの隠れたリスクを避ける方法をもう少し深く見るなら：How to Use MCP Safely with Hermes Agent
👉 複数の agents を environments 間で動かしているなら、この整理が役に立ちます：Hermes Agent vs EvoMap: Memory Architecture Differences
👉 agent capabilities と stored knowledge の違いを理解したいなら、profile design にはかなり重要です：Agent Skills vs GEP Assets: What Actually Persists
👉 profiles を越えた長期的な agent evolution を考えているなら：EvoSkills: Self-Evolving Agent Skills in Practice
