Azure hosted ClaudeがMicrosoft Foundryで一般提供された。既存Azure accountからEntra ID、RBAC、network、governance、billingを利用し、Messages APIやFoundry Agent ServiceでClaudeを組み込める。inferenceはAzureで処理されるが、Anthropicがdata processorとSLA providerである。FoundryにはAnthropic hosted版もあり得るため、「FoundryでClaudeを選んだ」だけではhosting・data・契約境界は確定しない。

何が変わったか

MicrosoftはAzure hosted ClaudeをGAとし、Messages API、prompt caching、extended thinking、tool streamingを提供する。Foundry Agent ServiceでClaudeをreasoning coreとしてmulti-step agentへ利用できる。GlobalとUS data zoneを選択でき、Microsoft Entra ID、Azure RBAC、governance、management experienceを使える。高機密workload向けにzero data retentionも用意され、使用量はClaude Consumption UnitsとしてAzure billへ集約される。

変更前後の差

previewやAnthropic直接契約、Anthropic hosted catalog経路と比べ、Azure hosted GAはAzure procurement、MACC、identity、networkへ統合しやすい。一方API surfaceが似ていてもendpoint、authentication、model ID、quota、zone、billing unit、SLA、support、feature availabilityは異なる。既存Anthropic SDK設定の単純なURL置換では移行できない場合がある。

誰に影響するか

Azure-first企業でClaudeをcoding、document analysis、agent、researchへ使いたいteamが対象である。platform teamはcatalogとdeployment、securityはRBAC・network・data zone、legal・privacyはAnthropicのprocessor roleとZDR、FinOpsはCCU・MACC・per-model detailを確認する。unsupported subscriptionやcredit-only accountではdeployできない可能性がある。

対応期限

強制移行期限はない。既存Anthropicまたは別cloud経路を直ちに移す必要はなく、並行評価できる。GAであっても全model・全region・全subscriptionが同条件とは限らないため、deployment時点のcatalog、quota、data zone、subscription eligibilityを確認する。

必要な対応

Foundry model catalogでAzure hostedかAnthropic hostedかを識別し、deployment metadataとして保存する。Global・US data zoneと業務data residencyを照合する。Entra service principalとRBACをleast privilege化し、network path、logging、key management、ZDRの適用範囲を確認する。CCUとdirect provider価格をtask完了単価で比較する。

実装・移行手順

  1. subscription・region・model availability・hosting typeを確認する。
  2. staging deploymentを作りEntra ID・RBACとnetworkを設定する。
  3. Provider Adapterでendpoint、auth、model ID差を吸収する。
  4. caching、thinking、streaming、tool useを比較する。
  5. data zone、log、retention、ZDRをreviewする。
  6. shadow trafficから限定productionへ移行する。

失敗しやすい点

Azure hostedという表現をMicrosoftだけがdata processor・SLA providerと解釈するのは誤りで、公式発表はAnthropicの役割を明記している。Global data zoneを単一region保持と誤解すること、catalog上の別hosting typeを同じdeploymentとして扱うことも危険である。CCU単価だけ比較し、cache hit、retry、output length、support費用を無視しやすい。

リスク

誤ったdata zone、過剰RBAC、public network exposure、provider境界の契約誤認、ZDR未適用、quota不足がある。model updateやavailabilityがhosting typeで異なる場合、routingが意図せず別経路へfallbackするとdata policy違反になる。agent tool実行はmodel hostingとは別にtarget system権限とapprovalを必要とする。

評価方法

同一prompt・tool・datasetで既存providerとAzure hostedを比較し、task success、quality、latency、streaming、cache hit、tool error、CCU、total costを測る。security testではEntra token scope、RBAC denial、private network、log内容、ZDR、data zoneを確認する。failover時にhosting typeとzoneが維持されるかも検証する。

ロールバック

Provider Adapterとrouting flagで旧provider・旧deploymentへ戻せるようにする。conversation stateやtool stateはprovider外へ保存し再実行可能にする。Azure deployment削除前にtraffic、quota、log retention、billingを確認する。fallback先が異なるdata policyを持つ場合は自動fallbackせず停止する。

編集部の見解

GAの価値はClaudeの能力だけでなく、Azureのidentity・procurement・governanceへ統合できる点にある。ただし「Azure上」という一語でprocessor、SLA、retention、zoneを単純化してはいけない。hosting typeをdeploymentの必須属性にし、技術・契約・dataの三つを同時に検証すべきである。

実務チェックリスト

  • Azure hostedとAnthropic hostedを区別した
  • subscription eligibilityを確認した
  • Global・US data zoneを要件と照合した
  • Anthropicのprocessor・SLA roleを確認した
  • Entra IDとRBACを最小化した
  • ZDRの適用範囲を確認した
  • CCUをtask完了単価で比較した
  • 異なるdata policyへの自動fallbackを禁止した

一次情報