日本時間の2026年5月13日、1年ぶりとなるAdobe CommerceとMagento Open Sourceの新バージョンが出ました。
以前であれば「ここが変わった」という内容をお届けしていたのですが、ここ最近は大きな変化がないので中々大きく取り上げにくい状況が続いています。

今回はリリースノートを踏まえながら、どのような点が変わったのかについて解説をしていきたいと思います。

リリースノートで触れられているハイライトは以下の9点です。

• PHPとComposer
• プラットフォームとインフラ構成
• フレームワーク
• セキュリティ
• REST API
• GraphQL API
• 管理画面UI
• Braintree
• 配送

重要度の順に解説していきましょう。

まずはPHP対応バージョンの更新です。

• PHP 8.5 と 8.4 を完全サポート。PHP 8.3 はアップグレード用途のみ許容（本番環境での利用は非推奨）。
• PHP 8.2 のサポートは終了。
• Composer 2.9 との互換性を確認済み。 

となっています。このあたりは予告されていたものなので、計画通りですね。
2.4.8系以前からのアップデート時にはどのPHPバージョンを使用してアップデートするかを検討するとよいでしょう。

続いてPHP以外のミドルウェアと依存関係です。

• Valkey 9.x のサポートを追加。Redis 7.2 のサポート終了。ライセンス変更を受けた代替として推奨。
• OpenSearch 3.x に完全対応。最新マイナーバージョンが推奨検索エンジン。OpenSearch 2.x との後方互換性も維持。
• MariaDB 11.8 / 12.x をサポート追加。
• RabbitMQ 4.2 の互換性を追加（短期的な移行パス）。長期的には Apache ActiveMQ Artemis への移行を推奨。
• PHPUnit 12 への対応完了。 

MySQL 8.0とMariaDB 10.6のサポートが廃止されている点に注意が必要ですね。
MySQL 8.4 LTS や MariaDB 11.4 LTS で稼働していない環境からのアップデートについては事前にデータベースサーバーの更新が必要です。

フレームワークについては色々と手が入っています。

• Symfony 7.4 LTS への全面対応。
• Laminas MVC をネイティブMVC実装に置き換え。PHP 8.5 以降の長期互換性を確保。
• Zend_Cache を Symfony Cache コンポーネントに置き換え。
• TinyMCE WYSIWYGエディタを HugeRTE（オープンソース）に移行。TinyMCE 5/6 のサポート終了・ライセンス問題への対応。
• サードパーティ製OAuthライブラリ（carlos-mg89/oauth）を PHP ネイティブ関数に置き換え。
• JWT フレームワークを最新メジャーバージョンに更新。
• マルチテーマ・マルチロケールストアで SRI ハッシュをエリア/テーマ/ロケール別ファイルに分割。ページロード時間の短縮とメモリ使用量の削減を実現。

Magentoフレームワークは長らくZend FrameworkやLaminas Frameworkを多用してきましたが、Laminas Framework自体のメンテナンス継続が問題になっています。
今回のバージョンアップではLaminas MVCを従来との互換性がある独自実装に置き換えたり、Zend_Cacheを置き換えたりしています。

また、TinyMCEがHugeRTEに置き換わっているため、WYSIWYGエディタ関係のカスタマイズをしている場合は注意が必要です。
その他、OAuthやJWTフレームワークの更新・置き換えが行われているのはセキュリティ対応です。
Content Security PolicyにおけるSub Resource Integrity（SRI）が改修されただけにとどまっています。
つまり、PHPやミドルウェアレベルでのパフォーマンス改善の影響は受けるかもしれませんが、2.4.9ではアプリケーションとしてのパフォーマンス改善はなさそうだ、と言ってよいでしょう。

セキュリティ面はCAPTCHAやreCAPTCHA、二要素認証が中心です。
Braintreeは日本国内のアカウントでは利用できないので、越境で現地アカウントを持っている事業者が対象です。

• CAPTCHA / reCAPTCHA が有効な場合、REST API および GraphQL 経由でのアカウント作成にも同じバリデーションを適用。
• 複数の2FAプロバイダーが有効な場合、管理者ユーザーはそのうち1つを設定するだけでログイン可能に（従来は全プロバイダーの設定が必須だった）。
• APSB25-08 セキュリティパッチ適用後に発生していた非同期/バルクリクエストのパフォーマンス低下を修正。
• Braintree の Cardinal（3-D セキュア）統合に対応した CSP（コンテンツセキュリティポリシー）を更新。

上記に含まれない修正として、APSB25-94の対応があります。こちらは2.4.9にだけ行われているもので、2.4.8以前のバージョンにはバックポートされていません。

REST APIは商品画像管理のエンドポイントが改修されています。

• 商品ギャラリーのストアビュー継承制御。（ACP2E-4358）
• ストアビューレベルで REST API 経由の商品更新を行う際の挙動が改善。
• media_gallery_entries をペイロードから省略 or NULL に設定 → グローバルスコープの変更をストアビューに引き継がないように修正。（従来は意図せず継承されていた）
• media_gallery_entries 内の個別フィールド（label、position、disabled、video_title など）を NULL に設定 → デフォルト/グローバルの値に継承を復元できるように修正。

GraphQLはAdobe Commerce Cloud ServiceやAdobe Commerce Optimizer等との連携もあるので、色々と改修されています。

• clearCart ミューテーションが Magento Open Source でも利用可能に（従来は Adobe Commerce のみ）。
• clearWishlist ミューテーションを新規追加。ウィッシュリストの全アイテムを一括削除可能。
• exchangeExternalCustomerToken ミューテーションを新規追加。インテグレーショントークンによるユーザー認証とカスタマートークンの取得が可能。
• OrderTotal に grand_total_excl_tax フィールドを追加。税抜き合計金額を直接取得可能。
• 在庫切れ商品でも過去の注文履歴に完全な商品情報を表示。
• reCAPTCHA バリデーションを updateCustomer、updateCustomerV2、contactUs、applyCouponsToCart の各ミューテーションに追加。
• B2B GraphQL API の customer_id フィールドを復元・正常化。

管理画面においては多少利便性が改善されています。
以下の3点が変更点です。

• カタログ価格ルールグリッドに アクションメニューを追加。複数ルールの一括有効化・無効化・削除が可能に（カート価格ルールと同等の機能）。
• コンテンツステージングのプレビューでモバイル表示シミュレーションをサポート。ステージング更新がモバイルでどう見えるか事前確認可能。
• ゲストログイン時のカートマージ挙動を設定可能に（Guest Priority / Customer Priority / Merge Quantities）。「Stores > Configuration > Sales > Checkout」より設定。

