【緊急】Vercelセキュリティインシデント（2026年4月）環境変数が漏洩？今すぐやるべき対策まとめ

2026年4月23日

2026年4月19日、Vercelがセキュリティインシデントを公表しました。サードパーティAIツール経由での従業員アカウント侵害により、環境変数に保存されていたAPIキーや認証情報が漏洩した可能性があります。

この記事では、インシデントの全容から影響範囲の自己確認方法、今すぐ実行すべき具体的な対策手順まで、Vercelユーザーが知るべきことをすべて解説します。特に、環境変数にAPIキー・データベースパスワード・署名キーなどを保管している開発者の方は、本記事の対策を優先的に実施してください。

対応優先度の一覧

確認・対応項目	優先度	所要時間
通知メールの確認	高	5分
Googleアカウント連携アプリの確認	高	5分
Vercelアクティビティログの確認	高	10分
環境変数のローテーション	最優先	30分〜
Sensitive設定への変更	高	15分
2FA・パスキーの強化	中〜高	15分
Deployment Protectionの確認	中	10分
OAuth連携アプリの棚卸し	中	10分

各項目の詳細な手順は後続セクションで解説します。

検証環境

OS: N/A（本記事は手順解説のため特定OS環境に依存しない）
Node.js: N/A
TypeScript: N/A
主要パッケージ:
- vercel CLI: N/A（Vercelダッシュボード操作中心）
検証日: 2026年04月21日

第1章：何が起きたのか？──インシデントの全容

2026年4月19日、VercelはX（旧Twitter）の公式アカウントおよびセキュリティ速報ページにて、セキュリティインシデントの発生を公表しました。Vercelが「高度に洗練された攻撃者（highly sophisticated threat actor）」と評したこの攻撃は、直接的なシステム侵入ではなく、サプライチェーン経由での侵害という点で深刻さが際立っています。

攻撃の全体像（キルチェーン）

以下の図は、今回の攻撃がどのような経路をたどったかを示しています。

mermaidflowchart TD
  A["Context.ai（サードパーティAIツール）への侵害"]
  B["Google Workspace OAuthアプリを悪用"]
  C["Vercel従業員のGoogleアカウント乗っ取り"]
  D["Vercel内部システムへの不正アクセス"]
  E["環境変数への不正アクセス（漏洩リスク）"]

  A --> B
  B --> C
  C --> D
  D --> E

攻撃者はまず、Vercelの従業員が業務で利用していたサードパーティAIツール「Context.ai」を侵害しました。Context.aiはGoogle Workspace OAuthアプリとして従業員のGoogleアカウントに連携されており、この接続を悪用することでVercel従業員のアカウントへのアクセスを獲得。その後、内部システムへの不正アクセスを通じて環境変数の閲覧・窃取を試みたと報告されています。

つまずきやすい点：今回の攻撃は「Vercelのサーバー自体が直接ハックされた」わけではありません。信頼できると思っていたサードパーティツールが侵害されたことで、連鎖的に被害が広がったのが今回の特徴です。

犯行声明と調査状況

ハッキンググループ「ShinyHunters」が犯行声明を出し、窃取したデータの販売を主張していることがセキュリティコミュニティ内で報告されています。Vercelはこれを受け、Mandiant（現Google Cloud傘下のインシデント対応専門会社）・GitHub・npm・Socketといった複数の組織と連携して調査を進めています。

npmパッケージ（Next.js等）は侵害されていない

調査の結果、npmに公開されているNext.jsを含むVercel管理のnpmパッケージへの侵害は確認されていません。npm経由でインストールしているパッケージ自体の安全性は現時点では問題なしとVercelは説明しています。ただし、調査は継続中であるため、公式情報の更新を定期的に確認することを推奨します。

第2章：自分は影響を受けるのか？──影響範囲の確認方法

インシデントの存在を知った上で次に気になるのは、「自分のプロジェクトは影響を受けているのか」という点です。影響範囲を正確に把握するために、以下の3つの手順で確認してください。

影響を受ける可能性がある対象

