エッジコンピューティングとは？CDN・エッジ関数・オリジンの違いと選び方

「東京から見たら一瞬で開くのに、海外のユーザーから『遅い』ってクレームが来る」

数年前、僕が運用していた小さなサイトで実際にあった話です。サーバーは東京のデータセンターに1台。日本の自分が見るぶんには爆速。でもブラジルからのアクセスは、地球の裏側まで往復していたわけです。光の速さでも、片道で200ミリ秒くらいかかる。ページを開くだけで何度も往復するので、体感はもっと遅くなります。

このとき初めて「処理する場所」を意識しました。コードを速くするんじゃなくて、コードをユーザーの近くに置く。それがエッジコンピューティングの出発点です。

ただ、調べ始めると専門用語の渋滞に巻き込まれます。CDN、エッジ関数、オリジン、Workers、Lambda@Edge……。どれも「速くなる何か」っぽいのに、違いがはっきりしない。この記事は、そこを身近な言葉で整理して、「自分の場合どれを使えばいいのか」まで一気に分かるようにしたものです。手を動かす実装の細かいところは別記事に送るので、ここは安心して「考え方」に集中してください。

この記事の要点

• エッジとは「ユーザーに物理的に近い、世界中に散らばった小さな処理拠点」のこと。速い理由はシンプルで、データの往復距離が短いから。
• CDN・エッジ関数・オリジンは役割が違う。CDNは「コピーを配るキャッシュ」、エッジ関数は「近くで動く小さなプログラム」、オリジンは「正本（マスターデータ）を持つ本拠地」。
• エッジが向くのは、URL・ヘッダー・Cookieだけで判断できる軽くて速い処理。DBを深く読む処理や決済確定は向かない。
• 主要3つは性格が違う。Cloudflare Workers=軽量で世界最速級、Vercel Edge=Next.jsとの一体感、AWS Lambda@Edge=既存AWS資産との接続。
• 「全部エッジに移す」のは事故のもと。入口の判断だけ近くに置き、重い処理は本拠地に残すのが鉄則。

エッジって、そもそもどこのこと？

エッジ（edge）は直訳すると「端」「縁」です。ネットワークの世界では、利用者に一番近い末端の拠点を指します。

イメージしやすいのはコンビニです。商品の在庫を全部、巨大な物流センター1か所に置いていたら、遠くの人は受け取りに時間がかかる。だから街角にコンビニを置いて、よく出る商品を近くに並べておく。あれと同じ発想で、世界中の都市に小さな処理拠点をばらまいておくのがエッジです。

東京の人は東京の拠点、ロンドンの人はロンドンの拠点で処理が返る。だから速い。「賢いから速い」のではなく「近いから速い」——ここが一番大事なところです。コードのアルゴリズムをいくら磨いても、地球の裏側との往復は消えません。でも処理する場所を近づければ、往復そのものが短くなる。

CloudflareやVercel、AWSといった事業者は、こうした拠点を世界中に数百カ所持っています。Cloudflareはこの拠点を「colo（コロ、データセンター識別子）」と呼びます。僕らはそのネットワークに小さなプログラムを置かせてもらうだけで、自前で世界中にサーバーを建てなくても「近さ」を手に入れられる。これがここ数年で一気に普及した理由です。

CDN・エッジ関数・オリジンは何が違う？

ここが一番こんがらがるポイントなので、役割をはっきり分けます。3つは競合ではなく、協力して1つのリクエストを処理する仲間です。

用語	役割	身近な例え	何を持っている／できる
オリジン	正本（マスター）を持つ本拠地	本社・物流センター	DB、認証、決済、すべての確定処理
CDN	コピーを近くに配るキャッシュ	各地のコンビニの棚	画像・CSS・JSなど「同じものを大量配布」
エッジ関数	近くで動く小さなプログラム	コンビニ店員のその場判断	URL・ヘッダー・Cookieを見て分岐・加工

順番に見ていきます。

