サーバレスが変えた“バックエンドという概念”
🧭 はじめに
最近、Cloudflare Pages や Vercel、Supabase を触ってみて、
「フロントだけで完結する時代が来たんじゃないか？」
と感じました。
Next.js で画面を作り、Functions で API を書き、D1 に接続するだけ。
サーバ構築もデプロイ設定も不要で、フロントエンドだけでアプリが動く。
この体験が、バックエンドの“常識”を大きく変えていると思います。
🏗️ これまでのバックエンド像
少し前までは、
- Java + Spring Boot
- DB: MySQL / PostgreSQL
- REST or GraphQL API
が定番の構成でした。
サーバを立て、環境を整え、ログやセキュリティを細かく管理する。
「堅牢だが重厚」 — そんなイメージがバックエンドにはありました。
ただし個人開発や小規模サービスでは、
この構成を支えるための初期コストが大きすぎるという課題もありました。
🌤️ サーバレス × BaaS の登場
今では Cloudflare Pages や Vercel、Supabase のように
“サーバを持たないバックエンド” が当たり前になっています。
特に Cloudflare Pages Functions の存在は衝撃でした。
HTML や JS を置くだけで、
/functions/api/hello.ts に 1 ファイル書けば即 API が動く。
D1 データベースもワンクリックでバインドできる。
もはや
「バックエンド＝別サーバ」
ではなく、
「バックエンド＝フロントの一部」
という世界に変わりつつあります。
⚙️ Cloudflare Functions でできること
Cloudflare Pages の「Functions」は、
“Workers と同じ仕組みで動く軽量バックエンド” です。
つまり、サーバを立てなくても、ページと同じ場所で API が動きます。
🔧 主な機能一覧
| カテゴリ | できること |
|---|---|
| ✅ API 実装 |
/functions/api/hello.ts に書くだけで API 化 |
| 💾 データ操作 | D1（SQLite 互換 DB）や KV / R2（ストレージ）へ接続 |
| 🔐 認証処理 | Cookie / JWT / セッション制御 |
| ⏰ スケジュール実行 | Cron Triggers で定期ジョブを設定可能（Workers と共通） |
| 🌍 外部連携 | Fetch で他 API を呼び出し、データを加工して返す |
| 🔄 SSR 対応 | Next.js や Remix などのサーバサイドレンダリングを動かせる |
| 🧠 AI 連携 | OpenAI / Claude / Gemini API を直接呼び出して処理可能 |
🌍 エッジとは何か？
最近よく聞く「エッジ（Edge）」とは、
ユーザーの近く（ネットワークの“端”）でコードを実行する仕組み
のことです。
Cloudflare は世界中にエッジサーバを持ち、
ユーザーがどこにいても最寄りの拠点でリクエストを処理します。
💡 イメージ図
🌏 Cloudflare Edge Network
[User in Tokyo] → [Edge Tokyo] → [Cloudflare Functions]
[User in Paris] → [Edge Paris] → [Cloudflare Functions]
同じコードが世界中のエッジで動作するため、
遅延が最小化され、高速でスケーラブルなアプリが実現します。
🧩 エッジとバックエンドの関係
💡 エッジはバックエンドの“代わり”ではなく、“新しい形”
エッジは「バックエンドをユーザーの近くに分散配置したもの」。
つまり、バックエンドの一部がエッジ側に移動したと考えると分かりやすいです。
🔍 従来とエッジの構成比較
従来
[User]
↓
[サーバ(東京)]
↓
[DB]
エッジ構成
[User (Japan)] → [Edge Tokyo]
[User (France)] → [Edge Paris]
↓
[Core Backend (Spring Boot)]
↓
[DB]
エッジが**リクエストの入口（軽量処理・SSR・キャッシュ・認証）**を担当し、
重いロジックやトランザクションはバックエンドが処理します。
🖼️ アーキテクチャ図（イメージ）
※Zenn ではここに画像を挿入するとよりわかりやすいです
例：
┌──────────────────────────────┐
│ 🌍 Cloudflare Edge │
│ ────────────────────────── │
│ Pages + Functions (API/SSR) │
│ │ 認証 │ キャッシュ │ 軽いAPI │
└──┬──────────────────────────┘
│ fetch()
▼
┌──────────────────────────────┐
│ Core Backend (Spring Boot) │
│ ───────────────────────────── │
│ ビジネスロジック / バッチ / DB処理 │
└──┬──────────────────────────┘
│ JDBC/ORM
▼
┌─────────────┐
│ Database │
└─────────────┘
🧱 エッジとバックエンドの役割分担
| 処理内容 | 向いている場所 |
|---|---|
| 認証、SSR、キャッシュ、API ゲートウェイ | エッジ |
| 複雑なロジック、長時間ジョブ、バッチ処理 | 従来のバックエンド (Spring Boot など) |
🔹 エッジは「入り口の頭脳」
🔹 バックエンドは「心臓と記憶装置」
という関係性です。
🧠 エッジはバックエンドを“変えた”
昔は「サーバ＝バックエンド」でしたが、
今は**「場所」ではなく「役割」でバックエンドを定義**する時代になりました。
バックエンドの一部がエッジに移動し、
残りの重い処理がクラウドサーバに残る。
つまり、
バックエンドが“分散した”のがエッジ時代の特徴 です。
🧠 これからのエンジニアに求められること
- “自分で API を作る” よりも “API をどう設計・活用するか”
- “インフラを作る” よりも “ユーザー体験を素早く届ける”
- “1 つの技術を極める” よりも “技術を選び取る目を持つ”
バックエンドの仕事が減ったのではなく、
より高い抽象レイヤーに進化した と感じます。
✨ おわりに
Cloudflare Pages で API を動かしたとき、
「バックエンドがフロントの一部になった」と強く実感しました。
これからの時代は、
- 小さく作ってすぐ出す
- 必要に応じてスケールする
- その判断を自分でできる
そんな“軽やかで柔軟な開発”が求められるでしょう。
Spring Boot も Functions も、どちらも正解。
大切なのは「今の目的に合う形を選ぶ力」 だと思います。
バックエンドは、消えたのではなく、
形を変えて、もっと身近になった。
🪄 まとめ
- フロントエンドだけで API が作れる時代が来た
- Cloudflare Pages / Vercel / Supabase が新たな基盤に
- Functions は API・DB・ジョブ・SSR など多機能な軽量バックエンド
- エッジはバックエンドの延長であり、新しい実行レイヤー
- 大規模システムでは依然として Spring Boot が現役
- バックエンドは「なくなる」のではなく「進化している」
Discussion