＜不動産データの整備と活用＞お部屋探しのマスターデータマネジメントと活用を考えよう

概要
GA technologiesのAISC（AI Strategy Center）の
ゼネラルマネージャーかつ電気通信大学の客員准教授も務める橋本と、
リサーチャーとして活躍するイリーンから
データマネジメントや活用を解説いたします。

＼ こんな方に！ ／
データ活用に興味のある方、AIに興味のある方、イタンジに興味のある方…
どなたでもご参加いただけます。

プログラム
19:00-19:05｜ごあいさつ

19:05-19:20｜プレゼンテーション① 不動産業界のデータの"負"と向き合おう！
不動産業界のデータのツラミ
MDMからのアプローチ
不動産IDへの期待

19:20-19:35｜プレゼンテーション② ドアtoドア検索のプロト紹介
道のりのデータでの表現方法
徒歩/電車での移動手段の探し方
クラウド上での地理空間データの扱い

19:35-19:55｜トークディスカッション
イタンジ永嶋を交えて、トークディスカッションやいただいた質問への回答を行います

19:55-20:00｜ごあいさつ＆アンケートのご案内

Transcript

1. ＜不動産データの整備と活用＞ お部屋探しの マスターデータマネジメントと 活用を考えよう
 1

2. 300 イタンジのDX推進への取り組みは、 DX銘柄2022の選定を通じて評価されてい ます。(3年連続) 2023年1月末 2
9. イタンジの情報は、Twitterをフォローお願いします✨
 公式アカウント
 9 Biz・PR・HRアカ ウント

10. 不動産業界のデータの"負"と向き合おう！
 10 2023.06.26 AI Strategy Center　General Manager
 電気通信大学　客員准教授
 滋賀大学データサイエンス学部　インダストリアルアドバイザー 
 
 橋本 武彦
 

11. Introduction：最近、”住所”が話題ですね、、、
 11 出典：とにかく日本の住所のヤバさをもっと知るべきだと思います https://note.com/inuro/n/n7ec7cf15cf9c 出典：日本の住所の正規化に本気で取り組んでみたら大変すぎて鼻血 が出た https://qiita.com/miya0001/items/598070abcdf0799daebc
12. たしかにヤバい・・・
 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
13. 本日、お伝えしたいこと
 13 • 住所や物件名の正規化や名寄せ • 商品特性ゆえに圧倒的に少ないデータ量 • 業界的に低いデータ品質、etc ◦ 2017年以降不動産業界のデータの”負”と向き合ってきました。そん な経験が、もしかしたらDX界隈で戦っているみなさまの　参考になる のでは？
14. P08　　　 不動産業界のデータのツラミ
 P13　　　 MDMからのアプローチ
 P20　　　 不動産IDへの期待
 Contents

15. 自己紹介
 15 氏名 橋本 武彦（はしもと たけひこ） 所属 GA technologies　AI Strategy Center　General Manager 電気通信大学　客員准教授 滋賀大学データサイエンス学部　インダストリアルアドバイザー 国土交通省 不動産IDルール検討会　構成員（令和 3年度） キャリア サマリ • Sier（エンジニア5年/研究員2年） ⇒ 調査会社（リサーチャー 3年） ⇒ ブレインパッド（シニアデータサイエンティスト 9年）を経て2017 年4月から現職にてAISCの立ち上げに参画（当初は新卒含め 3 名、現20名体制） • データサイエンティスト協会（元事務局長）やデータサイエンティス ト育成の新規事業の立ち上げ • 大学や官公庁での講義や執筆、 不動産とAIコミュニティ運営など E-Mail t_hashimoto@ga-tech.co.jp Socialｱｶｳﾝ ﾄ https://www.facebook.com/hashimoto.takehikko 2019/11/23@電通大 研究室 2021/05/26@新丸子自宅
16. P08　　　 不動産業界のデータのツラミ
 P13　　　 MDMからのアプローチ
 P20　　　 不動産IDへの期待
 Contents

17. 不動産業界のデータはツライ？
 17 Yes！！！ Because…
