AEM EDS（Edge Delivery Services）とは？仕組みとCDNの関係・ブロック開発・導入手順を解説

AEM EDSとは、Adobe Experience Manager（AEM）の一部として提供されるコンテンツ配信フレームワーク「Edge Delivery Services」のことです。名前に「Edge」と付くため自社CDNを置き換えるサービスだと受け取られがちですが、Adobeの公式ドキュメントはこれを明確に否定しています。EDSは既存のCDNの背後に置くオリジンサービスであり、ページの正規コンテンツはサーバー側でHTMLに描画されます。この記事では、HelixとFranklinから改称された経緯、オリジンサービスとしてのアーキテクチャ、配信HTMLを実測して確かめた速さの実装、ドキュメントオーサリングとユニバーサルエディターの使い分け、ブロックとウィジェットの開発、そして導入手順とライセンス条件までを、aem.liveとExperience Leagueの一次情報にあたって整理します。

まとめ：AEM EDSの要点

先に結論をまとめます。EDSの理解でつまずきやすいのは「何ではないか」の部分です。

この記事の内容は2026年9月8日時点で、Adobeの公式ドキュメントであるaem.liveとExperience Leagueを直接参照して確認したものです。仕様は更新されるため、実際の導入判断では最新の公式ドキュメントを併せて確認してください。

AEM EDSとは：HelixとFranklinからEdge Delivery Servicesへ

Edge Delivery Servicesは、Adobe Experience Managerの配信基盤です。検索すると「Helix」「Franklin」という別名が混在して出てくるため混乱しやすいのですが、公式FAQは経緯をはっきり書いています。FranklinとHelixはAEMエンジニアリングチームの社内プロジェクト名で、2022年から2023年にかけて一部の顧客と検証を行い、2023年10月にAdobeがEdge Delivery Servicesとドキュメントベースオーサリングを正式に発表した、という流れです。つまりHelixとFranklinとEDSは別製品ではなく、同じものの旧称です。

EDSを正しく理解するうえで効くのは、「EDSではないもの」を先に押さえることです。公式FAQは3つの誤解を名指しで否定しています。

3つ目を取り違えると、コンテンツの保管先と配信側の責任範囲を誤ります。EDSはコンテンツを保管するCMSではなく、他所にあるコンテンツを受け取って表示する側です。コンテンツソースになるのは、SharePointやGoogle Drive上のドキュメント、Adobe Document Authoring、あるいはAEM as a Cloud Serviceのインスタンスです。なおEDSは主に高速なHTMLを配信しますが、コンテンツをインデックスに集約してJSONとして配信することもできるため、ヘッドレス的な使い方と併用できます。ヘッドレス構成そのものの考え方はCMSとは？仕組み・種類・WordPressとヘッドレスの違いと選び方を発注視点で解説で整理しています。

EDSのアーキテクチャ：オリジンサービスと自社CDNの分担

公式のアーキテクチャドキュメントは、最上位の説明としてAEMを「既存のContent Delivery Networkに差し込む、オリジン側のサービス」と定義しています。Akamai、Cloudflare、Fastly、Amazon CloudFrontとの標準統合が用意されており、CDNを持っていない場合はAEMのライセンスに含まれるAdobe管理CDNを使えます。ここを取り違えて「Adobeが世界中に持つエッジノードが配信する」と理解すると、CDNの設計も費用見積もりも噛み合わなくなります。

全体は4つの層に分かれます。上から順に、自社のCDN・DNS・TLS証明書などの顧客側インフラ、Adobeのエッジコンピュート層、エッジ配信用のストレージ層、そして顧客側のコンテンツとコードのソースです。ストレージ層は用途別に分かれており、構造化・非構造化コンテンツはContent Bus、アセットとメディアはMedia Bus、サイトのコードはCode Busが受け持ちます。配信サービスは可用性のために冗長化された2つのエッジプロバイダーで動いています。

公開の流れとaem.pageとaem.liveの違い

公開処理はAdmin serviceが担い、作成者はSidekickというブラウザ拡張から操作します。手順は2段階です。まずプレビュー操作で、設定済みのコンテンツソース（SharePoint、Google Drive、AEM Sitesなど）からコンテンツを取り出し、AEMのストレージ層に格納します。次に公開操作で、そのコンテンツを公開状態に移します。この2段階が、プレビュー用ドメインと公開用ドメインの違いに対応しています。

