ホスト型エージェントとは

オープンソース フレームワークを使用してエージェント アプリケーションを構築する場合、通常、コンテナー化、Web サーバーのセットアップ、セキュリティ、メモリ永続化、スケーリング、インストルメンテーション、バージョンのロールバックなど、多くの横断的な問題を管理します。 これらのタスクは、異種クラウド環境ではさらに困難になります。

Foundry Agent Service でホストされるエージェントは、Microsoft Foundry ユーザーに対するこれらの課題を解決します。 ホストされるエージェントは、Foundry モデル カタログからモデルを呼び出して推論を実行し、カスタム コードがオーケストレーションを処理します。 このマネージド プラットフォームを使用すると、AI エージェントを安全かつ大規模にデプロイして運用できます。 デプロイと管理を合理化して、カスタム エージェント コードまたは優先エージェント フレームワークを使用できます。

AI コーディング エージェントを使用してホストされたエージェントを探索する場合、Microsoft Foundry Skill は、これらの概念を実装、デプロイ、運用のタスクに結び付けるのに役立ちます。

ホストされているエージェントを使用する場合

必要に応じて、プロンプト ベースのエージェントよりもホストされるエージェントを選択します。

• 独自のコードの作成 - プロンプトのみの定義ではなく、任意のフレームワーク (Agent Framework、LangGraph、Semantic Kernel、またはカスタム コード) を使用します。
• カスタム プロトコルを使用する - 呼び出しプロトコルを使用して、Webhook または非 OpenAI ペイロードを受け入れます。
• コンピューティング リソースを制御 する - エージェントのサンドボックスの CPU とメモリを指定します。
• ステートフル ワークロードを実行する - $HOMEと /files エンドポイントを介して、複数のターンにわたってファイルと状態を保持します。
• 有効期間の長い作業を回復力を持って実行 する - プロセスの中断間で進行中のエージェント作業を保持し、ストリーミングされた結果を再生してクライアントを再接続します。

しくみ

エージェントをコンテナー イメージとしてパッケージ化し、Azure Container Registryにプッシュします。 デプロイすると、Agent Service によってイメージがプルされ、専用のMicrosoft Entra ID (エージェント ID) が割り当てられ、エージェントの専用エンドポイントが公開されます。

エージェント サービスは、実行時にセッションのコンピューティングをプロビジョニングし、要求をコンテナーにルーティングします。 エージェント コードはこれらの要求を処理し、そのエージェント ID を使用して Foundry モデル、ツールボックス ツール、ダウンストリーム Azure サービスを呼び出すことができます。 プラットフォームは、スケーリング、セッション状態の永続化、可観測性、およびライフサイクル管理を処理します。

次の図は、責任がどのように分割されるかを示しています。 サンドボックス内で実行されるコードを所有している。 プラットフォームは、エンドポイント、ID、スケーリング、および周囲のセッション状態を所有します。

主な概念

ホストされたエージェント

ホストされるエージェントは、エージェント サービスで実行されるコンテナー化されたエージェント AI アプリケーションです。 Foundry ポータルでプロンプトとツール構成によって完全に定義されるプロンプト ベースのエージェントとは異なり、ホストされるエージェントはコンテナー イメージとしてパッケージ化された独自のコードです。 フレームワークを選択し、ランタイムの動作を制御し、Microsoftマネージド インフラストラクチャにイメージをデプロイします。

プラットフォームは、アクティビティに基づいてコンテナーのライフサイクルを自動的に管理し、バージョンの作成時にリソースをプロビジョニングし、アイドル タイムアウトに達したときにプロビジョニングを解除します。

分離モデル

ホストされるエージェントは、セッションごとの VM 分離サンドボックスで実行されます。 各セッションは永続的なファイルシステム ($HOME と /files) を備えた専用のサンドボックスを取得し、ステートフルな再開と予測可能なコールド スタートによるゼロへのスケールを有効にします。 セッションは互いに分離され、アイドル状態になった後にセッションが再開されると状態が自動的に復元されます。

プロトコル: 応答、呼び出し要求、呼び出し要求 (WebSocket)

ホストされるエージェント コンテナーは、1 つ以上のプロトコルを公開できます。 各プロトコルは、HTTP または WebSocket サーバー、正常性チェック、OpenTelemetry 統合を処理する軽量ライブラリによって提供されます。 応答、呼び出し、および呼び出し (WebSocket) プロトコルは、 ホストされているエージェントをサポートするすべてのリージョンで使用できます。

どのプロトコルを使用する必要がありますか?

選択したプロトコルによって、コンテナーが受け取るペイロードと、プラットフォームが管理するセッション、ストリーミング、およびバックグラウンド ライフサイクルの量が決まります。 1 つのエージェントで複数のプロトコルをサポートできるため、この選択は永続的ではありません。 次のデシジョン ツリーを使用して、開始点を選択します。

