News

お知らせ

今回は「Adobe Commerce / Magento Open Sourceのフロントエンドの課題をどうするか〜その3」の最後で予告した通り、「ヘッドレス構成での課題」について解説していきたいと思います。ヘッドレス構成の課題とは前回の記事の最後で、ヘッドレス構成の課題を以下の通りあげました。   APIアクセスが引き起こす負荷 決済連携 開発・維持コスト 今回はこれらの課題について解説していきたいと思います。APIアクセスが引き起こす負荷Adobe Commerce / Magento Open Sourceの場合、VarnishまたはFastlyをアプリケーションサーバーの前に設置することが多くなります。もちろんほかのCDNサービスなどを利用いただいても構わないのですが、ここではVarnishとFastlyに絞って解説をしていきます。（ビルトインのフルページキャッシュ機能も大枠ではVarnishやFastlyに準じます）キャッシュサーバーがキャッシュするリクエストは限定されているVarnishとFastlyが使用する設定ファイルはVCLと呼ばれる独特の言語で書かれています。この設定ファイルの中には、VarnishとFastlyが各HTTPメソッドに対してどのような振る舞いをするかが定義されています。例えばVarnish用の場合は、以下のように書かれています。     if (req.method != "GET" &&        req.method != "HEAD" &&        req.method != "PUT" &&        req.method != "POST" &&        req.method != "TRACE" &&        req.method != "OPTIONS" &&        req.method != "DELETE") {          /* Non-RFC2616 or CONNECT which is weird. */          return (pipe);    }         # We only deal with GET and HEAD by default    if (req.method != "GET" && req.method != "HEAD") {        return (pass);    } この定義内容では、該当しないHTTPメソッドのリクエストを受け付けた場合に、アプリケーションサーバーにリクエストをpipeまたはpassすることを意味しています。どちらもアプリケーションサーバーにリクエストを通す点は同じですが、 pipeはリクエストとレスポンスを素通しする passはvcl_backend_fetchからvcl_deliverを通るが結果をキャッシュしない という違いがあります。このあたりの状態遷移についてはVarnish Softwareの公式サイトの図がわかりやすいと思います。 いずれにしてもVCLの定義上はGETとHEAD以外のHTTPリクエストはキャッシュが利用できないため、すべてのリクエストがアプリケーションサーバーへなだれ込んできます。Adobeの公式ドキュメントでも以下のように触れられていますが、GETリクエストのみがキャッシュ可能です。 Only queries submitted with an HTTP GET operation can be cached. POST queries cannot be cached. 単純なクエリであればGraphQLの場合はGETでも利用できますが、各種条件や認証パラメータなどを含めていくとPOSTリクエストでなければ処理できなくなってきます。そうなるとVarnishやFastlyではGraphQLリクエストが全くキャッシュされなくなり、アプリケーションサーバーの負荷が高止まりすることになります。決済連携決済連携、特にクレジットカード決済においては以下の実装上の要件が求められています。 カード情報の非通過・非保持（トークン化含む） EMV 3Dセキュアの導入 既に多くの決済代行サービスではこれらの機能が提供されていますし、ECサイト側での実装も求められています。2024年3月14日に公開された、クレジット取引セキュリティ対策協議会のクレジットカード・セキュリティガイドライン5.0版では、以下のように述べています。 特に、2025 年 3 月末までに、原則、全ての EC 加盟店に EMV 3-D セキュアの導入を求めていくにあたっては、加盟店への周知と併せて消費者であるカード会員の理解・協力を得るための周知・啓発への取組が強く求められる。 クレジット取引セキュリティ対策協議会のクレジットカード・セキュリティガイドライン5.0版　59ページより トークン化の実装は誰が行うのかカード情報の「非通過・非保持」を実現するために導入された、トークン化。基本的に実装する場所としてはフロントエンド側、特に支払い方法選択やカード番号登録の箇所になると思います。 ヘッドレス構成でないAdobe Commerce / Magento Open Sourceの場合は、決済エクステンションのフロントエンド実装で対処します。ヘッドレス構成の場合は、一体誰が実装すればよいのでしょう？決済エクステンションが実装しようとしても、フロントエンド側の実装方法は多岐にわたるため、予測することは困難です。ヘッドレス構成を取りたい場合は、トークン化の処理をフロントエンド側で別実装する認識が必要だと思います。EMV 3Dセキュア時の画面遷移多くの日系の決済サービスの仕様では、3Dセキュア認証時に以下のような流れが起きます。 決済申し込みリクエストの送信 決済サービスまたはカード会社の用意する認証画面を表示 3Dセキュア認証処理の実行 ECサイト側への3Dセキュア認証結果伝達 与信・売上処理実施 ヘッドレス構成でない場合は、この一連の流れはAdobe Commerce / Magento Open Source側で調整できます。ヘッドレス構成の場合、どちらのアプリケーションがなんの処理を担当するかを整理・調整しておく必要があります。それによって決済連携そのものの実装方法も変わってくる可能性があり、既製のエクステンションが利用できないケースも起こり得ます。開発・維持コスト最後はコストです。ヘッドレス構成で運用する場合、単純にコストが増えます。 Adobe Commerce / Magento Open Sourceの構築・維持費 フロントエンドアプリケーションの構築・維持費 がそれぞれ必要になるからです。これはフロントエンドアプリケーションをスマートフォン・タブレット向けのアプリに置き換えても同じです。 Adobe Commerce / Magento Open Sourceのためだけに新たにフロントエンドを別立てする、といった構成は単純にコストが増えるだけなのでおすすめできません。それならばいっそのこと、ハイパフォーマンスなテーマを利用して構築するほうがよほどコストパフォーマンスが良いと思います。 特にAdobe Commerceの場合はAEMやその他CMSとの連携という話題が多いように感じます。Magento Open Sourceと異なりライセンス費用がかかるため、 何のためにAdobe Commerceに対してAPI連携したいのか 本当にヘッドレス構成にする必要があるのか という点は十分検討したほうが良いと思います。まとめ今回はAdobe Commerce / Magento Open Sourceをヘッドレス運用する際の課題について解説しました。 APIアクセスが引き起こす負荷 決済連携 開発・維持コスト といった課題を取り上げています。なお、 課題がある　＝　ヘッドレス運用できない というわけではなく、構築時にこれらの議題についてきちんと議論・検討することが重要です。よくないケースとしては、検討が不十分なままプロジェクトが進行してしまうことだと思います。次回予告次回は「Core Web Vitalsのスコアをあげたい」という要望に対してのアプローチについて解説します。

