【Microsoft Foundry】- hosted agentとは？

執筆日

2026/5/9

参考資料

https://learn.microsoft.com/ja-jp/azure/foundry/agents/concepts/hosted-agents

執筆日時点では、 パブリックプレビュー の機能です。

---

Hosted Agent とは？

自分で書いたコードをコンテナ化し、Microsoft のマネージドインフラ上でエージェントとして実行できる仕組み。

プロンプトとツール設定だけで定義される「プロンプトベースエージェント」とは異なり、フレームワークの選択やロジックの実装を開発者が完全にコントロールできる。インフラのライフサイクル管理はプラットフォームが担う。

---

なぜ Hosted Agent が必要なのか？

従来のエージェント開発の課題

エージェントをクラウドで動かすとき、開発者は AI ロジック以外に以下をすべて自前で管理する必要がある。

• コンテナ化・Web サーバーのセットアップ
• セキュリティ統合
• メモリ永続化
• インフラスケーリング
• 計装（インストルメンテーション）
• バージョンロールバック

これらは本質的な開発価値ではなく、インフラの煩雑さだ。Hosted Agents はこれをプラットフォームに委譲することで、開発者がエージェントのロジックだけに集中できるようにする。

---

Hosted Agent の仕組み

① セッションごとの VM 分離サンドボックス

リクエストが来るたびに、ハイパーバイザーレベルで分離された専用サンドボックスが各セッションに割り当てられる。プロセスレベルの分離（コンテナ共有）ではなく VM レベルの分離のため、セッション間でファイルシステムや実行環境が干渉しない。

② 永続ファイルシステム ＋ ゼロスケール

アイドル状態になるとコンテナはスケールゼロになり課金が止まる。しかしスケールゼロになってもファイルシステムの状態は保持される。次のリクエスト時、エージェントは中断した場所から正確に再開できる。

「アイドル時はコストゼロ、再開時はステートフルに復元」という両立がここで実現される。

③ Hosting Adapter によるフレームワーク抽象化

エージェントのコードをそのまま Foundry に繋げることはできない。Foundry には独自の Responses API プロトコルがあり、各フレームワークにはそれぞれのネイティブなデータ構造がある。この変換を担うのが Hosting Adapter だ。

Hosting Adapter があることで、開発者は「Foundry のプロトコルに合わせてコードを書き直す」必要がなくなる。好きなフレームワークで書いたコードを、アダプター経由でそのまま Foundry に接続できる。

ローカル開発時も同じ Hosting Adapter を使って localhost:8088 で HTTP サーバーを起動できるため、コンテナ化・デプロイの前にエージェントの動作を確認できる。

④ エージェント ID と発行（Publish）

Hosted Agent には発行前後で ID が変わるという重要な概念がある。
発行（Publish）すると、Foundry は以下を自動的に行う。

1. 専用の呼び出し URL を持つエージェントアプリリソースを作成
2. プロジェクト共有 ID とは独立した専用エージェント ID をプロビジョニング
3. Microsoft Entra エージェントレジストリに登録（検出・ガバナンスのため）

発行後は Web App・Teams / M365 Copilot・安定した API エンドポイント・カスタムアプリなど複数チャネルへの配布が可能になる。

---

全体アーキテクチャ

---

エージェントのライフサイクル

Hosted Agent は「作成 → 開始 → 実行 → 停止 → 削除」という標準的なライフサイクルに従う。

バージョン更新には「バージョン管理あり」「バージョン管理なし」の2種類がある。

更新種別	対象の変更内容	新バージョンが作成されるか
バージョン管理あり	コンテナイメージ・CPU/メモリ・環境変数・プロトコルバージョン	⚪︎
バージョン管理なし	スケール設定（min/max レプリカ数）・説明・タグ	×

---

エージェントタイプの比較

Foundry Agent Service には3種類のエージェントタイプがある。Hosted Agent はその中で最もカスタマイズ性が高い。

	プロンプトエージェント	ワークフローエージェント	Hosted Agent
