先に結論
Next.js 開発で迷いやすいのは、どの agent が一番賢いかより、Vercel 文脈をどこで持たせるかです。
ざっくり整理すると、役割はこう分かれます。
- Vercel plugin: Vercel / Next.js / AI SDK の知識を、Claude Code / Cursor / Codex に自動注入したいときに強い
- MCPサーバー: GitHub 以外の SaaS、社内API、DB、独自ツールを agent に接続したいときに強い
- 素の coding agent + repo rules: まず最小構成で始め、repo-local なルールだけで十分かを見極めたいときに強い
なので最初の選び方はこうです。
- Vercel / Next.js の比重が高く、agent に毎回 platform 文脈を説明するのが面倒 → Vercel plugin
- 外部ツールや社内データを agent に触らせたい → MCPサーバー
- 案件が単純で、Vercel 固有判断も少ない → 素の agent + rules
この3つは競合というより、知識注入・能力接続・repo 運用ルールという別レイヤーです。
Claude Code / Cursor / Codex そのものの比較は Cursor vs GitHub Copilot vs Claude Code、より広い自律 agent 比較は open-swe vs Claude Code vs Codex vs GitHub Copilot coding agent、MCP の立ち位置をもう少し抽象化して見たいなら GitAgent vs OpenClaw Skills vs MCPサーバー を先に読むとつながります。
なぜ今この比較が重要か
2026年3月、Vercel は Vercel plugin for coding agents を公開し、Claude Code と Cursor で使える形を出しました。公式 changelog では、Vercel plugin は単なる docs 検索ではなく、platform knowledge、skills、specialist agents、slash commands、post-write validation をまとめて agent に注入する仕組みとして説明されています。
さらに 2026-03-26 には、OpenAI Codex / Codex CLI 対応 も追加されました。つまり論点は「Claude Code だけに便利な専用機能」ではなく、複数の coding agent に対して、Vercel 文脈をどう与えるか に広がっています。
一方で、現場ではここが混ざりやすいです。
- Vercel plugin を入れるべきなのか
- MCPサーバーで十分なのか
- AGENTS.md や rules ファイルだけで足りるのか
この3つは同じ棚の話ではありません。
- Vercel plugin は、agent に Vercel / Next.js の知識を渡す仕組み
- MCPサーバー は、agent に外部ツールや外部データへ触る能力を渡す仕組み
- repo-local rules は、その repo で守ってほしい設計・実装・レビュー方針を渡す仕組み
つまり今大事なのは、Vercel 前提の repo で、何を runtime 側に持たせ、何を repo 側に持たせるか を切り分けることです。
比較表
| 比較軸 | Vercel plugin | MCPサーバー | 素の coding agent + repo rules |
|---|---|---|---|
| 主な役割 | Vercel / Next.js 文脈の自動注入 | 外部ツール・SaaS・DB 連携 | repo 固有ルールの共有 |
| 何が強いか | platform knowledge、skills、validation、slash commands | ability 拡張、社内システム接続、データ取得 | 導入初速、シンプルさ、制御性 |
| 向いている場面 | Vercel 固有の判断が多い開発 | Vercel 以外の外部能力が必要 | まず最小構成で始めたい案件 |
| 導入コスト | 低〜中 | 中 | 非常に低い |
| 制御性 | 中 | 中〜高 | 高い |
| 誤用しやすい点 | 過剰文脈注入への依存 | 何でも MCP で解決しようとする | Vercel 固有判断を毎回手で補う必要 |
| Claude Code / Cursor / Codex との関係 | 対応 agent に文脈を追加 | agent に tool 接続を追加 | agent をそのまま使う |
3つの違いを最初に整理する
Vercel plugin は「Vercel 文脈を自動で入れる」
Vercel plugin の価値は、agent を別物に変えることではありません。Vercel 前提のときだけ、必要な専門知識を自然に差し込むことです。
公式公開情報で強く出ている要素は次の通りです。
- Vercel / Next.js / AI SDK / Functions / Routing Middleware などの platform knowledge
- specialist agents
- slash commands
- file path や command、prompt signal に反応する skill injection
- deprecated pattern や stale API を補足する post-write validation
ここが効くのは、たとえば次のようなケースです。
next.config.tsや routing、middleware 周辺で Vercel 流の判断が必要- AI SDK や Vercel Functions を使っていて、フレームワーク更新に追従したい
- deploy、env、status のような Vercel 特有の導線を agent に理解させたい
- Claude Code / Cursor / Codex に、毎回 Vercel 文脈を手で説明したくない
逆に言うと、Vercel plugin は外部システム接続の一般解ではありません。GitHub、Notion、Stripe、社内DB などに触らせたいなら、それは plugin の仕事ではなく MCP 側の話です。
MCPサーバーは「能力をつなぐ」
MCPサーバーの役割は、agent が何に触れられるかを増やすことです。
たとえば、
- 社内 CMS から記事データを取る
- Notion や Linear を読む
- 独自 API を叩く
- DB を参照する
- デザインシステムの tokens や internal docs を読む
といった接続は、MCP の主戦場です。
重要なのは、MCP は Vercel 固有の実装判断を賢くする仕組みではないことです。もちろん Vercel 関連 API を MCP 経由で触らせることはできますが、それは「触れる」だけで、Next.js の設計判断や deprecation 検知まで自然に面倒を見てくれるわけではありません。
この誤解はかなり多いです。
- MCP がある = Vercel 文脈が自動で入る ではない
- plugin がある = 外部SaaS接続まで不要 でもない
MCP と plugin は、かなりきれいに役割が分かれています。
素の coding agent + repo rules は「最小構成」
三つ目は、Claude Code / Cursor / Codex をそのまま使い、AGENTS.md、rules、README、architecture docs で repo の方針を教えるやり方です。
これは軽視されがちですが、実はかなり重要です。
なぜなら、多くの案件では最初から plugin や MCP を増やさなくても、次の情報が repo にあれば十分進むからです。
- ディレクトリ構成
- 命名規約
- component / route 設計方針
- テスト方針
- deploy 前チェック
- PR の粒度
特に、
- 小〜中規模の Next.js repo
- Vercel 固有機能を深く使っていない
- チーム内で設計ルールがすでに明文化されている
なら、まずはこの最小構成から入る方が事故が少ないです。
Next.js / Vercel 開発でどれが強いか
1. Vercel plugin が強い場面
次のような repo では、Vercel plugin の価値がかなり出やすいです。
- App Router、middleware、edge / functions を横断する
- AI SDK、Vercel platform、observability、deploy 導線まで含めて触る
- 新しい Vercel 機能や推奨パターンに追従したい
- Claude Code、Cursor、Codex のどれを使っても Vercel 文脈を一定品質で入れたい
要するに、Vercel がただのホスティング先ではなく、設計判断に食い込んでいるかが分かれ目です。
2. MCP が強い場面
MCP が必要になるのは、Next.js を書くだけでなく、その周辺の情報や操作が必要なときです。
- headless CMS の下書きを読む
- analytics や product DB を参照する
- design tokens を internal system から取る
- support logs や feature flag 状態を見る
この手の仕事は、Vercel plugin だけでは埋まりません。Vercel 文脈ではなく、自社文脈を agent に与える必要があるからです。
3. 素の agent + rules で十分な場面
次の条件なら、最初はこれで十分です。
- pages / app がシンプル
- Vercel 固有の最適化が少ない
- deploy / env / edge 周りの複雑さが薄い
- チームの設計ルールが repo に書いてある
この段階で plugin や MCP を増やすと、むしろ「なぜうまくいったのか / 失敗したのか」が見えにくくなります。
Claude Code / Cursor / Codex の見え方はどう変わるか
Claude Code
Claude Code は重い実装委譲と長い文脈保持が強いので、Vercel plugin が入ると Next.js / Vercel 特化の実装相談相手 としてかなり扱いやすくなります。逆に plugin がなくても、repo rules が整っていれば大きな実装は十分進みます。
Cursor
Cursor は日常編集が速いので、Vercel plugin は 日常の修正のたびに Vercel 文脈を自然に差し込む補助輪 として相性が良いです。細かい UI 修正や route 修正の積み重ねでは効きやすいです。
Codex
2026-03-26 の対応追加で、Codex / Codex CLI でも Vercel plugin を使う意味が出ました。Codex は policy や sandbox 設計を重視する場面で強いので、そこに Vercel 固有知識だけ plugin で補う 形が取りやすいです。つまり、Codex を選ぶ理由と Vercel plugin を選ぶ理由はぶつかりません。
セキュリティ / 制御性の観点でどう考えるか
便利だからといって、何でも自動注入すればよいわけではありません。
見るべき論点は次の4つです。
- 何の知識を runtime 側で注入するか
- 何のルールを repo 側で明文化するか
- どの外部システムを MCP で接続するか
- agent にどこまで権限を与えるか
基本方針としては、こう考えるとブレにくいです。
- Vercel 共通知識 → plugin
- repo 固有の設計・レビュー・運用ルール → AGENTS.md / rules / docs
- 社内SaaS・DB・独自 API との接続 → MCP
この分離ができていないと、何か問題が起きたときに「plugin が悪いのか、MCP が悪いのか、repo rules が足りないのか」が切り分けにくくなります。
おすすめの導入順
多くのチームでは、次の順で入れるのが安全です。
1. まずは素の agent + repo rules
最初にやるべきは、repo 側の source of truth を整えることです。
- AGENTS.md / rules / README を整える
- Next.js / Vercel で守るべき実装方針を明文化する
- deploy / env / review の最低限の基準を書く
2. Vercel 固有の迷いが多いなら plugin を追加
次に、Vercel 文脈を毎回説明している、deprecation や platform 固有の判断ミスが多い、という状態なら Vercel plugin を足します。
3. 社内文脈が必要なら MCP を追加
最後に、repo の外にある知識や操作が必要になったら MCP を足します。ここで初めて「自社専用の能力」を agent に渡す意味が出ます。
まとめ
結論はシンプルです。
- Vercel plugin は、Vercel / Next.js 文脈の自動注入に強い
- MCPサーバー は、外部ツールや社内データ接続に強い
- 素の coding agent + repo rules は、最小構成として今でも強い
一番ズレにくい考え方は、plugin = Vercel 共通知識、MCP = 外部能力接続、rules = repo 固有運用 と分けることです。
Vercel 前提の Next.js チームなら、まず repo rules を整え、そのうえで Vercel 文脈が足りなければ plugin、社内文脈まで必要なら MCP、と段階的に足すのがいちばん失敗しにくいです。