第3回直接APIかMicrosoft Foundryか — 機能差と運用統一の価値を比較する

2026/10/22

連載：LLMのAPIと提供経路を選ぶ・第3回 ｜連載のまとめ

Microsoft Foundryの対応機能と運用の統一効果

Microsoft Foundry（以下、Foundry）は、大規模言語モデル（以下、LLM）をAzureの運用に組み込む選択肢です。ただし、提供元のAPIと同じ機能をすべて利用できるわけではありません。モデル、API、ホスティング、デプロイ種別の組み合わせごとに、利用できる機能と条件を確認します。

提供経路を選ぶ際には、APIの互換性と運用の統一を別々に評価します。認証・監視・請求をAzureへまとめられることは、社内の運用部門にとって大きな価値になり得ます。一方、直接APIでは使えてもFoundryでは使えない機能があれば、アプリ側で補うための開発・運用費がかかります。運用を統一する価値が、その費用を上回るかが判断の中心です。

4つの経路を並べる

経路	API・運用の出発点	必ず確認する差
OpenAI直接API	OpenAIのAPIと管理機能	必要モデルの機能、保持設定、アカウントの制限
FoundryのAzure OpenAI	Azureのエンドポイントとデプロイ	モデル・地域別のAPI対応、容量、更新ポリシー
Anthropic直接API	Claude APIと提供元の機能	必要機能の提供状態、データ条件、利用制限
FoundryのClaude	Messages APIとFoundry用クライアント	ホスティング別の対応機能、CCU課金、監視

Azure OpenAIのResponses APIは、OpenAI公式のソフトウェア開発キット（以下、SDK）にAzureの接続先を設定して呼べます。ClaudeにはAnthropicFoundryなどの専用クライアントがあります。この連載で扱うデプロイ方式では、APIのmodelパラメーターにモデル名ではなくデプロイ名を渡します。[1][2]

同じSDKを使えても、同じ機能をすべて使えるとは限りません。提供元のAPI、SDK、管理型エージェント基盤、Foundry Agent Serviceでは、それぞれが提供する機能を分けて比較します。

FoundryのClaudeで選べる2つのホスティング先

2026年10月8日の公式文書では、FoundryのClaudeはHosted on AzureとHosted on Anthropicを選べます。前者もAnthropicが運営するサービスであり、Azure OpenAIと同じデータ条件だとは判断できません。

条件	判断への影響
Hosted on AzureとHosted on Anthropicで機能範囲が異なる	必須機能をホスティングごとに照合する
FoundryのClaudeではMessage Batches APIなどが非対応	大量処理の割引と実装方法を別途見積もる
Models APIやサーバー側fallbacksが非対応	機能情報と代替処理をアプリ側で管理する
Hosted on AzureではFiles API・コード実行などにも制約	ファイル保管・計算環境の補完費を加える
Sonnet 5.5はGlobal Standardのみ	US Data Zoneが必須なら同じ候補にできない

公式文書では、Hosted on Azureでも、使用メタデータや安全システムでフラグが付いた内容がAnthropicへ送られる場合があると説明しています。「すべてのデータがAzure内から出ない」という説明は正確ではありません。[2]

ここでいう非対応は、特定のAPIやツールのバージョンについての話です。たとえば、新しいcomputer/browser toolsetが非対応であることを、画面を操作するすべての方式が使えないと読み替えてはいけません。

Azure OpenAIとOpenAIの直接APIで異なる提供機能

OpenAIのモデルページに載るツールを、そのままAzure OpenAIで使える一覧にしてはいけません。Azure側のResponses API文書、モデルの機能表、リージョン・デプロイ種別を組み合わせて確認します。

この連載のチャット例では、Responses APIを採用し、社内検索や業務処理はアプリの関数ツールから呼ぶ構成を出発点にします。組み込みの検索、ファイル保管、コード実行、バックグラウンド実行を使う場合は、機能ごとに対応状況とデータの保持条件を確認します。[1]

Foundry全体にBatch系のデプロイ種別があることから、ClaudeのMessage Batches APIも使えるとは判断できません。サービス共通のメニューとモデル固有の提供条件は別です。

「Azureにある」と「国内で処理する」を分ける

Microsoftのデプロイ種別の説明では、データの保存場所と推論を処理する場所を分けています。Globalでは広い地域で処理される場合があります。Data Zoneは指定されたゾーン内で処理する方式であり、単一の国やリージョン内で処理するという意味ではありません。また、すべてのモデルで全デプロイ種別を選べるわけではありません。[3]

日本国内処理が必須なら、US Data Zoneを選べることは解決策になりません。所在地条件はモデル評価の前に判定します。プライベートネットワークも接続の制御であり、推論の処理地域を決める設定とは別です。

ビジネス判断へ変換する

状況	候補の絞り方	承認資料に書くこと
提供元固有の機能が売りになる	直接APIと対応ホスティングを優先評価	新機能の価値と別運用の負担
既存Azure運用の統一効果が大きい	Foundryで必須条件を満たす構成を評価	運用の統一で減る工数と、使えない機能を補うために増える工数
大量の非同期処理が中心	バッチ対応を経路別に確認	割引の実適用条件、待ち時間、容量
データ所在が制約になる	地域条件を満たす候補だけ残す	保存・処理・ログ・安全関連データの流れ

この選び方は筆者の提案です。複数の経路を併用することもできますが、運用先が増え、会話状態の移行、請求、障害調査が複雑になります。提供元を分けるだけでは、両方が同じ障害の影響を受けないとは保証できません。

前回： 第2回 ResponsesとMessagesの設計差 — 会話・推論・ツールの責任はどこにあるか

参考資料

参考資料の仕様確認日：2026年10月8日。契約・SLA・実請求額は採用条件として個別に確認する項目です。