Claudeモデルは2026年6月にMicrosoft Foundryで一般提供(GA)となりました。このとき、Azure上でのホスト型アクセスとして、最先端のClaudeモデル、Azureネイティブのエンドポイント、Entra ID認証、Azure Marketplace課金が提供され、調達とガバナンスの問題が解決しました。チームは、他のAzure資産と同じサブスクリプション、ネットワーク境界、コスト管理の画面の中でClaudeを実行できるようになりました。推論は、Hosted on AzureではAzureインフラ上のAnthropic運営サービスが、Hosted on AnthropicではAnthropicインフラ上のAnthropic運営サービスが、それぞれ実行します。

GA後の数週間で、Hosted on Azureのオプションには機能が追加されました。Foundryの顧客に見られるパターンとして、Claudeを使った強力な機能を出荷したチームが、次の四半期を同じ4つの足場(scaffolding)の作り直しに費やすというものがあります。今回のリリースは、これら4つの足場をプラットフォームに移し、さらにAzure上でホストされるデプロイメントに移します。これにより、エージェント機能を取るか、プロンプトと応答(completions)をAzure内に保つかを選ぶ必要がなくなります。この投稿では、各機能の内容、Foundry上のAPIの形、現実的なエンタープライズのユースケース、本番で問題になる制約を解説し、コード例はAnthropic Foundry SDKを使ったPythonとTypeScriptで示しています。Microsoft Foundry上のClaudeモデルには、デプロイメント作成時に選ぶ2つのホスティングオプションがあります。

プラットフォームが足場を担うようになったため、開発者に残る構築対象は自社の事業そのものにあたる部分です。これまでは、モデルが末尾にカンマの付いたJSONを返したために再度プロンプトを送るリトライループが必要になる例がありました。独自のクローラー、キャッシュ、robots.txtの処理、および引用の仕組みを備えた検索とスクレイピングの専用サービスを自前で構築する例もありました。さらに、モデルがJira、ServiceNow、Confluence、および3つの社内APIに到達するために手作りのMCPクライアントを用意する例も存在しました。これら4つの足場はいずれも差別化につながらないエンジニアリング(undifferentiated engineering)であり、どれも自社の製品そのものではありません。チームが作り直す4つの足場の4つ目はツールルーターです。300個のツールを接続すると、モデルが誤ったツールを選び始めるためです。

Azure上で使える5つのエージェント機能

Structured outputs(構造化出力)、Web検索、Web fetch、MCP connector、およびツール検索の5つのエージェント機能は、従来はHosted on Anthropicでのデプロイメントでのみ利用可能でした。

そのため、プロンプトと応答をAzure内に留めるというデータ取り扱い上の約束を持つチームは、その約束を諦めるか、検索・フェッチ・MCP・ツールルーティングをクライアント側で作り直すかのどちらかを迫られていました。しかし現在は、Structured outputs、Web search、Web fetch、MCP connector、およびTool searchがAzure上でホストされるデプロイでも利用可能となり、この問題は解決されています。

このトレードオフが解消されたことで、規制産業にとっての実務上の影響は大きいものです。

ホスティングオプションとデータの扱い

Hosted on Azureで利用できるモデルは、最新のOpus、Sonnet、Haikuモデルです。Hosted on Anthropicでは、Foundry上のClaudeカタログ全体が利用できます。デプロイメントタイプについては、Hosted on AzureではGlobal StandardとUS Data Zone Standardがあり、Hosted on AnthropicではGlobal Standardがあります。推奨される用途として、Hosted on Azureはほとんどのワークロードに適しており、Hosted on AnthropicはまだAzureでホストされていないモデルを使いたい場合に適しています。

元記事の表
Hosted on AzureHosted on Anthropic
推論の実行場所Anthropic-operated service on Azure infrastructureAnthropic-operated service on Anthropic infrastructure
モデルの利用可否Latest Opus, Sonnet, and Haiku modelsThe full Claude catalogue on Foundry
デプロイメントタイプGlobal Standard, US Data Zone StandardGlobal Standard
The five features in this post✓✓
推奨される用途Most workloadsAccess to models not yet hosted on Azure

元記事の表を転載しています(見出しは日本語にしています。値は原文のままです)。出典: 元記事

Hosted on Azureのデプロイメントでは、プロンプトと応答はAzure内に留まります。Anthropicに送出されるのは、使用状況のメタデータと、Anthropicの安全システムによってフラグが立てられたコンテンツだけです。AnthropicはMicrosoftに対して独立した処理者(independent processor)として動作し、FoundryでClaudeを使う顧客には、Anthropicのデータ利用条件が適用されます。

