Azureで使えるAIサービスは？Microsoft Foundry時代の主要サービス一覧・利用メリットを解説【2026年版】

Azureで使えるAIサービスとは、2026年6月のMicrosoft Build 2026でリブランドされたMicrosoft Foundry傘下のFoundry Models・Foundry Agent Service・Foundry IQ・Foundry Toolsの4層と、独自モデルを構築するAzure Machine Learningを指します。

旧「Azure AI Services（さらに旧Cognitive Services）」は「Foundry Tools」へ呼称変更され、Vision・Speech・Languageなど組み込みAI 10種＋非推奨6種として整理し直されました。

本記事では、4層構造の位置づけ、基盤モデル1,900超のラインアップ、企業導入メリット、用途別の選び方、料金体系、Japan Eastでの提供状況、大塚製薬工場・SoftBankの事例までを、公式一次情報を軸に整理します。

Azureで使えるAIサービスとは

Azureで使えるAIサービスとは、Microsoft Azure上で提供される事前構築型AI API・基盤モデルカタログ・エージェント実行基盤・独自モデル構築基盤の総称で、2026年6月のMicrosoft Build 2026以降は「Microsoft Foundry」ブランドの傘下に統合されて提供されています。

Azure上のAIサービスが他クラウドと一線を画すのは、かつて別枠で語られてきたAzure Cognitive Services(画像・音声・言語などの個別API群)とAzure OpenAI Service(GPT系モデル)を、Foundry上で1つのプラットフォームに再編した点です。基盤モデル・エージェント・組み込みAI・独自モデル構築を分断なく組める形は、AWSやGCPが個別サービスの積み上げで構成しているのとは対照的な設計になっています。

この統合の意義は、既存のAzure資産(Entra ID・Purview・仮想ネットワーク・データ基盤)の延長線でAIを業務エージェントまで一気通貫に組み立てられる点で、Microsoft 365やDynamics 365と連続した業務プロセスの中にAIを埋め込みたいエンタープライズにとって刺さります。

Cognitive Services → Foundry Toolsへの呼称マップ

「Azureで使えるAIサービス」の呼称は2018年以降で3世代にわたって変化してきており、Web検索で古い記事に当たっても、多くのサービスは同じ系譜で継続しています。以下の表で、世代ごとの呼称の変遷を整理しました。

世代	主要な呼称	主なタイミング
第1世代	Azure Cognitive Services	〜2023年
第2世代	Azure AI Services	2023年〜2026年6月
第3世代	Foundry Tools(Microsoft Foundryの一部)	2026年6月〜(Build 2026)

Microsoft Learnの公式ドキュメントでも「Azure AIサービス → Foundry Tools(鋳造ツール)」への呼称変更が明記されているため、外部記事で「Azure AI Services」「Cognitive Services」と書かれているものは、2026年半ば以降はFoundry Toolsを指していると読み替えて構いません。

---

Microsoft Foundryが束ねるAzureのAIサービス4層構造

2026年時点で「Azureで使えるAIサービス」を整理するときは、Microsoft Foundryの4層構造＋独立系サービスという枠組みで捉えると全体像がつかめます。

このセクションでは、4層それぞれの役割と、後段H2との対応関係を骨格として押さえます。各層の詳細な機能・料金・使い方は、後続のFoundry Models / Foundry Tools / Azure Machine Learningのセクションでホーム論点として深掘りします。

Foundry Models——1,900以上の基盤モデルを一元管理

Foundry Modelsは、OpenAIのGPTシリーズ、Anthropic Claude、xAI Grok、Meta Llama、Mistral、DeepSeek、Microsoft Phiなど、社内外の基盤モデルを1つのカタログから呼び出せる層です。

Microsoft公式によれば、Foundry上で提供されるモデルは1,900を超え、モデルファミリごとに用途が定義されています。詳細と主要ファミリの使い分けは、次のH2「Foundry Modelsで使える基盤モデルのラインアップ」で扱います。

Foundry Agent Service——エージェントの実行ランタイム

Foundry Agent Serviceは、AIエージェントを本番運用するためのマネージド実行環境です。

2026年3月に一般提供（GA）済みで、マルチエージェントオーケストレーション、1,400を超えるツールカタログ、対話間コンテキストの保持（メモリ）、Microsoft 365やTeamsへの公開など、業務エージェントを商用ワークロードに載せるための機能が揃っています。ただし公式ドキュメント上ではメモリやWeb検索などの一部ツール・機能はまだプレビュー扱いのため、採用時は機能ごとにGA / プレビュー状態を個別に確認する運用が前提です。

「モデルを動かす基盤」がFoundry Modelsで、「モデルに業務手順・道具・記憶を持たせる基盤」がAgent Serviceという役割分担です。

Foundry IQ——エンタープライズデータへのグラウンディング

Foundry IQは、SharePoint・OneLake・ADLS・Webといった社内外の情報源にエージェントを接続し、根拠付き回答を返させるためのナレッジ統合レイヤーです。Foundry IQのナレッジベース（APIレベル）は2026年6月のBuild 2026でGA、Foundryポータル面やWork IQ・Fabric IQ・Web IQの一部はプレビュー状態が残る、という段階的なGA構成です。

