JP7091639B2 - 推定プログラム、推定方法および推定装置 - Google Patents

Description

本発明は、推定プログラム、推定方法および推定装置に関する。

Ｗｅｂページなどを用いて、ユーザに複数の選択肢やアイテムを提示し、ユーザの選択回答に基づき、ユーザの選好を探索する技術が知られている。また、アイテム空間から属性の組で特定されるアイテムを探索するシステムにおいて、ユーザに提示するアイテムの数を的確な数となるように、属性の組を選択する技術が知られている。

特表２００９－５４０４７５号公報 特開２００６－３３０８５８号公報

ところで、ユーザが、自身が望む真の選好にたどり着く過程で、自身の今の選好を確認し、洗練するために他のアイテムが提示されるように、システムへ入力する指標を変更するプロセスである収束プロセスが存在することが知られている。

図１８は、収束プロセスを説明する図である。図１８は、交通利便性と安全性との２次元の指標でアイテムが特定される例を示す。図１８に示すように、ユーザは、自分の選好として交通利便性の重要度を上げてきたが、安全性の重要度を上げるまたは下げることを行った方がよりアイテムが探索できるのではないかと考える。このとき、ユーザは、自身が明確に重視するメイン指標以外のサブ指標を様々に動かすことによって、より自分にあうアイテムが出るように入力内容を洗練していく。

しかしながら、ユーザが収束プロセス等により、新たなアイテムが提示されるように入力内容を変更する場合、他のアイテムが提示されるためには、ユーザにより変更する入力内容では不足する場合がある。例えば、ユーザがメイン指標のみを重視しようと思っても、サブ指標の値も変えないとメイン指標のスコアの高いアイテムが出てこない場合がある。この場合、ユーザは、指標変更の回数が足りないと思い、何度もリストを更新するが、アイテムが変更されず、自分の選好が進まなくなる状況が生じる。

また、システム側が、過去の入力内容とは関連しない、単に新たなアイテムを提示することも考えられる。この場合、今まで繰り返し指標を入力してきたことによる自分の選好とは関連性が弱いアイテムが提示されるので、ユーザが自身の選好を確認するための情報としても、システムがユーザの選好を特定するための情報としても有用ではない。

一つの側面では、ユーザへ表示するアイテムの変更とユーザ選好の特定を両立して進めることができる推定プログラム、推定方法および推定装置を提供することを目的とする。

第１の案では、推定プログラムは、それぞれ複数の選択肢を含む、複数の問い合わせに対する回答に基づき、回答者の選好を推定する処理をコンピュータに実行させる。推定プログラムは、コンピュータが、前記回答者からの複数の回答内容に基づき、選好トレンドを生成する処理をコンピュータに実行させる。推定プログラムは、前記回答者に対する問い合わせで提示される提示アイテムの内容の履歴に基づき、提示アイテムを変更する情報の提示要否を判定する処理をコンピュータに実行させる。推定プログラムは、コンピュータが、前記判定に応じて、前記提示アイテムを変更させる入力候補を前記選好トレンドに基づき生成し、前記問い合わせにおいて、提示アイテムとともに前記入力候補を表示する処理をコンピュータに実行させる。

一実施形態によれば、ユーザへ表示するアイテムの変更とユーザ選好の特定を両立して進めることができる。

図１は、実施例１にかかるシステムの全体構成例を説明する図である。 図２は、実施例１にかかる探索装置の機能構成を示す機能ブロック図である。 図３は、自治体情報ＤＢに記憶される情報の例を示す図である。 図４は、候補ＤＢに記憶される情報の例を示す図である。 図５は、アイテムの具体的な表示例を説明する図である。 図６は、アイテムの更新および順位付けを説明する図である。 図７は、凸包の端点の特定例を説明する図である。 図８は、アイテム群の順位の特定例を説明する図である。 図９は、選好トレンドの推定例を説明する図である。 図１０は、選好トレンドに対応する候補ベクトルの判定例を説明する図である。 図１１は、推薦方向を促すメッセージの提示例を説明する図である。 図１２は、推薦方向の新しいアイテムの提示例を説明する図である。 図１３は、ユーザ選好の選択時のアイテム表示処理の流れを示すフローチャートである。 図１４は、新しいアイテムの提示処理の流れを示すフローチャートである。 図１５は、実施例１による手法と一般技術との比較例を説明する図である。 図１６は、選好をランダムに選択した場合のアイテム提示例を説明する図である。 図１７は、ハードウェア構成例を説明する図である。 図１８は、収束プロセスを説明する図である。

以下に、本願の開示する推定プログラム、推定方法および推定装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。

［全体構成］
図１は、実施例１にかかるシステムの全体構成例を説明する図である。図１に示すように、このシステムは、ユーザ端末１と探索装置１０とがネットワークＮを介して接続される移住者マッチングシステムである。ネットワークＮは、有線や無線を問わず、インターネットなどの各種ネットワークを採用することができる。

本システムでは、移住希望者が使用するユーザ端末１が、移住地を検索するために探索装置１０にアクセスする。そして、探索装置１０が、ユーザ端末１に複数回の質問を表示させて、移住希望者（以下、ユーザと記載する場合がある）の重要項目や好みなどである選好を推定し、選好に合致する地方自治体をユーザ端末１に表示する。このようにして、本システムは、移住希望者と移住先となる地方自治体とをマッチングするシステムである。

なお、本実施例では、移住者マッチングシステムを例にして説明するが、これに限定されるものではない。例えば、ユーザへの問い合わせの回答によってユーザの選好を推定するシステムであれば、どのようなシステムにも適用することができる。

