News

お知らせ

こんにちは！ベリテワークス株式会社マラソン部です！弊社では、福利厚生の一環として2023年から「部活」制度が設けられました！オフィス勤務のメンバーと、リモートワークのメンバーとの交流、社内コミュニケーションを円滑にとるきっかけとしての位置づけもある当制度！去年の第21回和歌山ジャズマラソンをきっかけにマラソン部ができました！今年は2名のランナーがエントリーしました！ランニングはストレス解消など、メンタルヘルスケアの面でも効果的です！

企業の人事・労務担当者向けの専門誌「労基旬報」9月号において、人事図書館の運営スタッフも務める弊社代表の下記記事が掲載されました。 「キャリア開発」の２つの問い 「あなたはどのようにキャリア開発をしていますか？」そして「人事としてどのようなキャリア開発支援をしていますか？」という問いに対して、個人視点からのキャリア開発、企業・組織視点のキャリア開発のいずれにおいても、社会の変化に適応することが求められます。この変化の大きい時代だからこそお勧めしたい1冊として『キャリア開発と統合的ライフ・プランニング』（サニー・S・ハンセン著）をご紹介しています。 弊社代表はキャリアサポート歴20年、アジア太平洋キャリア開発協会(APCDA)の会長も務めた経歴があります。キャリアについてご相談されたい方は、是非コチラへ！ ※「労基旬報」（1968年創刊）は企業や法人・団体の人事・労務担当者、社会保険労務士、労働組合、研究者、働き方に関心のある方に向けた専門誌となります。

Adobe Commerce / Magento Open Source 2.4.7-p2 / 2.4.6-p7 / 2.4.5-p9 / 2.4.4-p10 のリリースに伴い、一部機能に仕様変更が加えられました。この記事ではそれらの変更について解説していきたいと思います。各バージョンのリリースノートAdobe Commerce / Magento Open Sourceの各バージョンに対するリリースノートは、以下のページから確認できます。 2.4.7 2.4.6 2.4.5 2.4.4 文量としてはさほど多くなく（セキュリティアップデートなので当然ですが）、どのバージョンも同じ内容が記載されています。  アップデート内容の概要アップデート内容としては以下のものが記載されています。 ワンタイムパスワードの以下のレート制限 二要素認証に対するリトライ回数 二要素認証のロックアウト時間 暗号化キーのローテーションコマンドの追加 prototype.jsの更新 CVE-2024-39397に対する修正（緊急パッチ情報を参照） 最も重要度が高いのはCVE-2024-39397ですが、CosmicSting の対策で必要となる「暗号化キーのローテーションコマンドの追加」も重要なポイントです。 この記事では ワンタイムパスワードのレート制限 暗号化キーのローテーションコマンドの追加 に絞って解説していきたいと思います。ワンタイムパスワードのレート制限今回のアップデートでは、以下の設定値が追加されています。 二要素認証に対するリトライ回数 二要素認証のロックアウト時間 以前から用意されている、二要素認証の設定画面で設定できます。 それぞれ初期値は10回と300秒です。必要に応じて変更するとよいでしょう。要は二要素認証を10回失敗すると300秒締め出される、ということですね。暗号化キーのローテーションコマンドの追加magentoコマンドをパラメータ無しで実行すると、利用可能なすべてのコマンドが一覧で表示されます。今回のアップデートでは、このコマンドの中に新しく以下のコマンドが追加されました。 encryption:key:change コマンド名からなんとなく役割がイメージできそうですが、このコマンドは暗号化キーを更新するためのコマンドです。「CosmicSting対策の方法〜CVE2024-34102による被害を防ぐには」で紹介した通り、CosmicSting対策としては暗号化キーの更新が重要です。これまでは管理画面からしか更新作業ができませんでしたが、以下のバージョンからはCLIからでも暗号化キーの更新が可能となりました。 2.4.7-p2 2.4.6-p7 2.4.5-p9 2.4.4-p10 コマンドの使い方php bin/magento encryption:key:change --help で利用可能なパラメータなどの確認ができますが、このコマンドの主なパラメータは「-k（--key=キー値　でも可）」だけです。このパラメータ自体は任意なので、指定しない場合はシステム側で暗号化キーを自動生成します。意図的に指定するつもりがないのであれば、自動生成を選ぶとよいでしょう。注意点このコマンドは、env.phpファイル上の暗号化キーを新しいキーに更新します。ただし、実装を見る限りでは すでに暗号化されているデータの再暗号化は行わない 古いキーでハッシュ値を算出したディレクトリ名の更新は行わない ようなので、利用の際には注意しましょう。管理画面の暗号化キー更新機能とは少し動きが異なるので、同じだと思っていると思わぬトラブルを引き起こす可能性があります。まとめAdobe Commerce / Magento Open Source 2.4.7-p2 / 2.4.6-p7 / 2.4.5-p9 / 2.4.4-p10 では新しく以下の機能が追加されました。 二要素認証のリトライ回数制限 二要素認証のロックアウト時間 CLIからの暗号化キー更新機能 ただし、CLIからの暗号化キー更新機能については、「単にキーを更新するだけ」の機能のようなので、利用する際は管理画面にある機能との機能差に注意しましょう。

