Azure AI ServicesとAzure OpenAI Serviceの違い｜守備範囲とリソース種別で選ぶ基準

Azure上でAIを実装するとき、最初に決めるのが「どのリソースを作るか」です。Azure AI Services（2026年8月時点の公式名称はFoundry Tools）は音声認識・翻訳・文書解析といった個別のAI APIをまとめた製品群、Azure OpenAI Serviceは大規模言語モデルの推論を提供する製品で、担当する処理そのものが違います。この記事では、両者の守備範囲、Azureリソースとしての種別とエンドポイントの持ち方、トランザクション課金とトークン課金という課金単位の差を1枚の表に整理し、要件別にどちらを選ぶかを実装者の目線で示します。2026年に進んだ名称変更の読み替えも併せて扱う内容です。

まとめ：要件別にどちらのリソースを作るかの結論

文字起こし、翻訳、帳票の読み取りといった入出力の決まったタスクだけなら、Foundry Tools（旧Azure AI Services）のリソースで完結します。モデルのデプロイ作業が要らず、APIを呼べばその場で結果が返る設計だからです。一方、プロンプトで振る舞いを決める生成AIやエージェントを作るなら、Azure OpenAIのモデルが必要になります。

そして2026年8月時点の推奨は、どちらか一方ではなくkind=AIServicesのFoundryリソースを1つ作ることです。このリソースはAzure OpenAIとFoundry Toolsの両方を単一のエンドポイントとキーで到達させ、Azure OpenAI APIとの後方互換も保ちます。スタンドアロンのAzure OpenAIリソースが要るのは、社内のセキュリティ方針でFoundry機能の全体が許可されていない環境に限られます。以下が、その根拠です。

Foundry Toolsへ改称したAzure AI Servicesの守備範囲

Azure AI Servicesは、学習済みモデルをAPIとして提供する製品群の総称でした。公式ドキュメント「Foundry Tools とは」は2026年8月9日時点の表示でタイトルごとFoundry Toolsに置き換わっており、本文でも「Foundry Tools（以前のAzure AI サービス）」と併記されています。中身の製品構成は変わっていません。

音声・翻訳・文書解析など個別AI APIとして残る十種類の内訳

現行として案内されているのは10サービスです。Speech（音声テキスト変換・読み上げ・話者認識）、Translator（100超の言語）、Language（自然言語理解）、Content Understanding（各種メディアの解析）、Document Intelligence（文書のデータ化）、Vision（画像と動画の解析）、Azure AI 検索、Content Safety（不適切コンテンツの検出）、Custom Vision（画像認識の作り込み）、Immersive Reader（読解支援）。

いずれも「入力を投げると解析結果が返る」形で、プロンプト設計は要りません。帳票やPDFの読み取りを担うDocument Intelligenceの実装感は、Azure AI Document Intelligenceの料金・使い方・精度で個別に整理しています。

提供終了が予定された六つのサービスと既存アプリの移行実務判断

同じドキュメントは、6サービスを提供終了予定として別表に分けています。Anomaly Detector、Content Moderator、Language Understanding（LUIS）、Metrics Advisor、Personalizer、QnA Makerです。既存アプリケーションでは引き続き使えるものの、新規のAI アプリケーションには使わない、と明記されています。

判断はここで割れます。LUISやQnA Makerで作った既存の対話機能を抱えているなら、同等機能をLanguageサービスへ移すか、Azure OpenAIのモデルに置き換えるかの二択です。意図分類のラベルが安定していて精度要件が厳しいならLanguageへ、想定外の言い回しに広く応答させたいならモデル側へ寄せる、という分け方が実装上は扱いやすくなります。

トランザクション数で決まる価格レベルとF0無料枠の実務適用条件

Foundry Toolsの課金は、認証情報を使って送るトランザクションの数に基づきます。価格レベルごとに、1秒あたりに許可されるトランザクション数（TPS）の上限、そのレベルで有効になる機能、あらかじめ定義されたトランザクション数が決まり、その数を超えると追加料金が発生する構造です。

