AgentDock：複数の machine を Agent が扱える MCP runtime にする
AI Agent が日常の開発に入り込むと、すぐに出てくる問題がある。作業場所はいつも一台の machine ではない。Code は Mac にあり、service は VPS で動き、logs は container にあり、temporary test environment は別の Linux host にある。Agent が current workspace しか見られないと、人間が logs をコピーし、SSH を切り替え、command output を貼り続けることになる。Context window を長くしても、この問題は根本的には解けない。実行環境が分散しているからだ。
今日見たいのは uvwt/agentdock。この project は、自分を independent Agent tool runtime と位置づけている。MCP 経由で files、commands、Git、Skills、dynamic MCP、browser automation、recoverable tasks などを公開し、ChatGPT、Claude、Codex、その他 MCP client が local machine、remote server、container を同じ tool model で扱えるようにする。Chat interface も model inference も提供しない。狙いは、real environment operations を authorization、traceability、verification のある tool layer にまとめることだ。
GitHub repository page、README、Releases、LICENSE、Git default branch history を 2026-08-02 時点で確認すると、uvwt/agentdock は 162 stars、23 forks。主要言語は Go、license は Apache-2.0。Git history で確認できる最初の public commit は 2026-05-24 07:04:05 UTC。Default branch main の現在の HEAD は 2401c4a、commit time は 2026-08-02 09:48:10 UTC。最新 GitHub Release は v0.5.4、published time は 2026-07-20 09:29 UTC。Repository page では default branch はおよそ 385 commits と表示されている。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | uvwt/agentdock |
| 位置づけ | AI Agent 向け secure MCP runtime |
| Stars | 162 |
| Forks | 23 |
| 主要言語 | Go |
| ライセンス | Apache-2.0 |
| 最初の public Git commit | 2026-05-24 07:04:05 UTC |
| 現在の default branch commit | 2401c4a、2026-08-02 09:48:10 UTC |
| 最新 GitHub Release | v0.5.4、2026-07-20 09:29 UTC |
| Commit 数 | 約 385 commits |
| キーワード | MCP、remote control、self-hosted、DevOps、browser automation、recoverable tasks |
解いているのは「Agent はどの machine で作業するのか」という問題
多くの Agent tool は一つの project directory から始まる。Single repository の coding なら自然だが、実際の maintenance work は複数の環境にまたがる。Local で code を直し、remote で service を見て、container で logs を読み、browser で admin console を確認する。人間は複数の terminal と browser tabs を行き来できるが、Agent にはそのたびに context を渡し直す必要がある。
AgentDock の考え方は、それぞれの environment を MCP endpoint にすることだ。README が描く基本像は、一つの AI conversation が Local Mac、LAN Host、Cloud VPS など複数の AgentDock instance に接続し、それぞれの instance が自分の files、shell、Git、tunnel、proxy、deploy target を操作する、というものだ。Agent はすべてが一つの workspace にあるふりをする必要がなく、「この step はどの machine で実行するのか」を明示できる。
この角度は server maintenance、cross-environment debugging、deployment の最後の確認に向いている。たとえば NAT の内側にある machine を外から使えるようにする場合、local tunnel client を起動しつつ、server 側で forwarding、ports、domains、reverse proxy を設定する必要がある。AgentDock はこのような multi-device flow を同じ tool-call context に入れ、人間が terminal 間で状態を運ぶコストを減らそうとしている。
重要なのは大きな権限ではなく、明確な boundary
この種の tool で一番怖いのは、Agent が real machine に触れることだ。AgentDock の README は permission boundary を繰り返し強調している。Path scope、command timeout、output limit、sensitive data redaction、tool-call state と command exit status の分離などだ。Authentication や OS security control を回避するための tool ではないとも明記している。
つまり、これは「Agent に root を渡して祈る」方向ではない。現実的な使い方は、machine と task ごとに別の AgentDock instance を用意し、必要な directories、commands、network endpoint だけを公開することだ。Production server では特に、dedicated user、least file permission、controlled reverse proxy、HTTPS を前提にすべきで、unauthenticated MCP endpoint を public internet に出すべきではない。
README の public access に関する条件もかなり明確だ。Non-loopback listener には Bearer Token または OAuth が必要で、public deployment は HTTPS を使い、firewall、reverse proxy、network access control と組み合わせる必要がある。Agent 向け operations runtime では、これは補足ではなく試用の前提条件である。
単体の MCP server より runtime layer に近い
AgentDock はいくつかの shell commands を MCP tools として包むだけではない。Filesystem、command execution、Git、Skills、dynamic MCP server、browser / desktop automation、long task recovery を同じ runtime に置く。README が触れている structured results も重要だ。Tool call が完了したこと、command の exit status、stdout、stderr は分けて扱うべきで、「tool が走った」だけで task 成功と見なしてはいけない。
これは Codex 的な workflow と相性がよい。ひとつの fix には、files を読む、patch を当てる、tests を走らせる、Git diff を見る、commit する、push する、remote server で service state を確認する、といった step が含まれる。それぞれを記録して検証できれば、失敗時にも具体的な状態から復帰しやすい。Skills と dynamic MCP server を扱える点も、AgentDock を固定機能の remote shell ではなく、拡張可能な local / remote tool host に近づけている。
Browser automation と desktop automation も境界をまたぐ作業に効く。多くの internal system にはきれいな API がなく、debugging では web admin に login し、UI を何度か操作し、terminal に戻って logs を見ることがある。AgentDock はこうした動作を同じ MCP model に収めようとしている。Browser、SSH、file editing がばらばらの tool になるより、context を保ちやすい。
Installation path は実用的だが、まず小さく試したい
AgentDock には Docker、Linux systemd、macOS、Windows の installation path がある。README の Docker quick start は release に含まれる docker-compose.yml を download し、AGENTDOCK_AUTH_TOKEN を設定して docker compose up -d する流れだ。Default MCP address は http://127.0.0.1:18766/mcp。Production images は GHCR と Docker Hub に公開されており、production では latest に頼り続けず specific version を pin するよう README も促している。
macOS には graphical installation path があり、Linux と macOS には共通 install script、Windows には PowerShell entry point がある。agentdock update は platform release を download し、SHA-256 を検証し、新しい binary を確認し、古い binary を backup し、service 設定を検出した場合は restart と verification まで行う。Operations tool としては、source build 前提よりも日常利用に近い。
ただし project はまだ若い。v0.5.4、162 stars、2026 年 5 月以降の Git history という状態は、まだ急速に形が変わっている段階だと見たほうがよい。まずは personal dev machine、test VPS、non-critical automation で観察するのが妥当で、いきなり production write permission や sensitive directories を渡すべきではない。
注意したい境界
第一に、AgentDock が操作するのは real environment だ。Tool 自体が boundary を提供しても、実際の risk は公開した paths、commands、secrets、browser session、network endpoint に左右される。
第二に、multi-device coordination は誤操作の cost を大きくする。Agent が local test machine と production server を取り違えた場合、単一 repository の code edit より深刻になりうる。Instance naming、permission isolation、read-only / write boundary は明確にしたい。
第三に、これは complete Agent platform ではない。README は chat interface、model inference、model account、API quota を提供しないと説明している。上位の入口として ChatGPT、Claude、Codex、その他 MCP-compatible client が必要になる。
第四に、project は新しい。Frequent releases は active signal でもあるが、configuration、tool schema、installation method がまだ変わり続ける可能性もある。Team trial では version を lock し、AgentDock 自体も monitoring と rollback plan に入れておきたい。
まとめ
uvwt/agentdock が面白いのは、Agent tool calling を「current project directory」から「複数の real machines」へ広げているところだ。Model を賢くする project ではなく、model が environment に触れる方法を整理する project である。どこで file を読むのか、どこで command を走らせるのか、どこで logs を見るのか、どこで結果を検証するのかを明確にする。
Agent workflow がほぼ single repository coding で完結するなら、少し重く感じるかもしれない。しかし local machine、VPS、containers、browser admin を行き来する作業が多いなら、AgentDock は watchlist に入れてよい。個別 tool よりも参考になるのは、その素朴な原則だ。Agent に real environment を操作させる前に、permission、state、verification boundary を先に明確にする。