🛡️ 技術調査 - Vercel Agent の権限境界・承認制御・監査証跡

Vercel ダッシュボードに常駐し、本番調査・承認付きアクション・PR コードレビュー・計測の自動導入を担う AI エージェント「Vercel Agent」を、構造とデータの観点から調査します。とくに「AI に本番環境を直させる」運用を成立させるための権限境界・承認制御・監査証跡の設計に焦点を当てます。

本稿は 2026 年 7 月 1 日時点の Vercel 公式ドキュメント(Agent / Chat / Investigation / Code Review / Pricing / Observability Plus)を一次情報として整理しています。Vercel Agent は public beta であり、料金や UI は変わり得ます。

概要

Vercel Agent は、Vercel ダッシュボードに常駐する AI エージェントです。デプロイ・ログ・メトリクス・プロジェクト設定・使用量・連携リポジトリといった、プロジェクト運用に関わる周辺シグナルを横断的に読み取ります。Vercel の AI Cloud 上で動作し、生成したコードは secure sandbox(Vercel Sandbox)上で実行します。これにより、本番環境に到達する前にビルド・テスト・lint を検証できます。

Vercel Agent が重要な理由は、「AI に本番環境を直接触らせる」運用を成立させる最低限の統制を備えているからです。具体的には次の 3 点です。

1. read-only by default: 非センシティブなリソース(プロジェクト・デプロイ・ログ・ドメイン)の読み取りは自動承認ですが、書き込みを伴う操作はすべて承認が必須です。
2. 承認付きアクション(approved actions): 書き込みが必要な場面では scoped plan(対象範囲を限定した実行計画)を提示し、人間の承認を経るまで一切変更しません。
3. 帰属記録(attribution): 昇格された操作は Agent・依頼者・承認者の 3 者に紐づけて記録され、Activity Log や Audit Log で追跡できます。

AI エージェントが本番環境の調査やコード変更に関与する場面が広がる中、これらの権限境界・承認制御・監査証跡が欠けると、誤操作や説明責任の所在不明といったリスクが生じます。Vercel Agent はこの 3 点を製品設計の核に据えることで、AIOps/AgentOps の実用化を進めています。

なお、ダッシュボード chat・investigations・approved actions は、Pro team と Enterprise team を対象とした public beta です。

特徴

Vercel Agent は 4 つの主要 skill を提供します。それぞれの「何ができるか」を一覧します。

統制面の特性は次のとおりです。

• read-only by default: 非センシティブなリソースの読み取りは自動承認、センシティブなリソース(環境変数・トークン)の読み取りと全ての書き込み操作は承認が必須です。
• plan 単位の承認(plan-based authorization): 承認はセッション単位ではなく plan 単位です。各 plan は固有の権限を持つ独立した作業単位であり、同一チャットセッション内でも新しい plan には新しい承認が必要です。plan の完了またはキャンセルで権限は失効します。
• 本人権限への bound: Agent は自身の identity で動作しますが、実行権限は依頼者(requesting user)の権限に bound されます。依頼者が持たない操作は、Agent も承認・実行できません。
• 3 者帰属(Agent / requester / approver): 昇格された操作は、実行した Agent・依頼した requester・承認した approver の 3 者に紐づけて記録されます。GitHub への書き込み(PR 作成・更新・コメント・commit push)も明示的承認が必須で、commit には Vercel Agent が co-author として列挙されます。
• Activity Log / Audit Log への記録: 全ての承認イベントと書き込み操作は team の Activity Log に記録されます(誰が・何を・いつ承認したか)。Enterprise プランでは owner ロールのメンバーが Audit Log でも閲覧でき、CSV エクスポートや SIEM 連携に対応します。Vercel アカウント/プロジェクトへの書き込みは、依頼者本人が "via Vercel Agent" で実行したものとして表示されます。

運用エージェント / AgentOps アプローチとの比較

Vercel Agent を、実行場所・権限・承認モデルが異なる他の運用エージェント型アプローチと比較します。比較対象は、IDE 内コーディングエージェント(Cursor、Claude Code 等)、CI 常駐の自動化 bot(Dependabot 等)、汎用 chatops です。

技術的根拠は以下の一次情報に基づきます。

