Azure AIでHosted agentsを検証・運用している場合、2026年4月30日の公式ドキュメント更新「Update hosted agents region list」は必ず確認しておきたい変更です。結論から言うと、この更新はHosted agentsで利用できるリージョン一覧の拡張・整理に関するもので、アプリのコード仕様変更というより、デプロイ先、データ所在地、レイテンシ、クォータ、移行計画に影響する可能性がある更新として見るべきです。
特に日本の開発者やクラウド管理者にとっては、リストにJapan Eastが含まれている点が重要です。これまで別リージョン前提で検証していたHosted agents構成を、日本東日本リージョン中心の設計へ見直せる可能性があります。ただし、Microsoft Foundry Agent ServiceのHosted agentsはプレビュー扱いの機能であり、リージョン可用性は今後も更新される前提で確認する必要があります。(GitHub)
Azure AIの公式ドキュメント更新「Update hosted agents region list」で何が変わったか
今回の更新は、MicrosoftDocsのazure-ai-docsリポジトリに対するコミットとして公開されています。コミット内容を見ると、対象ファイルはarticles/foundry/agents/concepts/hosted-agents.mdで、Hosted agentsのリージョン一覧に対して10行追加、3行削除の差分が入っています。(GitHub)
この更新で重要なのは、Hosted agentsの機能説明そのものではなく、「どのAzureリージョンでHosted agentsを使えるか」という運用設計に直結する情報が更新された点です。
現在の公式ドキュメントでは、Hosted agentsは次のリージョンで利用可能とされています。(Microsoft Learn)
| リージョン | 確認ポイント |
|---|---|
| East US 2 | 米国東部系の既存検証環境で使われやすい候補 |
| North Central US | 米国内の別地域分散や検証先として確認 |
| Sweden Central | EU圏・北欧向けの配置候補 |
| Canada Central | カナダ向けワークロードの候補 |
| Southeast Asia | アジア向けだが、日本国内利用ではレイテンシとデータ所在地を別途確認 |
| Poland Central | EU圏内の追加候補 |
| South Africa North | アフリカ地域向けの候補 |
| Korea Central | 東アジア向けの候補 |
| South India | インド向けの候補 |
| Brazil South | 南米向けの候補 |
| West US | 米国西部向けの候補 |
| West US 3 | 米国西部系の追加候補 |
| Norway East | 欧州・北欧向けの候補 |
| Japan East | 日本向け構成で特に確認したい候補 |
| France Central | フランス・EU圏向けの候補 |
| Switzerland North | スイス向け、データ所在地要件がある場合に確認 |
| Spain Central | スペイン・EU圏向けの候補 |
| Australia East | オーストラリア向けの候補 |
コミット差分上は、West US、West US 3、Norway East、Japan East、France Central、Switzerland North、Spain Centralなどが新たに追記された地域として読み取れます。一方で、Australia Eastは差分上では一度削除され、リスト末尾に再追加されています。そのため、単純に「Australia Eastが新規追加された」と断定するより、リージョン一覧の整理・再配置も含む更新と捉えるのが安全です。(GitHub)
Hosted agentsとは何かを簡単に整理する
Hosted agentsは、Microsoft Foundry Agent Serviceで提供されるコードベースのエージェント実行環境です。任意のフレームワークで作成したエージェントをコンテナとしてデプロイし、Foundry Agent Service側でランタイム、スケーリング、インフラ管理を担う仕組みです。公式ドキュメントでは、Agent Framework、LangGraph、独自コードなどで構築したHosted agentsをデプロイできると説明されています。(Microsoft Learn)
通常のチャットボットがテキスト応答中心であるのに対し、エージェントはツール呼び出し、外部データアクセス、複数ステップの判断を組み合わせてタスクを実行します。Microsoft Foundry Agent Serviceは、ホスティング、スケーリング、ID、監視、エンタープライズセキュリティを扱うため、開発者はエージェントのロジックに集中しやすくなります。(Microsoft Learn)
ただし、Hosted agentsは現時点でプレビューです。公式ドキュメントでもHosted agentsはプレビュー中と明記されており、リージョン一覧についても「追加リージョンが利用可能になるにつれて更新される」とされています。(Microsoft Learn)
今回のリージョン更新で確認すべき実務ポイント
今回の「Update hosted agents region list」は、単なるドキュメント修正に見えても、実務ではいくつかの確認作業が必要です。特に、developers、cloud admins、solution architects、technical decision makersは、次の観点で影響を切り分けると判断しやすくなります。
デプロイ先リージョンをJapan Eastに変更できるか
日本企業や日本向けサービスでHosted agentsを使う場合、Japan Eastが選択肢に入ることは大きな意味があります。
これまでは、米国やシンガポール、韓国などのリージョンで検証していた構成でも、Japan Eastで作成できるなら次の改善が期待できます。
| 観点 | Japan Eastを確認する理由 |
|---|---|
| レイテンシ | 日本の利用者に近いリージョンを使うことで応答遅延を抑えやすい |
| データ所在地 | 国内運用ポリシーや顧客説明で整理しやすい |
| ネットワーク設計 | 既存のAzureリソースがJapan East中心なら連携しやすい |
| 運用体制 | 国内時間帯での監視・障害対応設計と合わせやすい |
ただし、リージョン一覧に載っていることと、すべてのサブスクリプション・SKU・関連リソースで直ちに同じ構成が作れることは同義ではありません。実際の利用可否は、Azureポータル、Azure Developer CLI、SDK、サブスクリプションの制約、モデルSKUの可用性を合わせて確認する必要があります。
既存のIaCやCI/CDのlocation指定を見直す
Hosted agentsを検証済みのチームでは、Bicep、Terraform、Azure Developer CLI、GitHub Actions、Azure DevOpsなどにリージョン指定が固定されていることがあります。
たとえば、検証時に米国リージョンを指定していた場合、Japan Eastへ変更するだけで済むとは限りません。モデル、Azure Container Registry、ネットワーク、監視、RBAC、接続先ツールのリージョン制約を合わせて確認する必要があります。
見直すべき代表的な設定は次の通りです。
| 確認対象 | 具体的に見る場所 | 失敗しやすいポイント |
|---|---|---|
| デプロイ先リージョン | location、--location、環境変数 | Hosted agentsだけでなく関連リソースの可用性も必要 |
| モデルデプロイ | Foundryプロジェクト、モデルSKU | 対象リージョンで希望モデルやSKUが使えない場合がある |
| ACR | コンテナイメージの保存先 | ネットワーク分離時でもACRの到達性要件を確認する |
| RBAC | Azure AI Project Manager、Azure AI Userなど | 自動付与に必要な権限が不足するとデプロイで止まる |
| 監視 | Application Insights、ログ出力先 | リージョン変更後にログ連携が抜けることがある |
| CI/CD | azd deploy、GitHub Actions、Azure DevOps | 手元では動くがパイプラインで権限やリージョンがずれる |
公式クイックスタートでも、Hosted agentプロジェクトの初期化時にはAzureサブスクリプション、リソースのLocation、モデルSKU、コンテナサイズなどを選択する流れになっています。つまり、リージョン更新は単なる表示変更ではなく、初期構成パラメータの選択肢に関わる変更です。(Microsoft Learn)
クォータをリージョン単位で確認する
Hosted agentsは、プレビュー期間中の制限として「サブスクリプション・リージョンごとの最大アクティブ同時セッション数」が50とされています。この値はMicrosoft Supportへのクォータリクエストで調整可能と説明されています。(Microsoft Learn)
ここで重要なのは、クォータはグローバルに一律で見るのではなく、リージョン単位で確認することです。
たとえば、North Central USで検証していた環境をJapan Eastへ移す場合、既存リージョンで問題なく動いていた同時接続数が、そのまま移行先でも許容されるとは限りません。PoC、本番、負荷試験のそれぞれで、次のように確認すると安全です。
| フェーズ | 確認すること |
|---|---|
| PoC | 1〜数名の検証でデプロイ・実行・ログ確認ができるか |
| 社内展開 | 想定ユーザー数で同時セッション上限に近づかないか |
| 本番前 | ピーク時の同時実行数、再試行、タイムアウトを含めて検証 |
| 本番運用 | クォータ引き上げが必要な場合の申請リードタイムを確認 |
特にAIエージェントは、単純なAPI呼び出しよりも処理時間が長くなりやすく、ツール呼び出しや外部API連携を含むとアクティブセッションが伸びることがあります。平均応答時間だけでなく、ピーク時の滞留を見てクォータを設計することが大切です。
料金影響をCPU・メモリ・アクティブセッションで見る
Hosted agentsのManaged hosting runtimeは、アクティブセッション中に消費されるCPUとメモリリソースに基づいて課金されると説明されています。公式ドキュメントでは、現在の料金はFoundryの価格ページを参照する形になっています。(Microsoft Learn)
そのため、リージョンが増えたからといって、すぐにコストが下がるとは限りません。確認すべきなのは、次の3点です。
| コスト確認項目 | 見るべき内容 |
|---|---|
| コンテナサイズ | 必要以上に大きなCPU・メモリを割り当てていないか |
| セッション時間 | ツール呼び出しや外部API待ちで実行時間が伸びていないか |
| 周辺リソース | ACR、ログ、ストレージ、ネットワーク転送などを含めて見積もっているか |
公式ドキュメントでは、Hosted agent sandboxesが0.25 vCPU / 0.5 GiBから2 vCPU / 4 GiBまでのCPU・メモリ割り当てをサポートすると説明されています。小さな社内エージェントなら小さめの構成から始め、応答時間やエラー率を見て段階的に調整するのが現実的です。(Microsoft Learn)
Japan Eastが使える場合の設計メリット
Japan Eastを利用できる場合、日本向けのAzure AI構成では設計の選択肢が広がります。特に、すでにAzure OpenAI、Azure AI Search、Storage、Application Insights、Virtual Networkなどを日本リージョン中心に置いている組織では、Hosted agentsも同じ地域に寄せることで構成を説明しやすくなります。
代表的な活用シーンは次の通りです。
| 活用シーン | Japan Eastを選ぶ理由 |
|---|---|
| 社内ナレッジ検索エージェント | 日本国内のユーザーが多く、既存データも国内リージョンにある |
| 顧客問い合わせ支援 | 応答速度とデータ管理の説明責任が求められる |
| 業務システム連携エージェント | 既存のAPI、VNet、監視基盤が日本リージョン中心 |
| PoCから本番移行 | 海外リージョン検証から国内運用へ移しやすい |
一方で、Japan Eastを選べばすべて解決するわけではありません。エージェントが呼び出すモデル、ツール、検索インデックス、外部API、業務データベースが別リージョンにある場合、ネットワーク遅延やデータ移動の考慮が残ります。Hosted agentsのリージョンだけでなく、エージェントが依存する全体構成で判断する必要があります。
移行前に確認したいチェックリスト
既存のHosted agents検証環境を新しいリージョンへ移す場合、いきなり本番を切り替えるのは避けるべきです。まずは同じ構成を新リージョンに複製し、機能・性能・権限・監視を段階的に確認します。
| 確認項目 | チェック内容 | 合格基準の例 |
|---|---|---|
| リージョン作成可否 | 対象サブスクリプションでHosted agentを作成できるか | AzureポータルまたはCLIで作成できる |
| モデル可用性 | 利用予定モデルとSKUが対象リージョンで使えるか | 既存と同等のモデル構成が作れる |
| RBAC | デプロイ担当者とエージェントIDに必要権限があるか | デプロイ・実行時に権限エラーが出ない |
| コンテナイメージ | ACRからイメージを取得できるか | Hosted agentが正常に起動する |
| ネットワーク | VNet、Private Endpoint、外部API接続が成立するか | 必要な通信だけが許可されている |
| ログ・監視 | トレース、メトリック、Application Insights連携が取れるか | 障害時に原因追跡できる |
| 性能 | 応答時間、同時実行、タイムアウトを測る | 想定ピークでも許容範囲に収まる |
| コスト | CPU・メモリ・セッション時間を見積もる | 月額上限や予算アラートと整合する |
| ロールバック | 旧リージョンへ戻す手順があるか | 切り戻し判断と手順が明文化されている |
公式クイックスタートでは、ローカルテスト後にazd deployでFoundry Agent Serviceへデプロイする流れが示されています。移行時も同様に、ローカル検証、ステージング環境、本番相当の順で確認すると失敗を減らせます。(Microsoft Learn)
権限不足でつまずかないための注意点
Hosted agentsのデプロイでは、単にAzureリソースを作成できるContributor権限だけでは不十分な場合があります。
公式クイックスタートでは、Hosted agentsの作成とデプロイにはプロジェクトスコープのAzure AI Project Managerが必要であり、エージェントIDには実行時にモデルや成果物へアクセスするためのAzure AI Userが必要と説明されています。また、azd deployによるRBACロール割り当てには、OwnerまたはUser Access Administrator権限が必要になる場合があります。(Microsoft Learn)
移行プロジェクトでよくある失敗は、開発者のローカル環境ではOwner権限で成功したのに、CI/CDでは権限が絞られてデプロイに失敗するケースです。これを防ぐには、次のように役割を分けて確認します。
| 役割 | 必要な確認 |
|---|---|
| 開発者 | ローカル実行、エージェントコード、依存ライブラリの確認 |
| クラウド管理者 | サブスクリプション、RBAC、クォータ、ポリシーの確認 |
| セキュリティ担当 | VNet、ACR到達性、外部通信、ログ保全の確認 |
| アーキテクト | リージョン選定、DR、性能、コスト、移行順序の判断 |
権限は広く付ければ解決するように見えますが、本番運用では最小権限の原則が重要です。初回デプロイ時だけ強い権限が必要なのか、継続運用でも必要なのかを分けて設計しましょう。
ネットワーク分離構成ではACR到達性に注意する
Hosted agentsは、ネットワーク分離されたFoundryリソース内へのデプロイをサポートしています。ただし、公式ドキュメントでは、エージェントイメージを保持するAzure Container Registryは現時点でパブリックエンドポイントから到達可能である必要があり、private-network-secured ACRは現在サポートされないと説明されています。(Microsoft Learn)
これは、セキュリティ要件が厳しい組織ほど見落としやすいポイントです。
「すべてPrivate Endpoint化する」という既存方針がある場合、Hosted agentsの仕様と衝突する可能性があります。特に金融、医療、公共、製造業などで閉域構成を前提にしている場合は、次の観点で事前レビューが必要です。
| 確認観点 | 具体的な確認内容 |
|---|---|
| ACRの公開範囲 | パブリック到達性を許容できるか |
| イメージ管理 | 脆弱性スキャン、署名、タグ固定を行っているか |
| 送信制御 | エージェントから外部APIへ出る通信を制御できるか |
| 監査 | デプロイ、起動、ツール呼び出しのログを追跡できるか |
リージョンが増えるとデプロイしやすくなりますが、ネットワークとセキュリティの前提まで自動的に緩和されるわけではありません。むしろ、利用可能リージョンが増えたタイミングで、セキュリティ標準との整合性を再確認することが重要です。
アーキテクチャ判断では「近いリージョン」だけで選ばない
Hosted agentsのリージョン選定では、地理的に近いリージョンを選ぶのが基本です。しかし、実務ではそれだけでは不十分です。
特にエンタープライズ向けのAIエージェントでは、次の条件を合わせて判断します。
| 判断軸 | 確認すべきこと |
|---|---|
| 可用性 | 対象リージョンで必要なサービスがそろっているか |
| データ所在地 | 顧客契約、社内規程、業界ルールに合うか |
| レイテンシ | ユーザー、モデル、検索、DB、外部APIの距離は適切か |
| 運用 | 監視、障害対応、サポート体制と合うか |
| DR | 障害時に別リージョンへ復旧できる設計か |
| コスト | リージョン差、ネットワーク転送、周辺リソースを含めて見ているか |
Microsoftの参照アーキテクチャでは、Foundry Agent ServiceがAzure Cosmos DB、Storage、AI Searchなどと連携し、エージェントの状態、チャット履歴、ファイル、検索インデックスなどを扱う構成が示されています。つまり、Hosted agentsの移行ではエージェント本体だけでなく、状態管理や検索基盤も含めた構成確認が必要です。(Microsoft Learn)
また、同参照アーキテクチャでは、Foundry Agent Serviceに組み込みのDR機能がなく、状態の復旧はレプリカ昇格ではなく再構築によって行うと説明されています。リージョン変更や本番導入を検討する場合は、エージェント定義、会話履歴、ナレッジデータの復旧方針を事前に決めておくべきです。(Microsoft Learn)
開発チームがすぐに取るべきアクション
今回の更新を受けて、開発チームは次の順番で確認すると効率的です。
| 優先度 | アクション | 目的 |
|---|---|---|
| 高 | 公式ドキュメントの現在のリージョン一覧を確認する | 古い情報で設計しないため |
| 高 | 自社で使いたいリージョンにHosted agentを作成できるか試す | 実サブスクリプションでの可用性確認 |
| 高 | モデル、ACR、ネットワーク、RBACを同じリージョン前提で確認する | 依存関係の抜け漏れ防止 |
| 中 | 既存IaCのlocation指定を棚卸しする | 移行時の設定漏れ防止 |
| 中 | クォータと負荷試験計画を見直す | 本番時の同時実行不足を避ける |
| 中 | コスト見積もりを更新する | CPU・メモリ・実行時間ベースの課金を把握 |
| 低 | リージョン追加を前提に将来のDR案を検討する | 本番運用の信頼性向上 |
特にJapan Eastを使いたい場合は、まず小さなHosted agentを作成し、モデル呼び出し、ツール呼び出し、ログ出力、削除までを一通り試すのがおすすめです。いきなり本番構成を移すより、最小構成で「作れる・動く・監視できる・消せる」を確認した方が、後続の設計判断が速くなります。
今回の更新をどう受け止めるべきか
2026年4月30日の「Update hosted agents region list」は、Azure AIのHosted agentsを本格的に検討しているチームにとって、単なるドキュメント差分ではありません。利用可能リージョンが広がることで、これまで海外リージョン前提だった検証を、より利用者やデータに近いリージョンへ寄せられる可能性があります。
一方で、Hosted agentsはプレビュー中の機能です。リージョン一覧は今後も更新される前提であり、公式ドキュメントの記載、実際のAzureポータルやCLIでの作成可否、モデルSKU、クォータ、RBAC、ネットワーク要件をセットで確認する必要があります。
次に取るべき行動は明確です。まず、自社の現在のHosted agents構成や検証計画で使っているリージョンを洗い出してください。そのうえで、Japan Eastを含む新しい候補リージョンで最小構成をデプロイし、権限、ネットワーク、性能、コスト、監視の5点を確認します。リージョン更新を早めに取り込めば、Azure AIエージェントの本番化に向けた設計の自由度を高められます。
コメント