Azure AI Foundry Agents実装ガイド2026｜料金・競合比較

「Azure AI FoundryでAIエージェントを構築したいけど、どこから始めればいいかわからない」

先日、あるプロジェクトでまったく同じ状況に直面しました。チームはすでにAzure OpenAI Serviceを使っていたのですが、Assistants APIからFoundry Agent Serviceへの移行タイミングと、Entra ID統合の具体的な手順が社内でまったく整理されていなかったのです。

実際に構築してみてわかったのは、「Foundry Agent Serviceは、セキュリティ・ID管理・スケーリングをMicrosoftが全部面倒を見てくれる仕組みになっており、エンタープライズの観点ではかなり完成度が高い」ということでした。一方で、ドキュメントが英語でかつ量が多く、どの機能が自分のユースケースに必要なのかを把握するまでに時間がかかりました。

この記事では、2026年4月時点の最新仕様をもとに、実際に動くPythonコードとともに、Azure AI Foundry Agentsの全容を解説します。

Azure AI Foundry Agentsとは？概要と位置づけ

Microsoft Azure AI Foundry（旧称: Azure AI Studio）は、2025年後半からエンタープライズAI基盤として急速に整備されてきたプラットフォームです。その中核にある Foundry Agent Service は、AIエージェントを構築・デプロイ・スケールさせるためのフルマネージドサービスです（参照: Microsoft Learn公式ドキュメント）。

Foundry Agent Serviceの大きな特徴は次の3点です。

• モデルを選ばない: GPT-4o、Llama、DeepSeek、Mistralなどのモデルカタログから自由に選択できます。コードを変えずにモデルをスワップできるのは運用上の大きなメリットです。
• エンタープライズセキュリティが標準装備: Microsoft Entra ID統合・ロールベースアクセス制御（RBAC）・VNet分離・コンテンツフィルタリングがすべてビルトインです。
• エージェントのライフサイクルを一元管理: 作成 → テスト → トレース → 評価 → 公開 → モニタリングのフローを単一プラットフォームで完結できます。

Azure OpenAI Service（Assistants API）との違い

既存のAzure OpenAI ServiceユーザーにとってFoundry Agent Serviceへの移行は「アップグレード」と考えてください。Microsoft自身が「Azure OpenAI ServiceはFoundryへ統合される方向」と説明しており、2026年4月時点でFoundryからAzure OpenAIリソースを自動アップグレードする機能もプレビュー提供されています。

比較軸	Azure OpenAI Assistants API	Foundry Agent Service（新）
対応モデル	OpenAIモデルのみ	GPT-4o / Llama / DeepSeek / Mistral等マルチモデル
エージェントタイプ	プロンプトエージェントのみ	プロンプト / ワークフロー / ホステッド（コンテナ）
ID管理	APIキー中心	Entra ID統合・エージェント専用マネージドID
MCP対応	なし	あり（Azure Functions経由のカスタムMCPサーバーも可）
VNet分離	限定的	フル対応（データ所在地要件への対応が容易）
可観測性	ログのみ	Application Insightsとのエンドツーエンドトレース
Teams/M365連携	なし	ビルトイン（Teams・Copilotへの公開が数クリック）

正直に言うと、シンプルな社内FAQボットレベルであれば、既存のAssistants APIで十分なケースもあります。しかしAWS/GCPとのハイブリッド環境・金融・医療などコンプライアンス要件が厳しい領域・複数エージェントのオーケストレーションを視野に入れている場合は、最初からFoundry Agent Serviceを選ぶほうが将来の移行コストを減らせます。

主要機能の全体像

3種類のエージェントタイプ

Foundry Agent Serviceは用途に応じて3つのエージェントタイプを提供しています。

• プロンプトエージェント: コード不要。ポータルまたはSDKで指示・モデル・ツールを設定するだけで動きます。素早いプロトタイピングや社内ツールに最適です。
• ワークフローエージェント（プレビュー）: 複数エージェントの調整や承認フロー（Human-in-the-loop）が必要なケースに使います。YAMLまたはポータルのビジュアルビルダーで定義できます。
• ホステッドエージェント（プレビュー）: LangGraphなど任意のフレームワークで書いたコードをコンテナとしてデプロイします。最もフレキシブルで、本番グレードの複雑なワークフローに向いています。

