Vercelの今回の侵害は、クラウド本体よりも「周辺のAIツール連携」が入口になった点が重要です。開発基盤そのものが強固でも、社員が使う外部AIアプリとOAuth接続が残っていれば、そこから業務アカウントに入られます。対策の主眼は、流出後のパスワード変更だけではありません。どの連携を許可し、何を秘密情報として扱うかを先に見直す必要があります。
この記事でわかること
– 今回のVercel侵害で何が起きたか
– なぜAIツール連携が侵入口になるのか
– まず切るべき設定と、残すべき設定の分け方
– 似た事故を減らすための運用ルール
何が起きたのか
Vercelは2026年4月20日から21日にかけて、内部システムへの不正アクセスを公表しました。公式の説明では、影響を受けたのは一部の顧客で、漏えいしたのは「sensitive」に分類されていない環境変数です。Vercelは法執行機関と外部のインシデント対応専門家を入れ、影響範囲の調査を続けています。
この件で重要なのは、Vercelの中枢サービス自体が止まったわけではないことです。攻撃者は、社員が使っていた第三者のAIツール Context.ai 側の侵害を足がかりに、Google Workspaceアカウントへ入り込みました。その結果、Vercelの一部環境と設定情報に到達しました。つまり、攻撃面は「SaaS本体」だけではなく「SaaSに接続したSaaS」にまで広がっています。
入口はOAuthだった
今回のような事故では、OAuthがよく使われる入口になります。OAuthは、外部サービスにパスワードを渡さずに権限を委任する仕組みです。便利ですが、接続した瞬間に「その外部アプリが持てる権限」が増えます。
社員が業務改善のためにAIツールを試すのは自然です。問題は、試用のつもりで許可した連携が、そのまま本番の業務アカウントに残ることです。攻撃者はその一点を突きます。単体のパスワードを盗むより、連携済みアプリを起点にした方が、検知されにくく横展開しやすいからです。
何が漏れやすいのか
Vercelは「sensitive」に分類された値は読み取れない設計だと説明しています。逆に言えば、運用の中で軽く扱われがちな設定値は狙われやすいということです。
代表例は次の通りです。
– 本番以外と思っていたAPIキー
– 解析や通知に使うトークン
– 内部向けのWebhook URL
– 一時的に入れた検証用の資格情報
これらは「そのうち消す」前提で置かれがちです。しかし、攻撃者から見れば実運用に繋がる鍵です。秘密情報の格付けを曖昧にすると、守るべきものが守れません。
まず見直すべき3点
対策は難しくありません。優先度の高い順にやるだけです。
-
外部AIアプリとの接続を棚卸しする
社員個人の便利ツールを含め、Google WorkspaceやGitHub、Slackに入っているOAuthアプリを洗い出します。使っていないものは外します。 -
環境変数を再分類する
本当に読み取り不可にしたい値と、業務上の都合で平文管理している値を分けます。後者は漏れてもいい、ではなく「漏れたら即交換」にします。 -
連携アプリの承認ルールを作る
AIツールの導入を個人判断にしないことが重要です。管理者承認、最小権限、期限付き許可の3点をルール化すると、事故率が下がります。
開発組織への影響
この事件は、Vercelを使う開発組織だけの話ではありません。ClaudeやChatGPT、社内向けAIエージェント、データ分析SaaSなど、業務アカウントと連携する道具は増え続けています。道具が増えるほど、監査対象も増えます。
特に注意したいのは、導入が早いチームほど承認プロセスが追いつかないことです。便利だから先に入れる、あとで整える、という順番は危険です。AIツールは生産性を上げますが、同時に認可経路を増やします。ここを別問題として扱う必要があります。
まとめ
今回のVercel侵害が示したのは、クラウドの脆弱性だけではありません。最大のリスクは、社員が使う外部AIツールと業務アカウントの接続です。攻撃者はそこを起点に、権限の広い業務環境へ入ります。
対策の順番は明確です。連携を棚卸しし、秘密情報を再分類し、承認ルールを作る。これだけで被害の幅はかなり縮みます。AIツールを止める必要はありません。止めるべきなのは、管理されていない接続です。