Vercelの不正アクセス調査方法｜デプロイ履歴・アクセスログ・環境変数の確認

Next.jsや各種フロントエンドフレームワークを用いた個人開発・Webサービス運営において、デプロイ基盤として広く支持されているのがVercelです。GitHubと連携するだけで数秒で本番公開できる利便性がある一方、アカウントやリポジトリのセキュリティ管理を怠ると、予期せぬ不正アクセスや侵害インシデントに巻き込まれるリスクを抱えています。

「GitHubに身に覚えのないコミットやプルリクエストが作成され、勝手にVercelへデプロイされている」「サーバーレス関数の呼び出し回数が突如跳ね上がり、高額課金の警告メールが届いた」「環境変数に設定していたOpenAIやStripeのAPIキーが外部に漏洩した形跡がある」。このような事態に直面した際、Vercelのどの画面を、どのような手順で点検すべきかを正確に把握しておく必要があります。

この記事では、個人開発者や少人数チーム向けに、Vercelにおける不正アクセスの調査手順を網羅的に解説します。チームメンバーの権限点検から、デプロイ履歴（Deployments）の照合、Runtime Logs（実行ログ）の追跡、環境変数の安全確認、緊急時のAttack Challenge Mode（Attack Mode）発動手順、そして無料プラン（Hobby）におけるログ保持期間の制約と調査の限界まで詳しく整理しました。

この記事で行うこと
前提条件・対象読者
1. Quick Reference：Vercel不正アクセス調査の優先度別早見表
2. Vercelで想定される代表的な3大侵害シナリオ
3. チーム・アカウント権限とGit連携の点検手順
1. 3-1. チームメンバーとロール（権限）の確認
  1. 確認すべきポイント
2. 3-2. 接続済みGit連携とOAuthトークンの点検
  1. Vercel側の確認
  2. GitHub側の確認
4. Deployments（デプロイ履歴）の検証手順
1. 4-1. デプロイ一覧の精査
  1. 確認すべきポイント
2. 4-2. CLIおよびAPI経由のデプロイ確認
  1. 確認すべきポイント
5. Runtime Logs（実行ログ）の追跡と異常検知
1. 5-1. Logs画面の開き方とフィルタリング
  1. 活用すべき検索・フィルタ条件
2. 5-2. ログから見つけるべき異常パターン
6. Environment Variables（環境変数）の点検と安全対策
7. 緊急防御：Attack Challenge Mode（Attack Mode）の発動
1. 7-1. Attack Challenge Modeの概要と効果
  1. 主な特徴とメリット
2. 7-2. 有効化の手順
8. プラン別のログ保持期間と調査の限界
1. 8-1. プラン別のログ保持期間の違い
2. 8-2. 個人開発・Hobbyプランにおける調査の限界と対策
  1. Hobbyプランで事後調査を行うための事前対策
9. よくある質問（FAQ）
10. まとめ
次に読むおすすめ記事
参考情報

この記事で行うこと

Vercel上で想定される代表的な3大侵害シナリオを理解する
チームメンバーとアカウントのアクセス権限を点検する
Deployments（デプロイ履歴）から不審なコミットやデプロイ元を特定する
Runtime Logsを活用して異常リクエストや関数乱用の痕跡を追跡する
Environment Variables（環境変数）の漏洩・改ざんリスクを点検する
接続済みGit連携（GitHub / GitLab / Bitbucket）の認証トークンを見直す
DDoSや課金攻撃時にAttack Challenge Modeを有効化してサイトを保護する
HobbyプランとProプランにおけるログ保持期間の違いと調査の限界を把握する

前提条件・対象読者

Vercelを利用してNext.jsや静的サイト、サーバーレス関数を個人でデプロイしている方
Vercelアカウントや連携先GitHubに不正アクセスの疑いがあり、調査を行いたい方
Vercel DashboardおよびGitHubの管理画面を操作できる方
最終確認日：2026年11月（Vercel公式ドキュメントに基づく）

1. Quick Reference：Vercel不正アクセス調査の優先度別早見表

異常を察知した直後は、被害の拡大（課金の急増・データの破壊）を食い止める緊急処置と、侵入経路・影響範囲の調査を並行して進める必要があります。

