先日、Adobe DX Partner Enablement Sessionでの当社登壇について、お知らせ記事で概要をご紹介しました。本記事はその続編として、当日お話しした内容のうち、特に反響の多かったポイントを、あらためて整理したものです。

お知らせ：Adobe DX Partner Enablement Sessionに登壇しました（2026/2/13）

Edge Delivery Services（EDS）は「ページ表示が速くなる」という文脈で語られがちです。ただ当社がお伝えしたいこととしては、機能の説明そのものではありません。「ページを速く表示すること」と、「改善を小さく頻繁に試せること」がますます重要になる中で、提案やプロジェクトの進め方、運用体制をどう組み替えると現実的か。この記事では、当社の考え方をまとめます。

※本記事はBusiness Architectsとしての見解を整理したもので、アドビ株式会社の公式見解を示すものではありません。

「機能紹介」ではなく「前提の変化」

EDS（Edge Delivery Services）は、「速い」「簡単」といった文脈で語られがちです。もちろんそれ自体とても重要ですが、当社が登壇でお伝えしたかったのは、機能ではありません。ポイントは、いま起きようとしている前提の変化です。

昨今企業サイトに求められているのは、

• ページを速く表示すること
• 改善を小さく頻繁に試せること

この2つだと考えています。言い換えると、「作って終わり」ではなく、「作ってから改善を回す」ことが当たり前になりつつあります。

この前提に立つと、提案の組み立て方も、プロジェクトの進め方も、運用設計の考え方も変わります。

たとえば、最初に完璧を目指して作り切るより、改善を回し続けられるように、責任範囲や運用の線引きを先に決めるほうが現実的です。EDSは、そうした「改善を回すことを前提にした運用」にフィットする配信の考え方だと捉えています。

EDSをどう捉えるべきか（CMSとの違い／ヘッドレスとの違い）

まず整理しておきたいのは、EDSはCMSそのものではない、という点です。CMSが担うのは、企業サイトを安全に回すための「統制」の仕組みです。たとえば、誰が編集できるか（権限）、誰が承認するか（承認フロー）、いつ公開するか（公開／差し戻し）、公開後を含めてどう管理するか（ライフサイクル管理）といった領域です。

一方でEDSは、コンテンツを管理するというより、ページをユーザーに届ける仕組みに寄せた考え方です。表示や配信をシンプルにし、ページを速く表示しやすい状態を作る。ここに重心があります。どちらが優れているかではなく、役割が違う。だからこそ、最初に「どこを管理として捉え、どこを配信として捉えるか」を分けて考える必要があります。

もうひとつ、よく誤解されるのがヘッドレスとの違いです。ヘッドレスは、ざっくりいうと「中身（データ）を渡して、受け取った側が表示を組み立てる」考え方です。EDSは「ページ（HTML）を用意して、そのまま配る」考え方に近く、表示側の構造がシンプルになりやすい。どこで何を作り、どこに負荷がかかるかが変わるため、この違いは設計や体制の議論に直結します。

技術者向け補足

ドキュメント更新＝CMSではない
ドキュメントで更新できることは便利ですが、それは『入力方法』の話です。企業サイトで重要になりがちな「承認」「権限」「公開・差し戻し」「ライフサイクル管理」まで自動的にそろうわけではありません。
運用でつまずかないためには、「入力」と「管理」を分けて設計する発想が必要になります。

ヘッドレスとEDSの違い
ヘッドレスは、AEMなどから返されるデータ（API）をもとに、フロント側でその都度画面を組み立てるモデルです（SPA的な構成になりやすい）。

一方でEDSは、コンテンツから事前にHTMLを生成し、それを配信するモデルです（JAMStack的な考え方に近い）。配信時はHTMLを最適な単位で配る設計になりやすく、表示側の構造をシンプルに保ちやすい点が特徴です。

変わるのは「手順」より「役割分担」

ここまで、EDSの概念をお伝えしましたが、「現場の手順が全部変わるのでは？」と身構えてしまう方も多いかもしれません。ただし、当社の見立てでは、手順そのものが劇的に入れ替わるというより、役割分担がより重要になると捉えています。

ページを速く表示すること、そして改善を小さく頻繁に試せることを両立しようとすると、途中で滞りやすい／止まりやすいポイントが出てきます。その多くは技術の難しさというより、「誰がどこまで責任を持つか」が曖昧なことから起きます。

