目次
「Claude Code に修正させた → でもデプロイは手動で git push して、ブラウザで Vercel のダッシュボードを開いて……」。この往復を減らす手段を、Vercel は公式に3つ出している。Vercel MCP（AI ツールから Vercel のプロジェクト・デプロイ・ログを操作するサーバー）、Vercel Plugin（Claude Code や Cursor に Vercel の知識とスラッシュコマンドを足す拡張）、Agent Skills（npx skills add で入れる手順書の束）だ。名前が似ているうえに役割が重なって見えるので、「Agent Skills を MCP で繋ぐ」のような混ざった説明がよく出回っている。
結論から書く：AI エージェントから Vercel へ出す方法は3つのアプローチに分けて考えるとよい。① Git 連携（git push → 自動デプロイ）は個人開発ならこれで足りる。② エディタから直接（Vercel MCP・Vercel Plugin）は、ログを読ませる・環境変数を触らせるなど、デプロイの前後まで AI に任せたい人向け。③ GitHub Actions + Claude Code Actionは、PR コメントで @claude に直させ、テストや承認のゲートを通してから出したいチーム向け。「どれが最強」ではなく「どこまで AI に任せ、どこで人が止めるか」で決まる。
本記事は Vercel と Anthropic の公式ドキュメントの原文を 2026年9月30日に読み直して書いた。設定例・コマンド・プランの条件はその時点のものだ（どちらも更新が速いので、使う前に文中のリンク先で確かめてほしい）。AI推奨Vercel、Cursor解説、AIにインフラ任せていい？ も併せて読むと判断しやすい。
3つのワークフロー——個人 / 日常の操作 / チーム
— AI にどこまで任せ、どこで人が止めるか
どのアプローチでも プレビューまでは自動、本番は人が承認が基本。
Vercel 自身も MCP のドキュメントで 「人による確認を必ず有効に」と勧めている。
1. 「Agent Skills」「MCP」「Plugin」は別物
AI にコードを書かせても、デプロイの確認は別の画面——ターミナルに戻って git add . && git commit -m "fix" && git push、ブラウザで Vercel のダッシュボードを開き、プレビューURL をコピーして Slack に貼る。この切り替えを減らすために、Vercel は段階的に AI 向けの入口を増やしてきた。
時系列で並べると混同がほどける。2025年8月4日、Vercel MCP が公開ベータになった（Vercel の告知）。https://mcp.vercel.com に置かれた OAuth で認証するリモート MCP サーバーだ。同じ月の 2025年8月には Anthropic の Claude Code GitHub Action の v1.0 が出た（v1.0.0 のタグは 2025-08-25）。2026年3月17日には Vercel Pluginが出て（告知）、2026年7月23日には Vercel MCP からコードを直接デプロイできるようになった（告知）。
そして Agent Skills は MCP ではない。Vercel の Agent Skills のページは、npx skills add <owner/repo> で入れる「エージェントに特定の手順を教える部品」として説明していて、Claude Code・GitHub Copilot・Cursor など18以上のエージェントで使えるとしている。MCP がアカウントへの操作の手段なら、Skills はやり方の知識だ。MCPとは、Claude Agent SDK も参考になる。
2. Vercel の5つの入口——何ができて、どう認証するか
AI エージェントから Vercel に触れる入口を、公式ドキュメントの記述どおりに並べる（2026年9月30日時点）。「何を AI に渡すか」＝認証の欄が、事故の大きさを決める。
| 入口 | 何ができるか | 入れ方 | 認証 | 条件・注意 |
|---|---|---|---|---|
| Git 連携（Vercel for GitHub など） | push のたびにビルド・デプロイ、PR ごとのプレビューURL、本番のロールバック | ダッシュボードでリポジトリを Import | GitHub App（AI には何も渡さない） | 非公開リポジトリは、コミットの作者が Vercel 側で権限を持つ必要がある |
| Vercel CLI | vercel deploy・vercel env・vercel rollback など全操作 | npm i -g vercel | 対話ログイン、CI では VERCEL_TOKEN | トークンは強い権限を持つので、CI では Secrets に置く |
| Vercel MCP | デプロイの作成・一覧、ビルドログ・実行ログ、環境変数、ロールバックなどをツールとして呼ぶ | クライアントに https://mcp.vercel.com を登録 | OAuth（ブラウザでログインし、使わせるチームを選ぶ） | ベータ版・Vercel が審査したクライアントのみ接続可・自分の Vercel アカウントと同じ権限を持つ |
| Vercel Plugin | Vercel の知識（28 skills）・専門エージェント3つ・スラッシュコマンド5つ | npx plugins add vercel/vercel-plugin | 操作は手元の Vercel CLI 経由 | Node.js 18 以上と Bun が必要、対応は Claude Code・Cursor・Codex CLI・VS Code など |
| Agent Skills | 特定の作業の手順書（例：vercel-deploy・vercel-cli） | npx skills add vercel-labs/agent-skills | Skills 自体は認証を持たない | 実際の操作は CLI や MCP が行う |
出典：Vercel MCP・MCP のツール一覧・Vercel Plugin・Agent Skills・コミットでデプロイされないとき（Vercel KB）。
読み方のコツ：「デプロイできる」だけなら Git 連携で足りる。MCP や Plugin が効くのは、ビルドが落ちた理由をログから読ませる、環境変数の差分を見せる、本番を1つ前に戻すといった、デプロイの前後の作業まで会話の中で済ませたいときだ。
3. 3つのアプローチを見渡す
3アプローチの違いを 「AI に渡すもの × 自動化の深さ × 人が止める場所」で整理する。
| アプローチ | AI に渡すもの | 自動化の深さ | 人が止める場所 | 向く使い方 |
|---|---|---|---|---|
| 1. Git 連携型 | git の push 権限だけ | ★★☆☆☆ | main へのマージ | 個人開発、小さなチーム |
| 2. MCP・Plugin型 | Vercel アカウントの権限（OAuth）または CLI のログイン | ★★★★☆ | ツール実行ごとの確認 | ログ調査・env 管理まで AI に任せたい人 |
| 3. Actions型 | リポジトリの Secrets（API キー、必要なら VERCEL_TOKEN） | ★★★★★ | PR のレビューと検査ゲート | PR レビューが日常のチーム |
選び方の目安：「デプロイ後にダッシュボードでログを見に行くことが多い」なら②。「PR レビューが日常で、テストを通ったものだけ出したい」なら③。「個人ブログや小さなアプリ」なら①で十分で、無理に高度化すると保守の手間が上回る。3つは排他ではなく、①を土台に②や③を足す形がふつうだ。
4. アプローチ1：Git 連携（git push で自動デプロイ）
最も基本の構成。Vercel と GitHub を連携しておけば、git push のたびに Vercel がビルドし、終わると反映される。AI の仕事は 「コードを書く」「コミットメッセージを書く」「push する」だけだ。Vercel 自身も GitHub Actions の案内で、Git 連携がプレビューURL・変更されないデプロイ・即時ロールバックを担うので、多くのチームはパイプラインが要らないと書いている。
# セットアップ（1回だけ）
1. Vercel ダッシュボード → Add New → Project
2. GitHub リポジトリを選択 → Import
3. Framework Preset: 自動検出（Next.js など）
4. Environment Variables: 必要に応じて追加
5. Deploy
# 日常フロー（Cursor / Claude Code の中で）
> このボタンを赤色に変えて。終わったら feature/red-button ブランチに push して。
# AI が実行するコマンド
git switch -c feature/red-button
git add app/components/Button.tsx
git commit -m "feat: change primary button to red"
git push -u origin feature/red-button
# Vercel がプレビューをビルド → PR にプレビューURL が付く
この構成の 真の価値は 「ブランチごとにプレビューURLが自動で立つ」こと。Vercel のプレビューURL には、そのブランチの最新を常に指す URLと、そのコミットのデプロイを指す URLの2種類がある（Environments）。本番に出すのは main へのマージだけにしておけば、AI が何度 push してもプレビューで止まる。
注意：Hobby プランは非商用・個人利用に限られる（Hobby プラン）。1日に作れるデプロイは Hobby で100、Pro で6,000、同時に走るビルドは Hobby で1つ（Limits）。AI に細かく push させると、この上限に先に当たる。料金の罠は AI推奨Vercel §5 を参照。
5. アプローチ2：エディタから直接（Vercel MCP・Vercel Plugin）
デプロイの前後まで AI に任せるなら、Vercel MCP か Vercel Plugin を使う。どちらもトークンをファイルに書く必要はない。
Vercel MCP の設定（Cursor）：公式の手順では、.cursor/mcp.json（プロジェクト用でも全体用でもよい）に URL を1行書くだけだ。
{
"mcpServers": {
"vercel": {
"url": "https://mcp.vercel.com"
}
}
}
追加すると Cursor が接続を試みて Needs login と表示する。これを押すとブラウザで Vercel にログインし、Cursor に使わせるチームを選ぶ。Claude Code なら次の2行だ。
claude mcp add --transport http vercel https://mcp.vercel.com
# claude を起動してから、/mcp で認証する
公式ドキュメントには、複数のクライアントにまとめて登録する npx add-mcp https://mcp.vercel.com も載っている。サーバーを登録しただけでは認証は済んでいない点に注意。ログインしてチームへのアクセスを許すまで、プロジェクトのデプロイもログも見えない（ツール一覧のページ）。
MCP はスラッシュコマンドではなく「ツール」だ。こちらは「最新のデプロイのエラーを調べて」と頼むだけで、AI が次のようなツールを選んで呼ぶ（2026年9月30日時点の一覧から抜粋）。
| やりたいこと | Vercel MCP のツール |
|---|---|
デプロイを作る（target を省くとプレビュー） | create_deployment |
| デプロイの一覧・状態 | list_deployments・get_deployment |
| ビルドの出力・実行時のログとエラー | list_deployment_events・get_runtime_logs・get_runtime_errors |
| 環境変数の追加・編集・一覧 | create_project_env・edit_project_env・filter_project_envs |
| 本番を前のデプロイへ戻す | request_rollback |
| 保護されたプレビューの共有リンク | get_access_to_vercel_url |
Vercel Plugin（npx plugins add vercel/vercel-plugin）は、Vercel の知識とスラッシュコマンド5つを足す。コマンドは名前空間つきで、/vercel-plugin:deploy（prod を付けると本番）、/vercel-plugin:env（list・pull・add・remove・diff）、/vercel-plugin:status、/vercel-plugin:bootstrap、/vercel-plugin:marketplace だ（Vercel Plugin）。deploy コマンドの定義を読むと、中身は手元の Vercel CLI（vercel・vercel --prod）を呼ぶ手順で、既定はプレビュー、本番は利用者の明示の「はい」を待つ作りになっている。/logs や /rollback というコマンドは無い。ログやロールバックは MCP のツールか CLI（vercel rollback）で扱う。
真価は 「対話の中で完結」すること。「この API を追加して、プレビューにデプロイして、エラーが出たらログを見て直して」と頼むと、AI は コード修正 → デプロイ → ビルドログの確認 → 修正 → 再デプロイを順に進める。AIにインフラ任せていい？ の区分でいえば、「できるけど任せると危ない」領域に当たる。Vercel は MCP の接続が 自分の Vercel アカウントと同じ権限を AI に渡すと明記し、人による確認を必ず有効にするよう勧めている。ツール実行の承認を自動にしないこと。
6. アプローチ3：GitHub Actions（@claude と検査ゲート）
チーム運用の構成。Claude Code GitHub Actions を入れると、issue や PR のコメントで @claude とメンションするだけで、Claude が修正をコミットし、同じスレッドに返信する。プレビューのデプロイは、アプローチ1の Git 連携がそのまま担う——Claude が PR のブランチに push すれば、Vercel がプレビューを立て直す。
# セットアップ
1. Claude Code の中で /install-github-app を実行（github.com のリポジトリのみ）
2. Claude GitHub App を入れ、ANTHROPIC_API_KEY（または CLAUDE_CODE_OAUTH_TOKEN）を Secrets に保存
3. .github/workflows/claude.yml が PR として届く
# .github/workflows/claude.yml（公式ドキュメントの例）
name: Claude Code
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
jobs:
claude:
if: contains(github.event.comment.body, '@claude')
runs-on: ubuntu-latest
timeout-minutes: 30 # 暴走を止める（公式が勧める）
permissions:
contents: write
pull-requests: write
issues: write
id-token: write # 既定の GitHub App 認証に必要
actions: read # PR の CI 結果を読む
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 1
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
claude_args: "--max-turns 10" # 1回の実行の往復数に上限
timeout-minutes と --max-turns は例として足したもので、公式の「コストを抑える」節が勧める2つだ（値はプロジェクトに合わせる）。既定で回数制限が効くわけではないので、自分で付ける。
GitHub Actions からデプロイもしたい場合——テスト・脆弱性スキャン・性能予算・人の承認をデプロイの前に挟みたいときだけ——は、Vercel の 公式ガイドの形に揃える。Secrets は3つ（VERCEL_TOKEN・VERCEL_ORG_ID・VERCEL_PROJECT_ID。後の2つは vercel link が作る .vercel/project.json にある）。
# .github/workflows/vercel-preview.yml（Vercel の KB の形）
name: Vercel Preview Deployment
env:
VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
push:
branches-ignore:
- main
jobs:
Deploy-Preview:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install --global vercel@latest
- run: vercel pull --yes --environment=preview --token=${{ secrets.VERCEL_TOKEN }}
# ここにテストやスキャンを挟む
- run: vercel build --token=${{ secrets.VERCEL_TOKEN }}
- run: vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }}
# vercel.json —— Git 連携と二重にデプロイしないよう、Git 側の自動デプロイを止める
{ "git": { "deploymentEnabled": false } }
同じガイドは、Git 連携を有効にしたまま Actions でもデプロイすると、同じコミットで両方が動くこと、--prebuilt を付けないと Vercel が同じものをもう一度ビルドすることを落とし穴に挙げている。逆に、テストだけを走らせたいなら Git 連携を残し、deployment_status イベントでプレビューに対してテストを流し、Deployment Checks で本番への昇格を止める形のほうが軽い。
# 運用の例
# 開発者が PR を作る → Git 連携がプレビューを立てる
[Bot] Vercel Preview: https://<プレビューURL>
# レビュアーが PR にコメント
@claude このボタンの hover 時にも色が変わるようにして
# Claude がコミットを足して返信 → Vercel がプレビューを立て直す
# レビュアーが確認 → approve → merge → 本番デプロイ
注意：非公開リポジトリでは、コミットの作者が Vercel のチームのメンバー（Hobby なら所有者本人）でないとデプロイされない（Vercel KB）。Actions の中で作られたコミットでプレビューが立たないときは、まず Vercel Bot のコメントとコミットの作者を確かめる。
この構成で 「PR が終わるまで人がコードを触らない」シナリオが現実的になる。ベテランvs若手、ホワイトカラー消滅論 で書いたとおり、チームはレビューに集中し、実装は AI が担う分業になる。
7. プレビュー環境の使い方——ブランチ→URL→共有
3アプローチに共通して効くのが プレビュー環境を使い倒すこと。Vercel は 本番以外のブランチや PR にプレビューのデプロイを自動で作るので、同じ変更を複数案で並べて比べることが追加の設定なしでできる。
プレビュー環境の3つの活用パターン
develop などのブランチを 常設のステージングにする。プレビュー用の環境変数を分けて 本番のDBに触らない。この形は Hobby を含む全プランで使える。
環境変数は Development / Preview / Production で分けて持てる——ステージング用の値を本番に入れない。
共有リンクは Hobby ではアカウント全体で1つまで。
出典：Environments（ステージングの作り方とプラン）、Password Protection（料金）、Sharable Links（Hobby は1つ）。いずれも2026年9月30日時点。パスワードを使わない既定の保護は Vercel Authentication（チームのメンバーだけが見られる）で、Vercel はこれを推奨の方法としている。
8. 落とし穴4つ——env漏洩・上限と費用・競合・rollback
AI エージェントにデプロイを任せると、次の4つにぶつかりやすい。どれも事前の設定で被害を小さくできる。
AIエージェント運用の4つの落とし穴
対策：
.gitignore に .env*、GitHub の Push Protection、AI へ「git add . は使わない」指示、ツール実行は毎回確認。対策：Pro なら Spend Management、AI へ「最後にまとめて push」指示、不要なブランチは
git.deploymentEnabled で自動デプロイを外す。対策：1PR=1Issue=1エージェントの分業、ブランチの命名規則、CODEOWNERS で必須レビュアーを決める。
対策：Instant Rollback の手順を先に決める（Hobby は直前のデプロイへ、Pro 以上は過去の本番から選べる）、エラー監視、本番は人の承認。
ガード3点セット：Spend Management（Pro）+ Deployment Checks + エラー監視。
「AI が暴走しても致命傷にならない」状態を先に作る。
出典：MCP の環境変数ツール（get_project_env は復号した値を返す）、Spend Management（Pro と Enterprise の一部で追加料金なし。使用量の確認は数分おきなので、止まるまでに遅れが出る）、Instant Rollback、Git の設定。
よく見かける「Vercel の前に Cloudflare のプロキシを置く」は、ガードとしては勧めない。Vercel は 公式の KB で、外部のプロキシを前に置くと Vercel Firewall が通信を見られなくなり、性能も落ちるとして 推奨しないと書いている。
追加の注意：「AI に本番デプロイを完全自動化」は勧めない。アプローチ②③でも、本番だけは人の最終承認を挟む。AIに渡す情報の注意点 でも触れたが、AI は 悪意のないミスでも本番を壊しうる。プレビュー・ステージングまでは自動、本番は人の承認という 2段階のゲートを設ける。
まとめ
「Claude Code / Cursor から Vercel へのデプロイ」を考えるときは、まず Git 連携・CLI・Vercel MCP・Vercel Plugin・Agent Skills を区別する。MCP は OAuth で繋ぐ操作の手段、Plugin は /vercel-plugin:* のコマンドと知識、Skills は手順書だ。デプロイそのものは、ほとんどの場合 Git 連携で足りる。
選び方は 「どこまで AI に任せ、どこで人が止めるか」で決まる：① 個人開発 → Git 連携型、② ログ調査や env 管理まで任せたい → Vercel MCP・Plugin 型（トークンは書かず OAuth でログイン）、③ PR レビューが日常のチーム → GitHub Actions 型（@claude で修正、デプロイは Git 連携か、検査を挟む Actions + CLI）。プレビュー環境は A/B比較・ステージング・クライアント共有で使い、4つの落とし穴には ツール実行の確認・上限と費用の設定・ロールバック手順・本番の人の承認で備える。
関連記事として、AI推奨Vercel、Vercel AI SDK、v0 vs Bolt vs Lovable、Cursor解説、AIにインフラ任せていい？ も併読してほしい。
FAQ
Q. Vercel 以外のホスティング（Cloudflare・Netlify）でも同じことができますか？
A. できる。どちらも公式の MCP サーバーを出している。Cloudflare は OAuth で繋ぐリモート MCP サーバーを用途別に多数用意し、その中に Workers のビルド用もある（Cloudflare の MCP サーバー）。Netlify には Netlify MCP Server がある。選ぶ基準はエージェント連携の有無より、フレームワークとの相性や料金だ。AI推奨Vercel の選択基準も参照。
Q. Claude Code と Cursor、どちらが Vercel デプロイに向いていますか？
A. どちらも Vercel MCP と Vercel Plugin の対応ツールに入っているので、Vercel 側でできることはほぼ同じ。違いは使い方で、Claude Code は ターミナル中心で、GitHub Actions の公式統合がある。Cursor は エディタ中心で、MCP をワンクリックで追加できる。VS Code 派なら Cursor、ターミナル派なら Claude Code が自然だ。
Q. AI に本番デプロイを完全自動化させていいですか？
A. 勧めない。プレビュー・ステージングまでは自動でよいが、本番は必ず人の最終承認を挟む。理由は「悪意がなくても AI が本番を壊しうる」ことと、事故のときの責任があいまいになること。GitHub の Branch Protection で main への直接 push を禁じ、承認つきの PR を必須にする。
Q. .cursor/mcp.json は git に含めていい？
A. Vercel MCP の公式設定なら秘密の値は入らない。中身は https://mcp.vercel.com という URL だけで、認証は OAuth でブラウザ側に残る。チームで共有するためにコミットしてもよい。ただし他の MCP サーバーの API キーをヘッダーに直書きしている場合は別で、そのファイルは git に入れない。CI で使う VERCEL_TOKEN は GitHub の Secrets に置き、ワークフローに直書きしない。
Q. GitHub Actions の費用が心配です。
A. 公式ドキュメントによると、費用は GitHub Actions の実行時間と Claude API のトークンの2つ（サブスクリプションの OAuth トークンで認証すれば、API の従量課金ではなくサブスクリプションの枠を使う）。1回あたりの額は、プロンプトの長さ・作業の複雑さ・コードの規模で変わる。抑え方として公式が挙げるのは、claude_args の --max-turns で往復数に上限、ワークフローにタイムアウト、具体的な @claude の依頼、CLAUDE.md を短く保つこと。回数の上限は既定では付かないので、自分で設定する。