ビルトインツール一覧

エージェントはツールを通じてアクションを実行します。Foundry Agent Serviceが標準提供するツールは次のとおりです（公式ドキュメントより）。

• Webサーチ: Bingグラウンディングツール（プレビュー）
• ファイルサーチ: ベクトルストアを使ったナレッジ検索
• コードインタープリター: Pythonコードの実行・データ分析
• MCP（Model Context Protocol）サーバー: Azure DevOps MCPサーバーなど既成サーバーの追加、Azure Functions経由のカスタムMCPサーバー
• Azure AI Search: エンタープライズ規模のベクトル・フルテキスト検索
• Azure Functions / Logic Apps連携: カスタム関数呼び出し
• OpenAPI仕様によるカスタムツール: 任意のREST APIを数行で統合

環境セットアップ：5分で動かす基本エージェント

前提条件として、AzureサブスクリプションとAzure AI Foundryプロジェクトが必要です。また、Azure CLIでログイン済みであることを確認してください。

コード例1: 認証とエージェント作成の基本

まず必要なパッケージをインストールします。Python 3.9以上が必要です（動作環境: Python 3.11 / azure-ai-agents 1.1.0）。

pip install azure-ai-agents azure-identity

Entra IDのDefaultAzureCredentialを使った認証が推奨です。APIキーによる認証は廃止方向に進んでいるため、新規実装ではマネージドIDまたはDefaultAzureCredentialを使いましょう。

import os
from azure.ai.agents import AgentsClient
from azure.identity import DefaultAzureCredential

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# PROJECT_ENDPOINTはAzure AI FoundryポータルのProject詳細ページから取得できます。
agents_client = AgentsClient(
    endpoint=os.environ["PROJECT_ENDPOINT"],
    credential=DefaultAzureCredential(),
)

# 基本的なエージェントの作成
agent = agents_client.create_agent(
    model=os.environ["MODEL_DEPLOYMENT_NAME"],  # 例: "gpt-4o"
    name="enterprise-assistant",
    instructions=(
        "あなたは社内ナレッジベースを参照して質問に答える企業向けアシスタントです。"
        "該当情報がない場合は、その旨を明示してください。"
    ),
)
print(f"エージェント作成完了 — ID: {agent.id}")

# スレッドを作成して会話を開始
thread = agents_client.threads.create()
message = agents_client.messages.create(
    thread_id=thread.id,
    role="user",
    content="Azure AI Foundry Agentsの料金体系を教えてください。"
)
run = agents_client.runs.create_and_process(thread_id=thread.id, agent_id=agent.id)
print(f"実行ステータス: {run.status}")

# レスポンスの取得
from azure.ai.agents.models import ListSortOrder
messages = agents_client.messages.list(thread_id=thread.id, order=ListSortOrder.ASCENDING)
for msg in messages:
    if msg.text_messages:
        print(f"{msg.role}: {msg.text_messages[-1].text.value}")

# リソースのクリーンアップ
agents_client.delete_agent(agent.id)

ポイント：

• DefaultAzureCredentialは、az loginで取得した認証情報を自動的に使います。本番環境ではマネージドIDに切り替えることを推奨。
• create_and_processを使うとSDKがポーリングを自動処理してくれます。関数ツールがある場合もSDKが自動で呼び出します。
• エージェントIDは再利用可能です。本番では削除せずにバージョン管理しましょう。

ツール統合の実装：Azure AI SearchとBingグラウンディング

本番エージェントでは、ビルトインツールを組み合わせて情報源を広げるケースがほとんどです。以下では、企業ユースケースで特に需要が高い「Azure AI Search連携」と「カスタム関数ツール」の実装例を紹介します。

コード例2: Azure AI Search連携エージェント

社内ドキュメントや製品カタログをAzure AI Searchにインデックスしておくことで、エージェントが自然言語で検索できるようになります（動作環境: Python 3.11 / azure-ai-agents 1.1.0 / Azure AI Search既存インデックス必須）。

