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

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

皆さん、いかがお過ごしでしょうか？　もう、5月も終わりですね。6月は私の上司、CEOのFredyが来日するので、日本法人のメンバーは楽しみにしているようです。彼との出会いはこちらの記事に書いてある通り、バリでのマイクロソフト株式会社主催のアワードセレモニーだったのですが、気付くと長い付き合いになります。人間的にも尊敬できるのと、エンジニアバックグラウンドなので、彼の元では仕事がしやすいです。私は恵まれていますね。

さて、そのFredy（とその仲間たち）も、Agentic Engineeringの波に乗って様々な取り組みを進めています。今日は第1回に続き、第2回をお届けします。テーマは「どこに人間を置くか」です。

Series #02 — Agentic Engineering × Dynamics 365

どこに人間を置くか

Human-in-the-Loopの設計原則——エージェントと人間の役割分担を設計する

2026年5月
第2回
Dynamics 365
Agentic AI
Human-in-the-Loop

第1回では、エージェント型AIの定義と自律性の段階（L1〜L4）を整理しました。エージェントが「ゴールを渡されると自分で手順を考えて実行する」という性質を持つ以上、実装者に問われるのは「どこまで自律させるか」の設計です。しかしその問いは、もう少し具体的に言い換えられます。「どこに人間を置くか」——これがHuman-in-the-Loopの設計原則です。エージェントが自律的に動けば動くほど、「人間が介在するポイント」の設計が、システム全体の品質・リスク・説明責任を左右します。今回はこの原則をDynamics 365のCRMとERPに引き付けて、具体的に考えてみます。

Definition

そもそもHuman-in-the-Loopとは何か

Human-in-the-Loop（HITL）とは、AIや自動化システムの判断・実行プロセスの中に、人間の介在ポイントを意図的に設計する考え方です。「AIに全部任せる」でも「全部人間がやる」でもなく、「AIと人間がどう役割を分担するか」を設計することです。

重要なのは、Human-in-the-Loopは「AIを信頼していないから人間を挟む」という後ろ向きの発想ではないという点です。むしろ「AIが最も得意なことをAIにやらせ、人間が最も価値を発揮できるポイントに人間を置く」という、積極的な設計思想です。

Human-in-the-Loopには大きく3つのパターンがあります。

事前承認型（Human-in-the-Loop）

エージェントがアクションを実行する前に人間が承認します。確実性は高いですが、スピードは落ちます。高リスク・高額・対外的な影響がある業務に適しています。

事後監督型（Human-on-the-Loop）

エージェントが自律実行し、人間は事後にログや結果を監督します。スピードは上がりますが、リアルタイムの介入はできません。ルーティンで判断基準が明確な業務に適しています。

例外介入型（Human-in-the-Loop on Exception）

通常はエージェントが自律実行し、例外・異常・閾値超過のときだけ人間に通知・介入を求めます。第1回で説明したL3がこれにあたります。現時点でDynamics 365のエージェント設計で最も現実的なパターンです。

CRM — Quote approval design

CRMで考える——見積承認フローの設計

Dynamics 365 Salesを例に、見積承認フローでのHuman-in-the-Loopを考えてみましょう。見積は顧客に直接提示するものであり、金額・条件・タイミングが商談の成否を左右します。「エージェントに任せすぎた」では済まない領域です。

まず前提として、見積から受注への流れには大きく2つのパターンがあります。どちらのパターンを選ぶかによって、Human-in-the-Loopの設計も変わってきます。

パターンA：CRM起点モデル

CRM（Dynamics 365 Sales）で見積を作成し、受注確定後にERPへ受注伝票として連携する流れです。顧客接点・商談管理をCRMで一元管理したい企業、営業プロセスが複雑で複数の承認ステップが必要な企業に向いています。

顧客 → CRM（見積作成・承認） → CRM（受注） → ERP（受注伝票） → ERP（出荷・請求）

エージェントはCRM側で見積の自動生成・承認フローへの投入・ステータス管理を担います。ERPへの連携はバーチャルテーブルまたはデータ統合で自動化します。

パターンB：ERP起点モデル

ERP（Dynamics 365 Supply Chain ManagementまたはBusiness Central）で見積・受注をすべて処理する流れです。製造業・卸売業など、在庫・原価・納期の精度が商談の中心になる企業に向いています。

顧客 → ERP（見積作成・承認） → ERP（受注伝票） → ERP（出荷・請求）

エージェントはERP側で在庫確認・原価計算・納期回答・受注登録まで一貫して担います。CRMは顧客情報の参照元として連携しますが、トランザクションの主体はERPです。

両パターンに共通するHuman-in-the-Loopの介在ポイント

介在ポイント①：見積金額の閾値設計

見積金額によって承認フローを変えるのが最もシンプルな設計です。

→100万円未満：エージェントが自動生成・送付（事後監督型）

→100万円〜500万円：担当者が確認・承認後に送付（事前承認型）

→500万円超：担当者＋マネージャーの二段階承認（事前承認型）

金額の閾値はビジネスの規模・業種によって変わりますが、「閾値を設計する」という行為そのものが、実装者の重要な仕事です。

介在ポイント②：顧客セグメントによる分岐

→既存顧客・標準製品：エージェントが自動生成・送付

→新規顧客：担当者確認を必須とする

→VIP・戦略顧客：担当者＋営業マネージャーの確認を必須とする

→クレーム履歴あり：必ず人間がレビューしてから送付

パターンAではCustomer Insightsのセグメントデータと連携してこの分岐を自動判定できます。パターンBではERPの顧客マスタの与信情報・取引区分と連携して判定します。

介在ポイント③：カスタム条件・特別値引きの検知

標準価格から一定割合を超える値引きや、通常の契約条件と異なる条件が含まれる場合は、自動的に承認フローに乗せる設計が重要です。エージェントは「異常値の検知」は得意ですが、「その異常値を受け入れるかどうかの判断」は人間が担うべき領域です。

パターン別の設計上の注意点

パターンAではCRMとERPをまたぐデータ連携の設計が鍵になります。見積がCRMで承認された後、ERPの受注伝票に正確に変換されるマッピング設計と、原価・在庫はERPのデータを正として返すバーチャルテーブル連携が必要です。パターンBではERPの中でエージェントが完結して動くため、データ連携の複雑さは下がりますが、顧客とのコミュニケーション履歴・商談情報をどこで管理するかを明確にしておく必要があります。

実装のポイント

どちらのパターンでも、エージェントはCopilot Studioで組み立て、承認フローはPower AutomateのApprovalコネクタと組み合わせるのが現実的な実装です。承認者へのTeams通知・メール通知・モバイル承認まで一連の流れを設計できます。

CRM — Credit management

与信管理はCRMとERPどちらで行うか

見積・受注の承認フローを設計する上で、避けて通れないのが「与信管理をどこでやるか」という問いです。これはシステムの役割分担に直結する設計判断です。

与信管理をERPで行う場合

Dynamics 365 Finance・Supply Chain Management・Business Centralはいずれも与信管理機能を持っています。顧客ごとに与信限度額を設定し、受注金額が限度額を超えた場合に自動的に保留・エスカレーションする仕組みが標準で組み込まれています。

この場合、エージェントはERP側の与信情報をリアルタイムで参照しながら受注処理を進め、与信超過を検知した時点で自動的に承認フローへエスカレーションします。与信の「事実」はERPが持ち、判断はエージェントが自動化するという構造です。ERPで与信管理を行うのが適しているのは、製造業・卸売業など取引金額が大きく、財務部門が与信を一元管理したい企業です。

与信管理をCRMで行う場合

Dynamics 365 Salesでも顧客（Account）に対して与信に関連する情報を持つことはできますが、ERPほど精緻な与信管理機能はありません。CRMで与信管理を行う場合は、カスタムフィールドや外部与信サービスとの連携で補完するケースが多くなります。

CRMで与信情報を持つメリットは、営業担当者が商談の初期段階から与信状況を確認しながら活動できることです。「この顧客はそもそも与信が通るか」を商談開始時点でエージェントが自動チェックし、与信リスクが高い場合は早い段階でアラートを出す設計が可能です。

推奨パターン：ERPをマスターとしてCRMに返す

実務的に最も合理的な設計は、与信のマスターデータはERPで管理し、バーチャルテーブル経由でCRMのエージェントがリアルタイムに参照する形です。

→与信限度額・残高・超過状況：ERPが保持（データの正）

→営業担当者・CRMエージェントからの参照：バーチャルテーブル経由でリアルタイム取得

→与信超過の検知・承認フロー起動：エージェントが自動実行

この設計により、CRM側のエージェントが見積を生成する時点で与信状況を自動チェックし、問題があれば承認フローへ自動エスカレーションするという、シームレスなHuman-in-the-Loopが実現できます。見積承認フローと与信管理が一体となって機能することで、「与信が通らない顧客への見積送付」という実務上のミスをエージェントが防いでくれます。

ERP — Purchase order threshold design

ERPで考える——発注閾値設計の原則

次にDynamics 365のERP領域でのHuman-in-the-Loopを考えてみましょう。発注処理はCRMの見積と異なり、直接財務・在庫・サプライヤー関係に影響します。「エージェントが誤発注した」では済まない領域です。

閾値設計の3つの軸

発注処理のHuman-in-the-Loopを設計するとき、閾値は1つではありません。少なくとも次の3つの軸で考える必要があります。

軸① 金額

10万円未満：自動発注

10〜100万円：担当者承認

100万円超：二段階承認

軸② 取引先

既存：自動発注

新規：担当者確認必須

海外：リスク判断を人間が行う

軸③ 品目

標準品：自動発注

特注・長納期品：担当者確認

規制品目：必ず人間が承認

実際の設計では、この3つの軸を組み合わせてエスカレーション条件を定義します。たとえば「既存サプライヤーへの標準品の発注であっても、金額が100万円を超える場合は承認フローへ」というように、複数条件のAND・ORで閾値を設計します。エージェントはこの条件を自動判定し、自律実行か承認フローへのエスカレーションかを瞬時に振り分けます。

SCM・Finance・Business Centralでの実装の違い

Supply Chain Management：購買ポリシー（Purchasing Policy）と承認ワークフローを組み合わせて閾値を設定します。エージェントはこのポリシーをリアルタイムで参照しながら発注の可否を判断します。

Finance：支出管理ポリシーと連動した承認フローが組み込まれています。発注金額・勘定科目・部門コードの組み合わせで承認者を自動決定する設計が可能です。

Business Central：Approval Workflowを使って閾値・承認者・エスカレーション先を設定します。中堅・中小企業向けにシンプルな設定で実装できるのが特徴です。Payable AgentやSales Order Agentはこのワークフローと連動して動きます。

Common pitfalls

Human-in-the-Loopの設計で陥りやすい3つの罠

Human-in-the-Loopの設計は、原則を理解しているだけでは不十分です。実装の現場では、理屈では正しいはずの設計が機能しないケースが少なくありません。よくある3つの罠を紹介します。

承認フローが多すぎて、誰も承認しなくなる

「リスクが怖いから、とりあえず全部承認フローに乗せよう」という発想で設計すると、承認者が毎日大量の承認依頼に埋もれ、形骸化します。承認フローの件数は「多いほど安全」ではなく「多いほど形骸化リスクが高い」という逆説を意識してください。エージェントが自律実行できる範囲を広げ、本当に人間の判断が必要なケースだけに承認フローを絞り込むことが重要です。

閾値を設定したまま見直さない

最初に設定した金額閾値・顧客セグメント・品目区分は、ビジネスの変化とともに陳腐化します。エージェントの判断ログを定期的にレビューし、「承認フローに上がってきた案件のうち、何割が実際に却下されたか」を確認することが重要です。却下率が極めて低い場合、その閾値は下げられる可能性があります。閾値は「設定して終わり」ではなく、継続的にチューニングするものです。

人間の介在ポイントが「責任の所在」になっていない

承認フローを設計したにもかかわらず、「誰が最終的に責任を持つか」が曖昧なまま運用されるケースがあります。「この承認ボタンを押すということは、この内容に責任を持つということだ」という意味を承認者が明確に理解できるUIと運用設計が必要です。承認画面にエージェントの判断根拠・参照データ・リスク情報を明示することで、承認者が「意味のある判断」を下せる環境を作ることが重要です。

Summary