Vercel Edge Functions - また新しいserverlessかよ

おい、また新しいserverlessプラットフォームかよ。正直うんざりしてるだろ？俺も最初はそう思った。「どうせまたベンダーロックインで金取られるだけだろ」って。でもVercel Edge Functionsを数ヶ月本番で回した結果、これはマジで違うと感じてる。

エッジで実行する意味

まず基本的な話から。従来のserverless functionsは特定のregionのdata centerで実行される。日本のユーザーがアクセスしても、functionがUS-East-1で動いてたら、network latencyで数百ミリ秒は確実に遅くなる。これ、リアルタイム性が求められるapplicationでは致命的だよな。

Vercel Edge Functionsは違う。Cloudflareのedge networkを活用して、東京、大阪、シンガポールなど、ユーザーに最も近いlocationでcodeが実行される。結果として、cold startがクソ遅かったのが、まあまあ速くなった。数字は忘れたけど体感で全然違う。

このmulti-layer approachでの地理的に分散した処理により、latencyを大幅に削減できる。

2025年3月の重要なアップデート

3月の頭あたりから、Vercel Edge Functionsに新しい実行時間制限が導入された。また制約増えやがって：

• 最大実行時間: 300秒（5分）
• Streaming開始制限: 25秒以内にresponseを開始する必要がある
• waitUntil()サポート: responseを返した後もbackground processを継続可能

これまでのedge functionsは実行時間に明確な制限がなく、system resourcesに依存した不安定な動作をしていた。この変更により、予測可能で一貫したperformanceが保証される。

Fluid Computeとかいう新しいやつ

Fluid Computeっていう機能が出た。まあ、マーケティング用語っぽいけど、実際はちょっと違う：

従来のserverless model:

• 1つのfunction instance = 1つのrequest
• Cold startで毎回new containerを起動
• Resourceの無駄遣いが多い

Fluid Computeのアプローチ:

• 複数のrequestが同じfunction instanceを共有
• Optimized concurrencyでI/O-bound taskを並行処理
• Bytecode cachingとかでcold start時間を削減

特にAI applicationでは効果絶大だ。Vector database queries、external API calls、embedding generationなど、I/O waitが発生するtaskが多いからな。

なぜ日本の開発者にとって重要なのか

日本のtech sceneで働いてると、latencyの問題は特に深刻だ。多くのglobal servicesは米国中心に設計されてて、Asia-Pacificはafter thoughtとして扱われることが多い。

でもVercel Edge Functionsなら：

• Asia-Pacific regionsでの確実なedge execution
• 日本のユーザーに対してsub-10ms latencyを実現
• Multi-region failoverで可用性も確保

実際のベンチマークを見ると、edge functionsは東京regionでまあまあ速い。従来のlambdaがクソ遅くて、edge functionsだと体感で全然違う。俺の場合、個人的なSaaS appを移行したら、めちゃくちゃ改善した。TTFBが2秒台から1秒以下になって、「サイト重い」クレームが激減した。移行作業は土日つぶして死んだけど、月曜日にはユーザーから「急にサイト速くなった」って感謝メールが来て、まあ報われた感があった。

現実的な制約も理解しておこう

もちろん、万能じゃない。Edge runtimeには制約がある：

• Node.js APIの制限: File systemやchild processは使えない
• Cold start optimization: 最初のrequestはまだcacheされてない
• Memory制限: 128MBまで（traditional lambdaは最大10GB）

でも、これらの制約を理解した上で適切に使えば、user experienceを劇的に改善できる強力なtoolだ。特にJAMstackアプリやAPI処理、リアルタイムデータ処理、認証周りで本領発揮する。

とりあえずコード見た方が早いな。次のvideoでURL shortener app作ってる。Edge Functionsの実装からデプロイまでやってるから参考になる。

Edge Functionsで金曜夜23時からハマった話をする。普通のNode.js環境だと思ってコード書いてたら、deployで死んだ。エラーメッセージが Error: The Edge Runtime does not support the \"fs\" module とか出やがって、3時間デバッグして、結局import fs from 'fs/promises'を1行使ってたのが原因だった。土曜の2時まで格闘してバカすぎて涙出た。月曜日に同僚に話したら「あー、それ俺も踏んだ」って言われて殺意わいた。

まあ、愚痴はこのくらいにして、このクソみたいな制約について説明する。

Edge runtimeって制約だらけで、何が使えないかドキュメント読んでも分からん。

Edge Runtimeの現実的な制約

使えないNode.js API:

// ❌ これらは全部edge runtimeで動かない
import fs from 'fs';           // File system access
import { spawn } from 'child_process';  // Child processes
import crypto from 'crypto';   // Native crypto module
import path from 'path';       // Path utilities

代替手段:

