リリーススケジュール通り、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におけるピークシーズンを迎えるため、注意が必要です。

久しぶりのGDPR関連ブログとなります。ePrivacy Regulation※が出てきたら書くぞ〜と思いつつ、一旦は合意したはず（2021年）なのにいつまで経っても音沙汰なく、と思っているうちに気付けば2025年2月11日、欧州委員会での2025年作業計画において撤回すると発表されておりました。

撤回の理由としては、合意が得られる見込みがなかった点と、技術面立法面から時代遅れとの理由となっておりました。

※GDPR を補完する法規制で、現行法令の ePrivacy Directive（クッキー法とも言います）はEU/EEA加盟各国で規制されるのに対して、ePrivacy Regulation は EU/EEA加盟国全てで適用される法規制です。

ePrivacy Regulationとは、どのような規則なのか概要に触れておきたいと思います。また、私が要約しようとすると半年くらいかかってしまうので、ChatGPTにePrivacy Regulationに関するEU公式の初期提案文書（2017年1月10日提出）の要約をお願いしましたw原文はコチラとなります。

• GDPRを補完し、電子通信の分野におけるプライバシー保護の水準を高める。
• 通信内容やメタデータ、デバイス情報の取り扱いに関する共通ルールをEU全体に適用。

• 通信データの傍受・盗聴・保存・スキャン等を原則禁止。
• 通信の送受信者間の秘密保持を最重要視。

• Cookie、デバイスフィンガープリンティング、ローカルストレージなど、端末に関する情報の取得は明示的同意が必要。
• 例外：通信サービスの提供に不可欠な場合等。

• 電話、SMS、Eメールなどによる無断マーケティング行為を禁止。
• 明確な事前同意（opt-in）が必要。

• 各加盟国が規制機関（通常はデータ保護当局）を通じて執行。
• 違反にはGDPRに準ずる制裁金（最大2%（補足 GDPRは4%）のグローバル年間売上）を科す可能性あり。

• デジタル技術の進展により、従来の通信事業者以外（OTT※）も大量の通信データを処理している。
• しかし、現行のePrivacy Directive（2002/58/EC）はこれに対応できていない。
• EU市民の信頼を維持するには、通信の秘匿性に関する明確な保護規範が必要であり、そのための包括的規則を提案する。

※OTTとは　Over The Topの略称（以降、OTTと省略）。インターネット回線を通じて提供されるサービス全般を指し、動画・音楽コンテンツ配信、SNS、メッセンジャーツールなどの様々なサービスが該当します。

今回撤回の要因の１つともなった技術面の課題は小さくないのではないかと考えられます。AIの進化だけでなく、WEBミーティングや電子メールを取り上げても暗号化に関してはまだまだ広く一般化しておらず発展途上です。また、安心・安全な暗号化通信の普及が遅れていることで、迷惑通信の防止が立ち遅れ、セキュリティ面での喫緊の課題となっているかと思います。

直近のニュースでも流れたNATO（北大西洋条約機構、外務省資料）の首脳会議で防衛費の目標としてGDPの5%が掲げられましたが、NATOの加盟国32カ国中23カ国はEUに加盟しており、EU内ではロシアによるウクライナ侵略は喫緊の課題となっています。

GDP比5%とは？なんとなくピンときていない方も多いと思われるので2024年の日本の場合で数字を列挙します。2024年度の実質GDPは559.9兆円、この1%とすると防衛予算は約5.6兆円となりますが（2025年度の防衛予算は約7.7兆円）、5%となると約28兆円もの巨額になります。2024年度の一般会計税収は75兆2320億円（2025年7月2日発表数値）、ここに先ほどの防衛予算約28兆円を当てはめると実に一般会計歳入の約37%が防衛予算となります。いかに巨額の予算であるかこの数値を見ていただくだけでEUの中での重要課題か伝わると思います。

安全保障に関わる話のついでに、それに関わる法的な建て付けもわかる範囲でお伝えしたいと思います。GDPR23条では、安全保障などに関わる部分は権利が制限される対象となっています。ただし、無条件ではなく立法化が必要なので、各国の法制度で整備されています。ePrivacy Regulationの要約の中には「通信データの傍受・盗聴・保存・スキャン等を原則禁止」という文言もありますが、安全保障となると矛盾する部分もあるのではと感じてしまいます。この辺り米国との個人データの越境フレームワークDPFとの整合性は？と感じるのですが、英国の場合（EUからは離脱してしまいましたが）、諜報機関といえば007から連想するMI6ですね。英国はUK GDPRとセットでData Protection Act 2018により規制されておりMI6もその規制対象です。そして英国のICO（UK GDPRと同じ監督機関）により安全保障に関する領域も監督されています。この差異が越境フレームワークにつながっているように考えています。

GDPRの施行が決まる前にはスノーデン事件があり、後押しする形となった理解ですが、今はどうでしょうか？少なくともGDPRもまだ消化不良の部分、例えばGoogle Analyticsなどを使用して適法化の上で計測するためには利用者の同意なしには困難で多くの課題があるのではないでしょうか？（私自身、GDPR対応時代にCookie同意を導入した結果、大半の方が同意せず（大雑把に半減したかと）計測できなくなりました）。また、優先課題を考えた場合、安全保障や経済など他の事案がプライオリティが上がった中で下地が整っていなかったとも考えられるかと思います。

