Vercel Connectの権限管理：共有認証情報を誰に任せるか

Vercel Connect の共有コネクタ認証情報は、管理担当者を明示しても、その人に Vercel チームの Owner ロールまで付与する必要がなくなりました。Vercel は2026年9月11日、Pro と Enterprise のチーム向けに Connector Permissions を追加しました。これにより Owner は、コネクタの作成・管理を Owner と Connector Manager 権限を持つメンバーだけに絞れます。

ただし、Member ロールにはもともと Connector Manager が含まれています。この設定で所有権の境界を狭くできるのは、ロールの割り当ても同時に見直した場合だけです。

Vercel ConnectのConnector Permissionsで何が変わるのか

Vercel Connect のコネクタは、Slack、GitHub、Microsoft、カスタムプロバイダーなどのサービスを表す、チーム所有のレコードです。複数のプロジェクトで使う認証情報を保持したり、その受け渡しを仲介したりするため、変更は通常のアプリ編集ではなく、チーム単位の操作になります。

Connector Permissions は、そのレコードを管理できる人を絞るための権限ゲートです。Owner が Team Settings で制限を有効にすると、それ以降コネクタを作成・管理できるのは、Owner または Connector Manager の拡張権限を持つ人に限られます。

この権限の対象には、チーム全体のコネクタ、プロジェクト接続、インストール、トークンが含まれます。ただし、あらゆるアクセス判断がひとつのスイッチに集約されるわけではありません。

この切り分けは重要です。Connector Manager が共有接続を保守する一方、デプロイ済みアプリは、Vercel OIDC（実行中のアプリに Vercel が発行するデプロイID）とプロジェクトリンクを使い、チーム、プロジェクト、環境を引き続き証明します。そのうえで、プロバイダーが独自のスコープを適用します。メッセージの投稿や顧客レコードの更新に人間の判断が必要なら、その承認はアプリケーションのワークフローに残す必要があります。

以前の Vercel Connect認証の解説 では、このトークン交換の経路を詳しく取り上げました。今回変わるのは接続を保守できる人であり、実行中のアプリがトークンのリクエスト権限を証明する仕組みではありません。

ビジネス上の判断基準は「変更できる人数」

ここで見るべき数字は、もうひとつのAPI上限ではありません。認証情報を含むチームリソースを変更できる人数です。

すべての開発者が共有コネクタを編集できる状態では、人員の入れ替え、外部委託先への引き継ぎ、急ぎの本番修正のたびに、レビュー対象が広がります。Connector Permissions を使えば、管理グループを明示したうえで、それ以外のメンバーは、管理者が承認済みのプロジェクトリンクを使って開発を続けられます。

9月11日のリリースでは、直接的な料金変更は発表されていません。Vercel Connect の課金対象はトークンリクエストとトリガーであり、Connector Manager の割り当てではありません。別の Connect料金ページ によると、更新後のベータ料金は2026年9月25日から適用され、Pro はトークンリクエスト1,000件あたり$3.00、Enterprise は個別料金です。この権限設定がランタイムの課金単位を変えるとは説明されていません。

一方で、運用コストは下げられる可能性があります。プロバイダー設定、クライアントシークレット、インストール情報、プロジェクト接続を変更する権限を必要とする人が減るからです。指名された管理担当者が作業できるため、開発者は Owner の対応を待たずに済み、Owner はその権限を誰に付与するかを引き続き管理できます。

ひとつのチームで責任を明確に引き継ぐ

役割を分けた例として、Northstar Agency を見てみましょう。Maya は Vercel の Owner です。Jon は共有サービス接続を保守する Developer で、Connector Manager も付与されています。Priya は Connector Manager を持たず、クライアントアプリを開発する Developer です。Leah は、アプリによる送信や更新を許可するかどうかを決める業務ルールを担当します。

この分担を崩さない引き継ぎは、次のようになります。

1. 1

   継承済みのアクセス権を監査する

   Maya は制限を有効にする前に、チームメンバーの一覧を確認します。Owner または Member であれば、すでに Connector Manager を持っています。Developer、Security、Billing、Viewer、Contributor には、そのほかの業務にベースロールが適していれば、Connector Manager を拡張権限として付与できます。

2. 2

   コネクタの管理担当者を指名する

   Maya はチームの Settings を開き、Members に移動して、Jon の Manage Role を選びます。Jon は Developer ロールのまま、Connector Manager を付与されます。引き継ぎ記録には、コネクタ、プロバイダーアカウント、接続先のプロジェクトと環境、プロバイダー側の責任者、ローテーションまたは失効が必要な場合のエスカレーション経路を明記します。

