Planned Featuresを一通り俯瞰すると、そこに見えてくるのは「もっと売れるようにする」「接客を賢くする」といった直接的なメッセージではありません。今回のCommerceは、店舗やECといった個別チャネルの話というよりも、販売・在庫・価格・注文・顧客といった要素を、どう業務として成立させるかという視点に、静かに重心を移しているように見えます。

これまでのDynamics 365 Commerceは、「売場のシステム」として語られることが多い製品でした。POS、EC、店舗オペレーション─それぞれの体験や機能をどう磨くか、という文脈で理解されることが自然だったと思います。しかし2026 wave 1の計画を見ていると、その前提が少しずつ揺さぶられているようにも感じます。

価格はFinanceやSCMと切り離して語れず、在庫はチャネルごとの都合ではなく全体最適が前提になり、注文や返品は例外処理ではなく業務プロセスの一部として整理されていく。こうした流れは、Commerceを「チャネル単位のアプリ」として見るだけでは、少し捉えきれなくなってきている兆候とも言えるでしょう。

もちろん、この段階で「Commerceはこう変わった」と言い切るのは早いかもしれません。ただ、今回のrelease wave 1からは、Dynamics 365 Commerceが単なる売るための仕組みではなく、企業活動の中でどう位置付けられるべきかを、改めて問い直そうとしている雰囲気が伝わってきます。

この先の章では、2026 release wave 1に含まれる具体的な新機能・改善点を通して、Dynamics 365 Commerceがどの方向へ進もうとしているのかを、室長の勝手な解釈で整理していきたいと思います。

この改善が効いてくるのは、複数の購買拠点や出荷先、価格条件を持つ法人顧客を扱うシナリオです。たとえば、同一企業であっても、東京本社と地方拠点で利用する商品が異なり、価格や在庫、配送条件も違う、といったケースは珍しくありません。従来は、こうした違いをCommerce側で表現するために、ユーザーアカウントを分けたり、別ストアとして管理したり、運用で吸収したりする必要がありました。Streamline multioutlet accessは、この煩雑さを前提から見直し、「1人のB2Bユーザーが、複数のアウトレットを文脈に応じて扱える」体験へ近づけようとするものです。

2025 release wave 2までのDynamics 365 Commerceでも、B2B向けのWebストアは十分な機能を備えていました。法人顧客、ユーザー、価格、カタログといった基本要素は揃っており、B2Cとは異なるB2B特有の要件にも対応してきました。ただし、複数アウトレットを持つ顧客を前提とした場合、その構造は必ずしも直感的とは言えず、「誰が、どの拠点の文脈で、今ストアを使っているのか」が分かりにくくなる場面もありました。その結果、設計や運用でカバーせざるを得ない部分が残っていたと言えます。

2026 release wave 1では、この前提に手が入ります。B2B Webストアにおいて、複数アウトレットを持つ顧客が、よりスムーズに適切な購買文脈へアクセスできるようになり、「どの拠点として買っているのか」「どの条件が適用されているのか」を意識しやすくなります。これは単にUIを調整するという話ではなく、B2Bコマースを“個人のログイン体験”ではなく、“企業の購買行動”として、捉え直す動きとも読み取れます。

この改善によって、B2B Webストアは「法人向けに作られたEC」から一歩進み、組織構造を持つ顧客が、業務として使える購買チャネルに近づきます。購買担当者が拠点や用途を切り替えながら利用する前提が明確になることで、価格、在庫、注文、配送といった後続プロセスとの整合も取りやすくなり、Commerceを業務フローの中に組み込みやすくなります。

一方で、留意点もあります。multioutlet accessが整理されるということは、裏を返せば、顧客マスターやアウトレット構造、価格・出荷条件の設計が、これまで以上に重要になるということです。アウトレットの定義が曖昧なままでは、体験が改善されても業務上の混乱は解消されません。この機能はB2B運用を簡単にする魔法ではなく、現実の購買構造を正しく表現するための器です。だからこそ、Commerce単体ではなく、FinanceやSCM側の設計と合わせて考えることで、本来の価値が見えてくる機能だと言えるでしょう。