Braintreeは日本国内で利用される方は少ないと思うので、影響は大きくないと思いますが、Adobe Commerce に限定して改修が行われています。

• Google Pay / Apple Pay のエクスプレス支払い画面内でプロモーション・クーポンコードを直接適用可能。
• Apple Pay が Safari だけでなく Chrome・Firefox でも利用可能に（QRコードスキャンによる決済）。
• PayPal Express の配送コールバックをクライアントサイドからサーバーサイドに移行。動的な配送方法とリアルタイムコスト計算が可能。

配送方法についてはAPI連携が標準で搭載されているもののうち、USPSとDHLに改修が行われていますね。

• USPS 連携をレガシー Web Tools API から新しい RESTful API（OAuth 2.0、JSON形式）に移行。デュアルAPI設定対応。
• DHL 連携を MyDHL RESTful API に対応。レガシー XML API との後方互換性も維持。

そもそも、現在のAdobe Commerce / Magento Open Sourceのバージョン番号というのは、

2・・・アーキテクチャレベルのバージョン
4・・・メジャーバージョン
9・・・マイナーバージョン
p1・・・セキュリティリリース

という形で管理されています。そのため、同じメジャーバージョン内であれば「比較的」互換性は保たれています。
（部分的に後方互換性がない修正が入っていることはよくありますが）

よって、2.4.9が2.4.8より以前のバージョンに比べて「劇的に進化した」という印象はありません。
ただ、PHPやミドルウェアといった環境の変化であったり、セキュリティ面の強化といった必要な改修は行われています。

今回のバージョンアップで注意すべき点は、

• Laminas MVCを独自実装にリプレースした
• Zend_CacheをSymfony Cacheにリプレースした
• MySQL 8.0 / MariaDB10.6のサポートを廃止した

というフレームワークレベル・ミドルウェア対応の変更でしょう。
データベースの移行はデータ量によっては大変な作業になることがあるため、計画を念入りに立てて行うのが良いでしょう。

そしてなによりも2.4.8以前のバージョンに対してバックポートされていない、APSB25-94（通称 PolyShell）の修正です。
これは2.4.9にしか正式に実装されていません。
この点についてはAdobe側の対応が非常に不誠実であると言えます。本来であれば公式サポートを提供しているバージョンについては2.4.9のリリースと同時に対応コードを展開するべきなのですが、Magento Open SourceはともかくとしてAdobe Commerceの利用者にすら提供していないのはかなり問題があると言えます。

Adobe Commerce / Magento Open Source 2.4.9は、基本的にこれまでの2.4.7や2.4.8のリリースと同様に、

• ミドルウェアの更新に伴う対応
• 不具合の修正
• フレームワークの改修
• API周りの拡充
• 外部連携先の仕様変更に対する対応

が主な変更点です。
ただし、最も大きな違いは、APSB25-94（PolyShell）の公式対応は2.4.9にしか搭載されていないという点です。

それ以外については劇的な進化や目立った新機能は今のところはありません。
時代の変化に即した対応については、サードパーティ製のエクステンションや独自実装で補っていくのがAdobe Commerce / Magento OpenSourceにおける調整になると言えるでしょう。

リリーススケジュール通り、Adobe Commerce / Magento Open Sourceのセキュリティリリースが行われました。
今回のリリースは2026年では2回目のリリースで、今年からはリリース計画が変更されている関係で、次のリリースは7月に予定されています。
Magento Open Source向けの2.4.4系と2.4.5系のメンテナンスはすでに終了しています。
そのため、2.4.4−p18と2.4.5-p17はAdobe Commerce専用のリリースとなります。

では、早速詳細を確認していくことにしましょう。

2026年5月現在、Adobe Commerce / Magento Open Sourceのサポート対象となっているバージョン系統は、

• 2.4.8
• 2.4.7
• 2.4.6

となっています。Magento Open Sourceの2.4.4系と2.4.5系はサポートが終了していますので、今回のリリースはありません。
Adobe Commerceの2.4.4系と2.4.5系に対してのみリリースが行われています。
そのため、今回のアップデートの対象バージョンは以下の通りです。

• 2.4.8-p4以前の2.4.8系
• 2.4.7-p9以前の2.4.7系
• 2.4.6-p14以前の2.4.6系
• Adobe Commerce 2.4.5-p16以前の2.4.5系
• Adobe Commerce 2.4.4-p17以前の2.4.4系

また、Adobe Commerce B2Bにおいては、

• 1.5.2-p4以前
• 1.4.2-p9以前
• 1.3.5-p14以前
• 1.3.4-p16以前
• 1.3.3-p17以前

が明確に対象であると示されています。

Adobe Security Bulletinによると、今回のアップデートでは16件の脆弱性が修正されているようです。
件数は前回と同じですが、内容のレベルに差があります。
内訳としては、

• Criticalが10件
• Importantが5件
• Moderateが1件

となっています。
すべての脆弱性に対して、

• 管理者権限
• 攻撃に際して認証

の両方またはいずれかが必要となっているため、

• 管理者アカウントの適切な管理
• 二要素認証の導入
• 管理画面へのアクセス制限

がなされていれば、緊急（72時間以内）の対応は必要ありません。レベルとしては30日以内の適用が推奨されています。
ただし、Adobeが緊急でないと判断していても、後に深刻なセキュリティ被害が発生した例もありますので、早めの適用が望ましいと言えます。

今回のアップデートで、対象のバージョンに共通して修正された脆弱性としては、

• Remote Code Execution (RCE)
• Security Feature Bypass
• Arbitrary File Write
• Information Disclosure
• Denial of Service
• Cross-site Scripting (XSS)

の6種類となっています。

Application Denial-of-Service (DoS) と Security Feature Bypass、Arbitrary Code Execution の3種類で全体の約81%（13件）を占めています。
Critical の脆弱性はすべて認証または管理者権限が必要ですが、これは現時点での発表であるため、やはり早めの適用が重要視されます。

いずれの脆弱性も公表時点での悪用は確認されていません。

Adobe Security Bulletinでは、緊急度を次の3段階に分けて示しています。