ユーザ端末１は、移住希望者が使用するコンピュータ装置であり、例えばパーソナルコンピュータ、携帯電話、タブレット端末、スマートフォンなどである。なお、移住希望者は、回答者の一例である。

探索装置１０は、上述した移住者マッチングを実行するサーバ装置の一例である。この探索装置１０は、「地域Ａ、地域Ｂ、地域Ｃ」などの地方自治体に関する情報、移住希望者が探索した履歴、移住希望者が移住先に要求する選好の推定に関する情報などの各種ログを記憶する。そして、探索装置１０は、移住希望者に問い合わせ（質問）を複数回提示して、その回答によって移住希望者の選好を推定し、移住希望者の希望と合致する移住先（地方自治体）を提示する。なお、本実施例では、移住希望者に提示する移住先を「アイテム」を記載する場合がある。

一般的に、都市部の住人が移住する地域を選択する際、移住先への希望をシステムに入力する必要があるが、移住後の生活利便性の低下などを考慮できず、真の選好を明示的に表現できない。そこで、探索装置１０は、地方自治体への移住希望者に対して適切な地域を人間の心理を元に提案するレコメンドシステムを実現し、移住希望者が潜在的にまたは無意識に要求する自らの真の選好に辿り着けるように、ユーザへの情報提示を実行する。

このようなシステムにおいて、探索装置１０は、それぞれ複数の選択肢を含む、複数の問い合わせに対する回答（選好）に基づき、ユーザの選好を推定する。具体的には、探索装置１０は、ユーザからの複数の回答内容に基づき、ユーザの選好の方向である選好トレンドを生成する。探索装置１０は、ユーザに対する問い合わせにおいて提示されたアイテムの内容の履歴に基づき、表示するアイテムを変更する要否を判定する。そして、探索装置１０は、判定に応じて、提示する提示アイテムを変更させる入力候補を選好トレンドに基づき生成し、問い合わせにおいて、提示アイテムとともに表示する。

例えば、ユーザは、今の自分の選好に近い別のアイテムを検討することで、自分の現状の選択が正しいか検証したい。このため、ユーザが、真の選好にたどり着く過程で、自身の今の選好を確認し、洗練するために他のアイテムを出そうとするプロセス（以下では、収束プロセスと記載する場合がある）を実行する。

このとき、探索装置１０は、ユーザのログデータ（選好履歴）から、ユーザが選好していきそうな方向にあたりをつけ、ユーザに対してそちらの方向に選好することをサジェストする。具体的には、探索装置１０は、ユーザの選好する候補をユーザに対して提案する。このように、探索装置１０は、提示アイテムを入れ替えつつ、より多くのアイテムを提示することで、ユーザへ表示するアイテムの変更とユーザ選好の特定を両立して進める。なお、本実施例では、この提案の候補を絞り込むことを、方向付けを絞り込む、と表現する。

図２は、実施例１にかかる探索装置１０の機能構成を示す機能ブロック図である。図２に示すように、探索装置１０は、通信部１１、記憶部１２、制御部２０を有する。通信部１１は、ユーザ端末１などの他の端末との通信を制御する処理部であり、例えば通信インタフェースなどである。例えば、通信部１１は、ユーザ端末１との間でＷｅｂブラウザによる通信を確立し、Ｗｅｂブラウザ上での情報のやり取りを実現する。

記憶部１２は、プログラムやデータを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。この記憶部１２は、自治体情報ＤＢ１３、履歴情報ＤＢ１４、候補ＤＢ２５を記憶する。なお、記憶部１２は、これらのＤＢ以外にも、例えば氏名や選好の推定状況など移住希望者であるユーザに関する各種情報を記憶することもできる。

自治体情報ＤＢ１３は、探索装置１０がマッチング対象とする地方自治体に関する情報を記憶するデータベースである。図３は、自治体情報ＤＢ１３に記憶される情報の例を示す図である。図３に示すように、自治体情報ＤＢ１３は、「地域名、交通利便性、買い物、学校、近所付合、病院、安全性」などを対応付けて記憶する。

ここで記憶される「地域名」は、移住先となる地方自治体の地域の名称である。「交通利便性、買い物、学校、近所付合、病院、安全性」は、地域のアピールポイントなどであり、ここで挙げた項目は任意に数や内容を変更することができる。「交通利便性」は、地域の交通の利便性に関する情報であり、「買い物」は、地域にあるスーパーなどの情報であり、「学校」は、地域内の学校の設置情報などである。「近所付合」は、地域の近所付き合いに関する情報であり、「病院」は、地域内の病院に関する情報であり、「安全性」は、地域内の犯罪件数などに関する情報である。

図３の場合、「地域Ａ」は、１日に○○駅から片道〇本の電車が通っており、地域内に大型スーパーがあり、最寄りの小学校まで徒歩〇分である。また、「地域Ａ」は、行事参加率が〇％であり、かかりつけ医院数が〇件であり、軽犯罪が１年に〇件発生していることを示す。なお、自治体情報ＤＢ１３は、各項目を具体的数値（例えば点数）で保持することもできる。

履歴情報ＤＢ１４は、移住者マッチングで発生した各種ログを記憶するデータベースである。具体的には、履歴情報ＤＢ１４は、ユーザごとに、探索装置１０からの問合せ、当該問い合わせに対する応答、ユーザが入力した属性組、ユーザの選択履歴（選好履歴）などを記憶する。