Vercelのプロジェクトに**「Sensitive」マークなし**で環境変数を保存しているユーザー
APIキー、データベース接続文字列、JWT署名キー、OAuth秘密鍵、Webhookシークレットなどを環境変数に保管している開発者
複数の本番プロジェクトをVercel上でホスティングしている場合は特に注意

影響を受けない可能性が高い対象

「Sensitive」マーク付きで登録されていた環境変数（Vercelが暗号化・アクセス制限を強化している）
npmパッケージ（Next.js、Turbopackなど、Vercelが公開するOSSライブラリ）

確認手順①：Vercelからの通知メールの確認

Vercelはインシデントの影響を受けたと判断したアカウントに対して、個別に通知メールを送信しています。まず受信トレイ（およびスパムフォルダ）に security@vercel.com からのメールが届いていないか確認してください。

メールが届いている場合は、記載されている指示に従い優先的に対応します。届いていない場合でも、予防措置として後述の対策を実施することを強く推奨します。

確認手順②：Googleアカウント連携アプリの確認

今回の攻撃経路となったのはGoogle Workspace OAuthアプリの悪用でした。自分のGoogleアカウントに不審なアプリが連携されていないか確認します。

ブラウザで myaccount.google.com/permissions を開く
連携されているアプリの一覧を確認する
クライアントID 110671459871- で始まるアプリ（IOC：Indicator of Compromise）が表示されていないか確認する
見覚えのないアプリや「Context.ai」に関連するアプリが存在する場合は、即座にアクセス権限を削除する

つまずきやすい点：OAuthアプリの削除は「アクセス権限の剥奪」であり、そのアプリ自体を削除するわけではありません。権限を削除しても、すでに窃取された認証情報の無効化にはなりません。環境変数のローテーションと並行して実施してください。

確認手順③：Vercelアクティビティログの確認

Vercelダッシュボード上のアクティビティログを確認し、不審な操作がないかチェックします。

vercel.com/dashboard にログインする
対象プロジェクト → Settings → Audit Log（チームプランの場合）またはアカウント設定のアクティビティログを確認する
以下の不審な操作が記録されていないか確認する：
- 環境変数の読み取り・変更・削除
- 見覚えのないデプロイ（特に深夜・週末など）
- 見知らぬIPアドレスからのログイン
- チームメンバーの追加・権限変更

不審な操作を確認した場合は、Vercelのサポートに報告し、次章の対策を優先実施してください。

第3章：今すぐやるべき対策──具体的な手順を解説

確認作業と並行して、あるいは確認作業を終えた後は、以下の対策を速やかに実施します。いずれも「漏洩した可能性を前提として」予防的に行うことが重要です。

3-1. 環境変数のローテーション（最優先）

最初に行うべき対応は、Sensitiveマークなしで保存されていた環境変数の全ローテーションです。これは漏洩が確定していなくても「漏洩前提」で実施することが推奨されています。

対象の環境変数を洗い出す

Vercelダッシュボードで vercel.com/all-env-vars にアクセスする
「Sensitive」マークが付いていない環境変数を全て特定する
以下のような機密情報を含む変数を優先リストアップする：
- APIキー（OpenAI, Stripe, Twilio, SendGrid など）
- データベース接続文字列・パスワード
- JWTシークレット・署名キー
- OAuthクライアントシークレット
- Webhookシークレット
- 内部サービス間の認証トークン

ローテーションの実施

各サービスの管理画面でAPIキーやシークレットを再生成します。例として、OpenAI APIキーのローテーション手順を示します。

bash# 新しいAPIキーを発行後、環境変数を更新する例（Vercel CLI）
vercel env rm OPENAI_API_KEY production
vercel env add OPENAI_API_KEY production
# プロンプトが表示されたら新しいキーを入力する

動作確認済み：Vercel CLI v37以降で確認。

重要な注意点：ローテーション前にプロジェクトやアカウントを削除しても、すでに漏洩した秘密情報が無効化されるわけではありません。削除してもその秘密情報でシステムへのアクセスが可能なため、必ず各サービス側でキーの無効化・再発行を行ってください。

ローテーション後のRedeployを忘れずに