• 緊急度1・・・最上位の緊急度。72時間以内に対処が必要。
• 緊急度2・・・中位の緊急度。30日以内の対処を推奨。
• 緊急度3・・・低位の緊急度。直ちに問題が起きることは考えにくいため、管理者の判断での適用が可能。

今回のリリースについては、

• Adobe Commerce B2B・・・緊急度2
• Adobe Commerce・・・緊急度2
• Magento Open Source・・・緊急度2

となっています。
緊急パッチが出ていないので、通常のアップデートを30日以内を目処に行えば問題はないとAdobeからの発表には記されています。

2.4.7と2.4.8系については、今回のアップデートで以下の互換性対応が追加されています。

• MariaDB 11.8サポートの追加
• OpenSearch3系サポートの追加
• Valkey 8.1 LTSサポートの追加
• RabbitMQ 4.2サポートの追加

とくにMariaDB 11.8サポートについては、MySQL 8.0のサポート期限が終了していることに関係しています。
早いうちにMySQL 8.0系を使用しているサイトについてはMariaDB に移行することが推奨されます。

2026年最初のAdobe Commerce / Magento Open Sourceのアップデートは、緊急パッチを伴わないものとなりました。
ただ、脆弱性の件数は多いため、油断は禁物です。
また、繰り返しになりますがAdobeが「問題ない」と発表していても実際は攻撃が成功してしまうケースが何度か起きていますので、アップデートは早めに行うことが強く推奨されます。

なお次回のアップデートは2026年7月の予定です。
前回のリリース後に、Adobe側のリリース方針が改定されたため、緊急パッチリリースが7月に行われる予定となっています。

リリーススケジュール通り、Adobe Commerce / Magento Open Sourceのセキュリティリリースが行われました。
今回のリリースは2026年では1回目のリリースで、今年からはリリース計画が変更されている関係で、次のリリースは11月に予定されています。
Magento Open Source向けの2.4.4系と2.4.5系のメンテナンスはすでに終了しています。
そのため、2.4.4−p17と2.4.5-p16はAdobe Commerce専用のリリースとなります。

では、早速詳細を確認していくことにしましょう。

2026年3月現在、Adobe Commerce / Magento Open Sourceのサポート対象となっているバージョン系統は、

• 2.4.8
• 2.4.7
• 2.4.6

となっています。Magento Open Sourceの2.4.4系と2.4.5系はサポートが終了していますので、今回のリリースはありません。
Adobe Commerceの2.4.4系と2.4.5系に対してのみリリースが行われています。
そのため、今回のアップデートの対象バージョンは以下の通りです。

• 2.4.8-p3以前の2.4.8系
• 2.4.7-p8以前の2.4.7系
• 2.4.6-p13以前の2.4.6系
• Adobe Commerce 2.4.5-p15以前の2.4.5系
• Adobe Commerce 2.4.4-p16以前の2.4.4系

また、Adobe Commerce B2Bにおいては、

• 1.5.2-p3以前
• 1.4.2-p8以前
• 1.3.5-p13以前
• 1.3.4-p15以前
• 1.3.3-p16以前

が明確に対象であると示されています。

Adobe Security Bulletinによると、今回のアップデートでは19件の脆弱性が修正されているようです。
件数は前回と同じですが、内容のレベルに差があります。
内訳としては、

• Criticalが6件
• Importantが10件
• Moderateが3件

となっています。
すべての脆弱性に対して、

• 管理者権限
• 攻撃に際して認証

の両方またはいずれかが必要となっているため、

• 管理者アカウントの適切な管理
• 二要素認証の導入
• 管理画面へのアクセス制限

がなされていれば、緊急（72時間以内）の対応は必要ありません。レベルとしては30日以内の適用が推奨されています。

今回のアップデートで、対象のバージョンに共通して修正された脆弱性としては、

• Incorrect Authorization 
• Stored XSS
• Improper Input Validation
• SSRF（Server Side Request Forgeries）
• Path Traversal
• Open Redirect

の6種類となっています。

Stored XSS と Incorrect Authorization の2種類で全体の約68%（13件）を占めています。
Critical の脆弱性はすべて認証が必要（Auth required: Yes）ですが、うち2件は管理者権限不要で悪用可能なため注意が必要です。

ただ、いずれの脆弱性も公表時点での悪用は確認されていません。

Adobe Security Bulletinでは、緊急度を次の3段階に分けて示しています。

• 緊急度1・・・最上位の緊急度。72時間以内に対処が必要。
• 緊急度2・・・中位の緊急度。30日以内の対処を推奨。
• 緊急度3・・・低位の緊急度。直ちに問題が起きることは考えにくいため、管理者の判断での適用が可能。

今回のリリースについては、

• Adobe Commerce B2B・・・緊急度2
• Adobe Commerce・・・緊急度2
• Magento Open Source・・・緊急度2

となっています。
緊急パッチが出ていないので、通常のアップデートを30日以内を目処に行えば問題はありません。

Adobe Commerce向けのリリースノートでは触れられていませんが、以下の変更が加えられています。

REST API / GraphQL経由で顧客メールアドレスを変更すると、通知メールが送信される機能が追加。

外部システムとAPI連携をされている運用形態の場合は注意が必要ですね。

2026年最初のAdobe Commerce / Magento Open Sourceのアップデートは、緊急パッチを伴わないものとなりました。
ただ、脆弱性の件数は多いため、油断は禁物です。

次回のアップデートは2026年11月の予定です。
しばらくアップデートリリースはありませんので、バージョンアップなどを進行するには良い時期と言えるでしょう。

以前、Mage-OSについてご紹介しました。
あれから2年近い時間が経過し、現在はMage-OSはバージョン番号が2.1になり、Magento Open Sourceとの差が段々と現れてきました。

今回はMage-OS 2.1とMagento Open Sourceを比較し、その違いについてご紹介したいと思います。

まずはMage-OS 2.1に搭載されている、「Adobe CommerceにもMagento Open Sourceにもない機能」について紹介していきましょう。
Mage-OS 2.0がリリースされた際のアナウンスで触れられているものとしては、以下のものがあります。

• AI自動翻訳
• 拡張在庫管理
• SEOチューニング機能
• Page Builder拡張
  • 埋め込みウィジェット
  • Page Builderテンプレートのインポート/エクスポート機能
• パフォーマンス最適化
  • Back/Forwardキャッシュサポート
  • Speculative preloading（投機的読み込み）
  • スムースなページ移動

