JP2019149055A - リフォーム提案方法、プログラム及びリフォーム提案システム - Google Patents

Abstract

【課題】ユーザの要望の自由度の向上を図ることができるリフォーム提案方法、プログラム及びリフォーム提案システムを提供する。【解決手段】リフォーム提案方法は、取得処理と、提案処理と、を有する。取得処理は、施設のリフォームに関する要望を表すテキストデータを含む要望データセットＤｓ１を取得する処理である。提案処理は、取得処理で取得した要望データセットＤｓ１に基づいて、リフォームに関する提案コンテンツデータを出力する処理である。【選択図】図１

Description

本開示は、一般にリフォーム提案方法、プログラム及びリフォーム提案システムに関し、より詳細には、施設のリフォームを提案するためのリフォーム提案方法、プログラム及びリフォーム提案システムに関する。

特許文献１には、リフォーム販売を促進するリフォーム販売支援装置が記載されている。このリフォーム販売支援装置は、間取情報記憶手段に複数種類記憶された間取情報の中からいずれかの間取情報を選択するためのユーザからの選択指令を受け付け、選択された間取情報と躯体情報とを基に、間取画像を作成する。そのため、ユーザは、間取画像を見ることで、リフォームされた住戸の様子を具体的に認識することが可能となり、購買意欲が喚起される。

特開２００７−２９３６３３号公報

しかし、特許文献１に記載の技術では、ユーザは、予め用意された複数種類の間取情報の中からいずれかの間取情報を選択できるだけであって、例えば、ペットと一緒に暮らしたい、又はパン作りをしたい等の、ユーザの自由な要望に対応することはできない。

本開示は上記事由に鑑みてなされており、ユーザの要望の自由度の向上を図ることができるリフォーム提案方法、プログラム及びリフォーム提案システムを提供することを目的とする。

本開示の一態様に係るリフォーム提案方法は、取得処理と、提案処理と、を有する。前記取得処理は、施設のリフォームに関する要望を表すテキストデータを含む要望データセットを取得する処理である。前記提案処理は、前記取得処理で取得した前記要望データセットに基づいて、リフォームに関する提案コンテンツデータを出力する処理である。

本開示の一態様に係るプログラムは、前記リフォーム提案方法を、コンピュータシステムに実行させるためのプログラムである。

本開示の一態様に係るリフォーム提案システムは、取得部と、提案部と、を有する。前記取得部は、施設のリフォームに関する要望を表すテキストデータを含む要望データセットを取得する。前記提案部は、前記要望データセットに基づいて、リフォームに関する提案コンテンツデータを出力する。

本開示によれば、ユーザの要望の自由度の向上を図ることができる、という利点がある。

図１は、実施形態１に係るリフォーム提案方法における入力画面の例を示す説明図である。 図２は、同上のリフォーム提案方法における出力画面の例を示す説明図である。 図３は、実施形態１に係るリフォーム提案システムの概略構成を示すシステム構成図である。 図４Ａは、同上のリフォーム提案方法における出力画面の例を示す説明図である。図４Ｂは、同上のリフォーム提案方法における詳細画面の例を示す説明図である。 図５は、同上のリフォーム提案システムの動作例を示すフローチャートである。 図６は、同上のリフォーム提案方法における学習済みモデルの生成又は更新の様子を示す概念図である。

（実施形態１）
（１）概要
本実施形態に係るリフォーム提案方法は、施設のリフォーム（reform）、つまり施設の改築及び増築等の施設の改修を、提案するための方法である。このリフォーム提案方法は、例えば、リフォーム対象となる施設の所有者等のリフォームを検討中のエンドユーザ（施主）、又はリフォーム業者の営業職に従事する者（いわゆる「営業マン」）等に利用される。本実施形態では一例として、エンドユーザ（施主）がリフォーム提案方法を利用する場合について説明する。

本開示でいう「リフォーム」は、経年劣化等により劣化した施設の修繕だけでなく、施設に新たな機能を追加したり、使い勝手を向上したりするために行うリノベーション（renovation）を含んでいる。本開示でいう「リフォーム」には、一例として、耐震工事、設備の交換、設備の追加、間取りの変更、壁紙の張り替え、模様替え及び外壁塗装等が含まれている。また、本開示でいう「施設」は、戸建住宅、集合住宅、集合住宅の各住戸、オフィス、店舗、病院、工場及び学校等の建物を含み、更には、庭、駐車場、門扉、グランド及び公園等の屋外施設を含む。そのため、本開示でいう「施設のリフォーム」は、庭及び駐車場等の、屋外施設のリフォーム（エクステリアリフォーム）も含んでいる。

本実施形態に係るリフォーム提案方法は、図１及び図２に示すように、要望データセットＤｓ１を取得する取得処理と、提案コンテンツデータＤｐ１〜Ｄｐ６を出力する提案処理と、を有している。要望データセットＤｓ１は、施設のリフォームに関する要望を表すテキストデータを含んでいる。提案コンテンツデータＤｐ１〜Ｄｐ６は、リフォームに関するデータである。以下、複数の提案コンテンツデータＤｐ１〜Ｄｐ６を区別しない場合には、複数の提案コンテンツデータＤｐ１〜Ｄｐ６の各々を「提案コンテンツデータＤｐ０」という。

ここで、提案処理では、取得処理で取得した要望データセットＤｓ１に基づいて、提案コンテンツデータＤｐ０の出力が行われる。つまり、リフォーム提案方法にて提案（出力）される提案コンテンツデータＤｐ０は、施設のリフォームに関する要望を表すテキストデータを含む要望データセットＤｓ１に基づいて決定される。

上記リフォーム提案方法によれば、ユーザの要望の自由度の向上を図ることが可能である。すなわち、上記リフォーム提案方法によれば、ユーザは、施設のリフォームに関する要望を、要望データセットＤｓ１に含まれるテキストデータにて比較的自由に表現することが可能である。そのため、例えば、単に複数種類の情報の中からいずれかの情報を選択する態様に比べ、施設のリフォームに関するユーザの要望の自由度の向上を図ることができる。一例として、ペットと一緒に暮らしたい、又はパン作りをしたい等の、要望があれば、ユーザは、そのような要望を要望データセットＤｓ１に含まれるテキストデータにて表現すればよい。その結果、ユーザにおいては、これらの要望に応じたリフォームの提案（提案コンテンツデータＤｐ０）を受けることが可能である。

