インフラライフサイクル情報管理研究小委員会

橋梁維持管理データベース構築における課題

インフラ維持管理 ２.０
２０２１年８月５日
株式会社ナップザック

1

目次

◼まえおき
• 自己紹介• 改めてWeb2.0 ～ システム化の重要なファクター◼橋梁維持管理データベース構築における課題• 細かすぎて使われないデータモデル• ユニークではないID• 紙からデータへ• 撤去更新と諸元• データ連携は分散か集中か？
• インフラ維持管理のSociety5.0とは？
2

まえおき

•

自己紹介

•

改めてWeb2.0 ～ システム化の重要なファクター3自己紹介 その１
札幌で小さなシステム開発会社を営んでいます。
東北大学インフラ・マネジメント研究センターで産学連携研究員をしていました。
東北大学では、⚫ 戦略的イノベーション創造プログラム（SIP）、地域実装支援拠点に採択
東北インフラ・マネジメント・プラットフォームの構築と展開
1. 山形県に山形県道路橋梁メンテナンス統合データベースシステム（DBMY）を導入
2. 宮城県建設センターにセンターDIMを導入

補助的な役割です⚫ 東北大との共同研究からインフラDBを開発➢➢➢➢

橋梁管理者（地方自治体）向けの橋梁維持管理データベース
クラウド上に橋梁諸元と定期点検結果を格納
タブレット端末による現場点検とAPI連携
橋梁長寿命化修繕計画を試算する機能立ち上げを支援

現在は完全に退く⚫ 東北大学ビジネス・インキュベーション・プログラム（BIP）を経て、（株）インフラ・ストラクチャーズの立ち上げ
研究題目：インフラ維持管理の本格化に向けてAIを活用した画像処理技術によるひび割れ検出システムの開発と実用化⚫ 官民研究開発投資拡大プログラミング（PRISM）への参画➢ 地方自治体のインフラデータベース整備とAPI連携➢ 国土交通データプラットフォームへのAPI連携

4自己紹介 その２
⚫ 子どもの頃からプログラミングを独学⚫ 大学でさらに情報処理を学ぶ➢ GIS（地理情報システム）が研究テーマ⚫ ソフトウェア開発に従事➢ 中小企業から上場企業まで➢ 制御系からネイティブアプリ、ウェブアプリまで、要件定義から設計・開発・運用まで➢ Web2.0以降はマッシュアップやアジャイル開発など、ウェブアプリ中心⚫ 経産省の情報大航海プロジェクト「Viewサーチ北海道」（2007年）

マッシュアップ部分の実装⚫ 経産省の「IT融合による被災地のインフラ復旧支援とメンテナンス技術拠点の形成・展開」 （2012年）➢ 東北大が拠点。仙台の土木コンサル会社さんに常駐して、橋梁点検業務の業務分析⚫ 独立・起業（2013年）⚫ SIPで、再び東北大へ（2017年）

東北大での取り組み（自己紹介 その1）
5

改めてWeb2.0 ～ システム化の重要なファクター
ティム・オライリー氏が2005年に発表した論文「What Is Web 2.0」で表明された、次世代型ウェブのパラダイムとしてのWeb 2.0
ティム・オライリー氏 ・・・ コンピュータ関連の書籍出版などを手掛けるオライリーメディア社の創業者「○○2.0」が大流行

Web2.0はバズワードだったのか？

昨今では国の方でも「データ連携が重要だ！APIだ！」と言われている
それは IT業界では古典的な技術。新しくも何もない。
Web2.0で言う、☆データは次世代の「インテル・インサイド」

・・・ データベースとクラウド☆モジュール化とゆるやかな結合

・・・ API連携※参考： CNET Japan／Web 2.0ってなんだ？／https://japan.cnet.com/article/20090039/
CNET Japan／ひろゆきがティム・オライリーに直接きいた、「Web2.0ってなんだったの？」／https://japan.cnet.com/article/20361105/

6