18. 18 ツライ①物件の名寄せ
 • 物件をIDでなく、物件名で管理 ◦ 表記ゆれや転記ミスが増幅　し やすい仕組み ◦ システムで連携困難（≒要 人手 での名寄せや前処理） ※出典：不動産取引データベースの網羅性向上を目的とした不動産募集広告情報のレコード同定（情報 処理学会誌） 　　　　https://www.jstage.jst.go.jp/article/pjsai/JSAI2021/0/JSAI2021_4F3GS10n03/_pdf/-char/ja
19. ツライ②：データ量が少ない！
 19 商品特性に起因 • 同一の物件は存在しない • 超高額商品ゆえに、取引回数が少 ない（= データ量が少ない）
20. ツライ③：データの質が低い
 20 商品特性に起因 業界特性に起因 • 同一の物件は存在しない • 超高額商品ゆえに、取引回数が少 ない（= データ量が少ない） • IT化の遅れ（紙・FAX） • デジタルだけでなく、内見など のリアルが介在（X-Tech） ◦ 人手での入力データ主体
21. 不動産業界のデータはツライ？
 21 Yes！！！ But we keep on fighting…
22. P08　　　 不動産業界のデータのツラミ
 P13　　　 MDMからのアプローチ
 P20　　　 不動産IDへの期待
 Contents

23. GA technologiesの不都合な現状 *2020年経営会議資料より
 23 物件情報 GAのシステム/サービス RENOSY SUPPLIER / MANAGE Lifedesigner 各グループ企業 Modern Standard 神居秒算 パートナーズ ・・・ 建物マスタ 名寄せ 正確な情報 物件情報の追加・更新 機能してない or 各サービスが独自で開発
24. MDM（マスターデータマネジメント）とは
 24 MDM（通称：マスターデータ管理）は、 Master Data Managementの略で、ITにおいて使用されるマスターデータの管理を行う ための手法またはそれを実現する ソフトウェア製品である。 概要[編集] • マスターデータとは、一般的に企業が社内や業務に構築する際の、 データベースであり、共通となる基本的な情報で 代表的なものには「商品」「顧客」「単価」「社員」「取引先」など多岐にわたる。マスターデータ管理とはその情報を管 理する手法である。 背景と意義[編集] 通常マスターデータは個々の情報管理 アプリケーション内で定義されるが、マスターデータが適切に管理されていない場合や、 複数の情報管理システムで同じマスターデータを使用する場合には、 マスターデータ間の整合性が保たれない、または重複が 存在するという事態が発生しうる。マスターデータの重複や 不整合は、そのマスターデータと関連するデータが検索・ 同定できな くなる、といった不都合を生むため 、マスターデータ自体を管理する必要から MDMという概念が生まれている。 ・・・ 出典: フリー百科事典『ウィキペディア（ Wikipedia）』
25. 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外販）
26. 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 正規化後名称 • 不要文字削除 • 住所変換 • 都道府県補正 • 数字・漢数字変換 正規化処理
27. ID連携に向けて：②建物名寄せ
 27 • 建物名寄せAPIを開発 ◦ 背景 ：ノイズなどによる低精度 ▪ 「駅徒歩２分の好立地！セザール御嶽山」、【上質リノベ ×防 音室付×角部屋】駅６分の好立地 ♪シュロス田園調布南、 etc ◦ 対応 ：各種辞書の地道な拡充 建物名: 六本木マンション 101 建物名: roppongi mansion(3F) 建物名:六本木マンシヨン 建物名: 六本木マンション 正規化後名称 • 英語カタカナ変換 • 不要文字削除 • 数字・漢数字変換 • ブランド補正 正規化処理
28. ID連携に向けて：②建物名寄せ
 28 • 最終的にはAPI ＋ ルール ＋ 目視の併用で、限りなく 100%へ！ ◦ ルール ▪ 物件名、住所の正規化名称の比較 • 部分一致の場合、他ルール併用で判定 ▪ 他の定量項目の利用（築年、階建て） • 他ルールと併用で一定の誤差許容 ◦ 目視 ▪ ルールで判別困難な場合に利用 ▪ 目視でも確証が得られない場合もあり、、、 • データに信頼度をつけて管理 • （New）Chat-GPTも色々試用 ◦ 正規化後のさらなる処理（ ”物件名”の抽出）に効果 ◦ プロンプトの工夫（教示）、 temperature指定、etc 名寄せ作業の流れ（抜粋）

