Webセキュリティの常識が覆っています。「重要なサーバーを堅牢なファイアウォールで守る」という従来のアプローチに代わり、「そもそも攻撃対象となるサーバーを存在させない」という発想が登場しました。これがエッジコンピューティングと呼ばれる新しいインフラパラダイムです。
本記事では、Cloudflare WorkersやVercel Edge Functionsなどの「エッジサーバーレス」技術が、どのようにセキュリティリスクを根本から減少させるのかを解説します。
1. 従来のセキュリティモデルの限界
従来のWebアプリケーションは「オリジンサーバー」という単一の拠点に集約されていました。これはまるで「要塞」を構えるようなもので、厚い壁（ファイアウォール）と門（WAF）を設けて攻撃者を防ぐ設計でした。しかし、このモデルには根本的な弱点があります。
- 単一障害点：要塞が破られる（サーバーが侵害される）と、中のすべての資産が漏洩
- 横展開攻撃：1つの脆弱性から内部ネットワーク全体への侵攻
- DDoS脆弱性：物理的な帯域上限があるため、大規模攻撃で即座にダウン
- パッチ管理の苦労：OS・ミドルウェアの常時更新が必要
過去の案件でも、WordPress製のコーポレートサイトがプラグインの脆弱性で改ざんされた事例がありました。要塞の「門」であるログインフォームが突破され、内部に侵入されたのです。
2. エッジコンピューティング：「存在しないインフラ」のセキュリティ
エッジサーバーレス（Cloudflare Workers / Vercel Edge Functions / Deno Deployなど）は、コードを「エッジロケーション」で実行します。重要な点は、「どのサーバーで実行されるか」が開発者にも不明瞭であり、かつ1リクエストごとに隔離されたサンドボックスで動作することです。
2.1 オリジン隠ぺい（Originless Architecture）
従来のCDNは「オリジンサーバー（原本）」があり、それをキャッシュ配信していました。エッジコンピューティングでは、オリジン自体が存在しません。コードはエッジにデプロイされ、そこで完結します。攻撃者が「どのサーバーを攻撃すべきか」特定できないため、標的型攻撃が物理的に不可能になります。
2.2 サンドボックスの寿命
エッジ関数は1リクエスト処理ごとに新しいサンドボックスで起動し、処理後即座に破棄されます。これは「使い捨ての計算環境」であり、たとえその瞬間に悪意のあるコードが注入されたとしても、次のリクエストでは完全に別の環境になります。従来のサーバーでの「潜伏型マルウェア」が存在し得ません。
出典：Cloudflare「How Workers Works」
3. ゼロトラストアーキテクチャの実現
「ゼロトラスト（信頼しない）」は「内部ネットワークは安全」という前提を捨て、すべてのアクセスを検証する設計思想です。エッジコンピューティングはこの思想を自然に実現します。
出典：Cloudflare「How Workers Works」
4. フォームのエッジ化
機密性が高いお問い合わせフォームや決済情報の前段階処理を、Cloudflare Workersに移行します。従来は「フォーム送信 → VPSのPHP処理 → DB保存」という流れでしたが、以下のように変更できます：
4.1 新しいアーキテクチャ
- ユーザーがフォーム入力（スタティックサイト）
- JavaScriptでエッジのWorkerに直接送信（オリジンサーバーを経由しない）
- Workerで入力検証・ボット判定・レート制限を実行
- 検証済みデータのみを、別途分離された安全なDB層に保存
- Workerは処理後即座に終了（メモリにデータ残存なし）
4.2 得られる効果
- 攻撃対象の消失：PHPやMySQLへの直接アクセス経路が存在しない
- 自動スケーリング：攻撃トラフィックが増えても、エッジが自動分散処理
- コスト最適化：攻撃トラフィック分の請求が発生しない（CloudflareのDDoS保護込み）
- コンプライアンス：処理ログがエッジに残らないため、データ滞留リスク減少
特に重要なのは、「フォームの処理ロジックがブラウザとDBの間に存在しない」点です。従来は「VPSのPHPが侵害されると、そこに到達するまでのすべてのデータが危険に晒される」状況でしたが、エッジ化により「仮にWorkerが侵害されたとしても、そこには一時的なリクエストデータしか存在しない」状態になりました。
当サイトのお問い合わせフォームはCloudflare Workers経由で送信する設計にしています。実装はwrangler deployコマンド一発でデプロイでき、Workerのコード量は約80行。スパムフィルタリング（Cloudflare Turnstile）も同じWorker内に組み込んでいます。公開後、スパム送信の試みはWorker側で自動ブロックされており、迷惑メールが管理者に届いたことは一度もありません。
5. 限界と向き合うべき課題
エッジコンピューティングは万能ではありません。以下のケースでは従来のアーキテクチャが有効です：
- 長時間処理：エッジ関数には実行時間制限（通常30秒-5分）がある
- 大容量データ：リクエスト/レスポンスサイズに制限（通常1MB-50MB）
- ステートフルな処理：WebSocketなど長期接続が必要なケース
- 特定のライブラリ依存：Node.jsの一部モジュールがエッジランタイムで動作しない
セキュリティのパラダイムシフト
エッジコンピューティングは「より強固な要塞を作る」から「要塞を作らない」という、セキュリティ思想の転換点です。2026年現在、「Astroなどのスタティックサイト生成」＋「エッジでの軽量処理」という構成は、セキュリティ・パフォーマンス・コストのすべてにおいて、従来のVPS中心アーキテクチャを上回る選択肢となっています。セキュリティ対策として「何を追加するか」ではなく「何を削除するか（サーバーを）」を考える時代が来たのです。