Web2.0 ミームマップ（一部抜粋）
技術ではなく態度

プレイ（遊びの要素）

データは次世代の「インテル・インサイド」

ロングテール⚫ パッケージソフトウェアではなくサービス
ユーザー行動の意外性⚫ 参加のアーキテクチャ⚫ 高い拡張性とコスト効率
コンテンツ単位のアドレス特定⚫ 再構成可能なデータソースとデータの変換⚫ 単一デバイスの枠を超えたソフトウェア

再構成する権利＝一部権利保有

ハッキングが可能

リッチなユーザー体験⚫ 集合知の利用

永久にベータ版

モジュール化とゆるやかな結合

利用者が増えるほど改善されるソフトウェア
7橋梁維持管理データベース構築における課題•

細かすぎて使われないデータモデル•

ユニークではないID•

紙からデータへ•撤去更新と諸元•

データ連携は分散か集中か？

•

インフラ維持管理のSociety5.0とは？
8

細かすぎて使われないデータモデル （1）
経産省の「IT融合による被災地のインフラ復旧支援とメンテナンス技術拠点の形成・展開」⚫ データをAPI連携⚫ 大学などの専門家とビデオ会議⚫ 様々な知見の蓄積（マルチメディアDB）

このシステムで構築したデータモデル
構造物データや点検データは、業務で使用している帳票類や実際の構造物の部材構成、点検内容をもとにデータ設計システムの全体イメージ ※１

構造物や業務内容のデータモデルとしては詳細に反映されているが、細かすぎてシステムとしては使いづらい※１ 出典：土木学会第68回年次学術講演会(平成25年9月)／ＩＴ融合による被災地のインフラ復旧支援とメンテナンス技術拠点の形成・展開

9細かすぎて使われないデータモデル （2）インフラDBでは、⚫ 国土交通省の点検要領を満たすデータモデルに簡略化（具体的には点検調書の項目をデータモデル化）⚫ 国管理橋梁の詳細な点検要領と、地方自治体向けの簡易な点検要領のハイブリッド型
ユースケースを想定した
データ設計も重要システムとしての守備範囲が広がった
ケース

対応

例

すべての橋梁に詳細な点検○

宮城県建設センター（市町村）

15m未満は簡易点検のみ○

宮城県

一部橋梁を直営点検○

小さな自治体☆再構成可能なデータソースとデータの変換☆ユーザー行動の意外性・・・ 一部橋梁を直営点検

10

【参考】インフラDBのプラットフォーム構想

11ユニークではないID
橋梁を一意に特定する方法をどのように考えるか？
① 国土交通省が提唱している施設ID⚫ 定期点検対象施設のＩＤ付与に関する参考資料（案）

施設ID（18桁・半角） → 43.18167,141.32556⚫ 緯度経度を利用して符号化したもの（位置情報に対して一意という意味では理に適っている）⚫ 「緯度経度 ＝ ID」の誤解から、点検のたびに異なる緯度経度（ID）が付与され、一意にならないことがあった。

② Excelシート上で付与したIDシステムの内部IDも同等⚫ 県や市町村での ローカルルール （しかし、その上位にIDを付与することでユニークにできる。市町村コードなど）⚫ IDが国・県・市町村・事業者で共通認識されていない。一意にならない。

③ 橋梁名と路線名⚫ 誤字脱字、表記ブレで一意に特定できない。上下線など同一のものも存在。

システム化できないことと同じ橋梁を一意に特定できないことによる弊害① データの移動ができない （システム⇒システム、紙⇒システム）② データ移動のたびに間違いが発生

国・県・市町村・事業者で共通認識されるIDが必要！
☆コンテンツ単位のアドレス特定
12紙からデータへ既存の紙の情報をどのようにデータ化するか？

ExcelやＰＤＦファイルも紙の情報と同等『ゆるいデータ化も決してムダではない』
ケース【タイプⅠ】
ファイル保存（索引情報のみ）