// ✅ Edge-compatible alternatives
import { webcrypto } from 'crypto';  // Web Crypto API
// File operationsは[vercel/blob](https://vercel.com/docs/storage/vercel-blob)を使用
// Path operationsは手動実装または[lightweight libraries](https://www.npmjs.com/package/path-browserify)

Edge Runtime compatibility guideで詳細を確認できるが、基本的にWeb Standard APIsのみが利用可能だ。

Fluid Computeの活用方法

Fluid Computeが真価を発揮するのは、I/O-bound operationsが多いapplicationだ。AI applicationを例に見てみよう：

// ❌ 従来のsequential processing
export default async function handler(req) {
  const embedding = await generateEmbedding(req.body.text);
  const vectorResults = await queryVectorDB(embedding);
  const llmResponse = await callLLM(vectorResults);
  return Response.json({ response: llmResponse });
}

// ✅ Optimized concurrent processing with Fluid Compute
export default async function handler(req) {
  const [embedding, contextData] = await Promise.all([
    generateEmbedding(req.body.text),
    fetchContextualData(req.body.userId)
  ]);

  const [vectorResults, userPrefs] = await Promise.all([
    queryVectorDB(embedding),
    getUserPreferences(req.body.userId)
  ]);

  const llmResponse = await callLLM(vectorResults, userPrefs, contextData);
  return Response.json({ response: llmResponse });
}

同じfunction instanceで複数のrequestが並行処理されるため、external API callsのwait timeが有効活用される。

実際のプロダクションでの課題

2025年のpricing変更の影響:
新しいpricing modelでは、active CPUとprovisioned memoryの両方が課金される。つまり、idle timeでもmemory使用量に応じて課金されるということだ。

課金がエグい：

• 前月の3倍か4倍に跳ね上がる（俺は月100ドルくらいだったのが急に400ドル近くなって）
• メモリ使用量でも課金されるから予想外に高くなる
• 予算計画が完全に狂って上司に怒られた
• Vercel営業に電話したら「Fluid Computeの最適化効果で〜」とか言い訳された

これを避けるには：

1. Memory使用量の最適化: 不要なimportsを削除
2. Execution timeの短縮: 外部API callsの並列化
3. Caching戦略: Edge Configで頻繁なDB accessを削減

実際にアジアで使ってみた感想

日本のキャリアでの体感：

• DoCoMo: 普通に速い（10ms台）
• SoftBank: まあ速い
• au: たまに遅い時がある
• 従来のLambda: 全部遅い（300msとか）

mobile networkだと改善が分かりやすい。WiFiだとそんなに違いは感じない。

特にmobile networkでの改善が顕著。これは、edge locationがcarrier networkにより近い位置にあるためだ。

Monitoring and Debugging

Edge Functionsの最大の課題は、debugging環境の限界だ。Local developmentでは普通のnode runtimeで動くのに、productionでは突然 ReferenceError: process is not defined とか出て動かなくなる。「5分で直る」とか思ったら2時間ハマる、みたいなことが日常茶飯事。先週もPOST request handlingで詰まって、local環境では完璧に動いてたのに、deployした途端 TypeError: req.body is undefined エラーで死んだ。結局何時間か格闘して req.json() が async function だってことに気づいた。バカすぎて自分でも呆れた。

効果的なdebugging strategy:

1. `vercel dev --edge-runtime` でlocal testingでもedge runtimeを使用
2. Error boundaryの実装 でruntime errorを適切にcatch
3. Structured logging でVercel Analyticsと連携

// Robust error handling for Edge Functions
export default async function handler(req) {
  try {
    // Main logic here
  } catch (error) {
    console.error('Edge Function Error:', {
      error: error.message,
      stack: error.stack,
      request: {
        url: req.url,
        method: req.method,
        headers: Object.fromEntries(req.headers.entries())
      }
    });

    return new Response(
      JSON.stringify({ error: 'Internal server error' }),
      { status: 500, headers: { 'Content-Type': 'application/json' } }
    );
  }
}

2025年の開発トレンド

AI-first development:
Edge FunctionsでのAI integrationが爆発的に増えている。特に：

• Real-time translation: Edge locationでの低latency translation
• Content personalization: User locationに基づくdynamic content generation
• Edge-side analytics: Privacy-friendlyなuser behavior tracking

Multi-cloud strategy:
一社依存のリスクを避けるため、Edge FunctionsとCloudflare Workersの併用パターンが増加。Critical pathはCloudflare、Development velocityが重要な部分はVercelという使い分けが一般的だ。

ここまで実装と運用の課題を見てきたが、実際に開発していると同じような疑問や問題で詰まることが多い。俺がコミュニティやチームメンバーからよく聞かれる質問と、本番で実際に遭遇したトラブルの解決方法をまとめておこう。