リリーススケジュール通り、Adobe Commerce / Magento Open Sourceのセキュリティリリースが行われました。今回のリリースは2024年では5回目、今年はあと1回リリースが予定されています。早速詳細を確認していくことにしましょう。対象となるバージョン2024年8月現在、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-p1以前の2.4.7系 2.4.6-p6以前の2.4.6系 2.4.5-p8以前の2.4.5系 2.4.4-p9以前の2.4.4系 ということになります。アップデートの内容Adobe Security Bulletinによると、今回のアップデートでは23件の脆弱性が修正されているようです。このうち Criticalが7件 Importantが1件 Moderateが15件 となっています。脆弱性の概要今回のアップデートで、対象のバージョンに共通して修正された脆弱性としては、 Arbitrary code execution Arbitrary file system read Privilege escalation Security feature bypass の4種類となっています。 これらの脆弱性については、Adobe Security Bulletinは Note: Authentication required to exploit: The vulnerability is (or is not) exploitable without credentials. Exploit requires admin privileges: The vulnerability is (or is not) only exploitable by an attacker with administrative privileges. としています。脆弱性ごとにレベル感が異なりますが、脆弱性の発現に際して 認証情報 管理者権限 のいずれかまたは両方が必要なものが大半を占めています。なお、CVE-2024-39397 のみがどちらも必要としていない点に注意が必要です。Apacheで稼働させているサイトは要注意今回のセキュリティアップデートでは、Apacheで使用する .htaccess ファイルの定義内容が変更されています。Nginxの場合は影響を受けませんが、Apacheの場合は pub/media下にある .htaccess ファイルの内容も合わせて確認が必要です。修正が漏れていた場合、脆弱性への対応が不完全なものとなってしまいます。緊急パッチ同時リリース今回のアップデートに付随する形で、緊急パッチがリリースされています。このパッチは CVE-2024-39397 を修正することが目的で、今回のセキュリティアップデート対象のすべてのバージョンに共通するパッチとなっています。セキュリティアップデートの適用に時間を要する環境であっても、最低限このパッチだけは適用されることを強くおすすめします。まとめ今回のセキュリティリリースは、修正された脆弱性の数がかなり多い印象です。通常であれば対象ファイルを精査しているのですが、今回は修正件数に比例し、対象のファイル数が多いため省略します。 なお、今回のアップデートで仕様変更を受けている機能が一部あるようなので、そちらについては別記事で解説したいと思います。

