【連載開始】企業ソフトウェアが「考えて動く」時代へ

こんにちは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

皆さん、いかがお過ごしでしょうか？　私は今日は珍しく21時くらいに会社員としての業務が終わり、そこからあることについて悩み始めました。

あることというのは、先日のDirections ASIA 2026の2日目のキーノートで、目の前で見せられた「Agentic Engineering」の凄さについてです。

弊社の中でも取り組みが進んでいる内容です。

ソフトウェアを開発している企業はなんとか生き残れるのだろうとは思うのですが、日本でいうSIerのビジネスは、相当ヤバイことになるだろうという感覚です。

まぁ、そういう思いで、Directions ASIAで自分が担当するセッションは創り上げたわけなのですが。

それにしても、、、、あのレベルのものを見せられるとねぇ。

いよいよ、書き溜めていたものをお披露目するタイミングかもしれませんね。

という事で、今日のお題に向かいます。

Series prologue — Agentic Engineering × Dynamics 365

企業ソフトウェアが「考えて動く」時代へ

Dynamics 365とエージェンティックエンジニアリング——このシリーズが問うこと

2026年5月
プロローグ
Dynamics 365
Agentic AI
Copilot Studio

多くの企業ソフトウェアは「何が起きたか」を正確に記録します。しかし、「次に何をすべきか」は依然として私たち人間に委ねられています。

営業担当はレポートを確認し、サービス担当は履歴を見ながら判断し、在庫担当は複数のシステムを横断して最適な意思決定を行います。

情報は揃っています。それでも、業務は自動化されません。

——そして、その“人間に残された判断”こそが、今まさに変わろうとしています。

Microsoftは2026 wave 1で、CopilotをERPとCRMに組み込まれた「エージェント型の動作層（Agentic Operating Layer）」へと格上げしたように思います。これはDynamics 365の機能アップデートではありません。企業の基幹システムが仕事をどのように実行するかという、構造そのものの変化です。このシリーズは、その変化の意味を実装者と意思決定者の両方の視点から紐解いていきたいと思います。

Background

なぜ今、エージェントなのか

AIが「使えるもの」になってから数年が経ちました。Copilotはメールの下書きをし、会議の要約を作り、コードを補完しました。便利ではあります。しかしそれは本質的には「高性能な検索と生成」であり、業務の主体はあくまで私たち人間でした。

転換点は、AIが「ゴールを与えられて自律的に行動できる」ようになったことです。エージェント型AIとは、単一のプロンプトに応答するのではなく、複数のステップにわたって計画・実行・修正を自律的に繰り返すシステムを指します。人間が「何をするか」を指示するのではなく、「何を達成するか」を指示すれば、エージェントが手順を組み立てて実行するのです。

定義の整理

従来のCopilot：プロンプト → レスポンス（1ターン）
エージェント型AI：ゴール → 計画 → 実行 → 観察 → 修正 → 完了（複数ターンの自律ループ）

この転換がエンタープライズソフトウェアにとって重要なのは、企業の業務が本質的に「複数ステップの連鎖」で成り立っているからです。見込み客への商談フォローアップは、メール送信・返信確認・次のアクション設定・スケジュール調整・社内共有という一連のステップで構成されます。在庫補充は、在庫水準の監視・発注点の判断・仕入先への発注・入荷確認・原価への反映という流れを持ちます。これまではその各ステップを我々人間がつないでいました。エージェントはそのつなぎを自律的に担います。

Wave 1 — Technical background

Dynamics 365 2026 wave 1が変えた3つのこと

Microsoftが2026年4月にリリースしたwave 1は、Copilotの役割を「UIレイヤーのアシスタント」から「業務実行の動作層」へと根本的に再定義したように思います。技術的に見ると、3つの変化が重なっています。

エージェントがDynamics 365のデータとアクションに直接アクセスできるようになった