自社CDNを使うときの必須設定

自社CDNを本番前段に置く構成（BYO Production CDN）では、Adobeが指定する設定があります。設定漏れはキャッシュの不整合や更新の遅延として表面化するため、導入時のチェック項目として押さえておく価値があります。

あわせて、Adobeが非推奨としている構成も明示されています。CDNを何枚も重ねるCDNチェーンは、プッシュ無効化が本番CDN1枚でしか機能しないため推奨されません。またTLSインターセプト（SSLインスペクション）は、再暗号化の処理遅延と証明書の取り扱いの問題から避けるべき構成として挙げられています。セキュリティ製品を前段に置く前提の企業では、この2点を事前に確認しておく必要があります。

EDSが高速な理由：サーバー描画と初期HTMLの構成

EDSの速さは「エッジに置くから速い」という説明で片づけられがちですが、実装上の要点は描画の分担と、マークアップに何を含めないかの取捨選択にあります。公式のパフォーマンス指針は次のように書いています。ページ上の正規コンテンツはすべてサーバー側でマークアップに描画される。CSSとDOMによる装飾は表示とアクセシビリティ上の意味づけにしか影響しない。そしてページの正規コンテンツではない冗長な要素、具体的にはヘッダーとフッター、多数のページで共通利用されるフラグメントは、LCPを遅らせTBTを増やすため、マークアップに含めない、というものです。

この方針は仕様としても明文化されています。公式のHTML Markup referenceは、サーバー側で生成されるドキュメント構造の雛形として、body直下に空の header 要素、本文が入る main 要素、空の footer 要素を並べた形を示しています。ヘッダーとフッターは、要素の器だけが初期HTMLにあり、中身は後からブロックとして読み込まれるという設計です。

仕様どおりに配信されているかは、実際のレスポンスで確認できます。EDSで構築されているAdobe自身のドキュメントサイトに対し、2026年9月8日に次のコマンドを実行して返ってきたHTMLをそのまま調べた結果です。同じコマンドを実行すれば誰でも再現できますが、公開後のサイト更新によってバイト数やスクリプト構成は変わり得ます。

$ curl -sL https://www.aem.live/docs/ -o eds.html -w "bytes %{size_download} ttfb %{time_starttransfer}"
bytes 41170 ttfb 0.113928

# 配信HTMLに含まれる script は3本のみ、すべて type="module"
<script nonce="..." src="/scripts/aem.js" type="module">
<script nonce="..." src="/scripts/scripts.js" type="module">
<script nonce="..." src="/scripts/indexing-test.js?date=2024-08-16" type="module">

# stylesheet も1本のみ
<link rel="stylesheet" href="/styles/styles.css">

# ヘッダーとフッターは要素だけがあって中身が空
header repr: '<header></header>'
footer repr: '<footer></footer>'

Markup referenceが示す雛形どおり、ヘッダーとフッターが空の要素として配信されていることが確認できます。これがLCPまでに送るバイト数を絞る仕掛けです。同時に、SEOの観点では初期HTMLに本文が入っているかどうかが効くため、EDSは本文をサーバー側で出しつつ、周辺のナビゲーションだけを遅らせるという分担をとっています。この判断軸はReact SEO対策とは？SSR・SSG・プリレンダリングの選び方と実装手順で扱っているレンダリング方式の選択と同じ論点です。

Lighthouseスコア100の位置づけ

公式FAQは「すべてのEDSサイトはLighthouseスコア100を達成できるし、達成すべきである」と書いています。さらに公開前チェックリストでは、対象を明確に限定しています。すなわち、すべてのAEMプロジェクトは、自身の.aem.liveサイトに対するGoogle PageSpeed Insightsで、モバイルとデスクトップの双方でLighthouseスコア100を出すべきである、という基準です。デスクトップだけの100で足りるわけではない点と、測定対象が本番ドメインではなく.aem.liveである点に注意してください。

実運用の監視には、ラボ計測であるLighthouseとは別に、運用上のテレメトリ（Operational Telemetry）が使われます。これは実利用のフィールドデータを継続的に集める仕組みで、CrUXのデータが動くのを待たずにコードやデプロイの影響を見られます。プライバシー面では、全ページビューではなく一部のみを監視するサンプリングと、個人を特定できる情報の除外が組み込まれています。EDS以外のサイトにも、スタンドアロン用のスクリプトを1行入れれば導入できます。公式ドキュメントはこのスクリプトをLCPの発生後に読み込むことを推奨しています。

<script defer type="text/javascript"
  src="https://ot.aem.live/.rum/@adobe/helix-rum-js@^2/dist/rum-standalone.js"></script>

なお、旧来この記事に記載していた「Edge Insights」という監視機能は、aem.liveおよびExperience Leagueのいずれの公式ドキュメントにも存在しません。EDSの監視機能として実在するのは、ここで説明した運用上のテレメトリです。

ドキュメントオーサリングとユニバーサルエディターの使い分け

EDSのオーサリングには2つの系統があります。どちらを選ぶかで必要なAEMの構成が変わるため、導入検討の早い段階で決める項目です。公式FAQによれば、対応するオーサリング環境はAEMのユニバーサルエディター、Adobe Document Authoring、そしてMicrosoft WordとExcel、GoogleドキュメントとGoogleスプレッドシートといった既存ツールです。

ユニバーサルエディターを選ぶ場合、AEMのすべての機能がそのまま使えるわけではない点に注意してください。Adobeは、従来のページエディターとユニバーサルエディターの間には機能差が残っており、その差は縮小し続けていると明記しています。指針としては、新規プロジェクトはユニバーサルエディターを既定とし、既存プロジェクトはページエディターを継続しつつ、Edge Deliveryやヘッドレスに着手する段階でユニバーサルエディターを検討する、という整理です。要件ごとの可否は、採用前に公式の機能比較表とユニバーサルエディターのリリースノートで確認するのが確実です。

ドキュメントオーサリングでは、Wordの見出しがそのままサイトの見出しになり、太字・斜体・リスト・画像もそのまま反映されます。画像はドキュメントにドラッグして貼るだけで、閲覧者のブラウザ幅に合わせてリサイズされます。ドキュメント上でサイズを変えても表示には影響しないため、代替テキストの設定に手をかけるほうが効果があります。どのコンテンツソースを使うかは、リポジトリ内の fstab.yaml でマウントポイントとして指定します。1つの fstab.yaml に指定できるマウントポイントは1つだけで、追加のコンテンツソースはサイト作成後に構成サービス側でオーバーレイとして足す形になります。

ここで注意が要るのは、Markdownの扱いです。EDSはGitHub上のMarkdownドキュメントをコンテンツソースとしてネイティブにサポートしなくなりました。GitHubにあるMarkdownを公開したい場合は、いったんサポート対象のオーサリング環境へコピーしたうえで、プレビューと公開の操作を行う必要があります。Markdownベースの運用を前提に構成を組もうとしている場合は、この制約を先に確認してください。Markdownでサイトを運用する方式そのものの比較はMarkdownでWebサイトを作る3つの方法【2026年版】にまとめています。

もう1点、EDSには承認ワークフローが組み込まれていません。ワークフロー管理はコンテンツソース側に委ねる設計で、SharePointやGoogle Drive上での文書レビューと承認については、Adobe WorkfrontとAdobe自身が案内しています。AEMのユニバーサルエディターを選べばAEM側のワークフローが使えるため、承認プロセスが必須要件ならこの点が選択の分かれ目になります。

ブロックとウィジェット：EDSのフロントエンド開発

EDSのフロントエンドは、ブロックとウィジェットという2種類の部品で構成されます。用語が近いので混同されがちですが、公式ドキュメントは役割で明確に線を引いています。

Adobeはブロックコレクションとして、実際の本番プロジェクトで使用頻度が高いブロックを製品の一部として配布しています。収録されるのは、コンテンツモデルを変えずに再利用できる程度に汎用で、依存関係を持たずボイラープレートと互換なブロックです。全ブレークポイントでの動作、CSSコンテキストの継承、ローカライズ可能であること、性能への影響がないこともあわせて条件になります。

ボイラープレートの実測構成

開発の起点になるのがAdobeが公開しているボイラープレートです。第三者が同じ版を再検証できるよう、mainブランチの特定のコミットを指定してアーカイブを取得し、中身を数えた結果が次のとおりです。

adobe/aem-boilerplate  Apache-2.0 / テンプレートリポジトリ
検証した版: main @ baa7ca014780ff72b84dba5c18149f5571aeb7d1（2026-09-04）