2024年6月11日（太平洋標準時）にAdobeがリリースしたAdobe Commerce / Magento Open Source向けのセキュリティアップデートでは、CVE2024-34102という脆弱性が修正されました。この脆弱性については、別記事で紹介している通り、セキュリティ企業SanSecが「CosmicSting」と命名してより詳細な情報提供を行っています。今回はこの脆弱性に対する対策方法について解説していきたいと思います。CosmicSting（CVE2024-34102）とはCosmicStingとは、CVE2024-34102として採番されているAdobe Commerce / Magento Open Sourceの脆弱性です。Adobe Security Bulletinでは、「Improper Restriction of XML External Entity Reference（不正な外部XMLエンティティ参照）」と記載があるもので、XMLファイル・データの取扱いに関する不具合が原因で発生するものです。この脆弱性を悪用することで、Adobe Commerce / Magento Open Sourceの持つ環境固有の設定ファイルである「env.php」の中身を盗み出すことができ、このファイルに含まれるあらゆる情報が漏洩してしまうことになります。env.phpが漏洩することによって起きる問題env.phpには様々な情報が含まれますが、特に重要なものとしては以下のものがあります。 データベース接続情報 暗号化キー 特に今回CosmicStingで問題視されているのは後者の「暗号化キー」のほうです。この情報が漏洩してしまうと、Adobe Commerce / Magento Open Sourceが用意している各種Web API（RESTやGraphQLなどすべて）のうち、管理者用のものを自由に利用できてしまいます。 すでにこの脆弱性を悪用されて、何らかの被害にあっているサイトが世界各地で報告されています。早急な対処・対応が必要な事案ではありますが、CosmicStingの対応はかなり面倒であることも同時に判明しています。対策方法CosmicStingに対しては、すでに対策手順が公開されています。当初はSanSecから暫定パッチがリリースされていましたが、現在はAdobe公式から緊急パッチがリリースされています。基本的には公式のパッチを利用するようにしましょう。Adobe公式パッチ2024年6月27日時点でAdobeが緊急パッチをリリースしています。このパッチは 2.4.4系 2.4.5系 2.4.6系 2.4.7系（実際は2.4.7のみ） に対して適用可能なものとなっています。適用対象のバージョンを間違えないように注意してパッチのアーカイブをダウンロードし、適用ガイドに沿って適用作業を行いましょう。 まずはこれで1段階目の作業は完了です。パッチ適用と合わせて行うと良いことパッチ適用に加えて、以下の対応を行うことでより安全性が高まります。 Content Security Policy（CSP）の有効化とホワイトリストの最新化 glibcに含まれるiconvライブラリとPHPの更新 合わせて実施されるとよいでしょう。CMSページやブロックを改ざんされ、不正なスクリプトを埋め込まれたとしても、CSPが有効であればブラウザ側が読み込みを止めてくれるはずです。適用後に実施する必要がある作業さて、パッチ適用だけで今回の問題は終わりません。以下の作業が残っています。 暗号化キーの更新 暗号化済みデータの再暗号化 リサイズ後画像ディレクトリの更新 それなりに手間のかかる作業なので、どのようにすればよいか解説していきましょう。暗号化キーの更新まず最初は暗号化キーの更新です。env.phpが丸ごと漏洩したと想定して対処を行う必要があります。この場合、暗号化キーを新しいものに置き換えないと、いつまで経ってもAPIの不正利用がなくなりません。暗号化キーの更新機能自体は、Adobe Commerce / Magento Open Sourceの管理画面に標準で用意されています。   システム＞暗号化キー管理   にアクセスし、自動生成の選択か手動生成したキーの入力を行い、変更ボタンをクリックします。適切に実装されているAdobe Commerce / Magento Open Sourceであれば、本来これだけで作業は終了です。 ただ・・・おそらく殆どの環境でこれだけでは済まないのが現状であるようです。暗号化済みデータの再暗号化暗号化キーの更新後には、暗号化キーを使用して暗号化されたパスワードや認証情報の更新が必要になります。（暗号化に使用したキーが変わったのですから当然ですね） この処理自体は、先程の「暗号化キーの更新」のあとに自動的に実施してくれます。ただし対象が以下のデータに限定されています。 core_config_dataテーブルに記録されている情報で、backend_modelが\Magento\Config\Model\Config\Backend\Encryptedであるもの sales_order_paymentテーブルのcc_number_enc列 それ以外のデータについては、自力で再暗号化を行う必要があります。特に注意が必要なものとしては、 core_config_dataテーブルに記録されていて、暗号化もされているが、backend_modelが\Magento\Config\Model\Config\Backend\Encryptedでないもの config.xmlとsystem.xmlのパスの定義が一致していないもの です。まずは検証用の環境を用意し、どのデータが正しく更新されないかを確認する必要があります。更新されないものについては 実装や定義の修正を行い、正しく再暗号化が行われることを確認する 手作業でパスワードや認証情報をセットし直す 必要があります。少なくとも顧客や管理者パスワードでこれらの作業は必要ありません。リサイズ後画像ディレクトリの更新もう1つ、サイトの規模によっては大変な作業があります。それは「リサイズ後画像を配置するディレクトリの更新」です。CDN側でリサイズを行っている場合には不要な作業ですが、おそらく大半のAdobe Commerce / Magento Open Sourceベースの環境では必要な作業です。 標準の仕様としては、「Magentoのリサイズ後商品画像のパスはどのように決まるか」で触れた通り、以下のパラメータと暗号化キーを用いてハッシュ値を算出し、リサイズ後の画像を配置するディレクトリ名に使用しています。 画像の高さ 画像の幅 画像の品質 角度 アスペクト比の維持フラグ 枠線の有無 背景透明の有無 元サイズより大きくなるリサイズの可不可 背景色の指定 もとのパラメータが同じだったとしても、暗号化キーが変わってしまうので、生成されるハッシュ値も変わります。そのため、暗号化キーを変更したあとは 画像の再リサイズを実施する ディレクトリ名の変更を実施する のいずれかが必要になります。このハッシュ値はあらかじめ計算しておけるものなので、暗号化キーの更新前に新しいディレクトリ名のリストを用意しておくとよいでしょう。作業を支援してくれるツールAdobe Commerce / Magento Open Sourceの強みはオープンソースコミュニティです。すでにコミュニティからこれらの作業を支援するためのツールがリリースされています。今回はそのなかでも 「genecommerce/module-encryption-key-manager」を紹介します。 このエクステンションには以下の機能が用意されています。 新しいキーの生成時に、古いJWT（Json Web Token）を自動で無効化する リサイズ後画像ディレクトリを暗号化キー更新後でも変わらないように調整する 古い暗号化キーの無効化 標準の再暗号化処理で正しく処理されないデータの暗号化 上手く使えば暗号化キーの切り替えに伴う様々な作業負荷を軽減することができるでしょう。ただし、Readmeにも書かれている通り「よく試験をしてから」本番投入するようにしてください。（弊社では責任を負いかねます）まとめ今回のまとめです。 CosmicSting（CVE2024-34102）を狙った攻撃がAdobe Commerce / Magento Open Source向けに多発していて、すでに被害が報告されている。 Adobe公式パッチの適用と、暗号化キーの更新が急務。 暗号化キーの更新に伴う諸作業が発生する可能性があるので、必ず検証環境でよく試験をしてから暗号化キーの切り替えを実施。 コミュニティが提供する支援ツールを利用することで、作業負荷とリスクの軽減が可能。 弊社ではこれらの作業に関しまして、テクニカルサポートを行う用意がございます。ご関心のある事業者様はお問合せフォームよりご連絡ください。お使いの環境を調査したうえで、対処費用などの提案をいたします。

