結論。境界+隣接の整合性チェックを繰り返しても向きが決まらないマスが残ったら、そのうち選択肢が最も少ないマス(この実例では2択)を1つ選んで仮に向きを決め、そこから同じ隣接チェックを波及させる。波及の結果、盤の一部が輪(ループ)で閉じて孤立し、点灯数(◯ / 総マス数 接続の表示)が全マス数に届かない形になったら、その仮置きは誤り。もう一方の向きが正解になる。 中級編の実例では、この「仮置き→波及→矛盾の確認」が1箇所で1回だけ必要でした。
まず境界+隣接で絞れるところまで絞る
初級編と同じ手順(盤の端の制約→隣接マスとの整合性チェックの繰り返し)を、この5×5盤面に適用します。4巡の隣接チェックで、25マス中19マスが確定します(Signal側の難度判定でもlocalRounds: 4・localFixed: 19)。
残り6マスは、盤の右側、2列4〜5列目・3行目〜4行目にまとまっています(マス番号は行1列1を0とした行→列の連番。8=行2列4、9=行2列5、13=行3列4、14=行3列5、18=行4列4、19=行4列5)。それぞれの残り候補は次のとおりです。
| マス | 位置 | 残り候補 |
|---|---|---|
| 8 | 行2列4 | 「上・右・左」/「上・下・左」 |
| 9 | 行2列5 | 「下」/「左」 |
| 13 | 行3列4 | 「上・右・左」/「右・下・左」 |
| 14 | 行3列5 | 「上・左」/「下・左」 |
| 18 | 行4列4 | 「上・下・左」/「右・下・左」 |
| 19 | 行4列5 | 「上」/「左」 |
これ以上、境界の制約や隣接マスとの整合性チェックだけを繰り返しても、この6マスの候補はこれ以上絞れません(実際にNode.js上で隣接チェックをさらに数巡試しましたが、候補数は変化しませんでした)。これが「境界+隣接だけでは解けない」局面です。
選択肢が最も少ないマスを1つ選んで仮に置く
6マスのうち、マス9(行2列5)は「下」か「左」かの2択で、他のマスより選択肢が少ない端点タイルです。ここを仮に決めることから始めます。
まず「マス9=左」を仮定してみます。この仮定のもとで隣接チェックを波及させると、他の5マスも含めて全マスの向きが1通りに確定します(隣接チェックの結果に矛盾は起きず、候補が0件になるマスもありません)。一見、これで解けたように見えます。
ところが、この確定した盤面全体を実際に点灯判定してみると、信号源(盤中央、行3列3=マス12)から点灯するマスは25マス中15マスしか届きません。 残る10マスは、盤のどこかにできてしまった輪(ループ)によって、信号源側の区画から完全に切り離された状態になります。全体の接続数(辺の本数、両端カウントで48=片道24本)を数えると正解と同じなのですが、辺の配分が偏っていて、信号源側の15マスの中に本来不要な輪が1つでき、残り10マスは辺が9本(10マスの木として過不足ない本数)ながらも信号源側とはつながっていません。 「輪がなく全マスが1本でつながる」というSignalの完成条件に反するため、マス9=左は誤りです。
続いて「マス9=下」を仮定して同じように波及させると、今度は全マスが1通りに確定したうえで、点灯判定も25マス中25マス全部に届きます。これが正解です。
なぜ「隣接チェックだけ」では見抜けないのか
隣接チェックは「隣のマス同士が矛盾していないか」しか見ません。マス9=左を選んでも、選んだ瞬間には周囲のどのマスとも矛盾しないため、隣接チェックの範囲では「候補が0件になる」という分かりやすいエラーは起きません。矛盾が表面化するのは、全マスを埋め終えたあとに、盤全体で「輪ができていないか」「全部つながっているか」を確認したときです。これは1マスと隣のマスだけを見る隣接チェックより広い範囲(盤全体)を見る判断で、初級編の手順だけでは検出できません。
手順のまとめ
- 境界+隣接チェックで絞れるところまで絞る(この実例では19/25マス)。
- 残ったマスの中から、候補数が最も少ないマスを1つ選ぶ(この実例ではマス9、2択)。
- 候補の一方を仮に選び、隣接チェックを波及させて残りのマスも埋める。
- 埋め終わった盤全体で、信号源から点灯するマスが全マスに届くかを確認する。届かなければ(輪ができている、または孤立領域がある)、その仮置きは誤り。もう一方の候補に切り替える。
タップ手順と検証
出題時点から正解までの、各マス(0〜24)のタップ回数(時計回り)は次のとおりです。
マス: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
タップ回数: 1 0 0 2 2 0 0 1 0 2 2 2 0 3 3 1 3 0 1 3 2 1 0 1 0
合計30回。実際にこの回数どおりにタップした結果が正解と完全に一致し、点灯判定も25マス全部に届くことを、Node.jsでsignal/engine.jsを直接実行して確認済みです(盤中央、行3列3=マス12が信号源)。
誤りやすい判断
- 候補が0件にならないから正しい、とは限らない。 隣接チェックの範囲で矛盾が出ないことと、盤全体として正しい(輪がなく全部つながる)こととは別の基準です。埋め終えたら必ず点灯数を確認してください。
- 点灯数が「多いから」といって正しいとは限らない。 この実例の誤答(マス9=左)でも、25マス中15マスは実際に点灯し、進捗表示は「15 / 25 接続」と表示されます。0や少数ではなく、全体の6割相当という紛らわしい数で止まる点に注意してください。
- 仮置きは「賭け」ではなく、UIの「一手戻す」「1マスの答え」(この記事でのヒント)で安全に試せる操作です。 仮に置いて矛盾が見えたら、「一手戻す」でその1マスを含む変更を取り消し、もう一方を試せます。
読者の検証方法
- 同じ盤面は
n=5・シードnotes-solve-medium・難度指定mediumで再現できます。 - 「マス9=左」を試して点灯数が25に届かないことを、実際に自分の手元で確認できます(信号源からの点灯が止まる位置は、輪ができている境目のマスの手前です)。
- 不安な場合は、候補を1つ選ぶたびにヒントで1マスだけ答え合わせしながら進めても、手順の妥当性は変わりません。
この記事が確認していないこと
- 「候補数が最も少ないマスから仮置きする」という選び方は、この記事とSignal自身の内部実装(
analyzeDifficultyが使うMRVという同種の考え方)の両方で有効でしたが、別の中級問題でも必ずこの選び方1回だけで解けることまでは保証しません。README自身も「少数の残りマスに浅い仮置きが必要なだけなら中級」と述べるにとどまり、必要な仮置きの回数を厳密に定義していません。 - 上級編(その3)で扱う、未確定マスが盤面の半分以上を占めるケースは、この記事の手順の延長で対応できますが、仮置きの回数がこの記事より明らかに増えます。
この結果が言っていないこと
- 検証は
signal/engine.js・signal/app.js(エンジンv3、2026-09-29時点)を対象にしています。将来の版で表示・判定基準が変わる可能性があります。 - 「輪ができて盤の一部が孤立する」という矛盾のパターンは、この実例で実際に起きたものです。中級問題で起こりうる矛盾のパターンがこれだけとは限りません(境界からはみ出す・隣接マスと直接食い違う、といった、より単純な矛盾が起きる問題もあります)。