Microsoft Foundry Agent Service（旧Azure AI Agent Service）とは？主要機能や使い方、料金体系を解説！

Microsoft Foundry Agent Service（旧Azure AI Agent Service）は、2026年3月16日に次世代版が一般提供（GA）となったフルマネージドのAIエージェント開発プラットフォームです。
OpenAI Responses APIベースの新ランタイム、ノーコードのPromptエージェント、宣言型のWorkflowエージェント、コンテナベースのHostedエージェントという3つのエージェント種別を提供し、エンタープライズレベルのセキュリティと監視機能を標準で備えています。


Microsoft Foundry全体を対象としたForrester TEI調査では3年間でROI 327%、開発者生産性35%向上という成果が報告されており、Fujitsuは営業提案書の自動作成で67%の生産性向上を達成しています。
本記事では、主要機能からVoice Live API、Copilot Studioとの使い分け、Python実装例、料金体系、導入ステップまで2026年3月時点の最新情報で解説します。


✅Microsoft 365 Copilotの最新エージェント機能「Copilot Cowork」については、以下の記事をご覧ください。
Copilot Coworkとは？機能や料金、Claude Coworkとの違いを解説

Microsoft Foundry Agent Service（旧Azure AI Foundry Agent Service / Azure AI Agent Service）とは

Microsoft Foundry Agent Service は、AIエージェントの構築・デプロイ・スケーリングを一貫して支援するフルマネージドプラットフォームです。

Bing、SharePoint、Azure AI Search、Microsoft Fabricなどの多様なデータソースや、Azure Logic Apps、Azure Functionsなどの外部サービスとシームレスに連携可能です。

https://youtu.be/dMEwpthSuhU

エンタープライズレベルのセキュリティ機能（End-to-End Private Networking、Microsoft Entra ID RBAC、エージェント専用ID）を標準搭載しており、組織のデータプライバシーとコンプライアンス要件を満たしながら、様々なビジネスプロセスの自動化を実現します。

Forrester TEI調査（2026年2月）では、Microsoft Foundry全体の導入企業で3年間ROIが327%、開発者生産性が最大35%向上したと報告されています（Agent Service単体の数値ではなく、Foundryプラットフォーム全体の効果です）。

【名称変更の歴史】製品名の変遷と2026年最新情報

Microsoft Foundry Agent Serviceは、その進化とともに名称を変更してきました。以下に名称変更の歴史をまとめます。

名称変更のタイムライン

2024年11月: Azure AI Foundry Agent Service（パブリックプレビュー開始）

2025年5月: Azure AI Foundry Agent Service（一般提供開始・GA）

• 名称変更自体はブランド刷新が主目的でしたが、以下の機能強化も同時にリリースされました。

2025年11月: Azure AI Foundry → Microsoft Foundry へ（Microsoft Ignite 2025発表）

2026年1月頃: Microsoft Foundry Agent Service に名称変更

• 「Azure」の名前を外し、Microsoftエコシステム全体への統合を強調

2026年3月16日: 次世代Foundry Agent ServiceがGA（一般提供）

• OpenAI Responses APIベースの新ランタイムに移行
• Prompt・Workflowエージェントが正式導入、Hostedエージェントはパブリックプレビュー
• End-to-End Private Networking、評価・Observability機能を同時発表
• Voice Live API（リアルタイム音声対話）がパブリックプレビュー開始

この名称変更と2026年3月GAは単なるリブランディングではなく、AIエージェントがAzureサービスの一つではなく、Microsoft全体のファーストクラス製品として位置づけられたことを意味します。エージェントは今や、Microsoft 365、GitHub、Dynamics 365など、あらゆるMicrosoft製品と深く統合される戦略的な存在です。

3つのエージェント種別（2026年3月）

　
2026年3月のGA版では、用途と開発スタイルに応じた3つのエージェント種別が導入されました（Hostedエージェントはパブリックプレビュー）。以下の表で、各種別の特性を整理しました。

この3種別がカバーする範囲は広く、ノーコードのPromptエージェントでPoC（概念実証）を数分で作成し、要件が複雑になればWorkflowやHostedに段階的に移行できます。AI総研の導入支援でも、まずPromptエージェントで社内FAQ対応の成果を可視化し、経営層の承認を得てからHostedエージェントに拡張するパターンが最も成功率が高いことが分かっています。

PromptエージェントはAzure AI Foundryポータルから直接作成でき、SDKやREST APIでもデプロイ可能です。HostedエージェントはMicrosoft Agent Framework、LangGraph、独自コードで構築し、コンテナとしてAgent Serviceにデプロイします。

2025年5月GA時の主な強化ポイント

名称変更と同時に、以下の機能が大幅に拡充されました。

• マルチエージェント・オーケストレーションの強化

  • Connected Agents エージェント間でのツール呼び出しやデータ受け渡しを可能にし、協調動作を実現します。
  • Multi-Agent Workflows 長時間実行やエラーからの復旧を含む、より複雑なワークフローの構築をサポートします。
  • Agent Catalog 事前に構築されたエージェントやテンプレートを利用可能にし、開発を迅速化します。
    
    

• Logic Apps／外部システム連携の大幅な拡充

  • 1,400以上のLogic Appsコネクタ これらに直接アクセス可能となり、多様な外部サービスとの連携が容易になります。
  • Azure Logic Appsからのエージェントトリガー Logic Appsのワークフローから直接Microsoft Foundry Agent Serviceのエージェントを起動できるようになりました。
  • Agent-to-Agent プロトコル マルチクラウド環境でのエージェント間連携を促進します。
    
    

• 開発者体験の向上とランタイム統合

  • Semantic Kernel／AutoGen ランタイム統合 ローカル開発からシミュレーション、クラウド展開までの一貫したパイプラインを提供し、単一APIでコードベースの動的オーケストレーションを実行可能です。
  • Foundry Visual Studio Code拡張機能 ローカル環境での開発、デバッグ、テストを効率化します。
  • Trace Agents エージェントの実行フローを詳細に追跡し、デバッグやパフォーマンス分析を支援します。
    
    

• エンタープライズ向けの信頼性・セキュリティ強化

  • SLAサポートとコンプライアンス対応 正式なSLAが提供され、各種コンプライアンス要件に対応します。
  • ガバナンス機能とコンテンツ・セーフティ 標準で搭載され、安全な運用を支援します。
  • Azure Monitorとの統合強化 エージェントの監視、ログ収集、アラート設定などがAzure Monitorを通じて行えるようになり、運用管理が向上します。
    
    

• 新しい組み込みツールの追加

  • Bing Custom Search ツール カスタマイズされたWeb検索結果をエージェントが利用できます。
  • Morningstar ツール 金融関連データへのアクセスを提供します。
  • Microsoft Fabric ツール Microsoft Fabric内のデータとの対話型アクセスを強化します。

Microsoft Foundry Agent Serviceと他サービスの比較

Microsoft Foundry Agent Serviceは、Microsoftが提供する唯一のエージェント開発プラットフォームではありません。用途やスキルセットに応じて、Assistants API、Copilot Studioとの使い分けが重要です。

Assistants APIとの違い

2026年3月のGA版はOpenAI Responses APIベースに移行しており、従来のAssistants APIとは異なるアーキテクチャです。以下の表で、両サービスの主な違いを整理しました。

ここで注目すべきは、Microsoft Foundry Agent Serviceは単なるエージェント構築ツールではなく、エンタープライズ全体のワークフローを統合するプラットフォームという点です。つまり、Assistants APIがAIモデルとの対話に特化しているのに対し、Microsoft Foundry Agent Serviceは、マルチエージェント協調、外部システム連携、イベント駆動実行、そしてエンタープライズセキュリティまで包括的にカバーしています。

