Microsoft Agent Frameworkの「Handoff orchestration」は、複数のAIエージェントが会話やタスクの文脈に応じて担当を引き継ぐための仕組みです。2026年5月11日に更新されたMicrosoft Learn公式情報では、ハンドオフの基本動作だけでなく、Agent-as-Toolsとの違い、対話型実行、自律モード、ツール承認、チェックポイント、コンテキスト同期まで整理されています。(Microsoft Learn)
結論から言うと、この更新は一般ユーザーがMicrosoft 365やCopilotの画面で何かを設定する類の変更ではありません。影響が大きいのは、Microsoft Agent Frameworkでカスタマーサポート、社内ヘルプデスク、業務エージェント、Copilot風の独自AIアプリを開発・運用している管理者や開発者です。特に「どのエージェントに制御を渡すか」「人間の承認をどこで挟むか」「会話履歴をどう同期するか」を設計し直す必要があります。
Microsoft Agent Framework Handoffとは何か
Microsoft Agent Framework Handoffは、ユーザーの依頼内容や会話の文脈に応じて、あるエージェントから別のエージェントへ制御を渡すオーケストレーション方式です。Microsoftの公式説明では、カスタマーサポート、エキスパートシステム、動的な委任が必要なシナリオで特に有用とされています。(Microsoft Learn)
分かりやすく言えば、「最初の受付担当AIが内容を見て、返品担当AI、配送担当AI、返金担当AIへ引き継ぐ」ような構成です。
たとえばECサイトの問い合わせでは、次のように役割を分けられます。
| エージェント | 主な役割 | ハンドオフの例 |
|---|---|---|
| triage_agent | 問い合わせ内容の分類 | 「配送の相談なので order_agent に渡す」 |
| order_agent | 注文状況・配送確認 | 「返品希望に変わったので return_agent に戻す」 |
| return_agent | 返品手続き | 「返品後の返金なので refund_agent に渡す」 |
| refund_agent | 返金処理 | 「追加確認が必要なので triage_agent に戻す」 |
ポイントは、中央のオーケストレーターが常に命令するのではなく、エージェント同士がメッシュ状につながり、各エージェントがルールやメッセージ内容に基づいて引き継ぎを判断する点です。(Microsoft Learn)
今回の公式情報で押さえるべき変更点・整理点
2026年5月11日更新の公式ページで重要なのは、「Handoffは単なるマルチエージェント連携ではない」という点が明確に説明されていることです。特に、Agent-as-Toolsとの違い、対話型ワークフロー、自律モード、承認フロー、チェックポイント処理が実装上の判断材料になります。(Microsoft Learn)
Handoffは「担当者交代」、Agent-as-Toolsは「部下に作業を依頼」
HandoffとAgent-as-Toolsは見た目が似ていますが、設計思想は異なります。
| 比較項目 | Handoff orchestration | Agent-as-Tools |
|---|---|---|
| 制御の流れ | エージェント間で制御を明示的に渡す | 主エージェントが他エージェントをツールとして呼ぶ |
| タスクの所有権 | 引き継ぎ先エージェントがタスクを引き受ける | 主エージェントが全体責任を持つ |
| コンテキスト管理 | 会話全体を引き継ぎ先が扱う | 主エージェントが必要情報だけを渡す場合がある |
| 向いている用途 | 問い合わせ窓口、専門担当の切り替え | 主要エージェントが一部処理だけを外注する用途 |
たとえば「ユーザーの相談内容が、配送、返品、返金のどれに変わるか分からない」場合はHandoffが向いています。一方で「主エージェントが文章を作り、別エージェントに翻訳だけ依頼する」ような処理はAgent-as-Toolsの方が自然です。
影響範囲：誰が何を確認すべきか
今回のMicrosoft Agent Framework Handoffの更新は、すべてのMicrosoft利用者に直接影響するものではありません。影響範囲は、Agent Frameworkを使ってAIエージェントアプリやワークフローを構築している組織に限定して考えるのが現実的です。
| 対象者 | 影響 | 確認すべきこと |
|---|---|---|
| 一般利用者 | 直接の操作変更は基本的にない | 利用中のAIアプリで担当切り替えや承認画面が増える可能性 |
| Microsoft 365/Copilot管理者 | 独自AIエージェント連携を導入している場合に影響 | データ共有範囲、承認フロー、ログ取得方針 |
| Azure/AI基盤管理者 | 認証・モデル接続・権限管理に影響 | Managed Identity、環境変数、資格情報の扱い |
| 開発者 | 実装設計に大きく影響 | HandoffBuilder、handoffルール、HITL、checkpoint設定 |
| セキュリティ担当 | ツール実行とデータ共有に影響 | 承認必須ツール、外部連携、監査ログ |
特に注意したいのは、Handoffでは「誰が最終的に応答したか」だけでなく、「どのエージェントからどのエージェントへ制御が渡ったか」を運用上追跡できる設計が必要になることです。問い合わせ対応や社内業務で使う場合、誤った担当エージェントへ渡ると、回答品質だけでなく権限逸脱やデータ漏えいのリスクにもつながります。
管理者が確認すべき設定・運用ポイント
エージェント間の引き継ぎルールを明文化する
Handoffでは、既定で全エージェントが互いにハンドオフできる構成も可能ですが、業務システムでは無制限に引き継がせない方が安全です。公式例でも、add_handoff()を使って「triage_agentから直接refund_agentへは渡さない」「return_agentからrefund_agentへ渡す」といったルールを設定する例が示されています。(Microsoft Learn)
実務では、次のようなルール設計が必要です。
| 業務シーン | 推奨される設計 |
|---|---|
| 返金・解約・契約変更 | 一次受付から直接実行担当へ渡さず、確認担当を挟む |
| 社内ITヘルプデスク | アカウント、端末、ネットワークなど担当別に分ける |
| 人事・労務問い合わせ | 個人情報を扱うエージェントへの遷移を限定する |
| 営業支援 | 顧客情報を扱うエージェントと一般FAQエージェントを分離する |
「便利だから全エージェントを相互接続する」ではなく、「業務上あり得る遷移だけを許可する」と考えるべきです。
本番環境ではDefaultAzureCredentialの扱いに注意する
公式サンプルではAzure OpenAIクライアント設定にDefaultAzureCredentialが登場しますが、Microsoftは本番環境では慎重な検討が必要とし、ManagedIdentityCredentialなど特定の資格情報の利用を検討するよう注意しています。理由として、待機時間、意図しない資格情報探索、フォールバック機構によるセキュリティリスクが挙げられています。(Microsoft Learn)
管理者は、少なくとも次の点を確認してください。
| 確認項目 | 実務上の判断基準 |
|---|---|
| 認証方式 | 開発環境と本番環境で認証方式を分ける |
| 環境変数 | AZURE_OPENAI_ENDPOINTなどを平文で不用意に共有しない |
| 権限 | エージェントごとに必要最小限の権限を割り当てる |
| 監査 | どのエージェントがどのツールを呼んだか記録する |
| 障害対応 | 資格情報探索による遅延や失敗をログで確認できるようにする |
Handoffは複数エージェントが関与するため、単一エージェント構成よりも「どの権限で、どの処理が動いたか」が見えにくくなります。認証と監査を後回しにすると、検証段階では動いても本番展開で問題が出やすくなります。
開発者が確認すべき実装ポイント
HandoffはAgentのみをサポートし、ローカルツール実行が必要
公式情報では、Handoff orchestrationはAgentのみをサポートし、エージェントがローカルツール実行をサポートしている必要があるとされています。(Microsoft Learn)
これは移行時に重要です。既存のワークフロー内で関数、ツール、独自ラッパー、外部エージェントを組み合わせている場合、そのままHandoffに載せ替えられるとは限りません。
確認すべき観点は次の通りです。
| 確認項目 | チェック内容 |
|---|---|
| エージェント種別 | Handoff対象がAgentとして扱えるか |
| ツール実行 | ローカルツール実行に対応しているか |
| 引き継ぎ先 | すべての遷移先エージェントが定義済みか |
| 会話履歴 | 引き継ぎ後に必要な文脈が失われないか |
| 出力処理 | ストリーミング時の応答表示を適切に処理できるか |
HandoffBuilderと開始エージェントを設計する
Python側の公式例では、HandoffBuilderで参加エージェントを指定し、with_start_agent()で最初にユーザー入力を受け取るエージェントを定義します。さらにadd_handoff()で特定のハンドオフ関係を設定できます。(Microsoft Learn)
実務では、最初に受けるエージェントを「何でも答える万能AI」にしない方が安全です。おすすめは、最初のエージェントをトリアージ専用にする構成です。
ユーザー
↓
triage_agent（分類・聞き返し）
↓
order_agent / return_agent / refund_agent / faq_agent
↓
必要に応じて triage_agent に戻すこの設計にすると、ユーザーの意図が曖昧なときに専門エージェントが勝手に処理を進めるリスクを下げられます。
ハンドオフしない場合は人間の入力が必要になる
Handoffは他のオーケストレーションと異なり、エージェントが毎ターン必ずハンドオフするとは限りません。エージェントがハンドオフしない場合、ワークフローはtype="request_info"のWorkflowEventとHandoffAgentUserRequestを出力し、ユーザーの応答を待って継続します。(Microsoft Learn)
この仕様はUI設計に直結します。チャットUIや業務アプリに組み込む場合、以下を実装しないと会話が途中で止まったように見える可能性があります。
| 必要な実装 | 目的 |
|---|---|
| pending requestの表示 | どのエージェントが入力待ちか分かるようにする |
| ユーザー応答の送信 | HandoffAgentUserRequest.create_response()相当の処理 |
| 終了操作 | ユーザーが会話を打ち切れる導線 |
| タイムアウト設計 | 放置されたワークフローの扱いを決める |
| 再開処理 | 承認待ち・入力待ちから復帰できるようにする |
「AIが自動で最後まで処理する」と思って設計すると、Handoffの対話型仕様とずれます。ユーザー入力を待つ場面を、正常なワークフローの一部として扱うことが重要です。
自律モードは便利だが、本番では慎重に使う
公式情報では、Handoff orchestrationは本来、人間の入力が必要になる対話型シナリオ向けとされています。ただし実験的機能としてwith_autonomous_mode()を使うと、エージェントがハンドオフしない場合でも既定メッセージを自動送信し、人間の介入なしに継続できます。(Microsoft Learn)
自律モードは、PoCや社内検証では便利です。一方で、本番環境では「ユーザーが返答していないのにAIが判断を進める」状態になるため、次のようなリスクがあります。
| リスク | 具体例 | 対策 |
|---|---|---|
| 誤判断の継続 | 曖昧な問い合わせを勝手に返金処理へ進める | 自律モード対象をtriage_agentなどに限定する |
| 無限に近い会話継続 | エージェント同士が判断を続ける | turn limitを設定する |
| 責任所在の不明確化 | 人間が承認していない判断が実行される | 機密操作にはツール承認を必須にする |
| UXの違和感 | ユーザー不在なのに会話が進む | 自動継続時の文言を明示する |
公式例では、自律モードを一部エージェントに限定したり、既定メッセージをカスタマイズしたり、自律実行できるターン数を制限したりする設定が示されています。(Microsoft Learn)
機密操作にはツール承認を必ず組み込む
Handoffワークフローでは、実行前に人間の承認を必要とするツールを持つエージェントを含めることができます。公式情報では、返金処理、購入、元に戻せない操作などに有効とされています。(Microsoft Learn)
たとえば、返金処理ツールに@tool(approval_mode="always_require")を設定すれば、エージェントがツールを呼び出そうとした時点で承認要求を出せます。承認が必要なツール呼び出しでは、function_approval_requestとして要求が出力され、承認・却下の応答を返す流れになります。(Microsoft Learn)
本番環境では、次の操作を「承認必須」にするのが現実的です。
| 承認必須にすべき操作 | 理由 |
|---|---|
| 返金・支払い・購入 | 金銭的損失につながる |
| 契約変更・解約 | 顧客影響が大きい |
| ユーザー権限変更 | セキュリティ事故につながる |
| 個人情報の外部送信 | コンプライアンスリスクがある |
| データ削除・更新 | 復旧が難しい場合がある |
Handoffでは、担当エージェントが切り替わることで、ユーザーも管理者も「いつ重要操作に到達したか」を見落としやすくなります。承認イベントをUI上で分かりやすく表示し、承認者、時刻、引数、結果を記録する設計が必要です。
長時間処理にはチェックポイントを使う
返金承認や本人確認のように、承認が数時間後または数日後になるワークフローでは、チェックポイント処理が重要です。公式情報では、checkpoint_storage=をHandoffBuilderに渡すことで、プロセス再起動をまたいで一時停止・再開できる永続的なワークフローを構成できると説明されています。(Microsoft Learn)
開発者は、次のようなケースでチェックポイントを検討してください。
| ケース | チェックポイントが必要な理由 |
|---|---|
| 管理者承認待ち | 承認者がすぐに対応するとは限らない |
| ユーザーの追加情報待ち | 写真、注文番号、本人確認情報などを後で受け取る |
| 外部システム連携 | API応答やバッチ処理を待つ場合がある |
| 長時間チャット | プロセス再起動で会話状態を失うと復旧できない |
PoCではメモリ上で動いても、本番ではアプリ再起動、障害、デプロイ、スケールアウトが発生します。Handoffを業務処理に使うなら、承認待ちや入力待ちの状態を保存できるかを早めに確認してください。
コンテキスト同期で注意すべきこと
Handoff orchestrationでは、各エージェントは同じAgentSessionインスタンスを共有しません。代わりに、参加エージェントが応答やユーザー入力を他の参加者にブロードキャストし、次のターンに必要な文脈を保つ仕組みです。(Microsoft Learn)
ただし、ツール関連のコンテンツ、ハンドオフツール呼び出しを含む内容は他エージェントにブロードキャストされません。同期されるのは、ユーザーとエージェントのメッセージです。(Microsoft Learn)
この点は、実装上かなり重要です。
たとえば、返金エージェントが内部ツールで「与信確認結果」を取得したとしても、そのツール結果が他エージェントにそのまま同期されるとは限りません。次の担当エージェントに必要な情報は、エージェントの応答や明示的な状態管理に反映させる必要があります。
| 注意点 | 起こりやすい問題 | 対策 |
|---|---|---|
| ツール結果は自動共有されない | 次のエージェントが判断材料を持たない | 必要な要約をメッセージや状態に残す |
| セッションは共有されない | エージェントごとに履歴解釈が変わる | 重要情報を構造化して管理する |
| 全文脈が増え続ける | トークン消費や応答遅延が増える | 引き継ぎ用サマリーを設計する |
| 個人情報が広く共有される | 不要なエージェントまで情報を知る | エージェント設計とマスキングを行う |
Handoffは「担当者交代」に近い仕組みですが、人間の業務引き継ぎと同じで、必要な情報を正しく残さないと品質が落ちます。
HandoffAgentExecutorの役割
公式情報では、Handoff orchestrationは標準ワークフローと異なり、専用のHandoffAgentExecutorを使うと説明されています。このExecutorは、構成されたハンドオフルールに基づいてハンドオフツールを自動登録し、エージェント応答内のハンドオフツール呼び出しを検出し、制御を対象エージェントへルーティングします。さらに、次のエージェントへ渡す前にハンドオフ関連の関数呼び出しやツール結果を会話履歴から除外し、モデルが内部処理に混乱しないようにします。(Microsoft Learn)
開発者にとっては、次の理解が重要です。
- ハンドオフは単なる文字列メッセージの転送ではない
- ハンドオフ用ツール呼び出しによって制御移譲が発生する
- 内部的なハンドオフ処理は、次のエージェントの会話履歴からフィルタリングされる
- そのため、デバッグ時は「表示される会話」と「内部イベント」を分けて確認する必要がある
トラブルシューティングでは、最終応答だけを見るのではなく、executor_id、request_info、output、承認要求、チェックポイントIDなどをログに残すと原因を追いやすくなります。
移行・展開時の実践チェックリスト
既存の単一エージェント構成やAgent-as-Tools構成からHandoffへ移行する場合は、いきなり本番業務へ適用せず、小さな業務領域で検証するのが安全です。
| フェーズ | 確認項目 | 合格基準 |
|---|---|---|
| 設計 | エージェントの責任範囲 | 1エージェント1責任で説明できる |
| 設計 | ハンドオフルール | 業務上不要な遷移がない |
| 実装 | 開始エージェント | 受付・分類役が明確 |
| 実装 | ユーザー入力待ち | request_infoをUIで処理できる |
| 実装 | 機密ツール | 承認必須になっている |
| 運用 | ログ | 誰が、いつ、どのツールを呼んだか追跡できる |
| 運用 | 再開 | チェックポイントから復帰できる |
| セキュリティ | 権限 | エージェントごとに必要最小限 |
| UX | 引き継ぎ表示 | 利用者が担当切り替えを理解できる |
特に失敗しやすいのは、次の3つです。
すべてのエージェントを相互接続してしまう
検証では便利ですが、本番では誤ルーティングの原因になります。返金、契約、個人情報、権限変更などの担当エージェントには、必ず明示的な遷移条件を設けてください。
自律モードに頼りすぎる
自律モードは実験的機能として説明されています。人間が返答していない状態でも処理が進むため、問い合わせ対応の自動化では便利でも、金銭・契約・権限操作ではリスクが高くなります。(Microsoft Learn)
ツール結果が共有される前提で設計する
Handoffではユーザーとエージェントのメッセージは同期されますが、ツール関連コンテンツは他エージェントにブロードキャストされません。重要な結果は、引き継ぎ用の要約や状態管理に明示的に残す必要があります。(Microsoft Learn)
どのようなシナリオでHandoffを使うべきか
Handoffは、エージェントごとの専門性が明確で、ユーザーとの会話中に担当が変わる業務に向いています。
| 向いているシナリオ | 理由 |
|---|---|
| カスタマーサポート | 問い合わせ内容に応じて担当が変わる |
| 社内ヘルプデスク | アカウント、端末、ネットワークなど専門領域が分かれる |
| 法務・人事・経理の一次対応 | 内容分類後に専門担当へ渡せる |
| 教育・チューターAI | 数学、歴史、文章添削など分野別に担当できる |
| 業務申請サポート | 申請内容により承認・確認フローが変わる |
反対に、処理順序が最初から決まっている業務は、シーケンシャルワークフローの方が分かりやすい場合があります。複数エージェントが同じ会話内で協議する必要があるなら、グループチャット型の方が適している可能性もあります。Agent Frameworkには、シーケンシャル、並行、ハンドオフ、グループチャット、Magenticなど複数のオーケストレーションパターンが用意されています。(Microsoft Learn)
管理者・開発者が次に取るべき行動
Microsoft Agent Framework Handoffを検討している組織は、まず「AIに任せたい業務」ではなく「どの担当に、どの条件で引き継ぐべきか」から設計してください。
最初にやるべきことは、次の5つです。
- 対象業務を1つに絞る
例：EC問い合わせ、社内ITヘルプデスク、申請サポートなど。 - エージェントの責任範囲を分ける
「受付」「配送」「返品」「返金」のように、業務担当として説明できる粒度にします。 - ハンドオフルールを表にする
どのエージェントからどのエージェントへ渡せるかを、業務ルールとして確認します。 - 承認が必要なツールを洗い出す
返金、削除、契約変更、権限変更などは人間の承認を必須にします。 - ログ・再開・権限を本番前に確認する
Handoffは複数エージェントが関わるため、後からログを足すのではなく、最初から監査とチェックポイントを設計します。
Microsoft Agent Framework Handoffは、AIエージェントを「単体のチャットボット」から「担当者が連携する業務システム」に近づける仕組みです。便利さだけで導入するのではなく、引き継ぎルール、承認、コンテキスト同期、再開処理をセットで設計することが、本番展開で失敗しないための最重要ポイントです。
コメント