--- title: マルチエージェントの時代でもやっぱり Durable Functions は最高だぜ！ tags: #azure #マルチエージェント author: [yuma(Maki)](https://www.docswell.com/user/yuma) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/YJ6WP4WGJV.jpg?width=480 description: [【Azure AIの必須機能!?】YonaYona Durable Functions Night - connpass](https://yonayona.connpass.com/event/393817/ )のスライドです。Durable Agentsについてまとめています。 published: June 12, 26 canonical: https://www.docswell.com/s/yuma/ZX269P-2026-06-12-yonaazu --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/YJ6WP4WGJV.jpg) マルチエージェントの時代でも やっぱり Durable Functions は最高だぜ！ 【Azure AIの必須機能!?】YonaYona Durable Functions Night 2026/06/12 Maki Nagase # Page. 2 ![Page Image](https://bcdn.docswell.com/page/GJ5MKQMXJ4.jpg) 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 • 趣味 • 技術コミュニティ,アニメ,キャンプ,しゃぼん玉,法螺貝, サバゲ,などなど # Page. 3 ![Page Image](https://bcdn.docswell.com/page/LE3WZVW4E5.jpg) そもそもエージェントとは # Page. 4 ![Page Image](https://bcdn.docswell.com/page/8EDKR8K57G.jpg) AIエージェントの基本 LLM/SLM などの言語モデルが入力を受け取り、ツールを呼び出し、自律的に目標を達成するソフトウェア AIエージェント モデル 目標 → LLM / SLM 思考・判断を担う頭脳 + 指示 プロンプト・目標 振る舞いと目的を定義 + ツール 検索・DB・外部API 外部と連携して実行 → 達成 モデルが指示に従い、ツールを自分で使って目標を達成するまで動く 3 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/V7PKW8KDJ8.jpg) なぜマルチエージェントが出てきたか 「何でもできる1つのエージェント」はFAQボットなら十分。仕事が複雑になると構造的な限界に シングルエージェントの限界 何が起きるか 過度な一般化 多くの業務を1つで担うほど指示が複雑化。応答が汎用的になり、品質が全体的に低下 性能のボトルネック すべての処理が1か所に集中。利用者や処理ステップが増えるほど遅くなる セキュリティの不安 1つのエージェントが全データにアクセス。「必要最小限の権限」の原則を守れない 変更がこわい ロジック・ツール・記憶が一体化。小さな機能追加でも全体の再テストが必要 専門化できない 新しいツールや得意分野別のモデルを部分的に組み込めず、改善が止まる 万能型の1エージェント → 専門特化エージェント × まとめ役 人間のチームと同じ発想で分担 ＝ マルチエージェント 4 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/2JVV8NVGJQ.jpg) マルチエージェントのワークフローの例 シーケンシャル（順次） A → B → C パラレル（並列） B A ⇉ ⇉ D C 前の結果を次のエージェントへ順番に渡す Group Chat A マネー ジャー B → → 複数エージェントを同時に実行し、結果を集約する Human-in-the-Loop（HITL） A → 人 → B C マネージャーエージェントがどのエージェントにタスクを引き渡すか判断する 人間の承認が必要な所で一時停止・再開する 4 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/5EGL5K1DJL.jpg) Microsoft Agent Framework Microsoft 製オープンソースのAIエージェント開発フレームワーク 基本的にマルチエージェント構築時に使うもの AutoGen マルチエージェント研究の知見 シンプルなエージェント抽象化 ＋ Semantic Kernel エンタープライズ向けAI SDK → エンタープライズ機能（OpenTelemetry・Entra ID） Microsoft Agent Framework 2つを統合した次世代フレームワーク グラフベースのワークフロー 5 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/4JQYZNDX7P.jpg) Agent Framework の2つの構成要素 Agents Workflows 言語モデルがツールやMCPサーバーを呼び出して応答する エージェントや関数をグラフ構造でつなぐ 複数ステップのワーク 単体のエージェント フロー シンプルなタスク向き。自律的な計画とツール使用が得意 明確なステップがあるプロセス向き。実行順序を明示的に制御できる 対応言語 C# / Python 対応モデル Microsoft Foundry・OpenAI・Anthropic・Ollama など 6 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/K74W3GZ2E1.jpg) 作ったマルチエージェント、デプロイ先どうする問題 01 サーバーを管理したくない インフラ運用に手間をかけられない 02 承認待ちの間は課金さたくない HITLでの人間の承認待ちは数時間〜数日続くことも 03 スケールを任せたい LLMの応答待ちが多く、増減の調整が大変 04 失敗したとき自動でリトライしてほしい LLM APIの一時的なエラーはつきもの 05 会話履歴の管理が煩雑 セッション状態の自前管理はつらい 06 可観測性も重要 パフォーマンスの監視やエラー時の調査がしやすいものがいい 7 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/LJ1Y1DRKEG.jpg) そこで Durable Functions サーバーレス × ステートフル × ワークフロー ! # Page. 11 ![Page Image](https://bcdn.docswell.com/page/GJWG8Y1P72.jpg) Durable Functions でのワークフロー Durable Functions を使って独自実装することも可能 Building secure AI Agents with Azure Functions | BRK189 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/4EZL8XP673.jpg) Durable Functions でのワークフロー Durable Functions を使って独自実装することも可能 Building secure AI Agents with Azure Functions | BRK189 1 Function を 1 Agent と考えると…？ # Page. 13 ![Page Image](https://bcdn.docswell.com/page/Y76WP4ML7V.jpg) Durable Functions のおさらい 詳細は前のセッションにて — ここでは6つの機能だけ押さえれば OK ステートフル実行 自動チェックポイント 自動リトライ 途中経過を保ったまま、順番・条件付きで処 各ステップの完了を自動保存。障害後も途 回数・間隔を指定して、失敗時に自動で再 理を進める 中から再開 実行 長期間実行 Human-in-the-Loop ゼロスケール 数日〜数週間続くワークフローも安定して実 外部イベント待ちで実行を一時停止し、応 待機中はコンピューティングゼロ＝ 課金なし 行 答で再開 9 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/G75MKQZM74.jpg) 承認待ち24時間の課金を考えると Durable Functions 24時間分 ¥0 承認を待っている間も、ずっと稼働コストが発生 待機中の課金なし。実際にコードが動く数秒〜数十秒分だけ 支払 常時起動のサーバー う Flex Consumption プランの場合。課金対象はコンテンツ生成・通知送信・応答処理などの実行時間のみ （こちらはFable 5が作ってくれた、いらないけどなんか面白いから残しておいたスライド） 10 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/9J29WPRRER.jpg) Durable Agents の全体像 正式名称：Durable Task Extension for Microsoft Agent Framework Agent Framework エージェントの書き方 × Durable Functions 堅牢な実行基盤 → Durable Agents エージェントが永続的に動く 永続セッション管理 — 会話履歴を自動で保存・管理 HTTPエンドポイント自動生成 — APIをすぐ呼び出せる 分散スケーリング — スケールはAzureにおまかせ セッションTTL — エージェントごとに設定可能 11 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/DEY4L5D5JM.jpg) 1行追加で実現するDurable Agents 化 agent = ... # 通常の Agent Framework のエージェント定義 app = AgentFunctionApp(agents=[agent]) # ← この1行 エージェントの書き方は変更なし。 この一行で以下が実現している • HTTP エンドポイント（POST /api/agents/{name}/run）を自動生成 • 各エージェントセッションをDurable Entityとして実装 • 会話履歴・チェックポイントを自動管理 12 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/VJNY4N6478.jpg) Durable Agents の内部構造 Agent Framework で書いた概念が、Durable Functions の部品にそのまま対応付けられる Agent Framework で書くもの Durable Functions での実体 エージェント → Durable Entity 1エージェント＝1エンティティとしてホストされる 会話スレッド → エンティティの状態 会話履歴は Durable Task Scheduler に自動保存 マルチエージェントの流れ → オーケストレーター関数 確定的ワークフローとして実行・再現できる 各エージェントの実行・処理 → アクティビティ関数 自動リトライ・チェックポイントの単位になる 13 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/YE9PQRL4J3.jpg) リクエストとセッションの流れ → クライアント Durable Agent POST /api/agents/{name}/run 永続エンティティとして稼働 ⇄ LLM・ツール Azure OpenAI など x-ms-thread-id: abc123 状態の保存・読み込みは自動 Durable Task Scheduler 会話履歴・チェックポイントを保存 同じ thread-id で呼べば会話の続きから 履歴管理のコードは不要 障害時はチェックポイントから復元 14 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/GE8DGWXVED.jpg) レイヤーで見る役割分担 アプリ層のコードはそのまま、インフラ層の恩恵がすべて乗る アプリ層 Agent Framework エージェント定義・モデル接続・ツール / MCP 呼び出し 橋渡し Durable Task Extension AgentFunctionApp の1行。エージェントを下の層へ対応付け Durable Functions 実行・自動リトライ・自動スケール・一時停止 / 再開 Durable Task Scheduler 状態の保存・管理、ダッシュボードでの可視化 インフラ層 15 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/LELMGN8R7R.jpg) 他のフレームワーク・自前実装との比較 最大の違いは、アプリ層だけでなくインフラ層まで含めて統制できること 観点 自前実装 Durable Agents 可観測性 別途実装が必要 ダッシュボードで自動可視化 リトライ 自分で実装 組み込みの自動リトライ スケール 自前管理 Azure Functions が自動スケール Human-in-the-Loop 複雑な実装が必要 外部イベント待ちを書くだけ 状態管理 自前実装 Durable Task Scheduler が自動管理 インフラ管理コスト インフラによっては高い サーバーレスでほぼゼロ 18 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/4JMYQX6PJW.jpg) DTSダッシュボードがとてもよい 追加実装なしで使える トークン使用量・応答時間も見える ローカルのエミュレーターでも同じ画面 21 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/PJR98NPY79.jpg) まとめと次の一歩 可観測性 ダッシュボードで会話履歴・実行フローが即見える サーバーレス インフラ管理不要、スケールは自動 ゼロスケール 承認待ち中の課金なし 自動リトライ 一時エラーから途中再開できる 低管理コスト アイドルコストなし・ストレージ管理不要 実装が簡単 1行追加でDurable化 次の一歩 公式ドキュメント：Microsoft Learn 「Durable Task Extension for Agent Framework」 サンプル：GitHub Azure-Samples / durable-taskextension-for-agent-framework 22 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/PEXQ8N34JX.jpg) 最後に、今後のイベント紹介！ 登壇・運営・主催イベント一覧をまとめているのでこちらからご確認ください！ https://yuma-722.github.io/events/