ポイント監査ログ — 不正・障害に備える履歴設計

はじめに

ポイント制度は、顧客をつなぎとめる強力な仕組みです。ただ、設計側に立つと「これは実質お金だな」と背筋が伸びる領域でもあります。

私が担当したのは、POS（スマレジ）と自社ECをまたいでポイントを運用するプロジェクトでした。店頭で貯めたポイントをECで使い、ECで貯めたポイントを店頭で使う。便利な反面、「いま何ポイント持っているのか」という状態が2つのシステムに分かれて存在します。

この記事では、そんなポイント運用を安全に回すための土台として設計した監査ログの考え方を、非エンジニアの方にも伝わるように解説します。

なぜポイント運用に監査ログが要るのか

ポイントは実質「お金」だから

ポイントは1ポイント=1円のように金銭的価値を持ちます。つまり、システムがポイントを1つ増やすことは、帳簿上でお金を発行しているのとほぼ同じです。

現金なら金庫やレジで物理的に管理されますが、ポイントは数字でしかありません。だからこそ「誰が・いつ・なぜ増やした（減らした）のか」を後から追える形で残しておかないと、間違いにも不正にも気づけないんです。この「追える状態」を作るのが監査ログの役割です。

「なかったこと」にできない記録が必要

普通のデータベースは、最新の残高だけを上書きで持っていることが多いです。残高が「1000」から「500」に変わったとき、その差分の理由はどこにも残りません。

そこで、残高を直接いじるのではなく、すべての増減を「イベント」として1行ずつ積み上げる設計にしました。残高はイベントの合計として導き出す。この考え方はイベントソーシングと呼ばれます。

POSとECをまたぐと状態が分裂する

一番やっかいなのが、ポイントの「正しい値」が1か所にないことです。店頭のPOSにも残高があり、ECにも残高がある。通信が一瞬切れただけで、両者の数字はすぐズレます。

両システムが直接会話するのではなく、すべての操作をいったんログに落とす。こうしておけば、ズレが起きても「正しい履歴」に立ち返って再計算できます。

監査ログに何を記録するか

1イベント=「いつ・誰が・何を・何ポイント」

監査ログの1行は、ポイントが動いた1つの出来事です。ここで大事なのは、後から見て意味が分かる情報を漏れなく残すこと。特に「変換後の残高」を一緒に記録しておくと、後の突合が驚くほど楽になります。

付与ソースを制御して二重付与を防ぐ

ポイントのトラブルで多いのが「二重付与」です。同じ購入に対して、なぜかポイントが2回付いてしまう。原因はたいてい、システム間の再送やボタンの二度押しです。

「同じ操作は何度実行しても結果が1回分」という性質を冪等性（べきとうせい）と呼びます。監査ログにこの仕組みを組み込むことで、再送が起きても残高が狂わなくなります。

消費と変換も同じ粒度で残す

付与だけでなく、ポイントを使ったとき（消費）、クーポンに引き換えたとき（変換）も、まったく同じ粒度で記録します。ポイントが「消えた」場合こそ、顧客からの問い合わせが増える場面だからです。

「先週のポイントが減っている」と言われたとき、ログに変換イベントが1行あれば、「◯月◯日にクーポンへ引き換えられています」と即答できます。記録の粒度をそろえておくことが、そのままカスタマーサポートの武器になるんです。

監査ログが効いてくる3つの場面

不正やミスの検知

付与ソースを記録していると、「手動付与が特定の担当者に偏っている」「深夜に大量付与が走っている」といった異常が見えるようになります。金庫の出入りを監視カメラで記録するのと同じ発想です。

すべてを止めて監視するのは現実的ではありませんが、後から追える記録さえ残っていれば、疑わしい動きを事後にでも洗い出せます。抑止力としても効いてきますよね。

障害時の突合と復旧

POSとECの残高がズレたとき、監査ログがあれば「どちらが正しいか」ではなく「ログを合計するといくつか」で答えを出せます。人間が勘で調整するのではなく、履歴という事実から正しい状態を再構築できるわけです。

この突合と復旧の具体的な手順は、サブ記事「障害時の突合・復旧に使えるログの持ち方」で詳しく扱います。

保持期限と個人情報への配慮

監査ログは顧客IDや操作履歴を含むため、個人情報そのものです。「監査のために全部・永久に残す」は、プライバシーの観点では望ましくありません。必要な期間だけ安全に持ち、期限が来たら適切に削除・匿名化する設計が求められます。

まとめ

ポイントは実質お金です。だからこそ、「今の残高」だけを持つのではなく、すべての増減をイベントとして積み上げる監査ログが、不正にも障害にも効く土台になります。

このハブ記事では全体像を扱いました。それぞれの詳細は、次の3本で深掘りしています。

• 付与・消費・変換のイベント記録設計 — 1イベントに何を持たせるか、スキーマの具体を解説します。
• 障害時の突合・復旧に使えるログの持ち方 — 残高がズレたとき、ログから正しい状態を再構築する方法を扱います。
• ログの保持期限と個人情報への配慮 — いつまで持つか、どう安全に消すかを設計します。