Gcore FastEdge

WebAssemblyによるサーバーレスエッジコンピューティング

主な利点

• 210箇所以上のエッジロケーションでコードを実行し、世界平均30msという低遅延を実現
• WebAssembly(Wasm)ランタイムによるマイクロ秒単位のコールドスタートで、コンテナ型サーバーレスより数桁高速
• サーバーの構築・運用が一切不要で、コードのアップロードのみで世界中へ数分で展開
• 各アプリケーションはWebAssemblyのサンドボックス内で分離実行され、悪意のあるコードから保護
• JavaScript・Rustでの開発に対応(Go等の対応言語は今後拡充予定)
• コール数に応じた従量課金制で、アイドル時のコストが発生しない
• Gcoreの CDN・仮想マシン・S3互換ストレージなど他サービスとシームレスに連携

Gcore FastEdgeは、アプリケーションのコードをWebAssemblyにコンパイルし、Gcoreのグローバルネットワーク上のエッジサーバーで直接実行するサーバーレスサービスです。
環境構築やインフラの保守を行うことなく、リクエストごとに最寄りのエッジでコードを実行するため、動的でパーソナライズされたアプリケーションを高いレスポンス性能で構築できます。

FastEdgeの動作の仕組み

FastEdgeには、リクエスト処理に関する2つの動作方式があります。
用途に応じて使い分けることで、既存のオリジンサーバーへの負荷を抑えながら、柔軟なロジックをエッジ側で実行できます。

HTTPリクエストを変更しない方式

特定の機能のみをエッジ側で実行し、オリジンサーバーへリクエストが到達する前にエッジネットワークで処理を完結させます。
オリジン側の負荷軽減とスケーラビリティの向上につながります。

HTTPリクエスト・レスポンスを変更する方式

FastEdgeのノードが、設定したロジックに基づいてHTTPリクエストを変更したうえでオリジンサーバーへ送信します。
オリジンからのHTTPレスポンスについても、同様にエッジ側で内容を変更したうえでエンドユーザーへ返却できます。

主な用途

EdgeComputingの価値は、オリジンサーバーに計算させる必要のない処理をエッジ側で完結させ、レスポンスを高速に返せる点にあります。
あるいは、オリジンに送るべきデータの前処理をエッジ側で行い、結果だけをオリジンへ渡すことで、オリジンの負荷そのものを下げることもできます。
重要なのは、オリジンサーバーが計算すべきもの(トランザクションを伴う処理など)と、しなくてもよいものを見極めたうえで設計することです。
より一般化すると、判断基準は「単一の正となるデータソースで整合性を取る必要があるか、それとも多少の遅延・分散があっても実害が小さいか」です。
決済や在庫引当のように整合性が求められる処理はオリジン側で行い、トークンの有効性チェックのように多少古い情報でも実害が小さい処理はエッジ側で完結させる、という切り分けになります。

• 画面遷移・入力フォームの一時データ保持
• オリジンに送る前のデータの絞り込み・前処理
• 認証トークンの検証
• APIレスポンスの集約・整形
• 広告処理
• その他の活用パターン

画面遷移・入力フォームの一時データ保持

複数ステップの入力フォームや画面遷移では、各ステップの入力内容を一時的に保持しながら、セッションを管理する処理が発生します。
この一時データの保持とセッション管理をFastEdgeとEdge Storageで行い、最終的なSubmit時のデータのみをオリジンサーバーへ送信する設計が可能です。
オリジンサーバーは、各ステップごとの一時保存処理から解放され、本来計算すべき最終データの処理のみに専念できます。
なお、途中のステップで在庫引当や決済などのトランザクションが発生する場合は、その処理はオリジン側で行う必要があります。

実装にあたっては、同じユーザーの複数リクエストが異なるエッジロケーションに着信した場合、一時データを正しく引き継げない可能性がある点に注意が必要です。
Cookieやリクエストヘッダを用いたエッジ間のセッション引き継ぎ設計、またはEdge Storageの参照設計を事前に検討する必要があります。
一時データの保存・参照自体はI/O待ちが中心の処理のため、JavaScriptで十分対応できます。

