Hermes AI アシスタント - インストール、設定、ワークフロー、およびトラブルシューティング
Hermes エージェントの開発者向けインストールとクイックスタート
Hermes Agent は、ローカルマシンまたは低コストの VPS で動作し、ターミナルやメッセージングインターフェースを通じて機能し、繰り返し実行されるタスクを再利用可能なスキルに変換することで、時間とともに性能を向上させる、セルフホスト型でモデルに依存しない AI アシスタントです。
その機能面では、OpenClaw と非常に似ています。OpenClaw もまた、ツール、メモリ、ローカル制御を中心に構築された、セルフホスト型のアシスタントスタックです。
Hermes を取り巻くセルフホスト型アシスタント、検索、ローカルインフラストラクチャの全体像をご覧になりたい場合は、AI システムの概要 が、Hermes が解決しようとしている問題とそれらのトピックを結びつけています。
デプロイのトレードオフとランタイムの選択については、LLM ホスティング 2026: ローカル、セルフホスト、クラウドインフラの比較 がホスティング地図を提供し、LLM パフォーマンス 2026: ベンチマーク、ボトルネック、最適化 が、Hermes が稼働した後のスループットとレイテンシの側面をカバーしています。

私の偏った見解:Hermes は、たまに開くタブではなく、インフラストラクチャとして扱われる時に最も興味深いです。サービスとして動作し、安定したホームディレクトリを持って一旦運用されると、あなたのプロンプトは「チャット」のようなものから「オペレーション(ops)」のようなものへと変化していきます。
Hermes Agent とは何か、そしてなぜそれが重要なのか
Hermes Agent は、Nous Research によって構築されたオープンソースの AI エージェントです。これは永続的に動作し、ツール(ターミナル、ファイル、Web など)を使用し、スキルとメモリシステムを通じて時間をかけて自身の振る舞いを改善するように設計されています。
このガイドの残りの部分を形作るため、2 つの設計選択について詳しく説明する価値があります。
第一に、Hermes は単一のモデルプロバイダーにロックされません。公式のセットアップフローは複数のプロバイダーと任意の OpenAI 互換エンドポイントをサポートしており、切り替えはコードの編集ではなく hermes model コマンドを通じて行われます。
第二に、Hermes は「会話」と「実行」の間に明確な線引きをします。エージェントは一日中話すことができますが、行動が必要になった時、それは明示的なツールと構成可能な実行バックエンドを通じて行われます。そこには安全性、再現性、トラブルシューティングが存在します。
コストとライセンスは、なんとなく退屈なほどにシンプルです。Hermes Agent 自体は MIT ライセンスの下で無料ソフトウェアです。ホストされたモデルを使用する場合、継続的なコストはプロバイダーの料金の通りとなります。ローカルモデルを実行する場合、API 料金を完全に回避できます。
Hermes Agent のインストール
Hermes は、Linux、macOS、WSL2 向けの迅速なインストールパスを提供しています。公式ドキュメントは意図的にシンプルに保たれています。
1 行でのインストール
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
インストール後、シェルをリロードし、CLI を起動してください。
source ~/.bashrc # または 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 つの役割を果たします:ターミナルツールをチェックし、権限プロンプトを検証します。
例のプロンプト:
ディスク使用量と 5 つの最大のディレクトリを表示してください。
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} 構文による環境変数の置換もサポートしています。これは、特定の値を環境に保ちたいが、構造化された構成で参照したい場合に便利です。
スandbox と実行バックエンド
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.md や USER.md などのファイルとして保存され、Hermes はより深い想起のために外部メモリプロバイダーも使用できます。メモリドキュメントは複数のプロバイダープラグインをリストしており、メモリプロバイダーガイドはインタラクティブなセットアップフローを文書化しています。
同じマシンで複数の独立したエージェントを求めたい場合、Hermes プロファイルは分離を提供します。各プロファイルは、独自の構成、秘密情報、メモリ、セッション、スキル、cron ジョブ、ゲートウェイ状態を持つ独自のディレクトリを保有します。
典型的なワークフロー
Hermes を長く維持するエージェントとして扱う場合、ワークフローはサービスエンジニアリングのように見え始めます。
安定したベースライン
腐敗しにくいベースラインは以下の通りです。
- インストールし、CLI で最初のチャットを実行します。
hermes modelでプロバイダーとモデルを選び、コストを確認します。- ツールセットを構成し、ターミナル実行がローカルかサンドボックス化されるかを決めます。
- デフォルトをしばらく使用してから、
SOUL.mdのみを素早く変更します。アイデンティティの変更は、それがシステムプロンプトの「スロット 1」であるため、人々が予想する以上に重要です。
複利を生む日常利用
Hermes は Web UI ではなくターミナル UI を持ち、スラッシュコマンド、再開可能なセッション、ストリーミングツール出力を備えた長時間セッションのために設計されています。
実際には、有用なサイクルは以下の通りです。
- プロジェクト用に名前付きセッションで作業を実行
- コンテキストが大きくなりすぎたら圧縮
- Hermes に繰り返しルーチンをスキルに変換させる
- ツール実行を監査可能にするために「尋ねる」と「実行する」の間の精神的な境界を保つ
24 時間アクセスのためのメッセージングゲートウェイ
メッセージングゲートウェイは、Hermes をターミナルアプリではなくアシスタントのように感じさせる部分です。ドキュメントは、これを複数のプラットフォームに接続し、セッションを管理し、cron ジョブを実行し、メッセージを配信する単一プロセスとして説明しています。
セットアップは hermes gateway setup で呼び出され、ゲートウェイはフォアグラウンドまたはユーザーサービスとして実行できます。CLI 参照では、run、install、start、stop、status、restart などのゲートウェイサブコマンドが文書化されています。
ツールを使用するボットのセキュリティは重要です。ゲートウェイドキュメントは、特定のプラットフォーム向けのホワイトリストと、ワンタイムペアリングコードを発行し hermes pairing approve による承認を必要とする DM ペアリングフローについて説明しています。
ドラマのないアップデート
Hermes のアップデートはファーストクラスのコマンドです。アップデートガイドは hermes update、構成マイグレーションチェック、および hermes doctor と hermes 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 変数の欠落など、バックエンドごとの典型的な原因を指摘しています。また、サンドボックス構成に疑問がある場合、ローカルに戻ることは有効なデバッグ操作であると注記しています。
ゲートウェイの問題については、メッセージングガイドはホワイトリストとペアリングを安全なデフォルトとして強調しており、これは多くの「ボットが沈黙している」インシデントが実際には承認機能が働いているためであることを意味します。