はじめに

上下水道業界で管路台帳システム(GIS)の運用に携わっている実務者です。

前回の記事の最後で、国総研が災害時の管路台帳データ交換の形式に GeoPackage を指定した話に触れました。今回はその一次資料 — 「地震対応における下水道管路データ交換標準仕様書(素案)」(国総研、令和 8 年(2026 年)3 月) — を、台帳データを扱う実務者の目線で通読して解説します。

なぜ今読むかというと、この素案はまさに今、自治体・台帳システムベンダー・災害支援企業への意見照会が行われている最中だからです(民間企業向けの提出期限は 2026 年 8 月 26 日 17 時)。関係者なら「意見を出せる側」として、そうでなくても「下水道×GIS の標準がどこへ向かうか」の定点として、読む価値のある文書です。

この記事の要点

令和 6 年能登半島地震で、被災自治体の台帳データが支援自治体に渡るまでに時間を要し、発災後の調査に大きな影響が出ました。加えて、台帳システム間のデータ交換には文字化け等のエラー解消に時間を要するという以前からの課題があります。この 2 つを受けて、災害時専用のデータ交換標準の素案が公開されました(平時の台帳やオープンデータの作り方を変えるものではありません)。
配布形式は OGC GeoPackage(.gpkg)・文字コード UTF-8。選定理由の 4 要件は、そのまま shapefile の制約の裏返しになっています。
設計思想は徹底した割り切り。必須項目は最小限・厳密な正確度は求めない・メタデータは作らない。
意見照会が進行中(民間企業向けは 2026 年 8 月 26 日まで)。運用開始は令和 9 年度以降の予定です。

形式の話だけ読みたい方は「なぜ GeoPackage なのか」の節へどうぞ。

掲載ページ(仕様書本体・説明資料・意見照会資料): https://www.nilim.go.jp/lab/ebg/jishin_dataexchange.html

お断り: 本記事は公開資料の紹介・解説です。対象は「素案」であり、意見照会の結果を受けて内容が変わる可能性があります。引用は仕様書本体と説明資料を区別して示します。

何があったのか — 能登半島地震の教訓

出発点は令和 6 年能登半島地震です。掲載ページの説明によれば、被災自治体が保有する管路台帳データを支援自治体に提供するまでに時間を要し、発災後の調査に大きな影響が生じたとのこと。各自治体の台帳システムは既存の標準仕様(日本下水道協会)に基づいて構築されていて相互利用も想定されているのですが、「災害時等の時間的猶予がない状況下におけるデータ交換には課題があります。例えば、文字化けの発生等のエラーを解消するのに時間を要する等」— と、文字化けが名指しされています。

説明資料(Part1)には現場の困りごとがさらに具体的に並びます。「調査開始までに支援自治体が台帳を入手出来ない」「土地勘のない場所で現在地や人孔の位置の把握に苦労」(人孔 = マンホール)「紙の応急復旧調査表に手書き入力」「夜間に膨大な転記作業」。災害対応の律速が、データの受け渡しと転記だったわけです。

国総研はこの改善を 2 段階に分けています。すぐできる改善(調査表の簡略化・デジタル化など)がフェーズ 1、時間のかかる DX がフェーズ 2 — 今回の交換標準仕様はフェーズ 2 の成果物です。後で見るデータ項目の定義を読んでいくと、現地で調査に当たった方々が紙に書いていた内容が、そのまま項目として落とし込まれていることが分かります。

この文書は「何を決めて、何を決めない」のか

仕様書本体の適用範囲は明快です:

本データ交換標準仕様書は、大規模地震発生時における下水道管路の復旧対応の判断及び災害査定に引き継ぐことを目的として、関係者間で授受されるデータの構造及び内容を定める。(仕様書 p.5)

(災害査定 = 被災した施設の復旧費に国庫負担を付けるための国の審査のこと)

つまり災害時(地震対応)専用の交換仕様であり、平時の台帳やオープンデータの作り方を変えるものではありません。ここは誇張せず正確に押さえたいところです。

そして設計の基本方針が面白い。既存の台帳データを「作り替える」のではなく、地震対応に必要なデータだけを交換仕様に「変換」するという割り切りです(説明資料 Part1)。全自治体の台帳データを統一するのは費用・時間・ランニングコストの面で困難なので、交換するデータの構造だけを「協調領域」として厳密に統一し、変換機能の実装は各ベンダーの「競争領域」に委ねる — 既存の台帳標準仕様(日本下水道協会「下水道台帳管理システム標準仕様(案)・導入の手引き Ver.5」。多くの自治体の台帳システムがこれに基づいて構築されています。以下 Ver.5)を置き換えるのではなく補完する関係だと説明されています。