そのため、プロトタイプや小規模な実験ではAssistants APIで十分ですが、本格的なエンタープライズ展開、複数部門をまたぐ業務自動化、コンプライアンス要件が厳しい環境では、Microsoft Foundry Agent Serviceが最適な選択肢と言えるでしょう。

【関連記事】
Azure AI services(旧Azure Cognitive Services)とは？その概要や料金を徹底解説

Copilot Studioとの使い分け

もう一つ混同されやすいのが、Microsoft Copilot Studioとの違いです。以下の表で、選定基準を整理しました。

実務で選ぶ際のポイントは、開発チームのスキルセットと統合先のエコシステムです。Microsoft 365中心の業務環境で市民開発者がエージェントを作る場合はCopilot Studioが適しています。一方、Azure上の独自アプリケーションに組み込む場合や、LangGraph・Semantic Kernelなどのフレームワークでカスタム制御が必要な場合はFoundry Agent Serviceが最適です。

両者は排他的ではなく、Copilot StudioのエージェントからFoundry Agent Serviceのエージェントを呼び出す連携パターンも可能です。

Microsoft Foundry Agent Serviceの主要機能

Microsoft Foundry Agent Serviceは、迅速なエージェント開発、広範なデータ統合、柔軟なモデル選択、そしてエンタープライズ対応機能を実現し、他のサービスとは一線を画しています。

以下では、これらの特徴について詳しく説明します。

Microsoft Foundry Agent Serviceの構成要素 (参考:Microsoft)

1. 迅速なエージェント開発と強力なAPI統合

Microsoft Foundry Agent Serviceは、OpenAIの「Assistants API」を基盤としつつ、Microsoft Foundry SDKやVS Code拡張機能などを通じて、より高度で効率的な開発環境を提供します。

さらに、Microsoft Foundry SDKを利用することで、開発者はPython, .NET, Java など、使い慣れた言語でAIエージェントを開発できます。
このSDKは、Microsoft Foundry Agent Serviceの機能を最大限に活用するための各種ツールやライブラリを提供し、より高度なカスタマイズや、他のAzureサービスとの連携を可能にします。

具体的には、以下のような強力な統合機能が利用できます。

Logic Appsコネクタ

1,400以上のAzure Logic Appsコネクタを利用することで、様々な外部サービスと連携したタスクを自動化できます。Azure Logic Appsからエージェントを直接トリガーすることも可能です。

例えば、以下のようなサービスとの連携が可能です。

• Microsoft製品
  Azure App Service、Dynamics 365 Customer Voice、Microsoft Teams、M365 Excel など
  
  

• 主要なエンタープライズサービス
  MongoDB、Dropbox、Jira、Gmail、Twilio、SAP、Stripe、ServiceNow など

これらのコネクタを使うことで、様々な業務プロセスをエージェントに自動で実行させることが可能です。

• 顧客情報をデータベースから取得する
• メールを自動送信する
• 承認ワークフローを開始する

【試算例】 カスタマーサポート部門で月間約5,000件の問い合わせがある場合、定型回答を自動処理に切り替えることで、オペレーター配置の最適化が期待できます。削減幅は自動化対象の範囲やFAQの整備状況に依存するため、まずパイロットで実測値を取得することを推奨します。

【関連記事】
Azure Logic Appsとは？主要機能や料金、設定手順をわかりやすく解説

Azure Functions

Azure FunctionsやAzure Durable Actionsと連携することで、外部システムとのやり取りを効率化できます。

APIの呼び出しや、非同期イベントの送受信を簡単に実装でき、以下のような処理を自動化できます。

• 請求書の自動承認処理
• 製品サプライチェーンのリアルタイム監視
• 顧客からの問い合わせに応じた動的な処理

Code Interpreter

安全な実行環境でPythonコードを記述・実行できるため、複雑なデータ処理や分析、グラフや図を用いたデータ可視化をエージェントに任せることができます。

• エージェントにデータ分析や数値計算をさせ、その結果をレポートにまとめる。
• 機械学習モデルを使って、データを分析する。
• 可視化ツールを利用し、分析結果をグラフで表示する。

OpenAPI仕様

OpenAPI 3.0仕様に対応したツールを利用して、外部APIと連携できます。
これにより、様々なアプリケーションと連携して、AIエージェントの活用範囲を大きく広げることができます。

• 天気予報APIを利用して、天気情報を取得する
• 翻訳APIを利用して、多言語対応のチャットボットを作る
• 地図APIを利用して、周辺の店舗情報を検索する

これらの強力な統合機能により、開発者はAIエージェントを迅速に開発し、様々なシステムやサービスと連携させ、ビジネスニーズに合わせた高度な自動化を実現できます。

2. ナレッジソースとの連携

Microsoft Foundry Agent Serviceで構築されたエージェントは、以下に示す様々なデータソースに安全にアクセスし、関連性の高いエンタープライズナレッジを最大限に活用できます。

