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

室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。気が付けば、あっという間に3月ですね。3月決算の企業にお勤めの皆様は、いよいよラストスパートですね。体調に留意して、花粉対策をしながら、頑張っていきましょう！

ワールドベースボールクラシックも本格化し、日本代表の試合も始まりました。大谷選手は、いきなりの満塁ホームラン。正直、役者が違うなぁと思いました。山本投手は、肘が若干下がっているように見えて、個人的にちょっと気になりましたが（気のせい？）、今シーズンも日本人選手が、世界の舞台で大活躍する姿を沢山見たいですよね。

そして、今週末はオーストラリアのメルボルンでF1が開催されるようです。当社のお客様であるGeneral Motors（ゼネラルモーターズ）様も参戦されていて、弊社も数名お招きいただき、現地に入って観戦しているようです。こういう時は、仕事を忘れて、思いっきり楽しんで欲しいなと思います。

毎年この時期は、多くのRFI・RFPをいただき、バタバタしておりますが、確定申告もある程度落ち着いてきたので、「大切な事」を書き留める時間としたいと思っています。

ということで、本稿では、『Dynamics 365 Business Central』のUpdate 28.0/Public Preview (≒2026 wave 1)の情報公開に伴い、ユーザー様や、ITベンダー様向けに、いつものような室長の勝手な解釈で、纏めておきたいと思います。現在公開されている情報に基づいた全体像の整理となりますが、本日も最後までお付き合いくださいますと幸いです。

Copilotとか、AIエージェントと聞くと、“またかよ！”と思う方もいらっしゃるとは思うんですよ。確かに、このAI領域以外にも、とても良き改善・改良が数多く含まれているのですが、このアップデートを1行表現するならば、

「AIに仕事を任せるERP」から、「AIの仕事を管理・監督するERP」への進化

という語り方がしっくりきます。『Dynamics 365 Business Central』は何処に向かってるの？と、日本の方々からもよく聞かれるのですが、

「中堅中小企業の業務オペレーションをオーケストレーションするAI基盤」

と私は回答しています。10年後はCRM・ERPは、“主語”として語られる存在ではなくなっているはずです。既に、AIエージェントを、判断と処理のできる一人の業務キーユーザーとして考えなくてはならないステージに入っています。

ポイントは「完全自動化」ではなくて、「責任ある自律化（Responsible AI/Autonomous with Responsibility）」です。何故、そう感じているかというと、

Copilot and Agents（Update 28.0）領域

Update 28.0 におけるCopilot and Agentsの進化は、「AIが裏で自動的に動く存在」から、「AIの仕事を人が可視化し、統制しながら使う存在」へとフェーズが明確に変わった点にあります。これまでのアップデートが、AIに業務を任せられるかどうかの検証に重点を置いていたのに対し、今回のアップデートでは、AIを前提とした業務運用を成立させるための基盤整備が前面に出ているように思います。

その方向性は大きく三つに整理できます。

第一に、エージェントの「仕事の見える化」。どのメールを処理したのか、どのタスクが進行中なのか、そして誰がその業務に関与しているのかが、ユーザーにとって直感的に把握できるようになった。

第二に、人によるレビューや介入を前提としたAI設計。生成されたコンテンツを業務画面上で直接確認できることに加え、必要であればタスクを一括停止できるなど、AIに対する明確なブレーキが標準で用意されました。

第三に、Copilot拡張やエージェント開発を見据えた本格的な基盤整備。Microsoft管理のAIに限定せず、自社のAIリソースを利用できる道を開いたことで、ISVや内製開発を強く意識した構成となっている。

これらを総合すると、Update 28.0のキーワードは「完全自動化」ではなく、「責任ある自律化（Responsible AI）」を明確に志向したアップデートだと感じています。

機能別まとめ

1. Discover emails in the mailbox that have been processed by Payables Agent

＜機能概要＞

Payables Agentが処理したメールを、メールボックス上で識別できるようになった。これにより、AIがどのメールを既に処理したのかを人が明確に把握できる。

＜以前＞

Payables Agentは従来からメールボックスを監視し、請求書メールを自動的に処理していた。ただし、そのメールがすでにAIによって処理済みかどうかは、最終的には人が判断する必要があった。

＜改善＞

処理済みのメールが明示的に識別されることで、二重処理や見落としのリスクを大きく低減できるようになった。

＜利用シーン＞

AP担当者が共有メールボックスを日次で確認する際、未処理メールのみに集中してレビューできる。特に月末や請求書が集中するタイミングにおいて、業務の混乱を抑える効果が期待できる。

＜課題・留意点＞

処理対象はあくまで Payables Agentのスコープ内に限られるため、メール運用（個人メールか共有メールか）を事前に整理しておくことが前提となる。

2. Get item insights with advanced KPIs and Summary

＜機能概要＞

アイテム（商品）に対して、Copilotが高度なKPIとそのサマリーを提示する機能がリリースされる。

＜以前＞

売上、在庫、回転率といった指標は個別のレポートや分析画面で確認できたが、それらの数値をどう解釈するかはユーザー自身に委ねられていた。

＜改善＞

Copilot が複数のKPIを横断的に整理し、状況を文章として要約することで、数値の意味を直感的に把握できるようになった。

＜利用シーン＞

営業や購買担当者がアイテム詳細画面を見ながら即座に判断したり、在庫過多や欠品リスクを早期に察知したりする場面で有効である。マネージャー層の意思決定支援にもつながる。

＜課題・留意点＞

KPIの定義や元データは従来の設定に依存するため、マスタデータの品質が低い場合には、要約の精度もそれに影響される点には注意が必要です。

3. Manage tasks from all agents in dedicated task pane

＜機能概要＞

すべてのAIエージェントのタスクを、専用のタスクペインで一元的に管理できるようになった。

＜以前＞

エージェントごとに個別に状況を確認する必要があり、全体像を把握しづらい状態だった。

＜改善＞

複数エージェントのタスクを横断的に可視化できるようになり、レビュー待ちや人の介入が必要なタスクを即座に把握できる。

＜利用シーン＞

Payables AgentとSales Order Agentを併用している企業や、業務責任者がAIの稼働状況を監督するケースで特に有効である。

＜課題・留意点＞

エージェントの利用が進むほどタスクが増え、情報過多になりやすいため、誰がどのタスクをレビューするのかといった運用ルールの設計が重要になる。

4. Review content generated by agents directly on pages

＜機能概要＞
AIエージェントが生成したコンテンツを、対象となる業務ページ上で直接レビュー・確認できる。

＜以前＞
Copilotペインや別画面で内容を確認する必要があり、業務画面との行き来が発生していた。

＜改善＞
業務画面の文脈を保ったままレビューや修正、承認が行えるようになり、操作が直感的になった。

＜利用シーン＞
請求書ドラフトの確認や、見積・注文文面のレビュー、監査対応時の説明などで効果を発揮する。

＜課題・留意点＞
どこまでを人が確認するのかという線引きを明確にし、権限設計と合わせて検討する必要がある。

ここまでの4機能に共通しているのは、AIが何をしたかを“見える形で業務に戻す”ことに主眼が置かれている点です。

5. Show avatars for record creators and modifiers in lists

＜機能概要＞

レコード一覧に、作成者や更新者のアバターが表示されるようになった。

＜以前＞

作成者や更新者は文字情報として表示されるのみだった。

＜改善＞

誰が関与したレコードなのかを直感的に認識でき、コラボレーションの可視性が向上した。

＜利用シーン＞

問題が発生したレコードの即時エスカレーションや、グローバルチームでの責任所在の把握に役立つ。

＜課題・留意点＞
Microsoft Entra IDとの連携が前提となり、監査用途では従来のログと併用して利用することが望ましい。

6. Stop all active tasks for selected agent

＜機能概要＞

特定のエージェントが実行中のタスクを、一括で停止できる機能である。

＜以前＞

個別タスクへの対応が中心で、緊急時に即座に止める手段は限られていた。

＜改善＞

エージェント単位で即時にブレーキをかけることができ、障害や誤学習による影響を最小限に抑えられる。

＜利用シーン＞

設定ミスに気づいた場合や、想定外のメールが大量に流入した場合など、緊急対応が必要な場面で有効である。

＜課題・留意点＞

停止後の再開手順を事前に整理しておくこと、業務影響を考慮した権限管理が不可欠となる。

7. Use AI resources for your Copilot extensions（Public Preview）

＜機能概要＞

Copilot拡張において、Microsoft管理のAIだけでなく、自社のAIリソースを利用できるようになる（Public Preview）。

＜以前＞

CopilotはMicrosoft提供のAI基盤に依存していた。

＜今回＞

BYO-AI（Bring Your Own AI）が可能となり、ガバナンスやコスト最適化の選択肢が広がった。これは単なる拡張ポイントではなく、Business Centralを企業のAI戦略に組み込むための「入口」を正式に開いたという意味を持つ。

＜利用シーン＞

規制産業でのAI利用、ISVによる差別化されたCopilot開発、既存のAI投資を活用した内製拡張などが想定される。

＜課題・留意点＞

設定や責任範囲が明確にユーザー側に移るため、設計と運用には慎重さが求められる。Preview機能なので、本番適用は段階的に検討すべきであると言えるだろう。

なぜ Microsoftはこの順番でCopilotを進化させているのか

― Update 28.0 に見る戦略的意図の解釈（室長版）

MicrosoftがBusiness CentralにおけるCopilotとAIエージェントを、この順番で進化させていることには明確な理由があるように感じます。2025 Wave 2では、Payables AgentやSales Order Agentを通じて、「AI が業務を代行できる」という事実をまず証明した。これは技術的な実験というより、ユーザーと市場に対する心理的ハードルを下げるフェーズだったと言えるはず。AI は本当に使えるのか、実業務で役に立つのか。その問いに対する答えを、限定された業務領域で示してきた。

しかしMicrosoftは、その次に「自動化範囲の拡大」へは進まなかった。Update 28.0で強化されたのは、AIの賢さではなく、可視性・統制・介入性だった。これは、Copilotが単なる便利機能ではなく、ERPの中核業務を担う存在になることを前提にした設計転換を意味しているように思う。

ERPの世界では、業務が止まること、誤ること、その責任が曖昧になることは許されない。だからこそ Update 28.0では、「AIが何をしたかを把握できる」「止められる」「人がレビューできる」という機能が優先された。これは技術的制約ではなく、業務システムとしての必然だと考えます。

さらに、Copilot extensionsで自社のAIリソースを使える方向性が示された点も重要である。MicrosoftはCopilotを「囲い込む」のではなく、企業の AI 戦略に組み込ませる道を選んだ。これはBusiness Centralを、完成されたERPではなく、業務AIを統合・運用するための基盤として位置づけていることの表れではないだろうか。

この順番は偶然ではないはずだ。① 使えることを示す → ② 任せ続けられる構造を作る → ③ 拡張と統制を可能にする。Update 28.0は、その第二段階を明確に完了させたアップデートだと言えるのではないだろうか。

