0. 振り返り：ここまでのあらすじ

第1回： 爆速ソルバー完成。SATソルバーという「論理の怪物」を飼い慣らす
第2回： 「唯一解」の生成に成功。しかし、生成されるのは「解けるだけ」の凡問ばかり

次に立ちはだかったのは、「解ける」と「面白い（難しい）」の間に横たわる、深くて暗い溝でした。

1. 人間の限界：物理制約という「エンジニアのエゴ」

「難しい問題」を作ろうと、私はエンジニアとパズラーしての知見を総動員し、物理的な制約をコードに落とし込みました。

直線の排除: 最短ルートを封じれば、プレイヤーは迷うはずだ
直角箇所の強制: ぐねぐね曲げれば、視覚的に混乱するはずだ
数字の分散: 端点を離せば、ヒントが減って難易度が上がるはずだ

しかし、結果は惨敗。
実装を重ねるほど生成ロジックは肥大化し、計算時間は伸び、肝心の「解きごたえ」は一向に上がりません。
おそらく考えうる原因は「そもそもの仮設」の定義が誤りであったこと。
その仮説とは、「難しそうな作り方をさせれば難易度は上がるはず」というものです。
私の考える問題の難問化ロジックは、残念ながらいたずらに作問の負荷を上げるだけの、徒労にしかならないもののようでした。

2. 転換点：AIが教えてくれた「難しさの正体」

試行錯誤の中、ランダム生成の海から、運よく 「解くのに5分以上かかる難問」 が1問だけ見つかりました。一方で、難易度を決めるであろう諸条件が同じなのに 「20秒で解ける凡問」 も山ほどあります。

以下の二問を用意いたしましたので解いてみてください。どちらが難しいと感じたでしょうか。

圧倒的に後者のほうが、難しいと感じたのではないでしょうか。この後者の問題が、運よく私が発掘したものになります。

この両者の決定的な違いはどこにあるのか？ AIに問いました。
するとAIは、SATソルバーが吐き出す統計データ accum_stats() に答えを求めてはどうかと提案してきました。

3. SATソルバーの「葛藤（Conflicts）」をスコアリングする

SATソルバーが解を見つけるまでの内部プロセスを覗くと、そこには壮絶な 「論理の葛藤」 がありました。

指標	20秒の凡問	5分の難問
Conflicts (葛藤回数)	43	4632

最終解答を生成するまでの葛藤回数に、まさかの100倍もの差がついています。
人間が「こっちかな？」と悩むのと同様に、ソルバーもまた、数千回、時には数万回にも及ぶ「矛盾」に突き当たり、引き返し、試行錯誤を繰り返しているようです。

ひょっとして、人間が難しいと感じる問題はAIにとっても難しいのだろうか。
この「Conflicts（葛藤）の回数」こそが、人間の脳が感じる「壁」の高さと相関しているのだろうか。

これまで定性的だった「難易度」を「ソルバーの苦悩の量」として定量化すればいいのではという仮説のもと、いよいよ物量で殴る作戦へと舵を切ります。

4. 結論：理屈より回数。最強の「無限ガチャ」戦略

結論から言うと、この仮説は当たりのようでした。
「良い問題を作るエンジニアのエゴ」を捨て、ひたすら「ガチャを回す環境」を整える、 これがひとまずの最適解となりました。

新・戦略：無限パズルガチャ

生成: 制約の少ない問題を爆速で量産する
評価: 生成した問題を片っ端からソルバーにかけ、Conflictsスコアを計測
試行: とにかく1万回ぶん回す
選別: スコアが跳ね上がった「選ばれしエリート」だけを世に出す

「良い問題を目指して作る」のではなく、「凡問を1万問作って、難易度が統計的に上振れた最高の1問を選ぶ」 。このパラダイムシフトが、作問のクオリティを劇的に進化させました。

以下が、生成された1万問のうち、上位10問の難問です(下に行くほど葛藤スコアが高いです)。

個人的には下から二つ目がエグいと感じましたが、全て解きごたえとしては抜群の問題が並んでいるのではと思います。

5. おわりに：エンジニアのエゴを捨てる勇気

現代のAIの基礎を形作る機械学習は、膨大なデータから法則性を自動的に導出させるというものです。
そのさらに過去には、エキスパートシステムという知識ベースを基にするAIの失敗がありました。
そのような歴史があったことも忘れ、私は「自分の稚拙な知識をベース」に難問を生み出そうとしてしまいました。

エンジニアの役割は、迷路を緻密に設計することではなく、「何が優れた迷路か」を見抜く審美眼（評価関数）を構築し、あとは計算資源という暴力でガチャを引き続けること にある。

AI駆動開発とは、自分のエゴを捨て、AIが見せた意外な指標を信じてシステムを組むこと。1万回の試行の先に待っていたのは、人間には到底設計できない、美しくも残酷な「葛藤」の記録でした。
ここまでの一連の開発を通して、近年盛り上がりを見せているAI駆動開発というものの一端を垣間見ることができたのではと感じています。

この後は、補足分析として1万件のデータを統計的に紐解いていきたいと思います。

Girhubリポジトリ（記事公開時コミット）
https://github.com/mashinosatoshi/pencil_puzzle_solver/tree/67c293bccc45cd6e5a95bdfc77f8bcf95d40e860/numlin

あわせて読みたい：

※本記事は一部Geminiを使用して作成しています。