**オリジン（origin）**は、あなたのアプリの本拠地です。データベースがあり、ユーザー認証があり、決済の確定処理が走る。世界に1つ（または数カ所）だけ。ここが「正本」を持っています。

**CDN（Content Delivery Network）**は、そのオリジンにある静的ファイル——画像やCSS、JavaScriptなど、誰がアクセスしても中身が同じもの——を世界中の拠点にコピーして配る仕組みです。コンビニの棚によく出る商品を並べておくのと同じ。ただし、CDNが配るのは基本的に「できあいのコピー」。その場で中身を作り変えることはしません。

エッジ関数（Edge Functions）は、その拠点で実際にコードを動かす仕組みです。ここがCDNとの決定的な違い。CDNが「棚から出すだけ」の店員だとしたら、エッジ関数は「お客さんの様子を見て対応を変えられる」店員です。日本からのアクセスなら日本語ページへ、ログイン済みなら専用バナーを、といったその場の判断ができます。

つまりCDNとエッジ関数の違いを一言でいうと、CDNは静的なコピーを配るだけ、エッジ関数は近くで小さなプログラムを実行できる。この一文を押さえれば、もう用語に迷いません。最近は両者の境界が溶けてきて、CDN事業者がそのままエッジ関数を提供する形が主流です。

flowchart LR
  User["ユーザー（東京）"] --> Edge["エッジ拠点（近い）"]
  Edge -->|キャッシュにあれば即返す| CDN["CDNキャッシュ"]
  Edge -->|その場で判断・加工| Func["エッジ関数"]
  Func -->|重い処理だけ問い合わせ| Origin["オリジン（本拠地・DB）"]
  Origin --> Queue["キュー／バックグラウンド処理"]

なぜエッジは速いのか（距離と往復の話）

「近いから速い」をもう少しだけ掘ります。Webの遅さの正体は、多くの場合往復回数（ラウンドトリップ）×距離です。

ブラウザがサーバーと通信するとき、接続を確立するだけでも数回のやり取りが発生します。HTTPS（暗号化通信）だと、暗号鍵の交換でさらに往復が増える。1往復ごとに「物理的な距離 ÷ 光の速さ」の時間がかかります。東京〜サンパウロは片道でだいたい200ミリ秒前後。これを数回繰り返すと、データを1バイトも送る前に1秒近く溶けることもあります。

エッジに処理を置くと、この往復の相手が「地球の裏側のオリジン」から「すぐ近くの拠点」に変わります。往復1回が200ミリ秒から数ミリ秒へ縮む。処理時間そのものより、距離が消えることの効果が大きいんです。

だからエッジが一番効くのは、「軽い処理だけど、必ず通る入口」です。リダイレクト、言語の出し分け、A/Bテストの振り分け、軽い認証チェック。こういう「全リクエストが通過するけど中身は軽い」処理をユーザーの近くに置くと、体感がガラッと変わります。逆に、処理自体に時間がかかるもの（重いDB読み込みなど）は、近くに置いても劇的には速くなりません。詳しい速度改善の考え方はClaude Codeでパフォーマンスを最適化する手順にまとめてあります。

エッジに向く処理・向かない処理

ここを間違えると「速くするはずが、制約で詰まる」事故になります。判断基準はシンプルで、リクエストのURL・ヘッダー・Cookie・短い本文だけで答えが出せるかです。出せるならエッジ向き。DBを深く読んだり外部APIを何度も叩いたりするなら、オリジン向きです。

処理	置き場所	理由
地域・言語による表示の出し分け	エッジ	国コードや言語ヘッダーで入口を即分岐できる
短時間キャッシュの出し入れ	エッジ	近い拠点でレスポンスを返せる
A/Bテストの振り分け	エッジ	Cookieを見てページ到達前に決められる
軽い認証ゲート（プレビュー保護など）	エッジ	入口で早めに弾ける
Webhookの署名検証（入口だけ）	エッジ	署名だけ確認して内部APIへ渡せる
税金・請求・在庫の確定	オリジン	正本データと整合性が必要
重いLLM呼び出し・画像変換	オリジン	実行時間とメモリの制約に引っかかる
複雑なDB読み書き（ORM経由など）	オリジン	コネクション管理と実行時間がきつい