リリーススケジュール通り、Adobe CommerceとMagento Open Sourceに対するセキュリティアップデートが公開されました。今回のセキュリティアップデートについては、Adobe Security Bulletinで概要が開示されています。 今回はこのセキュリティアップデートについて詳しく解説したいと思います。対象となるバージョン2024年4月現在、Adobe Commerce / Magento Open Sourceのサポート対象となっているバージョン系統としては、 2.4.7 2.4.6 2.4.5 2.4.4 があります。Adobe Commerce向けには延長サポートして、2.4.3以前のバージョンに対するアップデートも提供されていますが、これはあくまでも希望者向けの限定的なものとなります。本来のセキュリティアップデート対象としては、 2.4.7-beta3以前の2.4.7系 2.4.6-p4以前の2.4.6系 2.4.5-p6以前の2.4.5系 2.4.4-p7以前の2.4.4系 ということになります。アップデートの内容Adobe Security Bulletinによると、今回のアップデートでは2件の脆弱性が修正されているようです。このうち Criticalが2件 となっています。2024年は比較的短い間隔でセキュリティアップデートが実施されるため、今回の件数は少なめです。ただし、件数は少ないかわりに重要度は変わらず高いため、早めのアップデートが推奨されます。脆弱性の概要今回のアップデートで各バージョンとも修正された脆弱性は、 Improper Input Validation Cross-site Scripting (Stored XSS) の2点です。入力値チェックの不備と、データベースに保存されたデータを起点として発生するクロスサイト・スクリプティングです。どちらも放置して良いものではないので、対処が必要ですね。対象となるファイルMagento Open Source 2.4.6-p4から2.4.6-p5へアップデートした際に発生した差分を確認したところ、以下のファイルが影響を受けています。 vendor/magento/framework/Data/Form/Element/Image.php vendor/magento/framework/Mail/EmailMessage.php vendor/magento/module-admin-adobe-ims/Console/Command/AdminAdobeImsDisableCommand.php vendor/magento/module-admin-adobe-ims/Console/Command/AdminAdobeImsEnableCommand.php vendor/magento/module-admin-adobe-ims/Console/Command/AdminAdobeImsInfoCommand.php vendor/magento/module-admin-adobe-ims/Console/Command/AdminAdobeImsStatusCommand.php vendor/magento/module-catalog/Model/Config/Backend/File.php vendor/magento/module-customer/Model/ResourceModel/CustomerRepository.php module-admin-adobe-imsについては、コンソールに表示されるメッセージの処理が変わった程度のようです。あまり気にしなくてもよいでしょう。 その他については、値チェック処理やエスケープ処理が修正・追加されています。ファイル数としては多くないようなので、目視差分チェックも十分可能でしょう。アップデート全体に対するまとめ今回のアップデートは、前回から2ヶ月程度の間隔でリリースされたものですが、内容としては小規模な修正にとどまっています。ただし、脆弱性の脅威度は高いものが2件となっていますので、早い段階での適用が望ましいと思われます。 なお、次のリリースは2024年6月11日（日本時間だと6月12日）の予定です。次回はセキュリティアップデートのみとなる予定です。

