FUSO Shop ― SAP Commerce Cloud（JDK 21）と Spartacus への全面アップグレード

Eコマースサイトは、稼働している限り「動いているものには触れない」という判断が続きがちです。しかし、その土台となるソフトウェアには必ずサポート期限があります。FUSO Shop の場合、その期限はバックエンドとストアフロントの双方に、ほぼ同時に訪れていました。

サポート期限を過ぎるとどうなるか

FUSO Shop は、SAP Commerce Cloud（CCv2）上のバックエンドと、Angular ベースのヘッドレス・ストアフロントである SAP Commerce コンポーザブルストアフロント（Spartacus）で構成され、両者は OCC（Omni Commerce Connect）API を通じて通信します。今回は Java 実行基盤だけでなく、フレームワーク、検索、認証、キャッシュ、ストアフロントのライブラリ群まで、バックエンド9項目・ストアフロント9項目の計18項目を一つのプログラムとして刷新しました。

FUSO Shop は、顧客認証の CIAM、決済の DT Pay、受注を受け取る Siebel、そして顧客・部品・価格などのマスターデータをファイルで受け取るホットフォルダーとつながっています。アップグレードの成否は、Commerce Cloud 単体が起動するかではなく、これらの連携が本番で動くかどうかで決まります。

進め方は、計画からハイパーケアまでの8ステップで構成しました。最初に SAP のアップグレードガイドを精査し、影響を受けるカスタム機能を洗い出したうえで、専用のアップグレードブランチ上に Java 21 と新しい SAP Commerce パッケージを構築。カスタムコードは、SAP が提供する移行ツール（OpenRewrite レシピ）で機械的に変換し、変換しきれなかったクラスと単体テストを手作業で書き換えました。自動化で網羅性を確保し、人の目で精度を担保する——この組み合わせが、メジャーアップデートの工数とリスクを同時に抑える鍵です。

• 1. 計画：SAP のアップグレードガイドを精査し、影響を受けるカスタム機能を特定
• 2. 環境構築：アップグレード用ブランチを作成し、Java 21 と新しい SAP Commerce パッケージを導入
• 3. コード更新：SAP の自動移行ツールでカスタムコードを更新し、残りを手作業で修正
• 4. 設定・起動：セキュリティとサーバー設定を更新し、システムが正常に起動する状態まで調整
• 5. ストアフロント刷新：顧客向けサイトを最新の Spartacus・Angular へ移行
• 6. テスト：単体テスト、システムテスト、回帰テスト、業務部門によるテスト
• 7. 本番稼働：バックアップ取得、リリース承認を経て本番環境へデプロイ
• 8. ハイパーケア：稼働中のサイトを監視し、発生した事象に迅速に対応

フェーズは、計画・設計 → 開発 → テスト → 業務受入テスト（UAT）→ リリース・本番稼働 → ハイパーケアの6段階です。テストでは、開発者テスト、システム統合テスト、回帰テストを経て、MFTBC様による業務受入テストを実施し、サインオフを取得しました。本番リリースにあたっては、SAP Commerce Cloud（CCv2）上で標準のデータベースバックアップを取得してロールバックポイントを確保したうえで、リリース承認を経てデプロイしています。

フレームワークのメジャーアップデートでは、エラーが出ること自体は避けられません。問われるのは、現象ではなく原因を特定し、同じ種類の問題をまとめて解消できるかです。本プロジェクトで直面した主な課題は、プラットフォーム領域の3件と、業務フロー領域の3件でした。

• ① サイトのプログラムが新しい環境で動かない（Java 21・Spring 6 へのコード互換性）：カスタムの Java コードが新しい基盤でコンパイルできない状態となりました。原因は、javax.* から jakarta.* へのパッケージ移行、旧 Apache ライブラリ（Commons Lang／Collections、HttpClient 4、Ehcache 2）の削除、各サービスで使用していた @Required アノテーションの廃止です。OpenRewrite レシピで import を自動更新し、残るクラスと単体テストを手作業で書き換えました。
• ② ビルドもサーバー起動もできない（ビルドとサーバー起動のエラー）：ビルド（ant clean all）が失敗し、解消後も SAP Commerce（Hybris）サーバーが起動しない状態となりました。原因は、カスタムの型・Bean 定義が SAP 標準に新たに追加された属性と重複したこと（例：Product.size）、Spring Security 6 での XML 設定ルールの厳格化、利用していた Bean の廃止（Ehcache マネージャー、マルチパートリゾルバー）、SAP 標準の Bean 名との衝突です。重複定義の改名・削除、Spring Security の XML とスキーマの更新、廃止 Bean の置き換え、カスタム Bean への固有名の付与で解消しました。
• ③ お客様のログインと社内のシングルサインオンが止まる（OAuth・ログイン・シングルサインオン）：CIAM 経由の顧客ログインと、バックオフィスのシングルサインオン（SSO）が停止しました。原因は、カスタムのトークン発行処理が依存していた旧 Spring Security OAuth2 モジュールが SAP 側で削除されたことです。新しい認可サーバー（Spring Authorization Server）は署名付き JWT トークンを発行し、pbkdf2 のパスワードエンコーディングも非サポートとなりました。新しい認可サーバー向けに CIAM 用のグラント変換処理を構築し、SAML による SSO 設定を修正、パスワードを argon2 へ移行しました。

