VercelがNode.js 20を非推奨化、10月1日から新規デプロイ不可に
VercelにおけるNode.js 20非推奨の概要
Vercelは2026年10月1日をもって、ビルドおよびFunctionsにおけるNode.js 20のサポートを終了する。これは2026年4月30日にNode.js 20がEOL（End of Life / サポート終了）を迎えたことを受けた動きだ。
Node.jsの各バージョンにはライフサイクルが定められている。長期サポート（LTS）が終了すると、セキュリティパッチの提供も停止される。Vercelがプラットフォームとして非推奨とするのは、ユーザーに安全で最新の実行環境を提供し続けるための当然の判断といえる。
この変更で影響を受けるのは、Node.js 20を指定している新規デプロイメントだ。既にデプロイ済みのサーバーレス関数は、その後も問題なく動作し続ける。
上図の通り、Node.js 20を指定したプロジェクトは、10月1日を境に新規デプロイができなくなる。Node.js 22または24への移行が必須だ。
なぜNode.js 20は非推奨となるのか
Node.js 20のLTSは2026年4月30日に終了した。LTS終了後は重大な脆弱性が見つかっても公式の修正は行われない。VercelのようなPaaS（サービスとしてのプラットフォーム）がEOLバージョンをサポートし続けることは、プラットフォーム全体のセキュリティリスクを高める。
実際、Node.jsのEOL後も古いバージョンを使い続けると、依存パッケージの互換性問題やパフォーマンス低下にもつながる。Vercelのこの方針は、ユーザーに対して積極的なアップグレードを促すための健全な措置だ。
影響を受けるプロジェクトの確認方法
まず最初に、自分が管理するVercelプロジェクトのうち、どれが今回の非推奨の影響を受けるかを確認する必要がある。Vercel CLIを使えば、コマンド一発で該当プロジェクトの一覧を取得できる。
最新のVercel CLIをインストールし、以下のコマンドを実行するだけだ。
npm i -g vercel@latest
vercel project ls --update-requiredこのコマンドは、非推奨のNode.jsバージョンをターゲットにしているプロジェクトの一覧を表示する。出力結果にプロジェクトが表示された場合、早急な対応が必要だ。
このフローで影響範囲を可視化できる。チームで複数のプロジェクトを運用している場合、全メンバーがこの確認を共有しておくとスムーズだ。
既存のデプロイメントは安全
ここで一つ重要なポイントがある。2026年10月1日以降も、既にデプロイ済みのサーバーレス関数は影響を受けない。すでに本番環境で稼働している関数への呼び出しは、これまで通り正常に動作する。
非推奨の影響が出るのは、あくまで新しいデプロイメントを作成するときだ。既存の環境が突然停止することはないため、慌てて不完全な状態でアップグレードする必要はない。計画的に移行を進められる。
Node.jsバージョンのアップグレード手順
Node.jsのバージョンを変更する方法は大きく2つある。プロジェクト設定のGUIから変更する方法と、package.jsonのenginesフィールドで指定する方法だ。
package.jsonで指定する場合は、以下のように記述する。
{
"engines": {
"node": "24.x"
}
}この設定がデプロイ時に読み取られ、Node.js 24が使用される。プロジェクト設定の値よりもpackage.jsonの指定が優先されるため、リポジトリにこの設定を含めておけば、デプロイのたびにGUIで変更する手間が省ける。
また、Vercelの公式ブログでは、コーディングエージェントにアップグレードを依頼する際のプロンプトも紹介されている。
Upgrade this Vercel project from Node.js 20 to 24.
Set the engines field in package.json to { "node": "24.x" },
which overrides the Project Settings version on the next deployment.
Update any Node 20 pins in .nvmrc, .node-version, or CI configs.
Switch the local runtime to Node 24, reinstall dependencies,
run the build and tests, and fix any breaking changes.
After deploying, confirm the version by logging process.version.このプロンプトをClaudeやChatGPTなどのコーディングエージェントに渡せば、Node.jsバージョンの変更に伴う一連の作業をある程度自動化できる。
上記の対比の通り、コーディングエージェントを活用すれば複数ファイルの一括更新が可能で、変更漏れのリスクを減らせる。
アップグレード時に気をつけるべき破壊的変更
Node.js 20から22、あるいは24へ移行する際、APIの破壊的変更がいくつか存在する。特に注意すべきなのは、以下の点だ。
- 廃止されたAPI（fs.rmdirのコールバック形式など）が完全に削除されている可能性
- ESM（ECMAScript Modules）の取り扱いに関するデフォルト挙動の変更
- ネイティブアドオンのABI互換性（再ビルドが必要になるケース）
- V8エンジンのバージョンアップに伴うパフォーマンス特性の変化
移行前に必ずローカル環境でNode.jsのバージョンを切り替え、依存関係を再インストールした上で、ビルドとテストを実行してほしい。CIパイプラインでNode.jsのマトリクステストを実施している場合は、テスト対象に新しいバージョンを追加しておくと安全だ。
アップグレードが間に合わない場合の緊急回避策
どうしても10月1日までにNode.jsのバージョンアップが完了できないプロジェクトが出てくるかもしれない。大規模なコードベースや、多数の依存パッケージとの互換性確認に時間がかかるケースだ。
そうした状況のために、Vercelはコンテナイメージとしてデプロイする代替手段を用意している。
プロジェクトのルートにDockerfile.vercelを作成し、Node.js 20をベースイメージとして指定するだけでよい。
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci
# サーバーは $PORT をリッスンする必要がある
CMD ["node", "server.js"]この方法を使えば、プロジェクト設定のNode.jsバージョンはコンテナに適用されない。つまり、プラットフォーム側のNode.js 20非推奨の影響を受けずにデプロイを継続できる。
コンテナデプロイはあくまで一時的な回避策だ。Node.js 20のセキュリティサポートはすでに終了している。長期的に見れば、Node.jsのバージョンアップこそが唯一の正しい解決策である。
この記事のポイント
- Vercelは2026年10月1日にNode.js 20を非推奨とする。既存デプロイメントは影響を受けない
- vercel project ls –update-required で影響を受けるプロジェクトを特定できる
- package.jsonのenginesフィールドでNode.js 22または24を指定して移行する
- コーディングエージェント用のプロンプトを使うと、複数ファイルの一括更新が効率的
- どうしても間に合わない場合はコンテナデプロイ（Dockerfile.vercel）で緊急回避が可能
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Vercel Agentが本番環境に進出、プラン即許可で安全なAI運用を実現
Vercelが2026年7月8日、自社のAIエージェント「Vercel Agent」の大幅な機能拡張を発表した。従来はアラートのトリアージやプルリクエストのレビューが中心だったが、今回のアップデートでダッシュボード上に常設され、本番環境の調査やプロジェクトへの質問応答、承認後のアクション実行まで可能になった。
Vercel Agentの最大の特徴は「プラン即許可（Plan-to-Permission）」という新しい権限モデルだ。デフォルトで読み取り専用として動作し、デプロイのロールバックや設定変更といった操作は、具体的な作業計画を提案して承認を得たうえで、そのタスクに限定された一時的な権限のみを使って実行する。
本番稼働中のアプリケーションにAIを介入させるには、安全性の担保が不可欠である。Vercel Agentは独立したIDで動作し、生成したコードは隔離されたサンドボックスで検証する。この設計により「自律的でありながら制御された状態」を実現しており、AIエージェントの運用にまつわる信頼の課題に対して、具体的な解決策を示した製品といえる。
Vercel Agentの全体像と導入背景
Vercel Agentは、Vercelプラットフォーム上で動作するAIエージェントだ。アプリケーションのデプロイと実行を支えるインフラに組み込まれているため、本番環境で問題が発生した際に、最初に対応を開始できるポジションにある。アラートを受けてから自律的にログやメトリクス、デプロイ履歴を調査し、根本原因を特定して修正案を提示する。
Vercel社内では数ヶ月前から本番運用に組み込まれており、すでに具体的な成果が出ている。典型的な事例として、深夜23時に不良デプロイが行われ、チェックアウト用のエンドポイントが500エラーを返し始めたケースでは、オンコールエンジニアがログインする前にAgentがエラーを4分前のデプロイまでトレースし、即時ロールバックを推奨した。エンジニアが計画を承認すると、Agentが前の正常なビルドにロールバックし、エンドポイント修正用のプルリクエスト作成まで自動で進めた。アラート発生から問題緩和までの時間は3分未満だったという。
このデモは、同じインシデントに対する従来の対応とVercel Agent導入後の対応を比較した概念図である。Agentが自律的に調査と提案を行い、人間は最終判断に集中できる点が最大の違いだ。
本番環境にAIを近づけるための新セキュリティモデル
アプリケーションの修正や設定変更が可能なAIエージェントを本番環境に導入する場合、最も重要な問いは「どう安全にデプロイや設定変更を任せられるか」である。多くのAIエージェントはユーザーの全権限を引き継いで動作するため、誤った指示や混乱したサブエージェントの被害がそのまま本番に及ぶという構造的な課題を抱えている。
Vercel Agentはこの問題に対して、3つの要素からなる新しい権限モデルを実装した。エージェント自身の固有ID（Principal）、タスクごとの一時的な権限付与（Plan-to-Permission）、そして生成コードの隔離実行環境（Sandbox）である。これらはプラットフォームレベルで強制されるため、AIモデルの挙動にかかわらず安全策が機能する。
エージェント固有のIDによる帰属と権限の分離
一般的なAIエージェントは、操作する人間のIDと権限をそのまま使って動作する。その場合、エージェントが行った操作と人間が行った操作を区別できず、誰が何を指示し実行したのか追跡不可能になる。
Vercel Agentは「vercel-agent」という固有のプリンシパル（主体）として動作する。すべての変更操作には「誰が依頼したか」「誰が承認したか」「Vercel Agentが実行した」という記録が必ず残る。さらに、Agentに付与される権限は、操作を指示した人間がもつ権限の範囲を超えることはない。この設計により、説明責任（アトリビューション）と権限の透明性を両立している。
⚠️ 誤指示や誤動作の影響範囲がユーザーと同等
✅ 付与される権限は承認された計画の範囲に限定
この図は、従来型エージェントとVercel Agentの権限構造の違いを表している。Vercel Agentでは、常に「依頼者」「承認者」「実行者」の3者が記録され、権限も計画単位で一時的に付与されるため、誤動作の被害範囲が極めて狭い。
プラン即許可（Plan-to-Permission）の仕組み
多くの組織がAIエージェントを開発フローに統合する際、最初に直面するのが「事前に広範な権限を付与してしまう」という課題だ。これはエージェントに必要以上の権限を、必要以上の期間与えることになる。そのエージェントにプロンプトを送れる人なら誰でも、付与された権限の範囲にアクセスできてしまうため、権限の広さがそのままセキュリティリスクの大きさに直結する。
Vercel Agentはデフォルトで読み取り専用である。デプロイのロールバック、設定変更、キャッシュのクリアといった操作が必要な場合、Agentはまず実行計画を提案し、その計画に限定されたアクセス権限を要求する。ユーザーが計画を承認すると、Agentはそのタスクに必要な能力を一時的に取得し、作業完了後は自動的に読み取り専用状態に戻る。
Agentが行うすべてのAPI呼び出しは、3つのチェックを通過する必要がある。承認された計画で付与された能力（Capability）、トークンのスコープ、そしてチームの既存権限だ。これら3つすべてが許可する場合にのみ操作が実行され、このチェックはプラットフォーム側で強制されるため、AIモデルがどのような挙動をとっても安全策が破られることはない。Vercelはこの仕組みを「プラン即許可（Plan-to-Permission）」モデルと呼び、最小権限の原則を設計レベルで組み込んでいる。
この一連の流れでは、Agentが自律的に調査と提案を行う一方で、実際の操作権限は人間の承認を経て初めて発行される。人間の判断を挟むことで安全性を確保しつつ、Agentの自律性を最大限に活かせる設計だ。
サンドボックスによる生成コードの安全な検証
コードを生成するAIエージェントにはもうひとつ重大な課題がある。それは「生成されたコードが実際に動くかどうかは、実行してみるまでわからない」という点だ。動作確認されていない修正を本番環境に適用することは、さらなる障害を引き起こすリスクを伴う。
Vercel Agentが生成したコードは、Vercel Sandbox（FirecrackerマイクロVMによる短寿命の隔離環境）内で実行される。このサンドボックスは実際のプロジェクトのコピーを持っており、Agentは生成したコードを本物のビルドプロセス、テスト、リンターに対して実行し、問題なくパスしたものだけをPRとして提示する。たとえば壊れた設定ファイルを修正する場合、Agentが変更を加えてサンドボックス内でビルドテストを通過させ、その結果をPRにまとめるという流れになる。
この仕組みにより、Agentは自由にコードを生成して実行できるが、検証に失敗したコードや壊れた修正が人間の前に提示されたり、本番環境に直接届いたりすることはない。コードレベルの安全性をインフラ側で担保している点が重要だ。
現場の開発フローがどう変わるか
Vercel Agentはインシデント対応だけでなく、開発者が日常的に直面するさまざまなタスクを支援する。具体的なユースケースを4つ紹介する。
プルリクエストのレビュー
AgentにPRの確認を依頼すると、CIがパスしているだけでは検出できないパフォーマンスの低下やリスクの高い変更を指摘する。たとえば、ある変更によってページが毎回サーバーサイドレンダリングされるようになり、キャッシュが効かなくなっていないかといった観点までチェックできる。
コスト増加の原因追及
「なぜ今月の請求額が跳ね上がったのか」という問いに対して、Agentはコード変更履歴を調査し、コスト急増の原因となった特定のコミットを特定する。たとえば、あるページがキャッシュされずに毎回サーバーサイドレンダリングされるようになったコード変更を検出し、承認を得たうえで修正PRを作成する。
ビルド失敗の修正
失敗したデプロイをAgentに調査させると、ログを読み取り、問題のある設定ファイルを特定し、修正の許可を求めてくる。ユーザーが承認すれば、Agentが設定を修正し、サンドボックス内でビルドをテストしてからPRとして提出する。
本番リリースの安全性確認
フィーチャーフラグに関する質問に対して、Agentはコードと本番のライブメトリクスの両方を分析し、その機能をロールアウトしても安全かどうかを判断する。データに基づいた客観的な判断が得られるため、リリース判断の品質が向上する。
この比較図は、日常的な開発タスクにおける負荷の変化を表している。Agentが調査と提案を担うことで、開発者はコードの質やビジネス判断といったより本質的な業務に集中できる。
反脆弱性インフラがもたらす意味
Vercel Agentの発表で最も重要なポイントは、単にAIエージェントの機能が追加されたという話ではない。AIエージェントを「本番環境に近づけても安全に運用できる」という状態を、プラットフォームの設計で実現したことだ。
AIエージェントの時代において、真の限界は2つの天井で決まる。ひとつはモデルが「何をできるか」、もうひとつはユーザーが「何を許可するか」だ。モデル性能が向上し続けるなかで、実際の運用において重要になるのは後者、すなわち信頼の設計である。どれほど高性能なモデルでも非決定論的であり、非決定論的なシステムは非決定論的に失敗する。安全性は「エージェントが毎回正しい判断をすること」に依存してはならず、システムそのものに組み込まれていなければならない。
Vercelは長年にわたり、イミュータブルデプロイメント（デプロイが書き換え不可で、不良デプロイは1回のロールバックで元に戻せる仕組み）をはじめとする安全策を積み上げてきた。これらはもともとAIエージェントのために設計されたものではないが、自律システムが必要とするガードレールそのものとして機能する。Vercelはこの考え方を「反脆弱性インフラ（Anti-fragile Infrastructure）」と呼んでいる。
反脆弱性インフラの本質は、エージェントに誤りがあっても被害を局所化でき、人間のミスさえもコストを抑えられる点にある。安全性がインフラ層に組み込まれているため、エージェントが正しいことを前提にせずとも、実用的な権限を委譲できる。Vercel Agentのケースでは、自律的に調査と提案を行い、人間が承認した範囲内でのみ操作を実行し、何か問題があれば即座にロールバックできる。
このモデルは、AIエージェントの実運用における「自律性 vs 安全性」というトレードオフに対して、明快な解を示している。エージェントが仕事をし、人間が最終判断を保持し、インフラがフェイルセーフとして機能する。この3層構造が揃って初めて、本番環境にAIを近づける信頼の土台が成立する。
Vercel Agentの将来展望と利用開始方法
現時点でのVercel Agentは、異常の調査、プルリクエストの作成、プロジェクトや本番アプリに関する質問への回答が可能だ。今後のロードマップとして、特定分野の専門家エージェントへの委任機能が予定されている。たとえば、コードベース全体に対する詳細なセキュリティレビューや、フロントエンドのデザイン・UXレビューを、オンデマンドで専門家AIに依頼できるようになる見込みだ。
Vercel Agentは、ProプランおよびEnterpriseプランのチームに対して段階的にロールアウトされている。利用を希望する場合は、Vercelのアーリーアクセスページから申請するか、ダッシュボードのサイドバーにある「Agent」セクションから有効化できる。
この記事のポイント
- Vercel Agentは本番環境の異常を自律的に調査し、人間の承認を得て修正を実行するAIエージェントである
- 「プラン即許可」モデルにより、Agentの権限はタスク単位で一時的に付与され、完了後は読み取り専用に戻る
- 生成されたコードは隔離されたサンドボックスで検証され、本番環境に直接影響を与えない設計になっている
- イミュータブルデプロイメントなどのインフラ安全策と組み合わせることで、エージェントの誤動作コストを最小化する
- AIエージェントの実運用における信頼の課題に対して、プラットフォーム設計で安全性を担保するアプローチを具体化した製品といえる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
VercelがDockerfileサポートを発表、任意のHTTPサーバーをデプロイ
VercelがDockerfileサポートを発表、任意のHTTPサーバーをワンコマンドでデプロイ可能に
2026年6月30日、VercelはDockerfileサポートを正式に発表した。プロジェクトにDockerfile.vercelというファイルを追加するだけで、Vercel上でコンテナイメージのビルド、保存、デプロイ、そしてオートスケールが完結する。
従来、Vercelはフロントエンドとサーバーレス関数のプラットフォームだった。今回の発表で、Express、Rails、Spring Boot、FastAPIといったフル機能を持つHTTPサーバーも、同一のプラットフォームで運用できるようになる。バックエンドとフロントエンドの垣根は、ほぼゼロになった。
この記事では、Dockerfile.vercelの仕組み、対応スタック、Fluid computeによる運用面の利点、そしてVercelが10年越しでこの機能を実現した理由について解説する。
Dockerfile.vercelの基本的な使い方
最小限のHTTPサーバーをデプロイする手順
仕組みを理解するため、Goで書かれた最低限のHTTPサーバーを例に見ていこう。このサーバーは環境変数PORTからポート番号を読み取り、全リクエストに挨拶文を返すだけのシンプルなものだ。
package main
import (
"fmt"
"net/http"
"os"
)
func main() {
port := os.Getenv("PORT")
if port == "" {
port = "80"
}
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "Hello from a container on Vercel 👋")
})
http.ListenAndServe(":"+port, nil)
}このコードを動作させるため、Dockerfile.vercelをプロジェクトルートに置く。内容は次のような2段階ビルドだ。ビルドステージでバイナリをコンパイルし、軽量なAlpineイメージにコピーして実行する。
FROM golang:1.24-alpine AS build
WORKDIR /src
COPY . .
RUN go build -o /server main.go
FROM alpine:3.20
COPY --from=build /server /server
CMD ["/server"]あとはvercelコマンドを実行するだけだ。
vercel deploy
Vercel CLI
✓ Building image from Dockerfile.vercel
✓ Stored image in your project's registry
✓ Deployed to Fluid compute
Production: https://my-server.vercel.appたった2ファイルで、本番公開まで完了する。git pushのたびにイメージが再ビルドされ、プレビューURLも自動生成される。ブラウザでそのURLを開けば、すぐに応答が返ってくるはずだ。
この例ではGoを使ったが、仕組みはどの言語でも同じだ。サーバーが$PORTで待ち受けること、これが唯一のルールである。HTTPプロトコルを話すサーバーであれば、すべてVercel上で動作する。
すべての言語とフレームワークに対応
VercelのDockerfileサポートは、特定の言語やフレームワークに縛られない。Rails、Spring Boot、Express、Laravel、ASP․NET、FastAPI、そしてnginxの背後にあるウェブサーバーまで、同じ手順でデプロイできる。記事によれば、JavaもPHPも例外ではない。
フレームワーク自動検出がVercelの主軸だが、検出対象外のフレームワークや、FFmpegやChromiumのようなシステムライブラリを必要とするサービスは、Dockerfileで直接定義できる。既存のアプリケーションを、今の構成のまま移行したい場合の受け皿にもなる。
Fluid computeがもたらす自動スケールとコスト最適化
コンテナはVercelプラットフォームのファーストクラス市民として扱われる。フロントエンドや他のVercelサービスと同一のコンピュート基盤、Fluid compute上で動作し、以下の恩恵を受けられる。
- プッシュごとのプレビューデプロイ 全コミットに不変のURLが付与され、共有やロールバックが容易になる
- 双方向オートスケール トラフィック到来でスケールアウトし、アイドル時はインスタンスが縮退する。フリートのサイジングや同時実行数の見積もりは不要
- アクティブCPU課金 コードが実際に動作している時間だけ支払う。遅いクエリや上流API待ちでサーバーが待機している間は、CPU時間を消費しない
- オブザーバビリティの統合 ログ、トレース、メトリクスを同一のダッシュボードで確認できる
- 単一プロジェクト・単一ドメイン コンテナはフロントエンドや他のサービスと並んで配置され、Vercelネットワーク上でプライベートに通信する。フルスタックが1デプロイで完了する
とくにアクティブCPU課金は、トラフィックが散発的なサービスにとってコスト面のインパクトが大きい。常時稼働のサーバーを抱える必要がなくなり、使った分だけの支払いで済む。
高速起動を支える最適化技術
コンテナの価値は、最初のリクエストに応答するまでの速さで決まる。Vercelはイメージビルド時に、最適化ブートイメージを生成する。これはコンテナのディスクスナップショットを圧縮し、起動速度に特化させた形式だ。
コンテナ起動時には、イメージ全体をダウンロードし終える前に、必要な部分からストリーミングと解凍が行われる。大きなイメージでも、ダウンロード完了を待たずにリクエスト処理を開始できる仕組みだ。
インスタンスが立ち上がった後は、Fluid computeがそのインスタンスを温かく保ち、複数のリクエストを処理する。リクエストごとに新しいコピーを起動するわけではないので、応答性は常時稼働サーバー並みでありながら、アイドル時はスリープするという課金上の利点が両立する。
各コンテナはステートレスプロセスとして設計される。リクエストを受け取り、レスポンスを返し、その間に状態を保持しない。永続的なデータはVercel Marketplaceで提供されるデータベースやキャッシュなどのバッキングサービスに依存する。これにより、インスタンスの追加と削除が自由に行え、トラフィック変動への追従がシンプルになる。記事によれば、コンテナに永続ストレージを直接接続する機能も現在開発中とのことだ。
10年越しで実現したDockerfileサポートの背景
Vercelの最初のプラットフォームは、1コマンドでDockerfileをデプロイできるツールだった。2016年頃の話だ。アイデア自体は正しかったが、当時のインフラでは十分に扱いきれなかった。
その後、Vercelはビルド、Functions、Sandboxと、プラットフォームを構成する基盤技術を一つひとつ磨いてきた。これらは現在、Vercel上で動作するすべてのワークロードを支えている。今回のDockerfileサポートは、それらの積み重ねの上に成り立っている。コンテナも、それらと同一のシステム上で動くファーストクラス市民になった。
フレームワーク自動検出はVercelの入り口だ。コードを読んでインフラを導出する。ほとんどのアプリではそれが最速の出荷手段となる。Dockerfileは、それ以外のすべてをカバーする。FFmpegやChromiumのようなシステムライブラリが必要なサービス、まだ自動検出が対応していないフレームワーク、あるいは既存の構成をそのまま持ち込みたいアプリケーション。Dockerfileは、プログラムのビルド方法を定義する普遍的な手段であり、フレームワークが読めない場合にはそれを直に受け取る。
Dockerfile以外の設定は不要だ。イメージを指定するだけで、ビルド、レジストリ、ロールアウト、スケーリング、URL発行まですべてが自動的に行われる。Vercelの発表文には「ゼロコンフィグレーション」という言葉が使われているが、まさにそれを体現する機能と言える。
バックエンド開発の新しい当たり前
バックエンドが、フロントエンドと同じ方法で出荷される時代が来た。ワンプッシュ、ワンプレビュー、ワンプラットフォーム。VercelのDockerfileサポートは、その簡潔さとスケーラビリティにおいて、バックエンド開発の風景を変える可能性を秘めている。
具体的な手順やテンプレートは公式ドキュメントで公開されている。GoやRailsだけでなく、あらゆるHTTPサーバーが対象だ。既存のDockerfileを持つプロジェクトがあれば、それをDockerfile.vercelにリネームするだけでVercel上での稼働を試せる。
コンテナを扱うためにローカルでデーモンを動かす必要も、レジストリを用意する必要も、クラスタを管理する必要もない。必要なのは、Dockerfile.vercelという1つのファイルと、vercel deployという1つのコマンドだけだ。その先の複雑さは、すべてVercelが引き受ける。
この記事のポイント
- VercelがDockerfileサポートを開始し、任意のHTTPサーバーをワンコマンドでデプロイ可能になった
- サーバーが$PORTで待ち受けることさえ守れば、Go、Rails、Spring Boot、PHPなど全スタックが動作する
- Fluid computeにより、トラフィックに応じた自動スケールと、CPU実行時間のみの課金が実現する
- イメージのストリーミング起動技術により、大きなコンテナでも高速にリクエスト処理を開始できる
- この機能は10年にわたるプラットフォーム基盤の改良の上に成り立っており、コンテナがVercelのファーストクラス市民として統合された
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AIエージェントがCloudflareで自律デプロイ。Stripe連携でアカウント作成からドメイン購入まで完結
AIエージェントがソフトウェアを開発するだけでなく、本番環境のインフラまで自ら調達し、デプロイを完了させる時代が到来した。Cloudflareは2026年4月30日、AIエージェントがユーザーに代わってCloudflareアカウントを作成し、ドメインを購入し、アプリケーションをデプロイできる新機能を発表した。
この仕組みは決済プラットフォームのStripeが提供する「Stripe Projects」と共同設計された新しいプロトコルによって実現されている。従来は人間が管理画面で行っていたAPIトークンの発行やクレジットカード情報の入力といった作業を、AIが安全かつシームレスに代行する。
開発者は複雑な初期設定に煩わされることなく、AIに指示を出すだけで「ゼロから本番公開まで」を最短距離で駆け抜けられるようになる。これはインフラ構築の在り方を根本から変える可能性を秘めたアップデートだ。
AIエージェントがインフラ構築を担う新時代の幕開け
コーディングエージェントはプログラムを書く能力には長けているが、これまでは本番環境へのデプロイという壁に直面していた。アプリケーションを公開するには、ホスティング先のアカウント、支払い手段、そして操作のためのAPIトークンの3つが不可欠だからだ。
これまでは人間がダッシュボードにログインし、設定を済ませてからエージェントに情報を渡す必要があった。Cloudflareが導入した新機能は、この「人間による介在」を最小限に抑えることを目的としている。
開発者の手作業をゼロにするStripe Projectsとの連携
今回の機能の中核にあるのが、Stripeとの提携による「Stripe Projects」だ。これはAIエージェントが複数のサービスを組み合わせてプロジェクトを立ち上げるためのプラットフォームである。開発者がStripeのアカウントを持っていれば、それを認証の基盤として利用できる。
エージェントはユーザーの許可を得た上で、Cloudflareのアカウントを自動的にプロビジョニング（準備）する。もしユーザーがすでにCloudflareのアカウントを持っている場合は、標準的なOAuthフローを通じてアクセス権が譲渡される。これにより、APIキーのコピペという原始的な作業から解放される。
● カード情報登録（手動）
● APIキー発行とコピペ（手動）
● ドメイン検索と購入（手動）
✔ 支払いトークンの自動受け渡し
✔ ドメインの自律取得とデプロイ
上記の図が示すように、人間が介入すべきポイントは「AIへの指示」と「最終的な承認」だけに集約される。これにより、開発のリードタイムは劇的に短縮されるだろう。
プロトコルを支える3つの柱
AIエージェントが自律的に動くためには、単にAPIを叩くだけでは不十分だ。CloudflareとStripeは、エージェントが環境を理解し、権限を得て、支払いを実行するための3つの要素をプロトコルとして定義した。
サービスカタログからの自律的な発見
まず重要になるのが「Discovery（発見）」だ。エージェントは、利用可能なサービスが何であるかを知る必要がある。新しいプロトコルでは、CloudflareなどのプロバイダーがREST APIを通じてサービスカタログをJSON形式で提供する。
エージェントはユーザーの要望に基づき、このカタログから最適なサービス（ドメイン登録、ストレージ、コンピューティングなど）を選択する。人間が「どのメニューから選ぶか」を悩む必要はなく、エージェントがタスク達成に最適な道具を自ら選び出す仕組みだ。
認証とアカウントの即時発行
次に「Authorization（認証）」だ。Stripeがアイデンティティプロバイダーとして機能し、ユーザーの身元を保証する。Cloudflareはこの情報を基に、未登録のユーザーに対しては即座にアカウントを発行する。
発行された認証情報はStripe Projects CLIによって安全に保管され、エージェントはそれを使ってCloudflareのAPIを操作する。この一連の流れにおいて、ユーザーがサインアップフォームに入力する手間は一切発生しない。
クレジットカード情報を渡さない安全な決済
最も懸念されるのは「Payment（支払い）」の安全性だろう。AIにクレジットカード番号を教えるのはリスクが高い。そこでこのプロトコルでは、カード情報の代わりに「支払いトークン」を使用する。
Stripeから発行されたトークンをCloudflareに渡すことで、エージェントは実際のカード番号に触れることなく、有料プランの購読やドメインの購入を実行できる。決済の利便性とセキュリティを両立させた設計となっている。
実際のワークフローとCLIでの操作感
この新機能を利用するには、Stripe CLIと専用のプラグインが必要になる。セットアップが完了すれば、ターミナルから簡単なコマンドを実行するだけでプロジェクトを開始できる。Cloudflareのブログでは、具体的な手順が紹介されている。
Stripe CLIを用いたプロジェクトの初期化
まず、以下のコマンドでプロジェクトを初期化し、Stripeにログインする。これがすべての作業の起点となる。
stripe projects initその後、AIエージェントに対して「新しいドメインを取得してアプリをデプロイしてほしい」と指示を出す。エージェントは自ら stripe projects catalog コマンドを叩いてCloudflareのドメイン登録サービスを見つけ出し、購入プロセスを開始する。
もしStripeアカウントに支払い方法が登録されていない場合は、エージェントがユーザーに対してカード情報の追加を促すプロンプトを表示する。人間はエージェントが提示した確認事項に対して「Yes」と答えるだけで、裏側で複雑なインフラの紐付けが完了する。
セキュリティとガバナンスへの配慮
AIに支払権限を与えることには、慎重な意見も多い。「エージェントが勝手に高額なドメインを大量購入したらどうするのか」という懸念は当然の反応だ。この問題に対処するため、プロトコルには厳格な制限が設けられている。
予算制限と予算アラートによる暴走防止
Stripe Projectsでは、デフォルトで1つのプロバイダーに対して月額100ドルという支出上限が設定されている。エージェントがこの上限を超えて勝手に課金することはできない仕組みだ。
さらに上限を引き上げたい場合は、ユーザーが明示的に設定を変更し、Cloudflare側で予算アラート（Budget Alerts）を設定する必要がある。これにより、AIの自律性を保ちつつ、予期せぬコスト増大を防ぐガバナンスが効いている。
独自分析。インフラのコモディティ化とエージェントOSの加速
今回のCloudflareの動きは、単なる利便性の向上に留まらない。筆者は、これがインフラの「完全な抽象化」に向けた決定的な一歩であると考えている。かつて開発者はサーバーを自前で立てていたが、クラウドが登場し、さらにサーバーレスへと進化した。そして今、インフラは「AIが勝手に調達するもの」へと変貌しようとしている。
ここで重要なのは、Stripeが単なる決済手段ではなく、Web上の「アイデンティティ（身元）」のハブとして機能し始めている点だ。Stripeでログインしていれば、CloudflareもPlanetScaleもNeonも、あらゆるクラウドサービスが即座に利用可能になる。これは、Web全体が1つの巨大なオペレーティングシステム（OS）のように振る舞い、AIエージェントがその上で自由にリソースを操作できる環境が整いつつあることを意味する。
開発者の役割は、コードを書くことよりも「AIにどのようなビジネスロジックを実現させたいか」を定義することへとシフトしていくだろう。インフラの設定ミスやAPIトークンの管理漏れといった「非本質的なトラブル」から解放される未来は、すぐそこまで来ている。
この記事のポイント
- AIエージェントがCloudflareのアカウント作成、ドメイン購入、デプロイを自律的に行えるようになった。
- Stripe Projectsとの連携により、OAuth認証と支払いトークンを用いた安全なプロトコルが構築されている。
- 人間はダッシュボードを操作することなく、CLIとAIへの指示だけで本番環境を構築できる。
- 月額100ドルのデフォルト支出制限により、AIの暴走による高額請求を防ぐ仕組みが備わっている。
- インフラの調達が自動化されることで、開発者はより高度なアプリケーション設計に集中できるようになる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験