リリーススケジュール通り、Adobe CommerceとMagento Open Sourceの新バージョンである2.4.7がリリースされました。すでに2.4.7-beta3が先月リリースされていましたが、そこから1ヶ月での正式リリースという流れとなっています。2.4.7のハイライト今回のバージョンアップでは、以下のような改良が行われています。 Content Security Policyの変更 REST / GraphQLに対するレート制限 UPS連携のアップデート FedEX連携のアップデート USPS Ground Advantage配送の追加 Temand Shippingモジュールの完全削除（2.4.4で無効化済み） 動作環境の変更 その他不具合修正多数（長いので詳しくはリリースノートをご覧ください） Adobe Commerce限定の変更Adobe Commerceのリリースノートでは、さらに以下の機能改良が行われているとされています。 1注文に対して複数クーポンのサポート パフォーマンス改善 有効な100万件のクーポンコードがある環境でのパフォーマンス改善 インデックス管理の改良 多くのオプションを持つ複雑な商品が一覧にある場合のパフォーマンス改善 RESTインポートAPIでのJSONフォーマットサポート セールスルール機能のパフォーマンス改善 500以上のストアがある環境での設定値保存パフォーマンスの改善 巨大なサイズの設定キャッシュの生成パフォーマンス改善 GraphQLアプリケーションサーバー これらについては、また別記事で紹介したいと思います。動作環境の変更について2.4.7-beta3の時点で公表されていましたが、動作環境については以下の変更が行われています。 PHP8.3のサポート（PHP8.1サポートは継続） RabbitMQ 3.13のサポート（3.11/3.12も継続） Composer 2.7.xのサポート（2.2.xも継続） Varnish7.3のサポート（7.2や6.0LTSも継続） Elasticsearch8.11のサポート OpenSearch 2.12 / 1.3のサポート Redis 7.2のサポート extjsをjsTreeに入れ替え jquery/fileUploadの削除 PHP8.1サポートが継続になったので、2.4.4や2.4.5からのアップデートパスができました。まだすべてのエクステンションがPHP8.3対応できていない状況のようなので、今すぐ2.4.7を利用したい場合はPHP8.2で動かすのが良いでしょう。2.4.4 / 2.4.5で稼働させているサイトはアップデートを2.4.7-beta3のリリース時にもお伝えしましたが、Adobe Commerce / Magento Open Source 2.4.4 / 2.4.5で稼働させているサイトについては、そろそろアップデート作業に着手する必要があります。その理由としては、 PHP8.1のサポートが2024年11月25日で終了する という点につきます。LinuxディストリビューションによってはPHP8.1のサポートがこの日以降も継続する場合がありますが、PHP公式としては11月25日がサポート期限です。この日までにPHP8.2以降のバージョンが動作する構成にアップデートすることが望ましいと言えます。11月26日以降、全く使えなくなるわけではありませんが、いかなる脆弱性・不具合についても修正されなくなるため大変に危険です。 サイトのカスタマイズ度合いによってはアップデート作業に膨大な作業を要する可能性もあるため、早め早めの対応が求められます。

今回は「Adobe Commerce / Magento Open Sourceのフロントエンドの課題をどうするか〜その2」の最後で予告した通り、「ヘッドレス構成」について解説していきたいと思います。そもそも「ヘッドレス」とはなにか「ヘッドレス」を英文表記すると「Headless」になります。「IT用語辞典 e-words」によると、 ソフトウェアについてヘッドレスという場合は、通常は用意されている表示・操作画面が存在しないか切り離されており、別の方法で操作・使用できるようになっていることを指す。 例えば、Webブラウザを通常のウィンドウ表示で操作せず、OSのシェルなどからコマンド入力で起動・操作する方式などが該当する。操作をスクリプトなどで自動化しつつ、アクセス先のWebサイトには人間が操作しているかのように装うことができる。 となっています。 CMSやECプラットフォームなどの場合は、Web APIでブラウザ経由で提供されていた機能を代替すると考えてよいでしょう。特に昨今は REST API GraphQL Webhook gRPC などがよく使われる技術として定着しているように思います。Adobe Commerce / Magento Open Sourceをヘッドレス構成で使うにはさて、Adobe Commerce / Magento Open Sourceをヘッドレスで利用したい場合はどうすればよいでしょうか？Adobeの買収前は差がなかったのですが、最近ではかなり方法に差がでてきています。共通する方法Adobe Commerce / Magento Open Sourceに共通して利用できるものとしては、 REST API（同期・非同期 / バルク） SOAP GraphQL があります。コアの実装についてはバージョンアップの度に対応範囲・内容の拡充・改良が行われており、これは今後も継続されるものと予想します。SOAPを利用するシーンはかなり減っているように思われるため、この記事はREST APIとGraphQLについて紹介したいと思います。REST APIの使い方REST APIの使い方については、 REST APIの使い方〜準備編〜 から始まる一連の記事をお読みいただければ良いと思います。 2.3以降で利用できる非同期 / バルクAPIについては、AMQP（Asynchronous Message Queue Protocol）に対応したメッセージキューサーバーが必要です。こちらについても以下の記事で紹介しています。 REST APIの使い方〜RabbitMQ導入〜 REST APIの使い方〜非同期・バルク処理API実践〜 GraphQLの使い方GraphQLについては、 GraphQL APIで別サイトにデータを表示する方法 GraphQL APIのmutationを使ってデータ更新をする方法 で解説しています。また、Experience Leagueのチュートリアルも参考になります。Adobe Commerce限定で利用できる方法最近のAdobe Commerceでは、Magento Open Sourceに含まれていないAdobeが提供するSaaSサービスをライセンス費用の範囲で利用できるようになっています。例えば、 App BuilderとAPI Mesh Catalog Service Data Connection などがあります。これらのサービスの利用方法については別記事で取り上げたいと思いますが、いずれにしてもMagento Open Sourceにはない仕組みがAdobe Commerceには用意されています。このあたりはやはり有償版ならではの対応というところでしょうか。Magento Open Sourceの場合はすべて自力で対応する必要があります。ヘッドレス構成で使う場合の課題ここまではAdobe Commerce / Magento Open Sourceのヘッドレス対応状況を紹介してきました。では、ヘッドレス構成を取った場合に課題がゼロなのか？といえばそんな事はありません。例えば以下のような課題がよく議題としてはでてきます。 APIアクセスが引き起こす負荷 決済連携 開発・維持コスト これらについては次回解説していきたいと思います。まとめ今回はAdobe Commerce / Magento Open Sourceをヘッドレス構成で利用する場合に利用できるWeb APIについて解説しました。バージョン2.3以降はGraphQLも使えるようになり、アップデートごとに改良が加えられています。 次回はヘッドレス構成で起き得る課題について解説していきたいと思います。

