※「④ Part 3：クラウドフレア / NET：エッジ・コンピート分野のアカマイ・テクノロジーズ（AKAM）との競合＆強み（優位性）分析」の続き

クラウドフレア（NET）とバーセルの比較

バーセル（Vercel）はサーバーレス・エッジ・コンピューティングの有望企業だが、フロントエンドの開発にのみフォーカスしている。

これは、バックエンドにWorkers、フロントエンドにPagesを持ち、オールラウンドなフルスタック開発エクスペリエンスを提供するクラウドフレア（NET）とは対照的である。

興味深いことに、バーセルのクラウドベースのサーバーレス機能はアマゾン（AMZN）のAWS Lambdaの上に構築され、エッジベースのサーバーレス機能はクラウドフレアのWorkersプラットフォーム上に存在している。

つまり、内部的には、バーセルはバックエンドのサービスと最適化にLambdaとWorkersを使っているのである。

そのため、バーセルを利用する開発者でバックエンドの操作を行う必要が開発者は、クラウドフレアを直接利用することで得られる低レベルのコントロールは得ることが出来ない。

一方で、バーセルは、フロントエンド開発にJAMstackとReactにフォーカスしたアプローチを提供することで、開発者のエクスペリエンスにおいて非常に高いスコアを獲得している。

Reactはフロントエンド開発者に愛されているJavaScriptライブラリで、その主な理由は再利用可能で管理しやすいコードピースを作成できるコンポーネントベースのアーキテクチャにある。

このモジュール性により、複雑なプロジェクトの処理やアプリケーションの効率的な拡張が容易になっている。

また、このライブラリはコミュニティから広く支持されており、ツールや拡張機能の豊富なエコシステムも人気に大きく貢献している。

同社はまた、GitHub、ギットラブ（GTLB）、Bitbucketとシームレスに統合され、コードの変更から直接的に容易な自動更新とデプロイを可能にする堅牢なCI/CD機能でも開発者の間で人気がある。

さらに、同社はオープンソースのNext.jsプロジェクトの開発者であり、このプロジェクトは間違いなく現在最も人気のあるOSSプロジェクトで、GitHubでは驚異的な12万2千ものスターを獲得している。

基本的に、Next.jsはReactの上に構築されたフレームワークであり、サーバーレンダリングされたアプリケーションや静的ウェブサイトを構築する標準的な方法を提供することでReactを拡張している。

具体的には、Next.jsはReactのコンポーネント・ベースのアーキテクチャを活用し、より複雑なアプリケーションと最適化されたページ・レンダリング戦略を可能にし、高度にダイナミックなコンテンツを提供するための自動コード分割、サーバーサイドレンダリング（従来のクライアントサイド・レンダリングよりもウェブページの読み込みが速くなる）などの機能を追加している。

また、Next.jsとの連携を望む開発者にとっては、バーセルが圧倒的な差でナンバーワンのベンダーであるように見える。

同じくJAMstackをベースにしたクラウドフレアのPagesは、フロントエンド開発には適しているが、どちらかというとシンプルさとコラボレーションに重点を置いた静的ウェブサイトのデプロイ用に設計されている。

そのため、このアプローチは、パフォーマンス、セキュリティ、スケーラビリティを向上させるが、バーセルと比較すると、動的な機能が制限されているように見えるかもしれない。

一方で、Next.jsを使用することで、バーセルは静的生成とサーバサイドレンダリングを組み合わせることができる。

これにより、静的サイトのパフォーマンスの恩恵を受けながら、高度にインタラクティブで動的なアプリケーションを構築することができる。

クラウドフレアのPagesもサーバーサイド・レンダリングを提供するが、2022年に導入されたばかりであるため、2016年に導入されたバーセルのサーバーサイドレンダリングに比べると成熟度が低く、高度にダイナミックでレスポンシブなユーザー・インターフェースではバーセルに優位性があるように見える。

さらに、AWS Lambda、または、クラウドフレアのWorkersを介したサーバーレス機能の統合により、バーセルを使用する開発者はサーバーを維持することなく、カスタムバックエンドロジックでアプリケーションを強化することができ、これはクライアントサイドのJavaScriptが効率的に管理できる以上のコンピューティングリソースを必要とするタスクを処理する上で極めて重要である。

このようなカスタム・バックエンド・ロジックは、HTMLのサーバーサイドレンダリングだけでなく、ユーザー認証処理など幅広いバックエンドタスクを含む。

これは、オンライン・マルチプレーヤー・ゲームのようなリアルタイムのデータ処理や、画像処理や物理シミュレーションのような集中的なデータ処理を必要とするアプリケーションには特に有益である。

しかし、バーセルを介した間接的な処理ではなく、クラウドフレアを介した直接的な処理の方が、シンプルさ、パフォーマンス、そして潜在的なコストにおいて有利であると思われる。

とはいえ、開発者が既にフロントエンドのデプロイにバーセルを使用していて、Next.jsや他のフレームワークとの統合環境を楽しんでいる場合、特に、追加の設定や潜在的な複雑さが、統一されたプラットフォームを維持するためのトレードオフとして受け入れられるのであれば、バーセルのアプローチはまだ適していると言えるかもしれない。

したがって、クラウドフレアとバーセルの両方は、プロジェクトの特定の要件に応じて、明確な利点を提供していると言える。

フロントエンドのパフォーマンスを最大化し、時折サーバーサイドのインタラクションを行うことに重点を置く開発者にとっては、クラウドフレアのPages + Workersのコンビネーションがより適しているかもしれない。

逆に、サーバーサイドの計算や更新を頻繁に行う、よりダイナミックなアプリケーションを必要とする開発者にとっては、バーセルのアーキテクチャは、特にNext.jsを活用することで、より柔軟な環境を提供することが出来る。

AWS Lambdaでは、バーセルはNext.jsが実行されるランタイムであるNode.js環境に依存します。

このセットアップでは、関数を呼び出すたびに、Node.js ランタイムが完全に初期化される必要があるコールドスタート遅延が発生する可能性があり、特に非アクティブな期間が続いた後のレスポンスタイムに影響を与える可能性がある。

一方、クラウドフレアのWorkers上で動作するバーセルのエッジ関数は、V8 Chromeランタイムを利用し、前述したように、これは計算を高速化し、待ち時間を最小化する。

開発者は、コードをコンパクトに最適化されたバイナリ命令フォーマットであるWebAssembly（Wasm）にコンパイルすることができ、ネイティブマシンに近い速度でコードを実行することができる。

Wasmの使用とV8アイソレートでの実行を組み合わせることで、従来のコンテナランタイムに比べてランタイムのフットプリントが大幅に削減されるのである。

このアプローチは、コールドスタートの問題を解消するだけでなく、コンピューティングコストも削減するため、パフォーマンスを重視するアプリケーションに最適となる。

バーセルはAWSとマイクロソフト（MSFT）のAzure上で動作するため、開発者はクラウドフレアよりも大規模なAIモデルへのアクセスを提供できる。

さらに、バーセルは、APIを介して最新のGPTモデルだけでなく、最大のオープンソースモデルにもアクセスできる。

興味深いことに、GPT APIを使用するには、通常、OpenAIに直接アプリケーションを提出する必要があり、待ち時間が発生する。

しかし、バーセルの顧客であれば、すぐにGPTにアクセスすることができることから、アプリケーション開発領域における同社の信頼性が際立っていると言える。

バーセルはすべてのワークロードに適しているわけではないが、Next.jsにとってこれ以上のベンダーはないため、Next.js開発者には理想的な選択肢となっている。

また、開発者のエクスペリエンスがシームレスであるため、経験の浅い開発者も熟練した開発者も同様に同社のプロダクトに魅了されている。

実際に、メタ（META）、ハシコープ（HCP）、Auth0、ウーバー・テクノロジーズ（UBER）等の大手テック企業のフロントエンド開発チームがバーセルを使用しており、その品質の高さを証明しています。

