生成AI検索の普及により、ユーザーは検索結果からWebサイトを探すだけでなく、AIがまとめた回答から情報を得ることができるようになっています。こうした変化を受け、「AIに読まれやすいサイト」をどう作るかへの関心も高まっています。

その選択肢の一つとして注目されているのが、Adobe Edge Delivery Services（以下、EDS）です。ただし、EDSを使えば自動的にAIフレンドリーなサイトになるわけではありません。

この記事では、「AIに読まれやすい」「AIを使って作り・更新しやすい」という2つの視点からEDSを検証し、EDSの特徴や導入時に確認しておきたいポイントを整理しながら、AEMの中でEDSをどこに適用するかを解説します。

なお、本記事はAdobeの公式ドキュメントなどの公開情報と、Business Architects（ビジネス・アーキテクツ、以下BA）で進めているEDSの検証結果をもとにしています。

EDSを評価する2つの「AIフレンドリー」

BAでは、AI時代のWebサイトを考えるうえで、「AIに読まれやすいこと」と「AIを使って作り・更新しやすいこと」の2つを「AIフレンドリー」の視点として捉えています。まずは、それぞれがどのような状態を指すのか見ていきましょう。

①AIに読まれやすい（外向きのAIフレンドリー）

1つ目の視点は、AIがWeb上の情報を取得する際に、コンテンツの内容や構造を読み取りやすいことです。技術面では、主に次の3つがポイントになります。

• 応答速度
  クローラーがコンテンツを取得しやすいよう、サーバーから素早くレスポンスが返ること。Googleはサーバー応答の指標であるTTFB（Time to First Byte）について、0.8秒以下を良好としています（※1）。
• セマンティックHTML
  見出しや段落など、コンテンツの構造をクローラーなど機械が解釈しやすい形でマークアップして書かれたHTMLであること。
• 最初に読み込まれるHTMLに情報が含まれていること
  伝えたい情報が、JavaScriptの実行を待たず、最初に返されるHTMLから読み取れることです。本文だけでなく、head内のmetaタグやJSON-LDなどの構造化データも含まれます。

※1：Time to First Byte (TTFB). web.dev.（参照 2026-09-25）

②AIを使って作り・更新しやすい（内向きのAIフレンドリー）

2つ目の視点は、AIエージェントを使ってコンテンツ制作・更新業務・コンポーネント開発を効率化できる、運用・開発者向けの視点です。

AEMは公式にMCP（Model Context Protocol）Serverを提供しており、AIエージェントからコンテンツ操作を行うことが可能です（※2）。

またEDSでは、WordやGoogleドキュメントで作成した文書をWebページとして公開する、ドキュメントベースオーサリングを利用できます。普段使っている文書作成ツールをそのまま制作環境として使えるため、生成AIで原稿の下書きを作成し、人が確認・修正して公開するといった流れも組み込みやすくなります。

「AIに読まれる」だけでなく「AIと一緒に作れる」ことまで含めて、当社ではAIフレンドリーの条件と捉えています。

※2：AEM as a Cloud ServiceでのMCPの使用. Adobe Experience Manager.（参照 2026-09-25）

EDSがAIに読まれやすい2つの理由

EDSは、AEM as a Cloud Serviceの一部として提供されるWebサイトの配信基盤です。EDSはAIのために作られたものではありませんが、高速な配信や、本文がJavaScriptの実行を待たずHTMLに含まれる構成は、AIがWebサイトの情報を取得しやすい条件と重なります。

一般的に「AI検索」と呼ばれる仕組みですが、Webサイトの情報を取得する方法は同じではありません。GoogleのAI OverviewsはGoogle検索の仕組みを基盤としています。一方で、ChatGPTやClaudeなどで使われる一部のAIクローラーは、JavaScriptを実行せずにWebページの情報を取得します。

こうした違いを踏まえながら、EDSがAIに読まれやすいと考えられる理由を解説していきます。

①高速なレスポンスでコンテンツを取得しやすい

EDSはCDNを利用した配信が前提となっており、サーバーからの応答時間を短くしやすい構成になっています。これはユーザーの表示だけでなく、クローラーがコンテンツを取得するうえでも同じです。

Googleは、サイトの応答時間が安定または改善するとクロール可能な容量が増え、反対に応答が遅くなるとクロール量が減る場合があると説明しています（※3）。

AIクローラーでも同様の傾向が報告されています。外部調査では、ChatGPTのクローラーが応答の遅いページへの接続を途中で終了し、HTTP 499エラーとなる事例が確認されています（※4）。こうした点からも、応答速度はAIがWebサイトの情報を安定して取得するための重要な要素と考えられます。

※3：クロール バジェットを最適化する. Google for Developers.（参照 2026-09-25）
※4：ChatGPT Search Abandons Slow Sites With 499 Timeout Errors. Implicator AI.（参照 2026-09-25）

②JavaScriptを実行しなくても本文を読み取れる

GooglebotはJavaScriptを実行し、後から表示される内容を読み取ることができます。一方、Vercelの調査では、ChatGPTやClaudeなどのAIクローラーはJavaScriptを実行しないため、ブラウザ側のJavaScriptによって後から表示されるコンテンツは読み取れないことが示されています（※5）。

EDSでは、著者が入力した本文は見出しや段落、リストなどの構造を保ったセマンティックHTMLとして最初に読み込まれるHTMLに含まれます。そのため、JavaScriptを実行しないAIクローラーでも、本文の内容を取得することができるのです。

