Supabase Edge Functions 实践：Deno ランタイム与グローバルエッジデプロイ

深夜 3 時。モニタリングダッシュボードの赤いラインを凝視していた。API レスポンス時間が 2.3 秒まで急上昇している。

ユーザーは日本、サーバーはオハイオ。光が往復するだけでも 120ms かかる。そこにデータベースクエリ、ビジネスロジック処理が加われば、遅いのは当然だ。

「エッジ関数を試してみたら？」同僚が Slack でメッセージを送ってきた。

正直、懐疑的だった。エッジ関数？ コードを別の場所で実行するだけじゃないか？ どれほどの違いがあるというのか。しかし、テストしてみて驚いた。コールドスタート 120ms、リクエストレスポンス 47ms。同じロジックが、オハイオから東京のエッジノードに移動しただけで、約 5 倍速くなった。

Supabase Edge Functions は Deno ランタイムをベースに、グローバルエッジノードでコードを実行します。本記事では、なぜこれほど高速なのか、Deno と Node.js の違い、ゼロから Edge Function を構築する方法、Cloudflare Workers との選定基準を詳しく解説します。

一、コア概念：Edge Functions とは、なぜ高速なのか

端的に言えば、Edge Functions はコードを「セントラルサーバー」から「エッジノード」へ移動させる仕組みです。

従来、Lambda 関数をデプロイすると、特定のリージョンのサーバー（米東部や欧州など）で実行されます。東京のユーザーがリクエストを送ると、データは太平洋を渡って米東部へ向かい、処理されてから戻ってきます。物理的な距離がレイテンシの下限を決める。光速度に限界があるからです。

Edge Functions は発想を変えました。コードは ESZip というコンパクトな形式にパッケージングされ、グローバル数十箇所のエッジノードへ自動分散されます。東京のユーザーがリクエストすれば、東京のエッジノードでコードが実行され、レスポンス時間から大陸間通信を丸ごと削減できます。

ESZip とは？

Deno チームが開発したパッケージング形式です。従来の JavaScript バンドルとは異なり、ESZip はコードだけでなく、モジュール依存グラフ全体をパッケージします。メリットは何か？ 起動時にネットワークから依存関係を取得する必要がなく、すべてが 1 つのファイルに含まれます。コールドスタート時間が「パッケージ取得 + 解析 + 実行」から「解凍 + 実行」に短縮されます。

Isolate 実行モデル

Supabase Edge Functions は V8 Isolate で実行され、従来のコンテナや仮想マシンではありません。Isolate とは何か？ 超軽量な Worker コンテナと考えればよいでしょう。1 つのプロセスで数十の Isolate を実行でき、各 Isolate が 1 つのリクエストを処理します。コンテナより軽量で、起動も高速です。

Supabase 公式ドキュメントによると、Isolate の CPU 時間上限は 400 秒（ソフトリミット + ハードリミットの合計）です。多く聞こえるかもしれませんが、エッジ関数はヘビーな処理を想定していません。軽量なロジック処理、JWT 検証、リクエスト転送などが主な用途です。重い計算はセントラルサーバーに任せるのが良いでしょう。

シンプルな Edge Function の例を見てみましょう。

// 最もシンプルな Edge Function の例
import "jsr:@supabase/functions-js/edge-runtime.d.ts"

Deno.serve(async (req) => {
  const { name } = await req.json()
  const data = { message: `Hello ${name}!` }
  return new Response(JSON.stringify(data), {
    headers: { "Content-Type": "application/json" }
  })
})

このコードはエッジノードで実行されます。ユーザーリクエストが届くと Deno.serve が受け取り、処理して返します。すべてのプロセスがユーザーに最も近いノードで完結します。

二、Deno ランタイム：Node.js の「セキュアな進化版」

正直に言うと、Deno を初めて耳にした時、ある疑問が浮かびました。Node.js はこれほど成熟しているのに、なぜ新しいランタイムが必要なのか？

答えは意外とシンプルです。Node.js は設計が早すぎて、多くの問題が後になって明らかになりました。

セキュリティの違い

Node.js のデフォルトポリシーは「すべてを信頼する」です。ファイルシステムにアクセスしたい？ 問題なし。ネットワーク接続したい？ ご自由に。システムコマンドを実行したい？ 可能です。つまり、悪意のある依存パッケージが何でもできることを意味します。

