プレイ回数の裏側を考える：ハッシュで数える仕組みと「残さない」判断の読み方

確認できていることと、できていないこと

まず、言えることと言えないことを分けておきます。

• プレイ回数は作品起動の実測回数、状況：確認済み
• 同じ端末・同じ作品の30分以内の再起動は重複を除く、状況：確認済み
• プレイ回数は人数ではない、状況：確認済み
• ランキングでプレイ回数・いいね数・レビュー平均を切り替えられる、状況：確認済み
• 重複判定にハッシュを使っているか、状況：確認済みの範囲にない
• IPアドレスや端末IDを保存しているか、していないか、状況：確認済みの範囲にない
• 保存期間、状況：確認済みの範囲にない

下の3行は「していない」と書けるわけではなく、「この記事では分からない」という意味です。分からない点は、後半で確かめ方を示します。

「30分以内の重複を除く」には何が必要か

重複を除くには、少なくとも二つの材料が要ります。一つは「さっきと同じ端末らしい」と判定する手がかり、もう一つは「最後に数えた時刻」です。

手がかりの持ち方には、一般にいくつかの方法があります。

• 生の値を保存する方法：IPアドレスや端末の識別子をそのまま記録します。判定は単純ですが、記録を見れば個々の端末の動きを追えてしまいます。
• ブラウザ側に印を持たせる方法：端末に小さな印を置き、起動時に確認します。サーバーに生の値を残さずに済む場合がありますが、印が消されると別の端末として数えられます。
• ハッシュにした値を保存する方法：手がかりを変換した値だけを残します。次の節で説明します。

どれを採るかで、数の正確さと、残る情報の重さが変わります。プレイ回数は「人数ではない」と明示されている指標です。完全に正確な人数を求めていない以上、数え方も粗くてよい、という見方は成り立ちます。ただし、これは考え方の整理であり、実際の実装を示すものではありません。

ハッシュで数える仕組み

ハッシュとは、入力された文字列から決まった長さの別の文字列を作る変換です。次の性質があります。

1. 同じ入力からは、いつも同じ出力ができます。
2. 出力から元の入力を直接計算で戻すことは、実用上できません。
3. 入力が少し違うだけで、出力は大きく変わります。

1番目の性質があるので、「前に見た値と同じか」は、元の値を知らなくても比べられます。たとえば「手がかり＋作品ID」をハッシュにして、出力と最後に数えた時刻だけを持つ設計が考えられます。同じ出力が30分以内に来たら数えず、30分を過ぎていたら数える、という判定です。作品ごとに別の値になる点も、「同じ端末・同じ作品」という条件と相性がよい形です。

ハッシュ化は匿名化とは限らない

注意したいのは、ハッシュにすれば安全とは限らないことです。IPv4アドレスは約43億通りしかありません。攻撃者が全部をハッシュにして照合表を作れば、出力から元のアドレスを割り出せてしまいます。これは一般に知られた弱点です。

そのため、実務では次のような工夫が語られます。

• 入力に秘密の値（ソルト）を混ぜ、外部から照合表を作れないようにする。
• そのソルトを一定期間ごとに入れ替えて捨て、過去の値と今の値を結びつけられなくする。
• 30分の判定にしか使わないなら、窓が過ぎた値は削除する。

つまり「ハッシュを使っている」という事実だけでは、残さない設計かどうかは決まりません。何を混ぜ、どれだけの期間持ち、いつ消すかまで見て、はじめて判断できます。

「残さない」判断とは何を捨てることか

データを残さない判断は、技術というより目的の絞り込みです。プレイ回数の目的は「作品がどれだけ起動されたか」を示すことです。この目的に、誰が、どこから、いつ何度遊んだかを個別に追える情報は要りません。目的に必要な分だけを持つ考え方は、データ最小化と呼ばれます。

確認済みの事項から、設計として読み取れる点が三つあります。

• 回数と人数を分けている：プレイ回数は人数ではない、と明示されています。個人を数える指標ではないので、個人を特定する情報を土台にしなくてもよい、という整理と矛盾しません。
• 重複除外の窓が短い：30分という区切りは、水増しを抑える最小限の記憶で済ませる形と整合します。ただし、実際に窓を過ぎた値を消しているかは確認済みの範囲にありません。
• 記録の機能が分かれている：ログイン中のプレイ履歴、あとで遊ぶ、クラウドセーブは、ユーザー自身の機能として案内されています。ゲストの履歴や進行は端末内に保存され、ログイン後のアカウントへ自動では混ざりません。プレイ回数の集計とは目的が違う機能として並んでいます。

