【Microsoft Azure】Microsoft FoundryのHosted Agentって？その立ち位置とMicrosoft Agent Frameworkとの関連性を整理してみる

こんにちは、MS開発部の渋谷です。みなさんはMicrosoft Foundryを利用されていますか？もちろん、Microsoft Foundryのモデルカタログに含まれるOpenAIのモデルを筆頭に様々なモデルを利用されている方もいらっしゃるかと思いますが、Microsoft Foundryには他にも「AIエージェント開発」に必要な様々な機能を一括で提供しています。今回はその中でもAgent ServiceのHosted Agentについて考えていきます。  

Microsoft Foundryおさらい

MicrosoftのAI開発環境は、急速な進化に伴い名称を変えました。当初「Azure AI Studio」として登場し、生成AIモデルのカタログやプレイグラウンド機能を提供していたサービスは、その後「Azure AI Foundry」へと改称され、最終的に2025年のMicrosoft Ignite前後のタイミングで「Microsoft Foundry」へと変更されました。Microsoft Foundryが持つ機能は主に以下の5つです。

• Foundry Models：OpenAI、Anthropic、Meta、Mistralなど11,000以上のモデルへのアクセスを提供。コストと性能のバランスを最適化する「モデルルーター」機能を含む。
• Foundry IQ：RAG（検索拡張生成）を動的な推論プロセスとして再定義し、Azure AI Searchと統合されたグラウンディングAPIを提供。データの機密性を保ちつつ、エージェントに知識を与える。
• Foundry Agent Service：エージェントのホスティング、オーケストレーション、メモリ管理を行うフルマネージドサービス。Hosted Agentはここの一機能。
• Foundry Tools：エージェントが実世界のシステムと連携するためのツール群（Azure Functions、OpenAPI等）への安全な接続を提供。
• Foundry Control Plane：ポリシー適用、可観測性（Observability）、セキュリティを一元管理する管理プレーン。

Agent Serviceのねらいは、AIエージェント特有の「運用の複雑さ」を解消することに重きが置かれています。一般的なWebアプリケーションと異なり、AIエージェントは以下のような特殊な要件を持ちます。

• ステートフルな対話管理: ユーザーとの過去のやり取り（コンテキスト）を維持し続ける必要があるが、LLM自体はステートレスである。

• 自律的なループ実行: ユーザーの入力を待たずに、エージェント自身が思考し、ツールを実行し、その結果を見て次の行動を決定するというループを回す必要がある。これには長時間の実行タイムアウト管理が必要となる。

• トークンとコストの制御: 無限ループや過度なトークン消費を防ぐためのガードレールが必要である。

• ツール連携の認証: 外部APIを叩く際、ユーザーの権限を借用（On-Behalf-Of）するか、エージェント自身の権限で行うかの厳密な制御が求められる。

Agent Serviceはこれらの機能をマネージドサービスとしてプラットフォームを提供しています。

Hosted Agentについて

Hosted Agentとは、いわゆるAgent Service上で稼働する、コードベースで構築されたコンテナ化エージェントアプリケーションとイメージするとわかりやすいです。これは、「宣言型エージェント（Declarative Agent）」とは対照的な存在でありDeclarative AgentがGUIベースの設定やプロンプトによって定義され、SaaSの制約内でのみ動作するのに対し、Hosted Agentは開発者がPythonやC#で記述したコードそのものが動作します。つまり、Microsoft Foundry内でGUIベースで宣言的にエージェントの作成を行うのではなく開発者がコードを用いてエージェントを作成するときに利用するものです。 Hosted Agentの実体はDockerコンテナです。開発プロセスにおいて、エージェントのロジック、依存ライブラリ（例えばデータ分析用のPandasや、特定業界向けの計算ライブラリなど）、そしてランタイム環境はすべてDockerイメージとしてパッケージングされ、このイメージがAzure Container Registry (ACR) にプッシュされ、Agent Serviceがそれをプルして実行するという仕組みになっています。Hosted Agentは、高度なカスタマイズを必要とするエンタープライズ開発者（Pro-code developers）向けに設計おり、以下の特長を持ちます。

• 完全なコード制御: 開発者はエージェントの挙動をコードレベルで完全に制御可能。独自のアルゴリズム、複雑な条件分岐、レガシーシステムとの独自のプロトコルによる通信など、宣言型エージェントでは不可能なロジックを実装可能。
• マネージドインフラストラクチャ: コンテナベースでありながら、Kubernetesクラスター（AKS）の管理やOSのパッチ適用といったインフラ運用はMicrosoftが行う。
• スケーリングと並行処理: Agent Serviceは、エージェントのプロビジョニングとオートスケーリングを処理する。トラフィックの増減に応じて、バックグラウンドでコンテナインスタンスが増減され、多数の同時対話を処理することが可能。

Hosted AgentとMicrosoft Agent Frameworkの連携

Microsoft Agent Frameworkで書かれたコード（クラスや関数）を、Agent Service上のサービスとして公開するのには、Hosting Adapterという仕組みを使っています。Hosting Adopterを使うことで以下のメリットを得られます。

• プロトコル変換: Microsoft Agent FrameworkやLangGraphで書かれたエージェントの内部的なメッセージ交換を、Foundry Agent Serviceが要求する標準的なHTTP REST APIやServer-Sent Events (SSE) プロトコルに自動変換。
• インフラの抽象化: アダプターが存在することで、エージェントのロジック（Agent Framework）と実行環境（Hosted Agent）が疎結合に。開発時はローカルでアダプターを介して localhost:8088 でテストし、本番時は同じコードをコンテナ化してFoundryにデプロイするだけで、認証やロギングの機能が自動的に有効化。

なお、Hosted AgentはMicrosoft Agent Framework専用ではなく、Hosting Adapterは、LangGraphや完全なカスタムコードもサポートしています。

---

Hosted Agentをデプロイする際は現状Azure Developer CLIを使い、Agentの定義ファイルやAzure構成の定義ファイルをもとにデプロイする方法とVS CodeのMicrosoft Foundry拡張機能を用いてデプロイする方法が用意されています。執筆現在はプレビューで提供されており、他にも方法が追加されると思います。 VS Codeを使う場合はコマンドパレットでDeploy Hosted Agentを選択して、必要なスペック等を選択することでデプロイが可能です。（※なお、執筆時点では米国中北部リージョンでのみHosted Agentが利用可能でした。）また、プレビュー中の期間は様々な制限があり、本番環境での利用に適していない点にも注意が必要です。組織内での検証で現状は利用し、一般提供が開始した後にエージェントのホスティングオプションの選択肢に加える方向で見てみるのが良いと思います。

まとめ

今回はMicrosoft FoundryのAgent Serviceの機能の1つであるHosted Agentについてみてみました。執筆時点ではまだプレビューで制限が多いサービスですが、エージェント開発における強力な選択肢の1つになりうるサービスになると思われます。特に、Microsoft Agent Frameworkとの組み合わせによって、開発者がローカルでDevUIを使ってテストするときと同じコードでHosted Agentへデプロイするといった体験を得られるのは大きなメリットだと思います。