オリジンに送る前のデータの絞り込み・前処理

リクエストヘッダやCookie、地域・デバイス情報などをもとに、オリジンへ送る必要のないリクエストをエッジ側で判定し、除外・集約したうえでオリジンへ送信します。
不正なリクエストや無効なパラメータをオリジン到達前にエッジ側で弾くことで、オリジンサーバーは正当なリクエストの処理のみに計算資源を使えます。

実装にあたっては、IPジオロケーションによる地域判定には一定の誤差があり、法人プロキシやVPN経由のアクセスでは意図しない判定になる場合がある点に注意が必要です。
除外条件を誤ると正当なユーザーのリクエストまで弾いてしまうため、段階的に適用しながらログで効果を確認することを推奨します。
ヘッダやCookieに基づく判定は軽量な処理のため、JavaScriptで十分対応できます。

認証トークンの検証

JWT等のセキュアトークンの検証を最寄りのエッジで行い、有効なリクエストのみをオリジンサーバーへ通過させます。
トークン検証のたびにオリジンへ問い合わせる必要がなくなり、オリジンの負荷とエンドユーザーの待ち時間の両方を削減できます。

実装にあたっては、トークンの失効(ログアウトや権限変更など)をどう即時にエッジへ反映するかが課題になります。
失効リストをEdge Storageに配信して各エッジロケーションで参照する、または有効期限を短く設定して定期的に再検証させる、といった設計を検討する必要があります。
一般的なJWT検証程度の暗号演算であればJavaScriptでも十分な性能が出ますが、検証件数が非常に多い場合はRustでの実装がより有利です。

APIレスポンスの集約・整形

複数のバックエンドAPIから取得したデータを、エッジ側で集約・整形してからクライアントへ返す処理も、オリジンの負荷を下げる代表的なパターンです。
例えば、ECサイトの商品ページで、価格API・在庫API・レビューAPIを個別に呼び出す代わりに、エッジ側でまとめて呼び出し、1回のレスポンスとしてクライアントへ返す設計が可能です。
データの取得・計算自体はAPI(オリジン)側の責務として残しつつ、複数APIの呼び出しをまとめる処理や、JSONとして返すかHTMLまで組み立てて返すかといった整形処理をエッジ側で行います。
クライアントとAPIサーバーの物理的な距離が離れているサービスほど、エッジ側での集約によりラウンドトリップを削減できる効果が大きくなります。

実装にあたっては、複数APIを並行して呼び出す際、1つのAPIが遅延・エラーとなった場合に全体のレスポンスが引きずられないよう、タイムアウト設計と、失敗したAPIを除いて残りのデータだけ返すフォールバック設計を検討する必要があります。
また、集約後のレスポンスをエッジ側で短時間キャッシュすれば、ラウンドトリップの削減に加えて、オリジンへのリクエスト数そのものも減らせます。
複数APIの呼び出し待ちが処理時間の大半を占めるため、集約・整形のロジック自体はJavaScriptで十分対応できます。

広告処理

広告配信に関わる処理も、エッジとオリジンの切り分けが特に効果を発揮する領域です。
地域・デバイス・ファーストパーティCookieのセグメントなどに応じたクリエイティブの出し分けは、パーソナライゼーションと同じくエッジ側で完結できます。
複数の広告取引先(SSP)へ並行してリクエストを送り、最高値の入札を選ぶヘッダービディングの集約も、APIレスポンスの集約と同じパターンで実装できます。
動画配信のマニフェスト(HLS/DASH)へ広告セグメントを組み込むSSAI(サーバーサイド広告挿入)は、CPU負荷が高くなりやすいため、Rustでの実装が向いています。

