---
title: "不動産価格のAI予測｜国交省APIのデータ取得から精度検証・AI査定の誤差率の読み方まで"
url: "https://www.issoh.co.jp/tech/details/2385/"
published: 2024-06-10
updated: 2026-10-26
categories: ["AI"]
publisher: "株式会社一創"
---

# 不動産価格のAI予測｜国交省APIのデータ取得から精度検証・AI査定の誤差率の読み方まで

不動産価格のAI予測でつまずくのは、モデル選びより**データの入手と精度の測り方**です。学習データをどこから取るのか、どの列を特徴量に入れてよいのか、出てきた誤差率を各社のAI査定の公表値と比べてよいのか。国土交通省のAPI仕様を確認したうえで、取得と前処理のコード、精度を偽装する列の見分け方、分割方法と指標による評価のぶれを、公開データでの実測値つきで整理します。

## まとめ

- **データ入手**：国土交通省「不動産情報ライブラリ」のXIT001が実質的な標準。申請制で、旧「土地総合情報システム」のAPIは令和6年3月末で廃止され、ドメインごと消えている。
- **位置の情報が薄い**：XIT001の出力29項目に最寄駅や緯度経度は無い。地区名で粒度を上げ、駅はXPT001が返す最寄り駅の点で補う。
- **リーク列**：坪単価・平方メートル単価は面積と組めば価格が決まる列。入れると誤差率が3分の1から4分の1に縮むが、本番では埋まらない。
- **手を入れる順番**：実測では3つのモデルの差が0.63ポイント、特徴量を3列から10列に増やした効果が4.26ポイント。特徴量が先。
- **誤差率は定義をそろえて比べる**：AI査定の公表値（リハウスAI査定MER 4.89%、SRE 誤差中央値5.6%）は中央値。同じ予測で平均（MAPE）は10.69%、中央値は6.75%と4ポイント近く開く。
- **業務で出すとき**：媒介で価格に意見を述べるなら宅建業法34条の2第2項で根拠の明示が要る。AIの数字だけでは根拠にならない。

## 予測対象の切り分け｜取引価格・成約価格・分譲価格の違い

最初に、何の価格を当てにいくのかを決めます。公開データで扱える価格は2種類で、XIT001のパラメータ `priceClassification` がこの区別です。`01` が不動産取引価格情報、`02` が成約価格情報で、指定できる期間は取引価格が2005年から（2005年は第3・第4四半期のみ）、成約価格が2021年からです。

