Microsoft Foundry Agent Service とは｜AIエージェントを業務で動かすための基盤

Microsoft Foundry Agent Service は、AIエージェントの実行、ツールへの接続、権限、監視、バージョン管理までをまとめて引き受けるマネージドのエージェント基盤です。

本記事では、Microsoft Learn の一次情報をもとに、3つの作り方、ツールと権限の考え方、データの置き場所と日本リージョンの対応状況、そして費用の考え方を解説します。

AIエージェントは、試しに動かすだけなら短時間で作れます。難しいのはその先で、「どの権限で動かすか」「会話や文書をどこに保存するか」「何をしたかを後から追えるか」といった、業務に載せるための土台づくりです。本記事は、その土台をプラットフォーム側がどこまで引き受けてくれるのかを整理します。エージェントの企画段階の考え方は「企業におけるAIエージェント活用の始め方」で解説しています。

株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。

Foundry Agent Service とは｜まず名称の整理から

Microsoftの説明では、Foundry Agent Service は「AIエージェントを構築・デプロイ・スケーリングするためのマネージドプラットフォーム」と定義されています。任意のフレームワークと、モデルカタログの対応モデルを使い、モデルの推論とツールへの入口をひとつにまとめる、という位置づけです。

まず押さえておきたいのが名称です。Microsoft 公式ブログには「Azure AI Foundry is now Microsoft Foundry」と明記されており、Microsoft Ignite 2025 にあわせて Azure AI Foundry から Microsoft Foundry へ名称が変わりました。ポータルの画面とアイコンも刷新されています。これに伴い、エージェント機能の名称も「Azure AI Foundry Agent Service」から「Microsoft Foundry Agent Service」になりました。

この記事でも、以降は現行の呼び方である「Foundry Agent Service」で統一します。検索で見つかる日本語の解説記事には旧名称のものが多く残っていますが、指しているサービスは同じものです。

一般提供されている部分と、プレビューの部分

公式ドキュメントには「Foundry Agent Service は一般提供（GA）です。一部のサブ機能はパブリックプレビューであり、制約が異なる場合があります」と記載されています。エージェントを作って動かす中核の部分は正式提供で、周辺の新しい機能にプレビューのものが混ざっている、という状態です。

2026年9月時点でプレビューと明記されている主な機能は、スキル、ツール検索、エージェントオプティマイザー、メモリ、ブラウザーの自動化、コンピューターの使用、イメージの生成、SharePoint・Fabric のコネクタ、Fabric IQ、Work IQ などです。エージェント間連携のプロトコルは、v1.0 が一般提供、v0.3 がプレビューという状態にあります。本番の業務に組み込む機能がどちらに属するかは、設計の初期に必ず確認しておきたい点です。

モデルを呼ぶことと、エージェントを運用することは別物

生成AIのAPIを呼び出して回答を得るだけなら、数十行のコードで実現できます。ところが、それを社内の業務として運用しようとすると、モデルの性能とは別の課題が次々に出てきます。

運用で出てくる課題	自前で作る場合に起きること	Agent Service が引き受ける部分
エージェントの権限	アプリの資格情報を使い回すことになり、どのエージェントが何にアクセスできるかが曖昧になる	エージェントごとに専用の Microsoft Entra ID を持たせ、リソースやAPIへのアクセス範囲を絞れる
ツールへの接続	接続先ごとに認証方式と資格情報が増え、エージェントの数だけ設定が重複する	ツールをひとつのマネージドエンドポイントにまとめ、認証と権限を一元化する
何をしたかの記録	ログの設計を自分で行う必要があり、判断の経緯を後から追えないことがある	モデルの呼び出し、ツールの実行、判断の経過を追跡する仕組みが組み込まれている
変更とやり直し	指示文を書き換えると前の状態に戻せず、品質が落ちた原因を特定しにくい	変更するたびにバージョンが記録され、以前のバージョンへ戻したり差分を比べたりできる
ネットワークの境界	閉じたネットワークの中で動かす構成を、自分で設計・維持する必要がある	仮想ネットワーク内での実行に対応し、自社の仮想ネットワークを持ち込める

Agent Service の価値は、モデルの賢さではなく、この「運用の土台」をプラットフォーム側が持っている点にあります。逆に言えば、単発の要約や分類のようにエージェントの形をとる必要がない用途であれば、モデルのAPIを直接呼ぶほうが簡単で費用も抑えられます。