Deno は逆です。デフォルトでは、コードは「サンドボックス」内に閉じ込められます。ファイル読み込み不可、ネット接続不可、システムコマンド実行不可。権限が必要な場合は、明示的に宣言する必要があります。

# ネットワーク権限を付与
deno run --allow-net server.ts

# ファイル読み書き権限を付与
deno run --allow-read --allow-write file_ops.ts

# すべての権限を付与（慎重に使用）
deno run -A everything.ts

この設計はエッジ環境で特に重要です。コードがグローバル数十箇所のノードで実行されるため、攻撃を受けると影響範囲が甚大です。

コールドスタートの違い

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

実測データです。同じコードを Deno Deploy と AWS Lambda で実行しました。

3 倍の差があります。理由は複雑ですが、核心は Deno に Node.js の歴史的な負債がないことです。CommonJS 読み込み機構、require 解決、node_modules 検索パスなどがありません。ESZip パッケージングとネイティブ TypeScript サポートにより、多くの起動オーバーヘッドが削減されます。

モジュールシステムの変化

Node.js は CommonJS を使用し、require() でモジュールを読み込みます。npm をインストールし、package.json を作成し、node_modules ディレクトリを構築する必要があります。プロジェクトが大きくなると、このディレクトリは数百メガバイトになることもあります。

Deno は ESM 標準を直接採用しています。npm なし、package.json なし、node_modules なし。インポートは URL を直接記述します。

// URL から直接インポート
import { serve } from "https://deno.land/[email protected]/http/server.ts"

// または JSR（Deno のパッケージリポジトリ）を使用
import { cors } from "jsr:@hono/hono/cors"

初回実行時、Deno はモジュールをダウンロードしてローカルにキャッシュします。以降の起動はキャッシュから直接読み込まれ、ネットワークへパッケージを取得しに行く必要がありません。

TypeScript のゼロ設定

Node.js で TypeScript を実行するには、ts-node をインストールするか、webpack/vite/esbuild を設定し、tsconfig.json を記述する必要があります。Deno にはこれらが不要です。TypeScript をネイティブサポートし、.ts ファイルを直接実行できます。

deno run hello.ts

コンパイルと型チェックがランタイムで完結します。開発体験が大幅に改善されます。

ベンダーロックインの問題

これも懸念していました。Supabase Edge Functions を使用すると、彼らのプラットフォームに縛られるのではないか？

答えは「必ずしもそうではない」です。Deno 自体はオープンソースのランタイムで、Supabase の Edge Runtime もオープンソース化されています（GitHub にソースコードあり）。理論上、自分のサーバーで Edge Runtime を実行できます。もちろん、グローバルエッジネットワークの運用コストは自己負担になりますが、技術的に「逃げられない」という問題はありません。

三、実践：10 分で初めての Edge Function を構築

理論だけでなく、実際に試してみないと良さはわかりません。

公式ドキュメントに従って一通り試しましたが、インストールからデプロイまで 10 分もかかりませんでした。完全なフローは以下の通りです。

ステップ 1：Supabase CLI のインストール

npm install -g supabase

インストール後、バージョンを確認できます。

supabase --version
# 出力例：1.200.0

ステップ 2：プロジェクトの初期化

既存の Supabase プロジェクトがある場合、プロジェクトディレクトリで初期化できます。

supabase init

これにより supabase ディレクトリが作成され、その中に config.toml 設定ファイルが生成されます。

ステップ 3：Edge Function の作成

supabase functions new hello-world

実行後、supabase/functions/hello-world/ に index.ts ファイルが生成されます。内容は概ね以下の通りです。

import "jsr:@supabase/functions-js/edge-runtime.d.ts"

Deno.serve(async (req) => {
  const data = {
    message: "Hello from Edge Function!"
  }

  return new Response(JSON.stringify(data), {
    headers: { "Content-Type": "application/json" }
  })
})

これを独自のロジックに変更できます。例えば、name パラメータを受け取って挨拶を返すようにします。

import "jsr:@supabase/functions-js/edge-runtime.d.ts"

