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