毎月届くアップデートをどう読むか|BC 28.4(2026年8月)と、Dynamics 365製品別リリースサイクルの整理

おはようございます。室長こと、吉島良平(Microsoft MVP for Business Applications | Microsoft Regional Director)です。
日本中が甲子園で盛り上がっています。室長も小学生の頃は、地元で野球をやったり、学校のイベントでソフトボールをやったりしていました。炎天下でボールを追いかけていた記憶がついこの間のように蘇ってきます。
甲子園—全国高校野球選手権大会は、1915年から100年以上続く日本の夏の風物詩です。
その甲子園が近年、試合の時間帯を変えました。猛暑の日中をできるだけ避け、午前と夕方に試合を集中させる運営へのシフトです。選手の熱中症リスクを真剣に受け止めた判断であり、「100年の伝統」と「現代の要求」を両立させた変化です。守るべきものは守りながら、変えるべきところは変える—この姿勢は、テクノロジーの世界にも通じるものがあります。
投手起用も変わりました。昔ながらのエース完投型ではなく、継投をルーティンとして組み込むチームが増えています。勝つためには合理的な判断です。それでも、炎天下の中を一人で投げ抜くエースの姿には、思わず目頭が熱くなります。「変えるべきこと」と「変えてはいけないもの」が同じグラウンドの上に共存している—甲子園はそういう場所に見えてきます。今年の夏も高校球児たちの熱い闘いに、ネット越しから精一杯のエールを送りたいと思います。
実は、Business Centralのマイナーアップデートも、実は同じ構造を持っています。2026年8月3日にリリースされたばかりのBC 28.4は、一見地味なアップデートに映るかもしれません。しかし、Payables AgentのGA(一般提供)化、E-Documentフレームワークへの支払い対応、Peppol電子請求書プレビューの追加—これらは、ERPにおける「業務のやり方」そのものを時代に合わせて変えていく変化です。
今回は、BC 28.4の変更内容を実務の視点でいつもより短くさくっと解説します。
(2026年4月6日から開始したSpotifyのポッドキャストは今回で50回目。いつもお聴きくださり、ありがとうございます!)
Dynamics 365 製品別リリースサイクル—まず「どの製品がいつ更新されるか」を把握する
Dynamics 365のアップデートを追いかける上で、まず理解しておきたいのが製品ごとのリリースサイクルの違いです。BC・Finance/SCM・CRMは、同じDynamics 365ブランドの下にありながら、更新のタイミングと頻度が大きく異なります。
BCは毎月マイナーアップデートが届く、最もアグレッシブなサイクルを持つ製品です。Finance/SCMは四半期に一度の大きなリリース、CRMはWaveを軸に機能が継続的に追加されていきます。同じ「Dynamics 365」でも、追いかけ方はまったく異なります。
今回の記事では、Business Central 28.4(2026年8月)に絞って解説します。Finance/SCMは次のリリース(10.0.49、9月予定)のタイミングで改めて書きます。
| 製品 | 4月 | 5月 | 6月 | 7月 | 8月 ★ | 9月 |
|---|---|---|---|---|---|---|
| 🟦 Business Central | 28.0 GA開始 | 28.1 | 28.2 | 28.3 | ★28.4 | 28.5予定 |
| 🟩 Finance & SCM | 10.0.47 GA開始 | — | 10.0.48 | — | — | 10.0.49予定 |
| 🟪 CRM / Power Platform | Wave1 GA開始 | 継続 | 継続 | 継続 | 継続 | 継続 |
「予定」と記載のバージョンは、執筆時点の公開情報と過去パターンをもとに記載しています。正式リリース時期はMicrosoft公式発表をご確認ください。
Finance/SCMのWave 2対応機能は、Waveの公式開始(10月)より1ヶ月早い9月リリース(10.0.49)に先行して含まれる場合があります。
CRM / Power Platformはバージョン番号による管理ではなく、Wave期間中に機能が継続的に有効化される継続的デリバリー方式を採用しています。
BC 28.4 変更点サマリー
| カテゴリ | 変更内容 | ステータス |
|---|---|---|
| 機能変更 | Payables Agent — 「既知の送信者」機能 | ✅ GA |
| 機能変更 | E-Documentフレームワーク — 支払い連携 | ✅ GA |
| 新機能(プレビュー) | 仕入見積ドラフトでPeppol電子請求書プレビュー | 🔵 PP |
| Good to Know | Field Service連携 — Customer Asset同期の挙動修正 | ⚠ 挙動変更 |
| Good to Know | Copilot & AgentsのAzureジオグラフィ処理変更 | ⚠ 要確認 |
Payables Agent — 「既知の送信者」機能がGA(一般提供)へ
Payables Agent(支払エージェント)は、BCのAI機能の中でも実務直結度が高い機能のひとつです。仕入先からの請求書を自動的に読み取り、支払い処理を補助するエージェントですが、28.4では「既知の送信者(Known Sender)」機能が加わり、GAになりました。