候補ＤＢ１５は、後述する選好推定部３０によって生成された、ユーザに提示するアイテムの候補を記憶するデータベースである。図４は、候補ＤＢ１５に記憶される情報の例を示す図である。図４に示すように、候補ＤＢ１５は、「１位のアイテム、上位３件」を対応付けて記憶する。ここで記憶される「１位のアイテム」は、ユーザの選好に最も近いと判断されたアイテムであり、「上位３件」は、ユーザの選好に近いと推定される上位３件のアイテムである。図４の例では、１位のアイテムがＡのとき、上位３件のアイテムがＡ、Ｂ、Ｇの３件であることを示す。

制御部２０は、探索装置１０全体を司る処理部であり、例えばプロセッサなどである。この制御部２０は、表示制御部２１と選好推定部３０とを有する。なお、表示制御部２１と選好推定部３０は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例である。

表示制御部２１は、ユーザの選好に応じてアイテムの表示制御を実行する処理部であり、選好受付部２２と更新部２３とを有する。例えば、表示制御部２１は、アイテムが提示されたＷｅｂ画面をユーザ端末１に表示して、Ｗｅｂ画面上でユーザの選好を受け付ける。そして、表示制御部２１は、受け付けたユーザの選好に応じて、提示するアイテムを変更し、当該アイテムが提示されるＷｅｂ画面をユーザ端末１に表示する。

選好受付部２２は、アイテムを表示するＷｅｂ画面上でユーザの選好を受け付ける処理部である。図５は、アイテムの具体的な表示例を説明する図である。図５に示す画面５０の５０ａの領域は、Ｗｅｂ画面のタイトルを表示したり、ユーザが選択した属性やユーザが重視項目を表示したりする領域である。５０ｂの領域は、ユーザとマッチングされた地方自治体の一覧が表示される領域、すなわちアイテムのトップＮリストが表示される領域である。

ボタン５０ｃおよびボタン５０ｄは、重視項目の選択を受け付けるボタンであり、交通利便性を重視するときはボタン５０ｃが選択され、安全性を重視するときはボタン５０ｄが選択される。ボタン５０ｅは、確認画面へ進むボタンであり、満足する地方自治体が探索されたときに押下される。また、ボタン５０ｆは、リストの更新を要求するボタンである。ボタン５０ｇは、お気に入りへの追加ボタンであり、ユーザが移住先の比較検討に用いるために一時的に情報を記憶させるボタンである。ボタン５０ｈは、後述する選好推定部３０による処理の実行トリガーであり、ユーザが選好に困ったと想定されるときに実行される処理のトリガーの一例である。

例えば、選好受付部２２は、図５に示すＷｅｂ画面上でボタン５０ｃが選択されて、リスト更新のボタン５０ｆが押下された場合に、ユーザの選好として「交通利便性」を重要視すると判定する。より詳細には、選好受付部２２は、「交通利便性＋」と判断して、現状の選好よりも、交通利便性が所定値以上高いアイテムを提示対象と判定して、更新部２３に通知する。なお、本実施例では、ユーザの選好として、「交通利便性」と「安全性」の２次元空間を用いる例を説明するが、これに限定されるものではなく、選好となる属性の数は任意に増減させることができる。

更新部２３は、選好受付部２２によって受け付けられた選好に応じて、提示するアイテムを更新する処理部である。また、更新部２３は、Ｗｅｂ画面等を用いて、アイテム提示前に受け付けられたユーザの選好に応じて、アイテムを選択してユーザに提示する。

具体的には、更新部２３は、交通利便性（縦軸）と安全性（横軸）とから決定される選好空間上で、ユーザが選好した位置を特定し、原点から当該位置へのベクトル（選好ベクトルβ）を特定する。そして、更新部２３は、提示するアイテムの順位を、交通利便性（縦軸）と安全性（横軸）とから決定されるアイテム空間上に、選好ベクトル（β）と並行に伸ばした直線上に、アイテムを正射影した時の並びで決定する。すなわち、アイテムの順位は、選好ベクトル（β）の比のみによってアイテムの順位や得点が決定される。

図６は、アイテムの更新および順位付けを説明する図である。図６に示すように、更新部２３は、ユーザの選好結果にしたがって、選好空間上でユーザ選好の位置を決定し、当該位置までの選好ベクトルβを特定する。そして、更新部２３は、アイテム空間上に選好ベクトルβを位置づけ、選好ベクトルβを延長する。その後、更新部２３は、各アイテムから延長済みの選好ベクトルβへ垂線を引き、原点と反対側から垂線を計数したときの登場順のＮ個のアイテムを、トップＮリストとして、Ｗｅｂ画面でユーザに提示する。図６の例では、更新部２３は、上位３個のアイテムを特定し、トップ３リストとして、図５の画面５０の５０ｂの領域に表示する。

選好推定部３０は、ユーザが指標変更するときに、より新しいアイテムが出やすく、かつ、ユーザの真の選好に近いと思われる方向をサジェストする処理部であり、事前処理部３１、仮選好推定部３２、候補判定部３３を有する。具体的には、選好推定部３０は、ユーザが収束プロセスに突入するのを抑制し、ユーザの収束プロセスを早期に終了させるために、ユーザが収束プロセスの状態か否かを検出する。そして、選好推定部３０は、ユーザが収束プロセスの状態である場合に、ユーザが重視しそうな単一の指標をサジェストするだけでなく、併せて変化させる必要のある指標の動かし方を提示する。なお、仮選好推定部は、生成部の一例であり、候補判定部３３は、判定部と表示制御部の一例である。