今回は「Adobe Commerce / Magento Open Sourceのフロントエンドの課題をどうするか〜その1」に続いて、「WebP対応」について解説していきたいと思います。WebPについては「MagentoでWebPを使うには」で少し触れています。かなり時間が経過していますので、ブラウザの更新なども踏まえた内容で改めてお届けしたいと思います。2024年3月時点での主要ブラウザの対応状況まず最初に、2024年3月時点での各ブラウザのWebP対応状況を確認しておきましょう。この手の調査では caniuse.com が用いられることが多いと思いますが、下図のとおり最新のメジャーブラウザではWebP対応が完了しています。 ということで、WebPをメインの画像として利用すること自体にほぼ障壁はないといえるでしょう。（IE対応が必須！という事案でない限り・・・）Adobe Commerce / Magento Open SourceでWebP対応するには冒頭でも触れましたが、以前の記事「MagentoでWebPを使うには」でWebP対応の方法について紹介しています。WebP対応する場合は大きく分けて、 エクステンションを導入する CDNなどで対応する 最初から全部WebPで制作する といった方法があります。エクステンションを導入する「MagentoでWebPを使うには」で紹介したとおり、手っ取り早い対応としてオススメしたい方法としては「Yireo_Webp2」を導入する方法があります。もちろん、他の実装方法を採用しても構いません。このエクステンションの仕組みとしては、 レスポンスのHTMLに含まれるimgタグを抽出する imgタグの画像ファイルを特定する PNGとJPEG画像の場合にWebPに未変換の場合はWebP化する（GIFの場合は行わない） imgタグをpictureタグに置き換え、WebP非対応ブラウザでも問題なく表示されるようにする というものです。 imgタグだけを対象にしているので注意が必要です。たとえばCSSのbackground-imageなどには対応していません。CSSで使用する画像をWebP化したい場合は使えないという点を忘れないでください。導入に際しての要件このエクステンションは、依存するエクステンションである「Yireo_NextGenImages」を必要とします。また、「cwebp」がサーバー上で利用できることが不可欠です。「cwebp」が導入できない環境には不向きです。 また、WebP変換前の画像と変換後の画像を両方ともディスク上に配置する必要があるため、より多くのディスク容量が必要になります。ディスクの空き容量には十分注意しましょう。パフォーマンス面での注意このエクステンションは、「オンザフライ」でのWebP変換を実施します。要は「WebP化された画像がなければ最初にリクエストされた際に変換処理を行う」、ということです。画像変換を実行するためには、 余裕を持ったCPU性能 ディスク性能（特に書き込み） が必要になりますが、これは通常のリクエストを処理するぶんに加えて求められるものです。アクセス数が多いサイトの場合、導入直後に変換処理が多く実行されがちで、そのための負荷がどうしても高くなる傾向があります。特に画像ファイルのあるディレクトリをNFS等でマウントしているような環境では、ディスクのI/O性能が不足することがあります。画像ファイルの数が多い場合は、別環境であらかじめ変換しておくなどの措置を取っておくと良いかもしれません。 ちなみに、Yireo_WebP2のGithubページでも以下のように書かれているので、エクステンションの不具合ではなく予想される現象として捉えていただくとよいでしょう。 This extension does two things: It shows a WebP on the frontend of your shop. And it generates that WebP when it is missing. Obviously, generating an image takes up system resources. And if you have a large catalog, it is going to do more time. How much time? Do make sure to calculate this yourself: Take an image, resize it using the cwebp binary and measure the time - multiply it by how many images there are. This should give a fair estimation on how much time is needed. CDNなどで対応する昨今ではCDN事業者などが提供するサービスの中に「画像最適化サービス」というものがあることがあります。例えば、 CloudFlare Images（CloudFlare） ImageFlux（さくらインターネット） CloudFront Functions（Amazon Web Services） Image Optimization（Fastly） といったものがあります。これらを活用して画像を最適化する、というものですね。 変換後の画像がどこに保存されるか 保持期間はどの程度か（あるいは調整できるか） 料金体系 といった点に注意が必要ですが、変換処理を外部サービス側に委ねてしまえる点は助かります。 Fastly向けには公式のAdobe Commerce / Magento Open Source用エクステンションがあり、Fastlyと契約することでサービスの利用が可能です。他のサービスについては何らかの実装・調整が必要です。外部サービスで画像最適化をする場合は・・・以前の記事「Magento Open Source / Adobe Commerceの商品画像に関するアレコレ〜その3」でもこのあたりの内容は触れていますので、お読みいただければ幸いです。Adobe Commerce / Magento Open Source 2.4.5以降であればかなり連携しやすいのではないでしょうか。最初から全部WebPで制作するこれから構築するサイト、あるいはリニューアルするサイトについてはこの方法も検討の余地があります。 テーマで使用する画像 media配下の画像 テーマ用の画像は頻繁に変更しないものなので、画像の入れ替え時に都度調整しても良いでしょう。media配下については、残念ながら以下の理由で難しいかもしれません。MagentoフレームワークはWebP形式のアップロードに対応していないMagentoフレームワークのソースコードを「image/webp」「webp」といったキーワードで検索すると、殆どヒットしません。そもそもMagentoフレームワークとしては2.4.7-beta3でもWebPに正式対応しておらず、画像アップロード機能が許可する画像フォーマットは以下のものに制限されています。 JPEG GIF PNG BMP ICO TIFF SVG SVGZ つまり、「Adobe Commerce / Magento Open Sourceの画像アップロード機能ではWebPフォーマットの画像をアップロードすることはできない」ということになります。アップロードできない以上、テーマ用以外の画像でWebPだけを利用するということは難しく、JPEGやPNG形式で作成した画像を使い続けることになります（AVIFでも同様です）。まとめ今回はWebP配信について解説しました。2020年当時よりもブラウザ側の対応状況が改善したので、WebP対応自体は簡単になったと言えます。Adobe Commerce / Magento Open Source側も2.4.5で画像リサイズなどをNginxやCDN側に任せる機能が追加されています。 サイトの規模や予算枠などにもよりますが、 十分な予算がある場合・・・CDNなどでの最適化配信 追加予算がかけられない場合・・・Yireo_WebP2でのWebP変換 という考え方が2.4.7時点では無難な判断軸ではないかなと考えます。 次回は「ヘッドレス構成」について解説していきたいと思います。

あっという間に2024年の第1四半期が終わろうとしている状況で、4月には1年ぶりの新バージョンである「2.4.7」がリリースされる予定となっています。さて、このシリーズでは2015年11月のMagento 2.0（ここではあえて当時の名称のままにしておきます）の正式リリース以降、ずっと大きな変更がないまま過ぎているフロントエンドの課題について取り上げたいと思います。約10年間変化がないフロントエンドMagento2系、つまりは今のAdobe Commerce / Magento Open Sourceがリリースされたのは2015年の11月のことです。すでに9年が経過している状況ですが、技術面で大きな変更というのはいままで1回も行われていません。GraphQL対応や複数拠点在庫対応、Page Builderなどの機能追加・拡張はありましたが、フロントエンドは局所的な仕様変更やライブラリのバージョンアップがある程度にとどまっています。フロントエンド周りでよくいただくご相談抜本的な進歩がないMagento2系のフロントエンド仕様に対して、ブラウザやフロントエンド実装手法は日々進化し続けています。その中でよく頂く相談としては、 Core Web Vitalsのスコアをあげたい WebPに対応したい ヘッドレス構成で運用したい といったものがあげられます。これらの内容について、次回以降深堀りをしていきたいと思います。技術要素のおさらいさて、フロントエンドの深堀りをしていく前に、Magento2系のフロントエンドを構成する技術要素についておさらいしておきましょう。大きなものとしては次のようなものがあります。 HTML 5 / CSS 3 jQuery RequireJS knockoutJS UI Component LESS / Grunt よく知られているものと、そうでないものがあると思います。この構成は2015年から変わっていません。2024年現在であまり見かけないものとしては、 RequireJS knockoutJS UI Component あたりでしょうか。UI ComponentはMagentoフレームワーク独自の実装ですが、RequireJSとknockoutJSに強く依存しています。この2つのライブラリは2019年以降新しいバージョンがないまま経過しています。（RequireJSは2018年8月。knockoutJSは2019年11月が最終リリース） 進化の早いJavaScript界隈にあって、4年以上新バージョンのリリースがないのはかなりよろしくない状況であると言ってよいでしょう。抜本的な見直しを阻む要素では、フロントエンド関係の抜本的な見直しがされないのはなぜなのでしょうか。理由はいくつか考えられます。例えば下記のようなものです。 作り込みすぎたUI Component 過去バージョンとの互換性問題 PWAStudioの存在 AEM（Adobe Experience Manager）の存在 これらについて個別に解説していきましょう。作り込みすぎたUI ComponentUI Componentは、現在のMagento2系に含まれる形でリリースされました。2015年当時としては良かったのかもしれませんが、多岐にわたるコンポーネントが作り込まれた結果として「リプレースが難しい」という状況に陥っています。 一部のテーマやソリューションではUI Componentを利用せず、完全に置き換えているものもあるくらいです。前述の通り、依存しているknockoutJSやRequireJSが更新を停止している点も問題視されるところです。過去バージョンとの互換性問題比較的現在のAdobe Commerce / Magento Open Sourceは旧バージョンとの互換性を重視する傾向にあります。以下のような仕様変更が行われたことはありますが、比較的「廃止予定（Deprecated）」とマークされた機能については延命させているように感じます。 メールテンプレートのレガシーモード廃止（2.4.4で廃止） XML Update機能の廃止（2.3.4では意思） 商品検索をElasticsearch / OpenSearchのみに変更（2.4.0で変更） Github上の不具合修正の際も、「改修後の処理が他の機能やサードパーティ製エクステンションなどに影響しないように配慮せよ」と要求がつくことがあるくらいです。ただ、後方互換性を重視しすぎるがために大掛かりな変更に踏み切れていないようにも思えるため、ここは判断の難しいところではないだろうかと思いはします。PWAStudioの存在2.3系のリリースと前後する形で登場した「PWAStudio」。現在も開発が続けられている、公式プロジェクトの1つです。PWA（Progressive Web Application）が話題だった頃に、GraphQLのサポートと合わせてリリースされたAdobe Commerce / Magento Open SourceのヘッドレスECリファレンス実装の形といえます。 ただ、PWAStudioは導入するために下記のものが必要になるという点で、かなりのコスト増を利用者側に求めていました。 Adobe Commerce / Magento Open Source用とは別のフロントエンド用インフラ ReactJSなどの知識と経験 PWAStudio用のテーマ「Venia」への理解 多言語化などの課題が当初はあったほか、導入には色々とカスタマイズ・調整が必要ということもあって中々ハードルの高い代物であったように思います。なんにしてもPWAStudioが登場したことによって、標準テーマに対する改良がおざなりになった感があり、それが今でも続いているように思われます。AEM（Adobe Experience Manager）の存在そして極めつけはAEMという存在です。大規模なプロジェクトでは、AEMで構築したサイトに対してAdobe Commerceから商品情報などを提供する構成を取ることがあります。この場合、Adobe Commerce側はヘッドレス運用となるのでフロントエンドのUI機能さほど求められません。どちらかといえばREST APIやGraphQLの対応領域やパフォーマンスのほうが重視されます。 この構図は「PWAStudioがAEMに置き換わっただけ」、とも言えますが、既にAEMで構築済みのサイトを持っている事業者にとってはある種当然の判断かもしれません。 どちらにしてもAdobe Commerce / Magento Open Sourceとしての標準のフロントエンド実装はあまり重要視されていない状況に変わりはありません。これらの流れが次に挙げる「標準テーマの行方」という話題につながってくるわけです。標準テーマの行方実際問題として、これらの技術要素に立脚しているAdobe Commerce / Magento Open Sourceに付属する「Luma」テーマについては、将来的に廃止される噂がでています。以下は2022年2月に公開された、Mage-OS（Magento Open Sourceのフォークプロジェクト）公式サイトの記事の抜粋です。 There was a lot of talking（中略）Even though there is little publicly visible output coming from these efforts, we believe it has been extremely valuable just to get an alignment on what the community needs from Adobe, and what Adobe is willing to provide.（中略）- Luma will be deprecated, but not on short term（中略）It is much clearer now what Adobe’s strategy is regarding Open Source, and that is a big win. Mage-OS update January 2022 「今すぐに」でないけれど、将来的にはという会話がされています。温度感はあれど、どこかのタイミングで動きがあるのかもしれません。次回予告次回は冒頭に挙げた以下の3つのよくあるご相談から、WebPに関する話題を取り上げたいと思います。 Core Web Vitalsのスコアをあげたい WebPに対応したい ヘッドレス構成で運用したい

