Microsoft Foundry Agent ServiceのHosted Agentsは、2026年4月の更新でパブリックプレビューとして位置付けられ、企業向けAIエージェントをマネージドにデプロイする選択肢として現実味が増しました。結論から言うと、今回のポイントは「カスタムコードのエージェントを、セッション単位の分離、状態保持、専用ID、スケール制御つきで実行できるようになった」ことです。
ただし、Public Previewは本番全面投入の合図ではありません。Azure Updatesのステータス説明では、Previewは非本番用途・テスト用途として利用できる段階とされています。IT管理者やプロダクトオーナーは、すぐに基幹業務へ投入するのではなく、既存のAIエージェントPoCを企業運用レベルへ引き上げるための検証対象として見るのが現実的です。(Microsoft Azure)
Microsoft Foundry Agent Serviceの最新動向: Hosted Agentsで何が変わったか
2026年4月24日にMicrosoft Azure Updatesで更新された「Hosted Agents in Foundry Agent Service enters public preview」は、Microsoft Foundry Agent ServiceにおけるHosted Agentsの公開プレビュー入りを示す更新です。関連するMicrosoft Foundry Blogでは、Hosted Agentsがパブリックプレビューとなり、エンタープライズ向けAIエージェントのためのエージェント最適化コンピューティングとして提供されることが説明されています。(Microsoft Azure)
従来、AIエージェントをローカル環境から企業利用へ移すには、コンテナー化、Webサーバー設定、セキュリティ、メモリ永続化、スケーリング、監視、バージョン管理などを個別に設計する必要がありました。Hosted Agentsは、これらをFoundry Agent Service側で扱いやすくするマネージド基盤です。カスタムエージェントコードや任意のフレームワークを使いながら、デプロイと運用管理を簡素化できる点が特徴です。(Microsoft Learn)
今回の更新を一言で表すなら、「AIエージェントを実験コードから、管理可能な業務アプリケーションに近づけるための実行基盤」です。
2026年4月更新で押さえるべき主なポイント
今回のHosted Agents公開プレビューで、IT管理者やプロダクトオーナーが特に見るべき点は次のとおりです。
| 更新ポイント | 何が変わるか | 実務上の意味 |
|---|---|---|
| セッション単位の分離 | 各エージェントセッションに専用の分離サンドボックスを割り当てる | 複数ユーザーの作業状態やファイル操作が混線しにくい |
| 状態保持 | $HOMEや/filesを使ってターン間・アイドル期間をまたいだ状態保持が可能 | 長時間タスク、ファイル処理、継続的な調査エージェントに向く |
| スケール・トゥ・ゼロ | アイドル時にコンピューティングを解除し、状態を保持して再開できる | 常時起動コストを抑えやすい |
| 専用EntraエージェントID | デプロイ時にエージェントごとの専用IDが割り当てられる | 共有サービスアカウントよりも権限管理・監査を設計しやすい |
| 専用エンドポイント | 各エージェントに専用エンドポイントが用意される | アプリ統合、バージョン管理、呼び出し経路の整理がしやすい |
| 複数プロトコル対応 | Responses、Invocations、Activity、A2Aなどを組み合わせられる | チャット、Webhook、非会話処理、エージェント間連携に対応しやすい |
Microsoft Learnでは、Hosted Agentsを「コンテナー化されたエージェントAIアプリケーション」と説明しています。プロンプトとツール設定だけで作るPrompt Agentとは異なり、Hosted Agentsでは自社コードをコンテナーイメージとしてパッケージ化し、Microsoft管理インフラ上にデプロイします。(Microsoft Learn)
Hosted Agentsは何を解決するのか
Hosted Agentsが解決しようとしている課題は、単なる「AIエージェントのホスティング」ではありません。ポイントは、エージェント特有のリスクを前提にした実行環境を提供することです。
通常のWebアプリやAPIでは、複数ユーザーのリクエストが同じ実行環境を共有する設計が一般的です。しかし、AIエージェントはファイルを書き換えたり、コードを実行したり、会話や作業状態を保持したりします。そのため、ユーザーAとユーザーBの作業が同じ実行環境で混ざると、セキュリティやデータ分離の問題が起きやすくなります。Microsoft Foundry Blogでも、従来型コンピューティングはこのエージェントの利用パターンに最適化されていないと説明しています。(Microsoft for Developers)
従来の実行基盤との違い
| 比較項目 | 従来のコンテナー・Webアプリ的な考え方 | Hosted Agentsの考え方 |
|---|---|---|
| 分離 | 複数セッションが同じ環境を共有しやすい | セッションごとに分離されたサンドボックスを使う |
| 状態管理 | 外部DBやストレージを自前で設計する | セッション状態やファイル保持をプラットフォーム側が支援する |
| ID管理 | 共有サービスアカウントになりがち | エージェントごとのEntra IDを使える |
| コスト | 常時稼働か、復帰遅延を許容する設計になりやすい | アイドル時にスケールダウンし、状態を保持して再開できる |
| 監視 | アプリ側で個別に実装する範囲が大きい | Agent、Session、Fleet単位の可観測性を意識した設計になる |
この違いは、特に「社内業務を代行するAIエージェント」を作る場合に重要です。単なるチャットボットなら状態管理は限定的でも運用できます。しかし、チケット調査、コード修正、資料作成、SaaS操作、承認ワークフローのように、複数ステップで実行結果を保持するエージェントでは、実行環境そのものの信頼性が問われます。
Prompt Agents・Workflow Agents・Hosted Agentsの使い分け
Foundry Agent Serviceには、Prompt Agents、Workflow Agents、Hosted Agentsという複数のエージェントタイプがあります。Microsoft Learnでは、Prompt Agentsは構成中心、Workflow Agentsは宣言的なワークフロー、Hosted Agentsはコードベースのエージェントとして整理されています。(Microsoft Learn)
| 種類 | 向いている用途 | コード要否 | 判断基準 |
|---|---|---|---|
| Prompt Agents | FAQ、社内ヘルプ、簡単な業務支援 | 不要 | プロンプト、モデル、ツール設定だけで十分な場合 |
| Workflow Agents | 承認、分岐、複数エージェントの連携 | 基本不要、YAML利用可 | 手順がある程度決まっていて、再現性を重視する場合 |
| Hosted Agents | カスタムロジック、独自フレームワーク、複雑な外部連携 | 必要 | エージェントの挙動をコードで細かく制御したい場合 |
Hosted Agentsを選ぶべきなのは、プロンプト設定だけでは足りないケースです。たとえば、LangGraphやMicrosoft Agent Framework、Semantic Kernel、独自コードで作ったエージェントを使いたい場合、Webhookや非OpenAI形式のペイロードを受けたい場合、CPU・メモリなどの実行リソースを指定したい場合、ファイルや状態をセッションをまたいで保持したい場合が該当します。(Microsoft Learn)
逆に、社内FAQや簡単な検索支援のように、複雑なオーケストレーションが不要な用途では、Hosted Agentsから始めると設計が重くなります。まずPrompt Agentで価値検証し、要件が複雑化した段階でHosted Agentsを検討する流れが現実的です。
Hosted Agentsの仕組みを実務目線で理解する
Hosted Agentsの基本的な流れは、エージェントをコンテナーイメージとして用意し、Azure Container Registryにプッシュし、Foundry Agent Serviceにデプロイするというものです。デプロイ時には、Agent Serviceがイメージを取得し、コンピューティングをプロビジョニングし、専用のEntraエージェントIDと専用エンドポイントを割り当てます。実行時には、そのIDを使ってFoundryモデル、Foundry Toolbox、下流のAzureサービスを呼び出せます。(Microsoft Learn)
実行イメージ
| ステップ | 担当 | 内容 |
|---|---|---|
| エージェント実装 | 開発者 | 任意のフレームワークや独自コードでエージェントを作る |
| コンテナー化 | 開発者 | Dockerfileなどで依存関係を含む実行環境を定義する |
| イメージ登録 | 開発・運用チーム | Azure Container Registryにイメージを配置する |
| デプロイ | Foundry Agent Service | コンピューティング、ID、エンドポイントを用意する |
| 実行・拡張 | Foundry Agent Service | セッション、状態、スケーリング、ライフサイクルを管理する |
| 監視・改善 | 運用チーム | ログ、トレース、評価結果を見ながら改善する |
この構成により、開発者はエージェントのロジックに集中しやすくなります。一方で、IT管理者は「どのエージェントが、どのIDで、どのデータやツールへアクセスするか」を設計する役割がより重要になります。
ResponsesとInvocationsの使い分け
Hosted Agentsでは、コンテナーがResponsesまたはInvocationsのいずれか、または両方のプロトコルを公開できます。Microsoft Learnでは、会話型アシスタントやRAG付きマルチターンQ&AではResponses、Webhookや任意JSON入力、非会話型処理ではInvocationsが適していると整理されています。(Microsoft Learn)
| プロトコル | 向いている用途 | 例 |
|---|---|---|
| Responses | 会話、チャット、RAG、ツール利用、バックグラウンド実行 | 社内問い合わせエージェント、調査エージェント、Teams連携 |
| Invocations | Webhook、任意JSON、非会話処理、独自プロトコル | GitHubイベント処理、請求データ分類、外部SaaSからの通知処理 |
| Activity | TeamsやMicrosoft 365チャネル連携 | 社内ユーザーがTeamsから使うエージェント |
| A2A | エージェント間の委任・連携 | 専門エージェント同士の分担処理 |
迷った場合は、ユーザーとの会話履歴やストリーミング、セッションライフサイクルをプラットフォーム側に任せやすいResponsesから始めるのが無難です。外部システムから独自形式のデータを受け取る、またはチャットではない処理を実行するならInvocationsを検討します。
IT管理者が見るべきセキュリティとガバナンスのポイント
Hosted Agentsは、AI開発者だけの新機能ではありません。むしろ、IT管理者が設計段階から関与すべき領域です。
Microsoft Learnでは、Hosted Agentsを本番アプリケーションコードのように扱うべきだと説明しています。また、コンテナーイメージや環境変数にシークレットを入れず、マネージドIDや接続、Key Vaultなどのマネージドなシークレットストアを使うことが推奨されています。(Microsoft Learn)
最初に確認したいチェック項目
| 確認項目 | 判断のポイント |
|---|---|
| エージェントID | エージェント単位で必要最小限のRBACを付与しているか |
| データ境界 | エージェントが扱うデータの保管場所・転送先を把握しているか |
| 外部サービス連携 | Microsoft以外のモデル、ツール、SaaSにどのデータが渡るか確認したか |
| シークレット管理 | APIキーや接続文字列をイメージや環境変数に直書きしていないか |
| 監査 | 誰が、どのエージェントを、どのエンドポイント経由で使ったか追跡できるか |
| ガードレール | メタプロンプト、コンテンツフィルター、承認フローなどの安全策を設けているか |
特にグローバル企業では、データが組織のAzureコンプライアンス境界や地理的境界の外へ流れる可能性を確認する必要があります。Microsoft Learnでも、サードパーティのモデル、サーバー、エージェントと連携する場合は、データ共有、保持、場所に関する扱いを確認するよう注意しています。(Microsoft Learn)
Product Ownerが見るべきビジネス上の価値
プロダクトオーナーにとってHosted Agentsの価値は、「AIエージェントをより複雑な業務に適用しやすくなること」です。
たとえば、次のようなユースケースではHosted Agentsが候補になります。
| ユースケース | Hosted Agentsが向く理由 |
|---|---|
| IT運用エージェント | ログ確認、設定変更、復旧手順など複数ステップの処理が必要 |
| サポートチケット分類・調査 | チケット、ドキュメント、履歴をまたいだ調査と状態保持が必要 |
| 開発支援エージェント | リポジトリ確認、ファイル編集、テスト実行などファイルシステム操作が必要 |
| 営業・CS支援エージェント | 顧客ごとの履歴や作業状態を継続的に扱いたい |
| 業務SaaS連携エージェント | Webhookや独自JSONを受け取り、外部ツールと連携したい |
一方、Hosted Agentsを使う目的が「AIっぽいチャットを作りたい」だけなら、過剰設計になる可能性があります。価値が出るのは、エージェントが単に答えるだけでなく、ファイルを扱い、外部システムを呼び出し、複数ターンにわたって作業を継続する場面です。
既存プレビュー利用者は移行計画が必要
すでに2026年4月以前のHosted Agents初期プレビューを使っていたチームは、今回の更新を単なる機能追加として見ないほうがよいでしょう。Microsoft Learnの移行ガイドでは、刷新されたPublic Previewにより新しいホスティングバックエンド、プロトコルライブラリ、IDモデル、管理APIが導入されたと説明されています。さらに、初期プレビューの旧バックエンドは自動移行されず、2026年5月22日までのサポートとされています。(Microsoft Learn)
移行で特に影響が大きいのは、次の項目です。
| 変更点 | 影響 |
|---|---|
| 自動コンピューティングライフサイクル | 手動の開始・停止・レプリカ管理を前提にした運用を見直す必要がある |
| セッションベースの分離 | ユーザーやワークロード単位のセッション設計が重要になる |
| プロトコルライブラリへの移行 | 旧来のフレームワーク別アダプターから、ResponsesやInvocationsなどのライブラリへ移る |
| 専用エージェントID | 下流リソースへのRBACをエージェントID単位で再設計する必要がある |
| 専用エンドポイント | 呼び出しURLやアプリ側の統合コードを更新する必要がある |
| capability host作成の廃止 | インフラ作成手順やIaC、運用手順書を更新する必要がある |
移行対象となるのは、2026年4月以前にazure-ai-agentserver-agentframeworkやazure-ai-agentserver-langgraphなどの初期プレビュー向けパッケージ、または初期プレビューのホスティングAPIを使っていたケースです。該当する場合は、単にSDKを更新するだけでなく、ID、エンドポイント、プロトコル、RBAC、監視の見直しまで含めて移行計画を作るべきです。(Microsoft Learn)
プレビュー時点の制限と注意点
Hosted Agentsは魅力的ですが、プレビュー段階であるため制限があります。Microsoft Learnでは、Hosted Agentsは現在プレビューであり、アクティブな同時セッション数はサブスクリプション・リージョンごとに既定で50、必要に応じてMicrosoft Supportへのクォータ要求で調整可能とされています。(Microsoft Learn)
また、サンドボックスサイズは0.25 vCPU/0.5 GiBから2 vCPU/4 GiBまでのCPU・メモリ割り当てをサポートするとされています。大規模なデータ処理や高負荷な推論をエージェント内で直接行う設計には向かない場合があるため、重い処理は別のAzureサービスへ逃がす設計も検討すべきです。(Microsoft Learn)
ネットワーク面では、Hosted Agentsはネットワーク分離されたFoundryリソース内でのデプロイをサポートします。ただし、エージェントイメージを保持するAzure Container Registryは、現時点ではパブリックエンドポイント経由で到達可能である必要があり、プライベートネットワークで保護されたACRは現在サポートされていないと記載されています。(Microsoft Learn)
導入前に避けたい失敗パターン
| 失敗パターン | 起きやすい問題 | 回避策 |
|---|---|---|
| Previewを本番GAと同じ扱いにする | サポート条件や仕様変更で運用影響が出る | 非本番PoC、限定ユーザー、段階的検証から始める |
| 共有権限で広くアクセスさせる | エージェントの操作範囲が過大になる | 専用Entra IDに最小権限を付与する |
| シークレットをイメージに含める | イメージ漏えい時に資格情報も漏れる | Key VaultやマネージドIDを使う |
| セッション設計を曖昧にする | ユーザーごとの状態管理が混乱する | isolation keyやセッションIDの設計方針を決める |
| 外部ツール連携を無審査で増やす | データ越境や保持ポリシー違反が起きる | 連携先ごとにデータ共有・保持・場所を確認する |
| 旧プレビューからの自動移行を期待する | 期限後に動作やサポートで問題が出る | 移行ガイドに沿って再デプロイ計画を立てる |
導入判断の基準
Hosted Agentsを検討すべきかどうかは、「エージェントにどれだけ自律的な実行環境が必要か」で判断すると分かりやすくなります。
Hosted Agentsを検討すべきケース
Hosted Agentsが向くのは、次の条件に複数当てはまる場合です。
- 独自コードや特定のエージェントフレームワークを使いたい
- ファイルの読み書きやコード実行を含むタスクがある
- 複数ターンにわたり作業状態を保持したい
- Webhookや独自JSONを受ける必要がある
- ユーザーやセッション単位の分離が重要
- エージェントごとのIDとRBACを設計したい
- 将来的にTeamsやMicrosoft 365、他エージェントとの連携を見据えている
まだHosted Agentsでなくてもよいケース
次のような場合は、Prompt AgentsやWorkflow Agents、既存のAzure Functions、Azure Container Apps、AKSなどのほうが適している可能性があります。
- 単純なFAQや社内検索支援が主目的
- プロンプトとツール設定だけで十分
- セッション状態やファイル永続化が不要
- Previewサービスを使えない本番要件がある
- 高負荷なバッチ処理を安定的に回したい
- 既存のコンテナー運用基盤で十分に統制できている
Hosted Agentsは「すべてのAIエージェントの標準解」ではありません。複雑なエージェントを安全に運用したい場合の選択肢として評価するのが適切です。
検証を始めるための実務ステップ
Hosted Agentsを検証する場合は、技術検証だけでなく、運用・セキュリティ・ビジネス価値を同時に確認する流れが重要です。
| ステップ | 実施内容 | 成果物 |
|---|---|---|
| 目的を決める | どの業務をエージェント化するか決める | ユースケース定義 |
| エージェントタイプを選ぶ | Prompt、Workflow、Hostedのどれが適切か判断する | 技術方式メモ |
| データと権限を棚卸しする | 利用データ、外部連携、必要RBACを整理する | セキュリティ設計 |
| 小さく実装する | Microsoft Agent Framework、LangGraph、独自コードなどで最小構成を作る | PoCエージェント |
| コンテナー化する | 依存関係、Dockerfile、環境変数を整理する | コンテナーイメージ |
| Foundryにデプロイする | ACR、エンドポイント、ID、プロトコルを確認する | 検証環境 |
| 評価する | 応答品質、コスト、遅延、監査、障害時挙動を確認する | 評価レポート |
| 段階展開する | 限定ユーザーから拡大し、必要ならカナリアやブルーグリーンを使う | 運用計画 |
Hosted Agentsでは、バージョン作成時にコンテナーイメージ、リソース割り当て、環境変数、プロトコル構成などのスナップショットが作られます。エージェントを更新するには新しいバージョンを作成し、カナリアデプロイやブルーグリーンデプロイのようにバージョン間でトラフィックを分割することもできます。(Microsoft Learn)
この仕組みは、プロダクトオーナーにとっても重要です。AIエージェントは「一度作って終わり」ではなく、プロンプト、ツール、モデル、コード、権限、評価基準を継続的に改善するプロダクトです。バージョン管理と段階展開を前提にすると、改善サイクルを安全に回しやすくなります。
まとめ: まずは非本番PoCで、エージェント運用の現実解を検証する
Microsoft Foundry Agent ServiceのHosted Agents公開プレビューは、AIエージェントを企業システムとして運用するための重要な更新です。特に、セッション単位の分離、状態保持、専用EntraエージェントID、専用エンドポイント、スケール・トゥ・ゼロ、複数プロトコル対応は、従来の「ローカルでは動くが、本番運用が難しい」問題を解消する方向にあります。
一方で、Public Previewであること、同時セッション数やサンドボックスサイズなどの制限があること、ACRのプライベートエンドポイント対応に制約があること、旧プレビュー利用者には移行対応が必要なことは見落とせません。
次に取るべき行動は明確です。まず、既存のAIエージェント構想やPoCを棚卸しし、「プロンプトだけで足りるもの」「ワークフローで十分なもの」「Hosted Agentsで検証すべきもの」に分類してください。そのうえで、最も効果が測りやすく、データリスクを管理しやすい1つのユースケースを選び、非本番環境でHosted Agentsのデプロイ、ID管理、セッション設計、監視、コストを検証するのが現実的な第一歩です。
コメント