プロトコルの比較

バックグラウンド モードと回復性のある実行によって、さまざまな問題が解決されます。 バックグラウンド モードでは、開始要求が返された後も作業を続行できます。 回復性のある実行では、ホスティング プロセスが停止した後も作業が保持されます。 復旧モデルとアプリケーションの役割については、 実行時間の長いホステッド エージェントの回復性に関するページを参照してください。

その他のプロトコル

また、ホストされるエージェントは、Teams とMicrosoft 365 チャネル統合の Activity プロトコルもサポートします。 エージェント ロジックに Responses プロトコルを使用し、Teams などのMicrosoft 365 チャネルに発行すると、プラットフォームはチャネル配信用のアクティビティ プロトコルに応答を自動的にブリッジします。個別の配線は必要ありません。 A2A プロトコルは、エージェント間の委任をサポートします。 サポートされているプロトコルは、1 つのエージェントで組み合わせることができます。

エージェント ID とエンドポイント

Foundry プロジェクトにデプロイされたすべてのホスト型エージェントは、独自の dedicated Microsoft Entra ID (エージェント ID) と dedicated エンドポイントを取得します。どちらもデプロイ時に自動的に作成されます。 マネージド ID またはルーティングを手動で構成する必要はありません。

エンドポイントはデプロイの直後に使用できます。プログラムによるアクセスには発行は必要ありません。

• 応答: {project_endpoint}/agents/{name}/endpoint/protocols/openai/responses
• 呼び出し (インボケーション): {project_endpoint}/agents/{name}/endpoint/protocols/invocations
• 呼び出し (WebSocket): wss://{account}.services.ai.azure.com/api/projects/{project}/agents/{name}/endpoint/protocols/invocations_ws?api-version=v1
• A2A (プレビュー): {project_endpoint}/agents/{name}/endpoint/protocols/a2a

アクティブなエンドポイントは、エージェント のバージョン定義で宣言されているプロトコルによって異なります。 azure.ai.agentを使用する場合は azure.yaml の azd サービスで、SDK を使用する場合は protocol_versions を使用して、この定義を設定します。

2 つの ID が関係します。

エージェント ID は、既定でプロジェクト エンドポイントとセッション ストレージを介してモデル推論にアクセスできます。 外部リソース (独自のAzure Storageなど) の場合は、エージェントのMicrosoft Entra IDに RBAC ロールを手動で割り当てます。 詳細については、 既定以外のエージェント アクセスに関するページを参照してください。

Microsoft 365 チャネル (Teams など) を介して統合された場合、ホストされるエージェントは、呼び出し方法に応じて 2 つの ID モードで動作できます。

• ユーザー呼び出しシナリオ (対話型): ユーザー トークンが存在する場合、プラットフォームは OAuth 2.0 On-Behalf-Of (OBO) フローをサポートします。 この場合、エージェントは、Microsoft Entra IDテナント ポリシーに従って、ユーザーの委任されたアクセス許可を使用して、ユーザーに代わってダウンストリーム サービスを呼び出すことができます。

• 自動またはバックグラウンドのシナリオ: 使用可能なユーザー トークンがない場合、エージェントは独自のMicrosoft Entra ID (エージェント ID) を使用して認証を行い、通常はマネージド ID を介してダウンストリーム サービスにアクセスします。

どちらの場合も、エージェントは認証、承認、監査の専用Microsoft Entra IDを保持します。 詳細については、「 エージェント アプリケーション と エージェント ID の概念」を参照してください。

セッションと会話

ホストされるエージェントは 、セッション と 会話を 使用して状態を管理します。 動作方法はプロトコルによって異なります。

セッション

セッション ID は、/files エンドポイントを介してアップロードされた$HOMEやファイルなど、永続化された状態の論理セッションを識別します。 プラットフォームはオンデマンドで計算リソースを提供し、永続化された状態をその上に復元します。

• 状態の永続化: $HOMEと /files のコンテンツは、ターン間およびアイドル期間にわたって保持されます。 コンピューティングがアイドル状態になり、(新規または既存のインフラストラクチャで) 復帰すると、セッションの状態が自動的に復元されます。
• 分離: 各セッションは、他のセッションから分離されます。
• 自動ライフサイクル: セッションは初回使用時に作成されます。 プラットフォームは、コンピューティング リソースを自動的にプロビジョニングおよびプロビジョニング解除します。
• セッションの有効期間: エージェント バージョンごとのアイドル タイムアウトは 5 分から 60 分まで構成できます。既定値は 15 分です。 そのウィンドウ内に要求が届かない場合、プラットフォームはコンピューティングのプロビジョニングを解除し、セッションの状態を保持します。 プラットフォームは、非アクティブ状態が 30 日後にセッションを完全に削除します。
• セッション管理 API: セッションを一覧表示し、セッションを終了し、セッションごとにファイルをアップロードまたはダウンロードします。

