はじめに さくらインターネットのCDNサービス「さくらのウェブアクセラレータ」は、2016年10月1日にさくらのクラウドのオプションサービスとして正式提供を開始し、2026年10月で提供開始から10周年を迎えます。月間数 […]

はじめに こんにちは！ KINTOテクノロジーズのデジタル戦略部DataOpsグループ所属の三浦です。 普段は、社内のデータ分析基盤の開発・保守・運用に加え、Google Analytics 4（以下、GA4）やGoogleタグマネージャー（以下、GTM）を利用した、Webサイトのアクセス解析や計測環境の整備を担当しています。 WebサイトでGA4やGoogle広告を計測する場合、一般的にはGoogleドメインからGoogleタグを読み込み、Googleドメインへ計測リクエストを送信します。 一方、ブラウザのプライバシー保護機能や広告ブロッカーなどの影響により、Googleタグの読み込みや計測リクエストがブロックされ、イベントが欠損することがあります。 今回、この課題への対応として、既存のAmazon CloudFrontを利用し、Googleタグゲートウェイを導入しました。 本記事では、Googleタグゲートウェイを導入した背景や構成、社内での役割分担、検証時に確認したポイント、導入後に確認できた効果について紹介します。 本記事の対象者 本記事は、以下のような方を対象としています。 GTMやGA4を利用したWebサイトの計測を担当している方 Googleタグゲートウェイの導入を検討している方 Amazon CloudFrontをCDNとして利用している方 本記事では、CloudFrontの細かな設定手順ではなく、導入時の考え方や進め方、検証内容を中心に紹介します。 Googleタグゲートウェイ導入の背景と概要 背景 当グループでは、Webサイトの利用状況や広告施策の成果を把握するため、GTMを利用してGA4やGoogle広告などの計測タグを配信しています。 通常の構成では、WebサイトからGoogleドメイン上のGoogleタグを読み込み、計測したイベントをGoogleドメインへ送信します。 通常のGoogleタグ配信の構成 しかし、Googleドメインへの通信は、ブラウザのプライバシー保護機能や広告ブロッカーなどによって、制限されることがあります。 計測タグや計測リクエストがブロックされると、ユーザーが実際にページを閲覧したり、コンバージョンしたりしていても、GA4やGoogle広告へイベントが送信されません。 その結果、以下のような課題が発生する可能性があります。 GA4で確認できるイベント数が、実際の発生件数より少なくなる コンバージョン数が正しく計測されない Webサイトの施策評価に使用するデータが不完全になる 広告経由の成果を正しく評価できない 広告配信の最適化に使用するコンバージョンデータが不足する 特に広告配信では、計測したコンバージョンデータが、自動入札や配信対象の最適化に利用されます。 そのため、イベントの欠損は、レポート上の数値が少なくなるだけでなく、広告配信の学習や最適化にも影響する可能性があります。 実際に対象サイトでは、GA4で計測しているコンバージョンページのイベント数と、バックエンドのデータベースに保存されているコンバージョン件数に差がありました。 もちろん、GA4とバックエンドのデータベースでは、計測の仕組みや集計条件が異なります。 そのため、数値が完全に一致するものではありません。 一方で、差が大きい状態では、実際に発生したコンバージョンの一部をGA4で取得できていない可能性があり、広告施策やサイト改善を評価するうえで課題となっていました。 そこで、Googleタグへの通信を自社ドメイン経由に変更し、タグやイベントがブロックされる影響を軽減することを目的として、Googleタグゲートウェイを導入しました。 概要 対象のWebサイトでは、CDNとしてすでにAmazon CloudFrontを利用していました。 そのため、新たにサーバーを構築するのではなく、既存のCloudFrontを利用してGoogleタグゲートウェイへの通信を中継する構成を採用しました。 導入後の構成は以下のとおりです。 flowchart TB Browser[Webブラウザ] --> Domain[Webサイトと同じ自社ドメイン] Domain --> CF[Amazon CloudFront] CF -->|通常のWebコンテンツ| Origin[既存の配信先] CF -->|Googleタグゲートウェイ用のパス| GTG[Googleタグゲートウェイ] GTG --> GA4[GA4・Google広告など] Webサイト上にGoogleタグゲートウェイ用のパスを用意し、そのパスへの通信をCloudFrontからGoogle側へ転送します。 ブラウザから見ると、Googleタグの読み込み先や対象となる計測リクエストの送信先が、Googleドメインではなく、Webサイトと同じ自社ドメインになります。 Googleタグゲートウェイ導入前後の構成図 要素技術・アーキテクチャの紹介 ここからは、今回の導入で利用したGoogleタグゲートウェイとAmazon CloudFrontについて紹介します。 Googleタグゲートウェイとは？ Googleタグゲートウェイ（ Google tag gateway for advertisers ）は、自社が管理するCDNやロードバランサーなどのインフラを利用して、Googleタグを自社ドメイン経由で配信する仕組みです。 通常はGoogleドメインから読み込まれるGoogleタグを、自社ドメイン上の特定のパスから読み込めるようにします。導入前後の経路の違いは、前述の「 概要 」節の構成図のとおりです。 Googleタグゲートウェイでは、GA4のイベント設計や、GTMコンテナ内のタグの処理内容を大きく変更するのではなく、Googleタグへアクセスする経路を変更します。 そのため、既存のGTMコンテナ内のタグ、トリガー、変数などを維持したまま導入できます。 Amazon CloudFrontとは？ Amazon CloudFront は、AWSが提供するCDNサービスです。 Webサイトのコンテンツを利用者に近い拠点から配信することで、表示速度や可用性の向上に利用されます。 CloudFrontでは、アクセスされたURLのパスに応じて、異なる配信先へリクエストを振り分けられます。 今回はこの仕組みを利用し、Googleタグゲートウェイ用のパスへの通信のみを、Google側へ転送するようにしました。 サーバーサイドGTMとの違い Googleタグゲートウェイと混同しやすい仕組みに、サーバーサイドGTMがあります。 サーバーサイドGTMでは、サーバー用のGTMコンテナを構築し、サーバー側で計測リクエストを処理し、送信先を制御します。 一方、Googleタグゲートウェイは、Googleタグの読み込みや対象となる計測リクエストを、自社ドメイン経由に変更する仕組みです。 観点 Googleタグゲートウェイ サーバーサイドGTM 変更するもの Googleタグへの通信経路 計測リクエストの処理・送信先 追加で必要なもの CDN / ロードバランサーの設定 サーバー用GTMコンテナと実行環境 既存のWeb用GTMコンテナ そのまま利用 サーバー用コンテナ向けの設定追加が必要 今回の目的は、既存のGTM構成を維持しながら、Googleタグへの通信経路を変更することでした。 そのため、新たなサーバー用GTMコンテナは構築せず、既存のCloudFrontとWeb用のGTMコンテナを利用する構成を採用しました。 導入の進め方 各担当者の役割分担 今回の導入では、計測担当だけでなく、インフラ担当、プロダクトチームのサイト管理者と連携して進めました。 大きな役割分担は以下のとおりです。 DataOpsグループ・計測担当 Googleタグゲートウェイの導入目的と要件の整理 対象ドメインや対象環境の整理 Googleタグゲートウェイ用パスの検討 ブラウザやGA4を利用した動作確認 既存の計測への影響確認 導入前後のイベント数の比較 インフラ担当 CloudFrontへのGoogleタグゲートウェイ用設定の追加 Googleタグゲートウェイへの転送設定 検証環境と本番環境への設定反映 必要に応じたCloudFrontやWAFの調査 プロダクトチーム・サイト管理者 Webサイトに設置しているGTMコードスニペットの差し替え 検証環境と本番環境へのリリース Googleタグゲートウェイは、GTMやGA4だけで完結する機能ではありません。 CDNなどの配信基盤と、Webサイトへ設置しているGTMコードスニペットの両方に対応が必要です。 そのため、導入前に各担当者の作業範囲と、検証時の確認項目を整理しました。 GTMコンテナ側の設定は変更しない Amazon CloudFrontを利用した今回の構成では、GTMコンテナ側でGoogleタグゲートウェイ用の設定変更は行っていません。 既存の本番用GTMコンテナを、そのまま利用しました。 変更したのは、Webサイトに設置されているGTMコードスニペットの読み込み先です。 変更前 GoogleドメインからGTMコンテナを読み込む 変更後 自社ドメイン上のGoogleタグゲートウェイ用パスから 同じGTMコンテナを読み込む GTMコンテナ内のGA4タグ、Google広告タグ、トリガー、変数などは変更していません。 GTMコードスニペットの差し替えについては、Webサイトを管理しているプロダクトチームへ依頼し、検証環境と本番環境へ反映してもらいました。 通信経路のみを変更する構成だったため、既存の計測設計への変更を抑えて導入を進められました。 検証用GTMコンテナは作成しない 今回の導入では、Googleタグゲートウェイの検証用に、新しいGTMコンテナは作成しませんでした。 実際に本番環境で利用しているGTMコンテナを、検証環境でもそのまま利用しました。 導入の流れは以下のとおりです。 検証環境のCloudFrontへ設定 検証環境のGTMコードスニペットを差し替え 検証環境で動作確認 本番環境のCloudFrontへ設定 本番環境のGTMコードスニペットを差し替え 本番環境で動作確認 先に検証環境のCDNへGoogleタグゲートウェイの設定を追加し、プロダクトチームに検証環境のGTMコードスニペットを差し替えてもらいました。 そこで問題がないことを確認した後、本番環境のCloudFront設定とGTMコードスニペットを変更しました。 本番用のGTMコンテナをそのまま使用したことで、検証用コンテナと本番用コンテナの間に設定差分が発生しません。 実際に本番で使用するタグ構成のまま、通信経路の変更による影響を確認できました。 検証時のポイント Googleタグが自社ドメインから読み込まれているか 最初に、ブラウザの開発者ツールにあるNetworkタブを利用し、GTMコンテナの読み込み先を確認しました。 導入前はGoogleドメインから読み込まれていたGTMコンテナが、導入後は自社ドメイン上のGoogleタグゲートウェイ用パスから読み込まれていることを確認します。 導入前 https://www.googletagmanager.com/... 導入後 https://www.example.com/<Googleタグゲートウェイ用パス>/... 読み込み先だけでなく、HTTPステータスコードが正常であることや、ページ表示時にGTMコンテナが問題なく実行されていることも確認しました。 既存のタグがこれまでどおり発火するか Googleタグの読み込み先を変更しても、GTMコンテナ内のタグやトリガーが、これまでどおり動作する必要があります。 GTMのプレビューモードを利用し、以下を確認しました。 ページ表示時に必要なタグが発火すること クリックなどのイベントタグが発火すること GA4へ必要なイベントが送信されること イベントパラメータの値が導入前と変わっていないこと 同一イベントが重複して送信されていないこと 今回、GTMコンテナ内の設定自体は変更していません。 そのため、通信経路を変更したことで、既存のタグ発火やイベント送信に影響が出ていないかを中心に確認しました。 GA4でイベントを確認できるか ブラウザ上でタグが発火していても、最終的にGA4へイベントが到達していなければ、計測は成立しません。 GA4のDebugViewやリアルタイムレポートを利用し、以下を確認しました。 ページビューが送信されていること 主要なイベントが送信されていること イベントパラメータが欠損していないこと page_location などの値が正しいこと コンバージョンページのイベントが送信されていること 導入前と比較して、想定外の重複や減少がないこと Googleタグゲートウェイを経由した場合でも、GA4上では、これまでと同じイベント名やパラメータとして確認できます。 SPAの画面遷移も確認する 対象サイトには、ページ全体を再読み込みせずに画面を切り替えるSPA形式のページもありました。 SPAでは、初回表示時にGTMコンテナが正常に読み込まれていても、その後の画面遷移でページビューやイベントが正しく送信されるとは限りません。 そのため、以下を分けて確認しました。 ページを最初に表示したときの計測 ページ内で画面遷移したときの計測 画面遷移後の page_location 仮想ページビューの発火 前画面の値が dataLayer に残っていないか 同じイベントが重複して送信されていないか Googleタグゲートウェイ自体は通信経路を変更する仕組みですが、導入を機に、既存のSPA計測が正常に動作していることも合わせて確認しました。 プレビューモードだけで判断しない GTMのプレビューモードでは正常に見えていても、プレビューモードを利用しない通常アクセスでは、想定した通信が発生していない場合があります。 そのため、以下の両方で確認しました。 GTMのプレビューモードを利用した状態 プレビューモードを利用しない通常アクセス 問題が発生した場合は、以下の順番で確認すると、原因を切り分けやすくなります。 Webサイト上でGTMコードスニペットが実行されているか GTMコンテナが読み込まれているか 対象のタグが発火しているか ブラウザから計測リクエストが送信されているか CloudFrontへリクエストが到達しているか Google側へ転送されているか GA4でイベントを確認できるか ブラウザのNetworkタブにリクエスト自体が表示されていない場合は、CloudFrontより前のWebサイトやGTMの処理を確認します。 一方、ブラウザからリクエストが送信されているものの、エラーになっている場合は、インフラ担当と連携して、CloudFrontやWAFなどを確認します。 すべての通信が自社ドメイン経由になるわけではない 検証時には、ブラウザのNetworkタブからGoogle関連の通信を確認しました。 その結果、GA4の計測では自社ドメイン経由になっている通信を確認できましたが、一部の通信は、引き続きGoogleドメインへ送信されていました。 :::message Googleタグゲートウェイを導入したからといって、Googleに関係するすべての通信が自社ドメイン経由になるわけではありません。 ::: そのため、Googleドメインへの通信が完全になくなるかどうかではなく、対象となるGoogleタグや計測リクエストが、想定どおり自社ドメインを経由しているかを確認しました。 導入後の効果 Googleタグゲートウェイの導入後、タグの発火状況と、コンバージョンページのイベント数を確認しました。 タグの発火状況が改善した 導入前は、Googleタグの読み込みや計測リクエストをGoogleドメインへ直接送信していました。 導入後は、対象通信が自社ドメインを経由する構成へと変更されました。 これにより、広告ブロッカー等に起因するタグの未発火が抑制され、GA4へ送信されるイベント数が前月比・前週比で約10〜15%増加しました。 :::message 旧環境との完全な並行稼働による厳密な差分比較はできないため、前後期間の傾向に基づく推定値です。 ::: Googleタグゲートウェイを導入しても、すべてのユーザー環境で必ずタグが発火するようになるわけではありません。 例えば、以下のような要因によって、引き続きイベントが送信されない可能性があります。 JavaScriptが無効化されている ユーザーの同意状況によって計測が制限されている ページ表示が完了する前にユーザーが離脱した ブラウザやネットワークの状態によって通信に失敗した 一方で、Googleドメインへの直接通信がブロックされることによるイベント欠損については、一定の改善効果を確認できました。 GA4とバックエンドデータベースの数値差が縮小した 今回、導入効果を確認するため、GA4で計測したコンバージョンページのイベント数と、バックエンドのデータベースに保存されているコンバージョン件数を比較しました。 導入前は、バックエンドのデータベース上ではコンバージョンが記録されているものの、GA4では対応するイベントを確認できないケースがあり、両者の数値に大きな差がありました。 導入前 バックエンドDBのコンバージョン件数 ＞ GA4のコンバージョンページイベント数 Googleタグゲートウェイの導入後は、GA4で確認できるコンバージョンページのイベント数が増加し、バックエンドのデータベースに記録されている件数へ大きく近づきました。 導入後 バックエンドDBのコンバージョン件数 ≒ GA4のコンバージョンページイベント数 バックエンドのデータベースとGA4では、計測の仕組みや集計条件が異なるため、両者の数値が完全に一致するとは限りません。 例えば、コンバージョン処理がバックエンドで完了していても、ユーザーが完了ページを表示する前に離脱した場合は、GA4のページイベントが発生しない可能性があります。 また、同意設定やブラウザ環境などによって、GA4への送信が制限される場合もあります。 それでも、導入後に両者の数値差が大きく縮小したことから、これまで欠損していた一部のイベントを取得できるようになったと考えています。 広告施策の評価に利用するデータが改善した コンバージョンイベントの取得数が増えたことで、GA4やGoogle広告で確認できるデータが、実際のコンバージョン状況により近づきました。 これにより、広告施策ごとの成果を、導入前より正確に評価できるようになりました。 また、Google広告へ連携されるコンバージョンデータの欠損が減ることで、自動入札や広告配信の最適化に利用できるデータ量の改善も期待できます。 ただし、広告の成果や配信精度は、以下のような複数の要因に左右されます。 広告予算 入札戦略 ターゲティング 広告クリエイティブ ランディングページ 市場環境 コンバージョン設定 そのため、Googleタグゲートウェイの導入だけで広告成果や広告精度が向上したとは断定していません。 今回の主な成果は、広告施策の評価や配信最適化に利用する、コンバージョンデータの欠損を減らせたことだと考えています。 振り返り GTMコンテナ内の変更を抑えて導入できた 今回の構成では、GTMコンテナ内のGA4タグ、Google広告タグ、トリガー、変数などを変更していません。 CloudFront側の通信経路と、Webサイトに設置しているGTMコードスニペットの読み込み先を変更することで導入できました。 既存の計測設計への影響を抑えながら導入できた点は、大きなメリットでした。 検証環境から段階的に導入することが重要 いきなり本番環境へ反映するのではなく、先に検証環境のCloudFront設定とGTMコードスニペットを変更しました。 検証環境では、GTMコンテナの読み込み、GA4イベント、SPA遷移、コンバージョンページなどを確認しました。 問題がないことを確認した後に本番環境へ展開することで、既存計測への影響を抑えながら導入できました。 複数チームの連携が必要 Googleタグゲートウェイは、GTMやGA4だけでなく、CloudFrontなどの配信基盤と、Webサイトに設置されるコードにも関係します。 今回の導入では、DataOpsグループ、インフラ担当、プロダクトチームがそれぞれ以下を担当しました。 DataOpsグループ：要件整理、計測確認、効果検証 インフラ担当：CloudFrontの設定 プロダクトチーム：GTMコードスニペットの差し替え 事前に担当範囲を整理したことで、検証環境から本番環境への展開をスムーズに進められました。 レイヤーごとに切り分けることが重要 Googleタグゲートウェイ導入後の通信には、複数の要素が関係します。 Webサイト ↓ GTMコードスニペット ↓ GTMコンテナ ↓ ブラウザ ↓ Amazon CloudFront ↓ Googleタグゲートウェイ ↓ GA4・Google広告など 問題が発生した場合は、最初からすべてを調査するのではなく、どこまで正常に処理されているかを順番に確認することが重要です。 ブラウザのNetworkタブ、GTMのプレビューモード、GA4のDebugViewなどを組み合わせることで、問題がWebサイト側にあるのか、GTMにあるのか、インフラ側にあるのかを切り分けやすくなりました。 おわりに 今回は、Amazon CloudFrontを利用して、Googleタグゲートウェイを導入した事例を紹介しました。 Googleタグゲートウェイの導入だけで、すべてのイベント欠損を防げるわけではありません。 一方で、Googleドメインへの直接通信がブロックされることによる欠損を軽減し、サイト改善や広告施策の判断に利用するデータを、実態に近づける効果を確認できました。 Amazon CloudFrontを利用してGoogleタグゲートウェイの導入を検討されている方にとって、本記事が少しでも参考になれば幸いです。

はじめに 企業がデジタルコマースプラットフォームのモダナイゼーションを進める中で、多くの企業は、コアとなる SAP ERP ワークロードを AWS 上の SAP Cloud ERP Private で運用しながら、SAP Commerce Cloud SaaS を採用しています。SAP Commerce Cloud は、複雑な B2B、B2C、B2B2C の企業向けに設計された統合型 e コマースプラットフォームであり、ホスティング場所を SAP が決定する完全マネージド型の SaaS ソリューションとして提供されます。そのため、重要なアーキテクチャ上の問いは、プラットフォームがどこで稼働するかではなく、AWS 上でホストされている SAP システムといかに効果的に統合するか、という点になります。SAP は、SAP Commerce（SAP Hybris）2205 のメインストリームメンテナンスの終了を 2026 年 7 月 31 日 と発表しており、多くの企業は、SAP Commerce Cloud SaaS と AWS 上で稼働する SAP Cloud ERP Private を統合することで、e コマースインフラストラクチャのモダナイゼーションをますます進めています。正しく設計されたとき、この統合モデルはセキュリティ、高いパフォーマンス、そして運用のシンプルさをもたらします。本ブログでは、4 つの重要な観点、すなわち 1) リージョン選択、2) レイテンシー最適化、3) ネットワーキング、4) セキュリティ実装にわたって、実証済みのアーキテクチャのベストプラクティスを探ります。これらのプラクティスは、SAP Commerce Cloud と AWS 上でホストされる SAP ランドスケープとの間で、堅牢かつスケーラブルな統合を構築するのに役立ちます。 SaaS は一貫性のある予測可能なユーザー体験を提供するように設計されている あらゆる SaaS プラットフォームの中核的な強みは、オンラインでアクセスできる場所であればどこからでも、一貫性のある予測可能なユーザー体験を提供できる点にあります。SAP Commerce Cloud はまさにこの目的のために構築されています。これは、リージョンやネットワークを越えて、買い物客、パートナー、モバイルデバイス、バックエンドシステムにサービスを提供します。ネットワークの変動、レイテンシーの差異、地理的に分散したアクセスに対応することは、このプラットフォームの基本的な設計原則です。 この運用モデルは、今日の大企業における標準的な実践です。企業は、CRM、人事、決済処理、物流、分析プラットフォームなど、複数の SaaS アプリケーションを自社のコアシステムと日常的に統合しています。SAP Commerce Cloud も、この実証済みの同じパターンに従っており、多様な SaaS ソリューションを AWS 上の SAP Cloud ERP Private と統合することは、現在のエンタープライズ標準となっています。 ベストプラクティス 1: リージョン選択 統合パフォーマンスを最適化するため、最も近い AWS リージョンを選択してください。AWS はグローバルなリージョンネットワークを運用しており、企業は SAP S/4HANA のデプロイを Commerce Cloud のエンドポイントと地理的に整合させることができます。鍵となるのは、SAP Commerce Cloud のホスティング場所に地理的に最も近い AWS リージョンを選択することです。このアプローチにより、ラウンドトリップのレイテンシーを最小化し、2 つのプラットフォーム間のリアルタイム API 呼び出しの応答性を向上させます。最も近い AWS リージョンを選択する際に、エンドユーザーの所在地と SAP Commerce Cloud のホスティングリージョンの両方を考慮することで、企業は予測可能で効率的な接続性を実現できます。このリージョン近接性の戦略は、複雑なネットワーク構成を必要とせずにクロスプラットフォーム統合を最適化するための、実践的かつ非常に効果的な方法です。 SAP Commerce Cloud リージョン AWS 上で稼働する SAP Commerce Cloud 向け Intelligent Selling Services * 推奨される最も近い AWS リージョン オーストラリア: ニューサウスウェールズ アジアパシフィック（シドニー）– ap-southeast-2 ブラジル: サンパウロ 南米（サンパウロ）– sa-east-1 カナダ: トロント カナダ（中部）– ca-central-1 中国: 香港 アジアパシフィック（香港）– ap-east-1 中国: North 3 中国（北京）– cn-north-1 中国: 上海 中国（寧夏）– cn-northwest-1 ドイツ: フランクフルト ドイツ: フランクフルト ヨーロッパ（フランクフルト）– eu-central-1 インド: プネ アジアパシフィック（ムンバイ）– ap-south-1 日本: 東京 アジアパシフィック（東京）– ap-northeast-1 オランダ: アムステルダム ヨーロッパ（アムステルダム）– eu-west-3 またはヨーロッパ（アイルランド）– eu-west-1 シンガポール アジアパシフィック（シンガポール）– ap-southeast-1 英国: ロンドン ヨーロッパ（ロンドン）– eu-west-2 アラブ首長国連邦: ドバイ 中東（UAE）– me-central-1 米国: カリフォルニア 米国西部（北カリフォルニア）– us-west-1 または米国西部（オレゴン）– us-west-2 米国: バージニア 米国東部（バージニア北部） 米国東部（バージニア北部）– us-east-1 米国: バージニア (2) 米国東部（バージニア北部）– us-east-1 または米国東部（オハイオ）– us-east-2 * SAP Commerce Cloud 向けの Intelligent Selling Services は、コマースプラットフォーム全体でお客様体験を高めるリアルタイムのパーソナライゼーションを提供します。 参照: ガイダンスについては、 SAP データセンターの所在地 および AWS グローバルインフラストラクチャ をご参照ください。 ベストプラクティス 2: レイテンシー最適化 優れたユーザー体験のための CDN の活用 重要な最適化手法の 1 つは、コンテンツ配信ネットワーク（CDN）を活用して買い物客の体験を向上させ、ストアフロントのパフォーマンスを加速することです。SAP Commerce Cloud のストアフロントは、画像、スクリプト、スタイルシート、商品メディアといった静的コンテンツに大きく依存しており、これらは CDN を通じて効率的にキャッシュおよび配信できます。 Amazon CloudFront は、静的コンテンツの配信とストアフロント API のパフォーマンスの両方を大幅に強化できます。SAP Commerce Cloud へのストアフロント API リクエストを適切にキャッシュすることで、CloudFront はバックエンドシステムの負荷を軽減しながら、エンドユーザーの応答時間を改善します。この二重の最適化、すなわち静的コンテンツ配信の高速化と API オーバーヘッドの削減により、地理的な場所を問わず、高速で一貫性のあるストアフロントのパフォーマンスが確保されます。 CloudFront は、SAP Commerce Cloud がどこにホストされていても、コンテンツ配信を加速するグローバルに分散したエッジネットワークを提供します。ユーザーに近いエッジロケーションでストアフロントのアセットをキャッシュすることで、企業はコアアプリケーションのアーキテクチャを変更することなく、ページの読み込み時間を短縮し、お客様体験を向上させます。 詳細は AWS ブログ : Supercharge your SAP Composable Storefront with Amazon CloudFront をご参照ください。 ミドルウェアがレジリエントなクラウド間の対話を実現する SAP BTP Integration Suite のような堅牢なミドルウェアレイヤーは、SAP Commerce Cloud と SAP Cloud ERP Private システムとの間の信頼性の高い統合に不可欠です。SAP Integration Suite、API ゲートウェイ、イベントブローカーといったプラットフォームは、アプリケーションを疎結合にするマネージドな通信チャネルを構築し、リクエストのキューイング、リトライ、変換、非同期処理を可能にします。 このアーキテクチャパターンにより、一時的なネットワーク遅延やレイテンシーの変動が、重要なビジネストランザクションを妨げることは決してありません。ミドルウェアはまた、キャッシュ、オーケストレーション、監視の機能を提供し、クラウド間のやり取りを円滑にし、システム全体のレジリエンスを向上させます。このようにミドルウェアを実装することは、ハイブリッドクラウド統合における十分に確立されたベストプラクティスであり、クラウドプロバイダーの整合性や地理的な近接性への依存を排除します。 非同期統合はレイテンシー感度を最小化する SAP Commerce Cloud と SAP S/4HANA との間のほとんどのやり取りは、設計上、非同期です。注文レプリケーション、顧客マスターの更新、カタログ同期、在庫フィードといったプロセスは、API、イベントストリーム、またはメッセージキューを通じて交換されます。これらのビジネストランザクションは、ミリ秒レベルの応答に依存せず、正確性やユーザー体験に影響を与えることなく、通常のインターネットレイテンシーを許容できるように設計されています。 同期統合のベストプラクティス SAP Commerce Cloud のリージョンに最も近い AWS リージョン（通常は同じ都市圏に位置します）を選択すると、SAP Commerce Cloud SaaS を AWS 上の S/4HANA Cloud ERP Private インスタンスと統合しても、意味のあるパフォーマンスへの影響はありません。リアルタイムの価格計算、ライブ在庫チェック、クレジットカード認証、与信限度チェック、または在庫可用性チェックといった、より少数の同期シナリオについても、AWS リージョンと SAP Commerce Cloud のホスティング場所との間の一般的なレイテンシーは、許容範囲内に十分収まります。数十ミリ秒程度の応答時間は、エンタープライズアプリケーションが最適なパフォーマンスのために必要とする閾値をはるかに下回ります。 ベストプラクティス 3: ネットワーキング AWS は、外部の SaaS プラットフォームとの統合をさらに強化する高度なグローバルネットワーキング機能を提供します。 AWS Global Accelerator 、 Regional NAT Gateway 、 Amazon Route 53 といったサービスや、高性能な AWS バックボーンルーティングインフラストラクチャは、エンドユーザー、SAP Cloud ERP Private ワークロード、SAP Commerce Cloud のエンドポイント間の接続性を最適化します。 AWS 内のトラフィックエンジニアリングは、ネットワークの障害を自動的に迂回してルーティングし、地理的に分散したデプロイ全体で一貫したパフォーマンスを維持します。企業は Amazon CloudWatch と VPC フローログ を使用して接続性を監視でき、統合トラフィックのパターンとネットワークの挙動を完全に可視化できます。これらのツールにより、AWS 上でホストされる SAP システムから SAP Commerce Cloud への、予測可能で安全かつレジリエントなアクセスが確保されます。 自動トラフィックエンジニアリング – AWS の自動トラフィックエンジニアリングは、ネットワークの障害を自動的に検出して迂回ルーティングすることで、SAP Commerce Cloud への接続性を強化します。AWS は、インターネットトラフィックのパフォーマンスを向上させるために、いくつかの舞台裏の最適化を実施します。 詳細は How AWS improves global connectivity via automated traffic engineering をご参照ください。 ベストプラクティス 4: セキュリティ AWS 上に構築されるセキュリティとコンプライアンス SAP Commerce Cloud は SaaS として稼働しますが、AWS は SAP Cloud ERP Private ワークロードを保護するための可能な限り最も強固な基盤を提供します。AWS は 140 を超えるコンプライアンス認証と、包括的なネイティブセキュリティサービス群を提供します。Identity and Access Management、暗号化、ネットワークファイアウォール、ロギング、監視により、SAP 環境に対する多層防御（defense-in-depth）モデルが実現します。 AWS 上の SAP Cloud ERP Private システムと SAP Commerce Cloud との間のすべての通信は、HTTPS や TLS といった標準的で安全なインターネットプロトコルを介して行われます。OAuth、API トークン、相互 TLS といった認証メカニズムは、ホスティングプロバイダーを問わず一貫して機能します。企業はすでに、銀行、決済ゲートウェイ、その他の重要な SaaS サービスへの接続に、日常的にこれらと同じ手法を利用しています。 AWS の優先事項について詳しくは、 AWS Culture of Security をご参照ください。 ベストプラクティス 5: Amazon 全体のサービスとの統合 さらに、SAP Commerce Cloud を Amazon のフルフィルメントサービスで拡張できます SAP Commerce Cloud を運用している企業は、Amazon のフルフィルメントサービス、すなわち Buy with Prime および Amazon Multi-Channel Fulfillment（MCF） と統合することで、既存のストアフロントとビジネスプロセスを維持しながら、Amazon の物流ネットワークを活用し、e コマース業務を強化できます。 Buy with Prime との統合 Buy with Prime により、ブランドは、迅速で送料無料の配送、簡単な返品、24 時間 365 日のサポート、Amazon のレビューといった Prime のショッピング特典を、自社のウェブサイト上で直接提供できます。SAP Commerce Cloud と統合することで、事業者は信頼されるショッピング体験によってお客様を惹きつけ、維持できます。調査結果によると、買い物客の 95% が Buy with Prime を再び利用する可能性が非常に高く、事業者は買い物客あたりの収益が平均 16% 増加しています。 Amazon Multi-Channel Fulfillment（MCF） Amazon MCF は、事業者がすべての販売チャネルにわたるピッキング、梱包、出荷、配送に Amazon のフルフィルメントネットワークを活用できるようにする、サードパーティロジスティクス（3PL）ソリューションです。SAP Commerce Cloud の事業者は、Amazon のネットワーク内で単一の在庫プールを使用することで、在庫切れ率の低減、在庫回転率の改善、業務効率の向上を実現できます。事業者からは、Amazon 以外のチャネルに MCF を追加して以降、売上または収益が平均で約 19% 増加したと報告されています。 SAP S/4HANA との統合の加速 SAP S/4HANA 向けの Amazon MCF および Buy with Prime アクセラレーター は、SAP Business Technology Platform（SAP BTP）を SAP Integration Suite および Amazon の事前構築済み API とともに活用することで、統合作業を最大 75% 削減し、多くのお客様が 6 週間未満で本番稼働できるようにします。この統合により、SAP のお客様は、既存の SAP S/4HANA のビジネスプロセスを妨げることなく Amazon のフルフィルメントインフラストラクチャを活用でき、既存の SAP ワークフローや構成とシームレスに連携する一般的なやり取りをすぐに利用できます。 SAP および AWS サポートから支援を受ける方法 AWS と SAP は、RISE with SAP on AWS 向けの Migration Support Service を提供しています。これは、RISE 移行および SAP Commerce Cloud 統合の期間中、迅速なトラブルシューティング、統合の課題、本番稼働支援のために、AWS のテクニカルインフラストラクチャエンジニアへの直接的なアクセスを提供するものです。AWS-SAP のエキスパートが戦略的なアドバイザリーとインフラストラクチャの専門知識を提供し、SAP と連携して迅速な課題解決と最適なパフォーマンスを実現することで、ミッションクリティカルな RISE with SAP on AWS ワークロードのより速く、よりスムーズな移行を確実にします。 まとめ SAP Commerce Cloud を AWS 上の SAP Cloud ERP Private と統合することは、業界全体で広く採用されている、実証済みで信頼性の高いエンタープライズアーキテクチャパターンです。SaaS プラットフォームは、インターネットベースで地理的に分散したアクセスを前提に、一から設計されています。非同期統合、ミドルウェア主導の通信、最適な同期統合レイテンシーのための SAP Commerce Cloud ホスティング場所に最も近い戦略的な AWS リージョン選択、そして CDN による高速化により、あらゆるデプロイシナリオで優れたパフォーマンスが確保されます。 AWS は、ミッションクリティカルな SAP Cloud ERP Private ワークロードに対して、セキュリティ、レジリエンス、運用面の成熟度の最適な組み合わせを提供します。同時に、そのグローバルネットワーキング機能により、SaaS プラットフォームとの統合を容易かつ信頼性の高いものにします。 適切なアーキテクチャ設計とベストプラクティスの遵守により、企業は、コアとなる SAP ランドスケープの最適な基盤として AWS を活用しながら、SAP Commerce Cloud によって自社のコマースプラットフォームを自信を持ってモダナイゼーションできます。このハイブリッドモデルは、成功しているデジタルビジネスが今日どのように運営されているか、すなわち柔軟で、分散されており、クラウドプラットフォーム全体でシームレスに接続されている姿を反映しています。 <!-- '"` --> 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。