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

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

皆さん、いかがお過ごしでしょうか？気付くと、もう5月も終わりですか。時間が経つのは本当にはやいですね。3月決算の方にとって来月は、四半期の締めですね。ファイト！

私の会社は6月決算なので、最後のラストスパートって感じです。

いい時も、悪い時もあるので、終わったら反省して、また次に向かって走っていきましょう。

さて、今日は、前回書いたプロローグに続き、このシリーズの第1回をお届けします。最後までお付き合いいただけますと幸いです。

Series #01 — Agentic Engineering × Dynamics 365

Agentic Engineeringとは何か

「作る」から「統率する」へ——実装者の役割が根本的に変わります

2026年5月
第1回
Dynamics 365
Agentic AI
Copilot Studio

従来のシステム開発では、人間が設計し、人間が実行し、その結果をシステムが記録してきました。

つまり「人間が考え、人間が動く」ことが前提でした。

しかし、Agentic Engineeringではこの前提が変わります。

人間は全体を設計し意思決定の基準を与え、実際の実行や判断の多くはエージェントが担うようになります。

「作る」から「統率する」へ。

それが、この変化の本質です。

そしてこの変化は、単なる開発手法の違いではなく、企業が「どのように業務を実行するか」という前提そのものを書き換えます。

そのため、「Agentic Engineeringとは何か」を単なる定義として理解するだけでは不十分なのです。

「Agentic Engineering」という言葉が急速に広まっています。しかし、その実態は、まだ多くの実装者にとって曖昧なままではないでしょうか。AIが「提案する」のか「実行する」のかは、実装の設計を根本から変える問いです。本稿では、エージェント型AIの定義と自律性の段階を整理し、Dynamics 365のCRMとERPの導入について改めて考えていきます。

Definition

そもそも「エージェント」とは何か

ソフトウェアの世界で「エージェント」という言葉は昔からありました。しかし今日のコンテキスト（文脈）で使われるエージェント型AIは、従来の自動化とは本質的に異なります。

従来の自動化（RPA・Power Automate等）は、あらかじめ決められた手順を機械的に実行します。条件分岐はあっても、判断の幅はプログラムされた範囲に限られています。一方、エージェント型AIは「ゴール（目標）を渡されると、自分で手順を考えて実行する」という動き方をします。プロセスが事前に定義されていなくても、状況に応じて計画を立て、ツールを呼び出し、結果を見て、次の行動を決めることができます。

この違いを整理するとこうなります。

観点	従来の自動化	エージェント型AI
指示の形式	手順を定義する	ゴールを渡す
計画	人間があらかじめ設計	エージェントが自律的に立案
例外処理	事前に定義した分岐のみ	状況を読んで対応を変える
ツール利用	固定のアクション	必要なツールを選んで呼び出す
学習・修正	人間が都度フローを修正	結果を観察して次の行動を調整

この違いは「便利さの度合い」ではなく、「誰が設計するか」の違いです。従来の自動化は実装者がプロセスを設計してコードやフローに落とし込みます。エージェント型AIは、実装者がゴールとガードレール（AIが暴走や誤作動を起こさないように設ける安全装置や制御）を設計し、プロセス自体はエージェントが組み立てます。

Autonomy Levels

自律性には段階（ステージ）があります

「エージェントに任せる」と一口に言っても、その自律性には幅があります。MicrosoftはCopilotの進化を次のような段階で整理しています。実装者はこの段階を意識しながら、「どこまで自律させるか」を設計する必要があります。

アシスタント（提案型）

人間のリクエストに応じてテキストや情報を生成します。実行はしません。従来のCopilotチャットがこれにあたります。

実行補助（確認型）

アクションを提案し、人間が承認したら実行します。「このメールを送りますか？」と聞いてから送る形です。人間が最終ゲートで確認します。

条件付き自律実行（閾値型）

設定した条件・閾値の範囲内では自律実行し、範囲を超えたら人間にエスカレーションします。2026 wave 1のエージェントの主流がこの段階です。

完全自律実行（監督型）

人間の承認なしに広範な業務を自律実行します。人間は事後ログで監督します。現時点では会計・法務など高リスク領域では推奨されない段階です。

重要なのは、「より高い自律性が常に良い」わけではないという点です。業務のリスク・コンプライアンス要件・組織の成熟度によって、適切な自律性の段階は変わります。Agentic Engineeringの設計とは、この段階を業務ごとに適切に選ぶことです。

CRM — Practical examples

CRMで考える——顧客接点の自律化

Dynamics 365のCRM領域を例に、自律性の段階がどのように変わるか見てみましょうか。ここでは「商談フォロー」と「ケース管理」の2つを取り上げます。

商談フォロー：Dynamics 365 Sales

シナリオは「商談が一定期間更新されていない場合のフォロー」です。

「この商談、フォローメールを書いて」と頼む

CopilotがCRMのデータを参照してメール文案を生成します。担当者が確認・編集・送信します。

エージェントが「このメールを送りますか？」と提案する

7日間更新のない商談を自動検知し、文案を生成して担当者に確認を求めます。担当者がOKを出したら送信します。