US Data Zone Standardのデプロイメントは推論を米国内に留め、これはClaude APIで `inference_geo: "us"` を設定するのと同等です。このデプロイメントでは、Web検索を使うリサーチエージェントの実行、社内MCPサーバーへの接続、文法制約付きJSONの返却ができるようになりました。12か月前は、この組み合わせには機能とデータ所在地(residency)の方針のどちらかを選ぶ必要がありました。

構造化出力とWeb検索・fetchの使い方

リトライ付きのパース処理はたいていの場合は動作しますが、一晩で40万件のドキュメントを処理するバッチジョブでは「たいていの場合」では不十分です。失敗率が0.3%であっても1,200行がデッドレターキュー(dead-letter queue)に入り、月曜日に誰かが仕分けを行う必要があります。

構造化出力(structured output)は生成そのものを制約します。モデルのデコードは、JSON Schemaからコンパイルされた文法によって制限されるため、出力が不正な形式になることはありません。Structured outputsには2つの補完的な機能があり、これらは単独でも併用でも利用できます。JSON outputs(`output_config.format`)はClaudeの応答テキストの形(shape)を制御する機能であり、Claudeが何を言うかを制御します。 Strict tool use(ツールに `strict: true` を指定する)はスキーマに適合したツール入力を保証する機能であり、Claudeがどのように関数(ツール)を呼び出すかを制御します。

商業向け保険会社における請求受付(claims intake)のユースケースでは、事故の初回通知(first-notice-of-loss)を、自由記述のメール、ブローカーのPDF、および損害査定人の音声メモの文字起こしとして受け取ります。この保険会社の下流システムは、厳密なスキーマを持つAzure SQLテーブルと、重大度に応じてルーティングするLogic Appsワークフローです。同社では従来、抽出を正規表現とヒューリスティクスのパイプラインで行っており、カバーできる形式は約60%で、残りは手作業のキューに回していました。構造化出力を使うと、抽出の契約はスキーマそのものになります。保険の請求受付の例では、ClaimIntakeというPydanticモデルが`policy_number`、`claimant_name`、`loss_date`(ISO 8601)、`loss_type`、`estimated_severity_usd`、`third_party_involved`、`injuries_reported`、`summary`、`escalate_to_adjuster`を定義します。ClaimIntakeスキーマのloss_typeは、"property_damage"、"bodily_injury"、"business_interruption"、"auto_liability"、"other"のいずれかのLiteralに限定されます。

Web Searchでは、リクエストにツールを1つ追加すると、Claudeがいつ検索するかを判断し、上限の範囲内で必要なだけ検索を実行し、参照した特定の箇所に引用を付けた回答を返します。クローラーの運用、インデックスの管理、再ランカーの実装は不要です。基本検索にあたるバージョンは`web_search_20250305`です。この基本検索では、定型文やナビゲーション部分、質問と無関係な4段落も含め、すべての検索結果がコンテキストウィンドウ(context window)に全文で読み込まれます。調査量の多いリクエストでは、1ターンあたり数万の入力トークンが無駄になります。

`web_search_20260209` 以降のバージョンでは、Claudeは検索結果がコンテキストに到達する前に、関連する内容だけを残すようにフィルタリングするコードを書いて実行します。このバージョンでは、検索はcode executionツールの内部から実行されます。`allowed_callers` の既定値は `["code_execution_20260120"]` になります。リクエストに必要なコード実行は Foundry が自動でプロビジョニングします。動的フィルタリングを使わずに直接呼び出しを強制するには、`allowed_callers: ["direct"]` を設定します。プログラムによるツール呼び出し(programmatic tool calling)をサポートしないモデルではこの設定が必須で、設定しないとその旨を伝える400エラーが返ります。Web Searchツールの `allowed_domains` と `blocked_domains` は同時に指定できず、両方を送ると400エラーになります。エントリはスキームを含まないドメインで、パスは任意に付けられます。コード実行をtools配列に追加する必要はなく、これらの呼び出しに標準のトークン料金以外の追加料金はかかりません。

ティア1(Tier 1)銀行の規制対応チームは、十数もの法域にわたる規則変更を追跡しています。従来のプロセスはRSSフィードと共有受信箱を使うアナリストチームによるもので、公表から社内影響メモまでの所要時間の中央値は6日でした。規制変更モニタリングの再構築では、毎晩実行されるAzure Container Appsのジョブを使用します。設計上の重要な選択はプロンプトではなく `allowed_domains` であり、二次情報源が規則を誤って言い換えるリスクを許容できない場面だからです。この例のシステムプロンプトでは、グローバル銀行向けに健全性規制と行為規制を監視する役割をClaudeに与えます。直近7日間に公表された変更のみを報告させ、各変更について規制当局、対象文書、発効日、影響を受ける事業ラインを述べさせ、原文を超えた推測をしないよう指示しています。

