Adobe Experience Manager 15周年 - 歴史

Adobe が Day Software の買収を完了し、現在「AEM」として皆さんに知られている製品を取得してから、今日で 15 年が経ちました。

私のように、このプラットフォームで何年も作業してきた皆さんにとって、Adobe が Day を買収した理由と、それから 15 年で何が変わったのか (そして何が変わっていないのか) を振り返るこの投稿が、楽しい (または辛い) 思い出の旅になることを願っています。

デー・コミュニケ - Adobe 買収前

Day Software はスイスのバーゼルに本拠を置く企業で、カスタムファイルシステムベースのプラットフォーム上で画期的な Communique CMS を開発しましたが、その後、現在知られている Java コンテンツリポジトリベースのシステムへと進化しました。

CQ の最初のバージョンは、2000 年初頭の Netscape Enterprise Server (使用したことがある方は手を挙げてください!) 用の CGI スクリプトのコレクションでしたが、CQ2 では Java アプリケーションとして書き直され、その後、CQ3 (CQSE の起源) では HTTP サーバーが分離されました。

CQ4 までは、コンテンツはローカル ファイル システム上のファイルに保存されていましたが、2005 年の CQ 4.0 のリリースで、古い「Content Bus」ファイル システム ストレージから「Content Repository eXtreme」(CRX) リポジトリ バージョン 1.0 に切り替えられました。この進化形は、20 年経った今でも AEM の基盤となっています。

CQ5は大規模なアップグレードであり、今日のAEMの基礎となりました。

CQ5 は、製品のほぼ完全な書き直しを表しています。

現在では当たり前のように思われる機能やアプローチが数多くありますが、それらは CQ5 プラットフォームの大きな革新的な部分でした。2008 年の CMSwire の魅力的な記事では、「一部の CMS ベンダーは Web 2.0の崩壊が差し迫っていると考え、Web 2.0 を避けていますが、Day はこれに大いに注力しています」と述べられています。その時代に Web 2.0 を 定義 できる人が何人いたでしょうか?しかし、CQ5 でリリースされた次のような膨大な新機能により、CQ5 は本質的にまったく新しいプラットフォームとなり、ほとんどの人は、CQ/AEM なしでは想像もできません。

• Sidekick と Author UI : CQ の GUI と WYSIWG オーサリングは当時大きなセールス ポイントであり、グラフィックが豊富な環境でコンポーネントを操作できるという事実は、当時の他の CMS 製品に比べて大きな進歩でした。

  

• ワークフロー: このリリースではワークフロー エンジンが追加されました。これもまた、CMS 内でワークフローを視覚化し、コンテンツ管理システム内にビジネス ロジックを直接開発できるという点で人々を驚かせました。この機能だけでも、多くの企業クライアントがシステムへの移行を決意しただろうと想像できる。

  

• CQ タグ: タグなしで CQ で作業することを想像できますか?タグ サポートを追加することで、CQ にフル機能の分類が導入されました。

• DAM : CQ5 のこのリリースでは、今では誰もがよく知っている/content/damパスにデジタル アセット マネージャーが追加されました。この初期の時代でも、ブラウザベース（Flash ではない）の画像切り抜きと回転が可能になりました。

  

• クラスタリング: これは CQ5 リリースでのみ存続し、良くも悪くも AEM6 には採用されませんでした。CQ5 にはかなり高度なクラスタリング機能があり、著者と発行者の両方に対してホット アクティブ/アクティブまたはアクティブ/パッシブ クラスタリング設定が可能になりました。Publisher クラスタリングを使用している顧客を 1 社だけ見たことがありますが、それはひどいアイデアであり、なぜそうしたのかはわかりません。ただし、著者のクラスタリングは、理論的にはクラスタ マスターで著者を作成し、その編集内容をクラスタ スレーブ (廃止された用語) に伝播できるようにする優れた「アイデア」でした。しかし、クラスタリングは常に信頼性の面で大きな悩みの種でした。

