Vercelのセキュリティ事件で、自分の設定を見直した話

2026年4月、Vercelからメールが届いた。

セキュリティインシデントがあったこと、そして「あなたの認証情報や個人データが侵害されたと考える根拠はない」という内容だった。

実害はない。でも、なんとなく気持ち悪い。そして「一応、確認しておくか」と開いたダッシュボードで、自分の設定の甘さに気づいた。

何があったのか

今回の件の起点は、Vercel社員が使っていた Context.ai というAIツールだった。その社員が会社のGoogleアカウントに広く権限を与えてサインアップしており、そこを経由して内部システムへのアクセスが広がったとされている。

ここで焦点になったのが、Sensitive指定されていない環境変数だ。

Vercelの説明によれば、Sensitive指定されていない環境変数にはアクセスされた可能性があるが、Sensitive指定済みのものにアクセスされた証拠はないとのことだった。

「Sensitive」って何のこと？

Vercelの環境変数には、通常モードとSensitiveモードの2種類がある。

通常の環境変数は暗号化されているが、ダッシュボードから値を読み取れる。プロジェクトにアクセスできれば、APIキーもパスワードも表示できる状態だ。

Sensitiveに設定すると、保存後は誰も値を読み取れなくなる。ビルド時にはコードに渡されるが、画面上には二度と表示されない。

問題は、Sensitiveはデフォルトでオフなことだ。自分で設定しないかぎり、保護されない。

正直に言うと、自分のプロジェクトでもほぼ全ての環境変数がSensitive指定になっていなかった。「暗号化はされているから大丈夫」と思っていた。「暗号化されている」と「読み取れない」は別物だ、と今回改めて気づいた。

私がやったこと

Vercelのメールには「直接の被害はない」とあった。それでも気持ち悪いので、ローテーション作業を進めた。

最初に動いたのは Claude API キーだ。課金に直結するため、これだけはすぐに差し替えた。

次に Supabase。今回とは直接関係ないが、ダッシュボードを開いたついでに確認すると、Legacy API key（旧来のJWT形式）をそのまま使っていた。Supabaseはすでに新しい形式（sb_publishable_... / sb_secret_...）への移行を推奨しており、これを機に更新した。

最後に Vercelの環境変数を全体的に見直し、シークレットを含む変数をSensitive指定に変更した。

マネージドサービスと、AIをめぐる状況

今回の件を通じて、もう一つ考えさせられたことがある。

VercelのようなマネージドサービスはDXが優れており、スモールプロジェクトにとっては非常に便利な選択肢だ。しかしその便利さの裏返しとして、プラットフォーム側で問題が起きると、利用者全員が同時に影響を受けるリスクがある。今回自分への実害はなかったが、数百万のプロジェクトが同じインフラを共有しているという事実は、改めて意識しておく必要がある。

そして、AIをめぐる状況として別の話も頭に浮かんだ。

Anthropicが開発した Claude Mythos は、「攻撃力が高すぎる」として一般公開を見送られ、政府機関や約40の組織に限定公開されたモデルだ。テスト中に主要なOSやブラウザの数千件の高深刻度の脆弱性を発見・悪用できることが示されたためだという。公開すら見送られるほどの能力を持つモデルが存在する一方で、AIの悪用というリスクは今後も多様な形で増えていくと考えたほうがいい。

開発者個人レベルでできることは限られている。それでも、「設定を正しく、シークレットを守る」という基本を怠らないことが、最初の防衛線になる。

事件の副産物

セキュリティインシデントは、もちろんないほうがいい。

ただ、今回のことがなければ、自分はSensitive設定のことをあまり深く考えずに運用を続けていたと思う。Claude APIキーもSupabaseのキーも「動いているから触らない」状態だった。

インシデントの副産物として、既存のセキュリティを棚卸しする機会ができた。それは素直によかったと思っている。

まだ自分のVercelの設定を確認していない人がいれば、一度ダッシュボードを開いてみるといいかもしれない。