Azure REST API更新：Hosted agent invocations eventsの変更点と確認事項

2026年5月19日にAzure REST API仕様で更新された「Add Hosted agent invocations events」は、Azure REST API全体の認証方式や既存エンドポイントを一斉に変える更新ではありません。主な変更点は、Azure AI VoiceLiveのプレビューAPIに、Hosted agentへ任意の入力を渡すinvoke_inputと、Hosted agent由来の非音声イベントを受け取るresponse.invocation.deltaが追加されたことです。既存アプリがすぐ壊れる可能性は高くありませんが、イベント型を厳密に判定している実装、SDKを自動生成している環境、ログ監査を行っている管理者は確認が必要です。(GitHub)

特に注意したいのは、この更新が「音声会話アプリでHosted agentの裏側の動きを扱いやすくする」方向の変更である点です。Microsoft 365 Copilotの管理画面設定を直接変更するものではなく、Azure AI VoiceLive、Microsoft Foundry Agent Service、REST API仕様、SDK生成、イベントストリーム処理に関係する更新として捉えると理解しやすくなります。

Azure REST API documentation update: Add Hosted agent invocations eventsの位置づけ

今回の更新は、Azureの公式REST API仕様リポジトリであるAzure/azure-rest-api-specsのPR「Add Hosted agent invocations events」として公開・マージされたものです。PRは2026年5月19日にvoicelive/20260601previewブランチへマージされ、その後、VoiceLiveの2026-06-01-preview APIバージョンをmainへ取り込むリリースPRにも含まれています。(GitHub)

対象は、Azure REST APIの中でもVoiceLiveのデータプレーンAPI仕様です。PRにはdata-planeとTypeSpecのラベルが付いており、変更ファイルとしてevents.tsp、models.tsp、preview/2026-06-01-preview/VoiceLive.jsonが示されています。つまり、Azure Resource Managerの管理APIやサブスクリプション設定そのものではなく、VoiceLive APIのイベント定義とリクエスト/レスポンスモデルに関する更新です。(GitHub)

何が変わったのか

今回の変更は大きく分けて3つです。

変更項目	追加内容	実務上の意味
Hosted agentへの入力	ResponseCreateParamsにinvoke_inputを追加	クライアント側からHosted agent呼び出し用の任意JSONを渡せるようになる
サーバーイベント型	response.invocation.deltaを追加	Hosted agentが返す非音声SSEイベントをVoiceLive側で受け取れる
イベントモデル	ServerEventResponseInvocationDeltaを追加	deltaとしてHosted agent由来の生イベントデータを扱う

events.tspでは、サーバーイベント型にresponse_invocation_delta: "response.invocation.delta"が追加されています。説明は「Invocation passthrough delta from hosted agent」で、Hosted agentからの呼び出しイベントをそのまま渡すためのイベント型として定義されています。(GitHub)

models.tspでは、invoke_inputがResponseCreateParamsに追加されました。これはHosted agentへ渡す入力データであり、プレビュー機能として扱われています。また、ServerEventResponseInvocationDeltaでは、Hosted agent invocationが非音声SSEイベントを生成した場合に、その内容をdeltaとしてそのまま返すモデルが追加されています。(GitHub)

Swagger側のVoiceLive.jsonにも、invoke_inputとresponse.invocation.deltaが反映されています。invoke_inputはHosted agentを呼び出すための入力データとして定義され、ServerEventResponseInvocationDeltaはdeltaを持つイベントとして定義されています。(GitHub)

なぜこの更新が重要なのか

VoiceLiveは、音声入力、音声出力、会話状態、モデル応答、エージェント連携をリアルタイムに扱うAPIです。Microsoft Learnでは、VoiceLiveとMicrosoft Foundry Agent Serviceを組み合わせることで、エージェント側にプロンプトや構成を持たせ、クライアントコードを大きく変えずに会話フローを管理しやすくできると説明されています。(Microsoft Learn)

今回追加されたresponse.invocation.deltaは、音声やテキストそのものではなく、Hosted agentの呼び出し中に発生する非音声イベントを扱うためのものです。たとえば、Hosted agent側が外部システム照会、処理状況、UI更新用の補助情報などをSSEイベントとして返す設計の場合、クライアントはそれをイベントストリーム上で検知しやすくなります。

