設定はたった1行
Vercel Functionsでは2025年10月27日からBunランタイムがパブリックベータとして利用可能になりました。驚くほど簡単で、vercel.jsonに以下を追加するだけです。
{
"bunVersion": "1.x"
}これだけで、Vercelがビルド時にBunを自動検出してインストールしてくれます。バージョンを"1.x"と指定することで、マイナーバージョンとパッチバージョンはVercelが自動管理してくれるのも地味にありがたい。
Next.jsで使う場合の設定
.png)
Next.jsプロジェクトでBunを使う場合、package.jsonのスクリプトも変更が必要です。
{
"scripts": {
"dev": "bun --bun next dev",
"build": "bun --bun next build",
"start": "bun --bun next start"
}
}--bunフラグがポイントで、これによってNext.js CLIがBunランタイム上で実行されます。TurbopackやWebpackによるバンドル処理は従来通り行われますが、JavaScript実行やファイル読み込み、レスポンス提供などはBunが担当するようになります。
なぜBunは速いのか
Vercelの内部ベンチマークによると、BunはCPUバウンドなNext.jsレンダリングワークロードでNode.jsと比較して平均レイテンシを28%削減したそうです。
この速度差の要因はいくつかあります。まずWeb Streams実装の最適化。Node.jsのWeb Streams実装では、バッファスキャンやデータ変換にCPUコストがかかっていましたが、Bunはこの部分を効率化しています。
次にガベージコレクションのオーバーヘッド削減。高負荷時のGC処理時間が短くなっています。
そして根本的な話として、BunはZig言語で実装されていて、低レイヤでのメモリ管理が効率的。I/OとスケジューリングもJavaScriptエンジンに依存せず最適化されています。
Bun固有のAPIが使える
個人的に一番嬉しいのはこれ。Bunランタイム上では、Node.jsにはないBun固有のAPIが全部使えます。
import { sql, s3 } from 'bun';
export default async function BlogPage({ params }: { params: { slug: string } }) {
// Bun.SQLで直接DBアクセス
const [post] = await sql\`
SELECT title, image_key, content_html
FROM posts
WHERE slug = \${params.slug}
\`;
// Bun.S3で署名付きURL生成
const imgUrl = s3.file(post.image_key).presign({ expiresIn: 3600 });
return (
<article>
<h1>{post.title}</h1>
<img src={imgUrl} alt={post.title} />
<div dangerouslySetInnerHTML={{ __html: post.content_html }} />
</article>
);
}Bun.SQLは組み込みのデータベースクライアントで、Bun.S3はS3との統合機能。アダプタや追加設定なしでそのまま動くのが楽すぎる。
他にもBun.fileによる高性能ファイル操作や、Bun.password.hashによるパスワードハッシュ機能など、便利なAPIが揃っています。
注意点とトレードオフ
ただし、いくつか制限があります。
まずBun.serveはVercel Functionsではサポートされていません。Vercelがサポートするフレームワーク（Next.js、Express、Hono、Nitro）と組み合わせて使う必要があります。
次に自動ソースマップが非対応。デバッグ時にスタックトレースがトランスパイル後のコードを指すので、少し不便かもしれません。
あとはNode.js API互換性の問題。Bunは互換性を実装していますが、カバレッジは拡大中で、エッジケースでの動作差異がある可能性があります。本番トラフィックを移行する前に、すべての依存関係をBunでテストしておくことをおすすめします。
どんな場面で使うべきか
Bunランタイムが向いているのはこんな場面です。
CPUバウンドなタスクの高速実行が必要な場合、例えばSSRや計算集約型の処理。ゼロ設定でTypeScriptを使いたい場合。新規プロジェクトでモダンなツーリングを活用したい場合。
逆に、最大の互換性が必要だったり、自動ソースマップが必須だったり、node:http/node:httpsモジュールでの詳細なリクエストメトリクスが必要な場合は、Node.jsのままの方が良いでしょう。
Routing Middlewareの注意点
Next.jsのRouting MiddlewareをBunランタイムで使う場合、ちょっとした設定が必要です。
// middleware.ts
export const config = { runtime: "nodejs" };
export function middleware(request: NextRequest) {
// ミドルウェア処理
}ランタイム設定を明示的にnodejsに指定する必要があります。これを忘れると動作が不安定になることがあるので要注意。
実際に試してみた感想
正直、28%の速度向上は体感できるレベルでした。特にSSRが多いページでは、First Contentful Paintまでの時間が目に見えて短くなります。
ただし、パブリックベータということもあり、プロダクション環境にいきなり全面導入するのは少し怖い。まずはステージング環境で十分にテストしてから、徐々にカナリアリリースしていくのが現実的なアプローチだと思います。
RailwayやRender、Docker環境では既にBunがサポートされていたので、Vercelでのサポートによって主要なデプロイプラットフォームでBunが使えるようになったのは大きな進歩です。
まとめ
- Vercel Functionsで
bunVersion: "1.x"を設定するだけでBunランタイムが有効化 - Node.js比で平均28%のレイテンシ削減を実現
- Bun.SQL、Bun.S3など固有APIがそのまま使える
- ソースマップ非対応やAPI互換性の制限に注意
- 新規プロジェクトやCPUバウンドな処理に特におすすめ