試用向けには無料レベルがあり、リソースのSKUに F0 を指定して作成します。有償の標準レベルは S0 です。トークン数ではなく「何回呼んだか」で費用が決まるため、1回あたりの入力が長くても短くても単価は変わりません。長文を扱うほど費用が伸びるモデル推論とは、コストの効き方が逆になります。

Azure OpenAI Serviceが担うモデル推論という領域

Azure OpenAI Serviceは、OpenAIのモデルをAzureのネットワーク・認証・コンプライアンスの枠内で呼び出す製品です。現在はMicrosoft Foundryの中でFoundry Modelsとして提供され、Microsoft・OpenAI・Anthropic・Metaなどから1,900を超えるモデルにアクセスできます。定義・できること・事例までの全体像はAzure OpenAI Serviceとは？できること・料金・導入事例まで実務目線で解説にまとめています。

デプロイの種類で決まるトークン課金とPTU予約の差を比較する基準

Foundry Toolsと違い、モデル側は「デプロイの種類」を選ぶ工程があります。公式ドキュメントは9種類のSKUコードを挙げており、課金の型は3つに整理できます。トークンあたりの支払い（GlobalStandard、DataZoneStandard、Standard）、予約容量であるPTU（GlobalProvisionedManagedほか）、そして24時間の目標ターンアラウンドで50%割引となるバッチ（GlobalBatchほか）です。

既定の出発点はGlobal Standardとされています。新しいモデルが最初に来て、価格が最も低く、リージョンのカバー範囲も最も広いためです。予約に切り替える損益分岐の計算はAzure OpenAI PTUとは？必要ユニット数の見積もりと予約課金の損益分岐で扱っています。

データ所在地をGlobalとData Zoneと単一リージョンで分ける基準

保存データは指定したAzure地域に留まりますが、推論データの処理場所はデプロイの種類で変わります。Global系は任意のAzureリージョン、Data Zone系は米国・EU・アジア太平洋のいずれかのゾーン内、単一リージョンのStandardはデプロイしたリージョン内で処理されます。

個人情報や契約情報をプロンプトに載せる案件では、ここが設計の分岐点になります。国内処理を契約条項で求められるなら単一リージョンのStandard、EUデータ境界の順守が条件ならData Zone Standard、制約がなければGlobal Standard。Foundry Toolsのリソースにはこの区分がなく、リージョン選択だけで決まる点も押さえておきます。

リソース種別とエンドポイントの違いを1枚に整理した実装対照表

どちらもAzure上は Microsoft.CognitiveServices/accounts という同じリソースプロバイダーに属します。違うのは kind の値と、それに紐づく機能範囲です。

AIServicesのFoundryリソースとAzure OpenAI専用リソース

Foundryリソースは kind に AIServices を指定して作ります。Azure CLIなら az cognitiveservices account create に --kind AIServices --sku S0 を渡す形で、Azureポータル上では「Foundry」の下に表示され、APIの種類はAIServicesと表示されます。

対するAzure OpenAIリソースは、OpenAIのモデルとAPIにだけアクセスできる特殊な種別です。公式ドキュメントは「ほとんどのユースケースではFoundryリソースを使う」と明言し、その理由としてすべてのAzure OpenAI APIとの下位互換を挙げています。既存のAzure OpenAIリソースは、エンドポイント・APIキー・作業状態・セキュリティ構成を保ったままFoundryリソースへアップグレードできます。

守備範囲・課金単位・デプロイ要否を並べた比較表による実装判断

実装判断で効く観点だけを抜き出すと、次の対照になります。

エンドポイントについては、Foundryリソースにまとめた場合、Azure OpenAIとFoundry Toolsが1つのエンドポイントとキーで到達可能になります。関連する作業はプロジェクト単位で分離しつつ、基盤となるリソースは共有する構成です。

旧名称から現行名称への読み替えと呼び出し方の変更点を整理する実務知識

検索で出てくる記事や社内資料は旧名称のままのことが多いため、対応関係を持っておくと迷いません。公式の対照表は次の通りです。