事前処理部３１は、事前処理を実行する処理部である。具体的には、事前処理部３１は、複数の選好ベクトルと各選好ベクトルを選択した時のアイテム順位を予め算出しておき、候補ＤＢ１５に格納する。例えば、事前処理部３１は、アイテム空間の特性を利用し、アイテム空間の凸包の端点となるアイテムを、１位になる可能性があるアイテムと特定する。そして、事前処理部３１は、各端点を一位とした時に上位Ｎ件でどのようなアイテムが出るかも特定し、候補ＤＢ１５に保存する。

図７と図８を用いて具体的に説明する。図７は、凸包の端点の特定例を説明する図である。図８は、アイテム群の順位の特定例を説明する図である。図７に示すように、事前処理部３１は、アイテム空間上に各アイテム（白丸）をマッピングする。続いて、事前処理部３１は、アイテム空間上で凸包を生成し、凸包の端点となるアイテムＡ、アイテムＢ、アイテムＨ、アイテムＬ、アイテムＫ、アイテムＩ、アイテムＥ、アイテムＣ、アイテムＤを、提示対象のアイテムで一位になりえるアイテムとして特定する。

続いて、図８に示すように、事前処理部３１は、凸包の重心から各端点に伸ばしたベクトルを、その端点のアイテムを一位にするベクトルとして、選好空間上に保存する。一例を挙げると、事前処理部３１は、アイテムＡへの候補ベクトルβ＿Ａ、アイテムＢへの候補ベクトルβ＿Ｂ、アイテムＨへの候補ベクトルβ＿Ｈ、アイテムＬへの候補ベクトルβ＿Ｌなどを、各端点について選好空間上に生成する。

その後、事前処理部３１は、各候補ベクトルについて、図６と同様の手法によってアイテムの順位付けを行い、上位３つのアイテムを特定する。例えば、事前処理部３１は、アイテムＡへの候補ベクトルβ＿Ａに対して、各アイテムから垂線を引き、上位３つのアイテムとしてアイテムＡ、アイテムＢ、アイテムＧを特定する。そして、事前処理部３１は、「アイテムＡ、アイテムＡ，Ｂ，Ｇ」を「１位のアイテム、上位３件」として、候補ＤＢ１５に登録する。

仮選好推定部３２は、ユーザの選好ログから導き出したその人の選択傾向（以下では「選好トレンド」または「仮の選好」と記載する場合がある）を推定する処理部である。具体的には、仮選好推定部３２は、ユーザの選好によるアイテム更新時に、提示されるアイテムが変更しなかった場合、提示されるアイテムが所定回数連続して変更しなかった場合、または、図５に示すＷｅｂ画面のボタン５０ｈが押下された場合に、選好トレンドの推定を実行する。

図９は、選好トレンドの推定例を説明する図である。図９では、７回の選好が既に実施されている状態で選好トレンドを推定する例である。また、図９では、前回に比べて、安全性などの属性の重要度を上げた場合を「＋（プラス）」、重要度を下げた場合を「－（マイナス）」、重要度を変化させなかった場合を「０」と記載する。

まず、仮選好推定部３２は、選好空間に示すように選好が７回実行された場合、１回目（Ｔ＝１）から７回目（Ｔ＝７）の各選好に対して、新しい選好についてより大きくなるような重み値（ｗ＿Ｔ）を付与する（図９の（Ｂ）を参照）。例えば、図９に示すように、仮選好推定部３２は、１回目の選好「安全性＋、交通利便性＋」に対して重み値「０．２５」、２回目の選好「安全性＋、交通利便性０」に対して重み値「０．３２」、３回目の選好「安全性０、交通利便性＋」に対して重み値「０．４１」を付与する。同様に、仮選好推定部３２は、４回目の選好「安全性－、交通利便性０」に対して重み値「０．５１」、５回目の選好「安全性＋、交通利便性＋」に対して重み値「０．６４」、６回目の選好「安全性０、交通利便性＋」に対して重み値「０．８」、７回目の選好「安全性－、交通利便性０」に対して重み値「１」を付与する。

続いて、仮選好推定部３２は、図９の（Ｂ）のリストから、選好の各傾向を抽出し、各傾向に対するスコアを計算する（図９の（Ｃ）を参照）。例えば、仮選好推定部３２は、「安全性＋」の選好が実行された１、２、５回目の重みの和「１．２１」を算出し、「安全性０」の選好が実行された３、６回目の重みの和「１．２１」を算出し、「安全性－」の選好が実行された４、７回目の重みの和「１．５１」を算出する。同様に、仮選好推定部３２は、「交通利便性＋」の選好が実行された１、３、５、６回目の重みの和「２．１」を算出し、「交通利便性０」の選好が実行された２、４、７回目の重みの和「１．８３」を算出し、「交通利便性－」の選好が実行されていないので重みの和「０」とする。

その後、仮選好推定部３２は、各選好の重みを重みの和「３．９３」で除算して、各選好のスコアを算出する。例えば、仮選好推定部３２は、選好「交通利便性＋」について、「２．１／３．９３＝０．５３」をスコアとして算出する。そして、仮選好推定部３２は、各選好のスコアのうち、任意に設定可能な閾値「０．５」以上である選好「交通利便性＋」を、選好トレンドとして推定し、候補判定部３３に追加する。すなわち、仮選好推定部３２は、「ユーザは交通利便性をもっと重要視したい」と推定する。

候補判定部３３は、選好トレンドの方向によりよいアイテムを提示できる候補ベクトルが存在するかを判定する処理部である。具体的には、候補判定部３３は、現在の選好ベクトルから選好トレンドとして特定された方向に他の選好ベクトルが存在するか否かを、候補ＤＢ１５や図８で説明した手法等により判定する。そして、候補判定部３３は、選好トレンドの方向に他の選好ベクトルが存在する場合、候補ＤＢ１５を参照して、現状の提示アイテムと上位３件がより多く変わる選好ベクトルを特定する。その後、候補判定部３３は、特定した選好ベクトルに対応するアイテムをユーザに提示する。

図１０は、選好トレンドに対応する候補ベクトルの判定例を説明する図である。図１０の（ａ）に示すように、現状では、ユーザの候補ベクトルがβ＿（ａ）であり、アイテムＡ、アイテムＢ、アイテムＧの順でユーザに提示されているとする。この状態で、ユーザの選好トレンドが「交通利便性＋」であることから、アイテムＨやアイテムＬが新たな一位候補と推定できる。

このようなことから、図１０の（ｂ）に示すように、候補判定部３３は、選好空間上で、現状の選好ベクトルよりも交通利便性が高い候補ベクトルとして、候補ベクトルβ＿Ｂ、候補ベクトルβ＿Ｈ、候補ベクトルβ＿Ｌの３つを特定する。

続いて、候補判定部３３は、特定した候補ベクトルを選択したときの上位３件を候補ＤＢ１５から特定し、現在表示されている３件のアイテム数との差異を特定する。例えば、図１０の（ｃ）に示すように、候補判定部３３は、現在の表示アイテムが「Ａ、Ｂ、Ｇ」、候補ベクトルβ＿Ｂを選択したときのアイテムが「Ｂ、Ａ、Ｈ」、候補ベクトルβ＿Ｈを選択したときのアイテムが「Ｈ、Ｌ、Ｍ」、候補ベクトルβ＿Ｌを選択したときのアイテムが「Ｌ、Ｈ、Ｎ」であることを特定する。

そして、候補判定部３３は、候補ベクトルβ＿Ｂを選択したときは、提示されるアイテムが１つ変わり、候補ベクトルβ＿Ｈを選択したときは、提示されるアイテムが３つ変わり、候補ベクトルβ＿Ｌを選択したときは、提示されるアイテムが３つ変わることを特定する。この結果、候補判定部３３は、候補である３つの候補ベクトルのうち、最も多くアイテム数が変化する候補ベクトルβ＿Ｈと候補ベクトルβ＿Ｌを採用候補と判定する。

その後、図１０の（ｄ）に示すように、候補判定部３３は、候補ベクトルβ＿Ｈと選好ベクトルβ＿Ｌの中で、現在の候補ベクトルとのコサイン類似度が高い（一番角度が小さい）ベクトルである候補ベクトルβ＿Ｈを、ユーザが選好を変化させる方向として採用する。

つまり、図１１に示すように、ユーザの過去の選好から特定されたユーザ選考の方向ベクトルが「交通利便性大」であり、候補判定部３３によって採用された候補ベクトルβ＿Ｈである。この結果、候補判定部３３は、ユーザの選好を維持しつつ、アイテムの提示を変えるには、安全性を少し下げることによって交通利便性が高い地域（アイテム）を提案できることを特定できる。したがって、図１１に示すように、候補判定部３３は、「安全性を下げると、あなたの選好に合いそうな地域が３件表示されます」などのメッセージをＷｅｂ画面上に表示する。なお、図１１は、推薦方向を促すメッセージの提示例を説明する図である。

その後、候補判定部３３は、表示させたメッセージなどがユーザによって選択された場合、推薦した方向の新しいアイテムをユーザに提示する。図１２は、推薦方向の新しいアイテムの提示例を説明する図である。図１２の（ａ）に示すように、候補判定部３３は、選好空間において、ユーザ選好の選好ベクトルを現状のベクトルから候補ベクトルβ＿Ｈに変更する。そして、候補判定部３３は、図１２の（ｂ）に示すように、アイテム空間上で、候補ベクトルβ＿Ｈに基づく上位のアイテムとしてアイテムＨ、Ｌ、Ｎを特定し、このアイテムＨ、Ｌ、Ｎをトップ３リストとして、図５の画面５０の５０ｂの領域に表示する。この結果、図１２の（ｂ）に示すように、候補判定部３３は、今まで表示されていたアイテムＡ、Ｂ、Ｇから、新たなアイテムＨ、Ｌ、Ｎに表示を変更したＷｅｂ画面をユーザに提示できる。

［処理の流れ］
次に、上述した各処理の流れを説明する。ここでは、ユーザ選好の選択時の処理と、新しいアイテムの提示時の処理とについて説明する。

（ユーザ選好の選択時の処理）
図１３は、ユーザ選好の選択時のアイテム表示処理の流れを示すフローチャートである。図１３に示すように、選好受付部２２によってユーザ選好が受け付けられると（Ｓ１０１：Ｙｅｓ）、更新部２３は、選好空間にユーザ選好を対応付けて、選好ベクトルを生成する（Ｓ１０２）。

続いて、更新部２３は、選好ベクトルをアイテム空間に対応付け（Ｓ１０３）、アイテム空間上で選好ベクトルと各アイテムとに基づいて、提示するアイテムの順位付けを決定する（Ｓ１０４）。その後、更新部２３は、トップＮのアイテムをユーザに提示する（Ｓ１０５）。

（新しいアイテムの提示時の処理）
図１４は、新しいアイテムの提示処理の流れを示すフローチャートである。なお、ここでは、一例として、事前処理から候補判定までを一連の流れで説明するが、各処理は別々のタイミングで実行することができる。