Ignite 2025以降、ナレッジソースにMicrosoft 365コンテンツを取り込むWork IQ（プレビュー）、Microsoft Fabricデータに接続するFabric IQ（プレビュー）、Web検索を組み込むWeb IQ（プレビュー）が追加され、社内RAGの選択肢が大幅に広がりました。

Foundry Tools——組み込み型AIのAPI群（旧Azure AI Services）

Foundry Toolsは、Vision（画像分析）・Speech（音声認識・合成）・Language（自然言語処理）・Document Intelligence（文書構造化）などの、事前学習済みモデルをAPIで呼び出せる従来型のサービス群です。

2026年半ばに旧「Azure AI Services」から「Foundry Tools」へ呼称変更され、Foundryプラットフォーム内でも1つの層として整理されています。既存のCognitive Services APIを使っていたユーザーが最初に思い浮かべる層は、このFoundry Toolsに該当します。

Foundry Control PlaneとAzure Machine Learning

上記4層に加え、統制レイヤーとしてFoundry Control Plane（AI資産の一元管理・RBAC・監視・ガバナンス）と、独立サービスとしてのAzure Machine Learningが存在します。

Foundry Control PlaneはAIリソースを組織横断で管理するIT管理者向けの層で、Azure Machine Learningは独自データで機械学習モデルを学習・運用する場合に選ばれる層です。以下の表で、5層それぞれの役割と後段H2との対応関係を整理しました。

層	役割	掘り下げているセクション
Foundry Models	1,900超の基盤モデル呼び出し	「Foundry Modelsで使える基盤モデルのラインアップ」
Foundry Agent Service	エージェント実行ランタイム	「業務要件から選ぶ」の業務エージェント項
Foundry IQ	社内外ナレッジ統合（RAG）	「業務要件から選ぶ」の社内RAG項
Foundry Tools	組み込みAI API群（旧Azure AI Services）	「Foundry Toolsに含まれる組み込みAIと非推奨サービス」
Foundry Control Plane	統制・ガバナンス	「企業導入するメリット」の責任あるAI項
Azure Machine Learning	独自モデル構築	「独自モデルを構築するAzure Machine Learning」

ここまでの4層＋独立サービスが押さえられれば、Azureで使えるAIサービスの全体像は把握できたと言って構いません。次のセクションから、各層の中身を順に見ていきます。

---

Foundry Modelsで使える基盤モデルのラインアップ

Foundry Modelsは、Azureで使えるAIサービスのうち「基盤モデルを呼び出したい」用途の中心となる層です。

Microsoft、OpenAI、Anthropic、xAI、Meta、Mistral、DeepSeek、Hugging Faceなどのモデルが、1つのカタログ上で1,900モデル以上提供されている点が特徴です。ここでは、代表的なモデルファミリと、Azure環境で使う際の位置づけを整理します。

Azure OpenAI in Foundry Models——中心は依然としてGPTシリーズ

Foundry Modelsのなかで最も広く使われているのは、依然として Azure OpenAI Service 経由で提供されるOpenAIモデルです。

現在の主要モデルは、GPT-5・GPT-5.1・GPT-5.2・GPT-5.4系列、そして2026年4月にFoundry上でGAとなった GPT-5.5 です。

GPT-5.5はMicrosoft公式ブログで「フロンティア知能をエンプラ対応プラットフォームで提供」と説明され、長文脈推論・エージェント実行・ツール利用の精度が強化されています。

これに加えて、gpt-realtime-1.5 / gpt-realtime-2・gpt-audio-1.5・GPT-image-1.5のマルチモーダル系モデルも2025年末〜2026年上半期にかけて順次追加されており（GPT-image-1.5は2025年12月時点で利用可能、gpt-realtime-2は2026年上半期）、音声対話やUI操作、画像編集を組み合わせた業務エージェントを構築しやすくなっています。

他社モデル群——ClaudeがFoundryでGA、Grok・Llama・Mistralも直販

Foundry Modelsの2026年最大の変化は、OpenAI以外の他社モデルがカタログ内で直接提供されるようになった点です。

Anthropicは2026年6月29日にClaudeをMicrosoft Foundry上でGAし、Opus 4.6・Sonnet 4.6は1M-tokenコンテキスト対応（128Kと切り替え可能）でGA利用できるようになりました。

現在提供されているモデル一覧と各モデルの対応リージョンは Microsoft LearnのClaudeモデルページ に整理されています。xAI Grokは Foundryで直販されるモデル一覧にGrok 4系が並び、Grok 4.1 Fast系（reasoning / non-reasoning）はモデルルーター対応がプレビュー段階として案内されています。以下の表で、Foundry Modelsで扱える主要なモデルファミリを整理しました。

