DifyのRAG機能を使って、不動産開発の過去物件検討メモに自然な言葉で質問できるチャットBotを作りました。
「近畿圏で見送った案件と理由を教えて」と聞くと、登録したナレッジをもとに、物件名・エリア・検討時期・判断理由を引用元つきで返してくれます。
📷 画像①：完成したBotに「近畿圏で見送った案件と理由を教えて」と質問し、正しい物件が引用元つきで返ってくる画面
使った技術・ツールはこちらです。
| ツール | 用途 |
|---|---|
| Dify | ノーコードでAIチャットアプリを作成 |
| Gemini API | 回答生成と、検索に使う埋め込み処理 |
| Markdown | 過去物件データの整理 |
この記事では、作ったものの構成・設定手順、そして「一見動いているのに、実はAIが嘘をついていた」失敗とその原因の切り分けまでをまとめます。
※この記事に登場する物件データは、すべて公開用に作成した架空のサンプルです。実在の物件、地権者、賃料等とは関係ありません。
解決したかったこと
不動産開発では、たくさんの候補物件を検討します。
出店を決める案件もあれば、条件が合わずに見送る案件もあります。見送った案件であっても、その判断理由は次の検討に活かせる大事なナレッジです。
一方で、実務では情報がいろいろな場所に散らばりがちです。
- 検討メモが個人のフォルダにある
- 過去資料のファイル名だけでは中身が分かりにくい
- 異動者や新任者が、過去の判断経緯を把握しにくい
- 「あの物件、どうだったっけ？」が人の記憶に頼りがちになる
特に不動産開発では、物件名、エリア、商圏、賃料、交通条件、収益性、行政協議など、判断材料が多くあります。
だからこそ、必要な人が、必要なときに、過去の検討内容へ迷わずたどり着ける状態を作りたいと考えました。
そこで今回は、RAGという仕組みを試してみることにしました。
RAGは、AIに手元の資料を検索させ、その検索結果にもとづいて回答させる仕組みです。AIが何でも自由に答えるのではなく、登録した資料を根拠に答えさせる点が特徴です。
今回は、ノーコードでRAGを試せるDifyを使いました。
作ったもの
過去の物件検討メモをDifyに登録し、自然な言葉で質問すると、該当する案件を整理して返してくれるチャットBotです。
たとえば、
近畿圏で見送った案件と、その理由を教えて
と聞くと、該当する物件について、以下のような情報を一覧で返してくれます。
- 物件名
- エリア
- 検討時期
- 検討結果
- 判断理由
- 参照したナレッジ
ポイントは、単にAIが文章を作るのではなく、登録したナレッジを検索し、その内容にもとづいて回答する形にしたことです。
📷 画像②：回答の下に「引用：bukken_knowledge_sample.md」が表示されている画面
できるようにしたこと
今回のBotでは、主に次の3つを意識しました。
- 複数の物件が該当する場合は、箇条書きで一覧化する
- 坪単価や収益計画などの専門用語は、新任者にも分かるように補足する
- 回答の下に引用元を表示し、根拠を確認できるようにする
業務で使うことを考えると、回答の見やすさだけでなく、「どの資料をもとに答えているのか」を確認できることがとても大切だと感じました。
制作手順
Step 1. ナレッジを用意する
まず、過去の物件検討メモをMarkdownで整理しました。
公開用の記事なので、データはすべて架空のサンプルです。1物件を1つのまとまりとして扱えるように、物件ごとに区切り線を入れました。
---
## 阪奈ニュータウン駅前
- エリア：近畿圏
- 検討時期：2024年
- 検討結果：見送り
- 判断理由：賃料水準が高く、収益計画が成立しにくかったため
---
ここで意識したのは、「AIに読ませるための資料」ではなく、「あとから人間も読み返しやすい資料」にすることです。
📷 画像③：用意したナレッジデータ（Markdown）
Step 2. Difyでチャットフローを作る
Difyでチャットフローアプリを新規作成しました。
最初は、以下のようなシンプルな構成になっています。
スタート → LLM → 回答
このままだと、LLMがユーザーの質問に直接答えるだけです。
過去物件データを参照するためには、途中に知識検索ノードを追加する必要があります。
📷 画像④：作成直後のフロー画面（スタート → LLM → 回答）
Step 3. ナレッジを登録する
Difyのナレッジ機能から、用意したMarkdownファイルをアップロードしました。
このとき、物件ごとに分割されるよう、チャンクの区切りを調整しました。
| 設定項目 | 内容 |
|---|---|
| データ形式 | Markdown |
| 分割単位 | 1物件ごと |
| チャンク識別子 | --- |
| 検索対象 | 物件名、エリア、検討結果、判断理由など |
ナレッジ登録後は、Dify上で各物件がきちんと分割されているかを確認しました。
ここで分割が崩れていると、あとから質問したときに、別の物件情報が混ざる可能性があります。
📷 画像⑤：ナレッジ登録の完了画面（各物件がチャンクに分割されている様子）
Step 4. 知識検索ノードを追加する
次に、チャットフローに知識検索ノードを追加しました。
構成は以下のように変更しました。
スタート → 知識検索 → LLM → 回答
さらに、LLMノードのコンテキストに、知識検索ノードの検索結果を渡すように設定しました。
この設定をしないと、知識検索ノードを置いていても、LLMが検索結果を使わずに回答してしまう可能性があります。
📷 画像⑥：4ノードがつながったフロー全体図と、LLMのコンテキスト設定
Step 5. プロンプトで回答ルールを明記する
LLMには、以下のようなルールを設定しました。
必ず提供されたナレッジの内容にもとづいて回答してください。
ナレッジに記載がない情報は、推測で答えず、
「該当する資料が見つかりませんでした」と伝えてください。
回答では、物件名、エリア、検討時期、検討結果、判断理由を整理してください。
異動者や新任者にも分かるように、専門用語は簡潔に補足してください。
特に大事にしたのは、「資料にないことは推測しない」と明示することです。
RAGでは、ナレッジを参照して答えることが重要です。見た目だけ整った回答よりも、根拠のある回答の方が大切です。
ここからが本番：一見成功、でもAIは嘘をついていた
最初に動かしたとき、画面上ではきれいな回答が返ってきました。
「お、できたかも」と思ったのですが、よく見ると違和感がありました。
同じ質問をするたびに、回答される物件名が変わります。
しかも、その中には自分が登録したナレッジには存在しない物件名が含まれていました。
たとえば、登録していないはずの物件名が、もっともらしい判断理由と一緒に返ってきます。
つまり、AIはナレッジを参照せずに、それらしい物件を作って答えていたのです。
RAGを使っているつもりでも、検索が正しく動いていなければ、AIはもっともらしい回答を作ってしまう。
ここが今回いちばん大きな学びでした。
📷 画像⑦：自分のデータに存在しない物件を答えてしまっている画面（失敗例）
症状：知識検索の結果が0件だった
原因を確認するために、Difyの実行ログを見ました。
すると、知識検索ノードの出力が次のようになっていました。
{
"result": []
}
検索結果が空でした。
つまり、LLMに渡すべきナレッジが何も渡っていない状態です。
そのため、LLMは資料にもとづいて答えることができず、想像で回答を作っていたと考えられます。
📷 画像⑧：知識検索ノードの出力が "result": [] になっている画面
切り分けたこと
最初は、ナレッジの作り方やDifyの設定を疑いました。
そこで、次の順番で確認しました。
| 確認したこと | 結果 |
|---|---|
| ナレッジの中身 | 正しく登録されていた |
| チャンク分割 | 物件ごとに分かれていた |
| 知識検索ノードの接続 | フロー上は接続されていた |
| LLMへのコンテキスト連携 | 設定されていた |
| ナレッジ単体の検索テスト | それでも0件だった |
データも設定も大きく間違っていない。
それでも検索結果が0件になる。
この時点で、Difyの画面設定ではなく、検索に使う処理そのものに問題があるのではないかと考えました。
原因：Gemini APIの無料枠超過
実行ログをさらに確認すると、埋め込み処理で以下のエラーが出ていました。
429 RESOURCE_EXHAUSTED
Quota exceeded
当時の環境では、Gemini APIの無料枠を使い切っており、ナレッジ検索に必要な埋め込み処理が動いていませんでした。
その結果、知識検索ノードの検索結果が空になり、LLMには参照すべき資料が渡っていなかったのです。
データの作り方やDifyの設定ミスではなく、APIの利用上限に達していたことが原因でした。
解決：従量課金を有効化して検索が復旧
Gemini APIで従量課金を有効化したところ、ナレッジ検索が動くようになりました。
ナレッジ単体の検索テストでも、質問に対して正しい物件データがヒットするようになりました。
📷 画像⑨：検索テストで正しい物件がヒットした画面
その後、Botに同じ質問をすると、今度は登録した物件情報にもとづいた回答が返ってきました。
さらに、回答の下には引用元も表示されるようになり、どのナレッジを参照したのか確認できる状態になりました。
「資料にないこと」について質問した場合も、推測で答えずに、
該当する資料が見つかりませんでした。
と返すようになりました。
ここでようやく、RAGとして使える状態になったと感じました。
📷 画像⑩：ナレッジに無い質問に「該当する資料が見つかりませんでした」と返す画面
もう一つの発見：全文検索とハイブリッド検索の違い
検索が復旧したあと、検索方式によって結果が変わることにも気づきました。
一時的に全文検索を使っていたとき、「2024年に出店決定した案件は？」と聞いても、該当データがあるのに「見つかりません」と返ってくることがありました。
検索方式をハイブリッド検索に戻すと、該当する物件が正しくヒットしました。
📷 画像⑪：全文検索では取りこぼし、ハイブリッド検索では正しくヒットした比較
違いを整理すると、以下のようになります。
| 検索方式 | 特徴 | 今回起きたこと |
|---|---|---|
| 全文検索 | 文字の一致で探す | 表記が少しずれると取りこぼすことがあった |
| ハイブリッド検索 | 文字の一致と意味の近さを組み合わせて探す | 質問文とナレッジの表現が違ってもヒットしやすかった |
不動産開発の検討メモでは、「出店決定」「出店判断済み」「事業化」など、似た意味でも表現が揺れることがあります。
そのため、単純な文字一致だけでなく、意味の近さも見てくれるハイブリッド検索の方が相性が良いと感じました。
ただし、ハイブリッド検索では埋め込み処理が重要になります。
今回のように埋め込みが動いていないと、本来の検索精度が出ません。
工夫したこと
今回、特に工夫したのは次の3点です。
1. 「推測しない」ルールを明記した
AIは、分からないことでも自然な文章で答えてしまうことがあります。
そのため、プロンプトには「ナレッジにない情報は推測しない」と明記しました。
業務で使う場合、もっともらしい回答よりも、分からないときに分からないと言えることの方が大切です。
2. 検索しやすい項目でナレッジを整理した
物件メモをそのまま登録するのではなく、検索されそうな切り口を意識して整理しました。
- エリア
- 検討時期
- 検討結果
- 判断理由
- 賃料
- 商圏
- 交通条件
こうした項目をそろえておくと、あとから自然な言葉で質問したときにも検索しやすくなります。
3. 引用元を確認できる形にした
回答の根拠が分からないと、業務では使いにくいです。
引用元が表示されることで、回答を見たあとに元の資料へ戻ることができます。
これは、AIを「判断する道具」として使うというより、「必要な資料へたどり着く入口」として使う感覚に近いと思いました。
実際に動かしてみた結果
実際に動かしてみると、過去の検討内容を自然な言葉で引き出せるようになりました。
たとえば、
- 近畿圏で見送った案件を教えて
- 賃料が理由で見送った案件はあるか
- 2024年に出店決定した案件を教えて
- 交通条件が課題になった物件を教えて
のように、頭の中の疑問をそのまま聞ける感覚は想像以上に便利でした。
一方で、今回の試作で分かったのは、AIの回答画面だけを見て安心してはいけないということです。
きれいな文章が返ってきても、それが正しいとは限りません。
RAGでは、少なくとも次の点を確認する必要があると感じました。
- 検索結果が空になっていないか
- 回答に引用元が表示されているか
- ナレッジにないことを推測で答えていないか
- 検索方式が目的に合っているか
- 埋め込み処理が正しく動いているか
特に今回のように、APIの利用上限が原因で検索が止まっている場合、画面上はBotが動いているように見えてしまいます。
この「動いているように見えるけれど、実は根拠がない」状態に気づけたことが、一番の収穫でした。
今後やってみたいこと
今回は架空データでの試作でしたが、実務で使うことを考えると、まだ検討すべきことがあります。
- 実データを扱う場合の機密情報管理
- 閲覧権限の設計
- 登録する資料フォーマットの統一
- 報告書や検討メモの入力ルール整備
- 既存店活性化事例など、ナレッジ対象の拡張
- チームで使う場合の運用ルール
特に重要：入力フォーマットのテンプレート化
実務で使う場合、入力データのフォーマット統一が大きなポイントになります。物件メモの書き方が担当者によってバラバラだと、検索精度や回答の安定性に影響が出るためです。
たとえば、以下のような必須項目をテンプレート化しておくことで、より安定して使える仕組みになると考えています。
## 物件名
- エリア：
- 検討時期：
- 検討結果：（見送り／継続検討／出店決定）
- 判断理由：
- 賃料：
- 商圏：
- 交通条件：
入力する資料の形が揃っていると、検索結果も安定しやすくなります。逆に言えば、AIツールを導入する前段階として、資料の形を整えることが重要だと今回の試作で感じました。
まとめ
今回は、Difyを使って、不動産開発の過去案件に自然な言葉で質問できるナレッジBotを作ってみました。
作ってみて感じたのは、AI活用で大切なのは、AIに何でも答えさせることではなく、正しい情報にたどり着ける状態を作ることだということです。
特にRAGでは、
- 検索結果が空になっていないか
- 回答に引用元が出ているか
- ナレッジにないことを推測で答えていないか
を確認することが重要だと分かりました。
過去案件の検討メモは、放っておくと個人の記憶やフォルダの奥に埋もれてしまいます。
でも、少しずつナレッジ化していけば、異動者や新任者も過去の判断にアクセスしやすくなります。
まずは架空データでの小さな試作ですが、「必要な人が、必要なときに、過去の検討内容へ迷わずたどり着ける状態」に近づける第一歩になりました。