3つの作り方｜どこまでを任せるかで選ぶ

Foundry では、エージェントの作り方が3つ用意されています。違いは機能の優劣ではなく、どこまでをプラットフォームに任せ、どこからを自分で持つかです。

プロンプトエージェント｜設定だけで動かす

指示文、使うモデル、持たせるツールを設定するだけで、あとは Foundry がエージェントを実行します。保守するアプリケーションのコードはなく、コンテナーの管理も必要ありません。ポータルの画面で対話的に作る方法と、SDK や REST API で定義して配置の手順に組み込む方法があり、後者ならソースコードとして変更履歴を残せます。最初の1体はここから始めるのが公式の推奨です。

ホステッドエージェント｜自分のコードを預ける

Microsoft Agent Framework、LangGraph、OpenAI Agents SDK、Anthropic Agent SDK、GitHub Copilot SDK、あるいは独自のコードで書いたエージェントを、コンテナーイメージまたはソースコードの.zipファイルとして渡します。.zipで渡した場合はイメージのビルドも Foundry が行います。実行時には、マネージドのエンドポイント、自動スケール、エージェント専用の Microsoft Entra ID、セッション単位の状態の保持、追跡の仕組みが付きます。

自社独自の処理を呼び出すエージェントや、複数のエージェントを組み合わせる構成に向いた方式です。コンテナーの基盤を自前で用意せずに、処理の中身だけを自分で持てる点が要点になります。

Responses API を直接呼ぶ｜アプリの中に置く

自分のアプリのコードから Responses API を直接呼び出す方式です。指示・ツール・モデルといったエージェントの定義がアプリのコードの中にあり、Foundry 側には作成も更新も削除もするエージェントがありません。この形でも、モデルカタログのモデル、プラットフォームのツール、プロジェクトに紐づくデータ、利用者本人の権限で外部にアクセスする認証方式、プロジェクト単位の追跡と統制は引き続き利用できます。エージェントの定義をアプリの変更履歴と一緒に管理したい場合に向きます。

ツールとツールボックス｜認証と権限を1か所に集める

エージェントが実際の仕事をするには、外部に働きかける手段が要ります。それが「ツール」です。Foundry には、Web検索、ファイル検索、コードインタープリター、Azure AI Search などが組み込みで用意されており、さらに自社の関数、OpenAPI仕様で記述したREST API、MCPサーバーを追加できます。

主なツール	ツールボックスに入れる	エージェントに直接付ける
MCPサーバー、Web検索、Azure AI Search、コードインタープリター、ファイル検索、OpenAPI、エージェント間連携、ブラウザーの自動化	できる	できる
ツール検索、スキル、リマインダー	できる	できない
関数呼び出し、Bingによる根拠づけ、コンピューターの使用、イメージの生成、SharePoint、Azure Functions	できない	できる

ここで押さえておきたいのが「ツールボックス」という考え方です。エージェントが増えるほど、同じツールを何度も設定し直し、資格情報が複製され、誰がどのツールを使っているかが見えなくなっていきます。ツールボックスは、一度まとめたツール群をひとつのマネージドMCPエンドポイントの背後に公開する仕組みで、認証・統制・バージョン管理を1か所に集めます。

• エージェントのコードを変えずにツールを差し替えられる
  エージェントは同じエンドポイントに接続し続け、管理者側がツールの構成を更新します。新しいバージョンを作ってテストし、準備ができたら既定に昇格させます。
• 認証方式を選べる
  キーによる認証、Microsoft Entra（エージェントまたはプロジェクトのマネージドID）、利用者本人の権限を引き継ぐ方式、必要に応じた認証なしのアクセスに対応しています。
• Foundry の外のエージェントからも使える
  MCPに対応したランタイムであれば、Agent Framework や LangGraph で作った独自のエージェントからも同じツールボックスを利用できます。

ツールが数十、数百と増えると、すべてのツール定義を毎回モデルに渡すこと自体が負担になります。入力トークンが増えて費用がかさみ、会話の履歴や社内文書と限られたコンテキストを奪い合い、似たツールの中から誤ったものを選ぶ確率も上がります。この問題に対しては「ツール検索」（プレビュー）が用意されており、ツールを既定では隠し、必要なものを探す機能と呼び出す機能の2つだけを公開する形になります。重要なツールは常に見える状態に固定しておけます。

企業で使うための土台｜権限・ネットワーク・安全性