モデルファミリ	主な用途（Microsoft公式ガイド）	提供元
GPT-5	複雑推論・マルチステップ・マルチモーダル	OpenAI
GPT-4.1	機能とコストのバランス	OpenAI
GPT-4.1 mini	低レイテンシ・高スループット	OpenAI
Claude	高度推論・コード生成・マルチモーダル	Anthropic
Grok	推論・コーディング・データ抽出	xAI
Mistral	コード生成・多言語・汎用チャット	Mistral
DeepSeek-R1	大規模オープンウェイト推論	DeepSeek
Phi-4	デバイス上・リソース制約下	Microsoft
Meta Llama	オープンモデル・カスタマイズ	Meta

実務では「まずGPT-5.4 miniで試作 → 精度が足りなければGPT-5.5やClaude Opus 4.6へ切り替え → コストが厳しくなればPhi-4やLlamaにオープンウェイトで切り出す」というモデル選択の三段構えが取りやすくなっています。

ClaudeをAzure環境で使うシナリオについては Claude Code on Microsoft Foundry の解説記事も併せて参考にしてください。

Foundry Modelsで押さえておく実務ポイント

Foundry Modelsを使う上で見落としやすい点として、次の3つを押さえておくと選定作業が早くなります。

• 1つのプロジェクトエンドポイントに集約される設計
  Foundryでは、Assistants API（Agents v0.5/v1）に代わるResponses API（Agents v2）と、統合されたプロジェクトクライアント（azure-ai-projects 2.x）＋OpenAI() を通じて、複数モデルを1エンドポイントから呼び分けられます。従来の月単位api-versionパラメータではなく、v1安定ルート（/openai/v1/）に統合されている点も、移行時にコード修正の焦点になります。
  
  

• モデルルーティングとインスタントアクセス
  Responses APIの新機能として、「モデルを名前で指定せず自動選択させる」モデルルーティングと、事前にデプロイを作らずに使えるInstant Access（プレビュー）が導入されました。プロンプトごとに最適モデルを切り替える運用が公式サポートで組めるようになっています。
  
  

• リージョンごとのモデル可用性差
  GPT-5.5や最新のマルチモーダルモデルは、Japan Eastを含む主要リージョンで順次展開されますが、公開直後はGlobal（データゾーン）リージョン限定になるケースがあります。「Japan Eastで日本語データを閉じたい」要件がある場合は、対象モデルの提供リージョン一覧を事前に確認する必要があります。

これらはAzure OpenAI Service世代からの延長線上にある実務論点ですが、Foundry化に伴ってエンドポイント名やSDKパッケージ名が変わっているため、既存の Azure OpenAI Studio や旧APIキー運用（APIキー取得方法）からFoundryへの移行を進める企業では、既存資産の棚卸しが最初の1歩になります。

---

Foundry Toolsに含まれる組み込みAIと非推奨サービス

Foundry Toolsは、Azureで使えるAIサービスのうち「事前学習済みモデルをAPIで呼び出す」用途の中心層です。

旧Cognitive Services、旧Azure AI Servicesの実体を引き継ぎつつ、Microsoft Learnの公式ドキュメントで現行サービス10種と非推奨サービス6種として明示的に整理し直されています。ここでは、各サービスの用途と、非推奨サービスの移行の考え方を扱います。

現行の主要組み込みAIサービス10種

以下の表で、Foundry Toolsに含まれる現行10サービスの用途を整理しました。旧Cognitive Services時代からの呼称や統合・分離を経て、2026年時点はこの一覧が公式定義となっています。

サービス	用途
Speech	音声テキスト変換・テキスト読み上げ・翻訳・話者認識
Translator	100以上の言語・方言のAI翻訳
Language	自然言語理解（分類・エンティティ抽出・要約等）
Content Understanding	複数メディア（文書・画像・動画・音声）を横断的に分析
Document Intelligence	帳票・契約書・請求書の構造化データ抽出
Vision	画像・動画のコンテンツ分析
Azure AI検索	AIを組み込んだクラウド検索（RAG基盤）
コンテンツの安全性	望ましくないコンテンツの検出
Custom Vision	業務データで画像認識をカスタマイズ
Immersive Reader	読解支援（読み上げ・翻訳・辞書機能）

大半の企業でまず引き合いに出るのは、Azure AI Speech とDocument Intelligence、そしてRAG基盤として使われる Azure AI Search です。

特にAzure AI Searchは、Foundry IQのランタイム基盤としても位置づけられているため、社内RAG構築を検討するチームはFoundry IQ経由で使うか、Azure AI Search APIを直接叩くかの判断から入ることが多くなります。

各サービスは、REST API・クライアントライブラリ（Python/C#/Java/JavaScript等）・Foundryポータルの実験環境から呼び出せます。多くのFoundry Toolsで無料枠（リソースSKU「F0」）が用意されている点も、PoC段階の企業にとって参入障壁を下げる要素です（対象サービスは公式ドキュメントで確認できます）。

特に押さえておきたい主要3サービスの詳細

Foundry Toolsのなかで、業務ニーズが集中しやすい3サービスを短くレビューします。

Azure Vision（旧Azure AI Vision）