優先度	調査対象・作業項目	主な確認画面（ダッシュボード）	検出できる異常・目的
P1	緊急防御（Attack Mode）	Project ＞ Security ＞ Attack Mode	DDoS攻撃・スクレイピング・関数乱用の即時遮断
P1	デプロイ履歴の点検	Project ＞ Deployments	未知のコミットハッシュ、不正なブランチデプロイ
P1	環境変数の確認と無効化	Project ＞ Settings ＞ Environment Variables	APIキーの改ざん確認、漏洩キーの即時ローテーション
P2	チームメンバー・権限点検	Team Settings ＞ Members	未知のアカウント、不要な権限の残存
P2	Git連携・トークン確認	Account Settings / GitHub Authorized Apps	不正な連携アプリ、漏洩した個人アクセストークン
P2	Runtime Logsの追跡	Project ＞ Logs（またはDeployments ＞ Logs）	異常なHTTPステータス、特定エンドポイントへの集中
P3	ドメイン・DNSレコード点検	Project ＞ Settings ＞ Domains	サブドメインの不正追加、外部への向き先改ざん
P3	使用量・課金アラート確認	Usage ＞ Serverless Function Execution	予期せぬリクエスト数や帯域消費の発生日時特定

2. Vercelで想定される代表的な3大侵害シナリオ

Vercel自体は極めて安全なマネージドインフラストラクチャですが、連携しているGitHubやAPIキーの管理不備を突かれるケースが多発しています。

2-1. GitHubアカウント連携の悪用による不正デプロイ

VercelはGitリポジトリと密結合しています。攻撃者が個人のGitHubアカウントを乗っ取った場合、あるいはリポジトリに悪意あるコラボレーターを追加された場合、リポジトリにバックドアやフィッシング詐欺用のページをコミットされると、Vercelが自動的に検知して本番環境へ即座にデプロイしてしまいます。管理者は「Vercelがハッキングされた」と誤認しがちですが、根本的な侵入元はGitHub側の認証突破や個人アクセストークン（PAT）の流出であるケースが大半を占めます。

2-2. 環境変数（Environment Variables）の漏洩と悪用

Vercelのプロジェクト設定に登録されている環境変数には、データベースの接続文字列（DATABASE_URL）、OpenAIやAnthropicなどのLLM APIキー、Stripeの決済秘密鍵、AWSのクレデンシャルなどが保存されています。ソースコード内で誤って NEXT_PUBLIC_ プレフィックスを付けてクライアント側のJavaScriptバンドルに埋め込んでしまったり、チームメンバーの権限を過剰に付与していたりすると、外部の攻撃者にAPIキーを吸い出され、外部サービスで莫大な従量課金が発生します。

2-3. Serverless Function乱用によるDDoS・課金攻撃

Next.jsのAPI RoutesやServerless Functionsで、重い処理（AIモデルの呼び出し、画像の変換処理、データベースの全件スキャン等）を行うエンドポイントにレートリミット（回数制限）や認証をかけていない場合、攻撃者からスクリプトで数万回〜数百万回の連続リクエストを送りつけられます。 Vercelは負荷に応じて自動スケールするためサーバーダウンは防げますが、その結果としてServerless Functionの実行時間・メモリ消費・帯域幅が跳ね上がり、予期せぬ課金（Wallet-draining attack）に見舞われます。

3. チーム・アカウント権限とGit連携の点検手順

調査の初期段階として、「誰がこのプロジェクトにアクセスできる状態になっているか」を厳格に確認します。

3-1. チームメンバーとロール（権限）の確認

Vercelダッシュボードの左上から該当チームを選択し、「Settings」＞「Members」を開きます。

確認すべきポイント

チームメンバー一覧に見知らぬメールアドレスやユーザー名が存在していないか
既にプロジェクトを離脱した元共同開発者や業務委託のアカウントが放置されていないか
各メンバーのロール（Owner、Member、Developer、Billing等）が適切か（不要に強いOwner権限が付与されていないか）

不審なメンバーを発見した場合は、即座に「Remove」をクリックしてチームから除外します。

3-2. 接続済みGit連携とOAuthトークンの点検

