ClaudeをMicrosoft Foundryで使う — 直接APIとの違いとSDK認証

Microsoft Foundryは、Azureのサブスクリプションと請求の中でClaudeを呼び出せる提供経路です。モデルの中身は直接APIと同じですが、認証方式・課金単位・使える機能の範囲はFoundry側の枠組みに従います。

Foundry上のClaudeは、デプロイ作成時に「Hosted on Azure」か「Hosted on Anthropic」を選びます。この選択で使えるモデルと機能が変わります。Opus 5.5・Sonnet 5.5・Haiku 4.5などはどちらでも選べ、Fable 5.1は後者だけです。SDKはPython・TypeScript・C#・Go・Java・PHPが対応し、cURLやREST APIからも呼べます。

最初に決めるのはホスティング、次にリソースとデプロイの作成、最後に認証とエラーの切り分けです。この順に進めます。

Foundry経由でClaudeを使う理由

企業がFoundry経由を選ぶ主な理由は3つあります。

• Azureの請求に統合できる。ClaudeはMicrosoft Azure Consumption Commitment(MACC)の対象になり、既存のAzure契約の中で使えます
• Azureのガバナンス機構(Entra ID・RBAC・Virtual Network)をそのまま適用できる
• Azure MonitorやLog Analyticsで利用状況を追跡できる

Claude Codeを使っている場合は本記事の対象外です。Claude CodeをFoundry経由で動かす環境変数の設定はClaude Code Microsoft Foundry設定ガイドにあります。ここで扱うのは、SDKやREST APIからClaudeを呼び出してアプリケーションを作る開発者向けの手順です。

Hosted on AzureとHosted on Anthropicはどう選ぶか

ホスティングはデプロイ作成時に選び、モデルバージョンの欄では別バージョンとして並びます。Hosted on Azureがversion 2、Hosted on Anthropicがversion 1です。

モデルごとの対応は次のとおりです。デプロイ名の既定値はモデルIDと一致します。

Sonnet 4.5は非推奨のモデルとして表に載っています。Sonnet 5.5は両ホスティングを選べますが、デプロイタイプはGlobal Standardだけです。Mythos Previewは招待制のリサーチプレビューで、表には含まれません。

Fable・Mythos・Opus 4.7以前が必要なら、選べるのはAnthropic側だけです。それ以外でプロンプトをAzure内に留めたいなら、Azure側が出発点になります。

後から切り替えるときは、もう一方のバージョンで新しいデプロイを作ります。同じFoundryリソース内なら、エンドポイントURLと認証はそのままです。アプリのmodelパラメータを新しいデプロイ名に差し替え、トラフィックが移ったら古いデプロイを消します。別リソースに作った場合は、エンドポイントと認証情報も差し替えます。

使えない機能はどこで線が引かれているか

使えない機能は2層あります。

Hosted on Azureのデプロイにこれらの機能を使うリクエストを送ると、400 Bad Requestが返ります。仕様どおりの挙動です。Claude CodeはAzureホストのデプロイを検知して機能セットを調整しますが、自前のSDK実装では分岐を自分で書きます。

サーバーサイドフォールバックが使えないので、モデルが応答できなかったときの代替はクライアント側のフォールバックとして実装します。

コンテキストウィンドウは、Fable 5.1・Fable 5・Opus 5.5・Opus 5・Opus 4.8・Opus 4.7・Opus 4.6・Sonnet 5.5・Sonnet 5・Sonnet 4.6が1Mトークンです。Sonnet 4.5を含む他のモデルは200kトークンになります。Bedrock経由の制約はAmazon BedrockでClaudeを使う、Claude Code側の対応状況はBedrock/Vertex/FoundryでClaude Codeが使えない機能一覧にまとめています。

リソースを作ってモデルをデプロイする

Foundryは2階層です。リソースがセキュリティと課金の設定単位で、その中のデプロイが、APIから呼ぶモデルのインスタンスになります。1つのリソースに複数のデプロイを置き、レート制限やバージョンを別々に管理できます。

前提は、有効なAzureサブスクリプションと、Foundryポータル(ai.azure.com)へのアクセスです。デプロイするには、リソースグループのContributorまたはOwnerロールが要ります。初回はAzure Marketplaceへの加入も発生するので、その権限も必要です。

「New Foundry」トグルがオフの旧ポータルでは、左ペインの「Model catalog」でモデルを探し、「My assets」の下の「Models + endpoints」でデプロイを確認します。

デプロイ名は、そのままAPIリクエストのmodelパラメータに渡す値です。同じモデルを別名で複数デプロイすれば、用途ごとにレート制限を分けられます。Bicepで同じ構成を自動化したい場合は、Microsoftが「Claude on Foundry starter kit」に基づくBicepとTerraformの手順を公開しています。

SDKをインストールして認証する

SDKごとのパッケージは次のとおりです。Foundry対応は専用のパッケージかクライアントクラスで提供されます。

Rubyだけは、Foundryをネイティブに扱えません。標準のSDKにbase_urlとapi_keyを明示的に渡す形になり、Foundryが対応しない機能はクライアントではなくサーバー側でエラーになります。認証情報を省くとANTHROPIC_API_KEYなどの環境変数に頼る動きになり、Claude API用のキーをFoundryのエンドポイントに送りかねないので、必ず明示します。

