カナルビュー（Canal View）を、4 段のソルバー内蔵でブラウザに実装した。ルールは「数字は四方向に見える黒マスの合計」。効いているのは見えるという一語だ。連なりは最初の白マスで止まるので、その白の向こうにどれだけ運河が続いていても数には入らない。つまり数字は自分の行と列についての主張ではなく、その手前の端についての主張でしかない。出荷 72 盤で測ると、8×8 の数字は自分の四方向に実在する黒 5.28 マスのうち 3.84 しか見ておらず（72.8%）、12×12 では 64.7% まで落ちる。12×12 では白 1 マスが、それを正面から見ている数字に対して黒の連なり 10 マスを隠していた。視線を二度数えると 4 × 運河 = 見えた + その方向に数字が無い + 白に遮られた がぴったり成立し、8×8 で 4,616 = 1,576 + 2,451 + 589。ソルバー内蔵パズル第 61 弾。

デモ: https://sen.ltd/portfolio/canal-view/
リポジトリ: https://github.com/sen-ltd/canal-view

ルール

いくつかのマスを黒く塗る（この記事とアプリでは「運河に沈める」と呼ぶ）。

黒マス全体が辺で連結した 1 つのかたまりになる
2×2 が全部黒になってはいけない
数字のマスは常に白。その数字は、四方向に見える黒マスの合計。自分の隣から始まる連なりを足す

以上。ルール自体は 3 行で終わる。にもかかわらず、この 3 行のどこが実際に難しさを作っているのかは、書いてみるまで自分の予想と一致しなかった。

「見える」という一語

数字の光線を外に向かって歩くと、答えがどうであれ形は必ずこうなる。黒が a マス、次に白が 1 マス、その先は何でもよい。

「その先は何でもよい」がこの puzzle の全部だ。白 1 マスの向こうに黒が 8 マス並んでいても、数字は 0 としか言わない。数字は行と列の総量ではなく、その手前の端しか報告していない。

出荷している 72 盤（8×8 と 12×12 を 36 枚ずつ）で測った。

盤	数字が言う値	自分の光線上に実在する黒	見えている割合	壁の向こうに運河がある光線	隠れているマス（平均）	白1マスが隠した最大
8×8	3.84	5.28	72.8%	9.5	1.73	6
12×12	5.06	7.83	64.7%	25.5	2.34	10

盤が大きくなるほど、数字は自分の行と列に対して盲目になっていく。12×12 では 1 枚あたり 25.5 本の光線が「壁の向こうに運河を持つ」状態で、最大のものは白 1 マスが黒 10 連を隠していた。

同じ 3 という数字が、隣が 3 連なのか、隣が 1 マスで奥に何かあるのか、まったく区別しない。これがクロダコ（黒どこ）系の「見通し」パズルと Canal View を分ける点でもある。

視線を二度数える

黒マス 1 つを固定すると、それを見ている数字は各方向にたかだか 1 つ（最初にぶつかった数字だけ）。だから「（数字, その数字が見ている黒マス）」の組を二通りに数えられる。

数字側から数えれば、それは数字の総和
マス側から数えれば、黒マス 1 つあたり 4 以下

したがって探索を一切しなくても運河の下限が出る。上限は 2×2 禁止から出る。h×w の格子で 2×2 を含まない最大の部分集合は hw − ⌊h/2⌋⌊w/2⌋ だ（1 行おきに全部塗り、その間の行は 1 マスおきに塗る）。

⌈Σ数字 / 4⌉ ≤ 運河 ≤ hw − ⌊h/2⌋⌊w/2⌋

盤	数字から出る下限	実際の運河	2×2 から出る上限	数字の総和 ÷ 運河
8×8	11	32.1	48	1.37
12×12	28	72.4	108	1.51

このサンドイッチは緩い。そしてその緩さの理由が、そのまま最初の節の内容になる。上限の 4 が達成されるのは「すべての黒マスが四方すべてから見えている」ときだけで、実測は 1.37（8×8）と 1.51（12×12）だった。足りない視線を分類するとこうなる。

盤	(黒マス, 方向) の組	見えている	その方向に数字が無い	途中に白がある	遮蔽の割合
8×8	4,616	1,576	2,451	589	12.8%
12×12	10,432	3,933	4,351	2,148	20.6%

