JP6599530B1 - 情報処理装置、情報処理方法、プログラム、記憶媒体 - Google Patents

Abstract

【課題】 簡易な操作でユーザが所望する検索結果の特徴を検索条件として指定可能な環境を提供することを目的とする。【解決手段】 情報処理装置は、評価対象ごとに付与された複数の評価軸と評価値を管理する評価情報管理部と、前記評価軸及び評価値を指定することにより前記評価対象の検索条件を設定可能な検索条件設定手段を提示する制御を行う提示制御部と、前記検索条件を変更する変更操作の対象とされた対象評価軸についての変更前の評価値と変更後の評価値の情報を取得する変更情報取得部と、前記変更前の評価値と前記変更後の評価値の差分に応じて、全ての評価軸の評価値の合計値が所定値以上変化しないように、前記対象評価軸以外の評価軸の少なくとも一つとされた調整評価軸の評価値を変更することにより前記検索条件を調整する検索条件調整部と、前記調整された検索条件に基づいて検索処理を行い前記評価対象を抽出する検索処理部と、を備えるものとした。【選択図】図５

Description

本発明は、検索処理を行うことによりユーザに所望の検索対象を提示する情報処理装置、情報処理方法及びプログラムについての技術分野に関する。

近年では、一般ユーザの投稿などによって情報（例えばレシピ情報）を蓄積すると共に、該蓄積された情報を検索対象とした検索サービスを提供するサービスなどが普及している。
このような情報提供サービスは、ユーザが各種の検索条件を指定することにより、ユーザが所望する情報を得ることが可能とされている。
例えば、特許文献１には、パラメータごとに設けられたつまみを操作することによりパラメータを変化させると、ランキングが動的に入れ替わることが記載されている。

特開２００５−２３５１３９号公報

検索サービスを利用することによって得られる検索結果は、検索条件への適合度合いを表す一種のランキングとして捉えることができる。その場合、ユーザがパラメータを変更することにより当該ユーザが得られる検索結果が変化する構成として、特許文献１に記載された構成を採用することが考えられる。
しかし、各パラメータの変更態様によっては、ユーザが所望する検索結果を得ることができない虞がある。
例えば、全てのパラメータを最大値にするような変更態様は、該当する検索結果が無くなる虞や少なくなる虞があるだけでなく、特徴のある検索対象を得ることができない虞がある。
そこで、本発明は、簡易な操作でユーザの所望する検索結果の特徴を検索条件として指定可能であると共に、ユーザが所望の検索結果を得られない可能性を低減させることのできる環境を提供することを目的とする。

本発明に係る情報処理装置は、評価対象ごとに付与された複数の評価軸と評価値を管理する評価情報管理部と、前記評価軸及び評価値を指定することにより前記評価対象の検索条件を設定可能な検索条件設定手段を提示する制御を行う提示制御部と、前記検索条件を変更する変更操作の対象とされた対象評価軸についての変更前の評価値と変更後の評価値の情報を取得する変更情報取得部と、前記変更前の評価値と前記変更後の評価値の差分に応じて、全ての評価軸の評価値の合計値が所定値以上変化しないように、前記対象評価軸以外の評価軸の少なくとも一つとされた調整評価軸の評価値を変更することにより前記検索条件を調整する検索条件調整部と、前記調整された検索条件に基づいて検索処理を行い前記評価対象を抽出する検索処理部と、を備えるものである。
調整評価軸の評価値を変更する調整を行い全評価軸の評価値の合計値の変化量を抑えることにより、ユーザが対象評価軸に設定した設定値（評価値）の特徴が出やすいような検索条件が設定される。

上記した情報処理装置の前記提示制御部は、前記評価値の初期値を指定して前記検索条件設定手段の提示を行い、前記初期値は前記評価対象の検索を行うユーザの行動履歴に基づく数値とされていてもよい。
例えば、「価格」という評価軸に対して「安い（評価値＝３）」「普通（評価値＝２）」「高い（評価値＝１）」の３段階が指定可能である場合に、ユーザが検索対象を検索する際に、安いことを示す評価値＝３を毎回指定していることに応じて、提示制御部は、「価格」の評価軸の初期値（デフォルト値）に「３」を設定した状態で検索条件設定手段を提示する。

上記した情報処理装置の前記検索条件調整部は、前記調整評価軸間の評価値の大小関係が崩れないように前記調整を行ってもよい。
ユーザが評価対象を検索するための条件を指定する際、即ち評価値の指定の際には、複数項目について指定することが考えられる。この場合において、本構成によれば、ユーザの操作対象とされた対象評価軸以外の評価軸について設定した大小関係が崩れないように評価軸の評価値が調整される。

上記した情報処理装置の前記検索条件調整部は、前記調整評価軸間の評価値の割合を変えないように前記調整を行ってもよい。
ユーザが複数の評価軸の評価値を指定する操作を行うことにより検索条件の設定を行うような場合に、次の操作対象とされた対象評価軸の評価値を変更する際にそれまでに設定済みの評価軸同士の関係性を保ったままとされる。

上記した情報処理装置の前記検索条件調整部は、前記調整評価軸ごとの前記対象評価軸との関係性に基づいて、前記調整評価軸を決定してもよい。
複数の評価軸の評価値の間に正の相関関係や負の相関関係が見られる場合がある。例えば、負の相関関係が見られる評価軸Ａ，Ｂにおいて、ユーザが評価軸Ａを対象評価軸として変更操作を行った場合に、評価軸Ｂを調整評価軸として選択し評価軸Ａに対して行われた評価値の増減操作とは逆方向に評価軸Ｂの評価値を増減させることが考えられる。
また、正の相関関係が見られる評価軸Ｃ，Ｄにおいて、ユーザが評価軸Ｃを対象評価軸として変更操作を行った場合に、評価軸Ｄを調整評価軸として選択し評価軸Ｃの評価値に対して行われた増減操作と同方向の調整を行うと共に、他の評価軸についても調整評価軸とし評価軸Ｃに対して行われた評価値の増減操作とは異なる方向に評価値を調整する。

上記した情報処理装置の前記変更情報取得部は、前記検索条件設定手段の提示から前記検索処理の間に受け付けた複数回の前記変更操作を一連の変更操作として特定し、前記検索条件調整部は、前記一連の変更操作における最新の変更操作に応じた調整を行う場合に、当該一連の変更操作それぞれにおいて対象評価軸とされた評価軸のうち少なくとも一部は前記調整評価軸から外して前記調整を行ってもよい。
例えば、ユーザが検索条件として設定可能な評価軸Ａ〜Ｅが用意されており、ユーザが評価軸Ａを対象評価軸とした変更操作を行い、次に評価軸Ｂを対象評価軸とした変更操作を行った場合に、評価軸Ｂの評価値を操作に応じて変更する代わりに他の評価軸を調整評価軸として全体の合計値が所定値以上変化しないように調整する。このときに、本構成によれば、評価軸Ａについては、ユーザが変更操作で指定した評価値を維持するために、調整評価軸から外される。

上記した情報処理装置において、前記調整評価軸は前記対象評価軸以外の全ての評価軸とされてもよい。
ユーザがそれまでに変更操作の対象としたか否かに関わらず、対象評価軸以外の評価軸全てが調整評価軸として調整の対象とされる。例えば、ユーザが誤って評価軸Ａの評価値を変更してしまった後、本来変更したかった評価軸Ｂの評価値を変更した場合に、評価軸Ａについても調整評価軸とされる。ことで、ユーザの意図に沿った検索条件の設定を行うことができる。

上記した情報処理装置の前記検索処理部は、前記調整された検索条件において評価値が所定値以上とされた前記評価軸が存在する場合は、前記評価値が所定値以上とされた評価軸を検索条件評価軸として決定し、前記検索条件評価軸に付与されているラベル情報に基づいて前記検索処理を行ってもよい。
例えば、各評価軸において取り得る評価値が０〜１００とされ、所定値が８０とされ、調整後において評価軸Ａの評価値が８０を超えていた場合、評価軸Ａが検索条件評価軸として決定される。更に、評価軸Ａのラベルが「節約」とされていた場合、「節約」についての評価値が高いレシピが検索結果として抽出されるように検索処理を行う。

上記した情報処理装置の前記検索処理部は、前記検索条件評価軸が複数存在する場合に、前記複数の前記検索条件評価軸にそれぞれ付与されたラベル情報を基づいたアンド検索を前記検索処理において行ってもよい。
例えば、各評価軸において取り得る評価値が０〜１００とされ、所定値が８０とされ、調整後において評価軸Ａ及び評価軸Ｂの評価値が８０を超えていた場合、評価軸Ａ，Ｂが検索条件評価軸として決定される。更に、評価軸Ａのラベルが「節約」とされ、評価軸Ｂのラベルが「健康的」とされていた場合、「節約」と「健康的」についての評価値が高いレシピが検索結果として抽出されるように評価軸のラベル情報を用いた検索処理を行う。

本発明に係る情報処理方法は、評価対象ごとに付与された複数の評価軸と評価値を管理する評価情報管理ステップと、前記評価軸及び評価値を指定することにより前記評価対象の検索条件を設定可能な検索条件設定手段を提示する制御を行う提示制御ステップと、前記検索条件を変更する変更操作の対象とされた対象評価軸についての変更前の評価値と変更後の評価値の情報を取得する変更情報取得ステップと、前記変更前の評価値と前記変更後の評価値の差分に応じて、全ての評価軸の評価値の合計値が所定値以上変化しないように、前記対象評価軸以外の評価軸の少なくとも一つとされた調整評価軸の評価値を変更することにより前記検索条件を調整する検索条件調整ステップと、前記調整された検索条件に基づいて検索処理を行い前記評価対象を抽出する検索処理ステップと、を備えたものである。
この情報処理方法により、簡易な操作でユーザが所望する検索結果の特徴を検索条件として指定可能な環境を提供する。
本発明に係るプログラムは、上記情報処理方法として実行する処理を情報処理装置に実行させるプログラムである。これらのプログラムにより上記の情報処理装置を実現する。

本発明によれば、簡易な操作でユーザの所望する検索結果の特徴を検索条件として指定可能であると共に、ユーザが所望の検索結果を得られない可能性を低減させることのできる環境を提供することができる。

本発明の実施の形態の情報処理装置を含む全体構成を示す説明図である。 コンピュータ装置のブロック図である。 レシピ管理サーバの機能構成を示す図である。 ユーザに提示される検索条件設定手段の一例を示す図である。 全体の流れを説明するための図である。 検索条件調整処理の一例を示すフローチャートである。 変更操作の前後における検索条件設定領域の変化を説明するための図である。 変更操作に応じた自動調整処理を説明するための図である。 変更操作に応じた自動調整処理の別例を説明するための図である。 検索条件調整処理の第２例を示すフローチャートである。 検索条件調整処理の第３例を示すフローチャートである。 検索条件調整処理の第３例において追加で実行する処理について示すフローチャートである。 検索条件調整処理の第４例を示すフローチャートである。 検索クエリ設定処理の例を示すフローチャートである。 初期評価値決定処理の例を示すフローチャートである。 レーダーチャートの代替例である。

以下、実施の形態について、添付図を用いて説明する。