対応データソース (参考:Microsoft

• リアルタイムWebデータ (Bing / Bing Custom Search tool)
  エージェントはBing検索およびBing Custom Search toolを利用して、インターネット上の最新情報やカスタマイズされた検索結果を取得し、それを基に応答を生成できます。
  
  
• 組織データ (SharePoint)
  組織内のSharePointに保存されたドキュメントやデータをエージェントが安全に利用できます。
  社内のみに公開された情報に基づいた、より専門的な応答やタスクの実行が可能です。
  
  
• 構造化データ (Microsoft Fabric) Microsoft Fabric内の構造化データ（データベースなど）に、Microsoft Fabric ツールを通じてSQLなどのクエリ言語の知識がなくても簡単にアクセスし、対話形式でデータに関する質問応答や分析が可能です。
  
  
• その他のデータソース
  Azure AI Search、Azure Blob Storage、ローカルファイルなど、様々なデータソースと連携できます。
  
  
• ライセンスデータ
  Tripadvisorなどのデータプロバイダーから提供されるライセンスデータを利用することで、エージェントの応答をさらに高品質なものにすることができます。

例えば、顧客からの問い合わせ対応を行うエージェントであれば、社内の製品データベースやFAQ、過去の顧客対応履歴などを参照して、より正確で適切な回答を提供できます。

また、市場調査を行うエージェントであれば、Bing Searchを通じてウェブ上の最新情報を収集し、分析レポートを作成することも可能です。

これらの機能により、エージェントは常に最新の情報と社内の知識を組み合わせ、より質の高い業務遂行をサポートします。特に社内ドキュメント検索の効率化は、多くの企業で最初に効果が出やすい領域です。

3. 柔軟なモデル選択

Microsoft Foundry Agent Serviceでは、タスクや要件に応じて最適なモデル選択が可能です。
具体的には、以下のような選択肢があります。

• Azure OpenAIのモデル
  Azure OpenAI Serviceを通じて、GPT-5シリーズ、GPT-4.1シリーズ、GPT-4oをはじめとする、OpenAIが提供する強力なモデル群を利用できます。

• 推論特化モデル
  o3-deep-research、o3-mini、o4-miniなど、高度な推論能力を持つ特化型モデルも利用可能です。

• オープンソースモデル
  「Llama 3.3」「Mistral」「Cohere」「DeepSeek-V3」「DeepSeek-R1」など、オープンソースコミュニティで開発されている高性能なモデルも利用可能です。

• Anthropic Claude
  Claude Opus 4.5、Claude Sonnet 4.5、Claude Haiku 4.5、Claude Opus 4.1など、Anthropic社の最先端モデルも選択できます。

この幅広い選択肢により、「特定のタスクや業界に特化したモデル」や、「コスト効率に優れたモデル」など、ビジネスニーズに最適なモデルを選ぶことができます。

例えば、特定の専門分野に特化した知識を持つエージェントを構築したい場合には、その分野のデータでファインチューニングされたモデルを選択できます。
また、推論コストを抑えたい場合には、軽量で高速なモデルを選択することも可能です。

さらに、テキストだけでなく画像や音声などのデータも扱えるマルチモーダル対応のエージェントを構築したい場合には、GPT-4oのように画像や音声の入出力に対応したモデルを選択することで実現できます。

4. エンタープライズグレードのセキュリティ機能

Microsoft Foundry Agent Serviceは、エンタープライズレベルのセキュリティ要件を満たすように設計されており、Azure Monitorとの連携による詳細な監査ログや監視機能も提供され、運用管理とセキュリティが強化されています。

安全なデータ処理、キーレス認証、パブリックエグレスなしといったセキュリティ対策により、機密データや個人情報の漏洩リスクを最小限に抑え、データのプライバシーとコンプライアンスを確保します。

• 安全なデータ処理
  エージェントとデータソース間の通信は暗号化され、データは安全に処理されます。機密性の高い情報も安心して扱えます。
  
  
• キーレスセットアップとOBO認証
  キーレスセットアップや代理認証(On-Behalf-Of)を活用することで、エージェントを簡単かつセキュアに構成・認証し、リソース管理とデプロイの複雑さを軽減します。
  
  
• ネットワークセキュリティ
  独自の仮想ネットワーク(Bring Your Own Virtual Network: BYOVN)を持ち込むことで、データトラフィックの公開を厳格に制御し、ネットワーク内の対話を安全に保つことが可能です。
  
  
• コンテンツフィルター
  事前構築済みのカスタムコンテンツフィルターにより、様々な重大度レベルで有害なコンテンツを検出し、企業ポリシーに沿った安全な運用を支援します。
  また、プロンプトシールドは、悪意のある攻撃者からのクロスプロンプトインジェクション攻撃からエージェントを保護します。
  
  

Microsoft Foundry Agent Serviceの先進ツール群（2026年3月最新）

Microsoft Foundry Agent Serviceは、2025年から2026年にかけて複数の革新的なツールを追加し、エージェントの能力範囲を大幅に拡張しました。以下の表で、これらの先進ツールの特性を整理しました。この表の説明を読んだ上で、次のセクションで各ツールの詳細と使用例を紹介します。

ここで注目すべきは、これらのツールが相互に連携することで、従来は複数のサービスやツールを組み合わせる必要があったワークフローを、単一のプラットフォーム内で完結できるという点です。例えば、Deep Researchで市場調査を実施し、その結果をBrowser Automationで自動的にWebフォームに入力し、Hosted Agentsでスケーラブルに実行する、といった一連のプロセスを統合的に管理できます。

つまり、開発工数の削減とともに、運用コストの最適化が同時に実現できるということです。

Deep Research：複雑な調査タスクの自動実行

Deep Researchは、OpenAIの「o3-deep-research」モデルを活用した高度な調査機能です。この機能により、エージェントは複数のソースから情報を収集し、分析し、包括的なレポートを自動生成できます。

主な特徴：

1. 多段階リサーチプロセス：最大20ステップの調査プランを自動生成し、段階的に情報を深掘りします
2. ソース多様性：Bing Search、SharePoint、Fabric、カスタムAPIなど複数のデータソースを横断検索します
3. 引用管理：収集した情報源を自動的に追跡し、レポートに引用情報を含めます

実装例：

from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential

# プロジェクトクライアントの初期化
project_client = AIProjectClient(
    credential=DefaultAzureCredential(),
    endpoint=os.environ["PROJECT_ENDPOINT"]
)

# Deep Researchエージェントの作成
agent = project_client.agents.create_agent(
    model="o3-deep-research",
    name="MarketResearchAgent",
    instructions="""あなたは市場調査の専門家です。
    指定されたテーマについて、複数のソースから情報を収集し、
    競合分析、市場規模、トレンド分析を含む包括的なレポートを作成してください。""",
    tools=[
        {"type": "bing_grounding"},
        {"type": "sharepoint"},
        {"type": "deep_research"}
    ]
)

# スレッドの作成と調査リクエスト
thread = project_client.agents.threads.create()
message = project_client.agents.messages.create(
    thread_id=thread.id,
    role="user",
    content="生成AIを活用したカスタマーサポート市場について、2026年の市場規模とトレンドを調査してください"
)

# エージェント実行
run = project_client.agents.runs.create_and_process(
    thread_id=thread.id,
    agent_id=agent.id
)

# 結果の取得
messages = project_client.agents.messages.list(thread_id=thread.id)
for msg in messages:
    if msg.role == "assistant":
        print(f"調査結果：\n{msg.content[0].text.value}")

このアプローチの利点は複数あります。

まず、人間のリサーチャーが数日かけて行う調査を、数時間で自動化できるという時間効率の向上です。通常、市場調査では複数のレポートサイト、業界誌、競合サイトを手動で巡回し、情報を収集・整理する必要がありますが、Deep Researchはこのプロセスを自動化します。

次に、調査の再現性と一貫性が担保されるという品質面でのメリットです。同じパラメータで実行すれば、常に同じソースから同じ基準で情報を収集するため、調査バイアスを最小化できます。

さらに、引用情報が自動的に管理されるため、コンプライアンス要件が厳しい業界（金融、医療、法律など）でも安心して利用できます。

【試算例】コスト比較（前提条件により変動します）

• 従来の人的リサーチ：シニアリサーチャー × 16時間/件
• Deep Research：o3-deep-researchモデル使用料 + Azure基盤費用
• 実行コストは調査の深さやソース数により変動するため、まず1件のパイロット実行で実測値を取得することを推奨します

Voice Live API：リアルタイム音声対話（プレビュー）

Voice Live APIは、2026年3月のGA発表と同時にパブリックプレビューが開始されたリアルタイム音声対話機能です。従来のターンベース（ユーザーが話し終わるのを待ってから応答する）方式ではなく、低レイテンシのストリーミング音声入出力により、人間同士の会話に近い自然なやり取りが可能になります。

Voice Live APIの主な特徴は以下の通りです。

• セマンティック音声アクティビティ検出
  ユーザーの発話意図を理解し、「えーと」などのフィラーワードと実際の質問を区別します。
  
  

• 割り込み対応
  ユーザーがエージェントの応答中に割り込んで話しかけた場合、エージェントは即座に応答を中断し、新しい入力に対応します。
  
  

• ノイズ抑制・エコーキャンセル
  周囲の騒音やスピーカーからの音声フィードバックを自動的に除去し、クリアな音声認識を維持します。
  
  

• Foundryエージェントとの統合
  テキストパイプラインと同じエバリュエーター・トレーシング機能を共有するため、音声エージェントの品質監視もFoundryの統合ダッシュボードで一元管理できます。

カスタマーサポートのコールセンター、フィールドサポートでのハンズフリー操作、店舗での接客応対など、音声インターフェースが求められるユースケースでは、Voice Live APIがエージェントの活用領域を大幅に広げます。

Hosted Agents：サーバーレスなエージェント実行基盤（パブリックプレビュー）

Hosted Agentsは、2026年3月時点でパブリックプレビューとして提供されているサーバーレスなエージェント実行環境です。開発者はインフラストラクチャの管理を最小限に抑えて、エージェントをデプロイし、スケーラブルに実行できます。マネージドランタイムの課金は2026年4月1日以降に開始予定ですが、デプロイ中はACR（Azure Container Registry）やApplication Insights等の関連Azureリソースの料金が発生します。

従来のアプローチとの違い：

主な特徴：

1. イベントドリブン実行：Azure Event Grid、Logic Apps、Power Automateからのトリガーに対応
2. 自動スケーリング：同時実行数を自動調整（デフォルト上限：10インスタンス/リージョン）
3. 状態管理：会話履歴とエージェント状態を自動的に永続化
4. 統合モニタリング：Application Insightsとの自動統合

実装例（イベントドリブンなカスタマーサポート）：

import os
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential

# プロジェクトクライアントの初期化
project_client = AIProjectClient(
    credential=DefaultAzureCredential(),
    endpoint=os.environ["PROJECT_ENDPOINT"]
)

# Hosted Agentで使用するエージェントの基本定義
# この後、HostedAgentDefinitionの構成とcreate_version()でデプロイする
agent = project_client.agents.create_agent(
    model="gpt-4.1",
    name="CustomerSupportAgent",
    instructions="""あなたはカスタマーサポート担当です。
    顧客からの問い合わせに対して、FAQデータベースと過去のチケット履歴を参照し、
    適切な回答を提供してください。解決できない場合は、人間のオペレーターにエスカレーションしてください。""",
    tools=[
        {"type": "azure_ai_search", "index_name": "faq-index"},
        {"type": "function", "function": {
            "name": "escalate_to_human",
            "description": "人間のオペレーターにエスカレーションする",
            "parameters": {
                "type": "object",
                "properties": {
                    "reason": {"type": "string", "description": "エスカレーション理由"},
                    "priority": {"type": "string", "enum": ["low", "medium", "high"]}
                }
            }
        }}
    ]
)

print(f"エージェント定義完了: {agent.id}")
# 実際のHosted Agentsデプロイには、この後HostedAgentDefinitionの
# 構成とcreate_version()が必要です（公式クイックスタート参照）

このアプローチの利点：

1. インフラ管理の大幅削減：コンテナ管理やオートスケール設定が不要になり、ビジネスロジックの開発に集中できます
2. 開発速度の向上：インフラ設計・構築・運用の工数が不要になり、エージェントの振る舞いに集中できます
3. スケーラビリティ：リクエスト数に応じた自動スケールにより、手動のキャパシティ管理が不要です

Anthropic Claude対応：OpenAI以外の選択肢

2026年1月、Microsoft Foundry Agent ServiceはAnthropic Claudeモデルのネイティブサポートを開始しました。これにより、開発者はOpenAIモデルとClaudeモデルを同じAPIインターフェースで使い分けることができます。2026年3月にはClaude Opus 4.6/Sonnet 4.6が追加され、選択肢がさらに広がっています。

以下の表は、2026年3月時点で利用可能なClaudeモデルの一覧です。ClaudeはAzure Marketplaceを通じたパートナーモデルとして提供されるため、料金はプロバイダー設定に準じます。最新の正確な料金はAzure Marketplaceで確認してください。

Claudeモデルの特徴：

1. 長文コンテキスト処理：Opus/Sonnet 4.6は最大1,000Kトークンのコンテキスト長をサポート
2. 指示追従性の高さ：複雑な指示や制約条件を正確に理解し実行
3. XML形式のサポート：構造化データの処理に優れる
4. 安全性重視：Constitutional AIによる有害コンテンツの生成抑制

実装例（Claude Opus 4.5を使った契約書分析エージェント）：

from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential

project_client = AIProjectClient(
    credential=DefaultAzureCredential(),
    endpoint=os.environ["PROJECT_ENDPOINT"]
)

# Claude Opus 4.5エージェントの作成
agent = project_client.agents.create_agent(
    model="claude-opus-4.5",  # Claudeモデルを指定
    name="ContractAnalysisAgent",
    instructions="""あなたは法務担当の専門家です。
    提供された契約書を分析し、以下の観点でレポートを作成してください：
    1. リスク条項の特定（解約条件、賠償責任、知的財産権など）
    2. 不利な条件の抽出
    3. 改善提案

    出力は必ずXML形式で、以下の構造に従ってください：
    <analysis>
      <risk_clauses>...</risk_clauses>
      <unfavorable_terms>...</unfavorable_terms>
      <recommendations>...</recommendations>
    </analysis>""",
    tools=[
        {"type": "file_search"}  # 契約書PDFの検索
    ]
)

# 契約書ファイルのアップロード
from azure.ai.agents.models import FilePurpose

with open("contract.pdf", "rb") as file:
    uploaded_file = project_client.agents.files.upload_and_poll(
        file=file,
        purpose=FilePurpose.AGENTS
    )

# 分析リクエスト
thread = project_client.agents.threads.create()
message = project_client.agents.messages.create(
    thread_id=thread.id,
    role="user",
    content="添付の契約書を分析してください",
    attachments=[{
        "file_id": uploaded_file.id,
        "tools": [{"type": "file_search"}]
    }]
)

run = project_client.agents.runs.create_and_process(
    thread_id=thread.id,
    agent_id=agent.id
)

# 結果取得
messages = project_client.agents.messages.list(thread_id=thread.id)
for msg in messages:
    if msg.role == "assistant":
        print(f"分析結果：\n{msg.content[0].text.value}")

このアプローチの利点：

1. モデル選択の柔軟性：タスクの性質やコスト要件に応じて、最適なモデルを選択できます
2. ベンダーロックイン回避：単一のモデルプロバイダーに依存しない、マルチベンダー戦略を実現できます
3. コスト最適化：長文処理タスクではClaudeの方がコスト効率が良い場合があります（例：200Kトークンの処理で約30-40%コスト削減）

実務的な使い分け：

• claude-opus-4-6：法務文書分析、学術論文要約、複雑な推論タスク
• gpt-4.1：コード生成、リアルタイム会話、マルチモーダル処理
• claude-haiku-4-5：大量データの分類、簡易な質疑応答
• gpt-5-nano：超高速応答が必要なチャットボット

Microsoft Foundry Agent Serviceで利用可能なモデルとリージョン（2026年3月最新）

Microsoft Foundry Agent Serviceは、2026年3月時点でOpenAI、Anthropic、Meta、DeepSeek、xAIなど多数のモデルプロバイダーをサポートしています。以下の表で、利用可能な主要モデルの特性を整理しました。

対応モデル一覧

モデルの選択はビジネス成果に直結します。カスタマーサポートでは応答速度が顧客満足度に影響するため、gpt-5-nanoやclaude-haiku-4-5が適しています。一方、契約書分析や市場調査では精度が重視されるため、claude-opus-4-6やo3が適切です。

つまり、同じエージェントアプリケーションでも、タスクに応じてモデルを動的に切り替えることで、品質とコストの両面で最適化できるということです。

利用可能なリージョン

Agent Serviceは複数のAzureリージョンで利用可能ですが、リージョンによって対応モデルやツール（File Search等）の可用性が異なります。日本の開発者にとってはJapan East（東日本） が最寄りリージョンとして利用可能です。

主要リージョン（Azure OpenAIモデル対応）：East US、East US 2、West US、West US 3、North Central US、South Central US、Australia East、Canada East、France Central、Japan East、Sweden Central、Switzerland North、UK South

リージョン選択の実務的考慮事項：

1. データレジデンシー要件：GDPRやブラジルLGPD等の法規制に準拠する必要がある場合、該当地域のリージョンを選択します
2. レイテンシ最適化：エンドユーザーに最も近いリージョンを選択することで、応答時間を短縮できます
3. ツール可用性：一部リージョンではFile Searchが利用できないなど、ツールの可用性に差があります。事前に公式ドキュメントで確認してください

Microsoft Foundry Agent Serviceの使い方

このセクションでは、Microsoft Foundry Agent Serviceを使った実践的な開発手順を、段階的に説明します。以下のステップで、基本的なエージェントから高度なマルチエージェントシステムまで構築できます。

ステップ1: Azure AI Foundryプロジェクトのセットアップ

前提条件：

• Azureサブスクリプション（無料試用版でも可）
• Azure CLI（バージョン2.50以上）
• Python 3.8以上（Python SDKを使用する場合）

プロジェクト作成手順：

# Azure CLIでログイン
az login

# リソースグループの作成
az group create --name rg-ai-agents --location eastus

# AI Foundryプロジェクトの作成
az ml workspace create \
  --name ai-agent-project \
  --resource-group rg-ai-agents \
  --location eastus \
  --kind project

Azure Portalでの確認：

1. Azure AI Foundryにアクセス
2. 作成したプロジェクトを選択
3. 「Settings」→「Properties」からエンドポイントURLをコピー（後で使用）

ステップ2: Python SDKのインストールと初期化

# Azure AI Projects SDKのインストール
pip install azure-ai-projects azure-identity

# 環境変数の設定（エンドポイントを使用）
export PROJECT_ENDPOINT="https://your-project.services.ai.azure.com"

基本的なクライアント初期化：

import os
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential

# プロジェクトクライアントの初期化
project_client = AIProjectClient(
    credential=DefaultAzureCredential(),
    endpoint=os.environ["PROJECT_ENDPOINT"]
)

print("プロジェクト接続成功！")

ステップ3: 最初のエージェントを作成する

シンプルな「製品推薦エージェント」を作成します。このエージェントは、ユーザーの質問に基づいて、製品カタログから最適な製品を推薦します。

# エージェントの作成
agent = project_client.agents.create_agent(
    model="gpt-4.1",
    name="ProductRecommendationAgent",
    instructions="""あなたは製品推薦の専門家です。
    ユーザーの要望を聞き、製品カタログから最適な製品を推薦してください。
    推薦時には、以下の情報を必ず含めてください：
    1. 推薦理由
    2. 製品の主な特徴
    3. 価格帯
    4. 類似製品との比較""",
    tools=[
        {"type": "code_interpreter"},  # データ分析用
        {"type": "file_search"}         # 製品カタログ検索用
    ]
)

print(f"エージェント作成完了: {agent.id}")

製品カタログファイルのアップロード：

# サンプル製品カタログ（CSV形式）
catalog_content = """product_id,name,category,price,features
P001,ノートPC Pro,電子機器,150000,16GB RAM / 512GB SSD / 14インチ
P002,ビジネスバッグ Premium,アクセサリー,25000,本革 / 防水 / PC収納
P003,ワイヤレスイヤホン Elite,電子機器,30000,ノイキャン / 8時間再生
"""

# ファイルとして保存
with open("product_catalog.csv", "w", encoding="utf-8") as f:
    f.write(catalog_content)

# Azureにアップロード
from azure.ai.agents.models import FilePurpose

with open("product_catalog.csv", "rb") as file:
    catalog_file = project_client.agents.files.upload_and_poll(
        file=file,
        purpose=FilePurpose.AGENTS
    )

print(f"カタログファイルアップロード完了: {catalog_file.id}")

ステップ4: エージェントとの会話を実行する

# 会話スレッドの作成
thread = project_client.agents.threads.create()

# ユーザーメッセージの送信
message = project_client.agents.messages.create(
    thread_id=thread.id,
    role="user",
    content="リモートワークに最適な製品を推薦してください。予算は20万円です。",
    attachments=[{
        "file_id": catalog_file.id,
        "tools": [{"type": "file_search"}]
    }]
)

# エージェントの実行
run = project_client.agents.runs.create_and_process(
    thread_id=thread.id,
    agent_id=agent.id
)

print(f"実行ステータス: {run.status}")

# 応答の取得
messages = project_client.agents.messages.list(thread_id=thread.id)
for msg in messages:
    print(f"{msg.role}: {msg.content[0].text.value}\n")

実行結果の例：

assistant: リモートワークに最適な製品として、以下を推薦します：

1. **ノートPC Pro（P001）- ¥150,000**
   - 推薦理由：予算内で高性能なノートPCです
   - 主な特徴：16GB RAMで複数アプリ同時実行、512GB SSDで高速起動
   - 14インチで持ち運びも容易

2. **ワイヤレスイヤホン Elite（P003）- ¥30,000**
   - 推薦理由：Web会議での音質向上とノイズキャンセリング
   - 主な特徴：8時間連続再生で一日中使用可能
   - 残予算：¥20,000

合計：¥180,000（予算内）

ビジネスバッグ Premiumは予算オーバーとなるため、今回は除外しました。

このアプローチの利点：

1. 製品知識の自動更新：カタログファイルを更新するだけで、エージェントが最新情報を参照します
2. 一貫した推薦基準：instructionsで定義した基準に基づき、常に同じフォーマットで回答します
3. スケーラブルな対応：複数ユーザーからの同時リクエストにも、スレッドで個別に対応できます

マルチエージェントシステムの構築（Connected Agents）

Microsoft Foundry Agent ServiceのConnected Agents機能を使うと、複数の専門エージェントを連携させ、複雑なワークフローを自動化できます。以下の表で、マルチエージェントアーキテクチャのパターンを整理しました。

ここで注目すべきは、エージェント間の通信プロトコルとして「Agent2Agent (A2A)」が標準化されているという点です。これにより、異なるチームが開発したエージェント同士でも、相互運用性が保証されます。

つまり、エージェントのエコシステムを構築し、部門横断的な業務自動化を実現できるということです。

実装例：カスタマーサポートの多段階自動化

以下は、「問い合わせ分類」→「FAQ検索」→「回答生成」→「満足度確認」の4段階プロセスを自動化する例です。

エージェント1: 問い合わせ分類エージェント

# 分類エージェントの作成
classifier_agent = project_client.agents.create_agent(
    model="gpt-4.1",
    name="InquiryClassifierAgent",
    instructions="""顧客の問い合わせを以下のカテゴリに分類してください：
    - technical_support（技術サポート）
    - billing（請求関連）
    - general_inquiry（一般問い合わせ）
    - complaint（クレーム）

    出力はJSON形式で、以下のフィールドを含めてください：
    {
      "category": "カテゴリ名",
      "priority": "low/medium/high",
      "keywords": ["キーワード1", "キーワード2"]
    }"""
)

エージェント2: FAQ検索エージェント

# FAQ検索エージェントの作成（Azure AI Searchと連携）
faq_agent = project_client.agents.create_agent(
    model="gpt-4.1",
    name="FAQSearchAgent",
    instructions="""分類結果を受け取り、FAQデータベースから関連する情報を検索してください。
    見つかった場合は、FAQ内容と信頼度スコアを返してください。
    見つからない場合は、next_agentフィールドに"escalation"を設定してください。""",
    tools=[
        {
            "type": "azure_ai_search",
            "index_name": "customer-faq-index"
        }
    ]
)

エージェント3: 回答生成エージェント

# 回答生成エージェント
response_agent = project_client.agents.create_agent(
    model="gpt-5",  # より高品質な応答のためGPT-5を使用
    name="ResponseGenerationAgent",
    instructions="""FAQ情報を基に、顧客向けの丁寧な回答を生成してください。
    以下の要件を満たしてください：
    1. 敬語を使用
    2. 解決手順を番号付きリストで提示
    3. 追加のサポートが必要な場合の連絡先を含める
    4. 回答の最後に満足度確認の質問を追加"""
)

エージェント4: エスカレーション管理エージェント

# エスカレーション管理
escalation_agent = project_client.agents.create_agent(
    model="gpt-4.1",
    name="EscalationAgent",
    instructions="""FAQで解決できない問い合わせを処理してください。
    1. 問い合わせ内容を要約
    2. 適切な担当部門を特定
    3. チケットシステムに登録（escalate_ticket関数を使用）
    4. 顧客に「担当者から24時間以内に連絡する」旨を通知""",
    tools=[
        {
            "type": "function",
            "function": {
                "name": "escalate_ticket",
                "description": "チケットシステムに問い合わせを登録",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "department": {"type": "string", "enum": ["technical", "billing", "general"]},
                        "priority": {"type": "string", "enum": ["low", "medium", "high"]},
                        "summary": {"type": "string"}
                    },
                    "required": ["department", "priority", "summary"]
                }
            }
        }
    ]
)