実装にあたっては、同じ「広告の表示回数」というデータでも、用途によって扱いを変える必要があります。
フリークエンシーキャップのための視聴回数カウントは、多少の遅延・分散があっても実害が小さいためエッジ側で完結させてよい一方、広告主への請求根拠となるインプレッション集計は、単一の正となるデータソースで整合性を取る必要があるため、オリジン側で行う必要があります。
また、広告リクエストの不正・ボットトラフィックをエッジ側で判定し、正当なリクエストのみを広告サーバーへ送る前処理も有効です。
ヘッダービディングの集約やクリエイティブの出し分けはI/O待ちが中心のためJavaScriptで十分ですが、SSAIのようなCPU負荷の高い処理はRustが向いています。

その他の活用パターン

パーソナライゼーション

ユーザーの地域・デバイス種別・ログイン状態などに応じたページ内容の出し分けを、オリジンへ問い合わせることなくエッジ側で判定します。
条件分岐が中心の軽い処理であれば、JavaScriptで十分対応できます。

A/Bテストの振り分け

どちらのバージョンを表示するかという振り分け判定自体は、オリジンが計算する必要のない処理です。
エッジ側でトラフィックを振り分けることで、オリジンへの問い合わせなしに実験を実施できます。
振り分けロジックが単純なランダム判定であれば、JavaScriptで十分です。

画像の変換

オリジナル画像をWebデザインに合わせた形式へ変換する処理をエッジ側で完結させ、オリジンサーバーを画像加工処理から解放します。
リサイズや形式変換はCPU負荷が高くなりやすいため、Rustでの実装が向いています。

軽量な判定処理・推論結果のキャッシュ

ルールベースの判定はJavaScriptで十分ですが、軽量なモデルによる推論結果のキャッシュ判断はCPU負荷が高くなりやすいため、Rustでの実装が向いています。
本当に重い生成AI呼び出しが必要な場合のみ、オリジンやAI基盤へリクエストを振り向けます。

その他のカスタムロジック

ヘッダ操作、リライト、リダイレクトなど、オリジンサーバーが計算する必要のない処理を、独自のロジックとしてエッジ側に実装できます。
いずれもI/O待ちが中心の軽い処理のため、JavaScriptで十分対応できます。

主要エッジコンピューティングサービスとの機能比較

Gcore FastEdgeは、Cloudflare Workers、Akamai EdgeWorkers、AWS Lambda@Edge/CloudFront Functions、Fastly Computeと比較されることが増えています。
いずれもWebAssemblyまたはこれに準ずる軽量ランタイムを採用しており、各社で対応言語や実行制限、料金体系が異なります。
各社の公開情報に基づく機能比較は次のとおりです。
※2026年7月時点の各社公開情報に基づきます。
※各社ともプランや契約条件により内容が変動するため、詳細は個別にお問い合わせください。

Gcore FastEdge×Spelldataが選ばれる理由

Cloudflare WorkersやAWS Lambda@Edge、Fastly Computeなどの海外エッジコンピューティングサービスは、価格や機能面で優れる一方、ドキュメント・サポートとも英語が中心です。
社内にWebAssemblyやエッジコンピューティングの実装経験を持つエンジニアが少ない企業にとって、設計・実装・運用までを自社だけで完結させるのは容易ではありません。
弊社Spelldataは、日本語による設計・実装支援とGcoreサービス全体の一元サポートで、この課題を解決します。

弊社代表の竹洞陽一郎は、Akamaiにおいて日本でのEdgeComputingの普及を推進し、2008年には日本でAkamai在職時にEdgeComputing Allianceを結成するなど、黎明期からEdgeComputingを推進してきた人物です。
Cloudflareにおいても、日本のお客様向けにWorkersの実装を早くから手掛けてきた実績があります。
複数のプラットフォームでEdgeComputingの導入を手掛けてきた経験に基づき、Gcore FastEdgeについても、設計から実装・運用まで一貫して支援します。

