【ITニュース解説】How Vercel Agent accesses production safely

Vercel Agentは、ウェブアプリケーションの本番環境（実際にユーザーが利用するシステム）で発生した問題を見つけ出し、修正するのを手助けするAIだ。本番環境は非常にデリケートな場所であり、少しのミスも大きなトラブルにつながる可能性がある。そのため、AIのような自動化されたツールが本番環境にアクセスする際には、最大限の注意と安全性が求められる。

従来のAIアシスタントでは、本番環境で作業する際に、どのような操作が必要になるか最初から予測できなかった。「このデプロイメント（アプリケーションの展開）を修正してほしい」という漠然とした指示に対し、AIに広範なアクセス権限を与えてしまうと、もしAIが間違いを犯した場合、意図しない全く関係のないシステムにまで影響が及ぶ危険があった。一方で、AIが何か操作をするたびに「この作業を承認しますか？」と尋ねられるようでは、ユーザーは何度も承認ボタンをクリックすることになり、そのうち内容をよく確認せずに承認してしまう習慣がついてしまう可能性がある。これでは、AIを導入するメリットである効率性が失われ、さらに安全性も確保されない。

Vercel Agentは、これらの課題を解決するために、新しいアプローチを採用している。まず、問題が発生している状況を徹底的に「調査」する。この調査段階では、基本的にシステムの状態を「読み取る」ことだけを行い、実際の変更は行わない。調査の結果、AIは問題の解決策を「計画」として提案する。この計画には、「どのような作業を行うのか」「その作業を行うために、どのようなアクセス権限（システムの特定の部分に触れる許可）が必要なのか」が具体的に示される。ユーザーは、この計画全体をじっくりとレビューし、問題の修正内容と必要な権限を一度に確認して承認するかどうかを判断できる。ユーザーが計画を承認することで初めて、その計画を実行するために必要な追加のアクセス権限がAgentに与えられ、変更作業が実行される。これにより、ユーザーはAgentが実際に何をしようとしているのかを事前に把握し、変更が実行される前にその内容を承認できるため、安全性が大幅に向上する。

この計画によるアクセス制御の核となるのが「スコープ」という概念だ。スコープとは、Vercelの認証システムが認識する「できることの範囲」や「権限の種類」を具体的に名前で定義したものだ。例えば、「read:deployment」はデプロイメントの情報を読み取ること、「create:deployment」は新しいデプロイメントを作成すること、といった具合だ。Vercel Agentが問題を調査する際には、最近のデプロイメント履歴やビルド（プログラムの作成過程）のログを読み取ったり、問題のデプロイメントと最後に正常だったデプロイメントを比較したりする。これらの作業は「読み取り専用」のアクセス権限（read:で始まるスコープ）があれば実行できるため、Agentは自動的に調査を進められる。もし調査の結果、「以前の正常なビルドで再デプロイする」という解決策が提案された場合、これは「デプロイメントを作成する」という「書き込み権限」（create:deploymentなど）が必要になる。このときVercel Agentは、必要な追加のアクセス権限を明記した計画をユーザーに提示し、承認を待つ。この仕組みにより、調査のための読み取り作業は自動で進めつつ、実際の変更にはユーザーの明確な承認を求めることが可能になる。

Vercel Agentが提示する計画は、ユーザーが求める「意図」（例: 壊れたデプロイメントを直したい）を達成するために、Agentが提案する「作業」（例: ログを調査し、再デプロイする）と、その作業に必要な「アクセス権限（スコープ）」、そしてそれらのアクセス制限を「強制」するメカニズムで構成される。一つ一つの計画には、どのようなタスクが実行され、その進行状況はどうなっているか、そしてどのスコープが必要かという情報が記録される。タスクの説明には、なぜそのアクセス権が必要なのかが分かりやすく記述されており、計画全体で必要となるスコープがまとめられている。

Vercel Agentは「読み取り専用のベースライン」という権限セットをデフォルトで持っている。これは、read:で始まる全てのスコープを含んでおり、ほとんどの調査作業はこれだけで完結する。このベースラインを超えるアクセス権限を要求する計画、またはGitHubのプルリクエストの作成など外部システムと連携するアクションを含む計画は、必ずユーザーの承認を必要とする。ただし、読み取り専用の操作であっても、機密性の高い情報にアクセスできる場合があるため、自動承認されるからといって完全に無害であるとは限らない。

Vercel Agentは、ユーザーが持つ権限の範囲内でしか動作できない。AgentはVercel Appとして動作し、ユーザーがチーム内でAgentに「自分の代わりに作業を行う」許可を与える。この許可は、Agentを承認したユーザー自身が持つ既存の権限によって制限される。つまり、たとえユーザーがAgentの計画を承認したとしても、その計画によってユーザー自身が持っていない権限をAgentに与えることはできない。VercelのOAuthサービスは、この許可に基づいて、短期間だけ有効な特定のスコープを持つ「トークン」を発行する。このトークンが、Agentが実行できる具体的な能力（例: デプロイメントを読み取る、プロジェクト設定を変更するなど）を定義する。VercelのAPI（アプリケーション・プログラミング・インターフェース）は、Agentからの各リクエストに対して、このトークンをチェックし、定義された制限を厳格に適用する。

