Microsoft Foundry で Claude を使う｜Azure で最上位モデルを動かす実践ポイント

AnthropicのClaudeが Microsoft Foundry（旧 Azure AI Foundry）で正式提供されました。

Azureの認証・課金・ガバナンスを保ったまま、最上位のAIモデルを組み込めるようになった——ただし、実際に動かすと公式ドキュメントだけでは越えにくい「つまずき所」がいくつもあります。

本記事は「Foundryで Claude を動かす」ときに実際につまずく所を、デプロイから呼び出しまで先回りで潰すための実務ノートです。弊社が自社の帳票読み取りで Claude を採用し、精度を上げた検証も併せてお伝えします。

株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。本記事では、Foundry での Claude 利用について、Microsoftの公式情報で裏付けを取りつつ、弊社が実装検証で実際に踏んだ落とし穴とその回避策を、実務目線で解説します。

なぜ Microsoft Foundry で Claude なのか

Microsoft Foundry（旧 Azure AI Foundry）は、Azure上でさまざまなAIモデルを扱うための基盤です。ここに Anthropic の Claude が加わり、2026年6月29日に正式提供（GA）されました。ポイントは、推論はAnthropicが運用しつつ、Azureの認証・課金・ガバナンスのワークフローにそのまま乗せられることです。ホスティングは2形態が用意されています。

ホスティング	どこで推論が動くか	位置づけ
Hosted on Azure	Azureのインフラ上で動く。プロンプトと生成結果はAzure内に留まり、Anthropicへ出るのは使用メタデータと安全性システムが検知した内容のみ	多くの用途の既定。最新のOpus・Sonnet・Haikuが対象
Hosted on Anthropic	Anthropicのインフラ上で動く	Azure側に未提供の機能・モデルを使いたいとき

「AzureでフロンティアAIが使える」こと自体は新しくありません。新しいのは選択肢が広がったことです。同じAzureのガバナンスの中で、OpenAI系（GPT）と Claude を用途ごとに選べる——訴求は「使えるか」から「選べるか」へ移りました。ここから先は、その Claude を実際にデプロイして呼び出すまでの、つまずき所に絞ってお伝えします。

最初の関門｜提供リージョンとデータの所在

最初に確認すべきは、Foundry上の Claude は提供リージョンが限られていて、日本リージョンには未提供（執筆時点）だという点です。デプロイ先はおおむね次のとおりで、いずれも国外です。

デプロイ形態	対象リージョン・特性（執筆時点）
Global Standard	全モデルが対象。米国系リージョン＋ Sweden Central など。推論の地理はグローバル
Data Zone Standard（US）	Azure上でホストされる一部モデルが対象。推論を米国内に限定する
リージョン例	East US 2・Sweden Central が全ファミリ（Haiku・Sonnet・Opus）を、West US 2 が Sonnet・Opus を提供。Japan East / West は対象外

つまり Claude を使うと、日本のデータを国外のリージョンで処理することになります。検証段階では割り切れても、本番でお客様のデータを扱うなら、データの所在（データレジデンシー）をどう説明し、どう統制するかの設計が欠かせません。国内での処理完結が要件なら、日本リージョンで提供されるGPT系モデルと役割で使い分ける、あるいはデータ所在の要件が許すお客様に絞る、といった整理が現実的です。この論点は「お客様専用のAI基盤とデータ主権」で詳しく扱っています。

デプロイでつまずく所｜属性ブロック・サブドメイン・クォータ

リージョンを決めても、デプロイの段階で手が止まりがちな点が3つあります。いずれも一度知っていれば数分で越えられますが、知らないと原因がつかみにくいものです。

① 事業者の属性ブロックが必須