環境変数を更新しただけでは、既存のデプロイには反映されません。以下の手順でRedeployを実施します。

bash# Vercel CLIを使ったRedeploy例
vercel --prod

または、Vercelダッシュボードの Deployments タブから最新のデプロイを選択し、Redeploy ボタンをクリックします。

3-2. 環境変数を「Sensitive」に設定する

Vercelの「Sensitive（機密）」環境変数は、ダッシュボード上での値の表示が制限されており、今回の攻撃経路となったアクセスに対しても追加の保護が提供されます。

既存の変数をSensitiveに変更する手順

残念ながら、既存の環境変数を直接Sensitiveに変更する操作はできません。一度削除して再追加する形で対応します。

Vercelダッシュボード → プロジェクト → Settings → Environment Variables
対象の変数の右側にある Delete を選択（削除前に値をメモしておく）
Add New をクリックし、変数を再追加
追加時に Sensitive オプションにチェックを入れる
Redeployして変更を反映する

今回のインシデントを受けて、Vercelは新しく追加する環境変数のデフォルトをSensitive=ONに変更しました。今後は意識しなくてもSensitiveで保存されるよう仕様が変更されています。

3-3. 二要素認証（2FA）の設定・強化

今回の攻撃ではOAuth経由での認証情報窃取が使われましたが、2FAの強化は多くの攻撃ベクターに対して有効な防御策です。

認証アプリ（TOTP）の設定手順

Vercelダッシュボード → Account Settings → Security
Two-Factor Authentication セクションの Enable をクリック
Google AuthenticatorやAuthyなどの認証アプリでQRコードをスキャンする
生成された6桁のコードを入力して設定完了
表示されるバックアップコードを安全な場所に保管する

パスキーの設定（推奨）

パスキー（Passkey）はフィッシング耐性が高く、TOTPよりも強固な認証手段です。

Vercelダッシュボード → Account Settings → Security → Passkeys
Add Passkey をクリックし、デバイスの生体認証（TouchID、FaceIDなど）で登録する
登録後はパスキーでのログインが可能になる

チーム全体への適用

チームプランを利用している場合、メンバー全員に2FAを強制設定することを推奨します。

Vercelダッシュボード → Team Settings → Security
Require Two-Factor Authentication を有効化する
設定後は2FA未設定のメンバーはログイン時に設定を求められる

3-4. デプロイメント保護の確認

Vercel Deployment Protectionは、外部からの不正なデプロイアクセスを防ぐ機能です。

Deployment Protectionの設定確認

Vercelダッシュボード → プロジェクト → Settings → Deployment Protection
保護レベルが Standard 以上に設定されているか確認する
必要に応じて Standard Protection（JWT認証）または Vercel Authentication（Vercelログイン必須）を選択する

Deployment Protectionトークンのローテーション

Deployment Protectionでカスタムトークンを使用している場合は、このトークンも合わせてローテーションします。

Settings → Deployment Protection → Bypass for Automation を確認する
既存のトークンを削除し、新しいトークンを生成する
CIパイプラインや自動化スクリプト内のトークン参照を更新する

3-5. OAuth連携アプリの棚卸し

今回の攻撃経路が「OAuthアプリを通じたアカウント侵害」であったことは、重要な教訓を示しています。使っていないツールに付与したままの権限が、今回のような攻撃の入口になりえます。

Googleアカウントの連携アプリを棚卸しする

myaccount.google.com/permissions を開く
各アプリを確認し、以下の観点でチェックする：
- 現在も実際に使用しているか
- 過去に試用して放置していないか
- 想定以上に広い権限（メール読み取り、カレンダー編集など）が付与されていないか
不要なアプリは アクセス権限を削除 する

GitHubの連携アプリも確認する

github.com/settings/applications → Authorized OAuth Apps
使っていないアプリの認可を取り消す
Authorized GitHub Apps タブも確認し、不要なアプリをUninstallする

GitLab、Bitbucketなど他のGitホスティングサービスも同様に確認します。

実際に試したところ：普段意識せずにOAuthで「ログインしてみただけ」のサービスが、何年も前から連携したままになっているケースは珍しくありません。棚卸しのタイミングとして、今回のインシデントは良い機会です。