• CRX 開発環境: 当時、Day は、Java コンテンツ リポジトリへのクライアント側の詳細なビューを提供するために作業できる Eclipse ベースの開発環境をリリースしました。また、Eclipse の代わりに使用できる「CRX Development Environment Lite」または crxde と呼ばれる軽量のブラウザベースのインターフェースもリリースされました。これは現在でも ほぼ同じ形式 で残っています。

このバージョンでは新しい機能ではありませんが、言及する価値はあります。CQ の個別のオーサリング層と公開層により、オーサリング側のパフォーマンス制約や不安定性によって公開サイトがダウンすることはなくなり、その逆も同様です。CQ を OSGI と Sling の基盤上に配置することで、豊富な動的応答とページ レンダリングの両方が可能な、非常に柔軟なコンテンツ エンジンが実現しました。また、以前は独自のアプリケーション サーバー スタックで実行しなければならなかったあらゆる種類のアプリケーションに、Java で高度な処理を組み込む機能も備わっています。

CQリリースと変更のタイムライン

Adobe による買収までの CQ のバージョン履歴は次のようになりました。

• デイCQ 3.5 (2002)

• デイCQ 4.0（2005）

• デイCQ 4.1 (2006)

• デイCQ 4.2 (2008)

• Day CQ 5.0 (2008) - プレビューとして社内顧客のみにリリース

• Day CQ 5.1 (2008) - CQ5 の最初の一般公開リリース。ワークフロー、DAM、タグ、CRXDE、クラスタリング、サイドキックの最初の追加

• CQ 5.2日目（2009年）：

  • メタデータ処理の改善によるデジタル資産管理（DAM）の強化
  • コンテンツ処理のワークフロー エンジンの改善
  • Adobe Analyticsとの統合強化
  • ここで、 Multi-Site Manager (MSM) が初めて世にリリースされました。

• デイCQ 5.3 (2010)

  • ソーシャル コラボレーションのためのコミュニティ機能の導入 (注: AEM 6.5 LTS でのみ、この機能は最終的に廃止され、削除されました)。
  • A/B テストと多変量テストのための「サイト オプティマイザー」（この名前はすぐにまた聞くことになるでしょう）
  • 強化された翻訳ワークフローと国際化サポート

AdobeによるDay SoftwareとCQの買収

Adobe は 2010 年 7 月に Day Software を買収し、CQ 製品も買収すると発表しました。Adobe はこの時点ですでに CQ 上で独自の Web サイトを運営しており、マーケティング テクノロジー事業の構築に新たに注力していたことを考えると、これは当然のことでした。Adobe は 2009 年 9 月に Omniture を 18 億ドルで買収したばかりで、2007 年には Scene7 を買収したばかりでした。つまり、Adobe がクリエイティブ ソフトウェア ビジネスだけにとどまらない何かに本腰を入れ始めていたのは明らかでした。

Adobe による買収は 2010 年 9 月に全額現金で 2 億 4,000 万ドルで完了しました。これは Omniture に支払った金額の 7 分の 1 であり、今にして思えばかなりお買い得でした。

皆さんはどうか分かりませんが、私はこの取引が発表された時自分がどこにいたかを正確に覚えています。当時、私は AARP のために CQ 5.2 を運用していました (AARP は CQ 4.2 以来 CQ を使用していました)。当時の私にとっての CQ は、「大きな頭痛の種」であると同時に「CMS はこうなるのだろうか?」という思いでもありました。CQ に強力な Java アプリケーション サーバー フレームワークが備わったため、どのサービスを JBoss 上に残すべきか、またどのサービスを CQ5 内で簡単に実行できるかをまだ検討中だったからです。

しかし 今はAdobeに買収されたのでしょうか? これにより、CQ5 の学習に引き続き時間を投資するかどうかについての私の考えは一変しました。明らかに、Adobe が後ろ盾となっているため、CQ5 は成功する可能性が高いと思われたからです。そしてそれは起こりました！

