検証ツール、決済システム実装レビューエージェントを公開──Claude Code による Web3 決済コードの 5 大バグを特定
AI に決済コードを実装・レビューさせた際に出現した「正常系は通るが壊れたときに回収できない」5 つの致命的な設計バグと対策を公開した。
リリース: 2026-08-05 · 読了 5 分記事の要約
1. 核心（What）
- RPC のレート制限やタイムアウトによる例外を広すぎる正規表現で拾った結果、未決済のユーザーに「支払い済み」と誤表示するバグが特定された。
- 状態を「送信中」に進めた後に署名・送信処理が例外で落ちた場合、進めた状態を戻す回収経路がなく無限ポーリングに陥る設計ミスが判明した。
- ガス価格を上げて再送するスピードアップ機能が呼び出し元から一切参照されておらず、 dead code になっていたことが判明した。
- ブロック番号の増加をそのまま着金確定と見なしたことで、 reorg（チェーンの分岐・巻き戻し）発生時に誤って Webhook が発火する危険性があった。
2. 影響（Why）
- 失敗時の回収コストの非対称性: 正常系ばかりに気を取られていると、外部 RPC の一時障害で決済が致命的な誤判定を起こすリスクを見落としやすい。
- 国内の決済・Web3 事業者への教訓: 決済という取り消せない処理を扱うシステムでは、実装した機能が確実に経路に載っているか、失敗時に安全側へ倒れるかを型とコードで強制する必要がある。
3. 根拠・詳細（How）
- 正規表現の範囲限定と例外の厳密な分類: /nonce/ のような広すぎるパターンマッチを避け、分類できない RPC のエラーは安全側（再試行・保留）に倒す設計へ改修した。
- 状態変更と回収経路の対ペア化: advanceState で状態を更新する前に、万が一の例外時に状態を戻す revertOrRecover 経路を必ずセットで記述する構造に変更した。
- 型定義による秘密情報の分離: クライアント側画面に渡してよい公開用 RPC URL と、サーバー専用の API キー入り RPC URL を型レベルで完全に分離した。
4. 展望・課題（Next）
- レビューエージェントの観点構造化: 決済領域に特化したレビュー専用エージェントに事前定義の確認観点を渡し、楽観的な評価を排除してセキュリティと回収経路の検証を自動化する方針を継続する。