コードに効くのはAPIバージョンの扱いです。月ごとの api-version パラメータを指定する方式から、/openai/v1/ の安定ルートへ移行しました。固定と追随のどちらを選ぶかはAzure OpenAIのapi-versionとv1 APIへの移行判断で整理しています。なおRBACロールは表示名だけが変わり、ロールIDと権限そのものは変わっていません。

1つのリソースに寄せる構成と分ける構成の判断基準と運用上の注意点

守備範囲が分かったうえで残る設計判断が、リソースを統合するか分割するかです。

統合エンドポイントとキー共有で得られる運用上の効果と設計上の注意点

Foundryリソースに寄せると、ID・アクセス制御・ネットワーク・セキュリティ・課金・監視の境界が1つにまとまります。RBACはFoundry User、Foundry Project Manager、Foundry Account Owner、Foundry Ownerの4ロールで統一され、ネットワーク設定もリソース単位で一度決めれば完了です。文字起こしと要約を組み合わせるような処理では、SpeechとGPT系モデルを同じキーで呼べる差が実装量に効いてきます。

逆に、キーが共有される点は制約にもなります。特定チームにSpeechだけを触らせたい、といった粒度の分離はキーでは実現できません。その場合はプロジェクトを分けたうえでロールを割り当てるか、リソース自体を分けます。

スタンドアロンのAzure OpenAIリソースが必要になる条件

公式ドキュメントが挙げるスタンドアロン構成の理由は1点です。IT セキュリティチームが環境でFoundry機能のスーパーセットを有効にしていない場合。つまり、社内のAzure Policyでエージェント機能や外部ツール接続が許可されていない環境では、機能範囲の狭いAzure OpenAIリソースを選ばざるを得ません。

もう1つ、実務上の理由としてコスト配賦があります。生成AIの費用を部門別に請求する運用では、リソースを分けたほうが請求書上の切り分けが単純になります。ただしこれはプロジェクト単位のタグ付けでも代替できるため、分割の決め手にはなりません。設計をどこまで詰めるか迷う段階なら、生成AI開発・AI受託開発の相談窓口で要件から詰める進め方もあります。

要件別にどちらを選ぶかを言い切る採用と見送りの条件を決める基準

ここまでの事実をもとに、判断を確定させます。

定型タスクだけならFoundry Toolsに寄せるべき三つの根拠

音声の文字起こし、多言語翻訳、請求書や申込書の項目抽出。この3つに用途が閉じているなら、Azure OpenAIのモデルは使いません。根拠は3点です。第1に、モデルのデプロイもクォータ管理も不要で、リソースを作ればすぐ呼べます。第2に、トランザクション課金は処理量の見積もりが立てやすく、F0 の無料レベルで精度検証まで進められる点です。第3に、コンプライアンス要件があればオンプレミスのコンテナで動かす選択肢が残ります。

汎用モデルに帳票を読ませる構成は一見すると柔軟ですが、レイアウトが決まった帳票では専用サービスのほうが結果が安定し、費用も入力の長さに引きずられません。

生成やエージェントを含むならFoundryリソースへ寄せる判断

要約、下書き生成、社内文書への質問応答、複数ツールを呼ぶエージェント。この領域が1つでも要件に入るなら、kind=AIServicesのFoundryリソースを作ります。Foundry Toolsだけでは生成の要件を満たせず、Azure OpenAI専用リソースを選ぶとエージェント機能や他社モデルが将来使えないからです。

エージェントを組む場合の具体的な構成はFoundry Agent Serviceとは？旧Azure AI Agent Serviceからの移行と料金・実装手順を参照してください。どのモデルを載せるかの選定はAzure OpenAI Serviceのモデル一覧と選び方で用途別に整理しています。

採用を見送るべき場面と現場で起きがちな失敗パターンを避ける方法

見送るべき場面を3つ挙げます。1つ目、提供終了予定のサービス（LUIS、QnA Maker、Personalizerなど）を新規プロジェクトの土台に据えること。既存アプリの延命なら構いませんが、新規構築で選ぶ理由はありません。