（２）システム構成
本実施形態に係るリフォーム提案方法は、例えば、図３に示すように、サーバ装置１とクライアント端末２とを含む、クライアントサーバ（client-server）型のコンピュータシステムにて実現される。このコンピュータシステムは、リフォーム提案システム１０を構成する。

すなわち、本実施形態に係るリフォーム提案システム１０は、図３に示すように、サーバ装置１と、クライアント端末２と、を備えている。このリフォーム提案システム１０は、取得部１１と、提案部１２と、を有している。取得部１１は、上述した取得処理を実行する部位であって、施設のリフォームに関する要望を表すテキストデータを含む要望データセットＤｓ１を取得する。提案部１２は、上述した提案処理を実行する部位であって、要望データセットＤｓ１に基づいて、リフォームに関する提案コンテンツデータＤｐ０を出力する。図３の例では、取得部１１及び提案部１２は、サーバ装置１に設けられている。

また、クライアントサーバ型のリフォーム提案システム１０においては、１台のサーバ装置１に対して、複数台のクライアント端末２を接続することが可能である。図３の例においては、リフォーム提案システム１０は、３台のクライアント端末２を備えている。これら複数台（ここでは３台）のクライアント端末２は、インターネット等のネットワークＮＴ１を介して、サーバ装置１に接続されている。クライアント端末２の台数は、３台に限定されず、例えば、２台以下であってもよいし、４台以上であってもよい。

サーバ装置１は、プロセッサ及びメモリを含むコンピュータシステムを主構成としている。プロセッサが、メモリに記憶されているプログラム（アプリケーションプログラム）を実行することにより、コンピュータシステムをサーバ装置１として機能させる。

サーバ装置１は、取得部１１及び提案部１２に加えて、図３に示すように、学習済みモデル１３、コンテンツ格納部１４、操作入力部１５及び処理部１６を更に有している。

学習済みモデル１３は、人工知能（ＡＩ：Artificial Intelligence）による機械学習アルゴリズムによって生成される。すなわち、詳しくは「（３．２）学習フェーズ」の欄で説明するが、学習済みモデル１３は、コンピュータシステムが、学習用データから学習用プログラムに基づいて生成するモデルである。

学習済みモデル１３は、取得部１１で取得された要望データセットＤｓ１に含まれるテキストデータの解析、及び提案部１２での提案コンテンツデータＤｐ０の決定等に用いられる。すなわち、取得部１１は、取得した要望データセットＤｓ１に含まれるテキストデータについて、学習済みモデル１３を用いて、意味解析及び文脈解析等の自然言語処理を実行する。提案部１２は、要望データセットＤｓ１に基づいて出力するべき提案コンテンツデータＤｐ０を、学習済みモデル１３を用いて特定する。

コンテンツ格納部１４は、複数の候補コンテンツデータを格納（記憶）している。複数の候補コンテンツデータは、提案コンテンツデータＤｐ０の候補となるデータであって、提案部１２は、これら複数の候補コンテンツデータの中から、１ないし複数の提案コンテンツデータＤｐ０を出力する。詳しくは「（３．１）利用フェーズ」の欄で説明するが、本実施形態では、提案コンテンツデータＤｐ０は、テキストデータｄ１（図２参照）及びイメージデータｄ２（図２参照）を含む。そのため、提案コンテンツデータＤｐ０の基になる候補コンテンツデータについても、テキストデータとイメージデータとを含む形で、コンテンツ格納部１４に格納されている。コンテンツ格納部１４に格納されている複数の候補コンテンツデータは、適宜更新（追加及び削除を含む）可能である。

操作入力部１５は、ユーザの操作によって発生する操作信号を取得する。本実施形態のようにクライアントサーバ型のリフォーム提案システム１０においては、ユーザは、クライアント端末２に対して操作を実行する。そのため、操作入力部１５は、クライアント端末２からネットワークＮＴ１経由で、操作信号を取得する（図３参照）。ここで、操作信号は、操作の内容に応じて、少なくともスキップ信号及び選択信号を含む複数種類の信号に分類される。

処理部１６は、操作入力部１５が取得した操作信号に対応する処理を実行する。操作入力部１５が操作信号としてスキップ信号を受信した場合、処理部１６はスキップ処理を実行する。また、操作入力部１５が操作信号として選択信号を受信した場合、処理部１６は選択処理を実行する。スキップ処理及び選択処理について詳しくは「（３．１）利用フェーズ」の欄で説明する。

クライアント端末２は、プロセッサ及びメモリを含むコンピュータシステムを主構成としている。クライアント端末２は、一例として、スマートフォン、タブレット端末又はウェアラブル端末等の携帯情報端末にて実現される。この種のクライアント端末２は、例えば、専用のアプリケーションプログラムをインストールし、このアプリケーションプログラムを起動することにより、リフォーム提案システム１０の一部として機能する。

クライアント端末２は、ネットワークＮＴ１に接続されることにより、サーバ装置１との間で、ネットワークＮＴ１を介して双方向の通信を行う。クライアント端末２が、スマートフォン、タブレット端末又はウェアラブル端末等の携帯情報端末であれば、例えば、電波を媒体とする無線通信により、ルータ等を介してネットワークＮＴ１に接続される。さらに、この種のクライアント端末２は、屋外においても、例えば、通信事業者が提供する携帯電話網（キャリア網）又は公衆無線ＬＡＮ（Local Area Network）を介して、ネットワークＮＴ１に接続可能である。クライアント端末２とネットワークＮＴ１との間の接続方式は、特定の方式には限定されず、例えば、有線方式、無線方式、及び有線方式と無線方式との組み合わせ、のいずれであってもよい。

クライアント端末２は、液晶ディスプレイ又は有機ＥＬ（Electro Luminescence）ディスプレイ等の表示部２１（図１参照）を有している。ここで、表示部２１は、タッチパネルディスプレイである。そのため、表示部２１に対してユーザが操作を行うと、この操作に応じた電気信号（操作信号）が発生し、サーバ装置１に操作信号が送信される。すなわち、クライアント端末２は、ユーザに対して情報を提示（出力）する提示部としての機能と、ユーザの操作を受け付ける操作部としての機能と、を有する。そのため、ユーザは、例えば、表示部２１に表示されるキーボードを操作することにより、直接的に文字列のデータ（テキストデータ）を入力する「文字入力」を行うことができる。

