Vercel侵害は「第三者AIツール経由」だった——Google Workspace OAuthが入り口、各社の管理者設定を見直すべき理由
朝に出た Vercel の侵害の件、公式セキュリティ告示が続報で更新され、原因が “third-party AI tool” 経由であることが明らかになりました。第三者 AI ツールは Vercel 従業員が利用していた Context.ai です。Vercel 本体の直接的な侵害というより、発端は第三者 AI ツール側だったが、その侵害を足がかりに Vercel 従業員の Google Workspace アカウントが乗っ取られ、結果として一部の Vercel 内部システムに不正アクセスが及んだ、という構図です。
ここ、朝の記事と視点を分けて整理しておきたい。
Vercelがハックされ顧客データが流出——ShinyHunters名乗る攻撃者が「販売中」と投稿、開発者勢は影響確認を急ぐべし
起点は「第三者AIツールの側」
Vercel の公式 bulletin によれば、侵害の発端は Vercel のインフラそのものではなく、Vercel 従業員が使っていた第三者 AI ツール Context.ai。このツールの侵害を通じて、攻撃者はその従業員の Vercel の Google Workspace アカウントを乗っ取り、そこから 一部の Vercel 環境と “sensitive” に設定されていない環境変数 へアクセスした、という流れです。Vercel はあわせて、この OAuth アプリが より広い侵害の対象になっており、多くの組織にまたがる数百ユーザー規模に影響し得る とも説明しています。
問題はここで、こういう侵害は「自社のクラウドが破られた」という従来の SIer 的な侵害地図では見えにくい。今回の Vercel の事実関係として公式に確認できるのは、Vercel 従業員側の OAuth 連携アプリが起点だった、という点までですが、実務上は、自社が直接契約していない”下流のAIツール”が Google Workspace に OAuth アプリとして入り込んでいるケースも同じ構図で攻撃面になり得る、と読んでおくべきです。
- 直接契約先：Vercel、Google Workspace（自社が契約している SaaS）
- 間接的な攻撃面：従業員が Google Workspace に OAuth 承認した AI ツール
AI ツール界隈は、ChatGPT 系のブラウザ拡張・議事録取り・メール下書き・文書要約などで、「Google でログイン」ボタンを押すだけで OAuth アプリが追加されるタイプが爆発的に増えました。ユーザー視点では便利ですが、Workspace 管理者から見ると、誰がどのアプリに何の権限を渡しているかを把握しきれていない状況が積み上がりやすい。今回の件は、その見えにくい攻撃面が現実に問題化した例として読むのが自然です。Google の管理者向けドキュメントでも、API controls 配下で「Configured apps」「Accessed apps」を確認し、第三者アプリのアクセス制御を管理できることが案内されています。
Google Workspace 管理者が見るべきポイント
Vercel 側は bulletin の中で、Google Workspace Administrators と Google Account owners に対し、該当アプリの利用有無を直ちに確認するよう勧告しています。Vercel 自体が細かい操作手順まで書いているわけではありませんが、実務で今夜から回しておきたい手はシンプルです。
- Google Workspace の Admin Console → Security → Access and data control → API controls → Manage Third-Party App Access
- 「社内で誰がどのサードパーティアプリに OAuth 権限を渡しているか」の一覧を引く
- 信頼していない AI ツール、または利用実態が不明なアプリのアクセス設定を見直す
- 必要に応じて、未設定の第三者アプリを制限したり、個別アプリを Blocked / Limited に切り替える
特に Gmail、Drive、Calendar などへの広いアクセス権を持つアプリは優先度が高い。Google も API controls や domain-wide delegation のドキュメントで、必要最小限の OAuth scope に絞ること、不要な委任やクライアントを定期的に見直すことを勧めています。
見落としがちだけど、個人の Google アカウント（@gmail.com） でもこの構造は同じで、Google アカウントの「third-party connections」ページから、Google アカウントへのアクセス権を持つアプリや「Sign in with Google」の接続を確認・削除できます。AI ツールを気軽に試してきた個人は、今夜ここを一回棚卸ししておくといいです。
“AIツールへのOAuth委任”は新しい攻撃面
規制の文脈で言うと、今回の件が示しているのは、AI ツール経由のサプライチェーン侵害というより、OAuth 委任がそのまま攻撃面になるタイプの侵害です。SolarWinds 以降、サプライチェーン攻撃は「ソフトウェアのビルドパイプライン」や「アップデート経路」に焦点が当たってきましたが、今回はそこではなく、OAuth アプリの侵害から委任先アカウントへ踏み込まれたのがポイントです。少なくとも Vercel の公式説明として確認できるのは、その経路で Vercel 従業員の Google Workspace アカウントが乗っ取られ、Vercel 環境へのアクセスに使われたという点です。
- 従来：ベンダーのコードがマルウェア化される（SolarWinds 型）
- 今回：ベンダー側で侵害された OAuth アプリが足がかりとなり、委任済みアカウント側に波及する
OAuth は”委任の仕組み”として優秀ですが、委任先が侵害された瞬間に、委任側（自社）のデータや環境が攻撃面に変わる。この構造は Google Workspace だけの話ではなく、Microsoft 365、Slack、GitHub でも設計上は同系統の問題として考える必要があります。今回の bulletin は、少なくとも Google Workspace と OAuth アプリの棚卸しを進める十分なきっかけになります。
朝記事との関係と、今夜の打ち手
朝の記事で書いたチェックリスト（Vercel アカウントの MFA、アクセストークン棚卸し、環境変数のローテーション）は、今回の続報で否定されたわけではない。Vercel も、活動ログの確認、環境変数の見直しとローテーション、最近のデプロイ確認、Deployment Protection の設定確認とトークンのローテーションを推奨しています。
ただし、今夜からやるべき1点を足すなら——Google Workspace（または個人の Google アカウント）の OAuth アプリ一覧を見て、AI ツール系の権限を整理する、ここになります。
- 法人：Admin Console → Security → Access and data control → API controls → Manage Third-Party App Access、必要なら Manage Domain Wide Delegation も確認
- 個人：Google アカウントの third-party connections ページから、接続中アプリの詳細確認とアクセス削除
今回の件で Vercel と無関係な組織でも、自社の OAuth 委任状況を棚卸しする良いトリガーになったと捉えるのが健全です。なお、どの AI ツールが該当したかは未公表ではなく、Vercel はすでに Context.ai を起点として明記しています。
煽りたくはないけれど、生成AIの便利さと引き換えに権限委任を積み上げてきたここ1年のツケが、こういう形で可視化される局面が今後も続くと思います。続報、特に Context.ai 側の事後対応や他組織での波及範囲は追っておきたい。
Vercel — April 2026 Security Incident（公式セキュリティ告示・続報含む）
