「Vercelを使えばそこそこ大規模なアプリケーションまでインフラエンジニア要らずにいけるのよな」——元Yahoo!エンジニアで YouTuber のしまぶー氏（@shimabu_it）のポストが話題になった。Vercel CEO の Guillermo Rauch 氏の投稿に対するコメントで、「しかも大抵の場合インフラエンジニアがAWSやGCPで構築したものより高機能、高可用性、高パフォーマンス」と踏み込んだ発言をしている。

Vercelが実現する「インフラレス」開発

Vercelは Next.js の開発元として知られるが、プラットフォームとしての本質は開発者からインフラの複雑さを隠蔽することにある。

Framework-defined Infrastructure（FdI）

Vercelが推進する Framework-defined Infrastructure は、Infrastructure as Code（IaC）の進化形だ。

従来のIaCでは、開発者がTerraformやCloudFormationでインフラを明示的に定義する必要があった。FdIでは、フレームワークのコードからインフラ構成が自動的に導出される。

  • ビルド時にソースコードを解析し、開発者の意図を理解
  • 必要なインフラ構成（Edge Functions、Serverless Functions、Static Assets、ISR設定など）を自動生成
  • 開発者は「何を作るか」に集中し、「どこにデプロイするか」を考える必要がない

Self-driving Infrastructure

Vercelは Self-driving Infrastructure というコンセプトも掲げている。本番環境の運用を自律的に管理し、実世界のインサイトを基にアプリケーションコードの改善まで行うというビジョンだ。

6人のエンジニアで年間360億トークンを処理

Vercelの「インフラ不要」の主張を裏付ける事例として、Durable社のケースが象徴的だ。

  • 6名のエンジニアチームで300万ビジネスをサポート
  • 年間360億トークン（日次1.1億トークン）を処理
  • 新しいAIエージェントを1日で本番環境に展開可能
  • 自社ホスティング比で3〜4倍のコスト削減

創業者は「インフラ構築ではなくエージェント開発に注力できるようになった」と評価している。

インフラエンジニアは本当に不要になるのか？

しまぶー氏は以前から「インフラエンジニアは二極化する」と指摘している:

  • 高待遇化: クラウドサービスの基盤自体を作れるエンジニア
  • 活躍の場が減少: アプリケーションのインフラを構築する程度のエンジニア

「基盤自体を作れるエンジニア」とは、VercelやAWSのサービスそのものを開発・運用する側のスキルセットを指す。具体的には以下のような領域だ:

  • 分散システム設計: AWS LambdaやVercel Edge Functionsの実行基盤を設計・構築するスキル
  • コンテナランタイム/オーケストレーション: Kubernetesを「使う」のではなく「作る・拡張する」レベル
  • ネットワーク基盤: CDN、ロードバランサ、DNSを大規模に設計・運用するスキル
  • ストレージエンジン: 分散データベースやオブジェクトストレージの内部実装
  • コンパイラ/ランタイム: サーバーレスプラットフォームのビルドパイプラインや実行環境の開発

つまり「AWS上にアプリをデプロイする」のではなく「AWSのようなサービスを作る」側の人材であり、このレベルのエンジニアはプラットフォームの進化によってむしろ需要が高まっている。

Vercelの基盤は何で動いているのか

「基盤を作る」とは具体的にどのレベルなのか。Vercel自身の技術スタックを見ると、その深さがわかる。

Vercelは当初 AWS Fargate でビルド処理を実行していたが、プロビジョニングに90秒かかる問題があった。そこで2023年に独自のコンピュート基盤「Hive」を構築し、起動時間を5秒に短縮した。

Hiveの技術スタックは以下の通りだ:

レイヤー技術
物理基盤ベアメタルサーバー（“Boxes”）
VM隔離Firecracker microVM + KVM
ビルド基盤Hive（独自コントロールプレーン）
関数実行AWS Lambda、Edge Functions
オーケストレーションAmazon EKS（一部）+ 独自制御
ストレージ/キューAmazon S3、SQS
ネットワークAmazon Global Accelerator

注目すべきは、OpenShiftのような既存のKubernetesディストリビューションは使われていない点だ。Firecracker はAWSがLambdaとFargateのために開発したオープンソースのmicroVMで、約300ミリ秒でVMを起動できる。Vercelはこの Firecracker + KVM の上に独自のオーケストレーション層を構築している。

KVM・コンテナ・OpenShift——レイヤーの違いを理解する

ここで「KVM」「コンテナ」「OpenShift」の関係を整理しておこう。これらは同じ「仮想化」でも、動作するレイヤーがまったく異なる。

物理サーバー（ベアメタル）
  └── KVM（ハイパーバイザー）← ハードウェア仮想化
        └── VM / microVM（Firecracker など）← OS レベルの隔離
              └── コンテナランタイム（containerd など）← プロセスレベルの隔離
                    └── Kubernetes / OpenShift ← コンテナオーケストレーション
  • KVM はLinuxカーネルに組み込まれたハイパーバイザーで、ハードウェアレベルの仮想化を提供する。物理マシン上に独立したVMを作る仕組みであり、コンテナ環境を用意するものではない
  • コンテナ（Docker等）はOSのカーネルを共有しつつプロセスを隔離する軽量な仮想化技術だ
  • OpenShift はKubernetesベースのコンテナオーケストレーションプラットフォームで、企業がコンテナを管理・運用するための製品だ