ただし、クライアント端末２は、タッチパネルディスプレイに限らず、例えば、キーボード、ポインティングデバイス又はメカニカルなスイッチ等の操作部を有していてもよい。また、クライアント端末２は、例えば、音声入力によって、ユーザの操作を受け付けてもよい。本開示でいう「音声入力」は、ユーザが発した音声をマイクロフォンで電気信号に変換し、この電気信号（音声信号）について音声認識を行うことで、音声から文字列のデータ（テキストデータ）を抽出することを意味する。また、クライアント端末２は、表示に代えて又は表示と共に、音声出力等により、ユーザに対して情報を提示してもよい。

また、クライアント端末２は、Ｗｅｂブラウザの機能を搭載しており、例えば、図１及び図２に示すように、サーバ装置１からから配信される画像を表示部２１に表示する。つまり、図１及び図２に示すような、表示部２１に表示されている画像は、サーバ装置１で生成された画像である。

（３）動作
次に、上述したリフォーム提案システム１０の動作について説明する。本実施形態に係るリフォーム提案システム１０は、機械学習アルゴリズムによって生成される学習済みモデル１３を用いている。そのため、以下では、学習済みモデル１３を利用してリフォームの提案を行う「利用フェーズ」と、学習済みモデル１３を生成又は更新する「学習フェーズ」と、に分けてリフォーム提案システム１０の動作を説明する。本実施形態に係るリフォーム提案方法は、「利用フェーズ」におけるリフォーム提案システム１０の動作に相当する。

（３．１）利用フェーズ
本実施形態に係るリフォーム提案方法は、基本的には、上述したように要望データセットＤｓ１を取得する取得処理と、提案コンテンツデータＤｐ１〜Ｄｐ６を出力する提案処理と、を有している。

要望データセットＤｓ１は、施設のリフォームに関する要望を表すテキストデータを含んでいる。提案コンテンツデータＤｐ１〜Ｄｐ６は、リフォームに関するデータである。そして、提案処理では、取得処理で取得した要望データセットＤｓ１に基づいて、提案コンテンツデータＤｐ０の出力が行われる。

これにより、本実施形態に係るリフォーム提案方法にて提案（出力）される提案コンテンツデータＤｐ０が、施設のリフォームに関する要望を表すテキストデータを含む要望データセットＤｓ１に基づいて決定されることになる。

すなわち、クライアント端末２にて、図１に示すような入力画面２１１において、ユーザが要望データセットＤｓ１の入力を行うと、サーバ装置１は、取得部１１にて要望データセットＤｓ１を取得する（取得処理）。そして、サーバ装置１は、提案部１２（図３参照）にて、施設のリフォームに関する要望を表すテキストデータを含む要望データセットＤｓ１に基づいて、図２に示すような出力画面２１２において、提案コンテンツデータＤｐ０を出力する（提案処理）。

図１及び図２等（後述の図４Ａ及び図４Ｂも含む）のクライアント端末２の表示画面の例を示す図面において、領域を示す一点鎖線及び符号は、説明のために付しているのであって、実際には表示部２１に表示されない。

ここにおいて、提案処理では、複数の候補コンテンツデータと要望データセットＤｓ１との対比を行う。そして、提案処理では、複数の候補コンテンツデータのうち要望データセットＤｓ１との相関関係が所定の判定条件を満たす候補コンテンツデータを、提案コンテンツデータＤｐ０として出力する。

すなわち、サーバ装置１は、提案処理を実行するに際して、コンテンツ格納部１４に格納されている複数の候補コンテンツデータと、要望データセットＤｓ１とを対比し、両者の相関関係が判定条件を満たす候補コンテンツデータを特定する。判定条件は、例えば、候補コンテンツデータと要望データセットＤｓ１との間の相関が所定値以上であること、である。具体的には、提案部１２は、学習済みモデル１３に照らして、候補コンテンツデータ及び要望データセットＤｓ１の各々をベクトル化し、両者のベクトルから、両者の相関の強さに相当する評価値を算出する。このように求まる評価値が閾値以上であれば、候補コンテンツデータと要望データセットＤｓ１との間の相関が所定値以上である、つまり判定条件を満たすと判断される。

ここにおいて、提案処理では、提案コンテンツデータＤｐ０を複数出力する。例えば、図２の例では、６つの提案コンテンツデータＤｐ１〜Ｄｐ６が出力（表示）されている。これら複数の提案コンテンツデータＤｐ１〜Ｄｐ６は、複数の候補コンテンツデータのうち、要望データセットＤｓ１との相関が強い順、つまり評価値が高い順に選択される。さらに、複数の提案コンテンツデータＤｐ１〜Ｄｐ６は、要望データセットＤｓ１との相関が強い順、つまり評価値が高い順に並べて表示される。図２の例では、左上に位置する提案コンテンツデータＤｐ１の評価値が最も高く、提案コンテンツデータＤｐ２、Ｄｐ３、Ｄｐ４、Ｄｐ５、Ｄｐ６の順に評価値が小さくなる。

また、本実施形態では、要望データセットＤｓ１は、図１に示すように、複数の要望データＤｒ１〜Ｄｒ４を含んでいる。取得処理では、複数の要望データＤｒ１〜Ｄｒ４を取得し終わるまでは、取得部１１は、複数の要望データＤｒ１〜Ｄｒ４の各々を取得する度に、取得した要望データＤｒ１〜Ｄｒ４に応じた質問データＤｑ１〜Ｄｑ５を出力する。そして、取得処理では、質問データＤｑ１〜Ｄｑ５への応答として別の要望データＤｒ１〜Ｄｒ４を取得する対話処理を繰り返す。以下、複数の要望データＤｒ１〜Ｄｒ４を区別しない場合には、複数の要望データＤｒ１〜Ｄｒ４の各々を「要望データＤｒ０」という。同様に、複数の質問データＤｑ１〜Ｄｑ５を区別しない場合には、複数の質問データＤｑ１〜Ｄｑ５の各々を「質問データＤｑ０」という。

要するに、本実施形態に係るリフォーム提案方法においては、取得処理は、対話（Interactive）方式にて行われる。そのため、ユーザにおいては、要望データセットＤｓ１に含まれる複数の要望データＤｒ０を一度に入力するだけでなく、質問データＤｑ０に応答する形で、順次、要望データＤｒ０を入力する。これにより、リフォーム提案システム１０においては、提案コンテンツデータＤｐ０を特定するために必要な要望データＤｒ０を、ユーザから引き出しやすくなる。

