「不動産API」を分かりやすく解説してみる

不動産物件データの標準「フォーマット」と標準「不動産API」が必要だ、と2002年からずっと言ってきたわけですが、具体的にどういうものなのか「不動産情報デジタル標準化の覚書」の中でもあまり触れていませんでした。（まだ世の中がその段階まで行けてないからｗ）

（追記：結局覚書の方に取り込みました）

分かり易く説明するに、まず見て頂いた方が早いと思うので、ちょっとサンプルをでっち上げてみます。

不動産標準フォーマット

不動産の物件情報を記述するXML形式（書式フォーマット）です。以下でっち上げサンプル。

<?xml version="1.0"?>
<物件データ>
　<物件 名称="おらがマンション" 不動産ID="54784345645654657">
　　<交通 沿線名="JR線" 駅名="新宿駅"/>
　　<所在地 郵便番号="101-0000" 住所="東京都新宿区"/>
　　<賃貸借条件>
　　　<賃料 単位="万円">5.5</賃料>
　　　<礼金 単位="ヵ月">1</礼金>
　　　<敷金 単位="ヵ月">1</敷金>
　　　<管理費 単位="円">2000</管理費>
　　</賃貸借条件>
　　<備考>あいうえお</備考>
　</物件>
</物件データ>

かな～り簡略化というか、かな～り現実的では無いものですが、分かり易さ優先でタグ名も日本語（笑）。少なくともイメージとしては分かり易いのではないでしょうか（30秒かそこらででっち上げたものとしては）。

これをシステムとシステムの間でポンポン投げ合って、お互いソフトウェアで機械的に処理（データ連携、自動化、リアルタイム化）できるようになるわけです。わざわざ手入力とかせずに（コンバートも不要に）良くなるわけです。

「<物件データ>」みたいなの（タグ名）は何でも良いわけで、それこそ別にアルファベットで<bukken>」でもなんでも良いのです。ただ、なんでもよくてもバラバラに皆が勝手にタグ名を付けていたら意味がないので、皆で決めましょう、というのが「標準化」という作業になります。

簡単な話しですよね。

不動産API

で、その標準フォーマットを「システムとシステムの間でポンポン投げ合う」際の方法の方法の一つが、APIなわけです。

APIとは、システムの一部の機能を切り出して、それを外部のシステムから利用できるようにする機能を言います。（ウェブを介してやる場合はWeb APIと言った方がより正確。厳密にはWebサービスAPIと言ったりします）

APIもやり方は色々あるので、「うちらはこれでやりましょう」と皆で決める必要があります。「標準化」作業です。じゃないと、銀行APIみたいな混乱した話しになってしまいますからね。

ちょっと突っ込んだ話しをすると、今や「REST（ful）」なAPIタイプが世界では主流です。APIもシンプルにすべきという流れで、これ、何かというと、基本ブラウザと同じ事をするだけです。

ブラウザは、アドレスを指定されるとそのページを表示します。裏で何をやっているかというと、例えば、「https://note.com/torum/n/n625a989856c1」 のページを表示すると、そのページをGETしているのです。文字通り「GET」というのがありまして＾＾；ページ（HTML）を「取得」しているのですが、それと同じです。

送信はというと（投稿とも言える）「POST」です。まんまです。（他にもUPDATEやDELETEなどがあります）

これで不動産情報の送受信も当然のように出来てしまいます。ソフトウェアで機械的に処理（データ連携、自動化、リアルタイム化）できるようになり、わざわざ手入力とかせずに（コンバートも不要に）良くなるわけです。

簡単な話しですよね。

あ、終わっちゃった。

名前空間で拡張

あ、これは説明しておきたい。

標準のフォーマットで皆が合意して「標準」が出来たとしても、ある企業では独自の項目があって、それを含めて流通させたいこともあるでしょう。

そういう時の為に、XMLには名前空間という仕組みがあります。

<?xml version="1.0"?>
<物件データ xmlns:hoge="http://www.w3.org/hoge">
　<物件 名称="あいうえお建物" 不動産ID="4567">
　　<交通 沿線名="JR線" 駅名="新宿駅"/>
　　<所在地 郵便番号="101-0000" 住所="東京都新宿区"/>
　　<賃貸借条件>
　　　<賃料 単位="万円">5.5</賃料>
　　　<礼金 単位="ヵ月">1</礼金>
　　　<敷金 単位="ヵ月">1</敷金>
　　　<管理費 単位="円">2000</管理費>
　　</賃貸借条件>
　　<備考>あいうえお</備考>
　　<hoge:コメント>名前空間で拡張された項目</hoge:コメント>
　</物件>
</物件データ>

「<hoge:コメント>」の太字部分は、独自の名前空間で追加（拡張）した項目で、この項目は、分かっているシステムではそれを解釈しますが、知らんよ、というシステムでも問題なくその他の部分を処理できます。

便利ですね。

米国での事例（RESO Web API）

米国における不動産情報の標準にはRETSとその後継であるRESO Web APIがあることは、「不動産情報デジタル標準化の覚書」で詳しく触れていますが、おまけで紹介したいと思います。

因みに、日本と米国では、不動産の取引上の慣習から法令から何からまるで違うので、残念ながら、じゃぁ米国のを輸入して使おうぜ、という訳には行きません。前提がまるで違います。残念なことですが。

RETSというのは、全米リアルター協会（National Association of Realtors）- 通称NAR -（日本では宅地建物取引業協会みたいなイメージの不動産業界団体） が主導して、1999年に作った不動産業界の標準規格です。

追記：＞NARについては、「NAR（全米リアルター協会）とその倫理規定（Code of Ethics） 」で詳しく書きました。

ひとことで言うと「不動産物件情報をXMLで定義した不動産情報の標準データ形式」などを含む関連仕様です。まさに米国における不動産デジタル標準、といったところです。

不動産トランザクション標準の略であるRETSとは、コンピューター同士やサイト間で共通の言語でより簡単にMLSのような不動産情報データの交換ができるようにするものです。1999年に、全米リアルター協会（NAR）と関連業界団体がRETSを立ち上げました。

Short for Real Estate Transaction Standard, RETS provides a common language so that computers can more easily transfer real estate information, such as MLS data, to other computer programs or websites. The National Association of REALTORS® and other industry groups launched RETS in 1999.

Field Guide to Real Estate Transaction Standards (RETS) | realtor.org

2011年、NAR（全米リアルター協会）が主体となって行ってきた不動産情報流通の標準化作業が、独立した非営利団体のRESOへ移管されました。作業部会が分離独立して標準化団体を結成した形です。もちろんNARも全面的にバックアップしています。

追記：＞あらたに「不動産の標準化組織 RESO（Real Estate Standards Organization）とは」にて解説しましたので、ご参照ください。

RESOに参加しているメンバーは早々たる面子です。個々のブローカーからテクノロジー企業、今どき不動産テック企業として話題のZillowやCompassまで、物件検索サイトの大手から大小様々のブローカーを含めて、まさに不動産業界と関連ITサービス企業の全員大集合。

RESOは、Real Estate Standards Organizationの頭文字を取ったもので、直訳すると、不動産標準（化）団体、という感じでしょうか。Standardsは標準規格（群というか一式というか複数系）という感じなので、日本語に直訳するとあまり意味が伝わりにくいです。（発音する場合は「リソ」）

しかし、日本での状況（惨状）と比べると、まことに羨ましい限りです。