Azure Functionsでのサーバーレス エージェントのランタイム

Azure Functions サーバーレス エージェント ランタイムは、Azure Functions アプリとして AI エージェントを構築するためのマークダウン優先プログラミング モデルです。 ホスティング、トリガー、モデル クライアント、ツール、セッション ストレージ、ID、および可観測性を結合する代わりに、 .agent.md ファイルにエージェントを定義し、それらを関数アプリとしてデプロイします。

ランタイムは、イベントに反応し、ツールを呼び出し、サーバーレス インフラストラクチャで実行するエージェント向けに設計されています。 エージェントは、HTTP 要求、スケジュール、キュー、メッセージ、データベースの変更、およびその他のイベントから開始できます。リモート MCP サーバー、コネクタ名前空間でホストされている MCP サーバー、再利用可能なスキル、サンドボックス実行を使用する。他のAzure Functions アプリで使用されるのと同じデプロイ、ID、監視、スケーリング機能を使用して実行します。 アプリ固有のロジックの場合は、同じ関数アプリでカスタム ツールを記述できます。

Azure Functionsでエージェントを構築する理由

運用エージェントには、プロンプトとモデル以上のものが必要です。 作業を開始する、外部システムを呼び出す、会話履歴を保持する、信頼できないコードを安全に実行する、シークレットなしで認証する、テレメトリを出力する、オンデマンドでスケーリングする信頼性の高い方法が必要です。

Azure Functionsには、これらの運用上の問題に対するイベントドリブン コンピューティング モデルが既に用意されています。 サーバーレス エージェント ランタイムは、そのモデルをエージェントに適用します。

• エージェントは作業単位です。 .agent.md ファイルは、1 つのエージェントのトリガーと命令を定義します。
• イベントはエージェントを起動します。 Functions トリガーを使用すると、エージェントをスケジュールに従って実行したり、キューやイベントに対応したり、HTTP エンドポイントを公開したりできます。
• 機能は、必要なときにコードを使用して最初に構成されます。 エージェントは、リモート MCP サーバー、コネクタ名前空間でホストされている MCP サーバー、スキル、およびセキュリティで保護されたコード実行を構成から使用できます。 アプリ固有のロジックにはカスタム ツールを使用します。
• ホスティングはサーバーレスです。 Flex Consumption では、0 から 0 までのスケール、1 秒あたりの課金、マネージド ID、仮想ネットワーク統合、Application Insights がサポートされます。
• 運用配管が組み込まれています。 ランタイムは、エージェントの検出、トリガー登録、ツール アセンブリ、セッション履歴、およびオプションの組み込みエンドポイントを処理します。

プロジェクトの構造

サーバーレス エージェント アプリは、通常の Functions プロジェクト ファイルの横にエージェント固有のファイルを含むPython Azure Functions アプリです。

最小限のプロジェクトには、 function_app.py、 host.json、 requirements.txt、および少なくとも 1 つの .agent.md ファイルがあります。 アプリ全体のランタイムの既定値が必要な場合は、 agents.config.yaml を追加します。

エージェント ファイル

エージェント ファイルでは、YAML のフロント マターの後にマークダウン命令が続きます。 この例では、タイマーによってトリガーされるエージェントを定義します。

---
name: Daily Tech News Email
description: Fetches top tech news and emails a summary daily.

trigger:
  type: timer_trigger
  args:
    schedule: "0 0 15 * * *"
---

You are a news assistant. When triggered, do the following:

1. Gather today's top technology news from reputable sources.
1. Summarize the stories in a concise HTML email body.
1. Email the summary to $TO_EMAIL with the subject "Daily Tech News Summary".

フロントマターは、エージェントの呼び出し方法を宣言します。 マークダウン本文は、実行時にランタイムがモデルに渡す命令ブロックです。 環境変数の置換により、命令と構成値は、 $TO_EMAILなどのアプリ設定を参照できます。

各 .agent.md ファイルは、1 つのエージェントを定義します。 ファイル名は、Azure関数名と組み込みエンドポイントのルート セグメントを派生させるために使用されます。 name フィールドは、ログ、ラベル、ドキュメントで使用される表示名です。

エージェントを構成するには、次のフロント マター フィールドを使用します。

agents.config.yaml でのランタイムの既定値