Anthropic系モデルのデプロイでは、モデル提供者向けの属性情報（organizationName＝法人名／countryCode＝2文字の国コード／industry＝業種）を渡す必要があります。industry は小文字指定で、technology や manufacturing などの決められた値から選びます。この属性ブロックは Azure Marketplace のオファー承諾に使われるため、法人名は既定値がなく、未設定だとデプロイが弾かれます。スターターキット（Bicep / Terraform）を使えば自動で付きますが、テンプレートを手組みすると見落としやすい所です。弊社の検証では、古いAPIバージョンだと属性ブロックが認識されず、比較的新しいプレビュー版のAPIバージョンで初めて受理されました（執筆時点の実測）。

② カスタムサブドメインが要る

トークン認証を使うエンドポイントは、リソース固有のカスタムサブドメインが前提です。これが未設定だと、正しいURLを組んだつもりでもホスト名が解決せず、接続できません。加えて、サブドメインを設定した直後は DNS の伝播にタイムラグがあり、いったん解決したのに再度引けなくなることもあります。設定後は数分待ってから疎通を確認するのが無難です。

③ クォータ（TPM）の上限

デプロイ容量は毎分トークン数（TPM・千単位）で指定します。上限を超える容量を要求すると弾かれ、逆に小さくしすぎると呼び出し時にレート制限（429）に当たります。上限を確認し、実際の負荷に合う容量へ調整してください。なお、リソースを削除しても、ソフト削除の状態が最大48時間クォータを保持することがあります。作り直しですぐ容量が足りなくなったら、削除済みリソースが枠を握っていないかを疑います。

呼び出しの作法｜ここが一番滑りやすい

デプロイが済んでも、最初の呼び出しでつまずく人が多い所です。原因のほとんどは「OpenAI系と同じ流儀で叩こうとする」ことにあります。

最初に滑る所は、エンドポイントの形式です。Claude は、OpenAI互換の統合エンドポイント（/models/chat/completions）では叩けません。Anthropicネイティブ形式で呼ぶ必要があります。ここを取り違えると、URLもキーも合っているのに応答が返らず、原因探しに時間を取られます。呼び出しに必要な要素を整理すると次のとおりです。

要素	作法（執筆時点）
エンドポイント	Anthropicネイティブ形式のパス /anthropic/v1/messages を使う（ベースURLは https://<リソース名>.services.ai.azure.com/anthropic）。OpenAI互換の統合エンドポイントは不可
認証	Entra ID（Bearerトークン・スコープ https://ai.azure.com/.default）が本命。APIキー（api-key または x-api-key ヘッダ）も使えるが、キー管理の要らない Entra ID が本番向き。スコープ違いや、キーを Authorization ヘッダに入れると401
ヘッダ	anthropic-version: 2023-06-01 を付ける。指示文（system）はメッセージ本文と別枠、画像は base64 で渡す
temperature	Anthropic側へそのまま渡るため、0 を指定すると400になる。付けないのが無難（拡張思考を使う場合も1以外は受け付けない）
権限（ロール）	呼び出し元（アプリのマネージドID等）に、最小権限の Cognitive Services User をFoundryリソースへID付与する。無いと403

もう一つの注意は、Azureでホストする形態では一部の機能が使えないことです。ファイルAPI、メッセージのバッチ処理、エージェント向けの一部ツールなどは、Azureホスト版だと非対応で、要求すると400が返ります。凝った機能を前提に組む前に、対応可否を確認しておくと手戻りを防げます。以上を、デプロイと呼び出しの「つまずき早見表」としてまとめました。

手書きOCRで Claude が効いた理由｜弊社の実装検証

ここまでの手順を越えて実際に動かすと、Claude の実力が見えてきます。弊社は、手書きの帳票を読み取る自社システムで、読み手のモデルを比較検証しました。難所は、紛らわしい手書き数字の字形です。丸みを帯びた「7」、筆記体の「8」、「7」と「2」の取り違えなど、人でも迷う字が正確さを左右します。