マルチエージェントワークフローの実行：

# 顧客からの問い合わせ
customer_inquiry = "先月の請求額が通常より高いのですが、内訳を確認したいです。"

# ステップ1: 分類
thread1 = project_client.agents.threads.create()
project_client.agents.messages.create(
    thread_id=thread1.id,
    role="user",
    content=customer_inquiry
)
run1 = project_client.agents.runs.create_and_process(
    thread_id=thread1.id,
    agent_id=classifier_agent.id
)
classification_result = project_client.agents.messages.list(thread_id=thread1.id)[0].content[0].text.value

# ステップ2: FAQ検索
thread2 = project_client.agents.threads.create()
project_client.agents.messages.create(
    thread_id=thread2.id,
    role="user",
    content=f"分類結果: {classification_result}\n元の問い合わせ: {customer_inquiry}"
)
run2 = project_client.agents.runs.create_and_process(
    thread_id=thread2.id,
    agent_id=faq_agent.id
)
faq_result = project_client.agents.messages.list(thread_id=thread2.id)[0].content[0].text.value

# ステップ3: 回答生成（またはエスカレーション）
if "next_agent" in faq_result and "escalation" in faq_result:
    # FAQ未解決 → エスカレーション
    thread3 = project_client.agents.threads.create()
    project_client.agents.messages.create(
        thread_id=thread3.id,
        role="user",
        content=f"元の問い合わせ: {customer_inquiry}\n分類: {classification_result}"
    )
    run3 = project_client.agents.runs.create_and_process(
        thread_id=thread3.id,
        agent_id=escalation_agent.id
    )
