Windows起動だけで常時稼働！Hyper-V × Ubuntuで作るHermes Agent実運用環境

投稿日: 2026.8.21

今回の目標は、Windowsへログインしてアプリを開かなくても、PCの電源を入れればバックグラウンドで復旧し、スマートフォンのTelegramから使える状態にすることでした。

Hermes専用のUbuntu ServerをHyper-V上に用意し、LinuxのsystemdとHyper-Vの自動起動を組み合わせています。Telegram Gatewayに加え、Web Dashboard、Chromium CDP、LiteLLM、Context Mode MCP、Skill、毎朝のニュース配信Cronまで、実際に構築した順序と途中で遭遇したエラーを残します。

バージョン差異について

本記事は2026年8月に構築した環境をもとにしています。Hermes Agentは更新が速いため、CLIの質問項目、サービス名、Node.jsやPlaywright Chromiumのバージョン別パスは変わる可能性があります。固定値をコピーする前に、各確認コマンドで自分の環境の値を確認してください。

1. 完成した構成

flowchart TD PC[Windows 11 起動] --> HV[Hyper-V] HV --> VM[Ubuntu Server 24.04 LTS] VM --> GW[Hermes Gateway] VM --> DB[Web Dashboard :9119] VM --> CH[Chromium CDP :9222] GW --> TG[Telegram] GW --> HM[Hermes Agent] HM --> CM[Context Mode MCP] HM --> SK[Custom Skills] HM --> LL[LiteLLM / OpenAI Codex] LL --> LLM[OpenRouterなどのLLM] SK --> CR[Cron: 毎朝7時] CR --> TG

起動シーケンスは次のとおりです。

PC電源ON
  ↓
Windows 11起動
  ↓
Hyper-VがUbuntu VMを自動起動
  ↓
systemdがGateway・Dashboard・Chromiumを起動
  ↓
TelegramからHermesを利用可能

2. なぜWSL2ではなくHyper-Vを選んだのか

WSL2でもsystemdは利用できます。ただし今回の判断基準は、systemdの有無ではなく、Windowsへユーザーがログインする前からHermesを起動できることでした。Hyper-VならAutomaticStartAction StartでVMの起動条件を明示でき、Ubuntu内のサービス管理は通常のLinuxサーバーと同じ手順にできます。

Hermesにシェル実行やファイル操作を許可するため、普段使いのWindows環境からVMを分離できる点も今回の要件に合いました。代わりに、VM用のメモリとディスクを確保し、Ubuntuの更新・バックアップ・ネットワークを別途管理する必要があります。導入の軽さより、起動経路の明確さと分離を優先した選択です。

3. Step 1：Hyper-VにUbuntu Server VMを作る

今回のVM設定は次のとおりです。

項目	設定
OS	Ubuntu Server 24.04 LTS
VM名	Hermes-Ubuntu
世代	第2世代
CPU	2 vCPU
起動RAM	4GB
動的メモリ	ON（最小2GB、最大8GBを目安）
仮想ディスク	40〜60GB
ネットワーク	外部仮想スイッチ（LAN接続用の物理NICに接続）
IPアドレス	LAN側のDHCP
OpenSSH Server	ON

今回は最初からDefault Switchを使わず、Ubuntu VMが同じLANまたはVLAN上の別PCから到達できるよう、外部仮想スイッチを作成します。

Hyper-Vマネージャーで「仮想スイッチマネージャー」を開く
「新しい仮想ネットワークスイッチ」で「外部」を選び、「仮想スイッチの作成」を押す
分かりやすい名前（例：External-LAN）を入力する
「外部ネットワーク」で、Windows PCがLAN接続に使っている物理NICを選ぶ
「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」を有効にして適用する
Ubuntu VMの作成時または「設定」→「ネットワークアダプター」で、作成したExternal-LANを選ぶ

有線LANを使う場合はEthernetアダプター、無線LANを使う場合はWi-Fiアダプターを選びます。VPN用や未使用のアダプターを誤って選ばないよう、Windowsの「ネットワーク接続」で使用中のNIC名を事前に確認してください。