import os
from azure.ai.agents import AgentsClient
from azure.ai.agents.models import AzureAISearchTool, AzureAISearchQueryType
from azure.identity import DefaultAzureCredential

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
agents_client = AgentsClient(
    endpoint=os.environ["PROJECT_ENDPOINT"],
    credential=DefaultAzureCredential(),
)

# AI_AZURE_AI_CONNECTION_IDはFoundryポータルのConnections設定から確認してください
conn_id = os.environ["AI_AZURE_AI_CONNECTION_ID"]

ai_search = AzureAISearchTool(
    index_connection_id=conn_id,
    index_name="company-knowledge-base",  # 自社のインデックス名に変更
    query_type=AzureAISearchQueryType.SIMPLE,
    top_k=5,
    filter=""  # 必要に応じてフィルタ条件を追加
)

agent = agents_client.create_agent(
    model=os.environ["MODEL_DEPLOYMENT_NAME"],
    name="knowledge-search-agent",
    instructions=(
        "社内ナレッジベースを参照して質問に答えてください。"
        "参照した情報のタイトルと引用箇所を必ず回答に含めてください。"
    ),
    tools=ai_search.definitions,
    tool_resources=ai_search.resources,
)
print(f"ナレッジ検索エージェント作成完了 — ID: {agent.id}")

コード例3: カスタム関数ツールの統合（自動実行モード）

社内システムのAPIや独自ロジックをツールとして組み込む場合は、FunctionToolを使います。enable_auto_function_callsを呼び出すと、エージェントが関数実行のタイミングを自動で判断してSDKが呼び出してくれます（動作環境: Python 3.11 / azure-ai-agents 1.1.0）。

import os
import json
from azure.ai.agents import AgentsClient
from azure.ai.agents.models import FunctionTool, ToolSet
from azure.identity import DefaultAzureCredential

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

def get_employee_info(employee_id: str) -> str:
    """
    社員IDを元に社員情報を取得します。
    :param employee_id: 社員ID（例: EMP001）
    :return: 社員情報のJSON文字列
    """
    # 実際の実装ではHRシステムのAPIを呼び出します
    mock_data = {
        "EMP001": {"name": "田中太郎", "dept": "開発部", "role": "シニアエンジニア"},
        "EMP002": {"name": "鈴木花子", "dept": "営業部", "role": "アカウントマネージャー"},
    }
    result = mock_data.get(employee_id, {"error": "社員IDが見つかりません"})
    return json.dumps(result, ensure_ascii=False)


def get_project_status(project_code: str) -> str:
    """
    プロジェクトコードを元にプロジェクトのステータスを取得します。
    :param project_code: プロジェクトコード（例: PROJ-2026-001）
    :return: プロジェクトステータスのJSON文字列
    """
    # 実際の実装ではプロジェクト管理システムのAPIを呼び出します
    mock_status = {
        "PROJ-2026-001": {"name": "AIエージェント基盤構築", "status": "進行中", "progress": "65%"},
    }
    result = mock_status.get(project_code, {"error": "プロジェクトコードが見つかりません"})
    return json.dumps(result, ensure_ascii=False)


agents_client = AgentsClient(
    endpoint=os.environ["PROJECT_ENDPOINT"],
    credential=DefaultAzureCredential(),
)

# ユーザー定義関数をFunctionToolとして登録
user_functions = {get_employee_info, get_project_status}
functions = FunctionTool(user_functions)

toolset = ToolSet()
toolset.add(functions)

# 自動関数呼び出しを有効化（SDKがrequires_actionを自動処理）
agents_client.enable_auto_function_calls(toolset)

agent = agents_client.create_agent(
    model=os.environ["MODEL_DEPLOYMENT_NAME"],
    name="hr-project-agent",
    instructions=(
        "社員情報とプロジェクトステータスを照会して質問に答えてください。"
        "必ず取得した情報に基づいて回答し、推測で答えないでください。"
    ),
    toolset=toolset,
)
print(f"HR・プロジェクト照会エージェント作成完了 — ID: {agent.id}")

ポイント：

• 関数のdocstringがツールの説明としてモデルに渡ります。詳細に書くほど精度が上がります。
• enable_auto_function_callsを使うとcreate_and_processまたはstream時に自動で関数が呼ばれます。手動でポーリングする必要がなく、コードがシンプルになります。