今回は、「ShopwareのCMS機能を知る〜その5」で予告した通り、カテゴリ管理機能を利用したナビゲーション管理の方法について紹介したいと思います。この方法を理解すると、フッターのナビゲーションを管理画面から調整できるようになります。カテゴリ管理機能の振り返りフッターのナビゲーション管理方法を紹介する前に、カテゴリ管理機能の振り返りをしておきましょう。下記の2つの記事で、カテゴリ管理機能については紹介しています。最初に目を通しておいていただくとよいでしょう。 Shopwareのカテゴリ管理画面を知る〜カテゴリ一覧 Shopwareのカテゴリ管理画面を知る〜カテゴリ設定 Shopwareではカテゴリ管理機能でカテゴリツリーの構成をみながら設定ができます。このようなUI自体は今となっては珍しくないものですが、実はこの機能にはまだ他の使い道があります。今回はこれらの記事で紹介しきれなかった部分について説明をしていきます。セールスチャネルの設定Shopwareの機能として、「セールスチャネル」という機能があります。管理画面の左ナビに項目が用意されていると思います。この機能は マルチサイト運用 ヘッドレス運用 といった用途で活用するものです。もちろん、1つのセールスチャネルだけを定義して運用しても構いません。セールスチャネルの使い方自体は、別の記事で詳しく取り上げるとして、今回は設定項目を眺めていくことにしましょう。気になる設定項目 この「セールスチャネル」の「General settings」の中に、次のような項目があります。 Entry point footer navigation Entry point footer service navigation なにやらナビゲーションの構成する起点になるような設定項目のようですね。Shopwareの標準テーマのフッター部分を見ると、次のようになっています。 よくある次のようなページへの動線がないことに気づかれると思います。 プライバシーポリシー Cookie同意 特定商取引法に基づく表示 お買い物ガイド 会社概要 別段これは不具合ではなく、Shopwareの仕組みとしては普通のことです。比較的簡単な操作でこれらのページへの動線を設置することができるようになっています。フッターにナビゲーションを表示させる方法では、フッターにナビゲーションを表示させる方法について紹介していきましょう。手順としては以下の流れで行います。 footer navigation用とfooter service navigation用のカテゴリツリーを作成する それぞれのカテゴリツリーにサブカテゴリを作成する セールスチャネルの設定で割り当てる ナビゲーションの項目ごとに設定を調整する footer navigation用とfooter service navigation用のカテゴリツリーを作成するまず最初にそれぞれのカテゴリツリーを作成しましょう。カテゴリツリーの作成方法については、「Shopwareのカテゴリ管理画面を知る〜カテゴリ一覧」で紹介しています。最上位階層のカテゴリで「New category before」か「New category after」を選んで作成してください。それぞれのカテゴリツリーにサブカテゴリを作成する次に、それぞれのカテゴリツリーにサブカテゴリを作成していきましょう。カテゴリツリーの作成と同じ手順で、先ほど作成したカテゴリツリーのところで「New subcategory」を選んで作成します。この時点ではカテゴリ名は適当でも構いません（必要に応じて後で直せます）。作成例は次のような内容です。 セールスチャネルの設定で割り当てるそして、作成したカテゴリツリーをセールスチャネルの設定で割当を行います。Entry point footer navigationの場合この設定の場合は、「サービスホットライン」の右側あたりに表示されます。 ページ上部のカテゴリナビゲーションとは異なった構成のナビゲーションを設けたい場合に使うとよいでしょう。Entry point footer service navigationの場合この設定の場合、表示位置としては画面の一番下にある薄いグレーのエリアの上に指定したカテゴリのサブカテゴリが表示されます。次のような表示になります。 こちらの設定のほうがプライバシーポリシーなどのページへの動線としては適していますね。Tips：Cookie同意設定を設置したい場合ShopwareでCookie同意設定を設置したい場合は、次の手順で対応できます。 Entry point footer service navigation用にカテゴリを作成する セールスチャネル設定で作成したカテゴリを割り当てる Cookie同意設定に使用したいカテゴリの設定を調整する 前2つは先ほど紹介した手順で問題ありません。3番目の手順を紹介したいと思います。Cookie同意設定に使用したいカテゴリの設定を調整するCookie同意設定に使用するカテゴリの設定画面を開きます。最初に「Category type」で「Link」を選びます。 連動する形で入力欄が変化し「Customisable link」というセクションになります。 次に「Link type」で「External」を選択し、「Link destination」で「/cookie/offcanvas」を選びます。「Open in new tab」はオフで構いません。設定を保存し、フロントエンドをリロードします。 フッターの「Cookie同意」をクリックすると、画面左側からCookie設定が現れます。 まとめ今回はShopwareのカテゴリ管理機能を利用して、フッターのナビゲーションを構成する方法をご紹介しました。また、Shopwareでは最近よく目にするCookie同意設定も簡単に設置が可能です。 次回はShopwareのCMS機能にある「Media」機能について紹介したいと思います。