図１４に示すように、事前処理部３１は、アイテム空間上に各アイテムをプロットして、各アイテムのうち凸包の端点を特定する（Ｓ２０１）。続いて、事前処理部３１は、凸包の重心から各端点に伸ばしたベクトルである候補ベクトルを生成する（Ｓ２０２）。そして、事前処理部３１は、各候補ベクトルについて、アイテム群の順位付けを記録する（Ｓ２０３）。

すなわち、事前処理部３１は、端点のそれぞれを一位にするベクトル（候補ベクトル）を生成し、それぞれが一位になる時のアイテム群の順位も同時に記録する。このとき、各端点を一位とした時に上位Ｎ件でどのようなアイテムが出るかが特定されて候補ＤＢ１５に保存される。

その後、仮選好推定部３２は、新しいアイテムの提示を要求するユーザ操作を受け付けると（Ｓ２０４：Ｙｅｓ）、ユーザの選好ログを履歴情報ＤＢ１４から読み出し、選好ログに基づいて選好トレンドを推定する（Ｓ２０５）。

そして、候補判定部３３は、前回提示されたアイテムのリスト更新で提示アイテムが変わらなかったかを判定する（Ｓ２０６）。ここで、候補判定部３３は、提示アイテムが所定数以上変わって表示された場合（Ｓ２０６：Ｎｏ）、処理を終了して、図１３の処理が実行される。

一方、候補判定部３３は、提示アイテムが変わっていない場合（Ｓ２０６：Ｙｅｓ）、選好トレンドの方向により良いアイテムを提示できる候補ベクトルがあるかを判定する（Ｓ２０７）。ここで、候補判定部３３は、該当する候補ベクトルがない場合（Ｓ２０７：Ｎｏ）、処理を終了して、図１３の処理が実行される。

一方、候補判定部３３は、該当する候補ベクトルがある場合（Ｓ２０７：Ｙｅｓ）、候補ベクトルによってトップＮリスト中、何件が変わるかを算出し、最も多くのアイテムが変わる候補ベクトルを特定する（Ｓ２０８）。

続いて、候補判定部３３は、該当する候補ベクトルが複数存在する場合（Ｓ２０９：Ｙｅｓ）、今の選好ベクトルとのコサイン類似度を計算し、類似度が高い候補ベクトルを特定する（Ｓ２１０）。一方、候補判定部３３は、該当する候補ベクトルが複数存在しない場合（Ｓ２０９：Ｎｏ）、Ｓ２１０を実行することなく、Ｓ２１１を実行する。

続いて、候補判定部３３は、採用された候補ベクトルへの方向と、「○個のアイテムが新しく出る方向」などのメッセージをユーザに提示する（Ｓ２１１）。その後、候補判定部３３は、提示方向または提示メッセージが選択された場合（Ｓ２１２：Ｙｅｓ）、該当する新しいアイテムをユーザに提示する（Ｓ２１３）。一方、提示方向も提示メッセージも選択されない場合（Ｓ２１２：Ｎｏ）、処理を終了して、図１３の処理が実行される。

［効果］
上述したように、探索装置１０は、ユーザの選好トレンドが明らかになる時、表示アイテム変更情報を提示するかを判定し、ユーザの選好トレンドに沿うが過去に選択していないアイテムを提示する。したがって、探索装置１０は、ユーザの過去の選択を保持しつつ、提示されるアイテムを変えることができる。この結果、探索装置１０は、ユーザに対する表示アイテム変更の要望に応えつつ、選好特定を進めることができる。

また、探索装置１０は、ユーザによるアイテム選択のログが溜まっていれば、ユーザの選好に沿いつつ、新たなアイテムを提示可能な入力変更内容を提示できる。また、探索装置１０は、ユーザがアイテムを選好していく中で、ユーザの選好トレンドが明確にわかるような場合、そのトレンドを活かしつつ、新しいアイテムが出やすい選好の方向を特定することができる。また、探索装置１０によって、選好トレンド情報と、新しいアイテムが出やすい方向を加味した入力変更内容が提示されることによって、新たに提示されるアイテムは、ユーザの収束プロセス、及び、システムの選好特定に有用な情報となる。

図１５は、実施例１による手法と一般技術との比較例を説明する図である。図１５の選好空間に示すように、選好トレンドとして「交通利便性大」が特定されたときに、一般的なユーザは、交通利便性だけが高くなるＡの方向にあるアイテムを探索する。この場合、図１５のアイテム空間に示すように、現在の選好ベクトルβ＿（ａ）からＡの方向に選好ベクトルを動かしたとしても、表示されるアイテム（Ａ、Ｂ、Ｇ）は現状のアイテム（Ａ、Ｂ、Ｇ）と同じであり、変化しない。

一方、探索装置１０は、選好トレンドとして「交通利便性大」が特定されたときに、Ｂの方向に有用なアイテムが存在することを特定できる。この場合、図１５のアイテム空間に示すように、現在の選好ベクトルβ＿（ａ）からＢの方向に選好ベクトルを動かすことで、現状のアイテムとは異なるアイテムＨを表示させることができる。したがって、ユーザが自分の力だけで探索することが難しいアイテムを提示できるので、ユーザが収束プロセスにかかる時間を短縮することができる。

図１６は、選好をランダムに選択した場合のアイテム提示例を説明する図である。図１６の選好空間に示すように、選好トレンドとして「交通利便性大」が特定されたときに、今までの選択とは関係がないランダムな動きによって、ユーザの選好をＣの方向に移動させることも考えられる。この場合、図１６のアイテム空間に示すように、ランダムに選択されたアイテム（Ｄ、Ｐ、Ｍ）がユーザに提示される。