画像分析、物体検出、OCR、空間認識をREST APIで提供します。Azure AI Visionとしての解説記事も併せて参照できますが、後述するようにVision内の Image Analysis API（「/imageanalysis」endpoint、v3.2 / v4.0）は2028年9月25日に退役予定であり、OCR用途はDocument Intelligence、その他の画像理解用途はGPT系マルチモーダルモデルへの移行が想定されています。

Speech（音声）

音声からテキストへの文字起こし、テキストから音声への合成、話者認識、話者ダイアライゼーションなどを提供します。日本語を含む多言語対応で、Japan Eastリージョンでも利用可能。GPT-5.5世代のマルチモーダルモデル（gpt-audio-1.5）とセットで、通話ログ解析や音声エージェント構築に使われる例が増えています。

Document Intelligence

帳票・契約書・請求書などの半構造化文書からデータを抽出するサービスです。Layout API・Prebuilt Model（請求書・領収書・ID等）・Custom Modelの3層を持ち、経理・法務・保険領域のOCR＋構造化タスクの中心にあります。

これら3サービスは、いずれも旧Azure Cognitive Services / Azure AI Services時代からの利用者が多い領域です。呼称変更後も多くのFoundry Toolsは同じREST API / SDK経由で利用できますが、既存アプリへの実際の影響は各サービスの移行・廃止予定を公式ドキュメントで個別に確認するのが安全です。

廃止・非推奨予定の6サービスと移行の考え方

Foundry Toolsのうち、以下6サービスは提供終了が公式に告知されており、新規アプリケーションでの採用は避けるべき状態です。2026年7月時点でも一部はまだ稼働継続していますが、退役済みのサービスもあるため、状態は個別に確認する必要があります。

サービス	現状（2026年7月時点）	公式が示す移行先
Language Understanding (LUIS)	退役済み	短期移行：Languageサービスの会話言語理解（CLU、2029年3月末退役予定） ／ 長期・新規：Foundry Models・Foundry Agent Service
QnA Maker	退役済み	短期移行：Languageサービスのカスタム質問応答（CQA、2029年3月末退役予定） ／ 長期・新規：Foundry Models・Foundry Agent Service
Metrics Advisor	退役済み	Azure Monitor（メトリック監視）、OSSの 「anomalydetector」、Microsoft Fabricの時系列/異常検知
Anomaly Detector	退役予告済み・順次サービス終了	Microsoft Fabricの異常検知、またはOSS「anomalydetector」 ライブラリ
Personalizer	退役予告済み・順次サービス終了	OSSの 「learning-loop」（自己教師強化学習ライブラリ）
Content Moderator	退役予告済み・順次サービス終了	Foundry Tools「コンテンツの安全性」

加えて、Azure AI Vision の Image Analysis API（「/imageanalysis」endpoint、v3.2 / v4.0を含む）は2028年9月25日に退役が予告されており、OCR用途はDocument Intelligence、汎用画像理解はGPT系マルチモーダル、業種特化の画像認識はCustom Vision、という3方向への移行が想定されています。Visionサービス全体が廃止されるわけではなく、退役対象はImage Analysis APIのエンドポイントに限定されます。

退役済みのサービス（LUIS / QnA Maker / Metrics Advisor）については、既存アプリでのAPI呼び出し自体が停止する状態のため、まだCLU / カスタム質問応答等への移行が終わっていない場合は最優先で対応する必要があります。退役予告段階のサービス（Anomaly Detector / Personalizer / Content Moderator）はパッチ提供とサポート期間が段階的に狭くなっているため、リプレース計画を並行して立てておくことが実務的な備えになります。

各サービスの正確な退役日と現状は Microsoft LearnのFoundry Tools公式ドキュメント、および各サービス個別の "What's new" ページで最新情報を確認するのが安全です。

---

独自モデルを構築するAzure Machine Learning

Foundry Models・Foundry Toolsが「用意されたモデルを呼ぶ」層であるのに対し、Azure Machine Learning（Azure ML）は「自社データで独自のモデルを学習・運用する」層に位置します。

Foundry傘下ではありませんが、Microsoft公式アーキテクチャでもAzureのAI能力の「基盤」として明確に位置づけられており、Foundry Modelsのカタログ画面からもAzure MLへの誘導が用意されています。ここではAzure MLが担う3つの役割と、Foundry時代の位置づけを整理します。

Azure Machine Learningが担う3つの役割

Azure MLは、機械学習ライフサイクル全体を支えるプラットフォームです。以下の3つを1つのワークスペース上で扱えるのが特徴です。

• モデルの実験・学習
  Jupyter Notebookでの試行、AutoMLによる自動モデル選定、ハイパーパラメータ探索、分散学習をサポート。scikit-learn・PyTorch・TensorFlow・XGBoostなど主要フレームワーク対応。
  
  

• モデルのデプロイと推論
  学習済みモデルをManaged Online Endpoint・Batch Endpoint・Kubernetes Endpointにデプロイ。オートスケール・カナリアデプロイ・A/Bテストなど、業務利用に必要な運用機能を提供。
  
  

• MLOps（継続運用）
  Azure DevOps・GitHub Actions・MLflowと連携し、モデルの学習パイプライン・データセット・実験履歴・デプロイ履歴を一元管理。モデルの再学習・監視・データドリフト検知まで含めた継続運用を支援。