Update 28.0が示す示唆

― 現場・IT部門・経営それぞれに何をもたらすのか

＜現場（業務ユーザー）への示唆＞
Copilotは「勝手に動くAI」ではなくなった。今回のアップデートにより、現場ユーザーはAIの成果物を理解し、判断する役割にシフトしていく。タスクペインや画面上レビューは、AI を疑うためのものではなく、安心して任せるための道具である。現場に求められるのは入力作業ではなく、「確認し、判断する力」なのだ。

＜IT部門への示唆＞

Update 28.0は、IT部門にとってCopilotを正式に“管轄できる存在”にした。一括停止、タスク可視化、自社 AIリソース利用といった要素は、AIを業務システムとして管理するための最低条件のはずだ。CopilotはPoCの対象ではなく、運用・統制の対象になった。ここから先、IT部門は「AIを止める側」ではなく、「AIを許可する側」になる。

＜経営への示唆＞
Copilot導入の価値は、単なる省力化ではない。Update 28.0が示したのは、人とAIの役割分担を前提にした業務設計が可能になったという事実だ。AIに任せ、人が判断し、責任を持つ。この構造が成立したことで、業務スピードと統制の両立が現実的になってきた。Copilotはコスト削減ツールではなく、組織の意思決定速度を引き上げる基盤として捉える段階に入ったと感じる。

室長の考察｜Copilotは「賢い機能」から「管理される同僚」へ進化した

Dynamics 365 Business CentralにおけるCopilotとAIエージェントは、2025 Wave 2で「業務を自動化できる存在」として明確な第一歩を踏み出した。Payables AgentやSales Order Agent は、メールやドキュメントを起点に、これまで人が担っていた定型業務を代替できることを示した点で大きな意味を持っていた。

一方、Update 28.0（2026 Wave 1）で示されたのは、AIを“使えるかどうか”ではなく、“任せ続けられるかどうか”という次の問いである。今回追加された機能群を見ると、Microsoftが意図しているのは、AIをさらに前に出すことではなく、AIの仕事を人が理解し、制御できる構造を整えることだと分かる。

象徴的なのが、Payables Agentが処理したメールの可視化や、全エージェントのタスクを横断的に管理できる専用タスクペインである。これらは新しい自動化ロジックを増やす機能ではない。しかし、AIが「何をしたのか」「今どこまで進んでいるのか」を明確にし、業務責任者が状況を把握できるという点で、実運用に不可欠な要素だ。

また、生成されたコンテンツを業務画面上で直接レビューできる仕組みや、エージェントのタスクを一括停止できる機能は、AIを前提とした業務における“安全装置”と言える。AI が間違えないことを期待するのではなく、間違えたときに人が介入できる前提で設計されている点が重要だ。

さらに、「Copilot extensionsで自社のAIリソースを利用できる」という方向性は、Business Centralを単なる業務アプリケーションではなく、業務AIを統合・運用するためのプラットフォームへと位置づけ直す動きでもある。これは ISVや内製開発を含め、企業ごとのAI戦略をERPに組み込む余地を広げるものだ。

2025 Wave 2 が「AIに仕事を任せられること」を証明したフェーズだとすれば、Update 28.0は「AIと一緒に働き続けるための前提条件を整えたフェーズ」と言える。Copilotは単に賢くなったのではない。業務の中で“責任を持って使える存在”へと進化した。この変化こそが、Update 28.0の本質のような気がする。

結論｜Business Centralは「AIと働くERP」へ本格的に進化した

Update 28.0が示した Copilot & Agentsの進化は、単なる機能追加ではない。Microsoftは、AIをより賢くすることよりも、業務の中で安心して使い続けられる存在にすることを優先した。可視化、レビュー、停止、統制―これらはすべて、AI を前提とした業務設計に不可欠な要素である。2025 Wave 2で「AIに任せられる」ことを示し、2026 Wave 1で「任せ続けられる構造」を整えた。この順序は、ERPという業務基盤を知り尽くしたMicrosoftならではの現実的なアプローチだと思う。Business Centralは今、AIを使うシステムから、AIと責任を分担しながら働くシステムへと確実に進化してきたと言ってもよいでしょう。

Country and Regional領域―「ローカル制度対応」を“後追い”から“前提条件”へ

序章｜Country and regional機能が意味するもの

Business CentralのCountry and Regional機能は、これまで「特定国向けの細かな追加対応」「グローバル展開時に後から有効化するローカル要件」として扱われることが多い領域でした。しかし Update 28.0（2026 Wave 1）を見ると、この領域の位置づけが少し変わってきているように感じています。

今回の改善は派手ではありませんが、税務・会計・環境規制・電子請求といった“止められない業務”を、より標準的かつ安全に運用するための土台整備に集中しています。AI領域が「任せ続けられる構造」を整えたアップデートだとすれば、Country and regionalは 「どの国でも、安心して使い続けられるERPにするための現実的な対応」と言えるでしょう。

今回はチェコ共和国での対応が中心ですね。Czechia（チェキア）と国際的な呼び名が代わった事を、私も知りませんでした…

機能別まとめ

1. Adjust VAT in local currency on sales documents in Czechia

＜機能概要＞
チェコ（Czechia）において、販売ドキュメント上でVATをローカル通貨建てで調整できるようになりました。

＜以前＞
外貨取引におけるVAT調整は制約が多く、実務上は手動調整や補助的な処理に頼るケースがありました。

＜改善＞
VATをローカル通貨ベースで正確に調整できることで、税務計算と実際の請求内容の乖離を抑えられるようになった。

＜利用シーン＞
• 外貨建て請求が多い企業
• 為替変動の影響を受けやすい販売取引
• 税務監査時の説明負荷軽減

＜課題・留意点＞
為替レートの管理方針や、会計ポリシーとの整合性を事前に整理しておく必要がある。

2. Align VAT periods with Microsoft standards for Czechia

＜機能概要＞

チェコ向けVAT期間の扱いを、Microsoftが定義する標準に合わせて整合させた。

＜以前＞

VAT期間の扱いにローカル差異があり、設定や運用で迷いやすいポイントが存在していた。

＜改善＞

標準化された期間定義により、設定の一貫性と可読性が向上した。

＜利用シーン＞

• 新規導入・再導入時の初期設定
• グローバルテンプレートをベースにした国別展開

＜課題・留意点＞

既存環境では、過去データや運用ルールへの影響を確認した上での適用が必要となる。

3. Change Original Document VAT Date in VAT Entries – Czechia

＜機能概要＞

チェコ向けのVATエントリにおいて、元ドキュメントの VAT日付を変更できるようになった。

＜以前＞

VAT日付はシステム的に固定されやすく、修正が必要な場合には迂回的な対応が必要だった。

＜改善＞

法令や実務に即した形で、VAT日付の調整が可能になった。

＜利用シーン＞

• 請求日と課税日がずれるケース
• 税務当局からの指摘対応
• 修正仕訳を伴う調整業務

＜課題・留意点＞

変更権限の設計と、監査ログの扱いには十分な配慮が必要となる。

4. Get started with clearer user setup controls for Czechia

＜機能概要＞

チェコ向け機能に関する ユーザー設定が、より分かりやすく整理された。

＜以前＞

ローカル機能の有効化や設定が分かりにくく、属人的になりがちだった。

＜改善＞

初期設定時の迷いが減り、設定内容の意図が理解しやすくなった。

＜利用シーン＞

• 新規ユーザーのオンボーディング
• IT 部門による設定引き継ぎ
• グローバルロールアウト時の展開効率化

＜課題・留意点＞

UIが整理されたとはいえ、制度理解そのものは依然として必要である。

5. Transfer journal line descriptions to bank statements

＜機能概要＞

仕訳行の説明（Description）を、銀行取引明細に引き継げるようになった。

＜以前＞

銀行明細と仕訳の突合時に、説明情報が不足しがちだった。

＜改善＞

取引内容の可視性が向上し、照合作業やレビューが容易になった。

＜利用シーン＞

• 銀行勘定調整（Bank Reconciliation）
• 経理レビューや監査対応
• 属人化しがちな入出金管理の標準化

＜課題・留意点＞

説明文の入力ルールを統一しておかないと、情報の質にばらつきが出る可能性がある。

6. Use carbon footprint with OIOUBL e-invoicing format

＜機能概要＞

OIOUBL電子請求フォーマットにおいて、カーボンフットプリント情報を扱えるようになった。

＜以前＞

環境情報は業務データとは分離して管理されることが多かった。

＜改善＞

取引データと環境情報を結びつけて扱えるようになり、サステナビリティ対応の実務に近づいた。

＜利用シーン＞

• 環境規制への対応
• 顧客・取引先からの情報開示要求
• ESG／サステナビリティレポーティングの基礎データ整備

＜課題・留意点＞

データの正確性や算出ロジックは、別途ガバナンス設計が必要となる。

傾向のまとめ｜Country and Regionalが示す方向性

Update 28.0のCountry and Regional領域を俯瞰すると、共通して見えてくるのは「ローカル制度対応を、特別扱いしない」 という姿勢です。
• 税務日付の調整
• VAT 期間の標準化
• 銀行明細との情報連携
• 電子請求と環境情報の統合

これらは派手な新機能ではありません。しかし、どれも業務が止まると困る領域であり、AI以前に “正しく動き続ける” ことが求められる分野です。実はお客様からもお問合せがかなり多くあり、私も税金関係は結構苦戦してきました。

AI 領域で「責任ある自律化」を支える構造を整え、Country and Regional領域で「どの国でも破綻しない業務基盤」を固める。この二つは別物ではなく、同じ方向を向いたアップデートだと感じます。Business Centralは、「どこでも使える ERP」から、「どこでも 使い続けられる 業務基盤」へ。Country and Regional領域の地味だが着実な進化は、その裏付けの一つと言えるのではないでしょうかね。

Development 領域― “AL 開発”を、属人芸から「再現可能な工学」へ

序章｜Update 28.0の開発者体験は、地味だけど「効く」

Business Centralの開発領域って、派手なデモ映えはしないんですよ。でも、開発者・ISV・パートナーの現場にとっては、この手の“摩擦の解消”が一番コストに効く。調べたところUpdate 28.0（2026 wave 1 / public preview）で並んだDevelopmentのトピックは、方向性がとても分かりやすいです。
• 探す（検索）
• 揃える（依存・シンボル）
• つなぐ（MCP / エージェント）
• 測る（ベンチ）
• 実行する（FQN / テスト）
つまり「作る」ことそのものより、作れる状態を“安定運用”するほうへ寄ってきています。AI領域が「任せ続けられる構造」なら、Development領域は 「作り続けられる構造」です。

機能別まとめ

1) AL developers can use semantic search on data and metadata

＜機能概要＞

AL開発者が、データやメタデータに対して セマンティック検索を利用できる。

＜以前＞