すべてのエージェントが継承できるアプリ全体のランタイムの既定値には、 agents.config.yaml を使用します。 ランタイムは、このファイルなしでアプリを読み込むことができます。 モデルのデプロイ、タイムアウト、サンドボックス実行エンドポイントなどの共有設定が必要な場合に追加します。

このファイルは、1 つのアプリ レベルの入力です。 ランタイムは、mcp.json から MCP サーバー、skills/ のスキル、および tools/ のカスタム Python ツールも検出します。 これらの機能は、エージェントで既定で有効になっています。 エージェントのフロントマターは、ランタイムの既定値をオーバーライドしたり、継承された MCP サーバー、スキル、ツールをフィルター処理したりできます。

system_tools:
  dynamic_sessions_code_interpreter:
    endpoint: $ACA_SESSION_POOL_ENDPOINT

model: $FOUNDRY_MODEL
timeout: 900

個々のエージェントは、サポートされているランタイム設定を独自のフロント マターでオーバーライドできます。

agents.config.yamlでは、次の最上位フィールドを使用します。

ランタイムは、最初にエージェントのフロント マターから値を解決してから、 agents.config.yamlし、次にアプリの設定とランタイムの既定値を解決します。 agents.config.yamlの文字列値は、$AZURE_OPENAI_DEPLOYMENTや$ACA_SESSION_POOL_ENDPOINTなどのアプリ設定を参照できます。

モデル、タイムアウト、およびシステム ツールの既定値を agents.config.yamlのままにします。 コネクタ名前空間からの MCP サーバー エンドポイントを含むリモート MCP サーバー定義を mcp.jsonに保持します。

変数の置換

ランタイムは、アプリの設定と環境変数を、エージェントフロントマター、エージェント命令本体、 agents.config.yaml、および mcp.jsonの文字列値に置き換えることができます。 $SETTING_NAME または %SETTING_NAME% を使用します。 変数名は、文字またはアンダースコアで始まる必要があり、文字、数字、およびアンダースコアを含めることができます。

model: $FOUNDRY_MODEL
system_tools:
  dynamic_sessions_code_interpreter:
    endpoint: %ACA_SESSION_POOL_ENDPOINT%

Email the summary to $TO_EMAIL.

{
  "servers": {
    "office365": {
      "type": "http",
      "url": "$O365_MCP_SERVER_URL"
    }
  }
}

置換は、オブジェクトまたはリストに入れ子になった文字列を含む文字列値に適用されます。 オブジェクト キーには適用されません。 エージェント命令本体のフェンスされたコード ブロックは置き換えられていないため、例にはリテラル $VALUE や %VALUE% テキストを含めることができます。

置換されたコンテンツにリテラル プレースホルダーが必要な場合は、 $$SETTING_NAME または %%SETTING_NAME%% を使用します。 不足している環境変数は変更されず、空の値は空の文字列に解決され、置換は 1 つのパスです。 ${SETTING_NAME}構文はサポートされていません。

1 つのエージェントのフロントマターと命令の置換を無効にするには、エージェント ファイルに substitute_variables: false を設定します。 この設定では、 agents.config.yaml または mcp.jsonでの置換は無効になりません。

ランタイムがアプリを起動する方法

Azure Functions ホストがアプリをインポートすると、create_function_app() は、構成された FunctionApp をプロジェクト ファイルからビルドします。

1. アプリのルートを解決します。
2. agents.config.yamlを読み込みます。
3. 各 .agent.md ファイルを読み込みます。
4. MCP サーバー、スキル、カスタム ツールを見つけます。
5. アプリ全体の既定値とエージェントごとの構成を作成します。
6. 解決されたエージェント構成を検証します。
7. 各エージェントの最終的なツールとスキル機能を構築します。
8. Azure Functions トリガーとオプションの組み込みエンドポイントを登録します。

起動後、Azure Functions ホストは、他の関数アプリの場合と同様に、登録されたトリガーのインデックスを作成します。 トリガーが起動すると、ランタイムは指示、モデル設定、ツール、スキル、セッション履歴を使用してエージェントをビルドし、Microsoft Agent Framework を介して実行します。

イベントからエージェントをトリガーする

サーバーレス エージェントは、作業を開始するイベントがモデル呼び出しと同じくらい重要な場合に便利です。 ランタイムは、エージェント ファイルごとに 1 つのトリガーをサポートします。

トリガー定義には、 type と args オブジェクトがあります。 typeはトリガー バインドを識別し、argsには、エージェントを開始するイベントを構成するトリガー固有の設定が含まれています。