Streamline multioutlet access for B2B web storefrontsは、B2Bコマースを「法人向けEC」という表現から、「企業の購買行動を支える業務チャネル」へと引き上げるための、静かですが重要な一歩です。Commerceがどこへ向かおうとしているのか。その方向性を読み解くうえで、この機能は分かりやすい入口の一つだと感じています。

B2B取引では、購買の起点と注文の成立が必ずしも1対1で結び付いているとは限りません。たとえば、購買担当者は全社共通のアカウントでログインしつつ、注文自体は拠点別、倉庫別、あるいは用途別のアウトレット単位で行われる、といった構造はごく一般的です。従来は、こうした注文構造をCommerce上で表現しようとすると、設計や運用での工夫が必要になり、CSUを介した注文処理では特に制約を意識する場面もありました。

2025 release wave 2までのDynamics 365 Commerceでは、CSUは店舗・オンラインを含むコマース処理の中核として機能していましたが、B2Bにおける「複数アウトレットをまたぐ注文」という前提は、必ずしも素直に表現できるとは言えませんでした。その結果、アウトレットごとにユーザーや注文フローを分けたり、後続の業務で帳尻を合わせたりといった対応が必要になるケースもありました。機能的には成立していても、B2Bの業務構造と完全に噛み合っているとは言いづらい部分が残っていたと言えます。

2026 release wave 1では、CSU経由のB2B注文においても、複数アウトレットを前提とした処理がサポートされることで、この前提が整理されます。ユーザーは同じB2Bストア体験の中で、適切なアウトレットの文脈を持ったまま注文を行えるようになり、CSU側でもその前提を崩さずに処理が進みます。これは、単に「複数アウトレットに対応した」という話ではなく、注文処理そのものをB2Bの業務単位で捉え直した改善だと読み取れます。

この変更によって、B2B Webストアでの操作と、その裏側で行われる注文処理や在庫引当、出荷、請求といった後続プロセスとの整合が取りやすくなります。購買担当者の操作と、実際にどのアウトレットとして注文が成立しているのかが分かりやすくなり、Commerceを起点とした業務フロー全体の見通しも改善されます。特に、FinanceやSCMと連携する前提のB2B運用では、この「文脈のズレ」が減ること自体が、大きな実務メリットになります。

一方で、ここでも留意点は明確です。multiple outlet B2B orderingが可能になるということは、アウトレット定義、在庫配置、価格条件、出荷ルールといった要素が、より正確に設計されていることが前提になります。CSU側で処理できる範囲が広がっても、業務設計が曖昧なままでは、注文処理が複雑化するだけに終わる可能性もあります。この機能は、B2B注文を魔法のように簡単にするものではなく、B2B業務の構造を、そのままCommerceに持ち込むための基盤強化だと捉えるのが適切でしょう。

Add support for multiple outlet B2B ordering via CSUは、先ほどのmultioutlet accessと合わせて見ることで、より意味を持つ機能です。アクセスから注文までを一貫して「複数アウトレット前提」で整理しようとする流れは、Dynamics 365 CommerceがB2Bコマースを、表層のUIやチャネル論ではなく、業務プロセスとして捉え直そうとしていることを示しています。このあたりから、Commerceの重心がどこへ移りつつあるのかが、少しずつ見えてくるように感じます。

これまでCSUのプロビジョニングや管理は、LCSを起点としたフローが前提となっており、環境の作成、再構成、運用といった作業は、Commerce固有の管理手順として扱われがちでした。その結果、Power Platformや他のDynamics 365アプリと並行して環境を管理している場合、「Commerceだけ管理の場所や考え方が違う」という違和感が生まれやすい構造になっていました。Manage Commerce Scale Unit deployment via Power Platform admin centerは、この分断を解消し、Commerceの運用管理をより統合的なものへと整理しようとする改善です。

この機能が効いてくるのは、Commerceを本番・サンドボックスを含めて継続的に運用している組織です。検証環境の立ち上げ、障害対応時の再起動、環境コピーによる再現テストなど、CSUに関わる運用作業は現場では少なくありません。Power Platform admin centerからCSUを管理できるようになることで、こうした作業を他のPower Platform環境と同じ感覚で扱えるようになり、管理作業の導線や責任分担を整理しやすくなります。

2025wave2までのDynamics 365 Commerceでは、Commerce自体はPower PlatformやDataverseの世界観と近い位置づけで語られる一方、CSUの管理はやや別枠として扱われていました。そのため、管理者やパートナー視点では、「業務アプリとしては近いのに、運用管理は別物」という印象を持つこともあったはずです。今回の変更は、その違和感を解消し、Commerceを他のDynamics 365アプリと同じ運用思想の中に収める動きだと捉えられます。

2026wave1では、Power Platform admin centerからCSUのプロビジョニングやライフサイクル管理を行えるようになり、Commerceの運用管理はより一貫した形になります。CSUの再起動、削除、複製といった操作を含め、環境管理を一つの管理面に集約することで、運用の見通しが良くなり、管理の属人化も抑えやすくなります。これは単なる管理画面の移動ではなく、CommerceをPower Platformの一員として明確に位置付け直す動きとも言えるでしょう。

一方で、留意点もあります。管理の入口が変わるということは、運用手順や権限設計、監査や統制の考え方も見直しが必要になるということです。これまでLCSを中心に回してきた組織ほど、管理者の役割や日常的な作業フローが変わりやすく、移行期には整理が求められます。この機能はCSU運用を自動化するものではなく、運用を標準化しやすくするための基盤です。Power Platform admin centerを前提に、誰がどこまで管理するのかを整理しておくことで、初めて安定した運用につながります。

Manage Commerce Scale Unit deployment via Power Platform admin centerは、Commerceを「個別に管理されるコマース基盤」から、「Power Platform上で他の業務アプリと並んで運用される業務基盤」へ近づけるための重要な一歩です。B2B機能で見えてきた“業務寄り”の方向性を、運用管理のレイヤーからも裏打ちする機能だと感じています。

小売やB2Bコマースの現場では、価格は必ずしも「SKUごと」に決められているわけではありません。サイズ、色、カテゴリ、ブランド、取引条件、顧客属性など、複数の属性の組み合わせによって価格ルールが決まるケースは多く、実務上は「この条件に当てはまる商品群の価格をまとめて変えたい」という要求が頻繁に発生します。従来は、こうした要件を満たすために、価格表を分けたり、対象商品を抽出して個別に更新したりといった運用が必要になりがちでした。

2025wave2までのDynamics 365 Commerceでも、価格管理の柔軟性は一定程度確保されていましたが、大量の商品に対して同じロジックで価格を調整したい場合、その作業は必ずしも効率的とは言えませんでした。特に、商品点数が多い環境や、頻繁な価格改定が発生するB2Bシナリオでは、「正しく更新する」こと自体が大きな運用コストになり、ミスや更新漏れのリスクも無視できない状況でした。

2026wave1では、attribute-based pricingを前提とした価格更新が整理されることで、この前提が変わります。商品や取引条件に付与された属性を軸に価格を定義・更新できるようになり、「どの商品か」ではなく「どの条件に当てはまるか」を基準に価格変更を行えるようになります。これにより、価格改定は例外的な作業ではなく、ルールに基づく業務プロセスとして扱いやすくなります。

この改善は、単なる操作性向上にとどまりません。属性ベースで価格を管理できるようになることで、価格が「その場の判断」や「一時的な調整」ではなく、業務ルールとして明示的に表現されるようになります。結果として、価格設定の意図が分かりやすくなり、後から見たときに「なぜこの価格なのか」を説明しやすくなります。これは、Commerceを単なる販売チャネルではなく、業務判断の結果を反映するシステムとして使ううえで、非常に重要なポイントです。

一方で、留意点もあります。attribute-based pricingが有効に機能するためには、商品属性や顧客属性が適切に設計・管理されていることが前提になります。属性が増えすぎたり、定義が曖昧だったりすると、価格ルールが複雑化し、かえって運用が分かりにくくなる可能性もあります。この機能は価格管理を自動化するものではなく、価格をルールとして整理するための器です。どの属性を価格判断に使うのか、どこまでを標準ルールとするのか、といった設計が重要になります。

Streamline mass price updates using attribute-based pricingは、価格管理を「商品を並べて直す作業」から、「条件に基づいて制御する業務」へと引き上げる機能だと言えます。B2BでもB2Cでも、価格が戦略や契約条件と強く結び付く環境ほど、この改善の価値は大きくなります。ここにも、Dynamics 365 Commerceが“売場の操作”ではなく、“業務プロセスとしてのコマース”へ寄ってきている流れが、静かに表れているように感じます。

B2Bコマースにおいては、注文が確定する時点で常に即時決済が行われるとは限りません。請求書払い、月締め請求、与信枠内での継続購買など、販売と回収のタイミングが分離しているケースが一般的です。そのため、与信超過のリスクは常に存在し、現場では「とりあえず受けて、後で調整する」「Finance側で止める」といった運用に頼らざるを得ない場面も少なくありませんでした。

2025wave2までのDynamics 365 Commerceでは、注文処理自体は可能であっても、与信管理の判断は主にFinance側や後続プロセスに委ねられていました。その結果、Commerce上では問題なく注文が作成されているように見えても、後から与信超過が発覚し、修正やキャンセル、調整が必要になるケースもありました。これは機能不足というより、「Commerceがどこまで業務判断を担うのか」という境界が曖昧だったことによるものと言えます。

2026wave1では、Commerce注文に対して与信管理の考え方を組み込むことで、この前提が整理されます。注文時点で顧客の与信状況を考慮できるようになり、どの注文が許容範囲なのか、どこで注意や判断が必要なのかを、Commerceの文脈で扱えるようになります。これにより、注文の成立と回収リスクの間にあったギャップを、早い段階で意識できるようになります。

この改善は、単に「与信チェックができるようになる」という話ではありません。Commerceが、注文を単なる取引イベントとしてではなく、企業として引き受けるべきリスクを伴う業務判断として扱い始めている点に意味があります。販売チャネルの都合だけで注文を受けるのではなく、Financeや債権管理と同じ前提で注文を捉える。その姿勢が、この機能には表れています。

一方で、留意点もあります。与信管理をCommerce側で扱えるようになることで、顧客マスター、与信枠、請求条件といった情報の整備が、これまで以上に重要になります。与信ルールが曖昧なままでは、判断基準が分かりにくくなり、現場の混乱につながる可能性もあります。この機能は与信判断を自動化するものではなく、どの段階で、どの視点の判断を行うのかを明確にするための仕組みだと捉えるのが適切でしょう。

Enable credit management support for Commerce ordersは、Commerceを「注文を受けるシステム」から、「与信と回収を意識した業務プロセスの入口」へと一段引き上げる機能です。B2Bコマースにおいて、販売と財務を切り離さずに扱おうとする今回の流れの中で、この機能は非常に象徴的な位置付けにあるように感じます。

現実のコマース業務では、在庫は必ずしも単一の法人内で完結しているとは限りません。グループ会社間で在庫を融通しているケース、販売法人と在庫保有法人が分かれているケース、地域別法人で在庫を持ちながらも、販売現場では全体在庫を意識した判断が求められるケースなど、リーガルエンティティをまたぐ在庫構造は珍しくありません。従来は、こうした構造をCommerceやPOS上でそのまま表現することが難しく、運用や説明で補う必要がありました。

2025wave2までのDynamics 365 Commerceでは、CSUやPOSが参照する在庫は、基本的に現在の法人やチャネルの文脈に強く紐づいていました。そのため、「別法人には在庫がある」「他拠点から融通できる」といった情報は、別画面や別システムで確認する必要があり、販売現場で即座に判断するのは簡単ではありませんでした。結果として、販売機会の逸失や、不要な欠品対応、後工程での調整が発生することもありました。

2026wave1では、CSUおよびPOSにおいて、リーガルエンティティをまたいだ在庫参照が可能になることで、この前提が緩和されます。販売や受注の現場で、現在の法人だけでなく、関連する他法人の在庫状況を把握できるようになり、「どこに在庫があるのか」「代替手段はあるのか」といった判断を、より早い段階で行えるようになります。これは在庫を横断的に使えるようにする、というよりも、在庫情報を横断的に“見る”ための整理だと捉えるのが適切でしょう。

この改善は、B2B・B2Cを問わず、オムニチャネルやグループ経営を前提としたコマース運用において、実務的な意味を持ちます。POSやCSUが参照できる在庫の視野が広がることで、販売判断と在庫戦略の距離が縮まり、Commerceが単なる取引処理の仕組みではなく、業務判断の入口として機能しやすくなります。ここでも、Commerceを現場のツールに留めず、業務全体の一部として扱おうとする方向性が見えてきます。

一方で、留意点もあります。複数リーガルエンティティの在庫を参照できるようになることで、「見える」情報は増えますが、それを「どう使うか」は別の話です。実際に在庫を融通できるのか、どの法人間で移動が許されるのか、原価や収益はどう扱うのかといった判断は、引き続き業務ルールに依存します。この機能は在庫移動や引当を自動化するものではなく、判断材料を正しく提示するための基盤です。リーガルエンティティ間の在庫運用ルールと合わせて設計することで、初めて効果を発揮します。

Enable cross-legal entity inventory lookup in CSU and POSは、Commerceにおける在庫管理を「法人ごとに閉じた情報」から、「グループ全体で把握すべき業務情報」へと引き上げる機能です。価格や与信、注文と同様に、在庫もまた業務判断の一部として扱われ始めていることを示す、地味ですが方向性のはっきりした改善だと感じます。

実店舗やB2B取引の現場では、返品不可とすべき商品は珍しくありません。たとえば、消耗品や衛生用品、カスタム品、特注品、ライセンス性のある商品、あるいは特定条件下でのみ販売される商品など、返品を受け付けることでリスクやコストが大きくなるものもあります。従来は、こうしたルールをPOSオペレーターの判断や運用ルールに委ねるケースが多く、結果として対応にばらつきが出たり、トラブルにつながったりすることもありました。

2025wave2までのDynamics 365 Commerceでも、返品処理自体は標準機能として整備されていましたが、「この商品は返品できない」「この条件では返品不可」といった判断は、必ずしもシステム上で一貫して制御できるとは限りませんでした。そのため、返品可否の判断が現場の経験や注意喚起に依存しやすく、ルールがあっても徹底されにくい構造になっていたと言えます。

2026wave1では、POSにおいて特定商品の返品を防止できるようになることで、この前提が整理されます。返品を許可しない商品については、システム側で明確に制御できるようになり、オペレーターは判断に迷うことなく、ルールに沿った対応を行えます。これは、返品を厳しくするための機能というよりも、返品ルールを業務プロセスとして安定させるための改善だと捉えるのが適切でしょう。

この変更は、顧客体験と業務統制のバランスを取り直す意味も持っています。すべてを現場判断に任せるのではなく、事前に定義されたルールをPOSに反映することで、対応の一貫性が保たれます。結果として、顧客への説明もしやすくなり、トラブルの予防にもつながります。Commerceが「現場の操作を支えるツール」から、「業務ルールを正しく実行させる基盤」へと寄ってきている流れが、ここにも表れています。

一方で、留意点もあります。返品不可の設定は、商品マスターや契約条件、法規制との整合が前提になります。ルール設定が曖昧なままでは、現場で混乱を招いたり、顧客満足度を損ねたりする可能性もあります。この機能は返品対応を自動化するものではなく、返品に関する判断基準を明確にし、それを確実に実行するための仕組みです。どの商品を対象にするのか、どの理由で返品不可とするのかを整理したうえで使うことが重要になります。

Prevent the return of specific items in point of saleは、Commerceを「例外処理が多い現場システム」から、「業務ルールが一貫して適用される業務基盤」へと近づける機能です。価格や与信、在庫と同様に、返品もまた業務判断の一部として整理され始めていることを示す、静かですが実務的な改善だと感じます。

実店舗の現場では、すべての支払方法が常に同じ重要度を持つわけではありません。現金、クレジットカード、電子マネー、QR決済、掛け払いなど、店舗や時間帯、顧客層によって実際によく使われる支払方法は異なります。それにもかかわらず、POS上で支払方法が一律に並んでいると、オペレーターは毎回選択に迷い、結果として操作時間の増加や誤選択につながることがあります。

2025wave2までのDynamics 365 Commerceでも、支払方法そのものは柔軟に設定できましたが、POS画面上での表示順や可視性については、運用や教育でカバーする前提が残っていました。たとえば、「この店舗では基本的にこの支払方法を使う」と決まっていても、POS画面上では他の支払方法と同列に並び、現場の判断に委ねられる場面も少なくなかったと言えます。

2026wave1では、支払方法の表示順序や表示可否を制御できるようになることで、この前提が整理されます。よく使う支払方法を上位に表示したり、特定の店舗や条件では使わない支払方法を非表示にしたりといった調整が可能になり、POS操作を業務ルールに近づけることができます。これは見た目の改善というよりも、現場での判断を減らし、操作を標準化するための改善だと捉えるのが適切でしょう。

この変更によって、POSオペレーションはより一貫したものになります。新人スタッフや応援要員であっても、画面上に表示される選択肢が整理されていれば、迷う余地は小さくなります。結果として、会計処理のスピードが上がり、誤操作や修正の発生も抑えやすくなります。Commerceが現場の“慣れ”に頼るのではなく、システム側で正しい流れを作ろうとしている点が、この機能からも読み取れます。

一方で、留意点もあります。支払方法を非表示にする、あるいは順序を固定するということは、例外対応の余地を減らすことでもあります。特定の顧客対応やイレギュラーな取引が発生する店舗では、どこまで制御するのかを慎重に判断する必要があります。この機能は支払方法を制限するためのものではなく、通常業務をスムーズに回すための前提を整える仕組みです。現場運用と照らし合わせたうえで、どのレベルまで制御するかを設計することが重要になります。

Set payment method display order and visibility in POSは、Commerceを「多機能なPOS」から、「業務ルールが自然に実行される現場基盤」へと近づける改善です。価格、与信、在庫、返品と同様に、支払方法もまた業務設計の一部として扱われ始めていることを示す、地味ですが実務に効く機能だと感じます。

この機能が効いてくるのは、POSオペレーションが複雑化している店舗です。商品検索、商品詳細確認、会計、割引や在庫状況の確認といった一連の流れは、現場では秒単位の積み重ねになります。操作が重い、画面遷移が多い、必要な情報が見つけにくい、といった“小さな摩擦”が多いほど、会計スピードが落ち、レジ待ちが増え、スタッフの判断ミスも起こりやすくなります。今回のPOS最新化は、そうした摩擦を減らし、必要な情報を適切なタイミングで分かりやすく提示しながら、販売フローをより滑らかにする方向性だと捉えられます。

2025wave2までのPOSでも、必要な機能は一通り揃っていましたが、UIフレームワークや画面構造の前提が古いままだと、どうしても「情報はあるが取り出しにくい」「できるが時間がかかる」という状態になりがちでした。特に、商品一覧、商品詳細、トランザクション画面はPOSの中心でありながら、業務の流れに対して画面構造が最適化されているとは言いづらい場面もありました。その結果、現場では“慣れ”でカバーする運用が残りやすく、店舗ごとの品質差が出やすい領域でもありました。

2026wave1では、商品一覧（検索結果）、商品詳細、トランザクション画面といった主要ビューが、ReactとFluent UIによる一貫したレスポンシブな体験へ移行し、デスクトップとモバイルの両方で同じ考え方の操作ができる方向へ進みます。また、在庫アラートや割引といった販売判断に直結する情報を、より早い段階で見せることが意識されており、「必要な情報を探しに行く」から「必要な情報が先に出てくる」体験へ寄せている点も特徴です。POSを単なる入力画面ではなく、現場の意思決定を支える画面にしていこうとしているように見えます。

この機能のもう一つのポイントは、段階的なロールアウトと制御が前提になっていることです。すべてを一気に置き換えるのではなく、管理者が機能フラグやビジュアルプロファイルの単位で有効化し、店舗や環境ごとに適用範囲をコントロールできる設計になっています。つまり、「新しいPOS体験を提供する」だけでなく、「現場を止めずに移行する」ことまで含めて考えられている改善だと言えます。

