MicrosoftはBuild 2026にて、Azure Functionsのサーバーレスエージェントランタイムをパブリックプレビューとして発表した。これにより、これまでイベント駆動の関数実行基盤として知られていたAzure Functionsが、AIエージェントのホスティング・実行プラットフォームとしての役割を担うことになる。

.agent.mdという新しいプログラミングモデル

今回の最大の特徴は、エージェントの定義を .agent.md というMarkdownファイル一枚で完結させる点だ。従来のエージェントフレームワークではPythonやTypeScriptで複数ファイルにまたがってエージェントを記述するのが一般的だったが、Azure Functionsのアプローチはこれを覆す。

YAMLフロントマターでトリガー種別やメタデータを宣言し、Markdownの本文がそのままエージェントへの指示（システムプロンプト）になる。MCPサーバーの接続設定や追加ツールの定義は mcp.json と agents.config.yaml という補助ファイルに分離されており、構成管理の観点でも整理しやすい。

たとえば「毎日15時にWeb上の技術ニュースを収集してメールで要約を送る」エージェントは、以下のような .agent.md 一枚で実現できる：

name: Daily Tech News Email trigger: type: timer_trigger args: schedule: “0 0 15 * * *”

You are a news assistant. When triggered, fetch today’s top tech news and email a summary to $TO_EMAIL.

Pythonプロジェクトとその依存関係の管理が不要になる。この簡潔さはDevOpsコストの削減に直結する。

対応トリガーとコネクタの広さ

エージェントを起動できるトリガーは既存のHTTP・Timer・Service Bus・Event Hubs・SQL・Cosmos DBに加え、TeamsメッセージやOutlookメール・カレンダーイベント・SharePointアイテムへの接続バックトリガーが新たに追加された。つまり、誰かがTeamsにメッセージを投稿したことをきっかけにエージェントが動き出す、といった業務自動化シナリオが標準で実現できる。

さらに、エージェントからアクセスできるコネクタは 1,400以上。Microsoft 365・Teams・Outlook・SharePoint・Salesforce・ServiceNowなど、企業の主要SaaSが一通りカバーされている。これはPower Automateのコネクタカタログと共通の資産を活用したものだ。

コールドスタートとコスト

実務者が真っ先に気にするであろう2点について、Azure Functionsプロダクトチームは明確に回答している。

コールドスタートについては「エージェントランタイム固有の追加遅延はない。インフラがボトルネックになるのではなく、LLMの推論時間がボトルネックになる」とのことだ。Flex Consumptionプランのスケールtoゼロ特性はそのまま維持される。

コストについては「エージェント税（追加料金）は存在しない」と明言。通常のFunctions実行と同一の秒単位課金モデルが適用される。

実務への影響——日本のエンジニア・IT管理者に向けて

既存のAzure Functions運用スキルがそのまま活きる

Managed Identity認証・Application Insightsによるトレース・Flex Consumptionのスケーリング設定——これらは既存のFunctions開発者がすでに知っているオペレーションモデルだ。エージェント化しても「関数が起動したらエージェントが動く」という概念モデルで理解できる。学習コストを低く抑えながらエージェント運用に踏み込めるのは、実際のシステム移行を担うエンジニアにとって大きなメリットだ。

MCPサーバー連携で社内ツールの自動化が加速

MCPサーバーを .agent.md から直接呼び出せるため、社内APIやデータソースへのアクセスを標準化しやすい。既存のMCP実装資産がある組織は、Azure Functions上のエージェントにそのまま流用できる。

Teams・Outlookトリガーは業務自動化の入り口として有望

Teamsのメッセージや受信メールをトリガーにしてエージェントが動作するモデルは、問い合わせ対応の自動化・承認フロー支援・レポート生成など、日本企業に多い「人手でやっているルーティン作業」の自動化に直接刺さる。Power Automateより低レベルで制御できる分、複雑な条件分岐や外部API連携が絡む処理に向いている。

筆者の見解

Azure Functionsのサーバーレスエージェントランタイムは、Azureプラットフォームが「エージェント時代」に対してどう向き合うかを明確に示した発表だと感じる。

.agent.md というアプローチは特に面白い。コードではなく構造化テキストでエージェントを定義するというモデルは、開発者以外のロールの人間——インフラエンジニアや業務担当者——もエージェントの仕様を読み書きできる世界を想定している。「AIの活用が一部の開発者に閉じない」という設計思想が透けて見える。

Azureをプラットフォームとして使い続けながら、その上で動かすAIの選択肢を広げていく——そういう構成がこれからの標準になっていくと筆者は見ている。今回の発表はその文脈において、Microsoft基盤の長所（スケーリング・認証・可観測性・コネクタ）を損なわずにエージェント化できる具体的な経路を示したという点で、実務に即した意義がある。

Microsoftが本来持っているエンタープライズ統合の強みは、エージェント時代においてもむしろ際立つはずだ。1,400以上のコネクタをベースに、Azureのセキュリティモデルとエージェントを組み合わせた基盤は、他のクラウドプロバイダーにはすぐには真似できないアドバンテージだ。この領域でのリードを、今後もしっかりと育てていってほしい。

出典: この記事は Azure Functions Ships Serverless Agents Runtime at Build 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。