Open Agentsを読む前に押さえる設計要点

Vercelが公開した Open Agents は、単なるAIチャットのテンプレートではありません。Web UI、Durable Workflow、Sandbox、GitHub連携までをまとめて含んだ、背景実行型エージェントの参照実装です。つまり本質は、AIにコードを書かせるデモではなく、エージェントを止まらずに運用するための基盤設計 にあります。

この記事では、Vercelのテンプレページ、GitHubリポジトリ、公開デモをもとに、Open Agentsのどこが重要なのかを整理します。特に、なぜ Agent と Sandbox を分けるのか、GitHub App や Vercel OAuth がなぜ必要なのか、そしてこれが今後のエージェント実装の標準パターンになり得る理由まで掘り下げます。

• テンプレページ: https://vercel.com/templates/template/open-agents
• GitHub: https://github.com/vercel-labs/open-agents
• Demo: https://open-agents.dev/

Open Agentsは何をまとめたテンプレートなのか

Open Agentsは、Vercel上で背景実行するコーディングエージェントを組むための reference app です。ここでいう reference app は、UIだけ配ったスターターではなく、実際に動く構成要素を一式まとめた雛形に近いです。

Vercelの説明では、構成は次の3層です。

• Web: 認証、セッション、チャット、ストリーミングUI
• Agent workflow: 長時間実行、再開、キャンセル、状態保持
• Sandbox VM: ファイルシステム、shell、git、dev server、preview port

公開デモの文面でも、Open Agentsは AI SDK / AI Gateway / Sandbox / Workflow SDK を土台にしていることが明示されています。ここが大事で、Open Agentsの価値は1つのモデル性能ではなく、複数の基盤を束ねてエージェント運用に落とし込んでいること にあります。

たとえばチャットで依頼を受けたあと、エージェントが別スレッドで作業を続け、Sandbox内でブランチを切り、必要ならGitHubへpushやPRまで進める。この一連の流れを、ブラウザを閉じても継続できるようにしているのがOpen Agentsです。

いちばん重要なのはAgentとSandboxを分ける設計

Open Agentsの説明で最重要なのは、agent is not the sandbox という設計思想です。つまり、エージェント本体はVMの中で動かず、外側からツール経由でSandboxを操作します。

この分離には、見た目以上に大きな意味があります。

• エージェント実行がHTTPリクエストの寿命に縛られない
• Sandboxは休眠・再開でき、計算資源を別管理できる
• モデルやプロバイダを後から差し替えやすい
• VMを制御プレーン化せず、実行環境として単純に保てる

要するに、推論する頭脳 と 実際に手を動かす作業場 を分けているわけです。この構造にすると、OpenAI系、Claude系、Gemini系のどれを使うかが変わっても、Sandboxの作り直しを最小限にできます。AIモデルの世代交代が速い今、この疎結合はかなり効きます。

さらにVercelの説明では、Sandboxはスナップショットから再開でき、ポート 3000 / 5173 / 4321 / 8000 を公開でき、一定時間でhibernateする設計です。これは単なる開発体験の話ではなく、長時間タスクをクラウドで安全に回す運用設計 そのものです。

GitHub連携があるから実際の開発フローに入れられる

Open AgentsはGitHubリポジトリ連携を前提に作られています。テンプレページとGitHub README相当の説明を見ると、想定フローはかなり明確です。

• GitHub App をインストールする
• リポジトリをSandboxにcloneする
• エージェントがブランチ上で作業する
• 成功したら auto-commit / push / PR 作成まで進められる

ここで必要になる環境変数も具体的です。

• NEXT_PUBLIC_GITHUB_CLIENT_ID
• GITHUB_CLIENT_SECRET
• GITHUB_APP_ID
• GITHUB_APP_PRIVATE_KEY
• NEXT_PUBLIC_GITHUB_APP_SLUG
• GITHUB_WEBHOOK_SECRET

つまり、Open Agentsは見た目はチャットでも、実際には GitHub App を使った開発自動化の制御面 をかなり本気で作っています。ローカルPCでCLIを動かすだけのエージェントと違って、クラウド上で継続実行しながら、コード変更をGitHubの標準フローに戻していける点が実務的です。

GitHubページからそのままVercelへデプロイ導線が用意されている点も実務的です。テンプレートの導入ページから、リポジトリ複製と初期デプロイまで短い動線で進められるため、まずは検証環境を素早く立ち上げたいチームに向いています。

実運用で見るべきはWorkflow SDKと認証まわり

Open Agentsを試すだけならテンプレを眺めれば十分ですが、実際に自分で動かすなら、肝は Workflow SDK と認証設定 です。Vercelの案内では最低限でも次が必要です。

• POSTGRES_URL
• JWE_SECRET
• ENCRYPTION_KEY

さらに、Vercelログインを機能させるには以下も要ります。

• NEXT_PUBLIC_VERCEL_APP_CLIENT_ID
• VERCEL_APP_CLIENT_SECRET

そしてGitHubまで含めると、前述のGitHub App一式が必要です。つまりOpen Agentsは、単に bun run web で終わるサンプルではなく、認証・暗号化・外部連携を含む本番寄りの雛形 です。

この重さこそが、逆にOpen Agentsの価値でもあります。AIエージェントの議論は、どうしてもモデルの賢さやコーディング精度に寄りがちです。でも実際に現場で詰まるのは、長時間実行、失敗時の再開、認証、権限、push先、監査可能性のような運用部分です。Open Agentsは、そこを最初から構成要素として見せてくれている点が強いです。

Open Agentsの本質はエージェント運用基盤の参照実装にある

Open Agentsを一言で言うなら、AIにコードを書かせるアプリではなく、エージェント運用基盤の参照実装 です。Web UI、Workflow SDK、Sandbox、GitHub App、AI Gatewayを分けて組み合わせる構造は、今後ほかのエージェント製品でも繰り返し出てくるはずです。

特に重要なのは次の3点です。

1. 会話と実行を分けていること
2. モデルと実行環境を分けていること
3. GitHubを最終成果物の受け皿にしていること

この3つが揃うと、エージェントは単発デモではなく、継続的な開発フローの一部になります。だからOpen Agentsは、SaaS連携の数よりも、runtime と harness の設計が本体 と見たほうが正確です。

もしOpen Agentsのような構造を自社向けに応用するなら、見るべきは派手なデモ画面ではありません。どこに状態を持つか、どこで再開するか、どの権限でGitHubへ触るか、どこまでをSandboxに閉じ込めるか。この設計が固まってはじめて、AIエージェントは運用に耐える形になります。inovieでも、こうしたエージェント基盤の整理、PoC設計、業務への実装支援まで伴走しています。まずは、自社で何を自律実行させたいのかを明確にするところから始めるのが一番です。