2024年も半年がもう終わりましたね。皆さんはもう振り返りしましたか？半年を振り返ることは、メンタルヘルスケアの面でも、目標達成の面でも良いそうですよ！今回は私の2024年上半期の振り返りを書いていこうと思います。 自分でできるメンタルヘルスケア！2024年上半期を振り返る方法！ 皆さんこんにちは！早いもので2024年も上半期が終わりましたね。 上半期はどのように過ごされましたか？年始に立てた計画は順調に進んでいますか？ 半年を振り返り、整理しておくことで残りの半年をより良く過ごすことができると思います。... 関連記事はこちら>> 年始に立てた目標はなんだっけ？今年は、年始に目標とその為にやることをリストアップしていました。まず、それの整理から始めます。今年の目標は「心と体の健康を第一に整理の年にする」でした。去年は私自身、心の不調を抱えていた期間もあったり、生活のリズムが乱れていましたのでその乱れを整えること。そして心身の健康の為に良いことを色々と試してみることが目標です。B-Brain脳活用度テストのインストラクター資格を取ったこともあり、このような形でメンタルヘルスに関わることを発信することも目標のひとつです。今年のやることリスト目標の為にやろうと考えたことはこちらです。 健康のために体づくり 自然に触れる趣味を見つける 去年始めたマラソンを続ける メンタルヘルスケアの勉強をする 良かったこと、出来た事。次に良かったこと、出来たことを書き出して、計画通りなのか変更が必要なのかを振り返っていきます。まず良かったことは、やることリストの２つ「健康のための体づくり」と「自然に触れる趣味を見つける」が出来たことです！1. 健康のための体づくり今年の4月からジムに通って筋トレを始めました。私は165cm、48kgの超痩せ型で健康診断でも指導されることがありましたが、3か月で4kg増量の52kgになりました。筋トレは体の健康に良いのはもちろんですが、メンタルヘルスケアの面でも良い効果がたくさんあると言われています。 自己肯定感の向上 運動による睡眠の質改善 ホルモンによるストレス耐性 などが言われています。実際に試してみて、徐々に筋肉が大きくなっている実感と体重が増えていくことに達成感を感じることができました。この小さな達成感の積み重ねが自信に繋がっていくと思います。また、次の話（趣味を見つける）に繋がりますが、どんなことでも新しい事を始める時は不安や恐怖心はあるものです。それらを乗り越える為にも勇気が必要です。自分を信じる力、自信が必要になります。 ちなみに分泌されるホルモンについては、幸せホルモンと呼ばれる「セロトニン」の増加、やストレスを感じると分泌されるストレスホルモンの「コルチゾール」の低下によってストレス耐性が上がると言われています。加えて、コルチゾールは筋肉を分解してしまう作用もあるそうです。ジムにいるマッチョたちはストレスコントロールも上手なのかもしれませんね！2. 自然に触れる趣味を見つけるメンタルヘルスケアのセルフケアの方法として、日光を浴びる、自然に触れる、非日常を味わう、デジタルデトックスなどがよく言われます。それらを踏まえて何か良い趣味ないかなと考えて、今月バイクの免許を取りました！ずっと興味はあったのですがなかなか勇気がでず、5年越しの念願の免許です。なぜなかなか重い腰が上がらなかったのかというと、「体づくり」の話でも述べたように自信がなかったのです。「体型的にバイクが似合わなかったらいやだなぁ」「教習所になんとなく嫌な思い出あるな」と逃げていました。 まだ実際に遠出して自然に触れることは出来ていませんが、趣味のことを考えてワクワクしたり、没頭して嫌なことを忘れたりとメンタルヘルスケアの面で良い結果が出てくれていると思います。悪かったこと、出来なかったこと悪かったこと、出来なかったことは体調を崩したことです。5月、6月は体も心も調子を崩しやすい時期です。まんまとこの時期に気象病にやられてしまいました。気を付けていてもゼロにすることは難しいようです。反省点は私のせっかちな性格です。筋トレやバイクの教習で平日や休日の生活リズムが変わったにも関わらず、早く早くとオーバーワークをしてしまったのかもしれません。ポジティブな変化であってもストレスはかかるということ、心も体と同じく疲れることがあるということは覚えておきましょう。残り半年、これからの計画。最後に残り半年をどう過ごすかですが、やることリストの残りを埋めたいと考えています。去年メンタルヘルスケアの一環としてマラソンを始めました。今年もマラソン大会が11月にあるのでそれに向けてランニングを今月から始めようと考えています。ランニングのメンタルヘルスへの影響についてはこちらの記事も読んでみてください。 運動を習慣化！ランニングがメンタルヘルスにどう作用するのか？ 健康のために運動を勧められたことはありませんか？運動は健康だけでなくメンタルを安定させることの助けにもなります。しかし、心身の健康に良いと分かっていながら、なかなか続けることができなかったという経験をした方も多いかと思います。... 関連記事はこちら>> もうひとつ、メンタルヘルスケアの勉強はメンタルヘルスマネジメント検定の２種と３種、セルフケアとラインケアの資格を目指しています。勉強して学んだことはこのような形で発信していけたらと考えています。SNSでもメンタルヘルスに関する知識を発信しています。(@veriteworks) よかったらフォローしてみてください！ マラソンも検定試験も11月にあるので、上半期の反省を活かしてペース配分をしっかりと体調を崩さないようにしたいです。皆さんも残り半年心身ともに健康で充実して過ごせますように！