ここで注意したいのは、JavaScriptを使って後から取得・表示する動的なコンテンツは最初に読み込まれるHTMLには含まれないことです。BAがEDSの標準構成で検証した際にも、Fragment Blockや外部データ由来の情報は最初には読まれないことを確認しています。こうした動的コンテンツの扱いは、EDSを導入する際に確認しておきたいポイントの一つです。

※5：The rise of the AI crawler. Vercel.（参照 2026-09-25）

AIフレンドリーだけでは決められない、EDSのトレードオフ

ここまで見てきたように、EDSにはAIに読まれやすく、AIを使った制作・更新とも相性のよい特徴があります。この特徴を生かすには、EDSが向いている領域と、そうでない領域を理解しておく必要があります。

ここからは、EDSを適用する際に確認しておきたい3つのポイントを解説します。

①動的コンテンツは最初に受け取るHTMLに含まれない

AEMには、構造化したコンテンツを複数のページやチャネルで利用するためのContent Fragmentという機能があります。このContent Fragmentや外部APIのデータ、他ページの内容を参照するFragment Blockなど、EDSの標準構成ではJavaScriptを使って後から情報を取得・表示します。

そのため、ページ上に直接入力した本文とは異なり、クローラーがページへアクセスした際に最初に受け取るHTMLには、これらの情報が含まれません。

JavaScriptを実行しないAIクローラーにも情報を読ませるには、公開前や公開時にHTMLへ含めるなど、別の仕組みが必要です。EDSには組み込みのSSR（サーバーサイドレンダリング）がないため、必要に応じてHTMLを事前に生成するといった補完方法を検討する必要があります。

②ドキュメントオーサリングでは承認・権限の統制が弱くなる

EDSのオーサリングには、実際のページ表示を確認しながら編集できるUniversal Editorと、WordやGoogleドキュメントなどを使うドキュメントベースの2つの方式があります。

ドキュメントベースオーサリングでは、普段使っているツールで手軽にコンテンツを作成できます。その反面、権限管理や承認はGoogle DriveやSharePointなど、それぞれのドキュメントサービスの仕組みに依存するため、一般的なCMSと比べると承認ワークフローや細かなアクセス制御は弱くなります。

Universal EditorではコンテンツをAEM上で管理するため、AEMの権限管理やワークフローを利用できます。細かなアクセス制御や承認フローが求められる場合は、Universal Editorを選ぶ方が適しています。

③AEM Sitesで使ってきた機能が、同じ形で使えるとは限らない

AEM SitesとEDSでは、開発の前提となる技術や機能に違いがあります。代表的な差分を整理します。

EDSではJavaを前提とせず、HTML、CSS、JavaScriptなどのフロントエンド技術を中心に開発することが可能です。

AEM Sitesで利用してきた継承やコンポーネントの自由な入れ子なども、EDSでは同じ形で使えるとは限りません。こうした違いは、シンプルな構成と高速な配信を重視するEDSの設計思想とも関係しています。

AEM Sitesで実現してきた機能をそのまま置き換えられるかではなく、サイトで実現したい構造や機能にEDSの考え方が合っているかという視点で、採用を判断すると良いでしょう。

まとめ：AEMの中でEDSをどこまで使うか

この記事では、BAが考える「AIフレンドリー」を「AIに読まれやすい」「AIを使って作り・更新しやすい」の2つの視点から捉え、EDSの特徴とトレードオフを見てきました。

AIに読まれやすいサイトは、EDSでなければ実現できないわけではありません。AEM SitesでもCDNやキャッシュなどを適切に設計すれば、応答速度やHTMLの構造を改善できます。EDSをどこまで使うかは、次の3つの視点から考えるとよいでしょう。

• ①AIに読ませたい情報に、動的コンテンツがどれくらいあるか
  記事や固定ページなど、ページ上に直接入力するコンテンツが中心であれば、EDSの標準的な構成を生かしやすくなります。外部データや構造化コンテンツの比重が大きい場合は、AIに読ませたい情報をどのようにHTMLへ含めるかまで考える必要があります。
• ②速さを標準的な仕組みで維持したいか
  AEM SitesでもCDNやキャッシュを設計することで高速なサイトを構築できますが、その性能を維持するには継続的な設計や運用が必要です。EDSでは高速な配信を前提とした仕組みが用意されており、コード更新時にはパフォーマンスのチェックも行われます（※6）。
• ③サイトの作り手をどこまで広げたいか
  EDSでは、WordやGoogleドキュメントなど普段使っているツールを利用したコンテンツ制作や、Javaを前提としないフロントエンド中心の開発が可能です。作り手を広げやすい反面、承認フローやアクセス制御などの要件に応じて、オーサリング方式や運用ルールを設計する必要があります。

※6：Frequently Asked Questions. Adobe Experience Manager（aem.live）.（参照 2026-09-25）

AEM SitesとEDSを二者択一で考えるのではなく、サイトの構造やコンテンツ、運用体制を踏まえて、EDSの特徴を生かせる領域を見極めることが重要です。

BAでは現在、EDSを活用したサイト構築の検証を進めています。EDSをサイト全体に適用するだけでなく、一部の領域から取り入れる方法も含め、AI時代のWebサイトに適した構成や運用方法をご提案します。