プレイ回数の「30分以内は数えない」は、どのくらい数字を変えるか

確認済みなのは「30分」と「起動回数」だけ

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

言えること（現在の案内で示されている範囲）は次のとおりです。

• プレイ回数は、作品を起動した実測回数です。
• 同じ端末・同じ作品で、30分以内に再び起動した分は重複として除かれます。
• 数えているのは起動であり、遊んだ人の数ではありません。

言えないこと、つまり作品を開いたり現在の案内で確認したりしないと分からないことは次のとおりです。

• 30分を、どの時点から数えるのか。
• ちょうど30分での再起動は、重複になるのか。
• 表示される数字が、どのくらいの遅れで更新されるのか。
• ログインの有無で、重複の判定が変わるのか。

この記事で扱うのは、2つ目の起点の問題です。ここが決まらないと、同じ起動記録から出る数字が大きく変わります。

同じ6回の起動が、数え方で3回にも1回にもなる

起点の取り方として、次の2つを想定します。これは仕様の推測ではなく、比較のために置いた2つのモデルです。

• 固定窓モデル：計上された起動から30分のあいだの再起動を、重複として除きます。30分が過ぎてからの次の起動は、新しく計上します。
• 連続モデル：直前の起動（除かれた起動も含む）から30分以内なら、重複として除きます。

起動時刻が 0分、10分、25分、40分、55分、75分の6回だったと仮定します。「ちょうど30分」の扱いが結果に混ざらないよう、30分きっかりの間隔は避けた例です。

• 0分、前回の計上から：なし、直前の起動から：なし、固定窓モデル：計上、連続モデル：計上
• 10分、前回の計上から：10分、直前の起動から：10分、固定窓モデル：除外、連続モデル：除外
• 25分、前回の計上から：25分、直前の起動から：15分、固定窓モデル：除外、連続モデル：除外
• 40分、前回の計上から：40分、直前の起動から：15分、固定窓モデル：計上、連続モデル：除外
• 55分、前回の計上から：15分、直前の起動から：15分、固定窓モデル：除外、連続モデル：除外
• 75分、前回の計上から：35分、直前の起動から：20分、固定窓モデル：計上、連続モデル：除外

固定窓モデルでは3回、連続モデルでは1回です。起動6回に対して、前者は半分、後者は6分の1になります。

連続モデルでは、遊び続けている限り、途中で何度やり直しても1回のままです。30分以上空いて初めて、次の1回が計上されます。固定窓モデルでは、遊び続けても30分ごとに1回ずつ増えます。

どちらが実際の仕組みに近いかは、この表からは決まりません。次の節の手順で、実際の挙動に近いほうを絞り込みます。

自分の起動を記録して、仮説を絞る

読者が自分の端末で行える、小さな記録の手順です。

準備するもの

• 同じ端末、同じブラウザ。途中で変えません。
• ログイン状態も固定します。ログインしたまま、またはゲストのまま通します。
• 時刻を書き留める手段（紙でもメモアプリでも構いません）。
• 対象の作品を1本。自分で投稿した作品のほうが、他の人の起動が混ざる量を見積もりやすくなります。

記録する項目

1行を1回の起動として、次の項目を残します。

• 起動した時刻（分単位）
• 起動前に作品ページで見たプレイ回数
• 起動後、少し時間を置いてからのプレイ回数

数字が更新されるまでに遅れがあるかもしれません。起動直後に見て変わっていなくても、すぐには結論を出さず、時間を置いて再確認します。

3つの条件

条件ごとに、できれば3セット繰り返します。

条件A：短い間隔で連続起動　5分おきに3回起動します。30分以内に収まるので、除外が働くなら増分は起動回数より小さくなるはずです。

条件B：十分に間隔を空ける　35分以上空けて、2回起動します。除外の範囲外なので、2回とも計上されるかを見ます。

条件C：起点の識別　0分、20分、40分の3回起動します。この条件が核になります。

• 固定窓モデルなら、0分と40分が計上され、増分は2です。
• 連続モデルなら、0分だけが計上され、増分は1です。

20分と40分の間隔は20分で、30分以内です。連続モデルでは40分の起動が除外されます。一方で、0分からは40分離れているため、固定窓モデルでは計上されます。

他の人の起動が混ざる問題

