アシスタント（提案型）

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

実行補助（確認型）

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

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

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

完全自律実行（監督型）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

L1「この領収書を経費申請して」→ Copilotが申請フォームを自動入力

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

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

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

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

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

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

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

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

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

Agentic Engineeringとは何か——「作る」から「統率する」へ ← 本記事

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

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

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

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

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

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