Microsoftは2026年6月、Azure FunctionsにAIエージェント向けサーバーレスランタイム（プレビュー）を追加し、.agent.mdファイルというMarkdownファーストのアプローチでエージェント定義を可能にした。

Azure Functions エージェントランタイムとは

これまでAIエージェントを構築するには、オーケストレーション基盤・スケーリング設定・ツール接続などを個別に実装する必要があった。今回プレビュー公開された「Azure Functions サーバーレス エージェント ランタイム」は、この複雑さを一気に解消しようとする試みだ。

最大の特徴は .agent.mdファイルによるエージェント定義。YAML/JSONではなく、読みやすいMarkdown形式でエージェントの振る舞い・ツール・トリガーを記述できる。プロンプトエンジニアリングとコード定義を自然に統合した設計思想であり、AIエージェント開発の敷居を下げる明確なメッセージが込められている。

主な機能

スケールゼロ経済性

Azure Functionsの「使った分だけ払う」モデルをエージェントに適用。エージェントがアイドル状態のときはリソースゼロ、リクエストが来た瞬間に起動する。常時稼働のエージェントサーバーを維持するコストと比較すると、実験フェーズや低頻度ユースケースでの経済性は圧倒的だ。

MCPツールサーバーへのアクセス

MCP（Model Context Protocol）に対応し、外部ツールをエージェントに統合できる。MCPはオープンプロトコルとして業界での採用が広がっており、MicrosoftがこれをAzure Functionsで公式サポートする動きはエコシステム全体にとって重要なシグナルだ。

1400以上のコネクタカタログ

イベントドリブントリガーと組み合わせて、Logic AppsやPower Automateでおなじみの1400以上のコネクタにアクセス可能。SalesforceやSAP、ServiceNowなど既存の業務システムとエージェントを接続するハードルが大幅に下がる。

実務への影響──日本のエンジニア・IT管理者へ

今すぐ試せるポイント:

  • PoCコストが激減: スケールゼロ設計により、エージェントの試験導入で余計なコストを気にせずに済む。まず動かして評価する文化を作りやすい
  • 可読性の高い.agent.md設計: インフラエンジニアでなくても定義ファイルを読み書きできる。開発とビジネス側の会話コストが下がる
  • 既存コネクタ資産の活用: すでにLogic AppsやPower Automateを使っている組織なら、コネクタ知識がそのまま転用できる
  • MCP対応でAIモデルの選択肢が広がる: 特定AIモデルへのロックインを避けながら業務エージェントを構築できる設計になっている

プレビュー段階のため本番利用は慎重に。ただしPoC開始のタイミングとしては今が最適だ。

筆者の見解

Azure Functionsがエージェントランタイムという新たな役割を担いはじめたことは、Microsoftのエージェントプラットフォーム戦略の具体化として注目に値する。

個人的にこの設計で評価しているのは、MCPという業界標準プロトコルを正面から採用している点だ。独自プロトコルで囲い込むのではなく、オープンな標準に乗ることで、Azure上で動かすAIモデルの選択肢をエンジニアに開放している。「エージェントが安全に動くプラットフォームとしてのAzure」というポジションを着実に固めている印象があり、これはMicrosoftが本来持っている強みを最大限に生かした戦略だと思う。

Markdownファースト設計も、開発者体験（DX）への本気度が伝わる。YAMLの深いネストに疲弊したエンジニアには朗報だろう。

一方、プレビュー段階であることは忘れてはならない。スケーリングの挙動やコールドスタートのレイテンシ、MCP接続の安定性など、本番ワークロードで必要な品質水準に達するまでの道のりはある。Microsoftにはここで手を抜かず、早期フィードバックを丁寧に拾い上げてGA品質に仕上げてほしい。エージェント基盤の信頼性こそが、この戦略の生命線になるはずだから。

出典: この記事は Introducing the Azure Functions serverless agents runtime (preview) の内容をもとに、筆者の見解を加えて独自に執筆したものです。