OpenClawからHermesへ移行してよかったこと・わるかったこと

はじめに

先月、自分のAIアシスタント環境をOpenClawからHermesに移行しました。約1ヶ月の運用を通じて、実際に感じたメリット・デメリットを整理してみます。

よかったこと

1. マルチエージェントによる並列処理

最大の変化は並列処理が可能になったことです。OpenClaw時代は単一エージェントでの直列処理が基本でしたが、Hermesでは複数のサブエージェントを同時に起動できます。

実際のパフォーマンス比較

実装例：並列タスクの実行

# Hermesでの並列エージェント呼び出し例
result = await delegate_task(
    agents=[
        {"role": "seo_analyzer", "task": "analyze_meta_tags", "urls": urls[:5]},
        {"role": "seo_analyzer", "task": "analyze_meta_tags", "urls": urls[5:]},
        {"role": "performance_checker", "task": "check_load_speed", "urls": urls}
    ],
    parallel=True,  # 並列実行
    timeout=300
)

これは単なる速度向上ではなく、思考の切り替えコストが激減したことの恩恵も大きいです。以前は1タスク完了→次タスク開始の待ち時間が発生していましたが、今は一度の指示で全タスクが動き出します。

2. セッション管理の明確化

ByteRoverによる永続化層の導入で、「セッションが切れたら全部忘れる」問題が解消しました。重要な設計決定やAPI仕様は自動的に記憶され、次回以降の対話で参照されます。

セッション永続化の設定例

# hermes-config.yaml
session:
  persistence:
    enabled: true
    backend: "byterover"  # 永続化バックエンド
    retention_days: 90    # 保持期間
    auto_save: true       # 自動保存
    
  context:
    project_specs: true   # プロジェクト仕様を記憶
    api_schemas: true     # APIスキーマを記憶
    coding_standards: true # コーディング規約を記憶

特にDifyワークフローの開発では、過去の設計意図が引き継がれるため、增速が半減しました。

3. モデル使い分けの自由度

メインをkimi-k2.5（コスト重視）、重要判断はThinkpad経由のClaude Code（品質重視）という使い分けが実現できました。

モデルルーティング設定

# models.yaml
primary_model:
  name: "kimi-k2.5"
  provider: "moonshot"
  cost_tier: "low"
  use_for: ["code_generation", "documentation", "refactoring"]

high_quality_model:
  name: "claude-sonnet-4"
  provider: "anthropic"
  cost_tier: "high"
  use_for: ["architecture_decisions", "security_review", "complex_debugging"]
  condition: "task.complexity > 0.8"

routing_rules:
  - pattern: "security|auth|payment"
    model: "high_quality_model"
  - pattern: "refactor|style|comment"
    model: "primary_model"

わるかったこと

1. 初期設定の複雑さ

OpenClawは「起動すれば使える」シンプルさがありましたが、Hermesは環境構築に手間がかかります。特にSSH経由のClaudeCode連携は、Tailscale設定や認証周りで試行錯誤しました。

典型的な設定トラブルと解決策

Error: ssh: handshake failed: ssh: unable to authenticate

# Windows側のOpenSSHエージェントを使用する設定
# ~/.bashrc に追加
export SSH_AUTH_SOCK="/mnt/U...sock"

# または WSL2 内で新規に鍵を生成
ssh-keygen -t ed25519 -C "hermes@wsl2"
ssh-copy-id user@thinkpad-gateway

Error: connection timeout to 100.x.x.x:22

# Tailscaleデーモンの自動起動設定
sudo systemctl enable tailscaled
sudo systemctl start tailscaled

# MagicDNSを有効化（hostnameでの接続が可能に）
tailscale up --accept-dns=true

# 接続テスト
ping thinkpad-gateway

推奨初期設定手順

1. 前提条件の確認
   • WSL2 Ubuntu 22.04以上
   • Python 3.10以上
   • Node.js 18以上（Claude Code用）
2. Tailscaleセットアップ

   # インストール
   sudo apt install tailscale
   sudo tailscale up
   
   # 同じTailnetにThinkpad Gatewayを追加
   # Dashboard: https://login.tailscale.com/admin/machines

3. Hermesインストール

   pip install hermes-ai-agent
   hermes configure --init
   hermes doctor  # 診断コマンドで環境チェック

2. デバッグの難易度

マルチエージェント化による失敗の追跡が難しくなりました。あるサブエージェントが失敗した際、どのコンテキストで何が起きたかを把握するのに時間がかかります。

ログ構造化の推奨設定

# logging.yaml
version: 1
disable_existing_loggers: false

formatters:
  detailed:
    format: "%(asctime)s | %(name)s | %(levelname)s | [%(correlation_id)s] %(message)s"
    datefmt: "%Y-%m-%d %H:%M:%S"

handlers:
  file:
    class: logging.handlers.RotatingFileHandler
    filename: /var/log/hermes/agent.log
    maxBytes: 10485760  # 10MB
    backupCount: 5
    formatter: detailed
  
  slack:
    class: hermes.handlers.SlackWebhookHandler
    webhook_url: "${SLACK_WEBHOOK_URL}"
    level: ERROR
    formatter: detailed

loggers:
  hermes.agent:
    level: DEBUG
    handlers: [file, slack]
    propagate: false
  
  hermes.subagent:
    level: INFO
    handlers: [file]
    propagate: false

現在はログ構造化と、Slackへの通知強化で対応中です。

3. 同一モデル継承の罠

delegate_taskでのサブエージェントは、デフォルトで親と同じモデルを継承します。つまりkimi-k2.5が統括していると、重要判断タスクもkimiに任されることに。明示的な指定が必要で、最初は気づきませんでした。

正しいモデル指定の例

# ❌ 誤り：モデル指定なし（親モデルが継承される）
result = await delegate_task(
    task="レビュー依頼",
    agents=[
        {"role": "security_reviewer", "task": "認証コードのレビュー"}
    ]
)

# ✅ 正解：明示的にモデルを指定
result = await delegate_task(
    task="レビュー依頼",
    agents=[
        {
            "role": "security_reviewer",
            "task": "認証コードのレビュー",
            "model": "claude-sonnet-4",  # 明示的に指定
            "temperature": 0.2  # 慎重な判断を促す
        }
    ]
)

よくある落とし穴チェックリスト

• ☐ サブエージェントのモデルは明示的に指定しているか？
• ☐ エラーハンドリングは各サブエージェント単位で設定しているか？
• ☐ タイムアウト値はタスクの複雑さに応じて調整しているか？
• ☐ 並列実行時のレート制限は考慮しているか？
• ☐ コンテキスト引継ぎは明示的に指定しているか？

総合評価

移行の結論として：

• 運用規模が大きいほど恩恵を受ける：並列処理の効果はタスク量に比例
• セッション継続性は必須：短期タスクならOpenClawでも十分
• 階層型モデル運用：コストと品質の最適解

個人的には、移行して正解でした。初期設定の手間は「一度済めば済む」もので、継続的な生産性向上と比較すれば許容範囲です。

おわりに

AIアシスタントの選定は、使い方によって最適解が変わります。自分のワークフローに合わせた設計が、結果的に最大の生産性につながります。

なお、Hermesの詳細な運用設計は、別記事で公開予定です。

参考リンク