外部仮想スイッチ作成時の注意

外部仮想スイッチの作成時は、Windowsホストのネットワーク接続が一時的に切り替わることがあります。リモート接続中ではなく、PCを直接操作できる状態で実施してください。会社や学校などの管理ネットワークでは、VMへのIPアドレス付与や端末追加が禁止されている場合があるため、ネットワーク管理者の方針も確認します。

Ubuntu Serverのインストール中に Install OpenSSH server を有効にすると、以後はWindows PowerShellや同じLAN上の別PCから管理できます。

ssh <Ubuntuのユーザー名>@<UbuntuのIPアドレス>

Ubuntu側のIPアドレスは次で確認します。

hostname -I

Telegram Gatewayは外向き通信で動くため、Telegramだけなら固定IPは不要です。SSHやDashboardへ継続的に接続する場合は、後からルーターのDHCP予約を設定すると管理しやすくなります。

作業前にチェックポイントを作る

Ubuntuのインストール直後と、Hermesの基本設定完了後にHyper-Vのチェックポイントを作っておくと、設定を壊してもすぐに戻せます。

4. Step 2：Ubuntuを更新して依存パッケージを入れる

sudo apt update
sudo apt upgrade -y
sudo apt install -y curl git libatomic1

今回、libatomic1がない状態ではHermesが管理するNode.jsの起動時に次のエラーが発生しました。

node: error while loading shared libraries:
libatomic.so.1: cannot open shared object file

少なくとも今回のUbuntu 24.04環境では、Hermesのインストール前にlibatomic1を入れることで、この共有ライブラリエラーを回避できました。

タイムゾーンも日本時間へ合わせます。

sudo timedatectl set-timezone Asia/Tokyo
timedatectl

期待値は次のとおりです。

Time zone: Asia/Tokyo (JST, +0900)

5. Step 3：Hermes Agentをインストールする

公式インストーラーを実行します。

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

この形式は取得したスクリプトをそのまま実行します。変更管理が必要な環境では、一度ファイルへ保存して内容を確認してから実行してください。

curl -fsSLo /tmp/hermes-install.sh https://hermes-agent.nousresearch.com/install.sh
less /tmp/hermes-install.sh
bash /tmp/hermes-install.sh

インストール後、シェルを再読み込みして確認します。

source ~/.bashrc
hermes --version
hermes doctor

Hermesの主なファイルはホームディレクトリの .hermes 以下に作られます。

~/.hermes/
├── config.yaml      # 本体設定
├── .env             # APIキーなどの秘密情報
├── cron/            # Cronジョブ
├── logs/            # ログ
├── sessions/        # セッション
├── skills/          # ユーザーSkill
└── hermes-agent/    # 本体コード

今回の最終状態では、Git、Node.js、agent-browser、Playwright Chromium、SQLite/FTSなどが認識され、systemd lingerも有効になりました。

6. Step 4：使用するLLMを設定する

6.1. ChatGPT / Codexサブスクリプションを使う

hermes model

メニューから ChatGPT or Codex Subscription に相当する項目を選びます。表示されたURLとデバイスコードをWindows側のブラウザで開いてOAuth認証すればよいため、Ubuntu ServerにGUIブラウザは不要です。

認証後、CLIを起動して応答を確認します。

hermes

6.2. LiteLLM Proxyを使う

複数モデルの切り替えやAPIキー管理を一元化するため、最終的に次の構成も追加しました。

Hermes
  ↓ OpenAI互換API
LiteLLM Proxy
  ├─ OpenRouter
  ├─ OpenAI
  ├─ Anthropic
  └─ その他のモデル

再度 hermes model を開き、Custom endpointを選択します。

Base URL: https://<LiteLLMのホスト名>/v1
API Key: <LiteLLMのMaster KeyまたはVirtual Key>
Model: <LiteLLM側のmodel_name>
API compatibility mode: Chat Completions
Context length: 空欄（まずは自動判定）

APIキーは~/.hermes/.envへ保存されます。ブログやGitリポジトリへ公開せず、読み取り権限も所有者だけに絞ります。

