AIエージェントをターミナルで使い続けていると、ふとこう思うことがあります。「スマートフォンから確認できたら便利なのに」「チームメンバーに渡すたびにCLIの説明をしなければいけない」。そのモヤモヤを解消する方向で作られているのが、今回紹介するリポジトリです。設計の話もしっかり掘り下げますので、導入を考えている方はもちろん、Webアプリの設計を考える上でのヒントとして読んでみてください。
どんなツールか
Hermes WebUIは、Hermes Agent（Nous Researchが開発する自律型AIエージェント）をブラウザから操作するためのインターフェースです。Hermesエージェント本体はセッションをまたいで記憶を保持し、オフライン中もcronジョブを実行するという特徴を持ちますが、操作はターミナル経由が前提でした。このWebUIは、その体験をブラウザへそのまま持ち込むことを目的に作られています。
三列レイアウトで、左サイドバーにセッション一覧、中央にチャット、右にワークスペースのファイルブラウザが並びます。モデルの切り替えやプロファイルの選択はコンポーザーフッターに常時表示されており、画面を移動しなくても操作できます。GItHub上のスター数は17,000を超えており、Hermesエージェントを実際に運用している層を中心に広がっているようです。
MITライセンスで公開されており、商用利用を含めて自由に使えます。OpenAI・Anthropic・Google・DeepSeekなど主要なプロバイダーに対応しており、既存のHermesエージェント設定をそのまま読むため、追加設定なしで動き始めます。
設計でここが上手い
ビルドステップを持たないフロントエンド
フロントエンドにバンドラーもフレームワークも使っていません。PythonとバニラJSだけで動きます。これは些細なことのように見えて、運用面では大きな差になります。Node.jsのバージョン管理やnode_modulesの更新作業が不要なため、Pythonが動く環境であればそのまま起動できます。ホームラボや自前のVMに置くケースでは、依存関係の管理コストが後々効いてくるので、この割り切りはかなり実用的だと感じます。
ctl.shによるデーモン管理の分離
サーバーの起動方法が複数あり（bootstrap.py直接実行、start.sh、ctl.sh start）、それぞれの停止手順も異なります。READMEではこの点を表形式で明示しており、「ctl.sh stopは自分が起動したプロセスしか止められない」という制約もきちんと書かれています。多くのツールがここを曖昧にして「止まらない」という問題を引き起こしがちですが、このリポジトリはPIDファイルを~/.hermes/webui.pidに書き、SIGTERM後にSIGKILLでフォールバックする流れを明示しています。デーモン管理の設計として、実際のホームラボ運用を想定した誠実なアプローチだといえます。
チャットのインプロセス実行とゲートウェイの分離
デフォルトでは、WebUIはHermesエージェントをプロセス内で動かし、外部APIサーバーには接続しません。HERMES_API_URLはTasksのヘルスチェックにしか使われず、チャットのルーティングには関係しないという点がREADMEに明示されています。外部エンドポイントを使いたい場合は、Settings→Providersからカスタムプロバイダーとして追加するか、HERMES_WEBUI_CHAT_BACKEND=gatewayで切り替える方法が用意されています。「デフォルトは最もシンプルな構成」「複雑な構成はオプト・イン」という方針が一貫しており、初期設定でつまずく人を減らす配慮があります。
トークン使用量の可視化
コンポーザーフッターに「コンテキストリング」と呼ばれる円形のインジケーターが常時表示されており、入力トークン数・出力トークン数・推定コストをひと目で確認できます。長い会話でコンテキストウィンドウが埋まっていくのを視覚的に把握できるため、セッションを切るタイミングの判断がしやすくなっています。これはモデルを頻繁に切り替えるユーザーにとって特に有用で、コスト管理の面でも実用的です。
こういう人に向くかも
Hermesエージェントをすでに使っていて、ターミナルに縛られずに操作したいと感じている人に向いています。スマートフォンからSSHトンネル経由でアクセスする使い方が想定されており、外出先でエージェントの状況を確認したり、簡単な指示を送ったりする用途に合います。
ホームラボや自前のVMを持っていてセルフホストに慣れている人にも向いています。Dockerによるシングルコンテナ・マルチコンテナのデプロイや、NixOSモジュールも用意されており、インフラ管理の方法を選べます。逆に、Hermesエージェントをまだ使っていない人にとっては、このWebUIだけを入れても動かないため、まずエージェント本体の導入が先になります。
設計の良し悪しをどこで見るか
想定ユーザー像の解像度
「CLIの体験をそのままブラウザへ」というコンセプトは明確です。READMEには比較表（OpenClaw・Claude Code・Codex CLIなど）も含まれており、競合との差分を開発者自身が整理しています。ただし、Hermesエージェント本体の知識がある程度前提になっているため、AIエージェント全般の入門者向けというよりは「すでにHermesを使っている人がWebUIを追加する」というシナリオ向けの設計です。この点は良し悪しではなく、スコープの絞り込みとして読む方が正確だと思います。
ドキュメントの深度
README単体でも概要はつかめますが、docs/ディレクトリ以下にadvanced-chat-setup.md、onboarding.md、onboarding-agent-checklist.md、wsl-autostart.mdなど複数のドキュメントが用意されています。特にonboarding-agent-checklist.mdは「AIアシスタントがインストールを手伝う場合はこのファイルを読ませてから始めよ」という注記があり、AIによる自動インストール支援を想定した設計になっています。このドキュメント構成は、ユーザーサポートの負荷を下げる意図があるのでしょう。
想定外の使われ方への備え
Windowsネイティブ環境は公式にはサポートされておらず、WSL2の利用を推奨しています。一方で、コミュニティによるネイティブWindowsセットアップガイドへの参照がREADME内に記載されており、完全に切り捨てるのではなくコミュニティに委ねる形をとっています。メモリ使用量（ネイティブ約330MBに対してWSL2+Docker約1080MB）のような具体的な数字も記載されており、ユーザーが判断できる情報が整理されています。
トークン経済性
チャットはデフォルトでインプロセス実行なので、外部API呼び出しのオーバーヘッドがありません。SSEによるストリーミングとrAFスロットリングを組み合わせた実装は、長い応答でも画面描画が詰まりにくくなる工夫です。コンテキストリングによるトークン可視化も、無意識にトークンを使い続けるのを防ぐ効果があります。
自分が書くなら、どこを変えるか
チャット処理がインプロセス実行である点は、シンプルさの代償として「WebUIサーバーとエージェントが同一プロセスに混在する」という構造的な問題を持ちます。エージェントが重いタスクを実行中に、WebUIの応答性に影響が出る可能性があります。ゲートウェイモードが実装されているものの、まだ完全なエージェントループの委任は未実装（issue #1925）とのことなので、この部分が成熟するまでは処理の重さによっては工夫が必要になるかもしれません。
もう一つは、Windows対応の位置づけです。コミュニティ製のガイドへの参照という形にしているのは理解できますが、ユーザーが混乱しやすいポイントでもあります。公式にサポートするかどうかを明言した上で、サポート外なら「WSL2を使ってください」と一本化する方が、サポートコストは下がりそうだと感じます。現状は「できるかもしれない」という玉虫色の状態になっています。
導入を検討するときのチェック観点
- Hermesエージェント本体がすでにインストールされているか（WebUIだけでは動かない）
- Pythonが動く環境か（Node.jsは不要だが、Python 3.11以上が推奨）
- 外部からアクセスする場合はSSHトンネルやTailscaleの設定が必要なことを把握しているか
- 使用するモデルプロバイダーのAPIキーが設定済みか
- デーモンとして動かす場合、
ctl.shと直接起動の停止手順の違いを理解しているか - Windows環境の場合、WSL2でのセットアップかネイティブかを事前に決めておくか
- チームで使う場合、パスワード設定（Settings→パスワード設定）と公開範囲の確認をしたか
CLIとブラウザの境界線
Hermes WebUIが解こうとしているのは「ターミナルの体験をどこまでブラウザに持ち込めるか」という問いです。ビルドステップを持たず、既存のエージェント設定をそのまま読むという方針は、「CLIの代替」ではなく「CLIの延長線上にあるもの」として位置づけていることが伝わってきます。Hermesエージェントを日常的に使っていて、場所を問わず操作したい場面が増えてきた人にとっては、試してみる価値のあるツールだと思います。
