Azure FunctionsでAIエージェントを作りたい開発者にとって、今回の要点は「.agent.mdに自然言語ベースでエージェントを定義し、Azure Functionsのトリガーで起動できるようになった」ことです。2026年6月3日更新の公式情報では、Serverless agents runtime for Azure Functionsがプレビュー段階として案内されており、ホスティング、トリガー、モデル、ツール、セッション履歴、ID、監視を個別につなぎ込むのではなく、FunctionsアプリとしてAIエージェントをデプロイするモデルが示されています。(Microsoft Learn)
ただし、すぐに本番移行すべき機能ではありません。Azure Updatesにおける「In preview」は、非本番での利用・テスト向けの位置づけであり、Microsoft Learnでも機能名、構成名、サポートされるコネクタが一般提供前に変わる可能性があると明記されています。(マイクロソフトアジュール) まずは既存のAzure Functionsを置き換えるのではなく、PoC、社内業務の試作、自動レポート、問い合わせ分類、イベント駆動のAI処理などで評価するのが現実的です。
Azure FunctionsのServerless agents runtimeとは
Serverless agents runtime for Azure Functionsは、Azure Functions上でAIエージェントを「第一級のワークロード」として扱うためのプレビュー機能です。従来のFunctionsがHTTPリクエスト、タイマー、キュー、Blob、Event Grid、Service Busなどのイベントを受けてコードを実行する仕組みだったのに対し、このランタイムではイベントをきっかけにAIエージェントを起動し、モデル推論やツール呼び出しを含む処理を行えます。(Microsoft Learn)
ポイントは、エージェント定義の中心がPythonコードではなく、Markdownファイルになる点です。.agent.mdファイルのYAMLフロントマターでトリガーやモデルなどを指定し、Markdown本文にエージェントへの指示を書きます。ランタイムはその定義を読み込み、Azure Functionsのトリガー登録、ツール構成、セッション履歴、任意の組み込みエンドポイントを処理します。(Microsoft Learn)
たとえば、社内のサポートキューに新しい問い合わせが入ったら、問い合わせ内容を読み取り、顧客情報を参照し、優先度を判定し、対応方針を返すエージェントを作る、といった用途が考えられます。単なるチャットボットではなく、「イベントが来たら動くAI処理」をFunctionsの運用モデルに乗せられるのが大きな変化です。
何が変わるのか
今回の更新で大きく変わるのは、AIエージェント開発の責務分担です。これまでは、エージェントを作る場合でも、実行基盤、トリガー、モデル呼び出し、外部API連携、認証、ログ、セッション管理を個別に設計する必要がありました。Serverless agents runtimeでは、それらをAzure Functionsのアプリ構成としてまとめやすくなります。
| 観点 | これまでの一般的な作り方 | Serverless agents runtimeでの考え方 |
|---|---|---|
| エージェント定義 | コード内にプロンプトやロジックを実装 | .agent.mdでトリガーと指示を定義 |
| 起動方法 | HTTP APIや独自ジョブで起動 | Functionsのトリガーで起動 |
| 外部システム連携 | SDK、REST API、独自認証処理を実装 | MCPサーバー、コネクタ、カスタムPythonツールを利用 |
| セッション履歴 | 独自DBやキャッシュを設計 | AzureWebJobsStorageを使ったBlob Storage保存が可能 |
| 監視 | アプリ側でログ設計 | Functionsの監視機能やApplication Insightsに寄せられる |
| スケール | 実行基盤ごとに設計 | Functionsホスティング機能を利用 |
特に重要なのは、エージェントがAzure Functionsの1つの関数として登録される点です。これにより、スケールルール、マネージドID、ネットワーク、監視など、既存のFunctions運用で使っている考え方をAIエージェントにも適用しやすくなります。(Microsoft Learn)
Azure FunctionsのAI/Copilot更新として見るべきポイント
今回の更新は「Copilotの画面に新機能が増えた」というより、CopilotやAIエージェントで作った処理をAzure Functions上で実行しやすくする基盤の更新です。自然言語で指示を書けるため、開発者はエージェントの役割、入力、出力、ツール利用方針をMarkdownで管理できます。
ただし、自然言語で書けるからといって、設計が不要になるわけではありません。実務では、次の3点を明確にしないと失敗しやすくなります。
| 確認項目 | 決めるべき内容 | 失敗しやすい例 |
|---|---|---|
| いつ起動するか | HTTP、タイマー、キュー、Blob、Event Grid、Service Busなど | すべてHTTPで作り、非同期処理や再実行が扱いづらくなる |
| 何を参照・実行できるか | MCP、コネクタ、カスタムPythonツール、サンドボックス実行 | エージェントに不要なツールまで渡し、意図しない操作範囲が広がる |
| どう監査するか | ログ、Application Insights、実行結果、ツール呼び出し履歴 | 「AIが判断した」で終わり、後から理由を確認できない |
AIエージェントは、プロンプトだけでは業務システムとして成立しません。入力イベント、利用可能なツール、権限、ログ、失敗時の再実行方針まで含めて設計する必要があります。
対応する主な構成ファイル
Serverless agents runtimeのアプリは、通常のFunctionsプロジェクトにエージェント用のファイルを加えたPython Azure Functionsアプリとして構成されます。公式ドキュメントでは、最小構成としてfunction_app.py、host.json、requirements.txt、少なくとも1つの.agent.mdファイルが示されています。(Microsoft Learn)
| ファイル・フォルダー | 主な役割 | 管理上の注意点 |
|---|---|---|
*.agent.md | エージェント定義。YAMLフロントマターで設定し、Markdown本文が指示になる | 1ファイル1エージェント。指示が長くなりすぎる場合は役割を分ける |
agents.config.yaml | モデル、タイムアウト、サンドボックス実行などの既定値 | 環境ごとの差分はアプリ設定に寄せる |
mcp.json | リモートMCPサーバーやコネクタツールの接続定義 | 静的シークレットを保存しない |
tools/ | アプリ固有のカスタムPythonツール | ツール名、説明、型ヒントを明確にする |
skills/ | 再利用可能なSKILL.mdプロンプト資産 | 汎用手順と業務固有手順を分ける |
requirements.txt | ランタイムパッケージとPython依存関係 | 依存ライブラリのバージョン固定を検討する |
infra/ | azdなどで使うIaCファイル | 検証環境と本番想定環境を分ける |
.agent.mdでは、フロントマターにname、description、trigger、model、timeout、builtin_endpoints、mcp、skills、tools、input_schema、response_schemaなどを指定できます。triggerは、組み込みエンドポイントを有効にしない限り必須で、エージェントファイルごとに1つのトリガーのみサポートされます。(Microsoft Learn)
簡略化すると、次のような考え方です。
---
name: Support Triage Agent
description: 新しいサポート問い合わせを分類し、対応優先度と初動案を返す
trigger:
type: queue_trigger
args:
queue_name: support-tickets
connection: AzureWebJobsStorage
timeout: 300
---
あなたはサポート一次対応を支援するエージェントです。
キューに入った問い合わせ内容を読み取り、緊急度、影響範囲、確認すべき追加情報を整理してください。
出力はJSON形式で返し、顧客へ直接送信しないでください。この例で重要なのは、「AIに何でも任せる」のではなく、出力形式、禁止事項、利用目的を明確に書いている点です。実務では、ここに社内の分類基準、SLA、エスカレーション条件を加えると運用品質が上がります。
影響範囲：既存のAzure Functions利用者は何を確認すべきか
既存のAzure Functionsアプリが、今回の更新によって自動的に変更されるわけではありません。影響が出るのは、主に新しくAIエージェント型のFunctionsアプリを作る場合、または既存のAI処理・自動化処理をServerless agents runtimeに寄せる場合です。
| 対象者 | 影響 | まず確認すべきこと |
|---|---|---|
| Azure管理者 | 新しいリソース、ID、権限、監視対象が増える | リソース作成権限、マネージドID、Application Insights、ストレージ設定 |
| Functions開発者 | .agent.md中心の開発モデルが追加される | Python Functions構成、トリガー設定、依存関係、デプロイ方法 |
| AIアプリ開発者 | モデル呼び出しとツール連携をFunctionsに載せやすくなる | モデルプロバイダー、MCP、コネクタ、カスタムツールの境界 |
| セキュリティ担当 | エージェントが外部システムを操作できる可能性がある | 最小権限、シークレット管理、監査ログ、ツールの許可範囲 |
| 運用担当 | 非決定的なAI処理の監視と障害対応が必要になる | ログ粒度、失敗時の再実行、コスト、タイムアウト |
特に、既存のFunctionsが.NET、Node.js、Javaなどで構築されている組織では、「既存アプリに混ぜる」よりも「AIエージェント用のPython Function Appを別アプリとして分ける」ほうが検証しやすいでしょう。プレビュー段階では、既存業務処理と密結合させず、イベントやAPIの境界で接続する構成が安全です。
管理者が確認すべき設定
管理者が最初に見るべきなのは、モデル、ID、ストレージ、コネクタ、監視です。AIエージェントは外部サービスを呼び出せるため、通常のFunctionsよりも権限設計が重要になります。
モデルプロバイダーとアプリ設定
ランタイムはMicrosoft Agent Frameworkを使ってモデルプロバイダーを呼び出し、プレビュー時点ではAzure OpenAI、Azure AI Foundry、OpenAIがサポート対象として示されています。プロバイダーはAZURE_FUNCTIONS_AGENTS_PROVIDERで指定するか、AZURE_OPENAI_ENDPOINT、FOUNDRY_PROJECT_ENDPOINT、OPENAI_API_KEYなどの設定から推論されます。(Microsoft Learn)
管理者は、少なくとも次を確認してください。
| 設定 | 確認内容 |
|---|---|
AZURE_FUNCTIONS_AGENTS_PROVIDER | 利用するモデルプロバイダーを明示するか |
AZURE_OPENAI_ENDPOINT | Azure OpenAIを使う場合のエンドポイント |
AZURE_OPENAI_DEPLOYMENT | 利用するデプロイ名 |
FOUNDRY_PROJECT_ENDPOINT | Azure AI Foundryを使う場合のプロジェクトエンドポイント |
FOUNDRY_MODEL | Foundry側のモデル指定 |
AZURE_FUNCTIONS_AGENTS_MODEL | 共通の既定モデル指定 |
AZURE_CLIENT_ID | ユーザー割り当てマネージドIDを使う場合のID指定 |
本番を見据えるなら、APIキーよりもマネージドIDを優先する設計に寄せるべきです。ただし、Azure OpenAIではAZURE_OPENAI_API_KEYが設定されている場合、マネージドIDではなくキーが使われる点に注意が必要です。(Microsoft Learn)
マネージドIDと権限
ランタイムは、Microsoft Entra認証をサポートするAzureリソースに対してマネージドIDを使用できます。モデルプロバイダー、Azure Container Appsの動的セッション、コネクタ名前空間でホストされるMCPサーバー、Blobベースのセッション履歴では、それぞれID指定の場所が異なります。(Microsoft Learn)
よくある失敗は、Function AppのマネージドIDだけを有効化して安心してしまうことです。実際には、接続先ごとにロール割り当てや許可設定が必要です。MCPサーバー、コネクタ、セッションプール、ストレージのどこでどのIDが使われるのかを、デプロイ前に表で整理しておくとトラブルを減らせます。
セッション履歴とストレージ
複数ターンの対話ではセッション履歴が必要になります。Azure上では、ランタイムはFunction AppのAzureWebJobsStorageアカウントを使ってBlob Storageにセッション履歴を保存します。(Microsoft Learn)
ここで確認すべきなのは、保存先のストレージアカウントにどのようなデータが残るかです。問い合わせ内容、ユーザー入力、エージェント応答、ツール呼び出しに関する情報が含まれる可能性があるため、個人情報や機密情報を扱う場合は、保存期間、アクセス制御、監査ログ、データ削除方針を事前に決めておきましょう。
MCPとコネクタのシークレット管理
リモートMCPサーバーを使う場合は、Function Appプロジェクトのルートにmcp.jsonを追加します。公式ドキュメントでは、mcp.jsonに静的シークレットを保存しないこと、コネクタMCPツールでもユーザーシークレットを保存しないことが示されています。(Microsoft Learn)
MCPやコネクタは便利ですが、エージェントに「実行できる操作」を与える仕組みでもあります。メール送信、Teams操作、レコード更新などの副作用があるツールは、検証段階では送信先や操作対象を限定してください。たとえばメール送信を試す場合は、外部宛てを許可せず、自分または検証用グループに限定するのが安全です。
開発者が確認すべき実装ポイント
開発者は、まず「コードで全部書く」のではなく、エージェント定義、共通設定、ツールを分けて考える必要があります。
| 実装要素 | 書く場所 | 判断基準 |
|---|---|---|
| エージェントの役割・指示 | .agent.md | 自然言語で説明できる処理 |
| トリガー設定 | .agent.mdのフロントマター | 何をきっかけに起動するか |
| モデルやタイムアウトの既定値 | agents.config.yaml | 複数エージェントで共通化したい設定 |
| 外部ツール接続 | mcp.json | 他サービスのMCPサーバーやコネクタを使う場合 |
| 業務固有ロジック | tools/のPythonファイル | 顧客検索、チケット作成、社内DB照会など |
| 再利用プロンプト | skills/ | 複数エージェントで共通する手順や判断基準 |
カスタムPythonツールでは、ツール名、説明、型ヒント、Pydanticのフィールド説明が、モデルがいつどのようにツールを呼び出すかを判断する助けになります。依存パッケージは通常のAzure Functionsアプリと同じくrequirements.txtに追加します。(Microsoft Learn)
実務では、ツールの説明を曖昧にしないことが重要です。たとえばupdate_customerという名前だけでは、モデルがいつ呼ぶべきか判断しづらくなります。update_customer_contact_preferenceのように用途を限定し、説明にも「本人確認済みの場合のみ連絡設定を更新する」といった条件を書くと、意図しない呼び出しを減らせます。
移行を考えるべきケース、考えなくてよいケース
Serverless agents runtimeは魅力的ですが、すべてのAzure Functions処理を移行する必要はありません。移行を考えるべきなのは、処理の中に「自然言語の理解」「判断」「要約」「複数ツールの使い分け」が含まれる場合です。
| 既存処理 | 移行判断 |
|---|---|
| JSONを受け取り、DBに保存するだけのHTTP Function | 移行不要。従来のFunctionsで十分 |
| 毎朝レポートを集計し、要約文を作る処理 | 検証候補。タイマートリガー型エージェントに向く |
| キューに入った問い合わせを分類し、担当チームを推定する処理 | 検証候補。キュー起動とAI判断の相性がよい |
| 決まった計算だけを行うバッチ | 移行不要。AIを入れる理由が薄い |
| 複数SaaSを横断して状況確認し、対応案を作る処理 | 検証候補。MCPやコネクタ活用の価値がある |
| 本番で厳密な再現性が必要な承認・課金処理 | 慎重に判断。AIの出力を直接確定処理に使わない |
公式ドキュメントでも、イベントドリブン、ツール利用が多い、Azure Functionsの運用モデルに近いエージェントに適している一方、決定論的な関数を別のAIクライアントのツールとして公開するだけならAzure Functions MCP拡張機能のほうが出発点として適している可能性があると説明されています。(Microsoft Learn)
つまり、移行判断の基準は「AIエージェントとして動かす意味があるか」です。単に新機能だから使うのではなく、従来のコードだけでは扱いづらい曖昧な入力、文章要約、判断支援、複数ツールの選択があるかを見てください。
展開前に確認したいチェックリスト
プレビュー段階で展開するなら、次のチェックを済ませてから検証環境に出すのがおすすめです。
| 項目 | 確認内容 |
|---|---|
| 環境 | 本番とは別のリソースグループ、サブスクリプション、または検証用環境か |
| コスト | Flex Consumption、モデル、Foundry、ストレージ、Container Apps動的セッション、コネクタの課金を見積もったか |
| 権限 | Function App、MCP、コネクタ、ストレージ、セッションプールのIDとロールを整理したか |
| 入力制御 | HTTP入力やキューメッセージのスキーマを定義したか |
| 出力制御 | JSON Schemaや応答例で出力形式を縛ったか |
| ツール制御 | エージェントごとに使えるMCP、skills、toolsを制限したか |
| ログ | Application Insightsで実行、モデル、ツール呼び出しを追えるか |
| セキュリティ | mcp.jsonやリポジトリにシークレットを入れていないか |
| 削除手順 | PoC終了後にazd downなどで関連リソースを削除できるか |
| 変更耐性 | プレビュー仕様変更に備え、既存本番処理と疎結合にしているか |
クイックスタートのテンプレートは、Flex Consumption Function App、ストレージ、監視、Microsoft Foundryプロジェクト、モデルデプロイ、Azure Container Apps動的セッションプール、必要なID割り当てをプロビジョニングします。メール配信を有効にした場合は、Connector Namespace、Microsoft 365 Outlook接続、コネクタ用のマネージドMCPサーバーも作成されます。(Microsoft Learn) そのため、軽い試用でも複数リソースが作られる前提で、検証後の削除まで含めて計画しましょう。
試す場合の基本手順
まずは公式クイックスタートのサンプルをそのまま動かし、構成ファイルの役割を理解するのが近道です。クイックスタートでは、azdを使ってサーバーレスエージェントをAzure Functionsにデプロイする流れが示されています。(Microsoft Learn)
azd init --template Azure-Samples/functions-quickstart-serverless-agents-azd -e serverless-agentsメール送信まで試す場合は、受信者アドレスを環境変数として設定します。
azd env set TO_EMAIL <[email protected]>その後、AzureリソースのプロビジョニングとFunction Appのデプロイを行います。
azd upTO_EMAILを設定した場合、Microsoft 365 Outlook接続とマネージドMCPサーバーを使うConnector Namespaceが作成されます。エージェントがメールを送信する前に、メール送信可能なMicrosoft 365アカウントで接続を承認する必要があります。(Microsoft Learn)
デプロイ後は、デバッグ用チャットUIにアクセスしてFunction Keyを入力し、動作を確認できます。ただし、公式ドキュメントではチャットUIやチャットAPIは開発、テスト、診断向けであり、主要な本番アプリケーションインターフェイスとして使うものではないと説明されています。(Microsoft Learn)
検証後は、不要なリソースを残さないように削除します。
azd downよくある失敗と回避策
.agent.mdに業務ルールを書きすぎる
エージェントへの指示を1つのMarkdownに詰め込みすぎると、保守しづらくなります。共通手順はskills/へ、外部システム操作はtools/やMCPへ、モデルやタイムアウトの既定値はagents.config.yamlへ分けるのが基本です。
すべてのツールを全エージェントに渡す
エージェントは、使えるツールが多いほど賢くなるとは限りません。不要なMCPサーバーやカスタムツールを渡すと、誤ったツール選択や意図しない操作につながります。エージェントごとにmcp、skills、toolsの利用可否や除外設定を見直してください。
デバッグ用エンドポイントを本番UIとして使う
組み込みのチャットUIやチャットAPIは便利ですが、テスト・診断向けです。本番でユーザーに公開する場合は、認証、認可、レート制限、入力検証、監査ログ、エラー処理を備えたアプリケーション層を別途設計する必要があります。
コネクタの承認を忘れる
Microsoft 365 Outlookなどのコネクタを使う場合、リソースを作っただけでは操作できません。接続を承認し、Function AppのマネージドIDがMCPサーバーを呼び出せる状態にする必要があります。(Microsoft Learn)
コストを見ずにPoCを放置する
サンプルは複数のAzureリソースを作成します。公式クイックスタートでも、Flex Consumptionプランと関連Azureリソースの利用により小さなコストが発生する可能性があると案内されています。(Microsoft Learn) PoC用のタグ付け、予算アラート、削除手順をセットで用意しましょう。
まず取るべきアクション
今回のServerless agents runtime for Azure Functionsは、Azure FunctionsをAIエージェント実行基盤として使いやすくする重要なプレビューです。特に、タイマー実行、キュー処理、イベント応答、SaaS連携、問い合わせ分類、レポート要約のように「イベントをきっかけにAIが判断・要約・操作する」用途と相性があります。
一方で、プレビュー段階である以上、既存の本番Functionsを急いで置き換える必要はありません。まずは次の順番で進めるのが安全です。
- 既存業務の中から、AI判断が入る小さなイベント駆動処理を1つ選ぶ
- 本番とは分離した検証環境でクイックスタートを動かす
.agent.md、agents.config.yaml、mcp.json、tools/の役割を確認する- マネージドID、ストレージ、Application Insights、コネクタ承認を整理する
- PoC結果を見て、本番採用するか、従来のFunctionsやMCP拡張で十分かを判断する
AIエージェントは「自然言語で書ける」ことよりも、「どのイベントで起動し、どの権限で、どのツールを使い、どのログを残すか」が重要です。Azure Functionsの運用モデルに合わせて小さく試し、仕様変更に備えて疎結合にしておくことが、今回のプレビュー機能を安全に評価するための最短ルートです。
コメント