もう一つ、ゲーム側への情報の渡し方にも似た発想が見えます。アップロード作品にはSDKが自動で追加され、作品専用のプレイヤーIDとクラウドセーブ（作品ごとにJSONで128KiBまで）が使えます。一方で、ゲームにはFirebaseのUID・認証トークン・メールアドレスを渡さないと定められています。作品ごとに別のIDを使い、アカウントの中身は渡さない形です。作品をまたいで同じ人を追いかけにくくする設計と読めますが、これも「設計から読み取れること」にとどまります。

自分で確かめる手順

保存の有無は外から断定できません。確かめられるのは次の二つの層です。

層1：書かれていることを読む

アソバースの現在の案内（プライバシーや利用規約に関する項目）を開き、次の語を探してください。

1. 起動記録・アクセス記録に当たる項目はあるか。
2. 取得する情報の種類（IPアドレス、端末の識別子、ブラウザ情報など）が列挙されているか。
3. 利用目的に、回数の集計や不正対策が含まれているか。
4. 保存期間や削除のタイミングが書かれているか。
5. 書かれていない点の問い合わせ先があるか。

見つからない項目は「記載なし」と記録し、「保存していない」とは読み替えないでください。書かれていないことと、していないことは別です。

層2：30分ルールを観察する

重複除外の挙動は、次の設計で確かめられます。

1. 準備：ログインの有無を固定します。同じブラウザ、同じ端末、同じ作品を使います。
2. 起動直前に、プレイ回数の表示値を記録します。
3. 作品を起動し、すぐ閉じます。表示値を記録します。
4. 30分以内に、もう一度同じ作品を起動します。表示値を記録します。
5. 30分以上空けてから起動し、表示値を記録します。

表示値は毎回同じ場所で、時刻とあわせてメモしてください。

結果の読み方は次のとおりです。

• 4番で増えず、5番で増えた場合：30分の窓が働いている可能性が高いです。
• 4番でも増えた場合：自分の記録の取り方を疑ってください。表示が更新されるまでに遅れがないか、別の人の起動が混ざっていないかを先に確かめます。

誤りやすい点は次のとおりです。

• 他の利用者の起動も同じ数字に入るため、人気の作品ほど変化が読みにくくなります。
• 別のブラウザやプライベートウィンドウは、別の端末として扱われる場合があります。条件を変えると比較になりません。
• 窓の起点が「最初の起動」か「直近の起動」かは、確認済みの範囲にありません。4番と5番の間隔を変えた追加の観察でないと、区別できません。
• 数を増やすために何度も起動を繰り返すことは、他の作者の作品の指標をゆがめるので避けてください。

観察で分かるのは挙動だけで、サーバーに何が残るかは分かりません。その部分は層1の案内と問い合わせで確認します。

作り手として、何を残すか決める

自作のゲームやツールで利用状況を数えるときにも、同じ問いが立ちます。次の三点を、集計を作る前に書き出しておくと迷いません。

• 何を知りたいか：起動回数なのか、人数なのか、継続して遊ぶ人の割合なのか。
• そのために必要な最小の値は何か：回数だけなら、個人につながる値は要らない場合があります。
• いつ消すか：判定にしか使わない値は、判定の窓が過ぎたら消す設計にできます。

アソバースへ投稿する作品なら、プレイヤー個人の進行を残したい場合はSDKのクラウドセーブを使い、集計は回数に絞る、という分け方が考えられます。なお、アップロード作品内のlocalStorageやsessionStorageは一時メモリーの互換処理であり、永続的な保存先とは考えないでください。

次の行動

アソバースの現在の案内を開き、取得する情報・利用目的・保存期間の三つを書き出してください。続けて、同じ作品で30分ルールの観察を一巡だけ行い、表示値と時刻を記録します。案内に書かれていない点は、問い合わせて確かめてください。

参考資料

• アソバースの現在の案内（プライバシー、利用規約に関する項目）