Microsoft Foundry / Azure OpenAIでAIエージェントを動かす第一歩は、単にモデルAPIを呼び出すことではなく、コンテナ化したエージェントをFoundry Agent Serviceへデプロイし、権限・実行環境・監視・コストまで含めて確認することです。2026年4月23日に更新されたMicrosoft Learnの「Quickstart: Deploy your first hosted agent」は、Azure Developer CLIまたはVS CodeのMicrosoft Foundry Toolkit拡張機能を使い、Hosted Agentを初回デプロイする流れを示しています。Hosted agentsは現時点でプレビュー扱いのため、IT管理者やプロダクトオーナーは「動いたか」だけでなく、RBAC、リージョン、モデル可用性、削除手順までセットで確認する必要があります。(Microsoft Learn)
Microsoft Foundry / Azure OpenAIの最新動向: Hosted Agentクイックスタートで何が変わったか
今回取り上げる「Quickstart: Deploy your first hosted agent」は、Foundry Agent Service上にコンテナ化されたAIエージェントをデプロイするための入門ドキュメントです。サンプルエージェントはFoundry modelsを呼び出し、Foundry toolsを利用し、Web検索や必要に応じてModel Context Protocol、いわゆるMCPツールを使える構成になっています。最終的にはFoundry playgroundからデプロイ済みエージェントと対話できる状態を目指します。(Microsoft Learn)
2026年4月更新で重要なのは、Hosted Agentが「開発者の実験用サンプル」だけではなく、Microsoft Foundry上でエージェントを実行・管理する実務的な導線として整理されてきた点です。GitHub上の履歴では、4月23日に初期化手順、言語選択、モデル構成、トラブルシューティングを明確化する変更が入っています。(GitHub)
特にAzure OpenAI利用者にとっては、これまでの「モデルをAPIで呼ぶ」発想から、モデル、ツール、エージェント実行基盤、ID、監視をひとまとまりで扱う発想へ移るサインと見てよいでしょう。Microsoft Foundryは、エージェント、モデル、ツールを統合し、RBAC、ネットワーク、ポリシー、監視、評価などを扱うAzure上のプラットフォームとして説明されています。(Microsoft Learn)
まず押さえるべき結論
Microsoft Foundry / Azure OpenAIのHosted Agentクイックスタートで確認すべきポイントは、次の5つです。
| 確認ポイント | 実務での意味 |
|---|---|
| Azure Developer CLIとVS Codeの2ルートがある | 自動化・再現性を重視するならazd、開発者体験を重視するならVS Codeが向く |
| Hosted Agentはプレビュー | 本番採用前にサポート条件、制約、リージョン、社内承認を確認する |
| RBACが重要 | Azure AI Project Manager、Contributor、OwnerまたはUser Access Administratorなどの権限設計が必要 |
| コンテナとACRが前提 | エージェントコードはコンテナイメージとして扱われる |
| 削除手順まで確認する | モデル、Foundry project、ACR、Application Insightsなどで課金が発生し得る |
クイックスタートでは、Python 3.10以降、Azure Developer CLI 1.24.0以降、またはVisual Studio CodeとMicrosoft Foundry Toolkit拡張機能が前提として示されています。さらに、Hosted Agentsの新しいバックエンドではazd ai agentの0.1.27-preview以降が必要とされ、旧来のAzure Container Appsベースの体験とは使うバージョンが分かれています。(Microsoft Learn)
Hosted Agentとは何か
Hosted Agentは、コードで作ったAIエージェントをコンテナ化し、Foundry Agent Serviceにホストする仕組みです。エージェントの推論部分はFoundry modelを使い、オーケストレーションやツール呼び出しの制御は自分たちのコードで行います。Microsoftの説明では、コンテナ化、Webサーバー設定、セキュリティ、スケーリング、計測、バージョン管理など、エージェント運用で横断的に発生する課題を扱いやすくするための仕組みとして位置付けられています。(Microsoft Learn)
Hosted Agentが向いているのは、プロンプトだけで完結しないユースケースです。たとえば、独自の業務ロジックを含む問い合わせ対応、社内APIを呼ぶ業務支援エージェント、Microsoft 365やTeamsとの連携を見据えたエージェント、LangGraphやSemantic Kernelなどのフレームワークを使ったエージェント開発が該当します。
一方で、単純なチャット補完や小規模なAzure OpenAI API呼び出しだけで十分な場合、いきなりHosted Agentに進む必要はありません。Microsoft Foundryのアーキテクチャ資料でも、エージェントホスティングや評価が不要でAzure OpenAIの補完だけが目的なら、スタンドアロンのAzure OpenAIリソースで足りる可能性があると説明されています。(Microsoft Learn)
2026年4月更新で実務上目立つポイント
4月23日前後の更新で、特に現場に影響しやすいのは次の点です。
| 更新ポイント | 何が実務に効くか |
|---|---|
azd ai agent initは空のディレクトリで実行する説明に整理 | 既存プロジェクトに誤って初期化する事故を避けやすい |
| 言語選択がC#またはPythonとして明示 | チームの技術スタックに合わせて初期サンプルを選びやすい |
| Agent TemplateとModel Configurationの説明が追加 | 新規モデルをデプロイするか、既存Foundry Projectのモデルを使うか判断しやすい |
| 認証エラー時の対処が具体化 | azd auth logout後にazd auth loginする流れが示され、認証の切り分けが早くなる |
azdと拡張機能のバージョン確認が強化 | azd 1.24.0以降、azure.ai.agents拡張の更新確認が重要になった |
| Responses APIとInvocations APIの入力形式が区別された | 文字列でよいケースとJSONペイロードが必要なケースを混同しにくい |
GitHubの差分を見ると、4月23日の変更では、初期化手順の表現、言語選択、モデル構成、認証エラー時の対処、azd ai agent init失敗時の確認項目などが修正されています。これは、単なる文章修正ではなく、初回導入でつまずきやすい箇所を減らすための実務的な更新と捉えるべきです。(GitHub)
Azure Developer CLIとVS Code拡張機能、どちらで始めるべきか
クイックスタートでは、Azure Developer CLI、つまりazdを使う方法と、VS CodeのMicrosoft Foundry Toolkit拡張機能を使う方法が示されています。どちらも初回デプロイに使えますが、目的によって選び方が変わります。
| 観点 | Azure Developer CLI | Microsoft Foundry Toolkit for VS Code |
|---|---|---|
| 向いている読者 | インフラ担当、DevOps担当、再現性を重視する開発者 | アプリ開発者、PoC担当、VS Code中心の開発チーム |
| 強み | コマンド化しやすく、CI/CDや手順書に落とし込みやすい | GUIでプロジェクト作成、モデルデプロイ、ローカルデバッグを進めやすい |
| 注意点 | 権限、環境変数、拡張機能バージョンの確認が重要 | プレビュー版拡張機能の利用確認が必要 |
| おすすめの使い方 | PoC後に標準手順として整備する | 初回検証や開発者向けハンズオンで使う |
azdルートでは、拡張機能のインストール、エージェントプロジェクトの初期化、Azureリソースのプロビジョニング、ローカル実行、デプロイという流れで進みます。VS Codeルートでは、Foundry Projectの作成、モデルデプロイ、Hosted Agentプロジェクト作成、依存関係インストール、F5によるローカルデバッグ、Foundry Agent Serviceへのデプロイという流れです。(Microsoft Learn)
azdで最初のHosted Agentを動かす基本手順
azdを使う場合、最小の流れは次のようになります。
azd ext install azure.ai.agents
azd ext list
azd ai agent init
azd provision
azd ai agent run
azd ai agent invoke --local "What is Microsoft Foundry?"
azd deploy
azd ai agent show --output table
azd ai agent monitor --tail 20この流れで重要なのは、デプロイ前にローカル実行で確認することです。クイックスタートでは、azd ai agent runでローカル起動し、別ターミナルからazd ai agent invoke --localでテストする流れが示されています。Responses APIを使うエージェントでは文字列ペイロードを送れますが、Invocations APIを使うサンプルではREADMEに記載されたJSONペイロードを確認する必要があります。(Microsoft Learn)
また、azd deployではエージェントコンテナがリモートでビルドされるため、クイックスタートのazdルートではローカルPCにDocker Desktopが必須ではありません。ただし、手動でコンテナ開発や本番向け設計を進める場合は、コンテナ要件やAzure Container Registryの制約を別途確認する必要があります。(Microsoft Learn)
IT管理者が事前に確認すべき権限とRBAC
Hosted Agentの導入で最も軽視してはいけないのが権限です。クイックスタートでは、Hosted Agentの作成とデプロイにAzure AI Project Managerが必要とされます。このロールには、エージェント作成に必要なデータプレーン権限と、プラットフォームが作成するエージェントIDへAzure AI Userロールを割り当てる権限が含まれます。(Microsoft Learn)
さらに、azd provisionでAzureリソースを作成するにはContributor権限が必要です。azd deployでエージェントIDにRBACロールを割り当てる場合は、Contributorに加えてOwnerまたはUser Access Administrator相当の権限が必要になる点も見落としやすいポイントです。(Microsoft Learn)
権限設計では、次のように分けて考えると失敗しにくくなります。
| 対象 | 確認すること |
|---|---|
| 作業ユーザー | Foundry ProjectでAzure AI Project Managerを持っているか |
| Azureリソース作成 | サブスクリプションまたはリソースグループでContributor権限があるか |
| ロール割り当て | OwnerまたはUser Access Administratorが必要な作業か |
| エージェントID | 実行時にモデルやツールへアクセスするためのAzure AI Userが付与されるか |
| ACR | Foundry ProjectのマネージドIDがコンテナイメージをpullできるか |
Microsoftの権限リファレンスでは、OwnerやContributorのようなAzure Resource Manager側の権限だけでは、エージェント作成や対話のようなFoundryデータプレーン操作をカバーできないことが説明されています。Azure AI DeveloperロールもHosted Agent用途では十分ではないと明記されているため、名前だけでロールを選ばないことが重要です。(Microsoft Learn)
プロダクトオーナーが見るべき導入判断
プロダクトオーナーにとって、Hosted Agentの価値は「AIを使える」ことではなく、業務プロセスの一部をエージェントとして安全に運用できるかにあります。
PoCを始める前に、次の3点を決めておくと評価がぶれません。
| 判断軸 | 具体的に決めること |
|---|---|
| 成功条件 | 回答精度、処理時間、問い合わせ削減率、担当者レビュー時間など |
| 利用範囲 | 社内検証のみ、特定部門向け、Microsoft 365やTeams連携を見据えるか |
| リスク許容度 | プレビュー機能の利用可否、外部ツール連携、ログ保存、個人情報の扱い |
特に、Web検索、Code Interpreter、ファイル検索、MCP、外部APIなどのツールを使う場合は、エージェントが「回答する」だけでなく「行動する」可能性があります。Foundry Agent Serviceのツール概要では、Web検索、Pythonコード実行、社内ドキュメント検索、外部API呼び出しなどが例として示されています。(Microsoft Learn)
リージョンとモデル可用性は必ず事前確認する
グローバル展開を想定する読者は、リージョン確認を後回しにしないでください。Microsoft Foundryのプロジェクトを作成できるリージョンと、Hosted AgentやAzure OpenAIモデル、ツールが使えるリージョンは同じとは限りません。Microsoft Learnのリージョンサポート資料でも、モデルや機能の可用性はリージョンによって異なり、デプロイ前にサービス別のページで確認するよう案内されています。(Microsoft Learn)
2026年4月末時点のHosted Agentsドキュメントでは、Hosted agentsの提供リージョンとしてAustralia East、Canada Central、North Central US、Sweden Centralが挙げられています。日本の読者は、Foundry Projectの候補リージョンにJapan Eastがあることだけで判断せず、Hosted Agent、モデル、ツールの組み合わせで実際に使えるか確認する必要があります。(Microsoft Learn)
コンテナとネットワークで失敗しやすいポイント
Hosted Agentはコンテナとして動くため、通常のアプリ開発とは違う確認項目があります。手動デプロイのドキュメントでは、エージェントコードをコンテナイメージとしてビルドし、Azure Container Registryへpushし、Foundry Agent Serviceがそのイメージをpullして実行する流れが説明されています。(Microsoft Learn)
特に注意したいのは、Azure Container Registryのネットワーク制約です。公式ドキュメントでは、Hosted Agentのコンテナイメージを保持するACRは現時点でパブリックエンドポイントから到達可能である必要があり、プライベートエンドポイントでパブリックネットワークアクセスを無効化した構成はサポートされていないと説明されています。セキュリティ基準が厳しい組織では、PoC前にネットワーク設計者と確認しておくべきです。(Microsoft Learn)
また、ホスティングプラットフォームはx86_64、つまりlinux/amd64のコンテナイメージを要求します。Apple SiliconなどARMベースの端末でビルドする場合は、プラットフォーム指定を忘れると動作しない可能性があります。(Microsoft Learn)
Responses APIとInvocations APIの選び方
Hosted Agentでは、エージェントの使い方に応じてプロトコルを選びます。会話型チャット、ストリーミング、複数ターンのやり取りを重視するならResponses APIが自然です。一方、Webhook受信、非会話型処理、カスタムの非同期ワークフローを扱うならInvocations APIが向いています。(Microsoft Learn)
クイックスタートでも、Responses APIでは文字列をペイロードとして送れる一方、Invocations APIではサンプルごとのREADMEを見てJSONペイロードを確認するよう案内されています。最初のPoCではResponses APIから始め、本格的に業務システムと接続する段階でInvocations APIを検討すると、学習コストを抑えやすくなります。(Microsoft Learn)
よくあるエラーと対処法
初回デプロイでは、コードの問題よりも環境・権限・名前の不一致で止まることが多くあります。クイックスタートに記載されている代表的なトラブルを、実務向けに整理すると次のようになります。
| 症状 | よくある原因 | 対処 |
|---|---|---|
AuthenticationErrorまたはDefaultAzureCredentialの失敗 | Azureログインセッションが古い | azd auth logout後にazd auth loginを実行 |
ResourceNotFound | エンドポイントURLやプロジェクト指定の不一致 | Foundry portalの値と設定ファイルを照合 |
DeploymentNotFound | モデルデプロイ名の不一致 | Build > Deploymentsでデプロイ名を確認 |
Connection refused | ローカルの8088番ポートが使用中 | 競合プロセスを停止するかポート設定を見直す |
AcrPullUnauthorized | ProjectのマネージドIDにACR pull権限がない | ACRに対するpull権限を付与 |
azd ai agent initの失敗 | azdや拡張機能が古い | azd version、azd ext list、azd ext upgrade azure.ai.agentsを確認 |
これらは、いずれもアプリケーションロジックの修正ではなく、権限、バージョン、リソース名、ポート、ACRアクセスの確認で解決できるケースが多い項目です。初回検証では、エラーが出た画面だけを見るのではなく、azdのバージョン、拡張機能、Foundry portal上のデプロイ名、RBAC割り当てをチェックリスト化しておくと再現性が上がります。(Microsoft Learn)
コスト管理ではazd downの意味を理解する
Hosted Agentのクイックスタートは、試して終わりではありません。デプロイ後は、モデルデプロイ、Foundry project、Azure Container Registry、Log Analytics Workspace、Application Insights、Managed Identityなどのリソースが作成されます。モデルやFoundry project、ACR、Azure Monitor関連の料金は利用状況や構成によって発生するため、検証後の削除手順まで含めて計画すべきです。(Microsoft Learn)
azd downは、クイックスタートで作成されたリソースを削除して課金を止めるための重要なコマンドです。ただし、既存のリソースグループを使っている場合は注意が必要です。公式ドキュメントでは、azd downがリソースグループ内のAzureリソースを削除し、Foundry project、モデルデプロイ、Container Registry、Application Insights、Hosted Agentなども対象になると警告しています。(Microsoft Learn)
PoC用には、既存の本番リソースグループを使わず、検証専用のリソースグループを作るのが安全です。プロダクトオーナーとIT管理者は、検証開始前に「誰が削除を承認するか」「ログや成果物を残す必要があるか」「削除後に再現できる手順があるか」を決めておきましょう。
本番検討に進む前のチェックリスト
Hosted Agentの初回デプロイに成功したら、すぐ本番化するのではなく、次の観点を確認します。
| チェック項目 | 確認内容 |
|---|---|
| ユースケース | エージェント化する業務が明確で、単純なチャットAPI呼び出しでは足りない理由があるか |
| 権限 | 作業者、Project、Agent identity、ACR、下流サービスの権限が最小権限になっているか |
| リージョン | Foundry Project、モデル、Hosted Agent、ツールが同じ計画内で利用可能か |
| プロトコル | Responses APIとInvocations APIのどちらがユースケースに合うか |
| ログと監視 | Application Insightsやazd ai agent monitorで問題調査できるか |
| バージョン管理 | エージェント更新時に、どのバージョンを利用者へ提供するか制御できるか |
| コスト | 検証・本番・停止時の費用と削除手順が明確か |
| プレビュー許容度 | プレビュー機能を本番または準本番で使える社内ルールか |
Microsoft Foundryでは、エージェントのライフサイクルとして、作成、テスト、ツール追加、バージョン保存、トレース、評価、公開、監視、改善の流れが整理されています。Hosted Agentも、単発のデプロイではなく、継続的に評価・監視・更新する対象として扱うべきです。(Microsoft Learn)
Azure OpenAI利用者はどう動くべきか
Azure OpenAIをすでに使っている組織は、いきなり全機能をMicrosoft Foundryへ寄せるのではなく、まずは次の順番で判断すると現実的です。
| 現在の状況 | 次の行動 |
|---|---|
| モデルAPIの単純利用が中心 | 既存構成を維持しつつ、Foundry移行の必要性を棚卸しする |
| 社内データ検索やツール連携を増やしたい | Foundry toolsやAgent ServiceのPoCを始める |
| TeamsやMicrosoft 365連携を見据えている | エージェントのID、認証、安定エンドポイント、公開方法を確認する |
| 複数チームでAIアプリを開発している | Foundry Project単位のRBAC、監視、評価の標準化を検討する |
Microsoft Foundryの公式資料では、Azure OpenAIから来た利用者向けに、エンドポイント、APIキー、既存状態を保持しながらFoundryリソースへアップグレードする導線も説明されています。ただし、移行は技術的な可否だけでなく、権限、ネットワーク、運用プロセス、監査要件と合わせて判断すべきです。(Microsoft Learn)
まとめ: 次にやるべきこと
2026年4月更新の「Quickstart: Deploy your first hosted agent」は、Microsoft Foundry / Azure OpenAIでHosted Agentを始めるための実践的な入口です。特に重要なのは、azdまたはVS Codeで動かす手順そのものではなく、Hosted Agentを支えるRBAC、コンテナ、ACR、リージョン、プロトコル、監視、コスト管理まで含めて理解することです。
最初に取るべき行動は明確です。検証専用のリソースグループを用意し、リージョンとモデル可用性を確認し、Azure AI Project Managerなど必要な権限を割り当てたうえで、azdまたはVS Codeでクイックスタートを1回通してください。その後、azd ai agent monitorでログを確認し、Foundry playgroundで応答を検証し、最後にazd downで削除まで行います。
Hosted Agentは、Azure OpenAIを単なるAPI利用から、業務アプリケーションとして運用する段階へ進めるための選択肢です。プレビュー段階であることを踏まえつつ、小さなPoCで権限・実行・監視・削除まで確認できれば、本番検討に進むための判断材料がそろいます。
コメント