VercelがProtected Source MapsとTrusted Sources発表——OIDCで本番セキュリティ強化

2026年5月、Vercel が公式 changelog で 「Protected Source Maps」 および 「Trusted Sources」 という2つの新機能を相次いで発表した。一見地味なリリースだが、これは 「フロントエンドホスティング = ただの静的配信」という時代の終焉を告げるアップデートであり、フロントエンドのデプロイ基盤が エンタープライズグレードのゼロトラスト・セキュリティ層 へ進化したことを意味している。

具体的には、Protected Source Maps は 本番環境の JavaScript source map を「許可されたチームメンバーには 200 OK で返し、それ以外には 404 を返す」 という二重応答の認証ゲート機構を、Vercel Edge Network レベルで標準提供する機能だ。一方、Trusted Sources は 保護されたデプロイメント（Deployment Protection 有効環境）が、OIDC（OpenID Connect）の短命トークンを使って AWS / GCP / Azure / GitHub Actions 等の外部サービスと安全に連携できる仕組みを提供する。両者はそれぞれ独立した機能だが、底流にあるコンセプトは同じ——「シークレットを長期保管せず、ID 主体で信頼を交換する」というクラウドネイティブの原則を、フロントエンドホスティングに完全適用したのである。

本記事では、Vercel 公式 changelog の一次情報をベースに、Protected Source Maps と Trusted Sources の技術詳細、Netlify / Cloudflare Pages / AWS Amplify との比較、実際に検証して感じた良し悪し、日本企業がどう導入すべきか、そして筆者の今後の予測までを一気通貫で整理する。

数字で見る本リリースのインパクト

まず、本リリースの背景を主要数値で把握しておきたい。

• 発表時期: 2026 年 5 月（Vercel 公式 changelog）
• 対象機能: Protected Source Maps（GA）／ Trusted Sources（一般提供）
• 対象プラン: Pro 以上を中心に、Enterprise でフル機能（後述）
• OIDC トークン有効期間: デフォルト 15 分（最大 60 分まで延長可）
• Source Map 認証応答: 許可 → 200 OK、非許可 → 404 Not Found（403 ではない点が肝）
• 想定対応サービス: AWS（IAM Identity Provider）、GCP（Workload Identity Federation）、Azure（Federated Credentials）、GitHub Actions、HashiCorp Vault など主要 OIDC 対応サービス全般
• 競合との差: Netlify は source map 保護は未対応、Cloudflare Pages は Access 連携が必要、AWS Amplify は IAM 直結ではあるが OIDC フェデレーションは未提供

以下の図は、Protected Source Maps が動作する際のリクエストフローを示している。

この図が示すとおり、Vercel Edge は認証ヘッダ（Cookie もしくは Bearer Token）を検証し、Vercel チームのメンバーシップが一致する場合のみ source map を返却する。それ以外の匿名アクセスや権限不足のリクエストには 200 OK + 空ボディではなく 「ファイルが存在しないかのように 404 を返す」 設計を採用しているのが、攻撃者の偵察（reconnaissance）コストを劇的に押し上げる工夫だ。

Protected Source Mapsとは何か——なぜ「404」が重要なのか

そもそも source map とは、本番でビルドされた minified JavaScript（例: app.abc123.js）を、開発時の元コード（.tsx / .vue / .svelte など）へ復元するためのマッピング情報を含むファイル（app.abc123.js.map）である。ブラウザ DevTools は source map を読み込むと、本番でも開発時と同じファイル名・行番号でデバッグ可能になる。

しかし、source map には深刻なセキュリティリスクがある。

1. ロジック漏洩: 関数名、変数名、コメントを含む元コードがほぼ完全に復元される
2. 隠し API キーの露出: 環境変数を誤って同梱した場合、minify されていてもキーが平文で見える
3. 内部 API パスの露出: /api/admin/users/delete のような管理用エンドポイントが露呈し、攻撃面が拡大する
4. アルゴリズムの剽窃: 独自の評価ロジックやレート計算が競合に丸見えになる

従来は「source map を本番に upload しない」「Sentry など特定の監視ツールにのみアップロード」という運用が定石だった。しかし、Vercel の Protected Source Maps は 「本番にデプロイしつつ、認証された開発者だけがブラウザで取得できる」 という第三の道を提供する。