Web検索が情報を見つけるのに対し、web fetchは読む役割を持ちます。URLを渡すとページ全文のテキストを返し、PDFの場合はbase64のドキュメントコンテンツを返しますが、これは直接添付したPDFとまったく同じように処理されます。基本的なfetchである`web_fetch_20250910`というツールバージョンがあります。ユースケースの例として、医療システムでのサードパーティリスク評価が挙げられます。病院ネットワークは四半期に約40のSaaSベンダーをオンボードし、ベンダーごとにセキュリティレビューが発生します。レビューでは、ベンダーのトラストセンター、サブプロセッサー一覧、直近のSOC 2スコープ概要、DPA、ステータスページの履歴を読みます。医療システム向けのシステムプロンプトの例では、モデルをHIPAAの対象となる医療システムの第3者リスクアナリストとして振る舞わせ、各ベンダーを評価させます。評価項目はデータ所在地、サブプロセッサーの開示、breach notification SLA、保存時と通信時の暗号化、BAAの提供状況、SOC 2スコープのカバー範囲で、すべての所見に出典を挙げさせ、ドキュメントで扱われていない統制は推測せず明示的にその旨を述べさせます。web fetchではWeb検索と異なり、citationsがデフォルトでオフであるため、リスク評価のような用途では`citations: { enabled: true }`でオンにすることが勧められています。また、`allowed_domains`はモデルがマーケティングブログなど別のサイトへ逸れていくのを防ぎます。web fetchの`max_content_tokens`は、サイズの大きすぎるテキストコンテンツがコンテキストに入る前に切り詰めます。web fetchのトークン消費の目安は、平均的な10 kBのWebページで約2,500トークン、100 kBのドキュメントページで約25,000トークン、500 kBの論文PDFで約125,000トークンです。そうしたサイズのドキュメントを4件読み込むと、1ターンでコンテキストウィンドウのかなりの割合を消費します。

このリリースにおいて最も効果が大きいパターンは、web_search と web_fetch の両ツールを一緒に有効にすることです。ユーザーがURLを示さずに特定の文書を名指しした場合（例として、anthropics/anthropic-sdk-python リポジトリの README を読むことや、ベンダーの最新の DPA を開くことが挙げられます）、Claudeはまず search で文書を探し、次に fetch で全文を読みます。web_search と web_fetch を併用すると、Claudeは検索を行い、有望な結果を選び、それらを全文取得して、引用つきで分析します。search は幅広さを安価に与え、fetch は重要な少数の情報源について深さを与えます。

MCP connectorとツール検索の使い方

Model Context Protocol(MCP)は、企業のシステムをモデルに公開するための事実上の標準(de facto standard)になっています。MCP connectorを使うと、Messages APIをリモートのMCPサーバーに直接向けられます。MCPクライアントの実装、セッション管理、ツールスキーマ変換層は不要で、接続とツール呼び出しはサービスが代行します。MCP connectorのAPIは2つの部分から成ります。`mcp_servers` が接続を定義し、*tools* 内の `mcp_toolset` エントリが、そのサーバーのどのツールをどのように有効にするかを定義します。MCP connectorはFoundryでベータであり、Claude APIでもベータであるため、呼び出しには `client.beta.messages.create` と `betas` ヘッダーを使います。

MCP connectorの呼び出し例では、`client.beta.messages.create` を model が `claude-opus-5`、`max_tokens` が 4096 で呼び出し、`messages` に role が user で content が "What's blocking the payments release?" のメッセージを渡します。`mcp_servers` には type が url、url が `https://mcp.contoso.com/jira/sse`、name が `jira`、`authorization_token` が `jira_oauth_token` のサーバーを指定し、`tools` には type が `mcp_toolset` で `mcp_server_name` が `jira` のエントリ、`betas` には `mcp-client-2025-11-20` を指定します。