3. 3

   Connector Permissionsを有効にする

   Maya は Team Settings を開き、Connector Permissions を見つけて制限を有効にします。これで Jon は、完全な Owner ロールを受け取らなくても、コネクタの作成と管理を担当できます。

1. 1

   プロバイダーのスコープを切り分ける

   Jon は、プロバイダーに要求するスコープ、リソース、認可の詳細を記録します。Connector Manager は、Vercel のオブジェクトを誰が保守できるかを定めます。一方、プロバイダー側の権限付与は、得られた認証情報で何ができるかを定めます。どちらの設定も実際の業務アクションを進めてよいかは決めないため、Leah の承認ルールはアプリに残します。

2. 2

   リクエスト経路をテストする

   Priya は、接続済みのQAプロジェクトから、範囲を絞ったリクエストをひとつ実行します。確認する経路は「QAデプロイのOIDC ID → Vercel Connect のプロジェクトリンク → 読み取りスコープのプロバイダートークン → プロバイダーAPIのレスポンス」です。Jon はコネクタの Observability タブで、トークンリクエストと認可を確認します。Maya は、Priya がコネクタ管理の経路を使えないことも確認します。

最後の手順が受け入れテストです。ポリシー文書だけでは十分ではありません。開発者は承認済みのランタイム経路を利用でき、その開発者の職務に含まれない限り、同じ人が共有コネクタを変更できない状態にする必要があります。

今すぐ導入すべきチーム

プラットフォームエンジニアが1人のProスタートアップ

創業者は Owner ロールを維持し、プラットフォームエンジニアに Connector Manager を付与できます。プロダクトエンジニアは接続済みプロジェクト経由で開発を続け、コネクタ変更にはひとりの管理担当者とひとつのエスカレーション経路を設けます。チーム全体の所有権を広げずに、創業者待ちを減らせるのが利点です。

Enterpriseのセキュリティチーム

セキュリティ責任者は、プロバイダー権限のレビューと日常的なコネクタ保守を分離できます。管理担当者がインストールとプロジェクト接続を扱い、プロバイダー管理者が重要なスコープを承認します。ひとつの共有エージェント認証情報を複数のアプリで使う場合も、変更履歴が明確になります。

複数のクライアントアプリを納品するエージェンシー

エージェンシーの運用責任者は、クライアント環境ごとにコネクタ管理者を指名し、開発を担う外部委託者には担当プロジェクトに集中してもらえます。次のアプリで効果が表れます。すべての開発者に共有認証情報レイヤーの編集権限を与えなくても、承認済みの接続経路を再利用できるからです。

エージェントアクションを追加する運用チーム

運用責任者は、認証情報の引き継ぎに Connector Permissions を使い、影響の大きいアクションはプロダクト独自の承認ステップで引き続き保護する必要があります。責任分担が明確になるのが利点です。Jon は接続を修復し、Priya はワークフローをリリースし、Leah は顧客レコードや外部メッセージを変更してよいタイミングを判断できます。

この設定だけではできないこと

Connector Permissions を有効にしても、既存のプロバイダーアクセスが失効した証拠にはなりません。失効は別の操作です。また Vercel は、即時に無効化できるかどうかは、プロバイダーが失効用エンドポイントを提供しているかに左右されると説明しています。

この設定は、プロバイダーのスコープを狭めるものでも、接続済みのどのデプロイ環境がトークンをリクエストできるかを変えるものでもありません。エージェントアクションに人間の承認を追加したり、Connect の利用料金を下げたりする機能でもありません。これらは別々の制御であり、それぞれに責任者が必要です。

Hobby チームは対象外です。この管理制限は Pro と Enterprise 向けだからです。共有コネクタを使わない個人のプロトタイプなら、まだ引き継ぎは不要かもしれません。一方、共有の本番認証情報、複数のエージェント対応アプリ、外部の協力者を抱えるチームは、次のコネクタを追加する前に境界を設けるべきです。

今週、最初にやること

ひとつのコネクタを複数のプロジェクトで使っている、または今後さらに多くの人がそのコネクタを使ってエージェントを開発する予定なら、今週中に対応してください。コネクタがまだ個人のテスト用途で、ほかに依存する人がいないなら待ってもかまいません。実行時に接続済みコネクタを利用するだけなら、今回のリリースに合わせてコード側の処理を変更する必要はありません。

最後は、1行の記録と1回の実際のリクエストで締めくくります。Maya がポリシーを担当し、Jon がコネクタを保守する。QAの読み取り経路は、デプロイIDからプロジェクトリンクを経由し、プロバイダーのレスポンスに至るまでテスト済み。 これが引き継ぎです。トグルは、その分担を強制する仕組みにすぎません。

次のプラットフォーム変更も、わかりやすいニュースレターで読む。