例えば、ユーザーがあるチームで数十のプロジェクトに対する権限を持っているとする。Agentが「デプロイメントの書き込みアクセス権」を要求する計画を提示した場合、これは単一のデプロイメントだけでなく、ユーザーがアクセスできる範囲内の全てのデプロイメントに影響を与える可能性がある。計画内で特定のデプロイメント「X」の名前が挙げられていても、それだけでトークンの権限がそのデプロイメントだけに制限されるわけではない。Agentの実行を調整するソフトウェアである「ランタイム」は、計画がアクティブ（実行中）であることを確認してから、承認されたクレデンシャル（Agentが権限を使うための認証情報）を選び、使用する。そして、VercelのAPIは、各リクエストがそのクレデンシャルの権限に合致しているかを再度チェックする。

ユーザーが追加のVercelアクセスを必要とする計画を承認すると、その計画で要求されたスコープが再度確認され、読み取り専用のベースラインスコープに加えて、承認された追加スコープを含むトークンが準備される。ランタイムはこのトークンを使用して作業を実行するが、このトークンは定義されたスコープ、所属するチーム、ユーザーの既存の権限、そして有効期限によって常に制限される。Agentが使用するクレデンシャルは、その作業の内容によって使い分けられる。読み取り専用の調査にはベースラインのトークン、承認されたVercelの変更には承認された追加スコープを含むトークン、GitHubなどの外部アクションにはその外部サービス固有のクレデンシャルが使われる。もしAIがトークンの権限外の操作を試みても、VercelのAPIによってそのリクエストは即座に拒否される。

計画で提案されるスコープの定義と、実際にトークンに付与されるスコープの定義が一致していることは非常に重要だ。もし計画が古い、または存在しないスコープを要求した場合、Agentは意図したとおりに動作できない。Vercel Agentは、Vercelのスコープレジストリから最新のスコープ定義を読み込み、メモリ上にカタログとして保持する。このカタログは、計画が検証される際、承認が必要かどうかを判断する際、そして実際にトークンを準備する際の3つの段階で利用される。これにより、たとえば「ファイアウォールルールを更新する」というタスクが古いスコープを要求した場合、システムは計画の段階でそれを拒否し、Agentに正しいスコープへの修正を促す。これにより、間違った権限が要求されることや、必要以上に広範な権限が意図せず付与されることを防ぐ。

Vercel Agentは、一度承認された計画の実行中に、ネットワーク接続が切れたり、元のチャットセッションが終了したりする可能性がある。このような状況でも、Agentは中断した作業を安全に再開できる必要がある。そのため、保存された計画には、その状態、誰がいつ承認したか、タスク内容、要求された権限といった情報が全て記録されている。作業を再開する際には、ランタイムがこの計画を再度読み込み、計画がまだアクティブ（停止されていない）であることを確認してから、承認された権限を持つクレデンシャルを選んで実行を継続する。もし計画の実行中に「停止」の指示があった場合、たとえトークンの有効期限が残っていても、その計画は実行されない。また、もし調査の結果、現在の計画では問題が解決できないと判断された場合、Vercel Agentは新しい計画を提案し、再度ユーザーに承認を求めることも可能だ。

Vercel Agentがプラットフォームのより多くの部分にアクセスできるようになるにつれて、権限の定義はさらにきめ細かくなる必要がある。例えば、ドメインの紐付けにはドメインとプロジェクトの両方の権限が必要であったり、ファイアウォールルールのテスト適用と公開では異なるレベルのアクセスが必要になったりする。Agentは、こうした複雑な区別を捉えながらも、ユーザーがレビューしやすいように計画のアクセス要求を分かりやすく保つ必要がある。

Agentが適切なスコープを選択するのは容易ではない。不完全な情報で選択するため、必要なアクセス権が不足してタスクがブロックされたり、逆に必要以上に広範な権限を要求してしまったりする可能性がある。また、「最後に成功したビルドを再デプロイする」といった具体的な作業内容の説明は、ユーザーがその影響を評価する上で重要であり、単にスコープ名だけを提示するのでは不十分だ。たとえ適切な権限が付与されていても、「どのコミット（コードの変更履歴）が本番環境に出荷するのに安全か」といった判断は、アプリケーションの特性や問題の内容、提案された修正によって大きく異なる。このような判断には、最終的にユーザーの確認と承認が必要になる。

さらに、読み取り専用の調査であっても、プロジェクトの機密設定や運用詳細といった情報にアクセスする可能性がある。そのため、取得した情報の取り扱い方や、どこまでその情報を利用できるかについても、厳格な管理が必要だ。Vercel Agentは、誤った判断を下したり、読み込んだビルドログなどのコンテンツから悪意のある指示を受け取ったりする可能性もゼロではない。スコープで制限されたクレデンシャルは、そのような場合でも実行可能な操作を限定するが、許可された操作自体が損害を引き起こす可能性は依然として存在する。そのため、Vercel Agentは、サンドボックス（隔離された実行環境）、ネットワークポリシー、機密情報の適切な取り扱い、レートリミット（APIへのアクセス回数制限）、監査ログ（操作履歴の記録）、そしてサービス全体の認証システムといった、他の多層的なセキュリティ対策と組み合わせて運用されている。

最終的に、Vercel Agentは「調査」から「承認されたアクション」まで、必要とされる作業に対して権限が明確に紐付けられるように設計されている。Agentの実行を制御するランタイムは、アクティブな計画に対して承認されたクレデンシャルを選択し、そのクレデンシャルのスコープがAgentが実行できる操作を厳格に定義する。ユーザーは、Agentによる調査結果を確認した上で、提案された修正案と、それに必要なアクセス権限の両方を合わせて評価し、安全に承認できる。これにより、AIの利便性と本番環境の安全性を両立する形で、Vercel Agentは開発者の課題解決をサポートする。