ひとつ強めに言っておきたいのが、地域情報を信用しすぎないことです。request.cf.country（Cloudflare）やx-vercel-ip-country（Vercel）は便利ですが、VPN・企業プロキシ・キャリアの設定で簡単にズレます。「日本語で表示する」程度の出し分けには使っていい。でも本人確認・課金・年齢確認・権限判定の根拠にしてはいけません。重要な判断は、必ず認証済みユーザー情報やオリジン側の確定データで行います。

主要3プラットフォームの選び方

ここからが本題の「選び方」です。エッジ関数を提供する事業者はいくつもありますが、実務でまず候補に挙がるのはこの3つ。性格がはっきり違うので、自分のスタックに合わせて選びます。数値は2026年6月時点の公式ドキュメント（Cloudflare Workersの制限、Vercel Edge Runtime、Lambda@EdgeとCloudFront Functionsの違い）を確認したものです。

	Cloudflare Workers	Vercel Edge	AWS Lambda@Edge
実行環境	V8アイソレート	V8アイソレート	Node.js / Python（コンテナ寄り）
言語	JS / TS / Wasm	JS / TS	Node.js / Python
実行時間の目安	無料10msCPU、有料は標準30秒・最大5分	25秒以内に応答開始、ストリームは最大300秒	最大30秒
メモリ	128MB	V8アイソレート（軽量）	128MB〜10GB（イベント次第）
Node API（fs等）	原則Web標準のみ	原則Web標準のみ	使える（ネットワーク・FSアクセス可）
向いている人	とにかく軽く速く世界配信したい	Next.jsを使っている	既存のAWS資産とつなぎたい

Cloudflare Workersは、軽量さと速さに振り切った選択肢です。V8アイソレート（コンテナを立てず、軽いサンドボックスで一瞬で起動する方式）なので起動が速く、世界中の拠点に展開されます。fsなどNode専用APIは原則使えず、Request／Response／URL／cryptoといったWeb標準で書くのが基本。KV（簡易キーバリュー）やD1（SQLite）、R2（ストレージ）といったエッジ用のデータ置き場も揃っています。「迷ったらまずこれ」で外しにくい。具体的なwrangler（CLI）でのローカル開発からデプロイ、KV/D1/R2の使い分けまではCloudflare Workers入門：wranglerでKV/D1/R2を使う実践ガイドに手順を全部書いたので、手を動かすならそちらへ。

Vercel Edgeは、Next.jsを使っているなら自然な選択です。とくにEdge Middleware（ページが描画される前にリクエストへ割り込める仕組み）で、リダイレクトやA/Bテストの振り分けを書くのが得意。こちらもWeb標準API中心でfsは使えません。ひとつ最新情報として押さえておきたいのが、Vercel公式が今はEdgeより通常のNode.jsランタイムへの移行を推奨し始めている点です（Fluid computeという新しい実行基盤の登場が背景）。新規でVercelを使うなら、Edgeに飛びつく前に「本当にEdgeである必要があるか」を一度立ち止まって考えるといい。安全な使い方はClaude CodeでVercel Edge Functionsを安全に使う実務ガイドに整理してあります。

AWS Lambda@Edgeは、すでにAWSにどっぷりな人向けです。Node.jsやPythonが動き、他のエッジ関数と違ってネットワークアクセスやファイルシステムアクセスができる。AWSのSDKを使って他サービスと連携する、といった「ちょっと重め」のエッジ処理もこなせます。ただしリージョンあたりのスループット上限があり、超軽量な処理にはオーバースペック。AWSには別途、JSのみ・サブミリ秒・超軽量の「CloudFront Functions」もあるので、キャッシュキーの正規化やヘッダー操作だけならそちらが向きます。Lambda全般の考え方はClaude Codeでサーバーレス関数を作る実践ガイドも参考になります。

