マルチエージェントの時代でもやっぱり Durable Functions は最高だぜ！

マルチエージェントの時代でも やっぱり Durable Functions は最高だぜ！ 【Azure AIの必須機能!?】YonaYona Durable Functions Night 2026/06/12 Maki Nagase

Maki Nagase @yuma_prog • My Info • 株式会社ゼンアーキテクツ所属 • GitHub Star • Microsoft MVP for Azure, Microsoft Foundry • 運営・主催コミュニティ • AI駆動開発勉強会, JAZUG(Japan Azure User Group), Azureわいがや会, GitHub Vibe Riders, Hack Everything., GitHub dockyard, AOAI Dev Day • 好きな技術 • Azure PaaS, Azure AI, C#, Terraform, GitHub Copilot • 趣味 • 技術コミュニティ,アニメ,キャンプ,しゃぼん玉,法螺貝, サバゲ,などなど

そもそもエージェントとは

AIエージェントの基本 LLM/SLM などの言語モデルが入力を受け取り、ツールを呼び出し、自律的に目標を達成するソフトウェア AIエージェント モデル 目標 → LLM / SLM 思考・判断を担う頭脳 + 指示 プロンプト・目標 振る舞いと目的を定義 + ツール 検索・DB・外部API 外部と連携して実行 → 達成 モデルが指示に従い、ツールを自分で使って目標を達成するまで動く 3

なぜマルチエージェントが出てきたか 「何でもできる1つのエージェント」はFAQボットなら十分。仕事が複雑になると構造的な限界に シングルエージェントの限界 何が起きるか 過度な一般化 多くの業務を1つで担うほど指示が複雑化。応答が汎用的になり、品質が全体的に低下 性能のボトルネック すべての処理が1か所に集中。利用者や処理ステップが増えるほど遅くなる セキュリティの不安 1つのエージェントが全データにアクセス。「必要最小限の権限」の原則を守れない 変更がこわい ロジック・ツール・記憶が一体化。小さな機能追加でも全体の再テストが必要 専門化できない 新しいツールや得意分野別のモデルを部分的に組み込めず、改善が止まる 万能型の1エージェント → 専門特化エージェント × まとめ役 人間のチームと同じ発想で分担 ＝ マルチエージェント 4

マルチエージェントのワークフローの例 シーケンシャル（順次） A → B → C パラレル（並列） B A ⇉ ⇉ D C 前の結果を次のエージェントへ順番に渡す Group Chat A マネー ジャー B → → 複数エージェントを同時に実行し、結果を集約する Human-in-the-Loop（HITL） A → 人 → B C マネージャーエージェントがどのエージェントにタスクを引き渡すか判断する 人間の承認が必要な所で一時停止・再開する 4

Microsoft Agent Framework Microsoft 製オープンソースのAIエージェント開発フレームワーク 基本的にマルチエージェント構築時に使うもの AutoGen マルチエージェント研究の知見 シンプルなエージェント抽象化 ＋ Semantic Kernel エンタープライズ向けAI SDK → エンタープライズ機能（OpenTelemetry・Entra ID） Microsoft Agent Framework 2つを統合した次世代フレームワーク グラフベースのワークフロー 5

Agent Framework の2つの構成要素 Agents Workflows 言語モデルがツールやMCPサーバーを呼び出して応答する エージェントや関数をグラフ構造でつなぐ 複数ステップのワーク 単体のエージェント フロー シンプルなタスク向き。自律的な計画とツール使用が得意 明確なステップがあるプロセス向き。実行順序を明示的に制御できる 対応言語 C# / Python 対応モデル Microsoft Foundry・OpenAI・Anthropic・Ollama など 6

作ったマルチエージェント、デプロイ先どうする問題 01 サーバーを管理したくない インフラ運用に手間をかけられない 02 承認待ちの間は課金さたくない HITLでの人間の承認待ちは数時間〜数日続くことも 03 スケールを任せたい LLMの応答待ちが多く、増減の調整が大変 04 失敗したとき自動でリトライしてほしい LLM APIの一時的なエラーはつきもの 05 会話履歴の管理が煩雑 セッション状態の自前管理はつらい 06 可観測性も重要 パフォーマンスの監視やエラー時の調査がしやすいものがいい 7

そこで Durable Functions サーバーレス × ステートフル × ワークフロー !

Durable Functions でのワークフロー Durable Functions を使って独自実装することも可能 Building secure AI Agents with Azure Functions | BRK189

• https://www.youtube.com/watch?v=9DPi9SANp9s

Durable Functions でのワークフロー Durable Functions を使って独自実装することも可能 Building secure AI Agents with Azure Functions | BRK189 1 Function を 1 Agent と考えると…？

• https://www.youtube.com/watch?v=9DPi9SANp9s