Foundry Modelsで試作したLLMアプリケーションが「業務データでのファインチューニングが必要な段階」に進んだときや、需要予測・異常検知・画像分類などの構造化AIをスクラッチで構築するときに、Azure MLが主戦場になります。

Azure ML × Foundry Modelsのハイブリッド運用

Foundry Modelsのカタログには、Azure Machine LearningからFoundry Modelsを呼び出す経路も公式に整備されています。

これにより、Azure MLパイプラインのなかでLLMを組み合わせた業務処理（例：構造化データの異常検知＋LLMによる原因説明の自動生成）を書けるようになっています。

「独自モデルvs Foundry Models」は排他的な選択ではなく、両者を役割分担する運用が2026年時点の標準的な設計です。中規模チームなら、UI周りとテキスト生成はFoundry Models／基幹予測はAzure ML／統制はFoundry Control Plane、という3層の切り分けが1つの型として使えます。

---

Azureで使えるAIサービスを企業導入するメリット

ここまで見てきた4層構造＋Azure Machine Learningを、企業がわざわざAzure上で組み立てるメリットは、単に「AIが動く」ことではありません。

競合クラウド（Amazon Bedrock、Google Vertex AI）と比較したときの差別化観点として、以下の5つが特に効きます。

Microsoft 365との親和性と業務エージェントへの直接接続

Azureで使えるAIサービスの最大の差別化ポイントは、Microsoft 365 と同じテナントで動く点です。

Foundry Agent Serviceで作ったエージェントを、Foundryポータルの発行機能からTeams・BizChat・Microsoft 365 Copilot の拡張として公開できます。

既存のSharePoint・OneDrive・OutlookのデータにはFoundry IQのWork IQ（プレビュー）経由でRBACを保ったまま接続できる設計ですが、memory・Web検索など一部ツールはプレビュー段階のため、機能ごとにGA / プレビュー状態を確認したうえで採用するのが実務の前提です。

社内ユーザーが日常的に触るツールがTeams・Outlook中心なら、「別の画面を開かせない」という運用面の効果は大きく、AWS BedrockやVertex AIの構成では別途Slack/Workspace側でのアプリ実装が必要になる部分を、Azureは自然に埋めています。

責任あるAI・エンプラガバナンス機能の内蔵

Foundry Control Planeを中心に、Azure Policy・Microsoft Entra ID との統合、RBACによる権限管理、Azure Monitor連動のオブザーバビリティが標準提供されます。

責任あるAIの観点では、Foundry Toolsの「コンテンツの安全性」がハルシネーション検出・有害コンテンツ検出・プロンプトインジェクション検出を提供しており、生成AI利用時のガードレールとして本番運用組み込みが容易です。監査ログ・データレジデンシー・SOC2/ISO27001/HIPAAなどの認証も揃い、金融・医療・公共領域の要件を満たしやすい状態にあります。

日本を含む多リージョン・データ主権対応

日本企業にとって重要なのが、Japan East（東日本）を中心に、主要なFoundry ToolsとOpenAI系Foundry Modelsが利用可能な点です。

海外リージョンにデータを持ち出さずにGPT-5系をJapan Eastから呼び出せるため、金融庁ガイドライン対応や個人情報保護法の観点から、AWSやGCPの日本リージョンだけでは対応が薄い領域を埋めやすくなります。

Anthropic Claude等のOpenAI以外のモデルは2026年7月時点でEast US2 / Sweden CentralなどのUS・EU系リージョンから提供されており、日本リージョンでの提供有無は公式のClaudeモデルリージョン一覧で個別確認する運用が前提です。

さらに、Microsoftが2026年4月に発表した3年間で$10Bの日本投資により、国内AIインフラの増強とパートナー各社（富士通・日立・NEC・NTTデータ・SoftBank）との連携で100万人規模のエンジニア育成が進行中です。

1,900モデルを1エンドポイントで呼び分けられる自由度

Foundry Modelsの1,900モデルカタログを、単一プロジェクトエンドポイントとResponses APIから呼び分けられる点も、AWS Bedrock（各モデルに個別ARN）やVertex AI（Google Cloud APIごとの分離）と比較したときの構造的な差別化です。

「OpenAIモデルとClaudeモデルとオープンウェイトLlamaを、同じチームが同じコードベースで使い分ける」構成が最小コストで組めるため、ベンダーロックインの回避と、モデル進化への追従が同時に狙えます。

既存Azure資産（データ・ID・ネットワーク）との統合コスト最小化

既にAzureを使っている企業なら、Microsoft Fabric のOneLake・Azure Databricks・Azure SQL Databaseなどの既存データ資産、Azure Databases 群、Entra IDの権限管理をそのままFoundryから参照できます。

新規にIDプロバイダを構築したり、S3/BigQueryとのデータ移動コストを積む必要がなく、「既存資産の上にAIを載せるだけ」の構成でPoCを開始できるのは、AzureをすでにIaaSで使っている企業にとって最も現実的な導入路です。

---

