不明と区域外の区別
「区域外」と「データなし(未収録)」を混同せず、安全と誤解させないための判定設計原則。
定義
ある地点がリスク区域に「入っていない」と判定したとき、それが 本当に区域外なのか、それとも そもそもデータが存在しない(未収録)のか を必ず分けて答えるという設計原則。Kurage の防災系製品群に共通する芯であり、hazard-map-judgment を成立させる前提条件でもある。
なぜ重要か
「区域外」という応答は、利用者にとって「安全」という意味に読み替えられる。しかしデータが未収録の自治体・県で黙って「区域外」と返せば、実際には危険がある土地を安全だと誤認させてしまう。これは判定ツールとしての最悪の故障であり、trust-boundary の観点からも許容できない。
三つの状態を区別する
kurage-products の各製品は、少なくとも次の状態を別々に答え分ける。
| 状態 | 意味 | 応答 |
|---|---|---|
| 区域外 | データは収録済みで、その地点は区域に入らない | 「区域外」と明示(ただし後述の留保付き) |
| 未収録 | その自治体・県のデータを取り込んでいない | 「データが無い」と明示し、安全と言わない |
| 想定不要 | 内陸など、そもそも想定の対象外 | 「対象外」として区域外と区別 |
具体例:kurage-tsunami-map
東京都・福井県・香川県は沿岸があるにもかかわらず、国の津波浸水想定データに未収録である。ここで黙って「区域外」と返すと、海岸沿いの土地が安全であるかのように見えてしまう。本製品は「未収録」「内陸(想定不要)」「区域外」を必ず分けて答える。
具体例:kurage-flood-hazard-map
「未収録と区域外を区別する」ことを設計の芯に掲げ、判定に必ずデータ時点を添える。
具体例:kurage-disaster-risk-area-map
指定のない自治体で黙って「区域外」と答えない。さらに区域外の場合でも「これは建築制限の指定であって、浸水の危険が無いという意味ではない」と明記する。区域外=無危険ではないという第二の区別を扱っている点で踏み込んでいる。
言い切らないという第2の原則
「不明」と「区域外」の区別に加えて、判定精度の限界も明示する。
- kurage-landslide-hazard-map — 住所から求めた座標は町丁目のおおよその位置にすぎない。250m以内に区域があるときは「区域外」と言い切らず、地番での確認を促す(実測で区域の縁から14〜50mずれた例あり)。
- kurage-disaster-risk-area-map — 代表点が区域の近くなら距離を添えて言い切らない。
- kurage-refuge-map — 時点が確認できないデータでは判定しない。市町村ごとに更新時期が違うため、判定結果にその市町村のデータ時点を必ず併記する。
データ時点の明示とセットになる
区域の指定は改正される。整備年度は県・市町村ごとにばらばらである。したがって「区域外」という答えには必ずいつのデータに基づくかを添える。これにより、利用者は「今の指定では区域外」と正しく理解できる。この考え方は evidence-traceability と直結している。
決定論的コードで実装する
この区別は、LLMの推測に任せると簡単に壊れる。モデルは文脈から「たぶん区域外だろう」と補完してしまうためである。そこで deterministic-core の原則に従い、状態の判定と応答の分岐はコードが決定的に処理する。
- 収録範囲(どの自治体・どの県をデータとして持っているか)をコード側のメタデータとして持つ
- 商用利用を認めていない自治体・非公開の自治体はそもそも取り込まない設計とし、その利用条件一覧をコードに持ち、テストで固定する(kurage-disaster-risk-area-map)
- 未収録を「区域外」にフォールバックさせない
関連する設計思想
この原則は、self-contained-php-app や self-hosting の構成でこそ意味を持つ。外部の有料APIに問い合わせる構成では、APIが返す「該当なし」が未収録なのか区域外なのかを区別できないことが多い。データを自社サーバー内に持ち、収録範囲を自分で把握しているからこそ、両者を厳密に分けられる。
関連ページ
- hazard-map-judgment
- deterministic-core
- evidence-traceability
- trust-boundary
- self-contained-php-app
- kurage-platform
- kurage-products
Kurage.AI に質問する