閾値内は自動送信、VIP顧客は確認を挟む

通常商談は7日で自動フォロー送信します。金額が500万円超またはVIPセグメントの顧客は担当者確認を必須とします。これが2026 wave 1の主流設計です。

すべての商談フォローをエージェントが完全自律実行

担当者への確認なしにフォロー・提案・スケジュール調整まで自律実行します。顧客との関係リスクから、現時点では慎重な判断が必要な段階です。

ケース管理：Dynamics 365 Customer Service

シナリオは「顧客からの問い合わせケースが起票されてから解決までの対応」です。

「このケースの回答案を作って」と頼む

担当者がケースを開き、Copilotに回答案の生成を依頼します。過去の類似ケースやナレッジベースを参照した文案が生成され、担当者が確認・送信します。

エージェントが一次回答を提案し、担当者が送信する

新規ケースが起票されると、エージェントが自動でナレッジベースを検索し、回答案を生成して担当者に提示します。担当者がOKを出したら送信します。

標準ケースは自動対応、複雑・クレームは担当者へ

問い合わせカテゴリと感情スコアを判定し、標準的な技術的問い合わせはエージェントが自動回答・クローズします。感情スコアが閾値を超えたケースや、複雑な手続き等は、即座に担当者にルーティングします。Contact Centerにおける主流設計です。

ケースのトリアージから解決・クローズまでを完全自律実行

エージェントがケースの分類・優先度付け・回答・フォロー・クローズまでを自律実行します。担当者は例外ケースと品質監視に集中します。

2つのシナリオに共通するのは、「ルーティンで判断基準が明確な部分はエージェントに委ね、感情・複雑性・金額リスクが高い部分に人間を置く」という設計原則です。この境界線の引き方が、実装者の腕の見せどころです。

ERP — Practical examples

ERPで考える—基幹業務の自律化

ERPでのエージェント導入は、CRMとは異なる難しさがあります。在庫・原価・会計は金銭的・法的な正確性が求められ、間違いの影響が直接財務に現れます。ここではSupply Chain Management・Finance・Business Centralの3つを取り上げます。

需要予測連動の自動発注：Dynamics 365 Supply Chain Management

シナリオは「需要予測データと在庫水準を組み合わせて、発注量と発注タイミングを判断する」です。

「来月の発注量を教えて」と頼む

CopilotがERPの在庫データと需要予測データを参照し、品目ごとの推奨発注量をリスト形式で提示します。担当者が確認して手動発注します。

エージェントが発注案を作成し、担当者が承認する

エージェントが在庫水準・需要予測・リードタイムを自動計算し、発注案を生成します。季節変動や急激な需要増にも対応した発注案を担当者に提示し、承認を得てから発注を実行します。

閾値以下は自動発注、高額・新規サプライヤーは承認フローへ

標準品かつ発注金額が閾値以下の場合は自動発注を実行します。高額発注・新規サプライヤー・初回取引品目は購買部門の承認フローへ自動エスカレーションします。これが現時点で最も現実的な設計です。

需要予測から発注・入荷確認・原価反映まで完全自律実行

需要予測・発注・入荷確認・受け払い元帳(在庫元帳)への反映・原価計算までエージェントが自律実行します。現時点では標準品・低リスク品目に限定して、段階的に適用することが推奨されます。

銀行口座照合（Bank Reconciliation）：Dynamics 365 Finance

シナリオは「銀行の取引明細とDynamics 365 Financeの仕訳データを照合し、差異を検出・処理する」です。月次決算の現場では非常に手間のかかる作業で、エージェント化の効果が出やすい領域です。

「未照合の取引を教えて」と頼む

Copilotが銀行明細と仕訳データを参照し、未照合リストを提示します。担当者が一件ずつ確認して手動で照合処理します。

エージェントが照合案を提示し、担当者が承認する

エージェントが銀行明細と仕訳データを自動マッチングし、照合候補を提示します。担当者が確認してOKを出したものから順次照合処理を実行します。

高精度マッチングは自動照合、差異・例外は担当者へ

金額・日付・摘要が一致する取引は自動照合します。差異がある取引・高額取引・初回取引先からの入金は担当者に提示します。月末の締め作業を大幅に短縮できます。

照合から仕訳修正・レポート生成まで完全自律実行

照合・差異分析・修正仕訳の下書き生成・経営レポートへの反映までエージェントが自律実行します。ただし修正仕訳の最終承認は監査要件上、必ず人間が行う必要があります。

Sales Order Agent・Payable Agent・Expense Agent：Dynamics 365 Business Central

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

Sales Order Agent——受注から出荷指示までの自律化

シナリオ：顧客からの注文を受け付けてから、在庫確認・出荷指示までを自律処理する

L1「この注文の在庫は足りますか？」→ Copilotが在庫状況を提示

L2受注登録後にエージェントが在庫確認・出荷可否を判定し、担当者に提示

L3在庫あり・標準顧客の受注は自動で出荷指示まで実行。在庫不足・新規顧客・大口注文は担当者確認へ

L4受注・在庫引当・出荷指示・請求書発行まで完全自律実行

Payable Agent——請求書処理から支払いまでの自律化

シナリオ：仕入先からの請求書を受け取り、照合・承認・支払い処理を自律実行する

L1「この請求書を仕訳入力して」→ Copilotが仕訳案を生成

L2請求書データを自動取り込み・仕訳生成し、担当者に承認を求める

L3発注書と一致する請求書は自動照合・承認。差異あり・高額・初回取引先は担当者確認へ

L4照合・承認・支払い実行まで自律処理。一定金額以上の支払いは承認フローが必須

Expense Agent——経費精算の自律化

シナリオ：従業員の経費申請を受け付けて、ポリシーチェック・承認・仕訳処理を自律実行する

L1「この領収書を経費申請して」→ Copilotが領収書をポータルへ　（L2からスタートする場合あり）

L2領収書がポータルへアップロードされると、エージェントが金額・カテゴリ・ポリシー適合を判定し、申請案を生成。申請者が確認して提出

L3ポリシー範囲内の経費は自動承認・仕訳処理。上限超過・例外カテゴリ・高額は上長承認フローへ自動エスカレーション

L4申請・ポリシーチェック・承認・仕訳・支払いまで完全自律実行。監査証跡は自動生成

Business Centralのエージェントが特に中堅・中小企業にとって有益なのは、Sales→Payable→Expenseという業務の流れが、ひとつのデータモデルで完結しているため、エージェントがシステムをまたがず、エンドツーエンドで動けるからです。

Role shift

「作る」から「統率する」へ——実装者の仕事が変わります

ここまで見てきたように、エージェント型AIの導入は「新しい機能を使う」という話ではありません。実装者の仕事の定義そのものが変わります。

従来のDynamics 365エンジニアは、Power Automateフローを組み、フォームをカスタマイズし、Visual Studio Codeを使ってAL言語でコードを書いていました。つまり「プロセスを作る人」でした。エージェント型の世界では、プロセスはエージェントが組み立てます。実装者の仕事は「プロセスを作ること」から「エージェントが正しく動くための環境を設計すること」にシフトします。

従来の実装者の仕事	エージェント時代の実装者の仕事
Power Automateフローを組む	どの業務をエージェントに委ねるか設計する
フォーム・ビューをカスタマイズする	自律性の段階（L1〜L4）を業務ごとに決定する
プラグイン・カスタムコードを書く	ガードレール・閾値・エスカレーションを設計する
業務要件をフローに落とし込む	Copilot Studioでエージェントを組み立てる
バグを修正する	判断ログを監視・チューニングする

では、エージェント時代に人間が担う役割とは具体的に何でしょうか。Dynamics 365の文脈で整理するとこうなります。

人間が担う役割	Dynamics 365での具体例
アーキテクチャ設計	どの業務プロセスをどのエージェントに委ねるか設計する
エージェントの統率	Copilot Studioでエージェントを組み立て・指揮する
品質管理・監督	エージェントの判断ログをレビューし、閾値・ガードレールを設定する
最終意思決定	例外処理・承認フローにおいて、人間が介在するべきポイントを設計する

これは「コードを書かなくてよくなる」という話ではありません。むしろ、業務の本質を深く理解し、AIに何を任せて何を任せないかを判断できる人材が求められるようになります。技術力よりも業務設計力、実装力よりもAI統率力が問われる時代になったという印象です。

意思決定者の視点でも同じことが言えます。「何を自動化できるか」ではなく「どこに人間の判断を残すか」を問うことが、エージェント導入の本質的な論点になります。自律化の範囲は技術の問題ではなく、経営判断の問題です

つまり、エージェントを適切に活用する為には、企業のビジネスプロセスを再構築する必要があるという事です。

Key questions

実装を始める前に問うべき3つのこと

Dynamics 365にエージェントを導入する前に、実装者・意思決定者は以下の内容を検討する必要があります。この3つへの答えが、設計の出発点になります。

このプロセスは「ルール化できるか」

エージェントが自律実行できるのは、判断基準が明確な業務です。「状況によって変わる」「経験が必要」な判断は、まだ人間が担います。銀行口座照合であれば「金額・日付・摘要が一致する取引の照合」はルール化できますが、「取引先との関係背景を踏まえた差異の判断」は、人間が担うべき領域です。

間違えたときのコストはどれくらいか

フォローメールの誤送信と、誤発注では影響の大きさが全く違います。エージェントの自律性は「失敗したときのコスト」に反比例して設計するのが原則です。Expense Agentで経費のポリシーチェックを間違えるコストと、Payable Agentで支払い処理を間違えるコストは桁が違います。同じ「自動化」でも、リスクに応じて自律性の段階を変える必要があります。

判断の根拠を説明できるか

エージェントが自律実行した結果について、「なぜそうなったか」を説明できる仕組みが必要です。ログ・監査証跡・承認記録の設計は、エージェント導入と同時に考えなければなりません。特にFinanceのBank Reconciliation（銀行口座勘定調整）やPayable Agentのような会計処理では、監査対応のために「誰が・いつ・何を判断したか」の記録が必須です。

Summary