業務要件から選ぶAzureで使えるAIサービス

Azureで使えるAIサービスは、層の広さゆえに「どこから手を付けるか」で迷いやすい構造です。

このセクションでは、業務要件を起点にしたサービスマッピングを整理します。前段で紹介した4層＋Azure MLの内容を再説明するのではなく、「読者が実際に何を作りたいか」から逆算してどのサービス群を組み合わせるかを示す視点です。以下の表で、代表的な7つの業務要件と、選ぶべきサービス組み合わせを一覧化しました。

業務要件	中心サービス	補助サービス
社内チャット・FAQ応答	Foundry Models（GPT-5.4/Claude Sonnet 4.6）	Foundry IQ（Work IQ）、Foundry Toolsのコンテンツ安全性
社内RAG（社内文書検索＋回答生成）	Foundry IQ／Azure AI Search	Foundry Models、Azure OpenAI On Your Data
帳票・契約書のOCRと構造化	Document Intelligence	Foundry Models（後処理での要約・分類）
音声認識・通話ログ解析	Speech、gpt-audio-1.5	Languageサービス
業務エージェント（社内システム操作）	Foundry Agent Service	Foundry IQ、Microsoft Copilot Studio
独自モデル（需要予測・異常検知）	Azure Machine Learning	Azure Databricks、Microsoft Fabric
画像認識・外観検査	Custom Vision、Document Intelligence	Foundry Models（GPT系マルチモーダル）

この表を出発点に、業務要件が複合するときは「中心サービス＋補助サービス」の組み合わせで構成を考えると、Foundry傘下のサービスを重複投資せずに使い分けられます。

ここからは、実務判断で迷いやすい3つの要件について、選び方の勘所を掘り下げます。

社内RAG——Foundry IQかAzure AI Search直接叩きか

社内文書検索を組み込んだ生成AIアプリを作るときは、Foundry IQ（ナレッジ統合の抽象化レイヤー）と、Azure AI Search を直接叩く方法の2択があります。

• Foundry IQが向くケース
  Microsoft 365データ（SharePoint・Teams・OneDrive）を主なナレッジソースにしたい／Work IQ・Fabric IQ・Web IQを組み合わせたい／RAG運用の統制をFoundry Control Planeに寄せたい
  
  

• Azure AI Search直接叩きが向くケース
  既存のAzure AI Searchインデックスを再利用したい／複雑なクエリ変換やハイブリッド検索（ベクター＋キーワード）を細かく制御したい／Azure OpenAIのOn Your Data を活用したい

2026年半ば時点は、標準の社内RAGならFoundry IQ、Azure OpenAIの既存構成を活かすならAzure AI Search直接叩きから入るのが自然な選び方です。

業務エージェント——Foundry Agent ServiceかCopilot Studioか

業務エージェントを構築するときの選択肢として、Foundry Agent Service と Microsoft Copilot Studio の2つが並びます。役割分担は次のとおりです。

• Foundry Agent Serviceが向くケース
  コード中心でエージェントを設計したい／複数モデルを切り替えたい／マルチエージェントオーケストレーションを組みたい／SDK（Python/C#/Java/TS）で本番運用したい
  
  

• Copilot Studioが向くケース
  ノーコード・ローコードで市民開発として展開したい／Power PlatformやDataverseと直接連携したい／既存のCopilot（M365 Copilot・Business Chat等）に業務エージェントを追加したい

実務では、「まずCopilot Studioでプロトタイプ→本番運用フェーズでFoundry Agent Serviceに移す」というハイブリッド運用も選択肢になります。両者は競合ではなく補完関係にあると捉えるのが自然です。

独自モデルvs Foundry Models——境界線

需要予測・在庫最適化・異常検知など、構造化データを扱う機械学習の場合、Foundry Models側にはNixtla TimeGEN-1のような時系列モデルもカタログに載っていますが、自社データでの継続的な学習・MLOps・独自モデル管理が必要になる本格運用は、Azure Machine Learning・Azure Databricks・Microsoft Fabricの組み合わせが主戦場になります。

一方、LLMで解ける自然言語処理・画像理解タスクは、独自モデル学習の初期投資を掛けずともFoundry Modelsのプロンプト調整＋Fine-tuningで十分な精度に到達するケースが増えています。

「継続学習・MLOps・独自モデル管理が必要ならAzure ML、LLMやマルチモーダル・カタログに載っている既製モデルの利用で足りるならFoundry Models」という役割分担で切るのを最初の判断軸にすると、リソース投下先を絞りやすくなります。データ種別（構造化 / 非構造化）で単純に二分するより、運用面（自社学習・管理が要るか）で切る方が、実プロジェクトの判断に直結します。

---

Azureで使えるAIサービスの料金相場と日本リージョンでの提供状況

Azureで使えるAIサービスは、サービス種別ごとに料金体系が異なります。

「Azureの料金って結局いくら？」という質問に一言で答えるのは難しいですが、Azureの料金体系 の基本4パターンを押さえれば、大半のサービスは見積もれます。ここでは、料金モデルの体系とJapan East提供状況を整理します。