else:
    # FAQ解決 → 回答生成
    thread3 = project_client.agents.threads.create()
    project_client.agents.messages.create(
        thread_id=thread3.id,
        role="user",
        content=f"FAQ情報: {faq_result}\n顧客への回答を生成してください"
    )
    run3 = project_client.agents.runs.create_and_process(
        thread_id=thread3.id,
        agent_id=response_agent.id
    )

final_response = project_client.agents.messages.list(thread_id=thread3.id)[0].content[0].text.value
print(f"最終回答:\n{final_response}")

このマルチエージェントアプローチの利点：

1. 専門性の分離：各エージェントが特定の役割に特化するため、精度が向上します
2. 保守性の向上：個別エージェントの改善が全体に影響を与えず、段階的な改良が可能です
3. 再利用性：FAQエージェントは他のワークフロー（メール自動応答、チャットボットなど）でも利用できます
4. スケーラビリティ：各エージェントを独立してスケールできるため、ボトルネックを解消しやすい

【試算時の測定指標例】

• 応答時間：人的対応とエージェント応答の平均時間を比較
• 自動解決率：エスカレーションなしで完了した割合
• コスト：オペレーター人件費とエージェント運用費（トークン消費＋基盤コスト）の比較
• 顧客満足度（CSAT）：24時間対応による改善幅を計測

