Azure Functions | The .NET Blog

Microsoft Agent Frameworkにおける永続的ワークフロー：In-MemoryからAzure Functionsへ

Emiliano Montesdeoca — Sun, 31 May 2026 00:00:00 +0000

初期のAIエージェントワークフローの問題点のひとつ：脆弱性です。単一プロセスに縛られた長時間実行のマルチステップワークフローは、プロセス再起動 = 状態喪失を意味します。シンプルなデモには問題ありませんが、本番ワークロードには向きません。

Microsoft Agent FrameworkのワークフロープログラミングモデルがAzure Functionsホスティングでのdurable task フレームワークによる永続的実行をサポートするようになりました。プログラミングモデルの仕組みと、永続性の重要性について説明します。

基本的な構成要素

Executorは作業の基本単位です。各Executorは型付きで、特定の入力を受け取り、特定の出力を生成します：

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // 注文を検索して返す
 return new Order(Id: message.OrderId, ...);
 }
}

WorkflowはFluentビルダーを使ってExecutorを有向グラフに接続します。フレームワークが実行、ステップ間のデータフロー、エラー伝播を処理します。

モデル化できるもの：

順次チェーン（ステップA → ステップB → ステップC）
並列Fan-out/Fan-in（エージェントA、B、Cを並列実行して結果を集約）
条件分岐
ヒューマン・イン・ザ・ループ承認（ワークフローを一時停止して外部シグナルを待機）

ローカル開発用In-Memoryランナー

開始は素早くできます：

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

コアパッケージには軽量なインプロセスランナーが含まれています。外部依存関係なし、データベースなし、Azureリソースなし。ローカル開発とユニットテストに最適です。

Durable Taskで永続性を追加

ワークフローがプロセス再起動を乗り越える必要がある場合 — 長時間実行だから、ヒューマン・イン・ザ・ループステップがあるから、多くの並列エージェント呼び出しに分散するから — In-Memoryランナーでは不十分です。

MAFのDurable Task統合はワークフロー状態をAzure Storageに保存します。プロセスが再起動しても、ワークフローは中断した場所から再開されます。プログラミングモデルは変わりません。ランナーを入れ替えるだけです。

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

同じExecutor、同じワークフローグラフ — 永続的な状態に支えられています。

Azure Functionsホスティング

3番目の層はAzure Functionsホスティングです。ワークフローはFunctionアプリになります：HTTPエンドポイントでワークフローをトリガーし、永続的ランタイムがスケーリング、状態、信頼性を管理します。

これにより、並列呼び出し、条件分岐、ヒューマン承認を持つマルチエージェントワークフローが、カスタム状態管理なしでサーバーレスFunctions環境でスケールできます。

なぜこれが重要か

この組み合わせは本番AIシステムにとって重要です：

並列エージェント呼び出し — ブロックなしで複数の専門エージェントに同時に分散し、全員が完了したら結果を集約
長時間実行プロセス — ヒューマン承認や外部イベントを含むワークフローが時間や日をまたいで一時停止・再開できる
スケーリング — Azure Functionsが実行を水平スケール；Durable Taskフレームワークが並列状態の調整を管理

シンプルなローカルデモを超えたMAFワークフローを構築するなら、これが本番品質の実行への道筋です。

元の投稿：Durable Workflows in the Microsoft Agent Framework

苦しんでいる依存関係を叩き続けるのをやめよう：Azure Functions + Service Bus のリトライパターン

Emiliano Montesdeoca — Thu, 21 May 2026 00:00:00 +0000

Functions アプリで回復可能な障害がサービス停止に変わる経緯はこうです：依存関係がタイムアウトし始め、すべての Functions インスタンスが即座に無限にリトライし、依存関係は数百の同時失敗リクエストで叩かれ、一時的な問題として始まったものがシステム全体のバックプレッシャーイベントになります。

この話はご存知でしょう。Azure Functions は素早くスケールアウトします — それが目的です。しかし、「素早くスケールアウト」と「即座にリトライ」が合わさると、障害を劇的に悪化させる可能性があります。

2つのパターンが役立ちます。指数バックオフとサーキットブレーカー。両方が、Service Bus でトリガーされる Azure Functions でネイティブサポートされるようになりました。

2つのパターン、異なる役割

これらのパターンは補完的で、代替ではありません：

指数バックオフは答えます：いつリトライすればよいか？ 依存関係が回復する時間を確保するためにリトライ間の遅延を増加させます。メッセージレベルで、リトライタイミングを調整します。