この手法では、提示されるアイテムは変化するが、ユーザの選好とは関係のないアイテムが表示されるので、ユーザにとって有益な情報ではなく、却って収束プロセスを促す結果となる場合もある。さらに、このようなランダムに選択されたことを記録したログは、ユーザの選好トレンドを推定するときに不要な情報であり、選好トレンドの推定精度の劣化を引き起こすことも考えられる。したがって、ランダムに提示する手法は、有効な手法とは言い難い。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。

［重視項目（選好項目）］
上記実施例では、交通利便性と安全性の２次元空間へのマッピングを例にして説明したが、これに限定されるものではなく、図３に示した交通利便性、買い物、学校、近所付合、病院、安全性などを任意に組み合わせで用いることができる。例えば、すべてを採用した場合、重視する項目として上記６つのいずれかを問合せ、６次元の空間にマッピングして、上記処理を実行する。また、実施例１では、トップ３のリストを表示する例を説明したが、トップ４など任意に設定変更することができる。

［重み値］
上記重み値の設定例はあくまで一例であり、任意に設定変更することができる。また、新しい選好に対する重みが一番大きくなるように、単純増加で設定することもでき、規則性を持って設定することもできる。また、上記実施例では、閾値（０．５）以上のスコアを有する選好を選択する例を説明したが、これに限定されず、例えば最もスコアが高い選好を選択することもできる。

［提示変更の要否判断］
実施例１では、ユーザがボタン５０ｈを押下した場合に、選好トレンドの推定および提示アイテムの変更を実行する例を説明したが、これに限定されるものではない。例えば、提示アイテムの履歴を保持し、例えば３回など所定回数連続して、例えば１つなど所定数未満のアイテム変更が続いた場合に、選好トレンドの推定および提示アイテムの変更を実行することもできる。

また、ユーザの選好回数が閾値（例えば３回）を越えたとき、あるいは、重み値の和が一定値（例えば３）を超えた時点で、自動的に行うこともできる。また、ユーザがボタン５０ｈを押下し、上記条件を満たす場合に、提示アイテムの変更等を実行することもできる。

また、実施例１では、一位のアイテムが変わるような候補ベクトルを選択する例を説明したが、これに限定されるものではない。例えば、二位以降が変わるような候補ベクトルを選択することもでき、少なくとも１つのアイテムが一致するような候補ベクトルを選択することもできる。なお、類似度の算出例も一例であり、公知の他の算出手法を採用することもできる。

［提示内容］
また、メッセージの内容も例示であり、任意に変更できる。さらには、現在の選好ベクトル、推定された選好トレンドの方向、お勧めするアイテムの方向などが表示されるアイテム空間の画像などを表示することもできる。

［選好の例］
上記実施例では、ユーザによる選好の表記例として、「＋（プラス）」や「－（マイナス）」を用いて、重要視する属性（選好）等を表記したが、あくまで一例であり、これに限定されるものではない。また、各地域に対する項目（図３参照）が数値で設定されている状態で、ユーザが「＋」を指定した場合は、例えば１などの所定値を増加させることもできる。具体的には、ユーザの選好として「交通利便性＝２、安全性＝１」が選択された状態で「安全性＋」が選択された場合、ユーザの選好は「交通利便性＝２、安全性＝２」に変化する。

また、各項目が図３のような具体例で記載されており、現在の選好が「安全性＝１０件／年（事件）」が選択された状態で、ユーザが「安全性＋」を指定した場合、「９件／年（事件）」以下が設定されている地域が該当することとなる。

［ハードウェア］
図１７は、ハードウェア構成例を説明する図である。図１７に示すように、探索装置１０は、通信インタフェース１０ａ、ＨＤＤ（Hard Disk Drive）１０ｂ、メモリ１０ｃ、プロセッサ１０ｄを有する。また、図１７に示した各部は、バス等で相互に接続される。

通信インタフェース１０ａは、ネットワークインタフェースカードなどであり、他のサーバとの通信を行う。ＨＤＤ１０ｂは、図２に示した機能を動作させるプログラムやＤＢを記憶する。

プロセッサ１０ｄは、図２に示した各処理部と同様の処理を実行するプログラムをＨＤＤ１０ｂ等から読み出してメモリ１０ｃに展開することで、図２等で説明した各機能を実行するプロセスを動作させる。すなわち、このプロセスは、探索装置１０が有する各処理部と同様の機能を実行する。具体的には、プロセッサ１０ｄは、表示制御部２１と選好推定部３０等と同様の機能を有するプログラムをＨＤＤ１０ｂ等から読み出す。そして、プロセッサ１０ｄは、表示制御部２１と選好推定部３０等と同様の処理を実行するプロセスを実行する。

このように探索装置１０は、プログラムを読み出して実行することで推定方法を実行する情報処理装置として動作する。また、探索装置１０は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、探索装置１０によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、アイテムを表示する処理部と、選好を推定する処理部とを別々の筐体で実現することもできる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

１ ユーザ端末
１０ 探索装置
１１ 通信部
１２ 記憶部
１３ 自治体情報ＤＢ
１４ 履歴情報ＤＢ
１５ 候補ＤＢ
２０ 制御部
２１ 表示制御部
２２ 選好受付部
２３ 更新部
３０ 選好推定部
３１ 事前処理部
３２ 仮選好推定部
３３ 候補判定部

Claims (5)