基本機能は既にMagento Open Source側である程度安定したものが実装されているため、どちらかと言えばMage-OS側は足りない部分を補うような機能拡張が色々と追加されている印象です。

Mage-OSには標準構成には含まれないモジュールがいくつもあります。（多くは実験ステータスですが）
例えば以下のようなものです。

• llms.txt拡張
• 管理者操作ログ
• Hyvaテーマ向け拡張

Mage-OSの開発コミュニティは、Hyvaテーマ開発の関係者と同じメンバーが多いので、Hyvaテーマ向けの機能拡張が出てくるのはある意味自然な流れですね。
これらの拡張機能については、次のメジャーバージョンである、Mage-OS 3.0で標準搭載になるとアナウンスされています。
今後が楽しみですね。

以前紹介した手順と基本的に変わりません。

composer create-project --repository-url=https://repo.mage-os.org/ mage-os/project-community-edition インストール先ディレクトリ

でプロジェクトを作成し、Magento Open Sourceなどと同様にインストールコマンドを実行します。
Magento Open SourceやAdobe Commerceのインストールに慣れている方であれば、特に苦労することもないでしょう。

Mage-OS 2.0では管理画面テーマが変更されています。
1.0の時点でもMagento Open Sourceとは色調が変えられていましたが、2.0ではもう少し深く手が加えられています。

Magento Open Sourceに比べると

• 白ベースの配色
• アイコン類の変更

が行われています。
このテーマは「m137」というもので、以下の特徴があります。

• より良いコントラスト、タイポグラフィ、レイアウト
• より速いパフォーマンスを管理者や管理画面を使う人に提供
• 完全にオープンソース。軽量で標準状態のMage-OSやMagento Open Source2.4で利用可能
• Mage-OS 1.0 と 1.1に対して互換性
• Magento Open Source 2.4に対して互換性
• Adobe Commerce 2.4でも利用可能（ただし、Adobe Commerce固有機能との互換性については未検証）

というものです。

このテーマは単独でもインストールが可能で、

composer require mage-os/theme-adminhtml-m137

を実行することでインストールできます。
（テーマの有効化は別途必要ですが）

Mage-OS公式サイトのバージョン比較ページで触れられている通り、Mage-OSはMagento Open Sourceの特定のバージョンをベースに作られています。

RedHat Enterprise Linuxとクローンディストリビューションのような関係性だと思っていただくとわかりよいでしょう。

もうひとつのMagento Open SourceであるMage-OS。Magento Open Sourceが足踏みをしている間に、コミュニティは色々と機能改良を施しています。
ロードマップでは、すでにMage-OS 3.0が計画されています。実験的なモジュールとして紹介したもののいくつかは3.0で標準搭載される見込みです。
2026年はMage-OSにも注目していきたいですね。

欧州データ保護会議（以降EDPBと略します）から出た「Recommendations 2/2025 on the legal basis for requiring the creation of user accounts on e-commerce websites」（タイトルでは「ECサイトにおけるユーザーアカウント要求の法的根拠に関する勧告」と短めのタイトルで翻訳しました）について概要をお知らせしたいと思います。

EDPBは、ECサイトでの「購入のためのユーザーアカウント作成の強制」は正当化できる場面が非常に限定的であり、多くの場合、ゲスト購入（ユーザーアカウントなし）を可能とする設計が、GDPR第25条のデータ保護・バイ・デザインおよびデータ保護・バイ・デフォルトの考え方に高い整合性を有すると示しました。

最初にこの勧告を見た時には少なからず驚きました。欧州委員会でデジタル法制簡素化 規則案2025/0360（Digital Omnibus Regulation Proposal）が公表されたばかりで、各デジタル関連の法整備の合理化が進むのか〜と、期待感を感じて各案に目を通していたところでしたから（153ページもあるのでまだ読破できておりません、、）。

以下、概要をお伝えしていきます。

勧告（Recommendations）は法令そのものではなく、EDPBがGDPRの一貫した適用を促すために示す解釈指針（ソフトロー）です。一方で、内容はGDPR（特に第6条の適法根拠や第25条のデータ保護バイデザイン及びデータ保護バイデフォルト等）の解釈に直結するため、各監督当局の運用や将来の執行・判断に強い影響を与え得ます。

これまでGDPRのプライバシー関連の記載事項に関わった事がある方はきっと驚かれる事項があると考えています。理由としては、ユーザーアカウント作成の要求が、GDPR第5条１(c)の「データ最小化の原則」に照らし合わせた上で、個人データ取扱の適法根拠（GDPR第6条の契約履行の為や正当な利益など）となる可能性が低い（絶対にならない、とは書いてありません）と書かれているからです。

全くの私見ですが、ランサムウェア被害などによる相次ぐ個人データの流出があるのではないかと感じました。どんなにセキュリティを強化しても、100%守られるわけではないと考えると、GDPR第5条 1 (c) のデータ最小化の原則に沿って個人データを扱うことが、結果として最も費用対効果が高い対応になるのではないかと感じました。

実際に本勧告のExecutive summaryの中では次のように書かれています。

While controllers in the e-commerce sector may have a commercial interest to require users to set up an account, the EDPB notes that such account creation may also expose data subjects to additional risks to their rights and freedoms.

（仮訳）電子商取引分野の管理者は、ユーザーにアカウント作成を求めることで商業的な利益の可能性がある一方で、EDPBはアカウント作成によってデータ主体の権利と自由に対する追加リスクの可能性があると指摘しています。

追加リスクに関しては、勧告のGeneral remarksの中で、ユーザー自身が登録した個人データの他に管理者側で作成される様々なデータがあるだろうと書かれています。実際にユーザー自身が登録する場合でも、契約履行と関連のない性別や誕生日の入力があるかもしれません（多くの利用者は誕生日クーポンがあるかも？と期待してしまうかと）。また、一旦登録してしまうと、注文から配送・決済の期間を超えて個人データを保持し、結果としてリスクにさらされることがあるとも指摘されています。さらに、シングルサインオン（SSO）についても、追加的なリスクが生じ得ると記載されています。

GDPR第6条の適法根拠に該当するか、下記のいくつかのケースについて勧告の中から抜粋して説明していきたいと思います。

前もって事例に該当する適法根拠をざっと列挙します。少し乱暴な要約かもしれませんがご容赦ください。

• 第6条 1 (a) 同意
• 第6条 1 (b) 契約履行のため
• 第6条 1 (c) 法的義務遵守のため 
• 第6条 1 (d) 人命に関する利益保護のため
• 第6条 1 (e) 公的な権限行使・職務遂行のため
• 第6条 1 (f) 正当な利益の目的のため

