Adobe Commerce as a Cloud Service に移行
Adobe Commerce as a Cloud Service では、既存のAdobe Commerce PaaS 実装から新しいAdobe Commerce as a Cloud Service（SaaS）機能に移行する開発者向けの包括的なガイドを提供します。 Adobe Commerce as a Cloud Serviceは、完全に管理されたバージョンのない SaaS モデルへの大幅な移行を意味し、パフォーマンス、拡張性、操作の簡素化、より広範なAdobe Experience Cloudとの緊密な統合を実現します。
シフトの理解 – PaaS と SaaS の比較
主な違い
- [PaaS のみ ]{class="badge informative" title="Adobe Commerce on Cloud プロジェクト（Adobeが管理する PaaS インフラストラクチャ）およびオンプレミスプロジェクトにのみ適用されます。"}PaaS （最新）：マーチャントは、Adobeがホストする環境内でアプリケーションコード、アップグレード、パッチ適用、インフラストラクチャ設定を管理します。 サービス（MySQL、Elasticsearchなど）の 共有責任モデル。
- [SaaS のみ ]{class="badge positive" title="Adobe Commerce as a Cloud ServiceおよびAdobe Commerce Optimizer プロジェクトにのみ適用されます（Adobeで管理される SaaS インフラストラクチャ）。"}SaaS （新規 – Adobe Commerce as a Cloud Service）: Adobeは、コアアプリケーション、インフラストラクチャ、およびアップデートを完全に管理します。 マーチャントは、拡張ポイント（API、App Builder、UI SDK）を使用したカスタマイズに重点を置いています。 コアアプリケーションコードがロックされています。
アーキテクチャの含意
- バージョンのないプラットフォーム：継続的なアップデートは、コアのメジャーバージョンアップグレードがなくなることを意味します。
- マイクロサービスと API ファースト：拡張性と統合に API をより深く活用します。
- デフォルトのヘッドレス （オプション）：分離されたストアフロントの強力なサポート（Edge Delivery Servicesを活用したCommerce ストアフロントなど）。
- Edge Delivery Services: フロントエンドのパフォーマンスとデプロイメントに影響を与えます。
新しいツールと概念
移行パス
Adobe Commerce as a Cloud Service は、タイムライン、ストアフロント、カスタマイズに応じて、複数の移行パスをサポートしています。
完全移行の代わりに、Adobe Commerce as a Cloud Service ではCommerce Optimizerまたは増分アプローチを使用した段階的な移行をサポートしています。
- 増分移行 – このアプローチでは、データ、カスタマイズおよび統合を段階的に移行します。 このアプローチは、複雑なカスタマイズやデータを自分のペースで徐々に移行したいと考えている、カスタマイズが多い大規模なマーチャントに Adobe Commerce as a Cloud Service 適です。
- Commerce Optimizer – このアプローチを使用すると、Commerce Optimizerを移行段階として使用して、複雑なカスタマイズとデータを自分のペースで Adobe Commerce as a Cloud Service に移行することで、繰り返し移行できます。 Commerce Optimizerを使用すると、カタログビューとポリシーを活用したマーチャンダイジングサービス、Edge Deliveryを活用したCommerce Storefront、AEM Assetsを活用した製品ビジュアルにアクセスできます。
- 完全移行：このアプローチでは、すべてのデータ、カスタマイズ、統合を一度に移行する必要があります。 このアプローチは、Adobe Commerce as a Cloud Service に迅速に移行したいカスタマイズが少ない小規模なマーチャントに最適です。
次の表は、様々なストアフロントと設定での移行プロセスの概要を示しています。
表に示されているように、各移行の緩和策は次の要素で構成されます。
- データ移行 – 提供された 移行ツールを使用して、既存のインスタンスから Adobe Commerce as a Cloud Service にデータを移行します。
- ストアフロント - Edge Deliveryを活用した既存のCommerce ストアフロントとヘッドレスストアフロントは軽減の必要はありませんが、Luma ストアフロントはEdge Deliveryを活用したCommerce Storefront に移行する必要があります。 PWA Studio ストアフロントは、Edge Deliveryを活用して、または現在の状態で維持しながら、Commerce ストアフロントに移行できます。 Adobeは、ストアフロントへの移行を支援するためのアクセラレーターを提供します。
- API メッシュ– 新しいメッシュを作成するか、既存のメッシュを修正します。 Adobeは、このプロセスを支援するために事前設定済みのメッシュを提供します。
- 統合 – すべての統合は、 統合スターターキットまたは Adobe Commerce as a Cloud Service REST API のいずれかを活用する必要があります。
- カスタマイズ – すべてのカスタマイズは、App Builderと API メッシュに移動する必要があります。
- Assets Management – すべての Assets Management には移行が必要です。 既にAEM Assetsを使用している場合は、移行する必要はありません。
- 拡張機能 – 処理中の拡張機能は、プロセス外の拡張機能として再作成する必要があります。 2025 年末までに、Adobeは、ビルド時間を最小限に抑えるために、最も一般的な拡張機能へのアクセスを提供します。
移行フェーズ
次のフェーズでは、Adobe Commerce as a Cloud Service への移行に必要な手順と考慮事項を説明します。
移行前の評価と計画
このフェーズは、リスクを最小限に抑え、明確な移行パスを確立し、問題を発生前に特定するために重要です。
現状環境の把握・監査
コードベース分析：
- すべてのカスタムモジュール、テーマおよび上書きを特定します。
- コアコードの変更を分析し、移行の一環としてリファクタリングが必要なものを特定します。
- サードパーティの拡張機能を評価し、Adobe Commerce as a Cloud Service との互換性を判断します。 SaaS と互換性のある代替手段はありますか。それとも、カスタム API 統合またはApp Builder アプリケーションを作成する必要がありますか。
- 移行されない非推奨のコードまたは機能を特定します。
データ監査：
- データベースのサイズと複雑さを評価します。
- クリーンアップする未使用のデータまたはテーブルを特定します。
- 既存のデータのインポート/エクスポートプロセスを確認します。
統合の確認：
- Adobe Commerceと統合されているすべての外部システム（ERP、CRM、PIM、支払いゲートウェイ、配送業者、OMS、その他のシステム）をリストアップします。
- 統合メソッド（API、カスタムスクリプト、その他のメソッド）を評価します。
- Adobe Commerce as a Cloud Service の API ファーストのアプローチおよびApp Builderとの互換性を評価します。
パフォーマンスベンチマーク：
- 現在の Lighthouse スコア、ページ読み込み時間、主要業績評価指標（KPI）を文書化します。これは、移行後の改善を測定するベースラインとなります。
セキュリティ構成の確認：
- カスタムのWAF ルール、IP許可リスト、その他のセキュリティ設定を評価します。
移行の範囲と戦略を定義：
-
段階的な移行と一括の移行の比較： 各アプローチの長所と短所を評価します。
-
主要なビジネスプロセスの特定： 最初に移行する必要がある次のような機能の優先順位を付けます。
- 複雑な価格ルール
- 正式に注文または処理される前に適用されるカスタム ビジネス ルール
- 複雑な税計算
- アドレスの検証
- 注文後にトリガーされるカスタムロジック
-
ヘッドレスとモノリシックなストアフロントの比較： 新しいストアフロント開発または既存のストアフロントの適応のための決定ポイント。
-
統合方法： 既存の統合の再プラットフォーム方法（API メッシュ、App Builder、ダイレクト API）を決定します。
-
データ移行方法： 完全な履歴データを使用して移行するのか、部分的なデータを使用して移行するのか、移行したデータを使用せずに移行するのかを決定します。
チーム対応およびトレーニング：
- Adobe Commerce as a Cloud Service の概念、開発ワークフロー、新しいツールについて理解します。
- Adobe App Builder、Edge Delivery Servicesおよび Adobe Commerce as a Cloud Service デプロイメントパイプラインを使用した実践トレーニングに参加します。
環境のセットアップとプロビジョニング：
- Commerce Cloud Manager を使用して、Adobe Commerce as a Cloud Service サンドボックスと開発環境をプロビジョニングします。
増分移行フェーズ
戦略的なリファクタリングと外部化
このフェーズは、移行の中心で構成され、コードベースを Adobe Commerce as a Cloud Service のクラウドネイティブなパラダイムに適応させることに重点を置いています。 これには、新しいAdobe サービスを戦略的に採用し、カスタムロジックをコア Commerce プラットフォームから移動することが含まれます。
1. 「プロセス内」のカスタマイズと拡張機能をApp Builderに移行する
これは、Adobe Commerce as a Cloud Service しいアーキテクチャ哲学の中心となる、「ロックコア」を達成し、ソリューションを将来保証するための重要なフェーズです。
- 複雑なロジックをApp Builderに外部化:PaaS コードベース内の既存のカスタムモジュールやサードパーティの拡張機能を分析します。 コアとなるCommerce データモデルをプロセス内で直接操作する必要がない複雑なビジネスロジック、カスタム統合、マイクロサービスの場合は、Adobe Developer App Builder内でサーバーレスのアプリケーションとしてリファクタリングし、再プラットフォームします。
- API メッシュの活用：複数のバックエンドシステム（PaaS Commerce バックエンド、ERP、CRM、カスタム App Builder マイクロサービスなど）からのデータが必要な場合は、App Builder内に API メッシュレイヤーを実装します。 これにより、様々な API が、新しいストアフロントや他のサービスで使用される単一のパフォーマンスの高いGraphQL エンドポイントに統合され、複雑なデータの取得が簡単になります。
- イベント駆動型アーキテクチャ:Adobe I/O Eventsを利用して、PaaS インスタンスで発生したイベント（製品の更新、お客様の登録、注文のステータスの変更など）または他の接続されたシステムに基づいて、App Builderのアクションをトリガー化します。 これにより、非同期通信が促進され、タイトカップリングが減少し、システムの回復力が向上します。
メリット：このステップでは、深く組み込まれたカスタマイズに伴う技術的負担を大幅に軽減し、Commerce インスタンスの Adobe Commerce as a Cloud Service への移行を大幅に高速化し、カスタムロジックのスケーラビリティと独立的なデプロイ性を向上させ、拡張機能の開発サイクルを高速化します。
2. SaaS ベースのAdobe Commerce マーチャンダイジングサービスの採用とカタログデータの統合
これは、カタログデータ管理に関する 2 つのオプションを備えた、重要な初期統合ポイントです。
PaaS バックエンドと統合された既存のカタログ SaaS サービスを活用
このオプションは、PaaS バックエンドがAdobe Commerce SaaS サービスの既存のインスタンスに catalog service、live search、および product recommendations からのデータを入力する既存の統合を基盤とする移行段階として機能します。
- カタログデータの同期:Adobe Commerce PaaS インスタンスが既存のAdobe Commerce カタログ SaaS サービスに商品とカタログデータを引き続き同期させるようにします。 これは、通常、PaaS インスタンス内で確立されたコネクタまたはモジュールに依存します。 カタログ SaaS サービスは、検索機能とマーチャンダイジング機能に対する権限のあるソースであり、PaaS バックエンドからデータを取得します。
- 最適化のための API メッシュ：ヘッドレスストアフロント（Edge Delivery Services上）やその他のサービスはカタログ SaaS サービスのデータを直接使用する可能性がありますが、Adobeでは（App Builder内で） API メッシュを使用することを強くお勧めします。 API メッシュは、Catalog SaaS サービスの API を、PaaS バックエンドのその他の必要な API （例えば、トランザクションデータベースからのリアルタイムの在庫確認や、Catalog SaaS サービスに完全にレプリケートされていないカスタム製品属性）と統合して、パフォーマンスの高い単一のGraphQL エンドポイントにすることができます。 これにより、キャッシュ、認証および応答の一元化も可能になります。
- Live Search と Product Recommendations の統合: Live Search と Product Recommendations SaaS サービスを設定して カタログデータを取り込む既存のAdobe Commerce Catalog SaaS サービスから直接アクセスします。
メリット：既存および運用中のカタログ SaaS サービスとその PaaS バックエンドとの統合パイプラインを活用することで、ヘッドレスストアフロントおよび高度な SaaS マーチャンダイジング機能への迅速な道筋を提供します。 ただし、プライマリカタログデータソースの PaaS バックエンドへの依存関係は維持され、新しいコンポーザブルカタログデータモデルに固有のマルチソース集計機能は提供されません。 このオプションは、より完全でコンポーザブルなアーキテクチャに向けた有効な足掛かりとなります。
新しいコンポーザブルカタログデータモデル（CCDM）の採用
これは、Adobe Commerce Optimizerを活用する際の、戦略的で将来性のあるアプローチです。 CCDM は、マルチソースデータ集計と動的マーチャンダイジング用に設計された、柔軟で拡張性の高い統合カタログサービスを提供します。
-
データの取り込みと統合
-
まず、既存のAdobe Commerce PaaS インスタンス（または他の PIM/ERP システム）から新しいコンポーザブルカタログデータモデル（CDM）に商品およびカタログデータを取り込みます。
-
既存の製品属性を CCDM の柔軟なスキーマにマッピングします。 初回取り込みで重要な製品データの優先順位を付けます。
-
継続的な同期のための堅牢なデータパイプラインを確立します。 これには以下が含まれます。
- イベント駆動型 （App Builderを通じて）: PaaS インスタンスのAdobe I/O Eventsを、一般に公開されているアプリケーションまたはカスタムのAdobe App Builder アプリケーションにトリガーします。 これらのアプリケーションは、API を介してデータの変更（作成、更新、削除）を変換し、CCDM にプッシュします。
- バッチ取り込み：大規模な初期読み込みまたは定期的な一括更新の場合は、ステージング領域への安全なファイル転送（CSV や JSON など）を使用し、Adobe Experience Platform（AEP）取り込みサービスによって CCDM に処理されます。
- API の直接統合 （App Builder オーケストレーションとの統合）：より複雑なシナリオでは、App Builderがオーケストレーションレイヤーとして機能し、PaaS バックエンドに対して直接 API 呼び出しを行い、データを変換して CCDM にプッシュできます。
-
-
カタログ表示とポリシー定義:CCDM 内のカタログビュー（店舗表示、地域、B2B/B2C セグメントなど、一意のカタログ表示の論理グループ）を設定し、ポリシー（製品表示、フィルタリングおよびマーチャンダイジングのルールセット）を定義します。 これにより、商品の品揃えを動的に制御し、カタログビューごとの表示ロジックを有効にできます。
-
Live Search と Product Recommendations の統合：カタログデータが CCDM に存在したら、Adobeの SaaS ベースの Live Search サービスと Product Recommendations サービスを統合します。 これらは、Adobe Sensei AI と機械学習モデルを活用して、優れた検索関連性とパーソナライズされたレコメンデーションを実現し、CCDM から直接データを使用します。
メリット：カタログ管理と検出を CCDM と関連する SaaS サービスに抽象化することで、パフォーマンスの向上、AI 駆動型マーチャンダイジング機能の獲得、レガシーバックエンドからの読み取り操作の大幅なオフロード、ファネルエクスペリエンスの上位からの堅牢な「ピールオフ」が可能になります。
3. Edge Delivery Servicesでストアフロントを構築する
マーチャンダイジングデータパイプラインが確立され、カスタマイズが外部化されると、高性能なフロントエンドの構築に焦点が移ります。
-
初期設定:Edge Delivery Services用のAdobe Commerce ストアフロントボイラープレートを使用して、プロジェクトを設定します。 これは、最新の web テクノロジーに基づいて構築された、基本的なヘッドレスフロントエンドを提供します。
-
カタログサービスと API メッシュへの接続:Commerce ストアフロントは、主にGraphQL API を通じてデータを使用します。
- オプション 1：製品情報とマーチャンダイジングルール用の既存のカタログ SaaS サービス（API メッシュ経由）から。
- オプション 2：製品情報とマーチャンダイジングルールの CCDM から。
- 従来のバックエンド（PaaS インスタンス）またはカスタム App Builder サービスから調整されたデータの API メッシュから（例：リアルタイム在庫、カスタム製品属性、ロイヤルティポイント表示）。
-
コンテンツ移行（AEM サービス）：既存の静的コンテンツ（「会社概要」ページ、ブログ投稿、マーケティングバナーなど）をAEM サービスに移行します。これにより、Commerce ストアフロントが強化されます。 AEMのコンテンツオーサリング機能を活用し、Edge Delivery Services用にアセットが最適化されていることを確認します。
-
コア UI コンポーネントの開発:Edge Delivery Services ドロップインコンポーネントとカスタム React/Vue コンポーネントを使用して、製品詳細ページ（PDP）、製品リストページ（PLP）、一般コンテンツページ用の重要なユーザーインターフェイスコンポーネントを構築します。 コアコマースフローの優先順位付け。
-
既存の買い物かご/チェックアウトとの統合：最初に、Edge Delivery Services ストアフロントは、買い物かごの管理とチェックアウトのために、既存のAdobe Commerce PaaS （またはその他のサードパーティプラットフォーム）へのハンドオフを調整します。 これには通常、次のものが含まれます。
- リダイレクト：ユーザーを従来のプラットフォームのネイティブな買い物かごおよびチェックアウト URL にリダイレクトし、必要なセッションと買い物かご識別子を渡します。
- 直接 API インタラクション （App Builder オーケストレーションを使用）:Edge Delivery Services内に、PaaS バックエンドの買い物かごとチェックアウト API と直接やり取りする、カスタムの買い物かごとチェックアウト UI コンポーネントを構築します。 これには、多くの場合、複数のバックエンドサービス（PaaS の買い物かご、支払い用ゲートウェイ、配送用の計算機など）への呼び出しを調整するための、バックエンド向けバックエンド（BFF）としてのApp Builderが含まれます。
メリット：超高速で、SEO に最適化され、非常に柔軟なストアフロント体験を提供します。 このフェーズは、優れた顧客体験に直接貢献し、将来のフロントエンドイノベーションの基盤を築きます。
4. データ移行（段階的プロセス）
データ移行は、リファクタリングとストアフロント開発を同時に実行する重要な多面的なプロセスであり、データの一貫性と整合性を確保します。
- 既存データのクリーンアップと最適化：大規模な移行の前に、既存の PaaS データベースで包括的なデータクレンジング、重複排除、検証を実行します。 このプロアクティブな手順は、従来のデータの転送に関する問題を最小限に抑え、新しい環境でのデータの品質を確保するために重要です。
一括データ移行
一括データ移行には、Adobe Commerce PaaS インスタンスから完全なデータダンプを取得し、データセット全体を変換して、それを一度にAdobe Commerce as a Cloud Serviceに読み込む必要があります。 このメソッドは、通常、データの初期母集団に使用されます。
-
ツールの可用性：お客様がファーストパーティのCommerce一括データ移行に使用できる専用の 一括データ移行ツールは、2025 年 7 月中旬のリクエストで利用できるようになります。 お客様が事前に一括データ移行の支援を必要とする場合、Adobeは、リクエストに応じて、データ転送を容易にすることができます。
-
プロセス:
- 完全なデータの書き出し:Adobe Commerce PaaS インスタンスからデータセット全体（製品、カテゴリ、顧客アカウント、注文履歴データ、静的ブロック、ページコンテンツなど）を抽出します。
- データ変換：抽出したデータを新しいAdobe Commerce as a Cloud Service コンポーネントのスキーマ要件（採用されている場合はコンポーザブルカタログデータモデル（CCDM）やその他の関連Adobe サービスやデータベースなど）に合わせるために、必要な変換を適用します。 これには、カスタムスクリプトや専用のデータマッピングツールが含まれる場合があります。
- 最初の読み込み：変換された完全なデータセットをAdobe Commerce as a Cloud Serviceの各コンポーネントに読み込みます。 製品データとカテゴリデータの場合は、選択したカタログサービス（CCDM または既存のカタログ SaaS）が入力されます。 顧客データと注文データの場合は、トランザクションバックエンドまたは関連するサービスが設定されます。
- 検証：読み込んだデータを厳格に検証し、すべての新しいシステム間での完全性、正確性、一貫性を確保します。
反復データ移行
反復データ移行では、ソース PaaS インスタンスから新しいCloud Service コンポーネントに増分的な変更と差分を同期することに重点を置いており、カットオーバーの前後でのデータの鮮度を確保しています。
-
ツールの可用性：反復的なデータ移行のために特別に設計されたツールは、2025 年後半に利用可能になります。
-
プロセス:
- デルタ識別：前回の同期以降に、PaaS 環境の重要なデータセットに加えられた変更（作成、更新、削除）を識別するメカニズムを確立します。 これには、CDC （Change Data Capture）、タイムスタンプ比較、イベントベースのトリガーなどが含まれます。
- 継続的な同期:PaaS 環境から新しいCloud Service コンポーネント（CCDM やトランザクションバックエンドなど）に継続的に増分データを同期するための堅牢なメカニズムを実装します。 これは、データの鮮度を維持し、カットオーバー時のダウンタイムを最小限に抑えるうえで重要です。
- イベントの活用：可能な場合はAdobe I/O Eventsを利用して、App Builderのアクションをトリガーに設定し、PaaS インスタンスから新しいサービスに対して、リアルタイムまたはほぼリアルタイムの更新を行います。 例えば、PaaS の商品の更新により、CCDM の対応するエントリを更新するイベントがトリガーになる場合があります。
- API 駆動型アップデート：イベント駆動型でないデータの場合は、（App Builderまたはその他の統合プラットフォームを通じて）スケジュールされた API 呼び出しを使用して、PaaS から変更を取り込み、新しいシステムにプッシュします。
- エラー処理と監視：すべての反復データパイプラインに対して堅牢なエラー処理、ログおよび監視を実装し、プロセス全体でデータの整合性が確実に維持されるようにします。
移行後および進行中の操作
DNS カットオーバーと運用開始：
- 最小限のダウンタイムで、DNS カットオーバーを慎重に計画します。
- 起動後直ちにサイトの正常性とパフォーマンスを監視します。
ローンチ後の操作：
PaaS 環境の廃止：
- 検証期間後に、古い PaaS インスタンスとデータを安全にアーカイブまたは削除します。
進行中の開発ワークフロー：
- 大規模なアップグレードではなく継続的に小規模なデプロイメントを行う、Adobe Commerce as a Cloud Service のバージョンを問わない特性を採用する。
- Cloud Managerを使用した環境とデプロイメントの管理
- App Builderを活用すれば、コアに影響を与えずに機能を拡張できます。
監視、パフォーマンス、セキュリティ：
- サイトのパフォーマンス、エラー、セキュリティ・ログを継続的に監視します。
- Adobeに組み込まれているセキュリティ機能を利用し、ベストプラクティスに従います。
トレーニングとドキュメント：
- Adobe Commerce as a Cloud Service プラットフォームとワークフローで、新しい開発者とビジネスユーザーをトレーニングします。
- カスタムの統合およびプロセスに関する最新の内部ドキュメントを維持します。