AI商圏分析と賃料予測の実務|開発企画を公開35APIとレンジ設計で組む

都市の高層ビル群

AI商圏分析とは、公開データでエリアの需給を推定する手法のことです。

国土交通省の不動産情報ライブラリは、2026年8月の確認時点で35本の公開APIを揃えています。不動産取引価格、地価公示・地価調査、用途地域、立地適正化計画、都市計画道路、駅別乗降客数、250mメッシュ単位の将来推計人口。開発企画で商圏を読むための材料は、この数年で「探しに行くもの」から「取りに行けるもの」へ変わりました。現場で詰まるのは入手ではなく、集めた層をどう重ねて賃料の見立てに変換するかの設計です。本記事は、宅建業免許(東京都知事(1)第113520号)を保有し、AI導入コンサル100社超の実績を持つ株式会社オルセル(不動産のチカラ運営)の現場知見にもとづいて解説します。

以下では、無料で使える公的データの現在地、賃料を4つの層に分解する考え方、開発企画の3つの意思決定でAIに渡す範囲の切り分け、プロンプト7本を順に置きます。賃料の推定値は参考値であり、事業として進めるかどうかの判断は企画責任者と宅地建物取引士が持つ。この前提を崩さない設計が、AIを企画部門へ入れるときの分岐点でした。

商圏分析の材料は、どこまで無料で揃うのか

先に結論を書くと、開発の一次検討で必要な地理・人口・価格の層は、2026年8月時点でほぼ無料の公的データだけで組めます。有償の商圏分析サービスが担っていた役割のうち、データ調達の部分は公開APIに置き換わりつつある、という理解が実務に近い。

不動産情報ライブラリのAPIは、APIキーをリクエストヘッダーの Ocp-Apim-Subscription-Key に載せてHTTPSで呼ぶ設計です。出力はPBF(バイナリベクトルタイル)とGeoJSONの2形式で、GeoJSONを選べばそのまま集計・分析に回せます。利用申請の審査結果は、申請後5営業日を目安にメールで通知される運用でした。ブラウザから直接叩くとCORSで弾かれるため、サーバ側かローカルのスクリプトから呼ぶ形になります。リクエスト数の明確な上限は公表されていませんが、連続実行を避けるよう案内されている点は運用設計に織り込んでおきたい。

商圏分析で効くAPIを具体名で挙げると、XIT001の不動産価格(取引価格・成約価格)情報、XPT002の地価公示・地価調査ポイント、XKT013の250mメッシュ別将来推計人口、XKT015の駅別乗降客数、XKT002の用途地域、XKT003の立地適正化計画、XKT030の都市計画道路、XKT031の人口集中地区の8本です。整備範囲にも差があり、取引価格情報は2005年第3四半期以降、成約価格情報は2021年第1四半期以降と公表されています。成約価格の蓄積が5年強しかないことは、推定モデルを組むうえで最初に押さえる制約でした。

地図データそのものは国土数値情報ダウンロードサイトから直接落とせます。250m・500m・1kmの各メッシュ別将来推計人口(R6国政局推計)、駅別乗降客数、地価公示、行政区域といったデータが並びます。ここで見落とされやすいのがライセンス表記です。同じサイト内でCC BY 4.0のもの、商用可のもの、非商用のものが混在しており、データごとに使用許諾条件が違います。社内資料にとどめるなら気にならない差ですが、投資家向け資料やウェブサイトへ転載する段階で問題化します。ダウンロードの時点で、データ名とライセンス区分を対で記録しておくのが定石です。

人口と世帯の詳細は総務省統計局のe-Stat API機能から取ります。バージョン3.0で小地域・地域メッシュデータの取得に対応しており、町丁・字レベルの人口・世帯構成を機械的に引けます(利用にはユーザ登録が必要)。地図上で目視確認したいときは統計地理情報システム(jSTAT MAP)が無償で使え、商圏の輪郭を描いてから数値を取りに行く順序が組みやすい。将来側は国立社会保障・人口問題研究所の日本の地域別将来推計人口(令和5年推計)で、令和2(2020)年から令和32(2050)年までの1,884地域分が公開されています。