誰と誰の間でデータが行き来するのかを図にすると、こうなります。

説明資料が挙げるメリットも、この図のとおりです。支援自治体は使い慣れた自分の台帳システムに被災自治体のデータを取り込んで使える。現地の調査結果を本庁側で集約すれば、GIS 等の知見のある職員がいなくても高度な活用ができ、本庁から後方支援に回せる。そして支援自治体が交代しても、統一されたデータ形式のまま次のチームへ引き継げるので、調査済みの範囲や結果の伝達漏れを防げる、というわけです。

中身の骨格 — 5 つのパッケージと 2 つのキー

データモデルは 5 つのパッケージで構成されます。

パッケージ	中身	位置づけ
①下水道管路	マンホール・管きょ・公共ます・取付け管	平時から持っている台帳データ(事前準備可能)
②調査	調査 ID・対応種別・調査日・調査自治体・被災自治体	発災後に発生
③施設障害	各段階の調査で見つかった被害の記録	発災後に随時更新
④現地確認	現地確認の記録	参考情報(発災後)
⑤地震防災マップ	防災関連の重要施設等の地図情報	参考情報(事前準備＋発災後)

(公共ます = 宅地と道路の境界付近に設ける桝、取付け管 = そこから本管につなぐ管です。なお本記事では仕様書の表記に合わせて「管きょ」と書きます — 過去記事の「管渠」と同じものです)

③の施設障害は、災害対応の進行に合わせて 6 段階のサブパッケージに分かれています。

発災 → 緊急点検(二次災害の防止)→ 緊急調査 → 緊急措置 → 応急復旧調査 → 応急復旧 → 本復旧調査(査定資料の作成)

(仕様書 pp.13-18 のサブパッケージ構成と p.31「対応種別フラグ」のコードリストより筆者作成)

パッケージ同士をつなぐのは 施設番号(どの施設か)と 調査 ID(いつ・誰が・何の調査をしたか)の 2 つのキーだけです(説明資料では「施設 ID」とも呼ばれています)。

そして調査クラスには「調査自治体」と「被災自治体」が別属性で定義されています(仕様書 p.30)。応援に入った自治体が調査した記録を、被災自治体のデータとして引き継ぐ — 支援・受援の構図がデータモデルに直接埋め込まれているのが、この仕様の性格をよく表しています。

各段階のデータは最終的に災害査定の資料作成へ引き継ぐことが明記されており、現場の調査記録を査定資料の作成へそのまま渡せる流れを作ろうとしています(査定設計書の作成そのものを代替するものではありません)。

設計思想は徹底した「割り切り」— 必須項目もメタデータも最小限

台帳の仕様書は普通「あれも記録、これも必須」と要求が増えがちですが、この素案は逆方向に徹底しています。

必須項目は最小限。下水道管路側で必須なのは位置・形状と施設番号くらいで、他はほぼ任意です(例外として、排水区域名称と処理区域名称は「どちらか必ず入力すること」とされています)。自治体ごとにデータの有無が違う現実を「Null 値(値が存在しない)の許容で解消」すると説明資料に明記されています。極端な例が取付け管で、定義されている属性は形状だけ。施設番号すらありません。
品質要求も最小限。「厳密な位置正確度や主題正確度の評価は求めない」(仕様書 p.69)と明言し、要求は調査 ID・施設番号の関連付けとコードリスト値の遵守など、機械的に検査できる項目だけです。
メタデータは作らない。JPGIS(地理情報標準プロファイル。国内で地理空間データの仕様書を書くときの共通の型)流の製品仕様書の体裁を取りながら、「JPGIS に基づくメタデータの作成は想定しない」(仕様書 p.70)と宣言しています。作成主体や時期はメタデータではなく調査パッケージのデータ本体に持たせる設計です。
管路データのコードリスト(仕様書 pp.24-29)には、ほとんどの項目に「88 その他」「99 不明」が用意され、「分からない」を分からないまま記録して先へ進めるようになっています(「対象/対象外」の 2 値だけの項目のような例外もあります。施設障害側のコードでも「不明」の選択肢が用意されています)。

一貫しているのは「正確さより、すぐ渡せること」。災害時の仕様として何を対象外とするかが明確で、データ仕様の設計例として読んでも勉強になります。

