PaaS系MCPの本番デプロイ権限を各社でどう絞るか
7社のPaaS向け公式MCPサーバーが持つ認証方式・スコープの絞り方・削除ツールの有無を比較し、本番デプロイ権限をどこまで渡すかの判断材料をまとめます。
VercelやRailwayのMCPサーバーをClaude Codeに繋ぐとき、渡している権限は「ちょっとログを見せる」程度ではありません。多くの公式MCPサーバーは、本番へのデプロイ・環境変数の書き換え・Dynoやサービスのスケーリングまで一通り実行できます。問題は、その権限をどこまで絞れるかがサービスごとにまったく違うことです。ワークスペース単位で絞れるものもあれば、アカウント権限がほぼそのまま渡るものもあります。7社の公式ドキュメントを突き合わせ、権限設計の違いを比較します。
比較の対象
Vercel・Netlify・Cloudflare・Railway・Fly.io・Render・Herokuの公式MCPサーバーを対象にします。RenderとHerokuの具体的な導入手順・全ツール一覧は個別記事に譲ります。Render MCPサーバーでClaudeからWebサービス・DBを管理するとHeroku MCPサーバーでClaude Codeからアプリをデプロイ・スケーリングするにまとめました。本記事は権限スコープの比較と意思決定に絞ります。
権限を絞る4つの評価軸
サービスごとに用語も設計思想も違うため、比較に使う軸をあらかじめ揃えておきます。次の4つです。
- 認証方式: OAuthか、APIキー/PATか、既存CLIセッションの再利用か
- スコープを絞る手段: ワークスペース・プロジェクト単位で選べるか、トークン自体に権限を埋め込めるか、専用の手段がないか
- 削除・破壊的操作のツール化: サービスやデータベースを削除するツールが実装されているか
- 本番に最も直結する操作: 一撃で本番環境を変える単一のツールは何か
7社の権限設計を比較する
| サービス | 認証方式 | スコープを絞る手段 | 削除ツール | 本番に直結する操作 |
|---|---|---|---|---|
| Vercel | 認証方式OAuth(承認済みクライアント限定) | スコープを絞る手段チーム選択のみ | 削除ツール確認できた範囲では無し | 本番に直結する操作deploy_to_vercel(targetにproductionを指定可) |
| Netlify | 認証方式PAT(Personal Access Token) | スコープを絞る手段専用の絞り込み手段は公式ドキュメントに見当たらない | 削除ツール明記なし | 本番に直結する操作プロジェクトのデプロイ・アクセス制御の変更 |
| Cloudflare | 認証方式OAuth(付与権限を選択可)またはAPIトークン | スコープを絞る手段権限選択・トークンスコープ・16種の製品別サーバーからの選択 | 削除ツールexecute()経由でAPIの削除系エンドポイントも呼べる | 本番に直結する操作execute()経由のAPI呼び出し全般 |
| Railway | 認証方式OAuthまたはCLI認証の再利用 | スコープを絞る手段ワークスペース・プロジェクト単位で選択 | 削除ツールローカルサーバーに存在。protocol-levelで破壊的操作と警告される | 本番に直結する操作accept-deploy・redeploy |
| Fly.io | 認証方式アクセストークン(macaroon) | スコープを絞る手段app-scoped・org-scoped・読み取り専用org-scopedトークンを発行 | 削除ツールトークンの権限次第で可能 | 本番に直結する操作machine・apps系コマンド全般 |
| Render | 認証方式OAuthまたはAPIキー | スコープを絞る手段ワークスペース選択に加え、ツール自体が更新・削除を実装しない設計 | 削除ツール存在しない | 本番に直結する操作trigger_deploy |
| Heroku | 認証方式CLIセッションの再利用またはAPIキー | スコープを絞る手段専用の絞り込み手段はなく、Claude Code側の設定に委ねる | 削除ツール専用ツールは無いがtransfer_appで所有権自体が移る | 本番に直結する操作pipelines_promote |
3つの設計思想に分かれる
7社を並べると、権限の絞り方は大きく3系統に分かれます。
ツール側で絞る設計はRenderだけです。更新・削除に対応するツールを最初から実装していないため、渡す認証情報の強さに関わらず、できる操作の上限が決まっています。誤操作の被害範囲を設計時点で狭めるアプローチです。
トークン側で絞る設計はFly.ioとCloudflareに見られます。Fly.ioのアクセストークンはmacaroon形式で、app単位・org単位・読み取り専用という粒度を発行時に選べます。
# 単一アプリだけに使えるデプロイトークン(48時間で失効)
fly tokens create deploy --name "claude-code" --expiry 48h
# 組織全体を読み取り専用で見られるトークン
fly tokens create readonly --name "claude-code-readonly" --expiry 168hFLY_ACCESS_TOKENにこの読み取り専用トークンを渡せば、MCPサーバー自体はflyctl相当の全コマンドを公開したままでも、実行時にはAPI側で書き込みが拒否されます。ツールの数を絞るのではなく、ツールが呼べる範囲を認証情報側で絞る発想です。
Cloudflareも同様に、OAuth接続時に付与する権限を選ぶか、権限を絞ったAPIトークンを使うかで調整できます。加えてCloudflareには、2,500以上のエンドポイントをカバーする総合API MCPサーバーとは別に、Browser Rendering・Workers Bindings・Observabilityなど16種の製品別サーバーが用意されています。スクレイピングやスクリーンショットだけが目的なら、デプロイ操作を一切持たないBrowser Rendering専用サーバーだけに接続すれば、そもそも書き込み系のツール自体が存在しない状態にできます。総合API MCPサーバーはsearch()とexecute()の2ツールだけで全エンドポイントを扱う設計のため、権限の絞り込みはOAuthの権限選択かAPIトークンのスコープに集約されます。
アカウント権限がほぼそのまま渡る設計がVercel・Netlify・Heroku・Railwayの基本形です。Vercelは公式が「接続したAIシステムに、あなたのVercelユーザーアカウントと同じアクセス権を与える」と明言しています。Herokuもheroku mcp:startは既存のCLIログインをそのまま使う設計で、権限を絞る専用の手段は用意されていません。
Netlifyは、公式の一覧に「プロジェクトの作成・管理・デプロイ」「アクセス制御の変更」「環境変数・シークレットの作成・管理」を明記しています。CLI相当のツールを一通り持つ設計で、Personal Access Tokenを渡した時点でこれらすべてが使える状態になります。トークン単位でスコープを絞る手段は、少なくとも公式ドキュメントの記載範囲では見当たりません。
Railwayだけは、この4系統の中では一段絞り込みが効きます。OAuth接続時にワークスペース・プロジェクトを選べます。加えてredeploy・accept-deploy・railway-agent、ローカルサーバーのremove_service・delete_domain・remove_tcp_proxy等はprotocol-levelで破壊的操作と明示され、対応クライアントは実行前に確認を挟みます。プロジェクトトークンは受け付けず、必ずユーザー本人の認証を要求する設計も、課金・監査の追跡可能性という観点で他社と一線を画します。
Vercelの購入系ツールという固有のリスク
Vercelには他社に無いカテゴリのツールがあります。チームのProプランへのアップグレードやAI Gateway・v0のクレジット購入、ドメイン登録を実行する購入系ツールです。見積もり取得(get_purchase_quote)と確定実行(confirm: true)を分ける2段階フローと、同じリクエストを重複実行させないidempotencyKeyが組まれており、誤課金への配慮は見られます。それでも支払い方法が登録済みのチームでは、AIが実際の課金を発生させる操作を実行できる立場にある点は、他の6社との明確な違いです。
Vercelは、OAuth接続のたびにクライアントごとの明示的な同意を求めます。これはconfused deputy攻撃(同意用のクッキーを悪用して不正な認可リクエストを通す手口)への対策でもあります。購入系ツールという実害の大きい機能を持つぶん、認可フロー自体の防御を積み増している格好です。
Vercelにはもう一つ他社にない制約があります。接続できるAIクライアントを公式がレビュー・承認したものに限定している点です。他の6社はMCP仕様に準拠していれば任意のクライアントを受け入れますが、Vercelは「レビューと承認を経たAIクライアントのみサポートする」と明記しています。購入系ツールという攻撃対象になりうる機能を持つぶん、接続元を絞る方向で補っている格好です。
Claude Code側でさらに絞り込む方法
いずれのサービスも、MCPサーバー自体が接続の全リクエストに人間の確認を強制する仕組みは持っていません。MCPの仕様上、ツールのtools/list応答にanthropic/requiresUserInteractionという注釈を付けると、Claude Codeはそのツールを呼ぶたびに承認を求めます。ただしこれはサーバー開発者が実装する側の機能で、7社の公式ドキュメントにこの注釈への言及は見当たりません。実務での絞り込みは、Claude Code側の権限ルールに委ねられているのが現状です。
claude mcp addの--scopeで設定の保存先(local / project / user)を分ければ、APIキーやOAuthトークンをリポジトリ共有の設定に残さずに済みます。さらに、trigger_deployやpipelines_promoteのような本番に直結するツールだけを狙って個別の承認を必須にする書き方は、Claude Code MCP権限ルールにまとめています。読み取り専用のPostgres接続を軸にしたい場合の考え方はClaude CodeでMCPからデータベースに接続する方法も参考になります。
OAuthで接続する場合は、oauth.scopesの設定でClaude Codeが認可フロー中に要求するスコープをあらかじめ固定できます。認可サーバー側が公開しているスコープの一部だけを要求する形にできるため、VercelやCloudflare、Railwayのようにアップストリームが広いスコープ集合を提示してくる相手には、接続前にチームで承認済みの範囲だけへ絞り込む手段になります。
もう一点、承認プロンプトが常に効くとは限りません。プロジェクトスコープの.mcp.jsonサーバーは、対話セッションでは承認を求めます。ただしclaude -pやAgent SDK・クラウドセッションではそのプロンプトを表示できず、承認済みとして読み込まれます。自動化パイプラインにPaaS系MCPを組み込む場合、対話時の確認に頼れないぶん、トークンのスコープ自体を絞っておく重要性がさらに増します。
用途別の使い分け早見表
| 用途 | 向く条件 | 該当するサービスの例 |
|---|---|---|
| 個人開発・検証環境 | 向く条件フル権限でも実害が小さい | 該当するサービスの例Heroku・Netlify・Vercelをそのまま接続 |
| チーム共有の本番環境 | 向く条件ワークスペース・プロジェクト単位で絞れる | 該当するサービスの例Railway・Cloudflareのスコープ付きOAuth |
| 規制対象・金融/医療系のワークロード | 向く条件削除ツールが無い、または読み取り専用トークンを発行できる | 該当するサービスの例Render(削除ツール無し)・Fly.io(読み取り専用org-scopedトークン) |
| CI/CDパイプライン組み込み | 向く条件有効期限付き・用途限定のトークンを発行できる | 該当するサービスの例Fly.io(--expiry指定)・Cloudflareの権限を絞ったAPIトークン |
まとめ
本番デプロイ権限をどこまで渡すかは、サービスを選ぶ段階である程度決まります。Renderのようにツール自体が破壊的操作を実装しない設計、Fly.ioやCloudflareのようにトークン発行時にスコープを決められる設計は、Claude Code側の設定だけに頼らない二重の防御になります。Vercel・Netlify・Heroku・Railwayのようにアカウント権限がほぼそのまま渡る構成では、--scopeによるトークンの保存先管理と、本番直結ツールへの個別承認を、導入時に組み込んでおく価値があります。
どのサービスを選ぶにせよ、渡す前に確認すべき問いは共通です。削除・スケーリング・所有権移転に相当する操作がツールとして存在するか、その操作だけを狙って承認を挟めるか、そして自動化パイプラインで確認プロンプトが機能しない場面を想定しているか。この3点を導入前のチェックリストとして扱うと、サービスごとの権限設計の違いに振り回されずに済みます。