APIキー認証は、Foundryポータルの「Details」タブで取ったキーを使います。api-keyかx-api-keyのヘッダーで渡せ、SDKに直接渡すこともできます。

import os
from anthropic import AnthropicFoundry
 
client = AnthropicFoundry(
    api_key=os.environ.get("ANTHROPIC_FOUNDRY_API_KEY"),
    resource="example-resource",
)
 
message = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello!"}],
)
print(message.content)

Entra ID認証にすると、APIキーを持たずにAzure RBACでアクセスを管理できます。トークンのスコープはhttps://ai.azure.com/.defaultです。

from anthropic import AnthropicFoundry
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
 
token_provider = get_bearer_token_provider(
    DefaultAzureCredential(), "https://ai.azure.com/.default"
)
 
client = AnthropicFoundry(
    resource="example-resource",
    azure_ad_token_provider=token_provider,
)

DefaultAzureCredentialは、サービスプリンシパルを使う場合にAZURE_CLIENT_ID・AZURE_TENANT_ID・AZURE_CLIENT_SECRETの環境変数を読みます。Microsoftのサンプルでは、この3つを先にexportしてから実行します。

エンドポイントと環境変数の対応

APIキーでもEntra IDでも、エンドポイントはhttps://{resource}.services.ai.azure.com/anthropic/v1/*の形です。{resource}はリソース作成時に控えた名前で、Foundryポータルの「Details」タブには「Target URI」としても表示されます。

APIキー認証のSDKは、次の3つの環境変数を自動で読みます。

resourceとbase_urlは同時に指定できません。リソース名だけ渡せばSDKがhttps://{resource}.services.ai.azure.com/anthropic/を作り、完全なURLを直接渡したいときはbase_urlを使います。C# SDKはANTHROPIC_FOUNDRY_BASE_URLを読まず、常にリソース名からURLを作ります。

Entra IDトークンをcURLで使うときは、Azure CLIで取ったトークンをAuthorization: Bearerで渡します。APIキーのヘッダーは、AnthropicのcURL例がapi-key、MicrosoftのcURL例がx-api-keyです。Anthropicのドキュメントは、どちらのヘッダーも使えると書いています。

ACCESS_TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)
 
curl https://{resource}.services.ai.azure.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

Anthropicのドキュメントには、antコマンドで試す例もあります。antはANTHROPIC_API_KEYをx-api-keyとして送るので、Azureのキーをその変数に入れてベースURLを指定します。ANTHROPIC_API_KEYが設定されていると--auth-tokenより優先されるため、Entra IDで呼ぶ場合はcURLかSDKを使います。

export ANTHROPIC_API_KEY="YOUR_AZURE_API_KEY"
ant messages create \
  --base-url https://example-resource.services.ai.azure.com/anthropic \
  --model claude-opus-5-5 \
  --max-tokens 1024 \
  --message '{role: user, content: "Hello!"}' \
  --transform content

Mythos系はEntra ID認証だけに対応します。Microsoftのページでは、SDKの節がMythos 5.1・Mythos 5・Mythos Previewを挙げ、cURLの節はMythos 5とMythos Previewだけを挙げています。

課金の仕組み

Foundry経由のClaude利用はAzure Marketplaceで課金されます。単位はClaude Consumption Units(CCU)で、時間ごとに計測し、月末にまとめてAzureの請求に載ります。CCUは前払いクレジットではなく、残高やコミットメントの概念はありません。

直接APIやサブスクとの費用感はClaude APIとサブスクの料金比較、料金プラン全体はClaude料金プラン完全ガイドが詳しいです。

つまずいたときの切り分け

エラーはステータスごとに原因が違います。

エラーの問い合わせでは、レスポンスヘッダーのrequest-idとapim-request-id(Azure API Managementの識別子)の両方を伝えると、AnthropicとAzureの双方で追跡しやすくなります。ログは少なくとも30日のローリングで残すことをAnthropicは勧めています。

サブスクリプションの種類にも制約があります。韓国のEnterprise Accounts・Cloud Solution Provider契約・従量課金の支払い方法がないサブスクリプション(学生・無料トライアル・スタートアップクレジット型)・Azureクレジットのみのスポンサー契約は非対応です。クレジットカード登録済みのアカウントでは、Azureクレジットでなくカードに課金されます。サブスクリプションの種別が合っていても、モデルの既定クォータが0の階層だと、サブスクリプション適格性のエラーになります。

ヘルプセンターの記事だけモデル名が古い

Claude Help Centerの「Use Claude in Microsoft Foundry」は、Haiku 4.5・Sonnet 4.5・Opus 4.1がパブリックプレビューで使えると説明しています。一方、Anthropicの開発者ドキュメントのモデル表は、Fable 5.1やOpus 5.5を含み、Sonnet 4.5を非推奨としています。

対応モデルを知りたいときは、開発者ドキュメントの「API model IDs and deployments」を基準にします。Microsoft Learnのコードサンプルは、Sonnet 4.6のデプロイ名で書かれています。コピーする場合は、自分のデプロイ名に置き換えます。

まとめ

Foundry経由のClaudeは、モデルは同じでも、認証・課金・機能の可用性がAzureの枠組みに従う別の経路です。必要な機能(code execution・Agent Skills・Fableなど)が決まっていればホスティングは自然に決まるので、機能の有無から先に決め、サブスクリプションの種別とSDKの対応を確かめてからリソースを作ります。