Agent Service には、企業で運用するための仕組みが標準で組み込まれています。ここが、モデルのAPIを自前で束ねる構成との最大の違いです。

• エージェントID
  各エージェントが専用の Microsoft Entra ID を持てます。資格情報を共有せずに、必要なリソースとAPIだけにアクセスさせられます。外部のMCPサーバーに対する認証にも使え、利用者本人の権限を引き継ぐ方式にも対応します。エージェントに権限をどう与えるかの考え方は「AIエージェントに「権限」をどう与え、統制するか」で詳しく解説しています。
• ロールに基づくアクセス制御
  Microsoft Entra と Azure のロールで、エージェントを作れる人、呼び出せる人、管理できる人を分けられます。
• プライベートネットワーク
  仮想ネットワークの中でエージェントを動かせます。プロンプトエージェントで利用でき、ホステッドエージェントは自社の仮想ネットワークを持ち込めます。この場合、セッションごとに仮想マシンで分離されたサンドボックスが、自社の仮想ネットワークに接続された状態で実行されます。
• コンテンツの安全性
  組み込みのフィルターが、指示の乗っ取り（プロンプトインジェクション）のリスクを下げます。参照した文書や検索結果の中に悪意ある指示が仕込まれる「クロスプロンプトインジェクション」への対策も含まれます。外部の文書を読ませるエージェントほど、この論点は重くなります。

作ったエージェントを、どこに届けるか

エージェントは、変更のたびにバージョンが自動で記録され、以前のバージョンへ戻したり差分を比べたりできます。安定したエンドポイントを持つマネージドリソースへ昇格させたうえで、Microsoft Teams や Microsoft 365 Copilot、Entra エージェントレジストリを通じて配布できます。利用者にとっては、新しい画面を覚えるのではなく、普段使っている Teams の中にエージェントが現れる形になります。エージェント同士が互いを呼び出す連携のプロトコルにも対応しています。

データはどこに置かれるか｜日本リージョンでの利用

業務で使ううえで避けて通れないのが、エージェントが扱うファイルや会話の履歴がどこに保存されるかです。Foundry Agent Service では、セットアップの選び方で保存先が変わります。

データの種類	Basic セットアップ（既定）	Standard セットアップ
ファイル、アップロード、添付	Microsoft 管理のストレージ	Azure Storage（Blob Storage）
ベクターストア、埋め込み、検索用の索引	Microsoft 管理のベクター検索	Azure AI Search
スレッド、会話履歴、メッセージ、エージェントの定義	Microsoft 管理のストレージ	Azure Cosmos DB

Basic は既定の構成で、論理的に分離された Microsoft 管理のストレージに保存されます。設定するものが少なく、すぐに始められます。Standard は、自社のサブスクリプションにある専用のAzureリソースに保存する構成で、Microsoftの説明では「データの所在とアクセスを完全に制御できる」とされています。データの置き場所を自社で管理したい場合は、こちらを選ぶことになります。

また、エンドポイントはリージョン単位で、データはエンドポイントと同じリージョンに保存されます。どのリージョンにエンドポイントを置くかが、そのままデータの所在地の判断になります。

東日本・西日本リージョンの対応状況

公式のリージョン対応表では、東日本（Japan East）と西日本（Japan West）のいずれも、Responses API、エージェント、プライベート仮想ネットワークのすべてに対応しています。ツールの対応にはリージョン差があり、東日本はコンピューターの使用を除くほぼすべてのツールが利用でき、西日本はブラウザーの自動化が対象外です。また、Bingによる根拠づけに対応するリージョンには東日本が含まれます。ホステッドエージェントの同時セッション数の既定上限も、東日本は上位の区分に入っています。

ひとつ注意したいのは、エージェントが日本リージョンで動くことと、使いたいモデルが日本リージョンで使えることは別の話だという点です。公式にも「一部の Azure OpenAI モデルはすべてのリージョンで利用できるわけではない」と明記されています。海外リージョンでしか提供されていないモデルを選ぶと、エージェントの基盤は日本にあっても推論は国外で行われます。データの取り扱いに要件がある場合は、リージョンの対応表とモデルの提供状況を分けて確認してください。

Copilot Studio との使い分け

「Copilot Studio があるのに、なぜ Foundry も必要なのか」という質問をよくいただきます。Microsoft のクラウド導入フレームワークでは、この2つを対立するものとしてではなく、組織でエージェントを作るための2つのプラットフォームとして並べて説明しています。どちらか一方を選ぶというより、作り手と要件によって主役が変わる、という整理です。