Copilot StudioからDynamics 365のエンティティ（リード・商談・注文・在庫・顧客）を直接読み書きし、Power AutomateフローやカスタムAPIを呼び出せる統合が標準化されました。エージェントはシステムの「外」ではなく「中」にいます。

マルチエージェント協調が実用レベルに達した

役割を分担した複数のエージェントが協調して動く構成がwave 1で実装されました。CRMフロントのエージェントが、ERPバックエンドのエージェントに在庫照会を依頼し、結果を受け取って、見積を完成させる連携がCopilot Studio上で設計できます。

ガバナンスと監査の仕組みが組み込まれた

エージェントの判断ログ・アクション履歴・承認フローの記録がDynamics 365の監査機能と統合された￥ました。自律性と説明責任を両立する基盤が整いました。

CRM — What changed

CRMで何が変わるか——顧客接点の自律化

Dynamics 365のCRM領域（Sales・Customer Service・Contact Center・Customer Insights）では、エージェントの導入によって、顧客接点の性質が変わります。従来のCRMは「記録する為のシステム」でした。営業担当が商談の状況を入力し、CSが対応履歴を残します。データは蓄積されますが、次のアクションを決めるのは人間でした。エージェント型CRMは「行動するシステム」です。

Sales：商談管理の自律化

Sales Copilotは、CRMの商談データとMicrosoft 365（メール・Teams・カレンダー）のアクティビティ（活動）を横断して分析し、次のアクションを自律的に実行します。重要なのは、これらが「提案」ではなく「実行」であることです。エージェントはメールを書いて「これを、送りますか？」と聞くのではなく、設定された条件が満たされれば送信まで行います。

Sales エージェントの自律実行例

・商談がX日間更新されていない場合、フォローメールを自動生成・送信
・会議後の議事録からアクションアイテムを抽出し、CRMのタスクとして登録
・受注確度が閾値を下回った商談を検出し、マネージャーにアラートを送信
・競合比較・製品情報をリアルタイムで収集し、商談担当者に提示

Customer Service / Contact Center：対応品質の均質化

エージェントが一次対応を担い、人間は複雑なケースにフォーカスできるようになります。Customer Insightsとの連携では、顧客の行動データ・購買履歴・セグメント情報をエージェントが、リアルタイムで参照し、対応のパーソナライズが可能になります。

CRM — エージェントが担う

→ 商談フォローの自律実行

→ CS一次対応の自動化

→ 顧客文脈を保持した対話

→ 受注確度の自動モニタリング

→ アクションアイテムの自動登録

CRM — 人間が担う

→ エージェントの行動条件設計

→ ガードレール・閾値の設定

→ 複雑・感情的なケースの対応

→ エスカレーションの判断

→ エージェントの判断ログ監督

ERP — What changed

ERPで何が変わるか——基幹業務の自律化

ERP領域でのエージェント導入は、CRMとは異なる難しさがあります。在庫・原価・会計は金銭的・法的な正確性が求められ、間違いの影響が直接財務に現れます。「どこまで自律させるか」の設計がより慎重に問われる領域です。

Dynamics 365のERP群を理解するには、まずライセンス体系の変遷を理解しておく必要があります。

ライセンス体系の変遷

旧称（〜2019年頃）

Dynamics 365 Finance & Operations（F&O）

大企業向けERPとして財務・SCM・製造を一体で提供していた単一製品

分離後

Dynamics 365 Supply Chain Management

在庫・製造・倉庫・物流に特化。F&OのSCM機能を独立ライセンス化

分離後

Dynamics 365 Finance

一般会計・固定資産・財務報告に特化。F&Oの財務機能を独立ライセンス化

こういう経緯があり、SCMとFinanceは同じ技術基盤（旧Dynamics 365 Finance and Operations：F＆O）を共有しており、両方を導入する企業も多いです。一方、Dynamics 365 Business Centralは別のプロダクトで、中堅・中小企業向けのオールインワンERPとして独立した位置づけにあります。

Supply Chain Management：在庫・発注の自律化

在庫ステータスの監視と、発注トリガーがエージェントの主要タスクになります。従来は担当者が定期的に在庫レポートを確認し、発注点を下回ったら発注処理を行っていました。エージェントはこれをリアルタイムで継続的に監視し、設定した閾値を超えたら自律的に発注処理を実行します。

Supply Chain エージェントの自律実行例

・在庫水準が発注点を下回った時点で仕入先への発注を自動実行
・需要予測データと照合し、季節変動を考慮した発注量を自動算出
・入荷確認後、受け払い元帳（在庫元帳）への反映と原価計算を自律処理
・サプライヤーの納期遅延を検知し、代替仕入先への切り替えを提案
・発注金額が閾値を超える場合は承認フローへ自動エスカレーション

Finance：自律化の限界と設計の原則

旧F&OからFinanceとして独立したこのプロダクトは、一般会計・固定資産管理・財務報告・連結決算を担います。監査要件・コンプライアンス規制・内部統制の観点から、「エージェントが下書きを作り、私たち人間が承認する」モデルが現実的です。

Financeでエージェントに向く業務 / 向かない業務

委ねやすい：仕訳の下書き生成・減価償却計算・未処理取引の洗い出し・レポート自動生成
人間が保持すべき：仕訳の最終承認・会計方針の変更・財務報告書の対外提出・監査対応

Business Central：中堅・中小企業のオールインワン自律化

Business CentralはSCM・Financeとは別のプロダクトで、財務（会計・固定資産）・在庫・販売・購買・倉庫・プロジェクト・サービス・組立製造管理等を、単一プラットフォームで完結させる中堅・中小企業向けの統合ERPです。業務がひとつのデータモデルの中に統合されているため、エージェントが業務をまたいで判断・実行する際にシステム間の断絶がありません。

Business Central エージェントの自律実行例

・売掛金管理：支払期限超過の請求書を検知し、督促メールを自動送信
・在庫・購買連動：販売注文（受注伝票）の増加を検知し、仕入先への発注を先手で実行
・経費精算：領収書データの取り込み・仕訳生成・承認フロー投入を自律実行
・プロジェクト管理：予算消化率が閾値を超えた時点でプロジェクトマネージャー（PM）にアラート
・月次クローズ支援：未計上取引を検知し、担当者への確認タスクを自動生成

財務

売掛・買掛・仕訳の自律化

期日管理・督促・仕訳生成をエージェントが担う

在庫・購買

需要連動型の発注自動化

販売動向を読んで先手の発注をエージェントが実行

プロジェクト

予算・進捗の自律モニタリング

閾値超過の検知とアラートをエージェントが継続監視

Integration — Virtual tables

CRMとERPをつなぐ基盤——バーチャルテーブルという設計思想

エージェントがCRMとERPをまたいで自律的に動くためには、両システムのデータをリアルタイムで参照・操作できる統合基盤が必要です。Dynamics 365では「バーチャルテーブル（Virtual Table）」がその役割を担っています。

バーチャルテーブルとは、ERPのデータをDataverse上の仮想テーブルとして公開する仕組みのことです。データをDataverseにコピー・複製するのではなく、ERP側の元帳にデータを置いたまま、CRMやPower Platformから直接読み書きできます。「データを動かさず、アクセスを動かす」という設計思想です。

バーチャルテーブルの本質

従来の統合：ERP → データコピー → Dataverse → CRM（二重管理・同期遅延が発生）
バーチャルテーブル：CRM/エージェント → Dataverse仮想テーブル → ERPデータをその場で参照（元帳がデータの正）

ただし、F&O系（SCM・Finance）とBusiness Centralでは、バーチャルテーブルの実装経緯と特性に違いがあります。

