リアクションタイム

どんなゲームか

画面が赤い間は待って、緑に変わったらできるだけ早くタップする。それだけです。結果は**ミリ秒（1000分の1秒）**で表示されます。

このサイトでいちばん短く、いちばん単純なゲームです。1回10秒もかかりません。それでも何度もやってしまうのは、自分の数字が出るからだと思っています。スコアではなく、自分の身体の性能がそのまま出る。だから「もう1回」が止まらなくなります。

遊び方

1. 画面をクリック（タップ）してスタート
2. 背景が赤の間はじっと待ちます
3. 背景が緑に変わった瞬間にタップ
4. 反応時間がミリ秒で表示されます
5. もう一度タップすると次の回が始まります

赤い間に押してしまうと「早すぎ！」と表示され、計測はやり直しになります。

評価の基準

反応時間	評価
150ms未満	超人的！
150〜199ms	すごい！
200〜249ms	いい感じ！
250〜299ms	まあまあ
300〜399ms	もう少し！
400ms〜	がんばろう！

200ms を切ると数字が緑色になります。ここがひとつの目標ラインです。

数字の読み方

200〜250msが普通です

視覚に反応してボタンを押すまでの時間は、一般に200〜250ミリ秒あたりと言われています。「まあまあ」と表示されても、それは平均的だということです。落ち込む必要はありません。

内訳はおおよそこうなっています。網膜が光を捉えて信号に変えるまでに数十ミリ秒、それが脳に届いて「緑だ」と判断するまでにさらに数十ミリ秒、そこから指を動かす命令が届いて実際に指が動くまでに数十ミリ秒。どれだけ集中しても、この積み重ねはゼロにはなりません。

100msを切ったら、それは反応ではありません

もし100ミリ秒を大きく下回る数字が出たら、それは緑を見て反応したのではなく、タイミングを予測して押した結果です。神経の伝達速度の都合上、本当に見てから反応して100msを切ることはまず起こりません。

表示の遅れも含まれています

正直に書いておくと、ここで測っているのは純粋な人間の反応時間ではありません。画面が実際に緑を映すまでのわずかな遅れ、タップを端末が認識するまでの遅れ、それらがすべて数字に含まれています。

一般的な60Hzの画面では、色が変わる指示を出してから実際に光るまでに最大で16.7ミリ秒（1フレーム分）のずれが生じます。つまりあなたの数字には、機械側の遅れが十数ミリ秒ほど乗っています。

なので別の端末で測った数字と比べても、あまり意味はありません。同じ端末で自分の調子を測るのがいちばん正確です。

攻略のコツ

待ち時間は必ず1〜4秒です

緑に変わるまでの待ち時間は、1秒から4秒の間でランダムに決まります。これは実装で決めている値です。

ここから言えることがあります。赤くなってから4秒が経てば、緑はもう出ているはずです。逆に、赤くなった直後に来ることはありません（最低1秒は待ちます）。

なので、赤くなった瞬間に身構えるのは早すぎます。1秒経ったあたりから集中を始めるのが効率的です。そして時間が経つほど「そろそろ来る」確率は上がります。3秒待った時点では、残りは1秒しかありません。

画面の中心を見ないほうがいい

文字を読もうとすると、そのぶん判断が遅れます。背景全体が赤から緑に変わるので、画面のどこか一点を見つめるより、視野全体をぼんやり眺めるほうが速く気づけます。文字は読まなくていいのです。

指は画面につけておく

タップの動作そのものにも時間がかかります。指を画面から離して構えていると、そのぶん往復の時間が乗ります。指を画面ぎりぎりに置いておくか、PCならボタンに指を乗せた状態で待つと、20〜30ミリ秒は変わります。

フライングは損しかない

赤い間に押すと計測がやり直しになります。「早めに押せば速い数字が出るのでは」と思うかもしれませんが、待機中のタップはすべてフライングとして弾かれます。予測して押しても得はしません。

開発ノート

なぜ performance.now() を使うのか

時間の計測には Date.now() ではなく performance.now() を使っています。

Date.now() はシステムの時計を読むので、ミリ秒より細かい精度がありません。それに加えて、時刻同期などでシステム時計が調整されると時間が巻き戻ることすらあります。数十ミリ秒を測るゲームでこれは致命的です。

performance.now() は起動時点からの経過時間を返す単調増加のタイマーで、小数点以下の精度があり、途中で巻き戻りません。反応速度のように短い時間を測る場面では、こちらを使うのが正解です。

待ち時間を1〜4秒にした理由

最初は0.5〜2秒で試していました。短いとテンポは良いのですが、待ち時間の幅が狭いと予測できてしまいます。2〜3回やれば「だいたいこのくらい」という感覚が身についてしまい、反応ではなく予測のゲームになりました。

かといって長すぎると、待っている時間が退屈です。10秒待つゲームは暇つぶしになりません。

1〜4秒は、予測しきれない程度にはばらつきがあり、待っていて飽きない程度には短いという範囲でした。最短の1秒は「赤を認識する時間」を確保するために必要で、これより短いと赤を見る前に緑になってしまいます。

フライング判定をどう実装したか

このゲームで唯一やっかいなのが「早すぎ」の判定です。素朴に作ると、緑になった瞬間のタップと、その直前のタップを区別できません。

解決策として、ゲームの状態を ready（開始前）・waiting（赤・待機中）・go（緑・計測中）・result（結果表示）・too-early（フライング）という5つの状態に分けて管理しています。タップが来たときは「今どの状態か」だけを見て処理を決めます。

• waiting 中のタップ → フライング。緑にする予定のタイマーを取り消す
• go 中のタップ → 計測して結果表示
• それ以外 → 次の回を開始

こうすると時刻の比較が一切要らなくなり、判定の取りこぼしがなくなりました。状態を分けたことで、条件分岐がひとつも入れ子にならずに済んでいます。

スコアを保存していない理由

このゲームだけ、ベストスコアの保存機能をあえて入れていません。

反応時間は体調や環境でかなりぶれます。眠いときは50ミリ秒くらい平気で遅くなりますし、たまたま予測が当たって速い数字が出ることもあります。「その日いちばん良かった1回」を残してしまうと、次からずっとそれを超えられません。

このゲームは記録を競うものではなく、今の自分の状態を測る体温計のようなものだと考えているので、毎回まっさらな状態で測れるようにしています。

更新履歴

• 2026-07-26 ─ 数字の読み方と計測の仕組みの解説を追加
• 2026-03-15 ─ 公開