trigger:
  type: timer_trigger
  args:
    schedule: "0 0 15 * * *"

一般的なトリガーの種類には、 http_trigger、 timer_trigger、 queue_trigger、 blob_trigger、 event_grid_trigger、および service_bus_triggerがあります。 組み込みのAzure Functions トリガーの場合は、Python v2 のトリガーとバインドのドキュメントおよびトリガーのバインド参照を使用して、args に含める設定を見つけます。 たとえば、タイマー トリガーは schedule 設定を使用し、キュー トリガーは queue_name や connectionなどの設定を使用し、BLOB トリガーは path や connectionなどの設定を使用します。 ランタイムは生成された関数エントリ ポイントを提供するため、エージェント ファイルにはイベント ソースを識別するトリガー設定のみが必要です。

一般的なトリガー パターンは次のとおりです。

各エージェントはAzure関数として登録されているため、アプリはスケール ルール、マネージド ID、ネットワーク、監視などの Functions ホスティング機能を使用できます。

エージェントにツールを提供する

エージェントは、アクションを実行できる場合に役立ちます。構成された機能 (リモート MCP サーバー、コネクタ名前空間でホストされている MCP サーバー、スキル、サンドボックス実行) から始めます。 これらのオプションに適合しないアプリ固有の機能には、カスタム Python ツールを使用します。

リモート MCP サーバー

アプリでリモート MCP サーバーを使用する場合は、関数アプリ プロジェクトのルートに mcp.json を追加します。 ランタイムは、このファイルからリモート HTTP またはストリーミング可能な HTTP MCP サーバーを検出し、エージェントごとにフィルターを適用して、それらのツールをエージェントで使用できるようにします。

各 servers エントリで次のフィールドを使用します。

エージェントが別のサービスによってホストされているツールを呼び出すか、アプリの境界を越えてエージェントとツールを作成する必要がある場合は、リモート MCP サーバーを使用します。

Azure コネクタ

コネクタを使用すると、エージェントはカスタム API クライアント コードなしで外部サービスを操作できます。 たとえば、Microsoft 365 Outlook コネクタは電子メールを送信でき、Teams コネクタはメッセージを操作でき、他のコネクタは Salesforce、SAP、SQL などのシステムでアクションを呼び出すことができます。 コネクタ名前空間は、それらの統合をアプリで使用できるようにする接続、トリガー、および MCP サーバーをホストします。

サーバーレスエージェントアプリでコネクタ機能を使用するには、まずコネクタネームスペースリソースを作成し、サービスへの接続を作成し、その接続を承認します。 次に、エージェントが接続を使用する方法を選択します。

• コネクタは、 接続されたサービス (新しいメール、Teams メッセージ、予定表イベントなど) で何かが発生したときにエージェントを開始します。 これを使用するには、承認された接続を使用するトリガーをコネクタ名前空間に作成し、そのコネクタ トリガー定義のトリガー名と引数を使用してエージェントを構成します。
• コネクタ MCP ツール を使用すると、エージェントはメールの送信やレコードの更新などのサービス アクションを呼び出すことができます。 それらを使用するには、承認された接続を使用する MCP サーバーをコネクタ名前空間に作成し、MCP サーバー エンドポイントを mcp.jsonに追加します。

コネクタ MCP ツールの場合、 mcp.json の MCP サーバー エントリには、エンドポイントとマネージド ID 認証の設定が格納されます。 エージェントがコネクタ名前空間からマネージド MCP サーバーを使用する場合は、Azure API Hub スコープを使用します。 mcp.jsonにユーザー シークレットを格納しないでください。

{
  "servers": {
    "office365-outlook": {
      "type": "http",
      "url": "$O365_MCP_SERVER_URL",
      "auth": {
        "scope": "https://apihub.azure.com/.default",
        "client_id": "$O365_MCP_CLIENT_ID"
      }
    }
  }
}

auth.client_id設定では、MCP サーバーで認証するマネージド ID を選択します。 ユーザー割り当てマネージド ID のクライアント ID に設定します。 関数アプリのシステム割り当てマネージド ID をAzureで使用するには省略します。 選択した ID、またはローカルで実行する際のローカル開発者 ID は、MCP サーバーの呼び出しを許可する必要があります。

スキル