＜１．全体構成＞

本発明の実施の形態における全体構成について説明する。
なお、以下の説明においては、ユーザの投稿などによって蓄積された料理のレシピ情報が検索対象とされた例について述べる。レシピ情報（以降、単にレシピともいう）は、調理手順や使用食材や調理器具などの情報が含まれている。
このようなレシピ情報を管理する情報処理装置として、レシピ管理サーバ１を例に挙げる。レシピ管理サーバ１は、本発明の情報処理装置の実施の形態に相当する。
また、ユーザが指定した検索条件に応じたレシピの検索やレシピの投稿などが可能なサービスを提供するためのポータルサイトとして、レシピ管理サーバ１が管理するレシピサイトを例に挙げる。

本発明の情報処理装置を含む全体構成を図１に示す。
レシピ管理サーバ１は、通信ネットワーク２を介して、ユーザ端末３，３，３，・・・と相互に通信可能な状態で接続されている。また、レシピ管理サーバ１は、ユーザに関する情報が記憶されるユーザＤＢ（Database）５０、レシピに関する情報が記憶されるレシピＤＢ５１、検索条件や検索結果の情報が記憶される検索ＤＢ５２、ユーザによる各種操作の履歴が記憶される履歴ＤＢ５３、レシピサイトを構成する各種ウェブページのウェブページデータが記憶されるウェブページＤＢ５４と接続されている。

レシピ管理サーバ１は、ユーザから投稿されるレシピを管理する処理や、検索条件に応じたレシピを提示するための処理を行う情報処理装置である。具体的な構成に関しては後述する。
検索条件は、ユーザがレシピを検索するために指定する情報であり、レシピを特定するための情報である。検索条件は、ユーザが入力した文字列（検索クエリ）だけでなく、ユーザが指定したレシピの傾向に関する情報も含んでいる。
レシピの傾向に関する情報とは、例えば、各レシピに「調理時間」という観点（評価軸）から評価値（３０分や１時間などの時間でもよいし、調理時間が短いことや長いことを表す値であってもよい）が与えられている場合に、ユーザが指定する評価値や範囲である。即ち、ユーザは「調理時間が短い」という検索条件や「調理時間が３０分以内」という検索条件を指定することにより、調理時間が短い傾向にあるレシピを検索することができる。

通信ネットワーク２の構成は特に限定されるものではなく、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網などが想定される。
また通信ネットワーク２の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線などの有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網などの無線でも利用可能である。

ユーザ端末３は、レシピをレシピ管理サーバ１に投稿するユーザや、レシピ管理サーバ１が管理するレシピ情報の検索や閲覧を行うユーザが使用する端末である。
ユーザ端末３では、必要に応じて各種の送受信処理や表示処理などが実行される。また、ユーザ端末３は、例えば、通信機能を備えたＰＣ（Personal Computer）やフィーチャーフォンやＰＤＡ（Personal Digital Assistant）、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。

＜２．ハードウェア構成＞

図２は、図１に示したレシピ管理サーバ１とユーザ端末３のハードウェア、及び、ユーザＤＢ５０とレシピＤＢ５１と検索ＤＢ５２と履歴ＤＢ５３とウェブページＤＢ５４のハードウェアを例示する図である。それぞれのサーバや端末、ＤＢにおけるコンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ（Read Only Memory）１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ（Random Access Memory）１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インターフェース１０５も接続されている。
入出力インターフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力装置１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどよりなる出力装置１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、通信ネットワーク２を介しての通信処理や機器間通信を行う通信部１０９が接続されている。
入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、レシピ管理サーバ１とユーザ端末３、ユーザＤＢ５０とレシピＤＢ５１と検索ＤＢ５２と履歴ＤＢ５３とウェブページＤＢ５４のそれぞれにおいて後述する情報処理や通信が実行される。
なお、レシピ管理サーバ１とユーザ端末３、ユーザＤＢ５０とレシピＤＢ５１と検索ＤＢ５２と履歴ＤＢ５３とウェブページＤＢ５４を構成するそれぞれの情報処理装置は、図２のようなコンピュータ装置が単一で構成されることに限らず、システム化された複数のコンピュータ装置によって構成されてもよい。複数のコンピュータ装置は、ＬＡＮなどによりシステム化されていてもよいし、インターネットなどを利用したＶＰＮ（Virtual Private Network）などにより通信可能な状態で遠隔地に配置されたものでもよい。

レシピ管理サーバ１としての各機能は、情報処理装置においてＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し以下において説明する各構成の処理の全部又は一部をハードウェアにより実現してもよい。
また各機能をソフトウエアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。一つのプログラムにより複数の機能の処理が実行されてもよいし、一つの機能が複数のプログラムモジュールの連携で実現されてもよい。

＜３．レシピ管理サーバの機能構成＞

レシピ管理サーバ１は、図３に示すように、レシピ管理部１ａ、変更情報取得部１ｂ、検索条件調整部１ｃ、検索処理部１ｄ、提示制御部１ｅを備えている。

レシピ管理部１ａは、ユーザが投稿したレシピ情報をレシピＤＢ５１に記憶する処理や、レシピＤＢ５１から特定のレシピ情報を取得する処理などを行うことにより、レシピ情報を管理する。
レシピ情報は、レシピタイトルと使用食材と調理方法と使用する調理器具とレシピが属するカテゴリ情報とレシピに付与された評価情報などがレシピ情報を投稿したユーザを識別する識別情報と紐付けられた情報である。

例えば、あるユーザが投稿した「野菜カレー」のレシピは、カテゴリ「カレーライス」に属するレシピであり、使用食材情報として、「じゃがいも」、「人参」、「タマネギ」、「ブロッコリー」、「トマト」、「ほうれん草」や、調味料（「塩」や「胡椒」など）や、それに準ずるもの（例えば「カレールー」など）が紐付けられてレシピ情報として記憶される。また、レシピを利用する際に使用する調理器具として、例えば、「ボウル」、「鍋」などの情報が紐付けられ、更には、食事をする際に使用する器具「スプーン」などのカトラリー情報が紐付けられてもよい。更に、レシピ情報には、評価軸及び評価値が紐付けられている。評価軸及び評価値は、当該レシピがどのようなレシピであるかをユーザが把握するために利用される情報であると共に、レシピ情報の検索に用いられる情報である。「評価軸」は「評価項目」と換言することが可能である。

評価値の算出には、各種の例が考えられる。例えば、レシピを投稿するユーザによって選択された評価値とされていてもよい。また、投稿されたレシピを実際に利用したユーザによって選択された評価値とされていてもよい。更には、使用食材の情報や調理手順の情報から自動で付与された評価値とされていてもよい。
勿論、これらの各種情報を総合して評価値が決定されてもよい。また、評価値は、初めて数値が付与されてからずっと固定である必要はなく、定期的に再評価が行われ、新たな評価値が付与されてもよい。

また、レシピ管理部１ａは、投稿されたレシピに対するユーザの評価情報を管理する。評価情報としては、レシピを実際に利用した際の感想や評価値を含む作成レポートなどである。作成レポートは、レシピＤＢ５１の各レシピに紐付けられて管理される。

変更情報取得部１ｂは、ユーザが検索条件を変更するための操作を行った際に、該変更に関する情報を取得する（受信する）処理を行う。以降の説明においては、変更に関する情報を単に「変更情報」と記載する。
具体的に図４を参照して説明する。

レシピの検索を行うユーザに対して、レシピ管理サーバ１は、図４に示すような検索条件設定領域１０を提示することにより検索環境を提供する。
図４のような検索条件設定領域１０は、例えばウェブページ上に所定の場所に配置され、ユーザが閲覧可能且つ操作可能とされている。

検索条件設定領域１０には、傾向設定領域１１と絞り込み条件設定領域１２が設けられている。
傾向設定領域１１は、検索するレシピの傾向を特定するものであり、例えば複数の評価軸１３，１３，・・・を備えている。

各評価軸１３は、位置によって評価値を表す摘み部１３ａと、評価軸１３の種別を表すラベル部１３ｂを備えている。摘み部１３ａには、評価軸１３に対する評価値を表す０〜１００の数値が表示されている。数字の表示態様は一例であり、０〜１で表示されていてもよいし、評価軸１３ごとに異なる数値範囲とされていてもよい。勿論、０と１の２値や０と１と２の３値によって表現されていてもよい。

ユーザは、摘み部１３ａを動かす操作を行うことにより、検索するレシピの傾向を変化させることができる。換言すれば、検索条件を変更することが可能である。
変更情報取得部１ｂは、例えば、「節約」ラベルが付与された評価軸１３の評価値を「９０」から「１００」に変更したことに応じて、操作対象とされた評価軸（対象評価軸）を特定する情報と、変更前の評価値（９０）と変更後の評価値（１００）を取得する処理を行う。このような処理は、例えば、ユーザに提示するウェブページデータに付加されたＪＳ（JavaScript）などのプログラムが実行されることにより実現されてもよい。

絞り込み条件設定領域１２には、１以上の条件入力欄１４，１４，・・・が配置されている。各条件入力欄１４は、傾向設定領域１１を利用して傾向が特定されるレシピを更に絞り込むための条件を設定するために設けられている。各条件入力欄１４は、例えば文字列の入力が可能とされている。図４は、冷蔵庫に余っている食材である「ほうれん草」を使ったレシピを検索したいと考えているユーザであって、且つ、「カレーライス」が食べたい気分とされているユーザによって絞り込み条件が設定された例を示している。
なお、図４に示す例では、使用食材を複数指定できるように、条件入力欄１４は複数設けられているが、一つのみ設けられた構成であってもよい。更に、これ以外にも検索結果を絞り込むための条件設定が可能な構成とされていてもよい。例えば、使用しない食材を指定可能な入力欄が設けられていてもよいし、主菜・副菜の何れかを選択可能とされたラジオボタンが設けられていてもよい。

検索条件調整部１ｃは、ユーザが摘み部１３ａを操作することにより一つの評価軸１３の評価値を変更させた場合に、他の検索軸１３の評価値を調整する処理を実行する。このような処理は、例えば、全ての評価軸１３の評価値の合計が大きすぎたり小さすぎたりしないように行うものである。具体的な処理内容については後述する。

検索処理部１ｄは、ユーザが指定した検索条件に応じてレシピを検索する処理を実行する。
例えば、図４に示す検索条件設定領域１０には、検索ボタン１５が配置されている。ユーザは検索条件を設定した後検索ボタン１５を押下することにより、設定した検索条件に応じたレシピ検索をレシピ管理サーバ１に実行させることができる。

具体的に、図４に示す検索条件のもとで検索ボタン１５が押下されると、レシピのジャンルが「カレーライス」であって、使用食材として少なくとも「ほうれん草」を含んでおり、更に、「節約志向」かつ「低価格志向」とされたレシピを抽出するような検索処理が実行される。

提示制御部１ｅは、ユーザに図４に示すような検索条件を設定可能なウェブページを提示する処理や、ユーザに検索結果を提示する処理などを行う。それ以外にも、ユーザ端末３から要求のあったウェブページデータを送信する処理などを行う。
そのために、提示制御部１ｅは、レシピ管理サーバ１が行う各種の通信処理を行う通信制御部であってもよい。