Deno.serve(async (req) => {
  // POST リクエストのみ受け付ける
  if (req.method !== "POST") {
    return new Response("Method not allowed", { status: 405 })
  }

  try {
    const body = await req.json()
    const name = body.name || "Stranger"

    return new Response(JSON.stringify({
      message: `Hey ${name}, welcome to the edge!`,
      timestamp: new Date().toISOString()
    }), {
      headers: { "Content-Type": "application/json" }
    })
  } catch (err) {
    return new Response(JSON.stringify({ error: "Invalid JSON" }), {
      status: 400,
      headers: { "Content-Type": "application/json" }
    })
  }
})

ステップ 4：ローカルテスト

Supabase CLI は Edge Function のローカル実行をサポートしており、デバッグに便利です。

supabase functions serve --no-verify-jwt

これによりローカルでサーバーが起動します。デフォルトポートは 54321 です。curl でテストできます。

curl -X POST http://localhost:54321/functions/v1/hello-world \
  -H "Content-Type: application/json" \
  -d '{"name":"Easton"}'

# 戻り値：
# {"message":"Hey Easton, welcome to the edge!","timestamp":"2026-05-03T14:30:00.000Z"}

--no-verify-jwt パラメータは JWT 検証をスキップすることを意味し、ローカルテストに便利です。本番環境では検証を有効にすることをお勧めします。

ステップ 5：グローバルへのデプロイ

ローカルテストが問題なければ、Supabase エッジネットワークへデプロイします。

# まずログイン（まだログインしていない場合）
supabase login

# プロジェクトをリンク
supabase link --project-ref <your-project-id>

# 関数をデプロイ
supabase functions deploy hello-world

デプロイ完了後、Supabase は関数をグローバルエッジノードへ分散します。Dashboard でデプロイログと関数 URL を確認できます。

ステップ 6：呼び出しテスト

関数デプロイ後の URL 形式は以下の通りです。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

https://<project-id>.supabase.co/functions/v1/hello-world

curl で呼び出します。

curl -X POST https://<project-id>.supabase.co/functions/v1/hello-world \
  -H "Authorization: Bearer <anon-key>" \
  -H "Content-Type: application/json" \
  -d '{"name":"World"}'

Authorization ヘッダーに注意してください。Supabase Edge Functions はデフォルトで JWT を検証するため、プロジェクトの anon key またはユーザー JWT token を含める必要があります。

さて、Edge Function で何ができるのか？ デモ以外にも実用的なシナリオはたくさんあります。

Webhook 処理

例えば Stripe の支払い成功後に Webhook が送信される場合、Edge Function で受信してデータベースに書き込めます。

// supabase/functions/stripe-webhook/index.ts
import "jsr:@supabase/functions-js/edge-runtime.d.ts"
import { createClient } from "jsr:@supabase/supabase-js@2"

Deno.serve(async (req) => {
  // Stripe 署名を検証（ここでは簡略化、実際は hmac 検証が必要）
  const event = await req.json()

  const supabase = createClient(
    Deno.env.get("SUPABASE_URL")!,
    Deno.env.get("SUPABASE_SERVICE_ROLE_KEY")!
  )

  if (event.type === "payment_intent.succeeded") {
    const payment = event.data.object

    await supabase.from("payments").insert({
      id: payment.id,
      amount: payment.amount,
      customer_id: payment.customer,
      created_at: new Date().toISOString()
    })
  }

  return new Response(JSON.stringify({ received: true }), {
    headers: { "Content-Type": "application/json" }
  })
})

API プロキシ

サードパーティ API に API Key が必要で、フロントエンドに公開したくない場合、Edge Function をプロキシとして使用できます。

// supabase/functions/openai-proxy/index.ts
Deno.serve(async (req) => {
  const body = await req.json()

  const response = await fetch("https://api.openai.com/v1/chat/completions", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${Deno.env.get("OPENAI_API_KEY")}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify(body)
  })

  return new Response(response.body, {
    headers: { "Content-Type": "application/json" }
  })
})

フロントエンドは Edge Function を直接呼び出し、API Key はエッジノードに隠蔽されます。

四、選定基準：Supabase vs Cloudflare Workers

エッジコンピューティングの話になると、多くの人が「Cloudflare Workers と Supabase Edge Functions、どちらが良い？」と聞きます。

正直なところ、この 2 つは直接の競合ではありません。シナリオが異なれば、選択も自然と異なります。

パフォーマンス比較