ePrivacyに関する規制はGDPRの補完ともなるものですから重なっている部分もあり、異なる部分もあります。一例が、IPアドレスやCookieなどのオンライン識別子です。自社のみで運用するIPアドレスなどのログや、1stパーティCookie（ただし外部送信しているGoogle Analyticsなどは除く）は違反となるリスクは低い反面、3rdパーティCookieやGoogle Analyticsなど照合性の高いデータは個人を特定しうることで適法でない越境や同意取得は厳しく規制されてきました。これは「個人を特定しうる」ということでGDPRの範疇です。一方で、現行のePrivacy Directiveは個人を特定しないものであっても同意を必要とする厳しい規制となっております。ePrivacy DirectiveはEU全域に適用されるRegulationではなく加盟国各国による規制となるDirectiveである関係からEU内でも国によって規制の厳しさが異なり、とても厳しい運用をしている国もあります。ePrivacy Regulationの提案の一節では下記のような文面があります。ブラウザの進化と合わせて、同意取得もわかりやすく、透明性を保ちつつ簡素化して欲しいと願いつつ、そうしたePrivacy Regulationの登場を待ちたいと思います。

"Simpler rules on cookies: the cookie provision, which has resulted in an overload of consent requests for internet users, will be streamlined. The new rule will be more user-friendly as browser settings will provide an easy way to accept or refuse tracking cookies and other identifiers. The proposal also clarifies that no consent is needed for non-privacy intrusive cookies that improve internet experience, such as cookies to remember shopping-cart history or to count the number of website visitors."

（仮訳）クッキーに関するルールの簡素化：インターネットユーザーへの同意要求の過負荷を引き起こしていたクッキー規定が簡素化されます。新しいルールでは、ブラウザ設定でトラッキングクッキーやその他の識別子の承認または拒否を簡単に行えるようになるため、よりユーザーフレンドリーになります。また、この提案では、ショッピングカートの履歴を記憶したりウェブサイトの訪問者数をカウントしたりするクッキーなど、インターネットエクスペリエンスを向上させるプライバシーを侵害しないクッキーについては、同意が必要ないことが明確にされています。

ここでハッと気付いたのですが、日本の電気通信事業法とePrivacy Directiveには複数の共通点があります。

・OTTサービスも規制対象

・個人を特定しない情報も規制対象

・同意で対応する場合はオプトイン方式

なお、改正電気通信事業法の外部送信規律は、ePrivacy Directiveを参照したことは総務省サイトのFAQで明らかにされておりますが、内容を同じくしているものではありません。

ここまで説明させていただきましたように合意には至っていないこと、時期的に内容が伴うまでに至っていないことからePrivacy Regulationは先送りはされてはおりますが、B2Bの領域もePrivacy Regulationで法整備される予定でしたから（実際にGDPR対応当初、それにより対応作業は半分になり軽減された記憶です）無くなったわけではなく、求められている役割はあるので、まだ時間はかかると思いますが各国で合意された形での再登場を待ちたいと思います。そしてこれは規制が強化されることだけを望むものではなく、誰でもが安全・安心に利用できる仕組みとして期待するものとなります。

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

リリーススケジュール通り、Adobe Commerce / Magento Open Sourceのセキュリティリリースが行われました。
今回のリリースは2025年では3回目のリリースです。Magento Open Source向けの2.4.4系のリリースはすでに終了していますので、2.4.4−p13はAdobe Commerce専用のリリースとなります。

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

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

• 2.4.8
• 2.4.7
• 2.4.6
• 2.4.5

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

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

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

• 1.5.2以前
• 1.4.2-p5以前
• 1.3.5-p10以前
• 1.3.4-p12以前
• 1.3.3-p13以前

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

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

• Criticalが2件
• Importantが3件

となっています。
このうちCVE-2025-47110について「攻撃に際して認証」が不要となっています。こちらについては緊急パッチがリリースされています。
それ以外については、

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

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

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

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

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

• Arbitary code execution
• Security feature bypass
• Privilege escalation

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

Privilege escalationについては、B2B版が対象となっています。

今回のセキュリティリリースに含まれている「CVE-2025-47110」については、緊急セキュリティパッチがリリースされています。
パッチの内容を確認したところ、Magento_Emailモジュールにおけるデータ取扱の不備を修正するものであるようです。

修正内容自体は軽微なものなので早めに当てておくとよいでしょう。

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

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

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

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

となっています。
今回は緊急度1が含まれますが、前述の緊急セキュリティパッチを当てておけば一旦は問題ありません。
その後、通常のアップデートを30日以内を目処に行えば完璧です。

Adobe Commerce向けのリリースノートによると、今回のアップデートに伴い、Cookieのキー値上限数に関する後方互換性問題が修正されています。
また、バルクAPIにおけるパフォーマンス劣化も修正されているようです。

2025年3回目のAdobe Commerce / Magento Open Sourceのアップデートは、脆弱性の件数は少ないものの、緊急パッチを伴うものとなりました。
Magento Open Source 2.4.4系向けにはアップデートはありませんが、今回リリースされている緊急パッチは適用可能です。早めに適用しておきましょう。

次回のセキュリティリリースは8月です。夏休みの方も多い時期ですが、セキュリティリリースは注視するようにしましょう。