スキルは、 skills/の下に保存された再利用可能なプロンプトアセットです。 これらは、必要に応じてドメイン固有の命令を使用できるようにしながら、ベース エージェントの命令を小さく保つのに役立ちます。 ランタイムでは 、エージェント スキル 形式が使用されます。

ランタイムは、関数アプリ プロジェクトルートの skills/ をスキャンし、 SKILL.mdを含むフォルダーを再帰的に検出します。

skills/
  incident-response/
    SKILL.md
    triage-checklist.md
    escalation-policy.md

SKILL.md ファイルには、YAML のフロント マターとそれに続くマークダウン命令が含まれています。

---
name: incident-response
description: Triage production incidents, summarize impact, and recommend next steps. Use when the task mentions incidents, outages, alerts, or severity levels.
---

Follow the incident response checklist in [triage-checklist.md](triage-checklist.md).

次のスキル作成ルールを使用します。

• すべてのスキル フォルダーには、 SKILL.md ファイルが含まれている必要があります。
• nameフィールドとdescription フィールドが必要です。
• スキル名には、小文字、数字、および 1 つのハイフンを使用する必要があります。 スペース、アンダースコア、大文字、先頭のハイフン、末尾のハイフン、繰り返しのハイフンは使用しないでください。
• スキル名は、アプリ全体で一意である必要があります。
• この説明では、スキルの動作と、エージェントがスキルを使用するタイミングの両方について説明する必要があります。 ランタイムは、スキル名と説明を最初に読み込んで、エージェントがスキル全体を読み込むタイミングを決定できるようにします。
• スキルには、同じスキル フォルダーに複数のマークダウン ファイルを含めることができます。 相対リンクを使用して、SKILL.md から補助的なMarkdownファイルを参照します。
• サーバーレス エージェント ランタイムでは、スキル コンテンツとしてサポートされるのはマークダウン ファイルのみです。 スキルで実行可能な動作が必要な場合は、そのコードをカスタム Python ツールとしてパッケージ化し、スキル命令から名前でツールを参照します。

エージェントは、検出されたすべてのスキルを既定で継承します。 特定のエージェントがスキルを使用しない場合に、エージェント ファイルのスキルを無効または除外します。

skills: false

skills:
  exclude:
    - incident-response

サンドボックス実行

コードの実行またはブラウザーの自動化では、ランタイムは Azure Container Apps 動的セッションを使用できます。 動的セッションは、 セッション プールから分離された環境を提供します。 ランタイムは 、コード インタープリター セッション を使用して、エージェントに execute_python ツールを提供します。

agents.config.yamlでサンドボックス実行を構成します。

system_tools:
  dynamic_sessions_code_interpreter:
    endpoint: $ACA_SESSION_POOL_ENDPOINT

次のサンドボックス要件を使用します。

• セッション プールは、--container-type PythonLTS で作成されたプールなど、Python コード インタープリター セッション プールである必要があります。
• endpoint値は、セッション プール管理エンドポイントです。
• Azureでは、関数アプリで使用されるマネージド ID に、セッション プールでコードを実行するために必要なロールの割り当てが必要です。 Azure Container Apps のコード インタープリター セッションでは、セッション プールに対して Azure ContainerApps Session Executor ロールと Contributor ロールが必要です。
• ローカルで実行する場合、開発者 ID にはセッション プールへの同じ必要なアクセス権が必要です。
• ユーザー割り当てマネージド ID をサンドボックス実行に使用するには、必要なロールの割り当てを持つ ID のクライアント ID に system_tools.dynamic_sessions_code_interpreter.client_id を設定します。 この設定が設定されていない場合、ランタイムは既定の資格情報チェーンである AZURE_CLIENT_IDを使用します。

サンドボックス ツールは、分離されたセッションでPython実行されます。 変数、インポート、およびファイルは、同じエージェント セッション内のツール呼び出し間で保持できます。 使用可能なエージェント セッション ID がない場合、ランタイムは新しいサンドボックス セッションを使用するため、関連のない実行は状態を共有しません。

エージェントは、グローバルに構成されている場合に、サンドボックス実行を継承します。 そのエージェントにコードを実行させるべきでない場合は、特定のエージェントではこれを無効にします。

system_tools:
  dynamic_sessions_code_interpreter: false

カスタム Python ツール