料金モデルは4体系——従量課金・PTU・リザーブド・Free Tier

Azureで使えるAIサービスの課金は、以下の4つのパターンに大別されます。

• 従量課金（Consumption / Pay-as-you-go）
  API呼び出しごとに従量で課金される最も一般的なモデル。Foundry Models（Azure OpenAI Serviceの料金）、Foundry ToolsのVision・Speech・Language、Foundry Agent Serviceなど、多くのサービスで標準採用。100万トークン単位や1,000リクエスト単位で課金される。
  
  

• PTU（Provisioned Throughput Units）
  Azure OpenAI Serviceで用意された「スループット予約枠」。特定モデルの推論スループットを事前確保することで、レイテンシ保証と月次固定コストを両立できる。大量トラフィックが読める本番運用向け。
  
  

• リザーブドインスタンス（1年/3年予約）
  PTUや一部のAzureリソース（Machine Learningのコンピュート等）で、1年・3年の予約割引が使える。運用が長期化する見込みが立った段階で、通常の従量課金からの割引が狙える。割引率と対象サービス範囲は契約条件・リージョン・サービスごとに変わるため、Azure Reservationsの公式ページと各サービスの料金ページで個別に確認する。
  
  

• Free Tier（F0 SKU）
  Foundry Toolsの多くは無料枠（SKU「F0」）を提供している。1秒あたりのトランザクション制限や機能制限があるが、PoCフェーズでの試作コストを抑えられる。

実務では、PoCはFree Tier ＋ 従量課金、本番運用は 従量課金 → 一定規模超えでPTUまたはリザーブドへ、という段階移行の流れが定石です。GPT-5.5世代のように従量課金単価が高いモデルは、月間トークン量の見積もりを元にPTUへの切り替え検討ラインを事前に設定しておくと、突発的な請求増を避けられます。

日本リージョンでの提供状況

Foundry Toolsの多くと、GPT-5系・GPT-4.1系などのOpenAI系Foundry ModelsはJapan East（東日本リージョン）で利用可能です。

一方、Claude Opus 4.6 / Sonnet 4.6などAnthropicモデルはEast US2 / Sweden CentralなどのUS・EU系リージョン中心の提供で、日本リージョンでの提供は 公式のClaudeモデルリージョン一覧 で個別確認が必要です。

日本国内でデータを閉じたい要件がある場合は、Japan Eastを第一選択にしつつ、対象モデル・サービスのリージョン提供状況を Microsoft公式のリージョン一覧 で個別確認する運用になります。

一方で、一部の最新マルチモーダル／リアルタイム系モデルはJapan East未対応の場合があり、まず別リージョンから段階展開されるケースがあります（例：gpt-realtime-2は現時点でSouth India / Sweden CentralなどのStandardリージョン中心の提供。ただしGPT-5 / GPT-5.1 / GPT-5.2 / GPT-5.4 / GPT-5.5など主要テキストモデルはJapan East対応済み）。対象モデルの現在の提供リージョンは Foundry直販モデルのリージョン別提供状況 で確認します。

Foundryのプレビュー機能（A2A Agent Endpoint、Instant Access等）については、リージョン対応が機能・ツール・モデルごとにバラバラで、A2A Agent EndpointのようにJapan Eastで利用可能なものもあれば、モデル依存で限定リージョンにしか出ていないものもあります。

「プレビュー＝Japan East未対応」と一括りにはできないため、Agent Serviceのツール別対応表 など、機能ごとの公式表で確認するのが安全です。

• 業務データを国内に閉じたい：Japan Eastに対応するサービスから選定
• 最新モデルを最速で使いたい：Global（East US 2 / Sweden Central等）から段階展開を待つ
• 両立させたい：Japan Eastで安定モデル運用しつつ、実験環境だけGlobalに配置

この使い分けが、リージョン制約と最新モデル追従を両立させる基本形になります。

---

AzureベースのAIサービスの企業事例

Azureで使えるAIサービスは、日本のエンプラでも既に本番運用の事例が公表され始めています。

ここでは、Microsoft公式カスタマーストーリーで一次情報として確認できる代表的な2事例（大塚製薬工場・SoftBank）を、出典を明示しつつ短くまとめます。

大塚製薬工場——MRの営業活動を支える生成AIエージェント「epico」

Microsoft公式カスタマーストーリー（2026年）によれば、大塚製薬工場はAzure OpenAI in Foundry Modelsを活用し、MR（医薬情報担当者）の営業活動を支援するAIエージェント「epico」を構築しました。

業務部門とIT部門が一体となって内製で構築を進めた点、Azure OpenAIのセキュリティ設計（送信データがモデル学習に使われないこと）、既存の権限管理・多要素認証をそのまま利用できた点が、生成AI全社展開のブレークスルーになったと同社は説明しています。

「大手製薬企業でも、Foundryを軸に業務部門主導のミドルアップダウン展開ができる」という前例として、日本の他エンプラ導入検討にも波及しています。

SoftBank——資料作成を高速化する「satto workspace」

Microsoft公式カスタマーストーリー（2026年）は、SoftBankがAzure OpenAIをベースに構築した「satto workspace」を紹介しています。

