こんにちは。現在、私はあるイベント出席用の打刻アプリのサーバサイド開発・保守を担当しています。この記事では、近年増えてきた「代返行為（＝出席の不正代行）」を防ぐために行った対策について、背景から実装、そして結果までを紹介します。

背景：なぜ代返が問題なのか？

この打刻アプリは、イベントの出席確認を目的に使用されています。仕組みとしては、

イベント会場に設置されたビーコンの信号をスマホ端末が受信
スマホが「位置情報」と「打刻時刻」をサーバに送信
サーバが打刻情報を記録

といった流れです。

ところが最近、代返（＝別人が他人のアカウントで打刻する行為）が増加してきました。主な手口は次のようなものです：

イベントに出席している学生が、出席していない知人のアカウントに切り替えて、代理で打刻する。

対策方針：「1端末1アカウント」の制限

代返を防ぐには、「1台の端末に1アカウントしかログインできない」ようにすれば良いと考えました。この方針に基づいて、次の2案を検討・実装しました。

案1：サーバ側で端末識別子を検証（主にAndroid向け）

方法

端末から送られてくるリクエストに「端末識別子（identifier）」を追加してもらう。
サーバは、その識別子とユーザーIDのペアをRedisに保存。
打刻時に、同じ識別子で過去に記録されたユーザーIDと異なる場合、切り替えが発生したと判断。

技術的な補足

AndroidではWidevine IDという端末固有の識別子を利用できます。
Redisに有効期限（TTL）を1週間設定することで、「中古スマホを譲渡した場合」などにも対応可能です。
Widevine IDはセンシティブな情報なので、ヘッダーで送信したほうが無難です。

案2：クライアント（iOS）側で切り替え検知

方法

初回ログイン時に、ユーザーIDと日時を端末内に保存（localStorageなど）。
打刻時には保存されたユーザーIDと照合し、異なる場合は打刻を送信しない。

技術的な補足

iOSは、アプリをアンインストールしても削除されない領域（Keychainなど）を使うことで、情報を持続的に保持できます。
Androidはユーザー側で比較的簡単にlocalStorageのデータを削除できてしまうため、この方法は不向きです。

実装概要

条件

以下のユースケースも想定して、対策を設計しました：

複数端末でログインしたい人：端末識別子ごとにユーザーIDを記録すればOK
スマホを譲渡された人：1週間以上ログインや打刻操作がなければ、切り替えを許可

サーバ側のコード（TypeScript + Redis）

1. 打刻時に識別子とユーザーIDを紐づける

public async updateAccessInfo(identifier: string | string[] | undefined, userObjectId: string): Promise<void> {
  if (!this.isIdentifierValid(identifier)) return;

  const identifierString = identifier as string;
  const currentUserObjectId = await this.redisService.getUserIdByIdentifier(identifierString);

  if (currentUserObjectId && currentUserObjectId !== userObjectId) {
    console.warn('アカウント切り替え検出:', { identifier, userObjectId, currentUserObjectId });
    return;
  }

  // 一週間（604800秒）の有効期限付きで保存
  await this.redisService.updateIdentifierValue(identifierString, userObjectId);
}

2. ログイン時に切り替えをチェック

public async checkAccessInfo(
  identifier: string | string[] | undefined,
  userObjectId: string,
): Promise<{ result: boolean }> {
  const identifierString = identifier as string;

  try {
    const currentUserObjectId = await this.redisService.getUserObjectIdByIdentifier(identifierString);
    if (!currentUserObjectId) return { result: true }; // 初回や期限切れならOK

    return { result: currentUserObjectId === userObjectId };
  } catch (error) {
    console.error('Redis query failed:', error);
    return { result: true }; // Redisが落ちていても通す（誤検出防止）
  }
}

iOS側の挙動

ローカルに「最初にログインしたユーザーID」と「日付」を保存
打刻時に照合。異なる場合、日付が1週間以上前なら上書き。それ以外は拒否

結果と感想

今のところは、代返の抑止に一定の効果が出ており、安定して動作しています。
ただ、私自身もイベントに参加していて、もう自分の代返はできなくなりました（当たり前ですが…）。

最後に

今回の対策は、「完璧な防止策」ではありません。ですが、代返のハードルを上げることで、不正を大幅に減らすことはできます。

「不正に厳しくしつつ、正規ユーザーにはできる限り不便をかけない」そんなバランスを目指して、今後も改善を続けていきます。