OpenFang 自動化ワークフロー構築ガイド

約7分で読めます

単一のエージェントでできることには限界がありますが、複数のエージェントを連携させることで真のエンドツーエンド自動化が実現します。本記事では、4つの完全なケーススタディ(日次業界レポート、競合モニタリングとアラート、コンテンツ制作パイプライン、カスタマーサポートの分類とエスカレーション)を通じて、OpenFangワークフローエンジンの全機能を習得する方法を解説します。

OpenFang 自動化ワークフロー構築ガイド:単一エージェントからエージェントチームへ

Slug: openfang-workflow-automation-guide カテゴリー: usage-guides (使用ガイド) ターゲットキーワード: OpenFang ワークフロー, OpenFang 自動化プロセス, OpenFang マルチエージェント連携 検索意図: 情報収集(複雑なエージェント自動化プロセスの構築を希望) 目標文字数: 約2000文字 言語: ja


なぜワークフローが必要なのか?

単一のエージェントがこなせるタスクには限界があります。「トピックの調査 → 記事の執筆 → 事実確認 → 公開 → フィードバックの監視」といったエンドツーエンドのプロセスを実現するには、複数のエージェントをワークフローとして連携させる必要があります。

OpenFangのワークフローエンジンは、シリアルパイプライン(Pipeline)、並列分散(Fan-out)、条件分岐(Conditional)の3つの連携モードをサポートしています。レゴブロックを組み立てるように、Handsとエージェントを組み合わせて複雑な自動化プロセスを作成できます。

本記事では、4つの実践的なケーススタディを通じて、シンプルなものから複雑なものまで、OpenFangワークフローの構築方法を習得します。

ワークフローの基本概念

ケーススタディに入る前に、いくつかの重要な概念を理解しておきましょう:

概念説明
Taskワークフローの最小実行単位。1つのTaskは1つのHandまたはエージェントに対応
Pipeline複数のTaskを直列につなぎ、前のTaskの出力を次のTaskの入力として自動的に渡す
Fan-out1つの作業を複数のエージェントに分散して並列処理し、最後に結果を統合する
Triggerワークフローを開始するイベント源:スケジュール実行、Webhook、ファイル変更、メッセージコマンド
Contextワークフローの各ステップ間で共有される状態。プログラミング言語の変数スコープに類似

ケース1:日次業界レポート(シンプルなパイプライン)

最もシンプルなパイプラインワークフローの例です。毎朝自動的に業界ニュースの要約を作成します:

toml
[[workflows]]name = "daily_industry_briefing"description = "毎朝8時に前日の業界動向レポートを生成"[workflows.trigger]type = "schedule"cron = "0 8 * * 1-5"             # 平日の朝8時[[workflows.tasks]]id = "monitor"hand = "collector"config = { keywords = ["AI agent", "Rust framework"], sources = ["news", "github"] }timeout = 300[[workflows.tasks]]id = "summarize"hand = "researcher"config = { depth = "shallow", focus = "summary" }depends_on = ["monitor"]timeout = 600[[workflows.tasks]]id = "notify"channel = "slack"config = { channel = "#industry-news", format = "rich_text" }depends_on = ["summarize"][workflows.output]format = "slack_message"save_to = "workspace/briefings/{{date}}.md"

ワークフローの実行順序:Collectorで収集 → Researcherで要約 → Slackで通知。depends_onでタスク間の依存関係を定義します。

ケース2:競合モニタリングとアラート(並列処理 + 統合)

複数の競合サイトを同時に監視し、並列収集した結果を統合・分析するワークフローです:

