Strands AgentsのWorkflowでDAGベースのタスク実行を試してみた

Strands AgentsのWorkflowでDAGベースのタスク実行を試してみた

2026.02.04

こんにちは。サービス開発室の武田です。

前回の記事ではSwarmパターンについて紹介しました。今回は Workflow パターンを試してみます。

Workflowとは

Workflowは、複数のタスクを依存関係にしたがって実行するパターン です。タスク間の依存関係は循環せず、いわゆるDAG(有向非循環グラフ)の構造を持ちます。Apache AirflowやAWS Step Functionsをご存じの方には馴染みやすいコンセプトですね。

公式ドキュメントでは次のように説明されています。

A workflow is a structured coordination of tasks across multiple AI agents, where each agent performs specialized functions in a defined sequence or pattern.

「構造化されたタスク調整」であり、複数のAIエージェントが定義されたシーケンスやパターンで専門的な処理を行うという説明です。

なぜこのパターンを使うのか

公式ドキュメントでは、Workflowのアーキテクチャとして3つの主要コンポーネントが挙げられています。

コンポーネント 説明
Task Definition and Distribution タスクの指定、エージェントへの割り当て、優先度レベルの設定
Dependency Management 順序制約、並列実行、結合ポイントの管理
Information Flow 入出力マッピング、コンテキスト保持、状態管理

「タスク定義」「依存関係管理」「情報フロー」の3つが明確に構造化されているのがWorkflowの特徴です。特に 順序制約が重要で、構造化された実行が求められる業務プロセス に適していますね。

GraphやSwarmとの違い

GraphやSwarmも複数のエージェントが協調するパターンですが、Workflowには明確な特徴があります。

観点 Workflow Graph Swarm
グラフ構造 DAGのみ サイクル可 -
ループ × ○(handoff)
条件分岐 × LLM判断
並列実行 -
進捗確認 ○(status/list) × ×

Workflowでは進捗確認(status/list)が可能です。ただし、条件分岐やループが必要な場合はGraphを選ぶべきです。

基本的なしくみ

Workflowパターンの構造を図で示すとこうなります。

strands-agents-workflow-dag-task-execution_1.png

Workflowはstrands-agents-toolsパッケージのworkflowツールを使用します。agent.tool.workflow()でプログラム的にワークフローを制御できます。

from strands import Agent
from strands_tools import workflow

agent = Agent(tools=[workflow])

# ワークフローの作成・開始
agent.tool.workflow(action="create", workflow_id="my_workflow", tasks=[...])
agent.tool.workflow(action="start", workflow_id="my_workflow")

利用可能なアクションは次のとおりです。

  • create - ワークフローを作成
  • start - ワークフローを開始(同期的に完了まで待機)
  • status - ステータスを確認
  • list - 全ワークフローの一覧を表示
  • delete - ワークフローを削除

実装例1: シーケンシャル実行

まずは基本的な順次実行の例から見ていきましょう。

ユースケース

調査 → 分析 → レポート作成という流れを実装します。

strands-agents-workflow-dag-task-execution_2.png

タスク定義

https://github.com/TAKEDA-Takashi/study-for-strands-agents/blob/main/04-workflow/01_basic_workflow.py#L26-L54

各タスクは辞書形式で定義します。ポイントは次のとおりです。

  • task_id - タスクの識別子
  • description - タスクの説明(LLMへの指示)
  • dependencies - 依存するタスクIDのリスト
  • priority - 優先度(高いほど優先)
  • model_providermodel_settings - 使用するモデルの設定

analysisタスクはdependencies: ["research"]で、reportタスクはdependencies: ["analysis"]と設定しています。これにより順次実行が保証されます。

ワークフローの実行

https://github.com/TAKEDA-Takashi/study-for-strands-agents/blob/main/04-workflow/01_basic_workflow.py#L61-L74

createでワークフローを作成し、startで実行します。startアクションは同期的に実行され、すべてのタスクが完了するまで待機します。

実装例2: 並列実行

次に、Workflowの真価が発揮される並列実行の例を見てみましょう。

ユースケース

市場調査として、競合分析・顧客ニーズ調査・市場トレンド調査を同時実行し、最後に統合レポートを作成します。

strands-agents-workflow-dag-task-execution_3.png

タスク定義

https://github.com/TAKEDA-Takashi/study-for-strands-agents/blob/main/04-workflow/02_parallel_workflow.py#L26-L65

3つの調査タスクはdependenciesを持たないため、並列実行されます。final_reportタスクは3つすべてに依存しているため、すべての調査が完了してから実行されます。

ポイント

  • 依存関係のないタスクは 自動的に並列実行 される
  • 最終タスクは すべての依存タスクの完了を待つ
  • 開発者は依存関係を宣言するだけでよく、並列化の詳細を意識する必要がない

実装例3: 複雑なDAG

最後に、より複雑な依存関係をもつワークフローの例を紹介します。

ユースケース

ソフトウェア開発プロセスをシミュレートします。要件定義から始まり、並列で開発を進め、統合・テスト・リリースへと進むフローです。

DAG構造

https://github.com/TAKEDA-Takashi/study-for-strands-agents/blob/main/04-workflow/03_complex_dag_workflow.py#L26-L47

この構造では次のような実行が行われます。

  1. requirementsが最初に実行
  2. frontend_devbackend_devapi_designが並列実行
  3. integrationはfrontendとbackendの完了を待つ
  4. api_implはapi_designとbackendの完了を待つ
  5. testingはintegrationとapi_implの完了を待つ
  6. 最後にreleaseが実行

タスク定義(一部)

https://github.com/TAKEDA-Takashi/study-for-strands-agents/blob/main/04-workflow/03_complex_dag_workflow.py#L49-L105

複雑な依存関係でも、各タスクにdependenciesを適切に設定するだけで、Workflowが自動的に実行順序を解決してくれます。

ポイント

  • 複雑な依存関係も宣言的に記述できる
  • 各タスクにtimeoutを設定して、長時間実行を防止できる
  • DAG構造のおかげで、どのタスクが並列実行可能かを自動判断

このパターンが向いているケース

固定された業務フローや、監査トレーサビリティが必要なケース、並列実行の最適化を重視する場合に向いています。

Apache AirflowやStep Functionsを使い慣れていれば、とても直感的に使えるでしょう。

逆に、条件分岐やループが必要な場合はGraphが適しています。文脈に応じて柔軟にエージェントを切り替えたいならSwarm、単純な専門家への委譲だけならAgents as Toolsの方がいいでしょう。

まとめ

Workflowは、Strands Agentsで 依存関係に基づいた決定論的なタスク実行 を実現するパターンです。strands-agents-toolsworkflowツールを使い、タスクの依存関係を宣言的に記述するだけで並列実行が最適化されます。

公式ドキュメントでは、監査要件があり各ステップの詳細な追跡が必要なケースに適していると説明されています。GraphやSwarmと比較するとループや条件分岐ができない分シンプルで、予測可能な動作が得られます。どなたかの参考になれば幸いです。

参考リンク

この記事をシェアする

FacebookHatena blogX

関連記事