Microsoft の「Step 6: Host Your Agent」は、Microsoft Agent Framework で作成した AI エージェントを、利用者や他のエージェントが呼び出せる状態にするためのホスティング手順です。今回確認すべきポイントは、エージェントの作成方法そのものではなく、どのプロトコルで公開するか、どこで実行するか、認証・状態管理・監視をどう設計するかにあります。
2026年6月26日時点で確認できる公式情報では、ホスティングの選択肢として A2A Protocol、OpenAI-compatible endpoints、Durable Extension、AG-UI Protocol が整理されています。特に実務では、既存の OpenAI 互換クライアントに接続したいのか、Web UI から使わせたいのか、長時間実行や障害復旧が必要なのかによって、採用すべき構成が変わります。なお、Step 6 の公式ページ自体には、特定日までに必ず移行しなければならない期限は明記されていません。運用担当者は「移行期限」よりも、公開方式・認証方式・セッション保存・責任ある AI 対策を先に確認すべきです。(Microsoft Learn)
Microsoft の新機能・変更点：「Step 6: Host Your Agent」で確認すべきポイント
「Step 6: Host Your Agent」は、Microsoft Agent Framework の入門ステップの最後に位置づけられています。Step 1〜5 で作成したエージェント、ツール、会話状態、メモリ、ワークフローを、実際のアプリケーションや外部システムから利用できるようにする段階です。
公式ドキュメントでは、ホスティングの目的を「ユーザーや他のエージェントが対話できるようにデプロイすること」と説明しています。つまり、ローカルで動くサンプルコードを本番相当のアプリケーションに近づけるための工程です。(Microsoft Learn)
実務上は、次のような判断が必要になります。
| 確認項目 | 判断のポイント |
|---|---|
| 誰が呼び出すか | 人間のユーザー、Web アプリ、モバイルアプリ、他の AI エージェント、既存の OpenAI 互換クライアント |
| どのプロトコルで公開するか | A2A、OpenAI 互換 API、AG-UI、独自 HTTP API、Azure Functions など |
| 状態を保持するか | 1回ごとの応答でよいのか、会話履歴・セッション・ファイルを保持するのか |
| 長時間処理があるか | 数秒のチャット応答か、数分〜数日続くワークフローか |
| 本番運用に必要なもの | 認証、認可、監視、ログ、スケーリング、障害復旧、コスト管理 |
| 管理者が関与すべき領域 | Azure リソース、Microsoft Entra ID、Managed Identity、ネットワーク、データ境界、秘密情報管理 |
単純に「エージェントを公開する」だけなら ASP.NET Core で HTTP エンドポイントを作れば足ります。しかし、企業利用では、誰が何を実行できるか、会話履歴をどこに保存するか、外部サービスにデータが流れるか、失敗時に再実行されるかまで設計する必要があります。
Step 6: Host Your Agent の主な変更・整理ポイント
Step 6 の重要な更新ポイントは、ホスティングを単一の方法ではなく、用途別の選択肢として整理している点です。
公式ページでは、主なホスティングオプションとして次の4つが示されています。(Microsoft Learn)
| ホスティング方式 | 向いている用途 | 実務での使いどころ |
|---|---|---|
| A2A Protocol | マルチエージェント連携 | 他のエージェントから発見・呼び出しされるエージェントを公開したい場合 |
| OpenAI-Compatible Endpoints | OpenAI 互換クライアント連携 | 既存の Chat Completions / Responses API 対応ツールから呼び出したい場合 |
| Durable Extension | 長時間・高信頼な処理 | 障害復旧、状態保持、複数ステップのワークフロー、分散実行が必要な場合 |
| AG-UI Protocol | Web ベースの AI エージェント UI | ブラウザーやモバイルアプリでストリーミング、承認、状態同期を実装したい場合 |
この整理により、管理者や開発者は「どの機能が新しいか」だけでなく、「自社のユースケースにはどれを選ぶべきか」を判断しやすくなっています。
たとえば、社内の業務支援チャットボットを Teams や Web アプリから呼び出すだけなら、OpenAI 互換エンドポイントや Hosted agents が候補になります。一方で、複数の専門エージェントが互いに問い合わせる構成なら、A2A Protocol を検討する価値があります。請求処理、稟議、調査、データ加工のように処理が途中で止まっても再開したい業務では、Durable Extension が重要になります。
影響範囲：誰が確認すべきか
今回の「Step 6: Host Your Agent」は、AI エージェントを試作している開発者だけでなく、本番展開を管理するクラウド管理者、セキュリティ担当者、アプリケーション運用担当者にも影響します。
特に影響を受けるのは、次のような組織です。
| 対象 | 影響内容 |
|---|---|
| Microsoft Agent Framework を利用する開発チーム | エージェントの登録、公開プロトコル、セッション管理、ワークフロー公開方法の見直しが必要 |
| ASP.NET Core で AI エージェントを公開するチーム | Microsoft.Agents.AI.Hosting を使った DI 登録やプロトコルアダプターの設計が必要 |
| Azure Functions を使うチーム | Durable Extension や AgentFunctionApp によるサーバーレス実行を検討できる |
| セキュリティ・ID 管理者 | DefaultAzureCredential の本番利用、Managed Identity、RBAC、秘密情報管理の確認が必要 |
| Web フロントエンド開発者 | AG-UI による SSE ストリーミング、Human-in-the-loop、状態同期の設計が必要 |
| グローバル運用チーム | リージョン、データ所在地、サードパーティ接続、監査ログ、コスト配分の確認が必要 |
注意したいのは、Agent Framework のホスティングは「アプリを公開するだけ」ではない点です。エージェントはモデル、ツール、外部 API、ファイル、会話履歴、ユーザー ID と結びつくため、通常の Web API よりもデータの流れが複雑になりやすくなります。
Microsoft の Providers Overview でも、サードパーティのサーバー、エージェント、コード、非 Azure Direct モデルを利用する場合は、利用者側がライセンス、費用、データ共有、保持場所、コンプライアンス境界を確認する責任を持つと説明されています。(Microsoft Learn)
ASP.NET Core ホスティングで押さえる設定変更
Step 6 では、ASP.NET Core で Agent Framework のエージェントをホストする方法が中心的に説明されています。ポイントは、エージェントをアプリケーション内で直接 new して使うのではなく、依存関係注入、つまり DI コンテナーに登録して管理することです。
公式ドキュメントでは、Microsoft.Agents.AI.Hosting ライブラリが ASP.NET Core ホスティングの基盤として説明されています。このライブラリは、IHostApplicationBuilder に対して AI エージェントやワークフローを登録・構成する拡張機能を提供します。(Microsoft Learn)
実務で確認すべき設定は次の通りです。
| 設定項目 | 確認内容 |
|---|---|
IChatClient の登録 | Azure OpenAI、Microsoft Foundry、OpenAI など、どのモデル接続を使うか |
| エージェント名 | エンドポイントやルーティングで衝突しない名前になっているか |
| instructions | 本番利用に耐える指示になっているか。テスト用の冗談めいたプロンプトを残していないか |
| description | A2A の AgentCard や管理画面で意味が伝わる説明になっているか |
| tools | 実行できるツールの権限が過剰でないか |
| session store | インメモリでよいのか、永続ストレージが必要か |
| 認証情報 | 開発用の資格情報が本番に残っていないか |
公式例では DefaultAzureCredential が使われていますが、Microsoft は本番環境では慎重に扱うべきだと警告しています。本番では、意図しない資格情報の探索やフォールバックを避けるため、ManagedIdentityCredential など、より明示的な資格情報の利用を検討すべきです。(Microsoft Learn)
AddAIAgent は「公開前の登録ポイント」として見る
AddAIAgent() は、AI エージェントを DI に登録するための主要な入口です。公式例では、エージェント名、instructions、description、利用するチャットクライアントのキーを指定しています。(Microsoft Learn)
実務では、次のように考えると分かりやすくなります。
AddAIAgent()は、エージェントをアプリ内で利用可能にする登録処理WithAITool()は、エージェントが呼び出せる業務機能を追加する処理WithInMemorySessionStore()は、会話データを一時的に保持する設定MapA2A()やMapOpenAIChatCompletions()などは、外部から呼び出せる形に公開する処理
特に失敗しやすいのは、開発環境の WithInMemorySessionStore() をそのまま本番想定で使ってしまうケースです。インメモリ保存は簡単ですが、プロセス再起動やスケールアウト時に会話状態が失われる可能性があります。会話履歴の保持が業務要件に含まれる場合は、Durable Extension や外部ストレージを含めて設計する必要があります。
ワークフローを公開する場合は AddAsAIAgent が重要
Step 6 では、複数のエージェントを組み合わせたワークフローをホストする方法にも触れています。公式ドキュメントでは、ワークフローは複数の AIAgent がノードとして連携するグラフのようなものとして説明されています。(Microsoft Learn)
ここで重要なのが、ワークフローを A2A や OpenAI 互換エンドポイントなどのプロトコル統合で使う場合、ワークフローを単体のエージェントとして公開する必要がある点です。公式ページでは、AddAsAIAgent() によってワークフローをエージェントとして扱えるようにする例が示されています。(Microsoft Learn)
実務では、次のようなケースで使います。
| 利用シーン | 構成例 |
|---|---|
| 問い合わせ分類後に専門エージェントへ転送 | 分類エージェント → 製品FAQエージェント → 回答整形エージェント |
| 調査レポート作成 | 情報収集エージェント → 要約エージェント → リスク抽出エージェント |
| 承認付き業務処理 | 入力確認 → 規程チェック → 人間の承認 → 実行 |
| データ処理 | ファイル確認 → 抽出 → 変換 → 結果通知 |
ワークフローを直接公開するのではなく、エージェントとしてラップする考え方を理解しておくと、外部プロトコルとの接続が整理しやすくなります。
A2A Protocol：他のエージェントと連携する場合の選択肢
A2A Protocol は、エージェント同士が標準化された方法で通信するためのプロトコルです。Microsoft の A2A Integration ドキュメントでは、Agent Card による発見、メッセージベースの通信、長時間タスク、異なるフレームワーク間の相互運用などが説明されています。(Microsoft Learn)
A2A を使うべきなのは、単体のチャットボットを公開する場合ではなく、他のエージェントから呼び出される部品として公開したい場合です。
たとえば、次のような構成が考えられます。
| 例 | A2A が向く理由 |
|---|---|
| 経理エージェントが購買エージェントに発注内容を確認する | エージェント間で役割を分けられる |
| 調査エージェントが翻訳エージェントや要約エージェントを呼び出す | 専門機能を分散できる |
| 外部パートナーが提供する A2A 対応エージェントを利用する | フレームワーク差を吸収しやすい |
| 複数部署のエージェントを統合する | Agent Card で発見・説明しやすい |
A2A で公開する場合は、エンドポイントのパス、AgentCard の名前・説明・バージョン、認証方式、contextId の扱いを事前に決めておくことが重要です。A2A Integration の公式例では、ASP.NET Core アプリで MapA2A() を使い、/a2a/pirate のようなパスにエージェントを公開しています。(Microsoft Learn)
A2A で失敗しやすいポイント
A2A は便利ですが、公開範囲を誤ると、意図しないエージェントから呼び出されるリスクがあります。
特に注意すべき点は次の通りです。
| 注意点 | 対策 |
|---|---|
| AgentCard に内部情報を書きすぎる | 公開してよい説明・スキル・URL だけを記載する |
| 認証なしで公開する | Bearer トークン、API Management、Entra ID などで保護する |
| contextId を軽視する | 会話継続、監査、トラブル調査に使える設計にする |
| エンドポイントが衝突する | エージェントごとに明確なパス設計を行う |
| 外部 A2A エージェントを無検証で使う | データ共有、費用、ライセンス、ログの扱いを確認する |
「他のエージェントとつながる」ことは、同時に「責任範囲が広がる」ことでもあります。A2A の導入時は、技術検証だけでなく、データ分類とアクセス制御を必ず確認してください。
OpenAI-Compatible Endpoints：既存クライアントと接続する場合の選択肢
OpenAI-Compatible Endpoints は、既存の OpenAI 互換クライアントやツールから Agent Framework のエージェントを呼び出したい場合に有効です。
公式ドキュメントでは、Chat Completions API と Responses API の2つが説明されています。Responses API は、会話管理、ストリーミング、長時間プロセスなどを扱える、より包括的な形式として紹介されています。一方、Chat Completions API はシンプルなステートレス形式で、既存システムとの互換性を重視する場合に向いています。(Microsoft Learn)
判断基準は次の通りです。
| 選択肢 | 向いているケース |
|---|---|
| Responses API | 新規開発、会話履歴の管理、長時間実行、詳細なストリーミング、応答 ID による管理が必要 |
| Chat Completions API | 既存アプリの移行、単純なリクエスト・レスポンス、クライアント側で状態管理する構成、レガシー互換性が必要 |
既存のチャット UI、社内ツール、SDK、検証コードが Chat Completions 前提で作られている場合、OpenAI 互換エンドポイントは移行コストを下げられます。ただし、新規開発では、将来的な拡張性を考えて Responses API を優先的に検討するのが自然です。
OpenAI 互換エンドポイントで確認すべきこと
管理者や開発者は、次の設定を確認してください。
| 項目 | 確認内容 |
|---|---|
| エンドポイントパス | 既存クライアントが想定する URL と一致するか |
| モデル名 | クライアントが送る model 値とエージェント名の対応が明確か |
| ストリーミング | SSE を使う場合、プロキシや WAF が切断しないか |
| 使用量ログ | トークン使用量、応答時間、エラーを記録できるか |
| 認証 | API キーだけでよいのか、Entra ID や API Management を併用するか |
| 状態管理 | Chat Completions ではクライアント側の履歴管理が前提になりやすい |
既存の OpenAI 互換クライアントをそのまま使える点は大きな利点です。ただし、互換性を優先しすぎると、セッション管理や承認フロー、監査ログが後回しになりがちです。本番導入前に、最低限「誰が、いつ、どのエージェントに、どのツール実行を依頼したか」を追跡できる状態にしておきましょう。
Durable Extension：長時間処理と障害復旧が必要な場合の選択肢
Durable Extension は、エージェント、マルチエージェント構成、Agent Framework のワークフローに耐久性のある実行を追加するための仕組みです。公式ドキュメントでは、セッションの永続化、進行状況のチェックポイント、障害からの復旧、分散ホストでのスケールなどが説明されています。(Microsoft Learn)
短いチャット応答だけなら、Durable Extension は必須ではありません。しかし、次のような業務では重要になります。
| 業務例 | Durable Extension が必要になる理由 |
|---|---|
| 稟議・承認フロー | 人間の承認待ちで処理が長時間停止する |
| 大量データ処理 | 処理途中で失敗しても最初からやり直したくない |
| 複数エージェントの順次実行 | どの段階まで完了したかを保持したい |
| 外部イベント待ち | Webhook、キュー、タイマーなどと組み合わせる必要がある |
| 分散実行 | 複数ワーカーで処理し、障害時に別インスタンスで再開したい |
Durable Extension は、Azure Functions と Bring-your-own-compute / self-hosted の2つのホスティングモデルをサポートしています。Azure Functions はサーバーレスで管理負荷を下げたい場合に向き、self-hosted はコンテナー、Kubernetes、既存サービスなど、自社の実行基盤に組み込みたい場合に向いています。(Microsoft Learn)
Azure Functions と self-hosted の選び方
| 観点 | Azure Functions | Bring-your-own-compute / self-hosted |
|---|---|---|
| 運用負荷 | 低い | 自社で管理が必要 |
| スケーリング | Functions の仕組みを利用 | 自社の設計次第 |
| ネットワーク制御 | Azure Functions の制約内 | より柔軟 |
| 既存アプリ統合 | イベント駆動に向く | 既存サービスへの組み込みに向く |
| 認証・API 公開 | Functions の HTTP エンドポイントを利用しやすい | 自社で API、認証、ルーティングを設計 |
| 利用例 | サーバーレス業務エージェント | Kubernetes 上の長時間ワーカー、社内基盤統合 |
公式ドキュメントでは、Azure Functions ホスティングでは HTTP エンドポイント、会話状態の保存、同時要求の処理、マルチエージェントワークフローの調整が自動的に扱われると説明されています。一方、self-hosted では、API 公開、ライフサイクル管理、ネットワーク、認証、デプロイモデルを自社側で担う必要があります。(Microsoft Learn)
この違いは重要です。Azure Functions は導入しやすい反面、プラットフォームの設計に合わせる必要があります。self-hosted は自由度が高い反面、運用設計の責任も大きくなります。
AG-UI Protocol：Web アプリに AI エージェントを組み込む場合の選択肢
AG-UI Protocol は、Web ベースの AI エージェントアプリケーションを構築するためのプロトコルです。公式ドキュメントでは、リアルタイムストリーミング、状態管理、インタラクティブ UI コンポーネント、Human-in-the-loop 承認などが説明されています。(Microsoft Learn)
AG-UI が向いているのは、単にテキストを返す API ではなく、ユーザー体験を重視した AI アプリを作る場合です。
たとえば、次のようなケースです。
| 利用シーン | AG-UI が有効な理由 |
|---|---|
| ブラウザー上で回答を逐次表示したい | SSE によるリアルタイムストリーミングを扱いやすい |
| ツール実行前にユーザー承認を取りたい | Human-in-the-loop のパターンを使える |
| エージェントの状態を UI に反映したい | クライアント・サーバー間の状態同期を設計しやすい |
| カスタム UI を動的に表示したい | ツール呼び出しに応じた UI レンダリングに向く |
| 複数ユーザーが同じエージェントサービスを利用する | HTTP ベースのリモートサービスとして公開できる |
公式ドキュメントでは、AG-UI Integration と直接的な Agent Framework 利用の違いも整理されています。直接利用ではアプリ内にエージェントを組み込みますが、AG-UI では HTTP 経由のリモートサービスとして公開し、SSE ストリーミングやプロトコルレベルの状態管理を利用できます。(Microsoft Learn)
AG-UI 導入時の注意点
AG-UI はフロントエンドとの連携を強化できますが、設計を誤ると複雑になります。
| 注意点 | 実務上の対策 |
|---|---|
| SSE が途中で切れる | ロードバランサー、プロキシ、WAF のタイムアウトを確認する |
| 承認フローが形だけになる | 何を承認するのか、承認ログをどう残すのかを決める |
| 状態同期が複雑になる | クライアント状態とサーバー状態の責任分界を明確にする |
| カスタム UI が増えすぎる | 業務価値の高いツールから段階的に実装する |
| 複数ユーザー利用で混線する | session ID、thread ID、ユーザー ID の対応を厳密に管理する |
Web UI にエージェントを載せる場合、見た目のデモは早く作れます。しかし、本番では「誰のセッションか」「どの操作を承認したか」「途中で切断した場合にどう再開するか」が重要です。AG-UI はそのための土台になりますが、業務要件に合わせた設計は必要です。
Microsoft Foundry Hosted agents との違い
Step 6 の次の学習先として、Microsoft Foundry の Hosted agents も紹介されています。Hosted agents は、コンテナー化したエージェントアプリケーションを Foundry Agent Service 上で実行する管理型の仕組みです。Microsoft の公式説明では、コンテナー化、Web サーバー、セキュリティ、永続化、スケーリング、計測、ロールバックなどの横断的な運用課題を軽減するための機能として位置づけられています。(Microsoft Learn)
Step 6 の ASP.NET Core / Azure Functions / self-hosted と比較すると、Hosted agents はよりマネージドな運用基盤です。
| 観点 | Step 6 のコードベースホスティング | Foundry Hosted agents |
|---|---|---|
| 実行基盤 | ASP.NET Core、Azure Functions、self-hosted などを選択 | Foundry Agent Service が管理 |
| デプロイ単位 | アプリケーションや Functions | コンテナー化された agent version |
| ID | 自分で Managed Identity や認証を設計する場面が多い | エージェントごとの Microsoft Entra ID が作成される |
| スケーリング | 選んだ基盤に依存 | セッション単位で管理される |
| プロトコル | A2A、OpenAI 互換、AG-UI などを実装 | Responses、Invocations、Activity、A2A などを組み合わせ可能 |
| 向いているケース | 既存アプリへの組み込み、細かい制御 | 管理型で安全に展開・運用したい場合 |
Hosted agents では、デプロイ時に専用の Microsoft Entra ID と専用エンドポイントが作成されると説明されています。また、セッションはアイドル状態になるとコンピュートが停止し、状態が保持される仕組みも示されています。(Microsoft Learn)
ただし、Hosted agents を使えばすべての責任が Microsoft 側に移るわけではありません。公式ドキュメントでは、サードパーティシステム利用時のリスク、データ所在地、権限、責任ある AI 対策について、利用者側の責任も明記されています。(Microsoft Learn)
設定変更で管理者が確認すべきポイント
Step 6 に関連する設定変更は、開発者だけで完結しません。管理者は、少なくとも次の項目を確認してください。
| 分類 | 確認ポイント | なぜ重要か |
|---|---|---|
| ID・認証 | DefaultAzureCredential を本番で使い続けていないか | 意図しない資格情報探索や権限過多を避けるため |
| Managed Identity | エージェント実行環境に必要最小限の権限を付与しているか | ツールや外部リソースへの過剰アクセスを防ぐため |
| エンドポイント公開 | A2A、OpenAI 互換、AG-UI の公開範囲を制限しているか | 未認証アクセスや外部呼び出しを防ぐため |
| セッション保存 | 会話履歴、ファイル、状態の保存場所と保持期間を決めているか | 個人情報・機密情報の管理に直結するため |
| ネットワーク | 社内 API、DB、Storage への接続経路を制御しているか | データ流出や不正アクセスを防ぐため |
| ログ・監視 | リクエスト、応答、ツール実行、エラーを追跡できるか | 障害対応と監査に必要 |
| 費用 | モデル呼び出し、CPU、メモリ、セッション数を見積もっているか | エージェントは利用増に伴いコストが膨らみやすいため |
| 責任ある AI | メタプロンプト、フィルター、承認、評価を入れているか | 誤回答や不適切な自動実行を抑えるため |
| サードパーティ連携 | 外部モデル、外部ツール、外部エージェントの利用条件を確認しているか | データ境界やライセンス違反を避けるため |
特に本番環境では、エージェントが実行できるツールの権限が問題になりやすいです。たとえば、顧客情報を検索できるツール、チケットを更新できるツール、メールを送信できるツールを付与する場合、単なるチャットボットではなく「業務操作を実行するアプリケーション」として扱うべきです。
移行期限はあるのか
2026年6月26日時点で確認できる Step 6: Host Your Agent の公式ページには、特定日までに既存システムを移行しなければならない期限は明記されていません。記事中で説明されているのは、主にホスティング方法、ASP.NET Core での登録、ワークフローの公開、Azure Functions での実行、関連プロトコルへの導線です。(Microsoft Learn)
そのため、現時点での対応は「期限付き移行」ではなく、新規構築・検証中の Agent Framework アプリの設計見直しとして捉えるのが現実的です。
ただし、次のような場合は早めに見直した方がよいでしょう。
| 状況 | 推奨対応 |
|---|---|
| ローカル実行のサンプルを本番公開しようとしている | DI 登録、認証、エンドポイント設計、ログ設計を見直す |
DefaultAzureCredential のまま本番デプロイ予定 | Managed Identity など明示的な資格情報へ変更を検討する |
| 会話履歴を保持する要件がある | インメモリではなく Durable Extension や永続ストレージを検討する |
| 複数エージェント連携を計画している | A2A Protocol と AgentCard の設計を始める |
| Web UI で承認や状態同期をしたい | AG-UI Protocol の採用可否を検討する |
| 既存 OpenAI 互換クライアントを使いたい | Responses API / Chat Completions API のどちらに寄せるか決める |
「期限がないから何もしない」ではなく、本番化の前に公開方式を決めることが重要です。あとからプロトコルや状態管理を変更すると、クライアントアプリ、監査ログ、権限設計、運用手順に広く影響します。
実務でのおすすめ構成パターン
Step 6 の内容を実務に落とし込むと、代表的な構成は次のようになります。
社内チャットボットを既存ツールから呼び出す
既存の OpenAI 互換 SDK やチャット UI を使いたい場合は、OpenAI-Compatible Endpoints が候補になります。
| 項目 | 推奨 |
|---|---|
| 公開方式 | OpenAI-compatible endpoint |
| API | 新規なら Responses API、既存互換重視なら Chat Completions API |
| 認証 | API Management、Entra ID、アプリ認証を組み合わせる |
| 状態管理 | 会話履歴が必要なら Responses API や外部ストレージを検討 |
| 注意点 | クライアント側に会話履歴を持たせる場合、機密情報の扱いを確認する |
Web アプリに AI エージェントを組み込む
Web フロントエンドでストリーミングや承認 UI を実装したい場合は、AG-UI が向いています。
| 項目 | 推奨 |
|---|---|
| 公開方式 | AG-UI Protocol |
| フロントエンド | React などの Web UI |
| 通信 | HTTP POST + SSE |
| 状態管理 | session ID / thread ID を明確に管理 |
| 注意点 | プロキシやロードバランサーの SSE タイムアウトを検証する |
複数エージェントを連携させる
部署別・機能別のエージェントを連携させたい場合は、A2A Protocol が候補です。
| 項目 | 推奨 |
|---|---|
| 公開方式 | A2A Protocol |
| 設計単位 | 専門エージェントごとに AgentCard を定義 |
| 認証 | 外部・内部の呼び出し元を分けて制御 |
| 状態管理 | contextId とセッションの対応を設計 |
| 注意点 | エージェント間で共有されるデータの範囲を明確にする |
長時間ワークフローや承認処理を実行する
処理が長時間続く、途中で人間の承認を待つ、障害時に再開したい場合は Durable Extension を検討します。
| 項目 | 推奨 |
|---|---|
| 公開方式 | Durable Extension |
| 実行基盤 | Azure Functions または self-hosted |
| 状態管理 | Durable Task infrastructure による永続化 |
| 適用例 | 承認、調査、バッチ、外部イベント待ち |
| 注意点 | 再実行時に副作用が重複しないように設計する |
導入前チェックリスト
Step 6: Host Your Agent を本番導入に進める前に、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 確認 |
|---|---|
| エージェントの公開目的が明確か | 人間向け、アプリ向け、他エージェント向けのどれか |
| ホスティング方式を選んだ理由を説明できるか | A2A、OpenAI 互換、Durable、AG-UI の選定理由があるか |
| 本番用の資格情報になっているか | 開発用資格情報やローカル依存が残っていないか |
| エンドポイントが保護されているか | 認証、認可、IP 制限、API Management などを検討したか |
| セッションと会話履歴の扱いを決めたか | 保存場所、保持期間、削除方法が決まっているか |
| ツール実行の権限が最小化されているか | 読み取り・更新・削除などの権限を分けているか |
| ストリーミングを検証したか | SSE、タイムアウト、再接続、キャンセルを確認したか |
| 障害時の挙動を検証したか | 再試行、再開、重複実行、途中失敗をテストしたか |
| ログと監査が取れるか | 誰が何を実行したか追跡できるか |
| コスト上限を設けたか | モデル利用量、CPU、メモリ、同時セッション数を見積もったか |
| サードパーティ接続を審査したか | データ共有、保持、リージョン、ライセンスを確認したか |
このチェックリストで1つでも曖昧な項目がある場合、本番公開前に設計を見直すべきです。AI エージェントは、通常の Web API よりも「判断」と「実行」を含みやすいため、公開後に権限やログを後付けするのは危険です。
まず何から対応すべきか
Microsoft の「Step 6: Host Your Agent」を確認した管理者・開発者が最初に行うべきことは、ホスティング方式の選定です。
順番としては、次の流れが現実的です。
- エージェントを誰が呼び出すのかを決める
- A2A、OpenAI 互換、AG-UI、Durable Extension のどれが適しているか選ぶ
- ASP.NET Core、Azure Functions、self-hosted、Foundry Hosted agents の実行基盤を比較する
- 認証、Managed Identity、RBAC、ネットワーク、ログを設計する
- セッション保存、会話履歴、ファイル、データ保持期間を決める
- 小さな検証環境で、ストリーミング、再試行、障害復旧、承認フローをテストする
今回の更新ポイントは、「エージェントを作れるようになった」ことではなく、「作ったエージェントをどう安全に公開し、運用するか」が明確になったことです。PoC の延長でそのまま公開するのではなく、公開プロトコル、認証、状態管理、監査、責任ある AI 対策をセットで設計することが重要です。
特にグローバル環境では、リージョン、データ所在地、外部サービス接続、権限委任、監査要件が国や組織によって異なります。まずは小さな業務ユースケースを1つ選び、OpenAI 互換エンドポイント、AG-UI、A2A、Durable Extension のどれが最も自然かを判断するところから始めると、後戻りの少ない構成にできます。
コメント