なぜ GeoPackage なのか

仕様書本体の規定は、実は箇条書き 3 行だけです。

ファイル形式: OGC GeoPackage
拡張子: .gpkg
文字コード: UTF-8

(仕様書 p.70「7-1. 配布書式情報」)

選定理由は説明資料(Part1)側にあります。求められる要件として挙げられた 4 点は、前回の記事で扱った shapefile の制約と、きれいに対応しています。

求められた要件(説明資料 Part1)	裏返しになっている shapefile の制約(筆者の整理)
単一ファイルで完結し、構成ファイルの欠落による「開けない」を防ぐ	.shp/.shx/.dbf などの複数ファイル構成
文字コード(UTF-8 など)を厳格に定義でき、文字化けを防ぐ	文字コードの宣言方法が shapefile の仕様として標準化されておらず、.cpg ファイルや .dbf ヘッダの言語ドライバー ID といった事実上の慣習に依存
属性フィールド名の文字数やファイル容量の制限がない	フィールド名 10 文字・各ファイル 2GB
特定企業の独自技術に依存しないオープンな国際標準規格	特定企業由来のフォーマット

念のため補足すると、同じ説明資料の比較表は shapefile を「デファクトスタンダードとして、ほぼ全ての GIS で取扱い可能」「互換性の面で安心感がある」とも評価した上で、GeoPackage を「次世代の標準」と位置づけています(GML や GeoJSON との比較も併記されています)。Ver.5 が shapefile を採用したこと自体は当時として合理的で、災害時の交換という用途に限れば 4 要件が GeoPackage を指す、という整理です。掲載ページや説明資料が名指しする「文字化け」への答えが UTF-8 必須の単一ファイル形式だった、という流れは実務者として腑に落ちるものがあります。

ちなみに GeoPackage は特別なツールがなくても扱えます。QGIS はそのまま開けますし、Python なら:

import geopandas as gpd
from pyogrio import list_layers

# レイヤ名・項目名は「仕様書で定められた」ものに統一される想定(国総研 FAQ No.2)。
# とはいえ受け取った .gpkg は、まず中身の一覧を取るのが確実です
layers = list_layers("exchange_data.gpkg")
print(layers)          # [['レイヤ名', 'LineString'], ...]

gdf = gpd.read_file("exchange_data.gpkg", layer=layers[0][0])

実務者にとって何が変わるか

台帳システムに「変換機能」が載る。説明資料によれば、クラウド型の台帳はベンダー対応で自動的に利用可能になり、オンプレミス型はバージョンアップで対応、独自開発、またはパッケージに独自カスタマイズを加えている自治体は、コストをかけて自前で変換機能を追加する必要があるとされています。ただしこれは「対応するなら」の話で、導入そのものは任意です。国総研は FAQ で「本仕様書の導入は任意であり、各自治体の判断となります」(No.8)、「必須ではありません」(No.10)と明言しています。一方で同 No.9・No.11 では、日本下水道協会が定めている下水道管路台帳の標準仕様 Ver.5 が「Ver.6」へ改定される際に、この交換標準を仕様の一部として組み込む方向で調整を進めているとされています(No.9 は「ただし、変換機能自体が不要になるわけではありません」とも付け加えています)。そして No.10 は、その改定後は「新システム導入時の標準仕様となっていく想定です」と続けています。任意のうちに備えるか、標準に取り込まれてから動くか、という話になりそうです。
平時の準備が問われる。下水道管路パッケージは発災前から準備できる区分に置かれています。発災してから慌てるのではなく、平時から交換仕様に変換できる状態にしておくことが想定されており、台帳データの整備・品質がそのまま災害対応力になる構図です。
施設番号の付番ルールが論点になる。意見照会では各自治体の施設番号の桁数・文字種まで確認されています。自治体ごとにバラバラな付番が相互運用の急所だと国総研が見ている、ということです。
背景地図は交換の対象外。意見照会資料には、地図は GIS に組み込まれた一般の地図や国土地理院の公開地図を使う想定で、市販地図のような著作物も、オープンデータとして公開されているデータも交換できないと明記されています。背景図を含めて一式渡す、という発想ではありません。
座標参照系は「日本測地系 2024 における緯度経度座標系」、標高は東京湾平均海面(T.P.)基準(仕様書 p.68)。台帳実務で馴染みのある平面直角座標系ではなく緯度経度が指定されている点は、変換を実装する側にとって最初の分岐点になりそうです。

