5. ワークフローのタスク分解における粒度決定の指針
「分解しすぎる」ことによるオーバーヘッドの増大
タスクを細かく分解することは、制御性を高める上で非常に有効ですが、分解の粒度が細かくなりすぎると、その「制御のためのオーバーヘッド」が処理時間やコストを圧迫し、かえって非効率になることがあります。どこまでを「タスク」と見なすかの線引きが、設計の成否を分けます。
タスク分解の目的と粒度の定義
タスク分解の目的は、単に処理を分割することではなく、**「失敗した場合に、どの部分で、なぜ失敗したのか」を特定し、かつ「再試行可能な最小単位」に分割すること**にあります。これが「適切な粒度」の定義です。
適切な粒度とは、以下の条件を満たす最小単位です。
| 条件 | 意味合い | 設計への影響 |
|---|---|---|
| 1. 独立性 | 他のステップの成功・失敗に依存しない、自己完結した処理であること | この単位で実行し、結果を外部ストアに書き出すことを前提とする |
| 2. 失敗の局所性 | 失敗した場合、その失敗が他のステップに影響を与えない範囲で完結すること | エラーハンドリングが容易で、リトライの単位として最適である |
| 3. 最小の実行単位 | これ以上分割すると、オーバーヘッド（メッセージ送信、状態書き込みなど）が無視できないほど増大するか、または処理が意味をなさなくなる点 | この単位を越えて分割すると、制御コストが処理価値を上回る |
粒度決定のための判断フロー
以下のフローチャート的な思考プロセスで判断を進めてください。
- ステップ1: 最終ゴールを特定する。（例：レポート生成）
- ステップ2: 必要な入力データと出力データを洗い出す。（例：データA, データB $\rightarrow$ レポートJSON）
- ステップ3: 依存関係をマッピングする。（データAの取得 $\rightarrow$ データBの加工 $\rightarrow$ レポート生成）
- ステップ4: 各ステップの「責務」を定義する。（データA取得は「データ取得ワーカー」、データB加工は「データ加工ワーカー」など、責務ごとに分割する。）
過剰分解によるコスト増大の回避
過剰な分解は、メッセージキューのメッセージ数、状態ストアへの書き込み回数、そして各ステップの実行オーバーヘッド（OpenClawのオーバーヘッド）を増大させます。例えば、単なるデータ整形（例：文字列のトリミングや大文字小文字の統一）を個別のステップにすると、その分の制御コストが処理価値を上回るため、単一のスクリプト内で処理すべきです。
まとめ：制御コストと処理価値のバランス点を見極める
タスク分解は、単なる分割作業ではなく、システム全体の「コスト計算」です。各ステップの「処理価値」と「制御コスト（オーバーヘッド）」を天秤にかけ、最も効率的で信頼性の高い粒度を見極めることが、設計の成否を分けます。