ある製造業のITサービスデスクは月に12,000件のチケットを処理しており、そのおよそ40%は、ディレクトリでユーザーを調べる、デバイスのコンプライアンス状態を確認する、ナレッジベースを検索する、既知の修正を適用するか文脈を添えてエスカレーションするという決まった手順で解決できます。この製造業のチームは、ServiceNow、Intune、Confluenceナレッジベース向けのMCPサーバーをすでに運用しており、これらは社内のClaude Code導入のために構築したものです。MCP connectorを使うと、新たな連携作業なしに、同じMCPサーバーを顧客向けエージェントの基盤にできます。ITサポートエージェントのシステムプロンプトは、読み取り専用ツールで先に診断すること、何をするか明示せずに変更を行わないことを指示しています。ITサポートエージェントの例では、Intuneの `mcp_toolset` で `default_config` を {"enabled": False} にしたうえで、get_device_compliance と list_user_devices だけを有効にする、読み取り専用の厳格なallowlistにしています。ナレッジベース(kb)は大規模で一度にすべてが必要になることはまれなので、`mcp_toolset` の `default_config` を {"defer_loading": True} にしています。MCPツールのガバナンスには、企業が実際にエージェントを統制する方法に直接対応する3つのパターン(Denylist、Allowlist、Deferred)があります。

Denylistパターンは、すべてのツールを有効にしたうえで破壊的な操作を無効にする方式であり、サーバーが信頼でき、幅広い機能が役立つ場合の良いデフォルトです。Allowlistパターンは、`default_config: {enabled: false}` にしたうえで名前を指定したツールだけを有効にする方式で、ID、エンドポイント、金銭に関わるものに適した姿勢であり、本当に読み取り専用(read-only)のエージェントを作る際に用いられます。Deferredパターンは `default_config: {defer_loading: true}` を指定する方式で、サーバーのツールをコンテキストウィンドウに読み込まず、ツール検索に渡します。MCPツールセットの設定は優先順位つきでマージされ、ツールごとの *configs* が、セット単位の `default_config` より優先され、`default_config` はシステムのデフォルトより優先されます。

MCPサーバーを使う場合、個々のツール定義に `defer_loading` を設定しません。`defer_loading` はツールセット(toolset)に対して1回だけ設定します。フィールドサービスエージェントの例では、parts サーバーの `mcp_toolset` のうち `search_parts` だけを `configs` で `defer_loading: False` に上書きします。`search_parts` はシステム内で最もよく使われる単一のツールなので、parts サーバーの残りのツールを遅延(defer)させても、`search_parts` は常に読み込まれた状態に保たれます。推奨パターンは、使用頻度が最も高い3〜5個のツールを読み込んだままにし、残りのロングテールを遅延させることです。システムプロンプトでモデルにどんな「カテゴリ」のツールがあるかを伝えると、検索の質が目に見えて向上します。これは、モデルは探すべきだと知らない機能を検索できないためです。Claudeのレスポンスに含まれる `server_tool_use` ブロックの例では、`id` が `srvtoolu_01ABC123` であり、`name` は `tool_search_tool_bm25` です。このブロックの `input` は、`query` が "warranty coverage lookup by serial number" で、`limit` が 10 です。

エージェントが8個のツールでは問題なく動いているチームにとって、直感に反する2つの失敗モードが、同じしきい値(ツール数の増加)で現れます。一つはコンテキストの肥大化(context bloat)であり、GitHub、Slack、Sentry、Grafana、Splunkという控えめなマルチサーバー構成でも、モデルが作業を始める前にツール定義だけでおよそ55,000トークンを消費します。この約55,000トークンは、料金を払っているのに使えないコンテキストであり、毎ターン発生します。もう一つは選択精度の崩壊(selection accuracy collapse)であり、利用可能なツールがおよそ30〜50個を超えるとClaudeが正しいツールを選ぶ能力が低下し、その低下は緩やかではありません。ツール検索は、すべてのツール定義を最初からコンテキストに入れる代わりに、Claudeがカタログを検索して必要なものだけを読み込みます。ツール検索は、ツール定義の読み込みモデルを反転させます。通常は1リクエストあたり3〜5個のツールを読み込むため、定義のトークンが85%以上削減されます。作業セットが小さいまま保たれることで、数千個のツールがあってもツール選択の精度は高く保たれます。エージェントは`search_pull_requests`を呼びたいときに`search_issues`を呼ぶようになり、evalsにはプロンプトの問題のように見えて実はそうではないノイズが入るようになります。