たとえば、表示を誰が直すのか、コンテンツの管理を誰が担うのか、基盤として守るべき範囲を誰が決めるのか。ここが曖昧だと、改善はすぐに止まってしまいます。

だからこそ、最初に線を引くことが大切です。表示・配信の領域と、管理・統制の領域を分けて考え、責任範囲を言語化する。これだけでも、運用の負荷は大きく変わり、改善を回しやすい状態に近づくのではないでしょうか。

開発の役割はどう変わるか

加えて、EDSの文脈では、「これからはフロントだけで良いのか」「AEM（Java）は要らなくなるのか」といった受け止め方をされることがあります。けれど当社の見立ては逆で、AEM（Java）はむしろ、企業サイトに必要な要件の中核に集中させたほうが強いと考えています。

たとえば、ガバナンス、ワークフロー、多言語、権限管理といった領域です。こうした統制が効かないと、企業サイトは運用の途中で破綻しやすくなります。一方で、表示やUIの改善は、小さく試して素早く直せる構造に寄せたほうが、改善を回しやすくなります。

つまり、役割は次のように整理できるでしょう。

• フロントは、改善を回しやすい構造を作る
• AEM（Java）は、統制や企業要件を担う

これによって、ひとり（あるいは一社）がすべてを抱え込む前提ではなくなり、得意領域を分けた進め方が現実的になります。EDSは新機能の追加というより、こうした役割の組み替えを後押しする考え方だと捉えています。

AIの文脈で見たときに、何が効いてくるのか

改善を小さく頻繁に試そうとすると、意外と早い段階で「回らない理由」が出てきます。たとえば、仕組みが複雑で直す場所が多い、変更の影響範囲が読みにくい、説明や確認に時間がかかる。こうした状態になると、改善の回転はすぐに落ちてしまいます。

そこで効いてくるのが、構造をできるだけシンプルに保つことです。依存関係を増やしすぎず、直すべき場所と影響範囲を追いやすくする。これだけでも、試作や修正のハードルが下がり、「作って試す」を回しやすくなります。

AIの活用も、突き詰めるとここに近いと感じています。複雑な前提が多いほど、意図を伝える説明コストが増えます。逆に、仕組みがシンプルなほど、支援ツールを使った試作や修正が進めやすくなります。EDSが比較的シンプルな技術スタックを前提にしている点は、改善を回しやすくするという狙いとも相性がよい、と捉えています。

技術者向け補足

フレームワーク否定ではなく依存を増やしすぎない話
大きい仕組みほど、変更のたびに説明や確認が増えやすくなります。改善を回すには、変更の粒を小さく保ち、影響範囲を追いやすくすることが重要です。AI活用の話も、突き詰めると「直しやすい構造をどう作るか」に帰着する場面が増えていきます。

BAのスタンス：EDS × Universal Editorを「成立させる」ために

当社の結論は、EDS × Universal Editorです。ただし重要なのは、単に「使う」ことではなく、運用や体制を含めて成立させることだと考えています。

設計を誤ると、編集できる人が限られてしまったり、運用が属人化したり、結果としてAEM側に負荷が戻ってしまったりします。さらに、更新が積み重なるほど統制が崩れ、サイト全体の運用が重たくなることも起こり得ます。こうした状態を避けるためには、技術の組み合わせ以前に、運用の前提を先に揃える必要があります。

そのため当社は、デザインシステムを起点に、コンテンツ構造を定義し、編集できる範囲と責任範囲を先に決めます。そのうえでPoC（Proof of Concept：概念実証）を行い、「どこまでEDS側で回せるか」「どこをAEM側に残すか」「誰の役割がどう変わるか」を現実に即して確認していきます。いきなり全面導入を目指すのではなく、相性を確かめながら進める。これが当社の現実的な進め方です。

さいごに

EDSのポイントは、単に「ページ表示が速くなる」ことだけではありません。ページを速く表示することと、改善を小さく頻繁に試せることが重要になる中で、AEMとパートナーの役割分担をどう設計し直すか。そこに本質があると考えています。

これは、新しい技術を足して終わり、という話ではありません。役割と前提を組み替える話です。だからこそ当社は、いきなり全面導入を目指すのではなく、PoCから一緒に整理しながら進めたいと考えています。

※本記事は登壇内容をもとに、Business Architectsとしての見解を整理したものです。アドビ株式会社の公式見解を示すものではありません。