言い換えれば、要望データセットＤｓ１には、提案コンテンツデータＤｐ０を特定するために必要なだけの複数の要望データＤｒ０が含まれる。そのため、提案部１２にて提案コンテンツデータＤｐ０を特定できた時点で、取得部１１は、要望データセットＤｓ１に含まれる複数の要望データＤｒ１〜Ｄｒ４を取得し終えたことになる。

図１の例では、取得部１１は、定型の質問データＤｑ１として、「どんなリフォームですか？」というテキストデータを、最初に表示する。これに対して、ユーザが「説明するね」というテキストデータを含む要望データＤｒ１をクライアント端末２にて入力する。次に、取得部１１は、質問データＤｑ２として、「わかりました」、「どんなご要望ですか？」というテキストデータを表示する。これに対して、ユーザが「ペットと暮らす」というテキストデータを含む要望データＤｒ２をクライアント端末２にて入力する。

次に、取得部１１は、質問データＤｑ３として、「どんなペットですか？」というテキストデータを表示する。これに対して、ユーザが「パグです」というテキストデータを含む要望データＤｒ３をクライアント端末２にて入力する。次に、取得部１１は、質問データＤｑ４として、「散歩はよくしますか？」というテキストデータを表示する。これに対して、ユーザが「します」というテキストデータを含む要望データＤｒ４をクライアント端末２にて入力する。

特に、図１に例示する入力画面２１１は、人同士が行うチャットを模擬した表示態様であるため、ユーザにおいては、人を相手に対話しているかのように、要望データＤｒ０の入力を行うことが可能である。これにより、提案コンテンツデータＤｐ０を特定するために必要な要望データＤｒ０を、ユーザから引き出しやすくなる。

上述したような一連の取得処理により、取得処理では、複数（ここでは４つ）の要望データＤｒ１〜Ｄｒ４からなる要望データセットＤｓ１を取得できる。この状態で、提案部１２にて提案コンテンツデータＤｐ０を特定できたことと仮定する。すると、取得部１１は、質問データＤｑ５として、「ボタンを押してね」というテキストデータを表示する。これに対して、ユーザが表示部２１に表示されるボタンＢ１を押す（タップする）と、図２に示すように、提案コンテンツデータＤｐ１〜Ｄｐ６が表示されることになる。

ここで、図１の例において、質問データＤｑ１は、定型文として設定されており、かつ要望データＤｒ０に応じて出力されるデータではないので、対話処理を実現するための質問データには含まれない。同様に、質問データＤｑ５は、定型文として設定されており、かつ要望データＤｒ０の応答を求めるデータではないので、対話処理を実現するための質問データには含まれない。

ここにおいて、対話処理を繰り返す回数は、複数の要望データＤｒ０の各々の内容によって変化する。すなわち、本実施形態に係るリフォーム提案方法では、要望データＤｒ０に対して質問データＤｑ０を出力し、質問データＤｑ０への応答として別の要望データＤｒ０を取得する、という対話処理の回数が固定的ではなく、要望データＤｒ０の内容によって変化する。

本実施形態では、上述したように、提案部１２にて提案コンテンツデータＤｐ０を特定できた時点で、取得部１１は、要望データセットＤｓ１に含まれる複数の要望データＤｒ１〜Ｄｒ４を取得し終えたことになる。そのため、１つ目の要望データＤｒ１に対して質問データＤｑ２が出力され、それに対する応答としての２つ目の要望データＤｒ２を取得した時点で、提案コンテンツデータＤｐ０が特定されれば、対話処理は１回で終わることになる。一方、２つ目の要望データＤｒ２に対して更に質問データＤｑ３が出力され、それに対する応答としての３つ目の要望データＤｒ３を取得した時点で、提案コンテンツデータＤｐ０が特定されれば、対話処理は２回繰り返されることになる。

また、本実施形態では、複数の候補コンテンツデータは複数の階層に分類されている。提案コンテンツデータＤｐ０として出力される候補コンテンツデータの階層は、複数の要望データＤｒ０の各々の内容によって変化する。すなわち、本実施形態に係るリフォーム提案方法では、どの程度深掘りしたリフォームの提案を行うかが、固定的ではなく、要望データＤｒ０の内容によって変化する。

より詳細には、コンテンツ格納部１４に格納されている複数の候補コンテンツデータは、複数の階層に階層化されている。これら複数の階層は、下位の階層ほど、より具体的なリフォームの提案内容となるように設定されている。一例として、最上位の階層が「オール電化」というような抽象的な内容である場合、その下位の階層は「給湯機の容量」、「給湯機の駆動方式」等を特定するやや具体的な内容となり、更にその下位の階層は「給湯機のメーカ」等を特定するより具体的な内容となる。

ここで、どの程度深掘りしたリフォームの提案を行うかは、ユーザのタイプによって変化することが好ましい。例えば、リフォームを検討中のエンドユーザ（施主）は、リフォームに対して具体的な要望を持っているタイプ（以下、「具体型」という）のユーザと、漠然とした要望のみを持っている対応（以下、「漠然型」という）のユーザと、に大別される。そこで、漠然型のユーザに対しては、提案部１２は、例えば、単に「給湯機の容量」、「給湯機の駆動方式」等を特定する内容の階層の複数の候補コンテンツデータの中から、提案コンテンツデータＤｐ０として出力する候補コンテンツデータを決定する。一方、具体型のユーザに対しては、提案部１２は、例えば、「給湯機のメーカ」等を特定する内容の階層の複数の候補コンテンツデータの中から、提案コンテンツデータＤｐ０として出力する候補コンテンツデータを決定する。

また、本実施形態に係るリフォーム提案方法は、スキップ処理を更に有している。スキップ処理は、ユーザの操作によって発生するスキップ信号に応じて、取得処理において複数の要望データＤｒ０を取得し終わる前に対話処理を終了する処理である。すなわち、リフォーム提案方法は、スキップ処理を有することで、要望データセットＤｓ１に含まれる複数の要望データＤｒ０を取得している途中であっても、ユーザが強制的に対話処理を終了させることが可能である。