コピペで動く：エッジの「入口判断」を体験する

概念だけだとピンと来ないので、エッジ関数が何をしているかを手元で体験できる最小コードを置いておきます。これはどのプラットフォームでも共通する「入口でURL・ヘッダーを見て分岐する」という考え方そのもので、特定の事業者に依存しません。Web標準APIだけで書いてあるので、ローカルのDenoで動きます。

// edge-router.ts — エッジ関数の「入口判断」をWeb標準APIだけで再現する最小例
// 実行: deno run --allow-net edge-router.ts （Denoが必要）

// 国コードから表示ロケールを決める。重要な判断には使わず「表示の出し分け」だけに使う
function localeFromCountry(country: string): string {
  const map: Record<string, string> = {
    JP: "ja",
    KR: "ko",
    CN: "zh",
    TW: "zh",
    FR: "fr",
    DE: "de",
    BR: "pt",
  };
  return map[country] ?? "en"; // 知らない国は英語にフォールバック
}

// 国ごとのCTA（行動喚起）文言。これがエッジで出し分けたい「中身」
function ctaFor(locale: string): string {
  const cta: Record<string, string> = {
    ja: "Claude Code教材を見る",
    en: "Explore Claude Code templates",
    ko: "Claude Code 템플릿 보기",
    zh: "查看 Claude Code 教材",
    fr: "Voir les modèles Claude Code",
    de: "Claude Code Vorlagen ansehen",
    pt: "Ver modelos de Claude Code",
  };
  return cta[locale] ?? cta.en;
}

Deno.serve((request: Request) => {
  const url = new URL(request.url);

  // ヘルスチェック用の入口
  if (url.pathname === "/health") {
    return Response.json({ ok: true, runtime: "edge-demo" });
  }

  // ここがエッジ関数の心臓部：ヘッダーを見て、その場で応答を変える
  // 本番ではプラットフォーム固有のヘッダー(CF-IPCountry / x-vercel-ip-country)が入る
  const country = (request.headers.get("x-country") ?? "US").toUpperCase();
  const locale = localeFromCountry(country);

  return Response.json({
    country,
    locale,
    cta: ctaFor(locale),
    note: "国コードは表示の出し分け専用。課金や権限の判断には使わないこと",
  });
});

動かしたら、別のターミナルからcurlでヘッダーを変えて叩いてみてください。countryを変えるだけで、返ってくるlocaleとctaが切り替わるのが分かります。

# 日本向けの応答
curl -s -H "x-country: JP" http://localhost:8000/

# 米国向けの応答（フォールバックの英語）
curl -s -H "x-country: US" http://localhost:8000/

# 未対応の国 → 英語にフォールバックされる
curl -s -H "x-country: ZZ" http://localhost:8000/

たったこれだけですが、「入口でヘッダーを見て、その場で応答を作り変える」というエッジ関数の本質が体験できます。あとはこれを実際のプラットフォームに載せ、キャッシュやデータ置き場をつなげていくだけ。その先の本番実装は前述の各プラットフォーム記事に送ります。

僕がやらかした失敗3つ

エッジは「速くなる」と聞いて飛びつくと、だいたい一度は転びます。僕の失敗を正直に置いておきます。

ひとつ目は、重い処理までエッジに押し込んだこと。「全部近くで処理すれば最速だろう」と、画像のリサイズやそこそこ重いDB集計までエッジに載せました。結果、実行時間の制約に引っかかってタイムアウト連発。エッジは「軽い入口判断」の場所だと痛感しました。今は「URL・ヘッダー・Cookieで答えが出るか？」を毎回自分に問うようにしています。