toml
[[workflows]]name = "competitor_monitor"description = "5つの競合サイトを並列監視し、変更があればアラートを送信"[workflows.trigger]type = "schedule"cron = "0 */6 * * *"# ステージ 1: 並列収集(Fan-out)[[workflows.tasks]]id = "check_competitor_a"hand = "collector"config = { target = "competitor-a.com", mode = "diff" }[[workflows.tasks]]id = "check_competitor_b"hand = "collector"config = { target = "competitor-b.com", mode = "diff" }[[workflows.tasks]]id = "check_competitor_c"hand = "collector"config = { target = "competitor-c.com", mode = "diff" }# ステージ 2: 統合分析(全収集完了を待機)[[workflows.tasks]]id = "aggregate"hand = "researcher"config = { action = "merge_and_prioritize" }depends_on = ["check_competitor_a", "check_competitor_b", "check_competitor_c"]# ステージ 3: 条件判断 — 重要な変更がある場合のみ通知[[workflows.tasks]]id = "check_significance"hand = "predictor"config = { action = "assess_impact" }depends_on = ["aggregate"]# ステージ 4: 条件付き通知[[workflows.tasks]]id = "alert_high"channel = "telegram"config = { chat_id = "-100xxx", priority = "high" }depends_on = ["check_significance"]condition = "ctx.significance_score > 0.7"[[workflows.tasks]]id = "alert_low"channel = "email"config = { to = "[email protected]", priority = "low" }depends_on = ["check_significance"]condition = "ctx.significance_score <= 0.7"

ここでの重要なパターンは以下の通りです:

  • Fan-out: ステージ1の5つの収集タスクは並列実行され、depends_onは不要です。
  • Barrier: ステージ2のAggregateは、5つすべての収集タスクの完了を待機します。
  • Conditional: ステージ4では、重要度スコアに基づいて通知チャネルを切り替えます。

ケース3:コンテンツ制作パイプライン(マルチエージェント連携)

AIによる執筆、校閲、画像生成を組み合わせた、典型的なマルチエージェント連携シナリオです:

toml
[[workflows]]name = "content_pipeline"description = "トピックから公開までを全自動化するコンテンツ制作パイプライン"[workflows.trigger]type = "webhook"endpoint = "/webhook/content/new"secret = "${WEBHOOK_SECRET}"# ステージ 1: リサーチ[[workflows.tasks]]id = "research"hand = "researcher"config = {  depth = "deep",  source_types = ["academic", "news", "social"],  target_length = "3000_words"}timeout = 900# ステージ 2: 執筆(異なるモデルを使用)[[workflows.tasks]]id = "draft"hand = "researcher"              # Researcher Handを再利用し、異なるプロンプトを使用config = {  model = "claude-opus-4-8",  instruction = "draft_article",  style = "professional_yet_approachable"}depends_on = ["research"]# ステージ 3: 事実確認[[workflows.tasks]]id = "fact_check"hand = "researcher"config = {  model = "claude-haiku-4-5",   # 高速モデルでチェック  action = "verify_claims",  strictness = "high"}depends_on = ["draft"]# ステージ 4: 画像生成[[workflows.tasks]]id = "generate_cover"hand = "clip"config = {  action = "generate_cover_image",  style = "modern_tech",  resolution = "1280x720"}depends_on = ["draft"]           # 事実確認を待たずに並列実行可能# ステージ 5: SEO最適化[[workflows.tasks]]id = "seo_optimize"hand = "researcher"config = { action = "seo_optimize", target_keyword = "{{.keyword}}" }depends_on = ["fact_check"]# ステージ 6: 公開[[workflows.tasks]]id = "publish"channel = "webhook"config = { url = "{{.cms_endpoint}}", method = "POST" }depends_on = ["seo_optimize", "generate_cover"]# ステージ 7: プロモーション[[workflows.tasks]]id = "promote"channel = "twitter"config = { action = "post_thread", hashtags = ["#AI", "#Automation"] }depends_on = ["publish"]

ステージ4の generate_coverdraft にのみ依存し、fact_check には依存していません。これにより、画像生成と事実確認が並列で行われ、全体の待ち時間が短縮されます。

ケース4:カスタマーサポートの分類とエスカレーション(条件ルーティング)