今回は「ShopwareのCMS機能を知る〜その4」に続いて、「既定コンテンツ（Shop page）」の設定方法について説明したいと思います。これで一通りのレイアウト関係の機能紹介ができたことになると思います。既定コンテンツ（Shop page）のレイアウトとはこれまで以下のレイアウト設定があるページを紹介してきました 商品一覧画面 商品詳細画面 ランディングページ 既定コンテンツ向けのレイアウト設定は、これらの設定と全く異なる作りになっています。というのも レイアウトに対するコンテンツ内容の設定画面がない からです。 どういうことなのか順番に説明していきましょう。既定コンテンツのレイアウトを作成するには既定コンテンツのレイアウトを作成するには、レイアウト管理機能で「Shop page」を選択してレイアウトを作成します。レイアウトの作成については、「ShopwareのCMS機能を知る〜その2」を参照してください。既定コンテンツを設定するには既定コンテンツを設定するには、「Settings > Basic information」にアクセスします。画面をスクロールしていくと、「Shop pages」というセクションがでてきます。 標準では以下の9種類の設定項目が用意されています。それぞれ説明していきましょう。既定コンテンツの種類既定コンテンツには以下の9種類が用意されています。 Layout for GTC pages Layout for revocation notices Layout for payment and shipping information Layout for privacy pages Layout for an imprint Layout for 404 pages Shop page layout for maintenance pages Shop page layout for contact pages Shop page layout for newsletter pages 画面を見ていただくとわかりますが、他のレイアウト設定とは異なり、コンテンツ設定をする部分は一切ありません。単純に定義済みのレイアウトを択一で指定するだけとなっています。ここが既定コンテンツ（Shop page）の他のレイアウト設定と大きく異なる部分です。 それでは順番に各コンテンツについて説明していくことにしましょう。Layout for GTC pages「GTC」は略さずに表現すると「General Terms and Conditions」となります。要は「利用規約」ページということですね。ここで指定したレイアウトは、 会員登録画面（ログイン画面も兼ねます） 購入画面 などに表示されます。Layout for revocation notices「revocation notice」の「revocation」とは直訳すると「廃止、取り消し、撤回」という意味です。意味合い的には「返品交換に関する規約と問い合わせ」になるようです。 このページは、「Settings > Cart settings」にある「Enable refunds」を有効にしている場合にのみ、購入画面に表示されます。この機能は、ドイツ民法の以下の条文に関連する機能として用意されています。日本法でいうところの「訪問販売法」「特定商取引法」に近いようです。（正確な解釈については、ドイツ民法に詳しい法律専門家にお尋ねください）Layout for payment and shipping information支払い方法と配送方法についての説明を表示します。通常はフッターにリンクが用意されています。Layout for privacy pages会員登録画面などでプライバシーポリシーをポップアップで表示します。プライバシーポリシーはGDPR的には「どのページからでも1クリックで確認できる動線にあること」が求められるため、若干違和感を覚える作りになっています。おそらくランディングページで作成するものとは別枠での掲載を意図しているのではないかと思われます。Layout for an imprint法律情報のコンテンツを表示します。標準のテーマではメンテナンス中ページのフッターに動線が設けられています。Layout for 404 pagesそのままズバリ、「404 Not found」ページ用です。存在しないURLにアクセスした場合に表示されます。Shop page layout for maintenance pagesセールスチャネルをメンテナンス状態にしている期間中に表示するコンテンツを指定します。Shop page layout for contact pages問い合わせフォーム用のレイアウトを指定します。標準のテーマではフッターに動線があります。Shop page layout for newsletter pagesニュースレター購読フォーム用のレイアウトを指定します。設定したページの確認方法は？商品ページなどのレイアウト設定とは異なり、既定コンテンツの場合は設定した内容を確認するための決まった方法がありません。レイアウト毎に表示される場所や表示形式に差があることが原因です（ただし、これは不具合ではなくアプリケーションの仕様です）。 基本的にこれらのページは一度設定してしまえばそこまで頻繁に更新されるものではないものがほとんどなので、サイト構築時に確認手順を明文化して残しておけばそこまで大きな問題にならないのではないかと考えられます。次回予告今回はShopwareの「既定コンテンツ（Shop pages）」の設定方法について紹介しました。次回はShopwareのカテゴリ管理機能を使ったナビゲーションの構成方法について紹介します。