取引価格情報は、[国土交通省の不動産取引価格情報提供制度](https://www.mlit.go.jp/totikensangyo/totikensangyo%5Ftk5%5F000069.html)によるもので、平成18年4月から取引当事者へのアンケート調査をもとに蓄積され、令和7年3月31日時点で約547万件です。アンケート由来なので全取引ではなく、件数も偏っています。累計は宅地（土地と建物）1,998,331件、宅地（土地）1,873,353件、中古マンション等893,567件に対し、農地466,257件、林地237,408件で、農地や林地のモデルは学習データが1桁少ないところから始まります。

新築分譲マンションの販売価格を網羅した公開データセットはありません。分譲価格は売主が決める提示価格で、成約後の取引価格とは性質が違います。新築の値付けを予測したいなら、周辺の中古取引価格や地価から相対的に推定することになります。本記事は、取引価格を目的変数に置いた回帰問題を扱います。

## 学習データの入手先｜国土交通省API（XIT001）の仕様と申請

### エンドポイントと必須パラメータ

不動産情報ライブラリは都市計画・防災・周辺施設まで含めて30種類以上のAPIを公開しており、価格予測の中心は [XIT001「不動産価格（取引価格・成約価格）情報取得API」](https://www.reinfolib.mlit.go.jp/help/apiManual/xit001/)です。ホストは `www.reinfolib.mlit.go.jp` です。

| 項目                    | 内容                                   |
| --------------------- | ------------------------------------ |
| パス                    | `/ex-api/external/XIT001`            |
| 認証                    | HTTPヘッダー `Ocp-Apim-Subscription-Key` |
| year（必須）              | 取引時期（西暦4桁）                           |
| quarter               | 四半期（1〜4）                             |
| area / city / station | 都道府県 / 市区町村 / 駅コード（1つ以上必須）           |
| priceClassification   | 01＝取引価格、02＝成約価格、未指定＝両方               |
| language              | ja / en（未指定は日本語）                     |
| レスポンス                 | gzipエンコードされたJSON                     |
| データが無いとき              | HTTP 404                             |

全国を一度に取ることはできないので、対象エリアの市区町村コードを列挙してループで回します。市区町村コードは `XIT002`（都道府県内市区町村一覧取得API）で取れます。駅コードは国土数値情報の駅データのグループコードを使いますが、対応する駅データが無いコードでは400エラーになるため、失敗したら市区町村指定に切り替えてください。

APIキーは申請制で、利用者種別（法人・法人以外の団体・個人）を選んで利用約款に同意して申し込みます。審査結果の通知は申請後5営業日が目安です。キーを付けずに叩くと401で `missing subscription key`、無効なキーなら401で `invalid subscription key` が返ります（2026年10月26日に確認）。401が返るならエンドポイントまでは届いている、という切り分けに使えます。

### 旧「土地総合情報システム」APIの終了

多くの解説記事やサンプルコードが、今も `www.land.mlit.go.jp/webland/api/` 配下のURLを載せています。かつてAPIキーなしで呼べたためです。このシステムは国土交通省が令和6年3月末で廃止したと告知しており、取引価格情報は令和6年4月から不動産情報ライブラリへ移りました。

しかもホスト名がDNSから消えています。パブリックDNS（8.8.8.8、1.1.1.1）に `www.land.mlit.go.jp` と `land.mlit.go.jp` を問い合わせると応答はNXDOMAINで、同じ `mlit.go.jp` 配下の `www.mlit.go.jp` は正常に解決します。旧URLのコードはHTTPエラーではなく名前解決の失敗で止まるので、エラーの出方で見分けられます。

### 取得コード｜gzipの展開と404の扱い

公式の[API操作説明](https://www.reinfolib.mlit.go.jp/help/apiManual/)には、データが無い場合の挙動が書かれています。タイルを指定するAPIは200と空の配列を返すのに対し、XIT001・XIT002・XCT001の3つは**HTTP 404**を返します。市区町村×四半期でループを回すと、取引が無い組み合わせは普通に出てくるので、404をエラー扱いにすると途中で止まります。同じページはリクエスト数の明確な上限は無いとしつつ、連続して実行しないよう求めているので、間隔も空けます。

```
import time
import requests

URL = "https://www.reinfolib.mlit.go.jp/ex-api/external/XIT001"
HEADERS = {"Ocp-Apim-Subscription-Key": "＜申請して発行されたAPIキー＞"}

def fetch(year, quarter, city, price_classification="01"):
    params = {"year": year, "quarter": quarter, "city": city,
              "priceClassification": price_classification}
    r = requests.get(URL, headers=HEADERS, params=params, timeout=30)
    if r.status_code == 404:          # 該当データが無い年・四半期・市区町村は404で返る
        return None
    r.raise_for_status()
    return r.json()                   # gzip は requests が自動で展開する

def fetch_all(cities, years, quarters=(1, 2, 3, 4), wait=1.0):
    out = {}
    for city in cities:
        for y in years:
            for q in quarters:
                out[(city, y, q)] = fetch(y, q, city)
                time.sleep(wait)      # 連続実行しないよう間隔を空ける
    return out

# 中央区の 2015年第2四半期・取引価格情報のみ
payload = fetch(2015, 2, "13102")
# 公式の出力例は空欄のまま掲載されている。レコード配列の入るキーは最初の1回を目視で確かめる
print(type(payload), str(payload)[:300])
```

公式のPythonサンプルは `urllib.request` を使い、`Content-Encoding` がgzipなら `gzip.decompress()` を呼ぶ作りですが、import文は `urllib.request` と `json` の2つだけです。そのまま貼るとgzipで返った時点で `NameError` になるので、`import gzip` を足すか、上のように `requests` に展開を任せてください。また、公式の「＜出力例＞」の欄は空のままで、レスポンスのトップレベルの形は書かれていません。キーを取得したら最初の1回はレスポンス全体を出力して確認します。

## 前処理｜文字列型のレスポンスと有効数字2桁の丸め

XIT001の出力は、取引価格も面積も建蔽率も、仕様上すべて文字列型です。値の無い項目は空文字で返るとみておくのが安全で、そのまま `pandas.DataFrame` に渡すと数値列がobject型のまま残り、学習の直前で落ちます。建築年は「1972年」、取引時点は「2015年第2四半期」という日本語混じりの表記なので、専用のパーサが要ります。

```
import re
import pandas as pd

# XIT001 の項目はすべて文字列型で返り、値の無い項目は空文字になる。
LEAKY = ("PricePerUnit", "UnitPrice")   # 取引価格から作られた列＝説明変数にできない

def to_num(s):
    """'85000000' -> 85000000.0 / '' や非数値 -> None
    ※「2000以上」のような上限つきの表記は数値だけを拾うため、実データで有無を確認する"""
    if s is None:
        return None
    s = re.sub(r"[^\d.]", "", str(s))
    return float(s) if s else None

def build_year(s):
    """'1972年' -> 1972 / 変換できない値 -> None"""
    m = re.match(r"(\d{4})年", str(s or ""))
    return int(m.group(1)) if m else None

def period_index(s):
    """'2015年第2四半期' -> 8061（四半期の通し番号）"""
    m = re.match(r"(\d{4})年第(\d)四半期", str(s or ""))
    return int(m.group(1)) * 4 + int(m.group(2)) - 1 if m else None

def to_frame(records):
    df = pd.DataFrame(records)
    df = df.drop(columns=[c for c in LEAKY if c in df.columns])
    for col in ("TradePrice", "Area", "TotalFloorArea", "Frontage",
                "Breadth", "CoverageRatio", "FloorAreaRatio"):
        if col in df.columns:
            df[col] = df[col].map(to_num)
    df["build_year"] = df["BuildingYear"].map(build_year)
    df["t"] = df["Period"].map(period_index)      # 時点分割にも使う
    df["age"] = df["t"] // 4 - df["build_year"]   # 取引時点の築年数
    return df.dropna(subset=["TradePrice", "Area"])
```

建築年が空文字のレコードは `build_year` と `age` がNaNになり、取引価格と面積が揃っている行だけが残ります。四半期を通し番号にしておくと、後で時点による分割に使え、時間トレンドを表す特徴量としても単調増加の数値で渡せます。建築年の欠損は土地のみの取引で自然に出るため、平均で埋めると土地と建物付きが混ざります。取引の種類（`Type`）で先に分けてから扱ってください。

目的変数そのものにも前提があります。この制度の取引価格は**有効数字2桁に丸められている**と国土交通省が明記しており、8,500万円は「85」の精度でしか与えられません。影響を測るため、後述のAmes Housingの価格を有効数字2桁に丸めたところ、丸めだけで平均1.36%ずれました。丸めた値で学習・評価したMAPEは10.81%で、丸めない場合の10.69%から0.12ポイントの悪化です。誤差10%規模の段階では支配的ではありません。

## 位置情報の特徴量｜XIT001に駅と座標が無いときの補い方

制度の概要には提供する情報として「最寄駅」が挙がっていますが、XIT001の出力29項目には最寄駅名・駅からの距離・緯度経度のいずれも無いことを、2026年10月26日の仕様ページで確認しました。位置を表すのは都道府県・市区町村・地区名（`DistrictName`、町・大字レベル）と地区コード（`DistrictCode`）です。不動産価格は立地で大きく動くので、この欠落をどう補うかで精度が変わります。

### 地区名で粒度を上げる効果の実測

位置の粒度がどれだけ効くかを、Ames Housingの近隣地区（`Neighborhood`、25地区）で測りました。基本10列のLightGBMに地区をカテゴリ型で足すと、MAPEは10.69%から9.61%へ1.08ポイント下がり、誤差±10%以内に収まる物件の割合は61.1%から67.4%に増えました。一方で誤差率の中央値は6.75%から6.89%とほぼ動いていません。地区の情報は、立地を読み違えて大きく外していた物件を減らす方向に効いているということです。

XIT001では `DistrictName` がこの役割を担います。ただし地区コードはデータ更新のたびに変わることがあり、過去に取得したコード・地区名との継続性は保証しないと仕様に明記されています。学習データと推論時のデータを取得時期をまたいで結合するなら、コードだけでなく市区町村コードと地区名の組で照合し、一致しない行を数えておいてください。地域を表す列を数値のまま渡すと、コードの大小に意味があるかのように学習されるので、pandasのcategory型に変えます。

### XPT001による最寄り駅の位置情報の補完

駅の情報は、[XPT001「不動産価格（取引価格・成約価格）情報のポイント（点）API」](https://www.reinfolib.mlit.go.jp/help/apiManual/xpt001/)で補えます。仕様は「対象となる不動産の最寄り駅のポイントを返却します」としており、返る点は物件の位置ではなく**最寄り駅の位置**です。同じ点に複数の取引がぶら下がります。物件ごとの緯度経度が取れるAPIではないので、駅単位の特徴量（駅の点、駅ごとの取引件数や価格水準）を作る用途に使います。

XPT001は地図タイルで範囲を指定します。必須パラメータは `response_format`（geojson または pbf）、ズームレベル `z`（11〜15）、タイル座標 `x`・`y`、取引時期 `from`・`to`（西暦4桁と四半期1桁を続けた5桁。取引価格は20053から）です。緯度経度からタイル座標は次の式で出せます。公式の使用例 `z=14&x=14624&y=6016` のタイル中心を逆算すると北緯43.06度・東経141.34度で、出力例の札幌市中央区と一致しました。

```
import math

def tile_xy(lat, lon, z):
    """緯度経度 -> XYZタイル座標（Webメルカトル）"""
    n = 2 ** z
    x = int((lon + 180.0) / 360.0 * n)
    y = int((1.0 - math.asinh(math.tan(math.radians(lat))) / math.pi) / 2.0 * n)
    return x, y

print(tile_xy(35.6812, 139.7671, 14))   # 東京駅付近 -> (14552, 6451)

params = {"response_format": "geojson", "z": 14, "x": 14552, "y": 6451,
          "from": "20241", "to": "20244", "landTypeCode": "07"}   # 07＝中古マンション等
```

XPT001の属性は表示用の文字列で、取引価格は「4,000万円」、面積は「90㎡」のように単位つきで返ります。学習用の数値はXIT001から取得できます。ただし両APIの仕様には共通の取引IDがないため、XPT001の駅の点を個別レコードへ一意に結合できるとは限りません。照合できない場合は地域単位の集計にとどめます。周辺環境は、同じライブラリの国土数値情報（駅別乗降客数）API、将来推計人口250mメッシュAPI、洪水浸水想定区域などの防災情報APIをタイル単位で引いて特徴量にできます。特徴量の作り方そのものは[特徴量エンジニアリングとは？変換・選択・自動化の工程と実装判断【2026年版】](/tech/details/15843/)で扱っています。

## リークする列の見分け方｜単価列を入れた場合の実測

XIT001のレスポンスには `PricePerUnit`（坪単価）と `UnitPrice`（平方メートル単価）があります。価格に効きそうに見えますが、**単価と面積が分かれば取引価格は一意に決まります**。予測したい価格が分からなければ埋まらない列なので、特徴量に入れると答えを渡して答えを当てさせることになります。

数字がどれだけ変わるかを、[OpenMLの house\_prices](https://www.openml.org/search?type=data&id=42165)（米国アイオワ州エイムズ市の住宅取引1,460件。2006〜2010年の売買時点つき）で測りました。居住面積・築年・敷地面積・総合品質・総合状態・地下室面積・車庫台数・浴室数・部屋数・改築年の10列（`GrLivArea`、`YearBuilt`、`LotArea`、`OverallQual`、`OverallCond`、`TotalBsmtSF`、`GarageCars`、`FullBath`、`TotRmsAbvGrd`、`YearRemodAdd`）を基本セットとし、「価格÷居住面積」で作った単価列を足すかどうかで比べています。目的変数は対数変換しています。時点分割では乱数シード0・1・2の予測を価格に戻して平均し、その予測で指標を算出しました。ランダムCVでは各シードのMAPEを平均しています。実行環境はPython 3.13.14、scikit-learn 1.9.1、LightGBM 4.7.0です。モデルの設定はLightGBMが `n_estimators=400`・`learning_rate=0.05`、ランダムフォレストが300本の木で、重回帰とランダムフォレストは欠損を中央値で埋めています。以降の表はすべてこの条件で、本文のXIT001用コードとは入力列が違います。

| 特徴量       | ランダム5分割CV   | 時点で分割（2010年をテスト） |
| --------- | ----------- | ---------------- |
| 基本10列     | MAPE 10.78% | MAPE 10.69%      |
| 基本10列＋単価列 | MAPE 3.39%  | MAPE 2.69%       |

誤差率が3分の1から4分の1に縮みます。本番で新しい物件を予測するときにその物件の単価はまだ分からないので、この精度は再現しません。見分け方は、**その列は予測する時点で手に入るのか**を1列ずつ確かめることです。目的変数から算術的に作られた列、成約後にしか確定しない列、目的変数を含む集計値が典型です。分割方法や前処理に起因するリークは[交差検証とは？分割手法の選び方とデータリーク対策を実装目線で解説【2026年版】](/tech/details/16353/)にまとめています。

## モデル選択より効くもの｜手法の差と特徴量の差

### 重回帰・ランダムフォレスト・LightGBMの予測誤差比較

同じAmes Housingで、2010年の売買175件をテストに回して3つのモデルを比べました。国内の取引データとは市場も通貨も違うので絶対値は持ち込めませんが、手法間の差の大きさを見る目安になります。

| モデル       | MAPE（平均） | 誤差率の中央値 | ±10%以内 | 学習＋予測1回 |
| --------- | -------- | ------- | ------ | ------- |
| 重回帰       | 11.18%   | 7.94%   | 62.9%  | 0.10秒   |
| ランダムフォレスト | 10.55%   | 6.44%   | 64.6%  | 1.29秒   |
| LightGBM  | 10.69%   | 6.75%   | 61.1%  | 0.54秒   |

最良と最悪の差はMAPEで0.63ポイントです。今回の条件ではランダムフォレストがLightGBMをMAPEで0.14ポイント上回りました。この規模の差は特徴量の選び方や乱数で入れ替わる、ということです。仕組みは[LightGBMとは？勾配ブースティングの仕組みと特徴・XGBoostとの違いを実装例つきで解説](/tech/details/3919/)と[決定木分析とは？分類木・回帰木の仕組みと過学習を防ぐ剪定・アンサンブルを実装目線で解説](/tech/details/15206/)で扱っています。

### 特徴量3列・10列・36列での誤差変化

| 特徴量（LightGBM） | 列数 | MAPE   | 誤差率の中央値 |
| ------------- | -- | ------ | ------- |
| 面積・築年・敷地のみ    | 3  | 14.95% | 10.44%  |
| 品質評価や間取りを追加   | 10 | 10.69% | 6.75%   |
| 数値列をすべて投入     | 36 | 9.36%  | 5.58%   |

3列から10列にしただけで4.26ポイント改善し、モデルの差し替えで動く0.63ポイントの6倍以上です。XIT001でいえば、用途地域（`CityPlanning`）、建蔽率、容積率、前面道路の幅員、建物の構造、地区名を素通りさせずに使いきるのが先です。列の意味と重要度の見方は[特徴量とは？機械学習での意味と作り方・重要度の見方を実装目線で解説【2026年版】](/tech/details/15842/)を参照してください。

## 精度検証の設計｜分割方法と評価指標の選び方

### ランダム分割と時点分割の使い分け

手元の数字が本番で出るかは、分割の仕方で決まります。ランダムな交差検証は学習データに未来の取引が混ざるため、価格水準が動く市場では甘い評価になります。ただし常に起きるわけではありません。Ames Housingの年別中央価格は2006年の163,995ドルから2010年の155,000ドルまでほぼ横ばいで、ランダムCV 10.78%に対し時点分割10.69%と差が出ませんでした。

そこで、取引時点を特徴量に入れたうえで、価格に年率の値上がりだけを人工的に与えて乖離を測りました。

| 年率トレンド   | ランダムCV | 時点分割   | 乖離       |
| -------- | ------ | ------ | -------- |
| 0%（元データ） | 10.70% | 10.65% | \-0.05pt |
| 5%       | 10.72% | 10.85% | +0.13pt  |
| 10%      | 10.86% | 11.95% | +1.09pt  |
| 15%      | 10.95% | 12.79% | +1.84pt  |

ランダムCVの数字はトレンドが強くなってもほぼ動きません。前後の時期の取引が学習側に入るので、値上がりを内挿できてしまうためです。この実験では、時点分割で学習期間より先の価格を予測すると誤差が増えました。実運用を再現するには、取引時点だけでなく、そのデータが予測時点で公表済みだったかも確認します。**市場が動いている局面ほど、ランダムCVの値は実力から離れる**ことになります。

国内市場の動きは、[国土交通省の不動産価格指数](https://www.mlit.go.jp/totikensangyo/totikensangyo%5Ftk5%5F000085.html)（住宅・全国・原系列、2010年平均＝100）で見られます。[公表データ（Excel）](https://www.mlit.go.jp/totikensangyo/content/001473668.xlsx)の「全国Japan原系列」シートで月次値を年ごとに平均すると、マンション（区分所有）は2015年121.0に対して2025年217.8で、10年間の年平均成長率は6.05%です。上の表の5%と10%の間にあたるので、国内の取引データで学習するなら時点で分けた検証を標準にしてください。同じ指数でも住宅総合は年率3.28%、住宅地1.97%、戸建住宅1.86%で、マンションだけが突出しています。

この指数は公表が止まっています。国土交通省は令和8年9月28日付で、算出プログラムの不具合により令和8年6月・第2四半期分の公表を延期すると告知し、令和8年1月〜5月分と令和7年第4四半期・令和8年第1四半期分も延期中で、新しい公表日は決まっていません。2026年10月26日時点で入手できる最新は令和7年12月分で、マンションの原系列は221.2です。指数を特徴量や補正に使っているパイプラインは、更新が止まった状態でも動くように組んでおきます。

```
import numpy as np
import lightgbm as lgb
from sklearn.metrics import mean_absolute_percentage_error

# df は前処理済み、t は四半期の通し番号（period_index の出力）
CUTOFF = df["t"].max() - 4            # 直近4四半期をテストに回す
for col in ("MunicipalityCode", "DistrictName"):
    df[col] = df[col].astype("category")   # 地域は数値でなくカテゴリ
train, test = df[df["t"] <= CUTOFF], df[df["t"] > CUTOFF]

FEATURES = ["Area", "TotalFloorArea", "age", "CoverageRatio", "FloorAreaRatio",
            "MunicipalityCode", "DistrictName", "t"]

model = lgb.LGBMRegressor(n_estimators=400, learning_rate=0.05, random_state=0)
model.fit(train[FEATURES], np.log(train["TradePrice"]))   # 対数で学習し
pred = np.exp(model.predict(test[FEATURES]))              # 予測時に戻す

ape = np.abs(pred - test["TradePrice"]) / test["TradePrice"]
# 各指標は割合で表示する（例：0.1069 は 10.69%）。
print("MAPE", mean_absolute_percentage_error(test["TradePrice"], pred))
print("誤差率の中央値", np.median(ape), "±10%以内", (ape <= 0.10).mean())
```

### MAE・RMSE・MAPEの違い｜高額物件が指標に与える影響

同じ予測結果でも、平均絶対誤差（MAE）は19,355ドル、二乗平均平方根誤差（RMSE）は36,029ドル、平均絶対パーセント誤差（MAPE）は10.69%でした。RMSEが大きく出るのは、誤差を二乗するため外れの大きい物件に引っぱられるからです。

テストの価格上位10%（175件中18件）だけで、二乗誤差の総和の66.0%を占めていました。件数で約1割の高額物件が、二乗誤差総和の約3分の2を占めています。価格帯で分けると、MAPEは下位90%で10.50%、上位10%で12.34%と近いのに、MAEは15,477ドルと53,180ドルで3.4倍開きます。価格の幅が数百万円から数億円まで広がる対象では、価格帯によらず比べられるMAPEか誤差率の中央値を主指標にし、金額の実感はMAEで併記するのが扱いやすい組み合わせです。RMSEは、高額帯の外れを特に嫌う要件があるときに使ってください。

## AI査定の精度の読み方｜誤差率の中央値と平均の違い

本記事で紹介するリハウスAI査定とSRE AI査定CLOUDの公表値は、いずれも**誤差率の中央値**です。[三井不動産リアルティの「リハウスAI査定」の発表](https://www.mf-realty.jp/news/2019/re%5Fpdf/20191216%5F02%5F01.pdf)（2019年12月16日）は、首都圏1都4県でMER 4.89%、全国で5.34%としています。MER（Median Error Rate）は、推定成約価格と実際の成約価格の差の絶対値を成約価格で割った誤差率の中央値で、過去に成約事例がある物件を対象に2019年11月1日時点で算出した値です。[SREホールディングスの2026年3月18日の発表](https://sre-group.co.jp/news/2026/260318.html)は「SRE AI査定CLOUD」について「誤差中央値5.6％の査定精度」と書いています。

本記事で測ったMAPEは**平均**なので、そのままでは比べられません。同じLightGBMの予測で両方を出すと、MAPEは10.69%、誤差率の中央値は6.75%で、4ポイント近く開きます。大きく外れた少数の物件が平均だけを押し上げるためです。自前モデルのMAPE 10%を見て「市販のAI査定の倍も悪い」と判断するのは早計です。中央値に定義をそろえても、市場・物件種別・評価期間・検証条件が異なるため、この数値差からサービスとの性能差は判断できません。

公表値を自社の判断に使うときは、次の4点を確かめます。

- **定義**：中央値か平均か。SREは2026年6月30日の発表で「業界水準の9～10%に対して5.6%」と書いていますが、注記によると9〜10%は公開データに基づく同社の試算で、5.6%は実績値と導入事例に基づく試算値です。基準のそろわない比較は参考にとどめます。
- **対象**：リハウスAI査定は全国18都道府県のマンション約30,000棟が対象です。同じ棟の過去事例があるマンションは当てやすく、土地や戸建の精度とは別物です。
- **時点**：2019年の値を、価格が年率6%で動いた後の市場にそのまま当てはめない。
- **外れの割合**：中央値は半分の物件の誤差しか語りません。±10%以内に何割が入るか、最大でどれだけ外れるかを別に聞きます。今回の実測では中央値6.75%でも、±10%を超えた物件が38.9%ありました。

不動産業界でのAI査定やテック企業の領域の全体像は[不動産テックとは？カオスマップ第12版が示す14領域と自社の投資領域の決め方](/column/details/17262/)で整理しています。

## 予測値を業務で使う線引き｜宅建業法の根拠明示と鑑定評価

予測モデルを社内の相場観に使うだけなら規制はかかりませんが、媒介の場面で価格を伝えるなら法令の枠に入ります。[宅地建物取引業法34条の2第2項](https://laws.e-gov.go.jp/law/327AC1000000176)は「前項第二号の価額又は評価額について意見を述べるときは、その根拠を明らかにしなければならない」と定めています。

根拠の中身は、[国土交通省の「宅地建物取引業法の解釈・運用の考え方」](https://www.mlit.go.jp/totikensangyo/const/content/001881261.pdf)（令和8年4月1日施行版）が、不動産流通推進センターの価格査定マニュアルかこれに準じたもの、または「同種の取引事例等他に合理的な説明がつくもの」としています。書面で示すなら、不動産鑑定評価法に基づく鑑定評価書でないことを明記し、他の目的に使わないよう依頼者に求めます。根拠の明示は法律上の義務なので、査定にかかった費用は依頼者に請求できません。

モデルの予測値をこの根拠にするには、数字だけでなく説明が要ります。実装としては、予測と一緒に条件の近い取引事例を数件並べ、どの特徴量が価格を押し上げたか（下げたか）を物件ごとに出せるようにしておくのが現実的です。個別の予測の寄与を示す手法は[モデル解釈性とは？説明可能性との違いとSHAP・LIMEの選び方を実装目線で解説](/tech/details/16357/)で扱っています。

もう一つの線は鑑定評価です。[不動産の鑑定評価に関する法律](https://laws.e-gov.go.jp/law/338AC0000000152)36条1項は「不動産鑑定士でない者は、不動産鑑定業者の業務に関し、不動産の鑑定評価を行つてはならない」と定めています。画面や帳票ではAIによる参考推定値であることを明示してください。法の適用は名称だけで決まるものではなく、評価行為の内容や報酬・業務形態も確認する必要があります。鑑定評価書が必要な場面では、予測モデルは鑑定士の作業を補助する位置づけにとどまります。

査定支援や価格予測の仕組みを自社のデータで作るときは、データ取得から検証設計までを含めて[生成AI開発・AI受託開発](/service/ai/development/)で支援しています。

## 運用フェーズの設計｜再学習頻度・外れ値・出典表示

**再学習の頻度**は、価格指数の過去の伸び率だけでは決まりません。物件種別ごとに直近期間の予測誤差と許容誤差を比較し、データの公表時期も踏まえて更新頻度を決めます。XIT001が取引時期を四半期で区切っているので、四半期ごとに直近データを足して学び直し、そのたびに直近四半期をテストにした誤差を記録するのが実務的です。誤差が悪化し始めたら、市場の変化か特徴量の劣化かを切り分けます。

**外れ値**も方針を決めておきます。実際の取引には、通常の市場取引とは言えない事情を抱えたものが混ざります。XIT001の `Remarks`（取引の事情等）が空でないレコードを除くか残すかを決め、除いた件数を記録してください。目的変数の対数変換は極端な高額物件の影響を抑えるので、本記事の実測でも前提にしています。

**出典の表示**も必要です。成果物を外部に出す場合は、不動産情報ライブラリの利用約款とコンテンツの出典に関する規定を確認し、出典を明記します。

## よくある質問

### 不動産価格の予測に必要なデータは無料で手に入りますか？

国土交通省の不動産情報ライブラリのAPIは利用料がかからず、申請して発行されるAPIキーで使えます。ただし審査結果の通知は申請後5営業日が目安で、承認とAPIキーの発行を待つ必要があります。検証の日程に申請期間を織り込んでください。

### 不動産のAI査定の精度はどのくらいですか？

公表値では、リハウスAI査定がMER（誤差率の中央値）で首都圏4.89%・全国5.34%（2019年11月1日時点・マンション）、SREのAI査定CLOUDが誤差中央値5.6%です。いずれも中央値です。平均と中央値の大小は誤差の分布しだいですが、大きく外れる物件が少数混ざる価格予測では平均の方が大きく出やすく、本記事の実測でも平均（MAPE）は中央値より4ポイント近く大きくなりました。土地や戸建、取引事例の少ない地域では精度が下がるので、対象と定義をそろえて比べてください。

### 自前で作るなら、どのくらいの誤差率を目標にすればよいですか？

本記事の公開データでの実測では、素直な10列の特徴量でMAPE 10.69%、誤差率の中央値6.75%でした。目標は、既存の査定業務が持つ誤差と同じ定義で比べて決めるのが現実的です。数字が異様に良いときはリーク列を、悪いときは分割方法と位置の特徴量の欠落を先に疑ってください。

### ディープラーニングを使えば精度は上がりますか？

本記事の比較対象は重回帰・ランダムフォレスト・LightGBMで、ディープラーニングは比較していません。表形式のデータでは、まずLightGBMなどを比較基準に置き、ディープラーニングの追加効果を同じ時点分割の条件で測ってください。物件写真や間取り図を入力に加える場合は、画像を扱えるモデルが候補に入ります。

### 需要予測のような時系列の手法を使った方がよいですか？

個別物件の価格を当てる問題は、取引時点を特徴量の一つに持つ回帰として扱うのが基本です。市場全体の価格水準を将来に外挿したい場合は時系列の手法が向いており、選び分けは[需要予測アルゴリズムの選び方と実装手順｜時系列・機械学習・Python](/tech/details/15335/)で整理しています。

## 関連記事

- [LightGBMとは？勾配ブースティングの仕組みと特徴・XGBoostとの違いを実装例つきで解説](/tech/details/3919/)
- [交差検証とは？分割手法の選び方とデータリーク対策を実装目線で解説【2026年版】](/tech/details/16353/)
- [特徴量エンジニアリングとは？変換・選択・自動化の工程と実装判断【2026年版】](/tech/details/15843/)
- [モデル解釈性とは？説明可能性との違いとSHAP・LIMEの選び方を実装目線で解説](/tech/details/16357/)
- [不動産テックとは？カオスマップ第12版が示す14領域と自社の投資領域の決め方](/column/details/17262/)

---

出典: [不動産価格のAI予測｜国交省APIのデータ取得から精度検証・AI査定の誤差率の読み方まで](<https://www.issoh.co.jp/tech/details/2385/>)（株式会社一創）