Azure FunctionsでAIエージェントを扱う開発者にとって、2026年5月7日時点で確認すべきポイントは明確です。Durable Workflows in the Microsoft Agent Frameworkにより、Microsoft Agent Frameworkで作成したAIエージェントのワークフローを、Durable Task runtimeで永続化し、最終的にAzure Functions上でサーバーレス実行しやすくなりました。
結論から言うと、これは既存のAzure Functionsアプリが自動的に変わる更新ではなく、AIエージェントの処理を「一回限りの呼び出し」から「失敗しても復旧できる長時間ワークフロー」へ発展させるための実装パターンです。コンソールアプリで始めたワークフロー定義を大きく変えずに、状態保存、チェックポイント、並列エージェント実行、Human-in-the-Loop、MCPツール化、Azure Functionsホスティングへ拡張できる点が重要です。Microsoft Agent Frameworkは、AIエージェントの構築・オーケストレーション・デプロイを目的としたオープンソースのマルチ言語フレームワークで、ワークフローではExecutorを有向グラフとしてつなぎ、順次処理、並列処理、条件分岐、人間承認などを表現できます。(Microsoft for Developers)
Azure FunctionsのAI/Copilot連携で何が変わるのか
今回の要点は、Microsoft Agent FrameworkのワークフローをAzure Functionsへ載せることで、AIエージェント処理をサーバーレスかつ耐障害性のある実行基盤に近づけられることです。
従来の単純なAI呼び出しでは、プロセス再起動、タイムアウト、途中失敗、承認待ち、複数エージェントの並列実行をどう扱うかが課題になりがちでした。Durable Workflowsでは、Durable Task runtimeを使ってワークフローの進行状況を保存し、完了済みのステップを再実行せずに復旧できる構成を取れます。公式ブログでは、インメモリ実行ではプロセス終了時に状態が失われる一方、Microsoft.Agents.AI.DurableTaskを追加すると、状態を保持した実行、自動チェックポイント、分散実行、長時間オーケストレーション、監視が可能になると説明されています。(Microsoft for Developers)
Azure Functionsで重要なのは、Microsoft.Agents.AI.Hosting.AzureFunctionsパッケージがMicrosoft Agent FrameworkのワークフローとAzure Functions runtimeを橋渡しする点です。登録したワークフローにはHTTPトリガーが自動生成され、ワークフローはorchestrator function、各Executorはactivity functionとして扱われます。これにより、手作業でコントローラーやルーティングを作り込まずに、AIワークフローをFunctions上で起動できるようになります。(Microsoft for Developers)
| 変更点 | これまで課題になりやすかったこと | Durable Workflowsでの整理 |
|---|---|---|
| 状態管理 | AI処理の途中でFunctionsインスタンスが再起動すると状態を失いやすい | Durable Task Schedulerで進行状況や履歴を保持 |
| 実行単位 | 1回のHTTP呼び出しに処理を詰め込みがち | Executorをステップ化し、ワークフローとして管理 |
| 並列処理 | 複数AIエージェントの結果集約を個別実装する必要がある | fan-out / fan-inで並列実行と集約を表現 |
| 人間承認 | 承認待ちの状態保持や再開処理が複雑 | RequestPortや外部イベントで待機・再開を扱える |
| Copilot/MCP連携 | AIエージェントから既存処理を呼び出す口が分散しやすい | ワークフローをMCPツールとして公開できる |
| 運用監視 | どのステップで止まったか分かりにくい | DTS DashboardやApplication Insightsで確認しやすい |
影響範囲：誰が確認すべきか
影響を受けるのは、すべてのAzure Functions利用者ではありません。主な対象は、Azure Functions上でAIエージェント、Azure OpenAI、Microsoft Agent Framework、Durable Functions、MCP連携を組み合わせようとしている開発チームです。
特に確認すべきなのは、次のようなケースです。
| 対象 | 確認すべき理由 |
|---|---|
| Azure Functions開発者 | ConfigureDurableWorkflowsや自動生成されるHTTPエンドポイントの動作を理解する必要がある |
| AIエージェント開発者 | 単体のAgent呼び出しではなく、複数Agentの順次・並列・条件分岐を設計する必要がある |
| Azure管理者 | Durable Task Scheduler、Function App、認証、監視、ネットワーク、コストを確認する必要がある |
| セキュリティ担当者 | MCPツール、HTTPトリガー、承認レスポンス用エンドポイントの公開範囲を確認する必要がある |
| 既存のDurable Functions利用者 | オーケストレーションのバージョン管理、実行中インスタンスへの影響を確認する必要がある |
一方で、単発のHTTPトリガーでAzure OpenAIを呼び出すだけの小規模アプリや、状態を保持しないチャットボットであれば、すぐにDurable Workflowsへ移行する必要はありません。長時間実行、承認待ち、複数エージェントの協調、障害復旧、監査性が必要になった段階で検討するのが現実的です。
まず理解したい構成要素
Durable Workflows in the Microsoft Agent Frameworkは、複数の技術を組み合わせて成立します。名前が似ているため、最初に役割を分けて理解しておくと実装ミスを減らせます。
| 構成要素 | 役割 | 実務上の見方 |
|---|---|---|
| Microsoft Agent Framework | AIエージェントやワークフローを構築するフレームワーク | AgentやExecutorを定義するアプリケーション側の土台 |
| Executor | ワークフロー内の1ステップ | 注文確認、分類、承認依頼、メール送信などの処理単位 |
| WorkflowBuilder | Executor同士をつなぐ定義 | 順次処理、分岐、並列処理をコードで表現する |
| Durable Task runtime | ワークフローを永続的に実行する仕組み | 再起動・障害・長時間実行への備え |
| Durable Task Scheduler | 状態保存、履歴、スケジューリング、監視を担うバックエンド | 本番運用ではリージョン、権限、クォータ、監視対象になる |
| Azure Functions hosting package | ワークフローをAzure Functions上でホストする橋渡し | HTTP起動、orchestrator/activity生成、サーバーレス運用に関係する |
Microsoft Learnでは、Durable Taskは状態永続化、自動復旧、分散協調を扱うワークフロー技術であり、Durable Functions、Durable Task SDK、Durable Task Scheduler、AIエージェント向けパターンを含むと説明されています。(Microsoft Learn)
実装の流れ：コンソールアプリからAzure Functionsへ段階的に拡張する
実務では、最初からAzure Functions本番環境に載せるより、段階的に進める方が安全です。
まずはインプロセスでワークフローを作る
最初は.NETのコンソールアプリで、Microsoft.Agents.AIとMicrosoft.Agents.AI.Workflowsを追加し、ExecutorとWorkflowBuilderで処理の流れを作ります。
例えば、注文キャンセル処理なら次のような流れです。
OrderLookup → OrderCancel → SendEmailこの段階では、まだ永続化やAzure Functionsの設定は必要ありません。狙いは、AIエージェントや業務処理をどの粒度のExecutorに分けるかを確認することです。
Durable Task runtimeで永続化する
次に、Microsoft.Agents.AI.DurableTaskを追加し、Durable Task Schedulerに接続します。公式ブログでは、ローカル開発用にDTS emulatorをDockerで起動し、8080をScheduler endpoint、8082をDashboard UIとして使う例が示されています。(Microsoft for Developers)
重要なのは、ワークフロー定義そのものを変えずに、実行基盤をインメモリからDurable Task runtimeへ切り替えるという考え方です。これにより、完了済みステップのチェックポイント、障害復旧、実行履歴の確認がしやすくなります。
Azure Functionsでホストする
Azure Functionsへ載せる場合は、FunctionsアプリのProgram.csでConfigureDurableWorkflowsを呼び出します。
using Microsoft.Agents.AI.Hosting.AzureFunctions;
using Microsoft.Agents.AI.Workflows;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.Hosting;
using IHost app = FunctionsApplication
.CreateBuilder(args)
.ConfigureFunctionsWebApplication()
.ConfigureDurableWorkflows(workflows => workflows.AddWorkflow(cancelOrder))
.Build();
app.Run();登録されたワークフローは、例えば次のようなHTTPエンドポイントから起動できます。
POST http://localhost:7071/api/workflows/CancelOrder/run
Content-Type: text/plain
12345この呼び出しは非同期でオーケストレーションを開始し、202 Acceptedとrun IDを返します。同期的に結果を待ちたい場合は、x-ms-wait-for-response: trueヘッダーを使う例も示されています。(Microsoft for Developers)
並列AIエージェントとHuman-in-the-Loopで使い道が広がる
Durable Workflowsが実務で効くのは、単にAIを呼ぶだけでなく、複数の判断を組み合わせる場面です。
fan-out / fan-inで複数エージェントを並列実行する
例えば、問い合わせ内容を「技術観点」「契約観点」「セキュリティ観点」の3つのAIエージェントに並列で確認させ、最後に集約する構成が考えられます。
この場合、順番に3回呼び出すと待ち時間が増えますが、fan-out / fan-inなら並列実行できます。公式ブログでも、物理・化学の専門エージェントを並列に動かし、Aggregatorで結果をまとめる例が紹介されています。完了済みのエージェント応答はチェックポイントされるため、途中でプロセスが再起動しても完了済みステップを再実行しにくくなります。(Microsoft for Developers)
ただし、並列化は必ずしもコスト削減ではありません。AIモデルを複数回呼ぶため、トークン使用量やレート制限に注意が必要です。DTS Dashboardでは会話履歴、タイムライン、プロンプト、レスポンス、トークン使用量などを確認できるため、PoC段階から監視対象に入れておくべきです。(Microsoft Learn)
Human-in-the-Loopで承認待ちを扱う
経費精算、契約レビュー、コンテンツ公開、インシデント対応などでは、AIが下書きや判定をしても、最後に人間の承認が必要になることがあります。
Microsoft Agent Frameworkのワークフローでは、RequestPortを使って外部からの入力を待つパターンを表現できます。Azure Functionsでホストすると、承認待ちの確認やレスポンス送信用のHTTPエンドポイントが自動生成される例が示されています。(Microsoft for Developers)
実務では、承認用エンドポイントを公開するだけでなく、次の点を必ず設計してください。
| 確認項目 | 具体的に見ること |
|---|---|
| 承認者の認証 | Function keyだけで十分か、Entra ID連携や社内ポータル経由にするか |
| run IDの管理 | 承認対象のワークフローと承認画面を正しく紐付けられるか |
| タイムアウト | 24時間、3営業日など、承認期限を業務ルールとして定義するか |
| 監査ログ | 誰が、いつ、何を承認したかを残せるか |
| 再送・重複 | 同じ承認レスポンスが複数回来ても安全に処理できるか |
MCPツール化でCopilotや他のAIエージェントから呼び出せる
今回の更新で見逃せないのが、ワークフローをMCPツールとして公開できる点です。exposeMcpToolTrigger: trueを指定すると、Functions hostが/runtime/webhooks/mcpにリモートMCPエンドポイントを生成し、登録されたワークフローをツールとして扱えるようになります。公式ブログでは、MCP互換クライアントやGitHub CopilotのようなIDE拡張から利用できる可能性が示されています。(Microsoft for Developers)
ただし、MCPツール化は便利な一方で、公開範囲を誤るとリスクが高くなります。例えば「顧客情報を検索する」「注文をキャンセルする」「社内文書を要約する」といったワークフローをMCPツールとして公開する場合、AIエージェントが実行できる操作範囲を明確に制限する必要があります。
特に本番環境では、次の設計を省略しないでください。
- ワークフロー名と説明文に、AIが誤解しにくい具体的な用途を書く
- 破壊的操作は人間承認を挟む
- 入力値の検証をExecutor側で行う
- ツール呼び出しのログをApplication InsightsやDTS Dashboardで追跡する
- 社外公開が不要な場合はネットワーク制限や認証で保護する
管理者が確認すべき設定
Azure Functions管理者は、コードだけでなく、実行基盤・認証・監視・ネットワークを確認する必要があります。
| 項目 | 確認ポイント | 失敗しやすい点 |
|---|---|---|
| NuGetパッケージ | Microsoft.Agents.AI.Hosting.AzureFunctionsなど必要パッケージを確認 | サンプルのバージョンや--prerelease指定をそのまま本番採用してしまう |
| Functions Worker | .NET Azure FunctionsではWorkerパッケージ要件を確認 | 古いWorkerで動かそうとして起動エラーになる |
| App settings | AZURE_OPENAI_ENDPOINT、AZURE_OPENAI_DEPLOYMENT、DTS接続情報、Task Hub名 | ローカル設定をAzureへ反映し忘れる |
| 認証 | Managed Identity、Function key、Entra ID、RBAC | 開発用のDefaultAzureCredential前提で本番化する |
| ローカル開発 | AzuriteとDTS emulatorを起動 | DTSだけ起動してAzure Functions側のStorage依存を忘れる |
| 監視 | DTS Dashboard、Application Insights、ログ相関 | AI応答だけ見て、ワークフローの停止箇所を追跡できない |
| ネットワーク | DTSとFunction Appのリージョン、Private Endpoint | リージョン差やネットワーク制限で遅延・接続失敗が起きる |
| データサイズ | 入出力ペイロード、外部イベント、Entity state | 大きな文書や大量JSONをそのまま渡す |
| 保持期間 | オーケストレーション履歴の削除・保持方針 | 履歴が増え続け、検索や保管コストの課題になる |
Microsoft Learnでは、.NET Azure Functionsプロジェクトで必要なパッケージに加え、Microsoft.Azure.Functions.Workerは2.2.0以降を使うよう案内されています。また、DefaultAzureCredentialは開発では便利ですが、本番では意図しない資格情報探索や遅延などを避けるため、Managed Identityなど具体的な資格情報を検討するよう警告されています。(Microsoft Learn)
ローカル開発では、Azure Functionsの内部状態用にAzurite、エージェント状態やオーケストレーション用にDTS emulatorを起動します。DTS emulatorは8080をgRPC endpoint、8082を管理ダッシュボードとして公開する例が示されています。(Microsoft Learn)
本番のHTTPトリガーではAPIキーが必要になるため、デプロイ後のテストではFunction keyの取得も確認対象になります。(Microsoft Learn)
Durable Task Schedulerの設計で注意すべきこと
Durable Task Schedulerは、ワークフローの状態保存と実行調整を担う重要な基盤です。Microsoft Learnでは、Durable Task SchedulerはDurable FunctionsとDurable Task SDK向けの推奨ストレージプロバイダーとされ、Function Appと同一リージョンに配置することでパフォーマンスやネットワーク面の最適化につながると説明されています。(Microsoft Learn)
また、DTSはアプリとは別リソースとして動作し、Task Hubを使ってオーケストレーションやEntityの状態を論理的に分離できます。開発、検証、本番でTask Hubを分けると運用しやすくなりますが、同じSchedulerインスタンス内のTask Hubはリソースを共有するため、重いワークロードが他のTask Hubに影響する可能性があります。(Microsoft Learn)
特に注意したいのはペイロードサイズです。DTSには、orchestratorやactivityの入出力、外部イベントデータ、custom status、Entity stateに最大サイズ制限があります。大きなファイル本文、長大なAIプロンプト、RAGで取得した大量テキストをそのままワークフローに流すのではなく、Blob Storageなどに保存し、ワークフローには参照IDを渡す設計が安全です。(Microsoft Learn)
移行・展開時に壊れやすいポイント
Durable Workflowsは「状態を持つ」ため、通常のFunctionsアプリよりデプロイ時の注意点が増えます。
実行中ワークフローがある状態で定義を変えない
Durable orchestrationsはリプレイによって状態を復元します。そのため、実行中のワークフローがある状態でステップの順序、activity名、入力・出力の形、分岐条件を大きく変えると、既存インスタンスのリプレイが壊れる可能性があります。
Microsoft Learnでは、古いバージョン向けのorchestratorロジックをそのまま保持することが重要で、既存バージョンのactivity呼び出しの順序やシグネチャを変えると、実行中オーケストレーションが失敗したり誤った結果を返したりする可能性があると説明されています。(Microsoft Learn)
安全な展開方針は次の通りです。
| 変更内容 | 推奨対応 |
|---|---|
| Executorの内部ロジックだけを修正 | 入出力型や副作用が変わらないか確認して通常デプロイ |
| ワークフローにステップを追加 | バージョン分岐、別ワークフロー名、別Task Hubを検討 |
| activity名やExecutor IDを変更 | 実行中インスタンスが完了してから変更、または旧名を残す |
| 入出力スキーマを変更 | 後方互換のDTOを用意し、旧データを読めるようにする |
| 古いコードを削除 | 旧バージョンのインスタンスが完了・失敗・終了済みか確認 |
古いコードパスを削除できるのは、古いバージョンのオーケストレーションがすべて完了し、新規作成も止まり、監視やクエリで実行中インスタンスがないことを確認した後です。(Microsoft Learn)
非決定的な処理をorchestratorに書かない
Durable FunctionsやDurable Taskでは、orchestratorがリプレイされます。そのため、現在時刻、乱数、直接HTTP通信、環境変数の直接参照、スレッドブロックなど、毎回結果が変わる処理は注意が必要です。Microsoft Learnでは、orchestratorは決定的である必要があり、外部I/Oはactivityへ移すべきと説明されています。(Microsoft Learn)
Microsoft Agent FrameworkのワークフローではExecutorがactivityとしてラップされるため、業務ロジックはExecutor側に置きやすくなります。それでも、独自のDurable Functions orchestratorを併用する場合は、次のように切り分けてください。
| 処理 | 置く場所 |
|---|---|
| Azure OpenAIへの呼び出し | Agentまたはactivity相当の処理 |
| Blob Storage、DB、外部APIへのアクセス | activityまたはExecutor |
| 現在時刻を使った期限判定 | Durable APIの時刻・timerを使う |
| ランダムなID生成 | replay-safeなAPI、またはactivity |
| 環境変数の読み取り | 起動時設定、入力、activity結果として渡す |
リトライ前提で副作用を設計する
Durable executionでは、失敗時に再試行される可能性があります。メール送信、注文キャンセル、チケット作成、請求処理などの副作用があるExecutorでは、同じ処理が複数回呼ばれても壊れない設計が必要です。
実務では、次のような対策を入れます。
- 外部システムに渡す一意の冪等キーをrun IDや業務IDから作る
- 送信済みメールや登録済みチケットを業務IDで照会してから処理する
- 「処理済み」フラグを外部DBに保存する場合は競合更新を考慮する
- AIの出力をそのまま確定処理に使わず、検証ステップを挟む
導入に向いているケース、向いていないケース
Durable Workflowsは強力ですが、すべてのAI機能に必要なわけではありません。導入判断は、状態管理と運用要件で決めるのが分かりやすいです。
| 向いているケース | 理由 |
|---|---|
| 複数AIエージェントでレビュー・分類・集約する | fan-out / fan-inとチェックポイントの効果が大きい |
| 人間の承認待ちがある | 長時間待機しても状態を保持しやすい |
| 障害時に途中から復旧したい | 完了済みステップを再利用しやすい |
| Copilotや他のAIエージェントから業務処理を呼びたい | MCPツール化を検討できる |
| 監査性が必要な業務フロー | 実行履歴やステップごとの状態を確認しやすい |
| 慎重に判断すべきケース | 理由 |
|---|---|
| 1回のAI応答だけで完了する処理 | Durable化の設計・運用コストが上回る可能性がある |
| ミリ秒単位の低遅延が最優先 | オーケストレーションの管理コストが増える |
| 大容量データを頻繁に受け渡す | ペイロード制限や履歴肥大化に注意が必要 |
| 認証・権限設計が未整備 | HTTP/MCPエンドポイント公開時のリスクが高い |
| プレビュー機能を本番採用できない組織 | パッケージやドキュメントの更新状況を継続確認する必要がある |
まず試すなら小さな業務フローから始める
最初のPoCには、複雑すぎる業務ではなく、3〜5ステップ程度のワークフローが向いています。例えば、問い合わせ分類、注文キャンセル、社内FAQ回答の承認付き公開、経費申請レビューなどです。
進め方は次の順序が安全です。
| 手順 | やること | 完了条件 |
|---|---|---|
| 1 | 業務フローをExecutor単位に分解する | 入力、出力、失敗時の扱いが決まっている |
| 2 | コンソールアプリでWorkflowBuilderを作る | ローカルで順次実行できる |
| 3 | DTS emulatorでDurable実行する | Dashboardで各ステップを確認できる |
| 4 | Azure Functionsへホストする | HTTPエンドポイントから起動できる |
| 5 | 認証、監視、ログ、リトライを確認する | 本番運用時の障害対応手順が見える |
| 6 | 必要に応じてMCPやHuman-in-the-Loopを追加する | 公開範囲と承認フローが明確になっている |
最初からMCP連携や複数エージェントを盛り込みすぎると、問題が起きたときに原因を切り分けにくくなります。まずは「1つのワークフローをAzure FunctionsでDurableに動かす」ことをゴールにしてください。
Azure Functions管理者・開発者が次に確認すべきこと
Durable Workflows in the Microsoft Agent Frameworkは、Azure Functions上でAIエージェントを実用的な業務フローに組み込むための重要な選択肢です。特に、長時間実行、承認待ち、複数エージェントの並列処理、障害復旧、Copilot/MCP連携を考えているチームでは、早めに検証する価値があります。
次に取るべき行動は、次の3つです。
- 現在のAI機能が「単発呼び出し」で十分か、「状態を持つワークフロー」にすべきかを分類する
- Azure Functions、Durable Task Scheduler、Azure OpenAI、認証、監視の構成をPoC環境で確認する
- 本番導入前に、バージョン管理、実行中インスタンス、ペイロード制限、MCP公開範囲、Human-in-the-Loopの承認権限を設計する
Azure FunctionsでAIエージェントを運用する場合、重要なのは「AIが答えること」だけではありません。途中で止まっても復旧できるか、誰が承認したか追跡できるか、ツールとして安全に公開できるかまで含めて設計することが、Durable Workflowsを使う最大の意味です。
コメント