なお、レシピ管理サーバ１は、ユーザ情報を管理するユーザ管理部や、ユーザのログイン操作に対する認証処理などを実現する認証処理部などを更に備えていてもよい。

＜４．ＤＢ＞

［４−１．ユーザＤＢ］
ユーザＤＢ５０にはレシピ管理サーバ１が提供するサービスを受けるユーザの情報が記憶される。例えば、一人のユーザを特定可能な一つのユーザＩＤ（Identification）に対して、ログインパスワード、氏名、年齢、性別、メールアドレスなどの個人的な情報が紐付けられて記憶される。また、ユーザ毎の嗜好情報が記憶されてもよい。嗜好情報は、ユーザによるレシピ情報や料理情報に関する検索や閲覧などの挙動に応じてレシピ管理サーバ１が判定したユーザの好みの食材（嗜好食材）や嫌いな食材（非嗜好食材）の情報や、ユーザに関わる投稿情報（テキスト情報やタグ情報や画像情報など）に基づいてレシピ管理サーバ１が判定したユーザの好みの食材（嗜好食材）や嫌いな食材（非嗜好食材）である。また、嗜好情報はユーザによって任意に登録された情報であってもよい。

［４−２．レシピＤＢ］
レシピＤＢ５１は、ユーザから投稿されたレシピの情報が記憶されるＤＢである。具体的には、それぞれのレシピを識別可能なレシピＩＤに対して、レシピを投稿したユーザを特定するユーザＩＤと、投稿日時情報と、レシピが属するカテゴリ情報と、レシピの使用食材情報（分量などを含む）と、レシピの調理手順と、料理画像（完成した料理の画像や調理途中の料理の画像）などの画像情報と、レシピの評価情報と、レシピを実際に利用した（料理を作成した）他のユーザによって投稿された作成レポートを特定する作成レポートＩＤと、が紐付けられて記憶される。
レシピの評価情報は、上述したように、レシピを投稿したユーザによって設定されてもよいし、レシピを利用したユーザによって設定されてもよい。また、その双方のユーザによって評価情報が蓄積されてもよい。例えば、レシピが投稿された当初は、レシピを投稿したユーザによって各評価軸に対する評価値が設定されると共に、レシピを実際に利用したユーザが増えていくにつれて、レシピ利用ユーザによる評価値が設定されてもよい。

また、レシピの詳細ページのＵＲＬ（Uniform Resource Locator）情報がレシピＩＤに紐付けられて記憶されてもよい。
更に、レシピＤＢ５１には、各レシピに対して投稿された作成レポートの情報が記憶される。作成レポートの情報としては、レポート内容を示すテキストデータや調理した料理の画像や投稿者を識別可能なユーザＩＤや投稿日時情報、更にはレシピの各評価軸に対する評価値などが記憶される。

［４−３．検索ＤＢ］
検索ＤＢ５２は、検索条件と対応した検索結果が記憶されるＤＢである。具体的には、「カレーライス」や「ハンバーグ」などの料理名や「きのこ」や「トマト」などの食材名などの検索条件、更に、評価軸と評価値などの検索条件に応じて、複数のレシピが検索結果として紐付けられて記憶される。
例えば、ユーザが指定した検索条件に応じて検索処理が実行され、その結果抽出された検索結果が検索条件に紐付けられて検索ＤＢ５２に記憶される。このように紐付けが行われることで、新たな検索要求があった際に検索処理を実行せずに以前の検索結果を利用した検索結果の提示を行うことができる機会が増える。
なお、予め定期的に検索条件に基づく検索処理を実行しておき、その結果抽出された検索結果を検索条件に紐付けて検索ＤＢ５２に記憶してもよい。

［４−４．履歴ＤＢ］
履歴ＤＢ５３には、ユーザの操作に関する各種履歴が記憶される。
具体的には、ユーザが行った操作毎に、ユーザＩＤ、履歴ＩＤ、操作種別、操作対象（「レシピ閲覧操作」や「レシピ印刷操作」であれば閲覧対象となったレシピＩＤ、「ウェブページを閲覧する操作」であれば対象となったウェブページを特定する情報、「投稿操作」であれば、投稿されたレシピＩＤや作成レポートＩＤ、「ユーザ情報変更操作」であれば変更対象となった項目名など）、操作日時、操作結果（「ログイン操作」であればログイン可否、「ユーザ情報変更操作」であれば変更可否などが記憶される。
また、本実施の形態では、ユーザに検索条件設定領域１０が提示されてから検索ボタン１５が押下されるまでの間に行われた検索条件を変更する操作（以降、単に「変更操作」）を一連の変更操作として記憶する。以降の説明においては、一連の変更操作に基づいて処理を行う例を述べる。

［４−５．ウェブページＤＢ］
ウェブページＤＢ５４には、レシピ管理サーバ１がユーザに提供する各種ウェブページのデータが記憶される。具体的には、レシピ検索ページや特集ページや検索結果ページやレシピ詳細ページやユーザページなどのウェブページデータである。図４に示す検索条件設定領域１０が配置されたウェブページに関するウェブページデータもウェブページＤＢ５４に記憶される。
ウェブページデータとしては、ウェブページのＵＲＬ（Uniform Resource Locator）情報と各ウェブページ上に配置されるオブジェクト（画像やテキストやバナーなど）の配置情報が記憶される。配置情報とは、ウェブページ上における各オブジェクトの配置態様（位置や大きさ、色等）が記載された情報である。
なお、ウェブページＤＢ５４に記憶される情報は、例えば、ＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible HyperText Markup Language）などの構造化文書ファイルで記憶されてもよい。

［４−６．ＤＢの態様］
これらの各ＤＢ（ユーザＤＢ５０、レシピＤＢ５１、検索ＤＢ５２、履歴ＤＢ５３、ウェブページＤＢ５４）は、レシピ管理サーバ１を構成する各情報処理装置が必要に応じてアクセス可能とされていればどのような形態で実現されていてもよい。例えばレシピ管理サーバ１と同一システム内の記憶部に各ＤＢ（ユーザＤＢ５０、レシピＤＢ５１、検索ＤＢ５２、履歴ＤＢ５３、ウェブページＤＢ５４）のすべてが形成されていてもよいし、各ＤＢ（ユーザＤＢ５０、レシピＤＢ５１、検索ＤＢ５２、履歴ＤＢ５３、ウェブページＤＢ５４）の一部又は全部が別体、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん各ＤＢ（ユーザＤＢ５０、レシピＤＢ５１、検索ＤＢ５２、履歴ＤＢ５３、ウェブページＤＢ５４）が一つの装置（例えば一つのＨＤＤ等）内に形成されている必要はない。また各ＤＢ（ユーザＤＢ５０、レシピＤＢ５１、検索ＤＢ５２、履歴ＤＢ５３、ウェブページＤＢ５４）のそれぞれが、それぞれ一つのＤＢとして構成される必要もない。例えばユーザＤＢ５０に記憶される情報が、複数のユーザＤＢ（例えばログイン用のユーザＤＢとレシピに関する嗜好情報が記憶されるユーザＤＢなど）により記憶管理されてもよい。以下説明する各ＤＢ（ユーザＤＢ５０、レシピＤＢ５１、検索ＤＢ５２、履歴ＤＢ５３、ウェブページＤＢ５４）は、実施の形態の処理に関連する情報の記憶部を、それぞれ一つのＤＢの形態で例示したものに過ぎない。

＜５．処理の流れ＞

レシピ管理サーバ１が実行する各種処理について説明する。

［５−１．全体の流れ］
先ず、図５を参照して、レシピ管理サーバ１とユーザ端末３が実行する各処理や双方の情報処理端末間で送受信されるデータについて説明する。

レシピ管理サーバ１が提供する各種サービスを享受するために、レシピサイトへのログインを行うためのウェブページを要求する操作をユーザが行うと、該操作に応じてユーザ端末３は、ステップＳ１０１においてログイン画面情報要求処理を実行する。この処理により、ユーザ端末３はログイン画面としてのウェブページデータをレシピ管理サーバ１に要求する。

ログイン画面情報の要求を受信したレシピ管理サーバ１は、ステップＳ２０１で、ウェブページＤＢ５４からログイン画面情報（ウェブページデータ）を取得し、ユーザ端末３へ送信する処理を実行する。
これにより、例えば、レシピ管理サーバ１から受信したレシピサイトのログイン画面情報（ウェブページデータ）に応じたウェブページがユーザ端末３上に表示される。
なお、レシピ管理サーバ１はこのとき、ログイン画面をユーザ端末３上に表示させたことを履歴（即ちログイン画面の閲覧履歴）として記憶してもよい。

次に、ユーザ端末３はステップＳ１０２において、ユーザの操作によって入力されたログイン情報（ユーザＩＤとログインパスワード）をレシピ管理サーバ１へ送信するログイン情報送信処理を実行する。

ユーザ端末３からレシピ管理サーバ１へログイン情報が送信されたことに応じて、レシピ管理サーバ１はステップＳ２０２において認証処理を実行し、続くステップＳ２０３においてログイン履歴を記憶する処理を実行し、ステップＳ２０４において認証結果通知処理を実行する。
具体的には、レシピ管理サーバ１は、ユーザ端末３上で入力されたユーザＩＤとパスワードをユーザＤＢ５０に記憶された情報と比較して当該ユーザのログイン可否を判定し、当該ログイン可否情報を履歴情報として履歴ＤＢ５３に記憶し、当該ログイン可否情報を認証結果としてユーザ端末３へ通知する。なお、認証結果をユーザ端末３へ送信すると共に、レシピサイトのトップページのウェブページデータを送信してもよい。これにより、ユーザ認証がなされると共に、ユーザ端末３上にレシピサイトのトップページが表示される。

なお、図５に示す一連の流れは、ステップＳ２０２の認証処理においてログイン可と判定された場合を示している。ステップＳ２０２においてログイン不可と判定した場合は、ユーザのログイン情報入力操作に応じてユーザ端末３は再度ステップＳ１０２の処理を実行し、これに応じてレシピ管理サーバ１はステップＳ２０２の処理を実行する。

次に、ユーザがレシピの検索を行うために、検索条件を設定するための検索条件設定画面を表示させるための操作を行うと、ユーザ端末３はステップＳ１０３で、検索条件設定画面をレシピ管理サーバ１へ要求する処理を行う。この処理により、ユーザ端末３からレシピ管理サーバ１へ検索条件設定画面要求が送信される。

レシピ管理サーバ１は、該要求に応じて、検索条件設定画面情報（ウェブページデータ）をウェブページＤＢ５４から取得し、ユーザ端末３に送信する処理を実行する（ステップＳ２０５）。
この処理により、例えば、レシピ管理サーバ１からユーザが所望するレシピを検索するための検索条件を設定可能なウェブページ（例えば図４に示すウェブページ）がユーザ端末３上に表示される。

