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 への分割を検討してください。

📖 まとめ


📝 練習問題

  1. 基礎問題(難易度⭐):リニアワークフロー Skill を作成し、「テスト → ビルド → デプロイ」の3ステップフローを実装してください。
  2. 応用問題(難易度⭐⭐):条件分岐ワークフロー Skill を作成し、テスト失敗時に自動的にデバッグフローに入るようにしてください。
  3. チャレンジ問題(難易度⭐⭐⭐):チェックポイント、例外回復、ロールバックメカニズムを含む完全なバージョンリリース Skill を作成してください。
Web-Tutorial.com

Web-Tutorial 技術チーム

複数の開発者によって共同維持されているプログラミングチュートリアルプラットフォーム。各チュートリアルは専門分野の開発者が執筆・レビューしています。正確で信頼性の高いコンテンツを目指しています — 問題を見つけた場合はお知らせください。

100%