hermes-studio（Ekko Studio）レビュー: 5つのエージェント実行環境を1つの画面に束ねるローカル優先ダッシュボード

誰の何を解決するのか: ランタイムが増えるほど散らかる設定と履歴

AI コーディングエージェントを使い始めると、たいてい同じ問題にぶつかる。Hermes でチャットを回し、Claude Code でリポジトリを触り、Codex で別のタスクを走らせると、セッション履歴はツールごとに別々の場所へ散り、ボットトークンはプラットフォームごとに違うファイルへ書き込まれ、利用トークン量はどこにも集計されない。hermes-studio が狙っているのはこの散在そのもので、README は自らを「shared product platform, not a sixth agent」と位置づけ、5つのランタイムを横断する共有機能を引き受けると説明している。対象読者は、Hermes Agent をすでに自前で動かしている人、あるいは複数のコーディングエージェントを1つの作業台にまとめたい人だ。単一のチャットUIが欲しいだけなら、この構成は過剰になる。

5ランタイムと2系統のAPI: Studio が持つ責務と持たない責務

設計の要は境界の引き方にある。README はランタイムを3つのファミリーに分けている。Hermes ファミリーはプロファイル、プロバイダ、モデル、スキル、プラグイン、メモリ、ジョブ、Kanban、チャネル、MCP、ターミナルを所有する。Ekko ファミリーは実行、承認、確認質問、メモリ、MCP、プロバイダ実行を所有する。コーディングファミリーは Claude Code、Codex、Pi のインストール、設定、プロキシ、セッション、プロセス実行を所有する。Studio 自身が持つのは、シングルチャット、グループチャット、グローバルエージェントのオーケストレーション、ワークフロー、Webhook、セッション、ファイルとアップロード、TTS/STT、メディア、テーマ、デバイス、ネットワーク、ログ、利用状況、認証、アプリ接続といった共有部分だ。この分離は HTTP のパスにも表れていて、Studio 所有の API は /api/studio/*、Hermes 所有のコントロールプレーン API は /api/hermes/* を使う。チャットのストリーミングは Socket.IO の /chat-run で行われ、Studio が各実行をランタイムアダプタ経由でいずれかのエージェントへ振り分ける。面白いのはここで、Studio はエージェントの内部状態を吸い上げず、所有モジュールに残したまま画面だけを共有する。統合の粒度を意図的に浅く保つ判断であり、各ランタイムの更新に追従しやすい反面、設定の実体は依然として各エージェント側のファイルに散ったままになる。

セッションDBが二重になる理由と、Ctrl+K が届かない範囲

README で最も実務に響く記述のひとつが、セッション保存の扱いだ。Studio は自前のローカル SQLite を持ち、Studio セッションをそこへ保存する。一方で Hermes の state.db は、Hermes 履歴 API にとって読み取り専用のソースとして残る。つまり履歴は1か所に統合されない。この帰結はセッション検索にそのまま現れ、Ctrl+K の検索は Studio のローカルセッションDBを対象とし、読み取り専用の Hermes 履歴セッションは含まれないと明記されている。Hermes 側で長く運用してきた履歴を Studio から横断検索したい、という期待は満たされない。セッションはソース別（Telegram、Discord、Slack など）に折りたたみ式のアコーディオンでグループ化され、最新メッセージ時刻で並び、実行中のセッションはスピナー付きで上部に固定される。日々の切り替えは快適になるが、過去の掘り起こしは Hermes 側の画面と併用する前提で読むべきだ。

10プラットフォームのチャネル設定と、書き込み先ファイルの実際

チャネル設定は1ページに集約されている。対応として README が挙げるのは Telegram、Discord、Slack、WhatsApp、Matrix、Feishu（Lark）、DingTalk、QQBot、WeChat、WeCom の10種類だ。プラットフォームごとに扱える項目は異なり、Telegram はボットトークン、メンション制御、リアクション、自由応答チャット、Discord はボットトークン、メンション、自動スレッド、リアクション、チャネルの許可・無視リスト、Slack はボットトークン、メンション制御、ボットメッセージの扱い、Matrix はアクセストークン、ホームサーバー、自動スレッド、DM メンションスレッド、といった具合に差がある。WeChat は例外的で、ブラウザ上で QR コードを読み取り、認証情報を自動保存する方式だ。重要なのは保存先で、認証情報は ~/.hermes/.env へ、チャネルの挙動設定は ~/.hermes/config.yaml へ書き込まれる。GUI で操作していても実体は Hermes の設定ファイルであり、この2ファイルをバージョン管理下に置いたり、複数環境で共有したりしている運用では、ダッシュボードからの書き込みが既存の差分と衝突しうる。設定ページにはプラットフォームごとの設定済み・未設定の検出表示があるので、まず現状把握に使うのが安全だ。

ワークフロー、ジョブ、Kanban、利用状況: 共有層に置かれた自動化

自動化は Studio 側の持ち物として実装されている。Vue Flow のキャンバス上で、Hermes、Ekko、Claude Code、Codex、Pi をまたぐ実行可能なビジュアルワークフローを組み、スケジュール、承認ゲート、グループチャットのルーム、プラットフォームチャネル、MCP サーバーで5つのランタイムをつなぐ、と README は説明する。スケジュールジョブは cron ジョブの作成、編集、一時停止、再開、削除に加え、即時実行のトリガーと cron 式のクイックプリセットを備える。Kanban はプロファイル対応のボードで、ダッシュボード上からタスクの作成、更新、ステータス移動ができ、Studio のローカル状態と認証モデルを共有する。利用状況分析は、入力と出力に分けたトークン使用量、日次平均を添えたセッション数、推定コストとキャッシュヒット率、モデル別の使用分布、30日間の日次推移（棒グラフとデータテーブル）を表示する。推定コストという語が示すとおり、これは請求額そのものではなく概算である点は押さえておきたい。

起動までの手順と、配布形態ごとの違い

README が示す最短経路は npm 経由で、npm install -g hermes-web-ui の後に hermes-web-ui start を実行する。デスクトップアプリは Windows、macOS、Linux 向けに releases ページからダウンロードでき、配布形態としてデスクトップアプリ、npm CLI パッケージ、Docker イメージの3つが挙げられている。ファイルの扱いはバックエンドごとに差があり、アップロード済みファイルとエージェントが生成したファイルのダウンロードは、local、Docker、SSH、Singularity の各バックエンドで解決済みパスを通じて行われる。生成物のインラインプレビューは HTML、PDF、DOCX、PPTX、XLSX、CSV、画像、Markdown、ソースファイルに対応する。ここで注意したいのは、README の記述が「何ができるか」の列挙に寄っており、必要とする環境変数、対応 Node のバージョン、Docker イメージのタグ名といった導入時の具体値が本文からは読み取れないことだ。手順の詳細は ekkostudio.xyz のドキュメント側に委ねられていると見るべきで、社内標準のデプロイ手順に落とし込む前にそこを確認する必要がある。

向かない場面と、素の Hermes Agent という対抗軸

この構成が過剰になる場面ははっきりしている。Hermes Agent を導入しておらず、単一のモデルと単一のチャット画面で足りるなら、~/.hermes/config.yaml と ~/.hermes/.env を前提とする設定系は使う場面がなく、5ランタイムを束ねる利点も発生しない。比較対象として最も自然なのは、hermes-studio が土台としている Hermes Agent そのものだ。Hermes Agent はプロファイル、プロバイダ、モデル、スキル、プラグイン、メモリ、ジョブ、Kanban、チャネル、MCP、ターミナルを所有する実行環境で、hermes-studio はその上に共有UIと横断機能を載せる。つまりアプローチの違いは、単一エージェントの能力を深く使い込むか、複数エージェントの操作面を浅く広く統一するかにある。Hermes Agent だけを使う場合、設定の実体は1か所に閉じ、セッション履歴も state.db に一本化されるため、二重DBの制約は存在しない。逆に、Claude Code と Codex を同じ画面で並行して走らせたいという要求は Hermes Agent 単体では満たせず、そこが hermes-studio を選ぶ理由になる。もう一点、モバイルアプリ向けの既存パスは重複した旧コントローラを増やさず、中央集約された互換レイヤー1か所で処理される。過去の経路を壊さずに統合した判断で、この種のプロジェクトでは珍しく感じる。

ライセンス表記と更新頻度から見た維持コスト

最初に確認すべきはライセンスだ。リポジトリのメタデータでは License が NOASSERTION と判定されており、GitHub が条項を特定できていない状態を示す。README のバッジには LICENSE へのリンクがあるが、本文中に条項の要約はない。npm パッケージ hermes-web-ui にもライセンス表記のバッジが付くが、識別子までは本文から読み取れない。ここは推測せず、LICENSE ファイルと npm 側の表記を直接読むべき箇所で、判断を誤ると再配布や社内ミラーでの運用が後から問題になりうる。更新の頻度は高く、v0.7.17（2026-09-04）、v0.7.18（2026-09-06）、v1.0.2（2026-09-09）と数日おきにリリースが並び、v1.0.2 ではバージョン表記が HStudio に変わっている。活発であることは追従コストでもあり、設定ファイルの書き込み先が ~/.hermes/.env と ~/.hermes/config.yaml である以上、Studio 側の更新が Hermes 側の設定スキーマとずれた場合の影響はダッシュボード内で完結しない。追従を自動化するなら、更新前にこの2ファイルの差分を取る手順を先に決めておきたい。なお本記事はリポジトリの資料のみを根拠としており、実際にインストールして動作を確認したものではない。

編集部の結論

採用を検討すべきなのは、Hermes Agent をすでに動かしていて、Telegram や Discord など複数チャネルの設定とセッション履歴を1画面に集約したい開発者、および Claude Code や Codex を同じ作業台で並行して走らせたい人である。逆に、単一モデル・単一チャットで足りる用途や、Hermes を導入していない環境では、設定ファイル ~/.hermes/config.yaml と ~/.hermes/.env への書き込みを前提とする設計が荷物になるだけで、選ぶ理由が薄い。導入前に確認すべきは3点で、第一に LICENSE が NOASSERTION と判定されているため実際のライセンス条項を自分の目で読み、第二に npm install -g hermes-web-ui で入る CLI とデスクトップ版が同一のリリース系列か releases ページで突き合わせ、第三に Studio 側のセッションDBと Hermes の state.db が別管理であることを踏まえて、過去履歴の検索範囲が自分の運用に足りるかを Ctrl+K の挙動で確かめることだ。この3点が問題にならないなら、5ランタイムを1つの認証モデルで扱える構成は代替が効きにくい。

公式情報源

1. EKKOLearnAI/hermes-studio on GitHub
2. Issues
3. Project website
4. README
5. Releases