ユーザが、検索条件を変更する操作を行うと、ユーザ端末３はステップＳ１０４で変更操作を受け付けると共に、レシピ管理サーバ１に対して変更情報を送信する処理を実行する。この処理は、例えば、ユーザが図４に示す摘み部１３ａを評価軸１３の軸方向にスライドさせることにより実行される。
レシピ管理サーバ１に送信される変更情報は、ユーザの変更操作の対象となった評価軸（以降、「対象評価軸」と記載）を特定する情報と、変更前の評価値と変更後の評価値の情報である。
但し、変更前の評価値は、評価値の初期値（例えば０〜１００の真ん中の値である５０）や、その前に行われた変更操作によって指定された変更後の評価値であるため、レシピ管理サーバ１が既に知り得る情報であるため、ユーザ端末３から受信しなくてもよい。
また、変更後の評価値の代わりに変動値、即ち、ユーザが変更操作によってどの程度評価値を動かしたかを特定可能な値（即ち変更量）を送信してもよい。

レシピ管理サーバ１へ変更情報が送信されるタイミングとしては、例えば、選択した摘み部１３ａに対するスライド操作が終わったタイミング、即ち、ドラッグ操作（摘み部１３ａをスライドさせる操作）を終えたタイミングとされてもよいし、ドラッグ操作を行っている最中も含めて一定時間ごとに設けられたタイミングとされてもよい。

変更情報を受信したレシピ管理サーバ１は、ステップＳ２０６で検索条件調整処理を実行する。この処理は、ユーザによって行われた評価値の変更によって、検索条件が不適切なものに変更されてしまうことを防止するための処理である。
不適切なものへの変更とは、例えば、検索結果が著しく少なくなってしまう検索条件へ変更されてしまうことや、全ての評価値が最大値（図４の例では１００）へ変更されてしまうことを示している。

具体的には、ステップＳ２０６で、ユーザが行った変更操作に応じて自動的に他の評価軸の評価値を調整する処理を行う。これにより、検索条件が不適切なものとなってしまうことを防止する。
ステップＳ２０６の詳細な処理内容については、後述する。

レシピ管理サーバ１は、ステップＳ２０６の処理を実行することにより、調整情報をユーザ端末３に送信する。調整情報とは、調整の対象となった評価軸（以降、「調整評価軸」と記載）についての調整情報がユーザ端末３に送信される。これにより、ユーザ端末３上に表示された検索条件設定画面において、調整された評価値が提示される。
ユーザ端末３は、ユーザが変更操作を行うたびにステップＳ１０４の処理を行い、レシピ管理サーバ１はそれに応じてステップＳ２０６の処理を行う。
これらの一連の処理が１または複数回実行されることにより、ユーザは検索条件設定画面において検索条件を設定することができる。

続いて、決定した検索条件に応じてユーザが検索ボタン１５を押下すると、ユーザ端末３はステップＳ１０５の検索操作受付処理を実行する。この処理では、確定した検索条件をレシピ管理サーバ１へ送信すると共に、検索条件に応じた検索処理の実行をレシピ管理サーバ１に要求する。

検索要求を受信したレシピ管理サーバ１は、ステップＳ２０７で、検索処理を実行し、ユーザの指定した検索条件に応じたレシピを検索結果として抽出する。
検索処理では、例えば図４のようなレーダーチャートで設定される検索条件に基づいてレシピを検索する処理が実行される。例えば、レシピ管理サーバ１が管理する各レシピは、レシピごとに図４に示すレーダーチャートを構築可能な情報を有しており、レーダーチャートの形状が検索条件と似ているレシピを検索結果として抽出する。

レーダーチャートの形状が検索条件と似ているレシピとは、例えば相似形にあるレシピであってもよいし、評価値が突出した評価軸（図４では「節約」とラベリングされた評価軸や「低価格」とラベリングされた評価軸など）が同じレシピであってもよい。また、逆に、評価値が低い評価軸（図４では「高級感」とラベリングされた評価軸など）が同じレシピであってもよい。
また、検索条件と検索対象のレシピにおける各評価値の差分を加算した情報を用いることにより、似ているレシピか否かを判定してもよいし、各評価値の差分から分散値を算出することにより、該判定を行ってもよい。
なお、ステップＳ２０７においては、ユーザ設定した検索条件に紐付けられた検索結果を検索ＤＢ５２から取得することにより、検索処理の代用としてもよい。

次にレシピ管理サーバ１は、ステップＳ２０８で、検索履歴の情報を履歴ＤＢ５３に記憶する処理を実行し、ステップＳ２０９で、検索結果の情報をユーザ端末３へ送信する。ユーザ端末３へ送信される情報は、例えば、検索結果が配置された検索結果画面のデータ（ウェブページデータ）である。

ユーザ端末３では、受信した検索結果画面データに応じて、検索結果画面をユーザ端末３上に表示させる処理を行う。これにより、ユーザは、自身の設定した検索条件に応じて抽出されたレシピ情報を閲覧することができる。
なお、ステップＳ１０６の処理の後、ユーザは、検索結果として表示された各レシピの一つを選択し、詳細画面を表示させる操作を行うことや、検索結果に納得いかずに他の検索結果を得るための検索条件を設定するために再度検索条件設定画面を要求するための操作を行うことが可能である。
ユーザ端末３は、そのような操作に応じて適切な処理を実行し、レシピ管理サーバ１ではユーザ端末３からの各種要求に応じて適切な処理を実行するものである。これらの処理についての説明の詳述は省略する。

［５−２．検索条件調整処理］
図５のステップＳ２０６に示した検索条件調整処理の一例について、図６を参照して説明する。
レシピ管理サーバ１はステップＳ３０１で、変更情報を取得する処理を実行する。変更情報は、前述したように、ユーザの変更操作の対象となった対象評価軸を特定する情報と、該対象評価軸の変更前の評価値と変更後の評価値の情報である。

レシピ管理サーバ１はステップＳ３０２で、差分算出処理を実行する。
具体的な例を挙げて説明する。
図７Ａには、ユーザに提示された検索条件設定画面に配置された検索条件設定領域１０を示している。この例では、六つの評価軸１３それぞれの評価値を検索条件として指定可能とされている。六つの評価軸１３は、「短時間」度合いを表す評価軸１３Ａ、「健康」度合いを表す評価軸１３Ｂ、「手軽さ」度合いを表す評価軸１３Ｃ、「高級感」度合いを表す評価軸１３Ｄ、「低価格」度合いを表す評価軸１３Ｅ、「満腹」度合いを表す評価軸１３Ｆとされている。評価軸１３Ａは、摘み部１３Ａａとラベル部１３Ａｂを備えている。評価軸１３Ｂは、摘み部１３Ｂａとラベル部１３Ｂｂを備えている。評価軸１３Ｃは、摘み部１３Ｃａとラベル部１３Ｃｂを備えている。評価軸１３Ｄは、摘み部１３Ｄａとラベル部１３Ｄｂを備えている。評価軸１３Ｅは、摘み部１３Ｅａとラベル部１３Ｅｂを備えている。評価軸１３Ｆは、摘み部１３Ｆａとラベル部１３Ｆｂを備えている。

図７Ａに示す状態から、ユーザが評価軸１３Ａの評価値を「５０」から「１００」へと変更させる変更操作を行った状態を示した図が、図７Ｂである。
なお、図７Ａに示す状態は、各評価軸１３Ａ〜１３Ｆの評価値を加算した合計評価値は、「３００」とされている。そして、図７Ｂに示す状態においては、合計評価値は「３５０」とされている。
従って、ステップＳ３０２の差分算出処理では、変更後の合計評価値「３５０」から変更前の合計評価値「３００」を減算した「５０」が差分値として算出される。

続いて、レシピ管理サーバ１はステップＳ３０３で、調整量を算出する処理を実行する。
調整量は、合計評価値が所定値以上変化しないようにするために算出される数値である。
例えば、所定値が「０」とされている場合、変更前後の合計評価値が同じ値となるように調整量を算出するということを意味する。従って、上述の例では、変更前の合計評価値が「３００」であることから、変更後の合計評価値が「３００」となるように調整量を算出する。変更後の合計評価値は、ユーザの操作によって「３５０」とされていることから、調整量は「−５０」と算出される。
これは、対象評価軸（評価軸１３Ａ）以外の評価軸（評価軸１３Ｂ〜１３Ｆ）の評価値を自動調整によって「５０」減算させることを意味する。

レシピ管理サーバ１は、ステップＳ３０４で、何れの評価軸の評価値を自動調整の対象とするかを決定する。自動調整の対象とされた評価軸を「調整評価軸」と記載する。
調整評価軸の決定については、いくつかの例を挙げることができる。

続いて、レシピ管理サーバ１はステップＳ３０５で、調整評価軸ごとの調整後の評価値を算出する処理を行う。
ステップＳ３０４及びＳ３０５の両処理については、各図を参照していくつかの例を説明する。

先ず、図８Ａを参照して一つ目の例を説明する。
一つ目の例では、対象評価軸を除く全ての評価軸を調整評価軸とする例である。即ち、評価軸１３Ｂ〜１３Ｆの５個の評価軸を調整評価軸として設定する（ステップＳ３０４）。
更に、ステップＳ３０５では、調整評価軸に対して一律同じ値を加算或いは減算する処理を行う。即ち、五つの調整評価軸を用いて調整量「−５０」を達成することから、一つの調整評価軸当たり評価値の調整量を「−１０」とすればよい。従って、評価軸１３Ｂは、「３０」から「２０」へと変更することにより調整量「−１０」を達成する。評価軸１３Ｃは、「５０」から「４０」へと変更することにより調整量「−１０」を達成する。評価軸１３Ｄは、「７０」から「６０」へと変更することにより調整量「−１０」を達成する。評価軸１３Ｅは、「３０」から「２０」へと変更することにより調整量「−１０」を達成する。評価軸１３Ｆは、「７０」から「６０」へと変更することにより調整量「−１０」を達成する。

レシピ管理サーバ１は、ステップＳ３０６で、調整情報をユーザ端末３へ送信する。ユーザ端末３へ送信される情報としては、例えば、調整後の数値としてもよいし、評価軸ごとの調整量を示す数値としてもよい。具体的に評価軸１３Ｂを例に挙げると、調整後の数値として「２０」の値を送信してもよいし、評価軸１３Ｂの調整量として「−１０」の値を送信してもよい。

ステップＳ３０５の処理における別の例について、図８Ｂを参照して説明する。
ステップＳ３０４で対象評価軸を除く全ての評価軸を調整評価軸として設定した後、レシピ管理サーバ１はステップＳ３０５で、調整評価軸ごとに調整後の評価値を算出するが、このとき、各評価軸の調整前の評価値に対する調整後の評価値が一定割合となるように評価値を算出する。

具体的に、図７Ｂに示す評価軸１３Ｂ〜１３Ｆの各軸の評価値の合計値は「２５０」とされており、調整量が「−５０」とされている。従って、「２５０」を８０％に圧縮する（即ち２０％減算）ことにより、調整量「−５０」を達成することができる。