ファイル総数: 44
blocks/  cards, columns, footer, fragment, header, hero, widget の7種
scripts/ aem.js, scripts.js, consent-check.js, consented.js
styles/  styles.css, fonts.css, lazy-styles.css
head.html, 404.html, favicon.ico, fonts/

package.json の中身（実測）
  "scripts": {
    "lint:js":  "eslint .",
    "lint:css": "stylelint \"blocks/**/*.css\" \"styles/*.css\"",
    "lint":     "npm run lint:js && npm run lint:css",
    "lint:fix": "npm run lint:js -- --fix && npm run lint:css -- --fix"
  }
  "dependencies": なし
  "devDependencies": eslint 系4本と stylelint 系2本のみ

注目すべきはpackage.jsonにdependenciesが1つも無く、scriptsがlintの4本しか無いことです。ビルドやバンドルのコマンドが存在しません。これがAdobeの言う「ビルドレス」で、公式ドキュメントも「GitHubリポジトリから直接動作するビルドレスのアプローチを使っている」と明記しています。日本語版のドキュメントでは「トランスパイル、バンドラー、設定、オーバーヘッドなどの複雑なものは一切ありません」と書かれ、素のHTML、モダンなCSS、バニラJavaScriptで書く方針が示されています。従来のフロントエンド開発を前提にツールチェーンの選定から入ると、この設計と噛み合いません。

もう1つ、ボイラープレートのhead.htmlにはコンテンツセキュリティポリシーが同梱されています。strict-dynamic と require-trusted-types-for 'script' を含む構成で、nonceベースのスクリプト許可とTrusted Typesが初期状態から有効になります。EDSのセキュリティを検討する際は、前段のCDNやWAFだけでなく、この配信側のポリシーも設定対象として把握しておくとよいでしょう。

導入手順：ボイラープレートからサイト公開まで

公式の開発者向けチュートリアルは、10分から20分で自分のサイトを立ち上げてコンテンツの作成・プレビュー・公開まで到達する構成になっています。前提として、GitHubアカウントとGitの基本、HTML・CSS・JavaScriptの基礎、ローカル開発用のNodeとnpmが必要です。

1. ボイラープレートのリポジトリを開き、Use this templateから新しいリポジトリを作成します。所有するユーザーまたは組織を選び、公開リポジトリにすることが推奨されています。
2. 作成したリポジトリにAEM Code SyncのGitHubアプリをインストールします。リポジトリのアクセス設定では、全リポジトリではなく対象リポジトリのみを選択します。
3. この時点でプレビュー用のサイトが立ち上がります。URLは https://<branch>--<repo>--<owner>.aem.page/ の形式になります。
4. オーサリング環境でコンテンツを編集します。チュートリアルではDocument Authoringを使ってサンプルコンテンツを開き、プレビューと公開を行います。
5. Sidekick拡張をChromeにインストールします。以降は自分のサイトのページ上から直接、編集・プレビュー・公開の操作ができます。

ここで見落としやすい制約が2つあります。1つは命名です。<branch>--<repo>--<owner> の組み合わせはハイフンを含めて63文字以内に収める必要があります。これはサブドメイン名の制約に由来します。加えて、branch名・repo名・owner名のいずれにも連続ハイフンを含めることができません。区切り文字として連続ハイフンを使っているためです。長いリポジトリ名や組織名を使う予定があるなら、設計時点で文字数を数えておくべきです。

もう1つはネットワークです。GitHub EnterpriseでIPフィルタリングを行っている場合、公式チュートリアルは 3.227.118.73 を許可リストに追加するよう案内しています。社内のネットワーク制約が厳しい環境では、着手前に情報システム部門と調整が必要になる項目です。GitHubを起点にしたデプロイの考え方そのものはGitHub Actionsとは？できること・使い方とCI/CD自動化の活用例をわかりやすく解説で整理しています。

導入前に確認すべきライセンスと制約

技術的な適合を確認しても、ライセンスと運用条件で止まることがあります。公式FAQに書かれている条件のうち、判断に効くものを挙げます。

まず開発用アクセスが無償である点は、検証の入口として重要です。AEM Sitesの契約前でもチュートリアルの手順で環境を作れるため、自社のコンテンツで実際に動かしてから判断できます。一方、本番運用にはAEM Sitesのライセンスが必要なので、EDSだけを安価な配信基盤として単独導入するという想定は成り立ちません。