29. P08　　　 不動産業界のデータのツラミ
 P13　　　 MDMからのアプローチ
 P20　　　 不動産IDへの期待
 Contents

30. 不動産ID（BR）への期待
 30 大いに期待しています！ 不動産IDとは？（国土交通省） • 住居表示の表記ゆれや同一住所上に複数物件が存在する等により、物件情報の照合、データ連携が難しいとの課題。物 件を一意に特定し、関連情報の連携・活用を促進するため、令和４年３月、国土交通省にて「不動産IDルールガイドライン」 を策定。 • 「不動産ID」は、不動産登記簿の「不動産番号」を基本に、同番号だけで特定できない場合にも対応できるよう「特定コード」 を加えた17桁の番号で構成される。 BR（ベース・レジストリ）とは？（デジタル庁） • 行政又は民間におけるサービスの共通基盤として利活用すべき又は可能なものであって、公的機関等が正当な権限に基 づいて収集し、正確性や完全性等の観点から信頼できる情報を元にした、最新性、標準適合性、可用性等の品質を満た すデータ群
31. ベース・レジストリ整備のメリット
 31 • 正確な情報公開 • 効率化、添付や申 請の省略、他との 掛け合わせによる 価値創造 ※出典：不動産ID官民連携協議会 協議会資料（デジタル庁） 　　　　https://www.mlit.go.jp/tochi_fudousan_kensetsugyo/content/001613870.pdf
32. ※出典：不動産ID官民連携協議会 協議会資料（国土交通省） 　　　　https://www.mlit.go.jp/tochi_fudousan_kensetsugyo/content/001613636.pdf 不動産IDが他産業への架け橋に
 32 • 不動産ID官民連携協議会に251会員 が参画 ◦ 半数が不動産業界以外 ◦ ex.建設、物流、金融、保険、 警備、小売、etc • 2028年〜本格普及
33. 先行例：法務省 登記所備付地図（XML）データ 無償公開
 33 • 2023/1に「登記所備付地図」データを法務省が無償公開。有志の様々なツールや Appが公開され、界隈 を賑わす • AISCでも住所⇔地番変換を実施、任意座標系の問題もあり一部だが効率化に貢献。 空間検索できる環 境を提供準備中（AWS Athena） 青丸：自社の住所マスタ *緯度・経度あり 赤丸：法務省データ • 緯度経度をもとにpolygonを空間検索 • 任意座標系に関しては画像処理などを 用いた研究を計画 例．住所と地番の変換（世田谷区若林）

34. まとめ：本日、お伝えしたかったこと
 34 • 不動産データは”ツライ” • けれど大きな未開の可能性（技術 + 根性 + 不動産ID） ◦ 不動産に閉じないデータ活用の道が拓けてきました　 　　 ぜひ一 緒にフロンティアの苦労・楽しみを味わいましょう！ ▪ ドアtoドア 検索（Ilinさん） ▪ 賃貸 × リアルタイムDB（ITANDI）
35. ドアtoドアのプロトタイプ紹介
 Ilin Viacheslav
 AI Strategy Center

36. 背景
 36 • 知名度の低い地域の物件に対して ◦ 立地のアクセスが物件の魅力の大きな要素 ◦ アクセスを評価するには ▪ 大企業事業所までのアクセス • 大企業社員向け ▪ 大学までのアクセス • 大学生向け アクセスのいい物件は投資対象になる • 地理空間データをアプリケーションに使う ◦ 会社、大学の位置 ◦ 歩ける道の細かいネットワーク ◦ 電車駅のネットワーク
37. アプリケーションデモ
 37 • 住所/位置を選択 • 駅が表示されます ◦ 歩ける範囲の駅、電車線 ◦ 駅までの最短ルート ◦ ルートの徒歩分数 • 電車を利用してアクセスできる　　大 企業、大学を表示 ◦ 駅までの徒歩分数 ◦ 電車の時間 ◦ 乗車、降車駅 ◦ 降車してからの徒歩分数
38. アプリケーションデモ: 駅までの徒歩分数、ルート
 38
39. アプリケーションデモ:アクセス
 39 大企業の所在地までアクセス分数 大学までのアクセス分数