検索はキーワード一致に依存しがちで、「言葉が違う」「呼び名が違う」だけで目的物に辿り着けないことがありました。

＜改善＞

“意味で探せる”方向に寄ることで、オブジェクト探索や影響範囲把握の初速が上がる。

＜利用シーン＞

• 大規模拡張で「似た概念が多い」環境での設計・保守
• 新任メンバーのオンボーディング（用語の壁を越える）
• テーブル/ページ/APIの当たりを付ける探索作業

＜課題・留意点＞

セマンティック検索は“魔法の正解”ではなく、検索対象（データ／メタデータ）の整備や命名の質に影響される。機能自体は「使える」としか明記されていないため、挙動の詳細は今後のドキュメント拡充待ちかな。

2) Download symbols from NuGet feed（Public Preview）

＜機能概要＞

AL 開発で必要なsymbol packages（シンボル）をNuGetフィードから取得できる。

＜以前＞

シンボル取得は環境（Docker / Sandbox）に依存しやすく、依存関係のあるアプリのシンボル入手も“手配”が発生しやすかった。

＜改善＞

Microsoftのpublic NuGet feedを通じて、外部依存（AppSource等）を含むシンボル取得の摩擦を減らす方向が明確になった。

＜利用シーン＞

• ISVが複数アプリ依存の上に拡張を積むケース
• リージョン別（w1/us/de…）でシンボル差分を扱うケース（ローカライズ考慮）
• CI/CD（AL-Go等）で“自動で依存を揃える”運用を作りたいケース

＜課題・留意点＞

Public Previewなので、本番運用にいきなり寄せるより、段階導入（Sandbox で検証→適用）が妥当かな。また、何でもかんでも自由になるというより「依存の入手経路が標準化される」方向性と捉えるのが安全ですね。

3) Enable Troubleshooting MCP Server for AL（Public Preview）

＜機能概要＞

AL向けに、MCP Server関連の トラブルシューティング機能を有効化できる。

＜以前＞

MCP Serverは「繋がる／繋がらない」「権限」「公開API範囲」など、運用時の切り分けが難しくなりやすい領域だった（特に Agentを絡めると）。MCP Server自体は、エージェントがBC環境のAPIとやり取りするための仕組みとして説明されている。

＜改善＞

“TroubleshootingをEnableする”という項目が並んだ時点で、Microsoft側もMCPを業務運用の対象として捉え始めたことが読み取れる。

＜利用シーン＞

• Copilot Studio等のエージェントとBCを接続し始めた段階の切り分け
• MCP構成変更（公開API/ 操作許可）の検証時の原因追跡

＜課題・留意点＞

現時点の一次情報（Update 28.0一覧）では「Troubleshootingの中身（何が見える／何を出す）」までは明記されていません。MCPを“運用する前提”の整備が入った感じですかね。

4) Evaluate AL coding agents with BC-Bench（General availability）

＜機能概要＞

BC-Benchを使って AL coding agentsを評価できる。

＜以前＞

AIコーディングは“便利さ”が先行し、品質や再現性の評価が属人的になりがちだった（= 使う人のスキルで印象が変わるイメージ）。

＜改善＞

「評価できる」ことが機能として明示されたのは大きい。AIを導入する側が、測定軸を持てる方向に寄ったということ。

＜利用シーン＞

• パートナー/ISVが「どのエージェント（または設定）が自社開発に合うか」を比較したい
• AI活用の社内ガイドライン（品質基準）を作りたい
• 変更前後で“悪化していない”ことを担保したい（回帰の観点）

＜課題・留意点＞

一覧以外の一次情報がここでは不足しているため、不明としておきます。

5) Run AL objects and open record references using fully qualified names（Public Preview）

＜機能概要＞

ALオブジェクト実行やRecordRefのオープンで、Fully Qualified Names（完全修飾名）を使える。

＜以前＞

名前衝突（同名オブジェクト）や拡張の増加により、「どれを指しているのか」が曖昧になりやすく、運用規模が大きいほど“地味な事故”の温床になりがちだった。

＜改善＞

名前空間＋完全修飾名で参照できることで、参照の曖昧さが減り、意図がコードに残る。実際にAL 17.0では、Codeunit.Run / Page.Run / Report.Run / RecordRef.Openなどが完全修飾名で扱える方向が紹介されています。

＜利用シーン＞

• 複数拡張が並ぶ大規模環境（特にISV+ 内製が混在）
• 共通テンプレートを多国展開し、国別拡張が増える環境
• “実行対象を間違えない”ことが重要な運用系ユーティリティ

＜課題・留意点＞

Public Previewなので、既存資産の移行（置換）を一気にやるより、新規コードから適用し、効果が出る部分から寄せるのが現実的ですね。

6) Run AL Tests from Visual Studio Code（Public Preview）

＜機能概要＞

Visual Studio CodeからAL Testsを実行できる。

＜以前＞

テストは「書く」ことより「回す」ことがボトルネックになりがちで、IDEから一気通貫で流れないと運用に乗りにくいイメージ。

＜改善＞

“VS Codeから実行できる”方向性が明示されたことで、テストが 開発の外付け作業ではなく、日常操作に寄る。

＜利用シーン＞

• CIの前段階として、開発者がローカルで短いループを回したい
• 回帰テストを“面倒だからやらない”状態から脱却したい
• テスト文化をチームに根付かせたい（特に多国・多人チーム）

＜課題・留意点＞

Public Previewなので、プロジェクト標準プロセスに組み込む場合は、まず Sandbox/ 検証環境から段階的に。コミュニティ側にはVS CodeでALテストを支援する拡張も存在しますが、今回の項目はMicrosoftのUpdate 28.0の“公式方向性”として見ておくのがよいでしょうね。

傾向のまとめ｜開発領域のキーワードは「測れる・揃う・迷わない」

Development領域を俯瞰すると、Update 28.0がやっていることはシンプルです。

1. 探せる（セマンティック検索）
2. 揃えられる（NuGetでsymbolsを取得）
3. つなげて運用できる（MCPのtroubleshooting）
4. 測れる（BC-Benchでcoding agentsを評価）
5. 迷わない（Fully Qualified Namesで参照が明確）
6. 回せる（VS Codeからテスト実行）

要するに、開発を“職人芸”から“再現可能な生産システム”へ寄せているんですよね。

AI がコードを書く時代だからこそ、
• 依存を揃える
• 参照を明確にする
• テストを回す
• 評価指標を持つ

という“地味なインフラ”が重要になる。Update 28.0のDevelopmentは、その現実をちゃんと踏まえたアップデートだと感じました。

Copilotが賢くなるほど、開発は楽になるとは限らない。楽になるのは、“揃えて、測って、回す”仕組みがあってこそですからね。Update 28.0のDevelopmentは、その前提条件を静かに揃えにきたイメージです。こういう改善、個人的にとても好きです。

ちなみに…今回の Update 28.0 でFeature Management自体に目新しさはありません。新しい画面や新機能が追加された、という類の話ではないからです。ただし一方で、「Feature Managementを見ずにアップデートする」ことが、現実的にリスクになってきたという意味では、大きな転換点だと感じています。Optionalとして提供されてきた機能が、次のメジャーバージョンで前提条件になるケースが増えており、開発者や ISV にとっては「コードを書く前に、どの機能が有効になっているかを把握する」ことが、もはや作法ではなく必須事項になりつつあります。念の為に、補足をいれておきますね。

Ecommerce領域―Business Centralを「裏方のERP」から「コマース中枢」へ

序章｜Shopify 連携は“機能追加”のフェーズを越えた

Business CentralとShopifyの連携は、ここ数リリースで一気に存在感を増してきました。単なる「受注データの連携」や「商品マスタの同期」ではなく、コマース運営の現実にどこまで寄り添えるかというフェーズに入ってきたように感じます。Update 28.0（2026 Wave 1）のEcommerce領域を見ると、追加されているのは派手な新機能ではありません。

しかし、
• 商品の持ち方
• バリエーション管理
• 通貨と会計の整合
• コネクタの継続的進化

といった “現場で必ず詰まるポイント”に、かなり正面から手を入れてきたように思えます。

機能別まとめ

1. Assign custom collections to items exported to Shopify

＜機能概要＞

Business CentralからShopifyにエクスポートする商品に対して、カスタムコレクションを割り当てられるようになった。

＜以前＞

Shopify側でのコレクション管理と、BC側の商品管理が分断されがちで、二重管理や手作業が発生しやすかった。

＜改善＞

商品マスタの延長として、「どのコレクションに属する商品か」までをERP側で管理できるようになった。

＜利用シーン＞

• 商品カテゴリや特集単位でのストア運営
• 多店舗・多ブランド展開での整理
• マーケティング施策と商品管理の連動

＜課題・留意点＞

コレクション設計そのもの（命名規則・粒度）が整理されていないと、ERP側に持ち込んでも混乱を招く可能性があるので気をつけましょう。

2. Export items to Shopify with product options based on item attributes

＜機能概要＞

Business CentralのItem Attributesをもとに、Shopify側の商品オプションを生成・エクスポートできる。

＜以前＞

サイズ・色・仕様といったオプション管理は、Shopify側での調整や拡張に頼るケースが多かった。

＜改善＞

ERPの商品属性定義が、そのままコマースの表現に直結する構造になった。

＜利用シーン＞

• バリエーションが多い商材（アパレル、部品、消耗品）
• B2B/B2C混在での属性管理
• 商品マスタを「単なるコード管理」から脱却したいケース

＜課題・留意点＞

Item Attributesの設計が曖昧だと、Shopify側の表示や購入体験に影響が出るため、マスタ設計の責任範囲がより重要になりますね。気配りしておきましょう。

3. Sync images of product variants between Business Central and Shopify

＜機能概要＞

商品バリアント（バリエーション）ごとの 画像をBusiness CentralとShopify間で同期できる。

＜以前＞

画像管理はShopify側に寄りがちで、BC側では「見ない前提」になることも多かった。

＜改善＞

ERP側でも、どのバリエーションにどの画像が紐づくかを意識した管理が可能になった。

＜利用シーン＞

• 色・仕様ごとに画像が異なる商品
• 海外拠点・委託先との商品情報共有
• 品質・ブランド管理を重視する企業

＜課題・留意点＞

画像データは容量・更新頻度ともに負荷が高いため、運用ルール（どこを正とするか）の整理を徹底しましょう！

4. Use checkout currency when you create sales documents from Shopify orders

＜機能概要＞

Shopifyのチェックアウト通貨を、そのままBCの販売ドキュメントに反映できる。

＜以前＞

通貨変換や表示通貨の違いにより、金額差異や確認作業が発生しやすかった。

＜改善＞

コマース側の実態と、会計・販売管理の整合性が大きく向上した。

＜利用シーン＞

• 多通貨・越境EC
• 為替変動が頻繁な市場
• 月次締め・監査対応の効率化

＜課題・留意点＞