観点	F&O系（SCM・Finance）	Business Central
導入時期	2020年頃（バージョン10.0.12）から提供。Wave 1で数千テーブル規模のパフォーマンスが実用レベルに強化	旧来から標準機能として提供されており、近年はDataverse連携が強化され、Integration Table Mappingによるデータ同期が実務で利用可能なデータ連携基盤として位置付けが明確化
データ操作	OData v4経由でCRUD操作が可能。F&Oの主要なODataエンティティをDataverseの仮想テーブルとして参照可能	DataverseとBC間で標準テーブルを中心としたデータ同期が可能。Integration Table Mappingにより、フィールドマッピングや追加テーブル連携を構成できる
CRMとの連携	Dual-writeによるリアルタイム双方向同期と、バーチャルテーブルによる参照専用アクセスを使い分け	Dynamics 365 Salesとの標準連携をサポートし、Dataverseを介したデータ同期が提供される。BCのCustomer（得意先）テーブルと、CRMのAccountテーブルの同期が標準設定として提供
エージェントへの影響	SCMの在庫・原価データをCRMエージェントがリアルタイムに参照。見積生成時に実原価・在庫可用性を直接取得	BCの請求・在庫・プロジェクトデータをCRMエージェントが参照。CRM側のエージェントがERPデータへ直接アクセスできる前提を整備し、中堅・中小企業においても実データに基づく判断を可能にする

いずれの場合も「原価はERPデータを正として、CRMに返す」という原則は、変わりません。CRMエージェントが見積を生成する際、その時点の実原価・在庫可用性・リードタイムをERPから直接取得して反映します。バッチ処理で同期された古いデータではなく、リアルタイムのERP元帳データが判断の根拠になります。これはエージェントの「判断の品質」に直結しますね。

What it means

実装者と意思決定者、それぞれに何が求められるか

エージェント型への移行は、作る側（実装者）と使う側（意思決定者）の両方に、従来とは異なる問いを、突きつけていきます。

実装者に求められること

コードを書くより、「どの業務をエージェントに委ねるか」を設計する。Copilot Studioでエージェントの行動条件・ガードレール・エスカレーションフローを定義し、判断ログを監視して、閾値を継続的にチューニングする。

意思決定者に求められること

「何を自動化できるか」より「どこに人間の判断を残すか」を問う。エージェントの自律範囲は技術の問題ではなく経営判断の問題。責任の所在・リスク許容度・コンプライアンス要件を踏まえて、自律化の境界線を引く。

この問いに向き合う方法論や知識の整理を、このシリーズでは以降7回にわたって積み上げていく予定です。

このシリーズの構成

プロローグ：企業ソフトウェアが「考えて動く」時代へ ← 本記事

Agentic Engineeringとは何か——「作る対象」から「統率する存在」へ

CRM：商談フォローERP：自動発注

どこに人間を置くか——Human-in-the-Loopの設計原則

CRM：見積承認ERP：発注閾値

エージェントはデータをどう使うか——CRMとERPのデータモデル

CRM：顧客データERP：仮想テーブル

エージェントを組み立てる——Copilot Studioで何ができて何ができないか

CRM連携ERP連携

エージェントを信頼できるか——ログ・監査・コンプライアンスの設計

CRM：通信ログERP：会計監査

CRMとERPをまたぐエージェント——統合設計の全体像

CRM + ERP 統合

これからのDynamics 365エンジニアに何が求められるか

CRMエンジニアERPエンジニア

「何を自動化するか」より「どこに人間を残すか」その問いに向き合うところから、エージェンティックエンジニアリングは始まります。在庫発注の例において、意思決定者は自動的な発注伝票の起票をよしとするのか、それとも発注伝票を作成するためのデータ生成までに留め、人間の判断を入れるべきか検討する必要があります。実装者は、意思決定者の方針に基づいてエージェントの設定を行っていく必要があるわけです。次回は、エージェント型AIの定義と自律性の段階を整理します。シリーズを通して、皆さまと一緒に、これからのDynamics 365の導入・設定・開発等について、考えていきたいと思っています。

以上、室長でした。