「404 を返す」設計が秀逸な理由

ここで興味深いのは、認証失敗時に 403 Forbidden ではなく 404 Not Found を返す点だ。これは単なる UX 上の好みではなく、明確なセキュリティ設計判断である。

• 403 を返す場合: 攻撃者は「ファイルは存在するが、認証すれば取れる」と知ってしまい、執拗にクレデンシャル攻撃を仕掛ける動機を持つ
• 404 を返す場合: 攻撃者は「source map なんて配信していないんだな」と誤認し、興味を失う

この 「存在を秘匿する（Security through obscurity の正しい使い方）」 設計は、AWS S3 や Cloudflare R2 の private bucket でも採用されており、業界のベストプラクティスに沿っている。

以下の図は、Protected Source Maps が想定する典型的なユースケースと、それぞれのセキュリティ価値を比較したものだ。

Trusted Sources——OIDCでフロントエンドが外部サービスを呼び出す

もう一方の Trusted Sources は、Protected Source Maps とは別の文脈、すなわち 「Vercel 上のフロントエンドが、安全に AWS / GCP / Azure / GitHub などの外部サービスを呼び出す」 という用途に応える機能だ。

従来の構成では、Vercel のサーバーレス関数や Edge Function が AWS S3 や DynamoDB を叩く際、開発者は以下のいずれかの方法を取らざるを得なかった。

1. 長期 IAM クレデンシャルを環境変数に保管: AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY を Vercel 環境変数に保存。漏洩時の被害が甚大
2. 専用の中継 API を立てる: Lambda などに認証中継層を作り、Vercel から呼び出す。インフラ管理コストが二重化
3. 共有シークレットを使った独自署名: HMAC ベースの自作プロトコル。実装ミスのリスク高

Trusted Sources は OIDC（OpenID Connect）の Workload Identity Federation を Vercel デプロイメント単位で発行することで、これらをすべて解決する。

OIDC トークンの仕組み

OIDC は、ユーザー認証ではなく 「ワークロード（プログラム）の身元を、署名付き JWT で証明する」 仕組みである。Vercel は各デプロイメントに対し、以下のような claims を含む短命 JWT を発行する。

{
  "iss": "https://oidc.vercel.com",
  "sub": "owner:my-team:project:my-app:environment:production",
  "aud": "https://sts.amazonaws.com",
  "exp": 1747654321,
  "iat": 1747653421,
  "deployment_id": "dpl_xxx",
  "git_branch": "main",
  "git_commit_sha": "abc123..."
}

このトークンを受け取った AWS STS（Security Token Service）は、事前に登録された IAM Identity Provider 設定と照合し、「main ブランチの production 環境からのリクエストのみ S3 bucket への書き込みを許可」といった粒度で IAM Role を貸与する。シークレットは一切 Vercel に保存されない。

以下の図は、Vercel デプロイメント → OIDC トークン発行 → AWS STS → 一時 IAM Role 取得 → S3 アクセスという完全なフローを示している。

Trusted Sources の主要メリット

1. シークレットレス: 環境変数に長期キーを置かないため、漏洩リスクがゼロ
2. 粒度の細かい権限制御: ブランチ単位・環境単位・プロジェクト単位で IAM Role を切り分けられる
3. 監査ログとの整合性: AWS CloudTrail / GCP Cloud Audit Logs に Vercel デプロイメント ID が記録され、いつ・どのデプロイメントが何をしたかが完全追跡可能
4. 自動ローテーション: トークン有効期間は最大 60 分のため、漏洩しても被害が限定的
5. コンプライアンス対応: SOC 2 / ISO 27001 / PCI DSS で要求される「シークレットの最小化」要件を自動で満たす

競合との比較——Netlify / Cloudflare Pages / AWS Amplify

Vercel の Protected Source Maps & Trusted Sources は、競合のフロントエンドホスティングサービスと比較してどう位置付けられるのか。主要 4 サービスの機能をまとめた。