アプリ内の「Day Software」ブランドはすぐに「Adobe CQ」に変更されましたが、その他は大部分同じままでした。

• Adobe CQ 5.4 (2011)

  • パフォーマンスとスケーラビリティを向上させる CRX2 リポジトリ (これは、CQ 5.3 から 5.4 へのリポジトリ移行という、私の最初の主要な CQ プロジェクトでした)
  • 強化されたソーシャル機能とコミュニティ管理
  • モバイルオーサリング機能の向上

• Adobe CQ 5.5 (2012)

  • Adobe Creative Suite、Scene7、Search&Promoteへのコネクタ
  • モバイルアプリの直接作成
  • eコマース統合のためのHybrisとの提携
  • エディターの元に戻す/やり直し機能
  • コンテンツ フラグメントは、私が実際に作業していた顧客向けのカスタム開発として最初にここに登場し、その後機能パックとしてリリースされました。

「Adobe Experience Manager」へのブランド変更

Adobe は、これが永久に「CQ」と呼ばれるわけではないことを知っていたので、最初は「Adobe WCM」、その後しばらくは「Web Experience Manager」と呼んでいましたが、何度かブランド変更を試みましたが失敗し、最終的に「Adobe Experience Manager」と呼ぶことに落ち着きました。5.6 リリースの途中でログイン画面が切り替わり、CQ にログインすると「Adobe Experience Manager」が表示されるようになりました。

• AEM 5.6 (2013)

  • TouchUI が Author 環境に導入されました (ClassicUI をまだ使用しているアプリケーションがいくつあるかご存じですか?)
  • モバイルサイトとアプリのサポート
  • パーソナライゼーションとターゲティングの改善
  • ビデオプロファイルを備えた拡張DAM

• AEM 6.0 (2014)
  AEM 6 は、AEM の基盤の多くを大幅に書き直したものです。私たちのようなビジネスに携わる者にとって、CQ5 から AEM6 への移行は非常に手間がかかる作業であったため、ほとんどの時間を占めていました。

  • AEM 6 では、基盤となるリポジトリが Apache Jackrabbit から Apache Oak に切り替えられたため、大規模な移行が必要になりました。
  • CQ のアクティブ/アクティブ クラスタリングは利用できなくなりましたが、Adobe は AEM 用の MongoMK ストレージ バックエンドを導入しました。これにより、理論的には (この時点では極めて理論的には) 水平スケーリングされた AEM Authors を提供できるようになりました。しかし、これは非常にバグが多く、私たちが行った唯一の実装は失敗に終わり、TarMKシングルオーサーに切り替えました。
  • ほとんどのページで TouchUI のフットプリントが拡大
  • 資産のスマートタグ

