灯りのチェスの思考時間は、なぜ約450msに制限されているのか

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

灯りのチェスについて、確認済みの事項から今回の話に関係するものを取り出します。

• 相手の強さ、確認できていること：3段階の相手がいる、確認できていないこと：段階ごとの違いが何で作られているか
• 思考時間、確認できていること：CPUの思考時間は約450msに制限されている、確認できていないこと：450msに決めた経緯、段階ごとに上限が違うか
• 学習の支え、確認できていること：駒の動き方ガイド、ヒント、一手戻すがある、確認できていないこと：ヒントの手がCPUの思考と同じ仕組みか
• 対局の形、確認できていること：ひとり対局、同じ画面でのふたり対局、招待リンクのオンライン対局、確認できていないこと：なし
• ルール、確認できていること：キャスリング、アンパッサン、選択式の昇格、標準の終局判定に対応、確認できていないこと：なし
• 判定、確認できていること：判定エンジンとしてchess.jsを同梱している、確認できていないこと：思考時間の制限とchess.jsの関係

右の列は「作品を開いて確かめる」か「現在の案内で確認する」ものです。以降の考察は、左の列だけを土台にします。

約450msという数字から読み取れること

「制限」という言葉は上限を意味します。CPUが考える時間を、ある長さ以内に収める設計だと言えます。ここで注意したいのは、「必ず450msかけて指す」とは書かれていない点です。上限なので、それより早く指す手があるかどうかは、作品を開いて確かめることになります。

次に、1秒の半分という長さの性格です。一般に、チェスのエンジンは考える時間が長いほど多くの先の局面を調べられるので、時間の制限は強さの制限にもなります。一方で、ブラウザで動くJavaScriptは、重い計算をしている間、画面の操作が止まって見えることがあります。持ち時間を短く区切っておけば、計算が長引いて画面が固まる心配を小さくできます。ただしこれは一般的な技術の話で、この作品がそれを狙ったかどうかは確認できません。

確認できる事実と照らし合わせると、次のような読み取りはできます。

• 灯りのチェスは、ヒント、一手戻す、駒の動き方ガイドなど、人間側が考えて学ぶための道具をそろえています。考える時間を人間側に残す設計と、CPU側の思考を短く区切る設計は、方向が合っています。
• 作品は独立したHTMLで、外部通信なしに動くと確認されています。CPUの手は端末の中で計算されるはずなので、端末の速さに左右されにくい上限を置く意味は想像できます。ただし、これも読み取りであり、断定はしません。
• 一方、オンライン対局の相手は人間です。待ち時間は相手次第になり、CPU戦の約450msとはリズムが違います。この対比が、CPU戦の「待たせなさ」を際立たせます。

時間を絞ると、強さはどこで決まるのか

ここが記事の中心です。待たせない対局と強さの釣り合いを考えてみます。

CPUの思考時間を一定の短さに固定すると、「長く考えさせて強くする」という調整はできなくなります。それでも3段階の相手が用意されているので、段階の差は、時間以外のどこかで作られていると考えられます。たとえば手の選び方の深さや、読みの精度、あえて最善を選ばない幅などが、一般には思い浮かびます。ただし、この作品でどれが使われているかは確認できていません。作品を開き、3段階を実際に指して確かめる部分です。

釣り合いという観点では、次の点が見どころです。

1. 速いのに弱いとは限りません。 待ち時間が短いことと、相手が弱いことは別の話です。短い時間でも、手の質は設計次第で変わります。
2. 段階の差は、待ち時間では感じられない可能性があります。 3段階で待ち時間がほぼ同じなら、違いは「指された手」にだけ現れます。段階の差を体感するには、勝敗だけでなく、手の内容を見る必要があります。
3. 人間側の支えとセットで考えます。 ヒントや一手戻す、取った駒と全棋譜の表示があるので、負けた局面を振り返って学べます。相手が速く指しても、自分が考える時間は無制限です。

つまり、約450msという数字は、相手を強くも弱くもする数字というより、「対局のテンポを決める数字」として読むのが自然です。強さの調整は別の場所で行われているはずで、その場所を探すのが、次の実験の目的になります。

自分で確かめる設計書