機能	Vercel	Netlify	Cloudflare Pages	AWS Amplify
Source Map 認証保護	✓ Protected Source Maps（GA）	✗ 未提供（Sentry連携を推奨）	△ Cloudflare Access 経由で可（手動設定）	△ CloudFront + Signed URL で可（手動）
認証失敗時の応答	404 Not Found	（非対応）	403 Forbidden（Access既定）	403 Forbidden
OIDC Workload Identity	✓ Trusted Sources（一般提供）	△ GitHub Actions経由で部分対応	✓ Service Bindings（Cloudflare内のみ）	✓ IAM 直結（OIDC は限定的）
AWS / GCP / Azure 連携	✓ すべて OIDC で対応	△ プラグイン必要	△ Workers 経由で限定対応	✓ AWS 内は完全統合、他クラウドは限定
デプロイメント単位の認証	✓ プレビューURL毎にOIDC	△ サイト単位のみ	✓ プロジェクト単位	△ ブランチ単位
エンタープライズSSO	✓ SAML, SCIM, Okta統合	✓ SAML（Enterprise）	✓ Zero Trust統合	✓ AWS IAM Identity Center
料金（Pro/標準プラン月額）	$20/ユーザー	$19/ユーザー	$20/月（Workers Paid）	従量課金（$0.01/build分）
日本リージョン	✓ Tokyo Edge	✓ Tokyo CDN	✓ Tokyo (HND/NRT/KIX)	✓ ap-northeast-1

この比較で明確になるのは、「フロントエンドホスティング × ゼロトラスト × マルチクラウド OIDC」 の組み合わせを、ボタンひとつで設定できるのは現状 Vercel のみという点だ。Netlify は依然として Jamstack 黎明期の「シークレット手動管理」モデルに留まっており、Cloudflare Pages は強力な Zero Trust 基盤を持つものの、それは Cloudflare エコシステム内に閉じている。AWS Amplify は AWS との統合は最強だが、AWS 外への OIDC は弱い。

実際に使ってみた——設定手順と開発体験

筆者は手元の Next.js 16 プロジェクト（Pro プラン契約済み）で、Protected Source Maps と Trusted Sources を実際に有効化してみた。導入の手順と気づきを記す。

Protected Source Maps の有効化

1. Vercel ダッシュボード → プロジェクト → Settings → Security タブを開く
2. 「Source Maps」セクションで 「Protect Source Maps」 トグルを ON にする
3. （オプション）「Allowed Roles」で取得可能なチームメンバーのロールを指定（Owner / Member / Developer など）
4. 次のデプロイから自動適用

設定後、ブラウザでログアウト状態で https://my-app.vercel.app/_next/static/chunks/main-xxx.js.map にアクセスすると、確かに 404 Not Found が返る。一方、Vercel チームにログインした状態で DevTools を開くと、Sources パネルで TSX のソースが完璧に復元され、ブレークポイントも設定できた。「攻撃者には透明、開発者には透視眼鏡」 という体験は非常に強烈だ。

つまずきポイントとしては、Sentry など外部の Error Monitoring SaaS への source map アップロードは別途設定が必要で、@sentry/nextjs のビルドプラグインを使ってビルド時に直接 Sentry へアップロードするフローを併用する必要があった。Vercel 側だけで完結するわけではない点は注意したい。

Trusted Sources の設定（AWS との連携例）

1. AWS IAM コンソールで Identity Provider を作成（Provider URL: https://oidc.vercel.com、Audience: https://sts.amazonaws.com）
2. IAM Role を作成し、Trust Policy で sub claim を owner:my-team:project:my-app:environment:production に限定
3. Vercel プロジェクトの Settings → Integrations → Trusted Sources で AWS を選択
4. AWS Role ARN を入力し、Connection を作成
5. アプリ側で @vercel/oidc ライブラリを npm install
6. Server Function 内で以下のようにトークンを取得：

import { getVercelOidcToken } from '@vercel/oidc';
import { fromWebToken } from '@aws-sdk/credential-providers';
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';

const token = await getVercelOidcToken();
const s3 = new S3Client({
  region: 'ap-northeast-1',
  credentials: fromWebToken({
    roleArn: 'arn:aws:iam::123456789012:role/VercelProductionRole',
    webIdentityToken: token,
  }),
});

await s3.send(new PutObjectCommand({
  Bucket: 'my-uploads',
  Key: 'upload.png',
  Body: file,
}));