具体的には、図１に示すような入力画面２１１において、例えば、要望データＤｒ０の代わりに特定のコマンドを入力するような操作がクライアント端末２にて行われると、この操作に連動して操作信号としてのスキップ信号が発生する。操作入力部１５が操作信号としてスキップ信号を受信すると、処理部１６は、要望データセットＤｓ１に含まれる複数の要望データＤｒ０を取得しきっていなくても、つまり提案部１２にて提案コンテンツデータＤｐ０を特定できていなくても、対話処理を終了する。スキップ処理が実行されると、提案部１２は、スキップ処理の実行時点で取得が完了している１ないし複数の要望データＤｒ０に基づいて、提案コンテンツデータＤｐ０の出力を行う。

ところで、提案処理においては、クライアント端末２では、例えば、図２に示すように、提案コンテンツデータＤｐ０が表示される。すなわち、本実施形態では、サーバ装置１は、提案部１２にて、クライアント端末２へ提案コンテンツデータＤｐ０を送信し、クライアント端末２の表示部２１に表示させることにより、提案コンテンツデータＤｐ０の出力を行う。

ただし、提案処理での提案部１２による提案コンテンツデータＤｐ０の出力の態様は、上記の態様に限らない。例えば、提案部１２は、コンピュータシステムで読取可能な非一時的記録媒体へ提案コンテンツデータＤｐ０を書き込むことにより、提案コンテンツデータＤｐ０を出力してもよい。また、提案部１２は、クライアント端末２以外の機器へ提案コンテンツデータＤｐ０を送信してもよく、例えば、送信先の機器が印刷機器であれば、印刷機器にて提案コンテンツデータＤｐ０が印刷により出力される。また、サーバ装置１自体がユーザインタフェースを有する場合には、提案部１２は、サーバ装置１のユーザインタフェースにて、表示出力又は音声出力等により提案コンテンツデータＤｐ０を出力してもよい。

ここにおいて、上述したように、提案コンテンツデータＤｐ０は、テキストデータｄ１及びイメージデータｄ２を含んでいる。図２の例では、６つの提案コンテンツデータＤｐ１〜Ｄｐ６が表示されており、提案コンテンツデータＤｐ１〜Ｄｐ６の各々が、テキストデータｄ１及びイメージデータｄ２を含んでいる。テキストデータｄ１は、文字、数字及び記号等で表される。イメージデータｄ２は、写真、イラスト又はＣＧ（Computer Graphics）等のデータである。

一例として、図１に示すような要望データセットＤｓ１に対しては、ペットとの暮らしに着目したリフォームの提案を行う提案コンテンツデータＤｐ１等が出力される。この提案コンテンツデータＤｐ１は、「散歩帰りに浴室へ直行できる清潔で快適な玄関」というテキストデータｄ１、及び浴室に繋がる玄関を表現した参考画像からなるイメージデータｄ２を含んでいる。このように、テキストデータｄ１及びイメージデータｄ２を含む提案コンテンツデータＤｐ０が出力されることで、ユーザにおいては、テキストデータｄ１のみの場合に比べて、リフォーム後の状態をイメージしやすくなる。

さらに、本実施形態に係るリフォーム提案方法は、選択処理を更に有する。選択処理は、ユーザの操作によって発生する選択信号に応じて、複数の提案コンテンツデータＤｐ１〜Ｄｐ６から１の提案コンテンツデータＤｐ０を選択し、選択した提案コンテンツデータＤｐ０に関連する関連データｄ３（図４Ｂ参照）を出力する処理である。すなわち、リフォーム提案方法は、選択処理を有することで、複数の提案コンテンツデータＤｐ１〜Ｄｐ６の中から、ユーザの操作によって選択されたいずれかの提案コンテンツデータＤｐ０について、より詳細な情報（関連データｄ３）をユーザに提示できる。

具体的には、図４Ａに示すような出力画面２１２において、１つの提案コンテンツデータＤｐ０を指定するような操作がクライアント端末２にて行われると、この操作に連動して操作信号としての選択信号が発生する。一例として、図４Ａに示すように、出力画面２１２上において、ユーザＨ１が提案コンテンツデータＤｐ２の表示領域を押す（タップする）と、提案コンテンツデータＤｐ２を指定する選択信号が発生する。操作入力部１５が操作信号として選択信号を受信すると、処理部１６は、クライアント端末２の表示部２１に表示させる画面を、図４Ｂに示すような、詳細画面２１３に切り替える。

詳細画面２１３では、選択信号で指定された提案コンテンツデータＤｐ２が拡大表示される。さらに、詳細画面２１３には、この提案コンテンツデータＤｐ２に関連する関連データｄ３が表示される。関連データｄ３は、提案コンテンツデータＤｐ２のテキストデータｄ１に比べて、より詳細な情報であって、例えば、提案コンテンツデータＤｐ２で提案するリフォームにおける利点、使用建材のリスト、概算費用及び概算工期等である。関連データｄ３については、テキストデータのみで構成されてもよいし、イメージデータのみ、又はテキストデータ及びイメージデータの組み合わせで構成されてもよい。

ところで、リフォーム業者の営業職に従事する者（いわゆる「営業マン」）が顧客（エンドユーザ）にリフォームの提案を行う場合、営業マンの熟練度（経験値を含む）等によって、提案内容の「質」にばらつきを生じる可能性がある。これに対して、本実施形態に係るリフォーム提案方法によれば、リフォームに関する要望を表すテキストデータを含む要望データセットＤｓ１に基づいて、リフォームに関する提案コンテンツデータＤｐ０が自動的に出力される。したがって、人（例えば営業マン）がリフォームの提案を行う場合に比較して、提案内容の「質」にばらつきが生じにくくなる。特に、後述するように、熟練度が所定値以上である営業マンにより、本実施形態に係るリフォーム提案方法の出力する提案コンテンツデータＤｐ０の評価が行われることで、熟練度が所定値以上である営業マンと同等の「質」の提案が可能となる。

図５は、上述したようなリフォーム提案方法を実現するための、リフォーム提案システム１０の動作例を示すフローチャートである。

すなわち、リフォーム提案システム１０は、まず変数ｍに「１」を代入する（Ｓ１）。次に、リフォーム提案システム１０は、質問データＤｑ（ｍ）を出力し（Ｓ２）、質問データＤｑ（ｍ）に対する応答としての要望データＤｒ（ｍ）を取得したか否かを判断する（Ｓ３）。リフォーム提案システム１０は、要望データＤｒ（ｍ）を取得するまで（Ｓ３：Ｎｏ）待機し、要望データＤｒ（ｍ）を取得すると（Ｓ３：Ｙｅｓ）、要望データＤｒ０と候補コンテンツデータとの対比を行う（Ｓ４）。