Microsoft Entra ID統合：エンタープライズセキュリティの実装

Foundry Agent Serviceの最大の差別化ポイントの一つが、Microsoft Entra IDとの深い統合です。エージェントに専用のEntraマネージドIDが自動でプロビジョニングされ、それを使って外部サービス（MCPサーバー・Azure API等）に対してシークレット不要で認証できます。

コード例4: DefaultAzureCredentialによるEntra認証

開発環境ではAzure CLIの認証情報を、本番環境ではManaged Identityを自動で切り替えてくれるDefaultAzureCredentialが推奨パターンです（動作環境: Python 3.11 / azure-identity 1.19+）。

import os
from azure.ai.agents import AgentsClient
from azure.identity import DefaultAzureCredential, ManagedIdentityCredential

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

# 【開発環境】DefaultAzureCredentialはaz loginの認証情報を使用
# 【本番環境（AKS/Azure Container Apps等）】マネージドIDが自動的に使用される
credential = DefaultAzureCredential()

# プロジェクトエンドポイントの形式: https://.openai.azure.com/
agents_client = AgentsClient(
    endpoint=os.environ["PROJECT_ENDPOINT"],
    credential=credential,
)

# エージェント専用のEntraマネージドIDを確認する場合
# Microsoft Entra管理センター > アプリケーション > エージェントID で確認可能
# エージェントIDはAzure AI Foundryポータルの Agents > [エージェント名] > 詳細 に表示

# 特定のマネージドIDクライアントIDを指定する場合（ユーザー割り当てマネージドID）
# production_credential = ManagedIdentityCredential(client_id=os.environ["MANAGED_IDENTITY_CLIENT_ID"])

print(f"Entra ID認証の設定完了")
print(f"プロジェクトエンドポイント: {os.environ['PROJECT_ENDPOINT']}")

Entra IDエージェントIDの仕組み

Foundry Agent Serviceのエンタープライズ向け機能として、各エージェントにMicrosoft Entra IDの専用アプリ登録（エージェントID）が自動でプロビジョニングされます。この仕組みにより：

• シークレット不要の認証：フェデレーテッドクレデンシャルを使い、エージェントIDがプロジェクトのマネージドIDに信頼されます。APIキーやシークレットを管理する必要がありません。
• 最小権限の原則：エージェントに必要なロール（例: Storage Queue Data Contributor）のみをリソーススコープで付与できます。
• 監査ログの自動記録：エージェントが行ったすべての操作がEntra IDの監査ログに記録されます。コンプライアンス要件への対応が容易です。

RBAC設定のベストプラクティスとして、サブスクリプション全体への権限付与は避け、必要なリソースグループまたは個別リソースのスコープに限定することを強くお勧めします（エージェントID概念の公式ドキュメント）。

Pythonコード例5：Production deploymentパターン

本番環境でFoundry Agent Serviceを運用する場合の、観測可能性（OpenTelemetry）と適切なエラーハンドリングを含む実装パターンです（動作環境: Python 3.11 / azure-ai-agents 1.1.0 / opentelemetry-sdk）。

import os
import sys
import logging
from azure.ai.agents import AgentsClient
from azure.ai.agents.models import ListSortOrder, RunStatus
from azure.identity import DefaultAzureCredential

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

# OpenTelemetryトレーシングの設定（Application Insights連携）
try:
    from azure.monitor.opentelemetry import configure_azure_monitor
    from opentelemetry import trace

    if appinsights_conn := os.environ.get("APPLICATIONINSIGHTS_CONNECTION_STRING"):
        configure_azure_monitor(connection_string=appinsights_conn)
        tracer = trace.get_tracer(__name__)
        print("Application Insightsトレーシング有効")
    else:
        print("警告: APPLICATIONINSIGHTS_CONNECTION_STRING未設定 — トレーシング無効")
except ImportError:
    print("azure-monitor-opentelemetryがインストールされていません")

# ロギング設定（本番ではINFOレベル推奨）
logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s [%(levelname)s] %(name)s: %(message)s",
    stream=sys.stdout
)
logger = logging.getLogger("foundry_agent")