サーキットブレーカーは答えます：今この依存関係を呼び出すべきか？ 障害のしきい値に達した後、不健全な依存関係への繰り返し呼び出しを停止し、クールダウン期間後に慎重に調査します。システムレベルで、リトライストームを防ぎます。

両方が必要です。バックオフはメッセージごとのリトライペーシングを処理します。サーキットブレーカーは集合的な健全性の決定を処理します。

Service Bus に特に重要な理由

キューはバーストトラフィックを吸収します、これは良いことです。しかし制御がなければ、ワーカーが失敗する呼び出しに計算リソースを無駄にし続ける間、キューが成長する可能性があります。ポイズンメッセージは、あるべき時間より長くアクティブのままです。ホットパーティションや下流の容量制限がカスケード問題を生み出します。

より安全な設計：

一時的な障害を検出する
指数バックオフで次の試行を遅らせる
障害しきい値に達したら依存関係への呼び出しを停止する（サーキットオープン）
クールダウン期間後に慎重に再開する（サーキット調査）
回復不能な作業を dead-letter または隔離パスに移動する

ネイティブサポートの外観

新しいサポートは既存の Azure Functions ホストモデルと統合されます — 追加ライブラリなし、カスタム実装なし。設定は host.json に入ります：

{
 "extensions": {
 "serviceBus": {
 "messageHandlerOptions": {
 "maxRetryCount": 5,
 "retryPolicy": {
 "mode": "exponentialBackoff",
 "minBackoff": "00:00:02",
 "maxBackoff": "00:05:00",
 "maxRetryCount": 5
 }
 }
 }
 }
}

サーキットブレーカーの設定は、不健全な依存関係が回復中に叩かれないよう、障害のしきい値とリセット間隔を設定します。

対応言語

これは .NET だけではありません。この機能は dotnet、JavaScript、TypeScript、Python をカバーします — Azure Functions の Service Bus トリガーでサポートされる言語の完全セットです。

まとめ

リトライパターンを設定するのは、下流の停止が発生して Functions が問題をより悪化させてしまう最初の事態が起きるまで、退屈に感じるものです。これを積極的に設定するのは安価です。インシデント中に改修するのはそうではありません。

元の投稿：Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

Azure FunctionsのMCPサーバーをFoundryエージェントに接続する方法

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。原文はこちらをご覧ください。

MCPエコシステムで私が大好きなことがあります：サーバーを一度構築すれば、どこでも動作するということです。VS Code、Visual Studio、Cursor、ChatGPT — すべてのMCPクライアントがあなたのツールを発見して使用できます。そして今、Microsoftはそのリストにもう一つの消費者を追加しています：Foundryエージェントです。

Azure SDKチームのLily Maが、Azure FunctionsにデプロイされたMCPサーバーをMicrosoft Foundryエージェントに接続する実践ガイドを公開しました。すでにMCPサーバーをお持ちなら、これは純粋な付加価値です — 再構築は不要です。

この組み合わせが理にかなう理由

Azure Functionsは、MCPサーバーのホスティングにスケーラブルなインフラ、組み込みの認証、サーバーレス課金を提供します。Microsoft Foundryは、推論、計画、行動ができるAIエージェントを提供します。この2つを接続すると、カスタムツール — データベースのクエリ、ビジネスAPIの呼び出し、バリデーションロジックの実行 — がエンタープライズAIエージェントが自律的に発見して使用できる機能になります。

重要なポイント：MCPサーバーはそのままです。Foundryをもう一つの消費者として追加するだけです。VS Codeのセットアップで動作している同じツールが、チームや顧客が対話するAIエージェントを動かすようになります。

認証オプション

ここが記事の真価が発揮されるところです。シナリオに応じた4つの認証方法：

方法	ユースケース
キーベース（デフォルト）	開発またはEntra認証なしのサーバー
Microsoft Entra	マネージドIDによる本番環境
OAuthアイデンティティパススルー	各ユーザーが個別に認証する本番環境
認証なし	開発/テストまたは公開データのみ

本番環境では、エージェントIDを使用したMicrosoft Entraが推奨パスです。OAuthアイデンティティパススルーは、ユーザーコンテキストが重要な場合に使用します — エージェントがユーザーにサインインを求め、各リクエストがユーザー自身のトークンを運びます。

セットアップ

大まかな流れ：

MCPサーバーをAzure Functionsにデプロイ — .NET、Python、TypeScript、Javaのサンプルが利用可能
Function Appで組み込みMCP認証を有効化
エンドポイントURLを取得 — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
FoundryにMCPサーバーをツールとして追加 — ポータルでエージェントに移動し、新しいMCPツールを追加、エンドポイントとクレデンシャルを提供

その後、Agent Builderのプレイグラウンドでツールをトリガーするプロンプトを送信してテストします。

私の見解

ここでのコンポーザビリティの話は本当に強力になっています。MCPサーバーを.NET（またはPython、TypeScript、Java）で一度構築し、Azure Functionsにデプロイすれば、すべてのMCP互換クライアントが使用できます — コーディングツール、チャットアプリ、そして今やエンタープライズAIエージェント。実際に機能する「一度書いて、どこでも使う」パターンです。

特に.NET開発者にとって、Azure Functions MCP拡張機能がこれを簡単にしてくれます。ツールをAzure Functionsとして定義し、デプロイすれば、Azure Functionsが提供するすべてのセキュリティとスケーリングを備えた本番グレードのMCPサーバーが手に入ります。

まとめ

Azure FunctionsでMCPツールを実行している場合、Foundryエージェントへの接続はクイックウィンです — カスタムツールが適切な認証付きでエンタープライズAI機能になり、サーバー自体のコード変更は不要です。

各認証方法のステップバイステップの手順は完全ガイドを、本番セットアップについては詳細ドキュメントをご覧ください。

MCP AppsにFluent APIが登場 — .NETでリッチなAIツールUIを3ステップで構築

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。原文はこちらをご覧ください。

MCPツールはAIエージェントに機能を与えるのに最適です。でも、ツールがユーザーに何かを表示する必要がある場合はどうでしょう？ダッシュボード、フォーム、インタラクティブなビジュアライゼーション。そこで登場するのがMCP Appsで、構築がずっと簡単になりました。

Azure SDKチームのLilian Kasemが、.NET Azure Functions上のMCP Apps向け新しいFluent設定APIを発表しました。なぜ最初からこんなにシンプルじゃなかったのかと思うような、開発者体験の改善です。

MCP Appsとは？

MCP AppsはModel Context Protocolを拡張し、ツールが独自のUIビュー、静的アセット、セキュリティコントロールを持てるようにします。テキストを返すだけでなく、MCPツールは完全なHTMLエクスペリエンスをレンダリングできます — インタラクティブなダッシュボード、データビジュアライゼーション、設定フォーム — すべてAIエージェントから呼び出し可能で、MCPクライアントを通じてユーザーに表示されます。

問題は、これらを手動で配線するにはMCP仕様を深く理解する必要があったことです：ui:// URI、特殊なMIMEタイプ、ツールとリソース間のメタデータ調整。難しくはないけど、面倒でした。

Fluent APIの3ステップ

ステップ1：関数を定義する。 標準的なAzure Functions MCPツール：

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

ステップ2：MCP Appに昇格させる。 プログラムのスタートアップで：

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

ステップ3：HTMLビューを追加する。 必要なUIでassets/hello-app.htmlを作成します。

以上です。Fluent APIがMCPプロトコルの配管をすべて処理します — 合成リソース関数の生成、正しいMIMEタイプの設定、ツールとビューを接続するメタデータの注入。

APIの設計が秀逸

特に気に入っている点がいくつかあります：

ビューソースが柔軟。 ディスク上のファイルからHTMLを提供したり、自己完結型デプロイのためにリソースをアセンブリに直接埋め込んだりできます：

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSPがコンポーザブル。 最小権限の原則に従い、アプリが必要とするオリジンを明示的に許可します。WithCspを複数回呼び出すとオリジンが蓄積されます：

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

可視性制御。 ツールをLLMのみ、ホストUIのみ、または両方に表示できます。UIのみをレンダリングし、モデルから呼び出されるべきでないツールが欲しい場合は簡単：

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

始め方

プレビューパッケージを追加：

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

すでにAzure FunctionsでMCPツールを構築している場合、これはパッケージの更新だけです。コンセプトが初めての方はMCP Appsクイックスタートが最適な出発点です。

まとめ

MCP AppsはAIツーリング分野で最もエキサイティングな開発の一つです — 物事を行うだけでなく、ユーザーに物事を見せることができるツール。Fluent APIはプロトコルの複雑さを取り除き、重要なことに集中させてくれます：ツールのロジックとそのUI。

完全なAPIリファレンスと例については完全な記事をお読みください。