会話

会話 ID は、Foundry に格納されている会話履歴 (メッセージ、ツール呼び出し、応答) の永続的なレコードです。

• 永続化: 会話履歴は Foundry に格納され、コンピューティング状態とは無関係に保持されます。
• クロスチャネル アクセス: ユーザーは、プレイグラウンド、API、Teams、またはその他の公開されたチャネルから同じ会話にアクセスできます。

各プロトコルでのセッションと会話のしくみ

応答プロトコル: 会話 ID が主要な概念です。 プラットフォームは会話履歴を自動的に管理し、セッション ID を各会話に関連付けます。 プラットフォームはセッション ID をクライアントに返します。これを使用して /files エンドポイント経由でファイルをアップロードし、それらのファイルを会話のコンピューティングで使用できるようにします。

呼び出しプロトコル: セッション ID が主要な概念です。 クライアントはセッション ID を直接管理して、対話の間で状態を維持します。 クライアントは、セッション ID を使用して /files エンドポイント経由でコンテンツをアップロードして、セッションで使用できるようにします。 プラットフォームで管理される会話履歴はありません。独自のコードで状態を管理します。

セッション コンピューティングのライフサイクル

コンピューティングは、個々の要求ではなく、セッションに従います。 プラットフォームは、セッションの開始時にサンドボックスをプロビジョニングし、構成されたアイドル タイムアウトが最新の要求の後に経過したときにサンドボックスを解放します。 セッションが再開されると、プラットフォームは $HOME と /filesを復元するため、コードは前に書き込んだファイルを検索します。 次の図は、要求がこれらの状態を移動する方法を示しています。

セキュリティとデータの処理

ホストされたエージェントを運用アプリケーション コードのように扱います。

• コンテナー イメージまたは環境変数にシークレットを配置しないでください。 マネージド ID と接続を使用し、マネージド シークレット ストアにシークレットを格納します。 ガイダンスについては、「 Key Vault接続を設定する」を参照>。
• Microsoft以外のツールとサーバーに注意してください。 エージェントがMicrosoft サービス以外のツールを呼び出すと、一部のデータがそれらのサービスに流れる可能性があります。 接続するMicrosoft以外のサービスのデータ共有、保持、場所のポリシーを確認します。

プラットフォームの詳細

バージョニング

バージョンを作成する各呼び出しでは、 変更できないエージェント バージョンが生成されます。 バージョンは、コンテナー イメージ、リソースの割り当て、環境変数、およびプロトコル構成のスナップショットです。 エージェントを更新するには、新しいバージョンを作成してデプロイします。

エージェント エンドポイントは一度に 1 つのバージョンを提供し、そのトラフィックの 100% をそのバージョンにルーティングします。 バージョン間のトラフィック分割はサポートされていません。

環境変数は、実行時にコンテナーに構成を渡すための主要なメカニズムです (プロジェクト エンドポイント、モデルデプロイ名、カスタム設定など)。 これらはバージョンごとに設定され、バージョンが作成されると変更できません。

可観測性

ホストされるエージェントは、組み込みの可観測性を提供します。 プラットフォームは、環境変数を使用して、Application Insights 接続文字列をエージェント コンテナーに自動的に挿入します。 プロトコル ライブラリを使用するエージェントは、既定で OpenTelemetry トレースを出力します。このトレースは、リンクされた Application Insights リソースの [調査>Transaction 検索 または パフォーマンス] に表示されます。

構成と分析のガイダンスについては、「 プロジェクトでトレースを有効にする」を参照してください。

Foundry のツールボックス

ホストされるエージェントは、コード インタープリター、Web 検索 (Bing カスタム検索によるグラウンド処理)、Azure AI 検索、OpenAPI、MCP、A2A、スキルなど、Foundry で管理されるツールにフル アクセスできます。 これらのツールは、エージェント定義に直接追加するのではなく、Foundry プロジェクトでプロビジョニングされた ツールボックス MCP エンドポイント を介して接続します。 このツールボックスでは、OAuth ID パススルー、エージェント ID、キーベースの認証などの統合認証が提供されます。 Microsoft Agent Framework を使用する場合は、汎用 MCP クライアントではなく、Python または .NET でAddFoundryToolboxesFoundryToolbox経由で接続します。 他のランタイムは、標準の MCP クライアント ライブラリを使用して接続します。 詳細については、「 Foundry の意図ベースのツールボックスをキュレーションする」を参照してください。

言語のサポート

