Slide 1
Slide 1 text
＜不動産データの整備と活用＞
お部屋探しの
マスターデータマネジメントと
活用を考えよう
1
Slide 2
Slide 2 text
300
イタンジのDX推進への取り組みは、
DX銘柄2022の選定を通じて評価されてい
ます。(3年連続)
2023年1月末
2
Slide 3
Slide 3 text
3
Slide 4
Slide 4 text
4
Slide 5
Slide 5 text
5
Slide 6
Slide 6 text
6
Slide 7
Slide 7 text
7
Slide 8
Slide 8 text
8
Slide 9
Slide 9 text
イタンジの情報は、Twitterをフォローお願いします✨
公式アカウント
9
Biz・PR・HRアカ
ウント
Slide 10
Slide 10 text
不動産業界のデータの"負"と向き合おう！
10
2023.06.26
AI Strategy Center General Manager
電気通信大学 客員准教授
滋賀大学データサイエンス学部 インダストリアルアドバイザー
橋本 武彦
Slide 11
Slide 11 text
Introduction：最近、”住所”が話題ですね、、、
11
出典：とにかく日本の住所のヤバさをもっと知るべきだと思います
https://note.com/inuro/n/n7ec7cf15cf9c
出典：日本の住所の正規化に本気で取り組んでみたら大変すぎて鼻血
が出た
https://qiita.com/miya0001/items/598070abcdf0799daebc
Slide 12
Slide 12 text
たしかにヤバい・・・
12
● 表記ゆれ： ex.港区六本木3ｰ2ｰ1
○ 3丁目2番1号、3-2,1、3丁目2-1、3番
地2-1、3丁目2 1号室
● 京都の通り名
○ 京都府京都市中京区御幸町通三条下
る海老屋町･･･ *ごごまちどおり
● 字、地番、条、etc
○ 地番住所
○ 数字でない番地、etc
※出典：NAVITIME_Tech
https://note.com/navitime_tech/n/ne71603fe4bf8
Slide 13
Slide 13 text
本日、お伝えしたいこと
13
● 住所や物件名の正規化や名寄せ
● 商品特性ゆえに圧倒的に少ないデータ量
● 業界的に低いデータ品質、etc
○ 2017年以降不動産業界のデータの”負”と向き合ってきました。そん
な経験が、もしかしたらDX界隈で戦っているみなさまの 参考になる
のでは？
Slide 14
Slide 14 text
P08 不動産業界のデータのツラミ
P13 MDMからのアプローチ
P20 不動産IDへの期待
Contents
Slide 15
Slide 15 text
自己紹介
15
氏名 橋本 武彦（はしもと たけひこ）
所属
GA technologies AI Strategy Center General Manager
電気通信大学 客員准教授
滋賀大学データサイエンス学部 インダストリアルアドバイザー
国土交通省 不動産IDルール検討会 構成員（令和 3年度）
キャリア
サマリ
• Sier（エンジニア5年/研究員2年） ⇒ 調査会社（リサーチャー 3年）
⇒ ブレインパッド（シニアデータサイエンティスト 9年）を経て2017
年4月から現職にてAISCの立ち上げに参画（当初は新卒含め 3
名、現20名体制）
• データサイエンティスト協会（元事務局長）やデータサイエンティス
ト育成の新規事業の立ち上げ
• 大学や官公庁での講義や執筆、 不動産とAIコミュニティ運営など
E-Mail [email protected]
Socialｱｶｳﾝ
ﾄ
https://www.facebook.com/hashimoto.takehikko
2019/11/23@電通大 研究室
2021/05/26@新丸子自宅
Slide 16
Slide 16 text
P08 不動産業界のデータのツラミ
P13 MDMからのアプローチ
P20 不動産IDへの期待
Contents
Slide 17
Slide 17 text
不動産業界のデータはツライ？
17
Yes！！！
Because…
Slide 18
Slide 18 text
18
ツライ①物件の名寄せ
● 物件をIDでなく、物件名で管理
○ 表記ゆれや転記ミスが増幅 し
やすい仕組み
○ システムで連携困難（≒要 人手
での名寄せや前処理）
※出典：不動産取引データベースの網羅性向上を目的とした不動産募集広告情報のレコード同定（情報
処理学会誌）
https://www.jstage.jst.go.jp/article/pjsai/JSAI2021/0/JSAI2021_4F3GS10n03/_pdf/-char/ja
Slide 19
Slide 19 text
ツライ②：データ量が少ない！
19
商品特性に起因
● 同一の物件は存在しない
● 超高額商品ゆえに、取引回数が少
ない（= データ量が少ない）
Slide 20
Slide 20 text
ツライ③：データの質が低い
20
商品特性に起因 業界特性に起因
● 同一の物件は存在しない
● 超高額商品ゆえに、取引回数が少
ない（= データ量が少ない）
● IT化の遅れ（紙・FAX）
● デジタルだけでなく、内見など
のリアルが介在（X-Tech）
○ 人手での入力データ主体
Slide 21
Slide 21 text
不動産業界のデータはツライ？
21
Yes！！！
But we keep on fighting…
Slide 22
Slide 22 text
P08 不動産業界のデータのツラミ
P13 MDMからのアプローチ
P20 不動産IDへの期待
Contents
Slide 23
Slide 23 text
GA technologiesの不都合な現状 *2020年経営会議資料より
23
物件情報
GAのシステム/サービス
RENOSY
SUPPLIER / MANAGE
Lifedesigner
各グループ企業
Modern Standard
神居秒算
パートナーズ
・・・
建物マスタ
名寄せ 正確な情報
物件情報の追加・更新
機能してない or
各サービスが独自で開発
Slide 24
Slide 24 text
MDM（マスターデータマネジメント）とは
24
MDM（通称：マスターデータ管理）は、
Master Data Managementの略で、ITにおいて使用されるマスターデータの管理を行う
ための手法またはそれを実現する
ソフトウェア製品である。
概要[編集]
● マスターデータとは、一般的に企業が社内や業務に構築する際の、
データベースであり、共通となる基本的な情報で
代表的なものには「商品」「顧客」「単価」「社員」「取引先」など多岐にわたる。マスターデータ管理とはその情報を管
理する手法である。
背景と意義[編集]
通常マスターデータは個々の情報管理
アプリケーション内で定義されるが、マスターデータが適切に管理されていない場合や、
複数の情報管理システムで同じマスターデータを使用する場合には、
マスターデータ間の整合性が保たれない、または重複が
存在するという事態が発生しうる。マスターデータの重複や
不整合は、そのマスターデータと関連するデータが検索・
同定できな
くなる、といった不都合を生むため
、マスターデータ自体を管理する必要から
MDMという概念が生まれている。
・・・
出典: フリー百科事典『ウィキペディア（
Wikipedia）』
Slide 25
Slide 25 text
MDMから目指す世界（GA technologiesの建物データ基盤）
25
建物基盤
BLDG：棟
ROOMS：部屋
RENT/BUYSELL：取引
FILES：ファイル エリア関連
PEOPLE
SUPPLIER
MANAGE
AGNT/INSIGHT/OWNR
RENOSY
AGNT2
神居秒算
Partners（Salesforce）
たてかんサポート
ITANDI *参照のみ
REINS,Suumo,homes,athome
社内向けシステム
Renosy
(社外向けサービス)
GA_Group企業の
システム
提携・購入データ
建物のデータを粒度を揃えID連携しGroup内で共有
● 特徴：強力な名寄せ ＋ 自動と人力での継続クレンジング ＋ データの網羅性と正確性
● 成果：効率化/コスト削減、データ活用施策の加速、（名寄せAPI外販）
Slide 26
Slide 26 text
ID連携に向けて：①住所正規化
26
● 住所の正規化APIを開発（Elasticsearch）。大量利用向けに並列処理版も開発
○ 背景 ：153万件／月の処理に255時間
○ 効果 ：500並列で処理時間が99%減（255時間⇒2.9時間）
東京都港区六本木1-2-3
港区六本木一丁目2-3
港区六本木1丁目2番3号
住所: 東京都港区六本木1丁目2-3
緯度：35.665061
経度：139.740792
正規化後名称
● 不要文字削除
● 住所変換
● 都道府県補正
● 数字・漢数字変換
正規化処理
Slide 27
Slide 27 text
ID連携に向けて：②建物名寄せ
27
● 建物名寄せAPIを開発
○ 背景 ：ノイズなどによる低精度
■ 「駅徒歩２分の好立地！セザール御嶽山」、【上質リノベ ×防
音室付×角部屋】駅６分の好立地 ♪シュロス田園調布南、 etc
○ 対応 ：各種辞書の地道な拡充
建物名: 六本木マンション 101
建物名: roppongi mansion(3F)
建物名:六本木マンシヨン
建物名: 六本木マンション
正規化後名称
● 英語カタカナ変換
● 不要文字削除
● 数字・漢数字変換
● ブランド補正
正規化処理
Slide 28
Slide 28 text
ID連携に向けて：②建物名寄せ
28
● 最終的にはAPI ＋ ルール ＋ 目視の併用で、限りなく 100%へ！
○ ルール
■ 物件名、住所の正規化名称の比較
● 部分一致の場合、他ルール併用で判定
■ 他の定量項目の利用（築年、階建て）
● 他ルールと併用で一定の誤差許容
○ 目視
■ ルールで判別困難な場合に利用
■ 目視でも確証が得られない場合もあり、、、
● データに信頼度をつけて管理
● （New）Chat-GPTも色々試用
○ 正規化後のさらなる処理（ ”物件名”の抽出）に効果
○ プロンプトの工夫（教示）、 temperature指定、etc
名寄せ作業の流れ（抜粋）
Slide 29
Slide 29 text
P08 不動産業界のデータのツラミ
P13 MDMからのアプローチ
P20 不動産IDへの期待
Contents
Slide 30
Slide 30 text
不動産ID（BR）への期待
30
大いに期待しています！
不動産IDとは？（国土交通省）
● 住居表示の表記ゆれや同一住所上に複数物件が存在する等により、物件情報の照合、データ連携が難しいとの課題。物
件を一意に特定し、関連情報の連携・活用を促進するため、令和４年３月、国土交通省にて「不動産IDルールガイドライン」
を策定。
● 「不動産ID」は、不動産登記簿の「不動産番号」を基本に、同番号だけで特定できない場合にも対応できるよう「特定コード」
を加えた17桁の番号で構成される。
BR（ベース・レジストリ）とは？（デジタル庁）
● 行政又は民間におけるサービスの共通基盤として利活用すべき又は可能なものであって、公的機関等が正当な権限に基
づいて収集し、正確性や完全性等の観点から信頼できる情報を元にした、最新性、標準適合性、可用性等の品質を満た
すデータ群
Slide 31
Slide 31 text
ベース・レジストリ整備のメリット
31
● 正確な情報公開
● 効率化、添付や申
請の省略、他との
掛け合わせによる
価値創造
※出典：不動産ID官民連携協議会 協議会資料（デジタル庁）
https://www.mlit.go.jp/tochi_fudousan_kensetsugyo/content/001613870.pdf
Slide 32
Slide 32 text
※出典：不動産ID官民連携協議会 協議会資料（国土交通省）
https://www.mlit.go.jp/tochi_fudousan_kensetsugyo/content/001613636.pdf
不動産IDが他産業への架け橋に
32
● 不動産ID官民連携協議会に251会員
が参画
○ 半数が不動産業界以外
○ ex.建設、物流、金融、保険、
警備、小売、etc
● 2028年〜本格普及
Slide 33
Slide 33 text
先行例：法務省 登記所備付地図（XML）データ 無償公開
33
● 2023/1に「登記所備付地図」データを法務省が無償公開。有志の様々なツールや Appが公開され、界隈
を賑わす
● AISCでも住所⇔地番変換を実施、任意座標系の問題もあり一部だが効率化に貢献。 空間検索できる環
境を提供準備中（AWS Athena）
青丸：自社の住所マスタ *緯度・経度あり
赤丸：法務省データ
● 緯度経度をもとにpolygonを空間検索
● 任意座標系に関しては画像処理などを
用いた研究を計画
例．住所と地番の変換（世田谷区若林）
Slide 34
Slide 34 text
まとめ：本日、お伝えしたかったこと
34
● 不動産データは”ツライ”
● けれど大きな未開の可能性（技術 + 根性
+ 不動産ID）
○ 不動産に閉じないデータ活用の道が拓けてきました ぜひ一
緒にフロンティアの苦労・楽しみを味わいましょう！
■ ドアtoドア 検索（Ilinさん）
■ 賃貸 × リアルタイムDB（ITANDI）
Slide 35
Slide 35 text
ドアtoドアのプロトタイプ紹介
Ilin Viacheslav
AI Strategy Center
Slide 36
Slide 36 text
背景
36
● 知名度の低い地域の物件に対して
○ 立地のアクセスが物件の魅力の大きな要素
○ アクセスを評価するには
■ 大企業事業所までのアクセス
● 大企業社員向け
■ 大学までのアクセス
● 大学生向け
アクセスのいい物件は投資対象になる
● 地理空間データをアプリケーションに使う
○ 会社、大学の位置
○ 歩ける道の細かいネットワーク
○ 電車駅のネットワーク
Slide 37
Slide 37 text
アプリケーションデモ
37
● 住所/位置を選択
● 駅が表示されます
○ 歩ける範囲の駅、電車線
○ 駅までの最短ルート
○ ルートの徒歩分数
● 電車を利用してアクセスできる 大
企業、大学を表示
○ 駅までの徒歩分数
○ 電車の時間
○ 乗車、降車駅
○ 降車してからの徒歩分数
Slide 38
Slide 38 text
アプリケーションデモ: 駅までの徒歩分数、ルート
38
Slide 39
Slide 39 text
アプリケーションデモ:アクセス
39
大企業の所在地までアクセス分数 大学までのアクセス分数
Slide 40
Slide 40 text
1) 道をデータで表現する
2) AからBまで徒歩、電車を利用してパスの探し方
3) クラウド上で地理空間データの扱い
目次
Slide 41
Slide 41 text
構造
41
徒歩ネットワーク
大企業、大学情報
電車ネットワーク
クラウドでデータ処理
ルート検索
地図で表示
Slide 42
Slide 42 text
1) 道をデータで表現する
2) AからBまで徒歩、電車を利用してパスの探し方
3) クラウド上で地理空間データの扱い
目次
Slide 43
Slide 43 text
ネットワーク
43
● ネットワークは、グラフともいう
● グラフの点を頂点（ノード）という
● その頂点を繋ぐものを 辺（エッジ）という
● 頂点から頂点までの連続道を パスという
1
2
4
3
1↔2辺(エッジ)
頂点 (ノード)1
頂点 (ノード) 2
Slide 44
Slide 44 text
地理的なデータオブジェクト
44
点
(x, y)
(x
1
, y
1
)
(x
2
, y
2
)
(x
3
, y
3
)
(x
4
, y
4
)
● グラフの概要の頂点・辺が形状を持たず、連続性だ
けを記載する抽象的なものです。
● しかし、実際の道を記載するには、少なくとも点と線
が必要です。
複数の点を繋ぐ直線分からなる。
線
Slide 45
Slide 45 text
道ネットワーク
45
● 頂点
○ 道の交差点
○ 駅
○ 建物
● 辺
○ 道
○ 電車駅の乗換
注意：
道から道に移動が出来ない所には、
頂点がありません。
この場合、一つの道が地下にあります。
Slide 46
Slide 46 text
オープンデータ
https://www.openstreetmap.org/#map=15/35.6815/139.6736
46
● OSM(OpenStreetMap)データ
○ ユーザー入力地理空間データ
● OSMデータ構造
○ 各オブジェクトが点の集合である
■ 道（線）
■ 建物（多辺形）
○ オブジェクトの種類をタグにより分裂
されます
○ 同じ点が複数オブジェクトに所属する
ことが可能です
Slide 47
Slide 47 text
オープンデータ処理
47
● OSMデータからネットワークを作るには
○ タグによってフィルタリング
○ 点の集合を取得
○ 直線分に分ける
○ 行さする点を頂点とし、その他の線分
を合併して辺とする
● ユーザー入力データなので、データク
リーニングが重要。例えば：
○ 道のタグですが、点の集合は一
点だけ。
○ スタート・エンドポイントの IDが同
じ。
● 長さ０の線分に置き換える。
● グラフとして無意味ですが、長さがあるとまと
もな道です。(リングロード） 形を変
えずに二つの道に分ける。
Slide 48
Slide 48 text
ここまで
48
48
徒歩ネットワーク
細かい徒歩ネットワークを取得しました！
どのように、このネットワークを使って徒歩分数を求
めますか？
Slide 49
Slide 49 text
1) 道をデータで表現する
2) AからBまで徒歩、電車を利用してパスの探し方
3) クラウド上で地理空間データの扱い
目次
Slide 50
Slide 50 text
ネットワークの最短パス
図: 新宿空の複雑な道ネットワーク。
ポイントからポイントまでの最短道が緑色になっていま
す。
50
● グラフ辺には重みを付ける。
○ 重みが、その辺の負担と考えられる。
○ この場合で、最短距離検索なら、重みは距離と
する。
● Dijkstraのアルゴリズムを使って、 ポイントAからポイン
トBまで、重さを最小限にするルートを探す
Slide 51
Slide 51 text
電車ネットワーク
51
● 電車ネットワークの構造
○ 電車の駅を頂点とする
○ 駅の間のを辺とする
○ 追加で駅の間の乗換も辺とする
● エッジ重みを時間に
○ 電車線の形がOSMから取得しにくい
○ 電車線の形を分かっても、移動時間が距離に依存し
ない（停止信号、電車の速度不定ため）
○ 結果、電車ネットワークは地理的線を持たず、距離が
無意味です。
○ ネットワークの重みを時間とする
２分
5分
8分
3分
乗換4分
3分
4分
２分
6分
Slide 52
Slide 52 text
電車ネットワークの工夫
52
● 電車ネットワークを徒歩ネットワークにつなぐ
○ 電車ネットワークが駅から始まる
○ 駅は大きい建物の中にいて、複雑な地下の歩道に繋ぐ
○ そのため、駅に繋ぐ 駅の入口が必要
● 電車駅への入口
○ 入口は歩道ネットワークの 頂点である
○ 駅は歩道ネットワーク・電車ネットワーク、 両方の 頂点
である
● 入口のデータをオープンデータの本で作り、大きくデータクリー
ニングが必要でした。
○ 大量の入口を追加しました。
図: 広尾駅の駅入口が緑色。
広尾駅自体が赤色。駅が地下 なの
で、直接道から入れません。
Slide 53
Slide 53 text
電車ネットワークの工夫（続き）
53
● しかし！
○ 電車降車駅を検索する前（最短パス検索す
る前）に分かりません。
○ 電車降車駅を知らないと、そのエリアの徒
歩ネットワークを取得出来ません。
● 解決策：
○ 到着地が大企業、大学であるため、徒歩
ネットワークを使って、その大企業、大学か
ら周りの駅までのルート、徒歩分数を事前
に計算し、電車ネットワークとともに保存す
る。
図: 電車ネットワークと
大学までの徒歩道
Slide 54
Slide 54 text
ここまで
54
徒歩ネットワーク
大企業、大学情報
電車ネットワーク
ルート検索
ネットワークデータを取得して、ドア toドアの道を検索
することが出来ます。
そして、大企業、大学の所在地がネットワークに含
む。
しかし、アプリケーションする
には、このデータを クラウド
で処理する必要があります。
Slide 55
Slide 55 text
1) 道をデータで表現する
2) AからBまで徒歩、電車を利用してパスの探し方
3) クラウド上で地理空間データの扱い
目次
Slide 56
Slide 56 text
データベース
56
● 地理的な検索の必要性
○ 最短パスアルゴリズムが比較的に早い。
○ しかし、データベースからの取り出しが遅い。
アプリケーションがユーザー検索に応じてデータを提供するため、速度が
重要です。
そのために、関連するエリアだけの徒歩ネットワークをロードします。
歩ける駅を見つけるには、 1500メートル範囲内のネットワーク を取り出
す。
このように地理空間データを取り出すには、特殊なデータベースが必要で
す。 図: 大岡山駅付近の1500メートル半
径の徒歩ネットワーク。
Slide 57
Slide 57 text
地理空間インデックス
画像: https://www.linkedin.com/pulse/geo-spatial-data-queries-mongodb-how-works-r-tree-indexing-joshi
57
● 直接検索方法
○ 全ての値に対して条件を確認して
○ 条件を満たすものを返す
● 地理的な課題：あるエリアに含む点を集
合から見つけたい
○ 直接：
■ 全ての点に対して、検索エリ
アに含むかの確認を行う
○ 地理空間インデックス：
■ 事前で空間を点の密度に応
じて地域に分けて行く
■ 検索時点で各店ではなく、地
域に対して確認を行う
■ 最終的にに数少ない点に対
して細かい確認を行う
Slide 58
Slide 58 text
データベース
58
● この地理空間的な課題に対して、地理空間インデクスを対応する
データベースが必要でした
○ Amazon RDS (Relational Database Service) for
PostgreSQL に決定
■ PostGISという拡張により地理空間処理対応します
■ リレーショナルデータベースであり：
● データをレコードとして保管します
Slide 59
Slide 59 text
グラフのデータベース化
59
● グラフをリレーショナルデータベースに保存するには：
○ 各頂点、各辺に地理空間形状をつく
○ 頂点にはその頂点の IDをつく
○ 辺には
■ 先端頂点のID
■ 後端頂点のID
● データベースから読込の時点で
○ 検索エリア内のデータベース行を取得
○ 頂点、辺の集合からグラフをプログラムで作り直す
Slide 60
Slide 60 text
出来上がり
60
1) ポイントの周りのネットワークを取得
2) 駅までのパスと時間を計算
3) 電車ネットワークを駅に繋ぎ、アクセス できる
大企業、大学を求める
Slide 61
Slide 61 text
まとめ
61
このプロジェクトには、複数のデータソースからの地理空間データを利用し、
アプリケーションをつくりました。
現実をデータで記述するには、起きる現象を事前に想像してから、どうやってデータを構造す
るのかを考えた方がいいです。
地理的なデータだからこそ様々な処理・保存・マネージメント・利用方法が必要です。
Slide 62
Slide 62 text
ご清聴ありがとうございました
62
2023.6.26