# Retry Idempotency Check

> 自動化フロー・API 呼び出しのリトライ設計とべき等性を確認する。同じ処理が複数回実行された場合に、データ破損・二重決済・重複挿入が起きないかを検証する。リトライ・再実行を伴う処理の設計時に使う。

- Skill: `thinkyou0714/retry-idempotency-check` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/retry-idempotency-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/retry-idempotency-check/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/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. **判断材料**: リトライ設計の確定に必要な人間の判断事項

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

| ステップ | 処理内容 | べき等か | リトライ安全か | 対応が必要な理由 |
|---|---|---|---|---|
| 1 | | Yes/No/条件付き | Yes/No | |

## 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

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | n8n のリトライ設定と整合しているか |
| データ / 認証 / ログ | — | 重複挿入・更新のリスクを DB 設計で防げているか |
| 実装 / 運用フロー | — | リトライ失敗の検知・対応手順が存在するか |
| 非エンジニア理解可能性 | — | 「安全に再試行できる」を説明できるか |
| 会員共有 / 再利用耐性 | — | べき等性チェックの枠組みが他フローに転用できるか |
| 他LLM移植耐性 | — | 設計が Claude 固有に依存していないか |

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

## Handoff Notes

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

## Further Reading

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