今月初め、バーセルはシリーズE資金調達ラウンドで2億5000万ドルを調達し、アクセル、セールスフォース・ベンチャー（CRM）、タイガー・グローバル、GGV、GV、ベッドロックを含む著名なVCから調達した資金総額は5億6300万ドルに達した。

シリーズEでの資金調達の急増は、バーセルが急速に普及しつつあることを示すもので、先に示したForrester Waveと一致している。

そして、バーセルとクラウドフレアに関する我々の最終的な考えは、多くの開発者チームがフロントエンドにバーセルを使い、バックエンドにクラウドフレアのWorkersを使うという取り決めをしているため、両者は真っ向から競合するものではないというものである。

とはいえ、バーセルはフロントエンドでクラウドフレアのPagesとある程度競合しており、クラウドフレアがより多くのフロントエンド機能を追加し、よりダイナミックなアプリケーションのニーズに応えるにつれて、この競合は拡大すると予想される。

また、バーセルは開発者が好んで使用し、簡単にアプリを開発・デプロイできるような、洗練されたフロントエンドの抽象化を作成することで、結果としてWorkersと直接作業する必要性をいくらか減らすことができることからも、この点でもクラウドフレアと競合していると言える。

実際に、バーセルを通してアプリケーションを構築し、デプロイするだけで十分なシナリオもたくさんあるだろうが、アプリケーションがより複雑なバックエンドロジックを必要とするシナリオもたくさんあるだろう。

しかし、仮に、バーセルや同レベルの優れた抽象性と開発経験を持つ代替手段が存在しなかったとしたら、クラウドフレアはWorkersを直接使用する必要がある開発者を大幅に増やしていることだろう。

とは言え、もしバーセルが当市場において勝っているのであれば、バーセルが稼働しているIaaS（Infrastructure as a Service）であるクラウドフレアのWorkersも勝っていることになるので、全体的にはクラウドフレアとWorkersはかなり安全なポジションにあると言えるだろう。

クラウドフレアに対するバーセルの強み

・より高度なサーバーサイド・レンダリングにより、ページ読み込みが速く、レスポンシブでダイナミックなウェブ・ユーザー・インターフェイスを実現。

・Next.js開発者にとって、これ以上のフロントエンド代替はなく、比類のないフロントエンド開発者エクスペリエンスを提供。

・バーセル、間違いなく現在最も人気のあるOSSプロジェクトの作成者であり、後援者であり、非常に広いファネルを作り出している。

・また、他のReactフレームワークにも非常に強い。

・バーセルの開発者向けサービスの質の高さは、それほど複雑でないバックエンドロジックを必要とするアプリケーションでは、開発者がクラウドフレアのWorkersと直接作業する必要性をいくらか減らすかもしれない。

・バーセルは最大規模のAIモデルへのアクセスを提供するが、クラウドフレアは～130億パラメータ数のモデルに限定されている。

クラウドフレアに対するバーセルの弱み

・開発者はバーセルのPaaS（Platform as a Service）サービスだけでなく、クラウドフレアやAWSのIaaSサービスにも間接的な支払いが必要なため、コスト面での負担がより高くなる可能性がある。

・バーセルはバックエンドロジックをカスタマイズするためのアクセスを提供するが、開発者が直接Workersを使用するのに比べると制限される。

・これはバーセルの弱点そのものではなく、クラウドフレアの強みであると言えるが、仮にバーセルがWorkersで直接作業する必要性を減らしたとしても、バーセル自体がWorkers上で実行されているため、バーセルが成長を遂げれば、クラウドフレアもある程度はこの市場において勝利すると言えるだろう。

次のレポートでは、クラウドフレア（NET）とNetlifyとエッジオ（EGIO）との比較について深堀していきたい。

※続きは「⑥ Part 3：クラウドフレア / NET：エッジオ（EGIO/Edgio）＆Netlifyとの競合＆強み（優位性）分析」をご覧ください。