AIエージェントに部門横断の仕事を任せる｜案件の担当・待ち状態・完了条件
複数部署が関わる仕事をAIエージェントへ任せる際の設計を解説。Copilot Studioの10月15日の発表を手がかりに、案件番号、次の担当、返答待ち、同時更新、完了条件を具体的な例で整理します。
問い合わせを受け、営業へ確認し、技術担当の回答を待って、お客様へ連絡する。企業の仕事には、一人との会話だけでは終わらないものが数多くあります。AIエージェントをこうした業務に組み込むなら、返答の上手さに加えて、今は誰の対応待ちで、何がそろえば次へ進めるかを共有できる設計が必要です。
この記事では、部門をまたぐ一つの案件を最後まで進めるための管理方法を整理します。AIの定時起動や記憶の保存そのものではなく、複数の人が同じ仕事に関わるときの進行ルールがテーマです。
Microsoftが発表した、組織の共有業務を担うエージェント
Microsoftは2026年10月15日、Copilot Studioで組織の共有業務を継続して担うエージェントに向け、専用アカウント、業務の文脈を引き継ぐ記憶、外部の出来事や設定した周期を起点にするトリガーを紹介しました。記事ではFrontierプログラムを通じた展開と説明しており、すべての組織で一律に利用できるという発表ではありません。また、改善案を作成者へ提案する機能などは今後の予定として区別されています。Microsoft公式発表
発表日・内容は2026年10月16日に確認しました。以下の案件例と運用手順は、この動向を踏まえたIvyLeapの設計提案です。Microsoft製品の実装手順や、当社の導入実績を示すものではありません。
一つの案件に、共通の番号と次の担当を置く
たとえば、AIコールが受けた「既存サービスの利用拠点を追加したい」という相談を考えます。営業が利用条件を確認し、技術担当が対応可否を調べ、窓口が回答する架空の業務です。
電話、メール、社内チャットを別々の依頼として扱うと、同じ相談への回答が重複したり、後から届いた訂正を見落としたりします。入口が異なっても、同じ案件番号へ結び付ける仕組みを先に用意します。氏名だけで自動的に同一案件と決めず、受付番号や確認済みの依頼内容で照合し、曖昧な場合は担当者へ確認します。
共有する案件票には、次の項目を持たせます。
- 案件番号と目的：何について、どの結果を届ける仕事か。
- 現在の状態：受付済み、情報不足、社内確認中、回答準備、完了など。
- 次に動く担当：部署名だけでなく、引き受けた担当者または担当窓口。
- 待っている情報：何の回答が不足しており、誰へ依頼したか。
- 確認期限と代替担当：いつ確認し、応答がないとき誰へ渡すか。
- 完了の根拠：何を確認できれば仕事を閉じられるか。
AIは案件票の作成や不足項目の整理を担い、人が引き受ける工程では受領を確認します。「チャットへ送った」だけで担当の移管が終わった扱いにしないことがポイントです。
返答待ちは、放置でも失敗でもない
技術担当の確認が必要な間、AIが同じ質問を繰り返したり、回答を推測して進めたりしないようにします。「社内確認中」という状態に、必要な返答と再確認する時刻をセットで残します。
先ほどの例なら、「追加拠点の対応可否を技術窓口へ確認中。回答後に営業が条件を整理する」と記録します。ここでAIができるのは、進行状況の案内や不足資料の整理まで。提供の可否や約束できる日程は、所定の確認を経てから案内するルールです。
期限を超えた場合も、同じ担当への催促を無制限に続ける設計にはしません。再通知の回数、代替担当、依頼者へ伝える内容を決めます。期限は社内の対応体制に合わせて定め、守れない回答時刻をAIが独自に約束しないようにします。
定期的な確認の動かし方は、AIエージェントの定期実行で別に解説しています。起動の仕組みと、案件がどの状態にあるかは分けて管理します。
複数人の更新がぶつかったら、最新の案件票を確認する
営業が「追加は二拠点」と記録した直後に、お客様から「一拠点へ変更」とメールが届く場合があります。古い情報を基にAIが確認依頼を送り続けると、社内の検討結果とお客様の希望がずれます。
対策として、案件票に更新番号を付け、重要な処理の直前に読み直す方法が考えられます。回答案を作った時点と送信前で更新番号が異なれば、そのまま送らず変更点を確認します。古い依頼は「取消」「再確認が必要」などと明示し、どの条件が現在有効かを一つにそろえます。
届く順番だけで判断しないことも大切です。遅れて届いた過去のメールと、新しい変更依頼を区別する必要があります。同じ通知を二度受け取った場合は、通知の識別番号と処理済み記録を確認し、同じ依頼や送信を増やさないようにします。
「回答を作った」と「案件が終わった」を分ける
完了条件が曖昧なままだと、AIは回答文を作成した時点で仕事を終え、人はまだ承認待ちだと考える可能性があります。案件の目的に合わせて、閉じる条件を明文化します。
拠点追加の可否を回答する相談なら、たとえば「必要な部署の確認がそろった」「回答内容を担当者が承認した」「指定した連絡先への送信結果を確認した」が完了条件になります。実際の拠点追加作業まで依頼されている場合は、回答の送信だけでは完了になりません。
送信結果が不明なときは、「完了」ではなく「送信確認待ち」として残します。同じ文章を再送する前に送信履歴を調べる工程を設けます。担当者が途中で交代しても、未完了の理由と次の行動が分かる状態を目指します。
最初の試運転で確かめる五つの場面
導入前には、正常な流れだけでなく、次の場面を用意して動作を確認します。外部へ実送信しない検証環境で行う方法が適しています。
- 担当者が不在：代替担当へ渡り、元の担当と二重に処理しないか。
- 途中で条件が変わる：以前の回答案を止め、関連する部署へ変更が届くか。
- 同じ通知が再到着する：新しい案件や重複した確認依頼を作らないか。
- 一部の部署だけ回答する：不足項目を残し、全部そろったと誤認しないか。
- 最終送信の結果が分からない：完了にせず、確認担当へ引き継げるか。
各場面では、画面に自然な文章が出るかだけでなく、案件票の状態と担当が期待どおり変わったかを確認します。評価用に案件番号、入力した出来事、期待する状態、実際の状態を残しておくと、修正後にも同じ条件で比べられます。
小さな共有業務から、責任のつながりを作る
最初の対象には、関係する部署と確認項目を説明できる業務を選びます。「問い合わせ対応を全部任せる」より、「受付後、二つの確認を集め、担当者の承認を経て回答する」と範囲を定める方が、止まる場所と完了条件を確認しやすくなります。
IvyLeapでは、AIエージェント構築・業務自動化支援とAIコール・AIテレアポ導入支援を案内しています。電話受付から社内確認までをつなぎたい場合は、現在の担当分担や案件票を基に、お問い合わせからご相談ください。