重複プッシュ通知を回避する方法：CID機能徹底解説

プッシュ通知システムにおいて、重複プッシュは一般的な問題であり、特にネットワークが不安定な場合やシステムのリトライ時に顕著です。本記事では Client ID（CID）機能を深掘りし、この仕組みを活用してメッセージの重複配信を効果的に防ぐ方法を解説します。

即時プッシュにおける CID 機能

コア特性

CID はプッシュリクエストを一意に識別するためのオプションパラメータです。同じ CID でリクエストを繰り返すと：

• システムは前回成功したプッシュの msg_id を返します
• ユーザーへのメッセージ重複配信を防止
• 冪等性保証（同じ操作を複数回実行しても結果は同じ）

主要属性

適用シーン

1. ネットワークリトライ：ネットワーク不安定時に同じ CID で再送
2. 冪等性保証：同一メッセージの重複配信防止
3. リクエストトラッキング：CID で特定プッシュの状態追跡

リクエスト例

単一プッシュで CID を付与

              
              curl --insecure -X POST -v https://pushapi-sgp.engagelab.com/v4/push \
  -H "Content-Type: application/json" \
  -u "AppKey:MasterSecret" \
  -d '{
    "options": {
      "cid": "order-notify-20230701-001",
      "time_to_live": 60
    }
  }'

            

バッチプッシュで CID を付与

              
              curl --insecure -X POST -v https://pushapi-sgp.engagelab.com/v4/push/batch/regid \
  -H "Content-Type: application/json" \
  -u "AppKey:MasterSecret" \
  -d '{
    "requests": [
      {
        "options": {
          "cid": "user-12345-notification",
          "time_to_live": 60
        }
      }
    ]
  }'

            

レスポンス処理

初回プッシュ成功時

              
              {
  "msg_id": "2460001"
}

            

同じ CID で重複プッシュ

              
              {
  "msg_id": "2460001" // 初回プッシュの msg_id を返却
}

            

CID フォーマット不正

              
              {
  "error": {
    "code": 23003,
    "message": "CID format does not meet requirements"
  }
}

            

エラーコード説明

ベストプラクティス

1. 重要業務には CID を利用：決済通知や重要アラート等は必ず CID を付与
2. 意味のある識別子を生成：businessType-userID-timestamp（例：payment-12345-202307011030）
3. ネットワークリトライ時も同じ CID を利用
4. バッチプッシュは CID で個別識別：各リクエストに異なる CID を付与し追跡性向上
5. クライアントで CID を記録：メッセージ重複排除や状態確認に活用

スケジュールタスクにおける CID 機能

コア特性

CID はスケジュールタスク作成時にも利用でき、同一タスクの重複作成を防止します：

• 同じ CID で再作成すると、既存の schedule_id を返却
• システムによる重複タスク作成を防ぐ

主要属性

リクエスト例

              
              curl --insecure -X POST -v https://pushapi-sgp.engagelab.com/v4/schedules \
  -H "Content-Type: application/json" \
  -u "AppKey:MasterSecret" \
  -d '{
    "cid": "daily-reminder-202307",
    "trigger": {
      "daily": {
        "start": "2023-07-01",
        "time": "09:00:00"
      }
    }
  }'

            

レスポンス処理

初回作成成功時

              
              {
  "schedule_id": "0123456789"
}

            

同じ CID で重複作成

              
              {
  "schedule_id": "0123456789" // 初回作成の schedule_id を返却
}

            

ベストプラクティス

1. 周期タスク識別：CID に周期情報を付与（例：weekly-report-2023w27）
2. タスクパラメータ要約：CID に主要パラメータのハッシュ値を含める（例：birthday-reminder-md5(params)）
3. 分散システム協調：複数サービス間で同じ CID を利用し重複作成防止
4. タスク更新時は新しい CID を利用

EngageLab の処理フロー

graph TD
    A[リクエスト受信] --> B{CID あり？}
    B -->|Yes| C[Redis を照会]
    B -->|No| D[通常処理]
    C --> E{CID 存在？}
    E -->|Yes| F[保存済みの msg_id/schedule_id を返却]
    E -->|No| G[リクエスト処理]
    G --> H[CID → ID マッピング保存]
    H --> I[新しい ID を返却]

よくある質問

Q: CID の有効期間が 1 時間なのはなぜ？
A: 通常のリトライシナリオをカバーしつつ、無制限なストレージ増加を防ぐためです。重要業務の場合は独自ログで重複排除期間を延長可能です。

Q: 異なる appkey で同じ CID は使える？
A: 可能です。CID は同一 appkey 内でのみ一意であれば十分です。

Q: CID はグローバルに一意である必要がある？
A: 必要ありません。同一 appkey 内で一意であれば問題ありません。

Q: CID のフォーマット検証方法は？
A: 正規表現：/^[a-zA-Z0-9_-]{1,64}$/ を利用してください。

まとめ

CID パラメータを正しく利用することで、以下が実現できます：

1. ✅ ネットワークリトライによるメッセージ重複配信の防止
2. ✅ 重要業務メッセージの冪等性保証
3. ✅ 分散システムでのメッセージ追跡簡素化
4. ✅ システム全体の信頼性向上

実装上の重要ポイント：

• 重要業務メッセージには必ず CID を付与
• business-entity-time 命名規則を推奨
• クライアントで CID ベースの重複排除ロジックを実装
• CID 関連エラーコードに注意

本ガイドを活用し、CID 機能を最大限に活かすことで、より堅牢なプッシュ通知システムを構築し、重複プッシュ問題を根本から解決しましょう。