Automation Feasibility

Purpose

「とりあえず自動化する」による過剰投資と、「手動でいい」による機会損失の両方を防ぐ。 自動化の可否・優先度・適切な実装レベルを判断する材料を提供する。

Use When

• 反復的な手動作業を自動化したい場合
• n8n / Webhook / cron 等を使った自動化を検討している場合
• 「自動化すべきか手動でよいか」の判断が必要な場合
• 自動化を提案する前に ROI を確認したい場合

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 対象プロセス: 自動化を検討しているプロセスの説明（手順を含む）
• 現状の頻度・工数: 現在どのくらいの頻度で、何分かかっているか
• 失敗時の影響: 自動化が失敗した場合の影響範囲
• 技術的環境: 使用可能なツール・API・インフラ
• 許容ダウンタイム: 自動化が止まった場合に何時間まで許容できるか

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: この自動化の可否を左右する核心的な判断軸
2. 根拠: その論点をそう判断した理由
3. 実現可能性評価: 技術・コスト・リスクの3軸評価
4. 含意: 自動化する/しないが示す中長期的な意味
5. 改善案: 実現可能性を高める段階的アプローチ
6. 代替案: 完全自動化以外の選択肢（半自動・ツール補助等）
7. 判断材料: 「自動化する / 後回し / 手動継続」を選ぶための情報

実現可能性評価 フォーマット

Review Lens

• 目的妥当性: 自動化が本来の目的に対して有効か（自動化のための自動化になっていないか）
• 範囲の過不足: 自動化範囲が広すぎ/狭すぎていないか
• 中長期リスク: 依存ライブラリ・外部API の変更リスクを考慮しているか
• LAB全体との整合性: n8n / Stripe Webhook / Supabase の既存自動化と整合しているか
• 非エンジニア理解可能性: 自動化の効果と障害リスクを非技術者に説明できるか
• 他LLM移植耐性: 評価基準が Claude 固有の解釈に依存していないか

Instructions

1. 対象プロセスを「トリガー → 処理 → 結果」の形に分解する
2. 各ステップに「自動化できるか」「何を使って実装するか」を付ける
3. 自動化コスト（初期実装工数）と手動コスト（月次換算）を概算する
4. ROI 回収期間を概算する（自動化コスト ÷ 月次削減工数）
5. 失敗シナリオを最低3つ列挙し、各々の影響度を評価する
6. 「今すぐ自動化 / 次フェーズで / 手動継続」の推奨観点を提示する（断定しない）
7. 自動化しない場合のリスクも明示する

Guardrails

• 「自動化できる = すべき」と断定しない。ROI とリスクをセットで示す
• 外部 API・サービスへの依存リスクを省略しない
• 失敗時のフォールバック（手動対応）が存在しない場合は必ず指摘する
• コスト比較（自動化コスト vs 手動コスト）を省略しない
• 最終判断は人間が下す

LAB Cross-Check

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

• 要件: 自動化する処理の仕様（トリガー・処理・出力・エラー時の挙動）
• 成功条件: 自動化が正常稼働していると判断できる基準
• 失敗条件: 自動化が失敗したと判断する基準と発動条件
• 実行範囲: 実装してよいファイル・ワークフロー・API
• 影響範囲: 自動化が影響する他のシステム・プロセス
• ロールバック方針: 自動化停止時の手動フォールバック手順
• コスト比較: 自動化コスト vs 手動継続コストの概算

Further Reading

• manual-vs-automation-cost skill — コスト比較をより詳細に行う
• trigger-action-map skill — 自動化フローのトリガー・アクション設計
• failure-point-review skill — 自動化フローの障害点を深掘り
• monitoring-alert-design skill — 自動化の監視設計
• docs/CONTEXT.md — n8n 自動化の現状