chmod 600 ~/.hermes/.env
hermes config
hermes gateway restart

Telegramでは /new を送り、新しいモデル設定を使うセッションへ切り替えます。

6.3. reasoning_effortが400になる場合

Kimi K3など一部モデルでは、Hermesが送る reasoning_effort をバックエンドが受け付けず、次のエラーになることがあります。

litellm.UnsupportedParamsError:
openrouter does not support parameters: ['reasoning_effort']

Hermes側の推論設定を全モデルで無効化するのではなく、LiteLLM Proxy側で非対応パラメータを除外しました。LiteLLMの config.yaml へ次を追加します。

litellm_settings:
  drop_params: true

LiteLLMを再起動した後、Hermes Gatewayも再起動します。

7. Step 5：Telegram Gatewayを設定する

Telegramの @BotFather でBotを作成し、Bot Tokenを控えます。次にHermesのセットアップを開始します。

hermes gateway setup

既存Botを使う場合は Manual を選び、次の2点を入力します。

Telegram Bot Token
Telegramの数値User ID

User IDは @username ではありません。@userinfobot などで確認できる数値です。

Allowed User IDは必ず制限する

Botを見つけた第三者からHermesへ指示されないよう、Allowed User IDには自分のTelegram数値IDを必ず設定してください。Bot Tokenもパスワードと同じ秘密情報として扱います。

自動起動を設定する前に手動でテストします。

hermes gateway

Telegramから「こんにちは」などと送り、返信が返ることを確認したら Ctrl+C で停止します。

8. Step 6：GatewayをOS起動時から常駐させる

Hyper-V上のサーバー用途では、boot-time system serviceとして導入します。

sudo hermes gateway install --system
sudo hermes gateway start --system
sudo hermes gateway status --system

ログは次で確認できます。

journalctl -u hermes-gateway -f

Hermesのバージョンやインストール方式によってはユーザーサービスが使われることもあります。その場合は実際のサービス名を確認してください。

systemctl --user list-units --type=service | grep hermes

通常の操作では次のCLIも使えます。

hermes gateway status
hermes gateway restart
hermes gateway stop
hermes gateway start

設定を大きく変更した後は、restartではなく完全停止と起動を分けた方が確実な場合があります。

9. Step 7：Hyper-V VMをWindowsと連動して起動する

Windowsの管理者PowerShellで実行します。

Set-VM -Name "Hermes-Ubuntu"   -AutomaticStartAction Start   -AutomaticStartDelay 30   -AutomaticStopAction ShutDown

設定を確認します。

Get-VM -Name "Hermes-Ubuntu" |
  Select-Object Name, AutomaticStartAction, AutomaticStartDelay, AutomaticStopAction

Windows起動の30秒後にUbuntu VMが起動し、Windows終了時にはUbuntuへ正常シャットダウンが送られます。

10. Step 8：Web Dashboardを常駐させる

同じLANまたは到達可能なVLAN上のPCから直接開けるよう、Dashboardを0.0.0.0へバインドして手動起動します。これによりUbuntu VMの全ネットワークインターフェースで9119番ポートを待ち受けます。

hermes dashboard --host 0.0.0.0 --port 9119 --no-open

which hermes で実行パスを確認後、~/.config/systemd/user/hermes-dashboard.service を作成します。<USER>はUbuntuのユーザー名へ置き換えます。

[Unit]
Description=Hermes Agent Web Dashboard
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
WorkingDirectory=/home/<USER>/.hermes/hermes-agent
Environment=HOME=/home/<USER>
EnvironmentFile=-/home/<USER>/.hermes/.env
ExecStart=/home/<USER>/.local/bin/hermes dashboard --no-open --host 0.0.0.0 --port 9119
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

ユーザーがログインしていなくてもユーザーサービスを起動するため、lingerを有効にします。

sudo loginctl enable-linger "$USER"
systemctl --user daemon-reload
systemctl --user enable --now hermes-dashboard.service
systemctl --user status hermes-dashboard.service
ss -ltnp | grep 9119
curl http://127.0.0.1:9119/api/status