問い合わせ内容に応じて処理プロセスを自動的に振り分ける、インテリジェントなカスタマーサポートワークフローです:

toml
[[workflows]]name = "support_triage"description = "インテリジェントなカスタマーサポート:分類 → ルーティング → 処理 → エスカレーション"[workflows.trigger]type = "message"channel = "whatsapp"pattern = "/help *"# 分類[[workflows.tasks]]id = "classify"hand = "researcher"config = {  model = "claude-haiku-4-5",  action = "classify_intent",  categories = ["billing", "technical", "feature_request", "complaint"]}# 請求関連 → システム照会[[workflows.tasks]]id = "handle_billing"channel = "webhook"config = { url = "https://billing-api.company.com/lookup" }depends_on = ["classify"]condition = "ctx.intent == 'billing'"# 技術関連 → ナレッジベース検索[[workflows.tasks]]id = "search_kb"hand = "researcher"config = { action = "search_knowledge_base", max_results = 3 }depends_on = ["classify"]condition = "ctx.intent == 'technical'"# 機能リクエスト → Product Boardへ記録[[workflows.tasks]]id = "log_feature"channel = "webhook"config = { url = "https://productboard-api.company.com/notes" }depends_on = ["classify"]condition = "ctx.intent == 'feature_request'"# クレーム → 即時有人対応へエスカレーション[[workflows.tasks]]id = "escalate"channel = "slack"config = { channel = "#urgent-support", mention = "@oncall" }depends_on = ["classify"]condition = "ctx.intent == 'complaint'"# 最終回答[[workflows.tasks]]id = "reply"channel = "whatsapp"config = { reply_to = "{{.original_message.id}}" }depends_on = ["handle_billing", "search_kb", "log_feature", "escalate"]

ワークフローのデバッグとテスト

本番環境へデプロイする前に、Dry Runモードでワークフローをテストすることをお勧めします:

bash
# Dry run(外部操作は実行されません)openfang workflow run competitor_monitor --dry-run# 指定したタスクまで実行openfang workflow run content_pipeline --until draft# ワークフロー実行履歴の確認openfang workflow history competitor_monitor --limit 10# 特定の実行ログの詳細確認openfang workflow inspect competitor_monitor --run-id abc123

ワークフローのベストプラクティス

  1. 適切なタイムアウト設定: 各タスクに timeout を設定し、1つのステップがプロセス全体を停止させないようにします。
  2. リトライメカニズムの追加: ネットワークリクエストを行うタスクには retry = 3 と指数バックオフを設定します。
  3. 条件分岐の活用: 不要なタスクの実行を避け、APIコストを節約します。
  4. 実行ログの記録: 問題調査のために log_level = "debug" を設定します。
  5. ワークフローの健全性監視: ワークフローのメトリクスをPrometheus/Grafanaに統合します。

よくある質問

1つのワークフローで最大いくつのタスクをサポートしていますか?
ハード制限はありません。ただし、保守性を維持するため、1つのワークフローあたりのタスク数は20個以内に抑えることを推奨します。より複雑なプロセスは、複数のサブワークフローに分割してください。
タスクの実行失敗をどう処理しますか?
各タスクに対して個別に失敗時の戦略を設定できます:

``toml
[workflows.tasks.fallback]
on_failure = "continue" # continue / retry / abort / escalate
retry_count = 3
retry_delay_seconds = 60
fallback_task = "manual_review" # 失敗時の代替タスク
``

ワークフロー同士を呼び出すことはできますか?
はい。trigger.type = "workflow" を使用すると、あるワークフローから別のワークフローをトリガーできます。条件分岐と組み合わせることで、複雑なネストロジックを実現可能です。
ワークフロー間で動的なパラメータを渡すには?
テンプレート構文 {{.variable_name}} を使用します。コンテキスト変数のソースには、トリガーデータ、前のタスクの出力、グローバル設定変数などがあります。

次のステップ