半年前は3%、いま過半数 — Vercel Ship 2026が示したエージェント駆動のリアル

6ヶ月前、Vercel上でコーディングエージェントが引き起こすデプロイは全体の3%未満だった。

2026年6月17日、ロンドンで開催されたVercel Ship 2026の壇上で示された数字は、50%超。月間のAIトークンの流量も、約2兆から約20兆へ10倍に膨れた。2,500人以上が集まったこのカンファレンスで最も響いたのは、新製品の発表ではなく、この2つの数字だったと思う。

人間がボタンを押してデプロイする行為が、もはや多数派ではなくなった。

Vercelはこの現実に対して、4つの回答を用意した。オープンソースのエージェントフレームワーク「eve」、認証情報を安全に渡す「Connect」、バックエンドとフロントエンドを統合する「Services」、そしてエージェントの挙動をIdPで制御する「Passport」。それぞれ何ができて、何が変わるのかを整理する。

「エージェントのためのNext.js」という野心

eveは、Vercelが「Next.js for Agents」と位置づけるオープンソースフレームワークだ。Apache 2.0ライセンス、TypeScriptネイティブ。

設計思想がユニークで、エージェントを「ファイルの集合体」として扱う。具体的にはこうなる:

agent/
  instructions.md    # エージェントへの指示（自然言語）
  tools/
    search.ts        # ツール（TypeScriptの関数）
    database.ts
  skills/
    onboarding.md    # スキル（手順の定義）

ディレクトリにファイルを置けば、eveが自動で検出してエージェントを組み立てる。LangChainやCrewAIのように大量のボイラープレートコードを書く必要がない。Next.jsがページをファイルシステムベースで定義したのと同じ発想を、エージェントに持ち込んだ形だ。

本番環境で必要になる機能がデフォルトで入っている点も見逃せない。会話の各ステップがチェックポイントされる耐久実行（Durable Execution）により、セッションが中断してもクラッシュしても、再開時に前回の地点から続行できる。サンドボックス化されたコード実行、サブエージェントの呼び出し、人間による承認ステップ（Human-in-the-loop）、そして評価（Evals）が箱から出してすぐに使える。

正直、フレームワークとしての完成度は高い。Vercel Functionsの上で動くため、別途ホスティング環境を用意する必要がない。Next.jsのプロジェクトにagent/ディレクトリを追加するだけでエージェントが動く世界は、開発者にとっては魅力的だ。

ConnectとPassport — エージェントに「短命の鍵」を渡す

eveが「エージェントの脳」だとすれば、Connectは「エージェントの手足」を安全にする仕組みだ。

従来、エージェントがSlackやGitHub、Salesforceなどの外部サービスにアクセスするには、長寿命のAPIトークンを環境変数に保存していた。これは素朴に危険だ。トークンが漏洩すれば、エージェントがアクセスできるすべてのサービスが丸裸になる。

Vercel Connectは、エージェントがタスクを実行するたびにスコープ付きの短寿命トークンを発行する。1つのタスクが終われば、そのトークンは失効する。監査証跡も残る。ローンチ時点でSlack、GitHub、Snowflake、Salesforce、Notion、Linearとの統合が用意されている。

料金は、Hobbyプランなら無料枠あり。ProとEnterpriseでは10,000トークンリクエストあたり$3（約440円）。1回のAPI呼び出しごとにトークンを発行する設計なので、エージェントが頻繁に外部サービスを叩くワークロードではコストが積み上がる可能性がある。ここは注意が必要だ。

Passportは、社内アプリやエージェントをIdP（Identity Provider）の認証で保護する機能。いわばVercel版のゼロトラストだ。外部に公開しない社内ツールをVercel上に置く場合、Passportで認証をかけておけば「エージェントが勝手に社外にデータを送る」リスクを制御できる。

Vercel Services — バックエンドとフロントエンドの壁がなくなる

7月1日にベータ提供が開始されるVercel Servicesは、フロントエンドとバックエンドを1つのプロジェクト内で統合する。

これまでVercelは「フロントエンドのデプロイプラットフォーム」という印象が強かった。Next.jsのSSRやAPIルートは使えても、本格的なバックエンドサービスは別のインフラ（AWS、Fly.io、Railway等）に置くのが一般的だった。

Servicesでは、同一プロジェクト内の複数サービスがプライベートネットワークで通信する。パブリックインターネットを経由しない。認証も自動で処理される。1つのコミットから、フロントエンドもバックエンドもeveエージェントも含めた統一プレビューURLが生成される。

エージェント開発の文脈で見ると、この統合は大きい。eveで作ったエージェントがバックエンドの処理を呼び出し、結果をフロントエンドに反映する。その一連の流れが同じプロジェクト内で完結する。

「デプロイの過半数がエージェント経由」の本質

ここで立ち止まって考えたい。50%超という数字は、何を意味しているのか。

Vercelのユーザーの多くは、v0やCursor、Claude Code、Lovable、Boltなどのコーディングエージェントを使っている。これらのツールが「アプリを作って」という指示を受けると、コードを生成し、Vercelにデプロイする。人間がgit pushするのではなく、エージェントがデプロイメントを発火させる。

重要なのは、この数字がVercel自身の内部データから出ているということだ。独立した第三者による検証ではない。とはいえ、Supabaseの「新規DBの60%がAI経由」という数字と合わせて考えると、インフラ層がエージェントのデフォルトの受け皿になっているトレンドは間違いないだろう。

この流れが加速すると、インフラの選択は「開発者が選ぶ」ものではなく「エージェントが選ぶ」ものに変わる。eveをVercel Functionsの上で動かし、ConnectでSaaSと接続し、Servicesでバックエンドもフロントエンドもまとめる。Vercelがやろうとしているのは、エージェントにとっての「一番楽なデプロイ先」になることだ。

気になる点

Vercelが描く未来は筋が通っているが、いくつか気になることもある。

ベンダーロックイン。eveはオープンソース（Apache 2.0）だが、Durable ExecutionやConnect、Sandboxなどの本番向け機能はVercelのインフラに依存する。eveで作ったエージェントをAWSやGCPに持っていくのは、現時点では現実的ではない。「Next.js for Agents」と謳っているが、Next.jsもVercelから離れると機能が制限されるのと同じ構図だ。

Connectのコスト設計。10,000リクエストあたり$3は一見安いが、エージェントは人間よりはるかに頻繁にAPIを叩く。1つのタスクで複数のサービスに10回、20回とアクセスするケースを考えると、月額コストが読みにくい。

LangChain/CrewAIとの差別化。ファイルシステムベースの定義は新しいが、LangGraphの状態管理やCrewAIのマルチエージェント協調など、既存フレームワークが強みを持つ領域で、eveがどこまで追いつけるかはまだ未知数だ。

何が変わるのか

とはいえ、Ship 2026が示した方向性は明確だ。「エージェントがデプロイする時代」のインフラを、Vercelが本気で取りに来ている。

eveのファイルシステムベースの設計は、Next.jsを触ったことがある開発者なら直感的に理解できる。Connectの短寿命トークンは、エージェントにAPIアクセスを渡すときの「怖さ」を軽減する。Servicesでフロントエンドとバックエンドの壁がなくなれば、エージェントが触れる範囲が一気に広がる。

6ヶ月で3%から50%超へ。次の6ヶ月でこの数字がどうなるかは分からないが、一つだけ言えるのは、デプロイボタンを押す主体がもう人間だけではないという事実は、覆らないということだ。