def run_agent_task(user_message: str, agent_id: str) -> str:
    """
    既存のエージェントIDを使ってタスクを実行し、レスポンスを返します。
    本番では既存エージェントをIDで再利用するパターンを推奨。
    """
    agents_client = AgentsClient(
        endpoint=os.environ["PROJECT_ENDPOINT"],
        credential=DefaultAzureCredential(),
    )

    try:
        # スレッドの作成（セッションごとに新規作成）
        thread = agents_client.threads.create()
        logger.info(f"スレッド作成: {thread.id}")

        # ユーザーメッセージを追加
        agents_client.messages.create(
            thread_id=thread.id,
            role="user",
            content=user_message
        )

        # エージェント実行（ポーリングはSDKが自動処理）
        run = agents_client.runs.create_and_process(
            thread_id=thread.id,
            agent_id=agent_id
        )
        logger.info(f"実行完了: status={run.status}")

        # 異常終了のハンドリング
        if run.status == RunStatus.FAILED:
            error_msg = run.last_error.message if run.last_error else "不明なエラー"
            logger.error(f"エージェント実行失敗: {error_msg}")
            return f"エラーが発生しました。しばらく待ってから再試行してください。"

        # レスポンスの抽出
        messages = agents_client.messages.list(
            thread_id=thread.id,
            order=ListSortOrder.DESCENDING
        )
        for msg in messages:
            if msg.role == "assistant" and msg.text_messages:
                return msg.text_messages[-1].text.value

        return "回答を取得できませんでした。"

    except Exception as e:
        logger.error(f"予期しないエラー: {e}", exc_info=True)
        raise


if __name__ == "__main__":
    # 既存エージェントのIDを環境変数から取得（デプロイ済みエージェントを再利用）
    agent_id = os.environ["AGENT_ID"]
    response = run_agent_task(
        user_message="今月の売上レポートのサマリーを作成してください。",
        agent_id=agent_id
    )
    print(f"エージェント回答:n{response}")

ポイント：

• 本番環境ではcreate_agentを毎回呼ばず、デプロイ済みエージェントのIDをAGENT_IDとして環境変数で管理するパターンが効率的です。
• RunStatus.FAILEDの場合のlast_errorフィールドでエラー詳細を取得できます。
• Application Insightsへのトレース送信で、エージェントの全判断フローをAzure Monitorで可視化できます。

競合比較：AWS Bedrock AgentCore / Google Vertex AI Agent Engine との違い

2026年4月時点で、クラウド3大プラットフォームはいずれも本格的なエージェント基盤を提供しています。エンタープライズ導入時の判断材料として比較します。

比較軸	Azure AI Foundry Agents	AWS Bedrock AgentCore	Google Vertex AI Agent Engine
ID管理	Microsoft Entra ID（業界最高水準のエンタープライズID）	AWS IAM / Cognito	Google Cloud IAM / Workload Identity
Microsoft 365連携	Teams / Copilotへのビルトイン公開	なし	なし
対応モデル	GPT-4o / Llama / DeepSeek / Mistral等	Claude / Llama / Nova / Mistral等	Gemini / Llama / Mistral等
Anthropic Claude	非対応（要Bedrock）	最高の統合度（最新モデル即日）	Vertex AI対応（Model Garden）
Agent Service基本料金	追加料金なし（モデル・コンピューティングのみ課金）	$0.0895/vCPU時	$0.00994/vCPU時
VNet分離	フル対応	VPC対応	VPC-SC対応
MCP対応	あり（カスタムMCPサーバー可）	あり（AgentCore Memory）	あり（Vertex AI Extensions）
最強の用途	Microsoft 365中心の企業、規制産業	Claudeを使いたい、AWSネイティブ企業	Gemini多モーダル、大規模コンテキスト

料金面では、Azure AI Foundry Agent Serviceのプラットフォーム自体には追加料金がかかりません。GPT-4o等のモデル利用料と、ストレージ・コンピューティングのAzure標準料金のみです。一方でAWS AgentCoreは$0.0895/vCPU時、Vertex AI Agent Engineは$0.00994/vCPU時のランタイム料金が発生します（Azure公式料金ページ参照）。

