2026.09.23 泊まれる場所4,223 立ち寄りスポット59,693 営業中を確認したキャンプ場1,005 note を読む

AIに道を敷かせたら、街が碁盤の目になった。対角線を見て直した

一つの修正を直したその日に、別の不具合が届いた。

日本進化シミュレーション第10回 / 全17回目次

AIの自動開発は、しばらく「行き止まりを作りがち」という弱点を持っていた。
道を1マス延ばしては、また別の場所に短い道を生やす。
1本を繋ぎ切る前に次へ移ってしまうので、街の外周がやたらとギザギザになる。

これを直そうと、直前にAIが作った行き止まりのセルを覚えておいて、次のターンもまずそこを最優先で延ばし続ける、という処理を入れた。
行き止まりでなくなって、ようやく新しい場所を探しに行く。
狙い通り、外周のギザギザは落ち着いた。

直したその日のうちに、別の報告が来た

「AIの道路が升目状になっている」というスクリーンショット付きの報告だった。
見ると、たしかに川沿いのような道路密度が上がりやすい場所で、1マス四方くらいの小さなブロックがびっしり並ぶ、まるで方眼紙のような道路網になっていた。

行き止まりを潰したはずなのに、別の意味で見た目がおかしくなった。
自分の直したコードが新しい不具合を生んだのは間違いなさそうだったので、僕はまず手元で再現させることにした。

手を動かして、実際に再現させる

ブラウザのコンソールから、ゲームの1ターン分の処理を数百回連続で呼び出すループを回した。
待ち時間を作らずに、ロジックだけを高速に繰り返す。
数十秒後、画面には報告通りの升目状の道路網ができあがっていた。

再現できたことで、原因の切り分けがぐっと楽になった。
「たまに起きる」ではなく「毎回同じ条件で起きる」なら、条件そのものを絞り込めばいい。

原因は2箇所、どちらも「密度を見ていない」ことだった

一つは、道路の候補を探す処理。
隣接する道路が2本あるマスを、無条件で「輪を閉じるのにちょうどいい場所」として扱っていた。
もう一つは、さっき直したばかりの行き止まり追跡。
延長先を選ぶときに、周辺の密度を一切見ていなかった。

どちらも、単体で見れば妥当な判断に見える。
けれど密集した場所でこの2つが同時に働くと、隣接ストリート同士をどんどん短く繋いでしまい、極小のブロックが量産される。

対角4マスを見る、という一つのルールで両方直った

候補マスの対角4方向のうち、2つ以上がすでに道路なら、その候補を外す。
「そこを埋めると小さなブロックができてしまう」という合図として扱うルールだ。

これを、輪を閉じる判定と行き止まり延長の両方に同じように入れた。
別々のバグに見えて、根っこは同じ「密度を見ずに繋いでしまう」という性質だったので、一つのルールで両方カバーできた。
あわせて、輪を閉じる確率や条件も少し控えめに調整した。

2つの修正が、互いに新しい不具合を生むことがある

今回学んだのは、一つの修正が別の不具合を作ることは珍しくないという当たり前の事実だった。
行き止まりを直したこと自体は間違っていない。
ただ、それが密集地帯でどう振る舞うかまでは、直したその瞬間には考えが及んでいなかった。

AIのロジックは、個々のルールがそれぞれ正しくても、組み合わさった結果までは予測しにくい。
だからこそ、直したら必ず長めにシミュレーションを回して、目で見て確認する習慣が欠かせなくなった。

ゲームを1本作るときの進め方を、noteにまとめています(書いているのは私です)。
noteで読む

まる子パパ

まる子パパ

会社員。受託開発のエンジニアを15年以上続けていて、その前は寿司職人・長距離運転手・農業。 技術ブログは、キャンプの合間に踏んだバグと、AI・Web開発の運用の失敗を書いています。 このサイト自体が、開発に携わっているCMS「コンテナ」の稼働中の実例です。 このサイトについて / 小さな自動化の相談

—

ほかにも書いています

受託・note・スタンプ

※受託の相談とnoteは、運営者が個人で受けている・書いているものです。

技術ブログ一覧へ戻る