Skills: マルチステップワークフロースキル
最終更新:2026-08-31
複雑なタスクは1ステップでは完了しない——マルチステップ Skill は「どう分割するか、どう繋ぐか、エラー時にどうするか」をフローに書き込む。
1. ワークフロー設計原則
(1) タスクの分解
TEXT
📖 参照専用
タスク分解の原則
├── 各ステップに明確な入力と出力がある
├── 各ステップが独立して検証可能
├── ステップ間の依存関係が明確
├── 重要ステップにチェックポイントがある
└── 例外時にフォールバック案がある
(2) ステップタイプ
| タイプ | 説明 | 例 |
|---|---|---|
| 順次ステップ | 順序通りに実行する必要がある | 先に依存関係をインストール、次にビルド |
| 条件ステップ | 条件を満たした時のみ実行 | テスト失敗時のみデバッグに進む |
| オプションステップ | スキップ可能 | ドキュメント生成 |
| ループステップ | 繰り返し実行 | ファイルのバッチ処理 |
| チェックポイント | 状態確認とスナップショット | ビルド完了後の検証 |
2. ワークフローのオーケストレーション
(1) リニアワークフロー
最もシンプルな順次実行:
TEXT
📖 参照専用
新機能開発ワークフロー
1. 要件分析 → 出力:要件ドキュメント
2. 技術案 → 出力:設計ドキュメント
3. コーディング実装 → 出力:ソースコード
4. ユニットテスト → 出力:テストレポート
5. コードレビュー → 出力:レビュー意見
6. マージ・デプロイ → 出力:リリース状態
(2) 条件分岐ワークフロー
TEXT
📖 参照専用
デプロイワークフロー
1. 事前チェック
2. テスト実行
3. 条件判定:
- テスト通過 → デプロイ続行
- テスト失敗 → デバッグ修正 → ステップ2に戻る
4. staging にデプロイ
5. ヘルスチェック:
- 通過 → 本番デプロイの確認
- 失敗 → ロールバック + 通知
(3) 並行ワークフロー
TEXT
📖 参照専用
並行タスクの例
┌→ ユニットテスト ─┐
事前チェック ──┤→ コードレビュー ─┤→ 結果集約 → デプロイ
└→ セキュリティスキャン ─┘
3. 例外処理と回復
(1) エラーのランク付け
| レベル | 処理戦略 | 例 |
|---|---|---|
| 🟢 無視可能 | ログに記録し、実行継続 | 非クリティカルな警告 |
| 🟡 リトライ可能 | N回リトライ後にエスカレーション | ネットワークタイムアウト |
| 🔴 即時停止 | チェックポイントにロールバック、人工に通知 | データ損失 |
(2) チェックポイントメカニズム
MARKDOWN
## チェックポイントの設定
1. 重要ステップの前:git commit で状態を保存
2. 危険操作の前:ユーザーの意図を確認
3. 取り消し不能な操作の前:バックアップを作成
4. 各フェーズ完了時:進捗レポートを出力
(3) 中断回復
MARKDOWN
## 中断回復フロー
1. 前回の進捗記録を読み込む
2. 完了済みステップを確認
3. 未完了ステップから再開
4. 完了済みステップの状態を検証
4. ワークフロー Skill の実践
▶ 例:バージョンリリースワークフロー
Alice は標準化されたバージョンリリース Skill を作成しました:
YAML
---
name: release-workflow
description: "バージョンリリースワークフロー"
triggers:
- keyword: "release|バージョンリリース"
tools:
- Read
- Write
- Edit
- Bash
- Grep
---
MARKDOWN
## リリースフロー
1. Bash: git status(作業ツリーがクリーンか確認)
2. Bash: npm test(全量テスト)
3. Edit: バージョン番号を更新
4. Bash: git tag + git push
5. Write: CHANGELOG を生成
6. Bash: npm run build
7. Bash: staging にデプロイ + ヘルスチェック
8. 確認後、production にデプロイ
Bob は言います:「リリースで最も怖いのはステップの漏れ——Skill がフローを固定化すれば、テストを忘れてそのままリリースすることはあり得ない。」
❓ よくある質問
Q ステップが多すぎるとパフォーマンスに影響しますか?
A はい。コアステップは8個以内、チェックポイントは3個以内をお勧めします。それ以上は複数の Skill に分割してチェーンすることを検討してください。
Q 中断後の回復方法は?
A 各重要ステップで状態記録(ファイルまたはログ)を出力し、中断後に記録を読み込んで回復ポイントを特定します。
Q 条件分岐が多すぎるとフローが複雑になりませんか?
A なります。分岐は3本以内、ネストは2層以内をお勧めします。より複雑なロジックは独立した Skill への分割を検討してください。
📖 まとめ
- 設計原則:各ステップに明確な I/O、検証可能、フォールバック案あり
- 3つのオーケストレーション:リニア、条件分岐、並行
- 例外処理:エラーランク付け、チェックポイントメカニズム、中断回復
- 実践の推奨:ステップ <8、分岐 <3、ネスト <2
📝 練習問題
- 基礎問題(難易度⭐):リニアワークフロー Skill を作成し、「テスト → ビルド → デプロイ」の3ステップフローを実装してください。
- 応用問題(難易度⭐⭐):条件分岐ワークフロー Skill を作成し、テスト失敗時に自動的にデバッグフローに入るようにしてください。
- チャレンジ問題(難易度⭐⭐⭐):チェックポイント、例外回復、ロールバックメカニズムを含む完全なバージョンリリース Skill を作成してください。