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

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

Hermes Agentは、ローカルマシンや低コストのVPS上で動作する自己ホスト型でモデル非依存のAIアシスタントであり、ターミナルおよびメッセージングインターフェースを介して動作し、繰り返し行うタスクを再利用可能なスキルに変換することで、時間とともに性能を高めていきます。

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

Hermesを取り巻く自己ホスト型アシスタント、検索、ローカルインフラストラクチャの全体像を知りたい場合は、AIシステムの概要で、Hermesが解決しようとしている問題とそれらのトピックがどのように結びついているかを参照してください。HermesとOpenClawを参考実装とした5層のアシスタントモデル（LLM、メモリ、ツール、ルーティング、観測性）については、AIアシスタントアーキテクチャをご覧ください。具体的な採用データ（GitHubスター数、OpenRouterの1日あたりのトークン数、PyPIのダウンロード数、CVEの履歴、Redditコミュニティの世論など）については、OpenClaw vs Hermes Agent: スター数、ダウンロード数 & 2026年の利用状況で、Hermesが19の代替案と比較して、すべての測定可能な指標においてどのように比較されるかを追跡できます。

デプロイメントのトレードオフとランタイムの選択については、2026年のLLMホスティング：ローカル、自己ホスト型 & クラウドインフラストラクチャの比較でホスティングマップが提供されており、2026年のLLMパフォーマンス：ベンチマーク、ボトルネック & オプティマイゼーションでは、Hermesの実行後のスループットとレイテンシ側がカバーされています。Ollamaなどのローカルランタイム上でQwenやGemmaをHermesで使用する場合は、QwenおよびGemma向けのエージェント型LLM推論パラメータを使用して、マルチステップツール使用のための温度やペナルティプリセットを統合してください。シェルコマンドのコンパクトなマップ（hermes gateway、hermes memory、hermes doctor、スラッシュショートカットなど）が必要な場合は、Hermes Agent CLIチートシートを使用してください。モバイルでのメッセージングが主なエントリポイントである場合は、音声スタックとプラットフォーム固有の設定のためにHermesのスマートフォンからの音声制御を使用してください。

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

スケーラブルな構成

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はまた、${VAR_NAME} 構文を通じて config.yaml 内の環境変数置換をサポートしています。これは、構造化された構成で参照しながら、特定の値を環境内で保持したい場合に便利です。

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

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はより深い想起のために外部メモリプロバイダーも使用できます。メモリドキュメントは複数のプロバイダープラグインをリストしており、メモリプロバイダーガイドはインタラクティブなセットアップフローを文書化しています。メモリアーキテクチャの仕組み（フリーズされたスナップショット、文字数制限、8つの外部プロバイダー、および有界メモリ背後にある哲学）の完全な技術的解説については、Hermes Agentメモリシステム：永続的なAIメモリが実際にどのように機能するかをご覧ください。

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

役割による生産環境でよく機能するスキル（エンジニア、研究者、オペレーター、およびエグゼクティブワークフロー）の詳細については、本番環境セットアップ向けのHermes AIアシスタントスキルをご覧ください。SKILL.md ファイル自体の作成やデバッグ（YAMLメタデータ、プログレッシブディスクロージャーレベル、条件付き可視性、およびハブインストール）に備える準備ができたら、Hermes Agentスキル作成 — SKILL.md構造とベストプラクティスを使用してください。

典型的なワークフロー

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

安定したベースライン

腐りにくいベースラインは次の通りです：

CLIでインストールし、最初のチャットを実行します。
hermes model でプロバイダーとモデルを選択し、コストを確認します。
ツールセットを構成し、ターミナル実行がローカルかサンドボックス内かを決めます。
デフォルトをしばらく使用した後、SOUL.md にわずかな変更を加えます。アイデンティティの変更は、システムプロンプトの「スロット1」であるため、人々が予想するよりも重要に影響します。

複利で増加する日常使用

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

実際には、有用なリズムは次の通りです：

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

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

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

セットアップは hermes gateway setup で呼び出され、ゲートウェイはフォアグラウンドまたはユーザーサービスとして実行できます。CLIリファレンスは、run、install、start、stop、status、restart などのゲートウェイサブコマンドを文書化しています。このゲートウェイモデルを専用サーバーで実行しながら、別のデスクトップクライアントから接続したい場合は、Hermes Agentヘッドレスサーバーとリモートデスクトップセットアップを使用してください。

マルチエージェントバックログと制御されたスケジューリングについては、自己ホスト型LLMワークフロー向けのHermes AgentでのKanbanで、ディスパッチャー制限、依存チェーン、およびcronベースのバッチ処理がカバーされています。

ツールを使用するボットのセキュリティは重要です。ゲートウェイドキュメントは、特定のプラットフォーム向けの_allowlist_と、ワンタイムペアリングコードを発行し、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変数が欠落しているなど、バックエンドごとの典型的な原因を指しています。また、サンドボックス構成が疑問視される場合、ローカルにフォールバックすることは有効なデバッグ手法であると述べています。

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