10.1. 同じLANまたはVLANの別PCからDashboardへ直接接続する

Step 1でVMを外部仮想スイッチへ接続しているため、UbuntuはLAN側のDHCPからIPアドレスを取得します。Ubuntu側で接続先となるアドレスを確認します。

hostname -I
ip -br address

表示されたアドレスのうち、別PCと同じLANまたはルーティング可能なVLANに属するものを使用します。継続利用する場合は、ルーターまたはDHCPサーバーで予約しておくと接続先が変わりません。

別PCのPowerShellから9119番ポートへの到達性を確認します。

Test-NetConnection <UbuntuのLAN内IP> -Port 9119

TcpTestSucceeded : Trueなら、別PCのブラウザでUbuntu VMのIPアドレスを指定して開けます。

http://<UbuntuのLAN内IP>:9119

UFWを有効にしている場合は、9119番ポートを無条件に開けず、接続を許可するLANまたはVLANのCIDRだけに限定します。

sudo ufw status
sudo ufw allow from <接続を許可するLANのCIDR> to any port 9119 proto tcp

たとえば利用中のネットワークが192.168.10.0/24なら、プレースホルダーをそのCIDRへ置き換えます。実際のネットワーク範囲が分からない場合は、ルーターやネットワーク管理者へ確認してください。

接続できない場合は、Dashboardの待受アドレス、サービス状態、UFWを順に確認します。

systemctl --user status hermes-dashboard.service
ss -ltnp | grep 9119
sudo ufw status

ssの結果が127.0.0.1:9119なら別PCからは接続できません。systemd unitの--host 0.0.0.0を確認し、変更後に再読み込みして再起動します。

systemctl --user daemon-reload
systemctl --user restart hermes-dashboard.service

10.2. SSHトンネルを使う場合

9119番ポートをLANへ公開したくない場合は、Dashboardを127.0.0.1へ戻し、SSHトンネルを使用できます。この方法では、別PCからUbuntu VMのSSHポートへ接続できる必要があります。

ssh -N -L 9119:127.0.0.1:9119 <USER>@<UbuntuのLAN内IP>

接続中は別PCでhttp://127.0.0.1:9119を開きます。SSHトンネルは必須ではなく、DashboardをLANへ直接公開しないための選択肢です。

Dashboardをインターネットへ直接公開しない

Dashboardには設定、セッション、Cron、Skillなどの情報があります。0.0.0.0へバインドする場合は、利用中のHermesバージョンでBasic認証の設定方法をhermes dashboard --helpから確認し、UFWでも接続元を信頼できるLANまたはVLANへ限定してください。ルーターで9119番ポートを転送せず、インターネットへは公開しません。

初回起動や更新直後は npm ci とWeb UIビルドに時間がかかり、サービスがactiveでもポートがまだ開かないことがあります。次のログで確認してください。

journalctl --user -u hermes-dashboard.service -f

11. Step 9：ChromiumをCDPで常駐させる

Playwright ChromiumをCDPポート9222で常駐させます。まず実際のパスを探します。

find ~/.cache/ms-playwright -type f -name chrome

~/.config/systemd/user/hermes-chromium.service を作成します。<CHROMIUM_PATH>と<USER>は実環境の値へ置き換えます。

[Unit]
Description=Chromium CDP Browser for Hermes Agent
After=network.target

[Service]
Type=simple
ExecStart=<CHROMIUM_PATH> --headless=new --no-sandbox --disable-dev-shm-usage --remote-debugging-address=127.0.0.1 --remote-debugging-port=9222 --user-data-dir=/home/<USER>/.hermes/chrome-debug --no-first-run --no-default-browser-check about:blank
Restart=always
RestartSec=5

[Install]
WantedBy=default.target

有効化して疎通を確認します。

systemctl --user daemon-reload
systemctl --user enable --now hermes-chromium.service
systemctl --user status hermes-chromium.service
curl http://127.0.0.1:9222/json/version

JSON内に webSocketDebuggerUrl が返ればCDPは起動しています。~/.hermes/.env へ接続先を追加します。

BROWSER_CDP_URL=http://127.0.0.1:9222