定義方法	プロンプト＋ツール設定（GUI）	宣言的 YAML / GUI	コード（コンテナ）
カスタマイズ性	低	中	高
インフラ管理	不要	不要	不要（Foundry が管理）
フレームワーク	不可	不可	任意
ステータス	GA	Preview	Preview
向いているケース	迅速なプロトタイプ	マルチステップ・承認ワークフロー	複雑なカスタムロジック・既存コードの移植

---

対応言語・フレームワーク

公式ドキュメント（2026/5/10 時点）に明記されているのは以下の3種類のみ。

フレームワーク	Python	C#
Microsoft Agent Framework	⚪︎	⚪︎
LangGraph	⚪︎	×
カスタムコード（BYO）	⚪︎	⚪︎

Hosting Adapter は各フレームワーク向けにパッケージが分かれている。

パッケージ	用途
azure-ai-agentserver-core	コア（全フレームワーク共通）
azure-ai-agentserver-agentframework	Microsoft Agent Framework 用
azure-ai-agentserver-langgraph	LangGraph 用
Azure.AI.AgentServer.Core（.NET）	コア（C# 用）
Azure.AI.AgentServer.AgentFramework（.NET）	Microsoft Agent Framework 用（C#）

---

対応ツール

Hosted Agents は Foundry の組み込みツールを利用できる。
これに加え、MCP（Model Context Protocol）経由でリモートサーバーへの接続（RemoteMCPTool）も利用可能。認証方式は以下の3種類から選ぶ。

認証方式	概要
保存された資格情報	定義済みの資格情報を使用。全ユーザーが同じ ID で動作
プロジェクト Managed ID	Foundry プロジェクトのマネージド ID を使用。全ユーザーが同じ ID で動作
OAuth ID パススルー	ユーザーが個別アカウントで認証。ユーザーごとの権限を保持したい場合に使用

---

コストの考え方

Hosted Agent と プロンプトベースエージェントでは課金の構造が異なる。

コスト項目	プロンプトベース	Hosted Agent
ホスティング基盤	なし（Foundry が内包）	CPU × メモリ × レプリカ数 × 稼働時間
LLM 推論	トークン課金（従量）	トークン課金（従量）
ストレージ	File Search 用ベクターストレージ	ACR（コンテナイメージ保存）
可観測性	―	Application Insights（オプション）

スケーリングの考え方：

設定	挙動	向いているケース
min-replicas 0	アイドル時にゼロスケール。初回リクエストでコールドスタートが発生	散発的なリクエスト・コスト優先
min-replicas 1 以上	常時ウォームに保つ。レイテンシを最小化できる	高頻度リクエスト・レイテンシ優先

対応リージョン

公式ドキュメント（2026/5/10 時点）に明記されているのは以下。

• 米国東部 2
• 米国中北部
• スウェーデン中部
• カナダ中部
• 東南アジア
• ポーランド中部
• 南アフリカ北部
• 韓国中部
• インド南部
• ブラジル南部
• 米国西部
• 米国西部 3
• ノルウェー東部
• 東日本
• フランス中部
• スイス北部
• スペイン中部
• オーストラリア東部

---

注意事項・制限

制限項目	上限
サブスクリプションあたりの Foundry リソース数	100
Foundry リソースあたりの Hosted Agent 数	200
デプロイの min_replica 最大値	2
デプロイの max_replica 最大値	5

• プライベートネットワーク: ネットワーク分離 Foundry リソースでの作成は現在未対応
• シークレット管理: コンテナイメージや環境変数にシークレットを直接埋め込まないこと。Key Vault + Managed ID を使用する
• サードパーティ連携: Microsoft 以外のサービスにデータが流れる可能性があるため、データ保持ポリシーを事前確認すること
• Docker イメージのビルド: --platform linux/amd64 の指定が必須。ARM 環境（Apple Silicon Mac など）でビルドすると起動時にエラーが発生する

---