動的ワークフローはAzure Functionsのホスト型スキルの機能です。 ホストされたスキルが、ツール呼び出しや待ち時間の持続的で多段階のワークフローを開始させ、あなたがDurable Functionsのオーケストレーションコードを書かずに済むようにします。
最新かつ最も包括的なランタイムに関するドキュメントについては、Azure Functions Agents Runtime の動的ワークフローをご覧ください。
Important
Azure Functions Hosted Skillsは現在プレビュー中です。 機能、構成名、およびサポートされているコネクタは、一般公開前に変更される可能性があります。
会話ループを通じてツールを一つずつ呼ぶのではなく、動的なワークフローによりAIモデルは構造化されたツール呼び出し計画を生成できます。 ランタイムは、計画を Durable Functions のオーケストレーションとして実行します。このオーケストレーションは、並列に分岐し、待機し、再起動後も継続し、可観測性を保つことができます。一方で、ホストされたスキルのコンテキストに渡されるのは最終結果だけです。
なぜ動的ワークフローなのか
ホストされたスキルがモデルループでツールを直接呼び出すことには、4つの基本的な制限があります。
- トークンコストです。 すべての中間ツールの結果はモデルのコンテキストに追加されます。 マルチステッププランは、モデルが要約するだけで済む生データにトークンを使うことができます。
- 遅延。 ツールを直接呼び出すたびに、モデルとの往復がもう1回発生します。 長く分岐した作業は、独立した作業を並行して実行するのではなく、モデルループを直列的に通過します。
- 耐久性。 作業者が再起動するとインライン作業が失われることがあり、タイマーで眠ったり、長時間の外部信号を待つような一流の方法はありません。
- 可観測性。 オペレーターはチャットセッションを経ずに機内作業を簡単にリストアップ、検査、キャンセルできません。
動的ワークフローは、計画実行を持続的なオーケストレーションに移行させることでこれらの制限を解消します。 ホストされたスキルはワークフローを開始し、ワークフローIDを受け取り、ターンを終了できます。 オーケストレーターはワークフローに安全なツールと耐久性のあるタイマーを実行します。 チャットUIや操作の表面はワークフローを独立して追跡でき、ワークフローが完了するとホストスキルが再び引き継がれます。
動的ワークフローがプログラムツール呼び出しとどのように関連しているか
動的ワークフローは、Anthropicのプログラム的ツール呼び出しパターンと形状が似ています。 そのパターンでは、モデルは構造化されたツールプランを作成し、ランタイムは通常のツールごとのチャットループの外で実行します。 このアプローチは、中間結果がモデルの文脈外に留まるため、トークンの使用と遅延を削減でき、1つのモデル作成プランが複数のツール呼び出しを表現できるためです。
動的ワークフローはそのパターンをAzure Functionsに適用し、耐久性と操作層を追加します:
| 能力 | プログラムツール呼び出しパターン | 動的ワークフロー |
|---|---|---|
| プラン形式のツール呼び出し | はい | はい |
| マルチツール作業におけるトークン使用と遅延の低減 | はい | はい |
| ワーカーの再起動後も継続する耐久実行 | いいえ | はい、Durable Functionsを使っています |
| 耐久性のある待機とタイマー | いいえ | はい |
| ループ外リスト、検査、キャンセル、終了 | いいえ | はい |
| Durable Task Schedulerにおけるオペレーターの可視化 | いいえ | はい、設定時には |
動的ワークフローを使うべきタイミング
ホストスキルが単一のチャットターンや直接ツールコール以上の作業を行う必要がある場合は、動的なワークフローを活用しましょう。 適切な適合は次のとおりです。
- 複数の独立した情報源(ログ、メトリクス、デプロイ履歴など)から証拠を並行して収集するファンアウト/ファンインパターン。
- 分離された専門ホスト スキルを並列実行し、その応答を組み合わせること。
- 後のステップは以前のツール結果に依存するマルチステッププランを実施する。
- 作業員を忙しくせずに耐久性のあるタイマーを待つこと。
- 最終結果や要約が出るまで、大きな中間結果はホストされたスキルの会話文脈から除外します。
- モデルループの外から長期作業を追跡・管理すること。
Tip
作業が単一のツールコールで完了できる場合や、各ステップで即座にユーザー応答が必要な場合は、動的ワークフローの代わりに直接ツールコールを使いましょう。
ワークフローの動作
以下の図は動的ワークフローアーキテクチャにおける主要なコンポーネントを示しています:
動的なワークフローは以下のシーケンスを貫きます。
- イベントがホストスキルをトリガーしたり、ユーザーがチャットUIを通じてリクエストを送信したりします。
- ホストされたスキルは、AIモデルが生成したワークフロープランと呼び
start_workflowします。 - ランタイムはプランをDurable Functionsオーケストレーションとして開始し、ワークフローIDを即座に返します。
- オーケストレーターは既成ツールのアクティビティを並行して実行し、
waitステップに対して耐久性のあるタイマーを作成します。 また、サブエージェント上でホストされるスキルに作業を委任することもでき、各スキルは独立したステートレスなセッションで実行されます。 - ワークフローがターミナル状態に達すると、ランタイムはホストされたスキルに通知し、
get_workflow_statusを呼び出して最終出力をまとめます。
ホストスキルが内蔵のチャットUIを使うと、UIはワークフローの状況をポーリングし、進捗カードも表示します。
中間の結果はワークフローストアに残ります。 ホストされたスキルは、開始時のワークフローIDと結果取得時の最終ステータスのみを認識します。 ホストされたスキルはワークフローが実行されている間はポーリングしません。
ワークフロー管理ツール
ワークフローを有効にすると、ランタイムは以下のツールをホストスキルに追加します:
| ツール | Purpose |
|---|---|
start_workflow |
検証済みワークフロープランを開始し、すぐにワークフローIDを返します。 |
get_workflow_status |
ワークフローの現在の状況と最終出力を取得します。 |
list_workflows |
現在のセッションが所有するワークフローを一覧にします。 |
cancel_workflow |
協調キャンセルを要求します。 |
terminate_workflow |
ワークフローインスタンスが突然終了します。 |
ホストされたスキルはこれらのツールを呼び出します。 ユーザーはアプリケーションコードで直接呼び出すことはありません。
ワークフローサブエージェント
ワークフロー対応のホストスキルは、 workflows.subagents 構成で専門的なホストスキルへのアクセスを許可できます。 各スペシャリストは同じホストされたスキルアプリ内の別の .agent.md ファイルです。
以下の前線事項では、コーディネーターが2人のスペシャリストを活用できます。
---
name: PR Status Portfolio Coordinator
description: Reviews pull requests and produces an actionable report.
workflows:
enabled: true
subagents:
- agent: pr_status_analyst
when: Review one pull request and summarize its current status
- agent: actionable_report_writer
when: Combine pull-request summaries into an actionable portfolio report
---
agent値はスペシャリストのファイル名スラッグです。 例えば、 pr_status_analyst は pr_status_analyst.agent.mdを指します。 オプションの when 値は、モデルが専門家をいつ利用するかを判断するのに役立ちます。 ランタイムは、ワークフローをスケジュールする前に、この明示的な許可に照らして各スペシャリストを検証します。
このモデルは、id、agent、自己完結型taskを備えたsub_agentワークフロータスクを生成できます。 サブエージェントのタスクは、 depends_on、 when、 for_eachも使用できます。
{
"id": "analyze_pr",
"type": "sub_agent",
"agent": "pr_status_analyst",
"task": "Review the supplied pull request and summarize its current status."
}
各サブエージェントの呼び出しはステートレスで、独立しています:
- スペシャリストは独自のモデル、指示、ツール、MCPサーバー、スキル、タイムアウトを使用します。
- 専門家はコーディネーターの会話履歴、サンドボックス、ワークフロー管理ツール、チャット時間の委任ツールを受け取りません。
- スペシャリストの失敗やタイムアウトは親ワークフローを失敗させます。
- 専門ツールは再実行に耐えるべきです。なぜなら、ワーカーの失敗がサブエージェントを複数回実行させる原因になるからです。
並列でPRアナリストのタスクを実行し、それらの要約をまとめてレポートにまとめるエンドツーエンドの例については、 ワークフローサブエージェントのサンプルをご覧ください。
ストレージ バックエンド
動的ワークフローは内部でDurable Functionsを使用し、同じストレージバックエンドをサポートしています。 デフォルトでは、ワークフローは関数アプリがすでに持っているAzure Storageアカウントを使用します。 本番作業では、 Durable Task Scheduler(DTS)に切り替えることができ、インスタンスごとのタスク状態、再試行履歴、機内作業用のコントロールを含むダッシュボードを提供します。 ハウツーガイドは 両方の選択肢をカバーしています。
Considerations
動的ワークフローを使用する際には、以下の現在の制限を念頭に置いてください:
- ワークフローに安全なツールハンドラは同期的でなければならず、JSONで直列化可能な値を返す必要があります。
- AIモデルは実行時にワークフロープランを作成します。 YAMLやMarkdownでは静的なワークフローテンプレートを定義できません。
- タスクごとのリトライやタイムアウトポリシーを設定することはできません。
- 大規模出力処理やMCPタスク統合は利用できません。
次のステップ
ワークフローに安全なツールを設定し、ローカルでワークフローを実行しましょう: