Hermes Agent Wiki 非公式・日本語wiki

トラブル

症状から原因と対処を引く表です。対処の詳細は各行のリンク先(公式準拠の日本語版ページ)にあります。ここに無い症状は よくある質問 へ。

このページはこのサイト独自のまとめです。全項目が公式ドキュメントの記述に対応しています(推測の対処は載せていません)。

症状 よくある原因 対処 詳細
Telegram に送っても返事がない ゲートウェイの停止。ボットトークンの設定ミス。許可一覧への未登録 `hermes gateway status` で稼働を確かめ、止まっていれば `hermes gateway start` で立ち上げます。`TELEGRAM_BOT_TOKEN` を見直し、`~/.hermes/logs/gateway.log` にエラーが出ていないかも確かめます。
ボットが「unauthorized」と返す 自分のユーザー ID が `TELEGRAM_ALLOWED_USERS` に入っていない @userinfobot で自分のユーザー ID を確かめ直し、`TELEGRAM_ALLOWED_USERS` に加えます。
Telegram の個人チャットでは返事があるのにグループでは黙っている BotFather のプライバシーモードが有効。グループ側の許可設定の漏れ プライバシーモードを切るか、ボットをグループの管理者にします。設定を変えたらボットを一度外して追加し直し、`TELEGRAM_GROUP_ALLOWED_CHATS` などの許可設定も確かめます。
Discord のボットはオンラインなのにメッセージへ応答しない Message Content Intent が無効。アクセス方針が未設定で拒否側に倒れている Developer Portal で Message Content Intent を有効にし、`DISCORD_ALLOWED_USERS` などのアクセス方針を設定します。そのあと `hermes gateway restart` で再起動します。
Slack の DM では動くのにチャンネルでは動かない `message.channels` / `message.groups` のイベント購読と履歴スコープの不足。チャンネルへの招待漏れ イベント購読と `channels:history` などのスコープを足し、アプリをワークスペースへ再インストールします。そのうえで `/invite @Hermes Agent` でボットをチャンネルに招待します。
WhatsApp のブリッジが落ちる、再接続を繰り返す WhatsApp 側のプロトコル変更によるセッションの無効化 ゲートウェイを再起動して Hermes を更新します。それでも直らなければ `hermes whatsapp` で連携し直します。
Signal の設定中に「Cannot reach signal-cli」と出る signal-cli のデーモンが動いていない `signal-cli --account +YOUR_NUMBER daemon --http 127.0.0.1:8080` でデーモンを立ち上げてから、設定をやり直します。
メール連携の起動時に「IMAP connection failed」と出る `EMAIL_IMAP_HOST` と `EMAIL_IMAP_PORT` の誤り。アカウント側で IMAP が無効 接続先とポート番号を確かめます。Gmail なら「設定 → メール転送と POP/IMAP」で IMAP を有効にします。
ゲートウェイが起動しない 依存パッケージの不足。ポートの取り合い。トークンの設定ミス `uv pip install -e ".[messaging]"` で依存を入れ直し、`lsof -i :8080` でポートの重なりを見ます。`hermes config show` で設定も確かめます。
WSL でゲートウェイが切れ続ける、`hermes gateway start` が失敗する WSL2 で systemd が有効になっていない。WSL の再起動や Windows のアイドル終了でサービスが落ちる systemd のサービスにせず、`hermes gateway run` をそのまま動かすか tmux の中で動かします。
MCP サーバーにつながらない サーバーの実行ファイルが見つからない。コマンドのパスの誤り。実行環境の不足 `node --version` などで実行環境を確かめ、サーバーのコマンドを手で動かして確認します。そのうえで `~/.hermes/config.yaml` の `mcp_servers` の記述を見直します。
Docker バックエンドにつながらない Docker のデーモンが動いていない。ユーザーの権限不足 `docker info` で稼働を確かめ、`sudo usermod -aG docker $USER` と `newgrp docker` で権限を足します。
API キーが通らない キーの未設定・期限切れ・書き間違い。別のプロバイダー用のキー `hermes config show` で今の設定を確かめ、`hermes model` でプロバイダーを設定し直します。`~/.hermes/.env` に食い違う記述が残っていないかも見ます。
モデルが見つからない、使えないと出る モデル名の誤り。そのプロバイダーでは提供されていない `hermes model` で使えるモデルを一覧し、正しい名前を設定します。`hermes chat --model <name>` でセッションごとに指定することもできます。
最初のチャットが Error 400 で失敗する モデル名の食い違い。API キーにそのモデルを使う権限がない `hermes config show` で設定中のモデルとプロバイダーを確かめ、`hermes model` で選び直します。OpenRouter を使っているなら残高も確かめます。
レート制限(429 エラー)が出る プロバイダー側の利用制限 少し待ってから実行し直します。日常的に当たるなら、プランを上げるか、別のモデルやプロバイダーへ振り分けます。
`/model` に 1 つのプロバイダーしか出てこない 設定済みのプロバイダーが 1 つだけ。`/model` は設定済みの範囲でしか切り替えられない セッションを抜けて、ターミナルから `hermes model` を実行してプロバイダーを足します。そのあと新しいチャットを開きます。
選択画面に「No authenticated providers」と出る 使える認証情報のあるプロバイダーが 1 つもない サイドバーの Keys で API キーや OAuth の登録を確かめます。無ければ `hermes setup` を実行して設定します。
モデルを選んだのにプロバイダーが切り替わっていた 集約サービスでは、素のモデル名がその集約サービスの内側で先に解決される 選択画面の先頭に出る現在のメインモデルとプロバイダーを見て、意図した組み合わせか確かめます。
定期実行のジョブが動かない ジョブが `[paused]` や `[completed]` になっている。ゲートウェイの停止 `hermes cron list` で状態と次の実行時刻を確かめます。ジョブは裏で回るゲートウェイが動かすので、`hermes gateway` を立ち上げておきます。
ジョブは走るのに何も届かない 配信先の書き方の誤り。出力が空。返答に `[SILENT]` が入っている 配信先の綴りと、その宛先のサービスが設定してあるかを確かめます。`hermes cron list` の `last_error` の欄も見ます。
定期実行で「Skill not found」と出る スケジューラの動く端末にスキルが入っていない。スキル名とフォルダ名の食い違い `hermes skills list` で正確な名前を確かめ、無ければ `hermes skills install <skill-name>` で入れます。
定期実行のジョブが止まったままになる、時間切れになる 動きが止まってからの時間が既定の 600 秒を超えた 環境変数 `HERMES_CRON_TIMEOUT` で上限を変えられます。長くかかる仕事は、データを集めるところをスクリプトに任せて結果だけを届けます。
定期実行のジョブが遅れる、飛ばされる ゲートウェイの二重起動による鍵の取り合い。同じ時刻へのジョブの集中 `ps aux | grep hermes` で重なって動いているゲートウェイを止め、1 つだけにします。ジョブの時刻も少しずつずらします。
コンテキスト長を超えたと出る 会話が長くなってモデルの枠を超えた。コンテキスト長の誤判定 `/compress` で会話を圧縮するか、新しいセッションを開きます。長い会話の 1 回目で出るなら、`config.yaml` の `model.context_length` に実際の値を書きます。
応答が遅い モデルの大きさ。API サーバーまでの遠さ。ツールを盛り込んだシステムプロンプトの重さ もっと速くて小さいモデルを試し、`hermes chat -t "terminal"` のように有効なツールセットを絞ります。ローカルモデルなら GPU の VRAM も確かめます。
トークンを使いすぎる 会話の長さ。システムプロンプトとツール定義の膨らみ `hermes prompt-size` で毎回送られる分の内訳を測り、使っていないツールセットとスキルを切ります。長いセッションでは `/compress` と `/usage` も併せて使います。
エージェントが前より賢くなくなった気がする 思っているのと違うモデルでセッションが動いている `/model` か `/status` で今のモデルとプロバイダーを確かめます。違っていれば `/model <name>` でそのセッションを直せます。
このセッションで覚えてと頼んだのに忘れている 記憶はセッションの開始時に固定された写しとしてシステムプロンプトへ入る 意図どおりの動きです。保存自体はすぐ済んでいて、システムプロンプトに現れるのは次のセッションからです。
前にできたことを「できない」と言う スキルが読み込まれていない。ツールセットが絞られている `/skills` と `/tools list` で読み込まれているものを確かめます。`/reload-skills` で読み直し、`/tools enable` でツールを戻します。
インストールしたのに `hermes: command not found` になる シェルが新しい PATH を読み直していない `source ~/.bashrc`(zsh なら `~/.zshrc`)を実行するか、新しいターミナルを開きます。`which hermes` で入った場所も確かめます。
ターミナル操作で `node: command not found` になる ログインシェルから写し取った環境に `nvm` や `pyenv` の設定が入っていない `~/.hermes/config.yaml` の `terminal.shell_init_files` に、読み込ませたいファイルを並べます。
コマンドが危険と判断されて止まる 破壊的な可能性のあるコマンドの検出 意図した動きです。確認を求められたら中身を読み、問題なければ許可します。判断されるパターンはセキュリティのページに載っています。
メッセージ経由だと `sudo` が使えない メッセージゲートウェイに対話できるターミナルがなく、パスワードを尋ねられない メッセージ経由では `sudo` を避け、別のやり方をエージェントに探してもらいます。管理作業は `hermes chat` に切り替えます。
端末を移したら設定や記憶が引き継がれない `~/.hermes/` の中身を移していない 移す元の端末で `hermes backup` を実行して zip を作り、新しい端末で `hermes import` を実行します。そのあと `hermes setup` で API キーとプロバイダーの設定を確かめます。