価格の水準感は2つの一次情報で押さえます。ひとつは地価公示です。国土交通省が2026年3月17日に公表した令和8年地価公示は、全国26,000地点を調査対象とし、全用途平均・住宅地・商業地のいずれも5年連続で上昇しました。全用途平均と商業地は上昇幅が拡大し、住宅地は前年と同じ上昇幅にとどまっています。三大都市圏のうち名古屋圏は上昇幅が縮小し、地方四市(札幌市・仙台市・広島市・福岡市)も縮小に転じた点は、エリア判断で見落とせない差でした。もうひとつは不動産価格指数で、年間およそ30万件の取引価格データをもとに月次で公表されています。令和7年11月分の公表値は住宅総合が147.3(前月比0.7%増)、商業用不動産が147.2(前期比1.1%増)でした。指数は改定と月次更新が入るため、企画書に載せるときは同ページで最新の公表分を確認してください。

出典を追いながら散在情報を集める工程については、Perplexityで不動産の相場リサーチと商圏分析を行うで手順を整理しています。API調達とリサーチ型AIは、代替ではなく分担の関係にあります。

賃料は4つの層の掛け算で決まる

賃料の推定を精度よく回すには、賃料を単一の数字として扱うのをやめ、4つの層に分解するのが早い。層ごとにデータ源と更新頻度が違うため、混ぜたまま推定すると、どの前提が崩れて外れたのかが後から追えなくなります。

第1層は立地スコアです。最寄駅までの距離、その駅の乗降客数、商業施設・医療機関・学校の分布、幹線道路への接続。XKT015の駅別乗降客数とXKT006の学校、XKT010の医療機関を重ねれば、候補地の生活利便を機械的に点数化できます。この層は年単位でしか動かないため、一度作れば使い回しが効きます。

第2層は需給です。将来推計人口の増減だけを見るのは危険で、世帯数の増減と世帯規模の変化を分けて見る必要があります。人口が減っても単身・二人世帯が増えるエリアでは、住戸数の需要は落ちません。供給側の実像としては、総務省統計局の令和5年住宅・土地統計調査で、2023年10月1日時点の総住宅数6,504万7,000戸に対し空き家900万2,000戸、空き家率13.8%と公表されました。うち賃貸・売却用と二次的住宅を除く空き家が385万戸です。全国平均をエリア判断に直接持ち込むことはできませんが、既存ストックの余剰がどこまで賃料の上限を抑えるかという論点は、企画の初期に置いておきたい。

第3層は商品企画です。専有面積、間取り、設備水準、共用部の作り。同じ立地でも25平米の単身向けと55平米の二人以上世帯向けでは、坪単価も想定入居者も別物になります。この層は自社で動かせる変数であり、複数案を並べて比較させる使い方が向いています。

第4層は市況です。金利、建築費、投資市場の資金流入。不動産価格指数の推移が指標のひとつになりますが、この層は最も予測が当たらない領域でした。推定に織り込むより、感度分析の変数として外に出すほうが実務に耐えます。

4層を掛け合わせた結果を、単一の数字で出さないこと。ここが賃料予測でいちばん事故る箇所です。「この住戸の想定賃料は月11万2,000円」と書かれた企画書は、読み手に検証の余地を与えません。第25パーセンタイル・中央値・第75パーセンタイルの3点で幅を示し、その幅がどの前提から出たのかを併記する。この形にすると、上振れケースと下振れケースで収支がどう動くかを会議の場で確認できます。査定精度の指標そのものの読み方については、AI家賃査定の精度をMERで見抜くで誤差率中央値の扱いを整理しました。

賃料や地価の将来水準を断定する記述は、企画書でも記事でも避けるべきものです。推定は参考値であり、募集賃料の最終決定は現地の反響と競合の動きを見て人が判断する。この線引きを文書に明記しておくと、社内でもオーナーとの協議でも、数字の性格をめぐる齟齬が減ります。

開発企画の3つの意思決定で、AIに渡す範囲を分ける