これは、各評価軸１３Ｂ〜１３Ｆについて、それぞれの評価値を２０％減算することによって実現可能である。即ち、評価軸１３Ｂについては、調整前の評価値「３０」から２０％減算し「２４」とする。評価軸１３Ｃについては、調整前の評価値「５０」から２０％減算し「４０」とする。評価軸１３Ｄについては、調整前の評価値「７０」から２０％減算し「５６」とする。評価軸１３Ｅについては、調整前の評価値「３０」から２０％減算し「２４」とする。評価軸１３Ｆについては、調整前の評価値「７０」から２０％減算し「５６」とする。
これによって、評価軸１３Ｂ〜１３Ｆにおける調整後の評価値の合計値が「２００（＝２４＋４０＋５６＋２４＋５６）」とされる。換言すれば、調整量「−５０」が達成される。

なお、上述の例では、ステップＳ３０３の調整量算出の際に用いる「所定値」が「０」である例を説明したが、それ以外の値とされていてもよい。例えば、所定値が「２０」であってもよい。この場合には、変更前の合計評価値と変更後の合計評価値の差分が「２０未満」であれば、自動調整不要とするものである。例えば、変更前の合計評価値が「３００」とされており、ユーザの変更操作後の合計評価値が「３１０」である場合には、所定値（＝２０）以上の変化が起きていないため、ステップＳ３０３で算出される調整量が「０」とされ、ステップＳ３０４乃至Ｓ３０５の各処理の実行が省略される。ステップＳ３０６の送信処理では、調整不要である旨を通知可能とされていればよく、そのためには、調整後の評価値として未調整の評価値の情報を送信してもよいし、調整量が「０」であることを示す情報を送信してもよいし、調整を行っていないことを示す情報を送信してもよい。

また、「変更前の評価値と変更後の評価値が所定値以上」変化しないように調整量を算出することについて、「変更前の評価値」をユーザが検索条件設定画面を表示させた際に表示される各評価軸の初期状態（即ち、ユーザが検索条件設定画面を表示させてから評価値の変更操作を行っていない状態）における評価値としてもよい。
例えば、ユーザが評価軸１３Ａについて、評価値を「１０」加算する変更操作を行った場合、変更操作は変更前後の評価値が所定値（＝２０）以上変化するものではないため、調整量が「０」とされてしまう。ところが、評価値を「１０」加算するこのような変更操作を連続的に行うと、全ての評価軸１３Ａ〜１３Ｆについての評価値を「１００」としたにも関わらず、評価値の自動調整が行われない事態が生じうる。即ち、検索結果が著しく少ないような不適切な検索条件が設定可能とされてしまう虞がある。
そこで、「変更前の評価値」を「初期状態における評価値」とすることで、先の例によれば、評価値を「１０」加算するような変更操作を２回行った段階で「初期状態における評価値」から所定値（＝２０）以上変化することとなり、適切に評価値の自動調整が行われる。
これによって、検索条件が不適切なものとなってしまうことを防止することができる。

なお、図７Ｂに示す状態は、図７Ａに示す状態（初期状態）に対してユーザの変更操作による変更だけが反映された状態を示している。変更操作による変更が検索条件設定領域１０に反映されると略同時に、レシピ管理サーバ１によって実行される検索条件調整処理の結果が検索条件設定領域１０に反映される場合には、実際に図７Ｂに示される状態がユーザに提示される時間は極めて短い時間となるか、或いは図７Ｂに示される状態がユーザに提示されることはなくてもよい。その場合には、ユーザが変更操作を行ったことに応じてユーザに提示される検索条件設定領域１０としては、図８Ａなどに示す状態とされる。

［５−３．検索条件調整処理の第２例］
検索条件調整処理の第２例及び後述する第３例では、評価軸間の関係性に着目して評価値の調整を行うものである。
図９Ａに示す状態は、評価軸間の負の相関関係を考慮して評価値の調整を行う例である。また、図９Ｂに示す状態は、評価軸間の正の相関関係及び負の相関関係の双方を考慮して評価値の調整を行う例である。

検索条件調整処理の第２例においてレシピ管理サーバ１が実行する各処理について、図１０を参照して説明する。
なお、検索条件調整処理の第２例は、図７Ａに示す状態においてユーザが図７Ｂに示す状態へと検索条件を変更するための変更操作を行ったことに応じて、レシピ管理サーバ１が検索条件の自動調整を行い、図９Ａに示す状態へと変化させるものである。

レシピ管理サーバ１はステップＳ３０１乃至Ｓ３０３の各処理を行う。この処理は図６で説明した処理と同様の処理であり、詳述を省く。
調整量を「−５０」と算出した後、レシピ管理サーバ１はステップＳ３０７で、対象評価軸と負の相関関係が見られる評価軸を調整評価軸として設定する。即ち、対象評価軸とここで選択された調整評価軸は、負の相関関係があるということである。

負の相関関係について具体的に説明する。
例えば、図９Ａに示す例では、評価軸１３Ａが対象評価軸とされ、評価軸１３Ｄが調整評価軸として設定されている。即ち、ラベル部１３Ａｂが「短時間」とされた評価軸１３Ａとラベル部１３Ｄｂが「高級感」とされた評価軸１３Ｄは、負の相関関係がある。
評価軸間における負の相関関係の有無は、レシピ管理サーバ１が管理するレシピ群においてみられる傾向を元に判定される。従って、図９Ａに示す例では、調理時間が短時間とされたレシピは高級感に乏しいものが多く、また、高級感のあるレシピは調理時間が短時間では済まないものが多かったことから、評価軸１３Ａと評価軸１３Ｄは負の相関関係を有すると判定されたものである。

レシピ管理サーバ１はステップＳ３０５で、調整評価軸（即ち評価軸１３Ｄ）の調整後の評価値を算出する。ステップＳ３０３の処理において、調整量が「−５０」と算出されたことから、調整評価軸の調整後の評価値は５０を減算した「２０」と算出される。
これにより、相反する評価軸の評価値が互いに最大値（＝１００）となってしまうような状態を回避することができる。即ち、検索条件が不適切なものとなってしまうことを防止することができる。
続いて、レシピ管理サーバ１はステップＳ３０６で調整情報を送信する。

［５−４．検索条件調整処理の第３例］
検索条件調整処理の第３例について、図９Ｂ及び図１１を参照して説明する。
なお、検索条件調整処理の第３例は、図７Ａに示す状態においてユーザが図７Ｂに示す状態へと検索条件を変更するための変更操作を行ったことに応じて、レシピ管理サーバ１が検索条件の自動調整を行い、図９Ｂに示す状態へと変化させるものである。

レシピ管理サーバ１は、ステップＳ３０１乃至Ｓ３０３の各処理を実行することにより、変更情報に基づいた調整量の算出を行う。調整量は、「−５０」とされる。
次に、レシピ管理サーバ１はステップＳ３０８において、対象評価軸と正の相関関係が見られる評価軸を第１調整評価軸として設定する。
具体的に、図９Ｂを参照して説明する。図９Ｂに示す例では、評価軸１３Ａと評価軸１３Ｃは正の相関関係があるとされている。即ち、ラベル部１３Ａｂが「短時間」とされた評価軸１３Ａとラベル部１３Ｃｂが「手軽さ」とされた評価軸１３Ｃは、正の相関関係がある。これは、調理時間が短時間とされたレシピは手軽さも高い評価値となるものが多く、また、調理時間が短時間で済まないレシピは手軽さも低い評価値となるものが多いことを意味している。

このような評価軸間の正の相関関係情報や負の相関関係情報は、レシピ管理サーバ１が用いるＤＢの何れかに記憶されていればよい。

レシピ管理サーバ１はステップＳ３０９において、第１調整評価軸（評価軸１３Ｃ）の調整後の評価値を算出する処理を行う。図９Ｂに示す例では、対象評価軸（評価軸１３Ａ）の評価値が「５０」から「１００」へと「５０」増加されたことから、第１調整評価軸についても「５０」増加させている（評価値「５０」から評価値「１００」）。
ステップＳ３０９の処理については、いくつかの例が考えられる。例えば、対象評価軸の増加率と第１調整評価軸の増加率が同等となるように第１調整評価軸の評価値を調整してもよい。

レシピ管理サーバ１は、ステップＳ３１０で、対象評価軸と負の相関関係が見られる評価軸を第２調整評価軸として設定する。先の例と同様に、負の相関関係が見られる評価軸は評価軸１３Ｄとされている。即ち、第２調整評価軸は評価軸１３Ｄとされる。
次に、レシピ管理サーバ１は、ステップＳ３１１で、第２調整評価軸（評価軸１３Ｄ）の調整後の評価値を算出する。この処理において、ステップＳ３０３で算出した調整量（＝−５０）を達成することができた場合、レシピ管理サーバ１はステップＳ３０６で調整情報をユーザ端末３に送信する処理を行い、検索条件調整処理を終了する。

なお、図９Ｂに示す例では、第１調整評価軸で「５０」増加されたため、調整量「−５０」を達成するためには、第２調整評価軸を「１００」減算させる必要がある。第２調整評価軸の調整前の評価値は「７０」であるため、調整量「−５０」を達成することはできない。その場合には、ステップＳ３１１の処理の後に、図１２に示す各処理を実行することが好ましい。

ステップＳ３１１の処理の後、レシピ管理サーバ１はステップＳ３１２において、他の評価軸の調整が必要か否かを判定する。他の評価軸とは、対象評価軸（評価軸１３Ａ）と第１評価軸（評価軸１３Ｃ）と第２評価軸（評価軸１３Ｄ）を除いた他の評価軸（評価軸１３Ｂ，１３Ｅ，１３Ｆ）を示している。
図９Ｂでは、第１調整評価軸に対する調整量が「＋５０」とされ、第２調整評価軸に対する調整量が「−７０」とされている。第１調整評価軸及び第２調整評価軸における合計の調整量は「−２０」であることから、ステップＳ３０３で算出した調整量「−５０」とは乖離がある。
このような場合には、ステップＳ３１２の判定処理で、他の評価軸の調整が必要と判定される。

レシピ管理サーバ１は、ステップＳ３１３で、調整評価軸に選択されていない評価軸（即ち評価軸１３Ｂ，１３Ｅ，１３Ｆ）を新たな調整評価軸として設定し、ステップＳ３１４で、新たな調整評価軸の調整後の評価値を算出する。
図９Ｂの例では、新たな調整評価軸それぞれについて、評価値を「−１０」変更することにより、ステップＳ３０３で算出した調整量「−５０」を達成することができる。
従って、評価軸１３Ｂの評価値を「３０」から「２０」へと調整し，評価軸１３Ｅの評価値を「３０」から「２０」へと調整し，評価軸１３Ｆの評価値を「７０」から「６０」へと調整する。
まとめると、検索条件調整処理を実行後の各評価値は、評価軸１３Ａが「１００」とされ、評価軸１３Ｂが「２０」とされ、評価軸１３Ｃが「１００」とされ、評価軸１３Ｄが「０」とされ、評価軸１３Ｅが「２０」とされ、評価軸１３Ｆが「６０」とされる。各評価軸の合計評価値は「３００」とされ、ユーザの変更操作前の合計評価値と等しくされる。

レシピ管理サーバ１は、最後にステップＳ３０６で調整情報をユーザ端末３に送信し、図１１及び図１２に示す一連の処理を終了する。また、ステップＳ３１２において、他の評価軸の調整は不要と判定した場合についても、レシピ管理サーバ１は最後にステップＳ３０６で調整情報をユーザ端末３に送信し、検索条件調整処理を終了する。
なお、図１２に示す各処理は、図１０のステップＳ３０５の処理の後に実行してもよい。

［５−５．検索条件調整処理の第４例］
検索条件調整処理の第４例について、図１３を参照して説明する。
検索条件調整処理の第４例では、検索条件設定画面がユーザに提示されてから検索要求を受信するまでに行われる複数の変更操作を一連の変更操作として扱う。

レシピ管理サーバ１は、ステップＳ３０１乃至Ｓ３０３の各処理を実行することにより、ユーザが行った検索条件変更操作に応じた調整量を算出する。
続いて、レシピ管理サーバ１はステップＳ３１５で、前回の変更操作からページ遷移したか否かを判定する。
前回の変更操作からページ遷移していない場合、レシピ管理サーバ１は今回の変更操作（ステップＳ３０１で変更情報の取得対象となった変更操作）はその前に行われた他の変更操作から続く一連の変更操作であると判定して記憶する。

具体例を説明する。ユーザは、図７Ａに示す状態が初期状態とされた検索条件設定画面が提示された後、「調理時間が短時間で済み、且つ健康的なレシピを検索したい」と考えたとする。その場合、ユーザは、検索軸１３Ａの摘み部１３Ａａを操作することにより、評価値を「５０」から上昇させる変更操作を行った後に、検索軸１３Ｂの摘み部１３Ｂａを操作することにより、評価値を「３０」から上昇させる変更操作を行うことが考えられる。
ここで、検索軸１３Ａに対する変更操作を「第１変更操作」、検索軸１３Ｂに対する変更操作を「第２変更操作」とする。第１変更操作でユーザが設定した評価値が、第２変更操作に応じて実行される検索条件調整処理によって調整（変更）されてしまうことは、ユーザにとって好ましくないことが考えられる。
本例はこのような状態を回避するものである。

今回の変更操作が前回の変更操作から続く一連の変更操作とされた場合、レシピ管理サーバ１は、ステップＳ３１７で、一連の変更操作における対象評価軸以外の評価軸を調整評価軸として設定する。即ち、先の例においては、第１変更操作の対象評価軸である評価軸１３Ａと今回の変更操作（第２変更操作）の対象評価軸である評価軸１３Ｂが外され、それ以外の評価軸が対象評価軸として設定される。

続いて、レシピ管理サーバ１はステップＳ３０５で調整評価軸ごとの調整後の評価値を算出する。この処理については、図７を参照して説明した処理と同様の処理であるため、詳述を省く。但し、図７に示す処理に代わって、図１０乃至図１２で説明した各種の処理を実行してもよい。

調整評価軸の調整後の評価値を算出した後、レシピ管理サーバ１はステップＳ３０６で、調整情報をユーザ端末３に送信する。

また、ステップＳ３１５で前回の変更操作からページ遷移していると判定した場合、即ち、今回の変更操作が検索条件設定画面がユーザに提示されてから行う最初の変更操作である場合、レシピ管理サーバ１はステップＳ３１８で新たな変更操作として今回の変更操作に関する情報を記憶し、ステップＳ３０４で対象評価軸以外の評価軸全てを調整評価軸として設定し得る。勿論、その中の一部を調整評価軸としてもよい。
次に、レシピ管理サーバ１はステップＳ３０５及びＳ３０６の各処理を実行する。

図１３に示す各処理を実行することにより、一度ユーザが変更した調整軸は調整対象の評価軸から外されるため、ユーザの設定値が保持される。

なお、一連の変更操作を行うことによって、変更操作可能な評価軸全てが対象評価軸とされた場合、調整評価軸として設定可能な評価軸が存在しないこととなってしまう虞がある。この場合には、例えば、直前の変更操作と今回の変更操作における対象評価軸以外を調整評価軸とすることが考えられる。これによって、一連の変更操作のうち最初の方に行った変更操作の対象評価軸については、調整評価軸として設定され得ることとなり、全ての評価値を最大値にするような不適切な検索条件が設定されてしまうことを防止することができる。

［５−６．検索クエリ設定処理］
前述の各例においては、図５のステップＳ２０７の検索処理において、レーダーチャートの形状が似ているレシピを検索する例を説明したが、その他の例も考えられる。
具体的に、図１４を参照して説明する。

本例では、各評価値に応じて検索クエリを設定する例である。
レシピ管理サーバ１は、ステップＳ４０１で、取得した検索条件に基づいて、評価軸の少なくとも一部を検索条件評価軸として特定する処理を行う。
検索条件評価軸とは、ラベル部１３ｂに掲載されたテキスト情報が検索クエリとして使用される評価軸である。例えば、図８Ａに示す例では、他の評価軸と比較して最も高い評価値とされた評価軸１３Ａ（評価値「１００」）が検索条件評価軸とされる。検索条件評価軸の特定においては、閾値を用いてもよい。例えば、閾値が「８０」とされた場合において、閾値以上の評価値を有する評価軸を検索条件評価軸として特定してもよい。

検索条件評価軸を特定した後、レシピ管理サーバ１はステップＳ４０２で、検索条件評価軸のラベル情報を取得する。図８Ａの例においては、ラベル部１３Ａｂに表示されたテキスト情報である「短時間」という文字列がラベル情報として取得される。

レシピ管理サーバ１は、ステップＳ４０３において、検索クエリを生成する処理を実行する。この処理においては、ステップＳ４０２で取得したラベル情報を含む検索クエリが生成される。例えば、検索クエリには、図８Ａから抽出された「短時間」という文字列と、図４に示す絞り込み条件（例えば「カレーライス」というジャンル情報と「ほうれん草」という使用食材情報）が用いられる。具体的には、「カレーライス ほうれん草 短時間」という文字列が検索クエリとして生成される。

レシピ管理サーバ１は生成した検索クエリを用いて、ステップＳ２０７の検索処理を実行する。これによって、ユーザが設定した検索条件に応じたレシピ情報の検索が行われる。

なお、ステップＳ４０１の処理で複数の検索条件評価軸を特定し、ステップＳ４０２で複数のラベル情報を取得してもよい。その場合には、ステップＳ４０３で、「短時間 手軽」のようなＡＮＤ検索を行うための検索クエリが生成される。

また、ステップＳ４０１で検索条件評価軸を特定する際に、評価値が最も低い評価軸を検索条件評価軸としてもよい。図８Ａに示す例では、評価軸１３Ｂと評価軸１３Ｅが検索条件評価軸とされる。その場合には、ステップＳ４０２で「健康」と「低価格」という文字列がそれぞれ抽出され、ステップＳ４０３で、検索クエリを生成する際に、「健康」と「低価格」という文字列が含まれないレシピを検索対象とすることが考えられる。即ち、所謂ＮＯＴ検索に用いる文字列を取得するために検索条件評価軸を利用する。
もちろん、評価値が高い評価軸と低い評価軸の双方を検索条件評価軸として特定してもよい。

［５−７．初期評価値決定処理］
検索条件設定画面がユーザに提示される際には、同画面内に配置された検索条件設定領域１０の傾向設定領域１１に表示されるレーダーチャートは各評価値の初期値（初期評価値）の設定された状態（初期状態）とされる。ここでは、各初期評価値をユーザに応じて決定する例について、図１５を参照して説明する。

レシピ管理サーバ１は、ステップＳ５０１で、ユーザの履歴情報を取得する。
ユーザの履歴情報としては、例えば、レシピの閲覧履歴であってもよいし、レシピの使用履歴であってもよいし、ユーザの他のウェブページの閲覧履歴であってもよい。また、ユーザが指定した検索条件の履歴であってもよいし、ユーザが購入した商品や食材などの情報であってもよい。レシピの使用については、レシピを利用して実際に料理を作成したユーザが投稿する作成レポートによって推定してもよいし、レシピの閲覧時間の長さによって推定してもよい。

一例を挙げると、ユーザが前回レシピを検索するために設定した各評価軸の評価値を履歴情報として取得する。
続いて、レシピ管理サーバ１はステップＳ５０２で、初期評価値を設定する。
前回のレシピ検索時に設定した各評価値を取得した場合、取得した評価値をそのまま初期評価値として設定する。

なお、直近の複数回のレシピ検索において設定した評価値を履歴情報として取得し、初期評価値の算出においては取得した評価値の平均値を用いてもよい。

他の例として、ユーザが「お手軽レシピ」と検索した履歴情報を取得し、これに応じて「手軽さ」の評価軸１３Ｃの初期評価値を高く設定するなどしてもよい。

＜６．各種変形例＞

［６−１．変形例１］
検索クエリ設定処理における変形例について述べる。
図１４に示すステップＳ４０１の検索条件評価軸の特定処理では、ユーザが評価値を設定した評価軸、即ち対象評価軸を考慮してもよい。
例えば、図９Ｂに示す例では、ユーザの変更操作によって評価軸１３Ａの評価値が「１００」へと変更されたものである。即ち、ユーザは、「短時間」で調理可能なレシピを検索したいという意思を持っていることが推測できる。
一方、検索軸１３Ｃは、図１１に示すステップＳ３０８，Ｓ３０９の処理によって評価値が「１００」へと調整されたものである。

評価軸１３Ａと評価軸１３Ｃに関する上記の違いを鑑みると、「手軽さ」のみを含む検索クエリは好ましくないことが分かる。また、「短時間」を含む検索クエリは、ユーザの意図に沿った検索クエリである可能性が高い。

そこで、図１４に示すステップＳ４０１の処理では、少なくともユーザの変更操作の対象である対象評価軸であって高い評価値とされた（或いは低い評価値とされた）評価軸を検索条件評価軸として特定することが望ましい。また、それに加えて、調整評価軸のうち高い（或いは低い）評価値とされた評価軸についても検索条件評価軸としてもよい。
これにより、ユーザの検索意図に適合した検索クエリを生成することが可能となる。

［６−２．変形例２］
上述した各例では、ユーザの変更操作が完了するごとに図６などに示した検索条件調整処理が実行されるものとした。他に考えられる例として、ユーザが変更操作を行っている最中、換言すれば、ユーザが摘み部１３ａを移動させている最中においても、定期的（例えば１００ｍｓｅｃごとなど）に検索条件調整処理を行ってもよい。ユーザは、自分の変更操作に応じて他の評価軸の評価値がどのように変化するのかをリアルタイムで知ることができ、該変化を考慮した適切な変更操作を行うことが可能となる。

［６−３．変形例３］
検索条件設定領域１０の傾向設定領域１１に表示されるレーダーチャートの変形例について図１６を参照して説明する。
傾向設定領域１１に表示されるグラフや図の形式は、図１６Ａに示すように折れ線グラフであってもよいし、棒グラフであってもよい。
また、図１６Ｂに示すように、ラベル部と評価値が入力可能な入力欄が並べられた形状とされていてもよい。
更には、円グラフのようなものであってもよい。
このような表示態様は、評価軸間の評価値の大小関係を明確にすることができるため、ユーザは自身が設定している検索条件がどのようなものであるのかを把握することが容易となる。

