Salesforce Commerce Cloudアップデート短報—— 越境EC基盤への実務インパクト

最新シグナル

誤解1：「Commerce Cloudが別製品に置き換わった」

ブランド名がAgentforce Commerceに寄せられても、店頭の実装軸は従来どおりです。SFRA（Storefront Reference Architecture）、カートリッジ、SCAPI、Composable Storefrontの組み合わせは、公式ガイドでも「基盤技術」として残っています。名前の変更を「全面リライトが必須」と読むのは誤りです。まずは自社がSFRAかComposable（またはハイブリッド）かを1行で固定し、リリースノートの対象範囲をその軸で絞ります。

AgentforceのShopper／Buyer／Merchantエージェントは2026年6月29日に一般提供開始、と複数の製品解説が整理しています。エージェントはEinsteinの推薦・検索の延長線上にあり、店頭アーキテクチャの廃止ではありません。越境ECでは、エージェントに渡すカタログ言語・通貨・在庫の単一ソースが整っているかが先です。エージェント試験の前に、マルチサイト設定の国別サイトIDを表にします。

誤解2：「2026年夏の更新＝大規模な新アーキテクチャ」

2026年8月前後のB2C Commerce／Agentforce Commerce B2Cリリース（例：26.8系）は、公式ブログでも運用効率寄りの機能が中心です。代表例は次です。（1）Catalog Unification：B2C Commerceを商品情報の正にしつつ、Salesforce Point of Saleへスケジュール同期。（2）Google Merchant Center向けカタログフィード連携：フィールドマッピングと日次同期でカスタム開発なしに商品を配信。（3）CommerceアプリのIntegration Health（接続状態）表示。（4）Log Center側のAnomaly Detection。（5）オンサイト検索ダッシュボードへのクリック率（CTR）指標。

いずれも「店頭の全面作り直し」ではなく、マーチャンダイズ・監視・検索分析の改善です。リリースノートが軽い月でも、自社がPOS連携やGoogle Shoppingを使うなら影響は実務に直結します。逆に、ヘッドレス刷新だけを見ているチームは、この月の更新をスキップしても構いませんが、「スキップ理由」を1行残します。

誤解3：「ComposableとSFRAはCookieの問題が無い」

Composable Storefrontの開発者向けリリースノート（2026年7月頃）では、ハイブリッド構成（PWA KitとSFRAをサブドメインで併用）向けに、共有の親Cookieドメイン設定が案内されています。設定が無いと、ブラウザがホスト単位でCookieを分離するため、ログイン状態やバスケットがサブドメインをまたいで失われる、という説明です。越境で`www`と`shop`を分ける設計は珍しくありません。

この更新は「新機能の宣伝」というより、既存ハイブリッド移行の落とし穴の是正に近いです。自社がサブドメイン分割をしているなら、親ドメインのCookie設定と、国別サイトでのログイン継続をステージングで再現します。再現手順と確認日を表に残します。

公式が示す2026年夏の要点（短表）

表は2026年7〜8月時点の公開情報の要約です。インスタンスのロールアウト窓（例：7月下旬〜8月下旬）はリージョンでずれるため、自社本番のバージョン番号とリリースノートの版を突合します。二次ブログの「全部入った」表現は使わず、自社環境で有効化済みかだけを正とします。

越境ECで読み方が変わる点

多言語・多通貨・多サイトを抱える日本企業では、カタログの「正」が国別に散らばりやすいです。Catalog UnificationとMerchant Center連携は、国別サイトごとにフィードと属性マッピングが正しいかを見る機会になります。Google側の必須属性（タイトル・価格・画像・在庫）が欠けると、配信停止や品質スコア低下につながります。フィードプレビューをオンにする前に、対象SKUのフィルタ条件を文書化します。

エージェント（Shopper等）を越境で試す場合は、対象国1つ・言語1つ・チャネル1つに限定します。同意・返品・価格表示のルールが国ごとに違うのに、全サイト共通のエージェントを有効化すると、スピードだけが上がります。Merchant Agentで商品説明やSEO文案を生成するときも、現地語の監修者を承認者列に入れます。国サイトごとに「エージェント試験の可否」列を表に追加すると、本番誤ONを防げます。

SFRAとComposableの選び直しは別プロジェクト

夏の運用更新と、店頭アーキテクチャの刷新は分けて計画します。SFRAのままCatalog Unificationだけ入れるチームもあれば、Composableへ段階移行しながら親Cookieを直すチームもあります。両方を同じスプリントに載せると、障害の切り分けが難しくなります。移行ロードマップがある会社は、今回のリリースノートを「移行ブロッカーか／運用改善か」でタグ付けします。

ハイブリッド期間が長いほど、サブドメイン設計とSEOの正規URLが複雑になります。親Cookieの設定後も、国別のログイン・カゴ復元をステージングで国×ブラウザの組み合わせで確認します。確認結果は「成功／失敗／未実施」の3値だけでも十分です。未実施の組み合わせを本番前にゼロに近づけるのが目的です。

よくある取り違え（運用）

「Agentforce」と聞くと、社内AIチャット全体の話と混ぜやすいです。Commerce文脈では店頭・注文・カタログに紐づくエージェントと、Salesforce全体のAgentforce層を分けて書きます。もう一つは、SFRAの保守停止を前提に急いでComposableへ全移行する判断です。公式は両方の店頭オプションを並記しており、移行はデータ・Cookie・SEOの計画が先です。三つ目は、リリース月の機能数の少なさ＝「何も起きていない」と読むこと。運用系の小さな更新ほど、現場の手作業時間に効きます。

今週の一手：Commerce更新1行表

今週の実務1点は、「サイトID（国）／店頭型（SFRA・Composable・ハイブリッド）／Catalog Unification要否／GMCフィード有無／親Cookie設定／本番バージョン／確認日」の1行表です。空欄がある国サイトでは、エージェントや新フィードを本番有効化しません。表が埋まった行だけ、ステージングで同期とログイン継続を確認します。

確認が終わったら、リリースノートのURLと自社バージョンを同じ行に貼ります。二次記事の要約だけで経営報告しないようにします。来月のリリースノートが出たら、表の「確認日」だけ先に更新し、差分がある列だけ深掘りします。差分が無ければ「変更なし」と書いて閉じます。越境の担当が国別に分かれている場合は、表を国×1行にし、日本本社が横断で版を揃えます。

デジタルマーケティングとEC基盤が別チームの会社では、Merchant Center連携の所有者を1名決めます。フィード障害は広告側に先に見え、店頭側に届くのが遅れることがあるためです。所有者が決まったら、週1の接続ヘルス確認をカレンダーに入れます。Integration Healthの表示が「degraded」なら、カスタム連携のログより先に公式接続ステータスを見ます。ステータスが正常でも商品属性が欠ける場合は、マッピング表の必須列を再点検します。再点検の結果は、翌週の定例で1分共有すれば足り、長いスライドは不要です。

エージェントを試験する行は、Creditsや契約上の利用枠があるかをBilling／契約担当に確認してから進めます。枠が不明なまま本番サイトでShopper Agentを有効化しない方が安全です。試験はステージングまたはトラフィックの少ない国サイトから始め、カゴ放棄率と問い合わせ件数を1週間だけ併記します。悪化が見えたら即オフにし、原因切り分けのログを残します。