• 日本語での要件整理・設計・実装支援により、社内にWebAssembly実装経験がなくても導入可能
• オリジンで整合性を取るべき処理と、エッジで完結させてよい処理の切り分け設計を、要件定義の段階から支援
• 複数のエッジロケーションにまたがるセッション・一時データの引き継ぎ設計など、実装時につまずきやすい論点も含めて伴走支援
• 代理店Spelldataへの問い合わせに1時間以内で回答する運用サポート体制
• 1コールあたりメモリ200MBは、Cloudflare Workers(1 Isolateあたり128MB)やAkamai EdgeWorkers・Fastly Computeの既定値(128MB)より余裕があり、画像処理や推論処理などCPU負荷の高い処理でも安定動作
• Gcore CDN・仮想マシン・S3互換ストレージとシームレスに連携し、既にGcoreサービスをご利用中のお客様は契約・請求・サポート窓口を一本化できる
• コード実装から本番投入後の継続チューニングまで、弊社のプロフェッショナルサービスが伴走支援

プラン・料金体系

弊社では、Gcore FastEdgeを月額1,600円(税抜)でご提供しています。
料金はコール数(実行回数)に応じた従量課金制で、無料枠を超えた分のみ追加料金が発生する、弊社独自の料金体系です。
月額基本料金には、以下の無料枠が含まれます。

FastEdgeには、アプリケーションから利用可能なEdge Storage(キーバリューストア)も付属しています。

• 上記は弊社Spelldataが設定する料金体系であり、Gcoreが直接販売するFastEdgeの公開価格とは異なります。
• コール数が非常に多い場合、実行時間が5秒を超える場合、または大量のメモリ・ストレージを要する場合は、個別見積りとなります。

ご請求

月払い

毎月のコール数・ストレージ利用量に応じての課金で請求書払いとなります。
利用月の月末締め・翌月末払いです。

年払い

12か月分の基本料金を、請求書払いとなります。
月毎の超過分は、利用月の月末締め・翌月末払いです。

FastEdge導入サポート

FastEdgeの導入には、WebAssemblyへのコンパイル、トリガーポイントの設計、既存のCDN・オリジン構成との連携など、いくつかの検討事項があります。
弊社のプロフェッショナルサービスをご利用いただくことで、要件整理から本番投入までスムーズに実施いただけます。
料金は1時間あたり30,000円です。
画像最適化・ヘッダ操作等、比較的シンプルなユースケースの場合は、概ね2~3時間の作業で完了します。
画面遷移データの一時保持、APIレスポンスの集約、広告処理(ヘッダービディング連携・SSAI等)など、複数エッジロケーション間の整合性設計や外部API連携を伴うユースケースの場合は、要件に応じて概ね5~10時間程度を見込みます。

導入手順

1. 実現したい処理内容のヒアリング

画像最適化、パーソナライゼーション、認証、A/Bテスト、API集約、広告処理など、エッジで実現したい処理内容と、既存のCDN・オリジン構成をお伺いします。

2. オリジン/エッジの処理切り分け設計

オリジンで整合性を取るべき処理(トランザクションを伴う処理など)と、エッジ側で完結させてよい処理を整理します。
複数エッジロケーションにまたがるセッション・一時データの引き継ぎが必要な場合は、この段階で設計方針を決定します。

3. アプリケーションの設計・実装

JavaScriptまたはRustにて、要件に応じたロジックを設計・実装し、WebAssemblyバイナリとしてコンパイルします。
ネットワークI/O待ちが中心の軽い処理はJavaScript、画像変換や推論処理などCPU負荷の高い処理はRustを選ぶのが基本方針です。
既存のテンプレートを活用できる場合は、開発工数を抑えて対応します。

4. Gcore Customer Portalへのアプリケーション登録

コンパイル済みのバイナリをGcore Customer Portalへアップロードし、トリガーポイント(on_request_headers等)や環境変数を設定します。

5. CDN・オリジンとの連携設定

既存のGcore CDNや外部CDN、オリジンサーバーとFastEdgeアプリケーションを連携させ、リクエスト・レスポンスの処理経路を設定します。

6. 動作検証

本番投入前に、想定どおりの処理が行われているか、レスポンスタイムやエラー有無を含めて弊社にて検証します。

7. 本番投入・継続チューニング

検証結果をもとに本番トラフィックへの適用を行い、運用開始後もログの分析やロジックの継続的なチューニングをサポートします。