Magento（Adobe Commerce / Magento Open Source / Mage-OS共通という意味で扱います）に限らず、越境ECを含めた他国展開するEC事業で手間のかかる作業といえば、「税率の管理」ではないでしょうか。もちろんMagentoには標準機能として税率の管理機能が備わっていますが、すべての地域の税率を常時管理するのは意外と面倒なものです。今回、Stripe公式からStripe Tax連携用エクステンション（RC版）がリリースされましたので、早速試してみました。Stripe TaxとはStripe Taxは、Stripeが提供するサービスのひとつです。 購入者住所と品目からの税率判定と計算（50カ国以上とアメリカのすべての州に対応） 税申告と納税のアシスト などを行えるサービスです。Magentoに対応した税率計算サービスは TaxJar Vertex などがありますが、これらと似たサービスとなっています。課金体系についてStripe公式サイトによるとStripe Taxの料金体系は2通りあるとされています。このエクステンションが利用するのはAPI実装の方なので、 Transaction API @0.05USD Calculation API @0.05USD が都度かかることになります。Stripeとの通信履歴を見る限りではCalculation APIのほうが多い印象なので、実サービス投入時には注意したほうが良いかもしれません。Stripe Taxエクステンションを試してみようでは、Stripe Taxエクステンションをインストールしてみましょう。現時点ではcomposer経由のインストールはできないので、以下の手順でインストールを行います。 GithubからStripe Taxエクステンションのアーカイブをダウンロード ダウンロードしたアーカイブを展開 app/code/StripeIntegration下にアップロード composer require stripe/stripe-php を実行し、最新版のStripeライブラリをインストール（ここ重要） php bin/magento module:enable StripeIntegration_Tax php bin/magento setup:upgrade これでインストールは完了です。 stripe/stripe-phpライブラリが古いバージョンの場合、うまく動作しないことがあるので注意しましょう。初期設定の方法エクステンションのインストール後は初期設定を行います。Stripe Taxエクステンションの設定は大きく分けて2箇所あります。 システム設定 税区分設定 それぞれ順番に設定していきましょう。システム設定まずはシステム設定を行います。Stripe Taxの設定は、 ストア ＞ 設定 ＞ 税 にあります。 設定に際しては、 公開可能キー シークレットキー が必要です。あらかじめ用意しておきましょう。その他の設定は導入する環境に応じて調整します。 それから、Stripe側でTaxのロケーション設定が必要です。未設定の場合は、「Register a new tax location」からお使いのStripeアカウントの管理画面に移動して、設定を行いましょう。税区分設定ここまで設定ができたら、あとはMagento上の商品税区分とStripe Tax上の区分のマッピングを行います。 ストア ＞ 税 > Stripe Tax Classes にアクセスします。Magento上で定義済みの商品税区分がある場合は、初期状態でこの画面に表示されます。 ただし、Stripe Tax上の区分との紐づけはできていないので、アクション列で「Set Category」を選んでStripe Taxの区分との紐づけを行います。現時点のバージョンではStripe Tax上の税区分はすべて英文で表示されるため、日本の消費税法の定める軽減税率対象の商品を選ぶのは少し大変かもしれません。 新規構築のサイトの場合は、Stripe Taxの区分とMagento上の商品税区分を揃えておくと混乱が少ないかもしれません。いずれにしても、マッピングができたら「Save changes」で保存しておきます。実際に動かしてみようでは、実際にStripe Tax連携が有効な状態で購入テストをしてみましょう。適当な商品をカートに入れ、購入画面に進んでいきます。 税額のところに「Japanese consumption tax」と出ていますね。「consumption tax」が要は「消費税」のことです。このまま注文を確定すると、注文詳細画面では次のように表示されます。  Stripe Taxを導入する際の注意点さて、ここまでMagento用Stripe Tax連携エクステンションについてご紹介してきました。ここからはこのエクステンションを導入する際に注意するポイントについて取り上げたいと思います。税計算式が変更になるStripe Taxを導入すると、標準のMagentoが持っている税計算処理は無効化されます。Stripe Taxを使うかどうかはストアビューレベルで設定が可能なので、 日本国内は標準機能 or 独自計算式 日本国外はStripe Tax という使い分けが可能です。事業者によっては税額の計算に独自の計算式を使用していることがあります。この場合、Stripe Taxの税計算結果が従来の計算結果と異なってくる可能性があります。事前に十分検証したうえでご使用ください。また、日本のインボイス制度の計算式に合致しているかどうかについても十分検証が必要でしょう。API呼び出しに伴うコストStripe Taxはサービスの性質上、API呼び出し毎に課金が発生します。顧客が頻繁に注文金額の合計を更新するような場合、Stripe TaxのAPI呼び出しが大量に発生してしまい、利益を圧迫する可能性が予想されます。 大規模なトラフィックが予想される事案の場合は、あらかじめStripe側に相談をしておくと良いかもしれません。日本向けの課題現時点でわかっている日本国内向けの課題としては、 軽減税率と通常税率を分けて表示できない Stripe側で判定した税率の名称を翻訳できない という点でしょうか。Stripe Taxから得られた税額を税率別に表示すればよいはずなので、モジュールの改良で対処できそうな気がします。もちろん、Stripe Taxエクステンション自体がまだRC版であることを踏まえると、今後の改良余地はありそうですね。 翻訳に関しては、翻訳辞書を作るかStripe側で翻訳できるようにしてもらえれば済むような気がするので、ここもある程度どうにかなりそうな気がします。まとめ今回はStripeの1サービスである、Stripe TaxとMagentoを連携するためのエクステンションをご紹介しました。Stripeを利用している事業者であれば、別途サービスの契約が不要ですぐ導入できるという点は魅力的です。 ただし、このエクステンションはまだ正式版ではありませんし、細かいところでは物足りないところや使い勝手の良くないところがあります。今後段階的に改善されていくと思われますが、導入を検討される際は十分理解したうえでご使用されることをおすすめします。

