要約

Hermes Agentは独自LLMではなく、複数のLLM、ツール、記憶、メッセージング、定期実行を束ねる汎用エージェント・ハーネスである。ツール実行結果を次の推論へ返すループ、文脈構成、永続記憶、スキル再利用により、単発回答ではなく検証を伴う継続作業を可能にする。

ただしClaude Code/CoworkおよびCodex/Codex appも、コーディング専用からブラウザ、デスクトップ操作、記憶、リモート利用を含む汎用エージェントへ拡張中である。現在の主な差は機能の有無ではなく、セルフホスト可能なOSSとして自分で制御・拡張・運用するか、ベンダー純正の完成度・安全性・手軽さを選ぶかにある。

背景・問い

  • HermesはLLMとどのように接続され、何が実行性能を高めるのか。
  • Claude Code/Codexを単体で使う場合と比べ、Hermesの利点・欠点・トレードオフは何か。
  • Claude/Codexも汎用業務へ広がる中で、Hermesを選ぶ合理性はどこに残るか。

Hermesの仕組み

中心ループ

Slack / CLI / Desktop / IDE / Cron
  → GatewayまたはCLI
  → AIAgent
    - プロンプト組み立て
    - プロバイダ・モデル解決
    - LLM API呼び出し
    - ツール実行と結果の返却
    - 圧縮・キャッシュ・保存
  → LLMプロバイダと実行ツール

AIAgentは、会話・有効なスキル・メモリ・プロジェクト指示・ツール定義を集めてプロンプトを構成する。LLMがツール呼び出しを選択すると、Hermesが実行し、その観測結果を次のLLM入力に戻す。最終回答まで、必要に応じてこの循環を繰り返す。

仮説 → ツールによる実行・観測 → 結果の評価 → 仮説修正 → 再実行

LLMとの連携

Hermesはプロバイダ非依存の解決層を持つ。設定上の(provider, model)を、API方式、認証情報、base URLへ解決し、プロバイダごとのChat Completions、Responses、Anthropic Messages等へ変換して呼び出す。

LLMに渡るのは単なる質問文ではなく、ツールのJSON Schema、利用ルール、実行環境、スキル、会話履歴、必要な記憶を含む作業文脈である。

実務性能を高めるハーネス要素

  1. ツールループ: 推測ではなく、ファイル・コマンド・Web・ブラウザ等の実測結果に基づき次の行動を選べる。
  2. Prompt Assembly: 指示、スキル、プロジェクト文脈、記憶、履歴を順序づけ、毎回の推論の前提を整える。
  3. 圧縮・キャッシュ・セッション保存: 長期作業で重要な決定を維持し、プロバイダが対応する場合はプロンプトキャッシュを活用する。
  4. MemoryとSkills: 好み・事実を記憶し、成功した手順を再利用可能な手続き知として残す。
  5. Gateway・cron・サブエージェント: 複数チャネルでの継続作業、定期実行、仕事の分割を可能にする。

Claude/Codexとの比較

解釈・判断

以前の対比は崩れている

「Claude Code/Codexはコーディング専門、Hermes/OpenClawは雑務用」という二分法は、現在は不正確である。Claude CoworkやCodex appの登場により、ブラウザ・PC操作・記憶・リモート利用・非コーディング業務の領域は急速に重なっている。

現在の選択は、できることの一覧よりも、次の問いで決めるべきである。

  • 完成品のアシスタントを使いたいか: Claude/Codexの純正製品が合理的。
  • アシスタントの基盤を自分で設計・接続・ホストしたいか: Hermes/OpenClawが合理的。

Hermesが向くケース

  • Slack等から依頼し、cron・監視・通知を含む常駐ワークフローを組みたい。
  • モデル、ツール、メモリ、MCP、実行環境を組織・個人の要件に合わせて差し替えたい。
  • 社内システム、SSH先、VPS、オンプレ、隔離VMなど独自環境へ接続したい。
  • パーソナルエージェントの仕組みそのものを研究・実験・拡張したい。

純正Claude/Codexが向くケース

  • まず成果を最短で得たい。
  • エージェントの常駐運用・認証・セキュリティ・更新に時間を使いたくない。
  • 利用モデルがClaudeまたはOpenAIにほぼ決まっている。
  • 単一または少数の明確な作業を高品質に進めたい。

現実的な併用

Hermesを受付・記憶・スケジュール・外部連携・進捗報告の層とし、深い実装やレビューをClaude Code/Codex CLIへ委譲する構成は可能である。ただし制御層が増えるため、指示伝達、権限、ログ、障害切り分け、コスト管理は複雑になる。これは必ずしも最適解ではなく、独自の常駐業務フローが必要な場合に限って正当化される。

セキュリティと運用上の注意

共有記事はHermes v0.14.0について、ローカル認証情報の自動検出と、自動スキル/メモリ更新による持続的プロンプト注入の可能性を実機観察として指摘している。この記事の検証結果は本セッションで独立再現していないが、構造的リスクとして重く扱うべきである。

  • 自動生成されたスキル・メモリは将来のプロンプトに再投入されうる。
  • 信頼できないWeb、メール、添付、チャットを扱う環境では、便利な永続記憶が注入経路になりうる。
  • 常駐・多ツール・多認証の利便性は、権限範囲と攻撃面の拡大でもある。

推奨する最低限の運用:

  • 普段使いの母艦ではなく、専用端末・隔離VM・Docker等で動かす。
  • 専用アカウントと最小限の認証情報を使う。
  • ツールセット、MCP、cron、実行環境を最小権限にする。
  • 自動スキル・自動メモリ生成を無条件に信頼せず、生成物を監査する。
  • 本番環境への操作は明示的な承認・レビュー・差分確認を挟む。

次に使う時の観点

  • 「何でもできるか」ではなく、誰が実行環境・資格情報・データ・更新を支配するかで比較する。
  • 自己改善という表現は、重み学習ではなく、外部化したプロンプト資産の蓄積・再利用として評価する。
  • 常駐化するほど、便利さより先に隔離・認可・監査の設計を行う。
  • 純正アプリで要件を満たせるなら、まず純正製品から始め、独自連携が必要になった段階でHermes/OpenClawを検討する。

未解決事項

  • 記事内のHermes v0.14.0に関する認証自動検出・自動生成スキルの挙動は、本セッションでは独立再現していない。
  • Claude CoworkおよびCodex appの機能・実行環境・安全境界は変化が速いため、導入判断時には公式の最新ドキュメントで再確認が必要。
  • Hermesの自動スキル生成と記憶更新を、具体的な設定でどこまで承認・隔離・監査できるかは別途検証が必要。

出典

関連メモ