VercelがDockerfileを受け入れた日 ― 「PaaSの逆襲」とエージェント実行基盤への布石任意Dockerfile対応が示すもの ― 導入判断と監査の論点
目次
要旨................................................................................... 3
第1章 これまでのVercel ― フレームワーク定義型............... 3
第2章 何ができるようになったのか ― ............................... 4
第3章 「バックエンドのVercel化」ではなく 5
第4章 向くワークロード・向かないワークロード. ....... 6
第5章 クライアント側の現実 ― ローカルDockerのメモ....... 7
第6章 セキュリティと監査 ― 本丸はサプライチェーン.......... 8
第7章 サーバーサイドJavaScriptというアナロジー 10
第8章 V8への一極依存と次世代エンジン構想（仮称「V12」）.. 13
第9章 「PaaSの逆襲」の一歩先 ― Agentic Infrastructure... 15
第10章 導入判断のためのチェックリスト.............................. 15
第11章 段階的採用のロードマップ........................................ 16
まとめ.................................................................................. 17
要旨
2026年6月30日、Vercelが「任意のDockerfileをそのままデプロイできる」機能を発表した。Dockerfile.vercel というファイルをプロジェクトに置くだけで、HTTPで待ち受ける任意のコンテナを、Vercel上でビルド・保存・デプロイ・自動スケールまで一貫して扱えるようになる。Go、Rails、Spring Boot、Express、Laravel、ASP.NET、FastAPI、nginx配下のWebサーバーなど、これまでVercelの「土俵」に乗りにくかったスタックが、同じやり方で動かせる。
この変化は、表面的には「Vercelでバックエンドが動くようになった」という機能追加に見える。しかし本質は二段構えである。第一に、これは「バックエンドのVercel化」ではなく「バックエンド運用のフロントエンド化」だ。第二に、その先には「フロントエンド配信基盤から、エージェントを動かす実行基盤（Agentic Infrastructure）へ軸足を移す」という、より大きな戦略が透けて見える。
一言でまとめれば「PaaSの逆襲」である。Kubernetesを直接触らせず、Dockerfileだけを入口にして、裏側のビルド・レジストリ・スケール・URL発行を全部吸収する。便利だが、便利すぎるものほど、責任と可視性の境界線を見失うと危うい。本稿では、何が変わったのかを整理した上で、向くワークロードと向かないワークロード、そしてセキュリティと監査の観点から、この機能を実運用に乗せる前に押さえるべき論点を通して読む。
次世代JavaScriptエンジン構想（仮称「V12」）
V8への一極依存を超えて ― AIエージェント時代に、ケイパビリティと可監査性を構造として備えるために
目次
要旨（エグゼクティブ・サマリー）............................................ 3
第1章 背景 ― なぜいま、エンジンを問い直すのか.................. 3
第2章 問題の所在 ― V8モノカルチャーと「既定で全開」....... 4
第3章 提言の核心 ― 仮称「V12」とは何か、何でないか........ 4
第4章 比較表：V8の既定 ⇄ V12の反転.............................. 5
第5章 設計目標の詳細........................................................ 6
第6章 AIバイブ開発との架橋 ― テキスト交換を「意図・実行・証跡」の回路にする.................. 7
第7章 想定される反論と応答............................................... 10
第8章 実現への道筋 ― 誰が、どこから作るか....................... 11
第9章 結び ― ひとつの警鐘................................................. 11
要旨（エグゼクティブ・サマリー）
現代の実行基盤の多く ―― Node.js、Deno、Chromium系のエッジ実行環境（Workers等）、そして異種バックエンドを吸収していくプラットフォーム ―― は、その最下層でGoogleのV8エンジンに支えられている。BunがAppleのJavaScriptCore（JSC）を採るなどの例外はあるが、V8系への重力は依然として圧倒的であり、しかもその主要な代替であるJSCもApple一社のエンジンで、多主体で統治されるエンジンは事実上存在しない。本資料は、この単一ベンダーへの重力と、V8が抱える「既定で全開」という設計姿勢を問い直し、次世代エンジン（仮称「V12」）が満たすべき五つの設計目標を、V8の既定との対比で提示する提言である。
先に断っておく。「V12」は現時点で存在せず、特定製品の予告でもない。これは、いずれ誰かが作らねばならないであろうエンジンの要件を、思考実験として言語化した警鐘である。要点はひとつ ―― 能力（速度・機能）と統治（権限・監査・独立性）を混同しないこと。V8はすでに十分に速い。律速はそこにない。真に不足しているのは、統治と可監査性という別種の“馬力”である。
そしてこの提言は、抽象的な将来論ではない。AIエージェントがCLI、すなわちテキストで機械速度・機械量のコマンドを吐く「バイブ開発」の時代において、実行環境が「既定で全開」であることは、看過できない急所になる。「V12」は、まさにこの文脈でこそ“あれば良いもの”から“なければ困るもの”へと変わる（詳細は第6章）。