2 列目は運河のマス数のちょうど 4 倍、3 列目はちょうど数字の総和になる。まったく別の経路で計算した 2 つの数が一致するので、この恒等式はテストにしてある（npm test が盤ごとに検証する）。遮蔽は 12×12 で全視線の 20.6% を占め、盤が大きくなるほど増える。

黒マスを「何人の数字が見ているか」で分けると、8×8 では 1,154 マス中 96 マスが誰からも見えていない。

光線は 2^m 通りではなく m+1 通り

さきほどの「黒 a、白 1、あとは自由」という形は、実装上とても都合がいい。長さ m の方向が取りうる状態は 2^m ではなく m+1（腕の長さ）しかなく、数字 1 つのクロス全体は 値を 4 つの腕に分ける有界な組成（composition） ちょうど 1 つで決まる。

ソルバーが分岐するのは、最後までこの組成の上だけだ。

盤	数字の個数	数字の光線上のマス	2^マス	実際に成立する組成
8×8	11.4	8.9	478	8.4
12×12	21.6	13	8,192	17.9

だから完全ソルバーが安い。12×12 の中央値は探索ノード 7 個、最悪でも 319 個、1 枚 22.2 ms で解ける。

ラダーは 4 段。

arm — 組成に対する弧無矛盾（arc consistency）。今の盤面と矛盾する腕の割り当てを捨て、生き残った全部が一致する所だけ確定させる
block — 加えて 2×2 のうち 3 つが黒なら残り 1 つは白
flow — 加えて連結性。もう合流できない 2 つの黒の塊は矛盾、運河が絶対に届かないマスは白、そこを失うと運河が二分されるマスは黒。さらに上のサンドイッチを残りマスの上下限として使う
search — 完全ソルバー。最も制約の強い数字の組成で分岐する

段	確定マス 8×8	確定マス 12×12	完答 8×8	完答 12×12
`arm`	54.6%	41.9%	0/36	0/36
`block`	63.7%	53.9%	0/36	0/36
`flow`	81.5%	67.5%	18/36	6/36
`search`	100%	100%	36/36	36/36

運河は湖を囲んでいい

Canal View には「白マスが連結していること」というルールが無い。ぬりかべ系に慣れているとつい足してしまうが、無い。そして実際の盤はそれを遠慮なく使う。

盤	運河	盤に占める割合	湖（外から遮断された白の領域）	湖のある盤	独立サイクル数	ループのある盤
8×8	32.1	50.1%	3.5	36/36	2.1	35/36
12×12	72.4	50.3%	12.1	36/36	6.8	36/36

湖を囲む運河とは、サイクルを持つ運河のことだ。ここで 2×2 禁止が効いてくる。2×2 を含まないのに木でない最小の形は 8 マスのリング（3×3 の外周）で、しかも 8 マスではそれが唯一である。固定ポリオミノを両方の基準で数えると、2 つの概念が分かれる瞬間がそのまま見える。

マス数	固定ポリオミノ	2×2 を含まない	木構造	2×2 無しでサイクル有り
7	760	570	570	0
8	2,725	1,909	1,908	1
9	9,910	6,485	6,473	12
10	36,446	22,282	22,202	80

2 列目と 4 列目は登録済みの数列（A001168 と A066158）で、npm run ledger は列挙器がどちらかとずれた瞬間に出力を書かずに落ちる。3 列目（運河が実際に満たすべき条件）はどちらでもなく、OEIS にも見当たらなかった。

小さい格子に収まる運河そのものも数えた。全 2^hw 部分集合を 1 つずつ試す方法と、アンカーから成長させる方法の 2 通りで数え、一致を要求している（4×5 で連結集合 116,166 のうち運河は 25,822、22.2%）。

1 マス反転させると、どのルールが怒るか

出荷した答えの 1 マスを反転させる。6,301 通りすべてが不正だった。問題はどのルールがそれを止めたかだ。

ルール	止めた反転	そのルールだけが止めた反転
数字	5,298	2,974
2×2 禁止	932	197
運河の連結性	2,395	806
どれも止めない	0	—

