Retry Idempotency Check

Purpose

「リトライしたら二重に請求された」「同じデータが2行挿入された」を防ぐ。 べき等性の有無を確認し、リトライが安全に行えるフロー設計を保証する。

Use When

• Webhook / API 呼び出しを含む自動化フローを設計する前
• Stripe Webhook の処理ロジックを設計・レビューする場合
• trigger-action-map の後に、リトライ安全性を確認したい場合
• 「このフロー、二重実行されたらどうなる?」が気になる場合

Inputs

• 対象フロー・処理: べき等性を確認する処理の説明
• リトライのトリガー: どのような条件でリトライが発生するか
• 外部 API: 呼び出す外部サービス（Stripe / Supabase / n8n 等）
• データ変更の有無: DB への INSERT / UPDATE / DELETE が含まれるか

Output Contract

1. 論点: このフローのべき等性で最も危険な箇所
2. 根拠: その論点をそう判断した理由
3. べき等性評価: 処理ステップ別の安全性確認
4. 含意: べき等性の欠如が引き起こすビジネス・データへの影響
5. 改善案: べき等キー・冪等性保証の実装方針
6. 代替案: 別のリトライ設計・フォールバック方式
7. 判断材料: リトライ設計の確定に必要な人間の判断事項

べき等性評価 フォーマット

Review Lens

• 目的妥当性: べき等性確認が本来の安全性目的に対して有効か
• 範囲の過不足: 外部APIへの副作用（メール送信・決済等）を全て確認したか
• 中長期リスク: べき等キーの衝突・有効期限切れのリスク
• LAB全体との整合性: Stripe Webhook のべき等性設計を含んでいるか
• 非エンジニア理解可能性: 「同じ処理が2回起きても安全か」を説明できるか
• 他LLM移植耐性: 設計が Claude 固有に依存していないか

Instructions

1. フローの各ステップを「読み取り / 書き込み / 外部API呼び出し」に分類する
2. 書き込み・外部API の各ステップにべき等性があるか確認する
3. べき等キー（idempotency key）が必要な箇所を特定する
4. Stripe Webhook は idempotency_key の実装を必ず確認する
5. DB への INSERT は ON CONFLICT DO NOTHING または UPSERT を検討する
6. リトライ回数・バックオフ方針を定義する（無限リトライは禁止）
7. リトライが安全でない処理（メール送信等）の重複防止策を設計する

Guardrails

• 「リトライしない」をフォールバックとして採用する場合は、失敗の検知方法を必ず含める
• べき等キーの有効期限を「無期限」にしない
• Stripe の二重請求は特に慎重に確認する（テスト環境で必ず検証）
• 「おそらく大丈夫」でべき等性を確認済みにしない

LAB Cross-Check

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

Handoff Notes

• 要件: べき等性を保証する実装仕様（べき等キー・UPSERT 設計等）
• 成功条件: 同一フローが2回実行されてもデータが重複しない状態
• 失敗条件: 重複データ・二重請求が発生した場合の検知基準
• 実行範囲: 修正してよいワークフロー・API ハンドラー・DB テーブル
• 影響範囲: べき等性変更が波及する他の処理・テスト
• ロールバック方針: 実装変更が失敗した場合の戻し方
• コスト比較: べき等キー実装の工数 vs 二重実行リスクのコスト

Further Reading

• trigger-action-map skill — フロー全体のリトライポイント確認
• failure-point-review skill — リトライ失敗の障害パターン
• monitoring-alert-design skill — リトライ失敗の監視・アラート