データ化の方法
アナログデータの資料はスキャナを使ってデジタルデータに変換し、索引情報を手入力で割り当てる。
デジタルデータの場合はソフトウェアを使って索引情報を自動抽出できる場合がある。索引情報の割り当て方によっては、プログラムで一括処理が可能。
アナログデータの資料はスキャナを使ってデジタルデータに変換し、OCR（光学的文字認識）をつかってテキスト情報を抽出する。画像形式のデジタルデータについても同様。文字を正しく認識でき【タイプⅡ】
ファイル保存（全文検索対応）

ない場合や誤認識が発生する。その修正には人のチェックと手作業による訂正が必要。
画像形式以外のデジタルデータの場合は、ベンダーなどから提供されているソフトウェアをつかってテキスト情報を抽出する。ファイル形式によっては抽出手段がない場合もある。その場合はOCRをつかって文字認識により抽出する。

【タイプⅢ】
データ構造化

ソフトウェアを使って構造化されたデータを取得できる場合は、個別に抽出プログラムを開発して半自動・一括でデータを取り込む。それ以外の場合は手入力でデータを取り込む。

☆参加のアーキテクチャ

努力と妥協の判断！

☆ロングテール13

撤去更新と諸元運用を進める中で、撤去更新した場合のIDや諸元をどのようにするか課題が上がる
IDをそのまま継続
撤去更新した新しい諸元に書き換えると、過去の点検データとの整合性が壊れる

IDを新たに付与⚫ 点検調書にはない、撤去の情報をデータモデルに追加⚫ 走りながら改善していくスタイル⚫ データ構造のアップデート⚫ ソフトウェアと建築物の違い➢ ソフトウェアはリファクタリング（内部構造の改善）できる。
土台部分にも手を入れる。しかし本質・骨格は重要。ブレない基本設計☆永久にベータ版☆利用者が増えるほど改善されるソフトウェア

14データ連携は分散か集中か？ （1）①システム間で相互にデータ連携（インフラDB）⇒分散型のデータ連携②国土交通データプラットフォーム（現時点）⇒集中型のデータ連携
国交PF

データベース

データベース

API

自治体A

API

API

自治体B自治体C

自治体A

自治体B

データベース

データベース

データベース

データベース15

データ連携は分散か集中か？ （2）③ハブとしてのインフラ連携プラットフォーム⚫ 分散か集中は問わない。すべてのデータ連携を仲介することを重視。

⚫ ネゴシエーションの役割⇒データ流通の監視。国防やサービス化（有料化）への展望

自治体A

データベース

データ流出の抑止
課金モデル
事業者Z

API

インフラ連携プラットフォーム

自治体B

自治体C

データベース

データベース16

インフラ維持管理のSociety5.0とは？

小話的な・・・

長寿命化修繕計画策定機能を開発するときに、高木千太郎先生（当時 東京都道路整備保全公社）にご助言を頂いたことがあります。

『劣化やコストの評価だけではなく、社会的便益も重要！』（以下は私なりの理解です。）⚫ 長寿命化は修繕計画を立てることだけが目的ではなく、管理橋梁一橋一橋の運用状態を把握するものであるべき➢ 標準の劣化予測より劣化が早いのか遅いのか？

➢ その橋梁は必要なのか不要なのか？
➢ SDGs的な言い回しでいうと 「（橋梁を）誰ひとり取り残さない」⚫ データは橋梁管理者（地方自治体）が管理することになる。
役所には担当者の異動がある問題⚫ 異なる事業者でも共通的にデータを利活用できる仕組み⚫ ICT導入をコストセンターからプロフィットセンターへ （利益は自治体へ還元＝社会への還元）⚫ Web2.0 ミームマップの要素を駆使したICT導入（最近の流行ワードで言えば、『DX』？）☆ハッキングが可能☆再構成する権利 ＝ 一部権利保有
17札幌景観色 9-A 水晶白（クリスタルホワイト）が塗装された上白石橋 https://sapporocolor.jp/

ご清聴ありがとうございました