• read-only/承認/帰属の 3 点は Chat ドキュメントの Authorization テーブルおよび Activity Log 記載に基づきます。「非センシティブ read は自動承認、センシティブ read と全 write は要承認」という区分は Vercel Agent に固有の設計であり、IDE 内エージェントの多くは diff 承認(変更内容そのもののレビュー)であって、リソース種別ごとの承認要否を区分する仕組みは標準装備ではありません。
• plan 単位承認(session ではなく plan ごとに失効)は、IDE/CLI エージェントの「セッション内は許可が持続する」設計や、chatops の「コマンドごとの単発承認」とは異なる粒度です。
• CI 常駐 bot(Dependabot 等)は、定義済みタスク(依存更新の PR 作成)に範囲が限定されており、本番ログ・メトリクスの調査(Investigation 相当の機能)は対象外です。

ユースケース別推奨

構造

Vercel Agent の構造を C4 model の 3 段階(システムコンテキスト/コンテナ/コンポーネント)で図解します。あわせて承認フローの状態遷移を示します。

システムコンテキスト図

Vercel Agent とその利用者、外部システムの関係を示します。

コンテナ図

Vercel Agent をドリルダウンし、主要構成要素を示します。

Chat(対話インターフェース)と 4 つの主要機能(Investigation / Code Review / Approved Actions / Installation)は、いずれも共通の権限・認可レイヤを経由して Vercel Platform にアクセスする点で統制基盤を共有します。各機能の起動契機(Chat=対話、Investigation=alert、Code Review=PR イベント)は独立しており、公式ドキュメントでは機能間で結果を引き渡す連携は明示されていません。

コンポーネント図

認可・承認・実行の流れをドリルダウンします。本番調査(Investigation)の流れを具体例として示します。

Investigation の内部フロー

Authorization 分岐

実行

記録

承認フローの状態遷移

read-only から承認・Sandbox 検証・実行・帰属記録までの状態遷移を示します。

データ

Vercel Agent の認可・承認・監査に関わるエンティティを、概念モデルと情報モデルで整理します。

概念モデル

Team を頂点に、ユーザー・Agent・作業単位(Plan/Task)・対象操作・記録の所有関係を示します。

情報モデル

Authorization 区分 (Resource.sensitivity × Operation.type)

構築方法

前提条件

• Dashboard chat / Investigations / Approved actions は Pro team と Enterprise team の public beta です。
• 段階的ロールアウト中です。アクセス権がない場合は request access から申請します。
• Investigation には Observability Plus が必須です。
  • Observability Plus は Paid Pro team と Enterprise team で利用できます。Hobby は Paid Pro へのアップグレードが必要です。Pro Trial では利用できません。
  • 2026 年 4 月 3 日以降に作成・アップグレードされた Paid Pro team はデフォルトで有効です。それ以前からの既存 Paid Pro / Enterprise team は Billing 設定 > Observability Plus トグルから個別に有効化します。
  • 料金は従量課金で 100 万イベントあたり $1.20 USD です(2026 年 6 月時点、Observability Plus docs 記載)。
• credit 不足を防ぐため、credit 購入 + auto-reload の設定を事前に検討します(後述「credit の追加」参照)。

有効化手順 (Vercel Agent 本体)

• ダッシュボードのサイドバーにある Agent セクションから有効化します。
• Code Review を有効化する場合は同セクションの Enable ボタンをクリックします。
• 機能ごとにセットアップ内容が異なります(詳細は次節)。
  • Code Review: レビュー対象リポジトリと draft PR レビューの可否を設定します。
  • Agent Investigation: Observability Plus が前提で、自動実行には別途トグル有効化が必要です。
  • Installation: プロジェクト単位の Analytics / Speed Insights タブから個別に起動します。

Code Review のセットアップ

• ダッシュボードの Agent セクションから設定します。
• 手順は次のとおりです。
  1. Enable をクリックして Vercel Agent をオンにします。
  2. Repositories で対象リポジトリを選びます。選択肢は次の 3 つです。
     • All repositories(既定)
     • Public only
     • Private only
  3. Review Draft PRs で draft PR をレビューするかを選びます。
     • Skip draft PRs(既定)
     • Review draft PRs
  4. 任意で Auto-Recharge を設定し、残高を自動補充できます。
     • When Balance Falls Below(補充トリガーとなる残高閾値)
     • Recharge To Target Balance(補充後の目標残高)
     • 任意で Monthly Spending Limit(月次上限)
  5. Save で設定を確定します。
