Vercel Fluid Compute徹底解説 – サーバーレスをさらに進化させる新モデル

## TL;DR

Fluid Computeは、Vercelが新たに提供するサーバーレスの実行モデルです。従来のサーバーレスと同様に必要なときだけ関数を起動しつつ、**1つの関数インスタンスで複数リクエストを同時処理できる**「ミニサーバー」のような動作を実現します ([従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey](https://www.publickey1.jp/blog/25/fluid_computevercel.html#:~:text=%E3%81%9D%E3%81%93%E3%81%A7Fluid%20Compute%E3%81%A7%E3%81%AF%E3%80%811%E3%81%A4%E3%81%AE%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9%E3%81%AB%E3%81%8A%E3%81%84%E3%81%A6%E8%A4%87%E6%95%B0%E3%81%AE%E9%96%A2%E6%95%B0%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E5%AE%9F%E8%A1%8C%E3%81%A7%E3%81%8D%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%97%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82)) ([従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey](https://www.publickey1.jp/blog/25/fluid_computevercel.html#:~:text=%3E%20In,function%20concurrency%EF%BC%88%E9%96%A2%E6%95%B0%E5%86%85%E4%B8%A6%E8%A1%8C%E5%87%A6%E7%90%86%EF%BC%89%E3%81%AB%E3%82%88%E3%82%8A%E3%80%811%E3%81%A4%E3%81%AEVercel%E9%96%A2%E6%95%B0%E3%81%A7%E8%A4%87%E6%95%B0%E3%81%AE%E5%91%BC%E3%81%B3%E5%87%BA%E3%81%97%E3%82%92%E5%90%8C%E6%99%82%E3%81%AB%E5%87%A6%E7%90%86%E3%81%A7%E3%81%8D%E3%82%8B%E3%81%9F%E3%82%81%E3%80%81%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%AE%E4%BD%BF%E7%94%A8%E3%81%8C%E6%9C%80%E9%81%A9%E5%8C%96%20%E3%81%95%E3%82%8C%E3%80%81%E5%8A%B9%E7%8E%87%E5%8C%96%E3%81%AB%E3%82%88%E3%82%8B%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%AE%E7%AF%80%E7%B4%84%E3%81%A8%E3%81%AA%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82))。これにより**コールドスタートの削減**や**リソースの有効活用**によって最大85%のコスト削減効果が報告されています ([Introducing Fluid compute: The power of servers, in serverless form - Vercel](https://vercel.com/blog/introducing-fluid-compute#:~:text=It%E2%80%99s%20time%20for%20a%20new%2C,costs%20by%20up%20to%2085))。ストリーミング応答やレスポンス後の非同期処理にも対応し、フロントエンド・バックエンド・インフラの各エンジニアに嬉しいメリットをもたらします。

## Fluid Computeとは何か？

Fluid Computeは **「サーバーのパワーをサーバーレスの形で提供する」** ことを掲げた新しい実行インフラです ([Fluid compute](https://vercel.com/fluid#:~:text=The%20power%20of%20servers%2C%20in,serverless%20form))。従来のサーバーレスでは「1リクエスト＝1関数インスタンス」で実行し、処理終了後はインスタンスを破棄します。しかし、このモデルではリクエスト待ちや外部API呼び出し待機中の**アイドル時間**にもインスタンスが占有され、非効率でした ([従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey](https://www.publickey1.jp/blog/25/fluid_computevercel.html#:~:text=%E3%81%97%E3%81%8B%E3%81%97Vercel%E3%81%AF%E3%81%93%E3%81%AE%E5%BE%93%E6%9D%A5%E3%81%AE%E3%82%B5%E3%83%BC%E3%83%90%E3%83%AC%E3%82%B9%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF%E3%81%AB%E3%81%AF%E3%80%81%E3%81%BE%E3%81%A0%E9%9D%9E%E5%8A%B9%E7%8E%87%E3%81%AA%E7%82%B9%E3%81%8C%E3%81%82%E3%82%8B%E3%81%A8%E3%81%97%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82)) ([Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community](https://dev.to/andycasen/vercels-fluid-compute-and-what-it-means-for-aws-lambda-38dl#:~:text=If%20user%201%20makes%20a,reality%2C%20they%E2%80%99re%20both%20just%20waiting))。Fluid Computeでは以下の原則に基づき、この非効率を解消しています ([Introducing Fluid compute: The power of servers, in serverless form - Vercel](https://vercel.com/blog/introducing-fluid-compute#:~:text=Fluid%20compute%20is%20a%20new,demands%20of%20today%E2%80%99s%20dynamic%20web)) ([Introducing Fluid compute: The power of servers, in serverless form - Vercel](https://vercel.com/blog/introducing-fluid-compute#:~:text=,compute%20usage%2C%20minimizing%20waste)):

- **必要なときだけ起動**: リクエスト発生時に関数を起動し、アイドル時は稼働しない (従来同様のオンデマンド実行)。  
- **瞬時のスケーリング**: ゼロからピークトラフィックまでリアルタイムに自動スケール。  
- **インスタンス再利用**: 新規インスタンスを起動する前に**既存の空きインスタンス**を活用 ([Introducing Fluid compute: The power of servers, in serverless form - Vercel](https://vercel.com/blog/introducing-fluid-compute#:~:text=%2A%20Real,to%20peak%20traffic))。一つのインスタンスで複数の呼び出しを並行処理することで効率アップ ([従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey](https://www.publickey1.jp/blog/25/fluid_computevercel.html#:~:text=%3E%20In,function%20concurrency%EF%BC%88%E9%96%A2%E6%95%B0%E5%86%85%E4%B8%A6%E8%A1%8C%E5%87%A6%E7%90%86%EF%BC%89%E3%81%AB%E3%82%88%E3%82%8A%E3%80%811%E3%81%A4%E3%81%AEVercel%E9%96%A2%E6%95%B0%E3%81%A7%E8%A4%87%E6%95%B0%E3%81%AE%E5%91%BC%E3%81%B3%E5%87%BA%E3%81%97%E3%82%92%E5%90%8C%E6%99%82%E3%81%AB%E5%87%A6%E7%90%86%E3%81%A7%E3%81%8D%E3%82%8B%E3%81%9F%E3%82%81%E3%80%81%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%AE%E4%BD%BF%E7%94%A8%E3%81%8C%E6%9C%80%E9%81%A9%E5%8C%96%20%E3%81%95%E3%82%8C%E3%80%81%E5%8A%B9%E7%8E%87%E5%8C%96%E3%81%AB%E3%82%88%E3%82%8B%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%AE%E7%AF%80%E7%B4%84%E3%81%A8%E3%81%AA%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82))。  
- **実行時間課金**: 実際の**CPU実行時間に応じて課金**し、待機時間のムダを最小化 ([Introducing Fluid compute: The power of servers, in serverless form - Vercel](https://vercel.com/blog/introducing-fluid-compute#:~:text=,needed))。  
- **事前ウォームアップ**: 関数インスタンスをあらかじめプールして**コールドスタートを低減** ([Introducing Fluid compute: The power of servers, in serverless form - Vercel](https://vercel.com/blog/introducing-fluid-compute#:~:text=,compute%20usage%2C%20minimizing%20waste))。Node.js 20以降では**バイトコードキャッシュ**により初回起動後の再デプロイ時の起動を高速化 ([Fluid compute](https://vercel.com/docs/functions/fluid-compute#:~:text=When%20using%20Node,recompilation%20during%20subsequent%20cold%20starts)) ([従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey](https://www.publickey1.jp/blog/25/fluid_computevercel.html#:~:text=%E8%A4%87%E6%95%B0%E3%81%AE%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%82%921%E3%81%A4%E3%81%AE%E5%90%8C%E3%81%98%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9%E3%81%A7%E5%87%A6%E7%90%86%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%A7%E3%80%81%E3%82%B3%E3%83%BC%E3%83%AB%E3%83%89%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%88%E3%81%8C%E6%B8%9B%E3%82%8A%E3%80%81%E3%82%A2%E3%82%A4%E3%83%89%E3%83%AB%E3%82%BF%E3%82%A4%E3%83%A0%E3%81%AE%E5%89%8A%E6%B8%9B%E3%81%AB%E3%82%82%E3%81%A4%E3%81%AA%E3%81%8C%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82))。  
- **高度な処理に対応**: レスポンスを**ストリーミング**で逐次送信したり、応答返却後も関数内で後処理（ログ記録やDB更新など）を続行可能 ([Fluid compute](https://vercel.com/fluid#:~:text=Post))。これらを追加設定なしで実現。

要するに、Fluid Computeは**サーバーレスの自動スケーリングと課金モデル**はそのままに、**サーバー常駐プロセスの柔軟性**を取り込んだハイブリッドモデルです ([Introducing Fluid compute: The power of servers, in serverless form - Vercel](https://vercel.com/blog/introducing-fluid-compute#:~:text=It%E2%80%99s%20time%20for%20a%20new%2C,costs%20by%20up%20to%2085))。開発者は今まで通りVercel Functionsを使えばよく、特別なコード変更なしにこの恩恵を受けられます ([従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey](https://www.publickey1.jp/blog/25/fluid_computevercel.html#:~:text=Fluid%20Compute%E3%81%AFVercel%E3%81%8C%E6%8F%90%E4%BE%9B%E3%81%99%E3%82%8B%E3%82%B5%E3%83%BC%E3%83%90%E3%83%AC%E3%82%B9%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF%E3%81%A7%E3%81%82%E3%82%8B%E3%80%8CVercel%20Functions%E3%80%8D%E3%81%A7%E6%8F%90%E4%BE%9B%E3%81%8C%E9%96%8B%E5%A7%8B%E3%81%95%E3%82%8C%E3%81%A6%E3%81%8A%E3%82%8A%E3%80%81%E6%97%A2%E5%AD%98%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%AA%E3%81%8F%E5%88%A9%E7%94%A8%E5%8F%AF%E8%83%BD%E3%81%A8%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82))。

## 利点とユースケース

Fluid Computeによって得られる主な利点を、フロントエンド・バックエンド・インフラ各視点のユースケースと合わせて見てみましょう。

- **フロントエンドエンジニア向け:** リアルタイムなUXを提供しやすくなります。たとえばサーバーサイドレンダリングしたHTMLや、チャットの逐次応答（「ChatGPT」のような一文字ずつ思考している風の出力）を**ストリーミング送信**できます ([Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community](https://dev.to/andycasen/vercels-fluid-compute-and-what-it-means-for-aws-lambda-38dl#:~:text=Another%20benefit%20with%20Fluid%20Compute,one%20character%20at%20the%20time))。Fluid Computeではレスポンス送信後も関数が即終了しないため、`res.write()`でチャンクを送り続けるような実装が可能です。加えて、関数の起動遅延が減り**応答時間が安定**するため、ユーザーにストレスのないインタラクティブなUIを提供できます。

- **バックエンドエンジニア向け:** 外部APIやデータベース呼び出しが多いサービスで**スループットとコスト**が大幅に改善します。従来はリクエストごとに別々の関数環境を起動していたため、たとえば複数ユーザからの同時リクエストがすべて外部API待ちになると**待ち時間にも課金**が発生していました ([Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community](https://dev.to/andycasen/vercels-fluid-compute-and-what-it-means-for-aws-lambda-38dl#:~:text=If%20user%201%20makes%20a,reality%2C%20they%E2%80%99re%20both%20just%20waiting))。Fluid Computeでは一つの関数インスタンスが**待機中に別のリクエスト処理を並行実行**できるため、この待ち時間コストをほぼゼロにできます ([Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community](https://dev.to/andycasen/vercels-fluid-compute-and-what-it-means-for-aws-lambda-38dl#:~:text=In,another%20request%20can%20be%20sent))。実際、10並列の外部API待ち処理をFluid環境にまとめることで**課金対象時間が1/10になり、約90%のコスト削減**という試算もあります ([Fluid compute](https://vercel.com/docs/functions/fluid-compute#:~:text=With%20fluid%20compute%20enabled%2C%2010,reduces%20the%20total%20billing%20to))。また関数グローバルな変数や接続を**インスタンス間で共有維持**できるため（例えばデータベースコネクションを使い回す等）、余計な初期化のオーバーヘッドも減らせます。

- **インフラエンジニア向け:** **可用性とスケーラビリティの担保**がより簡単になります。Fluid Computeには標準で**マルチリージョンのフェイルオーバー**機能が組み込まれており、デプロイ先リージョンに障害が起きても自動で他地域へリクエストをリルート可能です ([Fluid compute](https://vercel.com/fluid#:~:text=Cross))（プロプランで最大3箇所、エンタープライズでは全リージョンがバックアップ対象 ([Fluid compute](https://vercel.com/docs/functions/fluid-compute#:~:text=Settings%20Hobby%20Pro%20Enterprise%20CPU,85Up%20to%203%20All))）。これにより高可用システムを構築する手間が大幅に削減されます。また、ワークロードに応じて**同時実行数やリソース配分を動的調整**するため、負荷予測や手動チューニングなしでも安定したパフォーマンスを発揮します ([Fluid compute](https://vercel.com/fluid#:~:text=Dynamic%20scaling))。結果として**オーバープロビジョニングの削減**によるコスト効率も向上し、組織全体としてのインフラ最適化に繋がります。

以上のように、Fluid Computeは**低レイテンシーでリッチなフロント体験**、**高効率なバックエンド処理**、**信頼性の高いインフラ運用**をそれぞれ支援します。特に**大規模言語モデル(LLM)を扱うAIアプリケーション**では外部API応答待ち時間が長くなりがちですが、そのようなモダンなユースケースで真価を発揮するでしょう ([Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community](https://dev.to/andycasen/vercels-fluid-compute-and-what-it-means-for-aws-lambda-38dl#:~:text=Tailor%20made%20for%20Gen%20AI))。

## 実装方法とコード例

実際にFluid Computeを試してみましょう。現在、Node.js（14以降）とPythonランタイムで利用可能です ([Fluid compute](https://vercel.com/docs/functions/fluid-compute#:~:text=Fluid%20compute%20is%20available%20for,the%20following%20runtimes))。設定はとても簡単で、**既存のコードを変更する必要はありません** ([従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey](https://www.publickey1.jp/blog/25/fluid_computevercel.html#:~:text=Fluid%20Compute%E3%81%AFVercel%E3%81%8C%E6%8F%90%E4%BE%9B%E3%81%99%E3%82%8B%E3%82%B5%E3%83%BC%E3%83%90%E3%83%AC%E3%82%B9%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF%E3%81%A7%E3%81%82%E3%82%8B%E3%80%8CVercel%20Functions%E3%80%8D%E3%81%A7%E6%8F%90%E4%BE%9B%E3%81%8C%E9%96%8B%E5%A7%8B%E3%81%95%E3%82%8C%E3%81%A6%E3%81%8A%E3%82%8A%E3%80%81%E6%97%A2%E5%AD%98%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%AA%E3%81%8F%E5%88%A9%E7%94%A8%E5%8F%AF%E8%83%BD%E3%81%A8%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82))。以下の手順でプロジェクトにFluid Computeを有効化できます。

1. Vercelのダッシュボードで対象プロジェクトを開きます。  
2. **Settings** タブ内の **Functions** セクションに移動します。  
3. **Fluid Compute** の項目までスクロールし、トグルスイッチをオンにします ([Fluid compute](https://vercel.com/docs/functions/fluid-compute#:~:text=1,77%20to%20apply%20the%20changes))。  
4. プロジェクトを再デプロイします。これで新しいデプロイからFluid Computeが適用されます。  

有効化後は、新しいデプロイの関数が自動的にFluidモデルで実行されます。例えばNext.jsのAPIルートでストリーミング応答を行う簡単なコードは以下のようになります。

```ts
// pages/api/time-stream.ts
import type { NextApiRequest, NextApiResponse } from 'next';

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  // ストリーミング可能なContent-Typeとキャッシュ無効化ヘッダをセット
  res.setHeader('Content-Type', 'text/event-stream; charset=utf-8');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  // クライアントへ現在時刻を5回ストリーム送信する
  for (let i = 1; i <= 5; i++) {
    const now = new Date().toISOString();
    res.write(`data: ${now}\n\n`);  // SSEのdataフレーム送信
    await new Promise((r) => setTimeout(r, 1000));  // 1秒待つ
  }

  res.end();  // ストリーム終了

  // レスポンス送信後の後処理（ログ出力など）
  console.log('Stream finished at', new Date().toLocaleTimeString());
}
```

上記はシンプルな例ですが、`res.write()`で逐次データを送ることでクライアント側ではリアルタイムに内容を受け取れます。`res.end()`後にログを出力する部分は**ポストレスポンス処理**の例示です。Fluid Computeではレスポンス返却後も関数実行がすぐに終了しないため、このような後処理も可能です ([Fluid compute](https://vercel.com/fluid#:~:text=Post))。  

実行中の関数インスタンスは**複数リクエストを同時に処理する**可能性がある点にも注意してください。例えば別タブからこのAPIをほぼ同時に叩いた場合でも、Fluid Compute有効時には単一インスタンス内で2つのリクエストループが並行して動くことがありえます。結果として一方の`res.write()`実行中に他方のリクエストも進行し、効率的に処理されます。コード上では特別な対応をしなくても、Fluidの仕組みにより自動的にリソースが共有・並行利用される点がポイントです ([Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community](https://dev.to/andycasen/vercels-fluid-compute-and-what-it-means-for-aws-lambda-38dl#:~:text=Vercel%20came%20up%20with%20a,idle%20time%20during%20IO%20operations)) ([Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community](https://dev.to/andycasen/vercels-fluid-compute-and-what-it-means-for-aws-lambda-38dl#:~:text=The%202%20obvious%20benefits%20here,are%20simple))。

なお、Fluid Compute有効化に伴い**関数のデフォルト実行時間上限が延長**されています（Proプラン/Enterpriseでは最大800秒まで） ([Fluid compute](https://vercel.com/docs/functions/fluid-compute#:~:text=Settings%20Hobby%20Pro%20Enterprise%20CPU,85Up%20to%203%20All))。長時間のバッチ処理やストリーミングにも耐えられるため、必要に応じて`vercel.json`や関数内の設定でタイムアウト値(`maxDuration`)を調整してください。またデプロイ地域を複数指定するマルチリージョンデプロイにも対応しているので、グローバルなユーザー相手のAPIでも高速応答が期待できます。

## AWS LambdaやCloudflare Workersとの比較

最後に、Fluid Computeと他の代表的なサーバーレス実行環境との違いを簡潔に整理します。

### AWS Lambdaとの違い

- **実行モデル:** AWS Lambdaは「1リクエストにつき1コンテナ（関数インスタンス）」が原則で、同時リクエスト数だけ並列にインスタンスが増えます ([Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community](https://dev.to/andycasen/vercels-fluid-compute-and-what-it-means-for-aws-lambda-38dl#:~:text=Serverless%20functions%20take%20this%20dilemma,1%20million%20functions%20spun%20up))。一方Fluid Computeは単一インスタンスで複数リクエストを処理できるため、**関数内並行処理**によってインスタンス数の爆発的増加を防ぎます ([従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey](https://www.publickey1.jp/blog/25/fluid_computevercel.html#:~:text=%E3%81%9D%E3%81%93%E3%81%A7Fluid%20Compute%E3%81%A7%E3%81%AF%E3%80%811%E3%81%A4%E3%81%AE%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9%E3%81%AB%E3%81%8A%E3%81%84%E3%81%A6%E8%A4%87%E6%95%B0%E3%81%AE%E9%96%A2%E6%95%B0%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E5%AE%9F%E8%A1%8C%E3%81%A7%E3%81%8D%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%97%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82))。その結果、**コールドスタート頻度も下がり**スケーラビリティの上限も向上します ([従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey](https://www.publickey1.jp/blog/25/fluid_computevercel.html#:~:text=%3E%20%3E%20In))。  
- **リソース効率:** Lambdaでは待機時間も含めリクエストごとに個別のリソースが消費されます。Fluidではアイドル時間に他処理を詰め込むため**CPU・メモリ稼働率が高く**、同じ負荷でも必要リソース総量を削減できます ([Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community](https://dev.to/andycasen/vercels-fluid-compute-and-what-it-means-for-aws-lambda-38dl#:~:text=The%202%20obvious%20benefits%20here,are%20simple))。これは特に外部サービス待ちが発生するワークロードで顕著です。  
- **ストリーミング対応:** Lambdaでも2022年頃からAWS API Gateway経由でストリーミング応答が一部可能になりました。しかしFluid Computeでは**関数が応答後も生きている**ためコネクションを維持しやすく、より直感的にストリーミング実装ができます ([Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community](https://dev.to/andycasen/vercels-fluid-compute-and-what-it-means-for-aws-lambda-38dl#:~:text=Another%20benefit%20with%20Fluid%20Compute,one%20character%20at%20the%20time))。複雑なワークフローなしにチャンク配信やSSEが行える点は開発体験として優れています。  
- **デベロッパー体験:** Vercel上で動作するFluid Computeは、Next.jsなどフレームワークとシームレスに統合された環境です。デプロイやプレビューも含め**フロントエンド開発と一体化**しているため、Lambda単体を用いる場合よりも迅速に機能を提供できます（AWS CDK等での整備をする場合との比較）。その反面、Lambdaは対応言語が豊富でAWSサービス群との統合が容易という利点もあります。Fluid Computeは現時点Node.js/Python限定ですが、Vercelが提供する高レベルなサービス連携（StorageやEdge機能等）を活用できる強みがあります。

### Cloudflare Workersとの違い

- **実行環境:** Cloudflare WorkersはV8エンジン上のアイソレート（Isolate）で動作し、**エッジ（世界中のデータセンター）でグローバルに展開**されます。アイソレートは起動が高速でメモリフットプリントも小さいためコールドスタートが実質的に無視できる一方、Node.js互換ではなくブラウザ的なJavaScriptランタイムです ([How Workers works · Cloudflare Workers docs](https://developers.cloudflare.com/workers/reference/how-workers-works/#:~:text=A%20single%20instance%20of%20the,of%20the%20virtual%20machine%20model)) ([How Workers works · Cloudflare Workers docs](https://developers.cloudflare.com/workers/reference/how-workers-works/#:~:text=Unlike%20other%20serverless%20providers%20which,order%20of%20magnitude%20less%20memory))。Fluid ComputeはRegionベースですがマルチリージョン対応でグローバル冗長性は確保可能です。また**フル機能のNode.jsランタイム**上で動くため、既存のNPMパッケージやネイティブモジュール、Pythonの場合は通常のPyPIパッケージがそのまま利用できます。  
- **並行処理モデル:** Workersもシングルスレッドイベントループ上で複数リクエストを同時処理できる点ではFluidと共通しています ([How Workers works · Cloudflare Workers docs](https://developers.cloudflare.com/workers/reference/how-workers-works/#:~:text=Like%20all%20other%20JavaScript%20platforms%2C,two%20user%20requests%20will%20be))。ただしWorkersは各リクエストの実行時間やCPU使用量に制限があり（デフォルトで数十ms程度のCPU時間制限）、長時間の処理や大容量データ処理には不向きです。一方Fluid Computeは数分以上の実行や高CPU負荷のタスクもこなせるため、**重たいバックエンド処理やAI推論**などにも耐えられます。  
- **コストモデル:** Cloudflare Workersはリクエスト数や帯域に基づいた課金体系（無料枠も広め）ですが、一定以上の規模では従量課金制のWorkers Unboundを利用することになります。Fluid Computeは**GB-時間あたり課金**で、前述のように並行処理による効率化でコスト削減効果が期待できます ([Fluid compute](https://vercel.com/docs/functions/fluid-compute#:~:text=With%20fluid%20compute%20enabled%2C%2010,reduces%20the%20total%20billing%20to))。どちらが経済的かはワークロード次第ですが、**アイドル時間が多い処理ではFluidが有利**でしょう。逆にグローバル展開が必須の超低レイテンシ用途ではWorkersに軍配が上がります。

## まとめ

Fluid Computeは、昨今のAI時代やリアルタイムWeb体験のニーズに応えるために**サーバーレスを再発明したプラットフォーム**と言えます ([Why Vercel overhauled its serverless infrastructure for the AI era](https://www.runtime.news/why-vercel-overhauled-its-serverless-infrastructure-for-the-ai-era/#:~:text=Fluid%20Compute%20is%20a%20new,natural%20evolution%20of%20serverless%20computing))。フロントエンドエンジニアにとってはリアクティブなUIを支える頼もしい武器に、バックエンドエンジニアにとっては効率的なスケーラブルAPI基盤に、インフラエンジニアにとってはコストと運用負荷を抑える安心できる選択肢となるでしょう。実際に**設定はトグルをオンにするだけ**で試せます ([Fluid compute](https://vercel.com/docs/functions/fluid-compute#:~:text=1,77%20to%20apply%20the%20changes))。ぜひ既存プロジェクトでFluid Computeを有効化して、その効果を体感してみてください。今後のサーバーレスインフラの進化にも注目です。