今回はMage-OS向けに開発された、イベント駆動なデータ連携をするエクステンションについてご紹介します。このエクステンションを導入することによって、Mage-OSとMagento Open Sourceに対して、イベント駆動なデータ連携機能を追加することができます。Magentoには本来イベント駆動連携機能がないまず最初に、Magento Open SourceやMage-OS、Adobe Commerce（長いので以後、共通する話題について述べる場合はMagentoに統一します）にはイベント駆動な外部システム連携機能がないことをお伝えしておきます。確かに、Magento2.3系のリリース時に 非同期API バルクAPI が導入され、非同期処理ができるようになりました。ただし、これらの機能は「Magentoが外部のシステムからデータを受け取る」ことを主眼にしたもので、「Magentoから外部のシステムへデータを連携する」ことを主眼にはしていませんでした。 そのため、Magentoから外部システムへデータ連携をする場合は、 CSV等のファイルを定期的に出力する 自前で非同期処理を実装する という必要がありました。弊社でも実際のプロジェクトでこのような実装は手掛けたことが何度もありますが、相応に開発とテストの手間がかかるものでした。Adobe Commerce限定の仕組み有償版のMagentoであるAdobe Commerceに対しては、Adobe側から以下のような仕組みが提供されています。 Adobe I/O Events Webhook Adobe I/O Eventsはどちらかと言えばより大規模なイベント駆動システム連携をするための仕組みです。動作には必ずApp Builderのインスタンスが必要になり、開発コストも掛かります。その代わり、連携先システムへの通知に関してはAdobe I/O Eventsのシステムが間に立ってくれるため、連携先に個別にAdobe Commerceから通知を行う必要はありません。（ただし、App Builderのインスタンスからのアクセスはインスタンス数に応じて発生します）連携のイメージは下図のような形になります。 これに対してWebhookのほうはその名の通り、Webhook機能を実現するためのものです。Adobe I/O Eventsよりも簡便な仕組みでイベント駆動のシステム連携を実現します。連携先がさほど多くない場合は、Webhookのほうが適しているでしょう。連携のイメージは下図のとおりです。 残念な点としては、これらの仕組みはAdobe Commerceでしか利用できず、Magento Open SourceやMage-OSでは利用できないという点です。有償版ならでは、の仕組みではありますが、若干残念ですね。Mage-OSとMagento Open Sourceでイベント駆動を実現するにはMage-OSプロジェクトが公開しているリポジトリでは、以下のエクステンションが提供されています。 Magento Asynchronous Events Mage-OS Common Asynchronous Events Mage-OS Asynchronous Events Admin Ui これらのモジュールを組み合わせることで、イベント駆動なデータ連携をMagento上で実現できるようになります。対応しているイベントについては、Mage-OS Common Asynchronous Eventsで定義されていますが、もちろん自前でカスタム開発することも可能です。エクステンションのインストールでは、早速エクステンションをインストールしてみましょう。必要となる環境は以下のとおりです。 Magento Open Source / Mage-OS 2.4.4以降 PHP8.1以降 Rabbit MQまたはMySQL message queueの設定ができていること そのうえで、以下のコマンドを実行します。 composer require mage-os/mageos-async-events mage-os/mageos-common-async-events mage-os/mageos-async-events-admin-uiphp bin/magento module:enable MageOS_AsyncEvents MageOS_CommonAsyncEvents MageOS_AsyncEventsAdminUiphp bin/magento setup:upgrade productionモードの場合はdi:compileやstatic-content:deployが必要ですが、これらはお馴染みの手順なので本記事では割愛します。Webhookの作成Webhookを作成するには、Magento管理画面にアクセスし、 ストア ＞ Asyncronous Events > 購読者（Subscriber） にアクセスします。ここではWebhook通知先の管理ができます。 新しく通知先を増やしたい場合は、「新規追加」を行います。 このエクステンションでは、通知先に対して認証がかかっている場合は対応できません（現時点では、です）。何らかの認証が掛けられているエンドポイントに対してWebhook通知をしたい場合は、別途カスタマイズが必要になります。注意してください。どんなデータが通知先に飛ぶのかWebhookの実行履歴については、 ストア ＞ Asyncronous Events > ログ で履歴を確認できます。 一覧の右端にある「Trace」をクリックすると、送信したWebhookの履歴を確認できます。 リクエスト内容も確認できるので、エラーなどの場合に原因究明しやすいようになっています。 まとめ今回はMagento Open Source / Mage-OSにWebhook通知機能を追加し、外部システムへのイベント駆動データ連携を実現する方法をご紹介しました。この方法では通知するデータの内容を通知先に合わせて調整することは標準では用意されていないので、通知先の求める形式に整形したい場合は、 中間のサービスを挟む Magento側を調整する のいずれかの対応が必要になります。