デベロッパーの企画部門がAIを入れるとき、業務単位ではなく意思決定単位で切ると設計が楽になります。用地取得の可否、プランの決定、募集賃料の設定。この3つで、機械に任せられる比率がまったく違いました。

用地取得の一次スクリーニングは、AIの比率を最も高くできる工程です。候補地の住所リストを起点に、用途地域・建蔽率・容積率、災害リスク区域との重なり、最寄駅の乗降客数、周辺500メートル圏の世帯数推移を機械的に取得し、社内の除外条件に引っかかるものを落とす。ここまでは公開データと定型処理で完結します。候補を絞り込む工程の設計は不動産開発のAI市場調査と用地選定で層別に扱っています。

プランの決定になると、AIの役割は案の生成と比較の整理に移ります。住戸ミックス(単身向け・DINKS向け・ファミリー向けの比率)、平均専有面積、設備水準の3変数を振り、それぞれの想定賃料レンジと想定稼働率の組み合わせを並べさせる。判断そのものは人が行いますが、比較の下ごしらえが消える分、検討できる案の数が増えます。現場で繰り返し見るのは、案を3つしか作れなかったために最良案を取り逃す型の失敗でした。

募集賃料の設定は、AIの比率を意図的に下げる工程です。理由は3つあります。第1に、募集賃料は現地の反響という未観測データに依存します。第2に、成約価格情報の整備が2021年第1四半期以降であり、賃貸の成約データは価格情報ほど公開されていません。第3に、賃料設定は入居者への説明責任と直結する経営判断です。AIには、レンジの提示と、近隣競合との相対位置の整理までを担わせる。単価表として確定させる作業は、企画責任者が現地の情報を足して決める形が現実的です。

3工程に共通するのは、AIの出力に「留保条件」を書かせておくことです。どのデータをいつ時点で取ったか、どの前提が崩れたら結論が変わるか。この2点が出力に含まれていれば、半年後に前提を洗い直すときの再現性が担保されます。

商圏分析と賃料予測で使うプロンプト7本

以下の7本は、商圏の輪郭を決める工程から企画会議用の要約まで、順番に通して使う設計です。変数は中括弧で囲んでいるので、自社のフォーマットに置き換えてください。長文の資料を丸ごと読ませる工程では1Mトークンのコンテキストを持つClaude Opus 5、素早い一次整理ではGPT-5.5 InstantやGemini 3.6 Flash、という分担が2026年8月時点では扱いやすい組み合わせでした。

最初に決めるのは商圏の輪郭です。行政区界で切ると生活圏とずれるため、鉄道・道路・河川・地形で区切る発想に変えます。

プロンプト1:商圏の輪郭定義とデータ取得計画

あなたは日本の不動産開発における市場調査の実務担当者です。
以下の候補地について、賃貸住宅の商圏をどう区切るべきかを検討し、
必要なデータの取得計画を作ってください。

候補地情報:
- 所在地:{住所}
- 最寄駅と徒歩分数:{駅名/徒歩X分}
- 想定用途:{賃貸マンション/賃貸アパート/その他}
- 想定規模:{総戸数}

作業手順:
1. 一次商圏(徒歩10分圏を想定)と二次商圏(自転車・バス圏)の
   境界を、鉄道路線・幹線道路・河川・地形・行政区界の順で検討し、
   採用した境界とその理由を示す
2. 一次商圏・二次商圏それぞれについて、収集すべきデータ項目を列挙する
3. 各項目について、国土交通省の不動産情報ライブラリ、国土数値情報、
   e-Stat、自治体の都市計画情報のうちどこから取得できるかを示す
4. 取得できないと予想される項目は「現地調査が必要」として別枠にする

出力形式:
- 商圏定義(境界と理由)
- データ取得計画(項目/取得元/想定更新頻度)
- 現地調査が必要な項目のリスト
制約:推測でデータの数値を書かないこと。取得先の提示までにとどめる。

商圏が決まったら人口と世帯を読みます。人口の増減だけを見ると誤読するため、世帯規模の変化まで出させます。

プロンプト2:人口・世帯動態の読み取り

