Workflow Designer

ワークフローデザイナー

ワークフローデザイナーのスキルは、AI を活用した複数ステップのワークフローの設計、文書化、最適化を支援します。プロセス設計の原則を適用し、複雑なタスクを、Claude Code の機能、外部ツール、複数エージェント間の連携を活用する、明確で実行可能な手順に分解します。

このスキルでは、ワークフローの分析、最適なタスク分解の特定、自動化と人間による入力の使い分けの判断、人間にも読みやすく AI にも実行可能な形式でのワークフローの文書化を案内します。エラー処理、分岐ロジック、検証手順、統合ポイントについて検討する際にも役立ちます。

AI の支援が有効な複雑な複数ステップのプロセスに取り組む場合や、場当たり的な手順を、繰り返し実行できる文書化済みのワークフローに変換する必要がある場合に、このスキルを使用してください。

主なワークフロー

ワークフロー 1：要件から新しいワークフローを設計する

1. 目標を明確にします：
   • どのような成果が必要ですか？
   • 誰がワークフローを開始しますか？
   • 何をもって完了としますか？
2. 入力と出力を特定します：
   • 開始時に必要なデータやコンテキストは何ですか？
   • ワークフローで何を生成しますか？
   • 出力はどのような形式にしますか？
3. プロセスをマッピングします：
   • 論理的なフェーズに分割する
   • 意思決定ポイントを特定する
   • ステップ間の依存関係をマッピングする
   • 並列処理と逐次処理を明確にする
4. エラー処理を設計します：
   • 各ステップでどのような問題が起こり得ますか？
   • 失敗にどう対処しますか？
   • 人間の介入が必要なのはどのケースですか？
5. 担当を割り当てます：
   • どのステップを AI が実行できますか？
   • どのステップに人間の判断が必要ですか？
   • 外部ツールや API が必要なステップはどれですか？
6. ワークフローを文書化します：
   • ステップごとの手順
   • 意思決定ツリー
   • 検証チェックポイント
   • 成功基準
7. サンプルシナリオでテストします
8. 結果に基づいて改善します

ワークフロー 2：既存のワークフローを最適化する

1. 現在のワークフローを分析します：
   • 現在のステップをマッピングする
   • ボトルネックを特定する
   • 反復的なタスクを記録する
   • エラーが起こりやすい箇所を見つける
2. 最適化の機会を特定します：
   • 自動化できることは何ですか？
   • 並列化できることは何ですか？
   • 不要なステップはどれですか？
   • 引き継ぎが非効率な箇所はどこですか？
3. 改善を加えて再設計します：
   • 冗長なステップを統合する
   • 反復的なタスクを自動化する
   • 独立した処理を並列化する
   • 早い段階で検証を追加する
4. 改善前後を比較します：
   • 所要時間の短縮
   • エラーの削減
   • 複雑さの変化
   • 必要なリソース
5. 変更内容とその理由を文書化します
6. 新しいワークフローへの移行を計画します
7. 新しいワークフローを十分にテストします

ワークフロー 3：複雑なタスクを分解する

1. 複雑なタスクを理解します：
   • 何が複雑さの原因ですか？
   • どのような構成要素がありますか？
   • どのような制約がありますか？
2. サブタスクに分解します：
   • 論理的な境界を特定する
   • 関連する処理をまとめる
   • 依存関係に基づいて順序を決める
3. インターフェースを定義します：
   • 各サブタスクへの入力
   • 各サブタスクからの出力
   • タスク間のデータフロー
4. 適切な実行者に割り当てます：
   • AI エージェント
   • 外部ツール／MCP
   • 人間によるレビュー箇所
5. 調整レイヤーを追加します：
   • サブタスクはどのように連携しますか？
   • 全体の進捗を監視するのは何ですか？
   • 結果をどのように統合しますか？
6. 分解内容を文書化します
7. 完全性を検証します

ワークフロー 4：エラー処理と回復力を追加する

1. 潜在的な障害箇所をマッピングします：
   • 外部 API の障害
   • 無効な入力
   • リソースの制約
   • タイムアウトの発生
2. エラー処理の方針を設計します：
   • 機能を段階的に縮退させる
   • バックオフを伴う再試行ロジック
   • フォールバックの選択肢
   • エラーの報告
3. 検証チェックポイントを追加します：
   • 各ステップの実行前条件
   • 各ステップの実行後条件
   • 中間結果の検証
4. 復旧メカニズムを実装します：
   • 状態の保持
   • チェックポイントからの再開
   • ロールバック手順
5. エラーのシナリオを文書化します：
   • X が失敗した場合の対処方法
   • 復旧方法
   • エスカレーションのタイミング
6. 障害シナリオをテストします

クイックリファレンス

アクション	コマンド／トリガー
新しいワークフローを設計する	「[タスク] のワークフローを設計して」
既存のワークフローを最適化する	「このワークフローを最適化して：[説明]」
複雑なタスクを分解する	「このタスクを分解して：[タスク]」
エラー処理を追加する	「このワークフローにエラー処理を追加して：[ワークフロー]」
ワークフローを文書化する	「このプロセスを文書化して：[プロセス]」
ワークフローを可視化する	「[ワークフロー] のフローチャートを作成して」
ワークフローの設計を検証する	「このワークフローの設計をレビューして：[設計]」

ベストプラクティス

• 成果から始める：手順を設計する前に成功の定義を決めます

  • 「完了」とはどのような状態ですか？
  • どのような成果物が存在すべきですか？
  • システムはどのような状態であるべきですか？

