技術要素（２）：XML WebサービスAPI
本ブログは下記へ移転しました。誠に申し訳ありません、お手数をおかけします。
＞＞目次
XMLを用いたWebサービスAPI
前回の３大原則を前提として、 不動産情報流通IT化に必要な技術要素を見ていきます。
不動産物件情報の流通における特徴は、
インターネットに公開した物件情報は、申込時点で募集を取り下げないと「おとり広告」となってしまいます。そのため、情報の流れをコントロール出来なければならない。つまり一次情報の発信元が情報を更新したならば、２次３次情報公開者も遅滞なく更新された情報を反映させなければならない義務が発生するのです。（不動産の公正競争規約）
勝手に出回ってしまっては発信元も責任を問われる可能性が出てくるし、利用者にも不利益となります。なので、そういった意味でも物件情報の２次利用は勝手におこなってはならないという前提があります。元々無断転載、無断２次広告はダメです。空室確認せずに放置もだめです。
しかし、そんな事をいちいちちゃんとやっていたら、ひたすらFAXと電話で物件確認をし続けなくてはなりません。ありえません。これに関しては、テクノロージー的な課題でも障壁でもなく、逆に（正確性、リアルタイム性などなどは）ＩＴを使って解決できる問題なのであります。
というものです。これを、一々電話で確認した上で、手動で公開・非公開やったり、各物件検索サイトのシステムの独自仕様に合わせてデータを丸ごとCSVで送信したり、またはデータ変換業者を通したり、という現在の状況は超がつくほど前近代的です。
ありえないレベルです。
では、どうするか、というとAPIを使います。
WebサービスAPI
APIとは何か、というのはAPIやWebサービスで検索して頂ければ山ほど情報が出てくるので調べて頂くとして、異なるシステム同士で連携する仕組みです。つまり、システムの一部の機能を切り出して、外から利用できるようにする、という意味合いがあります。
これにより、あるシステムがAPIで他のシステムの機能を利用したり、そこのデータを取得したり新たに登録したりできます。
実は、今使っているこのブログでもAPIが利用できます。ここに限らずどのブログでもブログ投稿APIに対応していて、様々なツールと連携してブログを投稿する事が出来るようになっています。例えば、あるブログ投稿ツールを利用して、Aブログに投稿し、Bブログに投稿、という事が出来ます。APIが共通で標準化されているからです。ブログAPIの場合、有機的に広まってデファクトスタンダードが普及したXML-RPCタイプと、IETFという標準化団体により標準化されたより汎用的な「出版プロトコル」である、Atom Publishing Protocolという二つのAPIが利用されています。
＊技術的な詳細に触れると、APIには主に二つの形式があり、RPCタイプとRESTタイプに分かれます。RESTはよりインターネットネイティブと言える方法で、この方法が現在主流となっています。RESTな（RESTfullと言います）APIは、ブラウザと同じで、あるURIに対してGET、つまりこのIDのリソース（HTMLページとかXMLファイルとか画像ファイルとか）をくださいな、とすると、取得できたりします。POSTでリソースを追加・登録です。このIDのリソースを削除してくださいな、という場合はDELETEで、更新はPUTです。CSVでデータベース丸ごとダンプしてFTPでファイル転送するような野蛮な方式とくらべて、なんとシンプルで美しい方法ではありませんか。
CSV形式で一々各社の仕様に合わせて変換（コンバート）して、データを丸ごとドーンと送信するような前近代的で非効率極まりないやり方は、もう辞めましょう。
XMLフォーマット
APIでシステム間の相互連携が出来る、という事ですが、データの形式はどうなるか、というとXML形式で記述したものを使います。
XMLはデータフォーマットを定義して利用する為の標準規格で、ありとあらゆる所に使われています。ワードなどの文書ファイルも中身はXMLフォーマット、アプリの画面設計のフォーマット。100％間違いなく、誰もが一日に一度はXMLを利用した技術を使っているはずです。金融業界を含む各種業界で、標準データフォーマットとして利用されているのです。
具体的な例としては、金融・会計・財務関連の国際標準フォーマットとして、XBRLというのが標準化されています。これは2000年代初期には既にあった記憶があります。
XBRL（eXtensible Business Reporting Language）は、各種事業報告用の情報（財務・経営・投資などの様々な情報）を作成・流通・利用できるように標準化されたXMLベースのコンピュータ言語です。特に、組織における財務情報・開示情報（財務諸表や内部報告など）の記述に適しています。
たとえば財務情報は、年度ごと、あるいは組織や業種ごとに、文書構造や項目、計算式などが異なるといった特徴があります。このため、従来の作成方式では作成コストがかかるだけでなく、共通化や二次利用が困難です。XBRLを用いることにより、ソフトウェアやプラットフォームの壁を越えて、電子的な事業報告の作成や流通・再利用を容易に行うことが可能になります。その結果として、企業、会計専門家、監督機関、アナリスト、投資家、資本市場参加者、ソフトウェアベンダー、情報ベンダーなど、財務情報のサプライチェーンに関係するすべての当事者に、財務情報を取り扱うためのコストを削減させ、より正確でスピーディーな情報処理が可能となります。特にインターネット上に公開されている財務情報については、データの精度が向上するだけでなく、他のコンピュータシステムでの再利用が容易になることにより、その価値が飛躍的に高まるという効用もあります。
このようなメリットを実現するキーとなっているのは、「標準化」です。XBRLの普及の中心的役割を担っているのは、XBRL Internationalという非営利の世界的なコンソーシアムであり、IFRS（国際財務報告基準）を策定しているIASB（International Accounting Standards Board）をはじめ、財務情報サプライチェーンに関係する各種企業・団体がそのメンバーとなり、XBRLの標準化と普及を全世界レベルで強力に推し進めています。会計基準ではIFRSを自国の会計基準として採用する国が急速に広まっていますが、財務諸表を中心とする財務情報の作成・流通・利用を可能とする技術は全世界でもXBRLをおいて他にはなく、世界中の関心が確実に高まっています。
XMLは、標準フォーマットを定めるのに最適で、「名前空間」というシステムを利用して、標準規格のフォーマットに独自の拡張を施す事も可能ですから、非常に柔軟性があります。また、XMLのスキーマ定義を利用し、データの項目がちゃんとあるか、といった定義に即したデータであるかの確認が簡単に出来るようになっています。このスキーマ定義が仕様書としても機能し、異なるシステム間での利用に用いられます。
名前空間の拡張により、自社の独自項目を追加しても、なんの問題もなく他社システムとの連携を取る事が可能になるのです。殆どの方はこの事実を知らないで、「標準化など無理」などと言います。単に、XMLの事を知らないからそういう事を言ってしまうに過ぎません。
因みに、中にはJSON形式を使わないのか、と言う人もいるかもしれませんが、JSONは元々JavaScriptネイティブのデータフォーマットで、ブラウザの要素を一部書き換える為のデータフォーマットとして、小粒なデータをブラウザ内のJavaScriptがサーバとやり取りしたりするのに主に利用されており、その用途で最適なものであって、不動産物件情報の流通、といった汎用的な業界標準フォーマット用途には、XMLの方が向いている、と個人的には思います。まぁ、XML形式とJSON形式は、両方ともライブラリが揃っているので出入力に両方対応させるコストは微々たるもので、両方対応すれば良いに越したことはないです。
このようにして、物件検索サイト側が、データ入稿にXMLとAPIに対応さえすれば、業務ソフト（自社で使う物件管理システム）から、効率的に物件情報の流れがコントロールできるようになります。
ポイントは、このAPIとXMLフォーマットは、一企業の独自仕様ではいけない、という事です。業界団体なりが策定すべきものです。
EDIという用語について
EDI、つまり、 電子データ交換という表現が未だに官公庁をはじめとして使われている実態がありますが、「電子データ交換」がインターネット上に移行した現在ではもはや最も適切な表現とも言えないのではないでしょうか。
というのも、元々インターネットが登場する前からEDIというのがあって、Point-to-Pointまたは直接接続、つまりシステム同士がインターネットを経由せずに接続されるものも指す事があります。これは、前にのべた三原則にも反する事で、閉じたネットワークは使うべきではありません。EDIという言葉が使われている業種や分野はそうした過去の歴史上の経緯から、慣習的に使われ続けているにすぎません。
英語圏でも、もはやEDIなんて言い方はもはや一般にしませんし、「電子データ交換」はとっくにインターネットに移行し、いまや「電子データ交換」に相当するのは普通に「ウェブサービス」ということが多いです。
不動産ID
不動産IDは、XMLとAPIとちょっと違うレイヤーの話しですが、必要と言えるでしょう。ただし、無くてもWebサービスAPIは運用可能です。
現在、物件情報で、個別の物件を一意に識別する確実な方法はありません。つまり、A社が登録した「XXXマンション」と、B社が登録した「XXXマンション」は同じ建物の物件なのか分からないという事です。一般媒介物件だと複数の元付け会社から物件情報が回ってきますから、識別できた方が良いです。仲介先物を流す業者もいますし。
物件の住所で分かるではないか、というのは素人の考えで（私も不動産業に入ってから知ったのですが）厄介なもので、日本では様々な表記が存在し、単なる「表記揺れ」だけにとどまらず、平たく言うと登記簿上の所在地と郵便配達用の住所、地番と住居表示という2種類が存在してたりします。名簿のような「名寄せ」で特定も確実ではなくアナログ処理バリバリで難しい所があります。
登記簿謄本にある「不動産番号」を使えば良いのでは、と思ったりしましたが、登記簿情報を識別するIDを流用するのは色々とスッキリしない点があります。区分所有の建物じゃないと、部屋ごとに番号付かないし、土地も一筆単位だったりするし・・と。
という訳で、不動産IDが新たに出来ると、業者間で物件情報をデジタルでやり取りする際に、住所や物件名の表記揺れに関わらず、どの物件情報なのかを特定する事が出来ます。（＜出来ると、1つのデータにまとめたり、表示を整理できます）
2021年現在、不動産番号に部屋番号を付記したものを不動産IDとする、というような話しが出ているようですが、協会や国交省など、公的な所からは正式に何もないので、どうなんでしょうかね。
標準化に関する誤解
標準規格とか標準データフォーマットとか、標準化、という言葉を使ってきましたが、一般的にはなじみがない言葉のようで、不動産関係の方などから、ビックリするようなものすごい誤解を受けることもあるので、触れておきたいと思います。
まず、間違っても「物件名称」とか「物件名」とかの用語の統一を図るものでは無いので誤解をしないで欲しい、という事です。大昔（10数年前）、不動産流通近代化センターの天下り事務局の某が、「『物件名称』とか『物件名』とか様々なので、標準化などは出来ない」という発言をしたのですが、基本の勘違いですね。頭が痛くなります。いや、当時、会合にオブザーバー参加していたので、実際に頭痛がしました。
個々の企業やサービスが、「物件名称」という表現を用いていようが、「物件名」としていようが、全然構わないのです。標準化とは、「物件名称」を用いているシステムと、「物件名」を用いているシステムが、同じ共通言語でデータをやり取りできるようにするための中間フォーマットを作る、という話しです。
標準化とは？
標準化とは、異なるメーカの製品間で相互運用を可能とするため、業界内で統一規格を作成する取組みです。モバイル通信の世界では、周波数、無線技術、通信手順や信号インターフェースなどを統一化する取組みが該当します。その結果、世界中の端末が各国のネットワークに繋がり、モバイル通信が可能となります。また、同じ規格の製品が世界各国で採用される事で、端末や装置が共通化でき、価格が“低廉化”することが期待されます。
これは、関連するベンダー（機器の製造業者であったりソフトウェアの開発業者であったり）や業界団体が、自主的に業界発展の為に、協力しあって自主的に標準化団体を作って活動するものです。
なので標準化団体というのはどの業界にもあって、前述の、金融・会計・財務関連の国際標準フォーマットとして、XBRLだけではなく、各種業界の各用途向けに様々存在しています。
日本の不動産業界では、残念な事に機能している標準化団体は存在していません。
次回からは、海外の事例を紹介していきます。
