Hermes AI アシスタント - インストール、設定、ワークフロー、およびトラブルシューティング

Hermes Agentのインストールと開発者向けクイックスタート

目次

Hermes Agent は、ローカルマシンまたは低コストのVPS上で動作する、自己ホスト型のモデル非依存AIアシスタントです。ターミナルやメッセージングインターフェースを通じて動作し、繰り返されるタスクを再利用可能なスキルに変換することで、時間を経るにつれて能力を向上させます。

その機能性は、ローカルLLM、検索、メモリ、ルーティング、観測性を統合したコヒーレントなローカルインフラストラクチャを構築する別の自己ホスト型アシスタントスタックである OpenClaw と非常に類似しています。多くの開発者は、2026年4月にAnthropicがOpenClawのClaudeサブスクリプションアクセスをブロックした後にHermesへと移行しました。なぜHermesが、プロバイダーへの依存なしで永続的な自己ホスト型自動化を求めるユーザーにとって自然な選択となったのかについては、OpenClawの台頭と衰退のタイムライン で解説されています。

Hermesを取り巻く自己ホスト型アシスタント、検索、ローカルインフラストラクチャの全体像を知りたい場合は、Hermesが解決しようとしている問題と関連するこれらのトピックを結びつける AIシステムの概要 を参照してください。

デプロイメントのトレードオフやランタイムの選択については、LLMホスティング in 2026: ローカル、自己ホスト型、およびクラウドインフラストラクチャの比較 がホスティングのマップを提供し、Hermesが稼働し始めた後のスループットとレイテンシについては、LLMパフォーマンス in 2026: ベンチマーク、ボトルネック、および最適化 がカバーしています。シェルコマンド(hermes gatewayhermes memoryhermes doctor、スラッシュショートカットなど)のコンパクトなマップが必要な場合は、Hermes Agent CLIチートシート を使用してください。メインのエントリーポイントがモバイルでのメッセージングである場合は、音声スタックとプラットフォーム固有の設定については Hermes Voice Control from Your Phone を参照してください。

peronal-ai-assistant on laptop

私の個人的な見解としては、Hermesは時々開くタブとして扱うのではなく、インフラストラクチャとして扱うときに最も興味深いです。サービスとして実行され、安定したホームディレクトリを持てば、プロンプトは「チャット」らしくなくなり、「運用(ops)」らしくなります。

Hermes Agent とは何か、そしてなぜそれが重要なのか

Hermes Agent は、Nous Research によって構築されたオープンソースのAIエージェントです。永続的に実行され、ツール(ターミナル、ファイル、Webなど)を使用し、スキルおよびメモリシステムを通じて自身の動作を時間とともに改善するように設計されています。

このガイドの残りの部分に影響を与える2つの設計選択について、詳しく説明する価値があります。

まず、Hermesは単一のモデルプロバイダーにロックインされていません。公式のセットアップフローは複数のプロバイダーとOpenAI互換のエンドポイントをサポートしており、切り替えはコードの編集ではなく hermes model コマンドで行われます。

次に、Hermesは「会話」と「実行」の間に明確な線を引きません。エージェントは一日中会話できますが、行動が必要な場合は、明示的なツールと構成可能な実行バックエンドを通じて実行します。安全性、再現性、トラブルシューティングはここにあります。

コストとライセンスは、ほっとするようなほど地味です。Hermes Agent自体は、MITライセンスの下でのフリーソフトウェアです。ホスト型モデルを使用する場合、継続的なコストはプロバイダーが請求する金額です。ローカルモデルを実行する場合、API手数料を完全に回避できます。

Hermesのセットアップが外部ツールレイヤーを通じてClaudeを使用している場合、このAnthropicのサブスクリプション変更 は、なぜAPIベースの課金が現在期待されるパスなのかを理解するのに有用な参照となります。

Hermes Agent のインストール

