2026年4月29日のAzure AI公式ドキュメント更新「Update hosted agents region availability」は、Microsoft Foundry Agent ServiceのHosted agentsで利用できるリージョンが拡大したことを示す更新です。結論から言うと、開発者やクラウド管理者は「対象リージョンが増えたか」だけでなく、プロジェクトのリージョン、モデル可用性、ツール対応、ネットワーク、RBAC、移行計画まで確認する必要があります。リージョン一覧は今後も変わる可能性があるため、検証や本番展開ではGitHubのコミット情報だけでなく、最新のMicrosoft LearnページとAzureポータル上の表示を必ず突き合わせましょう。(GitHub)
Azure AIの公式ドキュメント更新「Update hosted agents region availability」で何が変わったか
今回の更新は、MicrosoftDocsのazure-ai-docsリポジトリに対するコミット2a7da62として記録されています。対象ファイルはarticles/foundry/agents/concepts/hosted-agents.mdで、Hosted agentsのリージョン可用性に関する記述へ7行が追加されました。コミットメッセージには「Added new regions for hosted agents availability」とあり、Hosted agentsの利用可能リージョンを増やすためのドキュメント更新であることが分かります。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 更新日 | 2026年4月29日 |
| 対象 | MicrosoftDocs / azure-ai-docs |
| コミット | 2a7da62 |
| 更新タイトル | Update hosted agents region availability |
| 変更内容 | Hosted agentsのリージョン可用性リストに新しいリージョンを追加 |
| 変更規模 | 1ファイル変更、7行追加、削除なし |
コミット上で追加されたリージョンは、East US 2、South East Asia、Poland Central、South Africa North、Korea Central、South India、Brazil Southです。なお、Microsoft Learnの現行ページでは、その後の更新によりさらに多いリージョンが掲載されている場合があります。公式ページ自体にも「追加リージョンが利用可能になればリストは更新される」と明記されているため、固定情報として扱わず、展開前に最新ページを確認することが重要です。(GitHub)
そもそもHosted agentsとは何か
Hosted agentsは、Microsoft Foundry Agent Service上で動作するコンテナ化されたAIエージェントです。プロンプトだけで定義するエージェントとは異なり、自分で用意したコードや任意のフレームワークをコンテナイメージとしてパッケージ化し、Microsoft管理のインフラ上で実行できます。公式ドキュメントでは、Agent Framework、LangGraph、Semantic Kernel、カスタムコードなどを利用できる用途が示されています。(Microsoft Learn)
実務では、次のようなケースでHosted agentsが候補になります。
| 利用シーン | Hosted agentsが向いている理由 |
|---|---|
| 独自の業務ロジックを含むAIエージェント | PythonやC#などで実装した処理をコンテナとして実行できる |
| Webhookや外部システム連携 | OpenAI互換のResponsesだけでなく、任意JSONを扱うInvocationsを使いやすい |
| 状態を保持するマルチターン処理 | セッション単位でファイルや状態を保持できる |
| 本番運用を見据えたエージェント | バージョン管理、ログ監視、トラフィック制御などを組み合わせやすい |
Hosted agentsは便利ですが、現時点ではプレビュー扱いの機能です。Agent Service全体がGAであっても、Hosted agentsの一部制約は異なる可能性があります。設計時は「Agent Serviceが使えるリージョン」と「Hosted agentsが使えるリージョン」を分けて確認しましょう。(Microsoft Learn)
今回の更新で最初に確認すべきこと
Azure AIの公式ドキュメント更新を見るときは、「自社の近くのリージョンが追加されたか」だけで判断しないことが大切です。Hosted agentsは、モデル、ツール、ネットワーク、権限、監視と組み合わせて動くため、リージョン対応だけでは本番利用の可否を判断できません。
追加リージョンが自社の要件に合うか
たとえば、APAC向けのサービスを運用している場合、Korea Central、South India、Southeast Asiaなどの選択肢が増えることは、レイテンシやデータ所在地の観点で有利になる可能性があります。ただし、Microsoft Learnの現行ページではJapan Eastなど、コミット時点とは異なるリージョンも掲載されています。最新の可用性は、Hosted agentsの公式ページで確認するのが安全です。(Microsoft Learn)
Microsoft Foundryプロジェクトのリージョンと一致するか
Hosted agentsを使うには、Microsoft Foundryプロジェクトのリージョンが前提になります。Foundryの機能可用性ページでは、Foundryプロジェクトを作成できるリージョンと、機能ごとの対応リージョンは必ずしも同じではないと説明されています。つまり、「Foundryプロジェクトを作成できるリージョン」だからといって、Hosted agentsや必要なモデル、ツールがすべて使えるとは限りません。(Microsoft Learn)
確認の順番は次の通りです。
| 順番 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | Foundryプロジェクトを作成できるか | 候補リージョンがFoundry対応リージョンに含まれる |
| 2 | Hosted agentsが使えるか | Hosted agentsのリージョン一覧に含まれる |
| 3 | 必要なモデルをデプロイできるか | 対象モデルとデプロイ方式がリージョンに対応している |
| 4 | 必要なツールが使えるか | File Search、Code Interpreter、MCPなどの対応を確認する |
| 5 | サブスクリプションのクォータが足りるか | AzureポータルやFoundryポータルで実際の割り当てを確認する |
リージョン追加が運用に与える影響
今回の「Update hosted agents region availability」は、単なるドキュメント変更ではなく、運用設計に影響する可能性があります。特に、グローバル向けサービス、法規制対応が必要な業務システム、低遅延が求められるアプリケーションでは、候補リージョンの増加がアーキテクチャ再検討のきっかけになります。
| 立場 | 確認すべきポイント |
|---|---|
| 開発者 | 自作エージェントのコンテナが新リージョンで動作するか、Responses / Invocationsのどちらを使うか |
| クラウド管理者 | RBAC、Azure Container Registry、クォータ、ログ監視、コスト管理 |
| ソリューションアーキテクト | データ所在地、レイテンシ、冗長化、依存サービスのリージョン整合性 |
| 技術意思決定者 | プレビュー機能の採用リスク、移行コスト、運用体制、本番投入時期 |
特に注意したいのは、リージョン追加が「自動的な移行」や「既存環境の改善」を意味しない点です。既存のFoundryプロジェクトやモデルデプロイが別リージョンにある場合、新しいリージョンを使うには、基本的に新規プロジェクト作成、モデル再デプロイ、エージェント再配置、外部連携の再確認が必要になります。
仕様確認で見落としやすいポイント
モデル可用性はHosted agentsの可用性と別に確認する
Hosted agentsが対象リージョンで使えても、利用したいモデルが同じリージョンで使えるとは限りません。Agent Serviceの制限とリージョンに関するドキュメントでは、モデルとリージョンの可用性は変わる可能性があり、Foundryポータルで実際にデプロイできる内容を確認するよう案内されています。(Microsoft Learn)
たとえば、社内FAQボットでgpt-4o系モデルを使う設計をしている場合、Hosted agentsのリージョン一覧だけでなく、対象リージョンでそのモデル、バージョン、デプロイ方式、クォータが利用できるかを確認する必要があります。
ツール対応はリージョンごとに差がある
Agent Serviceでは、すべてのツールがすべてのリージョンで使えるわけではありません。公式ドキュメントでは、例としてFile SearchがItaly NorthとBrazil Southでは利用できないことが示されています。今回のコミットではBrazil SouthがHosted agentsの追加リージョンに含まれていますが、Hosted agentsが使えることとFile Searchが使えることは別問題です。(Microsoft Learn)
RAG構成や社内文書検索を組み込む場合は、次のように確認しましょう。
| 使いたい機能 | 確認すべきこと |
|---|---|
| File Search | 対象リージョンで利用可能か |
| Code Interpreter | 対象リージョンとモデルで対応しているか |
| Web Search | 利用条件、ネットワーク、データ取り扱い |
| MCP連携 | 接続先サーバー、認証、データ所在地 |
| Azure AI Search連携 | Searchリソースのリージョンとネットワーク構成 |
ネットワークとAzure Container Registryの制約を確認する
Hosted agentsはコンテナイメージをAzure Container Registryに配置して利用します。公式ドキュメントでは、ネットワーク分離されたFoundryリソース内へのデプロイに対応する一方で、エージェントイメージを保持するAzure Container Registryは現時点でパブリックエンドポイントから到達可能である必要があり、プライベートネットワークで保護されたACRは現在サポートされていないと説明されています。(Microsoft Learn)
金融、医療、公共系などでネットワーク分離を厳密に設計している場合、この制約は大きな確認ポイントです。「リージョンが対応したから本番利用できる」と判断する前に、セキュリティ部門とACR到達性、イメージ管理、脆弱性スキャン、監査ログの要件をすり合わせましょう。
RBACとマネージドIDの設計を確認する
Hosted agentsでは、エージェントごとにMicrosoft Entra IDのエージェントIDが作成されます。デプロイ時には、モデル呼び出しや外部Azureサービスへのアクセスに必要なRBACを設定する必要があります。クイックスタートでは、Azure AI Project Manager権限やAzure AI Userロール、ACR pull権限などが説明されています。(Microsoft Learn)
本番環境では、次の権限を棚卸ししてください。
| 対象 | 確認内容 |
|---|---|
| デプロイ担当者 | Foundryプロジェクト作成、エージェント作成、RBAC割り当てができるか |
| プロジェクト管理ID | ACRからコンテナイメージをpullできるか |
| エージェントID | モデル、Storage、Cosmos DB、Searchなど必要なリソースにアクセスできるか |
| CI/CDサービスプリンシパル | デプロイ先リージョンで必要な権限を持つか |
| 監査 | 誰が権限を付与・変更したか追跡できるか |
移行準備でやるべき実務チェックリスト
新しいリージョンを使う場合、いきなり本番移行するのではなく、並行検証から始めるのが安全です。特にHosted agentsはプレビュー機能であり、リージョンごとの制約やポータル表示が変わる可能性があります。
| フェーズ | 作業 | 成功条件 |
|---|---|---|
| 現状把握 | 既存のFoundryプロジェクト、モデル、ツール、外部接続を一覧化 | 依存関係が1枚の構成図で説明できる |
| リージョン選定 | 候補リージョンを2〜3個に絞る | Hosted agents、モデル、ツール、クォータが確認済み |
| 検証環境作成 | 新リージョンにFoundryプロジェクトとモデルを作成 | 同じエージェントコードをデプロイできる |
| 機能テスト | ローカル実行、デプロイ、Playground、API呼び出しを確認 | 主要ユースケースが成功する |
| 運用テスト | ログ、監視、アラート、障害時手順を確認 | 障害を検知し、原因を追跡できる |
| 段階移行 | 一部トラフィックや一部ユーザーから切り替え | 品質、コスト、レイテンシが許容範囲内 |
| 本番反映 | DNS、アプリ設定、APIエンドポイントを更新 | ロールバック手順が用意されている |
Hosted agentsにはバージョン管理やトラフィックルーティングの仕組みがあり、同一エージェント内でバージョン別にトラフィック配分できます。公式ドキュメントでは、90%を旧バージョン、10%を新バージョンに流すカナリアリリースの例も示されています。ただし、リージョンをまたぐ移行では、アプリケーション側のルーティングやAPIエンドポイント切り替えも含めて設計する必要があります。(Microsoft Learn)
よくある失敗パターン
一般的なFoundryリージョン一覧だけで判断する
Foundryプロジェクトが作れるリージョンと、Hosted agentsが使えるリージョンは同じとは限りません。Foundryのリージョン対応ページでも、機能ごとの可用性はサービス別ページで確認するよう案内されています。Hosted agentsを使う場合は、必ずHosted agentsのページを確認しましょう。(Microsoft Learn)
Microsoft Q&Aやブログの古い情報をそのまま使う
リージョン可用性は更新頻度が高いため、過去のQ&Aやブログ記事の一覧が最新とは限りません。参考情報として使うのは問題ありませんが、本番判断ではMicrosoft Learnの公式ページ、GitHubコミット、Azureポータル上の実際の選択肢を優先してください。
「リージョン追加＝全機能対応」と誤解する
Hosted agentsが利用可能でも、モデル、File Search、Code Interpreter、評価機能、クォータが同じ条件で使えるとは限りません。特にRAG、コード実行、外部ツール連携を含むエージェントでは、機能単位でリージョン対応を確認する必要があります。
プレビュー機能の運用リスクを過小評価する
Hosted agentsはプレビューとして提供されています。検証環境では問題なく動いても、組織の本番基準では「SLA」「サポート条件」「変更頻度」「監査要件」を満たせない場合があります。意思決定者向けには、技術的に動くかどうかだけでなく、採用リスクを明文化しておきましょう。
すぐに使える確認テンプレート
社内レビューや設計レビューでは、次の項目をそのままチェックリストとして使えます。
| チェック項目 | OKの基準 | 未確認時のリスク |
|---|---|---|
| Hosted agentsのリージョン対応 | 最新Microsoft Learnに対象リージョンが掲載されている | デプロイ不可、ポータルに表示されない |
| Foundryプロジェクトの作成可否 | 対象リージョンでプロジェクト作成可能 | 設計した構成を再作成できない |
| モデル可用性 | 対象モデル、バージョン、デプロイ方式が利用可能 | エージェントは動いても推論できない |
| ツール対応 | File Search、Code Interpreter、MCPなどが確認済み | RAGや自動処理が動かない |
| クォータ | 想定トラフィックに必要なTPM/RPMやセッション数を確保 | 429エラーや性能不足が発生 |
| ACR到達性 | コンテナイメージをpullできる | デプロイや起動に失敗 |
| RBAC | エージェントIDとプロジェクト管理IDに必要権限がある | 認証エラー、外部リソース接続失敗 |
| 監視 | ログ、メトリック、アラートが設定済み | 障害原因を追跡できない |
| コスト | CPU、メモリ、モデル利用、監視ログの費用を見積済み | PoC後に予算超過 |
| ロールバック | 旧リージョンまたは旧バージョンへ戻す手順がある | 障害時に復旧が遅れる |
運用確認では、azd ai agent showで状態を確認し、azd ai agent monitorでログを監視できます。管理ドキュメントでは、バージョン状態の確認、ログストリーム、エージェント削除、エンドポイントルーティングなどの操作も説明されています。(Microsoft Learn)
どのチームが何をすべきか
開発チームは、エージェントコードが新リージョンでも同じように動くかを確認します。ローカル実行、コンテナビルド、Responses / Invocationsのプロトコル、環境変数、依存ライブラリを重点的に見てください。
クラウド運用チームは、Foundryプロジェクト、モデルデプロイ、ACR、RBAC、監視、コスト配賦を確認します。リージョン追加によって新しい選択肢が増えても、社内標準のリージョンやセキュリティポリシーに合わなければ採用できません。
アーキテクトは、データ所在地、可用性、レイテンシ、災害対策を設計します。たとえば、ユーザーがアジア、欧州、北米に分散している場合、単一リージョンで運用するのか、地域ごとに分けるのか、どのAPIエンドポイントをクライアントに向けるのかを判断する必要があります。
技術意思決定者は、プレビュー機能としての採用可否を判断します。PoCなら新リージョンを早期に試す価値がありますが、規制産業や基幹業務では、サポート条件、変更頻度、代替手段、撤退基準まで決めておくべきです。
今回の更新を受けて次に取るべき行動
Azure AIの公式ドキュメント更新「Update hosted agents region availability」は、Hosted agentsの利用範囲が広がっていることを示す重要な変更です。ただし、実務上の判断は「追加リージョンがあるか」だけでは不十分です。
まず、最新のHosted agents公式ページで現在のリージョン一覧を確認します。次に、対象リージョンでFoundryプロジェクト、モデル、ツール、クォータ、ネットワーク、RBACがそろうかを確認します。そのうえで、検証環境に同じエージェントをデプロイし、ログ監視、性能、コスト、ロールバック手順まで確認してから本番展開を判断しましょう。
特にグローバル向けのAzure AI活用では、リージョン追加は単なるニュースではなく、アーキテクチャを見直すタイミングです。今回の更新をきっかけに、Hosted agentsをどのリージョンで、どのモデルとツールの組み合わせで、どの運用基準で使うのかを整理しておくと、今後のリージョン拡大にも素早く対応できます。
コメント