ストレス耐性アップのためには、瞑想やマインドフルネスが有効であることは既に知られていますが、いざ日常に取り入れようとするとなかなか難しいですよね。今回は日常生活の中に瞑想に近いものがあるのではないかと考えた際に、私自身の生活の中で最も近いもので代用することでヒントになるのではないかと考え、趣味のオートバイを取り上げてみます。ChatGPTに尋ねてみた長年オートバイに乗る中で、瞑想に近いのではないかと考えてみました。経験則でオートバイを語ることはできるのですが、瞑想はちょっと調べてみただけでも膨大な情報があり多岐にわたるため、ChatGPTに尋ねてみました。オートバイと瞑想に共通点はありますか？オートバイに乗ることと瞑想にはいくつかの共通点があります。これらの共通点は、主に注意の集中、心のリラクゼーション、そして内面的な気づきに関するものです。以下に詳しく説明します。共通点1.注意の集中 オートバイ: オートバイに乗る際には、道路状況、交通、バランスなどに細心の注意を払う必要があります。これにより、ライダーは現在の瞬間に集中し、他の雑念を排除することになります。 瞑想: 瞑想では、呼吸やマントラなど特定の対象に注意を集中させます。この集中が心を静め、雑念を取り除く効果があります。 2.心のリラクゼーション オートバイ: 多くのライダーは、オートバイに乗ることでリラックスし、ストレスを解消することができると感じています。風を感じながら走ることで、自然との一体感や自由を感じることができます。 瞑想: 瞑想は心を落ち着け、リラックスする手段として広く認識されています。深い呼吸や静かな環境が心身のリラックスを促進します。 3.内面的な気づき オートバイ: 長時間のライディング中には、自分の思考や感情に気づく機会があります。この時間を利用して自己反省や内省を行うライダーもいます。 瞑想: 瞑想は自己観察と内面的な気づきを促進します。思考や感情を観察し、それに対する反応を理解することで、自己理解が深まります。 4.フロー状態 オートバイ: ライディング中には「フロー状態」と呼ばれる、時間の感覚が消え去り、完全に没頭する状態に入ることがあります。これは高い集中と快楽を伴う経験です。 瞑想: 瞑想中にも同様にフロー状態に入ることがあり、深い集中と内的な満足感を感じることがあります。 違い1.目的 オートバイ: 主な目的は移動や冒険、レクリエーションです。 瞑想: 主な目的は内面的な平和、精神的な成長、ストレスの軽減などです。 2.リスク オートバイ: ライディングには物理的なリスクが伴います。事故や怪我の可能性があります。 瞑想: 瞑想は一般的に安全であり、物理的なリスクはほとんどありません。 結論オートバイに乗ることと瞑想には多くの共通点があり、特に注意の集中、心のリラクゼーション、内面的な気づきに関して共通する要素があります。しかし、それぞれの活動には異なる目的やリスクも伴います。どちらの活動も、適切に行えば精神的な健康と幸福感を高める助けとなります。 ※上記の情報はChatGPT-4（OpenAI）による回答となります。オートバイを当てはめてみた（私の場合）集中オートバイに40年以上乗ってきた中でバイブルとなった書籍がありました。「ハイスピードライディング」（キース・コード著）という書籍です。この本の記述で最も身をもって体得した重要な言葉が「参照点（reference point）」でした。操作云々ではなく、オートバイは見ている方向へ向かっていく、というシンプルな解説が頭に焼き付いていました。おそらく、この本と出会わなかったら既にこの世に存在していなかったかもしれません。 ある時、ツーリング先の下り坂で私はオーバースピードになり、ブレーキングが一瞬遅れてしまいました。スピードが出過ぎていたせいで、本来バンクさせてターンするポイントは既に過ぎており、崖が目前に迫っていました。この時に、一瞬この本のことが脳裏に浮かび、無理矢理に視線をコーナー出口に向け奇跡的に事なきを得ました。後方を走っていた友人は「死んだ」と思ったそうです。 どこに向かっていくべきか集中することの重要さを身を持って感じた経験でした。オートバイは身体がむき出しになっていることもあり、一瞬の不注意が大怪我を伴う事故となるので、視線だけでなく常に集中して走らないといけません。心のリラクゼーション前出の「集中」と関連するのですが、何かに集中しようとした時に、さまざまな日常の出来事を考えていたらどうなるでしょうか？例えばですが、「今やっている仕事なかなか片付かないんだよな。。。」などと考えていたらどうなるでしょうか？考え事をしながらオートバイに乗っていると、おそらく事故を起こしてしまうでしょう。 また、「自分の方が速いのだから前を走っている車両を追い越してしまえ」とついつい欲を出したばかりに危険な目に遭うことはないでしょうか？何よりも怪我をしない・させない・事故を起こさない・違反しないためには、欲求のコントロールができないと常に危険に晒されることになるかと思います。（友人からは「お前が言うな」とは言われそうなのですが。。。） こうして走っていると、適度な緊張の中で集中しつつも、リラックスして（身体のどこかの筋肉が緊張している状態から解き放たれて）いることに気付くのです。緊張していると、不意の外乱（路面が荒れていたりとか）に対応できなかったりするのですが、身体の軸はしっかりしつつリラックスしていると容易に外乱を吸収できたりするのです。気づき前述の走ることに「集中」し、「自然体」になると、いろいろな事に気づき始めます。一例ですが、 前を走っていた車が何もないところで減速した タクシーが客がいない所で路肩に寄せた 一直線の道路なのに車がゆっくり走っている この結末は、 子どもが飛び出してきた タクシーは突然Uターンを始めた 速度取り締まりが行われていた オートバイ免許を取得した際に友人たちから「お前がオートバイに乗ったら死ぬよ」（なんでだ？）と言われていましたが、そのお陰か既に数十年もの間、無事故・無違反無転倒で今日まで至ります。（この先の未来も安全である保証は全くないので、日々精進あるのみです）フロー状態上記のような状態が続くと。。。確かに時間を忘れてしまいます。ということで、過去に「いつになったら休むんだい？」と一緒に走っている仲間から言われてしまったこともありますが、今は体力的な面もあり、1時間に1回は休んでおります。（今度は「いつになったら目的地へ着くんだい？」と聞かれそうですが笑）まとめ皆さんの周りにも瞑想に近いものはありませんか？大それた趣味でなくても、ちっちゃな植物を育ててみたりあるいは料理も良いかもしれません。是非日常生活の中で探していただければ、ストレスの軽減の一助となるものが見つかるのではないかと思います。何もない！という方はまだ自分の才能・能力に気付かれていないのかもしれません。そんな方は是非B-Brain診断を受けてみてください。※ 本記事については個人の考えであり会社を代表する考えではありません。また、専門的な助言を行うものではございません。お客さまが本サイトの情報を用いて行う行動や解釈について、いかなる場合も一切の責任を負いません