ただし、deltaの中身は固定スキーマではありません。TypeSpecの差分では、Hosted agent側のSSEイベントJSONはこのAPI側でスキーマ定義しない「opaque passthrough」として扱われています。つまり、アプリ側で「このキーが必ず来る」「この構造で必ず返る」と決め打ちすると、Hosted agentの実装変更や将来のAPI更新で壊れやすくなります。(GitHub)

影響を受ける環境と受けにくい環境

環境・実装	影響度	確認すべきこと
VoiceLiveとFoundry Agent Serviceを使う音声エージェント	高	invoke_inputとresponse.invocation.deltaを使う設計か確認する
イベント型をswitchや列挙型で厳密に処理しているクライアント	高	未知のイベント型で例外終了しないか確認する
OpenAPI/TypeSpecからSDKや型定義を自動生成している環境	中〜高	2026-06-01-previewの仕様を取り込んだ場合の差分を確認する
ログ、監査、分析基盤でイベント種別を集計している環境	中	response.invocation.deltaを分類対象に追加する
VoiceLiveを使っていない通常のAzure REST API利用	低	直接対応は原則不要
ARMテンプレートやAzure Policy中心の管理	低	今回の変更自体はコントロールプレーン設定変更ではない

影響が大きいのは、リアルタイムイベントを厳密にパースしている実装です。これまで想定していなかったresponse.invocation.deltaが流れてきたとき、未知のイベントとして無視できるのか、エラーにするのか、ログだけ残すのかを決めておく必要があります。

逆に、未知イベントを安全にスキップできる設計で、Hosted agent invocationを使っていない場合は、急いで移行作業をする必要はありません。まずはAPIバージョン、SDKバージョン、イベントハンドラーの実装を棚卸しするのが現実的です。

管理者が確認すべき設定と運用ポイント

プレビューAPIを本番前提で展開しない

VoiceLiveとFoundry Agent Serviceの連携は、Microsoft Learn上でパブリックプレビューとして説明されています。プレビューはSLAなしで提供され、本番ワークロードには推奨されない場合があり、機能に制約がある可能性もあります。(Microsoft Learn)

管理者は、2026-06-01-previewを使う環境を本番系に広げる前に、以下を確認してください。

確認項目	判断基準
利用目的	検証、PoC、限定公開、社内向けなどリスクを許容できる用途か
障害時の代替手段	旧APIバージョン、従来フロー、手動対応に戻せるか
SLA要件	顧客向け本番機能として必須の品質保証が必要か
変更追従体制	API仕様、SDK、ドキュメント更新を継続的に追えるか

Entra ID認証を前提に権限を確認する

VoiceLiveのAgent modeでは、Microsoft Learnに「キー認証はサポートされず、Microsoft Entra ID認証が必要」と説明されています。既存の非Agent構成でAPIキーを使っている場合でも、Hosted agent連携では認証方式の前提が異なる点に注意が必要です。(Microsoft Learn)

確認すべきポイントは、ユーザー、アプリ登録、マネージドID、CI/CD実行主体のどれがVoiceLiveとFoundry Agent Serviceへアクセスするのかです。特に検証環境では個人のAzure CLI認証で動いていても、本番展開時にマネージドIDへ切り替えると権限不足で失敗することがあります。

deltaのログ保存ルールを決める

response.invocation.deltaのdeltaはHosted agentから渡される生のイベントデータです。中身が固定されていないため、ユーザー入力、業務データ、外部システムの応答、内部処理状態が含まれる可能性を前提に扱うべきです。

ログに残す場合は、少なくとも次のルールを決めてください。

ルール	理由
生のdeltaを無条件に保存しない	個人情報や業務機密が混入する可能性がある
保存前にマスキングする	メールアドレス、電話番号、ID、トークンの漏えいを防ぐ
相関IDを別管理する	トラブルシュートに必要な情報を最小限で追跡できる
保存期間を短くする	プレビュー機能の検証ログが長期残存するリスクを下げる

APIバージョンを一括で上げない

今回の変更は2026-06-01-previewに関連する更新です。プレビューAPIは便利ですが、既存機能への影響を完全に読み切れないことがあります。複数サービスや複数チームでVoiceLiveを使っている場合、全環境のAPIバージョンを一括で上げるのではなく、検証環境、限定ユーザー、本番の一部トラフィックという順番で展開してください。