Hermesには、Linux、macOS、WSL2向けの高速なインストールパスがあります。公式ドキュメントは意図的にシンプルに保たれています。

Linux での Hermes のインストール

sudo apt-get update
sudo apt-get upgrade
sudo apt-get curl git
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

インストール後、シェルをリロードし、CLIを開始します。

source ~/.bashrc   # or source ~/.zshrc
hermes

インストーラーは単なる薄いラッパーではありません。インストールガイドによると、依存関係、リポジトリ、仮想環境、および hermes コマンドを設定し、最初のチャット準備状態に達するようにします。

Windows と Android に関する注意

ネイティブWindowsはサポートされていません。ドキュメントではWSL2を使用し、その中でHermesを実行することを推奨しています。

Androidの場合、HermesはTermuxインストールパスをサポートしています。Termuxを検出し、それに応じて依存関係と環境設定に適応するように設計されています。

クイックスタート

最速の最初の起動は文字通り hermes を実行するだけですが、意味のあるクイックスタートには、使用するモデルプロバイダーと有効にするツールの2つの追加決定が必要です。

プロバイダーとモデルの選択

Hermesは3つの補完的なエントリーポイントを公開しています:

  • hermes model でプロバイダーとデフォルトのモデルを選択
  • hermes tools でツールセットを有効または無効にする
  • hermes setup で主要な構成領域にわたってインタラクティブなウィザードを実行

最小限のフローは以下のようになります:

hermes model
hermes tools
hermes

実際にサポートされているものに関して、公式クイックスタートは範囲の広さをリストし、HermesがOpenAI互換APIと動作することを指摘しています。これは、ホスト型サービスと自己ホスト型エンドポイントの両方を含むため重要です。

早期にツール実行を証明する

Hermes围绕する習慣を築く前に、環境でツール使用が機能するかを確認する価値があります。クイックスタートでは、最初の機能としてターミナル使用を明確に提案しています。

実際には、小さな「スモークテスト」プロンプトは2つの役割を果たします:ターミナルツールをチェックし、権限プロンプトを検証します。

例のプロンプト:

Show my disk usage and the five largest directories.

Hermesがターミナルツールを実行できない場合、トラブルシューティングに進んでください。ターミナルバックエンドの誤設定は最も一般的な原因の一つであり、構成を見ると修正方法が通常明らかになります。

拡張できる構成

Hermesは、状態をどこに保存し、構成をどのように解決するかを理解する人を報います。これもまた、多くの「昨日は動いていた」問題の原因となります。

構成と状態の保存場所

Hermesは設定と状態を ~/.hermes 以下に保存します。公式構成ガイドは、設定用の config.yaml、シークレット用の .env、OAuth資格情報用の auth.json、アイデンティティ用の SOUL.md、およびメモリ、スキル、cron、セッション、ログ用のフォルダを含むレイアウトを文書化しています。

これは2つの理由で重要です。

  • デバッグは機械的になります。なぜなら、どこを見るべきかが正確に分かるからです。
  • バックアップは単純になります。なぜなら、1つのディレクトリが気にしているエージェント状態の大部分をキャプターするからです。

構成の優先順位と config.yaml からシークレットを排除する

Hermesは優先順位順序で構成を解決します。最上位はCLIオーバーライド、次に config.yaml、次に .env、最下位はビルトインデフォルトです。

良い詳細は、hermes config set が値を正しいファイルにルーティングすることです:APIキーは .env に、非シークレット設定は config.yaml に。

hermes config set model openrouter/meta-llama/llama-3.1-70b-instruct
hermes config set terminal.backend docker
hermes config set OPENROUTER_API_KEY sk-or-v1-xxxxxxxx

Hermesはまた、config.yaml 内部で ${VAR_NAME} 構文による環境変数置換をサポートしています。これは、構造化された構成で参照しながら、特定の値を環境内に保持したい場合に有用です。

サンドボックスと実行バックエンド