大量のエージェントを並列実行するような用途ではVertex AIのコスト優位性が出ますが、Microsoft 365やEntra IDとの統合を前提とするエンタープライズ環境ではFoundryの利便性が大きく上回ります。

料金の全体像：エンタープライズ導入のコスト計算

Azure AI Foundry Agentsの料金は、主に次の要素で構成されます。

• Foundry Agent Serviceプラットフォーム: 追加料金なし。エージェントの作成・管理・実行に対してAgent Serviceとして課金される費用はゼロです。
• モデル利用料: GPT-4o等の使用量に応じたトークン課金。例としてGPT-4oはAzure AI Foundry経由で利用できます（最新の入出力単価は公式料金ページを参照）。
• ベクトルストア（ファイルサーチ用）: 1日あたり/GB単位の料金。
• Application Insights（観測性）: ログ・メトリクスのデータ量に応じた課金。
• VNet統合: Azure Virtual Networkの標準料金。

中規模のエンタープライズエージェント（月50,000リクエスト程度）で試算すると、モデル利用料が費用の大半を占めます。Provisioned Throughput Units（PTU）を購入することで、高頻度ユースケースでのコスト予測が立てやすくなります。

法人導入を判断するためのチェックリスト

Azure AI Foundry Agentsが自社に適しているかを判断するためのチェックポイントを整理します。

これらに当てはまる場合は導入を強く検討してください：

• Azure / Microsoft 365 / Entra IDを主力インフラとして利用している
• Teams・Copilotに社内AIエージェントを公開したい
• 金融・医療・公共など規制産業でデータ所在地・VNet分離が必須
• マルチモデル構成（OpenAI以外のモデルも使いたい）
• 複数エージェントのオーケストレーションが必要

一方で、これらの場合は他サービスも検討してください：

• Anthropic Claudeを最優先モデルとして使いたい → AWS Bedrock
• 既存のGCP/BigQuery環境と深く統合したい → Vertex AI Agent Engine
• Agent Serviceのプラットフォーム料金を極限まで抑えたい → Vertex AI（$0.0099/vCPU時）

よくある失敗パターンと対策

実際にFoundry Agent Serviceを導入する際に陥りやすいポイントをまとめます。

失敗1: ロールの付与先を間違える

Entra ID統合を使う場合、エージェントIDとプロジェクトのマネージドIDの2つが存在します。外部リソースへのアクセス権は、エージェントID（Agent Identity Blueprint）に付与する必要があります。プロジェクトのマネージドIDに付与しても動作しないケースがあります。

❌ プロジェクトマネージドID → Storage Account（エージェントがツールでアクセスできない）

⭕ エージェントID → Storage Queue Data Contributor（ツールからの認証が通る）

失敗2: 環境変数PROJECT_ENDPOINTの形式ミス

プロジェクトエンドポイントはFoundryポータルの「Project details」から取得します。https://<region>.api.azureml.msとhttps://<project-id>.openai.azure.com/など複数の形式が存在し、SDKのバージョンによって受け付ける形式が異なります。必ずFoundryポータルのProject詳細に表示されるエンドポイント文字列をそのままコピーしてください。

失敗3: 一度に複雑すぎるワークフローを構築する

❌ 初期実装から10ステップのマルチエージェントパイプラインを組む

⭕ まずプロンプトエージェント1体でE2Eを動作確認 → 必要に応じてツールを追加 → ワークフロー/ホステッドエージェントへ段階的に移行

失敗4: モニタリングを後回しにする

エージェントの判断フローは、Application Insightsのトレース設定がないと後から追えなくなります。最初の実装時点でconfigure_azure_monitorを組み込んでおくことを強くお勧めします。ハルシネーションや意図しないツール呼び出しを本番稼働後に検出するためにも必須です。

Azure AI Foundryが向くケース・向かないケース早見表

Azure AI Foundry Agentsは「エンタープライズ向け」と一括りにされがちですが、実際には組織がすでに置かれているクラウド環境とガバナンス要件によって、最適解になるかどうかが大きく分かれます。同じAIエージェント基盤でも、Microsoft 365やAzureを全社標準にしている企業と、特定のSaaSをマルチクラウドで併用している企業では、得られるメリットが正反対になることもあります。導入を検討する前に、自社がどのケースに当てはまるかをまず確認してください。