• AEM 6.1 (2015)

  • 多くのバグが修正されましたが、6.1 はまだ特に安定したリリースではありませんでした。
  • バニティURLのサポートは6.1で登場しました
  • パーソナライゼーションのためのContextHub
  • モバイルアプリSDK
  • AEM Communitiesが導入され、それに伴い、ユーザー生成コンテンツ用のインフラストラクチャとストレージのオプションも多数導入されました。今後、この機能は改善されていくと思われますが、残念ながらクラウド サービスへの移行後は維持されません。
  • AEM デスクトップ アプリが 6.1 でリリースされました。このアプリを使用して、作成者環境を 100% DDOS 攻撃することができました :(

• AEM 6.2 (2016)

  • さらに多くのバグ修正と安定性の向上 - まだ特に安定したリリースではありませんが、6.1 や 6.0 よりは大幅に優れています。
  • 広範囲にわたるコンテンツフラグメントの導入（以前は機能パック経由で実行できましたが、現在は製品の一部になっています）
  • AEM 内の SSL サポート
  • UI が、現在私たちが慣れているものに変更されました。ナビゲーションがサイドレールから上部に移動されました。

• AEM 6.3 (2017)

  • コア コンポーネントが「実稼働対応」として導入されました。
  • 6.3 では基盤となるストレージが大幅に改善され、最終的にこれが最初の非常に安定した AEM 6 リリースになりました。これにより、分離されたdatastoreとsegmentstoreが導入され、オンライン バージョン管理 (tar 圧縮) のための信頼性の高いメカニズムが導入されました。
  • 経験の断片が導入される
  • シングルページ アプリ用にシングル ページ エディター (SPA) が導入されました。
  • 「Adobe Sensei」は、当時としては画期的な AI 機能を備え、Adobe の AI ブランドとして AEM Assets に浸透し始めました。スマートクロッピング、スマートタグ付けなどが Assets に導入されました。

• AEM 6.4 (2018)

  • 6.4 は、アップグレードを容易にし、最終的にはクラウド サービスへの移行への道を開くことを目的とした「リポジトリ再構築」の最初のラウンドでした。
  • ワークフローをTouchUIに移行
  • 翻訳サービスにおける数々の改善
  • アセットのビデオスマートクロップ

• AEM 6.5 (2019)

  • リポジトリの再構築が多数
  • Connected Assets は、リモート アセット環境を別の AEM Sites 環境に接続するための潜在的なオプションを提供します。ただし、画像に対してのみ機能します。
  • SPAエディターの大幅な改善
  • コマース向けGraphQL
  • また、6.5 は現在までに 6 年間存続しており (これまでの AEM/CQ バージョンの中で最長です)、サービス パックを通じて多数の新機能がリリースされています。現時点では Service Pack 23 を使用していますが、2019 年以降にリリースされたすべての新機能のロールアップについては、独自のブログ投稿で取り上げる価値があります。

• AEM クラウド サービス (2020)
  2019 年の adaptTo() で初めて紹介されました (この時点では、ほとんどの人が実際に何を見ているのか分かりませんでした!)AEM as a Cloud Service は 2020 年 1 月に世界にリリースされ、2020 年に Adobe Summit が対面で開催されていたら、Adobe Summit 2020 で中心的な役割を果たしていたはずです。さらに残念です。AEM as a Cloud Service は、AEM と CQ の長年の欠点のいくつかを解決するために作成され、さまざまな成功を収め、今日の AEM 製品群の姿につながっています。提供される内容は次のとおりです。

  • クラウド上のフルサービスベースのAEM環境
  • 著者と出版社の層での自動スケーリング
  • 組み込みCDN
  • マイクロサービスベースのアセット取り込みエンジンによるワークフローとデータ取り込み機能の大幅な更新
  • AI 強化（RAG ベース）検索を備えた新しい検索機能がリリースされ、adaptTo() で話題になりました。

• AEM 6.5 LTS
  エンジニアリング担当者とマーケティング担当者のどちらと話しているのかによって、「AEM 6.6」または「AEM 6.5 LTS」とさまざまな名前が付けられている 6.5 LTS は、2025 年以降も AEM 6.5 ワークロードをセルフホストまたは AMS ホストし続けることを計画しているユーザー向けの長期的なオプションです。Java 11 はまもなくサポートが終了するため、AEM を Java 17 または Java 21 で実行することが唯一の選択肢となります。
  
  これは、2009年に発売された製品の完全な後継機として確実に残っている最後の製品です。/crx/packmgr 、 /crx/de 、 /etc/replication.htmlなど) は、元の CQ5 リリースのときとほぼ同じです。

• エッジ配信サービスとDA
  AEM の将来はどうなるのでしょうか? おそらく、将来的に AEM の機能面でも「精神的」面でも後継となるのは、配信層では Edge Delivery Services 、コンテンツ管理および作成者支援層ではDocument Authoringになるでしょう。これは確かに議論の余地があるが、DA は今後数年間に AEM が進むべき方向性について非常に力強い主張をしている。

著者について

聞いてみてどうでしたか？自分に合ったものについてご質問がありますか?ぜひご相談ください！お問い合わせ

おすすめのAEM関連記事