はじめに
前回（※第3回）は AEM as a Cloud Service（以下 AEMaaCS）とオンプレ・AMS の違いを整理しました。その中で、AEMaaCS で標準提供されるものの一つとして Edge Delivery Services（以下 EDS） をさらっと挙げたのですが、「そもそも AEM には Sites と EDS という2つのアプローチがある」ということが謳われているため、Sites と EDS の違いをまとめておきます。
なお、公式ドキュメントでは、「新規プロジェクトの出発点としてEDSの活用を推奨する」ともあり、Adobeとしても今後の主軸としてEDSを位置づけていることがうかがえます。
— Adobe Experience League
整理しておきたい問いは、こんなあたり。
- Sites と EDS は、それぞれ何者なのか
- アーキテクチャ・技術スタック・オーサリングはどう違うのか
- どちらか一方を選ばないといけないのか
なお、第1回・第2回では EDS にまったく触れていないので、この回は「EDS を知らない自分」に向けて、公式ドキュメントの記述を頼りに整理していきます。
早見表
まずは横並びから。
| 項目 | AEM Sites（従来型） | Edge Delivery Services（EDS） |
|---|---|---|
| アーキテクチャ | Author / Publish / Dispatcher / CDN | GitHub + CDN エッジ（Publish/Dispatcher なし） |
| 技術スタック | JCR・HTL・Sling・OSGi | プレーンな HTML / CSS / バニラ JS |
| ビルド | Maven ビルドが必要 | トランスパイラ・バンドラー不要 |
| デプロイ | Cloud Manager のパイプライン | GitHub への push |
| オーサリング | ページエディター | ドキュメントベース or Universal Editor |
| コンテンツソース | AEM（JCR） | AEM・SharePoint・Google Drive など |
| 重点領域 | ガバナンス・多言語・ワークフロー | 速度・シンプルさ・SEO / GEO |
並べてみると、Sites が「リポジトリ中心のフルスタック CMS」なのに対して、EDS は「フロントエンド中心の配信フレームワーク」 という方向性の違いが見えてきます。同じ AEM の名前を冠していても、立っている場所がかなり違う、というのが第一印象です。
AEM Sites とは
第2回で整理したアーキテクチャが、そのまま AEM Sites の世界です。
- Author → Publish → Dispatcher → CDN という配信パイプライン
- コンテンツは JCR（Java Content Repository）に保存
- コンポーネントは HTL（HTML Template Language）と Sling Model で実装
- 編集者はページエディターでビジュアルに編集
強みが出るのは、エンタープライズのガバナンス要件が絡む場面です。MSM（Multi Site Manager）による多地域・多言語展開、複数レビュアーを通す承認ワークフロー、細かいロールベースのアクセス制御──このあたりは、シリーズ後半で Sites を掘り下げるときに順番に触れていく予定です。
Edge Delivery Services とは
EDS について、Adobe 公式ドキュメントでは次のように定義されています。
Edge Delivery Services は、web サイトの構築と配信の方法を再考し、速度、シンプルさ、拡張性を最適化する最新のコンテンツ配信フレームワークです。
— Adobe Experience League
ポイントは、従来の AEM Sites が持っていた Publish / Dispatcher という構成要素を持たないことです。レンダリングと配信をネットワークのエッジ（ユーザーに近い場所）に寄せることで、高速化を狙う設計になっています。
技術スタックは意図的にシンプルです。公式の説明によると、
- プレーンな HTML・CSS・バニラ JavaScript で書ける
- トランスパイラ・バンドラー・複雑な設定は不要
- コードは GitHub で管理し、push でデプロイ
- コンテンツソースは AEM のほか、SharePoint や Google Drive なども選べる
また、公式ドキュメントでは EDS のメリットとして「すべての開発者が 100 点の Lighthouse スコアを達成できる」「立ち上げが 数日〜数週間 で済む」「SEO に加えて生成 AI 向けの最適化（GEO）にも対応」といった点が挙げられています。
オーサリングは2系統
EDS のオーサリング方法は2つあります。
| ドキュメントベースオーサリング | Universal Editor | |
|---|---|---|
| 編集ツール | Microsoft Word / Google Docs など | ビジュアルエディター（WYSIWYG） |
| コンテンツ保存先 | SharePoint / Google Drive | AEM |
「使い慣れたドキュメントツールでそのまま書く」スタイルと、「AEM 上のコンテンツをビジュアルに編集する」スタイルの両方が用意されている、という理解をしています。
両者は排他ではない
ここが個人的に一番「なるほど」と思ったところです。
公式ドキュメントには、EDS と AEM Sites は同じドメイン上に共存できると明記されています。さらに「AEM Sites ページで EDS のコンテンツをシームレスに使用でき、その逆も可能」とあり、どちらか一方を選ばなければならない、という二者択一ではないことが分かります。
要件に応じて、サイトの一部を EDS で、別の一部を Sites で、という組み合わせも現実的な選択肢になる、ということです。
まとめ
自分用の整理として残しておきたい3点。
- Sites は「リポジトリ中心のフルスタック CMS」、EDS は「フロントエンド中心の配信フレームワーク」 ─ 同じ AEM でも方向性が違う
- EDS は Publish / Dispatcher を持たず、HTML / CSS / バニラ JS と GitHub で完結する ─ 速度・シンプルさ・SEO / GEO が重点
- 両者は同一ドメイン上で共存できる ─ 二者択一ではなく、組み合わせも選べる