Introducing Vercel Connect｜Vercel Connect の紹介：エージェントへのアクセス制御を強化 | AIニュース最前線

エージェントにツール、データ、サービスへのアクセス権を与えることが、それらを有用なものにする鍵です。システム間でより深い作業を行うにつれ、そのアクセスを認証し承認することが、アプリケーションアーキテクチャの中心となります。 現在、エージェントへのアクセスは通常、環境変数に保存された長期有効なプロバイダートークンを通じて付与されます。これはエージェントが必要とするあらゆるものに対して用意されたものであり、すべてのユーザー間で共有され、期限切れになることもなく、どんなに小さなタスクであってもエージェントがあらゆる作業に完全な権限を持つことを意味します。 バault（金庫）は、そのトークンを盗まれにくくするだけです。危険性を減らすわけではありません。問題となるのは、トークンが漏洩した際に何が起こるかです：そのトークンで触れられるすべてのものが、今や露呈してしまうのです。 私たちはこの問題を解決するために Vercel Connect を構築しました。現在パブリックベータ版として提供されている Vercel Connect は、保存されたトークンの代わりにランタイム認証情報の交換（runtime credential exchange）を採用しています。コネクターは一度だけ登録します。エージェントに作業が必要な際、アプリケーションは Vercel Connect に対して自らの身元を証明し、タスクに限定された短期有効な認証情報を取得します。これまでトークンで行っていたすべての操作は依然として機能します。異なる点は、エージェントが権限を保持するのではなく、毎回アクセスを要求するようになることです。 コネクターは一度登録すれば、プロジェクトや環境全体で再利用できます コネクターとは、Vercel チームと Slack や GitHub などのプロバイダーとの間で再利用可能な接続のことです。ダッシュボードまたは CLI から一度作成し、必要なプロジェクトや環境にアタッチします。プロジェクトレベルのアクセス制御も設定可能です。 プロバイダーとの関係は、12 の環境変数パネルに散らばっているものではなく、確認・管理できる単一のエンティティとなります。回転（ローテーション）が必要になった際も、すべてのコピーを探す必要はありません。 コーディングエージェントでもこのセットアップを実行できます。`npx skills add vercel/vercel-plugin --skill vercel-connect` で vercel-connect スキルをインストールすれば、接続コンポーネントの作成とアタッチを自動で行います。 ランタイムでのリクエストスコープトークン 接続コンポーネントが設定されれば、エージェントは作業を行う必要がある際にのみ資格情報を要求します。@vercel/connect SDK は、プロバイダー API に対して即座に使用できるトークンを返しますが、プロバイダーの秘密鍵（シークレット）がアプリケーション内に存在することはありません。 トークンは短期間で有効期限があり、その期間はプロバイダーによって異なります。SDK が自動的にリフレッシュするため、手動でシークレットを回転させる必要はなくなります。ここで残る疑問があります。もしアプリケーションに秘密鍵を持たないなら、何を以て要求する権限があることを証明するのかという点です。 OIDC によるアプリケーションの身元証明 その証明とは、アプリケーションが既に持っている身元情報です。Vercel 上のすべてのデプロイメントには OIDC（OpenID Connect）の身元が付与されており、アプリケーションまたはエージェントがトークンを要求する際、SDK はその身元を Vercel Connect に提示します。Vercel Connect はそれを検証し、プロジェクトと環境が接続コンポーネントの使用を許可されているかを確認した上で、プロバイダーの資格情報を返します。この往復通信がランタイムでの資格情報交換です。 同じアイデンティティは、vercel link および vercel env pull を通じてローカル開発中にも利用可能であり、Vercel 外では SDK が Vercel アクセストークンを受け入れます。いずれの場合も、アプリ内に漏洩・コミット・環境間でコピーされるべきプロバイダーシークレットは存在しません。 各トークンをタスクが本当に必要とする範囲に限定する 単一のエージェント内であっても、すべてのタスクが同じ権限を必要とするわけではありません。あるステップではリポジトリを読み取る一方、次のステップではイシューを開くこともあります。それぞれの要求は必要なアクセスのみを含み、要求自体が制限を設定します。要求には以下が含まれます: プロバイダースコープ インストール ID リソース制限 プロバイダー固有の認証詳細 GitHub は最も明確な例です。なぜなら、トークンを特定のレポジトリと権限に限定できるからです。 デプロイメントエージェントは、その 1 つのリポジトリのみを読み取り、それ以外のことは一切行いません。細粒度の GitHub App インストールも同様に狭い範囲に設定できますが、インストールは一度設定され、その後信頼される恒久的な付与です。一方、この制限は 1 つの要求、1 つのタスクのために存在します。最小権限の原則が、要求の形状そのものとなります。 特定のユーザーを代表して行動し、ユーザーごとのトークンスコープを設定する 共有ボットトークンは、すべてのユーザーの要求に同じアイデンティティと到達範囲を与えます。Vercel Connect を使用すれば、このアイデンティティを設定できます。対象をアプリから名前付きユーザーへ切り替えれば、そのトークンはそのユーザーを代表して動作し、そのユーザーが許可した範囲にスコープされます。 ユーザーが最初にアクセスを許可した際、startAuthorization はコールバック URL、Webhook、またはデバイスコードを通じて同意フローを実行します。その後、エージェントはそのユーザーとしてトークンを要求します。 環境ごとにアクセスを制限し、必要に応じて取り消してください コネクタは選択したプロジェクトと環境に紐付けられるため、開発、プレビュー、本番の 3 つすべてに対して 1 つのコネクタを指すのではなく、それぞれに別々のコネクタを実行できます。各環境が独自の認証付与とスコープを持つコネクタを持っている場合、開発環境で漏洩した資格情報は本番環境で再利用されません。 個別のコネクタは資格情報の有効範囲を限定しますが、すでに発行されたアクセス権限を取り消すわけではありません。これが通常は最も厄介な部分です。保存されたトークンの場合、これはローテーションを意味します。新しい秘密鍵を発行し、古いものが存在していたすべての場所を更新し、それに基づいて動作していたものを再デプロイする必要があります。Vercel Connect では、コネクタのトークンを、自分自身のものか、あるいはすべてを取り消すことができます。 取り消しが何を行うかはプロバイダによります。プロバイダが取り消しをサポートしている場合、Vercel Connect はプロバイダ側でトークンを取り消します。サポートしていない場合、Vercel Connect はその付与に対して新しいトークンの発行を停止しますが、すでに発行されたトークンはプロバイダ側で有効期限が来るまで有効なままです。これは取り消し API を持たないすべてのプロバイダにおける実際の制限であり、プロバイダがトークンを保持する期間が短いほど、このウィンドウは小さくなります。 検証済みの Slack トリガーからイベント駆動型エージェントを稼働させる これまでのところ、エージェント側からアクションを起こしていました。必要なときにトークンを要求し、サービスに呼び出しを行っていたのです。 一方、トリガーは逆の方向で動作します。接続されたサービスがアプリへイベントを送信すると、それに対してエージェントが応答します。 Vercel Connect はプロバイダーからの Webhook を受け取り、検証した上でプロジェクトへ転送します。現在、トリガー転送機能はベータ版として提供されており、Slack、GitHub、Linear に対応しています。Slack コネクタを使用すると、検証済みの Webhook を最大 3 つのプロジェクトに転送できるため、Slack 上のメッセージがエージェントを起動し、そのメッセージに基づいてアクションを実行させることが可能です。 このフローは、アプリ内にプロバイダーのシークレットを保持することなく、エンドツーエンドで実行されます： ユーザーが Slack でメッセージを投稿します。 Slack がイベントを Vercel Connect へ送信します。 Vercel Connect は保有する Slack の署名シークレット（Slack signing secret）を用いてイベントを検証し、その後、OIDC アイデンティティで再証明された状態で Vercel アプリへ転送します。 アプリはその証明を検証した後、スコープ付きのランタイムトークンを要求します。 エージェントがアクションを実行し、応答します。 Slack の署名シークレットが消滅するわけではありません。サーバーサイドで Vercel Connect へ移動し、そこが上流からの Webhook を検証した上で、アプリ側で確認可能なアイデンティティを用いて転送されたリクエストに再署名を行います。アプリはアクションを実行するためのボットトークンも、検証対象となる署名シークレットも保持していません。 Vercel Connect は、すでに存在するコードの場所に寄り添います すべての基盤には一つの呼び出しがあります。エージェントが AI SDK をベースに構築されていても、バックグラウンドジョブとして実行されていても、自分で記述したループであっても、すべて同じ方法で `getToken` を呼び出してトークンを要求します。この呼び出しを取り囲むように、すでに運用しているスタック用のアダプターが存在します。Better Auth (@vercel/connect/betterauth) と Auth.js (@vercel/connect/authjs) は、プロバイダー設定をそれぞれが期待する形式に変換し、@vercel/connect/ai-sdk と @vercel/connect/mcp も同様に AI SDK ツールと MCP クライアントに対して対応します。Nuxt のスタータープロジェクトは、GitHub と Linear を接続した動作可能なアプリを提供しますが、プロバイダーのシークレットは不要で、データベースに OAuth リフレッシュトークンを保存する必要もありません。 フレームワークはこの仕組みをさらに発展させ、接続自体を宣言的に記述できるようにすることも可能です。Vercel が提供するオープンソースのエージェントフレームワーク「eve」では、接続は単一のファイルで定義され、@vercel/connect/eve アダプターがその接続の認証情報を提供します。 エージェント側のコードにはトークン処理が含まれていません。Connect が同意フロー、リフレッシュ、エラーケースを eve にマッピングしているためです。OAuth をサポートする MCP サーバーであれば、その URL だけでコネクターとして機能できます。これが mcp.linear.app が Slack や GitHub と同じスコープ付きトークンモデルを採用する理由です。 同じアダプターが Slack チャンネルも接続します。`connectSlackCredentials` という一つの呼び出しで、送信用のボット認証情報と、受信側の Webhook 検証の両方をカバーできます。 Slack インテグレーションが通常、あなたの環境に保持する 2 つの秘密、SLACK_BOT_TOKEN と SLACK_SIGNING_SECRET は、もはやあなたのアプリには存在しません。プロビジョニング、保存、またはローテーションする必要のあるものは何も残っていません。 アクセスは、タスクにスコープを限定したリクエストとして扱われます エージェントが到達できる範囲が広くなるほど有用性が増すため、アクセス制御こそが最も重要な部分です。エージェントが触れることのできるすべてのシステムは、漏洩したトークンを通じて誰かが到達可能なシステムでもあります。ランタイム認証情報の交換により、すべてに対してプロビジョニングされるものはなく、すべてのユーザーに共有されるものもありません。永遠に続くものもなく、目の前のタスクを超えて届くこともありません。 認証情報の管理はかつてアーキテクチャの一部でした。それは環境間でのコピーされたシークレットや、誰にも漏洩しないことを願うほど広範なボットトークンを含むローテーションスクリプトのことです。しかし今では、それらを一切保存しません。エージェントが必要とする瞬間にアクセスをリクエストし、タスクにスコープを限定します。 Vercel Connect で構築を開始する コネクターを登録し、最初のランタイムトークンをリクエストして、プロバイダーのシークレットを保存することなく、エージェントを Slack や GitHub に接続してください。 コーディングエージェントにはプロンプトが必要です： よくある質問 Vercel Connect とは何か？ Vercel Connect を使用すると、あなたのエージェントやサービスが、ユーザーやチームに代わって外部システムにアクセスできるようになります。長期生存する環境変数にプロバイダーの認証情報を保存するのではなく、プロジェクトレベルのアクセス制御を備えたランタイムでユーザー承認トークンをリクエストします。 Vercel Connect が解決する課題は何か？ これにより、ランタイム中に長期有効なサードパーティのシークレットを削除しつつ、エージェントが外部 API を操作できる状態を維持できます。プロバイダー用のコネクタを登録し、プロジェクトや環境とリンクさせた上で、ランタイム時にプロバイダートークンをリクエストします。 Vercel Connect と Vercel Integrations のどちらを使用すべきか？ Vercel Marketplace でマーケットプレイス管理型のインストールやプロバイダー管理型製品を利用する場合は Vercel Integrations を使用してください。一方、エージェントワークフロー（例：Slack ワークスペースへのプロジェクトスコープアクセスを必要とするエージェント）に委譲されたランタイム認証情報とユーザーの承認が必要な場合は Vercel Connect を使用してください。 利用可能なコネクタはどれですか？ Vercel Connect は、汎用的な OAuth および API キーコネクタをサポートしており、さらに Slack、GitHub、Linear、Discord、Notion、Salesforce、Figma、Snowflake 専用のコネクタも用意されています。Resend、Workday、Microsoft Teams など、他のサービスも近日公開予定です。 料金体系はどうなっていますか？ 料金はトークンリクエスト数に基づいて算出されます。Hobby プランでは、月額 5,000 トークンのリクエストが追加費用なしで利用可能です。Pro および Enterprise プランでは、10,000 トークンあたりのリクエストに対して 3 ドルが請求されます。 現在のベータ版における制限事項は何ですか？ トリガー転送は Slack、GitHub、Linear に限定されています。コネクタのブランディングフィールドを設定した後は完全にクリアできない場合があります。また、トークンの取り消し、有効期限、スコープの粒度はプロバイダーのサポート状況に依存します。 続きを読む

Vercel Connect の紹介：エージェントへのアクセス制御を強化

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト