こんばんは。皆さま、いかがお過ごしでしょうか？

“室長”こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

フィリピンは今日も雨でした。先日マニラのBGCからBusiness Central 28.5の記事を書いたとき、窓の外はスコールでした。「フィリピンは今日も雨」——そのフレーズが頭に浮かんだ瞬間、あの名曲を思い出しました。「長崎は今日も雨だった」。内山田洋とクール・ファイブ。ちょっと古いですかね。おぢさんですねー。

今回の出張も後半戦に入りました。少し疲れが溜まってきていますし、最近は目の調子も悪くて。いつもは大画面のモニターで作業しているのですが、出張中はノートPCとモバイルモニターだけなので、目への負担がいつもより大きい気がします。歳のせいにしておきます。

さて。毎年この時期は、Wave2の季節でした。8月末から9月にかけて、Microsoftがリリース計画を公開し、各アプリの新機能を一気に追いかける、いわば年2回の祭り。今年もその時期になりましたが、「年2回の祭り」は終わりました。Waveという形式そのものが廃止され、情報はAI at Work ロードマップへ移行しています。

ただ、Waveがなくなっても、製品は動き続けています。Microsoftは機能をリリースし続けていますし、私たちが追うべき「今、何ができるのか」は変わりません。形式が変わっただけで、やることは同じです。

ということで、今年も各アプリの現在地を整理していきます。すでにBusiness CentralとFinance & SCMは書きました。今日は、Dynamics 365 Commerceです。

最後までお付き合いいただけますと幸いです。

注記：本稿の内容は、Dynamics 365 Commerce 10.0.48時点で公開されている情報をもとにした整理および筆者の見解です。機能によって一般提供（GA）・プレビュー・段階的展開・追加設定が必要なものがあります。機能の提供状況、対象地域、ライセンス、前提設定、対応プラットフォームは変更される場合があります。実際の導入にあたっては、対象環境のリリースノート、Microsoft Learn、機能管理設定、ライセンス条件、関連するFinance・SCM・Entraの設定を必ずご確認ください。

Dynamics 365 Commerce — 2026年9月時点の現在地

―Dynamics 365 Commerce 10.0.48（2026年6月GA / 7月自動更新）における新機能・改善点―

D365 Commerceよ、君はどこへ向かおうとしているのか？

Dynamics 365 Commerce 10.0.48のリリースノートを眺めていて、まず感じるのは、このバージョンが「店舗のシステム」から「企業の商取引基盤」へと、確実に重心を移しているということです。

Point of Saleのモダナイズ、法人間をまたぐフルフィルメント、B2Bの与信管理、外部アプリとのコンテキスト連携——これらは、個別チャネルの改善という話ではありません。Commerceが、Finance・SCMと同じ土俵でエンタープライズの業務を回す基盤へと、静かに変わろうとしているように見えます。

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

まず押さえておきたい — Commerceのデータ基盤は単一ではない

各機能の話に入る前に、ひとつ整理しておきたいことがあります。Dynamics 365 Commerceは「POSとECのアプリ」というイメージで語られることが多いですが、データ基盤の構成はFinanceやSCMよりも複雑です。機能を正しく理解するために、主要コンポーネントを先に確認しておきましょう。

※ Commerceのデータ基盤は構成要素ごとに役割が異なります。「CommerceはAzure SQLで動く」という単純化は避け、HQ・チャネル・Scale Unitの関係を踏まえて設計・評価することを推奨します。

≪Fulfillment≫

Cross-legal entity order fulfillment — 法人をまたぐ注文フルフィルメント

Commerceの注文を、複数の法人（Legal Entity）をまたいで調達・フルフィルできるようにする機能です。小売業者はクロスLE対応のフルフィルメントグループを定義し、複数法人の在庫にアクセスし、インターカンパニー注文を自動生成し、POS（Point of Sale）からクロスLE注文をフルフィルすることができます。DOM（Distributed Order Management）のプロファイルとルールも、このクロスLE戦略をサポートするように更新されています。

これが効いてくるのは、複数の法人を持つ小売グループや、地域ごとに法人を分けて運用している企業です。たとえば、東日本法人の在庫が不足している場合に、西日本法人の在庫を調達してフルフィルする、あるいはグループ間で在庫を融通し合いながら欠品を防ぐ、といった運用を、CommerceとFinance・SCMの連携モデルの中で、より標準的に構成できるようになります。これまで個別運用や追加連携が必要だったクロス法人の調達・フルフィルメントが、Commerceの注文管理を起点として設計できるようになります。

これまでのDynamics 365 Commerceでは、フルフィルメントは基本的に単一法人の範囲で行われることが前提でした。法人をまたぐ在庫調達が必要な場合は、Finance・SCMのインターカンパニー機能を別途活用するか、運用で吸収するかという対応が中心でした。Commerce側でそれを完結させる手段は限られており、特にPOSからのクロスLE操作は現実的ではありませんでした。

10.0.48では、Commerce・Finance・SCMおよびDOMを組み合わせたクロスLEフルフィルメントシナリオが標準サポートされます。フルフィルメントグループの定義からDOM処理、インターカンパニー注文の自動生成、POSからの操作まで、Commerceの注文・DOM機能を起点として、一連のクロス法人フルフィルメントを構成できるようになります。複数法人の在庫を束ねて最適フルフィルを行う、という動作がアーキテクチャとして整理された点は、グループ運用をするパートナーにとって大きな変化です。

ただし、この機能は有効化するだけで動くものではありません。インターカンパニー取引の設定、法人間の価格・コスト設計、DOMプロファイルのルール整理、そして会計処理をどう切り分けるかという設計が前提として必要です。クロスLE対応はCommerceの機能が広がったことを意味しますが、Finance・SCMの設計と密接に連動するため、実装は両方を見渡したアーキテクト視点で進める必要があります。

≪Point of Sale≫

Modernized customer details page — React × Fluent UI × Copilot の顧客画面 プレビュー

Store CommerceのPOSにおける顧客詳細画面を、React＋Fluent UIベースのモダンなUIに刷新する機能です。従来のレガシービューを置き換え、デスクトップとモバイルの両フォームファクターに対応したレスポンシブ設計になっています。画面はAccount summary・Timeline・Account details・Transactionsの4タブ構成となり、Account summaryタブにはCopilotによる顧客インサイトとレコメンド商品が表示されます。また、Transactionsタブでは購入履歴を確認しながら「Buy again」ボタンで過去購入商品をカートに追加できます。

この機能が効いてくるのは、店舗スタッフが顧客と対面しながら接客するシーンです。たとえば、来店した顧客のプロファイルを開いた際に、Account summaryタブで顧客の購買履歴や利用可能な顧客情報をもとにしたCopilotインサイト・推奨商品を確認でき、過去購入品を1クリックでカートに入れることができます。接客しながら画面を操作する時間が短縮され、顧客との会話に集中できる時間が増えます。

これまでのStore Commerceの顧客詳細画面は、機能としては十分なものを備えていましたが、UIの設計としてはやや旧来の作りが残っており、情報が複数画面に分散していました。特にモバイル端末での操作感や、AIインサイトを自然な形で埋め込む設計には限界がありました。Copilotの活用も、別途操作が必要な形での提供が中心でした。

10.0.48では、顧客詳細画面がReact＋Fluent UIで全面再設計されます。4タブに情報が整理され、Account summaryにCopilot顧客インサイトがネイティブに組み込まれます。モダン顧客詳細画面を有効化すると、Account summary内にCopilot顧客インサイトや推奨商品を表示する体験が提供されます。なお、有効化すると従来の顧客詳細ビューが置き換えられる点に注意が必要です（旧画面との併用ではありません）。有効化はFeature managementから「Modern customer details page」をON → 1110（Global configuration）配布ジョブ実行 → Store Commerce再起動、の手順です。

留意点は、Feature managementでの有効化が必要なこと（現時点ではプレビュー機能）、およびCopilot顧客インサイトの表示内容や有用性が、顧客データの整備状況、Dataverse連携の設定、利用可能な機能・環境条件に依存する点です。顧客データが整備されていない環境では、インサイトの有用性は限定的になります。まずはパイロット店舗で有効化し、スタッフのフィードバックを確認しながら展開を判断するのが現実的でしょう。

Contextual switching of POS with external apps — 外部アプリとのシームレスな文脈連携

外部システムからPOSへ、商品・顧客・トランザクションの文脈を直接渡せるようにする機能です。これまで、外部システムとPOSを統合するには相応の開発工数が必要でした。また、スタッフがアプリ間を移動するたびに情報を手入力し直す必要がありました。Contextual switchingは、この摩擦をなくし、外部アプリがPOSに文脈を渡すことで、情報の再入力なしに操作を引き継げるようにします。

活用シーンとしては、例えば商品スキャンアプリ・予約管理システム・修理受付システムなどの外部アプリで処理した情報を、そのままPOSのカート・顧客情報・トランザクションとして引き渡すケースが想定されます。特定業態（家電量販・自動車販売・修理サービスなど）では、業務専用アプリとPOSが共存している場面が多く、そこでの二重入力の解消に直結します。

これまでは、外部アプリとStore CommerceのPOSをつなぐには、カスタム開発による統合が必要でした。POS拡張フレームワークを使ったAPIの呼び出しや、独自のセッション管理など、実装コストが高く、既存のPOS投資を壊さずに統合するのは容易ではありませんでした。

10.0.48では、外部アプリがコンテキスト情報をPOSに直接渡せるAPIが整備されます。POSとのコンテキスト連携に必要な標準的な接続方式が提供されることで、従来の完全な個別統合と比較して、設計・実装の共通化が期待できます。詳細はMicrosoft LearnのContextual switching ドキュメントに記載されています。

ただし、この機能は外部アプリ側でも対応する実装が必要です。Contextual switching APIを呼び出すコードを外部アプリに組み込む必要があり、その設計はパートナーやSIが担います。「つながる仕組みができた」ことと「つなげた」ことの間には、設計と実装の工数があります。標準機能として使えるわけではなく、活用には開発リソースが前提になります。

Prevent the return of specific items in POS — 返品不可設定の標準化

特定の商品や商品カテゴリー全体を「返品不可」として定義できるようにする機能です。マーチャンダイジングマネージャーが、対象商品に「返品不可」プロパティを設定すると、POSで返品しようとした際にブロックされます。個別設定のほか、カテゴリービューからの一括設定も可能です。

実務上の活用シーンは幅広いです。消耗品・食品・カスタム注文品・セール品・衛生用品など、業種や商品特性によって「返品を受け付けない」という運用は一般的です。これまでは、POSの標準機能でこれを制御するには設定上の工夫や運用ルールの徹底が必要でした。今回の機能により、商品マスター側で返品可否をコントロールする仕組みが標準化されます。

以前は、返品不可の運用をPOSレベルで徹底するには、スタッフへの教育や個別の確認フロー、あるいはカスタム開発によるブロック実装が必要でした。標準機能として「返品不可」を設定する手段が限られており、店舗やスタッフによって対応がばらつくリスクがありました。

10.0.48では、released productに「返品不可」プロパティを設定することで、対象商品の返品処理をPOS側で制御できるようになります。個別商品・カテゴリー一括の両方に対応し、設定の手間も最小限です。設定された返品ポリシーをシステム上で一貫して適用しやすくなる点に、運用上のメリットがあります。

留意点は、このプロパティを誤設定した場合の影響範囲です。カテゴリー一括で返品不可を設定した場合、意図しない商品まで返品不可になるリスクがあります。設定前に対象カテゴリーの範囲を確認し、必要に応じて個別商品単位での設定を選ぶ方が安全です。また、顧客への説明義務（購入時の返品不可告知）は業務フローとして別途整理が必要です。

≪E-commerce≫

Entra External ID サインインページのブランディングカスタマイズ

Microsoft Entra External ID（EEID）のサインイン・サインアップ画面を、ストアフロントのブランドに合わせてカスタマイズできるようにする機能です。EEIDは、新規導入においてAzure AD B2C（Azure Active Directory Business to Consumer）に代わる選択肢として位置付けられているCIAM（Customer Identity and Access Management）ソリューションです。新規デプロイではAzure AD B2Cの代替として採用が進んでいますが、今回のアップデートにより、サインイン体験のブランディングカスタマイズもEEIDで対応できるようになります。

ECサイト運営において、サインイン画面は顧客が最初に目にするブランド接点のひとつです。ロゴ・配色・フォント・背景画像などをストアフロントのデザインに合わせることで、サインイン体験がブランドの一部として機能します。特にプレミアムブランドや、D2C（Direct to Consumer）戦略を重視する企業にとって、この統一感は顧客体験の品質に直結します。