実際の数値は業務内容やFAQの整備状況に大きく依存するため、パイロットフェーズで自社の実測値を取得することが重要です。

Microsoft Foundry Agent Serviceの導入事例

Microsoft Foundry Agent Service（および前身のAzure AI Agent Service）は、グローバル企業で実際に業務効率化の成果を上げています。以下の事例は、公式・企業公開情報を中心にまとめたものです。

• Fujitsu 営業提案書の自動作成で生産性67%向上
  Fujitsuは、Microsoft Foundry Agent Serviceを活用して営業提案書の作成プロセスを自動化しました。複数の専門エージェントが顧客のニーズを解釈し、分散した社内ナレッジにアクセスし、推論を適用して、カスタマイズされた提案書を生成するワークフローを構築しています。その結果、提案書作成の生産性が67%向上したと報告されています。
  
  

• KPMG 規制産業向けのエージェントオーケストレーション
  KPMGは、Semantic Kernelを使って専門エージェント間のワークフローを自動化し、監査業務の効率化を進めています。KPMGグローバル監査イノベーション・AI責任者のSebastian Stöckle氏は「Foundry Agent ServiceとMicrosoft Agent Frameworkがエージェント間のデータ連携を実現し、Azure AI Foundryのガバナンスと可観測性が規制産業に必要な要件を満たしている」と述べています。
  
  

社内のナレッジ検索に毎日30分以上かけているチームがあるなら、まずPromptエージェントでFAQ対応を自動化するPoCから始めるのが現実的な第一歩です。

【関連記事】
AIエージェントを企業に導入する全手順｜事例・費用も解説

Microsoft Foundry Agent Serviceが向いている場面 vs 向かない場面

Microsoft Foundry Agent Serviceの導入を検討する際、すべてのユースケースに適しているわけではありません。以下の表で、適用場面と非適用場面を整理しました。この表を参考に、自社のユースケースが適しているかを判断してください。

向いている場面

ここで注目すべきは、これらのユースケースに共通する特性があるという点です：

1. タスクの定型性：一定のパターンやルールに基づいて処理できる
2. 大量データ処理：人間が処理するには時間がかかる、または物理的に不可能な量
3. 24時間稼働の必要性：営業時間外の対応が求められる
4. スケーラビリティ：需要の変動が大きく、柔軟なリソース調整が必要

つまり、「繰り返し発生する、知識ベースのタスク」が最も適している**ということです。

向かない場面

これらの非適用場面に共通する特性：

1. 高いリスクと責任：誤りが人命や法的責任に直結する
2. 真の創造性と感情性：人間固有の能力が不可欠
3. 物理的制約：クラウドベースのサービスでは対応不可
4. コスト制約：AI実行コストが他の手段より高い

重要な注意点：

「向かない場面」でも、人間の判断を補助するツールとしては有効な場合があります。例えば：

• 医療診断：AIは補助診断ツールとして、医師の判断をサポート（最終判断は医師）
• 法的文書作成：AIは下書きを作成し、弁護士がレビュー・修正
• 創造的デザイン：AIが複数案を生成し、デザイナーが選択・改良

つまり、「AI単独での実行」ではなく「Human-in-the-Loop（人間が最終判断）」のアプローチが有効**ということです。

Microsoft Foundry Agent Serviceの段階的導入アプローチ

