(57)【要約】【課題】建設費用の見積もりにおいて、ユーザ・事業者共に負担の軽減を図ることができるサーバを提供すること。【解決手段】見積サーバ１は、ユーザ端末２から、ユーザが入力した物件住所、延床面積などを含む簡易情報を入力することで、解体費用の予想金額の算出依頼を受け付ける。次に、見積サーバ１は、簡易情報と、基準価格ＴＢ１２１及び過去価格ＴＢ１２２に記憶されている事業者毎の価格情報と、に基づいて、複数の事業者毎に予想金額を算出する。そして、見積サーバ１は、予想金額を算出した複数の事業者のうち、解体費用の見積金額を算出する可能性が高い５つの事業者を、ユーザ端末２に表示させる。続いて、見積サーバ１は、５つの事業者のうち、ユーザにより選択された事業者から、その事業者が算出した見積金額の入力を受け付ける。【選択図】図４
2020057417.tif 000002
【特許請求の範囲】
【請求項１】
建設費用の見積もりを提供するサーバにおいて、
ユーザから、物件情報に基づく第１の価格の算出依頼を受け付け、
前記物件情報と、予め登録された複数の事業者の価格情報と、に基づいて、前記サーバが複数の事業者毎に前記第１の価格を算出し、
前記第１の価格を算出した複数の事業者の中から、前記事業者が算出した第２の価格の入力を受け付けることを特徴とするサーバ。
【請求項２】
請求項１に記載のサーバにおいて、
前記第１の価格を算出した複数の事業者のうち、ユーザにより選択された事業者から、前記第２の価格の入力を受け付けることを特徴とするサーバ。
【請求項３】
請求項１又は請求項２に記載のサーバにおいて、
前記第１の価格は、前記物件情報のうちユーザが入力した工事範囲情報を参照して、前記サーバが複数の事業者毎に算出した値であり、
前記第２の価格は、前記物件情報のうちユーザが入力した工事範囲情報を参照せずに、前記事業者が算出した値であることを特徴とするサーバ。
【請求項４】
請求項１乃至請求項３の何れかに記載のサーバにおいて、
前記物件情報のうちユーザが入力した住所情報と、
予め登録された複数の事業者の住所情報と、に基づいて、
前記第１の価格を算出する複数の事業者を抽出することを特徴とするサーバ。
【請求項５】
請求項１乃至請求項４の何れかに記載のサーバにおいて、
ユーザから工事希望時期を受け付けていて、
前記工事希望時期と予め登録されている前記複数の事業者の工事可能時期とを照合することに基づいて、前記第１の価格を算出する複数の事業者を抽出することを特徴とするサーバ。
【請求項６】
請求項１乃至請求項５の何れかに記載のサーバにおいて、
前記第１の価格を算出した複数の事業者のうち、前記第２の価格の算出依頼を受け付ける可能性が高い事業者を、所定の順位まで表示させることを特徴とするサーバ。
【請求項７】
請求項１乃至請求項６の何れかに記載のサーバにおいて、
前記第１の価格を算出した複数の事業者のうち、前記第２の価格を算出した事業者と、前記第２の価格を算出していない事業者と、を一覧で表示し、
前記第２の価格を算出していない事業者に対してユーザから受注の確定を受け付けることがない一方、前記第２の価格を算出した事業者に対して受注の確定を受け付けることを特徴とするサーバ。
【請求項８】
請求項１乃至請求項７の何れかに記載のサーバにおいて、
前記物件情報と前記複数の事業者の価格情報とに基づく第３の価格と、前記複数の事業者の価格情報に依存しないで前記物件情報に基づく第４の価格とにより、前記第１の価格を算出することを特徴とするサーバ。
【請求項９】
建設費用の見積もりを提供する見積方法において、
ユーザから、物件情報に基づく第１の価格の算出依頼を受け付け、
前記物件情報と、予め登録された複数の事業者の価格情報と、に基づいて、サーバが複数の事業者毎に前記第１の価格を算出し、
前記第１の価格を算出した複数の事業者の中から、前記事業者が算出した第２の価格の入力を受け付けることを特徴とする見積方法。
【請求項１０】
請求項９に記載の見積方法において、
前記第１の価格を算出した複数の事業者のうち、ユーザにより選択された選択事業者から、前記第２の価格の入力を受け付けることを特徴とする見積方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、建設費用の見積もりを提供するサーバ及び見積方法に関する。
【背景技術】
【０００２】
従来から、建設費用の見積もりに関する技術は、知られている。例えば、下記特許文献１には、工事範囲情報毎に定められた、部品と工賃と既存構造物の撤去費の金額情報に基づいて、リフォーム費用（建設費用）の見積もりを行う技術が開示されている。また、下記特許文献２には、同一の建設工事に対して、複数の事業者から出された同一の建設費用の見積金額を比較する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第６３２９０２２号公報
【特許文献２】特開２００２−２６９２６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、建設費用の見積もりは、大量生産品の見積もりと異なり、建設物の周囲の状況や内部状況により、変化する。そのため、高精度な見積もりを出すためには、現地調査を行うことが好ましく、自動で見積もりを出すことが困難であった。
【０００５】
一方で、ユーザは、多くの事業者を比較したいものである。その場合、ユーザは、多くの事業者とコンタクトを取り、見積もりを取得する必要があった。更にその場合、各事業者も、受注につながらない可能性がある多くの見積もりに対応する必要があった。従って、建設費用を比較するために複数の事業者から見積もりを取得することは、ユーザ・事業者共に負担の大きいものであった。
【０００６】
本発明は上記事情に鑑みてなされたものである。すなわちその課題は、建設費用の見積もりにおいて、ユーザ・事業者共に負担の軽減を図ることにある。
【課題を解決するための手段】
【０００７】
本発明は、
建設費用の見積もりを提供するサーバにおいて、
ユーザから、物件情報に基づく第１の価格の算出依頼を受け付け、
前記物件情報と、予め登録された複数の事業者の価格情報と、に基づいて、前記サーバが複数の事業者毎に前記第１の価格を算出し、
前記第１の価格を算出した複数の事業者の中から、前記事業者が算出した第２の価格の入力を受け付けることを特徴とするサーバである。
【０００８】
このサーバによれば、物件情報と、複数の事業者の価格情報と、に基づいて、複数の事業者毎に、サーバが第１の価格を算出する。そのため、ユーザは、各事業者がどのくらいの第１の価格なのかを把握することができる。そして、サーバは、第１の価格が算出された複数の事業者の中から、事業者が算出した第２の価格の入力を受け付けることで、ユーザに建設費用の見積もりを提供する。こうして、ユーザは、複数の事業者の建設費用の相場を把握しつつ、現地調査を要する正確な見積もりを依頼することができる。即ち、ユーザは、複数の事業者の建設費用の相場を知った上で、事業者に見積もりの依頼をするため、多くの事業者に見積もりの依頼をすることを抑制することができる。一方、事業者は、自社の建設費用の相場を把握しているユーザからの見積もり依頼に対して、見積もりを作成することができる。即ち、事業者は、既に自社の建設費用の相場を知っているユーザから、見積もりを受け付けるため、受注につながり難いユーザからの見積もり依頼を受けることが抑制される。以上により、建設費用の見積もりにおいて、ユーザ・事業者共に負担を軽減することができる。
【発明の効果】
【０００９】
本発明によれば、建設費用の見積もりにおいて、ユーザ・事業者共に負担の軽減を図ることができる。
【図面の簡単な説明】
【００１０】
【図１】本形態の見積システムの概略構成図である。
【図２】本形態の基準価格テーブルを示す図である。
【図３】本形態の過去価格テーブルを示す図である。
【図４】予想金額が送信されるまでの流れを示す図である。
【図５】受注又は失注を連絡するまでの流れを示す図である。
【図６】簡易情報入力画像を示す図である。
【図７】（Ａ）は、相関係数がαよりも小さい場合を示す図であり、（Ｂ）は、相関係数がα以上であり且つβよりも小さい場合を示す図であり、（Ｃ）は、相関係数がβ以上である場合を示す図である。
【図８】予想金額表示画像を示す図である。
【図９】詳細情報入力画像を示す図である。
【図１０】見積金額表示画像を示す図である。
【図１１】第２形態の簡易情報入力画像を示す図である。
【図１２】第２形態のタイプ判別画像を示す図である。
【図１３】第２形態の基準価格テーブルを示す図である。
【図１４】第２形態の過去価格テーブルを示す図である。
【図１５】第３形態において予想金額が送信されるまでの流れを示す図である。
【図１６】第４形態において予想金額が送信されるまでの流れを示す図である。
【発明を実施するための形態】
【００１１】
以下、本発明のサーバ及び見積方法の第１形態（以下「本形態」とも呼ぶ）を、図面を参照して具体的に説明する。第１形態では、建設費用の見積もりとして、ユーザの建設物件を解体する際の解体費用の見積もりを、例にして説明する。
【００１２】
本形態の見積システムＭ１は、図１に示すように、見積サーバ１と、ユーザ端末２と、複数の事業者端末３と、を備えている。複数の事業者端末３は、第１事業者端末３Ａ、第２事業者端末３Ｂなど、おおよそ１０００の事業者端末からなる。従って、図１では、第１事業者端末３Ａ及び第２事業者端末３Ｂが、代表して示されている。この見積サーバ１は、ユーザ端末２と、複数の事業者端末３の各々とに、インターネット等のネットワークを介して、通信可能になっている。
【００１３】
見積サーバ１は、ユーザに対して、事業者が算出した解体費用の見積金額を提供する情報処理端末である。この見積サーバ１は、図１に示すように、ＣＰＵ１１と、メモリ１２（記憶手段）と、を含むコントローラ１０を備えている。また見積サーバ１は、通信インタフェース（通信ＩＦ）１３を備えていて、この通信ＩＦ１３が、コントローラ１０に電気的に接続されている。
【００１４】
コントローラ１０は、見積サーバ１の制御に利用されるハードウェアやソフトウェアを纏めた総称であって、実際に見積サーバ１に存在する単一のハードウェアを表すとは限らない。ＣＰＵ１１は、メモリ１２から読み出したプログラムに従って、各種の処理を実行する。メモリ１２は、ＲＯＭ、ＲＡＭ、ＨＤＤ、フラッシュメモリを含み、各種のプログラムやデータを記憶する。このメモリ１２には、基準価格テーブル（基準価格ＴＢ）１２１と、過去価格テーブル（過去価格ＴＢ）１２２と、が記憶されている。通信ＩＦ１３は、外部装置との通信を行うためのハードウェアを含む。
【００１５】
ユーザ端末２は、ユーザが所有する情報処理端末であり、例えばスマートフォン（携帯端末）である。ユーザ端末２と見積サーバ１とは、各種情報を送信又は受信可能である。このユーザ端末２は、図１に示すように、ＣＰＵ２１と、メモリ２２と、を含むコントローラ２０を備えている。またユーザ端末２は、ユーザインタフェース（ユーザＩＦ）２３と、通信インタフェース（通信ＩＦ）２４と、を備え、これらがコントローラ２０に電気的に接続されている。
【００１６】
ユーザ端末２を構成するＣＰＵ２１、メモリ２２、通信ＩＦ２４は、従来のＣＰＵ、メモリ、通信ＩＦの機能と同様であるため、説明を省略する。ユーザＩＦ２３は、ユーザによる入力操作を受け付けるハードウェアと、各種の情報を表示するハードウェアと、を含む。このユーザＩＦ２３は、入力操作を受け付ける入力機能（入力部）と、各種の情報を表示する表示機能（表示部）と、を兼ね備えたタッチパネルである。
【００１７】
複数の事業者端末３は、事業者の各々が所有する情報処理端末である。よって、第１事業者が所有する情報処理端末が、第１事業者端末３Ａであり、第２事業者が所有する情報処理端末が、第２事業者端末３Ｂである。第１形態の各事業者は、建物を解体して更地にする解体業者である。複数の事業者端末３の各々と見積サーバ１とは、各種情報を送信又は受信可能である。
【００１８】
次に、見積サーバ１のメモリ１２に記憶されている基準価格ＴＢ１２１について、図２に基づいて説明する。基準価格ＴＢ１２１は、各事業者が解体工事を行う際に、どのくらいの工事価格になるのかを予想するために構成されたものである。即ち、見積サーバ１の所有者が、予め各事業者から解体工事の工事価格情報を種別毎に収集していて、これらの工事価格情報を事業者毎に登録したものが、基準価格ＴＢ１２１である。なお、基準価格ＴＢ１２１は、おおよそ１０００の事業者から収集した情報に基づいて、構成されている。但し、図２では、第１事業者から収集した情報のみが代表して示されている。
【００１９】
図２に示すように、基準価格ＴＢ１２１は、事業者毎に分類されていて、事業者毎に住所が記憶されている。事業者の住所は、市区町村単位ではなく、事業者の所在地が厳密に特定できるように、記憶されている。基準価格ＴＢ１２１に記憶されている事業者毎の住所が、「予め登録された複数の事業者の住所情報」に相当する。また基準価格ＴＢ１２１は、建物種別として、専用住宅と、ビル・マンションに分類されている。そして、専用住宅の中でも、建物構造として、木造と鉄骨（軽量鉄骨及び重量鉄骨）と鉄筋コンクリートとに分類されていて、ビル・マンションの中でも、建物構造として、鉄骨と鉄筋コンクリートとに分類されている。
【００２０】
また、基準価格ＴＢ１２１は、専用住宅である場合には、建物構造（木造、鉄骨、鉄筋コンクリート）に応じて、１階、２階、３階、４階以上という階層に分類されている。また基準価格ＴＢ１２１は、ビル・マンションである場合には、建物構造（鉄骨、鉄筋コンクリート）に応じて、２階、３階、４階以上という階層に分類されている。なお、４階建て以上である専用住宅の木造は、ほぼ存在しない。また、木造のビル・マンションと、１階建てのビル・マンションは、ほぼ存在しない。従って、これらの情報は、基準価格ＴＢ１２１に記憶されていない。
【００２１】
そして、基準価格ＴＢ１２１は、専用住宅である場合には、建物構造と階層とに応じて、延床２０坪と延床４０坪と延床６０坪と延床８０坪と延床１００坪とに対応する価格を記憶している。また基準価格ＴＢ１２１は、ビル・マンションである場合には、建物構造と階層に応じて、延床５０坪と延床１００坪と延床１５０坪と延床２００坪と延床２５０坪とに対応する価格を記憶している。基準価格ＴＢ１２１に記憶されている価格を、「基準価格」と呼び、各基準価格が、「予め登録された複数の事業者の価格情報」に相当する。
【００２２】
ここで、実際の解体費用において、建物種別で分けた場合、ビル・マンションの方が、専用住宅よりも高くなり易い。また、建物構造で分けた場合、鉄骨の方が、木造よりも高くなり易く、鉄筋コンクリートの方が、鉄骨よりも高くなり易い。また階層が高くなるほど、解体費用が高くなり、延床面積が大きくなるほど、解体費用が高くなる。これらの事情が反映した形で、事業者毎に、基準価格ＴＢ１２１が構成されている。
【００２３】
また、基準価格ＴＢ１２１は、図２に示すように、事業者毎に、工事対象の前面道路の幅がＸｍ未満の場合の費用上昇率を記憶している。これは、前面道路の幅がＸｍ未満である場合に、前面道路に重機やダンプカーが入ることができなくて、工事金額が上昇するためである。従って、この場合を想定した工事金額の費用上昇率が、事業者毎に、記憶されている。また、基準価格ＴＢ１２１は、事業者毎に、工事対象の隣家距離がＹｃｍ未満である場合の費用上昇率を記憶している。これは、隣家距離がＹｃｍ未満である場合に、解体足場を作ることが困難となり、工事金額が上昇するためである。従って、この場合を想定した工事金額の費用上昇率が、事業者毎に、記憶されている。
【００２４】
続いて、見積サーバ１のメモリ１２に記憶されている過去価格ＴＢ１２２について、図３に基づいて説明する。過去価格ＴＢ１２２は、各事業者が解体工事を実際に見積もった際の見積金額を収集して構成されたものである。即ち、事業者毎に、過去の見積金額を１件ずつ登録したものが、過去価格ＴＢ１２２である。従って、過去価格ＴＢ１２２では、事業者が実際に見積もりを行う度に、情報が頻繁に追加されていく。これに対して、上述した基準価格ＴＢ１２１では、１〜２年に１回程度、情報が更新される。過去価格ＴＢ１２２は、おおよそ１０００の事業者から収集した情報に基づいて、構成されている。但し、図３では、第１事業者から収集した情報のみが代表して示されている。
【００２５】
図３に示すように、過去価格ＴＢ１２２は、事業者毎に分類されていて、１件ずつ見積時期が記憶されている。なお、過去価格ＴＢ１２２では、見積時期が古いものから順番に、１件ずつ並んでいる。また、過去価格ＴＢ１２２は、１件ずつ、建物種別（専用住宅、ビル・マンション）、建物構造（木造、鉄骨、鉄筋コンクリート）、階層（１階、２階、３階、４階以上）を記憶している。そして、過去価格ＴＢ１２２は、延床面積を１坪単位で記憶すると共に、その延床面積に対応した価格（実際の見積金額）を記憶している。過去価格ＴＢ１２２に記憶されている価格を、「過去価格」と呼び、各過去価格が、「予め登録された複数の事業者の価格情報」に相当する。また、過去価格ＴＢ１２２は、前面道路の幅がＸｍ以上であったか否かの情報と、隣家距離がＹｃｍ以上であったか否かの情報を記憶している。
【００２６】
また、過去価格ＴＢ１２２は、事業者毎で且つ１件ずつ、ユーザ評価を記憶している。ユーザ評価は、０．０〜５．０まで０．１単位で記憶されていて、数値が高いほど高評価を意味している。このユーザ評価は、ユーザからの情報に基づいて、逐次追加されていく。また、過去価格ＴＢ１２２は、事業者毎に、工事に取り掛かることが可能な時期を示す工事可能時期を記憶している。工事可能時期では、月単位で、事業者がいつまでに工事に取り掛かることが可能であるかが示されている。例えば、工事可能時期として、１か月以内、２か月以内、３か月以内、６か月以内、６か月を超える時期のうち、何れかの時期が記憶されている。この工事可能時期は、各事業者からの情報に基づいて、数か月毎に定期的に更新されていく。
【００２７】
こうして、本形態の見積サーバ１は、ユーザの建設物件の情報と、予め記憶している基準価格ＴＢ１２１及び過去価格ＴＢ１２２と、に基づいて、ユーザの建設物件を解体する際の予想金額を、複数の事業者毎に算出する。予想金額は、見積サーバ１のＣＰＵ１１によって、各々の事業者がユーザの建設物件を解体すると想定した場合に算出される予想の見積金額のことである。従って、予想金額は、各々の事業者によって、実際に算出される見積金額ではない。この予想金額が、「第１の金額」に相当する。予想金額の具体的な算出方法については、後に説明する。
【００２８】
次に、図４及び図５に基づいて、ユーザの建設物件を解体する事業者が決定するまでの流れを説明する。先ず、ユーザが、ユーザ端末２のユーザＩＦ２３を操作して、ユーザＩＦ２３に、解体費用サイトの簡易情報入力画像４０（図６参照）を表示させる。図６に示すように、簡易情報入力画像４０では、物件住所入力欄４１と、建物種別入力欄４２と、建物構造入力欄４３と、階層入力欄４４と、延床面積入力欄４５と、前面道路入力欄４６と、隣家距離入力欄４７と、希望工期入力欄４８と、比較見積依頼入力欄４９と、が示されている。
【００２９】
物件住所入力欄４１では、ユーザの物件住所のうち、市区町村までの情報が入力される。これは、ユーザに厳密な住所まで入力させないことで、見積もり依頼を気軽に利用してもらうためである。建物種別入力欄４２では、専用住宅又はビル・マンションの何れであるかが入力される。建物構造入力欄４３では、木造、鉄骨、又は鉄筋コンクリートの何れであるかが入力される。階層入力欄４４では、１階建、２階建、３階建、又は４階建以上の何れであるかが入力される。延床面積入力欄４５では、工事対象の延床面積が、１坪単位で入力される。この延床面積入力欄４５で入力される延床面積の情報が、「物件情報のうちユーザが入力した工事範囲情報」に相当する。前面道路入力欄４６では、工事対象の前面道路の幅がＸｍ以上であるか否かが入力される。隣家距離入力欄４７では、工事対象の隣家距離がＹｃｍ以上であるか否かが入力される。希望工期入力欄４８では、ユーザが希望する工事希望時期が１か月単位で入力される。比較見積依頼入力欄４９は、ユーザが上記した各入力欄４１〜４８に情報を入力した後に、５つの事業者の予想見積もりを依頼する場合に、操作される。
【００３０】
こうして、比較見積依頼入力欄４９が操作されると、図４に示すように、各入力欄４１〜４８に入力された情報（以下、「簡易情報」と呼ぶ）が、ユーザ端末２から見積サーバ１に送信される。この簡易情報が、「物件情報」に相当する。こうして、見積サーバ１のＣＰＵ１１は、簡易情報を入力することで、ユーザからの予想見積もりの依頼を受け付ける（Ｓ０１）。ここで、ＣＰＵ１１が行うＳ０１の処理が、「物件情報に基づく第１の価格の算出依頼を受け付ける処理」に相当する。そして、ＣＰＵ１１は、Ｓ０１の処理を行う第１処理部を備えている。また、簡易情報には、希望工期入力欄４８で入力される工事希望時期の情報が含まれているため、ＣＰＵ１１が行うＳ０１の処理が、「ユーザから工事希望時期を受け付ける処理」に相当する。
【００３１】
次に、見積サーバ１のＣＰＵ１１は、簡易情報のうちユーザが入力した市区町村までの住所情報と、基準価格ＴＢ１２１（図２参照）に登録されている約１０００の事業者の住所情報と、に基づいて、事業者を抽出する（Ｓ０２）。具体的に、ＣＰＵ１１は、約１０００の事業者のうち、ユーザが入力した住所から、事業者の住所までの距離が所定距離（例えば５０ｋｍ）以内である事業者のみを抽出する。このようにすることで、ユーザの物件住所から極めて遠い事業者が、予想見積もりを算出する事業者として決定されるのを防ぐことができる。また、約１０００という非常に多くの事業者毎に予想見積もりを算出することが抑制されるため、見積サーバ１のＣＰＵ１１の処理負荷を軽減することができる。ここで、ＣＰＵ１１が行うＳ０２の処理が、「物件情報のうちユーザが入力した住所情報と、予め登録された複数の事業者の住所情報と、に基づいて、第１の価格を算出する複数の事業者を抽出する処理」に相当する。そして、ＣＰＵ１１は、Ｓ０２の処理を行う第４処理部を備えている。
【００３２】
次に、見積サーバ１のＣＰＵ１１は、工事希望時期の情報と、Ｓ０２で抽出された複数の事業者のうち過去価格ＴＢ１２２（図３参照）に登録されている事業者の工事可能時期の情報と、を照合することに基づいて、事業者を抽出する（Ｓ０３）。具体的に、ＣＰＵ１１は、Ｓ０２で抽出された複数の事業者のうち、登録されている工事可能時期がユーザの工事希望時期を満たしている事業者のみを抽出する。このようにすることで、ユーザの工事希望時期で工事を行うことができない事業者が選択されるのを防ぐことができる。ここで、ＣＰＵ１１が行うＳ０３の処理が、「工事希望時期と予め登録されている複数の事業者の工事可能時期とを照合することに基づいて、第１の価格を算出する複数の事業者を抽出する処理」に相当する。そして、ＣＰＵ１１は、Ｓ０３の処理を行う第５処理部を備えている。
【００３３】
次に、見積サーバ１のＣＰＵ１１は、Ｓ０３で抽出された複数の事業者毎に、簡易情報と、基準価格ＴＢ１２１（図２参照）及び過去価格ＴＢ１２２（図３参照）と、に基づいて、予想金額を算出する。以下では、予想金額の算出方法を、図７（Ａ）（Ｂ）（Ｃ）に基づいて、概略的に説明する。
【００３４】
先ず、ＣＰＵ１１は、基準価格ＴＢ１２１の事業者の欄を参照する。次に、ＣＰＵ１１は、参照している事業者の欄において、入力した簡易情報（建物種別、建物構造、階層、前面道路の幅、隣家距離）と同一条件である延床面積毎の価格を参照する。例えば、ユーザの建設物件が、専用住宅であり、鉄骨であり、２階建であり、前面道路の幅がＸｍ未満であり、隣家距離がＹｃｍ未満である場合には、ＣＰＵ１１は、基準価格ＴＢ１２１で参照している事業者（例えば第１事業者）において、これらと同一の条件である延床２０坪の単価、延床４０坪の単価、延床６０坪の単価、延床８０坪の単価、延床１００坪の価格を参照する。そして、ＣＰＵ１１は、前面道路の幅がＸｍ未満である場合には、参照した延床面積毎の価格に対して、前面道路の幅がＸｍ未満である場合の事業者の費用上昇率（図２参照）を積算する。更に、ＣＰＵ１１は、隣家距離がＹｃｍ未満である場合には、参照した延床面積毎の価格に対して、隣家距離がＹｃｍ未満である場合の事業者の費用上昇率（図２参照）を積算する。これにより、ＣＰＵ１１は、基準価格近似曲線（図７（Ａ）（Ｂ）（Ｃ）参照）を求める。図７（Ａ）（Ｂ）（Ｃ）では、基準価格近似曲線が、実線で概略的に示されている。
【００３５】
また、ＣＰＵ１１は、過去価格ＴＢ１２２の事業者の欄を参照する。次に、ＣＰＵ１１は、参照している事業者の欄において、入力した簡易情報（建物種別、建物構造、階層、前面道路の幅、隣家距離）と同一条件である価格を参照する（図３参照）。但し、ＣＰＵ１１は、見積時期（図３参照）を参照して、ある時期から現時点までの価格（例えば直近３年間の価格）、又は、現時点までの所定数の価格を用いる。これは、実際の見積金額は、時間の経過と共に変動していくため、直近の価格であるほど、正確な見積金額を反映している可能性が高いためである。そして、ＣＰＵ１１は、簡易情報と同一条件であり、ある時期から現時点までの過去価格のデータにおいて、延床面積と価格との相関係数を求める。相関係数は、参照している過去価格のデータ（データの集まり）において、延床面積と価格との相関を示す値であり、「１」に近い値であるほど、延床面積と価格との間に、強い正の相関があることを意味し、「０」に近い値であるほど、延床面積と価格との間に、ほとんど相関がないことを意味している。
【００３６】
ここで、事業者が算出した実際の見積価格では、延床面積が大きくなるほど、価格が高くなるため、延床面積と価格との間に、強い正の相関があるはずである。即ち、登録されている過去価格のデータでは、サンプル数が多ければ多いほど、延床面積と価格との間に、強い正の相関があることが想定される。しかしながら、仮に、過去価格のデータのサンプル数が少ない場合、過去価格のデータにおいて、延床面積と価格との間に、強い正の相関にならないおそれがある。
【００３７】
そこで、本形態では、過去価格のデータにおいて、延床面積と価格との相関係数が小さい場合には、過去価格のデータよりも、基準価格のデータの方が、予想金額を算出するデータに相応しいと判断する。また、延床面積と価格との相関係数がある程度大きい場合には、過去価格のデータ又は基準価格のデータのうち、予想金額が低くなる方のデータが、予想金額を算出するデータに相応しいと判断する。また、延床面積と価格との相関係数が非常に大きい場合には、過去価格のデータの方が、基準価格のデータよりも、予想金額を算出するデータに相応しいと判断する。こうして、相関係数の大きさに応じて、過去価格のデータと基準価格のデータとの扱い方を変えるようにしている。
【００３８】
具体的に、図７（Ａ）では、相関係数が第１閾値α（例えば０．７）よりも小さい場合が示されている。この場合、参照している過去価格データにおいて、延床面積と価格との間の相関が弱い。従って、この場合には、見積サーバ１のＣＰＵ１１は、基準価格近似曲線（図７（Ａ）の実線）の方が、過去価格近似曲線（図７（Ａ）の破線）よりも、実際の見積金額に近いと判断して、基準価格近似曲線を用いて、面積比例価格を決定する。即ち、図７（Ａ）に示すように、ユーザの建設物件の延床面積が例えばＴである場合には、基準価格近似曲線によって、面積比例価格Ｋ１が決定される。
【００３９】
また、図７（Ｂ）では、相関係数が、第１閾値α（例えば０．７）以上であり、且つ第２閾値β（例えば０．８）よりも小さい場合が示されている。この場合、参照している過去価格データにおいて、延床面積と価格との間の相関が、図７（Ａ）に示す場合よりも、強い。但し、延床面積と価格との間の相関が非常に強いわけではない。従って、この場合には、見積サーバ１のＣＰＵ１１は、基準価格近似曲線（図７（Ｂ）の実線）又は過去価格近似曲線（図７（Ｂ）の破線）のうち、価格が低くなる方の近似曲線を用いて、面積比例価格を決定する。即ち、図７（Ｂ）に示すように、ユーザの建設物件の延床面積が例えばＴである場合には、価格が低くなる方の近似曲線（図７（Ｂ）では基準価格近似曲線）によって、面積比例価格Ｋ２が決定される。
【００４０】
また、図７（Ｃ）では、相関係数が、第２閾値β（例えば０．８）以上である場合が示されている。この場合、参照している過去価格データにおいて、延床面積と価格との間の相関が非常に高い。従って、この場合には、見積サーバ１のＣＰＵ１１は、過去価格近似曲線（図７（Ｃ）の破線）の方が、基準価格近似曲線（図７（Ｃ）の実線）よりも、実際の見積金額に近いと判断して、過去価格近似曲線を用いて、面積比例価格を決定する。即ち、図７（Ｃ）に示すように、ユーザの建設物件の延床面積が例えばＴである場合には、過去価格近似曲線によって、面積比例価格Ｋ３が決定される。
【００４１】
ところで、上述したように、面積比例価格Ｋ１、Ｋ２、Ｋ３が決定されるが、この面積比例価格（Ｋ１、Ｋ２、Ｋ３）は、未だ予想金額ではない。即ち、本形態の予想金額は、面積比例価格に、固定価格を加算することによって、算出される。固定価格は、カーポートの撤去費用や、土間コンクリートの撤去費用であり、事業者の各々によって、価格が変動しないものである。ここで、面積比例価格Ｋと固定価格との違いについて、説明する。
【００４２】
面積比例価格は、上述した説明から分かるように、ユーザが入力した簡易情報と、基準価格ＴＢ１２１及び過去価格ＴＢ１２２とに、基づいて、算出される。これに対して、固定価格は、基準価格ＴＢ１２１及び過去価格ＴＢ１２２に依存しないで、ユーザが入力した簡易情報に基づいて、算出されている。これは、以下の理由に基づく。
【００４３】
面積比例価格は、事業者毎に大きく変動する傾向があり、仮に予想金額を面積比例価格だけで決定すると、予想金額を適切にコントロールできないおそれがある。これに対して、カーポートの撤去費用や、土間コンクリートの撤去費用等の固定費用は、事業者毎に依存せずに、おおよその金額が予め定まっているものである。従って、予想金額に含まれる固定費用を、ユーザが入力した簡易情報だけに基づく変動価格として利用する。これにより、予想金額が、想定外に高くなり過ぎたり、想定外に低くなり過ぎるのを防ぐことができる。このようにして、予想金額は、面積比例価格と固定価格とにより算出されることで、予想金額を適切にコントロールすることができる。ここで、予想金額が「第１の価格」に相当し、面積比例価格が「物件情報と複数の事業者の価格情報とに基づく第３の価格」に相当し、固定価格が「複数の事業者に依存しないで物件情報に基づく第４の価格」に相当する。
【００４４】
図４に示すように、見積サーバ１のＣＰＵ１１は、上記の算出方法によって、Ｓ０３で抽出した複数の事業者毎に、予想金額を算出する（Ｓ０４）。ここで、ＣＰＵ１１が行うＳ０４の処理が、「物件情報と、予め登録された複数の事業者の価格情報と、に基づいて、サーバが複数の事業者毎に第１の価格を算出する処理」に相当する。そして、ＣＰＵ１１は、Ｓ０４の処理を行う第２処理部を備えている。
【００４５】
次に、見積サーバ１のＣＰＵ１１は、予想金額が算出された複数の事業者を、ユーザが実際の見積もりの依頼を行う可能性により、順位付ける（Ｓ０５）。本形態では、複数の事業者の順位付けは、予想金額の低さと、ユーザの物件住所（市区町村までの情報）と各事業者の住所との間の距離と、ユーザ評価の高さと、に基づく。具体的に、ＣＰＵ１１は、予想金額が算出された複数の事業者を、予想金額が低い順番に並べて、予想金額が低い事業者であるほど、順番に高得点を付与する。また、ＣＰＵ１１は、予想金額が算出された複数の事業者を、ユーザの物件住所と各事業者の住所との間の距離が近い順番に並べて、この距離が近い事業者であるほど、順番に高得点を付与する。また、ＣＰＵ１１は、過去価格ＴＢ１２２において、予想金額が算出された事業者の欄を参照して、ユーザが入力した簡易情報（建物種別、建物構造、階層）と同一条件である欄のユーザ評価を抽出する。そして、ＣＰＵ１１は、抽出したユーザ評価の平均値によって、その事業者のユーザ評価を決定する。こうして、ＣＰＵ１１は、予想金額が算出された複数の事業者を、ユーザ評価が高い順番に並べて、ユーザ評価が高い事業者であるほど、順番に高得点を付与する。
【００４６】
ここで本形態では、見積サーバ１のＣＰＵ１１は、予想金額が高い事業者に対して、ユーザからの距離が近い事業者、又はユーザ評価が高い事業者よりも、より高得点を付与する。これは、ユーザにとって、予想金額の低さが、住所間の距離又はユーザ評価よりも、重要視される傾向があるためである。また、ＣＰＵ１１は、ユーザからの距離が近い事業者に対して、ユーザ評価が高い事業者よりも、より高得点を付与する。これは、建設工事（例えば解体工事）において、ユーザの物件住所から近い位置にある事業者ほど、受注し易い実情があるためである。また、地方では、都市部よりも、ユーザの物件住所から近い位置にある事業者が受注し易いという実情もある。そこで本形態では、ユーザの物件住所が、地方にある場合には、都市部にある場合よりも、事業者に付与する配点の差が大きくなるように設定されている。
【００４７】
以上により、見積サーバ１のＣＰＵ１１は、予想金額が算出された複数の事業者を、付与された得点の合計により、順位付ける（Ｓ０５）。即ち、付与された得点の合計が多い事業者は、ユーザが見積金額の算出依頼を受け付ける可能性が高いものであると想定して、順番に並べられる。次に、ＣＰＵ１１は、ステップＳ０５で順位付けられた複数の事業者のうち、上位５社だけ抽出する（Ｓ０６）。
【００４８】
続いて、見積サーバ１のＣＰＵ１１は、抽出した上位５社の情報と、上位５社の各々の予想金額とを、ユーザ端末２に送信する（Ｓ０７）。これにより、ユーザ端末２のＣＰＵ２１は、ユーザＩＦ２３にて、図８に示すように、予想金額表示画像５０を表示させる。このようにすることで、ユーザによって選択され易い上位５社と各予想金額とが、ユーザ端末２のユーザＩＦ２３に表示される。即ち、ユーザによって、見積もりを依頼する可能性が、低い事業者が表示されない。よって、ユーザが見積金額の算出依頼を行う事業者を選び易くすることができる。ここで、抽出された上位５社の事業者が、「第１の価格を算出した複数の事業者」に相当する。また、ＣＰＵ１１が行うＳ０７の処理が、「第１の価格を算出した複数の事業者のうち、第２の価格の算出依頼を受け付ける可能性が高い事業者を、所定の順位まで表示させる処理」に相当する。そして、ＣＰＵ１１は、Ｓ０７の処理を行う第６処理部を備えている。
【００４９】
ここで、図８に基づいて、予想金額表示画像５０の表示態様について、説明する。なお図８では、３つの事業者の情報が示されているが、ユーザがユーザＩＦ２３に対してスクロール操作することで、５つの事業者が示される。なお以下では、図７において、上から順番に、第１事業者の情報と、第２事業者の情報と、第３事業者の情報と、が示されることとして説明する。
【００５０】
図８に示すように、予想金額表示画像５０の上部には、第１事業者に対する予想金額５１ａと、第１事業者に対する住所Ａ５１ｂと、第１事業者に対するユーザ評価５１ｃと、第１事業者を示すアイコン５１ｄと、第１事業者を選択するためのチェックボックス５１ｅと、が示されている。また予想金額表示画像５０の中央部には、第２事業者に関する事項が示されている。但し、上述した第１事業者に関する事項が、第２事業者に関する事項に替わるだけであるため、５２番台の符号を付して、説明を省略する。同様に、予想金額表示画像５０の下部には、第３事業者に関する事項が示されている。但し、上述した第１事業者に関する事項が、第３事業者に関する事項に替わるだけであるため、５３番台の符号を付して、説明を省略する。
【００５１】
こうして、ユーザは、予想金額表示画像５０によって、５つの事業者の予想金額を比較して見ることができる。更に、ユーザは、５つの事業者の住所を比較して見ることができると共に、ユーザ評価も比較して見ることができる。従って、ユーザには、５つの事業者のうち、どの事業者に実際に見積もりを行うのかを容易に判断させることができる。なお、図８に示す予想金額表示画像５０の左上部には、表記変更欄５４が設けられている。そのため、ユーザは、表記変更欄５４を操作する度に、予想金額表示画像５０で示される５つの事業者を、予想金額が安い順番、ユーザの住所から近い順番、ユーザ評価の高い順番に、並び替えることができる。
【００５２】
ユーザは、予想金額表示画像５０において、チェックボックス５１ｅ、５２ｅ、５３ｅを操作することで、見積金額を算出する事業者を選択する（Ｓ０８）。このようにして、ユーザが、事業者毎の予想金額を比較しながら、実際に見積もりを依頼したい事業者を更に絞り込むことで、見積もりを作成する事業者側の負担を軽減することができる。なお、図８では、ユーザにより、第１事業者と第３事業者とが選択された例が、示されている。従って、これら第１事業者と第３事業者とが、「ユーザにより選択された事業者」に相当する。その後、ユーザは、予想金額表示画像５０の最下部に設けられている一括見積依頼欄５５を操作する。これにより、ユーザ端末２のＣＰＵ２１は、ユーザＩＦ２３にて、図９に示すように、詳細情報入力画像６０を表示させる。なお、図９に示す詳細情報入力画像６０が表示されているときには、未だ見積もりの依頼が、確定していない。
【００５３】
ここで、図９に基づいて、詳細情報入力画像６０の表示態様について、説明する。図９に示すように、詳細情報入力画像６０では、氏名情報入力欄６１と、現在住所入力欄６２と、Ｅｍａｉｌ入力欄６３と、物件住所入力欄６４と、物件住所位置画像６５と、送信完了欄６６と、が示されている。氏名情報入力欄６１では、ユーザの氏名が入力される。現在住所入力欄６２では、ユーザの住所が入力される。Ｅｍａｉｌ入力欄６３では、ユーザのＥｍａｉｌアドレスが入力される。これらユーザの個人情報を入力させることで、ユーザに、実際の見積もりを行う意思を確認させることができる。言い換えると、図６に示す簡易情報入力画像４０の表示中には、ユーザには、個人情報の入力まで求められていない。これにより、ユーザには、より気軽に予想金額の算出依頼を頼み易くしている。
【００５４】
ところで、図９に示す詳細情報入力画像６０の物件住所入力欄６４では、図６に示す簡易情報入力画像４０の物件住所入力欄４１と異なり、ユーザの物件住所のうち、厳密な住所（例えば番地）まで入力される。これは、ユーザにより選択された事業者が、ユーザの物件住所を正確に特定するためである。物件住所位置画像６５では、物件住所入力欄６４で入力された物件情報の位置が、ＭＡＰ上で示される。これにより、ユーザは、物件住所の位置がＭＡＰ上で正しいか否かを、容易に判断することができる。送信完了欄６６は、ユーザが各入力欄６１〜６４を入力した後に、選択された事業者に実際に見積もりを依頼する場合に、操作される。
【００５５】
こうして、送信完了欄６６が操作されると、図４に示すように、選択された事業者の情報及び各入力欄６１〜６４に入力された情報（以下、「詳細情報」と呼ぶ）が、ユーザ端末２から見積サーバ１に送信される。これにより、見積サーバ１のＣＰＵ１１は、簡易情報を入力する（Ｓ０９）。続いて、見積サーバ１のＣＰＵ１１は、ユーザにより選択された事業者の事業者端末に、詳細情報と予想金額とを送信する（Ｓ１０）。ここで、選択された事業者に対して、詳細情報だけでなく、予想金額も送信するのは、以下の理由に基づく。即ち、これから見積金額を算出する事業者に、ユーザが予想金額によって既に解体費用（建設費用）の相場を把握していることを、認識させることができる。これにより、選択された事業者は、予想金額と見積金額との大幅な相違が発生することを抑制することができる。
【００５６】
続いて、図５に示すように、ユーザにより選択された事業者（第１事業者、第３事業者）は、詳細情報に含まれるユーザの物件住所の情報に基づいて、ユーザの建設物件に向かう。そして、各事業者は、現地確認を行って、ユーザの建設物件を解体する際の見積金額を算出する（Ｓ１１）。このとき、各事業者は、建物種別、階層、延床面積、前面道路の幅、隣家距離、カーポート等の撤去物、建築工法（木造軸組工法、ツーバイフォー、プレハブ工法等）、基礎種別（ベタ基礎、布基礎）など、現地の状況を正確に把握した上で、見積金額を算出する。
【００５７】
ところで、上述したように、見積サーバ１のＣＰＵ１１は、ユーザが入力した延床面積を参照して、事業者毎に予想金額を自動で算出する。これに対して、ユーザにより選択された事業者は、ユーザが入力した延床面積を参照しないで、見積金額を手動で算出する。これは、以下の理由に基づく。
【００５８】
予想金額は、コンピュータによって、過去の経験値からあくまで目安として算出されるものである。従って、ユーザが入力した延床面積の情報（工事範囲情報）を正しいものと推定した上で、予想金額が算出されても特段問題にならない。これに対して、見積金額は、建設物件が１件１件異なるため、正確な見積もりを行う際には、現地確認が必須である。従って、専門家である事業者が、ユーザが入力した延床面積（工事範囲情報）を参照しないで、自身で現場の状況（延床面積の情報等）を正確に把握することで、正しい見積金額を算出することができる。言い換えれば、ユーザが入力した延床面積は必ず正しいものとは限らないため、事業者はユーザが入力した延床面積の情報を参照しないことで、誤った情報に基づいて見積金額が算出されるのを防ぐことができる。ここで、見積金額が、「第２の価格」に相当する。
【００５９】
図５に示すように、例えば第１事業者が見積金額を算出した後、見積金額が、第１事業者端末３Ａから見積サーバ１に送信される。なお、本形態では、ユーザにより選択された第３事業者も見積金額を算出した後、その見積金額が、見積サーバ１に送信される。こうして、見積サーバ１のＣＰＵ１１は、ユーザにより選択された各事業者が算出した見積金額を入力する（Ｓ１２）。ここで、ＣＰＵ１１が行うＳ１２の処理が、「第１の価格を算出した複数の事業者のうち、ユーザにより選択された事業者から、第２の価格の入力を受け付ける処理」に相当する。そして、ＣＰＵ１１は、Ｓ１２の処理を行う第３処理部を備えている。
【００６０】
次に、見積サーバ１のＣＰＵ１１は、ユーザにより選択された事業者毎の見積金額を、ユーザ端末２に送信する（Ｓ１３）。これにより、ユーザ端末２のＣＰＵ２１は、事業者毎の見積金額に基づいて、ユーザＩＦ２３にて、図１０に示すように、見積金額表示画像７０を表示させる。見積金額表示画像７０では、予想金額を算出した事業者のうち、見積金額を算出した事業者（第１事業者、第３事業者）と、見積金額を算出していない事業者（第２事業者）と、が一覧で表示されている。こうして、ＣＰＵ１１が行うＳ１３の処理（図５参照）が、「第１の価格を算出した複数の事業者のうち、第２の価格を算出した事業者と、第２の価格を算出していない事業者と、を一覧で表示する処理」に相当する。そして、ＣＰＵ１１は、Ｓ１３の処理を行う第７処理部を備えている。
【００６１】
図１０に示す見積金額表示画像７０の表示態様の説明に戻る。図１０に示すように、見積金額表示画像７０の上部には、第１事業者に対する見積金額７１ａと、第１事業者に対する予想金額７１ｂと、第１事業者に対する住所Ａ７１ｃと、第１事業者に対するユーザ評価７１ｄと、第１事業者を示すアイコン７１ｅと、第１事業者に契約依頼するための契約依頼欄７１ｆと、が示されている。見積金額７１ａと予想金額７１ｂとは、上下に並記されている。そのため、ユーザは、第１事業者が算出した見積金額を把握しつつ、見積金額が予想金額とどのくらい差があるのかを容易に把握することができる。また、見積金額７１ａは、予想金額７１ｂよりも、目立つ態様で（例えば赤色で）且つ大きく示されている。これにより、ユーザに、予想金額７１ｂよりも重要な見積金額７１ａの値を、正しく認識させることができる。
【００６２】
また、見積金額表示画像７０の中央部には、第３事業者に関する事項が示されている。但し、上述した第１事業者に関する事項が、第３事業者に関する事項に替わるだけであるため、７３番台の符号を付して、説明を省略する。なお、第１事業者が算出した見積金額７１ａが、第３事業者が算出した見積金額７３ａよりも低いため、第１事業者に関する事項が、第３事業者に関する事項よりも、上側に示されている。また、見積金額表示画像７０の下部には、見積金額を算出していない第２事業者の予想金額７２ａと、第２事業者に対する住所Ｂ７２ｂと、第２事業者に対するユーザ評価７２ｃと、第２事業者を示すアイコン７２ｄと、第２事業者を選択するためのチェックボックス７２ｅと、が示されている。なお、図１０に示す見積金額表示画像７０では、ユーザが、ユーザＩＦに対してスクロール操作することで、見積金額を算出していない第４事業者及び第５事業者に関する事項を示すことができる。
【００６３】
ところで、見積金額表示画像７０の最下部には、追加見積依頼欄７４が設けられている。従って、ユーザは、見積金額を把握したものの、他の事業者にも見積金額の算出依頼を行いたい場合がある。この場合、ユーザは、チェックボックス７２ｅを操作して、追加見積依頼欄７４を操作する。これにより、上述した場合と同様に、見積サーバ１のＣＰＵ１１は、選択された事業者に、詳細情報と予想金額とを送信して（Ｓ１０）、事業者から算出された予想金額を入力することになる（Ｓ１２）。こうして、ユーザは、例えば予想金額と見積金額との差が大きい場合に、追加で他の事業者に見積金額の算出の依頼を行うことができる。
【００６４】
図５に示すように、ユーザは、見積金額を算出した事業者の中から契約依頼を行う事業者を選択して（Ｓ１４）、選択した事業者の契約依頼欄を操作する。これにより、見積サーバ１のＣＰＵ１１は、ユーザ端末２から、ユーザがどの事業者に契約依頼したかを示す契約依頼情報を入力する（Ｓ１５）。ところで、図１０に示す見積金額表示画像７０を見たユーザは、誤って、見積金額を算出していない事業者（第２事業者）に、契約依頼を申し込むおそれがある。
【００６５】
そこで本形態では、第１事業者及び第３事業者に対して、契約依頼欄７１ｆ、７３ｆが示されている一方、第２事業者に対して、契約依頼欄に相当する部分が示されていない。こうして、見積サーバ１のＣＰＵ１１は、見積金額が算出されていない事業者（第２事業者）に対してユーザの受注の確定を受け付けることがない一方、見積金額が算出された事業者（第１事業者又は第３事業者）に対して受注の確定を受け付けている。このようにして、見積金額が算出されていない事業者に契約依頼がされてしまい、誤った受注の確定がなされるのを防ぐことができる。ＣＰＵ１１が行うＳ１５の処理が、「第２の価格を算出していない事業者に対してユーザから受注の確定を受け付けることがない一方、第２の価格を算出した事業者に対して受注の確定を受け付ける処理」に相当する。そして、ＣＰＵ１１は、Ｓ１５の処理を行う第８処理部を備えている。
【００６６】
なお、本形態では、ユーザは、契約依頼を行う事業者として、第１事業者を選択して、契約依頼欄７１ｆ（図１０参照）を操作したこととする。この場合、見積サーバ１のＣＰＵ１１は、ユーザ端末２から、第１事業者に契約依頼がなされたことを示す契約依頼情報を入力する（Ｓ１５）。
【００６７】
次に、見積サーバ１のＣＰＵ１１は、契約依頼情報に基づいて、受注した事業者の事業者端末に、受注情報を送信する（Ｓ１６）。本形態では、第１事業者が受注したため、第１事業者端末３Ａに、受注情報が送信される。また、見積サーバのＣＰＵ１１は、見積金額を算出した事業者のうち、失注した事業者に、失注情報を送信すると共に、受注価格を送信する。本形態では、第３事業者が失注したため、第３事業者端末３Ｃに、失注情報が送信されると共に、受注価格として第１事業者が算出した見積金額が送信される。ここで、失注した事業者に受注価格を送信するのは、失注した事業者に自身が算出した見積金額の妥当性を再考させるためである。
【００６８】
次に、本形態の作用効果について、説明する。解体費用の見積もりでは、ユーザの建設物件に全く同じものが存在しないため、見積もりに多大な時間を要するという実情がある。例えば、ユーザは、解体費用の見積もりを５つの事業者に依頼することとする。この場合、ユーザは、５つの事業者に連絡すると共に、物件の立ち合いを５回行うため、少なくとも十数時間を費やすことになる。また、５つの事業者にとっても、それぞれ現地確認を行って、見積もりを作成するため、各事業者はそれぞれ３時間以上の時間を費やす。また、各事業者は見積もりを作成し終えるまでに、１か月以上の時間を費やす。従って、ユーザは、見積もりの相場を把握するために、１か月以上待つ必要がある。そして、５つの事業者のうち少なくとも４つの事業者は、失注することになるため、見積もりを作成した負担が無駄になってしまう。加えて、ユーザが見積金額の相場を把握していない場合には、ユーザの希望価格と見積金額との差が大きくて、５つの事業者全てが失注することもある。
【００６９】
そこで、本形態では、見積サーバ１が、ユーザからの簡易情報と、予め登録された基準価格ＴＢ１２１及び過去価格ＴＢ１２２と、に基づいて、約１０００の事業者から抽出された５つの事業者毎に、予想金額を算出する（図８参照）。ここで、見積サーバ１が、簡易情報を入力してから各予想金額を算出するまでの時間は、数秒程度である。従って、ユーザは、５つの事業者毎の予想金額により、極めて短時間で、各事業者の解体費用（建設費用）の相場を把握することができる。その上で、ユーザは、５つの事業者を比較して、見積金額を算出する事業者を選択する。こうして、ユーザには、各事業者の解体費用の相場を把握した上で、５つの事業者の中から、本当に依頼したい事業者にだけ、見積もりを依頼させることができる。そして、５つの事業者側にとっては、ユーザによって選択された事業者のみ（本形態では、第１事業者と第３事業者だけ）見積もりを作成するため、対応負担を軽減することができる。更に、ユーザが各事業者の解体費用の相場を把握している以上、選択された事業者全てが失注するリスクを軽減することができる。以上により、解体費用の見積もりにおいて、ユーザ・事業者共に負担を軽減することができる。
【００７０】
次に、変形例について説明する。なお、変形例の説明において、第１形態と同様の構成については、同じ符号を付して説明を省略する。勿論、変形例に係る構成同士を適宜組み合わせて構成してもよい。また、上記第１形態および下記変更例中の技術的特徴は、本明細書において必須なものとして説明されていなければ、適宜、削除することが可能である。
【００７１】
＜第２形態＞
第２形態では、建設費用の見積もりとして、リフォーム費用の見積もりを例にして説明する。但し、以下では、第１形態の相違点を中心に説明する。
【００７２】
第２形態では、ユーザによって、図１１に示すように、ユーザＩＦに、簡易情報入力画像４０Ａが表示される。ここで、リフォーム費用の見積もりの場合には、第１形態で説明した建物種別が、工事場所に替わり、第１形態で説明した建物構造が、ユーザが好むタイプに替わり、第１形態で説明した延床面積が、大きさに替わる。なお、第２形態では、第１形態で説明した階層の項目、第１形態で説明した前面道路の幅の項目、第１形態で説明した隣家距離の項目がない。
【００７３】
図１１に示すように、第２形態の簡易情報入力画像４０Ａでは、第１形態の簡易情報入力画像４０（図６参照）と異なり、工事場所入力欄４２Ａと、タイプ入力欄４３Ａと、タイプ判別欄４３Ｂと、大きさ入力欄４５Ａと、が示されている。工事場所入力欄４２Ａでは、リフォームの対象となる場所として、居室、浴室、トイレ、又はキッチンの何れであるかが入力される。タイプ入力欄４３Ａでは、ユーザがリフォームする際の好みとして、ベーシック、和モダン、ヨーロピアン、又はメルヘンの何れであるかが入力される。タイプ判別欄４３Ｂは、ユーザが自身の好みが分からない場合に操作される。大きさ入力欄４５Ａでは、ユーザが入力した工事場所に応じた大きさ（畳、坪、ｃｍ）が入力される。具体的に、居室の場合には何畳であるかが入力され、浴室又はトイレである場合には何坪であるかが入力され、キッチンである場合には何ｃｍの幅であるかが入力される。
【００７４】
ここで、ユーザが、タイプ判別欄４３Ｂを操作すると、ユーザ端末２のＣＰＵ２１は、ユーザＩＦ２３にて、タイプ判別画像８０（図１２参照）を表示させる。例えば、ユーザが工事場所として浴室を選択している場合には、図１２に示すように、タイプ判別画像８０では、６つの浴室画像８１ａ〜８１ｆと、各浴室画像８１ａ〜８１ｆに対応する６つのチェックボックス８２ａ〜８２ｆと、が示される。ユーザは、タイプ判別画像８０の上部に示されている３つの浴室画像８１ａ〜８１ｃのうち、好みの浴室画像を１つ選んで、その浴室画像に対応するチェックボックスを操作する。同様に、ユーザは、タイプ判別画像８０の下部に示されている３つの浴室画像８１ｄ〜８１ｆのうち、好みの浴室画像を１つ選んで、その浴室画像に対応するチェックボックスを操作する。
【００７５】
こうして、ユーザが２つの浴室画像を選択することで、ユーザ端末２のＣＰＵ２１が、メモリ１２に記憶されている組合せパターンに基づいて、ユーザの好みを判別する。そして、ＣＰＵ２１は、タイプ判別画像８０の下部に設けられている判定結果欄８３に、判別したユーザの好みとして、ベーシック、和モダン、ヨーロピアン、又はメルヘンの何れかを表示させる。こうして、ユーザは、リフォームする場所の自身の好みを把握することができる。なお上記では、浴室が選択されている場合の好みを判別する場合を説明したが、居室、トイレ、又はキッチンが選択されている場合も同様であるため、説明を省略する。ユーザは、タイプ判別画像８０の下部に設けられている戻る欄８４を操作すると、ユーザＩＦ２３に、簡易情報入力画像４０Ａ（図１１参照）が表示される。
【００７６】
第２形態では、見積サーバ１のメモリ１２に、図１３に示す基準価格ＴＢ１２１Ａと、図１４に示す過去価格ＴＢ１２２Ａと、が記憶されている。図１３に示す基準価格ＴＢ１２１Ａでは、図２に示す基準価格ＴＢ１２１の建物種別の項目が、工事場所に替わっていて、図２に示す基準価格ＴＢ１２１の建物構造の項目が、タイプに替わっていて、図２に示す基準価格ＴＢ１２１の延床面積の種別の項目が、大きさに替わっている。図１４に示す過去価格ＴＢ１２２Ａでは、図３に示す過去価格ＴＢ１２２の建物種別の項目が、工事場所に替わっていて、図３に示す過去価格ＴＢ１２２の建物構造の項目が、タイプに替わっていて、図３に示す過去価格ＴＢ１２２の延床面積の種別の項目が、大きさに替わっている。
【００７７】
但し、図１４に示すように、過去価格ＴＢ１２２Ａでは、事業者毎に、且つ工事場所毎に、得意なタイプが記憶されている。得意なタイプは、見積サーバ１のＣＰＵ１１により、自動で判別されている。具体的に、見積サーバ１のメモリ１２には、事業者毎に、且つ工事場所毎に、各事業者が過去にリフォームした際のリフォーム画像データが、記憶されている。また、メモリ１２には、工事場所毎に、タイプを判別するためのタイプ判別画像データが、記憶されている。そして、ＣＰＵ１１は、リフォーム画像データとタイプ判別画像データとの一致点を調査することにより、事業者の得意なタイプがベーシック、和モダン、ヨーロピアン、又はメルヘンの何れであるかを判別する。こうして、ＣＰＵ１１が判別した得意なタイプは、過去価格ＴＢ１２２Ａにおいて、事業者毎に、且つ工事範囲毎に、記憶されている（図１４参照）。
【００７８】
以上、第２形態では、見積サーバ１のＣＰＵ１１は、第１形態で説明した建物種別を工事場所に替えて、第１形態で説明した建物構造をユーザが入力したタイプに替えて、第１形態で説明した延床面積を大きさに替えて、第１形態と同様に、５つの事業者毎に予想金額を算出する。但し、第２形態では、ＣＰＵ１１は、第１形態と異なり、５つの事業者を抽出する前に、ユーザが入力したタイプと、事業者の得意なタイプと、を照合することで、予想金額を算出する事業者を予め抽出する。これにより、ユーザが好むタイプを得意としない事業者に対して、予想金額を算出するのを防ぐことができる。ＣＰＵ１１は、予想金額を算出した後、５つの事業者のうち、ユーザによって選択された事業者から、算出された見積金額を入力する。
【００７９】
第２形態の作用効果は、第１形態の作用効果のうち、解体費用の見積もりを、リフォーム費用の見積もりに替えただけであり、第１形態と同様の作用効果を奏する。従って、詳細な説明を省略する。なお、リフォーム費用の見積もりの方が、解体費用の見積もりよりも、部材と工数で価格が定まっていることが多いため、見積サーバ１のＣＰＵ１１は、予想金額を算出し易い。
【００８０】
＜第３形態＞
第３形態では、第１形態と異なり、ユーザによって、見積金額を算出する事業者が選択されることない。つまり、予想金額が算出された５つの事業者が、見積金額を算出する。以下では、図１５に基づいて、第１形態との相違点を中心に説明する。
【００８１】
第３形態では、図１５に示すように、ユーザ端末２に、見積金額が算出される可能性が高い上位５社の情報と、各予想金額と、が送信された後（Ｓ０７）、ユーザ端末２では、見積金額を算出する事業者が選択されない。即ち、図４に示すＳ０８の処理がない。見積サーバ１のＣＰＵ１１は、Ｓ０７の処理の後、ユーザ端末２から詳細情報を入力することで（Ｓ０９）、ユーザから上位５社の見積もり依頼があったと判断する。これにより、ＣＰＵ１１は、上位５社の事業者の事業者端末に、詳細情報と予想金額とを送信する（Ｓ２１０）。その後の処理については、第１形態で説明した図５に示す処理と同様であるため、説明を省略する。
【００８２】
第３形態では、ユーザは、予想金額が算出された５つの事業者の中から、見積金額を算出する事業者を選択するわけではない。そのため、予想金額が算出された５つの事業者は、見積もりを作成する必要がある。これに対して、第１形態では、ユーザは、５つの事業者毎に予想金額を比べて、見積金額を算出する事業者を選択する。そのため、予想金額が算出された５つの事業者の中から更に絞り込まれた事業者だけ、見積もりを作成する。以上により、第１形態では、第３形態と比べて、各予想金額を見たユーザに、見積もり依頼を行う事業者を選択させる点で、有利である。更に、第１形態では、第３形態と比べて、見積金額を算出する事業者が少なくなり、事業者側の負担を軽減できる点で、有利である。
【００８３】
＜第４形態＞
第４形態では、第１形態と異なり、見積サーバ１の所有者が、見積金額を算出する事業者を選択する。以下では、図１６に基づいて、第１形態と相違点を中心に説明する。
【００８４】
第４形態では、図１６に示すように、ユーザ端末２に、見積金額が算出される可能性が高い上位５社の情報と、各予想金額と、が送信された後（Ｓ０７）、見積サーバ１の所有者は、電話又はメール等でユーザに連絡する。そして、見積サーバ１の所有者とユーザとが、５つの事業者のうち、どの事業者が見積もりを算出するのに相応しいのかを相談する。その後、見積サーバ１の所有者は、ユーザからの意見を聞き出した後に、５つの事業者の中から、見積金額を算出する事業者を選択する（Ｓ３０８）。その後の処理については、第１形態で説明した図４及び図５に示す処理と同様であるため、説明を省略する。
【００８５】
第４形態では、第１形態と異なり、見積サーバ１の所有者とユーザとが連絡を取り合う必要がある。従って、第４形態では、第１形態に比べて、ユーザに、見積サーバの所有者と対応する負担を強いることになる。言い換えれば、第１形態の方が、第４形態よりも、ユーザに、建設費用の見積もりを気軽に利用してもらうことができる点で、有利である。
【００８６】
＜その他の変形例＞
上記各形態では、見積サーバ１のＣＰＵ１１は、図７（Ｂ）に示すように、相関係数が第１閾値α以上であり、且つ第２閾値βよりも小さい場合に、過去価格近似曲線と基準価格近似曲線のうち、価格が低くなる方の近似曲線を用いて、面積比例価格Ｋ２を算出した。しかしながら、ＣＰＵ１１は、この場合に、基準価格近似曲線から求まる価格の一部と、過去価格近似曲線から求まる価格の一部と、を加算することで、面積比例価格を算出するようにしても良い。また、ＣＰＵ１１は、各基準価格と各過去価格とを区別しないで、各基準価格及び各過去価格の両方のデータから近似曲線を求めて、面積比例価格を算出するようにしても良い。また、ＣＰＵ１１は、基準価格ＴＢ１２１に記憶されている各基準価格と、過去価格ＴＢ１２２に記憶されている各過去価格と、を用いて、機械学習に基づく予測分析によって、面積比例価格を算出するようにしても良い。
【００８７】
上記各形態では、見積サーバ１のＣＰＵ１１は、予想金額を算出した事業者のうち、見積金額の算出依頼を受け付ける可能性が高い５つの事業者を、表示させるようにした。しかしながら、ＣＰＵ１１は、見積金額の算出依頼を受け付ける可能性が高い事業者を、２〜４つ、又は６つ以上、表示させるようにしても良い。なお、ＣＰＵ１１は、見積金額を算出する可能性が高い事業者を、１０以上表示させても良い。ユーザは、より多くの事業者毎の見積金額を比べることができるからである。また、ユーザが、簡易情報入力画像４０の表示中に、予想金額が算出される事業者の数を入力できるようにして、ＣＰＵ１１が、ユーザによって入力された事業者の数だけ、見積金額の算出依頼を受け付ける可能性が高い事業者を表示させるようにしても良い。
【００８８】
上記各形態では、見積サーバ１のＣＰＵ１１は、予想金額を算出した事業者を、予想金額の低さ、ユーザの物件住所と各事業者の住所との間の距離の近さ、ユーザ評価の高さの３つに基づいて、見積金額の算出依頼を受け付ける可能性が高い事業者を順位付けた。しかしながら、ＣＰＵ１１は、上記した３つの項目のうち、何れか１つ、又は何れか２つに基づいて、見積金額の算出依頼を受け付ける可能性が高い事業者を抽出しても良い。また、ＣＰＵ１１は、過去に見積金額の算出依頼を受け付けた事業者毎のデータを用いて、機械学習に基づく予測分析によって、見積金額を算出する可能性が高い事業者を順位付けるようにしても良い。
【００８９】
上記各形態において、見積サーバ１のＣＰＵ１１は、見積金額の算出依頼を受け付ける可能性が高い上位数社の事業者に替えて、契約依頼（最終的な成約）を受け付ける可能性が高い上位数社（例えば上位５社）を、表示させるようにしても良い。この場合、ＣＰＵ１１は、過去に契約依頼を受け付けた事業者毎のデータを用いて、機械学習に基づく予測分析によって、契約依頼を受け付ける可能性が高い上位数社を表示させると良い。ここで、一人のユーザにつき、契約依頼を受け付ける事業者は、基本的に１つだけである。これに対して、一人のユーザにつき、見積金額の算出依頼を受け付ける事業者は、少なくとも１つあって、複数であることが多い。従って、過去に見積金額の算出依頼を受け付けた事業者のデータ数は、過去に契約依頼を受け付けた事業者のデータ数よりも、多くなる。よって、見積金額の算出依頼を受け付ける可能性が高い事業者を求めるために行う機械学習の方が、契約依頼を受け付ける可能性が高い事業者を求めるために行う機械学習よりも、精度が高くなり易い。
【００９０】
上記各形態において、簡易情報入力画像４０の表示中に、ユーザには、上限予想金額を入力させるようにしても良い。この場合、見積サーバ１のＣＰＵ１１は、ユーザ端末２から送信された上限予想金額よりも、算出した予想金額が低い事業者を抽出すると良い。これにより、ユーザにとって希望しない上限予想金額を超える事業者が、予想金額表示画像５０に表示されるのを防ぐことができる。
【００９１】
上記各形態において、予想金額表示画像５０の表示中に、予想金額が算出された事業者毎に、工事可能時期が表示されるようにしても良い。これにより、ユーザは、予想金額だけでなく、工事可能時期も参照して、見積金額を算出する事業者を選択できる。
【００９２】
上記第１形態において、見積サーバ１のＣＰＵ１１は、ユーザが入力する延床面積に基づいて、解体費用の予想金額を算出した。しかしながら、ＣＰＵ１１は、延床面積以外で、工事する範囲が分かる情報（例えば施工面積、建築面積）に基づいて、解体費用の予想金額を算出しても良い。同様に、第２形態において、見積サーバ１のＣＰＵ１１は、居室の大きさを示す畳、浴室又はトイレの大きさを示す坪、キッチンの幅を示すｃｍ以外で、工事する範囲が分かる情報（例えば、平方ｍ、立法ｍ、高さｍｍなど）に基づいて、リフォーム費用の予想金額を算出しても良い。即ち、「工事範囲情報」は、工事する範囲が分かる情報であれば、適宜変更可能である。
【００９３】
上記第１形態において、見積サーバ１のＣＰＵ１１は、ユーザが入力した住所情報と、基準価格ＴＢ１２１に記憶されている事業者毎の住所情報と、に基づいて、事業者を抽出した（Ｓ０２）。しかしながら、基準価格ＴＢ１２１には、事業者毎に、対応可能住所情報（例えば事業者の住所から半径５０ｋｍ以内で対応可能であることを示す情報）が記憶されていて、ＣＰＵ１１は、ユーザが入力した住所情報と、事業者毎の対応可能住所情報と、に基づいて、事業者を抽出しても良い。即ち、「予め登録された複数の事業者の住所情報」には、事業者毎の対応可能住所情報も含まれる。
【００９４】
上記第１形態において、基準価格ＴＢ１２１（図２参照）及び過去価格ＴＢ１２２（図３参照）の構成は、一例であり、含まれる項目は、適宜変更可能である。例えば、建築工法、基礎種別、解体種別（全部解体、一部解体、内装の解体）、築年数などの項目が、含まれていても良い。また上記第２形態において、基準価格ＴＢ１２１Ａ（図１３参照）及び過去価格ＴＢ１２２Ａ（図１４参照）の構成は、一例であり、含まれる項目は、適宜変更可能である。例えば、メーカ種別などの項目が、含まれていても良い。
【００９５】
上記各形態において、見積サーバ１のＣＰＵ１１は、見積金額の算出依頼を受け付ける可能性が高い上位５社の事業者の情報と、各予想金額と、をユーザ端末２に送信することで（Ｓ０７）、図１０に示すように、ユーザ端末２は、ユーザＩＦ２３にて、上位５社の事業者を表示した。しかしながら、ＣＰＵ１１は、上位５社の事業者を抽出した後（Ｓ０６）、見積サーバ１のメモリ１２に記憶されている見積金額表示画像の表示態様を、図１０に示す表示態様に変更する。これにより、ユーザ端末２が、見積サーバ１にアクセスすることで、ユーザＩＦ２３にて、上位５社の事業者が表示されるようにしても良い。
【００９６】
上記各形態において、簡易情報入力画像４０の表示中に、ユーザには、物件住所のうち、厳密な住所まで入力させるようにしても良い。これにより、詳細情報入力画像６０の表示中に、ユーザに物件住所を入力させる必要がなくなり、ユーザの入力作業を減らすことができる。
【００９７】
上記各形態において、ユーザ端末２は、スマートフォン（携帯端末）であったが、デスクトップのＰＣなど、固定端末であっても良い。
【００９８】
上記各形態において、建設費用の見積もりは、解体費用又はリフォーム費用の見積もりに限られず、適宜変更可能である。例えば、見積サーバ１は、外構費用の予想金額を算出して、外構費用の見積金額の入力を受け付けるようにしても良い。
【符号の説明】
【００９９】
１…見積サーバ
２…ユーザ端末
３…事業者端末
１１、２１…ＣＰＵ
２２…メモリ
５０…予想金額表示画像
７０…見積金額表示画像
１２１…基準価格ＴＢ
１２２…過去価格ＴＢ
【図１】
2020057417.tif 000003
【図２】
2020057417.tif 000004
【図３】
2020057417.tif 000005
【図４】
2020057417.tif 000006
【図５】
2020057417.tif 000007
【図６】
2020057417.tif 000008
【図７】
2020057417.tif 000009
【図８】
2020057417.tif 000010
【図９】
2020057417.tif 000011
【図１０】
2020057417.tif 000012
【図１１】
2020057417.tif 000013
【図１２】
2020057417.tif 000014
【図１３】
2020057417.tif 000015
【図１４】
2020057417.tif 000016
【図１５】
2020057417.tif 000017
【図１６】
2020057417.tif 000018