TL

Cloud Service

Azure AI Foundry

生成 AI アプリとエージェントの開発・評価・運用を1つの統合プラットフォームに集約し、モデル選定から本番運用までを一貫して進められる。AWS なら Amazon Bedrock の周辺ツール群に相当。

中級運用上の優秀性セキュリティパフォーマンス効率
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.多数の基盤モデルを比較・デプロイし、生成 AI アプリやエージェントを構築する統合プラットフォーム。
  • 2.プロジェクト単位で開発資産をまとめ、評価・コンテンツ安全・監視まで一体で扱える。
  • 3.ポータル(旧 AI Studio)と SDK の両方から操作でき、Azure のガバナンスに統合される。

解決する課題

生成 AI のアプリやエージェントを作るには、モデルの選定・プロンプト設計・データ連携(RAG)・評価・安全対策・監視・デプロイと、多くの工程をまたぐ必要があります。これらを個別のツールで継ぎ接ぎすると、開発が分断され運用が複雑になります。Azure AI Foundry は、これらを1つの統合プラットフォームにまとめ、試作から本番運用までを一貫した枠組みで進められるようにします。

  • 数多くの基盤モデルを横断的に比較・試用し、用途に合うモデルを選びたい
  • プロンプト・データ・評価・デプロイなどの開発資産を1か所に集約して管理したい
  • 生成 AI アプリの**品質を評価し、安全性(有害出力やインジェクション対策)**を組み込みたい
  • 単発の推論だけでなく、ツールを使うエージェントを構築・運用したい
  • 開発から本番まで、Azure の認証・ネットワーク・監視のガバナンスに統合したい

主要概念と用語

  • Azure AI Foundry ポータル: モデル探索・プロジェクト管理・評価・デプロイを行う Web 体験(旧称 Azure AI Studio)
  • プロジェクト(Project): 生成 AI 開発の作業単位。モデルのデプロイ、データ、評価、エージェントなどの資産をまとめる入れ物
  • モデルカタログ(Model Catalog): OpenAI 系をはじめ、各社・オープンソースの多数の基盤モデルを探索・比較・デプロイできる一覧
  • デプロイ(Deployment): 特定モデルを呼び出せる状態にしたエンドポイント。アプリはデプロイ名を指定して推論する
  • Agent Service: モデルにツール呼び出しや知識検索を組み合わせ、自律的に動くエージェントを構築・ホストする機能
  • 評価(Evaluation): 生成結果の品質(関連性・正確性・根拠性など)や安全性を、データセットや指標で測定する仕組み
  • コンテンツ安全(Content Safety): 有害な入出力やプロンプトインジェクションを検出・抑制する安全機構
  • 接続(Connection): Azure AI Search やストレージなど外部リソースへの認証情報をまとめた参照。RAG などで再利用する
  • SDK / ポータルの両対応: 同じプロジェクト資産を、ポータルからもコード(SDK)からも扱える

仕様・制限・クォータ

  • 利用できるモデルや機能はリージョンによって異なる: モデルカタログの提供状況やエージェント機能の対応はリージョン依存で、設計初期に確認が必要
  • モデルのクォータはトークン毎分やリクエスト毎分として割り当てられ、超過時はスロットリングされる
  • デプロイの課金方式は複数: 従量(トークン課金)型と、スループットを事前確保するプロビジョニング型などをモデルに応じて選ぶ
  • プロジェクトはハブ(共有設定)に紐づく構成があり、ネットワークやストレージなどの基盤設定をプロジェクト間で共有できる
  • 一部のモデルや機能は申請・承認やプレビュー扱いの場合がある(提供条件は変動するため最新情報を要確認)
  • 具体的なクォータ上限やリージョン対応は時期によって変わるため、最新値は公式ドキュメントで確認すること
リージョン差とプレビューに注意

使いたいモデルやエージェント機能が、目的のリージョンで提供されているとは限りません。プレビュー段階の機能は仕様が変わり得ます。設計初期に提供リージョン・クォータ・提供段階を確認してください。

内部の仕組み

Azure AI Foundry は、プロジェクトを中心に開発資産を束ねます。モデルカタログから選んだモデルをデプロイとして登録すると、固有のエンドポイントとデプロイ名が得られ、アプリは REST または各言語の SDK でそれを呼び出します。OpenAI 系モデルは Azure OpenAI の実行基盤を、他のモデルはそれぞれのホスティング方式(サーバーレス API や専用コンピュートなど)を通じて推論されます。

データ連携が必要な場合は、接続を介して Azure AI Search などをプロジェクトに紐づけ、RAG の検索層として使います。エージェントを構築する場合は Agent Service がモデルとツール(関数呼び出し、知識検索など)をオーケストレーションし、対話のスレッドや実行状態を管理します。入出力にはコンテンツ安全のチェックが入り、認証は API キーに加えて Microsoft Entra ID(旧 Azure AD)とマネージド ID が使え、ネットワークはプライベート接続で閉域化できます。

設計パターン / ベストプラクティス

  • モデル選定をカタログで体系化: 用途・コスト・レイテンシの観点でモデルを比較し、軽量モデルと高性能モデルを使い分ける
  • RAG を基本に据える: モデルの内部知識に頼らず、接続経由で Azure AI Search などから根拠を検索して渡し、正確性と更新性を確保する
  • 評価を開発に組み込む: プロンプトやモデルを変えるたびに評価を回し、関連性・根拠性・安全性の指標で回帰を検知する
  • デプロイ名を抽象化: アプリ側はデプロイ名を設定値として持ち、モデル更新時の差し替えを容易にする
  • エージェントはツールを最小権限で: エージェントが呼ぶ外部ツールやデータには必要最小限の権限を与え、暴走時の影響を限定する
  • 環境を分離: 開発・検証・本番でプロジェクトやデプロイを分け、設定をコード(IaC)で再現できるようにする