弊社製「 VeriTrans 4G連携エクステンション for Magento2 」をアップデートいたしました。今回のアップデートではDGフィナンシャルテクノロジー様より告知のあった、接続先ドメイン変更に対応しております。アップデートの概要今回のアップデートにつきましては、昨年よりDGフィナンシャルテクノロジー様から告知のあった、「接続先ドメイン名の変更」に対応するものです。 弊社製エクステンションは、MDKレス方式を採用しております。そのため、下記の変更を実施いたしました。 (1) MDK（MDKトークン）／3G-Direct方式 ／ 口座振替サービス ／ ApplePay・GooglePay 　変更前：api.veritrans.co.jp (210.239.44.163)　変更後：api3.veritrans.co.jp (210.239.44.141, standby 210.152.252.219) 　※MDKレス方式（接続APIを利用）の場合も対象となります。 変更後の接続先ドメインをご利用されたい場合は、新バージョンである4.0.0をご利用ください。なお旧接続先ドメインについては告知にあります通り、「2025年2月末日」までご使用いただけます。サポート期間中のお客様へ新バージョンはマイページよりダウンロードいただけます。お気づきの点がございましたら、お問合せフォームよりお知らせください。サポート期限が終了しているお客様へ新バージョンがマイページに表示されない場合は、サポート期間が終了しております。 お手数ではございますが、再購入をお願いいたします。なお、2023年10月にサポート期間の見直しを行っております。従来の 180日サポート（標準） 360日サポート（ロング） に代わり、 1年サポート（標準） 3年サポート（ロング） という構成になっております。従来の360日サポートと新しい1年サポートの場合のエクステンション費用は同一です。

リリーススケジュール通り、Adobe Commerce / Magento Open Source 2.4.7-beta3が公開されました。このバージョンは、来月リリースされる予定となっている正式版に対する最終ベータ版という位置づけです。2.4.7-beta2からの変更点昨年10月にリリースされた2.4.7-beta2からの変更点としては、やはりPHP8.3対応があげられます。この対応は以前から予告されていたものなので、予定通りの内容となっています。ただ、「Adobe Commerce / Magento Open Sourceを利用する事業者が2024年のうちに対処したほうがよいこと」で取り上げた対応PHPバージョンの構成と若干変化があります。 2.4.7-beta3を構成するパッケージのcomposer.jsonを確認すると、最新の情報としては下表のようになります。 バージョン番号 正式リリース日 サポート終了日 対応PHPバージョン 2.4.7 2024/04/09 2027/04/09 8.1 / 8.2 / 8.3 2.4.6 2023/03/14 2026/03/14 8.1 / 8.2 2.4.5 2022/08/09 2025/08/09 8.1 2.4.4 2022/04/12 2025/04/24 8.1 2.4.7でもPHP8.1がサポートされたことで、2.4.4と2.4.5からのアップデート経路が開かれました。これは朗報ですね。2.4.6からの変更点2.4.6あるいはそれ以前のバージョンからの変更点としては、「Commerce Service Connector」があげられます。これはAdobe Commerce / Magento Open Sourceの両方に追加されているもので、Experience Leagueでも説明ページが設けられています。 このサービスはAdobeが提供するSaaSサービスにAdobe Commerce / Magento Open Sourceのデータを連携することによって、様々な機能拡張ができるようにするものです。現在利用可能なものとしては、下表のものが用意されています。 サービス 対象 Product Recommendations Adobe Senseiを活用 Adobe Commerce Live Search Adobe Senseiを活用 Adobe Commerce Payment Services Adobe CommerceとMagento Open Source Channel Manager Adobe CommerceとMagento Open Source Site-Wide Analysis Tool Adobe Commerce Catalog Service Adobe Commerce Data Connection Adobe Commerce なお、Payment ServicesはUSのみ。Channel ManagerはWalmart Marketplaceとの連携なので日本国内向けではありません。Adobe CommerceとMagento Open Sourceの違いが拡大Adobe Commerce 2.4.7では、Magento Open Sourceには含まれていない新しい機能として以下のものが追加されています。 Adobe I/O Events Admin UI SDK Webhooks Commerce Service Connector経由で利用できるサービスについてもMagento Open Sourceでは一部しか利用できません。（日本国内向けという意味ではMagento Open Sourceで利用できる機能はゼロです） 2.4.7ではAdobe CommerceとMagento Open Sourceの方向性がかなり明確になってきたと言えるかもしれません。新しく追加された機能については後日改めて解説していきたいと思います。2.4.4 / 2.4.5からのアップデートはそろそろ準備が必要以前の記事でも触れましたが、2024年11月25日でPHP8.1がサポート期限切れになります。Linuxディストリビューション等によってはこれ以降もサポートが継続する場合がありますが、公式としては上記の期日がアナウンスされています。 Adobe Commerce / Magento Open Source 2.4.4および2.4.5からのアップデートとしては2.4.7が比較的無難ではないかと思われます。PHP8.1のサポート期限が切れる前に、余裕を持ったアップデートの実施をおすすめします。