作品ページの数字は、自分以外の人の起動も含みます。1回の増分だけで判断すると、他の人の起動を自分の分と取り違えます。

• 繰り返して、同じ傾向が出るかを見ます。
• 公開直後や、遊ばれることの少ない時期の作品を選びます。
• 増分が想定より大きい回は、他の人の起動が混ざった可能性として、その回を結論から外します。

条件Cで増分が1でも2でもなく、3以上になった場合は、モデルの違いではなく、他の人の起動か、別の仕組みを疑います。

最小のコードで二つの数え方を比べる

手計算が面倒な場合は、起動時刻の配列を入れて比べるコードが使えます。ブラウザの開発者ツールのコンソールか、Node.jsに貼って実行します。外部ライブラリは使いません。

// times: 起動時刻（分）を昇順に並べた配列
function countFixed(times, w = 30) {
  let last = -Infinity, n = 0;
  for (const t of times) {
    if (t - last >= w) { n++; last = t; } // 計上した起動だけを起点にする
  }
  return n;
}

function countSliding(times, w = 30) {
  let prev = -Infinity, n = 0;
  for (const t of times) {
    if (t - prev >= w) n++;
    prev = t; // 除外した起動も起点に含める
  }
  return n;
}

const times = [0, 10, 25, 40, 55, 75];
console.log(countFixed(times), countSliding(times)); // 3 1

比較に使い方があります。自分の記録の時刻を times に置き換えて、2つの関数の出力を、作品ページで見た増分と見比べます。

• 実際の増分が固定窓の出力に近ければ、固定窓モデルに近いと見ます。
• 連続モデルの出力に近ければ、連続モデルに近いと見ます。
• どちらにも合わなければ、30分の境界の扱い（>= と > の違い）や、他の人の起動の混入を確かめます。

境界は t - last >= w の部分です。「ちょうど30分」を重複にするかどうかは確認済みではないため、>= を > に変えた版も試します。ちょうど30分の起動を含む記録で、出力が変わるかを見ます。

結果の読み方と、起こりやすい誤り

差の大きさをどう見るか

起動回数に対して、計上される回数の割合を、次の式で出してみます。

計上率 = 計上される回数 ÷ 実際の起動回数

どのモデルを使っても、計上率が1に近いのは、起動と起動の間隔が長い作品です。計上率が小さくなりやすいのは、短い時間に何度も起動し直される使われ方の作品です。

モデルによる差が大きく開くのも、連続して起動し直される場面です。冒頭の6回の例では、固定窓で3、連続で1でした。1人が長く遊び続けるほど、2つのモデルの差は広がります。

起こりやすい誤り

• 人数だと読む：プレイ回数は起動の回数です。同じ人が時間を空けて戻ってくれば増えます。逆に、複数人が同じ端末を使えば、30分以内の分は重複として除かれる場合があります。
• 1回の増分で結論を出す：他の人の起動が混ざります。条件ごとに複数回、繰り返します。
• 途中で端末やログイン状態を変える：重複の判定が「同じ端末」を前提にしているため、変数を増やすと原因が切り分けられなくなります。
• 表示の遅れを見落とす：起動直後に変わっていないからといって、除外されたとは限りません。
• 境界の近くだけを見る：29分や31分の起動は、境界の扱いと窓の起点の両方が影響します。まず条件A・B・Cで大きな違いを見てから、境界へ進みます。

ランキングとの関係

ランキングには、プレイ回数・いいね数・レビュー平均の切り替えがあり、上位50作品が対象です。プレイ回数順は、この重複除外を通した数字で並びます。順位の差を読むときは、「何人が遊んだか」ではなく、重複を除いた起動回数の差を見ている、と考えるのが安全です。

作品の作り手にとっては、やり直しが多い作品ほど起動が重なりやすいため、プレイ回数の増え方の読み方が変わります。数字が伸びなかったとき、遊ばれなかったのか、短い間隔の起動が除かれたのかは、この数字だけでは区別できません。

次の行動

作品を1本選び、条件A・B・Cを順に記録してください。条件Cは、20分間隔で3回起動し、増分が1か2かを見る形です。記録できたら上のコードに時刻を入れ、どちらのモデルに近いかを比べます。起点や境界の扱いなど、記録でも決まらなかった点は、現在の案内で確認してください。