Buy Houses Japan事例：AI住宅検索をプロダクトスプリントで形にする

Buy Houses Japanは、Urbano DXが自社で開発し、現在も運用している公開プロダクトです。希望条件を自然文で入力すると、それが編集可能な構造化フィルターに変換され、地図付きの検索結果につながります。対象エリアは関東、関西、九州。UIは日本語と英語に対応し、通貨はUSD/JPY、面積は㎡/sqftを切り替えられます。

この事例が有効なのは、資料やコンセプト画像ではなく、実際に触れるWebアプリだからです。狭いプロダクト仮説を、AIを含む動く体験へ落とし込む流れがそのまま確認できます。

公開中のプロダクトはこちらから開けます：buyhouses.jp。

プロダクト課題

従来の物件検索は、最初から細かい条件を選ぶ前提になりがちです。条件が明確に決まっている人には便利ですが、検索が文章から始まる場面では使いづらくなります。

「駅に近い、静かなファミリー向けの家」

「庭があって、街へ出やすい物件」

「日当たりが良く、通勤しやすいモダンな部屋」

Buy Houses Japanは、このような自然な希望を構造化された検索意図へ変換します。プロダクト上の問いはシンプルです。AIは、最初の検索ステップを買い手の考え方に近づけられるか。

もう一つ、日本の物件データそのものに由来する課題があります。掲載元のポータルごとに、間取り、駅からの徒歩分数、権利形態、用途地域といった項目の書き方も粒度もばらばらで、そのままでは横並びに比較できません。加えて、海外の買い手にとってはこれらの表記に対応する概念がそもそも母国語に存在しません。使えるプロダクトにするには、表記の揺れた掲載情報を一つの比較可能なスキーマへ正規化し、しかも意味を取り違えたまま訳さないことが条件になります。

その下にある技術的な問いも同じくらい重要です。モデルの解釈をどう「見える化」すれば、モデルそのものを信用しなくても結果を信頼できるのか。答えは、解析結果を編集可能なフィルターとして画面に出し、AIが埋めた値も手動で組んだ条件もまったく同じ検索経路を通す、という設計です。

構築したもの

スプリントの形は、Urbano DXが日本企業向けに提供するプロダクト開発と同じです。1つのユーザーワークフローを特定し、UIを作り、主要ロジックを接続し、テストできる形にします。

実際のクエリで挙動を示します。「quiet family home near a train station in Osaka with a garden under 30 million yen」と入力すると、システムは4つのフィルターを生成します。都道府県は大阪、物件種別は一戸建て、上限価格、最低寝室数は3。この状態で該当物件は429件、18ページに分けて表示されます。

重要なのは、この4つが「AIの出力そのもの」として画面に残る点です。フィルターパネルでは、AIが埋めた値の隣に、地域、間取り条件、価格と広さといった通常の手動フォームが並びます。寝室数を4に上げる、上限価格を動かす、物件種別を外す。どれもその場で書き換えられ、結果は即座に更新されます。ユーザーはモデルを信用する必要がなく、モデルが何を読み取ったかを見て直すだけで済みます。

結果はカードリストと、価格ピンを載せた地図の並列表示です。物件詳細では、日本語の元データを正規化した項目、物件種別、間取り（3LDKなど）、権利形態、築年、最寄駅と交通アクセス（日本語のまま保持）、用途地域、建物面積と土地面積を表示します。あわせて、清潔感の評価、リフォーム状況、関連度スコア（例：92% Relevance）、相場との比較（例：Above market +30%、Great value -44%）といった導出値、写真と間取り図のギャラリー、元の掲載ページへのリンクを載せています。

正規化された日本語項目、間取り図ギャラリー、関連度スコアと相場比較を表示する物件詳細

土台の構成は、あえて手堅いものにしています。

フロントエンド。 React 18 + Vite（ビルドはBun）。地図はMapLibre GL（react-map-gl）。検索入力、フィルターパネル、結果リスト、地図がすべて同じクエリ状態を共有します。

バックエンド。 FastAPI（Python）とMongoDB（motor + beanie）。自然文の解釈は自社のLLMゲートウェイ経由で行い、結果は構造化されたフィルター集合として返します。

検索。 構造化フィルターに対する決定論的な絞り込みに、zvecによるベクトル検索を組み合わせています。件数もページングも、ユーザーが画面で見ているフィルターから計算されます。

データ取り込み。 Prefectのパイプラインが、AtHomeやNiftyなど主要な国内不動産ポータルをPlaywright / Scraplingで巡回し、表記の揺れた掲載情報を共通スキーマへ正規化します。

周辺。 認証はFirebase、決済はStripe。

価値はAI処理だけではありません。曖昧な希望を、使えるソフトウェアワークフローへ変える全体の流れにあります。AIが担うのはその一部で、残りは地に足のついた通常のプロダクトエンジニアリングを丁寧に積み上げた結果です。実際、日本語の物件データを正規化する工程のほうが、自然文の解析よりはるかに手間がかかっています。

法人のご担当者にとって重要な理由

実用的なAIプロダクトの多くは、単体のチャットボットではありません。曖昧な入力を構造化されたアクションへ変える、狭く定義されたワークフローです。

同じパターンは、問い合わせの一次振り分け、書類受付、社内ナレッジ検索、管理ツール、CRM業務、レポートにも使えます。ユーザーが出力を信頼し、修正し、次の行動へ進めるようにするには、UIの設計が効いてきます。Buy Houses Japanを成立させている構造は、そのまま転用できます。

会話を装わない自由文入力。

ユーザーから見える構造化中間表現。

その表現に紐づく編集可能なコントロール。

モデルが触らない決定論的な実行ステップ。

生成ではなく比較のためにデザインされた結果画面。

この構造があれば、問い合わせ対応は「チャットボットのデモ」ではなく実際に回る一次振り分けになり、ナレッジ検索は「流暢な回答」ではなく根拠付きの推奨になります。「AI機能」と「AIプロダクト」の違いは、この中間表現が存在するか、そしてユーザーがそれを編集できるかです。

この事例が示すこと

Buy Houses Japanは、シニアエンジニア主導のプロダクトデリバリーを示す具体例です。

摩擦の大きい1つのユーザージャーニーから始める

判断に必要な画面を中心にアプリを作る

AIがワークフローを良くする場所にだけ使う

出力を見える形、直せる形、検証できる形にする

地味な工程であるデータ取り込みと正規化を、一級の仕事として扱う

これは、有償PoCやMVPスプリントにも通じる進め方です。最初の版は、プラットフォーム全体を装うのではなく、プロダクトの道筋を証明するべきです。Urbano DXへのスプリント発注を検討されている法人のご担当者にとって、稼働しているプロダクトは最も誠実なリファレンスです。アーキテクチャも設計上の判断も画面に出ていますし、429件を返したあの検索は誰でもその場で再現できます。