下表は、典型的な利用シーン別に「Azure AI Foundryが向くか」を整理したものです。あくまで一般的な傾向であり、最終判断は自社の要件と公式ドキュメントでの最新仕様の確認を前提にしてください。

ケース	適性	理由
Microsoft 365 / Azureを全社標準で利用	非常に向く	Entra IDによる認証・権限管理、既存のAzureリソースやSharePoint等との連携がそのまま活きる。IDとガバナンスの統制を一元化しやすい。
エンタープライズのガバナンス・監査要件が厳しい	向く	RBACによる権限設計、Entra IDベースのエージェントID、Azure Monitorによるトレースなど、監査・統制に必要な仕組みが基盤側に揃っている。
社内データ（検索・ナレッジ）をAIに安全に参照させたい	向く	Azure AI Searchなどとの統合により、社内ナレッジを閉じた環境でグラウンディングしやすい。データの所在を自社テナント内に保ちやすい。
小規模な検証・個人開発のPoC	やや過剰	Entra IDやRBACの設計が前提になるため、ごく小さなプロトタイプには初期セットアップが重く感じられることがある。まず最小構成で試すのが現実的。
マルチクラウド前提・特定クラウドに縛られたくない	慎重に検討	認証・運用がAzure/Entra ID前提に最適化されているため、他クラウドとの抽象化レイヤーを別途用意する必要が出る場合がある。
AzureもMicrosoftエコシステムも使っていない	向きにくい	Entra ID・Azureサブスクリプションの新規整備コストが先に発生する。既存の別基盤を活かせるなら、そちらを優先する選択肢もある。

判断の軸はシンプルで、「すでにMicrosoft / Azureに寄せているか」「ガバナンス統制をどこまで重視するか」の2点です。前者がYesで後者を重視するなら、Azure AI Foundryは有力な第一候補になります。逆に、特定クラウドに依存せず軽量に始めたい場合は、最小構成から検証し、必要に応じて他基盤と比較するアプローチが安全です。なお、各機能の対応状況やリージョン提供範囲は変わりうるため、本番採用の前に必ずMicrosoft公式ドキュメントで最新情報を確認してください。

PoCから本番までの段階導入ロードマップ

Azure AI Foundry Agentsの導入でつまずく組織の多くは、最初から本番相当の複雑な構成を組もうとして、認証・権限・コスト・監視のどれかで止まります。エンタープライズ基盤だからこそ、「動くものを小さく作り、統制と運用を段階的に足していく」順序が重要です。ここでは、検証から全社展開までを4つのフェーズに分けて整理します。各フェーズで「次に進む前に確認すべきこと」を満たしてから次へ進むのが、手戻りを防ぐコツです。

段階導入の4フェーズ

フェーズ	主な目的	このフェーズでやること	次に進む前の確認
フェーズ1：PoC（検証）	技術的に動くかを確かめる	最小構成で基本エージェントを作成し、1つのユースケースだけ実装する。権限は検証用の限定スコープに留める。	想定したタスクをエージェントが完了できるか／応答品質が許容範囲か
フェーズ2：認証・権限の本設計	本番に耐えるID統制を整える	Entra IDによる認証へ切り替え、RBACで「誰が・何に・どこまで」アクセスできるかを最小権限で設計する。サービス用と開発者用のロールを分離する。	権限が最小限になっているか／不要な広い権限が残っていないか
フェーズ3：監視・コスト・データ統制	運用できる状態にする	トレース・ログを有効化し、利用状況を可視化する。コストの監視・上限管理を設定し、参照させるデータの範囲と保持方針を決める。	異常時に追跡できるか／コストが事前に把握・制御できるか
フェーズ4：段階展開（本番）	安全に利用者を広げる	一部門・少人数から本番運用を開始し、フィードバックを得てから対象を拡大する。ワークフローは段階的に複雑化する。	運用負荷・問い合わせが許容範囲か／拡大しても統制が崩れないか