Vercelの Hive はKVM + Firecracker で直接 microVM を動かしており、コンテナやKubernetes/OpenShiftのレイヤーを経由していない。コンテナより下のVM隔離レベルでワークロードを実行することで、マルチテナント環境でより強いセキュリティ隔離を実現している。

つまり、OpenShiftは「Kubernetesを利用するためのプラットフォーム」であるのに対し、Vercelが構築しているのはKubernetesよりさらに下のレイヤー——microVMレベルからの独自コンピュート基盤だ。「基盤を作れるエンジニア」とは、まさにこのレベルの設計・実装ができる人材を指している。

KVM基盤はEC2上で動いているのか？

ここで一つ疑問が浮かぶ。Hiveの「ベアメタルサーバー（Boxes）」は通常のEC2インスタンス上で動いているのだろうか？

答えは通常のEC2ではない。通常のEC2インスタンスはそれ自体がAWS Nitroハイパーバイザー上で動くVMであり、その中でKVMを動かすと「ネスト仮想化」となってパフォーマンスが大きく落ちる。

通常のEC2の場合（ネスト仮想化 — 非効率）:
  AWS Nitro → EC2 VM → KVM → Firecracker microVM

ベアメタルの場合（直接仮想化 — 効率的）:
  物理サーバー → KVM → Firecracker microVM

Hiveが使用する「Boxes（ベアメタルサーバー）」は、以下のいずれかと考えられる:

  • AWSベアメタルインスタンス（m5.metal, i3.metal 等）: Nitroハイパーバイザーを介さず物理ハードウェアに直接アクセスできるEC2の特殊なインスタンスタイプ
  • 自社所有の物理サーバー: コロケーション施設に設置したVercel自前のハードウェア

どちらであるかは公開情報では明確にされていない。ただし、AWSベアメタルインスタンスであればAWSのデータセンターの信頼性とグローバル展開の恩恵を受けつつ、KVM/Firecrackerを直接動かせる。一方、自社ハードウェアであればコスト面で有利になる可能性がある。いずれにせよ、通常のEC2 VM上でKVMを動かしているわけではない。

Vercelが自前で構築する範囲とAWSに委ねる範囲

ではVercelはすべてをmicroVMで動かしているのかというと、そうではない。Vercelが独自構築しているのはコンピュート層（ビルド・実行）だけであり、ストレージやキューイングといったステートフルなサービスはAWSのマネージドサービスに依存している。

領域方式理由
ビルド処理自前（Hive / Firecracker microVM）高速起動・セキュリティ隔離が必要
Edge/Serverless関数AWS Lambda + 独自EdgeAWSの実績あるサーバーレス基盤を活用
ストレージAmazon S3データの永続性・冗長性はマネージドが合理的
キューイングAmazon SQSデプロイのスケジューリングに利用
ネットワークAmazon Global Acceleratorグローバルなエニキャストルーティング

ストレージをmicroVMで自前構築しないのは合理的な判断だ。S3はデータの永続性（99.999999999%の耐久性）と冗長性で実績があり、自前で同等の信頼性を実現するのは膨大なコストがかかる。Vercelは差別化できるコンピュート層に集中投資し、コモディティ化されたストレージやネットワークはAWSに委ねるという戦略を取っている。

この「どこを自前で構築し、どこを委ねるか」の判断こそ、基盤を設計するエンジニアに求められるスキルの一つでもある。

一方で、反対の見方もある。2024年から2025年にかけてインフラエンジニアの求人は1.5倍に増加し、SREやクラウドアーキテクトは年収1,000万円を超えるポジションが増えているというデータもある。

Vercelが「不要」にするもの、しないもの

Vercelが代替するもの依然として必要なもの
CDN/Edge の設定・運用マルチクラウド戦略の設計
SSL証明書の管理オンプレミス・ハイブリッド環境
CI/CDパイプライン構築データベースのチューニング
DDoS対策・WAFコンプライアンス要件への対応
スケーリング設定コスト最適化の全体戦略
サーバーレス関数の配置ベンダーロックイン回避の判断

Vercelが不要にするのは「アプリケーションレイヤーのインフラ運用」であり、より深いレイヤーのインフラ設計・運用は引き続き専門性が求められる。

まとめ

Vercelのようなプラットフォームの進化により、「Next.jsアプリをAWSにデプロイするためにインフラエンジニアを雇う」という選択肢は合理性を失いつつある。しかし、大規模な組織ではマルチクラウド戦略、データ主権、コスト管理など、プラットフォームだけでは解決できない課題が残る。

「インフラエンジニア不要」ではなく「インフラエンジニアの役割が変わる」——それが現在起きていることの本質だろう。