Hermex レビュー: hermes-webui を iPhone から操作する SwiftUI クライアントの実力と境界
Native iPhone app for your Hermes agent
ひと目でわかる
- これは何？
- Hermex は自前の hermes-webui サーバーを iPhone から操作する MIT ライセンスの SwiftUI アプリだ。計算はサーバー側に置いたまま、チャット、セッション、cron タスク、スキル、ワークスペースを手元で扱える。ただしサーバーの公開とセキュリティは利用者の責任で、上流 API も安定保証がない。
- 誰に向いている？
- 導入を検討すべきなのは、すでに hermes-webui を自前で動かしており、iPhone からセッション再開や cron タスク確認を行いたい人だ。サーバーをまだ持っていない人、あるいは公開エンドポイントの運用に自信がない人には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Swift です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Hermex が埋めるのは「サーバーと手元の間」の空白
hermes-webui はエージェントを自前のマシンで動かすためのサーバーだが、その操作は基本的にブラウザ越しになる。外出先でセッションを再開したい、cron ジョブの時刻を少し直したい、といった用途でブラウザを開くのは快適とは言いにくい。Hermex はこの部分だけを担当する。README の表現を借りれば「The phone is the control plane, not the compute plane」であり、エージェント、ツール、データはすべて自分のハードウェアに残る。対象読者は、hermes-webui をすでに運用している個人開発者や小規模チームである。Hermex 単体では何も動かない。バックエンドを同梱も提供もしないと README が明記しており、サーバーを用意するのは利用者の仕事だ。
SwiftUI ネイティブという選択が意味するもの
iOS 18 以降を対象にした本物の SwiftUI アプリで、WebView のラッパーではないと README は述べている。これは機能面に具体的な差として現れる。応答はストリーミング表示され、thinking とツール呼び出しの詳細が同時に見える。実行中の処理に対して途中で指示を出したり停止したりできる。セッションはサーバー上のものを一覧、検索、再開でき、キャッシュ済みのセッションはオフラインでも読める。モデルとプロバイダはサーバーが設定している範囲で切り替えられ、最近使ったものとお気に入りが保持される。ほかにプロファイルとプロジェクトの切り替え、cron ジョブの閲覧と編集、インストール済みスキルの検索、サーバーのファイルシステムを見るワークスペースブラウザがある。メモリとインサイトは読み取り専用のパネルだ。アプリ内課金もサブスクリプションもなく、解析もトラッキングもサードパーティ中継もないと README は書いている。
接続経路の設計: トンネル、Tailscale、localhost
Hermex を使う上で最も判断が要るのはサーバーをどう公開するかである。README は3つの経路を挙げ、優先順位も示している。第一は Cloudflare Tunnel などのトンネルかリバースプロキシで、所有するホスト名に本物の TLS を終端させる方法。iOS の App Transport Security が例外なしで通るため推奨とされている。ただし公開ホスト名に置いた場合、アプリ層の防御はパスワードだけになる。第二は Tailscale Serve で、サーバーを 127.0.0.1:8787 に束縛したまま HTTPS を被せる。README は既存の Serve/Funnel ルートを確認したうえで、HTTPS の 443 番とルートパスが空いている場合にのみ tailscale serve --bg 8787 を実行するよう注意を促している。接続には tailscale serve status が報告する正確な https://…ts.net URL を使う。第三は 0.0.0.0 への直接バインドで平文 HTTP のまま公開する方法だが、これは手動のフォールバックであって既定ではないと明記されている。シミュレータでのローカル検証に限り http://localhost:8787 が使える。
セットアップ手順と、失敗時に見るべき4点
README は所要15分程度としている。手順は、macOS、Linux、Windows/WSL2 のいずれかで Python 3.11 以降を使って hermes-webui を導入し、HERMES_WEBUI_PASSWORD を設定して起動する。次に上のいずれかの方法で iPhone から到達可能にする。最後にアプリへサーバー URL とパスワードを入力する。接続テストが失敗した場合に確認すべき項目として README が挙げるのは4つだ。hermes-webui を載せたマシンが起きているか。サーバーが動いていて /health を返すか。トンネル、リバースプロキシ、Tailscale のルートがつながっているか。URL とパスワードが正しいか。2番目は curl https://<your-server>/health で確認できる。この切り分け手順が用意されている点は、接続トラブルの原因がアプリ側かサーバー側か分からなくなりがちな構成において実用的である。
自分でビルドする場合の前提と、上流 API の不安定さ
App Store 版が用意されている以上、ソースからのビルドは開発者向けだと README 自体が位置づけている。必要なのは Xcode 26 以降（iOS 18 SDK）と iOS 18 以降の実機かシミュレータ。リポジトリを clone し、HermesMobile.xcodeproj を開いて HermesMobile スキームを実行する。Xcode のターゲット名は HermesMobile で、表示名が Hermex という違いに注意したい。依存関係は Swift Package Manager で自動解決される。コマンドラインからは xcodebuild -project HermesMobile.xcodeproj -scheme HermesMobile -destination 'platform=iOS Simulator,name=iPhone 17' build でビルドでき、テストは同様の構成で xcodebuild test を実行する。iPhone 17 のシミュレータがなければ xcrun simctl list devices available で近いものを選ぶ。XcodeBuildMCP 利用者向けのローカル検証既定値は .xcodebuildmcp/config.yaml にあり、変更後の標準フローは DEVELOPMENT.md にまとまっている。ここで最も重い制約はサーバー互換性だ。アプリは UPSTREAM_TESTED_SHA に固定した hermes-webui のコミットに対して開発・テストされており、上流は API 安定性をまだ保証していない。上流 README 自身が安定 API の作業が終わるまでバージョン差をサポート外と宣言しているため、新しいサーバーでも古いサーバーでも個別の機能が壊れうる。
向かないケースと、代わりの選択肢
Hermex が適切でない状況ははっきりしている。hermes-webui をまだ運用していないなら、最初に必要なのはサーバーであってアプリではない。また、エージェントの実行基盤そのものをクラウド側に置きたい人には、この設計は根本的に噛み合わない。計算を手元のマシンに残すことが前提だからだ。比較対象として自然なのは、同じ hermes-webui をブラウザで開く経路である。違いは機能の有無ではなく到達性と操作感にある。ブラウザはサーバーに到達さえできれば追加インストールが不要で、デスクトップでもタブレットでも同じ画面が使える。一方で、実行中の応答を止める操作、セッションのオフライン閲覧、cron ジョブの手早い修正といった細かい操作はモバイル向けに作り込まれていない。逆に Hermex は iOS 18 以降の iPhone に限定され、サーバー側の API が動けばアプリ側も追従して更新される必要がある。ブラウザ経路が「常に最新のサーバーに追従しやすいが操作は粗い」、Hermex が「操作は作り込まれているが上流の変更に弱い」という関係になる。
ライセンスと維持コストの見取り図
Hermex 本体は MIT ライセンスで、リポジトリには LICENSE が置かれている。アプリ自体は無料で、サブスクリプションもアプリ内課金もないと README は述べており、支援は Buy Me a Coffee へのリンクという形になっている。ここで混同しやすいのは、Hermex が依存する hermes-webui が別プロジェクトであり、そちらも MIT ライセンスのオープンソースだと README が明記している点だ。ライセンス条件はそれぞれのリポジトリで確認する必要がある。維持コストの実体はアプリ側ではなくサーバー側にある。TLS の終端、トンネルや Tailscale のルート、パスワードの管理、マシンを起こしておくことはすべて利用者の運用に乗る。リリースは v1.4.0、v1.5.0、v1.6.0 とおおむね月1回の間隔で出ており、上流の変更に追従する作業が継続的に発生する構造だと読める。法務上の判断が必要な場合は、この記事ではなく各リポジトリのライセンス全文と所属組織のポリシーに当たってほしい。
編集部の結論
導入を検討すべきなのは、すでに hermes-webui を自前で動かしており、iPhone からセッション再開や cron タスク確認を行いたい人だ。サーバーをまだ持っていない人、あるいは公開エンドポイントの運用に自信がない人には向かない。最初に確認すべきは UPSTREAM_TESTED_SHA に記録されたコミットと自分のサーバーのバージョン差、次に curl https://<your-server>/health が通るかどうかである。この2点が噛み合わない限り、アプリ側の不具合とサーバー側の非互換を切り分けられない。
コミュニティノート