1. 選好対象である複数の提示アイテムを含む複数回の問い合わせに対する各回答に基づき、回答者の選好を推定する推定プログラムであって、
   前記回答者からの各回答内容に基づき、前記回答者の選好方向を示す選好トレンドを生成し、
   前記回答者に対する問い合わせで提示される複数の提示アイテムの内容の履歴に基づき、提示アイテムの変更要否を判定し、
   前記提示アイテムの変更が必要と判定された場合に、前記選好トレンドとして特定された方向を、前記回答者の回答内容にしたがって移動させ、移動させた方向に対応する複数のアイテムを、前記複数の提示アイテムとして前記問い合わせにおいて提示する場合に、前記複数の提示アイテムと、重要視する各項目を選択させるための各選択肢とを含む前記問い合わせを表示し、問い合わせ毎に前記各選択肢に対する選択結果に応じて、前記問い合わせで表示する前記複数の提示アイテムを変更する、処理をコンピュータに実行させ、
   前記生成する処理は、前記回答者からの各回答内容として選択肢の選択結果を受け付け、前記各選択肢それぞれを軸とする選好空間上で、前記問い合わせ毎に受け付けられた前記選択肢の選択結果を用いて前記選好トレンドを生成し、
   前記判定する処理は、前記提示するアイテムの変更要否を判定し、
   前記変更する処理は、前記各項目を軸とするアイテム空間上で前記選好トレンドとして特定された方向を、前記回答者の回答内容にしたがって移動させ、移動させた方向に対応する前記複数のアイテムを、前記複数の提示アイテムとして前記問い合わせにおいて提示する、ことを特徴とする推定プログラム。
2. 前記アイテム空間上で、提示候補である複数のアイテムについてベクトルを生成して、候補ベクトルとして保持する処理を前記コンピュータに実行させ、
   前記変更する処理は、
   前記アイテム空間上で前記選好トレンドとして特定された方向に前記候補ベクトルが複数存在する場合、前回複数の提示アイテムが最も変化する候補ベクトルを選択し、
   選択された候補ベクトルに対応する複数のアイテムを、前記複数の提示アイテムとして前記問い合わせにおいて提示する、請求項１に記載の推定プログラム。
3. 前記判定する処理は、前記複数の提示アイテムが所定回数連続して変更しなかった場合、または、所定回数連続して、所定数未満の提示アイテムの変更が続いた場合に、前記提示アイテムの変更要否を判定する、処理を前記コンピュータに実行させる請求項１または２に記載の推定プログラム。
4. 選好対象である複数の提示アイテムを含む複数回の複数の問い合わせに対する各回答に基づき、回答者の選好を推定する推定方法であって、
   前記回答者からの各回答内容に基づき、前記回答者の選好方向を示す選好トレンドを生成し、
   前記回答者に対する問い合わせで提示される複数の提示アイテムの内容の履歴に基づき、提示アイテムの変更要否を判定し、
   前記提示アイテムの変更が必要と判定された場合に、前記選好トレンドとして特定された方向を、前記回答者の回答内容にしたがって移動させ、移動させた方向に対応する複数のアイテムを、前記複数の提示アイテムとして前記問い合わせにおいて提示する場合に、前記複数の提示アイテムと、重要視する各項目を選択させるための各選択肢とを含む前記問い合わせを表示し、問い合わせ毎に前記各選択肢に対する選択結果に応じて、前記問い合わせで表示する前記複数の提示アイテムを変更する、処理をコンピュータが実行し、
   前記生成する処理は、前記回答者からの各回答内容として選択肢の選択結果を受け付け、前記各選択肢それぞれを軸とする選好空間上で、前記問い合わせ毎に受け付けられた前記選択肢の選択結果を用いて前記選好トレンドを生成し、
   前記判定する処理は、前記提示するアイテムの変更要否を判定し、
   前記変更する処理は、前記各項目を軸とするアイテム空間上で前記選好トレンドとして特定された方向を、前記回答者の回答内容にしたがって移動させ、移動させた方向に対応する前記複数のアイテムを、前記複数の提示アイテムとして前記問い合わせにおいて提示する、ことを特徴とする推定方法。
5. 選好対象である複数の提示アイテムを含む複数回の複数の問い合わせに対する各回答に基づき、回答者の選好を推定する推定装置であって、
   前記回答者からの各回答内容に基づき、前記回答者の選好方向を示す選好トレンドを生成する生成部と、
   前記回答者に対する問い合わせで提示される複数の提示アイテムの内容の履歴に基づき、提示アイテムの変更要否を判定する判定部と、
   前記提示アイテムの変更が必要と判定された場合に、前記選好トレンドとして特定された方向を、前記回答者の回答内容にしたがって移動させ、移動させた方向に対応する複数のアイテムを、前記複数の提示アイテムとして前記問い合わせにおいて提示する場合に、前記複数の提示アイテムと、重要視する各項目を選択させるための各選択肢とを含む前記問い合わせを表示し、問い合わせ毎に前記各選択肢に対する選択結果に応じて、前記問い合わせで表示する前記複数の提示アイテムを変更するする表示制御部と、を有し、
   前記生成部は、前記回答者からの各回答内容として選択肢の選択結果を受け付け、前記各選択肢それぞれを軸とする選好空間上で、前記問い合わせ毎に受け付けられた前記選択肢の選択結果を用いて前記選好トレンドを生成し、
   前記判定部は、前記提示するアイテムの変更要否を判定し、
   前記表示制御部は、前記各項目を軸とするアイテム空間上で前記選好トレンドとして特定された方向を、前記回答者の回答内容にしたがって移動させ、移動させた方向に対応する前記複数のアイテムを、前記複数の提示アイテムとして前記問い合わせにおいて提示する、ことを特徴とする推定装置。

Images