はじめまして。開発部の小関と髙木です。
今回は弊社のサービスである「飲食店ドットコム 店舗物件探し」の機能として、生成AIを活用した物件登録補助機能を提供することになったので、開発の進め方と実装した機能についてお話できればと思います。
飲食店ドットコム 店舗物件探し
まず、弊社のサービスである「飲食店ドットコム 店舗物件探し」について紹介いたします。本サービスは、飲食店が得意な物件探しサイトとなっており、店舗に強い不動産会社と提携することで、多数の店舗物件や居抜き物件を掲載しております。掲載されている物件には、最寄駅や賃料など物件情報が満載となっております。
機能開発の背景とプロジェクトの流れ
まず、機能開発に至る背景とプロジェクト進行の流れを大まかに触れておきます。
弊社では2023年から生成AIの利活用を実験的に始めており、運営するサービスの一部で生成AIを用いた新機能の開発やリリースを行い、徐々に開発ノウハウを溜めてきていました。
そのノウハウを他サービスにも横展開できないかと検討している中、弊社の「飲食店ドットコム 店舗物件探し」サービスにおいて、物件情報を登録する入力作業の手間を短縮させられないかという話が挙がっていました。 不動産会社の担当者は、基本的には不動産会社の店頭に掲載されているような物件の概要、間取り図、地図などをまとめた資料である「マイソク」と呼ばれる物件情報を見ながら手入力で登録をしており、その手入力に時間がかかっているため、入力を自動化できれば課題解決に繋がるのではないかという話です。
そして、その自動化には生成AIが有効に使える見込みがあったため、弊社GPTプロジェクトチームにて実現可能性の検証を行った結果、マイソクからテキストデータを抜き出して、その中から登録に必要な情報をChatGPTといった大規模言語モデル（LLM）に整理させることで、完全な入力の自動化は難しくとも、入力補助という形であれば実用的な精度で可能だとわかりました。
この検証を経て、設計、デザイン、そして開発へと進め、昨年夏にリリースに至ったというのが今回のプロジェクトとしての大きな流れでした。
今回の記事ではその中でも、GPTプロジェクトチームで進めた実現可能性検証のPoCとプロンプトチューニングについてや、サービス開発チームにおける実開発の中で、どういった課題や工夫があったかについて触れていきます。
※なお、本記事の検証等で使われたLLMのモデルは検証当時においての最新にすぎず、現在の最新モデルでは精度が大きく異なるため、ご留意ください。
PoCを通して確認したこと
今回、マイソクの自動入力ができないかという要望があった段階から、すでにある程度の機能の全体像は固まっていました。 それは、PDFまたは画像ファイルになっているマイソクデータから、OCR（光学文字認識）等の技術でテキスト情報を取得し、そこから登録に必要な情報だけを正確に抜き出すことができれば、登録はその情報を当てはめるだけで済むはずであるというものでした。
ただ、今回の前述の流れの中で特に壁となりそうだったのが、 "マイソクの形式は一定ではない" ということでした。 マイソクは不動産会社ごとに独自のフォーマットが存在し、マイソクごとの差としては次のようなものが挙げられます。
- 間取り図が左側、物件情報の表が右側にあるマイソクもあれば、それらが上下の関係になっている全く別の構成のマイソクもある
- 物件情報の表中の項目の並び順が異なる（賃料から始まるものもあれば、住所から始まるものもある）
- 賃貸物件においては同じ意味である「保証金」と「償却」のように、マイソクによって異なる表現が複数存在する
このように、どのようなマイソクにも対応できる機能として作るには、OCRによるテキスト情報の抜き出しが仮にできたとしても、住所っぽい情報を住所であると判断したり、「賃料」といった項目名と「20万円」といった項目内容がバラバラであってもそれらが対応する情報であると判断する必要があり、そういった曖昧な情報の整理に対してLLMが活用できるのではないかという話になっていました。
よって、PoCでは、OCRの質とLLMによる情報整理の質の2点において、一定以上の精度を担保できるかを重点に調査しました。
1点目のOCRに関しては、利用可能なサービスの候補はいくつかあったものの、Googleの Cloud Vision API のOCR機能が日本語の識別精度も高く、金額や総合的な観点からも早いうちにそちらを利用することに決まりました。
なお、のちに検証〜実開発の間ぐらいでリリースされた、Open AIのGPT-4oのVision機能による画像認識なども試してみたものの、当時はまだLLM系で画像認識をさせつつ分析させることに関しては出力の質が悪く、OCRで得たテキストデータをLLMに整理させるやり方のほうが良い結果が得られたため、採用とはなりませんでした。
2点目のLLMの情報整理という部分においても、当時ある程度は精度が良く、コストパフォーマンスもよかったOpen AIのモデル「GPT-4 Turbo」を利用することで、プロンプトチューニングにさほど時間を割かない段階でも7割程度は正しい情報が得られたため、チューニングによって8割程度は見込めるであろうという検証結果となりました。
これらを踏まえて、自動登録は情報の正確性の担保が難しいことからも、人間が必ずチェックする「入力補完」という立ち位置であれば問題ないという判断になり、機能開発に進むこととなります。
プロンプトチューニングで得た気づき
PoCを通して機能開発の実現は可能だと判明したあとは、なるべく多くのマイソクのパターンに対応できるようなプロンプトチューニングを行いました。
プロンプトチューニングとは、より欲しい出力結果を高い精度で得るために、制約の追加や出力例を明記するなど、LLMに与える指示を変えていく作業のことで、今回は特定のマイソクにおいてだけ正確な情報が取れても意味がなく、なるべく多くのマイソクで情報が取れるよう、与える制約も汎用性を考慮しながらチューニングする必要がありました。
今回はマイソクのサンプルデータを複数用意し、人間が目検で抜き出した正解の情報を元に、すべてその情報と同じようにデータを取得できた場合に100%の精度とし、プロンプトで与える制約や指示の仕方を変えながら、多くのパターンで検証していくといったシンプルな方法を取りました。
そして、ある程度はチューニングによってPoCの段階よりは精度を高められたものの、単純なチューニングではまだまだ正しく抜き出せないデータもある状況でした。
具体例を挙げると、住所が2行に改行されているようなマイソクで、OCRの結果として得られるテキストとしては住所1行目と2行目が散らばってしまうものなどがありました（1行目が「東京都渋谷区恵比寿」で2行目に「1-7-8」とあるようなものだと、「... 東京都渋谷区恵比寿 賃料 1ヶ月あたり 1-7-8 ...」のように住所の間に別の文字列が混在してしまう）。
こういったデータは、マイソクによっては、2行目となってしまった番地以降の情報は住所情報の続きではないと誤認識して、1行目のみが住所として取れるといった事態が起こっていました。
プロンプトチューニングにおいては、こういった表記があればこの情報をこのプロパティとみなすといった指示の追加によって、ある程度の情報を抜き出せるようにはなっていたものの、前述のようにテキスト上で分断されてしまう情報は、本来はOCRのテキスト位置もデータとして扱わないと難しい状況ではありました（ただし、複雑性が増すため、今回は位置情報は使わずに進めていました）。
ただ、この課題は結論のみ言ってしまうと、チューニング期間中にOpen AIから「GPT-4o」という新モデルがリリースされ、それを利用するだけでほとんど解決されることなりました（結果的にGPT-4oを採択）。
これだけを聞くと、やはり、新モデルによる精度向上のインパクトが大きいわけですが、プロンプトチューニングをする中で有効に感じたものもいくつかありました。
その中でも特に、今回の場合においては「取得する要素の分解」が精度の向上に有用に働きました。
例えば、PoCの段階では「物件の所在地」は「住所」という単位で取っていたものの、実際の物件登録画面では「都道府県」「市区町村」「丁目」「番地」などが分かれており、APIのJSONレスポンスとして対応した項目ごとに返すためにも分解することになったのですが、それによって正しく取れるようになる物件情報がありました。
他にも、同じ賃料でもマイソクによって税抜き表記と税込み表記が異なったり、両方記載されているパターンがあることで、実行ごとに結果が変わることがあったため、税込みかどうかのフラグを分解することで解決した箇所もありました（※ランダム性に寄与するtemperatureは検証時から0で設定しています）。
逆に分解せずにまとめることが有効な場合もありますが、分解することでプロパティごとに細かく指示を出しやすくなった点も含めて、そういったチューニングも場合によっては有効となることが今回のチューニングを通しての気づきでした。
このように、モデルの精度向上とプロンプトチューニングによって、PoC時点よりも10~20%ほど正確に情報が取得できるようになり、そうしてできた最終的なプロンプトは開発担当に引き渡され、機能開発へと続きます。
物件登録補助機能の提供
続いて、物件登録補助機能の提供について説明します。
前述したように、今回実装する物件登録補助機能は、物件登録作業の中で一番時間を必要とする「物件詳細情報の入力」に焦点を当てています。要するに、アップロードされたマイソクから物件詳細情報を抽出し、フォームへ自動で入力してくれる仕様となっております。特筆すべき点として、入力作業自体をほとんどスキップできるように、登録に必須な項目に重きを置いて情報を抽出するようプロンプトが調整されています。結果として、物件登録補助機能を利用することで、以下のように実務のフローを変更することができました。
この仕様を満たすため、物件登録補助機能は図に記載の処理フローとして実装しました。
今回は外部のAPIを利用しており、すべての処理が完了するまでにある程度の時間が必要となってきます。そのため、非同期で外部のAPIを利用できるように、主要な処理をすべてSidekiqで行うように実装しました。また、非同期で処理した結果を自動入力する必要があるため、ポーリングの仕組みをクライアント側の技術スタックであるReactと、サーバー側の技術スタックであるRailsを利用して実装しています。
非同期処理は、マイソクの画像化、OCR、生成AIによる情報抽出といった流れとなっています。マイソクを画像化するにあたって、今回はImageMagickとGhostscriptを利用しました。PDFをJPEGに変換しているのですが、その際に透過部分の処理や複数ページの対応など考慮すべき点が多く、日頃必要とされない技術分野の知識が要求される難しい内容でした。OCRと生成AIによる情報抽出は外部のAPIを利用しているため、仕様書を読み込むだけではなく、発生しうるエラーをどのように扱うべきかを意識して取り組みました。
利用アンケートの結果
本機能の効果を確認するため、不動産会社宛に利用アンケートを回答いただいております。
ここでは、利用アンケートの結果を共有したいと思います。
物件登録補助機能ですが、リリース当初から多くの不動産会社に利用していただいております。さらに、物件登録補助機能をご利用していただくことで、半数以上の利用者が物件登録の際に3分以上短縮できていることがわかります。従来の物件登録は平均6分必要であることを考えると、物件登録補助機能が大幅な工数削減に貢献できていると捉えることができます。
ただ、マイソクからの読み取り精度・速度の面では改善の余地があるといった内容でした。特に、読み取り速度は約半数が遅いと感じていることがわかりました。
物件登録補助機能の改善
前述した利用アンケートの結果から、読み取り精度・速度を向上するための後続対応を実施しております。具体的には、画像変換処理を削除したこと、物件情報の抽出ジョブの同時実行数を増やしたことが挙げられます。画像変換処理は基本的には1〜2秒程度で終了するのですが、PDFのページ数などに依存してしまうためボトルネックの一つとなっていました。そこで、PDFをJPEGへ変換するのではなく、利用するAPIを都度切り替えるようにすることで画像変換処理自体を廃止することができ、読み取り時間全体の平均値である10秒のうち、平均して2秒程度短縮することができました。また、物件情報の抽出ジョブの同時実行数を増やしたことで、処理が始まるまでの待機時間も削減させることができました。
まとめ
ノウハウの活用と不動産会社の需要に応えるため、生成AIを活用した物件登録補助機能を実装して提供することができました。PoCやプロンプトチューニングを通して、生成AIに対するノウハウをさらに高めることができたと考えています。また、実際に利用していただいた不動産会社からも、便利で物件登録の負担を減らすことができたといったお声をいただくこともできました。
弊社は今後もサービス全体を通して生成AIを活用した機能提供を継続してまいりますので、新たな知見やノウハウを積極的に発信していきます。