Gatewayを再起動し、Telegramで /new を送ってからブラウザ操作をテストします。

--no-sandboxについて

今回のUbuntu VMではChromiumのsandboxエラーを回避するため --no-sandbox を使用しました。CDPは127.0.0.1だけにバインドし、9222番ポートをLANやインターネットへ公開しない構成にしています。

12. Step 10：Context Mode MCPを追加する

大きなログ、Webページ、大量JSON、複数ファイルをそのままLLMへ流さず、必要部分だけHermesへ返すためContext Mode MCPを追加しました。

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"
npm install -g context-mode
which context-mode
context-mode --version

~/.hermes/config.yaml の既存設定へ追加します。パスは which context-mode の結果へ置き換えてください。

mcp_servers:
  context-mode:
    command: "/home/<USER>/.nvm/versions/node/<VERSION>/bin/context-mode"
    args: []
    env:
      PATH: "/home/<USER>/.nvm/versions/node/<VERSION>/bin:/home/<USER>/.local/bin:/usr/local/bin:/usr/bin:/bin"
      HOME: "/home/<USER>"
    tools:
      prompts: false
      resources: false

hermes mcp list
hermes mcp test context-mode
hermes gateway restart

Telegramで /new を送り、「ctx_doctor を実行してください」とテストします。

12.1. Context Modeを優先するSkillを作る

MCPへ登録しただけでは通常ツール出力が自動的にContext Modeへ迂回しないため、Routing Skillを作成しました。

mkdir -p ~/.hermes/skills/context-mode-routing
nano ~/.hermes/skills/context-mode-routing/SKILL.md

context-mode-routing/SKILL.mdの例

---
name: context-mode-routing
description: Use Context Mode for context-heavy tasks.
version: 1.0.0
author: local
---

# Context Mode Routing

Use Context Mode MCP when a task is likely to produce large raw output.

- Use ctx_execute for logs, JSON/CSV processing and aggregation.
- Use ctx_batch_execute for several independent analyses.
- Use ctx_execute_file for large files already on disk.
- Use ctx_fetch_and_index for large Web pages.
- Use ctx_index and ctx_search for repeated searches.
- Use Hermes native file tools for creating or editing files.

Do not return large raw outputs when Context Mode can reduce them first.
Context reduction must not reduce answer quality.

今回使ったHermesではSkillのdescriptionに60文字の制限があったため、短い1文にしました。バージョン差が出やすい箇所なので、Skillが読み込まれない場合はフロントマターとdescriptionの長さを確認します。

13. Step 11：日次ニュースSkillとTelegram配信Cronを作る

鳥取県とIT・AI・IoTのニュースを毎朝7時にTelegramへ送るSkillを作りました。

mkdir -p ~/.hermes/skills/news/daily-news-briefing
nano ~/.hermes/skills/news/daily-news-briefing/SKILL.md

重要なのは、単に「最近のニュース」ではなく、実行時刻から過去24時間以内に公開されたことを確認できる記事だけに限定する点です。古い記事の水増しや、更新日時だけ新しい記事を避けます。

daily-news-briefing/SKILL.mdの骨格

---
name: daily-news-briefing
description: Collect and summarize fresh Tottori, IT, AI, and IoT news.
version: 1.1.0
metadata:
  hermes:
    tags: [news, tottori, it, ai, iot]
    category: research
    requires_toolsets: [web]
    blueprint:
      schedule: "0 7 * * *"
      deliver: telegram
      prompt: "Run the daily news briefing."
---

# Daily News Briefing

Use this skill for a once-daily Telegram briefing covering Tottori, IT, AI, and IoT.

## Time window

1. Determine the current date and time in Asia/Tokyo.
2. Set the start to exactly 24 hours before execution.
3. Include only news published or officially announced inside that window.
4. Verify each publication date and time from the original source.
5. Exclude older, ambiguous, or unverifiable articles.

## Selection rules

- Prefer primary and authoritative sources.
- Prefer quality over quantity.
- Combine duplicate reports.
- Do not add older news to reach a target count.
- Include source URLs and publication timestamps.
- Do not invent facts, dates, times, or URLs.