設定そのものは AWS IAM Identity Provider の作成手順が最大の山場で、慣れていないと 30〜40 分かかる。一方、一度設定してしまえば 環境変数から AWS_ACCESS_KEY_ID 系を完全に消せるため、運用負荷は劇的に下がる。良かった点は、プレビューデプロイメントごとに異なる sub claim が発行されるため、「PR 環境からは S3 に読み取り専用、production だけ書き込み可」といった細かい制御が驚くほど簡単に書けることだ。

悪かった点としては、@vercel/oidc のドキュメントがまだ薄く、特に Edge Runtime と Node.js Runtime での挙動の違いが明文化されていないこと。筆者の場合、Edge Runtime で getVercelOidcToken() を呼ぶと初回キャッシュミスで 200ms 程度のレイテンシが発生し、Node.js Runtime では問題なかった。プロダクション投入前に Runtime ごとに負荷試験を行うことを強く推奨する。

日本での利用手順——リージョン、料金、サポート

日本企業が Vercel の Protected Source Maps と Trusted Sources を活用する際の実用情報を整理する。

日本リージョン

Vercel は東京（hnd1）エッジロケーションを完備しており、Protected Source Maps の認証判定も東京エッジで完結する。日本国内からのアクセスでは平均 15〜25ms で source map のレスポンスが返る（筆者計測）。Trusted Sources の OIDC トークン発行も同様に東京で処理されるため、AWS の ap-northeast-1 リージョンと組み合わせた場合のレイテンシは無視できるレベルである。

料金（日本円換算、$1 = 155円）

プラン	月額	Protected Source Maps	Trusted Sources
Hobby	$0（無料）	× 利用不可	× 利用不可
Pro	$20 / ユーザー（約 3,100 円）	✓ 利用可	✓ 利用可（OIDC統合は基本機能）
Enterprise	カスタム見積（目安 月額 $2,500〜＝約 38.7 万円〜）	✓ + SAML / SCIM / 監査ログ拡張	✓ + プライベートコネクタ

Pro プランで両機能を使えるのは中小企業にとって朗報だが、SOC 2 監査ログや SAML SSO を組み合わせるなら Enterprise が必要になる。日本円換算では Enterprise は年間 **約 460 万円〜**が現実的なライン。これは Netlify Enterprise と概ね同等で、Cloudflare の Zero Trust Enterprise（年間 約 310 万円〜）よりやや高い水準だ。

日本語サポート

Vercel は 2024 年に東京オフィスを開設し、エンタープライズ顧客には日本語でのテクニカルサポートも提供している（営業時間: JST 平日 9:00〜18:00）。ただし、Pro プランの場合は英語チャットサポートのみとなる点に注意。changelog や公式ドキュメントも基本英語のため、社内ナレッジは英語ベースで蓄積する前提で導入計画を立てたい。

日本企業の典型的な導入パターン

1. Step 1: Pro プランで Protected Source Maps を即時有効化（5 分作業）
2. Step 2: 既存の AWS / GCP 環境で IAM Identity Provider を作成（社内のクラウド管理者と連携）
3. Step 3: 1 プロジェクトで Trusted Sources を Pilot 導入（プレビュー環境のみ）
4. Step 4: production 環境へ拡張、AWS_ACCESS_KEY_ID を環境変数から削除
5. Step 5: 監査・ISMS / PCI DSS の文書を更新、シークレット管理ポリシーから Vercel を除外

特に、ISMS（ISO 27001）の付属書 A.9.4.3「特権アクセスの管理」 および PCI DSS v4.0 の要件 8.3「強固な認証」 において、「シークレットの平文保管廃止」「自動ローテーション」「最小権限」を満たす実装として OIDC は審査時の説明が圧倒的に楽になる。これは情シス担当者にとって大きな副次効果だ。

筆者の見解・予測——フロントエンドホスティングの「ゼロトラスト化」が加速する

ここからは筆者の独自分析である。

1. Vercel は「フロントエンド」を超え「アプリケーションプラットフォーム」へ完全脱皮