ホストされるエージェントは、Python と C# をサポートします。 任意のエージェント フレームワークを使用できます。プロトコル ライブラリはフレームワークに依存しません。 Microsoft Agent Framework、LangGraph、およびカスタム コードを使用するサンプルについては、foundry-samples リポジトリを参照してください。

サンドボックスのサイズ

ホストされるエージェント サンドボックスでは、次の CPU とメモリの組み合わせがサポートされます。

セッション ストレージ

各セッションには永続的な$HOMEが存在します。 構成されたアイドル タイムアウト後にコンピューティングのプロビジョニングを解除すると、プラットフォームはその内容を保持します。 プラットフォームはセッションの再開時にコンテンツを復元するため、 $HOME の下に書き込まれたファイルはアイドル期間中も存続します。 プラットフォームは、 /files エンドポイント経由でアップロードされたファイルを $HOMEに書き込み、そこで同じストレージを共有します。 各セッションのディスクの合計予算は 、1 vCPU 以上で最大 20 GiB であり、小さい CPU レベルでは比例してスケールダウンされます。 プラットフォームは、その予算の約20%をシステム用に確保しており、その分はエージェントには表示されず、利用することもできません。 残りの部分は、コンテナー イメージ、 $HOME、およびコンテナー内のその他の書き込み可能な場所の間で共有されます。

スケーリングと適切なサイズ設定

ホストされるエージェントは、レプリカごとではなく、セッションごとにスケーリングされます。 プラットフォームは、オンデマンドで各セッションに対して新しい VM 分離サンドボックスを作成し、要求が続行される間、そのコンピューティングをアクティブな状態に保ちます。 各要求によって、アイドル タイマーがリセットされます。 構成されたアイドル タイムアウトが最新の要求の後に経過すると、プラットフォームはサンドボックスコンピューティングのプロビジョニングを解除し、セッション状態を保持します。

アイドル タイムアウトは 5 ~ 60 分で、既定値は 15 分です。 プラットフォームは、非アクティブ状態が 30 日後にセッションを完全に削除します。 設定するレプリカ数もなく、ウォームプールのサイズを決める必要もありません。

すべてのセッションは独自のサンドボックスで実行されるため、エージェント のバージョンで設定した CPU とメモリの値は、エージェントの集約フットプリントではなく、 1 つのセッションを記述します。 課金は、すべてのアクティブなセッションで消費される CPU とメモリの使用量に基づいて計算されるため、必要以上に大きい構成にすると、コストは同時実行数に応じて増大します。

適切なサイズにするには、代表的なワークロードを実行し、リンクされた Application Insights リソースのリソース使用状況を調べます。

1. Azure ポータルで App Insights リソースを開き、Investigate>Performance を選択します。
2. CPU、使用可能なメモリ、要求レート、およびテストした期間の平均要求期間を確認します。

観測されたピークを、割り当てた CPU とメモリと比較します。 持続的なピークが約 70% の割り当てを超える場合は、次のエージェント バージョンの割り当てを上げます。ピークが低い場合は、コストを削減するためにそれを下げてください。 新しい各バージョンは不変であるため、変更後は常に再テストします。

プライベート ネットワーク

ホスト型エージェントは、ネットワーク分離 Foundry リソース内でのデプロイをサポートし、送信トラフィックに顧客が提供するAzure Virtual Networkを使用できます。 これにより、ネットワーク分離 Foundry デプロイのエージェントは、データベースや内部 API などのプライベート リソースに到達できます。 詳細については、「 仮想ネットワークの構成」を参照してください。

制限、価格、および可用性

価格

マネージド ホスティング ランタイムの課金は、アクティブなセッション中の CPU リソースとメモリ リソースの使用量に基づきます。 現在の料金については、Foundry の 価格に関するページを参照してください。

リージョンの可用性

現在、ホストされているエージェントは次のリージョンで利用できます。

• オーストラリア東部
• ブラジル南部
• カナダ中部
• カナダ東部
• 米国中部
• 米国東部
• 米国東部 2
• フランス中部
• ドイツ中西部
• イタリア北部
• 東日本
• 西日本
• 韓国中部
• 米国中北部
• ノルウェー東部
• ポーランド中部
• 南アフリカ北部
• 米国中南部
• インド南部
• 東南アジア
• スペイン中部
• スウェーデン中部
• スイス北部
• スイス西部
• アラブ首長国連邦北部
• 英国南部
• 英国西部
• 米国中西部
• 西ヨーロッパ
• 米国西部
• 米国西部 3

次の手順

関連コンテンツ

• エージェント ランタイム コンポーネント
• エージェント開発ライフサイクル
• Microsoft Foundry におけるエージェント・アイデンティティの概念
• Foundry のツールボックスとは
• Azure Container Registry ドキュメント