開発者が確認すべき実装ポイント

response.invocation.deltaをイベントハンドラーに追加する

イベント処理で最初に確認すべきなのは、未知のtypeを受け取ったときの挙動です。失敗しやすい実装は、定義済みイベント以外をすべて例外扱いにするコードです。

安全な実装では、新イベントを明示的に扱いつつ、将来追加されるイベントにも耐えられるフォールバックを残します。

type VoiceLiveServerEvent = {
  type?: string;
  delta?: unknown;
  [key: string]: unknown;
};

function handleServerEvent(event: VoiceLiveServerEvent) {
  switch (event.type) {
    case "response.invocation.delta":
      handleHostedAgentInvocationDelta(event.delta);
      return;

    case "response.text.delta":
    case "response.audio.delta":
      handleKnownStreamingEvent(event);
      return;

    default:
      handleUnknownOrFutureEvent(event);
      return;
  }
}

function handleHostedAgentInvocationDelta(delta: unknown) {
  // deltaの構造はHosted agent側に依存する。
  // ここでアプリ固有の検証、マスキング、監査ログ出力を行う。
}

ポイントは、deltaを最初から厳密なクラスにマッピングしないことです。今回の仕様では、Hosted agent側のイベントJSONはAPI側で固定スキーマ化されていません。アプリが必要とするフィールドだけを検証し、それ以外は破棄または安全に保管する設計にしてください。(GitHub)

invoke_inputは最小限の文脈情報に絞る

invoke_inputはHosted agentへ入力データを渡すためのフィールドです。便利だからといって、画面状態、ユーザープロフィール、会話履歴、外部APIの結果を丸ごと詰め込む設計は避けるべきです。

実務では、次のように用途を絞ると安全です。

入れる候補	入れない方がよいもの
問い合わせ番号、セッションID、業務フローID	アクセストークン、APIキー、秘密情報
ユーザーが明示的に選択した処理種別	画面全体のフォームデータ
Hosted agentが判断に必要な最小限の属性	不要な個人情報、全会話ログ
監査用の相関ID	パスワード、認証Cookie、内部URL一覧

invoke_inputは「Hosted agentに何でも渡せる箱」ではなく、「Hosted agentが今回の呼び出しを判断するための最小コンテキスト」と考えると、後から監査しやすくなります。

SDK更新とAPIバージョン固定をセットで確認する

OpenAPIやTypeSpecから生成されたSDKを使っている場合、API仕様だけを新しくしても、利用中のSDKが新フィールドや新イベントをまだ型として持っていないことがあります。PRではAPIレベルの変更が検出され、TypeSpec、Java、Python、C#、JavaScriptなどのAPIレビューが作成されています。(GitHub)

開発者は、以下を同時に確認してください。

確認対象	具体的な確認内容
APIバージョン	2026-06-01-previewを指定しているか、既存のプレビュー版のままか
SDKバージョン	invoke_inputやresponse.invocation.deltaに対応した型があるか
自前型定義	イベント列挙型に新イベントを追加したか
テストデータ	Hosted agent由来の非音声イベントを再現できるか
CI	型生成、lint、契約テストが新仕様で通るか

音声処理ループをブロックしない

response.invocation.deltaは非音声イベントですが、VoiceLiveのイベントストリーム上では音声、テキスト、会話状態、ツール呼び出し関連イベントと並行して扱われます。Hosted agentのイベント処理で重いDB書き込みや外部API呼び出しを同期的に行うと、音声応答やUI更新の遅延につながります。

実装では、response.invocation.deltaを受け取ったら軽量に検証し、必要に応じてキューへ渡す設計が向いています。音声再生、字幕表示、状態更新の処理とは責務を分けてください。

移行・展開時のおすすめ手順

手順	作業内容	完了条件
棚卸し	VoiceLive利用箇所、APIバージョン、SDK、自前イベント型を確認	影響を受けるアプリ一覧がある
検証環境で更新	2026-06-01-previewと対応SDKまたは仕様を試す	既存の音声会話が動く
イベントテスト	response.invocation.delta相当のイベントを処理できるか確認	未知イベントで落ちない
入力テスト	invoke_inputに最小限のデータを渡す設計を確認	不要な個人情報や秘密情報が含まれない
監視追加	新イベントの件数、エラー率、処理遅延を可視化	ダッシュボードまたはログ検索で追跡できる
段階展開	限定ユーザー、限定リージョン、限定機能から展開	ロールバック手順がある