ツール検索には2つのバリアントがあります。`tool_search_tool_regex_20251119` では、ClaudeがPythonの `re.search()` パターン(最大200文字、大文字小文字を区別しない)を書きます。もう一つの`tool_search_tool_bm25_20251119`では、Claudeが自然言語のクエリ(最大500文字)を書きます。どちらのバリアントも、ツール名、説明、引数名、引数の説明を検索対象にします。`defer_loading` が制御するのはコンテキストウィンドウに入る内容であり、送信する内容ではありません。ツール定義はすべて、APIがサーバー側で検索を実行し `tool_reference` ブロックを展開するために必要であるため、毎リクエストtools配列で送信し続ける必要があります。ツールのうち少なくとも1つは非deferredのままにする必要があり、通常それは検索ツール自体です。検索ツールに `defer_loading: true` を設定してはなりません。すべてのツールをdeferすると400が返り、メッセージは `At least one tool must have defer_loading=false.` となります。

産業機器メーカーが、3,000人の技術者向けにフィールドサービスエージェントを運用しています。このエージェントは9つのMCPサーバーにまたがり、ツールは合計600以上あります。すべてを最初から読み込むと、ツール定義だけで200kのコンテキストウィンドウの大半を消費し、エージェントのツール選択は信頼できず、パイロットは頓挫しかけました。MCPツール呼び出しは `mcp_tool_use` ブロックと `mcp_tool_result` ブロックとしてレスポンスに現れ、`server_name` がどのMCPサーバーのツールかを示します。この`server_name`は、サーバーごとの監査ログに役立ちます。ツール検索のレスポンスに含まれる `tool_reference` ブロックは、Claudeが見る前にAPIが完全な定義に展開します。開発者が自分で展開する必要はありません。また、`srvtoolu_...` のIDに対して `tool_result` を返してはいけません。返すとAPIに拒否されます。最後に、ツール検索を使う場合は、次のターンでアシスタントのcontentを変更せずに、同じ完全な *tools* 配列とともに返すことで、Claudeは再検索せずに発見済みのツールを再利用できます。

本番運用前の確認事項と機能の選び方

Foundryで本番運用する前のデプロイの選択について、Azureは用途に応じた使い分けを勧めています。ワークロードがプロンプトと応答をAzure内に留める必要があるならHosted on Azureを、推論を米国内に留めるならUS Data Zone Standardを、まだAzureでホストされていないモデルが必要ならHosted on Anthropicを選ぶよう勧めています。

コスト管理として、Web検索とWeb fetchには `max_uses` を使う。Web fetchには `max_content_tokens` を使い、大きなツールセットには `defer_loading` を使います。

データ取り扱いについて、構造化出力はZDRで処理されますが、スキーマは24時間キャッシュされるため、スキーマにPHIを含めてはなりません。MCP connectorとMCPサーバーとの間のデータのやり取りはZDRの対象外です。Azureは、この両方をレビューするよう勧めています。

セキュリティ面では、Web fetchの `allowed_domains` をプロンプトインジェクション(prompt injection)に対するセキュリティ制御として扱うようAzureは勧めています。ID、エンドポイント、資金に関わるものには、Allowlist方式の `mcp_toolset` 設定を使うよう勧めています。未知のツール名はエラーではなく警告になるため、DenylistはCIで検証するようAzureは勧めています。

耐障害性のため、検索では `pause_turn` を処理し、`encrypted_content` はバイト単位でそのまま返します。構造化出力をパースする前には `stop_reason` を確認してください。FoundryはAnthropicのレート制限ヘッダーを返さないため、指数バックオフ(exponential backoff)を実装することが勧められています。

可観測性のため、`request-id` と *apim-request-id* をログに記録してください。これらをAzure MonitorとLog Analyticsにルーティングし、Anthropicは少なくとも30日のローリング保持を推奨しています。また、ツール検索が発見するツールを追跡し、説明文を改善していくことが勧められています。なお、Foundryでは、Message Batches API、Admin API、Models API、Compliance API、Claude Managed Agents、server-side fallback、およびAdvisor toolは利用できないため、それを前提に計画する必要があります。

今週、いずれか1つの機能を試すのであれば、すでに抱えている課題に合致するものを選ぶとよいです。リトライループとデッドレターキューを持つデータパイプラインには、構造化出力が向いています。スキーマと1つのパラメータだけの最小の変更で、すぐに信頼性が上がります。

アナリストが元の文書を手作業で読んでいる場合は、ドメインを制限し、citationsをオンにしたWeb検索とWeb fetchを組み合わせて使うことが推奨されます。社内のClaude Code展開向けにMCPサーバーがすでに動いている場合は、MCP connectorが向いています。統合作業は完了しており、新しい利用側をそのサーバーに向けるだけです。

デモでは動くが本番で混乱するエージェントの場合は、ツール数を数えてください。30を超えるなら、必要なのはプロンプトの修正ではなくツール検索の導入です。