以下は{エリア名}について、e-Statの小地域集計と
国立社会保障・人口問題研究所の地域別将来推計人口から取得した数値です。
賃貸住宅の需要という観点で読み解いてください。

データ:
{町丁字別の人口/世帯数/世帯人員をここに貼付}
{市区町村単位の将来推計人口(2020年・2030年・2040年・2050年)を貼付}

分析してほしい観点:
1. 人口の増減トレンドと、世帯数の増減トレンドの乖離
2. 平均世帯人員の変化から読める世帯構成のシフト
3. 年齢階級別の構成変化(生産年齢人口の比率に注目)
4. 賃貸需要が想定される層(単身・二人世帯・単身高齢)の規模と方向
5. このデータからは判断できないこと

出力の条件:
- 各指摘に、根拠となった数値を漏れなく併記する
- 将来推計は確定した未来ではなく仮定にもとづく推計として扱い、
  推計であることを明示する
- 「賃料が上がる/下がる」といった断定は書かない

立地の良さを言葉で語ると比較ができません。候補地間で比べるために、点数化のルールを先に決めます。

プロンプト3:立地スコアの設計と採点

賃貸住宅の立地評価スコアを設計し、以下の候補地を採点してください。

評価軸の候補(重みは合計100点で配分し、配分理由を明示):
- 鉄道アクセス(最寄駅の乗降客数、都心主要駅への所要時間、乗換回数)
- 徒歩利便(駅距離、スーパー・コンビニ・ドラッグストアまでの距離)
- 生活施設(医療機関、小中学校、保育施設の分布)
- 道路・駐車(幹線道路への接続、駐車場需要の想定)
- 法規制・都市計画(用途地域、建蔽率・容積率、立地適正化計画の区域区分)
- 災害リスク(洪水浸水想定、土砂災害警戒区域、液状化傾向)

候補地データ:
{候補地A/B/Cの各項目の実測値・取得値を貼付}

出力:
1. 重み配分表とその根拠
2. 候補地ごとの項目別スコアと合計点
3. スコアが拮抗した場合に決め手になる追加調査項目
制約:データが無い項目は0点にせず「未取得」と明示し、
      合計点は未取得を除いた満点比で示すこと。

需給ギャップは、競合の棚卸しなしに出せません。近隣の募集在庫を実データで集めた前提で使います。

プロンプト4:競合供給の棚卸しと需給ギャップ推定

以下は{エリア名}の賃貸住宅の募集在庫データです。
需給のバランスを整理してください。

競合データ(自社で収集した募集情報):
{物件名/築年/総戸数/間取り/専有面積/募集賃料/募集開始からの経過日数}

需要側データ:
{プロンプト2で整理した世帯構成の要約を貼付}

整理してほしい内容:
1. 間取り・専有面積帯ごとの募集在庫数と、募集期間の分布
2. 築年帯ごとの賃料水準の差(同一面積帯で比較)
3. 需要側の世帯構成と供給側の間取り構成のずれ
4. 供給が薄い面積帯・設備条件の候補
5. この分析の弱点(データの偏り、収集漏れの可能性)

注意:
- 募集賃料と成約賃料は別の指標なので混同しない
- 募集期間が長い物件は、賃料が市場水準より高い可能性を示すが、
  他の要因もあり得るため断定しない

ここで賃料のレンジを出します。単一値を出させないことが、このプロンプトのいちばんの狙いです。

プロンプト5:賃料レンジの推定と前提の明示

以下の条件で計画している賃貸住宅について、
募集賃料の参考レンジを推定してください。

計画条件:
- 所在地・最寄駅:{住所/駅名・徒歩X分}
- 竣工予定:{年月}
- 住戸タイプ:{間取り/専有面積/階数/向き}
- 設備水準:{主要設備を列挙}

参照データ:
{プロンプト4で整理した競合の賃料一覧を貼付}
{プロンプト3の立地スコアを貼付}

出力条件:
1. 参考レンジを第25パーセンタイル・中央値・第75パーセンタイルの
   3点で示す(単一の数値では出さない)