商品の属性によっていろいろあると思いますが、消耗品でない限り1回限りの購入というケースも多々あるかと思います。そうしたケースでもユーザー登録を要求するケースが多々あると思います。この場合の適法根拠としては従来GDPR第6条 1 (b) の契約履行の為、という適法根拠が用いられていたケースがあるかもしれません。この点についてEDPBの勧告では、GDPR第6条 1 (b) に依拠すべきでないと書かれています。

ユーザーが契約したサービスにアクセスするために厳密に必要な場合に限り、GDPR第6条 1 (b) に基づく事が可能と書かれています。ユーザーアカウント作成が適法であると例示された数少ないケースですが、「厳密に」と書いた部分は「strictly necessary」と表現されていますので本当に必要か十分に注意してください。また、契約期間が過ぎた際には適法根拠がなくなるという点にも注意が必要です。

サブスクリプションと同様に、限定オファーへのアクセスについても条件付きでGDPR第6条 1 (b) に依拠することが可能となります。これはわかりやすい事例で紹介されています。小売業者がロイヤルカスタマー向けに限定販売などのイベント招待されるなどのケースとなります。一方で、ユーザー登録すると全員特典を受けられる場合は該当しませんので注意してください。

学割であったり、医師免許が必要な医療機器であった場合、身分証明書や資格確認が必要になる販売があります。これらのケースでは一見ユーザー登録が必要そうです。ただ、セキュアなオンライン入力フォームを提供すれば、必要ではなくなるため、こちらもGDPR第6条 1 (b) に依拠すべきでないとされています。

こちらもGDPR第6条 1 (b) を適法根拠にすることはできません。ただ、同意を取得すれば適法とはなりますが、同意取得前（例えば購入前＆ユーザー登録前）にパーソナライズできる適法根拠は無いため注意が必要です。

アフターサービスとユーザーの権利行使

アフターサービスとユーザーの権利行使についてもGDPR第6条 1 (b) に依拠すべきでないと書かれています。電話や電子メールなどにより代替できる事が理由と考えられます。また、事業者側はユーザー登録の有無に関わらず、消費者保護法や契約法に基づく遵守をしなければならないので、この点についても注意が必要です。

法的義務で一般企業に関係あるものとしては、税務・会計上のデータになります。これもユーザーアカウントを作る必要があるかと言えば、「必要ない」という事がこの勧告での答え（第6条 1 (c) に該当せず）になるかと思います。

原文では注文の追跡や、注文後の変更管理、顧客ロイヤルティの構築、先々の注文の円滑化などもGDPR第6条 1 (f) 正当な利益の目的のためが適法根拠になるかはおよそ依拠すべきでないということになりますが（こんないい加減な書き方で申し訳ありません、、）、ここでは不正防止について書いておきたいと思います。実際に私自身これまで運用をする中で当然の権利だと考えておりました。ただ、ユーザーアカウントの登録が必須か？というと、そうではないかもしれないと改めて考え直しました。

ここまでの説明でそれぞれ適法根拠となりうるかについて要約してきましたが、この勧告ではそれぞれ適法根拠とできる可能性もあり、その場合に必要性（“necessity”）のテストと“balancing”（翻訳しにくいのであえて原文で）テストが求められています。ただ、ここでの締めの言葉は、必要性のテストを満たす可能性は低く、GDPR第6条 1 (f) に依拠すべきでないということです。

ここでのまとめは次のようになります。

サブスクリプションや限定オファーなどでは適法根拠とする事が可能と考えられますが、「ゲストモードなどユーザーアカウントを作成せずに購入できる選択肢を提供すべき」という事が今回の結論となります。

なお本勧告の中心は“強制アカウント”であり、同意をベースにする場合は“任意”として設計する必要があります。

その上で、適法根拠を同意（第6条 1 (a) ）にして対応する方法も考えられますが、ここでも重要な注意点があります。

ユーザー登録しない利用者が不利益を被らないようにコアとなる購入プロセスから明確に分離されるべき（原文：Where such a service is based on the data subject’s consent, the offer should be clearly separated from the core purchase process so that customers who choose not to register are not disadvantaged.）という事です。

冒頭でも申し上げましたが、デジタル法制簡素化 規則案2025/0360（Digital Omnibus Regulation Proposal）は、現在パブリックコメント募集中の提案段階にあります。その上で、同規則案やEUの比例原則を踏まえて考えると、軽微な事項については簡素化が進む一方で、万一の際に重大なインシデントにつながり得るケースについては、むしろ厳格化が進むのではないかとも感じております。

※ 本記事記載にあたり、細心の注意を払っておりますが、法的な助言を行うものではございません。また、正確性・完全性を保証するものではなく、法令対応のご確認は、お客様ご自身で、弁護士・専門家にご確認いただく必要がございます。

10月17日、AdobeはExperience League上でAdobe Commerceの2026年のリリース計画を発表しました。
今回はこのリリース計画について解説していきたいと思います。

2025年までのAdobe Commerceは、以下のようなサイクルでリリースを行ってきました。

• 2ヶ月毎（2月,4月,6月,8月,10月）のセキュリティリリース
• 年1回の新バージョンリリース（4月）
• 不定期の緊急パッチリリース

定期リリースについては概ね12月以外の偶数月の第2週にリリースが計画されており、実際そのとおりリリースされてきました。
このサイクル自体はやや頻繁ではありましたが、一応計画されたものとして恒例化してきていました。

ただ、これまでのリリースサイクルには問題もありました。例えば以下のようなものです。

• リリースが頻繁すぎる（2ヶ月に1回では動作検証が間に合わない）
• セキュリティアップデートなのにそれ以外の仕様変更が含まれる

前者はテストの自動化などで対処できなくもないのですが、後者についてはかなり問題でした。
特にリリースノートに記載がない仕様変更がたびたび含まれた結果、動作検証や実装の調整に手間を取られる事が多くありました。

最初にExperience Leagueに掲載されているスケジュールの図を見てください。

この図にまとめられている、2026年のリリース計画としての変更点としては以下のとおりです。

• セキュリティパッチは毎月リリース
• パッチはQuality Patch Tool経由で適用が可能
• 年1回（5月）の定期バージョンアップ（新バージョンとパッチ適用済みバージョン）
• 10月のパッチ適用済みバージョンリリース（※ない可能性もあり）

