HotPlex - AI coding agent を Web、Slack、Feishu へつなぐ統一 gateway
AI coding agent をローカルで動かし始めると、次に出てくる問題は model の強さよりも、「同じ agent をどうやって複数の入口へ安定してつなぐか」であることが多いです。Web chat、Slack、Feishu、background task、permission control、session recovery、logging、diagnostics を別々の script で積み上げていくと、すぐに保守しづらくなります。
今日取り上げたい hrygo/hotplex は、まさにその接入層を扱う project です。Go で書かれた unified gateway で、複数の AI coding agent worker をひとつの WebSocket protocol の後ろにまとめ、同じ interface を Web、Slack、Feishu に提供します。Claude Code、Codex CLI、ACP-compatible agent を試している team には、かなり実務的な切り口です。
公開時点の GitHub data では、約 43 stars、11 forks。主な言語は Go。Repository は 2026-03-30 に作成され、最近の公開 update は 2026-06-17 です。License は Apache-2.0。Latest GitHub release は v1.29.1 で、公開日は 2026-06-16 です。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| Repository | hrygo/hotplex |
| 位置づけ | AI coding agent の unified access gateway |
| Stars | 約 43 |
| Forks | 約 11 |
| 主な言語 | Go |
| Protocol | AEP v1 WebSocket |
| License | Apache-2.0 |
| Latest version | v1.29.1 |
解いているのは model 層ではなく access 層
多くの team は、AI coding agent をまず CLI で動かします。本当に難しくなるのは、その agent を他の人にも使える形にするときです。
同じ agent を Web と chat tool の両方に出せるか。入口が違っても session state を保てるか。切断後に resume できるか。Backend agent が一時的に失敗したとき、統一された retry policy を持てるか。Claude Code、Codex CLI、ACP-compatible runtime を試すたびに、上の接入層を作り直さずに済むか。
HotPlex は、まず unified gateway を置くという答えを選んでいます。README では、高性能な Go gateway が単一の WebSocket interface を提供し、その背後で複数の AI coding agent worker を抽象化すると説明されています。現在明示されている backend は Claude Code、OpenCode Server、ACP compatible agent、そして Codex CLI。重要なのは、これが新しい agent そのものではなく、複数の agent capability を一貫した形で expose するための層だという点です。
接続先の広さが実用寄り
この project は protocol bridge だけでは終わっていません。実際に使うときに面倒になりがちな周辺も一緒に用意しています。
まず multi-platform delivery です。README では、同じ agent を Web、Slack、Feishu に接続できるとされています。Internal tooling では、browser で使いたい人と、chat workspace から直接 agent を呼びたい人が混在しがちなので、この設計はかなり現実的です。
さらに、embedded web chat と admin dashboard を最初から持っています。API だけを置いて frontend を別に作らせるのではなく、AEP gateway、Next.js SPA chat UI、admin UI を同じ配布面に含めています。初期段階の internal tool では、まず end-to-end で動くものを置けることが大きいです。
個人的に面白いと感じたのは AI-native cron scheduler です。単なる OS cron の wrapper ではなく、自然言語から scheduled task を作り、cron expression、fixed interval、one-shot scheduling、max_runs、expires_at などを扱います。たとえば「30分後にこの修正を再確認して」や「毎日この repo を巡回して」のような運用を、agent system の中に収めやすくなります。
一番見る価値があるのは backend abstraction
README では unified worker interface と 5-level config fallback が説明されています。要するに、frontend 側は特定の agent runtime に強く依存せず、bot、platform、env、messaging、default といった層で実際の worker を切り替えられる設計です。
この abstraction は地味ですが重要です。Agent infrastructure を試している team は、かなり高い確率で backend を入れ替えます。今日は Slack bot を Claude Code につなぎ、明日は一部 workflow を Codex CLI に寄せ、次は ACP-compatible implementation を試す、ということが普通に起きます。そうした変化を business integration layer ではなく backend adapter 側に閉じ込められるなら、全体の変更コストはかなり下がります。
また、deterministic session、UUIDv5 session id、reconnect、SQLite/PostgreSQL persistence、background GC を default capability として押し出しているのも好印象です。どれも派手ではありませんが、chat-style agent service を本当に運用し始めると必ず必要になる種類の機能です。
Security と operations も最初から意識している
README に並ぶ項目を見ると、HotPlex は demo 止まりにならないよう意識していることが分かります。Timing-safe API key authentication、SSRF protection、command/tool/model allowlists、environment isolation、path traversal prevention、Prometheus metrics、OpenTelemetry tracing、structured JSON logging などが挙げられています。
もちろん、これだけで enterprise product と断言はできません。ただ、Slack や Feishu、Web 経由で agent を公開するなら、問題は model response だけではありません。権限境界、監視、診断、設定変更の管理を早い段階から考えている project の方が、後から本番に近づけやすいです。
CLI がまとまっているのも実務向きです。gateway、service、onboard、doctor、cron、config、update、status などをひとつの binary に集約し、systemd、launchd、Windows SCM をサポートしています。Self-hosted 前提の internal platform を触る人には、このあたりの一貫性が効きます。
向いている人
HotPlex は特に三つのタイプの人に合いそうです。
ひとつ目は、AI coding agent を内部で試しているが、接続方法がまだ散らばっている team です。Terminal では動くものの、chat tool や Web に安定して出す基盤が欲しい場合、かなり参考になります。
ふたつ目は、複数の agent runtime を比較したい team です。Claude Code、Codex CLI、ACP-compatible backend を同じ gateway の背後で扱えるなら、上の体験を壊さずに差し替えを試せます。
三つ目は、agent の運用面に興味がある人です。Session、cron、admin、metrics、tracing、security policy、hot-reload config をまとめて見られるので、「agent をどう呼ぶか」だけでなく「どう運用するか」まで観察できます。
境界も見ておきたい
この project は扱う範囲が広いので、読むときは何がすでに使える機能で、何を自分で検証すべきかを分けておく方が良いです。
たとえば入口の多さ、worker の種類、docs portal、admin UI、cron scheduler は魅力ですが、実際に導入するなら自分たちの permission model、message platform の制約、network topology、運用方法に合うか確認が必要です。README では Docker が experimental 扱いなので、安定運用を重視するなら project 推奨の install と service workflow を優先して検証した方がよさそうです。
もうひとつは、中心 protocol が AEP v1 だという点です。すでに別の message protocol や独自 SDK で組んでいる環境では、そのまま差し込めるとは限りません。ただし、まさにそこが HotPlex の面白いところでもあります。これは単一 agent の周辺 plugin ではなく、AI coding agent gateway を独立した product layer として扱おうとしている project です。
まとめ
hrygo/hotplex は、またひとつの chat demo を増やす project ではありません。統一 WebSocket protocol、pluggable worker、multi-platform delivery、scheduled tasks、admin UI、observability をまとめ、AI coding agent をチームで配布しやすい形に寄せようとしている infrastructure 寄りの実装です。
最近「terminal の agent を、チームがアクセスできる service に育てるにはどうするか」を考えているなら、HotPlex はかなり参考になります。最終解ではないかもしれませんが、問題の分解の仕方がうまく、internal agent platform を考える上で見る価値のある小さめの project です。