2. 各点の算出根拠となった競合物件を具体的に挙げる
3. 立地スコア・築年・設備差による補正を、補正額と理由の対で示す
4. レンジの上限側・下限側それぞれについて、
   その水準になる場合の条件を1文で書く
5. 「この推定が外れる条件」を3つ挙げる
6. 末尾に「本推定は参考値であり、募集賃料の決定は現地の反響と
   競合動向を確認した上で企画責任者が行うこと」と明記する

禁止事項:
- 将来の賃料水準を断定する表現
- 参照データに存在しない物件名・数値の生成

推定を出しただけでは精度が分かりません。自社の既存物件で誤差を測る工程を、導入初期に組み込みます。

プロンプト6:推定精度のバックテスト設計

自社が保有・管理する既存物件を使って、
賃料推定の精度を検証する手順を設計してください。

利用可能なデータ:
{既存物件の一覧/竣工年/間取り/専有面積/募集開始時の賃料/
 成約賃料/募集から成約までの日数}

設計してほしい内容:
1. 検証対象の選び方(サンプル数、エリアの分散、竣工年の分散)
2. 推定値と実績値の比較指標(誤差率、誤差率の中央値、
   レンジ内に実績が入った割合)
3. 誤差が大きく出やすい物件タイプの見立て方
4. 検証結果をもとに補正ルールを更新する頻度と手順
5. 検証に使うデータのうち、個人情報にあたるものの取り扱い方針

条件:
- 入居者の氏名・連絡先・勤務先などの個人情報は
  検証データから除外する前提で設計する
- 誤差の目標値を先に決めず、まず現状値を測る手順にする

最後は会議用の1枚です。判断材料と留保条件を分けて書かせるのが要点になります。

プロンプト7:企画会議用の1枚要約

以下の商圏分析・賃料推定の結果を、企画会議で使う1枚の要約にまとめてください。

入力:
{プロンプト1〜6の出力をまとめて貼付}

要約の構成:
1. 結論(3行以内):この候補地で進めるべきか、追加調査が必要か
2. 判断の根拠(5項目以内):それぞれに数値と出典を併記
3. 想定賃料レンジ(3点)と、そのレンジが前提としている条件
4. 留保条件:現時点で確認できていない事項と、確認方法
5. この案件を見送るべきシナリオ(2つ)
6. データ取得日と、次回見直しの推奨タイミング

書き方の条件:
- 数値には出典を併記し、出典が無い数値は載せない
- 「推定」「参考値」「未確認」の区別が読み手に伝わる書き方にする
- 断定調で書ける部分と、留保が必要な部分を段落で分ける
- 分量はA4で1枚に収まる範囲

精度を落とす4つのパターンと、その手当て

商圏分析でAIを使い始めた企画部門が、最初の3か月でつまずく型はおおむね決まっていました。

ひとつ目は、商圏を行政区界で切ってしまうことです。市区町村や町丁字の境界はデータの取得単位としては便利ですが、通勤・買い物の動線とは一致しません。線路や大きな河川で分断されたエリアを1つの商圏として扱うと、需給の見立てが実態から離れます。手当ては、境界の設定理由を文書に残す運用にすること。プロンプト1で境界と理由を対で出させているのは、この記録を自動的に残すためでした。

ふたつ目は、募集賃料と成約賃料を混ぜることです。ポータルサイトから集めた募集情報は募集賃料であり、実際に契約された金額とは差が出ます。この2つを同じ列に並べて平均を取れば、推定値は上振れします。募集情報を使うなら募集期間の長さを併記し、成約データは自社の実績かレインズなど業務用データベースで確認できる範囲にとどめる、という切り分けが安全です。

3つ目は、将来推計人口を確定した未来として扱うことです。社人研の推計は令和2年国勢調査を基礎とした仮定計算であり、実際の人口移動が想定と違えばずれます。2050年の推計値を根拠に30年の事業収支を組むのは、前提の脆さに対して結論が重すぎる。推計は方向性の確認に使い、収支の前提には複数シナリオを置く扱いが望ましい。