このロードマップで特に効くのは、フェーズ2と3を「本番展開の前」に必ず挟むことです。認証・権限・コスト・監視を後回しにすると、利用が広がってから統制を入れ直すことになり、はるかに大きな手戻りになります。逆に、各フェーズの確認項目をクリアしながら進めれば、小さく始めても本番品質まで地続きで到達できます。なお、各機能の設定手順や推奨構成はアップデートされるため、実装時にはMicrosoft公式ドキュメントで最新の手順を確認することをおすすめします。

FAQ：よく聞かれる質問

Q. OpenAI Agents SDKとFoundry Agent Serviceはどう違うのですか？

OpenAI Agents SDKはPython中心のフレームワークで、モデルは主にOpenAI APIに依存します。Foundry Agent Serviceはクラウドマネージドのプラットフォームで、インフラ・ID・スケーリングをMicrosoftが管理します。両者はワイヤーレベルで互換性があり、OpenAI Agents SDKで書いたコードをFoundryにデプロイすることも可能です。

Q. FoundryとAzure OpenAI Serviceは今後どうなりますか？

MicrosoftはAzure OpenAI ServiceをFoundryに統合する方向で開発を進めており、2026年4月時点でAutoUpgrade機能（プレビュー）が提供されています。新規プロジェクトはFoundryから直接始めることを推奨します。

Q. Copilot StudioとFoundry Agent Serviceの使い分けは？

Copilot Studioはローコード・ビジネスユーザー向けのエージェントビルダーです。Foundry Agent Serviceは開発者向けで、フルコードでの実装・カスタムフレームワーク・複雑なワークフローに対応しています。社内で両方を組み合わせて使うことも可能です。

Q. Foundry Agent ServiceでAnthropicのClaudeを使えますか？

2026年4月時点では、Azure AI Foundryのモデルカタログに直接Claudeは含まれていません。Claudeを使う場合は、AWS Bedrockが最も統合度が高い選択肢です。ただし、Microsoft Agent Frameworkはオープンソースで開発されており、将来的なモデル対応追加の可能性はあります。

参考・出典

• What is Microsoft Foundry Agent Service? — Microsoft Learn公式ドキュメント（参照日: 2026-04-30）
• Azure AI Agents client library for Python — Microsoft Learn / PyPI（参照日: 2026-04-30）
• Agent identity concepts in Microsoft Foundry — Microsoft Learn公式ドキュメント（参照日: 2026-04-30）
• Foundry Agent Service – Pricing — Microsoft Azure公式料金ページ（参照日: 2026-04-30）
• Enterprise AI Platform: Vertex vs Bedrock vs Foundry (2026) — Internative（参照日: 2026-04-30）

まとめ：今日から始める3つのアクション

1. 今日やること：Azure CLIでFoundryプロジェクトにログインし、「コード例1」のbasic agentを実際に動かしてみましょう。数分で動作確認できます。
2. 今週中：社内のAzure AI Searchインデックスがあればコード例2のナレッジ検索エージェントを構築し、チームのFAQシナリオで精度を検証してみてください。
3. 今月中：Application Insightsトレースを有効化し、エージェントの判断フローを可視化した上で本番デプロイの計画を立てましょう。Entra IDのRBAC設定は最小権限から始めることを忘れずに。

---

あわせて読みたい：

• 【2026年4月速報】Vertex AI Agent Engine完全ガイド — Google Cloud側のエンタープライズエージェント基盤を比較したい方へ
• 【2026年4月】AWS Strands Agents完全ガイド — AWS Bedrockエコシステムでのエージェント構築を検討している方へ
• AIエージェント完全ガイド（ピラーページ） — AIエージェントの基礎から応用まで体系的に学びたい方へ

---

---

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。著書『AIエージェント仕事術』。
100社以上の企業向けAI研修・導入支援。SoftBank IT連載7回執筆。
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。

あわせて読みたい

• ▸ Gemini Managed Agents強化、予算管理と環境フックを追加
• ▸ Bedrock Agents Classic新規停止とAgentCore移行
• ▸ Nano Banana Proはどこで使える？できること・料金を整理【2026】
• ▸ AIエージェントのコスト監視入門｜トークン可視化と暴走対策【2026年8月】
• ▸ プロンプトインジェクション対策｜エージェント時代の多層防御5層【2026】