このプラットフォームは、日本語ビジネス文書の作法に沿ったプレゼンテーションや文書を、技術訓練なしで作成できるように設計されています。

ストーリー内で紹介されているのは全社実績ではなく、iPaaS Business Development部門をリードする平岡氏のチームで得られた効果で、同チームでは プレゼンテーションの30〜50%が「satto workspace」を通じて10分以内に作成されるようになり、ワークライフバランスと生産性の両方を改善したと語られています。

大企業のなかで生成AIを「一部の技術者向け」に留めず、業務チーム単位で日常的に触れる形に落とし込んだ例として、汎用性の高い参考事例です（全社展開の公式結果は本記事執筆時点では未公表）。

事例から読み取れる共通パターン

大塚製薬工場・SoftBankの2事例で共通しているのは、Azure OpenAI in Foundry Modelsを業務フローに直接組み込み、業務部門主導で生成AI活用を進めている点です。両社とも新規に専用AI基盤を立ち上げるのではなく、既存のAzureテナント上のAzure OpenAIを業務フローへ載せるアプローチをとっています。

一方で「どこまで既存のAzure資産を再利用しているか」は事例ごとに濃淡があります。大塚製薬工場のストーリーではAzure OpenAIのデータ非学習保証に加え、既存のEntra IDによる権限管理と多要素認証をそのまま活かして生成AIを全社展開したことが明示されています。

SoftBank側は同レベルのID / 認証まわりの記述は公式ストーリーで確認できないため、共通の学びは「Azure OpenAI in Foundry Modelsを業務フローに組み込むアプローチ」に留め、ID・認証統合を含めた再利用度は大塚製薬工場側の固有の強みとして読むのが正確です。

国内他エンプラの初期導入では、この2事例のパターンを踏まえてAzure OpenAI in Foundry Models単体から着手し、必要に応じてFoundry Agent ServiceやFoundry IQを段階的に足していく進め方が現実的な着地点になります。

---

Azure AI資産を業務エージェント自動化まで届けるなら

Azureで使えるAIサービスは、Foundry Models・Foundry Tools・Azure Machine Learningまで揃った時点で「モデルを呼ぶ」段階は十分に整備されています。

ただし、多くの企業で残る課題は、そこから先の「業務プロセスへ落とし込む」フェーズです。Foundry Agent Serviceで作ったエージェントを、社員が日常的に触るMicrosoft Teamsからそのまま呼び出せる形にまで持っていって、初めてAI投資がPoCで止まらず定着します。

このレイヤーを担うのが、Microsoft 365環境と自社テナントを接続するエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、既存のAzure AI資産（Foundry Models・Foundry Tools・独自Azure MLモデル）を、Teams上で動く業務エージェントとして公開できるように設計されており、自社テナント内で完結するセキュリティ設計を前提としています。

AI総合研究所の専任チームが、Azure環境の棚卸しから業務エージェント設計・運用まで伴走します。AI Agent Hubのサービスページで、自社の業務にどう接続できるかを具体例と合わせてご確認ください。

---

まとめ

本記事では、2026年時点の「Azureで使えるAIサービス」の全体像を、Microsoft Foundryリブランドを反映して解説しました。要点を改めて整理します。

• Azureで使えるAIサービスは、Microsoft Foundry傘下の4層（Foundry Models・Foundry Agent Service・Foundry IQ・Foundry Tools）＋ Foundry Control Plane ＋ 独立サービスのAzure Machine Learningで整理される
  
  

• 旧「Azure AI Services（さらに旧Cognitive Services）」は「Foundry Tools」へ呼称変更され、Vision・Speech・Language・Document Intelligenceなど組み込みAI 10種と、廃止予定6種として公式に再整理された
  
  

• Foundry Modelsは1,900モデルを超えるカタログで、GPT-5.5（2026年4月GA）・Claude Opus 4.6（2026年6月Foundry GA）・Grok 4・Llama・Mistral・DeepSeek・Phi-4を1エンドポイントで呼び分けられる
  
  

• 料金は 従量課金・PTU・リザーブド・Free Tier F0の4体系。PoCは無料枠から、本番運用は従量課金→PTU/リザーブドへの段階移行が定石で、Japan Eastでは 主要Foundry ToolsとOpenAI系モデルが利用可能（Claude等の他社モデルはUS・EU系リージョン中心）
  
  

• 企業導入メリットはMicrosoft 365との親和性・エンプラガバナンス・日本リージョン対応・1,900モデルの選択自由度・既存Azure資産との統合の5点で、大塚製薬工場・SoftBankをはじめとする日本エンプラでも本番運用が公表されている

2026年時点でAzureにAIを載せるなら、旧Cognitive Services時代の個別API発想から、Foundryの4層＋Azure MLを組み合わせる発想へと設計視点を切り替えることが第一歩になります。次のステップとして、業務要件を書き出して先ほどの選び方の表と照らし合わせ、まずはFoundry ToolsのF0無料枠、またはAzure OpenAIの従量課金でPoCから着手するのが実務的な着地点です。