リフォーム提案システム１０は、上記対比の結果、両者の相関関係が判定条件を満たす候補コンテンツデータが有るか否か、つまり解が有るか否かを判断する（Ｓ５）。解が無い（Ｓ５：Ｎｏ）、つまり両者の相関関係が判定条件を満たさなければ、リフォーム提案システム１０は、変数ｍをインクリメントし（Ｓ６）、処理Ｓ２に戻る。リフォーム提案システム１０は、処理Ｓ２〜Ｓ６にて対話処理を実現し、対話処理（処理Ｓ２〜Ｓ６）を繰り返すことで、複数の要望データＤｒ０を取得する取得処理を実現する。

また、処理Ｓ５で、解有り（Ｓ５：Ｙｅｓ）、つまり両者の相関関係が判定条件を満たすと判断された場合、リフォーム提案システム１０は、提案コンテンツデータＤｐ０の出力を行う（Ｓ７）。

スキップ処理が行われた場合には、処理Ｓ５をスキップして処理Ｓ４から処理Ｓ７に移行する。これにより、処理Ｓ２〜Ｓ６で実現される対話処理が強制的に終了する。ただし、スキップ処理が行われた場合には、要望データＤｒ０と候補コンテンツデータとの相関関係が判定条件を満たさないことがある。このような場合、評価値に対する閾値を下げることが好ましい。

提案コンテンツデータＤｐ０の出力後、リフォーム提案システム１０は、選択信号の監視を行う（Ｓ８）。一定時間以内に選択信号が有れば（Ｓ８：Ｙｅｓ）、リフォーム提案システム１０は、選択信号で指定された提案コンテンツデータＤｐ０の関連データｄ３を出力する選択処理を実行し（Ｓ９）、一連の処理を終了する。一方、一定時間以内に選択信号が無ければ（Ｓ８：Ｎｏ）、リフォーム提案システム１０は、処理Ｓ９をスキップして、一連の処理を終了する。

図５のフローチャートは一例に過ぎず、例えば、上記以外の処理が更に追加されてもよいし、上記処理の順番が適宜変更されてもよい。

また、上述した要望データセットＤｓ１及び提案コンテンツデータＤｐ０は一例に過ぎず、リフォーム提案方法によれば、他の要望データセットＤｓ１に対しては他の提案コンテンツデータＤｐ０を出力することが可能である。例えば、パン作りをしたい、という趣旨の要望データセットＤｓ１に対しては、パン作りに適したキッチン設備に追加又は交換を提案するような提案コンテンツデータＤｐ０が出力される。さらに、パン作りを親子で楽しみたい、という趣旨の要望データセットＤｓ１に対しては、例えば、キッチン及びダイニングの両方を使ったパン作りを可能とする間取りの変更を提案するような提案コンテンツデータＤｐ０が出力される。

（３．２）学習フェーズ
学習済みモデル１３は、上述したように、コンピュータシステムが、学習用データから学習用プログラムに基づいて生成するモデルである。本実施形態では、学習済みモデル１３は、例えば、ネットワークＮＴ１に接続されている辞典及び辞書等のＷｅｂサイト、ＳＮＳ（Social Networking Service）等から取得可能なデータを学習用データとして、生成又は更新される。

具体的には、サーバ装置１は、ネットワークＮＴ１を介して取得される種々のデータに、アノテーション処理を施すことにより、機械学習に適した形に加工された学習用データセットを生成する。サーバ装置１は、複数の学習用データを用いて、学習済みモデル１３を生成する。サーバ装置１は、一定量以上の学習用データを用いて、機械学習アルゴリズムによって学習済みモデル１３を生成する。ここで、サーバ装置１は、学習済みモデル１３の評価用のサンプルを有し、学習済みモデル１３の評価が向上する度に、学習済みモデル１３を更新することが好ましい。

ところで、本実施形態に係るリフォーム提案方法は、リフォーム業者の営業職に従事する者（いわゆる「営業マン」）に代えて、顧客（エンドユーザ）にリフォームの提案を行うことが可能である。このような場合に、上述したように、熟練度が所定値以上である営業マンと同等の「質」の提案を可能とするためには、熟練度が所定以上である営業マンによる提案コンテンツデータＤｐ０の評価が行われることが好ましい。すなわち、本実施形態に係るリフォーム提案システム１０の出力結果に対する営業マンの評価データを、学習済みモデル１３の生成又は更新のための学習用データに含めることが好ましい。

例えば、図６に示すように、ある要望データセットＤｓ１に対するリフォーム提案システム１０の出力結果として、提案コンテンツデータＤｐ１〜Ｄｐ４，Ｄｐ７，Ｄｐ８が出力されたと仮定する。この場合において、熟練度が所定値以上である営業マンは、この出力結果を評価したところ、提案コンテンツデータＤｐ７，Ｄｐ８は相応でないとの評価データを生成したと仮定する。図６では、営業マンが相応でないと判断した提案コンテンツデータＤｐ７，Ｄｐ８には、「Ｘ」印を付している。この評価データを受けて、リフォーム提案システム１０の出力結果が提案コンテンツデータＤｐ１〜Ｄｐ６となるように、学習済みモデル１３が更新される。このように更新された学習済みモデル１３が、リフォームの提案に利用されることにより、本実施形態に係るリフォーム提案方法では、熟練度が所定以上である営業マンと同等の「質」の提案が可能となる。

（４）変形例
実施形態１は、本開示の様々な実施形態の一つに過ぎない。実施形態１は、本開示の目的を達成できれば、設計等に応じて種々の変更が可能である。また、リフォーム提案方法と同様の機能は、コンピュータプログラム、又はコンピュータプログラムを記録した非一時的記録媒体等で具現化されてもよい。すなわち、一態様に係るプログラムは実施形態１に係るリフォーム提案方法を、コンピュータシステムに実行させるためのプログラムである。

以下、実施形態１の変形例を列挙する。以下に説明する変形例は、適宜組み合わせて適用可能である。