Microsoft Foundry Agent Serviceを本格的に導入する際、いきなり大規模展開するのではなく、段階的なアプローチが効果的です。Forrester TEI調査でも、段階的に導入した企業が6か月以内に投資回収を達成しています。以下のフェーズで、リスクを最小化しながら価値を実証できます。

フェーズ1: パイロットプロジェクト（1-2ヶ月）

目的：技術検証と初期効果測定

推奨アクション：

1. スコープの限定：

   • 単一部門、単一ユースケースに絞る（例：ITヘルプデスクの一般的な問い合わせ対応）
   • 影響範囲が小さく、失敗してもリカバリ可能な領域を選択

2. シンプルなエージェント構築：

   • 1-2個のエージェントのみ使用
   • 複雑なワークフローは避け、基本機能の検証に集中

3. 並行運用：

   • 既存の人的プロセスを並行稼働させ、AIの回答を人間がレビュー
   • 精度とユーザー満足度を測定

4. KPI設定：

   • 応答精度（正解率）
   • 応答時間
   • ユーザー満足度（CSAT）
   • コスト削減額

成功基準の例：

• 正解率 ≥ 80%
• 平均応答時間 < 5分
• CSAT ≥ 4.0/5.0
• コスト削減 ≥ 30%

このフェーズの利点：

パイロットプロジェクトにより、経営層への説得材料となる定量的なデータが得られるという点です。「理論上の効果」ではなく、「実測された効果」を示すことで、次フェーズの予算承認が容易になります。

フェーズ2: 部門展開（3-6ヶ月）

目的：スケールアップとプロセス最適化

推奨アクション：

1. 対象範囲の拡大：

   • パイロットで成功したユースケースを部門全体に展開
   • 関連する他のユースケースを追加（例：ITヘルプデスク → 人事・総務ヘルプデスク）

2. マルチエージェント化：

   • Connected Agentsで複数エージェントを連携
   • より複雑なワークフローの自動化

3. 運用プロセスの確立：

   • エージェントのモニタリング体制
   • エラー発生時のエスカレーションフロー
   • 定期的な精度評価とチューニング

4. ユーザートレーニング：

   • エンドユーザー向けの利用ガイド作成
   • 効果的なプロンプト作成のトレーニング

KPI追加項目：

• スループット（処理件数/日）
• エスカレーション率（人間対応が必要だった割合）
• システム稼働率（Uptime）

このフェーズの利点：

運用ノウハウの蓄積により、次の全社展開で発生しうる問題を事前に特定・解決できるという点です。特に、エスカレーションフローやモニタリング体制の構築は、本格運用の成否を左右します。

フェーズ3: 全社展開（6-12ヶ月）

目的：全社的な業務改革とROI最大化

推奨アクション：

1. 横展開：

   • 成功パターンを他部門に水平展開
   • 部門横断的なワークフロー自動化

2. 高度な機能の活用：

   • Deep Research（市場調査、競合分析）
   • Browser Automation（データ収集、RPA代替）
   • Hosted Agents（コスト最適化、グローバル展開）

3. データ統合：

   • 企業全体のナレッジベース統合
   • 部門間でのエージェント共有

4. ガバナンス体制：

   • AI利用ポリシーの策定
   • データプライバシーとセキュリティ監査
   • コンプライアンス確認

KPI追加項目：

• ROI（投資対効果）
• 従業員生産性向上率
• ビジネスプロセスサイクルタイム短縮率

全社展開の成功要因：

経営層のコミットメントと、現場の声を反映した継続的改善のサイクルが不可欠です。トップダウンの方針と、ボトムアップのフィードバックを組み合わせることで、持続可能なAI活用が実現します。

フェーズ4: 継続的最適化（12ヶ月以降）

目的：長期的な価値創出と進化

推奨アクション：

1. 定期的なレビュー：

   • 四半期ごとのKPIレビュー
   • エージェントのパフォーマンス分析
   • 新しいユースケースの発掘

2. モデルアップデート：

   • 新しいモデル（GPT-5、Claude等）へのマイグレーション
   • コスト最適化のためのモデル切り替え

3. エージェントの進化：

   • ユーザーフィードバックを反映した指示文改善
   • 新しいツール・機能の追加

4. ベストプラクティス共有：

   • 成功事例の社内共有
   • 他部門への知見移転

このフェーズの利点：

AIエージェントが「導入して終わり」ではなく、「継続的に進化する資産」として定着するという点です。定期的な改善により、初期導入時の3-5倍の効果を実現できるケースもあります。

Microsoft Foundry Agent Serviceの料金体系（2026年3月最新）

Microsoft Foundry Agent Serviceの料金は、Promptエージェント・Workflowエージェントの作成・実行自体には追加課金なく、使用したモデルのトークン消費量＋ツール使用料＋Azure基盤コストで構成されます。Hostedエージェントのマネージドランタイム課金は2026年4月1日以降に開始予定です（デプロイ中の関連Azureリソースは課金対象）。

クォータと制限

Agent Serviceにはリソース保護のためのサービス制限が設定されています。以下の表で、公式ドキュメントに基づく主要な制限を整理しました。なお、Agent ServiceはAPIコール自体に独自のレート制限を設けていませんが、基盤となるモデルのTPM/RPM制限は適用されます。

これらのサービス制限は固定値であり、サポートリクエストによる上限引き上げはできません。一方、モデルのTPM（Tokens Per Minute）制限はAzure OpenAIのクォータ管理で調整可能です。

本番運用では、モデル側のTPM制限がボトルネックになるケースが多いため、ピーク時のトラフィックを想定したキャパシティプランニングが重要です。最新の制限値は公式ドキュメントを確認してください。

クォータ超過時の動作：

• モデルTPM超過：HTTP 429エラー（Too Many Requests）が返され、リクエストが拒否されます
• 推奨対応：指数バックオフ（Exponential Backoff）による再試行実装

実装例（Pythonでの再試行ロジック）：

import time
from azure.core.exceptions import HttpResponseError

def create_message_with_retry(project_client, thread_id, role, content, max_retries=5):
    """クォータ超過時に自動再試行するメッセージ作成関数"""
    for attempt in range(max_retries):
        try:
            return project_client.agents.messages.create(
                thread_id=thread_id,
                role=role,
                content=content
            )
        except HttpResponseError as e:
            if e.status_code == 429:  # Rate limit exceeded
                wait_time = (2 ** attempt) + (random.random() * 0.1)  # 指数バックオフ
                print(f"クォータ超過。{wait_time}秒後に再試行します（試行 {attempt + 1}/{max_retries}）")
                time.sleep(wait_time)
            else:
                raise
    raise Exception(f"{max_retries}回の再試行後もクォータ超過が解消されませんでした")

クォータ最適化のベストプラクティス：

1. リージョン分散：複数リージョンにエージェントを分散配置し、クォータを分散
2. モデル選択：タスクに応じて、より軽量なモデル（gpt-4.1 → gpt-5-nano）を使用
3. キャッシング：同じ質問への回答をキャッシュし、重複リクエストを削減
4. バッチ処理：リアルタイム性が不要なタスクはオフピーク時にバッチ実行

モデル別料金の考え方（2026年3月時点）

コストの大部分はモデル実行コスト（トークン使用量）です。コスト最適化の鍵は「適切なモデル選択」と「トークン使用量の削減」です。

Azure OpenAIモデル（直接販売） の料金は公式料金ページで確認できます。主な傾向として、gpt-5が最も高精度・高コスト、gpt-5-nanoが最も軽量・低コストです。

パートナー/コミュニティモデル（Claude、Llama等） はAzure Marketplaceのプロバイダー料金が適用されるため、上記とは別体系です。利用前にMarketplaceで最新料金を確認してください。