なお、素案本体に「GeoPackage のテーブル名・カラム名の一覧」という形の規定表はありません。ただしこれは「決まっていない」という意味ではないようです。国総研は意見照会ページで公開しているよく寄せられる質問への回答(2026 年 8 月 10 日掲載)の No.2 で、GeoPackage 形式だけでなくレイヤ名・テーブル名・項目名・項目型・文字数・必須/任意・Null の扱い・ジオメトリ型まで固定されるのか、という自治体からの質問に対し、「データ交換標準仕様に基づき変換するデータは、仕様書で定められたレイヤ名、項目名、型、属性定義等に統一します」と回答しています。つまり、応用スキーマ文書(仕様書 pp.20-67)の地物名・属性名がそのままレイヤ名・項目名になる、という読み方になります。

素案らしい箇所としては、たとえばマンホール蓋種別のコード値は Ver.5 に該当項目がないため仮に割り当てた上で、管路協(下水道管路の管理業者団体)への確認結果を反映すると注記されています(仕様書 p.21)。こうした調整中の箇所が明示されているのも、素案段階の文書の読みどころです。

今後のスケジュール

公開されている工程表によれば、次の順で固まっていく予定です。文書としては「素案」(意見照会にかける段階)→「案」(委員会審議を経て公表する段階)という順序で、工程表では「(案)」の公表の次が運用開始になっています。

時期	内容
2026 年 7〜8 月(令和 8 年)	意見照会
2026 年 9〜12 月	必要に応じてヒアリング
2027 年 1 月頃	意見を素案に反映
2027 年 2 月頃	委員会審議
2027 年 3 月まで(令和 8 年度内目途)	「(案)」公表
2027 年 4 月以降(令和 9 年度以降)	運用開始

意見照会に出すなら

意見照会の対象は自治体と台帳システムを提供するベンダーだけではありません。掲載ページには「自治体及び下水道台帳システムを提供するベンダーや地震対応における災害支援に携わる民間企業を対象に意見照会を実施中」とあり、企業向けの設問でも回答者の立場が「提供者(ベンダー)」と「利用者(調査や計画業務等で自社又は他社製品を利用)」の 2 択になっています。調査・計画業務でシステムを使う側も回答対象に含まれる建て付けです。自治体向けの資料にも、台帳管理を委託している企業や包括業務委託先へ調査票を共有して相談してよい旨が案内されています(ただし回答は「自治体」の立場で、との但し書き付きです)。

設問は 11 問で、論点が明示されています。施設番号の付番ルール(桁数・文字種)、GeoPackage 形式によるデータ交換の運用上の課題、全体を通した課題・要望など、この記事で扱った話がそのまま設問になっています。提出は調査要領に記載された URL から入力する方式で、民間企業向けの提出期限は 2026 年 8 月 26 日(水)17 時です。

資料一式・提出方法: https://www.nilim.go.jp/lab/ebg/jishin_dataexchange.html

まとめ

能登半島地震で台帳データが支援自治体に渡るまでに時間を要したこと、そして台帳システム間のデータ交換に文字化け等のエラーという従来からの課題があることから、災害時専用のデータ交換標準(素案)が生まれました。
設計思想は徹底した割り切り: 作り替えず変換する・必須は最小限・正確さより速さ・メタデータは作らない。
配布形式は OGC GeoPackage(.gpkg・UTF-8)。選定 4 要件は shapefile の制約の裏返しで、国の資料でも既存標準(Ver.5 = shapefile 採用)と対比して GeoPackage が「次世代の標準」と位置づけられました。ただし Ver.5 を置き換えるものではなく、災害時対応を補完する位置づけです。
まだ「素案」であり意見照会が進行中(民間企業向けの提出期限は 8/26)。台帳データの整備が災害対応力に直結する時代が、工程表付きで近づいています。

関連記事: 上下水道×データの記事は一覧からどうぞ。コードは GitHub で公開しています。

免責・出典

本記事は公開資料の紹介・解説であり、引用部を除く見解は筆者個人のものです。対象は素案段階の文書であり、今後変更される可能性があります。
出典: 国土技術政策総合研究所「地震対応における下水道管路データ交換標準仕様書(素案)」(令和 8 年 3 月)および同説明資料・意見照会資料 https://www.nilim.go.jp/lab/ebg/jishin_dataexchange.html
GeoPackage は OGC(Open Geospatial Consortium)の標準です: https://www.ogc.org/standards/geopackage/