MCP サーバー、コネクタ名前空間でホストされている MCP サーバー、スキル、またはサンドボックス実行に適合しないアプリ固有の機能には、カスタム Python ツールを使用します。 カスタム ツールを使用すると、同じ関数アプリからAzure FunctionsパッケージとPython パッケージを使用できます。

関数アプリ プロジェクト ルートの tools/ フォルダーにツール ファイルを追加します。

tools/
  submit_ticket.py
  lookup_customer.py

ランタイムは、ファイル名が.pyで始まらないtools/内の_ファイルを検出します。 現在のプレビューでは、ランタイムは各ファイルからサポートされている最初のツールを登録します。 ファイルごとに 1 つのツールを使用して、検出を予測可能な状態に保ちます。

ランタイム パッケージの @tool を使用して関数を修飾することで、ツールを定義できます。

from azure_functions_agents import tool


@tool(name="submit_ticket", description="Create a support ticket with a title and summary.")
async def submit_ticket(title: str, summary: str) -> str:
    return f"Created ticket for {title}: {summary}"

パラメーターの詳細な説明と検証を行うには、ツール スキーマとして Pydantic モデルを使用します。

from pydantic import BaseModel, Field
from azure_functions_agents import tool


class LookupCustomerParams(BaseModel):
    customer_id: str = Field(description="Customer identifier from the CRM system.")


@tool(schema=LookupCustomerParams, description="Look up customer details by customer ID.")
async def lookup_customer(params: LookupCustomerParams) -> str:
    return f"Customer details for {params.customer_id}"

デコレーターなしでプレーンなPython関数を定義することもできます。 ランタイムは、ファイル内で見つけた最初のプレーン関数をラップし、関数名をツール名として使用し、ツールの説明として docstring を使用します。

def summarize_order(order_id: str) -> str:
    """Summarize an order by order ID."""
    return f"Summary for order {order_id}"

ツール名、説明、型ヒント、Pydantic フィールドの説明は、モデルがツールを呼び出すタイミングと方法を決定するのに役立ちます。 Azure Functions アプリの他のPython コードの場合と同様に、カスタム ツールで使用されるパッケージの依存関係を requirements.txt に追加します。

エージェントは、検出されたカスタム ツールを既定で継承します。 特定のエージェントでカスタム ツールを使用しない場合は、エージェント ファイル内のカスタム ツールを無効または除外します。

tools: false

tools:
  exclude:
    - submit_ticket

モデルプロバイダーを構成する

ランタイムは、Microsoft Agent Framework を使用してモデル プロバイダーを呼び出します。 プレビュー サポートの対象には、Azure OpenAI、Azure AI Foundry、OpenAI が含まれます。

プロバイダーの選択は、アプリの設定に基づいています。 プロバイダーを AZURE_FUNCTIONS_AGENTS_PROVIDERにピン留めするか、ランタイムが AZURE_OPENAI_ENDPOINT、 FOUNDRY_PROJECT_ENDPOINT、 OPENAI_API_KEYなどの設定からプロバイダーを推論できるようにすることができます。

モデルの選択では、次の一般的な優先順位が使用されます。

1. エージェントまたはランタイム呼び出しによって要求されたモデル。
2. プロバイダー固有の設定 ( AZURE_OPENAI_DEPLOYMENT や FOUNDRY_MODELなど)。
3. AZURE_FUNCTIONS_AGENTS_MODEL。
4. プロバイダーの既定値。

運用アプリの場合は、サポートされているマネージド ID を優先します。 アプリでユーザー割り当てマネージド ID を使用する必要がある場合は、モデル プロバイダーとサンドボックス実行がその ID を使用するように AZURE_CLIENT_ID 設定します。

マネージド ID の構成

ランタイムは、Microsoft Entra認証をサポートするAzure リソースにマネージド ID を使用します。 アプリの既定の ID セレクターとして AZURE_CLIENT_ID を使用します。 コネクタ名前空間と BLOB ベースのセッション履歴でホストされている MCP サーバーでは、より具体的な ID 設定を使用できます。

モデル プロバイダーとサンドボックス実行の場合は、ランタイムでユーザー割り当てマネージド ID を使用する場合に AZURE_CLIENT_ID を設定します。 AZURE_CLIENT_ID が設定されていない場合、ランタイムは標準のAzure SDK資格情報の動作を使用します。この動作には、システム割り当てマネージド ID が使用可能な場合に含めることができます。

マネージド ID を選択するには、次の設定を使用します。