［６−４．変形例４］
検索条件調整処理を行う際に、一定数以上の検索結果を得ることができるか否かを判定しながら行ってもよい。
例えば、図７Ａに示す状態から図７Ｂに示す状態へと検索条件を変更する操作をユーザが行った場合に、図９Ｂに示す状態へと検索条件を調整する検索条件調整処理を行う例を考える。
この際、図９Ｂに示す状態へと調整した場合に行う検索処理を事前処理として実際に実行する。更に、該検索処理を行った結果取得される検索結果が妥当であるか否かを判定する。例えば、検索結果が５件以上取得できた場合は、ユーザにとって有用な検索結果を提示することができると判定する。この場合は、該調整した検索条件を検索条件設定領域１０の傾向設定領域１１に反映させることでユーザに提示する。

一方、検索結果件数が５件未満など、ユーザにとって有用な検索結果を提示できないような場合は、再度各評価値の調整を行う。例えば、図９Ａに示す状態へと検索条件を調整する検索条件調整処理を行う。更に、先述の処理と同様に、再調整した検索条件がユーザにとって有用か否かを判定し、該再調整した検索条件を適用するか否かを決定する。

これによって、ユーザに提示される調整後の検索条件は、ある程度の検索結果を得られることができる検索条件であることが担保される。即ち、ユーザにとって適切な検索条件がユーザに提示される可能性を高めることができ、更に、ユーザが検索操作を行った際にユーザが所望の検索結果を得ることができる可能性を高めることができる。

［６−５．変形例５］
レシピに設定された１または複数の評価軸は、レシピごとに異なるものであってもよい。例えば、あるレシピはラベル情報が「満腹」とされた評価軸を備えているが、他のあるレシピは該評価軸を備えていなくてもよい。
レシピごとに備えている評価軸が異なる場合において、検索処理を行う際には、検索条件によって指定された評価軸と少なくとも一つ以上の評価軸が一致するレシピが検索対象とされる。更に、該一致する評価軸において、指定された検索条件における各評価値の傾向に沿ったレシピが検索結果として抽出される。
また、ユーザが手動で設定した検索条件、即ち、対象評価軸については、ユーザが所望しているレシピを特定する重要な要素であるため、少なくとも対象評価軸を備えていないレシピは検索対象から外してもよい。

［６−６．その他］
上述した各例では、料理のレシピを検索する例を挙げたが、それ以外の検索対象であってもよい。例えば、各種のウェブページデータを検索する際の検索条件を設定するものとして、図４に示したような検索条件設定領域１０がユーザに提示されてもよい。
また、自分の要望に合う中古車を検索するシステムとして上述に例示した各種態様が用いられてもよい。
図４に示すような検索条件設定領域は、ユーザが特定のものを検索するために用いるのでは無く、大まかな方向性だけを決めた検索を行いたい場合などに最適である。また、その場合には、検索対象物ごとの傾向を評価するための評価軸と評価値が設定されることにより、上述した各種の検索条件の設定や検索処理を実行することが可能である。

大まかな方向性だけを決めて検索を行う例としては、他にも、絵画や音楽を検索する場合や、婚活相手のマッチングシステムなどにも応用可能である。例えば、婚活相手のマッチングでは、全ての要素を兼ね備えた完璧なユーザを見つけることが困難であり、ユーザの優先度に応じて優先度の低い評価軸（「背の高さ」など）を自動調整することにより、ユーザにとって最適な相手をマッチングさせることが可能となる。

なお、上述した各種の例は、その組合せが不可能でない限り、適宜組み合わせることができる。

＜７．まとめ＞

上述した各例で説明したように、評価対象（例えばレシピ）ごとに付与された複数の評価軸と評価値を管理する評価情報管理部（レシピ管理部１ａ）と、評価軸及び評価値を指定することにより評価対象の検索条件を設定可能な検索条件設定手段（傾向設定領域１１）を提示する制御を行う提示制御部１ｅと、検索条件を変更する変更操作の対象とされた対象評価軸についての変更前の評価値と変更後の評価値の情報を取得する変更情報取得部１ｂと、変更前の評価値と変更後の評価値の差分に応じて、全ての評価軸の評価値の合計値が所定値以上変化しないように、対象評価軸以外の評価軸の少なくとも一つとされた調整評価軸の評価値を変更することにより検索条件を調整する検索条件調整部１ｃと、調整された検索条件に基づいて検索処理を行い評価対象を抽出する検索処理部１ｄと、を備えている。
調整評価軸の評価値を変更する調整を行い全評価軸の評価値の合計値の変化量を抑えることにより、ユーザが対象評価軸に設定した設定値（評価値）の特徴が出やすいような検索条件が設定される。
例えば、評価軸１３Ａの評価値を５０から６０に増加させた場合に、そのままだと他の評価軸の評価値（例えば初期値である５０）との差分は１０となり、特徴が出にくい検索条件となる。しかし、検索条件を調整する処理として評価軸１３Ａの評価値が増加した代わりに他の評価軸の評価値を５０から４０へと減少させる処理を行うことにより、他の評価軸との差分が２０となり、より特徴が強調された検索条件を自動で設定することができる。
特に、評価値の合計値の変化量が少なくなるように調整することで、例えば全ての評価軸の評価値を最大値にするような検索条件、換言すれば検索結果として該当する評価対象が存在しないか著しく少なくなるような検索条件を指定することができなくなる。これによって、何らかの検索結果を提示することが可能とされた適切な検索条件が設定され、検索結果が得られないといった好ましくない状況を避けることができる。また、そのような場合には、検索結果を適切に得るために、ユーザは、何らかの評価軸の評価値を上げる代わりに他の評価軸の評価値を下げるような設定を手動で行うことが考えられる。しかし、本構成によればそのような設定が自動的に行われることにより、利便性の向上が図られている。
また、上述した各種の例においてユーザに提示される傾向設定領域１１は、簡易な操作によって検索条件を変更させることができるものであり、検索条件を設定する際のユーザの操作負担を軽減することが可能である。

初期評価値決定処理の例で説明したように、提示制御部１ｅは、評価値の初期値を指定して検索条件設定手段の提示を行い、初期値は評価対象の検索を行うユーザの行動履歴に基づく数値とされていてもよい。
例えば、「価格」という評価軸に対して「安い（評価値＝３）」「普通（評価値＝２）」「高い（評価値＝１）」の３段階が指定可能である場合に、ユーザが検索対象を検索する際に、安いことを示す評価値＝３を毎回指定していることに応じて、提示制御部は、「価格」の評価軸の初期値（デフォルト値）に「３」を設定した状態で検索条件設定手段を提示する。
従って、ユーザは、自身のいつもの行動に応じた検索条件が予め指定された状態で検索条件設定手段が提示されるため、各評価軸の評価値をあまり設定し直さずにいつもの検索条件を指定することが可能となる。即ち、入力操作（評価値の設定操作）の煩わしさを軽減させることができる。

検索条件調整処理の例で説明したように、検索条件調整部１ｃは、調整評価軸間の評価値の大小関係が崩れないように調整を行ってもよい。
ユーザが評価対象を検索するための条件を指定する際、即ち評価値の指定の際には、複数項目について指定することが考えられる。この場合において、本構成によれば、ユーザの操作対象とされた対象評価軸以外の評価軸について設定した大小関係が崩れないように評価軸の評価値が調整される。
これによって、ユーザは、自分が検索したい条件を設定するために複数の評価軸の評価値を指定する際に、それまでに設定した検索条件の特徴を引き継いだまま次の評価軸の設定を行うことができ、使いやすい評価条件の設定環境が提供される。

検索条件調整処理の例で説明したように、検索条件調整部１ｃは、調整評価軸間の評価値の割合を変えないように調整を行ってもよい。
ユーザが複数の評価軸の評価値を指定する操作を行うことにより検索条件の設定を行うような場合に、次の操作対象とされた対象評価軸の評価値を変更する際にそれまでに設定済みの評価軸同士の関係性を保ったままとされる。
これによって、ユーザは、それまでに設定した評価軸の関係性が崩れないように所定の割合を保ったまま次の評価軸の評価値の設定を行うことができる。即ち、検索条件の特徴を出しやすい検索条件設定手段を提供することが可能となる。

検索条件調整処理の第２例や第３例において説明したように、検索条件調整部１ｃは、調整評価軸ごとの対象評価軸との関係性に基づいて、調整評価軸を決定してもよい。
複数の評価軸の評価値の間に正の相関関係や負の相関関係が見られる場合がある。例えば、負の相関関係が見られる評価軸１３Ａ，１３Ｂにおいて、ユーザが評価軸１３Ａを対象評価軸として変更操作を行った場合に、評価軸１３Ｂを調整評価軸として選択し評価軸１３Ａに対して行われた評価値の増減操作とは逆方向に評価軸１３Ｂの評価値を増減させることが考えられる。
また、正の相関関係が見られる評価軸１３Ｃ，１３Ｄにおいて、ユーザが評価軸１３Ｃを対象評価軸として変更操作を行った場合に、評価軸１３Ｄを調整評価軸として選択し評価軸１３Ｃの評価値に対して行われた増減操作と同方向の調整を行うと共に、他の評価軸についても調整評価軸とし評価軸１３Ｃに対して行われた評価値の増減操作とは異なる方向に評価値を調整する。
これにより、対象評価軸以外の評価軸が一律同様に調整評価軸として決定されて調整されるのではなく、評価軸間の関係性に基づいて適切な調整が行われるため、適切な検索条件を簡単な操作で行うことが可能となる。
なお、正の相関関係がある評価軸とは、例えば評価対象がレシピであれば、「高級感」と「価格」の評価軸や、「おいしさ」と「低価格」の評価軸などである。また、負の相関関係がある評価軸とは、例えば、「手軽さ」と「高級感」の評価軸や、「おつまみ感」と「満腹」の評価軸などである。勿論、レシピによっては必ずしもこのような相関関係が当てはまるとは限らないが、レシピ全体で見たときにこのような評価軸間の相関関係が総じて見られるものを「相関関係を有する評価軸」としている。

検索条件調整処理の第４例で説明したように、変更情報取得部１ｂは、検索条件設定手段の提示から検索処理の間に受け付けた複数回の変更操作を一連の変更操作として特定し、検索条件調整部１ｃは、一連の変更操作における最新の変更操作に応じた調整を行う場合に、当該一連の変更操作それぞれにおいて対象評価軸とされた評価軸のうち少なくとも一部は調整評価軸から外して調整を行ってもよい。
例えば、ユーザが検索条件として設定可能な評価軸１３Ａ〜１３Ｅが用意されており、ユーザが評価軸１３Ａを対象評価軸とした変更操作を行い、次に評価軸１３Ｂを対象評価軸とした変更操作を行った場合に、評価軸１３Ｂの評価値を操作に応じて変更する代わりに他の評価軸を調整評価軸として全体の合計値が所定値以上変化しないように調整する。このときに、本構成によれば、評価軸１３Ａについては、ユーザが変更操作で指定した評価値を維持するために、調整評価軸から外される。
これにより、一度設定した評価軸が他の評価軸を変更した際に変更されてしまうようなことが防止され、ユーザにとって使い勝手のよい検索条件設定手段を提供することができる。