ふたつ目は、キャッシュキーの設計をサボったこと。日本語と英語で中身が違うのに、同じキーでキャッシュしてしまい、米国のユーザーに日本語のCTAが返る事故が起きました。逆に、utm_sourceのような広告パラメータまでキーに含めてしまって、ほぼキャッシュが効かなくなったこともあります。「何で中身が変わるか」を洗い出してキーに入れる。これを最初にやらないと、必ずどこかで漏れます。

みっつ目は、地域情報を信じすぎたこと。countryを見て出し分けるだけなら問題なかったのに、一時期そこに割引の出し分けまで乗せてしまった。VPN経由のユーザーが意図しない価格を見る状態になって、慌てて戻しました。地域情報は「体験のヒント」であって「確定の根拠」じゃない。痛い勉強代でした。

よくある質問

Q. CDNとエッジ関数は、結局どう使い分ければいいですか？ A. 「中身が誰でも同じ静的ファイル（画像・CSS・JS）」はCDNに任せ、「リクエストごとに中身を変えたい処理」はエッジ関数で書きます。実際には両方を同じ事業者でまとめて使うのが普通で、CDNがキャッシュを返しつつ、必要なときだけエッジ関数が割り込む構成になります。

Q. エッジに置けば、どんなサイトでも速くなりますか？ A. いいえ。速くなるのは「軽い処理が全リクエストで通る入口」です。処理自体が重い（DBを深く読む、外部APIを何度も叩く）場合は、近くに置いても劇的には速くなりません。むしろ実行時間の制約で詰まることがあります。

Q. 3つのうち、最初に試すならどれですか？ A. 特定のスタックに縛られていないなら、Cloudflare Workersが学びやすく外しにくいです。Next.jsを使っているならVercel Edge、すでにAWS中心ならLambda@Edge。「今あるもの」に寄せるのが一番ラクです。

Q. エッジ関数でNode.jsのfsやライブラリは使えますか？ A. Cloudflare WorkersとVercel Edgeは原則Web標準APIのみで、fsは使えません。Node専用のライブラリも動かないことが多いです。AWS Lambda@Edgeは例外でNode.jsが動き、ファイルシステムやネットワークアクセスもできます。

Q. 国コードで価格や年齢制限を出し分けてもいいですか？ A. やめたほうがいいです。国コードはVPNやプロキシで簡単にズレます。表示言語の初期値くらいには使えますが、課金・権限・年齢確認は必ず認証済み情報やオリジン側の確定データで判断してください。

実際に試した結果

冒頭の「海外から遅い」問題は、リダイレクトと言語の出し分けをエッジに移しただけで、体感がはっきり変わりました。サーバーのコードは1行も速くしていません。やったのは「処理する場所を近づけた」だけ。それで往復が消えた。

そこから学んだのは、エッジ設計は技術というより仕分けの判断だということです。この処理は入口で答えが出るか、それとも本拠地の正本が要るか。そこさえ正しく分けられれば、どのプラットフォームを選んでも大きくは外しません。逆にそこを間違えると、最速のはずのエッジで一番遅いタイムアウトを食らいます。

迷ったら、まず一番小さくて戻せる処理——リダイレクトか言語の出し分け——をひとつだけエッジに移してみてください。効果が一番分かりやすく、失敗しても被害が小さい。そこで手応えをつかんでから、各プラットフォームの実装記事に進むのがおすすめです。手元にテンプレートを置いて学びたい場合はClaudeCodeLabの教材一覧、チームでエッジとオリジンの境界線を整えたい場合はClaude Code研修・導入相談が役に立つはずです。

まとめ

エッジコンピューティングは「全部をエッジに移す話」ではありません。ユーザーの近くに置くべきは、URL・ヘッダー・Cookieで判断できる軽い入口処理だけ。重い処理と確定判断は、これまで通りオリジン（本拠地）に残します。CDNは静的なコピーを配り、エッジ関数が近くで小さな判断をし、オリジンが正本を守る——この役割分担さえ頭に入れば、Cloudflare Workers・Vercel Edge・Lambda@Edgeのどれを選んでも、速いだけでなく事故りにくい設計になります。