観点	Copilot Studio	Foundry Agent Service
主な作り手	業務部門やシステム担当者。画面の操作が中心	開発者。コードと配置の手順に組み込む
得意なこと	Microsoft 365 の中で使うエージェント。既成のコネクタで社内システムにつなぐ	独自の処理や複数エージェントの連携。モデルを選んで載せ替える
データの置き場所	Microsoft 365 と Power Platform の枠組みに従う	自社のAzureリソースに保存する構成を選べる
ネットワーク	標準的な構成で利用する	仮想ネットワーク内での実行に対応
利用者への届け方	Teams や Microsoft 365 Copilot に組み込む	自社アプリに組み込むほか、Teams や Microsoft 365 Copilot へも公開できる

公式ガイドは、マネージドの仕組みとコード優先のフレームワークの違いについて「マネージドのオーケストレーションはデプロイが速く、セキュリティが組み込まれている一方でカスタマイズは制限される。コード優先のフレームワークはきめ細かな制御ができる一方で、相応のエンジニアリング投資と継続的な保守が必要になる」と率直に述べています。制御の自由度と、維持の手間は引き換えの関係にあります。

実務では、社内の問い合わせ対応のように Microsoft 365 の中で完結する用途は Copilot Studio、基幹システムと連携して独自の処理を動かす用途は Foundry、という分担が現実的です。両者をつなぐ経路も用意されており、Copilot Studio 側から Foundry のエージェントに接続することもできます。社内文書を参照させる場合の権限と出典の扱いは「社内文書をAIエージェントで活かす｜RAGの肝は権限と出典」で詳しく解説しています。

費用と上限｜専用の料金ページが無い理由

Foundry の料金を調べようとすると、専用の価格ページが見つかりません。これは意図的なもので、公式ドキュメントには「Foundry は任意のAzureサービスの組み合わせで構成されるため、料金計算ツールに専用のページがない」と説明されています。つまり、使った下位サービスの合算が Foundry の費用です。

費用の要素	かかり方	対象
モデルの推論	トークン単位。入力と出力で単価が分かれる。デプロイの種類によって単価と処理される場所が変わる	すべての作り方
ツールの使用	使ったツールごとの利用料	すべての作り方
コンテナーの実行	セッションと要求の量に応じてコンテナーが増減する	ホステッドエージェントのみ
保存先のリソース	ストレージ、Azure AI Search、Azure Cosmos DB の各利用料	Standard セットアップの場合

部門ごとの按分については、すべての Foundry プロジェクトに識別用のタグが自動で付与されるため、コスト管理の画面でプロジェクト単位に費用を分けて見られます（この機能はプレビューです）。手動でタグを付ける必要はありません。なお、ポータルに表示される推定コストにはプロンプトエージェントの費用が含まれないという注記があるため、請求額の確認はコスト管理の実績値で行うのが確実です。

設計時に知っておきたい上限

サービス側に固定の上限があり、これらはサポートへ依頼しても引き上げられません。設計の段階で収まる形にしておく必要があります。

項目	既定の上限
エージェント／スレッドあたりのファイル数	10,000
アップロードできる1ファイルのサイズ	512 MB
スレッドあたりのメッセージ数	100,000
エージェントに登録できるツール数	128
エージェントあたりのバージョン数	1,000

一方、モデルのクォータと、ホステッドエージェントの同時セッション数は引き上げを依頼できます。会話が長くなる用途ではスレッドを分ける設計にする、ツールは必要なものだけ登録する、使わなくなったバージョンは配置の手順の中で整理する、といった運用を前提に組み立てておくと安心です。

弊社の支援｜用途の見極めから、権限とデータの設計まで

弊社は Microsoft 365・Azure の導入支援と、AIの業務活用の支援を行っています。弊社自身も、音声AIの基盤などで Foundry のモデルを東日本リージョンで運用しており、リージョンやモデルの選定で実際に確認が必要になる点を、自社の運用を通じて把握しています。

• まず、エージェントにする必要があるかを見極める
  単発の要約や分類で足りる業務に、エージェントの仕組みは必要ありません。ツールを呼んで判断を重ねる必要がある業務かどうかから整理します。
• 作り方と、プラットフォームの組み合わせを選ぶ
  3つの作り方のどれが合うか、Copilot Studio と併用するかを、体制と要件から判断します。保守できる範囲を超えた構成は選びません。