40. 1)　　　 道をデータで表現する
 2)　　　 AからBまで徒歩、電車を利用してパスの探し方
 3)　　　 クラウド上で地理空間データの扱い
 
 目次

41. 構造
 41 徒歩ネットワーク 大企業、大学情報 電車ネットワーク クラウドでデータ処理 ルート検索 地図で表示
42. 1)　　　 道をデータで表現する
 2)　　　 AからBまで徒歩、電車を利用してパスの探し方
 3)　　　 クラウド上で地理空間データの扱い
 
 目次

43. ネットワーク
 43 • ネットワークは、グラフともいう • グラフの点を頂点（ノード）という • その頂点を繋ぐものを 辺（エッジ）という • 頂点から頂点までの連続道を パスという 1 2 4 3 1↔2辺(エッジ) 頂点 (ノード)1 頂点 (ノード) 2
44. 地理的なデータオブジェクト
 44 点 (x, y) (x 1 , y 1 ) (x 2 , y 2 ) (x 3 , y 3 ) (x 4 , y 4 ) • グラフの概要の頂点・辺が形状を持たず、連続性だ けを記載する抽象的なものです。 • しかし、実際の道を記載するには、少なくとも点と線 が必要です。 複数の点を繋ぐ直線分からなる。 線
45. 道ネットワーク
 45 • 頂点 ◦ 道の交差点 ◦ 駅 ◦ 建物 • 辺 ◦ 道 ◦ 電車駅の乗換 注意： 道から道に移動が出来ない所には、 頂点がありません。 この場合、一つの道が地下にあります。
46. オープンデータ
 https://www.openstreetmap.org/#map=15/35.6815/139.6736
 46 • OSM(OpenStreetMap)データ ◦ ユーザー入力地理空間データ • OSMデータ構造 ◦ 各オブジェクトが点の集合である ▪ 道（線） ▪ 建物（多辺形） ◦ オブジェクトの種類をタグにより分裂 されます ◦ 同じ点が複数オブジェクトに所属する ことが可能です
47. オープンデータ処理
 47 • OSMデータからネットワークを作るには ◦ タグによってフィルタリング ◦ 点の集合を取得 ◦ 直線分に分ける ◦ 行さする点を頂点とし、その他の線分 を合併して辺とする • ユーザー入力データなので、データク リーニングが重要。例えば： ◦ 道のタグですが、点の集合は一 点だけ。 ◦ スタート・エンドポイントの IDが同 じ。 • 長さ０の線分に置き換える。 • グラフとして無意味ですが、長さがあるとまと もな道です。(リングロード） 形を変 えずに二つの道に分ける。
48. ここまで
 48 48 徒歩ネットワーク 細かい徒歩ネットワークを取得しました！ どのように、このネットワークを使って徒歩分数を求 めますか？
49. 1)　　　 道をデータで表現する
 2)　　　 AからBまで徒歩、電車を利用してパスの探し方
 3)　　　 クラウド上で地理空間データの扱い
 
 目次

50. ネットワークの最短パス
 図: 新宿空の複雑な道ネットワーク。 
 ポイントからポイントまでの最短道が緑色になっていま す。
 50 • グラフ辺には重みを付ける。 ◦ 重みが、その辺の負担と考えられる。 ◦ この場合で、最短距離検索なら、重みは距離と する。 • Dijkstraのアルゴリズムを使って、 ポイントAからポイン トBまで、重さを最小限にするルートを探す
51. 電車ネットワーク
 51 • 電車ネットワークの構造 ◦ 電車の駅を頂点とする ◦ 駅の間のを辺とする ◦ 追加で駅の間の乗換も辺とする • エッジ重みを時間に ◦ 電車線の形がOSMから取得しにくい ◦ 電車線の形を分かっても、移動時間が距離に依存し ない（停止信号、電車の速度不定ため） ◦ 結果、電車ネットワークは地理的線を持たず、距離が 無意味です。 ◦ ネットワークの重みを時間とする ２分 5分 8分 3分 乗換4分 3分 4分 ２分 6分
