Microsoft の「Human-in-the-Loop with AG-UI」は、AIエージェントがメール送信、送金、削除、契約変更のような影響の大きいツールを実行する前に、人間の承認を挟むための実装パターンです。2026年6月26日に更新された Microsoft Learn の公式情報では、AG-UI プロトコルを使ってツール実行の承認ワークフローを実装する方法が整理されています。重要なのは、これは Microsoft 365 管理センターのような画面で一括設定する新機能ではなく、Microsoft Agent Framework や AG-UI を使って AI エージェントアプリを開発・運用する組織向けの設計・実装上の更新点だということです。(Microsoft Learn)
管理者や開発責任者がまず確認すべきことは、「どのツール実行に承認を必須にするか」「承認ログをどこに残すか」「承認 UI がユーザーに十分な判断材料を出しているか」の3点です。現時点の公式情報では、この更新に伴う強制的な移行期限やテナント全体の設定変更は示されていません。ただし、エージェントが外部送信、データ更新、金銭処理、権限変更を行う場合は、本番投入前に Human-in-the-Loop の設計を入れておくべきです。
Microsoft の新機能・変更点：「Human-in-the-Loop with AG-UI」で確認すべきポイント
Microsoft Learn の「Human-in-the-Loop with AG-UI」は、AG-UI 経由で AI エージェントのツール実行を承認制にするためのチュートリアルです。AG-UI は、Web クライアントやモバイルアプリから AI エージェントを利用するためのプロトコルで、リアルタイムストリーミング、セッション管理、状態同期、Human-in-the-Loop 承認などを扱えます。(Microsoft Learn)
今回の更新ポイントを一言でまとめると、AIエージェントが「実行してよいか」を人間に確認し、承認または却下の結果を受け取ってから処理を続ける仕組みが、AG-UI の文脈で具体化されたということです。
たとえば、ユーザーがエージェントに次のように依頼したとします。
取引先に見積書をメールで送って
休眠アカウントを削除して
顧客Aの契約プランを変更して
口座Aから口座Bへ500ドル送金して
通常のツール実行型エージェントでは、モデルがツール呼び出しを判断すると、そのまま関数が実行される設計になりがちです。しかし Human-in-the-Loop を入れると、実行前に「どのツールを、どの引数で、何のために実行しようとしているか」をユーザーに表示し、承認された場合だけ実行できます。Microsoft の公式ドキュメントでも、金融取引、データ変更、重大な結果を伴う操作のような場面で、人間による承認が重要だと説明されています。(Microsoft Learn)
Human-in-the-Loop with AG-UI とは
Human-in-the-Loop、略して HITL は、AI がすべてを自動実行するのではなく、重要な判断点で人間を処理フローに参加させる考え方です。
AG-UI での Human-in-the-Loop は、主に次の流れで動きます。
| 段階 | 何が起きるか | 実務上の意味 |
|---|---|---|
| エージェントがツール実行を判断 | 例：send_email や transfer_money を呼び出そうとする | AI が「必要な操作」を選ぶ |
| 承認リクエストを生成 | ツール名、引数、承認 ID などをクライアントへ渡す | ユーザーに判断材料を提示する |
| クライアントが承認 UI を表示 | 「承認」「却下」を選ばせる | 実行責任を人間が確認する |
| 承認結果を返す | approved: true または false を返す | 処理を進めるか止めるかを決める |
| エージェントが再開 | 承認済みなら実行、却下なら中止または別案を提示 | 暴走や誤操作を防ぐ |
Microsoft Learn では、AG-UI の Human-in-the-Loop は、エージェントが通常どおりツール呼び出しを生成し、サーバーが即時実行の代わりに承認リクエストをクライアントへ送り、ユーザーの承認・却下を受け取って処理を続ける流れとして説明されています。(Microsoft Learn)
ここで大切なのは、Human-in-the-Loop は単なる確認ダイアログではないという点です。承認対象のツール名、実行引数、対象データ、金額、宛先、削除対象などが明確に表示されなければ、ユーザーは正しく判断できません。実務では「OK / キャンセル」だけの UI では不十分です。
2026年6月26日の公式情報で整理された主な更新ポイント
2026年6月26日に更新された公式ページでは、AG-UI でツール実行の承認ワークフローを実装する方法が、.NET と Python の両方の観点で整理されています。特に注目すべきポイントは、承認が必要なツールの指定、承認リクエストと承認レスポンスの形式、クライアント側での承認処理、メッセージ履歴の扱いです。(Microsoft Learn)
承認が必要なツールを明示できる
.NET では、承認が必要な関数ツールを ApprovalRequiredAIFunction でラップするパターンが示されています。Microsoft Agent Framework の通常の関数ツールに対して、「このツールは人間の承認が必要」と印を付けるイメージです。(Microsoft Learn)
Python では、@tool デコレーターに approval_mode="always_require" を指定する形が示されています。公式情報では、承認モードとして always_require、never_require、conditional が説明されています。(Microsoft Learn)
実務では、すべてのツールに承認を求めるのではなく、リスクに応じて分けるのが現実的です。
| ツールの種類 | 承認の考え方 | 例 |
|---|---|---|
| 読み取り専用 | 原則として承認不要。ただし個人情報や機密情報の取得は別途制御 | 残高確認、一覧取得、ステータス確認 |
| 軽微な更新 | 条件付き承認を検討 | タグ付け、下書き作成、内部メモ追加 |
| 外部送信 | 承認必須にするのが安全 | メール送信、Teams投稿、外部API送信 |
| データ削除・契約変更 | 承認必須。可能なら二段階承認も検討 | ファイル削除、アカウント停止、契約解約 |
| 金銭・法務・人事に関わる処理 | 承認必須。監査ログも必須 | 送金、発注、雇用条件変更 |
承認リクエストと承認レスポンスの構造が明確になった
AG-UI の Human-in-the-Loop では、承認が必要になったときにクライアントへ承認リクエストが渡されます。公式ドキュメントでは、APPROVAL_REQUEST に承認 ID、ツール呼び出し ID、ツール名、引数、メッセージが含まれる例が示されています。承認側は、同じ承認 ID に対して APPROVAL_RESPONSE を返し、承認なら approved: true、却下なら approved: false を返す流れです。(Microsoft Learn)
この構造が重要なのは、承認対象を後から追跡できるためです。単に「ユーザーが承認した」という記録だけでは、監査では不十分です。次の情報を残せる設計にしておく必要があります。
| 記録すべき項目 | 理由 |
|---|---|
| 承認 ID | 承認要求と承認結果を紐付けるため |
| ツール名 | 何を実行しようとしたかを確認するため |
| 実行引数 | 宛先、金額、対象ファイルなどを後から検証するため |
| 承認者 | 誰が承認したかを説明できるようにするため |
| 承認日時 | インシデント調査や内部監査に使うため |
| 承認結果 | 承認・却下・タイムアウトを区別するため |
| 実行結果 | 承認後に実際に成功したか、失敗したかを確認するため |
クライアント側の UI 実装が重要になる
Human-in-the-Loop with AG-UI では、承認 UI は単なる飾りではありません。ユーザーが承認するかどうかを判断するための中核です。
公式情報では、クライアントが承認リクエストを受け取り、ツール名や引数を表示し、ユーザーが承認または却下を選ぶ流れが示されています。承認対象の例として、送金処理では送金元、送金先、金額、通貨などが表示されます。(Microsoft Learn)
実務では、次のような UI にする必要があります。
| 悪い承認 UI | 良い承認 UI |
|---|---|
| 「この操作を実行しますか？」だけ表示 | 「顧客ID 1234 の契約を Premium から Standard に変更します」と表示 |
| ツール名だけ表示 | ツール名、対象、変更前後、影響範囲を表示 |
| 承認ボタンが常に目立つ | 危険操作では警告、確認入力、却下理由の入力欄を用意 |
| 承認ログを残さない | 承認者、日時、引数、結果を記録 |
| 複数操作をまとめて一括承認 | 重要操作は1件ずつ承認 |
特にグローバル企業では、承認画面の言語、タイムゾーン、通貨、日付形式にも注意が必要です。たとえば「03/04/2026」は国によって3月4日にも4月3日にも見えるため、承認 UI では 2026-03-04 のような曖昧さの少ない表記を使うべきです。
メッセージ履歴のクリーンアップが必要になる
.NET 実装の説明では、承認レスポンスを変換した後に、request_approval のツール呼び出しとその結果をメッセージ履歴から削除する必要があるとされています。これを怠ると、Azure OpenAI 側で「tool_calls に対応する tool messages が必要」という趣旨のエラーが発生する可能性があります。(Microsoft Learn)
これは開発者向けには重要な注意点です。承認フローは UI だけで完結するものではなく、サーバー側のメッセージ変換、クライアント側の応答変換、セッション継続、履歴整合性まで含めて設計する必要があります。
影響範囲：誰が確認すべきか
この更新は、一般ユーザー向けの Microsoft アプリの画面変更というより、AI エージェントを開発・運用する組織に影響します。特に、Microsoft Agent Framework、Azure OpenAI、AG-UI、Web クライアントを組み合わせて業務アプリを作っているチームは確認が必要です。
| 対象者 | 影響 | 確認すべきこと |
|---|---|---|
| AIアプリ開発者 | 実装変更の可能性あり | 承認が必要なツールの指定方法、承認レスポンス処理、メッセージ履歴の扱い |
| セキュリティ管理者 | ガバナンス設計に影響 | 危険操作の分類、承認ログ、認可、監査証跡 |
| Microsoft 365 / Azure 管理者 | 直接のテナント設定変更は限定的 | Azure OpenAI、認証、ネットワーク、ログ保管先 |
| 業務部門の責任者 | 承認ルール策定に影響 | どの操作を自動化し、どの操作を人間承認にするか |
| グローバル運用チーム | 多地域展開時の運用設計に影響 | 地域別の承認者、言語、データ保護、時差対応 |
| エンドユーザー | 承認操作が増える可能性 | 承認画面で確認すべき項目、却下時の扱い |
反対に、AG-UI や Microsoft Agent Framework を使っていない組織に、すぐ設定変更が必要になる内容ではありません。Microsoft 365 の標準機能だけを利用している場合、この更新だけで管理センターの設定を変更する必要は通常ありません。
設定変更：管理画面ではなくアプリ実装で対応する
Human-in-the-Loop with AG-UI の設定変更は、主にアプリケーションコードと運用設計で行います。現時点の公式情報から読み取れる範囲では、Microsoft 365 管理センターや Entra 管理センターで「AG-UI の承認を有効化する」といった単一のテナントスイッチが示されているわけではありません。
実装上の代表的な変更点は次のとおりです。
| 項目 | .NET の考え方 | Python の考え方 | 管理者・責任者の確認点 |
|---|---|---|---|
| 承認対象ツールの指定 | ApprovalRequiredAIFunction で関数ツールをラップ | @tool(approval_mode="always_require") を指定 | どの業務操作を承認必須にするか |
| 承認フローの有効化 | AG-UI 用のミドルウェアで承認要求を変換 | AgentFrameworkAgent などで AG-UI に接続 | 本番アプリで承認が必ず通るか |
| 承認 UI | クライアント側で承認要求を表示 | クライアント側で承認要求を表示 | ユーザーが判断できる情報量か |
| 承認結果の返却 | 承認レスポンスをツール結果として戻す | 承認レスポンスをエージェントへ戻す | 承認・却下・タイムアウトの処理 |
| 監査ログ | アプリ側で設計 | アプリ側で設計 | 誰が何を承認したか追跡できるか |
Python では、たとえば次のように「承認必須のツール」と「承認不要のツール」を分ける考え方になります。
@tool
def check_status(ticket_id: str) -> str:
return "status checked"
@tool(approval_mode="always_require")
def close_ticket(ticket_id: str, reason: str) -> str:
return "ticket closed"この例では、ステータス確認は読み取り専用なので承認不要、チケットをクローズする操作は業務影響があるため承認必須にしています。実際の本番環境では、チケット番号、対象顧客、理由、実行者、承認者、実行結果をログに残す設計が必要です。
移行期限：現時点では強制期限よりも設計見直しが重要
2026年6月26日に更新された公式ページは、Human-in-the-Loop with AG-UI の実装方法を説明するチュートリアルであり、現時点で「いつまでに移行しなければならない」という強制的な移行期限は示されていません。ページ自体は 2026年6月26日更新として公開されていますが、既存アプリへの強制適用や廃止日を告知する内容ではありません。(Microsoft Learn)
ただし、移行期限がないから後回しでよい、という意味ではありません。AI エージェントが実際の業務データを更新したり、外部に情報を送信したりする場合、Human-in-the-Loop は安全対策として早めに検討すべきです。
優先順位は次のように考えると整理しやすくなります。
| 優先度 | 対象 | 対応方針 |
|---|---|---|
| 最優先 | 金銭処理、削除、契約変更、権限変更、外部送信 | 本番利用前に承認必須化 |
| 高 | 個人情報・機密情報を扱う更新処理 | 承認、ログ、権限チェックをセットで設計 |
| 中 | 社内ワークフローの更新 | 影響範囲に応じて条件付き承認 |
| 低 | 読み取り専用、検索、要約 | 承認よりもアクセス制御と出力制御を重視 |
管理者が確認すべきチェックリスト
Human-in-the-Loop with AG-UI を導入する場合、管理者はコードの細部だけでなく、業務ルール、セキュリティ、監査、運用まで確認する必要があります。
承認対象の棚卸し
まず、エージェントが呼び出せるツールを一覧化します。ツール名だけでなく、実行権限、対象データ、失敗時の影響、外部送信の有無まで書き出してください。
| 確認項目 | 見るべきポイント |
|---|---|
| ツール一覧 | エージェントが呼び出せる関数・API・外部サービス |
| 操作種別 | 読み取り、作成、更新、削除、送信、決済 |
| データ種別 | 個人情報、機密情報、財務情報、契約情報 |
| 実行権限 | ユーザー権限で実行するか、サービス権限で実行するか |
| 失敗時の影響 | 誤送信、誤削除、金銭損失、法的リスク |
| 承認要否 | 常に承認、条件付き承認、承認不要 |
特に注意すべきなのは、サービスアカウントやアプリケーション権限で実行されるツールです。ユーザー本人には権限がない操作でも、エージェント経由では実行できてしまう設計になっている場合があります。承認フローは、認可の代替ではありません。承認前に「そのユーザーが本当にその操作を要求できるか」を必ず確認する必要があります。
承認 UI の情報量
承認画面では、ユーザーが「何を承認するのか」を理解できなければ意味がありません。
最低限、次の情報を表示します。
| 表示項目 | 例 |
|---|---|
| 操作名 | メール送信、契約変更、ユーザー削除 |
| 対象 | 宛先メールアドレス、顧客ID、ファイル名、口座番号 |
| 変更内容 | 変更前と変更後 |
| 影響範囲 | 外部送信される、復元できない、請求が発生する |
| 実行理由 | ユーザーの依頼文、エージェントの判断理由 |
| 承認後の動作 | 即時実行、下書き作成、管理者キューへ送信 |
たとえばメール送信ツールなら、「メールを送りますか？」では不十分です。宛先、件名、本文の要約、添付ファイル、外部ドメインかどうかを表示すべきです。
ログと監査証跡
Human-in-the-Loop を導入しても、ログが残らなければ内部監査やインシデント調査に使えません。承認ログは、アプリケーションログ、SIEM、監査基盤、チケットシステムなど、組織の運用に合わせて保存します。
ログには、少なくとも次の情報を含めます。
| ログ項目 | 目的 |
|---|---|
| ユーザー ID | 操作を依頼した人物を追跡する |
| 承認者 ID | 承認した人物を追跡する |
| セッション ID | 会話や業務処理の流れを追う |
| ツール名 | 実行された機能を特定する |
| 引数 | 対象・金額・宛先などを検証する |
| 承認結果 | 承認、却下、期限切れを区別する |
| 実行結果 | 成功、失敗、部分成功を記録する |
| タイムスタンプ | 時系列で調査できるようにする |
ログには個人情報や機密情報が含まれる可能性があります。保存期間、アクセス権、マスキング、暗号化も同時に設計してください。
セキュリティ上の注意点
AG-UI はクライアントとサーバーが双方向に情報をやり取りするため、セキュリティ設計を誤ると危険です。Microsoft のセキュリティ考慮事項では、クライアントから送られるデータは潜在的に悪意があるものとして扱う必要があり、サーバー側のデータ露出やツール実行リスクにも注意が必要だと説明されています。(Microsoft Learn)
特に重要なのは、AG-UI サーバーを信頼できないクライアントへ直接公開しないことです。Microsoft の公式情報では、ブラウザー上の JavaScript やモバイルアプリのような信頼できないクライアントから AG-UI サーバーへ直接アクセスさせるのではなく、信頼できるフロントエンドサーバーを介してプロトコルメッセージを制御する構成が推奨されています。(Microsoft Learn)
承認フローで起きやすい失敗
| 失敗例 | 何が問題か | 対策 |
|---|---|---|
| 承認 UI にツール名しか出さない | ユーザーが影響を判断できない | 引数、対象、変更内容、影響範囲を表示 |
| 承認を認可の代わりにする | 権限のない操作を承認できてしまう | 実行前にユーザー権限を検証 |
| 複数の危険操作をまとめて承認 | 重要な操作が埋もれる | 高リスク操作は個別承認 |
| タイムアウトを設けない | セッションが不安定になる | 承認待ち時間を明示し、期限切れ時は中止 |
| 却下時の処理がない | エージェントが再試行や別操作をしてしまう | 却下時の応答ルールを設計 |
| ログがない | 後から説明できない | 承認要求、承認結果、実行結果を保存 |
| クライアント入力を信用する | プロンプトインジェクションや不正ツール呼び出しにつながる | 入力検証、許可リスト、サーバー側制御を行う |
グローバル向けに整理すべき運用ポイント
グローバル企業で Human-in-the-Loop with AG-UI を導入する場合、日本国内だけの設計よりも考慮点が増えます。
地域ごとの規制とデータ保護
承認ログには、顧客名、メールアドレス、口座情報、契約情報などが含まれる可能性があります。国や地域によって、ログの保存場所、保存期間、閲覧権限、削除要求への対応が異なります。
特に、EU、米国、日本、APAC で同じエージェントを展開する場合は、承認ログをどのリージョンに保存するかを事前に決めておく必要があります。
承認者のタイムゾーンと業務時間
承認者が別地域にいる場合、承認待ちで業務が止まる可能性があります。金銭処理や契約変更のような重要操作では、地域別の代理承認者、エスカレーションルール、期限切れ時の処理を定義しておくべきです。
例として、次のようなルールが考えられます。
| 状況 | 推奨ルール |
|---|---|
| 承認者が業務時間外 | 代理承認者へ自動エスカレーション |
| 30分以内に承認なし | 操作を中止し、再依頼を促す |
| 高額取引 | 二名承認または管理者承認を必須化 |
| 外部送信 | 宛先ドメインが社外なら追加確認 |
| 個人情報を含む処理 | データ保護責任者のルールに従う |
多言語 UI と誤解防止
承認 UI は、ユーザーの言語に合わせるだけでなく、業務用語の意味が変わらないようにする必要があります。たとえば「close account」は、金融では口座解約、SaaS ではアカウント停止、営業では取引完了という意味に見えることがあります。
ツール名をそのまま表示するのではなく、業務担当者が理解できる表現に変換することが重要です。
実務での設計例：承認ポリシーを先に決める
Human-in-the-Loop with AG-UI を導入するときは、コードを書く前に承認ポリシーを決めるべきです。ポリシーが曖昧なまま実装すると、開発者ごとに承認基準がバラバラになり、後から監査や運用で困ります。
以下は、社内向け AI エージェントの承認ポリシー例です。
| 操作 | 承認要否 | 理由 |
|---|---|---|
| FAQ検索 | 不要 | 読み取りのみで影響が小さい |
| 社内文書の要約 | 条件付き | 機密ラベル付き文書は追加制御 |
| メール下書き作成 | 不要または条件付き | 送信しないため影響は限定的 |
| メール送信 | 必須 | 誤送信や情報漏えいのリスクがある |
| 顧客情報の更新 | 必須 | データ品質と監査が必要 |
| ファイル削除 | 必須 | 復元不能な場合がある |
| 外部システムへの登録 | 必須 | 契約・課金・通知が発生する可能性がある |
| 送金・発注 | 必須、必要に応じて二名承認 | 金銭的損失のリスクが高い |
このように、ツールごとに承認要否を明確にしてから、.NET なら ApprovalRequiredAIFunction、Python なら approval_mode を適用していくと、実装と運用ルールが一致しやすくなります。
導入前に検証すべきテスト項目
Human-in-the-Loop は「承認ボタンが出るか」だけを見ても不十分です。本番投入前には、承認、却下、タイムアウト、通信エラー、セッション切断などを含めてテストします。
| テスト項目 | 確認内容 |
|---|---|
| 承認時 | 承認後に正しいツールが正しい引数で実行されるか |
| 却下時 | ツールが実行されず、ユーザーに適切な説明が返るか |
| タイムアウト時 | 操作が中止され、再承認なしに実行されないか |
| 引数改ざん | クライアント側で引数を書き換えてもサーバーが検出できるか |
| 権限不足 | 承認しても権限のない操作は拒否されるか |
| 複数承認 | 複数の承認要求を順序どおり処理できるか |
| ログ | 承認要求、承認結果、実行結果が追跡できるか |
| 再試行 | 同じ承認 ID で二重実行されないか |
特に二重実行は見落としやすいポイントです。ユーザーが承認ボタンを連打した場合、通信がリトライされた場合、ブラウザーを更新した場合でも、同じ処理が重複して実行されないように冪等性を設計してください。
既存の AI エージェントを見直すときの進め方
既存の Microsoft Agent Framework や AG-UI ベースのアプリがある場合、次の順序で見直すと効率的です。
ツールを分類する
まず、エージェントが使うツールを読み取り系、更新系、外部送信系、削除系、金銭・契約系に分類します。分類できないツールは、仕様が曖昧な可能性があります。
承認必須ツールを決める
次に、承認必須にするツールを決めます。迷った場合は、「実行後に元に戻せないか」「社外に影響するか」「金銭・個人情報・契約に関わるか」で判断します。1つでも当てはまるなら、承認必須を基本にします。
UI とログを設計する
承認 UI に出す情報と、ログに保存する情報を決めます。UI とログは似ていますが、目的が違います。UI はユーザーが今判断するための情報、ログは後から説明するための情報です。
セキュリティレビューを行う
AG-UI サーバーの公開範囲、認証、認可、入力検証、ツール許可リスト、セッション ID の扱いを確認します。Microsoft のセキュリティ考慮事項でも、AG-UI の信頼境界、未信頼入力、ツール実行リスクが重要な論点として示されています。(Microsoft Learn)
本番前に異常系をテストする
承認、却下、タイムアウト、通信断、重複クリック、権限不足、ログ欠落をテストします。正常系だけでリリースすると、実運用で止まりやすくなります。
まとめ：管理者は「承認を出すこと」より「承認できる状態を作ること」を重視する
Microsoft の「Human-in-the-Loop with AG-UI」は、AI エージェントが重要なツールを実行する前に、人間の承認を挟むための実装パターンです。2026年6月26日の公式更新では、AG-UI を使った承認ワークフローの具体的な実装方法、承認リクエストとレスポンスの扱い、クライアント側の承認処理、メッセージ履歴の注意点が整理されています。(Microsoft Learn)
管理者が次に取るべき行動は、AG-UI を使っているかどうかを確認し、使っている場合はエージェントが実行できるツールを棚卸しすることです。そのうえで、外部送信、削除、更新、金銭処理、権限変更などの高リスク操作を承認必須にし、承認 UI、ログ、認可、タイムアウト、二重実行防止をセットで設計してください。
Human-in-the-Loop は、AI の便利さを下げるための仕組みではありません。AI に任せる部分と、人間が責任を持って確認する部分を分けることで、業務自動化を安全に広げるための土台になります。
コメント