AI coding agent は、「ローカルで動く command line assistant」から「platform の一機能」へ広がりつつあります。Agent を product の中で複数回、複数ユーザー向けに動かそうとすると、問題は model 選びだけではありません。Code はどの isolated environment で実行するのか。Image と dependency をどう再利用するのか。Cloud sandbox をどう切り替えるのか。Streaming、approval、tool use、multimodal input を保ったまま扱えるのか。

今日紹介する TwillAI/agentbox-sdk は、この実行層を扱う project です。TypeScript SDK として、同じ Agent / Sandbox API から Claude Code、OpenCode、Codex と複数の sandbox provider をつなぎます。GitHub のページでは現在およそ 155 stars15 forks、主な言語は TypeScript、ライセンスは MIT。GitHub release はまだ公開されていません。Git history では最初の commit が 2026 年 4 月 7 日、最近の commit が 2026 年 5 月 25 日です。npm の agentbox-sdk は最新 version 0.1.315 が 2026 年 5 月 25 日に公開されています。

プロジェクト概要

項目内容
リポジトリTwillAI/agentbox-sdk
Stars約 155
Forks15
主な言語TypeScript
ライセンスMIT
最初の commit2026 年 4 月 7 日
最近の commit2026 年 5 月 25 日
GitHub release未公開
npm 最新 version0.1.315

実行層の問題を扱う

多くの AI coding tool は、ユーザーが自分の project directory で CLI を起動することを前提にしています。この形は個人開発には十分です。しかし agent を Web product、internal platform、CI、evaluation system、batch queue に入れると、runtime layer は急に複雑になります。

Clean working directory が必要です。Repository を clone し、dependency を入れ、必要最小限の secret を渡し、preview port を開き、task の終了後に環境を消す必要があります。Local Docker で十分な時もあれば、E2B、Modal、Daytona、Vercel の cloud sandbox を使いたい時もあります。さらに、agent ごとに start 方法、event format、approval flow、hook の仕組みが違います。

AgentBox の価値は、新しい agent を作ることではありません。この差分を SDK の中に寄せることです。Application code は「sandbox を一つ用意して、その中で agent を走らせる」と書けます。Provider ごとの処理を product code 全体へ散らさずに済みます。

Agent と Sandbox を別々に選ぶ

README の中心にある設計は、二つの軸を独立して差し替えられることです。

Agent provider は Claude Code、OpenCode、Codex を扱います。Sandbox provider は local Docker、E2B、Modal、Daytona、Vercel を扱います。つまり、同じ upper-level workflow を local Docker 上の Claude Code で始め、あとから E2B 上の Codex に変えたり、Modal 上で OpenCode を試したりできます。

これは agent platform を作る側にとって大きいです。初期には development machine の Docker だけで task flow を検証し、あとで concurrency と isolation が必要になったら cloud sandbox に移れます。Agent CLI も変わります。今日は Claude Code、明日は Codex や OpenCode という選択もあります。AgentBox はこれらの変更点を constructor parameter に閉じ込め、application 全体へ漏れにくくします。

もちろん、抽象化が差異を消すわけではありません。Sandbox provider ごとの auth、image、port、lifecycle は残ります。Agent ごとの model 名や能力差もあります。AgentBox はすべてを同一に見せるというより、違いを明確な場所に置く SDK です。

単なる shell out ではない

AgentBox README は、CLI を non-interactive command として一回実行するだけではない、と説明しています。Sandbox 内で agent を server process として立ち上げ、WebSocket または HTTP で通信します。これにより、streaming events、approval flows、tool-use control などの interactive capability を保てます。

ここが普通の wrapper script との大きな違いです。多くの platform prototype は、child_process で CLI を起動して stdout を読むところから始まります。Demo には十分ですが、agent を product に入れると stdout だけでは足りません。Run の event stream、text delta、tool call、approval point、final result、error state を扱う必要があります。

AgentBox は agent.run()agent.stream() を用意しています。前者は一回の task に向き、後者は async iterable として normalized events を返します。Web UI なら agent output をリアルタイムに表示できます。Backend queue なら event を保存し、tool call を監査し、必要なら中断や approval を差し込めます。

Sandbox lifecycle が明示的

AgentBox の Sandbox は、constructor を呼んだ瞬間に実環境を作りません。README では、先に findOrProvision() を呼ぶことが求められます。その後の rungitCloneuploadAndRun、agent run などは同じ sandbox を再利用します。