2つ目、検証段階からPTUを購入すること。予約容量は稼働率が読めて初めて得になる仕組みで、トラフィックが定まらない時期はGlobal Standardのままにします。3つ目、Azure OpenAI専用リソースを新規で作ること。後からFoundryリソースへアップグレードできるとはいえ、移行作業と検証の手間が無駄に増えます。

失敗として多いのは、翻訳や文字起こしまで生成モデルに寄せてしまい、入力が長い月だけ費用が跳ね上がる構成です。課金単位が違う以上、処理の性質で振り分けたほうが費用は読めます。

よくある質問

導入検討の場で実際に挙がる質問を5つ取り上げます。回答は2026年8月時点の公式ドキュメントの記載に基づきます。

Azure OpenAI ServiceはAzure AI Servicesに含まれるのですか？

製品群としては別扱いです。2026年8月時点の公式ドキュメントでは、Azure AI ServicesはFoundry Toolsへ、Azure OpenAIのモデル群はFoundry Modelsへと、それぞれ別の名前で整理されています。ただしAzureリソースとしては同じ Microsoft.CognitiveServices プロバイダーに属し、kindがAIServicesのFoundryリソースを作れば両方を1つのエンドポイントとキーから呼べます。「含まれる」というより「同じ入れ物に同居できる」と捉えると設計を誤りません。

Azure AI Servicesという名前はもう使われないのですか？

ポータルやCLIの表記としては残っています。リソースの kind は現在も AIServices ですし、公式ドキュメントも「Foundry Tools（以前のAzure AI サービス）」と併記しています。ドキュメントの表示上のブランド名が入れ替わった段階で、APIやリソース定義の識別子までは変わっていません。既存のBicepやTerraformのコードを書き換える必要はありません。

Foundry ToolsとAzure OpenAIで料金の考え方はどう違いますか？

課金の単位は別です。Foundry Toolsは認証情報で送るトランザクションの数に応じた価格レベル制で、レベルごとにTPS上限と含まれるトランザクション数が決まり、超過分に追加料金がかかります。SKU F0 の無料レベルも用意されています。Azure OpenAI側はデプロイの種類次第で、トークンあたりの支払い、PTUによる予約、24時間ターンアラウンドで50%割引となるバッチのいずれかです。入力が長い処理ほどモデル側の費用は伸びます。

すでにAzure OpenAIリソースがある場合は作り直しですか？

作り直しは不要です。公式にはAzure OpenAIリソースをFoundryリソースへアップグレードする経路が用意されており、既存のエンドポイント、APIキー、作業状態、セキュリティ構成を維持したまま、Foundryの全機能とモデルにアクセスできるようになります。アプリケーション側の接続設定を書き換えずに移行できるため、まずアップグレードを検討し、社内のセキュリティ方針で機能範囲を絞る必要がある場合のみ現状維持とします。

どちらを選んでもデータが学習に使われることはありませんか？

どちらもMicrosoft Entra IDによる認証、ロールベースのアクセス制御、コンテンツフィルター、ネットワーク分離、Azure Policyの適用といった企業向けの制御が用意されています。データの取り扱いはサービスごとに条件が定められているため、契約要件がある案件では対象サービスの条項を個別に確認してください。推論データの処理場所を国内やデータゾーン内に限定したい場合は、モデル側でデプロイの種類をStandardまたはData Zone系に指定します。

関連記事

• Azure OpenAI Serviceとは？できること・料金・導入事例まで実務目線で解説：モデル側の定義・料金・事例をまとめたハブ記事です。
• Microsoft Foundry（Azure AI Foundry）とは何か：両者を束ねるプラットフォーム全体の機能と他社比較を扱っています。
• Foundry Agent Serviceとは？旧Azure AI Agent Serviceからの移行と料金・実装手順：エージェントを組む場合の構成と移行手順です。
• Azure AI Document Intelligenceの料金・使い方・精度：Foundry Tools側の代表サービスを個別に掘り下げています。
• Azure OpenAI PTUとは？必要ユニット数の見積もりと予約課金の損益分岐：予約課金へ切り替える損益分岐の計算手順です。