15.9% は 2×2 か連結性だけが止めている。 言い換えると、この 2 つのどちらかを落とした瞬間に、答えの 1 マス編集がその数だけ合法になる。これは次の表で実際に測れる。

4 通りの誤読と、その結末

誤読	盤	枚数	意図した答えが合法か	解の個数（中央値）	一意	解無し
2×2 禁止を落とす	8×8	24	24/24	32	2	0
	12×12	24	24/24	≥2,000	0	0
連結性を落とす	8×8	24	24/24	1,248	0	0
	12×12	24	24/24	≥2,000	0	0
白も連結させる	8×8	24	0/24	0	0	24
	12×12	24	0/24	0	0	24
数字を行・列全体と読む	8×8	12	0/12	0	0	11
	12×12	12	0/12	0	0	12

上下 2 組は逆向きに壊れる。ルールを落とすと、意図した答えは合法なまま数百の解に埋もれる——だから解けてしまうし、2 つ目の解に気づくまで何もおかしく見えない。無いルールを足す（白も連結させる）か、見えないものまで数えると、意図した答えのほうが違法になり、盤は空になる。存在しない答えを延々と探すことになるのはこちら側だ。

ダイヤルは「残す数字の数」

生成器は答えを先に描く。ランダムな連結・2×2 なしの集合を成長させ、白マス全部に数字を書き、そこから 1 つずつ数字を消していく——一意性が保たれる限り。

白マス全部に数字を書いた盤は、答えを声に出して言っているようなものだ。そこからランダムに消すとどうなるか。

残した数字（8×8）	試行	一意	率
白マス全部	108	108	100.0%
26	108	83	76.9%
22	108	54	50.0%
18	108	21	19.4%
15	108	6	5.6%
12	108	0	0.0%
10	108	0	0.0%

出荷盤が持っている数字は 8×8 で 11.4 個、12×12 で 21.6 個。ランダムに 12 個まで削った 108 回の試行で一意は 0 回（12×12 で 22 個に削った 108 回も 0 回）。出荷盤の数字は 1 つ残らず「消してみて、駄目だったから戻した」ものだ。

そして表の 1 行目には落とし穴がある。白マス全部に数字を書いても一意とは限らない。 新しく引いた 8×8 の運河 200 本のうち 3 本は、全マスに数字を書いてなお 2 つ目の答えを持っていた。動いたマスは 3 本とも、どの数字からも見えていないマスだった。答えを全部書き出しても、言ったことにならない場合がある。

偶然には生まれない

数字をランダムな位置に、ランダムな値で置いてみる（実際の盤が使う小さい範囲と、光線が許す全範囲の 2 通り）。1,600 回引いて一意な盤は 0 枚。面白いのは「解無し」の列で、答えの周りに作られていない盤は、そもそも解けないことのほうが多い。要求している数と、それを支える運河の形が、噛み合わないからだ。

2 つのエンジン

組成による分解がこの実装の要なので、それを一切知らないエンジンと突き合わせている。マスを読み順に走査し、黒→白の順に試し、枝刈りは「すでに閉じた 2×2」と「もう値に着地できない数字」だけ、最後にルールを直接検査する。

6×6 の 30 盤（総当たり側 1,939,359 ノード）で、両者は 30 回一致・0 回不一致。しかも解の集合が一致している。2×2 禁止を落として解が数百に増える設定でも 30 回一致（合計 1,126 解）。

まとめ

3 行のルールのうち、盤を難しくしているのは数字ではなかった。数字は運河の 65〜73% しか見ておらず、残りは白 1 マスの陰に隠れている。それでも盤が一意になるのは、見えない部分を連結性と 2×2 禁止が押さえているからだ。1 マス反転の 15.9% はその 2 つだけが止めている。

実装: TypeScript + Vite、ランタイム依存ゼロ、20 テスト
生成: 答えを描いてから数字を削る。出荷 72 盤はすべて「これ以上削れない」局所最大
検証: 完全ソルバーと素朴エンジンの解集合一致、A001168 / A066158 との照合、格子上の運河数を 2 通りで計数

デモとソースは冒頭のリンクから。記事中の数値はすべて npm run stats / npm run ledger の出力から生成していて、README とページの本文はその JSON から機械的に書き出している。