コールドスタート時間から見ると、Cloudflare Workers の方が高速です。公式データでは ~30ms に対し、Supabase Edge Functions は ~120ms です。

違いはどこにあるか？ Cloudflare の Workers runtime は独自開発で、エッジシナリオに特化して最適化されています。Supabase は Deno を使用しており、高速ですが TypeScript コンパイルのレイヤーが 1 つ増えます。

実際の体感はどうか？ ほとんどのシナリオで、120ms と 30ms の差はユーザーが認識できません。Web リクエスト自体のネットワーク変動の方が大きいためです。ただし、高頻度取引やリアルタイムオークションなどミリ秒を争うビジネスでは、Cloudflare Workers が適しています。

統合性比較

これは Supabase の強みです。Supabase Edge Functions を使用すると、同じプロジェクトの Postgres データベースに直接接続し、Auth サービスを呼び出し、Storage にアクセスできます。環境変数は自動的に注入され、追加設定が不要です。

Cloudflare Workers はデータベース接続を自分で構築する必要があります。Cloudflare D1（彼らの SQLite エッジデータベース）を使用するか、外部データベースに接続できます。設定には少し手間がかかります。

ベンダーロックイン

これは興味深い話題です。Cloudflare Workers の runtime はクローズドソースです。書いたコードは Cloudflare でしか実行できず、プラットフォームを変えるにはコードの修正が必要です。

Supabase Edge Functions はオープンソースの Deno を使用しています。理論上、同じコードを Deno Deploy わ自己ホストの Edge Runtime に移行できます。もちろん、Supabase のエッジネットワーク自体は移動できませんが、少なくともランタイムレベルではロックインされていません。

エコシステム比較

Cloudflare Workers のエコシステムはより成熟しています。2017 年にリリースされ、多くのツール、フレームワーク、コミュニティの経験が蓄積されています。Hono、Remix フレームワークなどが Workers runtime をサポートしています。

Supabase Edge Functions は 2022 年にリリースされたばかりで、エコシステムはまだ成長期です。ただし、標準的な Deno を使用しているため、多くの Deno ライブラリが直接利用可能です。

選定のアドバイス

具体的な状況に応じて、私の大まかな判断マトリックスを紹介します。

私は現在、ハイブリッドで使用しています。Cloudflare Workers はフロントエンドのリバースプロキシとキャッシュ、Supabase Edge Functions は Auth 関連ロジックとデータベース操作を処理。2 つのプラットフォームの長所を活かしています。

五、遭遇した落とし穴とベストプラクティス

実践で遭遇した落とし穴を紹介します。回避していただければ幸いです。

落とし穴 1：Node.js パッケージを使用してしまった

HTTP リクエストを送るために axios を使おうと、import axios from "axios" と書きました。デプロイしたら即座にエラー。モジュールが見つからない。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

Edge Functions は Deno を使用しており、Node.js ではありません。npm パッケージは直接使用できません。Deno 互換のパッケージに変更するか、Deno ネイティブの fetch API を使用する必要があります。実際、fetch で十分です。

// axios は使わない
// import axios from "axios"  // この行はエラーになる

// fetch を使用
const response = await fetch("https://api.example.com/data", {
  method: "GET",
  headers: { "Authorization": "Bearer xxx" }
})
const data = await response.json()

axios に似たライブラリが必要な場合は、Deno エコシステムの alternatives、例えば ky などを使用できます。

落とし穴 2：関数が長時間実行されて強制終了された

ある時、数千件のレコードを走査して計算するバッチ処理関数を書きました。ローカルテストは問題なかったのに、デプロイしたら 30 秒で切断されました。

原因はシンプルです。Edge Functions には CPU 時間制限があります。公式ドキュメントによると、Isolate の上限は 400 秒（ソフトリミットとハードリミットの合計）。制限を超えると、プロセスは強制終了されます。

解決策は、Edge Function でヘビーな処理をしないこと。エッジノードは軽量なロジック処理に適しています。検証、転送、簡単な計算など。複雑なバッチ処理はセントラルサーバーまたは専用の Worker サービスに任せましょう。

落とし穴 3：データベース接続方法が間違っていた

エッジ環境で Postgres に接続する場合、従来の長時間接続を使用すると問題が発生します。エッジノードの数が多いため、各ノードが 1 つの長時間接続を確立すると、データベース接続プールがすぐに溢れます。