会計ポリシー（基準通貨・換算タイミング）との整合は、従来以上に明確にしておく必要がありますね。

5. Use the latest update for the Shopify Connector

＜機能概要＞

Business CentralのShopify Connectorを最新バージョンに更新。

＜以前＞

コネクタ更新は「いつの間にか溜まっている」存在になりがちだった。

＜改善＞

この項目が明示されていること自体が、Shopify連携を“継続進化する前提機能”として扱っていることの表れですね。

＜利用シーン＞

• Shopify API側の変更追随
• 新機能（属性・画像・通貨）の安定利用
• 長期運用を前提としたEC基盤

＜課題・留意点＞

コネクタ更新は、周辺カスタマイズや運用フローへの影響を伴うため、Sandboxでの事前検証を必須にしたほうがいいですね。

傾向のまとめ｜Ecommerce領域が示す方向性

Update 28.0のEcommerce領域を俯瞰すると、Microsoftが狙っているのは明確です。

Business Centralを「ECの後処理システム」にしない。商品属性、画像、コレクション、通貨。これらは本来、コマース体験の中核にある要素です。それを ERP側に引き寄せてきたということは、BCを“コマースの中枢データ基盤”として使ってほしいというメッセージでもあります。

AIが判断を支え、ERPが統制を担い、ECはその“結果を顧客に届ける窓口”になる。Update 28.0のEcommerce改善は、Business Centralがその役割を本気で取りに来たことを示しているように思いますね。

Electronic Documents 領域― 電子文書を「添付ファイル」から「業務フローの中核」へ

序章｜電子文書は、もはや“外部連携”ではない

Business CentralにおけるElectronic documents（e-documents）は、ここ数年で立ち位置が大きく変わってきました。当初は「国別要件への対応」や「外部サービスとの接続点」という色合いが強かったのですが、現在は 購買・会計プロセスそのものを成立させる前提要素になりつつありますね。

Update 28.0（2026 Wave 1）で追加されるe-documents関連の改善は、派手さはありません。しかし、“受け取った電子文書を、どう業務に結び付けるか”という一点に、非常に現実的な改善が入っています。

機能別まとめ

1. Link Inbound e-documents to Purchase Invoices

＜機能概要＞

受信したインバウンドe-documentを、購買請求書（Purchase Invoice）に直接リンクできるようになった。

＜以前＞

電子請求書を受信しても、実際の購買請求書との紐付けは手作業や運用ルールに依存しがちだった。

＜改善＞

電子文書が “参考情報”ではなく、購買処理の正式な構成要素として扱えるようになった。

＜利用シーン＞

• 電子請求書（PEPPOL等）を日常的に受信する企業
• 監査・証跡を重視する経理部門
• AP 業務の自動化・標準化を進めたいケース

＜課題・留意点＞

リンクルール（どの条件で紐付けるか）や例外処理は、業務設計として整理しておく必要がありますね。コンサルの皆さん、気をつけましょうね！

2. Set up Service Participants to Company Information

＜機能概要＞

e-documentsに関わるService Participantsを、Company Informationに紐付けて設定できる。

＜以前＞

サービス参加者（送信者／受信者情報など）の設定が分散し、環境移行や引き継ぎ時に分かりにくいケースがあった。

＜改善＞

会社情報を起点に、電子文書に関わる主体情報を一元管理できるようになった。

＜利用シーン＞

• 複数の電子文書サービスを併用している企業
• 拠点追加・法人追加を頻繁に行うグループ企業
• 設定の属人化を避けたいIT／業務部門

＜課題・留意点＞

Company Informationは他機能でも参照されるため、変更時の影響範囲を把握した上で運用していきましょう。

3. Set a default e-document type on vendor templates

＜機能概要＞

仕入先テンプレート（Vendor Templates）に、デフォルトのe-documentタイプを設定できる。

＜以前＞

仕入先ごとに電子文書の扱いが異なる場合、運用ルールや注意喚起に頼る部分が多かった。

＜改善＞

テンプレート段階でe-documentの前提を持たせることで、取引開始時点からブレのない運用が可能になった。

＜利用シーン＞

• 新規仕入先のオンボーディング
• 電子請求／紙請求が混在する環境
• グローバルで共通テンプレートを使うケース

＜課題・留意点＞

既存仕入先への影響は限定的だが、テンプレート運用が形骸化している環境では見直しが必要。

傾向のまとめ｜Electronic Documentsが示す方向性

Update 28.0のElectronic documents領域を俯瞰すると、Microsoftが目指しているのは明確です。電子文書を「外から来るデータ」ではなく、「業務プロセスの一部」として扱う。インバウンド文書を請求書に直接リンクし、主体情報を会社情報に集約し、仕入先テンプレートで前提条件を定義する。これらはすべて、電子文書を“例外処理”から“標準処理”に引き上げるための改善だと言えます。

AIが請求書を読み取り、ERPが正しい業務フローに乗せ、人が確認と判断を行う。Electronic documents領域の進化は、Copilot & Agentsの流れとも自然につながっており、「電子文書ありきの業務設計」が、もはや特別ではなくなったことを示しているように感じますね。

Financial Management領域― 財務・税務を「計算するERP」から「前提条件を内包するERP」へ

序章｜財務機能は“国別要件”から逃げられない

Financial Managementは、Business Centralの中でも最も 「後回しにできない」領域です。税制、源泉、自己請求、これらは業務効率以前に、守らなければ止まる要件だからです。
Update 28.0（2026 Wave 1）のFinancial Managementを見ると、新しい分析機能や派手なUI改善はありません。代わりに入っているのは、各国・各取引形態で“必ず必要になる計算と責任分界点”を、ERP側で明示的に扱うための改善です。

機能別まとめ

1. Calculate taxes for plastic and sugar

＜機能概要＞

プラスチック税や砂糖税といった、特定物品に対する税金を計算できるようになった。

＜以前＞

これらの税は、外部計算や補助的な仕訳、あるいは業務ルールで吸収されることが多かった。

＜改善＞

物品レベルで課税対象を扱えるようになり、財務・在庫・販売データが同じ前提条件で結び付くようになった。

＜利用シーン＞

• 環境税・健康関連税が適用される国・地域
• サステナビリティ報告や規制対応が求められる業種
• 税計算を“後工程”に回したくない企業

＜課題・留意点＞

課税対象や税率は国・時期によって変わるため、マスタ管理と法令アップデートの責任分界を明確にしておく必要があります。あと、新たな転記グループが生まれてくるはず。少しにおうので、後続で纏めます。

2. Calculate Withholding Taxes for Vendors

＜機能概要＞

仕入先に対する 源泉税（Withholding Tax）をBusiness Central上で計算できる。

＜以前＞

源泉税は国別・取引別の差異が大きく、外部計算やカスタマイズに頼るケースが多かった。

＜改善＞

ERP標準で源泉税計算を扱えるようになり、支払・仕訳・税務報告までの一貫性が高まった。

＜利用シーン＞

• フリーランス・個人事業主との取引
• クロスボーダー取引や役務提供
• 税務監査時の説明負荷軽減

＜課題・留意点＞

源泉税の適用条件は非常に複雑なため、すべてを自動化できるわけではない。例外処理やレビュー前提の設計が必要となる。米国では1099があったり、アセアンでもタイやベトナムのパートナー等は、源泉税の計算ロジックを自社開発している状況なので、本機能のインパクトは結構大きいと考えます。

3. Use self-billed invoices

＜機能概要＞

自己請求書（Self-billed invoices）を Business Centralで扱えるようになった。

＜以前＞

自己請求は、業務上は存在していても、ERP上では例外扱いになりがちだった。

＜改善＞

自己請求を正式な取引パターンとして扱えるようになり、会計処理と実態取引の乖離を減らせる。

＜利用シーン＞

• 農業・物流・プラットフォーム型ビジネス
• 取引先が請求書を発行しない取引形態
• 税務・監査要件が厳しい業界

＜課題・留意点＞

自己請求は税務責任の所在が明確でないとリスクになるため、業務ルールと権限設計の整理が不可欠です。特にインセンティブやロイヤリティ等の計算には使えますね。

傾向のまとめ（厚め）｜Update 28.0 が Finance に持ち込んだ「税の再定義」

結論から言うと、プラスチック税・砂糖税と源泉税（Withholding Tax）は、Update 28.0において「同じ思想のもとで再設計された税カテゴリ」だと読み取れます。もちろん、計算ロジックや設定項目が同一、という意味ではありません。あくまで「ERPが税をどう理解するか」という設計思想の共通点です。今回ここが大きいのは、MicrosoftがFinance領域で「税」を“金額に税率を掛けて計算するだけの結果”から、“取引の成立条件として最初から存在する前提”へと引き上げ始めた点にあります。ERPの税対応の質が、ひとつ段階上がった、と言ってよいでしょう。

Self-billed invoiceは「請求書を楽にする機能」ではありません。取引金額を最も正確に把握している側が、責任を持って請求書を発行するための仕組みです。源泉税や実績課金が当たり前になりつつある今、Self-billingは例外ではなく、むしろ合理的な取引形態になりつつあります。

この領域は、ちょっと深掘っておきます。

1) 公式に読み取れる共通点（事実）

1⃣ VATの延長ではなく「独立した税」として扱われている

Update 28.0の機能一覧上、「Calculate taxes for plastic and sugar」「Calculate withholding taxes for vendors」は、どちらもFinancial Managementの機能として並列に置かれています。VAT（付加価値税、日本では消費税）や VAT Product Posting Groupの拡張とは明記されていません。 特に源泉税は、公開されている情報からもVATとは別の枠組みとして整理されていることが見て取れます。具体的には、源泉税のために、「Withholding Tax Bus. Posting Group / Prod. Posting Group」「Withholding Tax Posting Setup」「Withholding Tax Entries」といった専用構造を持つことが、紹介記事で明示されています。 これは「VATの仕組みを流用した」というより、“VATとは性質が違う税”をERPが理解する構造を正式に持った、という意味合いが強いです。

2⃣税の発生タイミングと責任主体が「取引当事者と一致していない」

ここが一番重要です。VATは比較的「取引金額（課税標準）×税率」で語れますが、プラスチック税・砂糖税（物品税系）と源泉税は、そもそも税の性質が違う。

物品税（Excise）は、重量・数量・含有量（例：Sugar Content）など、金額ではない“物品特性”を基礎にする計算モデルを取り得ることが、Microsoftの公開情報として明記されています。

源泉税は、支払者が税を差し引き、税務当局へ納付する責任を持つ（= 支払者側が主体になる）税であり、BC 28.0の紹介でも、差し引き額が負債（Payable）として計上される流れが説明されています。

つまり両者とも、「請求書金額＝そのまま税額計算のベース」にならない、という共通性を持っています。

3⃣仕訳が “売上税／仕入税” に混ざらない（＝責任の見える化）

