不動産情報ライブラリAPIをBIツールに繋ぐ手順｜スプレッドシート・BigQuery経由の構成
APIの取得方法そのものは「不動産情報ライブラリAPIの使い方」で解説しています。この記事は、取得したデータをダッシュボードで使えるようにするところを扱います。
この記事のポイント
BIツールからAPIを直接叩く構成は選ばない。認証ヘッダー・GeoJSON・アクセス制限の3つが理由。定期取得して保存する層を1つ挟み、BIは保存先を読むだけにする。
国土交通省の不動産情報ライブラリAPIを使い始めると、次に必ず出てくるのが「このデータをそのままダッシュボードで見たい」という話です。取引価格や地価の推移を毎回スクリプトで出力するのではなく、TableauやLooker Studioで社内に共有したい、という要望です。
ここで多くの人が最初に試すのが「BIツールのWebデータコネクタでAPIのURLを指定する」方法です。これはほぼ確実に詰まります。理由は3つあり、いずれもこのAPIの仕様に起因します。
BIから直接叩けない3つの理由
| 制約 | 内容 | BIで起きること |
|---|---|---|
| 認証ヘッダー | APIキーを Ocp-Apim-Subscription-Key というヘッダーに載せる方式 | URLを貼るだけの標準コネクタはヘッダーを付けられず、認証エラーになる |
| レスポンス形式 | 地図系はGeoJSONとPBF（バイナリベクトルタイル） | 入れ子の構造や座標配列をBIが表として解釈できない |
| アクセス制限 | 同一APIキーで基準期間内に多数のリクエストがあると制限がかかる旨が公式に案内されている | 閲覧のたびに再取得する構成だと、人数が増えたときに止まる |
3つ目が特に見落とされます。1人で試している間は動くので、そのまま社内に共有してしまう。閲覧者が増えた時点で急に落ちる、という壊れ方をします。
正しい構成は「取り込み層を1つ挟む」
やることは単純で、APIとBIの間に「定期的に取得して保存する場所」を1つ作ります。BIはAPIを知らず、保存先だけを読みます。
構成
不動産情報ライブラリAPI
↓ 定期実行（1日1回など。閲覧のたびに叩かない）
取り込み処理（必要な項目だけを平坦な表に変換）
↓保存先（スプレッドシート / BigQuery など）
↓ BIは保存先だけを読む
ダッシュボード
この形にすると、3つの制約が全部消えます。ヘッダーは取り込み処理の中で付ける。GeoJSONは取り込み時に平坦化する。APIを叩く回数は閲覧者数と無関係になり、1日1回で固定されます。
保存先をどちらにするか
| スプレッドシート経由 | BigQuery経由 | |
|---|---|---|
| 向いている規模 | 対象エリアが数市区町村まで | 複数県・数年分を横断して見たい |
| 作り始めの速さ | 速い。当日中に動く | 初期設定に時間がかかる |
| つまずく所 | 行数が増えると重くなる。履歴を持つと特に厳しい | 費用の考え方と権限設計を先に決めないと運用で揉める |
| 現場での使われ方 | そのまま担当者が中身を直せてしまうのが利点でも欠点でもある | 中身を直せないので、正しさが保たれる |
最初からBigQueryを選ぶ必要はありません。ほとんどの場合、まずスプレッドシートで1エリア分を回して「そのダッシュボードが本当に毎週見られるか」を確認するほうが確実です。見られなかったものを大きい基盤に載せ替えても、見られないままです。
取り込み処理で先に決めておくこと
実装より先に決めておくと、後で作り直しにならない項目が4つあります。
1. 取得する範囲を先に絞る
エリアと期間を決めずに全部取ろうとすると、アクセス制限にも保存先の上限にも当たります。「どの市区町村の、何年分を、何のために見るか」を先に1行で書きます。
2. 上書きか、積み上げか
毎回まるごと入れ替えるのか、日付をつけて追加していくのか。推移を見たいなら後者ですが、行数の増え方が変わるので保存先の選択にも効きます。
3. 取得できなかった日の扱い
APIが応答しなかった日にどうするかを決めておきます。何もしないと「その日のデータが0件」として集計され、グラフが谷になります。実際にはこれが一番よくある事故です。
4. APIキーの置き場所
スクリプトに直接書かない。共有される可能性のあるファイルに置かない。取り込み処理の実行環境側に持たせます。
ダッシュボードを作る前に確認すること
技術的には以上ですが、実務で効くのは別のところです。データ基盤を作っても使われないダッシュボードは、たいてい次のどちらかが決まっていません。
ひとつは誰がいつ見るか。「仕入れ会議の冒頭で、担当者が対象エリアの価格推移を見る」まで決まっていれば残ります。決まっていないダッシュボードは、作った週だけ見られて終わります。
もうひとつはそれを見て何を決めるか。見て終わりの数字は、しばらくすると誰も開かなくなります。「この価格帯を上回ったら見送る」のように、判断の基準とセットにしてはじめてダッシュボードが業務に入ります。
APIの接続方法は調べれば分かります。決まらないのはこの2つのほうです。先に決めてから作ると、作り直しがなくなります。
まとめ
不動産情報ライブラリAPIをBIで使うときは、BIから直接叩かない。認証ヘッダー・GeoJSON・アクセス制限の3つが理由で、特に3つ目は人数が増えてから壊れます。
取り込み層を1つ挟み、保存先はまずスプレッドシートで始める。取得範囲・上書き方針・欠損日の扱い・APIキーの置き場所の4つを先に決める。そして作る前に「誰がいつ見て、何を決めるか」を1行で書いておく。この順番なら、作ったものが残ります。
関連記事
※ APIの仕様・利用条件は変更されることがあります。申請前に国土交通省 不動産情報ライブラリのAPI操作説明で最新の内容をご確認ください。
よくある質問
不動産情報ライブラリAPIをBIツールから直接呼び出せますか？
推奨しません。このAPIは Ocp-Apim-Subscription-Key というヘッダーにAPIキーを載せる方式で、BIツールの標準的なWebコネクタはヘッダー付きリクエストを扱えないものが多いためです。また同一APIキーで短時間に多数のリクエストがあるとアクセス制限がかかる旨が公式に案内されているため、ダッシュボードの表示のたびにAPIを叩く構成は避けるべきです。定期的に取得して保存する層を挟み、BIはその保存先を読む構成にします。
APIキーはどうやって取得しますか？費用はかかりますか？
国土交通省の不動産情報ライブラリで、API利用規約に同意のうえ利用申請を行い、審査・承認を経てAPIキーが発行されます。申請後すぐに使えるわけではない点に注意してください。費用の扱いは公式の利用規約と申請画面で最新の記載を確認してください。
レスポンスはそのまま表計算に貼れますか？
そのままでは扱いにくい形式です。地図系のデータはGeoJSONやPBF（バイナリベクトルタイル）で返るため、表形式に直す変換処理が要ります。BIで使うなら、必要な項目だけを平坦な表に落としてから保存するのが現実的です。
泉 款太（いずみ かんた）
株式会社SalesDock 代表取締役
慶應義塾大学法学部卒。スタートアップ、ラクスル、リクルート（SUUMO）を経て2025年に独立。 中小企業の経営・営業・業務・データをつなぐ事業基盤の設計と実装を支援。 不動産・製造業・クリニックを中心に30社以上の業務改善に携わる。
代表メッセージを読む →