移行というより、まずは「新しいイベントが来ても安全に受け流せる状態」にすることが重要です。そのうえで、Hosted agent invocationを使う機能を追加する場合だけ、invoke_inputやresponse.invocation.deltaを積極的に利用します。

失敗しやすいポイント

失敗例	起きる問題	対策
deltaの中身を固定スキーマとして実装する	Hosted agent側の変更でデシリアライズエラーになる	unknownとして受け、必要なキーだけ検証する
未知のイベント型を例外扱いにする	新イベント追加時にストリーム処理が止まる	default処理でログ化または安全に無視する
生のdeltaを全量ログ保存する	個人情報や内部データが漏えいする	マスキング、保存期間、アクセス権を決める
APIバージョンだけ先に上げる	SDKや型定義が追従せずビルドや実行時に失敗する	SDK、生成コード、契約テストを同時に更新する
APIキー前提の実装を流用する	Agent modeで認証エラーになる	Entra ID認証を前提に権限設計を見直す
プレビューを本番機能に直結する	仕様変更や制約の影響を受けやすい	フィーチャーフラグとロールバックを用意する

よくある疑問

既存のAzure REST API利用者はすぐ対応が必要か

VoiceLiveやFoundry Agent Serviceを使っていない場合、今回の更新による直接影響は限定的です。通常のAzure REST API操作、ARMテンプレート、Azure Policy、一般的なリソース管理APIには、今回のresponse.invocation.delta追加が直接関係するわけではありません。

ただし、社内でAzure REST API仕様からSDKや型定義を自動生成している場合は別です。VoiceLive関連の生成対象を含めているなら、差分の取り込みタイミングでビルド、型チェック、イベント処理のテストを行ってください。

response.invocation.deltaは必ず処理しなければならないか

必ず業務処理に使う必要はありません。Hosted agent invocationの詳細をUIやログ、監査、外部連携に活用したい場合に処理対象になります。

一方で、イベントストリーム上に流れてくる可能性を考えると、少なくとも「未知イベントとして安全に扱える」状態にはしておくべきです。何もしない場合でも、アプリを落とさないことが重要です。

invoke_inputにはどのような情報を渡すべきか

Hosted agentが今回の呼び出しを判断するために必要な最小限の情報です。たとえば、問い合わせID、選択中の業務フロー、ユーザーが明示的に指定した処理条件、相関IDなどが候補になります。

逆に、アクセストークン、APIキー、秘密情報、会話履歴の全量、画面フォームの全項目などは避けるべきです。Hosted agent側で本当に必要なデータか、ログに残った場合に問題ないかを基準に判断してください。

Copilotの設定変更と考えてよいか

直接的には違います。今回の更新は、Azure REST API仕様におけるVoiceLiveとHosted agent invocationのイベント定義追加です。CopilotやAIエージェント関連の開発文脈で目にすることはありますが、Microsoft 365 Copilotの管理センター設定やユーザーライセンス設定を変更する話ではありません。

まず取るべき対応

今回のAzure REST API更新で最初に行うべきことは、response.invocation.deltaという新しいサーバーイベントが来てもアプリが停止しないかを確認することです。次に、Hosted agent連携を使う予定がある場合は、invoke_inputへ渡すデータの範囲、deltaの検証方法、ログ保存ルールを決めます。

管理者は、プレビューAPIの利用範囲、Entra ID認証、ログのデータ保護、段階展開の方針を確認してください。開発者は、SDKや自前型定義を更新し、イベントハンドラーにresponse.invocation.deltaの処理または安全なフォールバックを追加します。

この更新は、単なるイベント名の追加ではありません。VoiceLiveとHosted agentを組み合わせた音声エージェントで、裏側の処理状況や非音声イベントを扱うための土台になります。プレビュー機能であることを前提に、まずは小さく検証し、型・ログ・認証・展開手順を整えてから利用範囲を広げるのが安全です。