「既知の送信者」とは、過去に処理実績のある仕入先を記憶し、次回以降の処理を高速化する仕組みです。初回はレビューが必要でも、一度処理した送信者からのドキュメントは信頼済みとして扱われるため、エージェントが自動処理できる範囲が広がります。
定期的な取引仕入先が多い企業ほど恩恵が大きい機能です。毎月同じ仕入先から請求書が届く環境では、エージェントの処理精度と速度が大きく向上します。GAになったことで本番環境への適用が安心して行えるようになりました。
E-Documentフレームワーク — 支払い連携がGA(一般提供)へ
E-Documentフレームワークは、BCにおける電子ドキュメント(電子請求書・電子帳票)の送受信を統合的に管理する仕組みです。28.4では、このフレームワーク上で支払い(Payment)との連携がGAになりました。

これにより、受信した電子ドキュメント(たとえばPeppol形式の仕入請求書)を、BCの支払い処理と直接紐づけることができるようになります。従来は「受信→手動確認→支払い登録」という流れが必要でしたが、E-Document経由で受け取ったドキュメントを支払い処理まで一気通貫でつなげる設計が整いました。
アジア各国でE-Invoice(電子インボイス)の義務化が進む中、BCの受信側対応が着実に強化されています。特にPeppolネットワーク経由でB2B取引を行う企業や、シンガポール・マレーシアなどでの展開を考えている場合、このGA化は重要な前提条件となります。
仕入見積ドラフトでPeppol電子請求書プレビュー(パブリックプレビュー)
28.4では、仕入見積のドラフトページ上で、Peppol形式の電子請求書としてどのように出力されるかをプレビューできる機能がパブリックプレビューとして追加されました。

送信前に「この内容でPeppol送信したらどう見えるか」を確認できるため、フォーマットエラーや必須項目の漏れを事前に検知できます。
現時点ではパブリックプレビューです。本番環境での利用は可能ですが、仕様が変更される可能性があります。GA前にテスト環境での動作確認を推奨します。
Field Service連携 — Customer Asset同期の挙動修正(Good to Know)
地味ながら、見落とすと痛い変更です。BCとDynamics 365 Field Serviceを連携している場合、DataverseのCustomer Asset変換設定に関する挙動が修正されました。

これまでは、設定が「No」になっていても、サービス項目(Service Item)が顧客資産(Customer Asset)として同期されてしまうケースがありました。28.4以降は、設定が「Yes」の場合のみ新規同期が行われます。
Field Service連携を利用していて、「意図せずCustomer Assetが増えていた」という経験がある場合、この修正が原因だった可能性があります。なお、既存の連携済みService Itemは今後も引き続き同期されます(設定のYes/Noに関わらず)。この変更の影響を受けるのは28.4以降に新規で発生する同期のみです。既存の運用を壊さずに修正が適用される設計になっています。
Copilot & Agents — Azureジオグラフィ処理の変更(Good to Know)
2026年7月1日以降、一部の国・地域では、BC 28.0以降の環境においてCopilotおよびエージェントのAI推論処理が異なるAzure Geographyで実行される場合があります。

これはデータそのものの移動ではなく、AI推論のリクエスト処理先が変わるものです。Microsoftが Copilot基盤のスケーラビリティと可用性を高めるための対応であり、処理されるGeographyは「Copilot & agent capabilities」ページで確認・管理できます。
金融・官公庁・医療系など、データ処理場所に厳しい要件がある業種では、この設定を明示的に確認しておくことをお勧めします。BC管理者として「どこで処理されているか」を把握しておくことが重要です。
まとめ—「変えるべきことを変える」という一手
甲子園の時間帯変更は、「やらなくても今年の大会は開催できる」改善でした。
しかし、選手の安全と競技の未来を考えれば、必要な変化でした。
BC 28.4も同じです。Payables AgentのGA化もE-Documentの支払い対応も、「なくても業務は回る」かもしれません。
しかし、AI時代のERPを正しく使っていくためには、これらの変化を把握し、自社の業務設計に組み込んでいくことが重要です。
マイナーアップデートは「小さな変化の積み重ね」です。
甲子園が100年かけて変わってきたように、BCも毎月少しずつ、時代に合った姿へと進化しています。
次のWave 2 2026(10月予定)では、より大きな変化が来ます。
その前に、28.4の変更内容を自社環境に照らし合わせて確認しておきましょうね!
それでは、今日はこのくらいで。
Let’s Enjoy our DX365LIFE!