源泉税については公開情報上、「ベンダーへの支払は税引後」「差し引いた税額は Withholding Tax Payable（負債） などの勘定に計上」「VATとは別エントリとして管理」という整理が確認できます。 これは、税務責任の所在（誰が納付するのか）を、仕訳と台帳の構造で表現したという意味で非常に大きいです。物品税（プラスチック税・砂糖税）も同様に、VATの枠に押し込めずに扱う方向性が、公開されている “Excise税計算フレームワーク” の記述から読み取れます。

2) 室長視点の解釈｜なぜこれが「大きな転換点」なのか

共通点A：「税を“計算結果”ではなく、“前提条件”として扱い始めた」

VATは、どうしても「結果」の税です。請求書を切って、金額が決まって、税率を掛ける。しかし物品税・源泉税は、取引が成立した瞬間に“責任構造”が決まる税です。

『物品税』は「何を」「どれだけ」扱ったか（重量・数量・含有量など）が本質になる。
『源泉税』は「誰が」「誰に」支払うか（支払者が預かり納付する）という責任分解が本質になる。

MicrosoftはUpdate 28.0で、こうした税を“あとで調整する対象”ではなく、取引の性質として ERPが理解すべき情報に格上げした、と私は見ています。

共通点B：「AIに任せる前提として、ERP側で“税の意味”を定義した」

CopilotやAIエージェントが、購買・支払・仕訳を扱う段階に入るほど、税がVATの枠に混ざっている状態は危険になります。なぜならAIは「この税は誰の責任か」「どのタイミングで確定するか」を誤解しやすいからです。源泉税でPayableを明確に分ける、物品税で重量・含有量ベースを扱えるフレームを持つ。これは、AIを使うための“会計前提の整備”でもあります。

共通点C：「国別要件を“例外”として扱うのをやめた」

源泉税も、環境・健康系の物品税も、多くの企業では「国別の面倒な要件」として、カスタマイズや手作業で吸収されがちでした。しかし今回、Update 28.0のFinancial Managementに 正規機能として明示されたことで、ローカル税制は周辺ではなく中心に置かれ始めた、と言えます。

3) ベンダー側（会計コンサル／ISV）にとってのメリットが大きい理由

“税の責任構造”を標準機能で表現できる：源泉税のように、差し引きと Payableを別建てで扱えるのは、会計設計と監査対応の説明が圧倒的に楽になります。

フレームワーク化の余地：物品税計算が、重量・数量・含有量など複数モデルを取り得るフレームとして説明されている点は、国別に違う税を“共通設計”でまとめる足掛かりになります。

カスタムの論点が変わる：「税計算そのものを自作する」から、「どの税タイプをどの品目・取引に適用するか」「例外をどう扱うか」へ。コンサルの価値が、実装から設計・統制へ移る。

4) ユーザー側（経理・IT）にとってのメリットが大きい理由

監査・説明責任が取りやすい：源泉税は、税引後支払とPayableの構造で説明できる。取引の説明が“仕訳の見た目”に直結するのは大きい。

業務の例外処理が減る：物品税や源泉税は、Excelで後調整しがちな領域。ERP側で枠があるだけで、締め処理の事故率が落ちます。

AI活用の前提が整う：AIに任せるほど、税の誤解がリスクになる。今回の “税を独立概念として持つ” 方向性は、AI時代の財務統制に直結します。

おまけ｜Update 28.0 が Finance に持ち込んだ本質的な変化

プラスチック税・砂糖税と源泉税は、一見するとまったく別の制度に見えます。しかし Update 28.0を通して眺めてみると、どちらも 「VATでは説明できない税を、ERPが正しく理解する」 ための、同じ思想の延長線上にあるように感じます。Microsoftは、税を単なる “計算する対象” から、“取引が成立する前提条件” へと引き上げ始めたのではないでしょうか。

ここで重要なのは、税そのものだけではありません。同じ文脈の中に Use self-billed invoices（自己請求書） が置かれている点も、非常に示唆的です。Self‑billed invoiceは、請求書発行の省力化機能ではありません。取引金額を最も正確に把握している側が、その前提条件（税・控除・責任）を含めて取引を確定させる ための仕組みです。実績ベース課金、源泉税控除、物品特性に基づく課税など、VATだけでは整理できない取引が増えるほど、請求書は「後追いの帳票」では成立しなくなります。

物品税（プラスチック税・砂糖税）は、金額ではなく 重量・数量・含有量 といった取引特性を前提に持つ税であり、源泉税は、売り手ではなく 支払者が税務責任を負う税であり、Self‑billed invoiceは、その前提条件を 請求書という取引確定点に持ち込むための手段 です。

この3つを並べて見ると、Update 28.0の Financeが目指している方向は明確です。「税と請求を、後工程の調整ではなく、取引設計そのものに戻す」 ということです。

Financeのアップデートは派手ではありません。しかし、“見えない税の例外”や“請求と税のねじれ”を、標準機能で見える化することは、運用と監査のコストを確実に下げます。Self‑billed invoice、源泉税、物品税は、そのための別々の機能ではなく、同じ問題意識に対する異なる解法です。AI時代のERPに本当に必要なのは、賢さよりも 前提条件の正しさ。Update 28.0のFinanceは、その土台を静かに、しかし確実に固めに来たアップデートだと感じます。

Governance and Administration―「守りの管理」から「AI 時代の統制基盤」へ

序章｜Governanceは“目立たないが、最も戦略的”

Governance and Administrationのアップデートは、機能一覧だけを見ると地味に見えます。しかし、Update 28.0を俯瞰すると、ここで手が入っているのは 「AI と自動化を前提にした統制の再設計」 です。AIエージェントが業務を実行し、環境がクラウド前提になり、データ量とコストが可視化される。そうした世界で必要なのは、「管理者が頑張る運用」ではなく、システムが前提として守るガバナンスです。

機能別まとめ

1. Audit user and group permissions across apps（Permissions Overview Page）

＜機能概要＞

インストールされている すべてのアプリ／拡張を横断して、ユーザー・グループの権限を一元的に可視化できる「Permissions Overview」ページが追加されました。

＜以前＞

• 権限はアプリごと・拡張ごとに分散
• 「誰が、どこまでアクセスできるか」を把握するには複数画面を行き来する必要があった

＜改善＞

• 権限セットを横断ビュー で確認
• 特定オブジェクトに「どの権限セットが効いているか」を即座に特定可能
• セキュリティグループ／ユーザーとの紐付けも同一画面で把握

＜利用シーン＞

内部監査・IT統制（J‑SOX / SOX）対応→ 「誰が、どの業務データにアクセス可能か」を横断的に棚卸しする必要がある場面

権限設計の見直し・ロール再定義→ 部署異動や業務変更後に、不要な権限が残っていないかを確認

AIエージェント導入前の事前チェック→ 自動処理・エージェントがどの権限セットで動くのかを人が説明できる状態にする

ISVアプリ導入時の影響確認→ 新しい拡張機能が、どの標準オブジェクトにアクセスしているかを即座に把握

＜課題・留意点＞

可視化されたからといって 自動的に権限が最適化されるわけではない

権限棚卸しを「一度きり」にせず、定期的な運用ルールとセットで考える必要がある

ISVアプリ側の設計品質（過剰権限）までは、この機能単体では是正できない

これは単なる UI改善ではありません。AIエージェントや自動処理が「どの権限で動いているか」を、人が説明できる状態にしたという点が重要です。

2. Connect AI agents to the Admin Center through MCP server

＜機能概要＞

Model Context Protocol（MCP）サーバーを通じて、AIエージェントがBusiness Central（および Admin Center）と安全に連携できるようになります。

＜ポイント＞

• MCPはAIと業務システムをつなぐための標準プロトコル
• Business Central側で公開するAPI・操作を 明示的に制御
• 既定では 読み取り専用、書き込みは管理者が許可した場合に限定

＜利用シーン＞

AIエージェントによる運用自動化の検討・PoC→「環境情報の取得」「状態確認」など、読み取り中心の業務を安全に委譲

管理系AIの段階的導入→ まずは Read Only、必要に応じて限定的にWriteを許可する段階導入

IT管理部門の負荷軽減→ 環境状況確認や定型的な管理操作を、対話型AI経由で実行

AI統制ルールの明文化→「どこまでAIに任せ、どこから人が判断するか」を技術的に担保

＜課題・留意点＞

MCP自体は “つなぐ仕組み”であり、業務判断を代替するものではない

書き込み操作を許可する場合、権限設計と責任分界を事前に整理する必要がある

「何でもAIに任せられる」と誤解した導入は、逆にリスクを高める

AIが環境管理や運用に関与する時代において、

• どこまで操作できるか
• どの操作を許可するか
• 誰の責任で実行されるか

を 技術的に縛れる仕組みが必要だから登場した感じですね。これは「AIを賢くする」機能ではなく、AIを“勝手に動かさない”ための統制機構です。

3. Manage database index usage and cost per company

＜機能概要＞

Business Central Admin Center 通じて、データベース使用量やコストを、環境・会社単位で把握・管理できるようになります。

＜背景＞

• SaaS化により、データ量＝コストが明確になった
• 拠点・会社・環境ごとに「誰がどれだけ使っているか」が問われる

＜改善＞

• 「なんとなく増えているDBサイズ」からの脱却
• データ増加を ガバナンスとコストの文脈で説明可能 に
• IT管理ではなく、経営管理の一部として扱える

＜利用シーン＞

グループ会社・複数会社運用→会社単位でのデータ使用量を可視化し、コスト配賦の根拠を明確化

海外拠点・新会社立ち上げ後のモニタリング→想定以上にデータが増えていないかを早期に検知

クラウドコストレビュー（FinOps）→IT部門だけでなく、経営・管理会計の文脈でデータコストを説明

不要データ整理・アーカイブ判断→どの会社・業務がデータ肥大化の要因かを特定

＜課題・留意点＞

可視化できても、削除・整理の意思決定は業務側に委ねられる

履歴保持・監査要件とのバランス設計が不可欠

コスト削減を目的にしすぎると、業務要件と衝突する可能性がある

Dynamics 365 Finance and SCM的な視点をBCの管理画面に持ち込んだ、とも言えますね。

4. Migrate to the cloud from any SQL database

＜機能概要＞

Business Centralのクラウド移行機能が拡張され、任意の SQLベースシステムからの移行を、標準フレームワークで実装可能になりました。

＜以前＞

• BC/GP/SLなど「想定された製品」からの移行が中心
• レガシーSQLシステムは個別対応・スクリプト頼み

＜改善＞

• 汎用的な移行エンジンをAL拡張として実装
• Cloud Migrationウィザードに統合
• ISV・パートナーが再利用可能な移行ソリューションを開発可能

＜利用シーン＞

BC以外のレガシー基幹システムからの移行→業界特化・自社開発SQLシステムを段階的にクラウドへ移行

ISV・パートナーによるテンプレート化移行→同種案件を「毎回スクラッチせず」に再利用可能な移行エンジンで対応