## Output

Produce the briefing in Japanese. Include the JST target period, title,
summary, publication timestamp, why it matters, and source URL.
If no qualifying story exists, say so instead of using older news.

Skillと配信先を確認します。

hermes skills list | grep daily-news

Telegram側では /sethome を送ります。さらに ~/.hermes/config.yaml のトップレベルへタイムゾーンを明示します。

timezone: "Asia/Tokyo"

設定反映が不安定な場合は ~/.hermes/.env にも指定します。

HERMES_TIMEZONE=Asia/Tokyo

Gatewayを完全に再起動してからCronを作成します。

hermes gateway stop
hermes gateway start

hermes cron create "0 7 * * *"   "毎日7時にニュースを収集してください。"   --skill daily-news-briefing   --deliver telegram   --name "日次処理 7時"

hermes cron list
hermes cron run <JOB_ID>

朝7時のジョブなら、Next run が 2026-08-22T07:00:00+09:00 のように +09:00 になっていることを確認します。

13.1. モデル変更後にCronがskipされる場合

Cron作成後にグローバルのproviderやmodelが変わると、意図しない課金を防ぐため未固定ジョブが停止します。

Skipped to prevent unintended spend:
global inference config drifted ... and this job is unpinned

利用するモデルをCronへ明示的に固定します。

hermes cron edit <JOB_ID>   --provider <PROVIDER>   --model <MODEL>
hermes cron run <JOB_ID>

普段使うモデルを変更しても定期処理が止まらないため、Cronごとにproviderとmodelを固定する運用がおすすめです。

13.2. 90秒タイムアウトが起きる場合

今回、Kimi K3で約3.8万トークンのニュース処理を行った際、非ストリーミング呼び出しが90秒でタイムアウトしました。

Non-streaming API call timed out after 90s
Context: 33 msgs, ~38,686 tokens

このログからは、コンテキスト量と応答時間の両方を切り分ける必要があります。対処候補は、別モデルへCronを固定する、Skillの検索範囲と出力量を絞る、Context Modeで中間出力を削減する、LiteLLMのログで上流APIの所要時間を確認する、の4点です。今回のログだけではボトルネックを一つに断定できません。

14. 最終テスト

Ubuntuを再起動し、手動でHermesを起動せずTelegramから返信することを確認します。続いてWindows自体を再起動して同じテストを行います。

# Gateway
hermes gateway status

# Dashboard
systemctl --user status hermes-dashboard.service
ss -ltnp | grep 9119

# Chromium CDP
systemctl --user status hermes-chromium.service
curl http://127.0.0.1:9222/json/version

# MCPとCron
hermes mcp list
hermes cron list

すべて復旧し、Telegramからブラウザ操作とニュースCronを実行できれば完成です。

15. 構築で得たポイント

常時稼働を重視するならHyper-V + Ubuntuが扱いやすい
最初に手動テストし、その後サービス化すると切り分けやすい
Bot TokenやAPIキーなどの秘密情報は .env へ分離する
CDPはlocalhost限定、Dashboardは認証付きLAN/VPNまたはSSHトンネルで使う
Context ModeはRouting Skillと組み合わせる
Cronのタイムゾーンとprovider/modelを明示する

16. FAQ