サポートの起票条件も見落としがちです。チケットを出すには、あらかじめEDSサイトをCloud Managerに登録しておく必要があります。起票時はタイトルに Edge Delivery を付し、本番サイトのURLとオリジンのURLの両方を記載する運用です。障害時の導線として、登録作業を公開前に済ませておくのが安全です。

A/Bテストやパーソナライズは、EDSのコア機能ではなくプラグインとして提供されています。Adobeが公開しているaem-experimentationは、EDS向けの軽量な実験・セグメンテーション用プラグインで、Apache-2.0ライセンスです。加えてEDSはAdobe TargetやAdobe Experience Platform Launchと併用できます。

ただし、公開直後は計測の前提が変わる点に注意してください。公式の公開前チェックリストは、サイトのリニューアルでは読み込みシーケンスと性能が変わるため、アナリティクスで取得する指標のベースライン自体が動くと明記しています。ページビュー、コンバージョン率、直帰率、滞在時間などが対象で、チェックアウトやフォーム送信のように業務システム側で記録される指標は影響を受けません。移行前後の数値を比較する担当者とは、事前に認識を合わせておく必要があります。テストの設計と判定についてはABテストとは？必要サンプル数の計算コードと検証期間・判定を誤らせる条件を参照してください。

よくある質問

AEM EDSの「EDS」は何の略ですか？

Edge Delivery Servicesの略です。Adobe Experience Manager（AEM）の配信フレームワークを指します。過去にHelix、Franklinという社内プロジェクト名で呼ばれていた時期があり、2023年10月にEdge Delivery Servicesとして正式に発表されました。検索結果に3つの名前が混在するのはこの経緯によるもので、別製品ではありません。

EDSとAEM Sitesはどちらを選ぶべきですか？

二者択一ではありません。EDSはAEM Sitesの一部であり、AEM SitesのライセンスがEDSの利用条件です。実際の選択は、コンテンツをどこで管理するかという点にあります。SharePointやGoogle Drive上のドキュメントで管理するならAEMのオーサーインスタンスは不要で、AEMのワークフローや多サイト管理を使いたいならユニバーサルエディターとAEM as a Cloud Serviceの構成を選びます。EDSとAEM Sitesは同じドメイン上で共存でき、大規模サイトでは一般的な構成だとAdobeは案内しています。

既存のCDNをそのまま使えますか？

使えます。EDSはCDNの代替ではなくオリジンサービスなので、前段のCDNは自社のものを使う構成が標準です。Akamai、Cloudflare、Fastly、Amazon CloudFrontには標準統合があり、CDNを持っていない場合はAEMライセンスに含まれるAdobe管理CDNを利用できます。ただし、オリジンURLの指定、X-Forwarded-HostとX-Push-Invalidationの送出、クエリパラメータの転送とキャッシュキーへの反映、Ageヘッダーの抑止といった設定が必要です。また、CDNを複数重ねる構成はプッシュ無効化が本番CDN1枚でしか効かないため推奨されていません。

GitHubのMarkdownをそのままコンテンツにできますか？

できません。EDSはGitHub上のMarkdownドキュメントをコンテンツソースとしてネイティブにサポートしなくなりました。GitHubにあるMarkdownを公開したい場合は、いったんサポート対象のオーサリング環境にコピーし、そこからプレビューと公開を行う必要があります。過去の情報を参照して構成を設計すると、この点で手戻りが発生します。

Lighthouseスコア100はどの条件で測るのですか？

公開前チェックリストでは、Google PageSpeed Insightsを使い、対象のプロジェクトの.aem.liveサイトに対して、モバイルとデスクトップの双方で100を出すことを基準としています。本番ドメインではなく.aem.liveを測る点と、デスクトップだけでは不足である点が条件です。継続的な監視には、実利用のデータを集める運用上のテレメトリを併用します。

関連記事

• CMSとは？仕組み・種類・WordPressとヘッドレスの違いと選び方を発注視点で解説
• Jamstackとは？意味・仕組みから開発・WordPress比較まで解説【2026年版】
• MarkdownでWebサイトを作る3つの方法【2026年版】
• React SEO対策とは？SSR・SSG・プリレンダリングの選び方と実装手順
• GitHub Actionsとは？できること・使い方とCI/CD自動化の活用例をわかりやすく解説