VercelはGitHub等のOAuth連携を通じてコードを取得しています。侵入経路を断つために、連携設定を点検します。

Vercel側の確認

プロジェクトの「Settings」＞「Git」を開く
接続されているGitリポジトリ（Connected Git Repository）が正しい本物のリポジトリを指しているか確認する

GitHub側の確認

GitHubにログインし、右上のアイコン＞「Settings」＞「Applications」を開く
「Authorized GitHub Apps」（現行の標準連携）および「Authorized OAuth Apps」（旧連携やCLI認証）の両方を開いて「Vercel」の存在を確認する
「Vercel」アプリの権限とアクセス許可リポジトリが意図した範囲（特定リポジトリのみ等）に限定されているか確認する
「Personal access tokens」一覧を開き、用途不明なトークンや外部ツールに渡したままのトークンが存在する場合は直ちに失効（Revoke）させる

4. Deployments（デプロイ履歴）の検証手順

Vercelダッシュボードの「Deployments」タブは、侵害調査において最も重要な一次証拠となる画面です。

4-1. デプロイ一覧の精査

Deployments画面には、過去に実行されたすべてのビルドとデプロイが時系列で一覧表示されます。

確認すべきポイント

直近のProduction（本番）デプロイのコミットメッセージとコミットハッシュが、GitHubの main（または master）ブランチの最新コミットと完全に一致しているか
自分やチームメンバーがコミットしていない時間にデプロイが成功していないか
「Deployed by」の欄に表示されているユーザーが正規の開発者であるか
見覚えのないブランチ名（例: patch-1, update-deps, test-feature 等）からPreviewデプロイが大量に生成されていないか

4-2. CLIおよびAPI経由のデプロイ確認

VercelはGitプッシュだけでなく、Vercel CLI（vercel --prod）やDeploy Hook（特定のWebhook URLを叩くことでデプロイをトリガーする機能）からもデプロイが可能です。

確認すべきポイント

コミット情報が紐付いていないデプロイが存在しないか
プロジェクトの「Settings」＞「Git」＞「Deploy Hooks」に、見覚えのないWebhook URLが登録されていないか
不要なDeploy Hookが存在する場合は直ちに削除し、第三者が勝手にビルドをトリガーできないように遮断する

もし不正なデプロイが本番環境（Production）に適用されていた場合は、正常だった直近のデプロイを選択し、右上の三点リーダー（…）から「Promote to Production（または Instant Rollback）」を実行して、正常な状態へ即座にロールバックします。

5. Runtime Logs（実行ログ）の追跡と異常検知

Vercelの「Logs」機能を使用すると、Webアプリケーションが実際に受信したHTTPリクエストや、Serverless Function内で出力された console.log、エラー情報を調査できます。

5-1. Logs画面の開き方とフィルタリング

プロジェクトダッシュボードの上部メニューから「Logs」を開くか、特定のDeploymentを選択して「Logs」タブを開きます。

活用すべき検索・フィルタ条件

ステータスコード（Status）: 4xx（特に401 Unauthorized, 403 Forbidden, 404 Not Found）や5xx（500 Internal Server Error, 504 Gateway Timeout）で絞り込む
パス（Path）: 特定のAPIエンドポイント（例: /api/chat, /api/generate, /api/auth など負荷の高い関数）で絞り込む
ログレベル（Level）: ErrorやWarningで絞り込み、予期せぬ例外の発生を特定する
リクエストID（Request ID）: 不審なリクエストのヘッダーに含まれる x-vercel-id を用いて、前後の関数呼び出しを一連の流れとして追跡する

5-2. ログから見つけるべき異常パターン

同一IPからの高頻度リクエスト

短時間に数千件の同一IP（または同一User-Agent）からのリクエストが特定のAPI Routesに集中している場合、スクレイピングボットやDoS攻撃の標的になっています。

環境変数や設定ファイルを狙うパストラバーサルスキャン

ログのURLパスに以下のような文字列が含まれている場合、外部の自動スキャナーが脆弱性を探っています。

/api/.env
/.git/config
/wp-login.php
/actuator/gateway/routes

