環境を3つ分ける

シークレット・データベース・URLすべて分離します。

監視（最低限）

• API呼び出しの成功率：99%以下で警告
• レート制限ヒット率：1%以上で警告
• Webhook受信成功率：99%以下で警告
• トークン更新失敗：即時通知
• 署名検証失敗：継続的に発生したら警告
• 処理キューの滞留：閾値を超えたら警告

デプロイ

• CIで自動テスト：型チェック、ユニット、API契約テスト
• カナリア：新バージョンを一部トラフィックに先行投入
• ロールバック計画：1コマンドで前バージョンに戻せる
• マイグレーション戦略：DBスキーマ変更は2段階（追加→削除）でリリース
• 機能フラグ：新機能はOFFでデプロイ、本番でONに切り替え

レシートローラー側のバージョン追従

• 「お知らせ」を購読しておく
• Sunset / Deprecation ヘッダーをログに出して通知
• 非推奨API使用を月次レビューで棚卸し
• 新APIバージョンが出たら、ステージングで先行検証

障害対応の基本構造

1. 検知：監視アラートが鳴る
2. 初動：オンコール担当が15分以内に着手
3. 影響範囲特定：誰の何が止まっているか
4. 暫定対応：ロールバック・機能停止・手動対応
5. 連絡：影響を受ける店舗・ユーザーへ通知
6. 恒久対応：根本原因を直す
7. 振り返り：ポストモーテム（責任追及ではなく改善）

ドキュメントを保つ

• Runbook：よくある障害の対応手順
• アーキテクチャ図：レシートローラーとの接続点
• 連絡先：レシートローラーサポート窓口、内部チームの連絡先
• 環境変数一覧：何の値か・どこから取るか
• 復旧手順：DB復元、デプロイロールバック、シークレット再生成

テストアカウント・テストデータ

• 本番アクセスを伴うE2Eテストには、専用のテスト店舗・テストユーザーを使う
• テスト用クレジットカード番号・テスト用メアドを定数化
• 本番データを使ったテストは原則禁止（個人情報の取り扱いリスク）

関連ガイド

• データ保護の考え方
• アクセス制御と監査ログ
• SLA・稼働率と障害時の確認手順
• 開発者ヘルプトップへ戻る