一方で、留意点もあります。POS体験が新しくなるほど、現場の教育や運用手順の見直しが必要になります。UIが変われば、従来の“慣れ”で成立していた操作は一度リセットされる可能性がありますし、拡張やカスタマイズをしている店舗ほど、既存の拡張ポイントとの整合も意識する必要があります。この機能はPOS業務を自動化するものではなく、現場の操作と判断を支える基盤を刷新するものです。だからこそ、段階的に適用し、店舗の反応や運用影響を見ながら進める前提で捉えるのが現実的でしょう。

Modernize POS journeys with React and Fluent UIは、Commerce全体の方向性として見えてきた「現場の体験を業務プロセスとして整える」という流れを、最も分かりやすく体現する機能の一つです。派手な新機能というより、POSという“毎日使う場所”の基本体験を作り直すことで、結果として販売効率と運用品質を底上げする。そういうタイプのアップデートだと感じます。

セルフチェックアウトが導入されている店舗では、必ずしも利用者が単一言語話者とは限りません。訪日客や在住外国人、あるいは多言語環境で働く従業員など、店舗によっては日常的に複数言語が混在する状況も珍しくありません。従来は、セルフチェックアウトの言語対応が限定的であったため、操作に迷う、途中で操作を断念する、結局スタッフを呼ぶ、といった場面が発生しやすく、セルフサービスの効果を十分に活かしきれないケースもありました。

2025wave2までのDynamics 365 Commerceでも、POSやチャネル全体としての多言語対応は進んでいましたが、セルフチェックアウトという“完全に顧客主導の体験”においては、言語切り替えや表示の柔軟性が十分とは言えない場面が残っていました。その結果、店舗によっては「セルフチェックアウトは特定の顧客層向け」という暗黙の前提が生まれ、利用範囲が限定されてしまうこともありました。

2026wave1では、Store Commerceのセルフチェックアウトで複数言語をサポートすることで、この前提が緩和されます。利用者が自身にとって理解しやすい言語で画面を操作できるようになり、商品のスキャン、支払方法の選択、確認画面といった一連の流れを、迷いなく進めやすくなります。これはセルフチェックアウトの利便性を高めるだけでなく、店舗オペレーション全体の効率にも影響する改善です。

この機能のポイントは、単に表示言語を増やすことではありません。セルフチェックアウトにおいては、操作ミスや理解不足がそのままトラブルや滞留につながるため、言語対応は体験設計そのものの一部になります。複数言語を前提とした設計が可能になることで、「誰が使っても同じ流れで完了できる」セルフチェックアウトに近づき、スタッフの介入を減らしやすくなります。結果として、セルフサービス本来の効果が出やすくなります。

一方で、留意点もあります。多言語対応を有効にするためには、翻訳の品質や用語の統一、店舗ごとの対象言語の選定といった設計が欠かせません。単に言語を増やせばよいわけではなく、どの言語を、どのレベルまでサポートするのかを明確にしないと、かえって分かりにくい体験になる可能性もあります。この機能はセルフチェックアウトを自動的に“グローバル対応”にするものではなく、多様な利用者を前提に設計するための基盤だと捉えるのが適切でしょう。

Support multiple languages in Store Commerce self-checkoutは、セルフチェックアウトを「特定条件下で便利な仕組み」から、「多様な顧客が安心して使える標準的な購買チャネル」へと引き上げる機能です。POSの近代化や支払方法制御と並んで、Commerceが現場体験を業務品質の一部として捉え直している流れが、ここにも静かに表れているように感じます。

D365 Commerceよ、君はどこに向かっているのかい？

ここまでDynamics 365 Commerce 2026 release wave 1の新機能・改善点を一つひとつ見てきましたが、全体を通して強く感じるのは、「Commerceをどう便利にするか」ではなく、「Commerceをどう業務として成立させるか」に軸足が置かれている、という点です。

次回予告｜Dynamics 365 Human Resource 2026 wave 1―人事はもはや“管理部門”でいられるのか？

それでは、今日はこのくらいで。Let’s Enjoy our DX365 Life!