監査・検証を意識した移行プロジェクト→移行ルール・結果・エラーを標準UIで追跡

将来の追加移行・再移行への備え→一度きりで終わらない、再現可能な移行プロセスとして保持

＜課題・留意点＞

フレームワークがあっても、業務データの意味付けは人が設計する必要がある

移行＝業務改革になるため、ITだけで完結しない

移行後の運用・データ統制まで含めた設計が重要

ガバナンスの観点では、移行を「一度きりのプロジェクト」ではなく、再現可能で監査可能なプロセスに引き上げた点が大きい。

傾向のまとめ｜Governance が示す方向性

Update 28.0のGovernance and administrationを通して見えてくるのは、明確な方向性です。

「人が管理する ERP」から、「前提条件をシステムが守る ERP」へ
• 権限は横断的に可視化され
• AIはMCPという“檻”の中で動き
• データ量とコストは経営文脈で語られ
• クラウド移行は属人技ではなく標準プロセスになる

これはすべて、AIと自動化が“当たり前になる前提”でのガバナンス再設計です。Governanceのアップデートは派手ではありません。しかし、後から事故を防ぐ力は、最も大きい領域です。AIエージェントが業務を実行し、環境が増え、データが膨らむほど、「何を許し、何を許さないか」を最初から決めておく必要があります。Update 28.0のGovernanceは、そのための 静かな基礎工事だと感じます。いやぁ、いいところに神の手が入りましたね！

Productive with Microsoft 365―Stay in flow of work with updated Outlook integration

序章｜「ERPを開かない一日」を前提にする

多くの業務ユーザーは、一日中ERPを開いているわけではありません。現実には、Outlook（メール）こそが業務の起点になっています。
• 見積依頼はメールで届き
• 請求や支払の問い合わせもメール
• 納期調整や条件変更もメール

Update 28.0のOutlook連携は、「Outlook からERPに行く」体験を改善したのではなく、「Outlookから離れない」ことを前提にERPを再配置したアップデートだと捉えるのが自然でしょう。

機能まとめ

＜以前＞

• メールを読んだあと、Business Centralを開いて情報を探す必要があった
• ERPの情報は「参照するために移動する先」にあった
• メール対応とERP操作が分断され、作業の流れが頻繁に中断された

＜改善＞

• Outlookのメール画面上で、Business Centralの顧客・仕入先情報を即時参照可能
• 見積・受注・請求書などの作成をOutlookから直接開始できる
• メール文脈（誰から・何について）とERPデータが同じ画面に統合された

＜利用シーン＞

• 営業：見積依頼メールを開いた瞬間に、過去取引・残高・進行中案件を確認し、そのまま見積作成
• 経理：請求・支払に関する問い合わせメールに、ERPを開かずに即答
• 購買：仕入先メールから、関連する発注・未処理取引を確認

いずれも共通しているのは、「ERPを探しに行く行為」が消える点です。

＜課題・留意点＞

• Outlook連携はBusiness Central側の権限設定に強く依存する
• 複数環境（本番・検証）を使い分ける場合、アドインの対象環境に注意が必要
• 「どこまでOutlookで完結させ、どこからERPで行うか」という運用整理は不可欠

傾向のまとめ｜ERPは「作業場所」ではなく「文脈の裏側」へ

Update 28.0のOutlook連携が示している方向性は明確です。ERPを主役の画面に据えるのではなく、人がすでにいる場所（Outlook）に文脈を持ち込む。これは単なる利便性向上ではありません。

• Governanceでは、AIや自動処理が勝手に動かない「枠」を整え
• Financeでは、税や請求を「前提条件」として正しく定義し
• Outlook連携では、人の作業を止めない導線を用意する

これらはすべて、AI時代のERPを成立させるための同じ思想に基づいています。OutlookはUI、Business Centralは整合性と統制を担う基盤。Update 28.0のOutlook連携は、「開かれない ERP」を前提に設計されたアップデートだと言えるでしょうね。

Outlook連携は「便利な追加機能」に見えがちですが、本質はERPの役割転換です。人が一日に何十回も開くのはメールであり、ERPは必要なときだけ使われる。Update 28.0は、その現実を前提に、ERPを作業場所から“裏方の基盤”へ引き戻したアップデートだと感じます。

Reporting and Data Analysis 領域― レポートは「作るもの」から「迷わず使えるもの」へ

序章｜レポートは“見たい時にすぐ見える”ことが一番大事

Reporting and Data Analysisというと、「Power BI」「高度な分析」といった言葉が先に浮かびがちです。

ただ、Update 28.0を眺めていて感じるのは、Microsoftが今回一番向き合っているのは “日常の使いにくさ” だという点です。
• 帳票が増えすぎて、どれを使えばいいかわからない
• デモや検証では見えるのに、本番では数字がしっくりこない
• 分析はしたいけど、準備が大変で結局Excelに戻ってしまう

Update 28.0 の Reporting and Data Analysisは、「高度な分析ができる人を増やす」よりも、“普通のユーザーが、迷わず数字を確認できる状態”を作りに来たように見えます。

機能別まとめ

1. Control the lifecycle of report layouts

＜機能概要＞

レポートや帳票のレイアウトを、「作って終わり」ではなく、運用の中で管理する前提に近づける改善です。

＜以前＞

• 帳票レイアウトは増えていくが「どれが標準なのか」「どれを使えばいいのか」が分かりにくい
• レイアウト変更の影響範囲が把握しづらく、現場が戸惑うことも

＜改善＞

• レポートレイアウトは複数持つ前提で整理され、「選んで使うもの」として扱いやすくなった
• Word / Excel / RDLCなど、形式の違いも意識しやすい構造に

＜利用シーン＞

• 請求書・注文書など、帳票のフォーマット変更が定期的に発生する現場
• 部署や用途によって、同じ帳票でもレイアウトを使い分けたいケース
• 「どの帳票を使えばいいか」を新人に説明したい場面

＜課題・留意点＞

レイアウトが整理されても、運用ルール（どれを標準とするか）を決めないと迷いは残ります。便利になった分、使い分けの整理はしておきたいところですね。

2. Enhanced demo data for sales, purchasing, and fixed assets analytics

＜機能概要＞

分析やレポートを試すための デモデータが、より“現実的”になりました。
見積・受注・請求・購買といった流れが、分析に耐える形で用意されます。

＜以前＞

• デモ環境では画面は動くが、分析画面は「数字が薄くてピンとこない」
• Power BIやExcelレポートを見せても、「実際の業務だとどうなるの？」という反応になりがち

＜改善＞

• 実務に近いデータで、分析やKPIの“絵”をそのまま確認できる
• 操作説明だけでなく、「数字の変化」を体感しやすくなった

＜利用シーン＞

• 導入前のデモ・検証
• ユーザー向けトレーニング
• 新しい分析レポートを試すときの事前確認

＜課題・留意点＞

デモデータはあくまでサンプルなので、自社の業務に置き換えたときの見え方は、別途確認が必要です。ただ「何が見えるか」を掴むには十分ですね。

3. Enhanced Subscription Billing Power BI App

＜機能概要＞

サブスクリプションビジネス向けに、最初から使える Power BIレポートが強化されています。MRR、解約、契約価値など、サブスク特有の数字をまとめて確認できます。

＜以前＞

• 売上は見えるが、「なぜ増えたのか」「なぜ減ったのか」を説明しづらい
• 解約・アップセル・新規が混ざって、数字の理由が見えにくい

＜改善＞

• 売上の変化を「解約」「アップグレード」「新規」などに分解して確認可能
• 経営向け・現場向けで、見る視点を切り替えやすい

＜利用シーン＞

• 月次の売上レビュー
• サブスク事業の状況確認
• 「今月なぜ数字が動いたのか」を説明する場面

＜課題・留意点＞

Power BIアプリは 前提となる設定（ジョブ実行など）をきちんと回していることが重要です。「入れただけ」では、数字が揃いません。

4. Financial Reporting Enhancements

＜機能概要＞

財務レポート（Financial Reporting）を、より“日常的に使える”方向へ近づける流れが続いています。

＜以前＞

• 財務レポートは作れるが、「見る人」「使う人」が限られがち
• 定義変更の影響が分かりづらく、触るのが怖い

＜改善＞

• レポートを見る人・作る人、それぞれの使い勝手を改善する方向性
• Excel と組み合わせて扱いやすくする流れが継続

＜利用シーン＞

• 月次・四半期の数字確認
• 部門別・期間別の比較
• 経理以外のメンバーにも数字を共有したい場面

＜課題・留意点＞

財務レポートは「作れる人」に依存しがちなので、定義を共有し、属人化させない運用がポイントになります。

5. Modernizing Analytical Reports for Inventory

＜機能概要＞

在庫分析を、現場と管理の両方で使いやすくする方向の改善です。

＜以前＞

• 在庫レポートは「帳票」か「管理用KPI」に分かれがち
• 現場と管理で、見ている数字がズレることも

＜改善＞

• 在庫回転・滞留・評価といった視点を整理し、Power BIや分析モードで見やすくする流れが明確に

＜利用シーン＞

• 在庫が増えすぎていないかの確認
• 滞留在庫の把握
• 期末の在庫評価・棚卸後の振り返り

＜課題・留意点＞

在庫分析は、品目・ロケーション・運用ルールの設計がそのまま結果に出ます。分析以前に、日々の入力とルールが大事ですね。

6. Set default language for Documents on the Company Level

＜機能概要＞

帳票やドキュメントの デフォルト言語を会社単位で揃えやすくする方向の改善です。

＜以前＞

• ユーザー設定や相手先設定に依存し、帳票の言語がバラつくことがあった
• グローバル運用では、地味に困るポイント

＜改善＞

• 会社としての“基本言語”を揃えやすくなり、帳票のブレを減らせる

＜利用シーン＞

• 海外拠点向け帳票の標準化
• 1テナントで複数会社を運用しているケース
• 「この会社の帳票はこの言語」というルールを作りたいとき

＜課題・留意点＞

UIの表示言語と帳票言語は別なので、どこに何が効く設定なのかは一度整理しておくと安心です。

7. Use new APIs for analyzing approval workflows for auditors and IT staff

＜機能概要＞

承認ワークフローを、あとから振り返り・分析しやすくするためのAPIが用意される方向です。

＜以前＞

• 承認状況は画面で追えるが、全体傾向（滞留、偏り）は見えにくい
• 「なんとなく回っている」状態になりがち

＜改善＞
• 承認の流れをデータとして扱いやすくなり、「止まっている」「偏っている」状態を把握しやすくなる

＜利用シーン＞

• 承認が遅れがちな業務の洗い出し
• 承認ルールの見直し
• 業務改善の材料集め

＜課題・留意点＞

APIがあっても、何を改善したいのかを決めないと活きません。現場目線での使い道を考えたいところです。

8. Use new APIs for analyzing permissions for auditors and IT staff