複数のモデルを同じ画像で突き合わせたところ、GPT系が一長一短だったのに対し、Claude の上位モデルがほぼ全問を正しく読み、最も安定していました（弊社の実装検証での結果です）。もう一つ実務で効いたのが、Claude が「自信がない」を自己申告できる点です。冷たいAPI呼び出しの一発では、Claude でもごく稀に曖昧な字を外します。しかし、行ごとに読み取り結果と一緒に確信度を返させると、迷った行だけを「自信なし」として拾えます。これを人の確認に回す設計にすれば、推測で押し切らず、本当に曖昧な字だけがピンポイントで人に届きます。

大切なのは、すべてを Claude に任せないことです。表の行・列や、氏名・金額・チェック欄といった構造の抽出は、座標を機械的に返す専用のOCR（Azure AI Document Intelligence）が確実で、行のズレも起こしにくい。一方、1マスの手書き数字という「構造は単純だが読み取りが難しい急所」は Claude に寄せる——この役割分担が、精度とコストの両方で効きました。専用OCRは番号が読めないときのフォールバックに回します。モデルを役割で使い分けるこの考え方は、「カスタムAI-OCRモデルの自動ルーティング」の延長線にあります。

まとめ｜つまずき所と、弊社の関わり

閉域のAzureガバナンスのままフロンティアのAIモデルを使う構成は、設計と運用の勘所を押さえれば、十分に実務へ乗せられます。弊社は、こうしたお客様専用のAI基盤の設計・実装を得意領域としています。「どのモデルを、どのリージョンで、どう組み込むか」をデータの所在要件から逆算し、無理のない形で導入まで伴走します。

よくあるご質問

こちらをクリックして「よくある質問」を表示

Foundryの Claude は日本リージョンで動きますか？

執筆時点では、Foundry上の Claude は日本リージョン（Japan East / West）へデプロイできません。East US 2・Sweden Central・West US 2 といった国外リージョンでの提供です。したがって、Claude を使うと推論は国外で行われます。国内での処理完結が要件になるお客様には、日本リージョンで提供されるGPT系モデルと役割で使い分ける、あるいはデータの所在要件が許す範囲で採用する、という整理をおすすめします。提供リージョンは変動するため、採用前に最新の提供状況をご確認ください。

OpenAI（GPT）向けに書いたコードを、そのまま Claude に使い回せますか？

そのままでは使えません。Foundry上の Claude は、OpenAI互換の統合エンドポイント（chat/completions）ではなく、Anthropicネイティブ形式のエンドポイント（/anthropic/v1/messages）で呼び出します。付けるヘッダ（anthropic-version）や、指示文を別枠で渡す・画像を base64 で渡すといったリクエストの組み立ても異なります。GPTと Claude を用途で切り替える構成にするなら、この呼び出しの違いをアプリ側で吸収する作りにしておくと運用が楽になります。

認証は APIキーと Entra ID のどちらを使うべきですか？

本番運用では Entra ID をおすすめします。キーの保管・更新を抱えずに済み、Azureのロールベースアクセス制御（RBAC）で誰が使えるかを管理できるためです。呼び出し元には最小権限の Cognitive Services User を付与します。APIキーも使えますが、手元での素早い疎通確認向けと考えるのが実務的です。なお一部のモデルは Entra ID 認証のみに対応します。Entra ID を使う場合は、トークンのスコープを ai.azure.com/.default に合わせることが、401を避ける勘所です。

Foundry での Claude 採用や、GPTと Claude をデータの所在要件に合わせて使い分ける構成のご相談は、お問い合わせよりお気軽にご連絡ください。現在お使いの Microsoft 365・Azure の環境に合わせて、どこから始めるべきかをご提案します。

関連サービス・関連コラム

• 関連コラム：お客様専用のAI基盤とデータ主権
• 関連コラム：カスタムAI-OCRモデルの自動ルーティング
• 関連コラム：Azure AI Vision とは（画像解析AIとの使い分け）
• 関連サービス：AI-OCRプライベート
• Azure導入支援
• Microsoft 365導入支援

まずは無料トライアルで、効果をご確認ください

「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）や電話受注（AI-Voice）の自動化、Azure/Microsoft 365・DXのご相談まで、お気軽にどうぞ。