推奨される方法は、Supabase が提供する接続プール（Pooler）を使用するか、リクエストごとにショート接続を作成して即座に解放することです。Supabase 公式の SUPABASE_DB_URL 環境変数は Pooler を指しています。

import { Pool } from "https://deno.land/x/[email protected]/mod.ts"

const pool = new Pool(Deno.env.get("SUPABASE_DB_URL")!, 10)

Deno.serve(async (req) => {
  const client = await pool.connect()
  try {
    const result = await client.queryArray("SELECT * FROM users LIMIT 10")
    return new Response(JSON.stringify(result.rows))
  } finally {
    client.release()  // 解放を忘れずに！
  }
})

落とし穴 4：JWT 検証を設定していなかった

ローカルテストでは --no-verify-jwt を使用していました。デバッグに便利です。デプロイ後に検証を有効にするのを忘れ、誰でも関数を呼び出せる状態になっていました。セキュリティリスクはかなり大きいです。

正しい方法は config.toml で設定することです。

[functions.hello-world]
verify_jwt = true

またはデプロイ時に指定します。

supabase functions deploy hello-world --verify-jwt

いくつかの実用的なテクニック

1. Hono フレームワークでネイティブ Deno.serve を置き換える

Hono は超軽量な Web フレームワークで、エッジ環境に特化して設計されています。ルーティング、ミドルウェアをサポートしながら、サイズはわずか 13KB です。Express の肥大化と比較して、Hono は Edge Functions に非常に適しています。

import { Hono } from "jsr:@hono/hono"
import { cors } from "jsr:@hono/hono/cors"

const app = new Hono()

app.use("*", cors())

app.get("/health", (c) => c.json({ status: "ok" }))

app.post("/echo", async (c) => {
  const body = await c.req.json()
  return c.json({ echo: body })
})

Deno.serve(app.fetch)

2. 環境変数管理

Supabase Edge Functions には 2 つのランタイムがあります。Main Runtime（Supabase プラットフォームが制御）と User Runtime（あなたのコード）。環境変数の権限は異なります。

• SUPABASE_URL、SUPABASE_ANON_KEY、SUPABASE_SERVICE_ROLE_KEY は自動的に注入され、コードで直接使用可能
• カスタム変数は Dashboard または CLI で設定：supabase secrets set MY_VAR=value

3. Import Map で重複解析を削減

関数が多くの外部モジュールに依存している場合、Import Map で事前定義し、リクエストごとに URL を解析するオーバーヘッドを削減できます。

// deno.json または import_map.json
{
  "imports": {
    "hono": "jsr:@hono/hono",
    "supabase-js": "jsr:@supabase/supabase-js@2"
  }
}

コード内でショートネームを直接使用できます。

import { Hono } from "hono"
import { createClient } from "supabase-js"

まとめ

ここまで説明してきましたが、核心は一文に集約されます。Supabase Edge Functions はコードをユーザーに最も近いノードにプッシュし、安全な Deno ランタイムで実行します。コールドスタートは 120ms、グローバル分散は自動的に完了します。

プロジェクトですでに Supabase を使用している場合、Auth、Database、Storage のいずれであっても、Edge Functions は自然な延長です。データベース接続に苦労する必要も、Auth 検証を別途設定する必要もありません。すべてのサービスが直接連携できます。ベンダーロックインが心配ですか？ Deno はオープンソースで、Edge Runtime は自己ホスト可能です。少なくとも「逃げる」選択肢はあります。

次に何をすべきか？ Supabase Dashboard を開き、Quickstart に従って一通り試してみてください。10 分以内に、あなたの最初の Edge Function がグローバルエッジノードで実行されます。

本シリーズの他の記事もぜひご覧ください：

• Supabase 入門：PostgreSQL + Auth + Storage 一站式后端——Supabase の全体像を理解する
• Supabase Auth 实战：邮箱验证、OAuth 与会话管理——認証サービスの実践
• Supabase Auth 深度配置：OAuth、SSO 与权限控制——高度な設定

Cloudflare Workers に興味がある方は、こちらの記事もご覧ください：Cloudflare Workers 实战指南。2 つのプラットフォームにはそれぞれ長所があります。最適な方を選んでください。

8 min read · 公開日: 2026年5月3日 · 更新日: 2026年5月4日

Easton

技術開発