# Trigger Action Map

> 自動化フローのトリガー・アクション・条件分岐・エラー処理を可視化する。n8n / Webhook / cron 等の実装前に、フロー全体の抜け漏れを確認する。

- Skill: `thinkyou0714/trigger-action-map` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/trigger-action-map`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/trigger-action-map/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/trigger-action-map

---


## Purpose

自動化フローを「何が起きたら → 何をする → 失敗したらどうする」の形で網羅的に整理する。
実装前に全体像を可視化することで、実装後の「あのケースが抜けていた」を防ぐ。

## Use When

- n8n ワークフロー / Webhook / cron ジョブを設計する前
- 既存の自動化フローを見直す場合
- automation-feasibility の後、具体的なフロー設計に入る前
- 「このフロー、本当に全ケース網羅できているか」を確認したい場合

## Inputs

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

- **フローの目的**: この自動化で何を実現するか（1文）
- **トリガー**: 何がきっかけでフローが起動するか
- **期待する結果**: 正常終了時に何が起きているべきか
- **関係するシステム**: 連携する外部サービス・DB・API
- **失敗許容度**: 失敗した場合に即時対応が必要か、遅延可か

## Output Contract

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

1. **論点**: このフロー設計の核心的な判断ポイント（最も複雑・リスクが高い部分）
2. **根拠**: その論点をそう判断した理由
3. **トリガー・アクション・マップ**: 全ステップの可視化（後述フォーマット）
4. **含意**: フロー設計が示すシステム依存性・脆弱性
5. **改善案**: フローを単純化・堅牢化する工夫
6. **代替案**: 別のトリガー・別のフロー構造の可能性
7. **判断材料**: 実装前に人間が確認すべき設計上の判断事項

### トリガー・アクション・マップ フォーマット

```text
## フロー概要
目的: （1文）

## トリガー
- 種別: （Webhook / cron / 手動 / イベント）
- 発火条件: （何が起きたとき）
- 発火頻度: （都度 / 定期 / 条件付き）

## アクション一覧

| ステップ | 処理内容 | 使用サービス | 成功条件 | 失敗時の処理 |
|---|---|---|---|---|
| 1 | | | | |
| 2 | | | | |

## 条件分岐

| 分岐ポイント | 条件 | Trueの場合 | Falseの場合 |
|---|---|---|---|

## エラー処理

| エラー種別 | 検知方法 | 対処 | 通知先 |
|---|---|---|---|
| タイムアウト | | | |
| API エラー | | | |
| データ不整合 | | | |

## 副作用（意図しない影響）
- （このフローが他に与える影響）
```

## Review Lens

- **目的妥当性**: フロー設計が本来の目的を達成できるか
- **範囲の過不足**: 考慮すべきケースが抜けていないか（ハッピーパス以外）
- **中長期リスク**: 依存サービスが変更・廃止された場合の影響
- **LAB全体との整合性**: 既存の n8n フロー・Stripe Webhook との整合
- **非エンジニア理解可能性**: フロー図が非技術者に説明できる形か
- **他LLM移植耐性**: フロー設計が Claude 固有の実装に依存していないか

## Instructions

1. トリガーを「何が起きたとき（イベント）」「どのシステムが検知するか」の形で明確化する
2. アクションを「入力 → 処理 → 出力」の最小単位に分解する
3. 条件分岐を全て列挙する（「それ以外」のケースを必ず含める）
4. エラー処理を「タイムアウト / API失敗 / データ不整合 / 権限エラー」で分類する
5. 副作用（他のシステム・データへの影響）を明示する
6. べき等性（同じトリガーが2回来た場合の挙動）を確認する
7. 「このステップが失敗したら全体をリトライすべきか」を各ステップで確認する

## Guardrails

- ハッピーパスだけ設計して終わらない。必ずエラーケースを含める
- 「失敗したら通知する」だけでは不十分。通知先・対応手順を明示する
- べき等性が保証されていない場合は必ず指摘する
- 外部APIへの依存を「失敗しない前提」にしない
- フロー設計の最終承認は人間が行う

## LAB Cross-Check

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 既存 n8n / Webhook との整合を確認したか |
| データ / 認証 / ログ | — | フローのログ・監査証跡を設計に含めたか |
| 実装 / 運用フロー | — | 障害時の手動対応手順を含んでいるか |
| 非エンジニア理解可能性 | — | フロー概要を非技術者に説明できるか |
| 会員共有 / 再利用耐性 | — | マップの構造が他フローにも転用できるか |
| 他LLM移植耐性 | — | n8n 固有の記法に依存していないか |

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

## Handoff Notes

- **要件**: 実装するフローの仕様（トリガー・アクション・エラー処理）
- **成功条件**: フローが正常稼働していると判断できる基準
- **失敗条件**: フローが失敗したと判断する基準と発動条件
- **実行範囲**: 実装してよいワークフロー・API・DB
- **影響範囲**: このフローが影響する他のシステム・プロセス
- **ロールバック方針**: フロー停止時の手動フォールバック手順
- **コスト比較**: 各実装オプションの工数概算

## Further Reading

- `automation-feasibility` skill — フロー設計前の可否判断
- `retry-idempotency-check` skill — べき等性・リトライ設計の深掘り
- `failure-point-review` skill — 障害点のより詳細な分析
- `monitoring-alert-design` skill — 監視・アラートの設計