静的ホスティングやNext.jsの適切なルーティングが設定されていればこれらは404で返却されますが、もし200 OKで何らかのレスポンスが返されている場合は、ファイル配信設定の重大な不備を疑う必要があります。

実行時間のタイムアウト（504エラー）の連続発生

Serverless Functionが最大実行時間（Hobbyプランでは標準10秒〜60秒）をオーバーして強制終了されているログが多発している場合、外部APIの障害、または攻撃者から意図的に巨大なペイロード（ReDoS攻撃や重い計算処理）を送りつけられている可能性があります。

6. Environment Variables（環境変数）の点検と安全対策

環境変数が改ざんされたり盗まれたりすると、Vercelだけでなく接続先のデータベースや決済サービス、クラウド基盤まで侵害が拡大します。

6-1. 環境変数設定の点検手順

プロジェクトの「Settings」＞「Environment Variables」を開きます。

確認すべきポイント

登録されている環境変数のキー名に見覚えのないものが追加されていないか（例: 外部のログ転送先や未知のWebhook URLなど）
本番環境（Production）、プレビュー環境（Preview）、開発環境（Development）のスコープが適切に分離されているか
テスト用の秘密鍵が誤ってProductionに設定されていないか、またはその逆がないか

6-2. Sensitive Environment Variables（機密変数）の活用

Vercelでは、環境変数の安全性を高めるために「Sensitive Environment Variables」機能が提供されています。環境変数を追加または編集する際、機密設定（Secret / Sensitive）を有効にすると、保存後はダッシュボード上で値がマスクされ、復号された平文の値を閲覧できなくなります（書き込み専用状態）。これにより、万が一チームメンバーのアカウントが部分的に侵害されたり、画面共有等でダッシュボードが露出したりしても、APIキーそのものを盗み見られるリスクを大幅に低減できます。

6-3. 漏洩が疑われる場合の対応手順

もしAPIキーの流出が疑われる場合は、以下の手順で速やかにローテーション（鍵の再生成）を実施します。

キーローテーションの手順

外部サービス側（OpenAI, Stripe, Supabase, AWS等）で新しいAPIキーを発行する
VercelのEnvironment Variablesで該当する環境変数の値を新しいキーに上書き保存する
重要な仕様：環境変数を変更しただけでは、現在稼働中のデプロイには反映されません。「Redeploy」を実行して新しい環境変数を読み込ませたビルドを本番公開する
新しいデプロイで正常動作を確認した後、外部サービス側で古いAPIキーを完全に無効化（Revoke / Delete）する

7. 緊急防御：Attack Challenge Mode（Attack Mode）の発動

DDoS攻撃や悪意のあるボットによる大量アクセスが現在進行形で発生しており、Serverless Functionの呼び出し回数が異常な勢いで急増している場合は、Vercel Firewallの「Attack Challenge Mode」を直ちに有効化します。

7-1. Attack Challenge Modeの概要と効果

Attack Challenge Modeは、サイトへの全訪問者に対して自動的にセキュリティチャレンジ（JavaScriptチャレンジまたはCAPTCHA）を提示し、ボットによる自動アクセスを水際で遮断する機能です。

主な特徴とメリット

無料プラン（Hobby）を含むすべてのプランで追加料金なしで利用可能
Attack Modeによってブロックされたリクエストは、Vercelの使用量制限（Usage Limits）や課金対象にカウントされない
Googlebotなどの正規の検索エンジンクローラーや、Vercel内部のCron Jobs・サーバーレス関数呼び出しは自動的に許可（バイパス）されるため、SEOや内部処理への悪影響が最小限に抑えられる

7-2. 有効化の手順

Vercelダッシュボードで対象プロジェクトを開く
上部メニューの「Security」タブ（または「Settings」＞「Security」）を開く
「Attack Mode」のトグルスイッチをクリックして「ON」にする
トラフィックが正常に戻り、攻撃が終息したことを確認した後に「OFF」へ戻す

8. プラン別のログ保持期間と調査の限界

インシデント調査を進める上で、契約しているプランごとのログ保持期間の制約を理解しておく必要があります。

8-1. プラン別のログ保持期間の違い

プラン区分	標準のRuntime Logs保持期間	備考・拡張オプション
Hobby（無料プラン）	約1時間	1時間以上前の詳細リクエストログはダッシュボードから消失
Proプラン（標準）	約1時間	リアルタイム調査向け、長期保存は別オプション
Pro（Observability Plus）	最大30日間	連続14日分のクエリ・検索が可能（有料アドオン）
Enterpriseプラン	最大30日間〜無期限（Log Drains）	SIEM連携、外部ストレージへの完全アーカイブ可能

8-2. 個人開発・Hobbyプランにおける調査の限界と対策

個人開発で最も一般的なHobbyプランでは、Runtime Logsの保持期間がわずか1時間程度しかありません。したがって、「3日前に不正アクセスがあったかもしれない」「先週末に発生した不審なアクセスを調べたい」といった事後調査をVercel標準のログ画面から行うことはできません。

Hobbyプランで事後調査を行うための事前対策

SentryやDatadog、Logflare、Better Stackなどの外部監視サービスを連携させておく
Next.jsのミドルウェア（middleware.ts）内で、認証エラーや異常リクエストを外部のログ収集APIに送信する仕組みを実装しておく
Google Cloud LoggingやAWS CloudWatch等へのLog Drainsを設定しておく（※Log DrainsはPro以上の機能となる場合があるため、外部SaaSのSDK活用が現実的です）

9. よくある質問（FAQ）

Q1. Vercelの環境変数は、ブラウザの開発者ツールから盗まれることがありますか？

接頭辞に NEXT_PUBLIC_ が付いていない環境変数は、サーバーサイド（Serverless FunctionsやSSR）でのみ実行時に評価されるため、ブラウザ（クライアント側）のJavaScriptバンドルに含まれることはありません。ただし、コード内で console.log(process.env.SECRET_KEY) を記述してクライアントコンポーネントに渡してしまったり、API RoutesのレスポンスJSONに誤って環境変数を含めて返却していたりすると漏洩します。また、NEXT_PUBLIC_ が付いた変数はすべてビルド時にHTML/JSへインライン展開されるため、秘密鍵には絶対に NEXT_PUBLIC_ を付けてはいけません。

Q2. 不正なデプロイが行われた場合、過去のビルド成果物は削除できますか？

Deployments一覧から該当するデプロイメントの三点リーダー（…）をクリックし、「Delete」を選択することで特定のビルドを完全に削除できます。ただし、本番ドメイン（Production Domain）が割り当てられているアクティブなデプロイは直接削除できません。先に安全な過去デプロイへロールバック（Promote to Production）してから削除を行ってください。

Q3. VercelのAudit Logs（監査ログ）は無料プランでも見られますか？

「誰がいつ環境変数を変更したか」「誰がプロジェクト設定を変更したか」を正確に記録する詳細なAudit LogsおよびAudit Log Drainsは、主にEnterpriseプラン向けの機能です。HobbyプランやProプランでは、チーム全体の概要的なActivityフィードは確認できますが、詳細な監査証跡の追跡には制約があります。そのため、GitHub側のAudit Logや二要素認証（2FA）の徹底が重要になります。

Q4. 攻撃を受けてServerless Functionの課金が膨らみそうな場合の緊急停止方法はありますか？

プロジェクトの「Settings」＞「General」の最下部にある「Pause Project」を実行することで、プロジェクト全体のトラフィック処理を完全に一時停止できます。また、VercelのSpend Management（支出管理）機能を利用して、利用額が一定の閾値に達した際に自動でプロジェクトを一時停止するガードレールを設定しておくことが推奨されます。

Q5. GitHubの連携先が「Authorized OAuth Apps」ではなく「Authorized GitHub Apps」にあります。正常ですか？

はい、完全に正常です。むしろ「Authorized GitHub Apps」に存在するのが現在のVercelの標準仕様です。Vercelの公式連携（Vercel for GitHub）は、細粒度の権限管理が可能な「GitHub App」として提供されているためです。一方で、過去に連携したままのアカウントや、Vercel WebサイトへのGitHubログイン、Vercel CLI認証などを行っている場合は「Authorized OAuth Apps」側にも登録されます。不正アクセスの点検時には、念のため両方のタブを開いて見知らぬ認可が残っていないか確認することをおすすめします。