検索条件調整処理の例などで説明したように、調整評価軸は対象評価軸以外の全ての評価軸とされてもよい。
ユーザがそれまでに変更操作の対象としたか否かに関わらず、対象評価軸以外の評価軸全てが調整評価軸として調整の対象とされる。例えば、ユーザが誤って評価軸１３Ａの評価値を変更してしまった後、本来変更したかった評価軸１３Ｂの評価値を変更した場合に、評価軸１３Ａについても調整評価軸とされる。ことで、ユーザの意図に沿った検索条件の設定を行うことができる。
これにより、ユーザの意図に沿った検索条件の設定を行うことができる。
なお、ユーザが評価軸の評価値を変更する操作を行った後、リセットボタンを押下するなどの特定の操作を行うことにより、対象評価軸以外の評価軸全てが調整評価軸とされるように構成してもよい。

検索クエリ設定処理の例で説明したように、検索処理部１ｄは、調整された検索条件において評価値が所定値以上とされた評価軸が存在する場合は、評価値が所定値以上とされた評価軸を検索条件評価軸として決定し、検索条件評価軸に付与されているラベル情報に基づいて検索処理を行ってもよい。
例えば、各評価軸において取り得る評価値が０〜１００とされ、所定値が８０とされ、調整後において評価軸１３Ａの評価値が８０を超えていた場合、評価軸１３Ａが検索条件評価軸として決定される。更に、評価軸１３Ａのラベルが「節約」とされていた場合、「節約」についての評価値が高いレシピが検索結果として抽出されるように検索処理を行う。
これによって、ユーザは各評価値を変更するという簡易的な操作で設定した検索条件の特徴を反映した検索処理が行われ、該当した検索結果を取得することができる。即ち、検索文字列などを入力する文字入力操作を行わなくても所望するレシピを検索することが可能となり、利便性の向上を図ることができる。

検索クエリ設定処理の例で説明したように、検索処理部１ｄは、検索条件評価軸が複数存在する場合に、複数の検索条件評価軸にそれぞれ付与されたラベル情報を基づいたアンド検索を検索処理において行ってもよい。
例えば、各評価軸において取り得る評価値が０〜１００とされ、所定値が８０とされ、調整後において評価軸１３Ａ及び評価軸１３Ｂの評価値が８０を超えていた場合、評価軸１３Ａ，１３Ｂが検索条件評価軸として決定される。更に、評価軸１３Ａのラベルが「節約」とされ、評価軸１３Ｂのラベルが「健康的」とされていた場合、「節約」と「健康的」についての評価値が高いレシピが検索結果として抽出されるように評価軸のラベル情報を用いた検索処理を行う。
これによって、複数の評価軸に対してユーザが指定したそれぞれの評価値が設定された一見複雑に見える検索条件に対して、簡易な検索処理を実行することにより、ユーザが所望するレシピを検索結果として提示することができるため、処理負担の軽減が図られる。
また、複数の評価軸に付与されたラベル情報を用いた検索操作を行いたい場合には、対応する検索軸の評価値を所定値以上にする簡易な操作を行うだけでよいため、操作負担の軽減を図ることができる。

＜８．プログラム及び記憶媒体＞

以上、本発明の情報処理装置の実施の形態としてのレシピ管理サーバ１を説明してきたが、実施の形態のプログラムは、レシピ管理サーバ１における各処理を情報処理装置（ＣＰＵ等）に実行させるプログラムである。

実施の形態のプログラムは、評価対象ごとに付与された複数の評価軸と評価値を管理する評価情報管理機能を情報処理装置に実行させる。
また、前記評価軸及び評価値を指定することにより前記評価対象の検索条件を設定可能な検索条件設定手段を提示する制御を行う提示制御機能を情報処理装置に実行させる。
更に、前記検索条件を変更する変更操作の対象とされた対象評価軸についての変更前の評価値と変更後の評価値の情報を取得する変更情報取得機能を情報処理装置に実行させる。
更にまた、前記変更前の評価値と前記変更後の評価値の差分に応じて、全ての評価軸の評価値の合計値が所定値以上変化しないように、前記対象評価軸以外の評価軸の少なくとも一つとされた調整評価軸の評価値を変更することにより前記検索条件を調整する検索条件調整機能を情報処理装置に実行させる。
加えて、前記調整された検索条件に基づいて検索処理を行い前記評価対象を抽出する検索処理機能を情報処理装置に実行させる。
即ちこのプログラムは、レシピ管理サーバ１に対して図５のステップＳ２０１乃至Ｓ２０９の各処理、図６，図１０乃至図１５の各処理を実行させるプログラムである。

このようなプログラムにより、上述したレシピ管理サーバ１としての情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置などの機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭなどに予め記録しておくことができる。或いはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的或いは永続的に格納（記録）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータなどにインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。

１ レシピ管理サーバ、１ａ レシピ管理部、１ｂ 変更情報取得部、１ｃ 検索条件調整部、１ｄ 検索処理部、１ｅ 提示制御部、２ 通信ネットワーク、３ ユーザ端末、１０ 検索条件設定領域、１１ 傾向設定領域、１３ 評価軸、５０ ユーザＤＢ、５１ レシピＤＢ、５２ 検索ＤＢ、５３ 履歴ＤＢ、５４ ウェブページＤＢ

Claims (10)

1. 評価対象ごとに付与された複数の評価軸と評価値を管理する評価情報管理部と、
   前記評価軸及び評価値を指定することにより前記評価対象の検索条件を設定可能な検索条件設定手段を提示する制御を行う提示制御部と、
   前記検索条件を変更する変更操作の対象とされた対象評価軸についての変更前の評価値と変更後の評価値の情報を取得する変更情報取得部と、
   前記変更前の評価値と前記変更後の評価値の差分に応じて、全ての評価軸の評価値の合計値が所定値以上変化しないように、前記対象評価軸以外の評価軸の少なくとも一つとされた調整評価軸の評価値を変更することにより前記検索条件を調整する検索条件調整部と、
   前記調整された検索条件に基づいて検索処理を行い前記評価対象を抽出する検索処理部と、を備え、
   前記変更情報取得部は、前記検索条件設定手段の提示から前記検索処理の間に受け付けた複数回の前記変更操作を一連の変更操作として特定し、
   前記検索条件調整部は、前記一連の変更操作における最新の変更操作に応じた調整を行う場合に、当該一連の変更操作それぞれにおいて対象評価軸とされた評価軸のうち少なくとも一部は前記調整評価軸から外して前記調整を行う
   情報処理装置。
2. 評価対象ごとに付与された複数の評価軸と評価値を管理する評価情報管理部と、
   前記評価軸及び評価値を指定することにより前記評価対象の検索条件を設定可能な検索条件設定手段を提示する制御を行う提示制御部と、
   前記検索条件を変更する変更操作の対象とされた対象評価軸についての変更前の評価値と変更後の評価値の情報を取得する変更情報取得部と、
   前記変更前の評価値と前記変更後の評価値の差分に応じて、全ての評価軸の評価値の合計値が所定値以上変化しないように、前記対象評価軸以外の評価軸の少なくとも一つとされた調整評価軸の評価値を変更することにより前記検索条件を調整する検索条件調整部と、
   前記調整された検索条件に基づいて検索処理を行い前記評価対象を抽出する検索処理部と、を備え、
   前記検索処理部は、
   前記調整された検索条件において評価値が所定値以上とされた前記評価軸が存在する場合は、前記評価値が所定値以上とされた評価軸を検索条件評価軸として決定し、
   前記検索条件評価軸に付与されているラベル情報に基づいて前記検索処理を行う
   情報処理装置。
3. 前記提示制御部は、前記評価値の初期値を指定して前記検索条件設定手段の提示を行い、
   前記初期値は前記評価対象の検索を行うユーザの行動履歴に基づく数値とされた
   請求項１または請求項２に記載の情報処理装置。
4. 前記検索条件調整部は、前記調整評価軸間の評価値の大小関係が崩れないように前記調整を行う
   請求項１または請求項２に記載の情報処理装置。
5. 前記検索条件調整部は、前記調整評価軸間の評価値の割合を変えないように前記調整を行う
   請求項４に記載の情報処理装置。
6. 前記検索条件調整部は、前記調整評価軸ごとの前記対象評価軸との関係性に基づいて、前記調整評価軸を決定する
   請求項１または請求項２に記載の情報処理装置。
7. 前記調整評価軸は前記対象評価軸以外の全ての評価軸とされた
   請求項１または請求項２に記載の情報処理装置。
8. 前記検索処理部は、
   前記検索条件評価軸が複数存在する場合に、前記複数の前記検索条件評価軸にそれぞれ付与されたラベル情報を基づいたアンド検索を前記検索処理において行う
   請求項２に記載の情報処理装置。
9. 評価対象ごとに付与された複数の評価軸と評価値を管理する評価情報管理ステップと、
   前記評価軸及び評価値を指定することにより前記評価対象の検索条件を設定可能な検索条件設定手段を提示する制御を行う提示制御ステップと、
   前記検索条件を変更する変更操作の対象とされた対象評価軸についての変更前の評価値と変更後の評価値の情報を取得する変更情報取得ステップと、
   前記変更前の評価値と前記変更後の評価値の差分に応じて、全ての評価軸の評価値の合計値が所定値以上変化しないように、前記対象評価軸以外の評価軸の少なくとも一つとされた調整評価軸の評価値を変更することにより前記検索条件を調整する検索条件調整ステップと、
   前記調整された検索条件に基づいて検索処理を行い前記評価対象を抽出する検索処理ステップと、を情報処理装置が実行する情報処理方法であって、
   前記変更情報取得ステップでは、前記検索条件設定手段の提示から前記検索処理の間に受け付けた複数回の前記変更操作を一連の変更操作として特定し、
   前記検索条件調整ステップは、前記一連の変更操作における最新の変更操作に応じた調整を行う場合に、当該一連の変更操作それぞれにおいて対象評価軸とされた評価軸のうち少なくとも一部は前記調整評価軸から外して前記調整を行う
   情報処理方法。
10. 評価対象ごとに付与された複数の評価軸と評価値を管理する評価情報管理ステップと、
    前記評価軸及び評価値を指定することにより前記評価対象の検索条件を設定可能な検索条件設定手段を提示する制御を行う提示制御ステップと、
    前記検索条件を変更する変更操作の対象とされた対象評価軸についての変更前の評価値と変更後の評価値の情報を取得する変更情報取得ステップと、
    前記変更前の評価値と前記変更後の評価値の差分に応じて、全ての評価軸の評価値の合計値が所定値以上変化しないように、前記対象評価軸以外の評価軸の少なくとも一つとされた調整評価軸の評価値を変更することにより前記検索条件を調整する検索条件調整ステップと、
    前記調整された検索条件に基づいて検索処理を行い前記評価対象を抽出する検索処理ステップと、を情報処理装置が実行する情報処理方法であって、
    前記検索処理ステップでは、
    前記調整された検索条件において評価値が所定値以上とされた前記評価軸が存在する場合は、前記評価値が所定値以上とされた評価軸を検索条件評価軸として決定し、
    前記検索条件評価軸に付与されているラベル情報に基づいて前記検索処理を行う
    情報処理方法。

Images