まず評価の土台を作る

生成 AI は変更の影響が見えにくいため、評価データセットと指標を先に整えておくと、モデルやプロンプトの改善を客観的に比較できます。勘に頼らない改善サイクルの起点になります。

運用・監視

  • メトリクスとログ: 呼び出し数、レイテンシ、トークン使用量、エラー率などを Azure Monitor で監視する
  • 診断ログ: リクエストやコンテンツ安全の挙動を診断設定でログ出力し、Log Analytics に集約する
  • クォータ監視: スロットリングの兆候を捉え、必要に応じてクォータ引き上げやプロビジョニング型への移行を検討する
  • 品質の継続評価: 本番のやり取りをサンプリングし、評価で品質や安全性の劣化を継続的に確認する
  • モデルのバージョン管理: モデルは更新・廃止されるため、サポート期限を追い、移行計画を持つ
  • コスト可視化: トークン使用量をプロジェクトや機能単位で集計し、想定外の急増を検知する

コスト

Azure AI Foundry のプラットフォーム自体ではなく、実際に使ったモデル推論や関連リソースに対して課金されるのが基本です。費用の中心はモデル推論で、入力トークンと出力トークンの合計に応じて増えます。性能の高いモデルほど単価が高い傾向があるため、用途に合った最小限のモデルを選ぶと無駄が減ります。

  • 推論は基本的にトークン量に応じた従量課金で、出力が長いほどコストが増える
  • 安定して高負荷をかける場合は、**スループット確保型(プロビジョニング)**の方が予測しやすいことがある
  • RAG で使う Azure AI Search やストレージなどの周辺リソースは別途課金される
  • 評価やコンテンツ安全など一部機能も利用量に応じてコストが発生し得る
  • 具体的な単価は変動するため、断定せず公式の料金ページで最新値を確認すること

セキュリティ

  • 認証: API キーに加え、Entra ID とマネージド ID を使ったキーレス認証で資格情報の漏えいリスクを下げる
  • ネットワーク: プライベートエンドポイントで閉域化し、パブリックアクセスを制限する
  • 権限管理: ロールベースアクセス制御で、プロジェクトやデプロイへのアクセスに最小権限を割り当てる
  • データ保護: 送受信データは暗号化され、カスタマーマネージドキーによる管理にも対応する
  • コンテンツ安全性: コンテンツ安全で有害な入出力を抑制し、プロンプトインジェクション対策を設計に含める
  • 入力検証: 外部から取り込んだテキストをそのままプロンプトに連結せず、信頼できないデータと指示を分離する
プロンプトインジェクション

外部データやエージェントが参照する文書には、モデルの指示を上書きしようとする攻撃が含まれ得ます。信頼できないデータと指示を分離し、エージェントの出力を実行系やツール呼び出しに無検証で直結させない設計を徹底してください。

関連サービス・比較

Azure AI Foundry は Azure OpenAI Service と密接に関係します。Azure OpenAI が「GPT 系モデルをマネージド API として呼び出す」ことに焦点を当てるのに対し、Azure AI Foundry は多数のモデルを横断し、評価・エージェント・安全・監視まで含めた開発プラットフォームとして位置づけられます。

観点Azure AI FoundryAzure OpenAI Service
立ち位置生成 AI 開発の統合プラットフォームGPT 系モデルのマネージド API
扱うモデル多数のベンダー・OSS を横断主に OpenAI 系
主な機能モデル比較・評価・エージェント・監視推論 API と埋め込み
操作方法ポータルと SDKREST と SDK
認証Entra ID とキーEntra ID とキー
AWS との対応

AWS で基盤モデルをマネージドに使う入口は Amazon Bedrock です。Azure AI Foundry は、その Bedrock とエージェントや評価などの周辺ツール群をまとめた開発体験に近い立ち位置です。どちらもモデル本体を運用せず、検索連携で RAG を組み、クラウドの認証・ネットワーク・監視に統合される流れは共通します。

ハンズオン / CLI例

# リソースグループを作成
az group create --name foundry-rg --location eastus

# Azure AI Foundry(AI Services)リソースを作成
az cognitiveservices account create \
  --name my-foundry \
  --resource-group foundry-rg \
  --kind AIServices \
  --sku S0 \
  --location eastus

# モデルをデプロイとして登録(モデル名やバージョンは提供状況に合わせる)
az cognitiveservices account deployment create \
  --name my-foundry \
  --resource-group foundry-rg \
  --deployment-name chat-model \
  --model-name gpt-4o \
  --model-version "2024-08-06" \
  --model-format OpenAI \
  --sku-name Standard \
  --sku-capacity 1

# エンドポイントを確認してアプリから利用する
az cognitiveservices account show \
  --name my-foundry --resource-group foundry-rg \
  --query "properties.endpoint" -o tsv

Azure Service

Azure AI Foundryを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

AI / 機械学習

比較で見る軸

クラウド: Azure / カテゴリ: AI / 機械学習 / 難易度: intermediate

導入後に効く点

プロジェクト単位で開発資産をまとめ、評価・コンテンツ安全・監視まで一体で扱える。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
AI / 機械学習
難易度
intermediate
関連資格
設計柱
operational / security / performance

判断チェックリスト

  • 自社の用途が「AI / 機械学習 / operational」に近いか確認する。
  • 強みである「多数の基盤モデルを比較・デプロイし、生成 AI アプリやエージェントを構築する統合プラットフォーム。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

AI / 機械学習operationalsecurityperformance