今回は前回セットアップしたCatalog Serviceに対して、実際にGraphQLクエリを投げる流れを紹介します。また、Catalog Serviceで利用できるクエリの種類についても解説します。Catalog Serviceで利用できるクエリの種類Catalog Serviceで利用できるクエリは、「Adobe CommerceのCatalog Serviceとは」で少し触れましたが、以下の4種類があります。 商品情報 カテゴリ情報 商品検索結果 商品オプション情報 商品に関する情報しかCatalog Serviceは保持していないので、以下のような情報についてはAdobe Commerceに直接クエリを投げる必要があります。 クーポン情報 会員情報 カート情報 購入手続き関係 Catalog Serviceにクエリを投げるにはCatalog Serviceにクエリを投げる前に、必要になるHTTPヘッダ情報を確認しておきましょう。各クエリとも共通で、以下のヘッダが必要となっています。 Magento-Customer-Group Adobe Commerce上の顧客グループID Magento-Environemnt-Id SaaS Identifierに表示されるもの Magento-Store-Code Adobe Commerceのストアコード Magento-Store-View-Code Adobe Commerceのストアビューコード Magento-Website-Code Adobe Commerceのウェブサイトコード X-Api-Key Commerce Service Connectorにセットするキー   このうち、以下の2つの値についてはどこから取得したら良いか解説しましょう。 Magento-Environemnt-Id X-Api-Key Magento-Environemnt-Idこの値を知りたい場合、以下の手順を踏む必要があります。 Adobe Commerceの管理画面にログインする 左ナビのメニューから「Commerce Services Connector」を選ぶ 表示された画面の「SaaS Identifier」を選ぶ Data Spaceの下に表示されている、「Data Space ID」をメモする なお、Data SpaceごとにIDは当然ながら異なるので、間違ったData SpaceのIDをメモしないように注意しましょう。下図の場所に書かれています。 X-Api-Keyこの値はSandboxまたはProductionのpublic APIキーです。Catalog Serviceを利用し始める段階で設定しているはずですが、もし忘れてしまった場合は以下の手順で確認できます。 Adobe Commerceの管理画面にログインする 左ナビのメニューから「Commerce Services Connector」を選ぶ 表示された画面の「Sandbox Keys」または「Production Keys」を選ぶ 「public API Key」をメモする クエリを投げるためのエンドポイントCatalog Serviceにクエリを投げる場合、以下のエンドポイントにクエリを投げます。 Sandbox　https://catalog-service-sandbox.adobe.io/graphql Production　https://catalog-service.adobe.io/graphql 当然ながら、本番用とテスト用でエンドポイントは異なります。利用するアプリケーションを設計・実装する際にはハードコードするようなことがないように注意しましょう。実際にクエリを投げてみようでは、試しにSandboxエンドポイントに対してクエリを投げてみましょう。なお、本記事で使用する商品データについては、公式のサンプルデータを使用しています。ヘッダ情報先程の6つのヘッダ情報には以下のように値をセットします。 Magento-Customer-Group 0 Magento-Environemnt-Id 先ほどメモしたもの Magento-Store-Code main_website_store Magento-Store-View-Code default Magento-Website-Code base X-Api-Key 先ほどメモしたもの クエリGraphQLクエリ本体については、categories queryのサンプルを使用します。以下のような内容です。 {   categories( ids: ["11"], roles: ["show_in_menu", "active"], subtree: { depth: 3, startLevel: 1 } ) {     name     id     level     roles     path     urlPath     urlKey     parentId     children     }   } 実際のリクエスト結果では、これらを連結して、エンドポイントにクエリを投げてみましょう。curlでリクエストする場合は、以下のような内容になります。 curl -X POST -H "Content-Type: application/json" \-H "Magento-Environment-Id: 先程のID"  \-H "Magento-Store-Code: main_website_store" \-H "Magento-Store-View-Code: default" \-H "Magento-Website-Code: base" \-H "X-Api-Key: 先程のキー" \-H "Magento-Customer-Group: 0" \https://catalog-service-sandbox.adobe.io/graphql -d '{"query":"{categories(ids: [\"11\"],roles: [\"show_in_menu\", \"active\"],subtree: {depth: 3,startLevel: 1}) {name,id,level,roles,path,urlPath,urlKey,parentId,children}}"}' この結果は、次のようになります。 {"data":{"categories":[{"name":"Men","id":"11","level":2,"roles":["active","show_in_menu"],"path":"1/2/11","urlPath":"men","urlKey":"men","parentId":"2","children":["12","13"]},{"name":"Bottoms","id":"13","level":3,"roles":["active","show_in_menu"],"path":"1/2/11/13","urlPath":"men/bottoms-men","urlKey":"bottoms-men","parentId":"11","children":["18","19"]},{"name":"Tops","id":"12","level":3,"roles":["active","show_in_menu"],"path":"1/2/11/12","urlPath":"men/tops-men","urlKey":"tops-men","parentId":"11","children":["14","15","16","17"]},{"name":"Jackets","id":"14","level":4,"roles":["active","show_in_menu"],"path":"1/2/11/12/14","urlPath":"men/tops-men/jackets-men","urlKey":"jackets-men","parentId":"12","children":[]},{"name":"Pants","id":"18","level":4,"roles":["active","show_in_menu"],"path":"1/2/11/13/18","urlPath":"men/bottoms-men/pants-men","urlKey":"pants-men","parentId":"13","children":[]},{"name":"Hoodies & Sweatshirts","id":"15","level":4,"roles":["active","show_in_menu"],"path":"1/2/11/12/15","urlPath":"men/tops-men/hoodies-and-sweatshirts-men","urlKey":"hoodies-and-sweatshirts-men","parentId":"12","children":[]},{"name":"Tanks","id":"17","level":4,"roles":["active","show_in_menu"],"path":"1/2/11/12/17","urlPath":"men/tops-men/tanks-men","urlKey":"tanks-men","parentId":"12","children":[]},{"name":"Shorts","id":"19","level":4,"roles":["active","show_in_menu"],"path":"1/2/11/13/19","urlPath":"men/bottoms-men/shorts-men","urlKey":"shorts-men","parentId":"13","children":[]},{"name":"Tees","id":"16","level":4,"roles":["active","show_in_menu"],"path":"1/2/11/12/16","urlPath":"men/tops-men/tees-men","urlKey":"tees-men","parentId":"12","children":[]}]}} 読みやすい例は公式のドキュメントに同じものがあるのでそちらをみていただいても良いでしょう。Catalog Serviceのパフォーマンスクエリの内容にもよりますが、Catalog Serviceにリクエストを投げてからレスポンスがえられるまでの時間は、300ms〜1.5sほどかかります。 Catalog Serviceのエンドポイントサーバーのある場所が日本から遠い場所にある可能性も考えられますが、それなりの時間が必要だということは間違いありません。 Catalog Serviceを利用する側のアプリケーションでキャッシュや読み込み中の表示を工夫するなどして、利用者にストレスを与えない実装をする必要があるでしょう。