Hermesは、シェルコマンドが実際にどこで実行されるかを定義する複数のターミナルバックエンドをサポートしています。構成ガイドは、local、docker、ssh、modal、daytona、singularityをリストしています。

意見的だが布教的ではない考え方は以下の通りです:

  • local は最も速くシンプルですが、分離されていません
  • docker は実用的な安全性と再現性のレイヤーです
  • ssh は、チャットデバイスとコンピュートボックスを分離するクリーンな方法です
  • modal と daytona は「サーバーレスだが十分に永続的」なワークフローに適合します
  • singularity はHPCフレンドリーなオプションです

最小限のDockerバックエンドの例:

# ~/.hermes/config.yaml
terminal:
  backend: docker
  docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
  docker_volumes:
    - "/home/user/projects:/workspace/projects"
  docker_forward_env:
    - "GITHUB_TOKEN"

ドキュメントはまた、Dockerバックエンドのセキュリティ強化、例えば機能のドロップや権限エスカレーションの無効化についても説明しています。

スキル、メモリ、プロファイル

Hermesには、価値を複利させるための2つの関連メカニズムがあります。

スキルは手続き型メモリです。Hermesは独自のスキルを作成、更新、削除でき、複雑なタスクを完了した後、アプローチをスキルとして保存するよう提案できます。

ビルトインメモリは ~/.hermes 以下の MEMORY.mdUSER.md などのファイルとして保存され、Hermesはより深いリコールのために外部メモリプロバイダーも使用できます。メモリドキュメントは複数のプロバイダープラグインをリストし、メモリプロバイダーガイドはインタラクティブなセットアップフローを文書化しています。メモリアーキテクチャがどのように機能するか — フローズンスナップショット、文字数制限、8つの外部プロバイダー、および有界メモリ背後の哲学 — に関する完全な技術的な分解については、Hermes Agent Memory System: How Persistent AI Memory Actually Works を参照してください。

同じマシン上で複数の独立したエージェントが欲しい場合、Hermesプロファイルは分離を提供します。各プロファイルは、独自の構成、シークレット、メモリ、セッション、スキル、cronジョブ、およびゲートウェイ状態を持つ独自のディレクトリを取得します。

役割別(エンジニア、研究者、オペレーター、およびエグゼクティブワークフロー)に、本番環境でどのスキルがよく機能するかについてより深く見るためには、Hermes AI Assistant Skills for Real Production Setups を参照してください。SKILL.md ファイル自体を記述またはデバッグする準備ができたとき — YAMLメタデータ、プログレッシブディスクロージャーレベル、条件付き可視性、およびハブインストール — Hermes Agent Skill Authoring — SKILL.md Structure and Best Practices を使用してください。

典型的なワークフロー

Hermesを維持するエージェントのように扱う場合、ワークフローはサービスエンジニアリングのように見えます。

安定したベースライン

腐りにくい傾向のあるベースラインは以下の通りです:

  1. CLIで最初のチャットをインストールして実行。
  2. hermes model でプロバイダーとモデルを選び、コストを確認。
  3. ツールセットを構成し、ターミナル実行がローカルかサンドボックス化されているかを決定。
  4. デフォルトをしばらく使用した後、SOUL.md にわずかな変更を加える。アイデンティティの変更は、人々が期待するよりも重要です。なぜなら、それはシステムプロンプトの「スロット1」だからです。

複利する日常的使用

HermesにはWeb UIではなくターミナルUIがあり、スラッシュコマンド、再開可能なセッション、およびストリーミングツール出力を備えた長時間セッションのために設計されています。

実際には、有用なリズムは以下の通りです:

  • プロジェクトの命名されたセッションで作業を実行
  • コンテキストが大きくなりすぎたときにコンテキストを圧縮
  • Hermesに繰り返されるルーティンをスキルに変換させる
  • ツール実行が監査可能になるように、「尋ねる」と「行動する」の間に精神的な境界を保つ

