商圏分析システムの部品を組み替えて、土砂災害ハザードマップの判定サービスを1日で作った——検索需要を先に実測して「作るもの」を決めた記録

2026年9月5日

名古屋でAIシステム開発の会社をやっています。

先日、住所を入れると土砂災害ハザードマップの警戒区域に入るかどうかを判定するサービスを公開しました。全国47都道府県・約179万区域を収録しています。

Kurage 土砂災害ハザードマップ（無料で試せます）

この記事は機能紹介ではありません。「何を作るか」をどう決めたかと、作らないと決めたものの話です。そこがいちばん再現性のある部分だと思うので。

きっかけは「売れていない」という事実

半年ほど前に、住所から徒歩圏の人口・世帯・事業所を出す商圏分析システムを作りました。技術的にはうまくいきました。道路網をたどった到達圏を出して、国勢調査のメッシュ統計を交差面積で按分する。精度も速度も満足しています。

ところが検索からの流入がゼロでした。1件もありません。

原因を調べたら、単純な話でした。

製品名そのものである「商圏分析ツール」を、月に210人しか検索していません。 しかも競合指数60で、正面から取りにいくには重い。仮に1位を取ってもクリックは月数十回です。

これは技術の問題でも、ページの問題でもありません。そもそも人が探していない言葉に賭けていたという、企画の問題でした。

同じ技術で、当てる先を変える

商圏分析システムの中身は、3つの部品でできています。

この3つは商圏分析専用のものではありません。「住所を点にして、面と重ねて、中身を答える」という汎用の仕組みです。

そこで、この仕組みが当てられる先を洗い出して、片っ端から検索需要を測りました。

ハザードマップが230倍で、競合指数はゼロでした。

ついでに、当てられそうに見えて需要が無かったものも測っています。ここを測らずに作ると時間を失います。

「業種ごとの専用システム」は、名前で探されていません。GISを活かすなら、業種名ではなくGISの言葉で入口を作るほうが正しい、というのがこの表から読み取れることでした。

作りながら、作らないものを決めた

方針が決まったので実装に入りました。部品は流用できるので、判定そのものは半日で動きました。

問題はデータでした。

浸水は扱わないと決めた

当初は「ハザードマップ」なので洪水の浸水想定も入れるつもりでした。国土交通省の国土数値情報からデータを取ってきて、中身を確認したところ、こうでした。

浸水想定区域は14年前のデータが最新でした。しかも2015年の水防法改正で「想定最大規模」に基準が変わる前のものです。

これで「浸水想定区域外です」と答えたらどうなるか。実際には現行の想定区域内、ということが起こり得ます。不動産の重要事項説明に使われでもしたら賠償問題です。

扱わないと決めました。 サービスの中にも、扱わない理由を書いてあります。機能が減るので売り文句としては弱くなりますが、間違った安心を与えるよりずっとましです。

「調べた気にさせない」を設計の中心に置いた

災害リスクを扱う道具でいちばん危ないのは、精度の低さそのものではなく、利用者に「調べた」と思わせて安心させてしまうことだと考えました。そこで次の4つを構造として組み込みました。

1. 判定に必ずデータ時点を添える

「区域外です」だけを返しません。必ず「判定に使ったデータの時点: 2026-03-06」を一緒に出します。データベースの側にも、出典と時点を記録する表を作りました。時点が記録されていないデータでは、判定そのものを行いません。

2. 近くに区域があるときは言い切らない

これは作ってから気づいたことです。

実際にハザード区域として登録されている住所を6件取り出して判定させたら、5件が「区域外」と出ました。距離を見ると 14m・47m・50m です。

理由は明快で、住所から求まる座標は番地ではなく町丁目のおおよその位置だからです。区域の縁ギリギリの土地では、代表点が外に落ちます。

このまま「区域外」とだけ返していたら、危険な場所を安全だと伝える道具になっていました。250m以内に区域がある場合は、次を必ず出すようにしています。

最も近い区域まで約14mしかありません。住所から求めた座標は町丁目のおおよその位置のため、実際の敷地が区域内である可能性があります。必ず現地の地番で確認してください。

3. 一次情報への導線を必ず返す

判定のたびに「本サービスの判定は参考情報です。公的な証明ではありません」と、自治体の最新ハザードマップを見るよう促す文言を出します。

4. 出典と加工の明記

国土数値情報は公共データ利用規約（PDL1.0）で提供されていて、出典の記載と、編集・加工した場合はその旨の明記が必要です。画面のフッタではなく、判定結果の中に入れています。

技術的に詰まったところ

同じことをやる方のために書いておきます。

国土数値情報のGMLは、GDALで読めません。 ogrinfo はファイルを開けるのにレイヤが0件になります。原因は、データが実体を直接持たず3段階の参照になっていることでした。

gml:Curve（座標を持つ）
  ↑ xlink参照
gml:Surface（面）
  ↑ xlink参照
フィーチャ（区域名・指定年月日などの属性）

ファイル内の並びが Curve → Surface → フィーチャ の順なので、1パスで解決できます。自前のパーサを書きました。

配布zipのパス区切りが \ です。 Linuxで展開すると、ディレクトリにならずファイル名に \ が入ります。メタデータのファイルを名前で探していて、これに引っかかりました。

結果

全国47都道府県・1,793,171区域を収録して公開しました。判定は PostGIS の ST_Contains で、住所の座標変換は国土地理院のAPIです。外部の有料APIは使っていないので、ランニングコストはサーバー代だけです。

自社サーバーに置ける買い切り版もKurage App Storeに出しました。ソースコードと設置手順書を同梱しています。住所を外部に送りたくない不動産・建設の会社向けです。

この記事で伝えたかったこと

作るものを勘で決めない。 技術がうまくいっていても、人が探していない言葉に賭けていたら流入はゼロのままです。半年それをやっていました。

手持ちの部品を数えてから、当てる先を探す。 ゼロから作るより、既にあるものを組み替えるほうが早いし、確実です。今回は判定が半日で動きました。

使えないデータは、使わないと決める。 機能が減っても、間違った安心を与える道具にはしない。これは災害に限らず、会計でも医療でも同じだと思います。

同じような組み替えができる部品が、御社にも眠っているかもしれません。何を持っていて、何に当てられるか。ご相談はお問い合わせからどうぞ。