この設計は小さく見えて重要です。Remote sandbox の作成は遅いこともあり、cost もかかります。既存環境を再利用したい場面もあれば、毎回新規作成したい場面もあります。Attach / create の段階を明示すると、呼び出し側が cost、concurrency、cleanup timing を制御しやすくなります。

SDK は common operation も同じ interface に寄せています。run()runAsync()gitClone()uploadAndRun()openPort()getPreviewLink()snapshot()stop()delete() などです。Agent 実行前後の準備と片付けを標準化しやすくなります。

たとえば「user ごとに temporary workspace を開き、agent が bug を直し、preview link を返す」ような product では、provider SDK を直接つなぐより扱いやすい層になります。

Skills、sub-agents、MCP も扱う

AgentBox は「prompt を agent に送る」だけではありません。README には skills、sub-agents、MCP servers、custom slash commands、hooks、multimodal input の例もあります。

これは、より完整な agent runtime を意識していることを示しています。Claude Code に GitHub repository 形式の skill を付けることもできます。小さな skill file を inline で埋め込むこともできます。Reviewer のような sub-agent を定義できます。Filesystem や remote service を MCP server として接続できます。/triage のような custom command も登録できます。

Application developer にとって、これは現実的です。本当の agent product には固定 workflow が必要です。毎回 prompt に「この tool と workflow を使って」と長く書くより、SDK parameter として workflow を渡すほうが安定します。

Image と provider 移行が重要

AgentBox は image build CLI も提供しています。Built-in preset で sandbox image を作ることも、自分で my-image.mjs を書いて image を定義することもできます。README の例では Node base image、system dependency、pnpm / Claude Code の global install、Playwright browser install などが含まれています。

これは地味ですが、agent platform の安定性を左右します。AI coding agent は純粋な inference service ではありません。Git、package manager、compiler、browser、system library、test database、project-specific toolchain が必要です。毎回 runtime で全部入れると、遅く不安定になります。

README では、image build が provider ごとの reference を出すことも説明されています。Local Docker tag、Modal image ID、E2B template、Daytona snapshot などです。AgentBox は task call だけでなく、「実行環境を準備する」部分も差し替え可能な layer に入れようとしています。

向いている場面

AgentBox は、agent product や internal platform を作っている人に向いています。普通の個人利用者にとっては、すぐ必要な tool ではないかもしれません。

Project directory でたまに Codex や Claude Code を起動するだけなら、既存 CLI で十分です。AgentBox が本当に効くのは、次のような場面です。

  • Web application から isolated coding agent を起動したい。
  • CI や evaluation system で agent を batch 実行したい。
  • Docker、E2B、Modal、Daytona、Vercel の間で execution environment を切り替えたい。
  • Claude Code、OpenCode、Codex の runtime events を統一したい。
  • Skills、MCP、sub-agents、hooks を platform configuration として管理したい。
  • Agent が code を生成したあと、preview port や snapshot を扱いたい。

つまり、これは terminal chat tool ではなく、agent runtime SDK に近い project です。

注意点

AgentBox はまだ早い段階にあります。Version は 0.1.x で、GitHub release もまだありません。npm では継続的に version が出ていますが、production platform に入れる前には、single provider と low-risk task で検証するのが現実的です。

また、unified API は「すべての provider が完全に同じ」という意味ではありません。README からも、Vercel sandbox では作成時に port を宣言する必要があることや、snapshot の扱いが provider によって違うことがわかります。実際の導入では、provider ごとの limit、pricing、cold start、network policy、credential handling を理解する必要があります。

Security boundary も重要です。Agent は sandbox 内で code と command を実行します。渡す API key、repository permission、network access、preview port は最小限にするべきです。AgentBox は構造を与えますが、permission model、log retention、cleanup policy は platform 側が設計する必要があります。

まとめ

TwillAI/agentbox-sdk は、AI coding agent が personal CLI から platform capability へ移る時に出てくる問題を扱っています。難しいのは model call だけではなく、runtime environment、isolation、event stream、provider migration です。AgentBox は TypeScript SDK として、agent provider と sandbox provider を二つの差し替え可能な軸に分け、streaming、approval、skills、MCP、hooks、preview、snapshot を同じ interface に寄せています。

まだ成熟した infrastructure ではありませんが、方向性は実用的です。Agent platform、internal automation、evaluation system、multi-provider experiment を作っている team なら、AgentBox は追いかける価値のある小さな project です。

リポジトリ:https://github.com/TwillAI/agentbox-sdk