＜機能概要＞

権限設定を、後から確認・分析しやすくするためのAPIが提供される方向です。

＜以前＞

• 権限は設定できるが、「今どうなっているか」を説明するのが大変
• 定期的な見直しが後回しになりがち

＜改善＞

• 権限状態をデータとして扱えるようになり、棚卸しや見直しの負担が下がる

＜利用シーン＞

• 定期的な権限チェック
• 異動・組織変更後の確認
• 「誰が何を見られるのか」を説明したい場面

＜課題・留意点＞

分析できるようになると、そもそもの権限設計の整理が重要になってきます。ここは一度やると、後が楽になります。

傾向のまとめ｜Reporting は「専門家向け」から「日常業務向け」へ

Update 28.0のReporting and Data Analysisを通して見えてくるのは、「分析を高度にする」よりも、「日常業務で数字に迷わない」状態を作るという方向性です。

• レポートは増やすより、整理する
• 分析は作るより、使い続ける
• 数字は見るより、説明できる

Reporting領域は、ERPを“記録する箱”から“考えるための道具”に近づけるアップデートだと感じます。分析機能は増えましたが、一番の価値は「Excelに戻らなくても、まず状況が分かる」ことです。Update 28.0のReportingは、派手さはないですが、使い続けるほど効いてくる、そんな改善だと思います。

Supply Chain Management領域— 現場の「迷い」と「手戻り」を、地味に減らしにきたアップデート

序章｜Supply Chainの改善は「正しさ」より「戻らなくて済むか」

Supply Chain Managementのアップデートというと、「計画ロジックが高度になった」「自動化が進んだ」といった話を期待しがちです。ただ Update 28.0を見ていると、今回の焦点はそこではありません。「どれを選べばいいか分からない」「後から修正・巻き戻しが面倒」「処理は合っているのに、作業がつらい」など、“日々の現場で一番ストレスが溜まるところ”に、かなり丁寧に手が入っています。

機能別まとめ

1. Add pictures to item variants to differentiate product options

＜機能概要＞

品目バリアント（色・サイズなど）ごとに 画像を登録できるようになりました。バリエーションの違いを、文字ではなく 視覚で判断できます。

＜以前＞

• バリアントはコードや説明文で見分けるしかなく
• 倉庫・営業・購買で「どれだっけ？」が起きやすかった

＜改善＞

• バリアント単位で画像を持てるため一目で違いが分かる
• タイル表示では特に効果大

＜利用シーン＞

• 色・仕様違いが多い商品
• 倉庫ピッキング時の取り違え防止
• 営業・購買が品目を確認する場面

＜課題・留意点＞

画像は 1 バリアント 1 枚なので、「何を表現する画像か」を決めておかないとブレます。

2. Define item attributes for item variants

＜機能概要＞

品目バリアントに対して 属性（Item Attributes）を定義でき、「違い」を構造的に表現できるようになります。

＜以前＞

• バリアントの意味が説明文頼み
• 分析や検索に使いづらい

＜改善＞

• 色・材質・規格などを属性として管理
• 後から分析・絞り込みがしやすい

＜利用シーン＞

• 類似商品が多い在庫管理
• 属性別の在庫・売上分析
• EC や外部連携を意識した商品管理

＜課題・留意点＞

属性設計を適当にすると、「結局使われない属性」が量産されがちです。最初が肝心ですね。

3. Add the Description 2 field to various pages to gain more insight

＜機能概要＞

これまで埋もれがちだった Description 2 が、各種ページで見やすく使えるようになります。

＜以前＞
• 詳細説明を書いても、画面上で見えにくい
• メモ欄代わりに使われがち

＜改善＞

• 補足説明として、業務画面で自然に参照可能に

＜利用シーン＞

• 品目・取引先の補足情報
• 現場向けの注意書き
• ベテランの暗黙知を残す用途

＜課題・留意点＞

Description 2 を何でも入れると、情報過多になるので使い分けが必要ですね。

4. Approve Requisition Worksheets and Item Journals

＜機能概要＞

Requisition Worksheets（要求ワークシート）とPlanning Worksheets（計画ワークシート）に標準の承認フローが追加されました。

＜以前＞

• 計画結果をそのまま発注に流せてしまう
• 誰がOKしたのか分かりにくい

＜改善＞

• 承認されるまでPurchase Orderを作成できない
• 「確認した」というワンクッションが入る

＜利用シーン＞

• 発注量・金額のチェック
• 複数人で計画をレビューする運用
• ミス防止・統制強化

＜課題・留意点＞

承認中のバッチは編集できないため、運用ルール（バッチ分け）が重要になります。

5. Create purchase orders from drop shipments

＜機能概要＞

ドロップシップメントからの 購買処理が整理され、販売・購買の流れが追いやすくなります。

＜以前＞

• 販売と購買の関係が見えにくい
• 後追い確認が大変

＜改善＞

• ドロップシップ前提の購買オーダー作成が自然に
• 流れを意識せず処理できる

＜利用シーン＞

• 在庫を持たない直送ビジネス
• 特注品・都度仕入れ

＜課題・留意点＞

通常の在庫フローとは考え方が違うため、教育なしで使うと混乱しやすいです。

6. Create Purchase Quotes for Contacts

＜機能概要＞

仕入先候補（Contacts）に対して、購入見積（Purchase Quote）を作成できるようになります。

＜以前＞

• 見積依頼はメール・Excel頼み
• 比較が属人的

＜改善＞

• ERP上で見積を管理
• 履歴・比較がしやすい

＜利用シーン＞

• 相見積
• 新規仕入先検討
• コスト交渉

＜課題・留意点＞

全てをBCに入れるかは、業務負荷とのバランスを見たいところです。Dynamics 365 Finance and SCMっぽくなっていきますねｗ

7. Experience Improved Usability in Manufacturing

＜機能概要＞

製造領域の画面・操作性が全体的に改善されています。まとめて処理できる操作や、確認ダイアログの強化が中心です。

＜以前＞

• 製造は「間違えやすい操作」が多い
• まとめ処理がしづらい

＜改善＞

• ステータス変更・印刷の一括操作
• FactBox 強化で 必要情報にすぐアクセス

＜利用シーン＞

• 製造オーダーを日常的に扱う現場
• 計画～実行を何度も回す業務

＜課題・留意点＞

改善は地味なので、気づかれずに使われない可能性もあります。周知したいですね。

8. Evaluate the Quality of Goods and Materials

＜機能概要＞

品質管理（Quality Management）が標準拡張として本格的に組み込まれました。

＜以前＞

• 品質チェックは紙・Excel・外部ツール
• システム的な一貫性が弱い

＜改善＞

• 受入・製造・組立の各タイミングで品質検査
• 合否・隔離・証明書まで一元管理

＜利用シーン＞

• 受入検査が必須な業界
• 製造品質を重視する企業
• クレーム・監査対応

＜課題・留意点＞

設定項目が多いため、最初から完璧を目指さず段階導入がおすすめです。

9. Filter receipt and shipment lines to quickly find documents to invoice

＜機能概要＞

出荷・受領済みで 未請求の行を素早く絞り込みできるようになります。

＜以前＞

• 「どれが未請求？」を探すのが大変
• 見落としが起きやすい

＜改善＞

• フィルタで即特定
• 請求漏れ防止

＜利用シーン＞

• 月末請求処理
• 分割請求
• 出荷・受領と請求のタイムラグがある業務

＜課題・留意点＞

フィルタ保存など、ユーザー教育で効果が倍増します。

10. Match Purchase Invoices to Multiple Order and Receipt Lines

＜機能概要＞

1つの仕入請求書を、複数の注文・受領行にまとめて突合できます。

＜以前＞

• 行ごとに処理が必要
• 手間とミスが出やすい

＜改善＞

• 実務に近い請求処理が可能
• 処理時間短縮

＜利用シーン＞

• まとめ請求
• 月次請求
• 大口仕入先

＜課題・留意点＞

突合ルールは、仕入先との運用前提と合わせる必要があります。

11. Post purchase invoices for drop shipments independently

＜機能概要＞

ドロップシップメントで、販売請求と独立して仕入請求を処理できます。

＜以前＞

• タイミングが縛られる
• 実務と合わないケース

＜改善＞

• 実際の請求タイミングに合わせられる
• 経理・購買が楽になる

＜利用シーン＞

• 仕入先請求が先行するケース
• 請求サイクルが異なる場合

＜課題・留意点＞

流れが柔軟になる分、理解不足だと混乱しやすくなるので、しっかりと機能を理解しましょう！

12. Reverse drop shipments when documents aren’t invoiced

＜機能概要＞

請求前のドロップシップメントを正しく巻き戻せるようになっています。

＜以前＞

• 巻き戻しが分かりづらい
• 怖くて触れない

＜改善＞

• 手順が整理
• 「やり直せる」安心感

＜利用シーン＞

• 誤出荷
• キャンセル
• 仕様変更

＜課題・留意点＞

請求後は別手続きになるため、タイミング管理が重要ですね。

13. Send posted sales shipments and return receipts by email

＜機能概要＞

出荷済・返品受領済のドキュメントをそのままメール送信できます。

＜以前＞

• PDF保存 → 添付 → 送信
• 地味に手間

＜改善＞

• ワンクリック送信
• 現場が楽

＜利用シーン＞

• 出荷連絡
• 返品受付通知
• 顧客対応の迅速化

＜課題・留意点＞

メール文面・言語は、事前にテンプレ整理したいですね。

傾向のまとめ｜Supply Chain を「判断が要らない業務」に近づける

Update 28.0のSupply Chain Managementを俯瞰すると、Microsoftがやろうとしていることは、在庫最適化や計画精度の話ではありません。一貫しているのは、次の問いです。

「現場の人は、なぜSupply Chainを“怖がる”のか？」

1. Supply Chainの事故は、ほとんどが「判断ミス」ではない

現場で起きるSupply Chainのトラブルを分解すると、

色・仕様の取り違え
どれを請求すべきか分からない
まだ戻せるのに、戻せないと思い込む
ルールは合っているのに、操作が分かりづらい

こうしたものが大半です。
つまり問題は、
「判断を誤った」のではなく、
「判断しなければいけない場面が多すぎる」
という点にあります。

2. Update 28.0は「考えなくていい状態」を増やしている

今回の Supply Chain改善を並べてみると、すべて同じ方向を向いています。

画像付きバリアント→考えなくても、見れば分かる

Item Attributes / Description 2→後から説明しなくていい

Requisition/Planning Worksheetの承認→作っていいか悩まなくていい

未請求行のフィルタ→ 探さなくていい

ドロップシップの独立請求・巻き戻し→「やってしまったら終わり」をなくす

どれも派手ではありません。しかし共通しているのは、「人に判断を委ねていた部分を、システム側に引き取っている」という点です。

3. Supply Chainを「熟練前提」にしない、という意思

これまでのERPの Supply Chainは、暗黙の前提がありました。