答えは自分の端末で出せます。2つの問いを立てます。

問い1：相手の手が返るまでの見かけの待ち時間は、約450msに近いか

準備するもの

• 灯りのチェスを開いた端末
• 画面を撮影できるもう1台のスマートフォンなど（動画撮影用）
• 撮影のフレームレートが分かること（60fpsなど）

手順

1. ひとり対局を始め、段階を決めます。まず最も易しい段階がよいでしょう。
2. 自分が駒を置く瞬間から、相手の駒が動き出す瞬間までを、画面全体が映るように動画で撮ります。
3. 動画をコマ送りにして、「自分の駒が置かれたコマ」と「相手の駒が動き始めたコマ」を数えます。
4. コマ数をフレームレートで割り、ミリ秒に直します。計算には次の小さなページが使えます。

<!doctype html>
<meta charset="utf-8">
<p>撮影のfpsと、数えたコマ数を入れます。</p>
<input id="fps" type="number" value="60"> fps
<input id="frames" type="number" value="27"> コマ
<button id="go">計算</button>
<p id="out"></p>
<script>
document.getElementById("go").onclick = () => {
  const fps = Number(document.getElementById("fps").value);
  const n = Number(document.getElementById("frames").value);
  document.getElementById("out").textContent =
    fps > 0 ? `約${Math.round(n / fps * 1000)}ミリ秒` : "fpsは1以上にします";
};
</script>

初期値の60fps・27コマで約450ミリ秒になります。これは計算の例であって、作品の実測値ではありません。

記録の取り方段階ごとに、序盤・中盤・終盤から数手ずつ、合計で各段階10手以上を目安に記録します。表の列は「段階」「手数目」「コマ数」「ミリ秒」です。

結果の読み方

• 多くの手が約450ms以下に収まるなら、「上限として働いている」と読めます。
• 450msより大きい値が出た場合は、すぐに「制限が働いていない」と考えないでください。駒の移動の演出、端末の処理、動画のコマ送りの誤差が加わっている可能性があります。思考時間の制限と、見かけの待ち時間は別のものです。
• 手によって値が大きくばらつくなら、「必ず同じ時間かける」のではなく、手に応じて変わる設計だと推測できます。これも推測にとどめ、段階の間で比べて確かめます。

問い2：3段階の差は、どこに現れるか

記録するもの1局ごとに、次の項目を記録します。

• 段階（3つのうちどれか）
• 自分の色（白か黒か）
• ヒントを使った回数
• 一手戻すを使った回数
• 結果（勝ち・負け・引き分け）
• 終局までの手数

回数1段階につき5局以上を目安にします。チェスは1局の偶然が大きいので、1局だけでは判断しないでください。ヒントと一手戻すを使う局と使わない局は、分けて数えます。使うほど自分に有利になるので、混ぜると段階の差が見えなくなります。

結果の読み方

• 段階が上がるにつれて、勝ち数が減る、終局までの手数が短くなる、ヒントや戻す回数が増える、といった変化が出るなら、段階の差は「強さ」に現れています。
• 差が見えないときは、局数が少ないか、自分の実力が段階の幅を超えている可能性があります。局数を増やすか、ヒントなしで挑み直します。
• 勝敗は同じでも、取られた駒の数や序盤の乱れ方が違うことがあります。全棋譜を見返して、どの手で形勢が動いたかを比べると、段階の違いが具体的に見えてきます。

起こりやすい誤り

• 450msを「かならず450msかける」と読む。 確認できるのは上限です。
• 待ち時間の短さを、強さの低さと結びつける。 2つは別の軸です。
• 動画の計測値のずれを、仕様の誤りだと決める。 演出や端末の差が混ざります。
• 1局の結果で段階を評価する。 色や序盤の偶然に左右されます。
• ヒントを使った局と使わない局を混ぜる。 比較が成り立たなくなります。

次の行動

灯りのチェスを開き、最も易しい段階で10手ほどの待ち時間を動画で撮って、コマ数を数えてみてください。続いて、3段階それぞれで5局ずつ、ヒントなしで指して記録をつけます。数字と棋譜の両方を見れば、約450msという上限が対局のテンポをどう支えているか、読者自身の言葉で説明できるようになります。