Azure AD B2Cでは、サインイン画面のカスタマイズには独自のHTMLテンプレート作成やCSSの調整が必要で、開発者の工数と専門知識が求められました。EEIDへの移行が進む中で、ブランディングカスタマイズの対応範囲が懸念点のひとつでしたが、今回の対応によりブランディング面での採用上の制約の一部が緩和されます。

10.0.48では、EEIDのサインインページに対して、ブランディングカスタマイズのサポートが拡張されます。サインイン・サインアップ体験にブランド要素を適用するための選択肢が広がり、EEIDを新規採用した場合でも、ブランド統一に向けた設計がより現実的になります。Azure AD B2Cからの移行を検討している場合、ブランディング面でのひとつのハードルが下がったことを意味します。

ただし、EEIDへの移行は単なるCIAMのスワップではありません。テナント構成・ポリシー設計・カスタムフロー（サインアップ時の属性収集など）の再設計が必要になるケースがあります。ブランディングカスタマイズが可能になったことは前進ですが、移行プロジェクト全体のスコープは別途見積もりが必要です。

≪Omni-channel≫

Credit management support for Commerce orders — B2B与信管理のCommerce統合

Commerce注文に対して、標準の与信管理フレームワークを適用できるようにする機能です。B2B取引では多くの場合、代金は後払い（掛売り）で行われ、与信限度額の管理が業務上の重要課題になります。これまでSCMにあった与信管理の仕組みを、Commerceの対象チャネル（Webストア・コールセンター・POSなど）の注文にも適用できるようになります。

B2Bコマースを運用する企業では、注文を受けた際に「この顧客の与信限度額は問題ないか」を確認するプロセスが必要です。以前は、CommerceとSCMで与信ポリシーの適用が分断されており、Commerceチャネルから入った注文については別途確認や手動対応が発生しがちでした。本機能により、Commerceの対象注文に対して、Finance・SCM側の与信管理フレームワークを適用するための標準的な構成が可能になります。与信ポリシーの設定やチャネル構成に応じて、限度額超過時のホールド処理などを組み込めるようになります。

従来のDynamics 365 Commerceでは、与信管理はFinance・SCMの領域の話であり、Commerce注文に対してその標準フレームワークを適用する手段は限られていました。B2Bコマースを運用するにあたって、与信ポリシーをCommerceチャネルに一貫して適用するためにはカスタム対応が必要なケースも多く、実装コストと運用の複雑さにつながっていました。

10.0.48では、標準の与信管理フレームワークがCommerceのすべてのチャネルに拡張されます。与信ポリシーの一元管理が可能になり、CommerceとSCMで整合のとれた与信運用ができるようになります。詳細はMicrosoft Learnのドキュメントを参照してください。

留意点は、与信管理の設定はFinance側で行われるため、CommerceとFinanceの連携設定が前提になる点です。与信限度額・ポリシー・ホールド解除のワークフローなどを事前に整備しておく必要があります。また、B2Cや現金取引には不要な機能ですので、対象チャネルと取引形態を明確にしてから有効化を判断するのが適切です。

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

10.0.48を振り返ると、これらの機能はDynamics 365 Commerceが単独のPOS／ECチャネルにとどまらず、Finance・SCM・顧客データ・外部アプリと連携しながら、企業全体の商取引プロセスを支える方向へ拡張していることを示しています。室長の目線では、「チャネルアプリ」から「エンタープライズコマース基盤」への重心移動が着実に進んでいるように見えます。

クロスLE注文フルフィルメントはFinance・SCMと同じ土俵でCommerceを動かすための機能。与信管理の統合は、B2B取引をCommerceで完結させるための機能。POSのモダナイズとCopilot統合は、店舗接客の「判断の質」を上げるための機能。そして外部アプリとのコンテキスト連携は、Commerceを他システムのハブとして機能させるための機能です。

これらはいずれも、単体のチャネルとしてのCommerceではなく、企業の商取引全体を支える基盤としてのCommerceを目指す方向性を示しています。

派手なUIの刷新や、目を引く新機能が並ぶわけではありません。しかし地道に、確実に、Commerceの土台は広がっています。Dynamics 365 Commerceを評価する軸も、そろそろ「POSやEC機能の数」から、「Finance・SCM・Copilotと連携した商取引プロセス全体の整合性」へ変えていく時期に来ているかもしれません。

次回は、Dynamics 365 Project Operationsです。

Let’s Enjoy our DX365LIFE!