最も大きな変更点としては、「2ヶ月ごとのパッチバージョンリリースがなくなった」ということです。
セキュリティパッチはすべてQuality Patch Tool経由となり、Adobe Commerce本体のアップデートは年1回しかでなくなりました。

新しいリリーススケジュールのメリットは以下のとおりです。

• パッチの適用が統一したツール（Quality Patch Tool）でできるようになる
• セキュリティ修正が今までよりも早くリリースされるようになり、ゼロデイのリスクが減る
• 修正の内容が個別のパッチ形式になるため、内容を確認しやすくなる
• 他のモジュールやパッケージのアップデートが不要

Adobe Commerceは非常に多くのコンポーネントから構成されているため、下手に更新をかけてしまうと収拾がつかなくなることがあります。
独立したパッチであれば影響範囲は限定的なので、目視で変更点を追うことも難しくはありません。

反対にデメリットは以下のとおりです。

• パッチの適用順を管理する必要がある
• 毎月Quality Patch Toolの更新が必要
• オンプレ環境の場合はパッチ適用方法の検討が必要

Magento1.x時代は今回と同じ方式のセキュリティパッチが提供されていたため、

• どのパッチが適用済みか
• どの順番で適用していくか

ということを管理する必要がありました。

パッチの適用状態は現在であればQuality Patch Toolを使えば管理できますが、適用順は自前で管理しなければなりません。そのため、適用するべきパッチを抜かしてしまうようなミスをどう防ぐかが重要になります。

毎月Quality Patch Toolの更新については、これは仕方ありません。パッチのリリース日にあわせてQuality Patch Toolを更新しましょう。

そして最後が課題です。Adobe Commerceクラウドの場合は .magento.env.yaml に定義するだけでパッチ適用ができますが、オンプレ環境（Adobe Commerce / Magento Open Source問わず）についてはどのようにパッチを適用するかが課題になります。
ここはソースの管理方法やデプロイ方法によって変わってくるため、それぞれのプロジェクトで考える必要があります。

いずれにしても、2026年からはAdobe Commerceのリリースはこれまでと大きく変わります。
早速1月からパッチがリリースされる予定なので、年始早々の対応が必要になってきますね。
それがどれくらいの粒度でリリースされるかによって、2026年のAdobe Commerce / Magento Open Sourceの管理の行方が見えてくると思います。

リリーススケジュール通り、Adobe Commerce / Magento Open Sourceのセキュリティリリースが行われました。
今回のリリースは2025年では5回目のリリースで、2025年中としては最終のリリースです。
Magento Open Source向けの2.4.4系と2.4.5系のメンテナンスはすでに終了しています。
そのため、2.4.4−p16と2.4.5-p15はAdobe Commerce専用のリリースとなります。

では、早速詳細を確認していくことにしましょう。

2025年10月現在、Adobe Commerce / Magento Open Sourceのサポート対象となっているバージョン系統は、

• 2.4.8
• 2.4.7
• 2.4.6

となっています。Magento Open Sourceの2.4.4系と2.4.5系はサポートが終了していますので、今回のリリースはありません。
Adobe Commerceの2.4.4系と2.4.5系に対してのみリリースが行われています。
そのため、今回のアップデートの対象バージョンは以下の通りです。

• 2.4.8-p2
• 2.4.7-p7以前の2.4.7系
• 2.4.6-p12以前の2.4.6系
• Adobe Commerce 2.4.5-p14以前の2.4.5系
• Adobe Commerce 2.4.4-p15以前の2.4.4系

また、Adobe Commerce B2Bにおいては、

• 1.5.2-p2以前
• 1.4.2-p7以前
• 1.3.5-p12以前
• 1.3.4-p14以前
• 1.3.3-p15以前

が明確に対象であると示されています。

Adobe Security Bulletinによると、今回のアップデートでは5件の脆弱性が修正されているようです。
件数は前回と同じですが、内容のレベルに差があります。
内訳としては、

• Criticalが2件
• Importantが3件

となっています。
このうちCVE-2025-54265について「攻撃に際して認証」が不要となっていますが、この脆弱性についての個別パッチはリリースされていません。
それ以外については、

• 管理者権限
• 攻撃に際して認証

の両方が必要となっているため、

• 管理者アカウントの適切な管理
• 二要素認証の導入
• 管理画面へのアクセス制限

がなされていれば、緊急（72時間以内）の対応は必要ありません。

今回のアップデートで、対象のバージョンに共通して修正された脆弱性としては、

• Security feature bypass 
• Privilege escalation
• Arbitrary code execution

の3種類となっています。

なお、今回のアップデートは2025年9月にリリースされた、APSB25-88の修正が含まれています。

Adobe Security Bulletinでは、緊急度を次の3段階に分けて示しています。

• 緊急度1・・・最上位の緊急度。72時間以内に対処が必要。
• 緊急度2・・・中位の緊急度。30日以内の対処を推奨。
• 緊急度3・・・低位の緊急度。直ちに問題が起きることは考えにくいため、管理者の判断での適用が可能。

今回のリリースについては、

• Adobe Commerce B2B・・・緊急度2
• Adobe Commerce・・・緊急度2
• Magento Open Source・・・緊急度2

となっています。
緊急パッチが出ていないので、通常のアップデートを30日以内を目処に行えば問題はありません。

Adobe Commerce向けのリリースノートでは触れられていませんが、管理画面でコンテンツ編集時に使用しているWYSIWYGエディタのTinyMCEがHugeRTEに変更されています。
標準のまま使用するぶんには特に大きな影響はありませんが、サードパーティ製のエクステンションで拡張や改変を加えている場合は影響があるかもしれません。

そういった場合はエクステンション側のアップデートを待って対応を行えば問題ないでしょう。

2025年最後のAdobe Commerce / Magento Open Sourceのアップデートは、緊急パッチを伴わない小規模なものとなりました。
変更点はさほど多くはありませんが、TinyMCEがHugeRTEに変更されている点は注意が必要です。

次回のアップデートは2026年2月の予定です。
しばらくアップデートリリースはありませんので、バージョンアップなどを進行するには良い時期と言えるでしょう。

日本時間の2025年9月9日現在、Adobe Commerce / Magento Open Sourceを対象とした、緊急セキュリティリリースが公開されています。
Adobe Security Bulletinによると、このリリースは「APSB25-88」として採番されており、緊急度は3段階中の2番目（最も高いもの）とされています。（緊急度の定義はこちら）
今回はこのセキュリティリリースの内容について解説していきたいと思います。