Durable Functions のおさらい 詳細は前のセッションにて — ここでは6つの機能だけ押さえれば OK ステートフル実行 自動チェックポイント 自動リトライ 途中経過を保ったまま、順番・条件付きで処 各ステップの完了を自動保存。障害後も途 回数・間隔を指定して、失敗時に自動で再 理を進める 中から再開 実行 長期間実行 Human-in-the-Loop ゼロスケール 数日〜数週間続くワークフローも安定して実 外部イベント待ちで実行を一時停止し、応 待機中はコンピューティングゼロ＝ 課金なし 行 答で再開 9

承認待ち24時間の課金を考えると Durable Functions 24時間分 ¥0 承認を待っている間も、ずっと稼働コストが発生 待機中の課金なし。実際にコードが動く数秒〜数十秒分だけ 支払 常時起動のサーバー う Flex Consumption プランの場合。課金対象はコンテンツ生成・通知送信・応答処理などの実行時間のみ （こちらはFable 5が作ってくれた、いらないけどなんか面白いから残しておいたスライド） 10

Durable Agents の全体像 正式名称：Durable Task Extension for Microsoft Agent Framework Agent Framework エージェントの書き方 × Durable Functions 堅牢な実行基盤 → Durable Agents エージェントが永続的に動く 永続セッション管理 — 会話履歴を自動で保存・管理 HTTPエンドポイント自動生成 — APIをすぐ呼び出せる 分散スケーリング — スケールはAzureにおまかせ セッションTTL — エージェントごとに設定可能 11

1行追加で実現するDurable Agents 化 agent = ... # 通常の Agent Framework のエージェント定義 app = AgentFunctionApp(agents=[agent]) # ← この1行 エージェントの書き方は変更なし。 この一行で以下が実現している • HTTP エンドポイント（POST /api/agents/{name}/run）を自動生成 • 各エージェントセッションをDurable Entityとして実装 • 会話履歴・チェックポイントを自動管理 12

Durable Agents の内部構造 Agent Framework で書いた概念が、Durable Functions の部品にそのまま対応付けられる Agent Framework で書くもの Durable Functions での実体 エージェント → Durable Entity 1エージェント＝1エンティティとしてホストされる 会話スレッド → エンティティの状態 会話履歴は Durable Task Scheduler に自動保存 マルチエージェントの流れ → オーケストレーター関数 確定的ワークフローとして実行・再現できる 各エージェントの実行・処理 → アクティビティ関数 自動リトライ・チェックポイントの単位になる 13

リクエストとセッションの流れ → クライアント Durable Agent POST /api/agents/{name}/run 永続エンティティとして稼働 ⇄ LLM・ツール Azure OpenAI など x-ms-thread-id: abc123 状態の保存・読み込みは自動 Durable Task Scheduler 会話履歴・チェックポイントを保存 同じ thread-id で呼べば会話の続きから 履歴管理のコードは不要 障害時はチェックポイントから復元 14

レイヤーで見る役割分担 アプリ層のコードはそのまま、インフラ層の恩恵がすべて乗る アプリ層 Agent Framework エージェント定義・モデル接続・ツール / MCP 呼び出し 橋渡し Durable Task Extension AgentFunctionApp の1行。エージェントを下の層へ対応付け Durable Functions 実行・自動リトライ・自動スケール・一時停止 / 再開 Durable Task Scheduler 状態の保存・管理、ダッシュボードでの可視化 インフラ層 15

他のフレームワーク・自前実装との比較 最大の違いは、アプリ層だけでなくインフラ層まで含めて統制できること 観点 自前実装 Durable Agents 可観測性 別途実装が必要 ダッシュボードで自動可視化 リトライ 自分で実装 組み込みの自動リトライ スケール 自前管理 Azure Functions が自動スケール Human-in-the-Loop 複雑な実装が必要 外部イベント待ちを書くだけ 状態管理 自前実装 Durable Task Scheduler が自動管理 インフラ管理コスト インフラによっては高い サーバーレスでほぼゼロ 18

DTSダッシュボードがとてもよい 追加実装なしで使える トークン使用量・応答時間も見える ローカルのエミュレーターでも同じ画面 21

まとめと次の一歩 可観測性 ダッシュボードで会話履歴・実行フローが即見える サーバーレス インフラ管理不要、スケールは自動 ゼロスケール 承認待ち中の課金なし 自動リトライ 一時エラーから途中再開できる 低管理コスト アイドルコストなし・ストレージ管理不要 実装が簡単 1行追加でDurable化 次の一歩 公式ドキュメント：Microsoft Learn 「Durable Task Extension for Agent Framework」 サンプル：GitHub Azure-Samples / durable-taskextension-for-agent-framework 22

• https://learn.microsoft.com/ja-jp/azure/durable-task/sdks/durable-agents-microsoft-agent-framework?tabs=csharp&pivots=azure-functions
• https://github.com/Azure-Samples/durable-task-extension-for-agent-framework

最後に、今後のイベント紹介！ 登壇・運営・主催イベント一覧をまとめているのでこちらからご確認ください！ https://yuma-722.github.io/events/

• https://yuma-722.github.io/events/