本開示におけるリフォーム提案システム１０では、例えば、サーバ装置１は、コンピュータシステムを主構成としている。コンピュータシステムは、ハードウェアとしてのプロセッサ及びメモリを主構成とする。コンピュータシステムのメモリに記録されたプログラムをプロセッサが実行することによって、本開示におけるサーバ装置１としての機能が実現される。プログラムは、コンピュータシステムのメモリに予め記録されてもよく、電気通信回線を通じて提供されてもよく、コンピュータシステムで読み取り可能なメモリカード、光学ディスク、ハードディスクドライブ等の非一時的記録媒体に記録されて提供されてもよい。コンピュータシステムのプロセッサは、半導体集積回路（ＩＣ）又は大規模集積回路（ＬＳＩ）を含む１ないし複数の電子回路で構成される。複数の電子回路は、１つのチップに集約されていてもよいし、複数のチップに分散して設けられていてもよい。複数のチップは、１つの装置に集約されていてもよいし、複数の装置に分散して設けられていてもよい。

また、リフォーム提案システム１０における複数の機能が、１つの筐体内に集約されていることはリフォーム提案システム１０に必須の構成ではなく、リフォーム提案システム１０の構成要素は、複数の筐体に分散して設けられていてもよい。例えば、取得部１１と提案部１２とは、別の筐体に設けられていてもよい。さらに、リフォーム提案システム１０の少なくとも一部の機能は、例えば、クラウド（クラウドコンピューティング）等によって実現されてもよい。反対に、リフォーム提案システム１０の少なくとも一部の機能が、１つの筐体内に集約されていてもよい。

また、コンテンツ格納部１４に格納されている複数の候補コンテンツデータのうちの１ないし複数の候補コンテンツデータを提案コンテンツデータＤｐ０として出力することは、リフォーム提案方法に必須の構成ではない。例えば、提案処理では、設備ごとにリフォームの提案を行う素材データ等を、要望データセットＤｓ１に基づいて複数組み合わせることにより、要望データセットＤｓ１に適合する提案コンテンツデータＤｐ０を生成してもよい。

また、実施形態１では、エンドユーザ（施主）がリフォーム提案方法を利用する場合を例示したが、この例に限らず、例えば、リフォーム業者の営業職に従事する者（いわゆる「営業マン」）等がリフォーム提案方法を利用してもよい。この場合、リフォーム提案方法を利用しない場合に比べて、営業マンの熟練度（経験値を含む）等による提案内容の「質」にばらつきを小さく抑えることが可能である。

また、提案処理にて複数の提案コンテンツデータＤｐ０を出力することは、リフォーム提案方法に必須の構成ではなく、提案処理にて、１つの提案コンテンツデータＤｐ０のみが出力されてもよい。

（実施形態２）
本実施形態に係るリフォーム提案方法は、ユーザによる要望データセットＤｓ１の入力から、提案コンテンツデータＤｐ０の出力までの一連の処理が、１台のコンピュータにて行われる点が、実施形態１に係るリフォーム提案方法と相違する。以下、実施形態１と同様の構成については、共通の符号を付して適宜説明を省略する。

すなわち、実施形態１に係るリフォーム提案方法は、クライアントサーバ型のシステム（リフォーム提案システム１０）にて実現されるのに対し、本実施形態に係るリフォーム提案システムは、スタンドアロン（stand-alone）型のシステムにて実現される。

本実施形態に係るリフォーム提案方法においても、実施形態１と同様に、ユーザは、施設のリフォームに関する要望を、要望データセットＤｓ１に含まれるテキストデータにて比較的自由に表現することが可能である。その結果、ユーザの要望の自由度の向上を図ることが可能である。

実施形態２で説明した構成は、実施形態１で説明した構成（変形例を含む）と適宜組み合わせて採用可能である。

（まとめ）
以上説明したように、第１の態様に係るリフォーム提案方法は、取得処理と、提案処理と、を有する。取得処理は、施設のリフォームに関する要望を表すテキストデータを含む要望データセット（Ｄｓ１）を取得する処理である。提案処理は、取得処理で取得した要望データセット（Ｄｓ１）に基づいて、リフォームに関する提案コンテンツデータ（Ｄｐ０）を出力する処理である。

この態様によれば、ユーザの要望の自由度の向上を図ることが可能である。すなわち、上記リフォーム提案方法によれば、ユーザは、施設のリフォームに関する要望を、要望データセット（Ｄｓ１）に含まれるテキストデータにて比較的自由に表現することが可能である。そのため、例えば、単に複数種類の情報の中からいずれかの情報を選択する態様に比べ、施設のリフォームに関するユーザの要望の自由度の向上を図ることができる。

第２の態様に係るリフォーム提案方法は、第１の態様において、提案処理では、複数の候補コンテンツデータと要望データセット（Ｄｓ１）との対比を行う。このリフォーム提案方法では、複数の候補コンテンツデータのうち要望データセット（Ｄｓ１）との相関関係が所定の判定条件を満たす候補コンテンツデータを、提案コンテンツデータ（Ｄｐ０）として出力する。

この態様によれば、例えば、予め設定されている複数の候補コンテンツデータの中から、要望データセット（Ｄｓ１）との相関が強い候補コンテンツデータを、提案コンテンツデータ（Ｄｐ０）とすることができる。そのため、提案コンテンツデータ（Ｄｐ０）を特定する処理が比較的簡単になる。

第３の態様に係るリフォーム提案方法では、第２の態様において、要望データセット（Ｄｓ１）は、複数の要望データ（Ｄｒ０）を含んでいる。取得処理では、複数の要望データ（Ｄｒ０）を取得し終わるまでは、対話処理を繰り返す。対話処理は、複数の要望データ（Ｄｒ０）の各々を取得する度に、取得した要望データ（Ｄｒ０）に応じた質問データ（Ｄｑ０）を出力し、質問データ（Ｄｑ０）への応答として別の要望データ（Ｄｒ０）を取得する処理である。

この態様によれば、要望データセット（Ｄｓ１）を取得する取得処理が、対話方式で実現されるので、提案コンテンツデータ（Ｄｐ０）を特定するために必要な要望データ（Ｄｒ０）を、ユーザから引き出しやすくなる。

第４の態様に係るリフォーム提案方法では、第３の態様において、対話処理を繰り返す回数は、複数の要望データ（Ｄｒ０）の各々の内容によって変化する。

この態様によれば、対話処理を繰り返す回数が固定的である場合に比べて、ユーザの要望の自由度が更に向上する。

第５の態様に係るリフォーム提案方法では、第３又は４の態様において、複数の候補コンテンツデータは複数の階層に分類されている。提案コンテンツデータ（Ｄｐ０）として出力される候補コンテンツデータの階層は、複数の要望データ（Ｄｒ０）の各々の内容によって変化する。