• 手順を最小単位にする：各手順は単一の目的を持つようにします

  • 明確なアクションを1つ
  • 明確な出力を1つ
  • 検証しやすい
  • 置き換えや改善がしやすい

• 依存関係を明示する：何が何に依存しているかを示します

  • 有向グラフまたは番号付きの依存関係を使用します
  • 並列化できる操作を特定します
  • 処理を妨げる依存関係を記載します

• 失敗に備える：すべてのワークフローには例外的なケースがあります

  • API が停止している場合はどうしますか？
  • 入力の形式が正しくない場合はどうしますか？
  • 処理に時間がかかりすぎる場合はどうしますか？
  • ユーザーがキャンセルした場合はどうしますか？

• 早い段階で検証を追加する：問題の連鎖を防ぎます

  • 処理の前に入力を検証します
  • 次の手順に渡す前に出力を確認します
  • 判断箇所で前提を確認します

• 判断箇所を文書化する：分岐ロジックを明確にします

  • どのような条件で各経路に進みますか？
  • 判断基準は何ですか？
  • 誰が判断しますか（AI と人間）？

• 関心事を分離する：関連する操作をまとめます

  • データ収集フェーズ
  • 処理フェーズ
  • 検証フェーズ
  • 出力生成フェーズ

• 再開できるようにする：長時間のワークフローでは中断に対応できるようにします

  • チェックポイントで状態を保存します
  • 最後のチェックポイントから再開できるようにします
  • 進捗を明示的に追跡します

• 例外的なケースでテストする：通常の成功パスだけでテストしないでください

  • 形式が正しくない入力
  • 依存関係の不足
  • タイムアウトのシナリオ
  • 同時実行

ワークフロー設計パターン

シーケンシャルパイプライン

Input → Step 1 → Step 2 → Step 3 → Output

使用する場面：各手順が前の手順の出力に依存する場合 例：データの取り込み → 検証 → 変換 → 保存

並列実行

Input → [Step 1, Step 2, Step 3] → Merge → Output

使用する場面：独立した操作を同時に実行できる場合 例：Lint、Test、Type-check → 結果を集約 → レポート

条件分岐

Input → Decision → [Path A | Path B] → Merge → Output

使用する場面：条件に応じて異なる経路を進む場合 例：ファイル形式の判定 → [JSON パーサー | CSV パーサー] → 正規化

反復的な改善

Input → Process → Validate → [Done? → Output | Refine → Process]

使用する場面：反復によって出力品質が向上する場合 例：コードを生成 → レビュー → [許容可能？ → デプロイ | 問題を修正 → 生成]

マルチエージェントオーケストレーション

Input → Coordinator → [Agent A, Agent B, Agent C] → Synthesizer → Output

使用する場面：複雑なタスクに専門のサブエージェントが必要な場合 例：機能リクエスト → プランナー → [デザイナー、開発者、テスター] → インテグレーター → PR

イベント駆動型ワークフロー

Trigger → [Handler 1, Handler 2, Handler N] → Aggregate → Output

使用する場面：イベント／ウェブフックに応答するワークフローの場合 例：Git push → [ビルド、テスト、デプロイ、通知] → ステータスを更新

ワークフロー文書化テンプレート

## Workflow: [Name]

### Purpose
[What this workflow accomplishes]

### Triggers
- [What initiates this workflow]

### Inputs
- [Required inputs]
- [Optional inputs]

### Steps
1. **[Step Name]**
   - Action: [What happens]
   - Owner: [AI | Human | Tool]
   - Input: [What this step receives]
   - Output: [What this step produces]
   - Validation: [How to verify success]
   - On failure: [What to do if this fails]

2. **[Step Name]**
   [...]

### Decision Points
- **[Decision Name]**
  - Condition: [What determines the path]
  - If true: [Path A]
  - If false: [Path B]

### Outputs
- [What the workflow produces]
- [Where outputs are stored/sent]

### Success Criteria
- [How to know the workflow succeeded]

### Error Handling
- [Common failures and responses]

### Estimated Duration
- [How long this typically takes]

### Dependencies
- [External tools/services required]
- [Other workflows this depends on]

追跡するワークフローのメトリクス

ワークフローを設計する際は、次の指標の測定を検討してください。

• 所要時間：ワークフローの完了にどれくらいかかりますか？
• 成功率：正常に完了する割合はどれくらいですか？
• ボトルネック：最も時間がかかる手順はどれですか？
• 失敗箇所：最も頻繁にエラーが発生するのはどこですか？
• 再試行率：手順の再試行はどれくらいの頻度で必要ですか？
• 人間の介入：手動操作が必要になる頻度はどれくらいですか？
• リソース使用量：計算コスト／金銭的コストはどれくらいですか？

よくある落とし穴

• 過剰な設計：まだ発生していない問題に複雑さを持ち込まないでください
• 仕様不足：ドキュメントなしで手順が自明だと思い込まないでください
• 失敗の無視：成功するケースだけを想定して設計しないでください
• 密結合：手順を実装の詳細に過度に依存させないでください
• ロールバック手段がない：破壊的な操作を取り消せないようにしないでください
• 検証不足：不正なデータを手順間で渡さないでください
• 並列化できる処理を逐次実行する：独立した操作を順番に実行しないでください
• 進捗状況を追跡できない：長いワークフローをブラックボックスにしないでください