• ④ 受注がSiebelに届かない（Siebel への受注連携）：受注は SAP Commerce に保存されるものの、Siebel へ連携されない状態となりました。原因は、Siebel への送信処理を起動する SubmitOrderEvent を、イベントリスナーが無視していたことです。ヘッドレス（OCC）構成で B2C サイトのチャネルが登録されておらず、さらに旧来の受注ストラテジーの上書き設定が SAP B2B の Bean と競合していました。B2C サイトチャネルを登録し、受注プロセスを確実に起動するカスタム受注サービスを追加して、Siebel への連携を回復しました。
• ⑤ 保存済みカードで支払えない（DT Pay の保存済みカード決済）：チェックアウト時に、保存済みカードでの支払いが失敗しました。原因は、保存済みカードのトークンを署名付き JWT として保持していたところ、従来のライブラリ（JwtHelper）がプレーンテキストに署名していたのに対し、後継の Nimbus JOSE は JSON ペイロードを必須とするため、トークンの生成も読み取りもできなくなったことです。トークンを JSON オブジェクトで包む形式に変更し、デコーダーは新旧両方の形式を読めるようにしたことで、既存の保存済みカードもそのまま利用できます。
• ⑥ 部品・価格などのデータが取り込まれない（ホットフォルダーによるデータ取込）：顧客・部品・価格などのマスターデータのファイルは届くものの、取り込まれない状態となりました。原因は Spring Integration 6 の仕様変更です。ファイルルーターにデフォルト出力チャネルを設定すると channelKeyFallback がエラーを出さずに無効化されるため、ファイル名と取込チャネルの対応付けが外れ、すべてのファイルが「未割当」チャネルへ流れていました。channelKeyFallback を明示的に有効化し、ファイル名パターンを修正して取込を回復しました。

6つの課題の背後には、多数の個別修正があります。ビルド段階で約40件のエラー、サーバー起動段階で16件の問題を解消し、あわせてセキュリティ設定とデプロイ手順の修正を行いました。

• デフォルトのパスワードエンコーディングを argon2 に設定し、管理者ユーザーを argon2 エンコーダーで再インポート
• 受注ストラテジーの別名定義が SAP B2B の標準 Bean を上書きしないよう修正し、カスタム受注サービスを追加
• ホットフォルダー用に spring-integration-zip 2.0.0 ライブラリを追加
• メール関連の ImpEx を INSERT_UPDATE から UPDATE へ変更
• 初期化時のメールメディアの重複キーエラー（DuplicateKeyException）を、HAC で孤立したメディアを特定・削除して解消
• 廃止済みのコックピット拡張を使用していないことを確認

• 2026年8月9日に本番稼働。稼働後はハイパーケア体制でサイトを監視し、発生した事象に迅速に対応
• バックエンドを SAP Commerce Cloud 2211-jdk21.11（JDK 21・Spring 6.2・Solr 9.10）へ刷新し、SAP のセキュリティ修正・アップデートを継続して受けられる状態を確保
• ストアフロントを Spartacus 221121.11（Angular 21・Node.js 22）へ刷新
• ログインを SAP の新しいセキュリティ基盤（Spring Authorization Server）へ移行し、argon2 によりパスワード保護を強化
• 移行で直面した6つの課題をすべて解消。Siebel への受注連携、DT Pay 決済、マスターデータ取込の3つの業務フローが新基盤で稼働
• 新旧両形式のトークンに対応し、既存の保存済みカードを引き続き利用可能に
• ビルドエラー約40件、起動時の問題16件を解消

このアップグレードの価値は、新しい機能ではなく、「止められないサイトを、これからも更新し続けられる状態に戻したこと」にあります。原因を一つずつ特定しながら進めたことで、受注・決済・データ連携という業務の根幹を、新しい基盤へ引き継ぎました。なお、FUSO Shop の日常運用を支える AMS（アプリケーション運用保守）の取り組みは、FUSO E-Shop の事例でご紹介しています。

経営・DX推進の視点でのまとめ

本エンゲージメントを通じて、以下の専門領域における実装力を実証しました。

• SAP Commerce Cloud のフレームワークアップデート：JDK 17 → 21、Spring 5 → 6.2 を伴うメジャー更新を、計画からハイパーケアまで一気通貫で遂行
• ヘッドレス・ストアフロントの刷新：Spartacus／Angular を複数のメジャーバージョンを跨いで更新し、サーバーサイドレンダリング方式の移行（@angular/ssr）にも対応
• 認証基盤の移行：旧 OAuth2 モジュールから Spring Authorization Server への移行と、CIAM 連携・SAML SSO の再構成
• 業務連携の保全：Siebel 受注連携・決済・ホットフォルダー取込を、原因特定から修正・検証まで一貫して対応
• 後方互換性への配慮：保存済みカードのトークンを新旧両形式に対応させるなど、お客様の既存データを損なわない移行設計
• 自動化と手作業の組み合わせ：OpenRewrite などの公式移行ツールと手作業の改修を組み合わせ、移行を効率的に推進