Azure OpenAI の場合、これらの ID 設定は、AZURE_OPENAI_API_KEY が設定されていない場合にのみ適用されます。 API キーが構成されている場合、モデル プロバイダーはマネージド ID の代わりにキーを使用します。

セッション履歴では、Azure Functions ホストと同じストレージ ID 構成が使用されます。 AzureWebJobsStorage、AzureWebJobsStorage__blobServiceUri、およびAzureWebJobsStorage__clientIdを使用して、BLOB ベースの履歴用に ID ベースのストレージを構成します。 ランタイムは、セッション履歴に個別のエージェント固有の ID 設定を使用しません。

セッションと状態

エージェントとの複数ターンの対話には、セッション履歴が必要です。 Azureでは、ランタイムは、関数アプリの AzureWebJobsStorage アカウントを使用して、セッション履歴をBlob Storageに格納します。 この設計では、多くのアプリに対して個別のセッション データベースが不要になり、接続文字列または ID ベースのストレージ構成で動作します。

Azureストレージ構成を使用しないローカル開発の場合、ランタイムはローカル エージェント構成ディレクトリの下にあるファイル ベースのセッション履歴にフォールバックできます。

サンドボックス実行もセッション対応です。 ランタイムは、明示的なセッション ID なしでサンドボックス ツールを作成するときに、関連のないエージェントの実行間で状態を共有するのではなく、呼び出しに分離セッションを使用します。

組み込みのエンドポイント

ランタイムは、追加のアプリケーション コードなしで、組み込みのデバッグ エンドポイントとコンポジション エンドポイントを公開できます。 開発、テスト、診断には、プライマリ運用アプリケーション インターフェイスとしてではなく、チャット UI とチャット API を使用します。

どのエージェント ファイルでも、フロントマターの builtin_endpoints 設定でオプトインできます。 <AGENT_NAME>ルート セグメントは、表示.agent.mdフィールドではなく、name ファイル名から派生します。 たとえば、 main.agent.md は /agents/main/を使用します。

Azureでホストされている場合、チャット UI はメッセージを送信する前に関数キーの入力を求めます。 このキーを使用して、HTTP チャット API を直接呼び出すこともできます。

az functionapp keys list \
  --resource-group <RESOURCE_GROUP> \
  --name <FUNCTION_APP_NAME> \
  --query "functionKeys.default" \
  --output tsv

x-functions-key ヘッダーまたは code クエリ文字列パラメーターにキーを渡します。 MCP クライアントを接続するには、代わりに MCP 拡張システム キーを取得します。

az functionapp keys list \
  --resource-group <RESOURCE_GROUP> \
  --name <FUNCTION_APP_NAME> \
  --query "systemKeys.mcp_extension" \
  --output tsv

アプリが匿名アクセスを構成しない限り、MCP エンドポイントにはこのシステム キーが必要です。

サーバーレス エージェント ランタイムを使用するタイミング

エージェントがイベントドリブン、ツール豊富、または運用上Azure Functionsワークロードに近い場合は、サーバーレス エージェント ランタイムを使用します。

適切な適合は次のとおりです。

• 集計、監視、調整、またはレポートを行うスケジュールされたバックグラウンド エージェント。
• メッセージ、電子メール、アラート、キュー メッセージ、またはデータの変更に対応するイベント ドリブン アシスタント。
• コネクタを使用して SaaS およびエンタープライズ アプリケーション全体の作業を調整するシステム間エージェント。
• HTTP、チャット UI、または MCP を介して同じエージェントを公開する会話型フロントエンド。
• ゼロにスケーリングし、マネージド ID、監視、デプロイ スロット、およびその他のAzureホスティング機能を使用する必要があるエージェント。

決定論的関数を別の AI クライアントのツールとして公開するだけで済む場合は、Azure Functions MCP 拡張機能の方が適切な出発点となる可能性があります。 詳細については、「 Azure Functions での AI ツールとモデルの使用」を参照してください。

概要

クイックスタートから始めて、チャット エージェント、タイマーによってトリガーされるブログの概要エージェント、モデルのデプロイ、サンドボックス実行、オプションの MCP ツールをコネクタ名前空間から使用してサーバーレス エージェント アプリをデプロイします。

関連するコンテンツ

• Azure Functions
• Azure Functions
• Azure Functions上の MCP サーバーを Foundry Agent Service に接続します
• Flex 従量課金プランのホスティング