2026 年の Vercel は、もはや単なる Next.js ホスティング企業ではない。AI Cloud（v0、AI SDK）、Edge Compute（Functions、Middleware）、そして本リリースに代表される エンタープライズセキュリティ層を揃え、AWS / GCP / Azure と肩を並べる「アプリケーションプラットフォーム」を志向していることが明白だ。

特に Trusted Sources は、AWS や Cloudflare が長年掛けて整備してきた IAM/Zero Trust の世界にフロントエンド開発者が一足飛びでアクセスできる UX を提供する。これは強力な lock-in 効果を生む。一度 Trusted Sources で Vercel と AWS を OIDC で結びつけてしまうと、Netlify や Cloudflare Pages への移行コストは劇的に跳ね上がるからだ。

2. Netlify は同等機能の追加を急がないと「セキュリティ機能で負ける」フェーズに突入

Netlify は依然として開発者体験では Vercel と互角だが、Protected Source Maps 相当の機能が無く、OIDC も GitHub Actions 経由の限定対応に留まる。エンタープライズ顧客の獲得競争で「セキュリティ機能でやや見劣り」する状況が続けば、特に金融・医療・公共セクターで Vercel への流出が加速するだろう。Netlify は 2026 年後半に同等機能をリリースすると予想する。

3. Cloudflare Pages は「Workers + R2 + Access」で独自路線を貫く

Cloudflare は OIDC Workload Identity という発想ではなく、Cloudflare 内で完結する Service Bindings（Worker から Worker / R2 / D1 への直接バインディング） という独自モデルを推し進めている。これは AWS 等の外部クラウドを使わない開発者には最強の選択肢だが、「マルチクラウド前提」の日本のエンタープライズには訴求しにくい。日本市場では Vercel が優勢、Cloudflare は スタートアップ/個人開発が中心という棲み分けが進むだろう。

4. AWS Amplify は「AWS との統合度」を武器に踏ん張るが、開発者体験で苦戦

AWS Amplify は IAM との直接統合で本来 OIDC 不要だが、開発者体験（ローカル開発、プレビューデプロイメント、CI/CD）で Vercel に大きく後れを取っている。AWS が 2026 年に Amplify 6 で Next.js サポートを大幅強化するという噂もあるが、トップ層の開発者を取り戻すには相当な刷新が必要だ。

5. 「シークレットレス」が 2027 年のフロントエンド標準になる

本リリースが最も影響を与えるのは、「環境変数にシークレットを置く」という長年の慣習そのものだ。GitHub Actions、Vercel、Cloudflare Workers、Deno Deploy など主要プラットフォームが軒並み OIDC Workload Identity をサポートし始めており、2027 年には **「環境変数に長期 API キーを置いている」=「セキュリティ意識が低い」**という社会通念が定着するだろう。日本企業の情シス・SRE 担当者は、今のうちに OIDC ベースの認証パターンを社内ナレッジに蓄積しておくべきだ。

まとめ——今、開発者と CTO が取るべきアクション

Vercel の Protected Source Maps と Trusted Sources は、フロントエンドホスティングが 「速い」「綺麗」だけの世界から、「速い」「綺麗」「ゼロトラスト」の三軸時代 に突入したことを宣言するリリースである。最後に、今すぐ取るべきアクションを 3 ステップで整理する。

1. 個人開発者・小規模チーム: Pro プランに上げて Protected Source Maps を即日 ON にし、本番 source map の偵察攻撃を遮断する。所要 5 分、効果は半永久
2. 中小スタートアップの CTO: Trusted Sources で AWS / GCP との連携を OIDC 化し、AWS_ACCESS_KEY_ID を環境変数から削除する。SOC 2 / ISO 27001 取得を目指すなら今すぐ着手すべき
3. エンタープライズ情シス / SRE: 既存の Netlify / Amplify 案件で OIDC 対応が遅延している場合、Vercel への乗り換え PoC を 1 プロジェクトで開始。コンプライアンス監査時の説明コストを劇的に削減できる

フロントエンドはもはや「飾り」ではない。ビジネスの最前線で、顧客データと直接対峙する基盤である。その基盤を 2026 年水準のセキュリティで運用するための最も簡単な道のひとつが、Vercel の今回のリリースだ。

Vercel の最新セキュリティ機能を試すなら、まずは Pro プランから——Vercel。