APSB25-88の対象になる環境は、現在サポートされているAdobe Commerce / Magento Open Sourceのほぼすべてのバージョンです。
対象になるAdobe Commerce / Magento Open Sourceのバージョンですが、以下のとおりです。

Adobe Commerce

• 2.4.9-alpha2以前

   

• 2.4.8-p2以前

   

• 2.4.7-p7以前

   

• 2.4.6-p12以前

   

• 2.4.5-p14以前

   

• 2.4.4-p15以前

Adobe Commerce B2B

• 1.5.3-alpha2以前
• 1.5.2-p2以前
• 1.4.2-p7以前
• 1.3.4-p14以前
• 1.3.3-p15以前

Magento Open Source

• 2.4.9-alpha2以前
• 2.4.8-p2以前
• 2.4.7-p7以前
• 2.4.6-p12以前
• 2.4.5-p14以前

Magento Open Sourceの2.4.4系が対象に含まれていませんが、これは公式サポートが終了していることが理由です。
ですが、今回の脆弱性が対象にしている箇所は共通部分であるため、Magento Open Source2.4.4系をまだ稼働させているサイトについても今回のセキュリティパッチの適用が必要です。

Adobe Security Bulletinによると、APSB25-88の脆弱性は

Security feature bypass

とされています。
対象箇所はWeb API部分であり、かつ攻撃の成立に際しては

• 管理者としての認証
• 管理者権限の奪取

がいずれも不要となっています。そのため、脆弱性未修正の環境においては攻撃が容易に成立する可能性がありえます。

この脆弱性への対処手順は以下のとおりです。

1. magento/out-of-process-custom-attributes を4.0.0に更新する
2. 公開されている緊急セキュリティパッチを適用する
3. 1と2を同時にデプロイする

なお、magento/out-of-process-custom-attributesというエクステンションですが、通常のインストールには含まれていないものです。
Adobe Commerce as a Cloud Serviceでは標準インストールされるものですが、それ以外の構成・環境では標準インストールされません。
また、Magento Open Sourceはサポート対象外のため、インストールはできません。

脆弱性が含まれるエクステンションがないからと言って、脅威レベルがゼロになるわけではありません。Adobe Commerce（オンプレ・クラウド共通）とMagento Open Sourceの両環境ともに今回のセキュリティパッチを適用しておくことを強くおすすめします。

4、5年前でしょうか、職場の複数のZ世代の若者に、「検索するときに使用するツールは？」と尋ねたことがあります。複数の方から「Instagram」と聞き、当時は大きな衝撃を受けました。そして今同じ質問をすれば「AI（生成AI）」と答える人が増えているのではないでしょうか？

これまで企業がデジタル空間で集客するための中心的な手段は検索エンジン最適化（SEO）でした。Googleの検索結果ページに上位表示されることが、WEBサイトへの流入とオンラインショップでの売上を左右してきたと言えるでしょう（中国では既にWEB検索ですら主流ではなくなっていますが）。

現在はChatGPTやGeminiといった生成AIが台頭し、ユーザーは検索結果をクリックするのではなく、最初からAIに尋ねてAIがまとめた答えを直接受け取るようになる機会が増えたのではないでしょうか。今回の記事では、これまでGDPRをテーマに書いてきたことを踏まえ、EUのAI Actの視点から書いてみたいと思います。

GDPRが世界的に影響力を持った背景には、最大でグローバル売上高の4％または2000万ユーロ（高い方）という巨額の制裁金がありました。

私自身、GDPR施行前に対応プロジェクトのリーダーを任命され、関係者に協力を依頼する際、この「2000万ユーロ」という数字は強力な説得材料になったことを覚えています。実際に大手テック企業が数億ユーロ規模の罰金を科され、世界中の企業が「無視できない」と認識するに至りました。

AI Actでも同様に、違反時の制裁金は最大でグローバル売上高の7％または3500万ユーロの高い方 と定められています（第99条）。これはGDPR以上のインパクトを持ち、AIを扱うすべての事業者に強い遵守圧力を与えることと感じています。

今年6月4日に公布・施行された日本のAI推進法（人工知能関連技術の研究開発及び活用の推進に関する法律）についても触れておきたいと思います。

この法律は努力義務を中心とするため一見「ソフトロー」（強制力や法的制裁がない）に見えますが、実際には国の責務や計画義務を法律で明示（第4条）し、国家戦略としての法的位置付けが明確化（第1条、第4条、第18条）し、さらに将来的な規制強化に向けた布石（附則第2条）を打った「基本法」となる中間的アプローチとなっています。

まだスタートラインに立ったばかりですが、日本の個人情報保護法がGDPRの十分性認定を受けて良い影響（個人の主観ですが）を受けたように、AI推進法も今後、AI Actの良い面（例えば、リスクベースド・アプローチ）も取り入れながら発展していくことが期待されます。直近では9月1日に「人工知能戦略本部」の設置も発表されました。

AI Actが重視するのは第13条と第50条の「透明性」（Transparency）と「説明責任」（Accountability）です。あれっ？どこかで聞いたような？気づいてくださった方ありがとうございます。以前、透明性についてブログ記事（GDPR 第6回　透明性に関するガイドライン）を書いているのですが、GDPRの原則との共通項です。

• 第13条：高リスクAIに関する透明性義務

• 第50条：AIとの対話や生成コンテンツにおける透明性義務（AIであることの通知やラベル表示）

• 第17条・第18条：提供者に対する品質管理システムや書面化の義務 → これは「説明責任」の根拠となる条文

AI Actは、GDPRが個人データ利用において確立した「透明性」と「説明責任」という原則を、AIアルゴリズムの利用に拡張したものだといえるかと思います。

すでにChatGPTや、最近「Googleに挑む検索AI」として注目されるPerplexityは、回答に出典リンクを添える方向へ進化しています。これはAI Actが義務づける透明性の先取りする動きといえます。

結果として、AIにおけるSEOとは「AIに拾われる信頼性の高い情報を提供すること」に他なりません。検索順位を意識するだけでは不十分で、情報の品質・責任ある運営主体・正確な出典が評価軸となるのです。前述の制裁金のようにEU法は厳しい側面だけでなく優れた面があるんですよね。