WSL2でも同じ構成を作れますか？: 構築できます。WSL2でもsystemdは利用できますが、Windows未ログイン時からの起動経路を明確にし、普段使いのWindows環境から分離することを優先するなら、Hyper-V上のLinux VMが扱いやすい構成です。
この構成にはどの程度のVMスペックが必要ですか？: 今回は2 vCPU、起動RAM 4GB、動的メモリ2〜8GB、仮想ディスク40〜60GBで構築しました。クラウドLLMを利用する前提の目安であり、ローカルLLMを同じVMで動かす場合は、モデルに応じてCPU、メモリ、GPU、ディスクを追加してください。
Telegram利用だけでも固定IPは必要ですか？: 必須ではありません。Telegram Gatewayは外向き通信で動きます。SSH、Dashboard、VM内APIへ同じIPアドレスで接続したい場合は、ルーター側のDHCP予約を検討してください。
Ubuntu ServerにGUIブラウザは必要ですか？: ChatGPTまたはCodex Subscriptionのデバイスコード認証は、表示されたURLをWindows側のブラウザで開けるため不要です。Web操作用のChromiumもヘッドレスで常駐させられます。
Hermes起動時にlibatomic.so.1が見つからないと表示されたら？: 今回のUbuntu 24.04環境では、sudo apt install -y libatomic1で解消しました。導入後にhermes doctorを再実行し、ほかの依存関係も確認してください。
Telegram Botが反応しないときは、どこを確認しますか？: まずhermes gateway statusを確認します。system serviceとして導入した場合は、journalctl -u hermes-gateway -fでログを追います。Bot Token、Allowed User ID、モデルの認証状態を確認し、設定変更後はGatewayを再起動してTelegramで/newを送ります。
Allowed User IDを設定しないとどうなりますか？: Botを発見した第三者からHermesへ指示される恐れがあります。Telegramのユーザー名ではなく自分の数値User IDだけを許可し、Bot Tokenもパスワードと同じ秘密情報として管理してください。
Dashboardを0.0.0.0で公開しても安全ですか？: 0.0.0.0はLANを含む全インターフェースで待ち受ける設定です。Basic認証を設定し、UFWで接続元を信頼できるLANまたはVLANへ限定し、ルーターで9119番ポートを転送しないでください。外部公開を避けたい場合は127.0.0.1とSSHトンネルを使います。
同じLANの別PCからDashboardへ接続するにはどうしますか？: Dashboardを0.0.0.0:9119で待ち受け、Ubuntu VMのLAN内IPを確認します。別PCからhttp://<UbuntuのLAN内IP>:9119を開けば接続できます。到達できない場合はTest-NetConnection <UbuntuのLAN内IP> -Port 9119、待受状態、UFWの許可範囲を確認してください。
Dashboardのサービスはactiveなのに9119番ポートが開かないのはなぜですか？: 初回起動や更新直後はnpm ciやWeb UIのビルドが続いている場合があります。journalctl --user -u hermes-dashboard.service -fで処理状況を確認し、ビルド完了後にss -ltnp | grep 9119を再実行してください。
ChromiumでNo usable sandboxやDevToolsActivePortのエラーが出たら？: 今回のVMでは--no-sandboxと--disable-dev-shm-usageを付けて起動しました。ただしsandboxを無効にするため、CDPは127.0.0.1だけへバインドし、9222番ポートをLANやインターネットへ公開しないでください。
Context Modeを登録すれば、すべての出力が自動で圧縮されますか？: いいえ。MCPへ登録しただけでは、通常ツールより常に優先されるわけではありません。大量出力時にctx_*ツールを選ぶルールをRouting Skillへ記述し、実際のセッションで利用されているか確認します。
Cronが突然skipされるのはなぜですか？: Cron作成時と現在のproviderまたはmodelが異なり、意図しない課金を防ぐ安全機能が働いた可能性があります。hermes cron editでジョブごとにproviderとmodelを固定してから再実行してください。
Cronが朝7時ではなく16時に動くのはなぜですか？: 7:00 UTCとして作られた可能性があります。OSとHermesのタイムゾーンをAsia/Tokyoへ揃え、Gatewayを完全再起動してCronを作り直します。hermes cron listのNext runが+09:00になっていることも確認してください。
ニュースCronが90秒でタイムアウトするときはどうしますか？: まずLiteLLMのログで上流APIの応答時間を確認します。そのうえで、Cronを別モデルへ固定する、検索対象と出力量を減らす、Context Modeで中間出力を削減する、といった対策を個別に試します。タイムアウトログだけで原因を一つに断定しないことが大切です。
Windows再起動後も本当に自動復旧したか、どう確認しますか？: Windows再起動後に手動でHermesを起動せず、Telegramから返信を確認します。あわせてGatewayの状態、Dashboardの9119番ポート、Chromiumの/json/version、MCP一覧、CronのNext runを確認してください。