← 制作記一覧へ

消しても消しても復活するゲームセンターの話

公開: 2026-07-25 · #99 / 最終更新: 2026-07-25 個人開発データ整備失敗談子連れスポット

📌 記事の取り扱いについて(公開当時の内容を含みます — タップで詳細)

本記事は公開当時の体験・気づきをまとめたものです。現在のツール数・プラン数・対象年齢・記事数・仕様とは異なる場合があります。最新の内容は各ツールページをご確認ください。ツールや外部サービスの仕様・料金は変更されることがあるため、利用前には各公式情報も併せてご確認ください。記載に誤りを見つけられた場合はお問い合わせフォームよりご連絡いただけると助かります。

ツール工房.ai では、0〜6歳の子ども連れで行けるおでかけスポットを地図で探せるツールを公開しています。公園や動物園、児童館などを載せているのですが、ある日この地図の中に、明らかに場違いなゲームセンターが混ざっているのを見つけました。

「小さな子ども向けの地図にゲームセンターはちょっと違うよな」と思って、その場でデータから削除しました。ここまでは普通の話です。問題はその後でした。しばらく経ってデータを更新したら、消したはずのゲームセンターがまた地図に戻ってきていたのです。

まるでゾンビです。倒したはずなのに、いつの間にか復活している。今回は、この「消しても復活するデータ」との付き合い方の話をします。

なぜ消したはずのものが戻ってくるのか

このツールのスポットデータは、私が一件ずつ手で集めているわけではなく、外部の公開データなどから自動で集めて、公開用の一覧に作り直す仕組みになっています。週次でデータを集め直しているので、新しいスポットが自然と増えていくのが良いところです。

ところが、この「作り直す」というのが曲者でした。データを更新するたびに、外部から集めた元データを最初から読み込み直して、公開用の一覧を組み立て直す構造になっていたのです。

つまり、私が削除したのは「組み立てた後の公開用一覧」のほうでした。元データにはゲームセンターがそのまま残っているので、次の更新で一覧を組み立て直した瞬間、また堂々と入ってくる。私の削除作業は、更新のたびに無かったことになっていたわけです。

仕組みを聞けば当たり前なのですが、当事者としては「先週消したのに、なんでいるの?」と、しばらく首をひねりました。自分の作業履歴を見返して、削除した日付まで確認したくらいです。消した記憶は確かにあるのに、目の前の地図には元気に表示されている。この時点では、まだ原因が構造にあるとは思っていませんでした。

「削除した結果」ではなく「削除するルール」を残す

原因が分かってからやったことは、シンプルでした。データを組み立てる処理そのものに、「この名前のスポットは入れない」という除外ルール、いわゆるブラックリストを組み込んだのです。

それまでの私は、完成品の一覧から手で消していました。これは言ってみれば「掃除した部屋の状態」だけを残すやり方です。でも部屋を毎回ゼロから作り直す仕組みの中では、掃除の結果は次の作り直しで消えてしまいます。

残すべきだったのは「この名前のものは部屋に入れない」というルールのほうでした。ルールを組み立て処理の中に書いておけば、元データに何が残っていようと、一覧を作り直すたびに自動で弾かれます。実際、この除外ルールを入れてからは、例のゲームセンターは二度と復活していません。なお、除外しているのは大型チェーンのゲームセンターだけで、子ども向けの遊び場を併設するような小規模な施設は個別に判断して残しています。地図にゲームセンターの名前が残っているのは、そのためです。

ただし正直に書いておくと、このルールは「この名前のものは入れない」という名前の一致で弾く仕組みです。消えるのは、私がリストに書き足した名前のものだけ。自動で集めたデータには、別の名前のゲームセンターが「遊園地・遊技施設」として残っていることがあります。見つけたら名前を足す運用で、いまも完全な自動判定にはできていません。

ちなみにこの除外ルールには、その後も仲間が増えました。閉業していたプールや、元データの登録ミスとしか思えない名前のスポットなど、「一度消したのに戻ってきそうなもの」を見つけるたびに、ルールのほうへ追記しています。ルールにコメントで「いつ・なぜ除外したか」を書き添えておくと、後から見返したときに助かります。

自動でデータを集める仕組みの宿命かもしれない

今回の件で感じたのは、データを自動で集める仕組みには「人間の手作業の修正が、自動処理に上書きされる」という宿命みたいなものがある、ということです。

自動収集はありがたい仕組みです。私一人では、全国のおでかけスポットを集めきることはとてもできません。ただ、自動で集めたデータには、どうしても場違いなものや間違いが混ざります。そして、それを見つけて直すのは結局人間です。

このとき、人間の修正を「完成品への上書き」でやってしまうと、次の自動処理でせっかくの修正が流されます。修正は「処理へのルール追加」という形で残す。手作業と自動処理を共存させるには、この置き場所の区別が大事なんだと、身をもって学びました。

似た構造は、開発以外にもある気がします。たとえば書類のひな形から毎回作り直す運用で、完成した書類のほうだけ直しても、次にひな形から作ればまた同じ間違いが出てくる。直すべきはひな形のほう、という話と同じですね。

振り返り

一連の対応は、AIに相談しながら進めました。「削除したはずのデータが更新後に復活する」と相談したら、データを組み立て直す処理の構造を一緒に追いかけてくれて、原因の見当が早くつきました。非エンジニアの私が一人でコードを読んでいたら、もっと長くゾンビと戦っていた気がします。

教訓を一行でまとめると、こうなります。データは「削除した結果」ではなく「削除するルール」を残さないと戻ってくる。

地味な学びですが、自動でデータを集めて公開する仕組みを持っている人には、けっこう普遍的な話ではないかと思っています。私の地図からゲームセンターが消えて、そのまま戻ってこなくなった日は、ちょっとした達成感がありました。


← 他の制作記を見るトップお問い合わせ