# Vercel Ship 26 まとめ

> Vercel Ship 26の主要発表(eve・Vercel Agent・Connect・Services)を図解つきで整理しました。テーマは「エージェントを本番で安全に動かす」。フロント専用ではなくなるVercelの現在地です。

- 公開日: 2026-07-02
- 著者: 村井 謙太
- タグ: Vercel, AIエージェント
- URL: https://tech.anycloud.co.jp/articles/vercel-ship-26

---

2026年6月17日、Vercelの年次カンファレンス「Vercel Ship 26」がロンドンで開催されました。Shipとしては初の米国外開催で、参加者は2,500人超だった[と報じられています](https://www.digitalapplied.com/blog/vercel-ship-2026-agents-half-of-deployments-enterprise-stack)。

私は現地にも配信にも参加していないので、この記事は[公式のリキャップ](https://vercel.com/blog/vercel-ship-2026-recap)と各発表ブログを読んでまとめたものです。

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

## 発表の全体像

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

![Vercel Ship 26の主な発表を3レイヤーで整理した図。作る=eve・AI SDK 7、本番で動かす=Vercel Agent・Connect・Passport、土台=Vercel Services・Dockerfile対応](./ship26-map.webp)

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

## eveは「Next.js for agents」

いちばん注目したのは[eve](https://vercel.com/blog/introducing-eve)です。ステージでは「Next.js for agents」と紹介されたそうです。

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

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

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

![eveのエージェントのディレクトリ構造。agent/配下にinstructions.md(必須のシステムプロンプト)、agent.ts(設定)、tools/(TypeScriptの型付き関数)、skills/(Markdownの手順書)、channels/(Slack・HTTPの入口)、schedules/(cron)が並ぶ](./eve-directory.webp)

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

```ts
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割以上を自律解決するエージェントがいる[とのことです](https://vercel.com/changelog/introducing-eve-an-open-source-agent-framework)。

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

なお、この「エージェントを本番で動かし続ける基盤」の層では、Anthropicも2026年4月にClaude Managed Agentsを出しています。両社のスタックの対応関係は[別の記事](https://tech.anycloud.co.jp/articles/claude-vercel-agent-stack/)に整理しました。

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

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

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

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

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

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

![エージェントに渡すクレデンシャルの比較図。これまでは.envの長寿命APIトークンでフルアクセスさせていたが、Vercel Connectではタスクにスコープした期限付きの一時クレデンシャルを発行する](./connect-credentials.webp)

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

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

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

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

![構成の変化を示す図。これまではVercelにフロントエンドのみ置き、APIサーバーは別のクラウドにあった。Ship 26後は1つのVercelプロジェクトにフロントエンドとバックエンドを同居させられる](./vercel-fullstack.webp)

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

## 所感

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

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