24/7アクセスのためのメッセージングゲートウェイ

メッセージングゲートウェイは、Hermesをターミナルアプリではなくアシスタントのように感じさせる部分です。ドキュメントでは、複数のプラットフォームに接続し、セッションを処理し、cronジョブを実行し、メッセージを配信する単一のプロセスとして説明されています。

セットアップは hermes gateway setup で呼び出され、ゲートウェイはフォアグラウンドまたはユーザーサービスとして実行できます。CLIリファレンスは、runinstallstartstopstatus、および restart などのゲートウェイサブコマンドを文書化しています。

マルチエージェントバックログと制御されたスケジューリングについては、Kanban in Hermes Agent for Self Hosted LLM Workflows を参照してください。これは、ディスパッチャーの制限、依存チェーン、およびcronベースのバッチ処理をカバーしています。

ツールを使用するボットのセキュリティは重要です。ゲートウェイドキュメントは、特定のプラットフォームのホワイトリストと、ワンタイムペアリングコードを発行し、hermes pairing approve による承認を必要とするDMペアリングフローを説明しています。

問題のないアップデート

Hermesのアップデートはファーストクラスコマンドです。アップデートガイドは hermes update、構成マイグレーションチェック、および hermes doctorhermes gateway status を含む小さなアップデート後検証ルーチンを文書化しています。

hermes update
hermes doctor
hermes gateway status

トラブルシューティングと診断

ほとんどのHermesの失敗は謎ではありません。謎のように見えるのは、人々がモデルレイヤーのみをチェックし、ランタイムレイヤーを無視するためです。

快速のトリアージコマンド

CLIリファレンスは、3つのコマンドをコアループとして明確に位置づけています:

  • hermes doctor でインタラクティブな診断
  • hermes status でクイックな概要
  • hermes dump で共有可能で編集済みのセットアップサマリー

ログについては、hermes logs~/.hermes/logs 以下に保存されたファイルをテールします。

hermes doctor --fix
hermes status
hermes dump --show-keys
hermes logs errors -f

一般的なインストール失敗

FAQとトラブルシューティングガイドは、Pythonバージョンの問題、uv が見つからないこと、およびsudoインストールとユーザーインストールを混在させることによる権限問題を含む、いくつかの再発する問題とそれらの修正をリストしています。

これらのエラーに遭遇した場合、ドキュメントはPythonのアップグレード、uv のインストール、およびsudoなしでHermesの再インストールなどの具体的な修復手順を提供しています。

プロバイダーとモデルの問題

APIキーが機能しない場合、FAQは構成をチェックし、hermes model を再実行するか、hermes config set を介してキーを直接設定することを推奨しています。また、一般的な落とし穴として、キーはプロバイダー固有であることを指摘しています。

「モデルが見つかりません」の問題について、FAQは有効な識別子を選ぶために hermes model を使用することに戻り、構成とセッションごとのオーバーライドの両方を見せています。

レート制限とコンテキスト長の問題もカバーされています。FAQは429エラーを待機し、プロバイダーまたはモデルを切り替え、圧縮または新しいセッションを介してコンテキスト圧力を低減することを提案しています。

ターミナルバックエンドとゲートウェイの問題

ターミナルコマンドが直ちに失敗する場合、構成ガイドには「一般的なターミナルバックエンドの問題」セクションが含まれ、Dockerが実行されていないことやSSH変数が欠落していることなどのバックエンドごとの典型的な原因を指摘しています。また、サンドボックス構成が疑問符の場合、ローカルにフォールバックすることは有効なデバッグ手順であることを注記しています。

ゲートウェイの問題については、メッセージングガイドは、多くの「ボットが沈黙している」インシデントが実際には認可が機能していることを意味する、安全なデフォルトとしてのホワイトリストとペアリングを強調しています。

参考文献

購読する

システム、インフラ、AIエンジニアリングの新記事をお届けします。