52. 電車ネットワークの工夫
 52 • 電車ネットワークを徒歩ネットワークにつなぐ ◦ 電車ネットワークが駅から始まる ◦ 駅は大きい建物の中にいて、複雑な地下の歩道に繋ぐ ◦ そのため、駅に繋ぐ 駅の入口が必要 • 電車駅への入口 ◦ 入口は歩道ネットワークの 頂点である ◦ 駅は歩道ネットワーク・電車ネットワーク、 両方の　頂点 である • 入口のデータをオープンデータの本で作り、大きくデータクリー ニングが必要でした。 ◦ 大量の入口を追加しました。 図: 広尾駅の駅入口が緑色。 
 広尾駅自体が赤色。駅が地下　　なの で、直接道から入れません。 

53. 電車ネットワークの工夫（続き）
 53 • しかし！ ◦ 電車降車駅を検索する前（最短パス検索す る前）に分かりません。 ◦ 電車降車駅を知らないと、そのエリアの徒 歩ネットワークを取得出来ません。 • 解決策： ◦ 到着地が大企業、大学であるため、徒歩 ネットワークを使って、その大企業、大学か ら周りの駅までのルート、徒歩分数を事前 に計算し、電車ネットワークとともに保存す る。 図: 電車ネットワークと
 大学までの徒歩道

54. ここまで
 54 徒歩ネットワーク 大企業、大学情報 電車ネットワーク ルート検索 ネットワークデータを取得して、ドア toドアの道を検索 することが出来ます。 そして、大企業、大学の所在地がネットワークに含 む。 しかし、アプリケーションする には、このデータを　クラウド で処理する必要があります。
55. 1)　　　 道をデータで表現する
 2)　　　 AからBまで徒歩、電車を利用してパスの探し方
 3)　　　 クラウド上で地理空間データの扱い
 
 目次

56. データベース
 56 • 地理的な検索の必要性 ◦ 最短パスアルゴリズムが比較的に早い。 ◦ しかし、データベースからの取り出しが遅い。 アプリケーションがユーザー検索に応じてデータを提供するため、速度が 重要です。 そのために、関連するエリアだけの徒歩ネットワークをロードします。 歩ける駅を見つけるには、 1500メートル範囲内のネットワーク を取り出 す。 このように地理空間データを取り出すには、特殊なデータベースが必要で す。 図:　大岡山駅付近の1500メートル半 径の徒歩ネットワーク。

57. 地理空間インデックス
 画像: https://www.linkedin.com/pulse/geo-spatial-data-queries-mongodb-how-works-r-tree-indexing-joshi
 57 • 直接検索方法 ◦ 全ての値に対して条件を確認して ◦ 条件を満たすものを返す • 地理的な課題：あるエリアに含む点を集 合から見つけたい ◦ 直接： ▪ 全ての点に対して、検索エリ アに含むかの確認を行う ◦ 地理空間インデックス： ▪ 事前で空間を点の密度に応 じて地域に分けて行く ▪ 検索時点で各店ではなく、地 域に対して確認を行う ▪ 最終的にに数少ない点に対 して細かい確認を行う
58. データベース
 58 • この地理空間的な課題に対して、地理空間インデクスを対応する データベースが必要でした ◦ Amazon RDS (Relational Database Service) for PostgreSQL に決定 ▪ PostGISという拡張により地理空間処理対応します ▪ リレーショナルデータベースであり： • データをレコードとして保管します
59. グラフのデータベース化
 59 • グラフをリレーショナルデータベースに保存するには： ◦ 各頂点、各辺に地理空間形状をつく ◦ 頂点にはその頂点の IDをつく ◦ 辺には ▪ 先端頂点のID ▪ 後端頂点のID • データベースから読込の時点で ◦ 検索エリア内のデータベース行を取得 ◦ 頂点、辺の集合からグラフをプログラムで作り直す
60. 出来上がり
 60 1) ポイントの周りのネットワークを取得 2) 駅までのパスと時間を計算 3) 電車ネットワークを駅に繋ぎ、アクセス　　できる 大企業、大学を求める
61. まとめ
 61 このプロジェクトには、複数のデータソースからの地理空間データを利用し、 アプリケーションをつくりました。 現実をデータで記述するには、起きる現象を事前に想像してから、どうやってデータを構造す るのかを考えた方がいいです。 地理的なデータだからこそ様々な処理・保存・マネージメント・利用方法が必要です。
62. ご清聴ありがとうございました
 62 2023.6.26