4つ目は、顧客データをそのままAIに投入することです。入居希望者の氏名・連絡先・勤務先・収入情報を含むファイルを商圏分析のために生成AIへ貼り付ける運用は、個人情報の保護に関する法律の観点から避けるべきものです。商圏分析に要るのは属性の集計値であって個人の識別情報ではありません。エリア・年齢階級・世帯類型まで集計してから投入する前処理を、業務手順に組み込んでおく。

これらに加えて頻度が高いのが、AIが参照データに存在しない物件名や数値を生成してしまう型です。プロンプト側で「参照データに存在しない数値の生成を禁止する」と明示し、出力の各数値に出典を併記させるルールを入れておくと、検出が容易になります。企画書に載せる前に、出典欄が空の行を機械的に抜き出して確認する工程を挟んでください。

費用と工数の目安、そして測る指標

初期費用は、生成AIのサブスクリプションだけで始められます。2026年8月時点の月額は、ChatGPT Plusが20米ドル、Claude Proが20米ドル、Google AI Proが20米ドル前後という水準です。為替と改定で変動するため、契約前に各社の料金ページで確認してください。公的データ側は、不動産情報ライブラリのAPIも国土数値情報もe-Stat APIも無償で、要るのは利用申請とユーザ登録の手続きだけでした。不動産情報ライブラリは審査完了まで5営業日が目安なので、案件が動き出す前に申請を済ませておくのが実務的です。

工数の目安は、1エリアの一次調査で担当者1名が半日から2日かけていたものが、データ取得の自動化とプロンプトの型化で1時間から2時間に収まる水準です。ただしこれは2回目以降の数字で、初回はスクリプトの整備とプロンプトの調整に3日から5日程度かかると見ておきたい。GIS環境をゼロから整えるなら、さらに1週間程度の学習期間を積んでおくと計画が崩れません。いずれも現場感覚での目安です。

測る指標は4つに絞ると運用が続きます。第1に、一次スクリーニングの通過率です。候補地100件を機械的に処理して何件が二次検討に進み、そのうち何件が取得に至ったかを追う。この2段の歩留まりが、スクリーニング条件の妥当性を映します。第2に、レンジ内的中率です。募集開始後の成約賃料が、推定した第25〜第75パーセンタイルの幅に入った割合を3か月ごとに集計すれば、補正ルールの更新タイミングが見えてきます。

第3に、募集開始から1か月の申込件数です。賃料設定が市場水準に合っていれば申込は初月に集まり、高すぎれば募集期間が伸びます。推定の精度を最終的に評価するのは、この現場の数字でした。第4に、企画書の差戻し回数です。根拠不足や出典欠落で企画会議から戻される回数を導入前後の3か月で比べると、社内での定着度が把握できます。

投資判断に直結する数値を扱う業務なので、KPIには精度だけでなく説明可能性を含めておきたい。出典が併記された数値の割合、留保条件が書かれた企画書の割合。この2つを測っている企画部門は、AIの出力を巡る社内の摩擦が小さい傾向にあります。

予測の精度より、前提の説明可能性が問われる

この領域で3年後に効いてくるのは、推定の精度そのものではなく、推定の前提を説明できる状態を保てているかどうかだと考えています。

理由は、データ供給側の変化の速さにあります。不動産情報ライブラリのAPIは公開本数が増え続けており、都市計画道路や高度利用地区のように、以前は自治体の窓口で図面を確認するしかなかった情報がAPIで取れるようになりました。データが増えれば、同じデータを使う競合との差はデータ量では付かなくなる。差が出るのは、どの層をどう重ねて何を問うかという設計と、それを他者に説明できるかどうかです。

モデル側の性能も、この方向を後押ししています。2026年7月24日に公開されたClaude Opus 5は1Mトークンのコンテキストを扱い、出力は最大128Kトークンです。都市計画マスタープラン、立地適正化計画、周辺の開発許可情報をまとめて読ませて横断的に整理させる作業が、分割なしで通るようになりました。GPT-5.6 Solのような推論重視のモデルは数値の整合性チェックや前提の矛盾検出に向き、Gemini 3.6 Flashのような軽量高速モデルは大量の候補地を一次篩にかける処理に適しています。3社を使い分ける前提で業務を設計するほうが、単一モデルに寄せるより結果が安定するケースが多い。

