不動産プラットフォームのアーキテクチャとインテグレーション：リファレンスマップと構築順序

この技術記事は、不動産プラットフォームの新規構築や、既存のリスティング・CRM・決済連携のつぎはぎを整理しようとしているCTO、アーキテクト、プロダクトオーナーを対象としています。すでにプラットフォームが必要であることはご存知の前提で進めます。ビジネスケースと主な機能構成については、まず不動産プラットフォームソリューションページと不動産セクターページをご覧ください。本記事では、その両方を支えるアーキテクチャを解説します。

このガイドの内容

• 不動産プラットフォームが実際に接続するシステム
• リファレンスアーキテクチャ
• インテグレーションはポイントツーポイントにすべきか、ゲートウェイ経由にすべきか
• 構築順序：まずリスティングとリードから
• セキュリティ、コンプライアンス、データオーナーシップ
• AIの活用場所と、一つの絶対的な制約
• 存在する納品実績と、存在しない納品実績
• 代替案：このインテグレーションレイヤーを誰が構築するか
• ゲートウェイレイヤーをまだ構築すべきでない場合
• このガイドの限界
• よくある質問
• 次のステップ

不動産プラットフォームが実際に接続するシステム

不動産プラットフォームが単独で完結することはほとんどありません。接続方法を決める前に、周辺システムがそれぞれ何を管理しているかを整理してください。

RESO Data Dictionaryは、不動産業界のリスティングフィールド共通標準です。これをサポートするフィードは接続ごとのフィールドマッピングが少なくて済みますが、非対応のフィードはアーキテクチャの選択に関わらずマッピングレイヤーが必要です。

リファレンスアーキテクチャ

このアーキテクチャにおけるリードの経路：問い合わせはソース情報付きでリードおよびCRMレイヤーに到達し、ルーティングルールによって対応期限付きでエージェントに割り当てられます。内見と申し込みを経てディールエンジンに移行し、署名済みの申し込みが電子署名をトリガーし、預託金の場合は信託台帳をトリガーします。クローズしたディールのコミッション配分は、後から手入力するのではなく、ディールのルールから自動計算されます。

インテグレーションはポイントツーポイントにすべきか、ゲートウェイ経由にすべきか

プラットフォームが最初の2つの接続を超えて成長した時点で、最も重要なアーキテクチャ上の決断です。

分岐点はビジネスの規模ではなく、外部システムの数です。CRM1件とMLSフィード1件であればポイントツーポイントで問題ありません。しかし、同じリスティングおよびディールレコードに対して複数のポータル、CRM、決済プロセッサー、電子署名プロバイダーが直接リンクを持つようになると、フォーマット変更1件が複数システムにまたがるバグ調査につながります。ゲートウェイは各インテグレーションの作業をなくすのではなく、システムが追加されるたびに作業が倍増することを防ぎます。

セキュリティ、コンプライアンス、データオーナーシップ

Netbase JSCのセキュリティ実践は、構築するすべてのシステムに同様に適用されます。セキュアコードレビュー、通信中のTLS暗号化、保存時の暗号化、ロールベースのアクセス制御、脆弱性スキャン、侵入テスト、ディザスタリカバリが含まれます。カードデータと信託/エスクロー資金には特別な注意が必要です。PCI DSSは、カード会員データを保存・処理・送信するシステムのベースライン要件を定めており、信託またはエスクロー口座には通常、営業口座とは別に照合される専用台帳が必要です。これは汎用の決済プロセッサーが単独で適用するルールではありません。GDPR第6条は、リードデータを処理する際の適法な根拠を、後から追加するのではなく取得時に記録することを義務付けています。リスティング、リード、テナント、ディールのレコードはお客様が所有するシステムに保持され、インテグレーション契約によりプラットフォーム外に何が出るかを定義します。これは一般的な情報であり、法的アドバイスではありません。

存在する納品実績と、存在しない納品実績

印刷・包装・小売・Eコマース以外にも、Netbase JSCは不動産分野のクライアントにプロジェクトを納品していますが、クライアント名は公表されていません。また、Netbase JSCはPoslor（不動産オペレーティングシステムかつNetbase Business Division）を構築・運用しており、WordPress、Wix、ウィジェットのインテグレーションとパブリックAPIを通じて自社サイトを超えた展開を実現し、プライベートなワークスペースデータと公開するリスティングレコードを分けて管理しています。匿名不動産リスティングプラットフォームの事例は、Netbase JSCがコンサルタント、カスタム開発者、インテグレーターとして不動産クライアントに構築したリスティング・リードプラットフォームを説明するものです。クライアント名、システム一覧、日付、数値は記載されていません。

存在しないもの。いずれのプロジェクトについても、接続されたMLS、IDX、決済、電子署名のプロバイダーを具体的に記載したNetbase JSCの公開記録は存在せず、インテグレーション件数、移行期間、コスト、稼働率の数値も公表されていません。リファレンスアーキテクチャおよびポイントツーポイント対ゲートウェイの判断基準は、Netbase JSCの一般的なインテグレーションアーキテクチャ納品実践（異なるシステム構成での同じパターンについてはERP・CRM・Eコマースインテグレーションアーキテクチャガイドを参照）と引用した標準規格に基づくものであり、実測された不動産インテグレーション件数から導かれたものではありません。

代替案：このインテグレーションレイヤーを誰が構築するか

Netbase JSCはコンサルティング、カスタム開発、デジタルトランスフォーメーションを中心に展開しています。ほとんどのプロジェクトはワークフローレビュー後にスコープを合意した請負契約で納品されますが、マイルストーンベース、月次チームリテイナー、KPI連動モデルも提供しています。カスタム開発においては、Netbase JSCが作成したIPはお客様に帰属します。Poslorなどのプロダクトモジュールはライセンスであり、譲渡されません。チームはハノイを拠点にリモートファーストで英語で業務を行い、不動産デジタルツールキットなどのモジュールを再利用することで、適合する場合に開発時間を最大60%短縮できます。

ゲートウェイレイヤーをまだ構築すべきでない場合

• 現時点でインテグレーションが1〜2件で、追加の具体的な計画がない場合。ゲートウェイは、まだ実際の問題を解消しないうちから、運用・セキュリティ管理が必要なコンポーネントを増やすことになる。
• MLSまたはポータルとの関係がまだ交渉中の場合。アーキテクチャの決定は、データ共有の条件が決まった後の方が、前より安価に済む。
• ゲートウェイの稼働を管理するリソースがない場合。管理が行き届いていないインテグレーションレイヤーは、誰かが実際に監視しているいくつかの直接接続より問題が大きい。

このガイドの限界

• リファレンスアーキテクチャと一般的な判断基準を説明しています。MLS、ポータル、決済プロバイダーごとにAPIとライセンス条件は異なります。
• PCI DSS、GDPR第6条、RESO Data Dictionary、フェアハウジング法は、各規格・法律が定義・要求する内容を参照するために引用しており、Netbase JSCのプロジェクトがそれらに対して認定・監査を受けたという主張ではありません。
• Netbase JSCの不動産プロジェクトについて、インテグレーション件数、構築期間、コスト、稼働率の数値は主張していません。
• ポイントツーポイント対ゲートウェイの分岐点は計画上のヒューリスティックであり、公開された不動産事例から導かれた実測値ではありません。

次のステップ

現在利用しているMLSまたはポータルフィード、CRM、決済・信託会計システムをお知らせください。インテグレーションアーキテクチャと最初の構築順序を整理するためのソリューションレビューのご予約を承ります。不動産プラットフォームソリューション、不動産セクターページ、またはNetbase JSCのインサイトもご覧ください。

関連サービスとソリューション