Azure AI FoundryでAIエージェントを開発しているチームにとって、今回のHosted Agentsプレビューは「自前のエージェントコードを、Microsoft管理の実行基盤に載せやすくなる」更新です。従来のようにコンテナー、スケーリング、ID、監視を個別に設計する負担を減らしつつ、LangGraphやMicrosoft Agent Framework、独自コードなどを使ったコードベースのエージェントを運用しやすくします。特に、社内データや業務APIを呼び出すAI/Copilot系エージェントを本格展開したい管理者・開発者は、RBAC、Azure Container Registry、ネットワーク、コスト、プレビュー制限を早めに確認しておくべきです。
Azure AI FoundryのHosted Agentsとは
Hosted Agentsは、Microsoft Foundry Agent Serviceで利用できるコードベースのエージェント実行方式です。Microsoft Learnでは、Foundry Agent Serviceを「AIエージェントを構築、デプロイ、スケーリングするためのマネージドプラットフォーム」と説明しており、Hosted Agentsは自分のエージェントコードをコンテナーとしてパッケージ化し、マネージドエンドポイント、スケーリング、ID、可観測性とともに実行できる仕組みです。(Microsoft Learn)
重要なのは、Hosted Agentsが「プロンプトだけで作るエージェント」ではない点です。プロンプトエージェントはFoundryポータルやSDKで定義し、ランタイムコードを持たずに運用できます。一方、Hosted Agentsは独自の処理、外部API連携、フレームワーク固有のオーケストレーション、複雑なセッション状態を含むエージェントに向いています。Microsoft Learnでも、Hosted Agentsは自前のコードをコンテナーイメージとして実行し、フレームワークや実行時の挙動を開発者が制御できると説明されています。(Microsoft Learn)
なお、公式ドキュメント上では「Microsoft Foundry」という表記が増えていますが、Azure AI Foundryを利用している開発者・管理者に関係するFoundry Agent Serviceの更新として理解すると分かりやすいでしょう。
今回のPublic Previewで何が変わるのか
今回の要点は、Hosted AgentsがPublic Previewとして、よりエンタープライズ向けの運用に近い形で使えるようになったことです。Microsoftの公式ブログでは、Hosted Agentsについて、セッションごとの安全なサンドボックス、ファイルシステムの永続化、統合ID、スケールトゥゼロを備えた新しい体験として紹介されています。(Microsoft for Developers)
実務上の変化は、次の3点に集約できます。
| 変更点 | これまで課題になりやすかったこと | Hosted Agentsで期待できること |
|---|---|---|
| セッション単位の分離 | 複数ユーザーの状態や一時ファイルが同じ実行環境に混在するリスク | 各セッションがVM分離されたサンドボックスで実行される |
| マネージドな運用基盤 | コンテナー、スケーリング、監視、IDを個別に設計する必要がある | Foundry側がエンドポイント、スケーリング、ID、可観測性を管理 |
| コードベースの自由度 | プロンプト中心では独自ロジックや外部連携を組みにくい | 任意のフレームワークや独自コードをコンテナー化して利用可能 |
Hosted Agentsは、各セッションに専用のVM分離サンドボックスを割り当て、$HOMEや/filesの永続ファイルシステムを持ちます。アイドル状態になってコンピュートが解放されても、同じセッションが再開されると状態が復元される設計です。(Microsoft Learn)
これは、単なる「コンテナー実行サービス」ではなく、AIエージェント特有の状態管理やツール呼び出しを前提にしたランタイムと考えるべきです。
影響を受ける利用者とシステム
今回の更新で直接影響を受けるのは、Azure AI FoundryやMicrosoft Foundryでエージェントを構築・運用する開発者、クラウド管理者、セキュリティ担当者です。特に次のようなシステムでは、Hosted Agentsの採用を検討する価値があります。
| 対象 | Hosted Agentsが向くケース | 慎重に判断すべきケース |
|---|---|---|
| 社内業務エージェント | 社内API、DB、ストレージ、検索基盤を呼び出す | 単純なFAQや定型応答だけで十分 |
| Copilot連携エージェント | TeamsやMicrosoft 365経由で利用者に提供したい | まだPoC段階で権限設計が固まっていない |
| 開発支援エージェント | リポジトリ操作、コード生成、テスト実行など独自処理が多い | 外部ツールの安全性を検証できていない |
| 音声・Webhook・非同期処理 | 独自プロトコルやWebSocket、外部サービスのペイロードを扱う | 対応リージョンやプレビュー制限が要件に合わない |
反対に、単純なチャット応答、軽量なRAG、ポータルで設定できる範囲のツール連携で十分な場合は、Hosted Agentsよりもプロンプトエージェントの方がシンプルです。Microsoft Learnでも、プロンプトエージェントはアプリケーションコードやコンテナー管理が不要で、Hosted Agentsは独自コードやカスタムオーケストレーションが必要なケースに適すると整理されています。(Microsoft Learn)
管理者が最初に確認すべき設定
Hosted Agentsを試す前に、管理者は「動くか」より先に「安全に動かせるか」を確認する必要があります。AIエージェントはモデル呼び出しだけでなく、ファイル操作、外部API、社内データ、ユーザー権限を扱うためです。
RBACとEntra IDの確認
Hosted Agentsでは、デプロイされた各エージェントに専用のMicrosoft Entra IDが自動作成されます。このエージェントIDは、実行時にモデル、ツール、下流のAzureサービスへアクセスするために使われます。外部リソース、たとえば自社のAzure StorageやDBへアクセスする場合は、そのエージェントIDに対して必要なRBACを手動で付与する必要があります。(Microsoft Learn)
注意したいのは、管理者が「Foundry Userだけあれば十分」と判断してしまうことです。デプロイには、プロジェクトスコープのFoundry Project Managerが推奨されており、これはエージェント作成だけでなく、プラットフォームが作成するエージェントIDへFoundry Userを割り当てる権限も含むためです。(Microsoft Learn)
また、Foundry RBACロール名は最近変更されており、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前のAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerに相当します。ロール名の移行中は旧名が表示される可能性がありますが、ロールIDと主要な権限は変わらないとされています。(Microsoft Learn)
Azure Container Registryの到達性
Hosted Agentsは、エージェントコードをコンテナーイメージとして扱います。通常はAzure Container Registryにイメージをpushし、Agent Serviceがそれをpullして実行します。現時点では、Hosted Agentsが利用するAzure Container Registryはパブリックエンドポイントで到達可能である必要があり、プライベートエンドポイントでパブリックアクセスを無効化したACRはサポートされていません。(Microsoft Learn)
ここは企業環境で見落としやすいポイントです。セキュリティ基準としてACRのパブリックアクセスを禁止している組織では、Hosted Agentsの検証用に例外を設けるのか、別構成を待つのか、あらかじめ判断しておく必要があります。
ネットワークとリージョン
Hosted Agentsは、ネットワーク分離されたFoundryリソース内へのデプロイや、ユーザー提供のAzure Virtual Networkを使ったアウトバウンド通信をサポートしています。これにより、内部APIやプライベートなデータベースに接続する構成を取りやすくなります。(Microsoft Learn)
一方で、リージョン対応は固定ではありません。Microsoft Learnでは、Hosted Agentsが利用可能なリージョン一覧が示されており、日本向けにはJapan Eastが含まれていますが、今後追加・変更される可能性があります。(Microsoft Learn) 本番利用を見据える場合は、データ所在地、利用モデルの提供リージョン、Azure AI SearchやStorageなど周辺リソースのリージョンを合わせて確認してください。
開発者が押さえるべき実装上のポイント
Hosted Agentsは自由度が高い分、プロンプトエージェントよりもアプリケーション開発に近い設計が必要です。特に、プロトコル、コンテナー、環境変数、セッション状態の扱いが重要になります。
まずはResponsesプロトコルから始める
Hosted Agentsでは、Responses、Invocations、Invocations WebSocketなどのプロトコルを利用できます。Microsoft Learnでは、会話型チャットボット、RAG、ツール利用、バックグラウンド処理にはResponsesが適しており、Webhookや独自ペイロード、非会話型処理にはInvocationsが適すると整理されています。迷う場合はResponsesから始め、必要に応じてInvocationsを追加する方が安全です。(Microsoft Learn)
たとえば、社内文書検索エージェントならResponsesで十分なことが多いでしょう。一方、GitHub、Jira、Stripeなど外部サービスからWebhookを受け取り、そのペイロードをそのまま処理するエージェントならInvocationsの方が向いています。
コンテナーはlinux/amd64でビルドする
Hosted Agentsのコンテナーイメージは、x86_64、つまりlinux/amd64が必要です。Apple SiliconなどARMベースの環境で開発している場合、何も指定せずにDockerビルドすると互換性のないARMイメージを作ってしまう可能性があります。公式ドキュメントでも、ARM環境ではdocker build --platform linux/amd64 .の利用が案内されています。(Microsoft Learn)
このミスは、ローカルでは動くのにデプロイ後に失敗する典型例です。CI/CDでイメージをビルドする場合も、プラットフォーム指定を明示しておくとトラブルを減らせます。
環境変数とシークレットを分けて扱う
Hosted Agentsでは、FOUNDRY_PROJECT_ENDPOINT、FOUNDRY_AGENT_NAME、FOUNDRY_AGENT_VERSION、APPLICATIONINSIGHTS_CONNECTION_STRINGなどがプラットフォームから自動注入されます。これらのFOUNDRY_*変数を自分で再定義しないようにしてください。(Microsoft Learn)
また、APIキーやトークンをコンテナーイメージやagent.yamlに直接書くのは避けるべきです。公式ドキュメントでは、Foundryプロジェクト接続のプレースホルダーを使って、サンドボックス起動時に値を解決する方法が示されています。(Microsoft Learn) 実務では、次のように分けると管理しやすくなります。
| 設定の種類 | 管理方法の例 |
|---|---|
| モデル名、機能フラグ、ログレベル | agent.yamlやバージョンごとの環境変数 |
| APIキー、GitHubトークン、外部SaaS認証情報 | Foundry接続、Key Vault、マネージドID |
| Foundryが自動注入する値 | コードから参照のみ。再定義しない |
セッション状態を前提に設計する
Hosted Agentsでは、セッションIDが$HOMEや/filesの永続状態と関連します。アイドル状態が15分続くとコンピュートは解放されますが、状態は保持され、同じセッションが再開されると復元されます。セッションは30日間非アクティブだと削除されます。(Microsoft Learn)
この仕組みは便利ですが、「永続DBの代替」として何でも置く設計は避けるべきです。ユーザーが後から参照する正式なデータ、監査が必要なログ、業務トランザクションは、Cosmos DB、Storage、SQL Databaseなど適切な永続ストアに保存してください。$HOMEや/filesは、作業中の一時ファイル、生成物、セッション内の中間状態に使うのが現実的です。
移行・展開時の注意点
既に以前のHosted AgentsプレビューやAzure Container Appsベースの構成を試している場合、今回の更新をそのまま上書きと捉えない方が安全です。公式のクイックスタートでは、新しいバックエンドのHosted Agentsにはazd ai agentバージョン0.1.27-preview以降が必要で、Azure Container Appsを使うレガシー体験では0.1.25-previewを使うとされています。(Microsoft Learn)
既存PoCを移行する場合は、次の順で確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| CLIと拡張機能 | azd本体、Foundry関連拡張機能、プレビュー版の要件 |
| エージェント定義 | agent.yaml、プロトコル定義、CPU・メモリ、環境変数 |
| イメージ | linux/amd64、一意のタグ、ACRのpull権限 |
| IDとRBAC | エージェント専用Entra ID、外部リソースへの最小権限 |
| 監視 | Application Insights、OpenTelemetryトレース、失敗時のログ |
| トラフィック切替 | 旧版と新版の並行検証、カナリア、ロールバック手順 |
Hosted Agentsでは、バージョン作成ごとにコンテナーイメージ、リソース割り当て、環境変数、プロトコル設定のスナップショットが作成されます。バージョンはイミュータブルで、更新時は新しいバージョンを作成してデプロイします。また、重み付きロールアウトによりカナリアリリースやブルーグリーン展開にも対応できます。(Microsoft Learn)
本番に近い検証では、いきなり既存エージェントを置き換えるのではなく、新しいHosted Agentを別名で作成し、同じ入力に対する応答品質、レイテンシ、権限、ログ、コストを比較するのが安全です。
コストとスケーリングで失敗しやすいポイント
Hosted Agentsはセッション単位でスケールします。レプリカ数やウォームプールを自分で設定するのではなく、アクティブなセッションごとにVM分離サンドボックスが作られます。既定のアクティブ同時セッション数は、サブスクリプション・リージョンごとに50で、Microsoft Supportへのクォータ申請により調整可能です。(Microsoft Learn)
コスト面で特に注意すべきなのは、CPUとメモリの設定が「エージェント全体」ではなく「1セッションあたり」の割り当てであることです。Microsoft Learnでは、課金はアクティブセッション全体で消費されるCPUとメモリに基づくため、過剰なサイズ指定は同時実行数に比例してコストを押し上げると説明されています。(Microsoft Learn)
たとえば、1セッションに2 vCPU / 4 GiBを割り当てたエージェントが30セッション同時に動くと、実質的にはその30倍のリソースを見込む必要があります。最初から大きめにするのではなく、代表的な負荷を流してApplication InsightsでCPU、メモリ、リクエスト数、処理時間を見てから調整する方が現実的です。公式ドキュメントでも、継続的なピークが割り当ての約70%を超える場合は次バージョンで引き上げ、十分低い場合は下げて再テストする考え方が示されています。(Microsoft Learn)
セキュリティで特に注意すべきこと
Hosted Agentsは、業務システムに接続する「実行権限を持ったAIアプリケーション」です。通常のチャットボットよりも、権限とデータ流出のリスクを重く見てください。
まず、コンテナーイメージや環境変数にシークレットを埋め込まないことが基本です。公式ドキュメントでも、シークレットをコンテナーイメージや環境変数に直接置かず、マネージドID、接続、マネージドなシークレットストアを使うよう注意されています。(Microsoft Learn)
次に、サードパーティのモデル、サーバー、エージェント、ツールを呼び出す場合は、データ共有、保持、保存場所、ライセンス、追加コストを確認する必要があります。Microsoft Learnでは、Foundry ModelsとしてAzureから提供されるものではない第三者システムを使う場合、その利用や関連コスト、データが組織のAzureコンプライアンス・地理的境界の外へ流れる可能性の管理は利用者側の責任だと説明されています。(Microsoft Learn)
実務では、少なくとも次のチェックを行ってください。
| チェック項目 | 確認内容 |
|---|---|
| 最小権限 | エージェントIDに必要以上のAzure RBACを付けていないか |
| ユーザー委任 | TeamsやMicrosoft 365から呼び出す場合、OBOの権限範囲は適切か |
| 外部通信 | 非Microsoftサービスへ送信されるデータ項目を把握しているか |
| 監査 | 誰が、どのエージェントを、どのデータに対して実行したか追跡できるか |
| ガードレール | プロンプトインジェクション、過剰なツール実行、危険操作への対策があるか |
AIエージェントの事故は、モデルの回答ミスだけでなく「権限を持ったツールを誤って実行する」ことで起きます。Hosted Agentsを使う場合も、人間の承認が必要な操作、読み取り専用にすべき操作、自動実行してよい操作を分けて設計しましょう。
導入判断の目安
Hosted Agentsをすぐ検証すべきなのは、すでにAzure AI FoundryでエージェントPoCを進めており、次の壁にぶつかっているチームです。
- 独自コードやフレームワークを使いたい
- セッションごとにファイルや状態を保持したい
- 社内APIやAzureリソースへ安全に接続したい
- Teams、Microsoft 365 Copilot、独自アプリから同じエージェントを呼びたい
- コンテナー基盤を自前で運用する負担を減らしたい
一方、単純な社内FAQ、少人数向けの検証、プロンプトと標準ツールだけで足りる用途では、Hosted Agentsはやや重い選択肢です。まずプロンプトエージェントで応答品質と業務価値を確認し、独自ロジックや運用要件が明確になってからHosted Agentsへ進む方が失敗しにくいでしょう。
まず取るべき次のアクション
管理者は、利用可能リージョン、Foundry Project Managerロール、ACRの到達性、ネットワーク制約、クォータ、監査ログの確認から始めてください。開発者は、最小構成のHosted AgentをResponsesプロトコルで作成し、ローカル実行、linux/amd64ビルド、ACR push、デプロイ、Application Insightsでのトレース確認までを1本の手順にまとめるのが現実的です。
今回のHosted Agents Public Previewは、Azure AI Foundryのエージェント開発を「PoCで動く」から「運用を意識して展開する」段階へ進めるための更新です。まずは重要データを扱わない検証環境で、権限・ネットワーク・コスト・監視の4点を確認し、自社のAI/Copilotエージェント基盤に組み込めるか判断しましょう。
コメント