Azure基盤コスト

タスクごとに最適なモデルを動的に選択することで、品質を維持しながらコストを最適化できます。簡易な問い合わせはgpt-5-nanoやclaude-haiku-4-5、複雑な推論はclaude-opus-4-6やo3のように使い分けるのが実務的なパターンです。

【コスト最適化の考え方】

モデルの使い分けによるコスト削減の基本的な考え方は、問い合わせの複雑さに応じてモデルを振り分けることです。定型的な問い合わせには軽量モデル、複雑な推論が必要な問い合わせにはフラッグシップモデルを使うことで、品質を維持しながら全体コストを抑えられます。具体的な料金は公式料金ページで最新値を確認した上で、自社のトラフィックパターンに基づいて試算してください。

Microsoft Foundry Agent Serviceのセキュリティとプライバシー

Microsoft Foundry Agent Serviceは、エンタープライズグレードのセキュリティ機能を標準で提供しています。2026年3月のGA版では、End-to-End Private NetworkingがMCPサーバー、Azure AI Search、Fabricデータエージェントまで拡張され、ツール接続を含むすべての通信をVNet内に閉じ込めることが可能になりました。以下の表で、主要なセキュリティ機能を整理しました。

ここで注目すべきは、これらのセキュリティ機能が「オプション」ではなく「標準機能」として提供されるという点です。追加コストなしで、エンタープライズレベルのセキュリティが実現できます。

つまり、スタートアップから大企業まで、同じセキュリティレベルを享受できるということです。

データ処理の透明性：

Microsoft Foundry Agent Serviceは、以下のデータプライバシー原則に基づいています：

1. 顧客データの非学習利用：顧客がアップロードしたデータや会話履歴は、Microsoftのモデル学習には使用されません
2. データ保持期間：明示的に削除するまでデータは保持されます（自動削除オプションも設定可能）
3. データ所有権：すべてのデータは顧客に帰属し、Microsoftは処理者として機能します

GDPRコンプライアンス対応：

• データ主体アクセス要求（DSAR）：ユーザーからのデータ開示請求に対応可能
• 削除権（Right to be forgotten）：ユーザーデータの完全削除をAPIで実行可能
• データポータビリティ：データのエクスポート機能を提供

実装例（ユーザーデータの完全削除）：

# 特定ユーザーのすべてのスレッドとメッセージを削除
user_threads = project_client.agents.list_threads()
for thread in user_threads:
    if thread.metadata.get("user_id") == "user_12345":
        project_client.agents.delete_thread(thread_id=thread.id)
        print(f"スレッド {thread.id} を削除しました")

# アップロードしたファイルも削除
user_files = project_client.agents.list_files()
for file in user_files:
    if file.metadata.get("user_id") == "user_12345":
        project_client.agents.delete_file(file_id=file.id)
        print(f"ファイル {file.id} を削除しました")

セキュリティベストプラクティス：

1. 最小権限の原則：エージェントには必要最小限のツールとデータアクセス権限のみ付与
2. 定期的な監査：Azure Monitorのログを定期的にレビューし、異常なアクセスパターンを検知
3. プライベートエンドポイント使用：機密データを扱う場合は、パブリックインターネットを経由しない
4. バージョン管理：エージェントの指示文やツール設定を版管理し、変更履歴を追跡

Foundry Agent Serviceで構築したAgentを業務基盤として運用するなら

Agent Serviceのプロトタイプは動いた。ここから先は「1つのAgentの実験」ではなく「複数Agentが連携する業務基盤」としての設計が必要になります。

AI Agent Hubは、Foundry Agent Serviceで構築したAgentを含め、全社のAIエージェントを1つのダッシュボードで一元管理できるエンタープライズAI基盤です。構築基盤を問わない統合管理で、PoCの先の本番運用を支援します。

• Foundryで構築したAgentを含め全社管理を統合
  Prompt・Workflow・HostedエージェントをFoundryで構築し、n8nやCopilot Studio製Agentも含めて1つの管理ダッシュボードに集約。構築基盤を問わない一元管理を実現します。
  
  
• AgentのデータアクセスにFabric OneLakeを活用
  Foundryで構築したAgentが参照するデータをFabric OneLakeに仮想統合。基幹システムのデータをZero ETLで横断参照し、業務判断の精度を底上げします。
  
  
• 使い慣れたMicrosoft環境をそのまま活用
  Teams・Excel・Outlookなど既存ツールの延長でAIエージェントが動作。新しいツールの学習コストはゼロです。
  
  
• データは100%自社テナント内に保持
  AIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、設計から運用まで伴走支援します。まずは無料の資料で、自社の業務にどう活用できるかご確認ください。

Foundry AgentをAI業務基盤に拡張

構築した先の運用・管理・データ統合まで

Foundry Agent Serviceで構築したAIエージェントを、ガバナンスつきの業務基盤として全社展開。Fabric OneLakeのデータ統合と一元管理で、PoCの先の本番運用を支援します。

▶ 無料で資料をダウンロード

まとめ

Microsoft Foundry Agent Service（旧Azure AI Foundry Agent Service / Azure AI Agent Service）は、2026年3月の次世代版GAにより、Responses APIベースのランタイム、Prompt・Workflowエージェント、End-to-End Private Networking、評価・Observability機能を備えたエンタープライズAIエージェント開発プラットフォームとなりました（Hostedエージェントはパブリックプレビュー）。

本記事で解説した価値は、以下の3点に集約されます。

• ノーコードからフルコードまで対応する3エージェント種別
  Promptエージェントで数分のPoC、Workflowエージェントで複数ステップの業務自動化、Hostedエージェントで独自フレームワークのコンテナデプロイと、開発チームのスキルと要件に応じた最適な選択が可能です。Fujitsuが営業提案書自動作成で67%の生産性向上を達成したように、適切なエージェント種別の選択が成果を左右します。
  
  

• Microsoft Foundry全体のForrester TEI調査でROI 327%
  これはAgent Service単体ではなくFoundryプラットフォーム全体の数値ですが、3年間で$49.5Mの定量的な効果が報告されており、投資回収期間は6か月以内です。パイロットプロジェクトの成果を定量データとして経営層に示せることが、全社展開への予算承認を加速します。
  
  

• エンタープライズグレードのセキュリティとガバナンス
  End-to-End Private Networking、エージェント専用Entra ID、評価・Observability機能（一貫性・関連性・根拠性の評価）により、金融・医療・法務などコンプライアンス要件が厳しい業界でも安心して導入できます。KPMGが規制産業向けに採用している実績が、その信頼性を裏付けています。

「AIエージェントに興味はあるが、どこから手をつければいいか分からない」という状況であれば、まずはAzure無料試用版（初月$200クレジット）でPromptエージェントを1つ作ることから始めてください。社内FAQの問い合わせ対応や、定型的なドキュメント検索の自動化が最もPoC効果を実感しやすいユースケースです。Promptエージェントの作成は無料で、課金はモデルのトークン消費量のみです。

本記事の「使い方」セクションのコード例と公式クイックスタートを参考にすれば、最初のエージェントは30分以内に動作確認できます。成果が確認できたら、本記事の段階的導入アプローチに沿ってWorkflowやHostedエージェントに拡張していくのが、AI総研の導入支援でも最も成功率の高いパターンです。

参考リンク：

• Microsoft Foundry Agent Service公式ドキュメント
• Azure AI Foundryポータル
• Foundry Agent Service料金ページ
• Forrester TEI調査レポート