• 権限とデータの置き場所を先に決める
  エージェントに与える権限の範囲、保存先を自社リソースにするか、ネットワークをどう閉じるかを、作り始める前に設計します。
• 小さく作って、実際の業務で測る
  1つの業務に絞って動かし、どこまで自動で進み、どこで人の確認が必要かを実測してから広げます。

検討の結果、いまの課題には Copilot Studio のほうが適している、あるいはエージェントではなく既存の仕組みの見直しで足りる、という結論になることもあります。その場合は、そのままお伝えします。サービスの詳細は「サービス一覧」を、お試しのお申し込みは「無料トライアル」をご覧ください。

よくあるご質問

こちらをクリックして「よくある質問」を表示

Azure AI Foundry Agent Service と Microsoft Foundry Agent Service は違うサービスですか？

同じサービスです。Microsoft Ignite 2025 にあわせて Azure AI Foundry が Microsoft Foundry へ名称変更され、エージェント機能の呼び方も変わりました。公式ドキュメントも新しい場所へ移っており、旧版は「classic」として併存しています。検索で見つかる旧名称の解説記事は、記述された時点の情報として読むとよいでしょう。

日本リージョンで使えますか？

使えます。公式のリージョン対応表では、東日本・西日本のいずれもエージェント、Responses API、プライベート仮想ネットワークに対応しています。データはエンドポイントと同じリージョンに保存されます。ただしツールの対応には差があり（東日本はコンピューターの使用が対象外、西日本はブラウザーの自動化が対象外）、使いたいモデルが日本リージョンで提供されているかは別途の確認が必要です。

Copilot Studio があれば、Foundry は必要ありませんか？

用途によります。Microsoft 365 の中で完結する問い合わせ対応などは Copilot Studio が適しています。基幹システムと連携して独自の処理を動かす、モデルを選んで載せ替える、仮想ネットワークの中で動かす、といった要件が出てくると Foundry が候補になります。Microsoftの公式ガイドも両者を併用する前提で書かれており、Copilot Studio から Foundry のエージェントに接続することもできます。

料金はどのように決まりますか？

Foundry 専用の料金ページはなく、使った下位サービスの合算になります。内訳は、モデルの推論（トークン単位）、ツールの使用、ホステッドエージェントを使う場合のコンテナーの実行、Standard セットアップを選んだ場合のストレージ・Azure AI Search・Azure Cosmos DB です。プロジェクトごとにタグが自動で付くため、部門別の按分はコスト管理の画面で行えます。

LangGraph など、他のフレームワークで作ったエージェントも動かせますか？

動かせます。ホステッドエージェントは、Microsoft Agent Framework、LangGraph、OpenAI Agents SDK、Anthropic Agent SDK、GitHub Copilot SDK、独自のコードに対応しており、コンテナーイメージまたはソースコードの.zipファイルとして渡します。実行時にはマネージドのエンドポイント、自動スケール、エージェント専用の Microsoft Entra ID が付きます。また、ツールボックスはMCPに対応したランタイムから使えるため、Foundry の外で動かしているエージェントからツールだけを利用することもできます。

まず何から始めればよいですか？

公式の推奨はプロンプトエージェントです。指示文とモデル、ツールを設定するだけで動き、保守するコードもコンピュートもありません。プレイグラウンドで動作を確かめてから、アプリケーションに組み込む流れになります。業務に載せる段階では、権限の範囲とデータの保存先を先に決めておくと、後戻りが少なくなります。

AIエージェントの構成の選定や、権限とデータの置き場所の設計についてのご相談は、お問い合わせよりお気軽にご連絡ください。いまの業務に対してエージェントが適しているかの見極めから、一緒に整理いたします。

関連サービス・関連コラム

• 関連サービス：サービス一覧
• 関連コラム：企業におけるAIエージェント活用の始め方
• 関連コラム：AIエージェントに「権限」をどう与え、統制するか
• 関連コラム：社内文書をAIエージェントで活かす｜RAGの肝は権限と出典
• 関連コラム：増える社内『シャドーAI』を統制する
• 関連コラム：Azure AI Voice Live APIで「電話対応の自動化」を実現する
• 関連コラム：AI駆動開発を安全に始める｜GitHub Copilot × Azure で作る開発基盤

まずは無料トライアルで、効果をご確認ください

「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）や電話受注（AI-Voice）の自動化、Azure/Microsoft 365・DXのご相談まで、お気軽にどうぞ。