AI Actの特徴は、事業者への義務だけでなく（第4条）、市民のAIリテラシー向上にも触れている点（前文20）です。こうした教育を社会的に進めることで、AIとの健全な共生を目指しています。また、日本のAI推進法第8条においても国民の責務として協力が求められており、方向性は共通しています。

また、これはSNSのレコメンド依存が子どもや若者に与える悪影響に対処してきた 英国のChildren’s Code（以前、ブログにて紹介） と通じる考え方です。透明性のあるAIと市民のリテラシー強化は、ブラックボックス的な検索エンジンやSNSアルゴリズムの負の側面からの脱却につながる一筋の光明と感じていたのですが。。。

悲しいことにこの記事を書いている最中に、ChatGPTを利用していた米国の16歳の少年が自殺したとのニュースがありました。現時点では因果関係は立証されていませんが、もしAIの利用が少年の脆弱性に作用していたとすれば、AI Actではどのようなケースになるか調べてみました。

今回のケースでは、第5条Prohibited AI practices(1)(b)の禁止事項に抵触していると考えられます。

検索エンジン対策においては、アルゴリズムを攻略することが優先であった時期もありました。それだけでなく、WEBやECに関わる方は（私自身もそうなのですが）SEOを気にしないわけにはいかない宿命でもありました。しかしAI時代においては、「AIに信頼される情報を提供できるかどうか」 が鍵になると考えられるかと思います。

• GDPRがデータ利用の透明性を世界に浸透させたように

• AI Actはアルゴリズムの透明性と説明責任を義務化し、世界的規範となる可能性が高い

企業にとってAIにおけるSEOは、もはや単なるマーケティング施策ではなく、法規制対応と不可分の信頼性ブランディング戦略と考えています。AIをめぐる法規制では、推進したい国家や企業の政策もあるとは思うのですが、人権や命に関わる部分ではハードローによる厳しい規制が求められる面もあるのではとあらためて感じた次第です。

そしてそれは同時に、AIが人々の生活に安心と安全をもたらす新しい情報環境を切り開くものとなりうると感じ今後に期待しています。

補足：当初はSEOに関連した記事を中心にまとめる予定でしたが、米国でChatGPTを利用していた16歳の少年の自殺のニュースがあり執筆途中で内容を少し変更しました。

※ 本記事記載にあたり、細心の注意を払っておりますが、法的な助言を行うものではございません。また、正確性・完全性を保証するものではなく、法令対応のご確認は、お客様ご自身で、弁護士・専門家にご確認いただく必要がございます。

リリーススケジュール通り、Adobe Commerce / Magento Open Sourceのセキュリティリリースが行われました。
今回のリリースは2025年では4回目のリリースです。
Magento Open Source向けの2.4.4 系のメンテナンスはすでに終了しており、2.4.5系は今回が最終となります。
そのため、2.4.4−p15はAdobe Commerce専用のリリースとなります。

では、早速詳細を確認していくことにしましょう。

2025年8月現在、Adobe Commerce / Magento Open Sourceのサポート対象となっているバージョン系統は、

• 2.4.8
• 2.4.7
• 2.4.6

となっています。Magento Open Sourceの2.4.4系は前回、2.4.5系は今回が最終リリースとなり、2.4.4系は今回のリリースはありません。
Adobe Commerceの2.4.4系に対してのみ、延長サポートとして2.4.4−p15がリリースされています。
そのため、今回のアップデートの対象バージョンは以下の通りです。

• 2.4.8
• 2.4.7-p5以前の2.4.7系
• 2.4.6-p10以前の2.4.6系
• 2.4.5-p13以前の2.4.5系
• Adobe Commerce 2.4.4-p14以前の2.4.4系

また、Adobe Commerce B2Bにおいては、

• 1.5.2-p1以前
• 1.4.2-p6以前
• 1.3.5-p11以前
• 1.3.4-p13以前
• 1.3.3-p14以前

が明確に対象であると示されています。

Adobe Security Bulletinによると、今回のアップデートでは6件の脆弱性が修正されているようです。
件数は前回と同じですが、内容のレベルに差があります。
内訳としては、

• Criticalが4件
• Importantが2件

となっています。
このうちCVE-2025-47110について「攻撃に際して認証」が不要となっていますが、DoS攻撃に対する対策不十分なので緊急パッチとしてのリリースはありません。
それ以外については、

• 管理者権限
• 攻撃に際して認証

の両方が必要となっているため、

• 管理者アカウントの適切な管理
• 二要素認証の導入
• 管理画面へのアクセス制限

がなされていれば、緊急（72時間以内）の対応は必要ありません。

今回のアップデートで、対象のバージョンに共通して修正された脆弱性としては、

• Improper Input Validation 
• Cross-Site Request Forgery
• Incorrect Authorization
• Stored Cross-site Scripting
• Time-of-check Time-of-use (TOCTOU) Race Condition

の5種類となっています。

今回はTime-of-check Time-of-use Race Conditionが出ている点が珍しいと言えます。

Adobe Security Bulletinでは、緊急度を次の3段階に分けて示しています。

• 緊急度1・・・最上位の緊急度。72時間以内に対処が必要。
• 緊急度2・・・中位の緊急度。30日以内の対処を推奨。
• 緊急度3・・・低位の緊急度。直ちに問題が起きることは考えにくいため、管理者の判断での適用が可能。

今回のリリースについては、

• Adobe Commerce B2B・・・緊急度2
• Adobe Commerce・・・緊急度2
• Magento Open Source・・・緊急度2

となっています。
緊急パッチが出ていないので、通常のアップデートを30日以内を目処に行えば問題はありません。

Adobe Commerce向けのリリースノートでは、触れられていませんが、GraphQLにおけるaliasの数に制限が加えられています。
以前は制限がなかったのですが、今回のアップデートを適用すると、GraphQLでaliasが10個までにデフォルトで制限されるようになります。
aliasはフィールドを別名で取得する際に用いるものですが、この利用に制限がかかった形です。

GraphQLを利用していない場合には特に問題はありません。

2025年4回目のAdobe Commerce / Magento Open Sourceのアップデートは、緊急パッチを伴わないものの、それなりの件数となりました。
変更点はさほど多くはありませんが、GraphQLのaliasに関する変更点は、ヘッドレス運用されているケースでは要注意です。

次回のアップデートは10月です。2025年最後のアップデートとなりますが、物販系のECにおけるピークシーズンを迎えるため、注意が必要です。