• 設定後は、Vercel project に接続済みのリポジトリで PR が自動レビューされます。
• Code Review は次のタイミングで自動実行されます。
  • PR が作成されたとき
  • オープン中の PR にコミットがまとめて push されたとき
  • draft PR レビューを有効化していれば、draft PR が作成されたとき
• レビュー対象には、ソースコード・テストファイル・設定ファイル(package.json、YAML 等)・ドキュメント(README 等)・コード内コメントが含まれます。
• リポジトリ内のガイドラインファイルを優先順位に従って自動検出し、レビュー時の文脈として利用します。優先順位は高い順に AGENTS.md(最優先)→ CLAUDE.md → .github/copilot-instructions.md → .cursor/rules/*.mdc → .cursorrules → 以下計 14 種です。同一ディレクトリに複数あれば最優先のファイルが使われます。
• ガイドラインの適用方式は次のとおりです。
  • Hierarchical: 親ディレクトリのガイドラインは子に継承されます(ルートの CLAUDE.md は全ファイルに適用、src/components/CLAUDE.md は当該ディレクトリに文脈を追加)。
  • Scoped: ガイドラインは自ディレクトリ配下のみに作用します(src/ のガイドラインは lib/ には適用されません)。
  • Nested references: @import "file.md" や相対リンクで他ファイルを参照でき、参照先も文脈に含まれます。
  • Size limit: ガイドラインの合計上限は 50 KB です。
  • ガイドラインは context として扱われ、バグ・セキュリティ・パフォーマンス問題の指摘というレビュアーの中核動作はガイドラインと矛盾しても優先されます。

Agent Investigation のセットアップ

• 前提として次の 2 点が必要です。
  1. Observability Plus サブスクリプション(billing cycle ごとに investigation 10 回分が込み)
  2. 込み分を超える investigation 用の 十分な credit
• 自動実行(アラート発火ごとに自動 investigation)を有効化する手順は次のとおりです。
  1. team の Settings ページに移動します。
  2. General セクションの Vercel Agent 項目内、Investigations のトグルを Enabled に切り替えます。
  3. Save をクリックして確定します。
• 自動実行を有効化しなくても、アラート詳細ページから手動実行は可能です(後述)。
• 以前に Code Review 目的だけで Vercel Agent を有効化していた場合、Investigation は自動開始しません。Investigation は別途有効化が必要です。

Installation のセットアップ

• 対象は GitHub リポジトリが接続済みのプロジェクト のみです。
• 手順は次のとおりです。
  1. ダッシュボードで GitHub 接続済みのプロジェクトを開きます。
  2. Analytics または Speed Insights タブに移動します。
  3. 機能が未有効なら Enable をクリックして有効化します。
  4. Implement ボタンをクリックしてエージェントを起動します。
  5. 作成された PR をレビューし、問題なければマージします。
• PR がマージ・デプロイされると計測が自動的に始まります。PR を作り直したい場合は Run Again をクリックします。
• Installation 自体は全チーム無料です(下層の Web Analytics / Speed Insights 利用量には別途課金されます)。

credit の追加 (Auto-Recharge / Auto-reload)

• Code Review・Investigation・Chat の write 操作はすべて同じ credit pool を共有する credit-based system です。
• 手動で credit を追加する手順は次のとおりです。
  1. ダッシュボードの Agent セクションに移動します。
  2. ページ上部の Credits ボタンをクリックします。
  3. ダイアログで追加金額を入力します。
  4. Continue to Payment でカード情報を入力し購入を完了します。
• auto-reload(残高が閾値を下回ったら自動補充)を有効化する手順は次のとおりです。
  1. ダッシュボードの Agent セクションに移動します。
  2. Credits ボタンをクリックし、auto-reload の Enable を選びます。
  3. 次の画面でトグルを Enabled にします。
  4. 補充条件を設定します。
     • When Balance Falls Below(例: $10 USD)
     • Recharge To Target Balance(例: $50 USD)
     • 任意で Monthly Spending Limit
  5. Save で有効化します。
• 残高が閾値を下回ると、設定した支払い方法に自動課金され credit が補充されます。Monthly Spending Limit を設定している場合、その月の上限に達すると auto-reload は停止します。

利用方法

Authorization テーブル (操作の前提)

各操作にどの認可が必要かを、利用方法に入る前に確認します。

• 承認が必要な場合、Vercel Agent は実行予定タスクを列挙した plan を提示し、実行前にレビューできます。
• Agent は本人(requesting user)が持つ既存権限の範囲内でのみ動作します。本人が実行権限を持たない操作は、Agent も承認・実行できません。
• 承認は session 単位ではなく plan 単位 です。plan は固有の権限を持つ独立した作業単位で、同一 chat session 内でも新しい plan には新しい承認が必要です。plan の完了またはキャンセルで権限は失効します。
• 昇格された操作はすべて team の Activity Log に記録されます(誰が・何を・いつ承認したか)。Enterprise は Audit Log でも閲覧できます。本人の Vercel アカウント/プロジェクトへの write は "via Vercel Agent" として実行されたものと表示されます。
• GitHub への write(PR 作成・更新、コメント、commit push)もすべて明示的承認が必要です。これらは本人に attributed され、commit には Vercel Agent が co-author として列挙されます。

Chat の使い方

• ダッシュボードで New Chat をクリックして会話を開始します。
• Vercel Agent がアクセスできるのは、現在選択中の team で本人がアクセスできるデータ(その team の全プロジェクトを含む)のみです。複数 team に所属していても他 team のデータにはアクセスできません。
• Chat でできることは次のとおりです。
  • プロジェクトに関する質問に、実際のデプロイデータに基づいて回答する
  • failed deploy・runtime error・cost spike の原因を追跡し、修正案を提示する
  • 環境変数の作成・更新・削除
  • deployment・rollback・redeployment のトリガー
  • observability alert・dashboard の構成
  • storage resource(Blob、Redis、Edge Config)の作成・更新・削除
• public/private を問わず、本人がアクセス権を持ち Vercel project にリンク済みのリポジトリを読めます。調査時には複数リポジトリを横断して読むことがあります。
• example prompts(公式ドキュメント記載分)は次のとおりです。

# Debugging and performance
Fix my 500 errors
How do I improve the Core Web Vitals of my site?
Has there been any spikes in TTFB lately?
How's my build performance?

# Cost and billing
Where can I add caching to reduce my bill?
Why did I get charged more this month compared to last?
Which projects generated the highest Active CPU usage?

# Traffic and analytics
Are traffic patterns different compared to last week?
What pages are bots interacting with most?
How many workflow runs have we done in the last 3 days?

# Configuration
Configure bot protection for my project
List environment variables and who created them
What's the best way to deploy an agent to Vercel?

• Chat 履歴は、Team Owner / Admin は Agent > Chats タブで team 全体の chat session を閲覧できます。他のメンバーは自分が参加した chat のみ閲覧できます。サイドバーのドロップダウンからも履歴にアクセスできます。
• beta 期間中、chat transcript は Vercel staff による Agent 改善目的のレビュー対象になり得ます。

Investigation の使い方

• 自動発火: Agent Investigations を有効化している場合、anomaly alert が発火すると Vercel Agent が自動的に investigation を実行します。alert 時刻周辺のログ・メトリクスを query し、パターンを探索し、関連エラー・anomaly を確認して結果を要約します。
• 閲覧方法: 結果を見る手順は次のとおりです。
  1. Vercel dashboard の Observability > Alerts に移動します。
  2. 確認したい alert をクリックします。
  3. alert 詳細とあわせて investigation 結果を確認します。investigation が実行中なら、分析過程を real-time stream で確認できます。
• Rerun: 最新データで再実行したい場合は Rerun ボタンをクリックします。
• 手動実行: Agent Investigations を自動実行で有効化していない場合でも、alert 詳細ページから手動実行できます。
  1. Observability > Alerts から対象 alert を開きます。
  2. Investigate(または Rerun)ボタンをクリックして手動実行します。

Approved actions の使い方

• write を伴うタスクが必要なとき、Vercel Agent は scoped plan(対象範囲を限定した実行計画)を提示し、承認を待ちます。承認するまで一切の変更を行いません(read-only by default)。
• 操作フローは次のとおりです。
  1. Agent が write が必要と判断すると、実行予定タスクを列挙した plan を提示する。
  2. 本人が plan の内容と要求される権限をレビューする。
  3. 承認すると、PR の作成、rollback、config 更新などを実行する。
• plan ごとに承認が必要で、同一 chat session 内でも新しい plan には改めて承認が必要です。plan の完了・キャンセルで権限は失効します。
• 承認・実行された write 操作は Activity Log(Enterprise は Audit Log)に記録され、本人 + "via Vercel Agent" として帰属表示されます。

Code Review の使い方

• セットアップ済みのリポジトリでは、PR 作成時・PR へのコミット push 時・(設定により)draft PR 作成時に自動レビューが走ります。
• レビューは secure sandbox で実ビルド・実テスト・linter を実行して検証され、検証を通過した修正のみ PR に提案として表示されます。提案は ワンクリックで適用 できます。
• 自動レビューに加えて、PR コメントで @vercel をメンションしてオンデマンドで起動できます。

@vercel run a review        # フルレビューを実行する
@vercel fix the type errors # 型エラーの修正を実装してコミットする
@vercel why is this failing? # 問題を調査する

• 返信は同じコメントスレッド内に表示されます。
• レビュー内容はリポジトリ内のガイドラインファイル(AGENTS.md が最優先、次いで CLAUDE.md 等)を自動検出して反映しますが、ガイドラインはあくまで context として扱われ、バグ・セキュリティ・パフォーマンス問題の指摘というレビュアーの中核動作はガイドラインと矛盾しても優先されます。

運用

Investigation の運用

• Investigation は Observability Plus を契約したチームで billing cycle ごとに 10 件込みです。
• 11 件目以降は追加 investigation として 1 件あたり固定 $0.30 USD + token 実費がかかります。
• 自動発火させるには、Team Settings の Vercel Agent 設定で Investigations トグルを個別に Enabled にする必要があります。
• Code Review だけ有効化していても Investigation は自動開始しません。Investigation は別トグルです。
• 自動発火が無効な場合は、Observability > Alerts のアラート詳細画面から Investigate ボタンで手動実行できます。
• 一度実行した investigation を最新データで再実行したい場合は Rerun ボタンを使います(自動発火後・手動実行後のどちらでも利用可)。
• credit が不足すると investigation の実行(追加分)が止まります。事前に auto-reload を設定するか、credit 残高を Agent タブで監視してください。

承認運用

• 承認は plan 単位です。session 単位ではありません。
• 1 plan は具体的な権限を持つ discrete unit of work として扱われ、同一 chat session 内でも新しい plan には改めて承認が必要です。
• plan が完了またはキャンセルされると、その plan に紐づく権限は失効します。
• Agent は requesting user が保有する権限の範囲内でしか動作できません。本人が権限を持たない操作は、承認しても実行できません。
• 承認が必要な操作は Authorization テーブル(前述)のとおりです。
• GitHub 連携の write(PR 作成・更新、コメント投稿、commit push)もすべて明示的な承認が必要です。これらの操作は承認したユーザー本人に attribute され、commit には Vercel Agent が co-author として列挙されます。

監査運用

• 全 authorization イベントと write 操作は team の Activity Log に記録されます。誰が plan を承認したか、何が許可されたか、いつ実行されたかを確認できます。
• Enterprise plan では、owner ロール のメンバーがこれらのイベントを Audit Log でも確認できます。Audit Log は CSV エクスポート(24 時間有効なダウンロードリンク)や SIEM(AWS S3 / Splunk / Datadog / Google Cloud Storage / 任意の HTTP エンドポイント)へのログストリーミングに対応し、Activity Log より監査・長期保全の用途に向きます。
• Vercel アカウント/プロジェクトへの write は、実行した本人が "via Vercel Agent" という形で行ったと表示されます。
• 定常運用では、定期的に Activity Log(Enterprise は Audit Log)を確認し、承認された plan の内容と実行結果に乖離がないかをレビューすることを推奨します。

Chat history 閲覧権限

• beta 期間中は、Vercel Agent 改善目的で Vercel staff が chat transcript をレビューする可能性がある点に留意してください。

無効化運用

• Team Owner / Admin は Team Settings > Agent からいつでも Vercel Agent を無効化できます。
• 無効化すると、進行中の chat セッションは即座に終了し、進行中タスクの権限はすべて revoke され、新規 chat の開始もできなくなります。
• 再有効化は同じ Team Settings > Agent からトグルを戻すだけです。

コスト運用

• 課金は credit ベースです。Agent の全機能(Code Review / Investigation / Chat 内の操作)は同一 credit プールを共有します。
• 1 件あたりのコストは 固定 $0.30 USD + token 実費(Agent が利用する AI provider のレートでの pass-through、Vercel のマークアップなし)です(2026 年 6 月時点、Vercel Agent Pricing docs 記載)。
• token コストは解析するログ・メトリクスの量や複雑さで変動します。
• Investigation は billing cycle あたり 10 件まで Observability Plus に込みで、11 件目以降のみ課金対象です。
• Code Review は都度課金(込み枠なし)です。
• Installation(Web Analytics / Speed Insights 導入)は全チーム無料です。
• credit 残高と個別アクションのコストは、ダッシュボードの Agent タブ(残高表示・Credits ボタン・reviews テーブルの Cost 列)で確認できます。
• 残高を切らさないために auto-reload を設定できます。「When Balance Falls Below」(再チャージ発動の閾値)・「Recharge To Target Balance」(補充後の目標残高)・任意で「Monthly Spending Limit」(月次上限)を設定します。上限に達すると auto-reload はその月は止まります。

ベストプラクティス

「AI に本番を直させる」前提で統制を設計する場合、最低限押さえるべき観点を以下にまとめます。

• read-only default を崩さない: Vercel Agent は自身の identity で動作しつつ、requesting user の権限に bound される設計です。write が必要な操作は常に scoped plan の提示と承認を経由させ、この既定動作を変える設定(回避策)を導入しないようにします。
• scoped plan は承認前に必ずレビューする: plan には実行予定のタスクと要求権限が列挙されます。over-broad な plan(必要以上の範囲の write を含む plan)は承認前に弾く運用にします。
• 全 write を帰属記録で追跡する: elevated actions は Agent / requester / approver の 3 者に attributed されます。Activity Log(Enterprise は Audit Log)を定期的に確認し、承認者と実行内容のトレーサビリティを保ちます。
• センシティブ resource の read も承認ゲートに含める: 環境変数やトークンの read は Auto-approved ではなく Requires approval です。この区分を緩めない(センシティブ resource read を自動承認に倒さない)ことが重要です。
• Sandbox 検証を本番反映の前提にする: 生成コードは Vercel Sandbox で実ビルド・テスト・linter による検証を経てから提案されます。検証を経ていない変更を手動で本番に適用しない運用と組み合わせます。
• Investigation の枠とコストを監視する: billing cycle あたり 10 件の込み枠を超えると課金が発生します。Agent タブで利用件数とコストを定常監視し、auto-reload と Monthly Spending Limit を組み合わせてコスト超過を防ぎます。
• data preferences off / Enterprise plan を選択する: team の data preferences 設定を "off" にするか Enterprise plan を利用すると、customer code や chat transcript を学習に使われません。beta 期間中は chat transcript が Vercel staff のレビュー対象になり得る点も併せて運用ポリシーに反映します。

CI/CD 連携

• Code Review を全 PR に対して有効化することで、人手レビュー前に Sandbox 検証済みの提案を得られます。
• 対象リポジトリと draft PR をレビュー対象に含めるかどうかは Code Review のセットアップで個別に設定します。
• PR コメントで @vercel をメンションすると、その場で修正提案やスレッド内の質問への回答を得られます(提案された修正の適用には別途レビュー・承認が必要です)。

マルチ環境 / チーム分離

• Vercel Agent は 現在選択している team でアクセス可能なデータのみを扱います。
• 同一ユーザーが複数 team に所属していても、選択中の team 以外のプロジェクトにはアクセスできません。
• 環境(Production / Preview など)をまたぐ操作も、ユーザー本人が持つ既存権限の範囲に制限されます。

権限最小化

• Agent 自体に独立した強い権限を持たせるのではなく、requesting user の権限に bound させる設計を維持します。
• write 操作を実行する個々のユーザーの Vercel/GitHub 権限を最小化しておくことが、結果的に Agent の実行可能範囲の最小化に直結します。

人間の承認をどこに置くか

トラブルシューティング

まとめ

Vercel Agent は、ダッシュボードに常駐して本番調査から承認付き修復まで担う運用エージェントであり、その本質は read-only default・plan 単位の承認・3 者帰属という統制設計にあります。「AI に直させる」前に、どのリソースの read/write にどの承認ゲートを置き、誰の権限境界で実行して何を監査ログに残すかを設計しておくことが、運用エージェント導入の最低ラインになります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 公式ドキュメント
  • Vercel Agent
  • Chat
  • Investigation
  • Code Review (PR Review)
  • Agent Installation
  • Vercel Agent Pricing
  • Observability Plus
  • Vercel Sandbox
  • Activity Log
  • Audit Log
  • Vercel for GitHub permissions
• 記事 / 発表
  • Introducing Vercel Agent
  • Vercel Agent can now run AI investigations
  • An expanded Vercel Agent: chat, investigations, and approved actions now in public beta