この態様によれば、提案コンテンツデータ（Ｄｐ０）として出力される候補コンテンツデータの階層が固定的である場合に比べて、ユーザの要望に対する提案の幅が広くなり、間接的に、ユーザの要望の自由度が更に向上する。

第６の態様に係るリフォーム提案方法は、第３〜５のいずれかの態様において、スキップ処理を更に有する。スキップ処理は、ユーザの操作によって発生するスキップ信号に応じて、取得処理において複数の要望データ（Ｄｒ０）を取得し終わる前に対話処理を終了する処理である。

この態様によれば、ユーザの操作によって対話処理を強制的に終了することが可能である。

第７の態様に係るリフォーム提案方法は、第１〜６のいずれかの態様において、提案処理では、提案コンテンツデータ（Ｄｐ０）を複数出力する。このリフォーム提案方法は、選択処理を更に有する。選択処理は、ユーザの操作によって発生する選択信号に応じて、複数の提案コンテンツデータ（Ｄｐ０）から１の提案コンテンツデータ（Ｄｐ０）を選択し、選択した提案コンテンツデータ（Ｄｐ０）に関連する関連データ（ｄ３）を出力する処理である。

この態様によれば、ユーザの操作によって、提案コンテンツデータ（Ｄｐ０）のより詳細な情報の提示が可能となる。

第８の態様に係るリフォーム提案方法では、第１〜７のいずれかの態様において、提案コンテンツデータ（Ｄｐ０）は、テキストデータ（ｄ１）及びイメージデータ（ｄ２）を含む。

この態様によれば、ユーザにおいては、テキストデータ（ｄ１）のみの場合に比べて、リフォーム後の状態をイメージしやすくなる。

第９の態様に係るプログラムは、第１〜８のいずれかの態様に係るリフォーム提案方法を、コンピュータシステムに実行させるためのプログラムである。

この態様によれば、ユーザの要望の自由度の向上を図ることが可能である。すなわち、上記プログラムによれば、ユーザは、施設のリフォームに関する要望を、要望データセット（Ｄｓ１）に含まれるテキストデータにて比較的自由に表現することが可能である。そのため、例えば、単に複数種類の情報の中からいずれかの情報を選択する態様に比べ、施設のリフォームに関するユーザの要望の自由度の向上を図ることができる。

第１０の態様に係るリフォーム提案システム（１０）は、取得部（１１）と、提案部（１２）と、を有する。取得部（１１）は、施設のリフォームに関する要望を表すテキストデータを含む要望データセット（Ｄｓ１）を取得する。提案部（１２）は、要望データセット（Ｄｓ１）に基づいて、リフォームに関する提案コンテンツデータ（Ｄｐ０）を出力する。

この態様によれば、ユーザの要望の自由度の向上を図ることが可能である。すなわち、リフォーム提案システム（１０）によれば、ユーザは、施設のリフォームに関する要望を、要望データセット（Ｄｓ１）に含まれるテキストデータにて比較的自由に表現することが可能である。そのため、例えば、単に複数種類の情報の中からいずれかの情報を選択する態様に比べ、施設のリフォームに関するユーザの要望の自由度の向上を図ることができる。

上記態様に限らず、実施形態１及び実施形態２に係るリフォーム提案方法の種々の態様（変形例を含む）は、プログラム及びリフォーム提案システム（１０）にて具現化可能である。

第２〜８の態様に係る構成については、データ変換方法に必須の構成ではなく、適宜省略可能である。

１０ リフォーム提案システム
１１ 取得部
１２ 提案部
ｄ１ テキストデータ
ｄ２ イメージデータ
ｄ３ 関連データ
Ｄｐ０、Ｄｐ１〜Ｄｐ８ 提案コンテンツデータ
Ｄｑ０、Ｄｑ１〜Ｄｑ５ 質問データ
Ｄｒ０、Ｄｒ１〜Ｄｒ４ 要望データ
Ｄｓ１ 要望データセット

Claims (10)

1. 施設のリフォームに関する要望を表すテキストデータを含む要望データセットを取得する取得処理と、
   前記取得処理で取得した前記要望データセットに基づいて、リフォームに関する提案コンテンツデータを出力する提案処理と、を有する
   リフォーム提案方法。
2. 前記提案処理では、複数の候補コンテンツデータと前記要望データセットとの対比を行い、前記複数の候補コンテンツデータのうち前記要望データセットとの相関関係が所定の判定条件を満たす候補コンテンツデータを、前記提案コンテンツデータとして出力する
   請求項１に記載のリフォーム提案方法。
3. 前記要望データセットは、複数の要望データを含んでおり、
   前記取得処理では、前記複数の要望データを取得し終わるまでは、前記複数の要望データの各々を取得する度に、取得した要望データに応じた質問データを出力し、前記質問データへの応答として別の要望データを取得する対話処理を繰り返す
   請求項２に記載のリフォーム提案方法。
4. 前記対話処理を繰り返す回数は、前記複数の要望データの各々の内容によって変化する
   請求項３に記載のリフォーム提案方法。
5. 前記複数の候補コンテンツデータは複数の階層に分類されており、
   前記提案コンテンツデータとして出力される前記候補コンテンツデータの階層は、前記複数の要望データの各々の内容によって変化する
   請求項３又は４に記載のリフォーム提案方法。
6. ユーザの操作によって発生するスキップ信号に応じて、前記取得処理において前記複数の要望データを取得し終わる前に前記対話処理を終了するスキップ処理を更に有する
   請求項３〜５のいずれか１項に記載のリフォーム提案方法。
7. 前記提案処理では、前記提案コンテンツデータを複数出力し、
   ユーザの操作によって発生する選択信号に応じて、前記複数の提案コンテンツデータから１の提案コンテンツデータを選択し、選択した提案コンテンツデータに関連する関連データを出力する選択処理を更に有する
   請求項１〜６のいずれか１項に記載のリフォーム提案方法。
8. 前記提案コンテンツデータは、テキストデータ及びイメージデータを含む
   請求項１〜７のいずれか１項に記載のリフォーム提案方法。
9. 請求項１〜８のいずれか１項に記載のリフォーム提案方法を、コンピュータシステムに実行させるためのプログラム。
10. 施設のリフォームに関する要望を表すテキストデータを含む要望データセットを取得する取得部と、
    前記要望データセットに基づいて、リフォームに関する提案コンテンツデータを出力する提案部と、を有する
    リフォーム提案システム。

Images