この業務はベテランがやる、例外は経験で吸収する、ミスしたら、戻せないのが普通

Update 28.0は、ここを明確に壊しに来ています。「見れば分かる」「承認が入る」「未処理が見える」「巻き戻せる」これは 機能改善ではなく、前提条件の変更です。

Supply Chain は「慣れている人が扱うもの」ではなく、「普通の人が、普通に触れるもの」へ、というメッセージだと受け取れます。

4. Finance / Governance / Reportingと完全に同じ方向を向いている

ここが重要です。Supply Chainの改善は、単体で見ると地味ですが、

Governance：勝手に動かさない

Reporting：説明できる状態にする

Ecommerce：現場で詰まる所を先に潰す

と、思想は完全に一致しています。

Supply Chain もまた、判断を減らし、例外を怖くなくし、人が無理に頑張らなくていい。そういう設計に寄せられています。

5. 結論：Supply Chainは「我慢する業務」ではなくなる

Update 28.0のSupply chain managementが目指しているのは、最適化された Supply Chainではなく、“安心して回せる” Supply Chainです。完璧でなくていい、速くなくていい、でも、戻れる・確認できる・迷わない。その状態を、機能の積み重ねで作りに来た。

Supply Chainは、「頭が良い人」や「経験が長い人」が支えてきた領域です。Update 28.0は、そこから一歩踏み出して、“人の頑張り”を前提にしない Supply Chainに近づいたリリースだと思います。これは地味ですが、長く使うERPとしては、ものすごく大事な進化です。製品開発チームに感謝ですね。

Sustainability Management領域— サステナビリティを「報告の仕事」から「日常業務の副産物」へ

序章｜サステナビリティは、もはや“別枠業務”では続かない

多くの現場にとって、サステナビリティ対応は長らく「年に一度、誰かが頑張る仕事」でした。Excelに数字を集める、どこから出た数値か思い出す、監査や説明で詰まる…

Business CentralのSustainability Managementは、この前提を 静かに壊しに来ています。Update 28.0の改善は、「環境に優しくしよう」というメッセージではありません。「“いつもの業務をしていたら、あとから説明できる状態になっている”」そこを本気で目指しているように見えます。

機能別まとめ

1. Use new APIs in Sustainability for Better Integration

＜機能概要＞

Sustainability Managementのデータを、外部システムやESGツールと連携しやすくするためのAPIが用意されています。

＜以前＞

サステナビリティデータは、ERPの中に閉じがち。外部レポーティングやESG基盤との連携は、個別対応・手作業になりやすかった。

＜改善＞

標準 REST APIを通じて、排出量・スコア・サステナビリティ台帳を外部と接続可能。「BCで集める」「外でまとめる」が現実的に

＜利用シーン＞

CSRD/ESGレポーティング基盤との連携
グループ全体のサステナビリティ集約
BI・分析ツールでの可視化

＜課題・留意点＞

APIがあっても、データの定義（何を Scope1/2/3 とするか）が曖昧だと使えません。ここは業務側の整理が不可欠です。

2. Use New Sales Document Reports Layout that Show Your Carbon Footprint

＜機能概要＞

販売ドキュメント（請求書・出荷関連帳票）で、カーボンフットプリントを表示できる新しいレポートレイアウトが提供されます。

＜以前＞

CO₂排出量は、社内向けの報告資料にしか出てこない。顧客や取引先に説明するには、別資料が必要だった。

＜改善＞

「いつもの帳票」に環境情報が載る。売上・数量と並んで、環境負荷を確認可能。

＜利用シーン＞

環境配慮を重視する顧客との取引
Scope3（販売後・取引先側排出）の説明
サステナブル調達・販売の可視化

＜課題・留意点＞

数字を載せられるからこそ、算定ロジックの説明責任がより重要になります。「出せる」＝「説明できる」ではありません。

傾向のまとめ｜サステナビリティを“業務の外”に置かせない設計

ここが、Sustainability Managementの一番重要なポイントです。Update 28.0のSustainability改善は、機能数は少ないが、思想は非常に明確です。

1. 「集める専用業務」を作らせない

新しいAPIと帳票レイアウトの共通点は、サステナビリティのために、新しい作業を増やさない。という点です。データは購買・仕訳・販売の中で発生し、計算はシステムが行い、連携や表示は“後付け”で行う。人が意識しなくても数字が残る設計に寄せています。

2. Sustainabilityを「会計・SCMと同列」に扱い始めた

これまでのERPでは、「会計は必須、在庫・販売は必須、サステナビリティは“オプション”」という扱いでした。

Business Central では、「Sustainability Ledger」「通常ドキュメントとの統合」「標準API」と、他の基幹データと同じ扱いに引き上げています。 これは「流行対応」ではなく、ERPの責任範囲を拡張したと見るべきです。

3. 「報告のための数字」から「判断のための数字」へ

帳票にカーボンフットプリントが載る、というのは象徴的です。

「報告書にだけ出てくる数字」「年度末にだけ見る数字」ではなく、売上・数量と同じタイミングで、環境負荷を見る。という状態を作ろうとしています。これはSustainabilityを経営判断・取引判断の文脈に戻す動きです。

4. Governance / Reporting / Supply Chainと完全に同じ方向

これまで書いてきた各章と並べると、方向は一致しています。

Governance：勝手に動かさない

Reporting：説明できる状態を作る

Supply Chain：迷わず処理できる

Sustainability：意識しなくても、後から説明できる

Sustainability だけが、特別扱いされていないことが、最大のメッセージです。

結論｜サステナビリティは「頑張る人の仕事」ではなくなる

Update 28.0のSustainability Managementが示しているのは、「サステナビリティを“良い人が頑張る業務”から解放する」という方向性です。記録は日常業務の中で、計算はシステムが行い、説明は帳票とAPIが支える。これができて初めて、サステナビリティは 続く業務になります。サステナビリティは、「正しいこと」だけでは定着しません。Business Centralのこの設計は、やらなくていい理由を、一つずつ潰していく、非常にERPらしいアプローチだと思います。

補足｜Preview と GA の違い、ライセンス・可用性、運用上の注意

1) Preview（Public Preview）と GA（General Availability）の違い

– Public Preview は新機能を早期に評価するための段階。機能は未完成、挙動が変更される可能性があり、サポート・SLA は GA 時より限定的。
– GA は正式リリースで、安定性・サポート・SLA が確立され、広範なリージョンや顧客に展開される。Preview で提供される機能の一部は GA まで変更・削除されることがある。
– 導入判断：本番運用は原則 GA を推奨。Preview は検証（PoC・検証環境）・評価用途に限定する。

2) ライセンス・可用性に関する留意点

– 提供範囲：Preview の機能はオンライン（SaaS）テナントで段階的にロールアウトされることが多く、オンプレミスや特定リージョンでは利用不可／遅延の可能性あり。
– 追加ライセンス：Copilot/Agents や BYO-AI の一部機能は別途ライセンスまたは追加購読（Microsoft 365 / Copilot for Business Central など）が必要になる場合がある。正式なライセンス要件は Microsoft の最新ドキュメントで確認すること。
– テナント管理：Preview 機能は管理者がテナント単位で有効化/無効化できる場合がある。組織のポリシーに基づいて有効化の可否を決める。

3) 運用上の注意（チェックリスト）

– 環境分離：Preview 機能はまずステージング／評価テナントで検証し、本番テナントでは GA 後に展開する運用ルールを作成する。
– 権限とレビュー：エージェントが生成・実行する操作に対して「承認者」「レビュー者」を明確にし、ロールベースで権限を制限する。
– 監査ログと変更記録：生成コンテンツやエージェントの実行履歴、データアクセスログを収集・保管する仕組みを用意する（トレーサビリティ確保）。
– データ取り扱い（BYO-AI 含む）：外部AIを利用する場合のデータ送信範囲を明確化し、機密情報・個人情報が送信されないようガードレール（フィルタリング、マスキング、同意管理）を設ける。
– セキュリティ評価：ネットワーク・認証・アクセス制御の観点でリスク評価を行い、必要なら追加のセキュリティ対策（IP制限、条件付きアクセス）を適用する。
– ロールアウト計画：段階的ロールアウト（パイロット→部門ごと展開→全面展開）とフォールバック手順（無効化方法、問題発生時の対応）を策定する。
– 利用規約・コンプライアンス：ベンダー/顧客向けに利用ルールを文書化し、内部ポリシー／法令（データ保護法、業界規定）に適合しているか確認する。
– 教育と運用体制：運用担当者およびエンドユーザー向けに機能の使い方、レビュー手順、問題報告フローを周知する。

4) 推奨アクション（短期）

– 影響範囲の把握：まず自社の利用シナリオで該当機能がどの程度影響するかを洗い出す。
– 検証計画の作成：評価テナントでのPoC項目（精度、誤動作事例、データ送信の可視化）を定める。
– ライセンス確認：MS の公式ドキュメント／営業窓口に最新のライセンスとリージョン可用性を確認する。

おわりに｜Update 28.0 は「賢くなった」のではなく、「任せ続けられるようになった」

ここまでお付き合いいただき、ありがとうございました。室長こと、吉島良平です。

Update 28.0（2026 Wave 1）を一言で言うなら、やはりこれです。「AIに仕事を任せる」から、「AIの仕事を管理・監督するERP」への進化。2025 Wave 2でMicrosoftは「AIに任せられる」ことを証明し、2026 Wave 1で「任せ続けられる」ための前提条件を整えた。

私は、この順番にこそMicrosoftの現実感が表れていると感じます。

現場にとっては、AIが勝手に動くのではなく、何をしたかが見え、必要なら止められ、レビューできるようになったことが大きい。

IT部門にとっては、CopilotがPoCの対象ではなく、運用・統制の対象になったことが大きい。

経営にとっては、省力化そのものより、意思決定速度と統制を両立できる構造が見えてきたことが大きい。

そして Finance / Supply Chain / Sustainability の各領域でも同じことが起きています。

税は「計算結果」ではなく「取引の前提条件」として整理され、Supply Chainは「熟練者の勘」に依存しない方向へ寄せられ、Sustainabilityは「誰かが頑張る報告」から「日常業務の副産物」へ近づいた。

つまり、Business Centralは、画面の主役ではなく、業務を成立させ続ける“基盤”へと役割を変えつつあります。10年後、「ERP」や「CRM」という言葉は主語ではなくなるかもしれません。その代わりに、「どのAIに、どこまで任せ、どこで人が責任を持つのか」が問われる。Business Centralは、その舞台装置として、ますます重要になっていくはずです。

年度末で慌ただしい時期ではありますが、少し落ち着いたタイミングでぜひ一度、“AIと業務をどう分担するか”という視点で、自社の業務プロセスを棚卸ししてみてください。Update 28.0は、その議論を現実にするための「地味だけど確実に効く土台」を用意してきたアップデートだと思います。

それでは、また次回。室長でした。