もう一歩先を見ると、商圏ダッシュボードの自動更新が現実的な範囲に入ってきます。公開APIから毎月データを取得し、前月との差分から担当エリアの需給の変化を通知する。技術的にはすでに組める構成です。ただし自動化が進むほど、出力を読む側のリテラシーが問われます。推計と実測の区別、募集と成約の区別、参考値と確定値の区別。この3つが組織に定着していないところに自動更新のダッシュボードを置くと、誰も検証しない数字が独り歩きします。

賃料や地価の将来水準は、金利・建築費・人口移動・政策という複数の変数に依存し、断定できるものではありません。令和8年地価公示でも、名古屋圏と地方四市は上昇幅が縮小に転じました。全国の傾向を個別エリアに当てはめる読み方では、この種の分岐を捉えられない。AIに任せるべきは、材料を漏れなく集め、比較可能な形に整え、前提を明示することまでです。そこから先の意思決定は宅地建物取引士と企画責任者が担う。この境界を業務手順として明文化しておくことが、AIを企画部門に定着させる条件だと判断しています。

よくある質問

AI商圏分析は無料のデータだけで始められますか

はい、一次検討の範囲であれば無料の公的データだけで始められます。不動産情報ライブラリのAPI、国土数値情報ダウンロードサイト、e-Stat APIとjSTAT MAPは、いずれも利用申請やユーザ登録のみで無償です。有償になるのは生成AIのサブスクリプション(2026年8月時点で月20米ドル前後)と、募集在庫や成約データを扱う業務用データベースの部分です。

賃料予測の精度はどのくらい出ますか

サービスやモデルによって差が大きく、単一の数字で語ることはできません。精度を比べるときは、誤差率の中央値がどのエリア・どの物件条件・どの時点で測られたものかを確認してください。自社での運用は、既存物件を使ったバックテストで現状値を測ってから目標を決める順序が現実的です。

AIが出した賃料をそのまま募集賃料にしてよいですか

いいえ、推定値は参考値として扱い、募集賃料の決定は現地の反響と競合動向を確認した上で企画責任者が行う前提にしてください。理由は、募集賃料が未観測の需要要因に依存すること、賃貸の成約データが公開情報として限られていること、賃料設定が入居者やオーナーへの説明責任と直結する経営判断であることの3点です。

ChatGPTとClaudeとGeminiのどれを使うべきですか

用途で分けるのが実務的です。計画資料や競合データを大量にまとめて読ませる工程は1Mトークンのコンテキストを持つClaude Opus 5、数値の整合性チェックはGPT-5.6 Solのような推論重視のモデル、候補地の一次篩のような高速処理はGemini 3.6 Flashが向きます。2026年8月時点の構成なので、モデル更新のたびに見直す前提で組んでください。

顧客情報をAIに入れて商圏分析してもよいですか

避けるべき運用です。入居希望者の氏名・連絡先・勤務先・収入といった個人情報を、同意のないまま生成AIへ投入する運用は個人情報の保護に関する法律の観点で問題になります。商圏分析に要るのは属性の集計値なので、エリア・年齢階級・世帯類型まで集計してから投入してください。

最初の一歩は何から始めればよいですか

不動産情報ライブラリのAPI利用申請と、e-Statのユーザ登録の2つから始めるのが早いです。利用開始まで5営業日程度を見込むため、案件が動く前に済ませておく。その間に自社の既存物件データで賃料の実績値を整理しておくと、バックテストの土台がそろいます。

参考文献


著者:齋藤竹紘(株式会社オルセル 編集長/宅建業免許 東京都知事(1)第113520号/AI導入支援100社超/EC支援19年5,000社超のノウハウを不動産×AIに横展開)


※不動産のチカラでは、生成AIの導入支援から運用最適化まで、貴社の不動産事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://fudosannochikara.jp/contact/


【監修】齋藤竹紘(株式会社オルセル代表 / EC支援19年5,000社超・AIコンサル100社超 / 宅建業免許 東京都知事(1)第113520号)