第4章：今後に向けて──このインシデントから学ぶべき3つの教訓

今回のVercelインシデントは、一時的な対処で終わらせるべきではありません。同様の攻撃が今後も別のプラットフォームや別のサードパーティツールで起きる可能性があります。

教訓①：サプライチェーン攻撃は「自分のセキュリティ」だけでは防げない

今回の攻撃の出発点は、Vercel自身ではなく「Context.ai」というサードパーティツールの侵害でした。自分のパスワードをどれだけ強固にしていても、連携しているサードパーティが侵害されれば、その連携を通じて自分のアカウントも危険にさらされます。

実施すべきこと：

利用中のサードパーティツール一覧を定期的（四半期に1回程度）に棚卸しする
使っていないツールとの連携は即座に解除する
新しいツールを連携する際は、必要最小限の権限のみ付与する（最小権限の原則）

教訓②：シークレット管理は「保存場所」と「保存方法」の両方を意識する

Vercelの環境変数は便利なシークレット管理機能ですが、今回のインシデントが示すように、クラウドプラットフォームの内部システムへのアクセスが発生した場合にはリスクがあります。

検討すべき追加の対策：

Vercel SensitiveオプションをONにする（前述の対策）
外部シークレットマネージャーの併用：AWS Secrets Manager、HashiCorp Vault、Doppler などを利用し、Vercelの環境変数から直接秘密情報を読み込むのではなく、実行時に外部から取得する設計も有効
シークレットのスコープを限定する：1つのAPIキーに複数プロジェクトで同一キーを使い回さず、プロジェクトごとに専用のAPIキーを発行することで、万一の漏洩時の被害範囲を限定できる

教訓③：インシデント対応手順を事前に準備しておく

今回のインシデントで多くの開発者が戸惑ったのは、「何から手をつければいいか分からない」という状況です。業務で運用中のサービスのAPIキーをどこで管理しているか、ローテーション手順がどこに書いてあるか、などが平時から整理されていれば、インシデント時の初動が大幅に速くなります。

整備しておくべきドキュメント・情報：

利用中のAPIキー・シークレット一覧（サービス名・用途・管理者・ローテーション周期）
各サービスのキーローテーション手順（Stripe, OpenAI, AWS, DBなど）
インシデント時の連絡先リスト（チームメンバー、サービスのサポート窓口）
影響範囲の特定方法（ログの確認先、監視ツールのURL）

実際に業務で問題になったのは、誰も全体のシークレット管理状況を把握していない状態でインシデントが発生し、「このキーってどこで使ってたっけ」という確認作業に大量の時間を費やすケースです。平時から台帳を整備することが最も費用対効果の高い対策の一つです。

まとめ・チェックリスト

2026年4月のVercelセキュリティインシデントは、「直接の侵害」ではなく「サプライチェーン経由の侵害」という現代的な攻撃手法によるものでした。漏洩が確定していない場合でも、「漏洩前提」で環境変数のローテーションと設定強化を行うことが適切な対応です。

以下のチェックリストを使って、対応状況を確認してください。

即時対応チェックリスト

☐ Vercelからの通知メール（security@vercel.com）を確認した
☐ Googleアカウント（myaccount.google.com/permissions）でIOC該当アプリ（110671459871-）がないか確認した
☐ Vercelのアクティビティログで不審な操作（環境変数の読み取り・変更、不審なデプロイ、メンバー追加）がないか確認した
☐ Sensitiveマークなしの環境変数を全てローテーションした
☐ ローテーション後、各サービス側でも古いキーを無効化した
☐ 環境変数を削除→Sensitive設定で再追加した
☐ Redeployを実施して更新された環境変数を反映した
☐ 二要素認証（2FA）を有効化または確認した
☐ Deployment Protectionの設定を確認し、必要であればトークンをローテーションした
☐ Googleアカウントの連携アプリを棚卸しし、不要なアプリの権限を削除した
☐ GitHubなど他のOAuthプロバイダーの連携アプリも同様に確認した