Vercel Ship 26 まとめ

2026年6月17日、Vercelの年次カンファレンス「Vercel Ship 26」がロンドンで開催されました。Shipとしては初の米国外開催で、参加者は2,500人超だったと報じられています。

私は現地にも配信にも参加していないので、この記事は公式のリキャップと各発表ブログを読んでまとめたものです。

Anycloudはクライアントのプロダクト開発支援をしていて、プロダクトの立ち上げではNext.jsとVercelの組み合わせが選択肢としてよく登場します。その現場の目線で、今回の発表がどう見えたかを書きます。

発表の全体像

発表は数が多いので、「エージェントを作る」「エージェントを本番で動かす」「プラットフォームの土台」の3つのレイヤーに整理してみました。

基調講演の軸は「エージェントを本番で安全に動かす」で、Vercel上のデプロイの半数以上がコーディングエージェント起点になった、という数字が示されたそうです。

eveは「Next.js for agents」

いちばん注目したのはeveです。ステージでは「Next.js for agents」と紹介されたそうです。

エージェントを作ろうとすると、モデルに何をさせるかを考える前に、会話の状態管理、ツール呼び出しのループ、生成コードを隔離して実行する環境、認証、ログといった足回りの自作に時間を取られます。

Vercelはこれを「どのチームも同じ配管を作り直していて、次のエージェントに何も引き継がれない」と表現していて、その配管ごとフレームワーク側に入れたのがeveです。Next.jsがルーティングやSSRの自作を終わらせたのと同じ狙いで、Apache 2.0のOSSとしてGitHubに公開されています。

eveでは、エージェント1体を1つのディレクトリで表現します。READMEに載っているプロジェクト構造を図にするとこうなります。

エージェントの役割を決める常時有効なプロンプトが instructions.md、必要なときだけ読み込まれる手順書が skills/ で、ここまではMarkdownで書きます。モデルに使わせる機能は tools/ にTypeScriptの関数として置きます。公式ブログの例では、SQLを実行するツールがこれだけで定義されています。

export default defineTool({
  description: "Run a read-only SQL query",
  inputSchema: z.object({ sql: z.string() }),
  async execute({ sql }) { /* ... */ },
});

ファイルを置けばモデルから呼べるようになる、という規約はNext.jsのファイルベースルーティングとよく似ています。Slackからの呼び出し口は channels/、cronでの定期実行は schedules/ に足していきます。

足回りも最初から入っています。会話はチェックポイント付きの永続ワークフローとして動いてクラッシュやデプロイをまたいで再開でき、生成コードはサンドボックスに隔離され、危険な操作には人間の承認を挟めます。デプロイは普通のプロジェクトと同じ vercel deploy です。

eveはVercel社内ですでに100体動いている

Vercel社内では100以上のエージェントがeveで本番稼働していて、Slackで月3万件超の質問に答えるデータアナリストや、サポートチケットの9割以上を自律解決するエージェントがいるとのことです。

面白いのは「指示をMarkdownファイルとして置く」という流儀です。このブログでもClaude CodeのAgent Skillsを扱ってきましたが、発想は同じです。エージェントの本体がプロンプトの塊ではなく「読めるファイルの集まり」になっていく流れは、ツールをまたいで定着しそうです。

なお、この「エージェントを本番で動かし続ける基盤」の層では、Anthropicも2026年4月にClaude Managed Agentsを出しています。両社のスタックの対応関係は別の記事に整理しました。

Vercel Agentは調査から修正PRまで出す

Vercel Agentは、本番デプロイを監視して、アラートや異常を自律的に調査し、修正をPRとして開くエージェントです。デプロイ・ログ・メトリクス・プロジェクト設定といったVercel上のシグナルをそのまま読める位置にいるのが、汎用のコーディングエージェントとの違いです。

権限のモデルも特徴的で、デフォルトはread-onlyです。本番に触る前に「このタスクにはこの権限が要る」というスコープ付きの計画を提示し、承認を得てから動きます。

PRのコードレビューも担当していて、提案するパッチは実際のビルドやテストをサンドボックスで通したものだけに絞られます。PRコメントで @vercel にメンションして修正を頼むこともできます。提供はPro/Enterpriseチーム向けのパブリックベータで、段階的にロールアウト中です。

Vercel Connectは長寿命トークンをなくす

Vercel Connectは、エージェントが外部サービスにアクセスするとき、環境変数に長寿命トークンを置く代わりに、目の前のタスクにスコープされた一時クレデンシャルを発行する仕組みです。

エージェントに仕事を任せ始めると、真っ先に悩むのが「どこまで権限を渡すか」です。人間用に発行したAPIトークンを.envに置いてエージェントに読ませる運用は、動きはするものの怖さが残ります。その怖さにプラットフォーム側が答えを出しにきた、という印象を受けました。

Vercelはフロント専用ではなくなる

Vercel Servicesでは、フロントとバックエンドを同じプロジェクトで開発・デプロイできます。バックエンドだけの変更でもプレビュー環境が立ち、サービス間の通信はパブリックインターネットを経由しません。

あわせてDockerfileのビルド・実行とコンテナレジストリ、FastAPI・Flask・Express・Honoといったバックエンドフレームワークのサポートも発表されました。GoのサーバーもShip 26に先立つ4月からゼロコンフィグで動くようになっていて、Servicesでは言語の違うサービスを1つのプロジェクトに同居させられます。

プロダクトの立ち上げ期に、フロントはVercel、APIは別のクラウド、と分けると、それだけでインフラの認知コストが増えます。「最初は全部Vercelに置いて、規模が出てきたら必要な部分だけ剥がす」という構成が現実的な選択肢になってきました。

所感

クライアントのプロダクト開発支援という立場からは、今回の発表は「エージェントが書いたコードを、誰が安全に本番へ運ぶのか」という問いへのVercelの答えに見えました。コードを書く速度はClaude CodeやCodexですでに上がっていて、ボトルネックはレビュー・権限・デプロイといった「運び」の部分に移っています。Vercel AgentやConnectの権限モデルは、そこを正面から扱っています。

プライベートベータのものも多く、手元のプロジェクトで今すぐ全部に乗れるわけではありません。ただ、eveとAI SDK 7はOSSとして今日から触れるので、様子見で困ることはなさそうです。エージェントの構成が「Markdown+TypeScriptのディレクトリ」という読める形に収まってきたのは、開発を支援する側として歓迎したい変化です。