JP6903523B2 - 情報処理装置、情報処理方法、及びプログラム - Google Patents

Description

本発明は、情報処理装置、情報処理方法、及びプログラムに関する。

従来より、食材の在庫情報を用いてレシピ情報を提案する手法（特許文献１参照）や、店舗等に設置され、特売品を食材に含む献立を顧客に提示する手法（特許文献２参照）は存在する。

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

しかしながら、特許文献１に記載された技術は、食材の在庫情報が取得されたその時点における当該在庫情報の内容に基づいたレシピ情報が提案される。このため、使用によって将来に渡って減少する食材の経時的な在庫情報が考慮された複数日間のレシピ情報を提供することはできない。
また、特許文献２に記載された技術は、特売品を食材に含む献立を顧客に提示することができるにすぎない。このため、顧客が実際に自宅で在庫として保有する食材が考慮された献立や、栄養、価格、ユーザの好み等が考慮された献立を顧客に提示することはできない。
さらに、特許文献１及び２に記載された技術は、食材を複数日に渡って効率良く使用することが考慮されていない。このため、結果的に食材が在庫として残ることがあり経済的でない。

本発明は、このような状況に鑑みてなされたものであり、献立を、ユーザが在庫として保有する食材、栄養、価格、ユーザの好み等、優先される１種類以上の要素に基づいて推薦する手法を提供すること目的とする。

上記目的を達成するため、本発明の一態様である情報処理装置は、
食材の在庫に関する情報を在庫情報として取得する在庫情報取得手段と、
前記在庫情報取得手段により取得された前記在庫情報に基づいて、作成可能な複数日間の献立を推薦する献立推薦手段と、
を備える。

また、１種類以上の要素を受付ける要素受付手段をさらに備え、
前記献立推薦手段は、前記在庫情報取得手段により取得された前記在庫情報と、前記要素受付手段により受付けられた前記１種類以上の要素とに基づいて、作成可能な複数日間の献立を推薦することができる。
また、前記献立推薦手段により推薦される前記献立の作成に必要となる食材には、前記在庫情報に含まれない食材としての在庫外食材を含むことができる。

また、指定食材の入力を受付ける指定食材受付手段をさらに備え、
前記献立推薦手段は、
前記指定食材が前記在庫情報に含まれない食材である場合には推薦すべき献立の作成にあたって前記指定食材を調達する必要がある旨を提示することができる。

また、所定の期間内に購入すれば当該所定の期間外に購入するよりも安価で購入可能な特売食材に関する情報としての特売情報を取得する特売情報取得手段をさらに備え、
前記献立推薦手段は、
特売情報に基づいて推薦すべき献立を作成することができる。

また、前記献立推薦手段により、前記在庫に含まれる食材としての在庫食材を１種類以上含む１以上の献立が推薦された場合に、当該１以上の献立の中から、ユーザにより指定された献立を指定献立として受付ける指定献立受付手段をさらに備え、
前記献立推薦手段はさらに、
推薦すべき前記指定献立の作成にあたって、在庫外食材が必要となる場合、当該在庫外食材を調達する必要がある旨を提示することができる。

また、前記要素受付手段により受付けられた前記要素が複数種類ある場合に、所定の判断基準に基づいて、前記複数種類の要素の夫々に対し重み付けを行う重付手段をさらに備え、
前記献立推薦手段はさらに、
前記在庫情報取得手段により取得された前記在庫情報と、前記重付手段により重み付けされた前記複数種類の要素の夫々とに基づいて、１以上の献立を推薦することができる。

また、ユーザにより実際に作成された献立をリアル献立として取得するリアル献立取得手段と、
前記１種類以上の要素毎に定められた所定の比較基準に基づいて、前記献立推薦手段により推薦された前記献立と前記リアル献立とを比較する比較手段と、
前記比較手段による比較結果に基づいて、前記１種類以上の要素毎の達成度を算出する達成度算出手段と、
をさらに備えることができる。

本発明の一態様の情報処理方法及びプログラムは、上述の本発明の一態様の情報処理装置に対応する処理方法及びプログラムである。

本発明によれば、献立を、ユーザが在庫として保有する食材、栄養、価格、ユーザの好み等、優先される所定の要素毎に推薦する手法を提供することができる。

本発明の情報処理装置の一実施形態であるユーザ端末を含む、情報処理システムの構成図である。 図１の情報処理システムのうち、ユーザ端末のハードウェア構成を示すブロック図である。 図２のユーザ端末の機能的構成のうち、献立推薦処理及び達成度算出処理を実現するための機能的構成の一例を示す機能ブロック図である。 複数種類の要素の夫々について重み付けの指定をユーザに行わせるための具体的手法の一例を示すレーダーチャートである。 図３のユーザ端末が実行する献立推薦処理の流れを説明するフローチャートである。 図３のユーザ端末が実行する献立推薦処理のロジックを示すイメージ図である。 図３のユーザ端末が実行する献立推薦処理の具体例を示すイメージ図である。 図３のユーザ端末が、過去のリアル献立と将来の推薦献立をユーザ端末に表示させた場合を示すイメージ図である。 図３のユーザ端末が実行する達成度算出処理の流れを説明するフローチャートである。 図３のユーザ端末により算出された要素毎の達成度を推薦する具体的手法の一例を示すグラフである。 特売情報と在庫情報から献立を推薦する具体的手法の一例を示すイメージ図である。

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

図１は、本発明の情報処理装置の一実施形態であるユーザ端末１を含む、情報処理システムの構成図である。

図１に示す情報処理システムは、ｎ人（ｎは任意の整数値）のユーザＵ１乃至Ｕｎの夫々によって操作されるユーザ端末１−１乃至１−ｎの夫々と、サーバ２とを含むように構成されている。
ユーザ端末１−１乃至１−ｎの夫々と、サーバ２とは、インターネット（Ｉｎｔｅｒｎｅｔ）等のネットワークＮを介して相互に接続されている。
なお、以下、ユーザＵ１乃至Ｕｎ、ユーザ端末１−１乃至１−ｎの夫々を区別する必要がない場合には、これらをまとめて、「ユーザＵ」、「ユーザ端末１」の夫々と呼ぶ。

ユーザ端末１は、ユーザＵが操作する情報処理装置であって、例えばスマートフォン等で構成される。ユーザ端末１ではアプリケーションプログラムが実行されることにより、例えば以下の処理が行われる。即ち、ユーザ端末１では、ユーザＵの冷蔵庫等における食材の在庫（以下、「在庫食材」と呼ぶ）に関する情報（以下「在庫情報」と呼ぶ）と、１種類以上の要素と、特売期間内に購入すれば特売期間外に購入するよりも安価で購入可能な特売食材に関する情報（以下「特売情報」と呼ぶ）とに基づいた複数日間の献立が提示される。
サーバ２は、図１に示す情報処理システムを管理するサーバであり、例えば、ユーザ端末１が実行する処理で必要となる特売情報の収集を行う。特売情報の収集処理は、ユーザ端末１で実行されても良い。また、サーバ２は、ユーザ端末１により推薦された献立（以下、「推薦献立」と呼ぶ）の実績をログデータとして管理する。推薦献立の実績は、ユーザ端末１自身も記憶しても良い。当該実績をサーバ２が管理することにより、ユーザ端末１の故障や紛失時にも対応することができる。また、推薦献立の実績を蓄積することにより、蓄積された当該実績をビッグデータとして活用することもできる。推薦献立とともに、又は、推薦献立に替えて、ユーザにより実際に作成された献立であるリアル献立を蓄積しても良い。

図２は、図１の情報処理システムのうち、ユーザ端末１のハードウェア構成を示すブロック図である。

ユーザ端末１は、ユーザＵが操作する情報処理装置であって、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、バス１４と、入推薦インターフェース１５と、表示部１６と、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０とを備えている。

ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、又は、記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入推薦インターフェース１５も接続されている。入推薦インターフェース１５には、表示部１６、入力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。

表示部１６は、液晶等のディスプレイにより構成され、各種画像を表示する。
入力部１７は、例えば表示部１６の表示面に積層される静電容量式又は抵抗膜式（感圧式）の位置入力センサにより構成され、タッチ操作がなされた位置の座標を検出する。
ここで、タッチ操作とは、入力部１７に対する物体の接触又は近接の操作をいう。入力部１７に対して接触又は近接する物体は、例えばユーザＵの指やタッチペン等である。
このように、本実施形態では、表示部１６と入力部１７とにより、タッチパネルが構成されている。

記憶部１８は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークＮを介して他の装置（例えば図１のサーバ２）との間で通信を行う。

ドライブ２０には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア３０が適宜装着される。ドライブ２０によってリムーバブルメディア３０から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。
また、リムーバブルメディア３０は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。

なお、図示はしないが、図１のサーバ２も、図２に示すハードウェア構成のうち、タッチパネルを構成する表示部１６と入力部１７とを除いた構成と基本的に同様の構成を有している。

次に、このようなハードウェア構成を持つユーザ端末１の機能的構成について、図３を参照して説明する。
図３は、図１の情報処理システムにおける図２のユーザ端末１の機能的構成のうち、献立推薦処理及び達成度算出処理を実現するための機能的構成の一例を示す機能ブロック図である。

「献立推薦処理」とは、ユーザ端末１が実行する処理のうち、ユーザＵの在庫情報と、１種類以上の要素とに基づいて複数日間の献立（レシピ）を推薦するまでの一連の処理をいう。
「献立」とは、１以上の食材で構成され、ユーザＵの食卓に並べられ得る料理の種類のことをいう。
「１種類以上の要素」とは、献立を推薦するに際し考慮すべき任意の要素のうち、在庫情報により示される要素を除くものをいう。
要素は、予め決められた固定のものであってもよいし、ユーザＵによって任意に選択されたものでもよい。要素の個数は、１以上であれば足りる。例えば「栄養バランス」という要素が選択されている場合には、在庫情報により特定される食材を少なくとも１種類以上用いて作成することができる献立のうち、特に栄養バランスが考慮された献立が、推薦対象として決定される。要素の他の例として、在庫品をなるべく使い切るために賞味期限が近いものを優先して使用するための献立が推薦対象として決定される「使い切り」や、食費をなるべく抑えるための「節約」、ユーザの嗜好になるべく沿った「好み」、特売されている食材を使用する「お買い得」などがあるが、これらに限られない。

「達成度算出処理」とは、ユーザ端末１が実行する処理のうち、実際にユーザＵが作成した献立（以下「リアル献立」と呼ぶ）に関する情報を履歴として取得してから、要素毎の達成度を算出するまでの一連の処理をいう。
「達成度」は、要素毎に予め定められた比較基準に基づいて、推薦献立とリアル献立とが比較され、その比較結果に基づいて、所定期間内の要素毎に算出される値としても良い。例えば「栄養バランス」という要素に基づいて、所定期間（例えば、１カ月間）の献立が推薦された場合には、この推薦された１カ月間の推薦献立の夫々と、当該１カ月間に作成されたリアル献立の夫々とが比較される。そして、その比較結果に基づいた達成度が算出される。即ち、推薦献立により示される栄養バランスを基準として、リアル献立により示される栄養バランスが、当該基準に対してどの程度達成されたのかを示す割合等の値が「達成度」となる。
「栄養バランス」は、各栄養素の相対的な量の関係をいい、摂取した食材や栄養素の数や量に基づいて計算しても良く、摂取した食物を「穀物」「肉類」「野菜類」などに分類し、摂取した食物の分類毎の数や量に基づいて計算しても良い。摂取カロリーを加味して栄養バランスを算出しても良い。
「達成度」の別の例として、所定期間ごとに達成すべき一定の数値を設定し、所定期間のリアル献立から算出される数値と比較しても良い。例えば「栄養バランス」であれば、各栄養素毎に、所定期間（例えば１日）に摂取すべき量（数値）を設定し、リアル献立から算出される数値と比較した結果を並列させた値の集合を「達成度」としても良く、各栄養素毎に比較した結果を加算又は平均した１つの値を「達成度」としても良い。

図３に示すように、ユーザ端末１のＣＰＵ１１（図２）においては、献立推薦処理が実行される場合には、在庫情報取得部１０１と、要素受付部１０２と、重付部１０３と、特売情報取得部１０４と、献立推薦部１０５と、指定食材受付部１０６と、指定献立受付部１０７とが機能する。
また、達成度算出処理が実行される場合には、リアル献立取得部１０８と、比較部１０９と、達成度算出部１１０とが機能する。
記憶部１８（図２）の一領域には、在庫ＤＢ４０１と、食材ＤＢ４０２と、特売ＤＢ４０３と、献立ＤＢ４０４と、リアル献立ＤＢ４０５と、要素ＤＢ４０６とが設けられている。記憶部１８は、ユーザ端末１ではなく、サーバ２に配置されても良い。

在庫情報取得部１０１は、在庫情報を取得する。在庫情報取得部１０１により取得された在庫情報は、在庫ＤＢ４０１に記憶されて管理される。これにより、ユーザ端末１は、在庫食材を漏れなく的確に管理することができる。
具体的には例えば、ユーザＵが購入、譲受、栽培等によって食材を調達して、これら食材に関する情報を入力部１７により入力した場合、在庫情報取得部１０１は、当該情報を在庫情報として取得する。より具体的には例えば、在庫情報取得部１０１は、食材の種類、価格、数量、含有栄養素、賞味・消費期限、アレルギー成分の有無等、食材に関するあらゆる情報を在庫情報として取得することができる。
なお、ユーザ端末１が在庫情報を取得する具体的な手法については、ここでは説明の便宜上、ユーザＵが入力部１８により入力する手法が採用されているが、特にこれに限定されない。例えば、図示はしないが、冷蔵庫等内の写真を撮像し、ユーザ端末１が画像処理等で当該写真に含まれる在庫食材を認識し、その認識結果に基づいて在庫情報を取得する、といった手法を採用しても良い。また例えば、ユーザ端末１は、内蔵されるカメラ（図示せず）等で、食材のパッケージ等に印字されている所定の識別子を撮像し、その撮像結果に基づいて在庫食材を認識し、その認識結果に基づいて在庫情報を取得する、といった手法を採用しても良い。

要素受付部１０２は、ユーザＵの入力部１７に対する操作により選択された１種類以上の要素を受付ける。これにより、ユーザ端末１は、ユーザＵがどのような目的に基づいて献立を作成したいのかを把握することができる。なお、要素受付部１０２により受付けられる要素は、要素ＤＢ４０６に予め記憶されて管理されている。
具体的には例えば、ユーザＵによって「使い切り」という要素とが選択された場合、要素受付部１０２はこれらの要素を受付ける。この場合の献立を推薦するためのアルゴリズムの例として、例えば、
（１）献立ＤＢに記憶された献立情報を読み出し、読み出した献立（「Ｍ」とする）に使用される食材毎の種類と量を抽出する。
（２）（１）で抽出した食材の種類と量のうち、在庫情報と合致する食材の種類（「Ｆ（ｉ）（ｉ＝１，…，ｎ）」とする）と量（「Ｑ（ｉ）」とする）を特定する。また当該食材の賞味期限までの日数（「Ｄ（ｉ）」とする）を取得する。
（３）賞味期限を加味した当該献立の食材使い切り度Ｅ（Ｍ）＝Σ_ｉＦ（ｉ）×Ｑ（ｉ）／Ｄ（ｉ）（ｉ＝１，…，ｎ）を計算する。
（４）（１）乃至（３）の処理を繰り返し、Ｅ（Ｍ）が最大となる献立Ｍ_ｍａｘ（ｊ）（ｊ＝１）を特定する。
（５）１回の食事に用意する献立の数（Ｎ）にいたるまで、（１）乃至（４）の処理を繰り返し、先の処理で特定済みの献立Ｍ_ｍａｘ（ｊ）を除き、Ｅ（Ｍ）が最大となる献立Ｍ_ｍａｘ（ｊ）（ｊ＝２，３，…Ｎ）を特定する。
としても良いが、これに限られない。例えば、（５）で（１）乃至（４）の処理を繰り返す条件として、１回の食事に用意する献立の数に替えて、または、とともに、１回の食事に用意する献立によって取得するグラム数や摂取カロリーを採用しても良い。また例えば、（１）で献立を読み出す際に、在庫情報から賞味期限までの日数が１日に満たない食材の種類と量を特定し、当該食材を含む献立を読出し、当該食材を使い切る１以上の献立を特定し、使い切った後に、前述の（１）から（５）の処理を行っても良い。また例えば、賞味期限が１日に満たない食材については、（３）の処理でＤ（ｉ）を０に近い値として、Ｅ（Ｍ）の値を極端に大きくしても良い。

また、要素の選択のされ方の別の例として、例えば、ユーザＵによって「お買い得」という要素と「使い切り」という要素とが選択された場合、要素受付部１０２はこれらの要素を受付ける。この場合の献立を推薦するためのアルゴリムの例としては、たとえば、前述の（１）に替えて、
（１’）献立ＤＢに記憶された献立情報を読み出し、特売情報を食材に含む献立（「Ｍ」）に使用される食材毎の種類と量を抽出する。
とし、その後、前述の（２）乃至（５）の処理を行うようにしても良いが、これに限られない。

また、要素の選択のされ方の別の例として、例えば、ユーザＵによって「栄養バランス」という要素と「使い切り」という要素とが選択された場合、要素受付部１０２はこれらの要素を受付ける。この場合、ユーザＵの目的は、健康に配慮しながらも経済的な献立を作成したいということになる。この場合の献立を推薦するためのアルゴリムの例としては、たとえば、前述の（１）の処理を行い、（２）〜（３）に替えて、
（２’’）（１）で抽出した食材の種類と量のうち、在庫情報と合致する食材の種類（「Ｆ（ｉ）（ｉ＝１，…，ｎ）」とする）と量（「Ｑ（ｉ）」とする）を特定する。また当該食材の賞味期限（「Ｄ（ｉ）」とする）と、当該食材の種類と量に含まれる栄養素の種類（「Ｎ（ｋ））（ｋ＝１，…，ｍ）」とする）と量（「Ｒ（ｋ）」とする）を取得する。
（３’’）賞味期限を加味した当該献立の食材使い切り度と、栄養バランス度を加味した当該食材の効用度Ｅ（Ｍ）＝ａ×Σ_ｉＦ（ｉ）×Ｑ（ｉ）／Ｄ（ｉ）（ｉ＝１，…，ｎ）＋ｂ×Σ_ｋＮ（ｋ）×Ｒ（ｋ）（ｋ＝１，…，ｍ）を計算する。ここで、ａとｂは、後述する重付部１０３が行う重み付けに基づいて決定される係数である。
の処理を行った後、前述の（４），（５）の処理を行うようにしても良いが、これに限られない。たとえば、（３’’）のａとｂを、予め定められた値にしても良い。
なお、ユーザＵが１種類以上の要素を選択する手法は特に限定されない。例えばユーザ端末１の表示部１６に表示された複数種類の要素の中から、ユーザＵが１種類以上の要素を選択できるようにしても良い。

重付部１０３は、要素受付部１０２により受付けられた要素が複数ある場合に、所定の判断基準に基づいて、複数種類の要素の夫々に対し重み付けを行う。
これにより、ユーザＵは、複数の目的に基づいた献立を作成したいと考えている場合に、複数の目的の夫々に対して優先度合を付与することができる。
具体的には、ユーザＵによって選択された要素が複数種類ある場合に、重付部１０３は、これら要素の夫々について重み付けを行う。例えば、ユーザＵによって「栄養バランス」という要素と、「使い切り」という要素という２種類の要素が選択されている場合には、これら２種類の要素のうちユーザＵが優先させたいと考える要素が、他方の要素よりも優先された内容で献立が推薦されように重み付けが行われる。
なお、複数種類の要素の夫々について重み付けを行う際、要素毎に優先度合が付与されるが、この優先度合を付与する手法は特に限定されない。例えばユーザ端末１の表示部１６に表示されている複数種類の要素の夫々について、ユーザＵが優先度合を付与する操作を入力部１７に対して行ってもよい。具体的には例えば、後述する図４に示すような複数種類の要素の夫々についての優先度合を正規化させた値がプロットされたレーダーチャートの内容を、ユーザＵが任意に設定できるようにしても良い。

また、要素受付部１０２に替えて、または、要素受付部１０２とともに、要素受付部１０３が、ユーザＵの入力部１７に対する操作により選択された１種類以上の要素を受付けても良い。たとえば、図４に示すレーダーチャートで、選択しない要素の優先度を「０」とし、選択する要素を「１」以上の値に設定しても良い。

また、要素受付部１０２と重付部１０３は、必須の構成ではない。これらがない場合は、予め決められたアルゴリズムに基づいて献立が推薦対象として決定される。たとえば、ユーザＵによって「使い切り」という要素が選択された場合と同じように、在庫品をなるべく使い切るために賞味期限が近いものを優先して使用するための献立が推薦対象として決定される。

また、予め決められたアルゴリズムの別の例としては、ユーザＵによって「お買い得」という要素と「使い切り」という要素とが選択された場合と同じように、後述する献立推薦部１０５が取得する特売情報を使用しつつ、在庫品をなるべく使い切るために賞味期限が近いものを優先して使用するための献立が推薦対象として決定される。

また、特定の１種類以上の要素を固定要素とし、それ以外の他の１種類以上の要素を変動要素とし、変動要素となっている１種類以上の要素のみに優先度合を付与することで重み付けを行う、といった手法を採用することもできる。例えば、「栄養バランス」という第１要素と、「使い切り」という第２要素と、「好み」という第３要素とのうち、第２要素を固定要素とし、第１要素及び第３要素を変動要素とすることができる。
この場合、変動要素となっている第１要素と第３要素との夫々について優先度合が設定され、その設定内容に基づいて重み付けが行われる。即ち、基本的な固定要素としての第２要素に基づいた経済的な内容の献立がユーザ端末１によって推薦されるが、変動要素としての第１要素と第３要素とに対する重み付けに変化を持たせることができる。
これにより、ユーザＵは、固定要素のみならず、自ら献立の作成に考慮させたい要素を変動要素として追加させ、さらに考慮させたい重要度に応じて重み付けを変更させることができる。例えば、上述の例では、在庫食材を使い切ることを優先させた経済的な献立でありながらも、栄養のバランスが良く、かつ、可能な限り好みの献立が、ユーザ端末１により推薦されることになる。さらに、ユーザＵは、このような変動要素を考慮した献立の推薦を受けるに際して、タッチパネル（入力部１７）に対する簡単な操作をするだけで済む。

これにより、ユーザ端末１は、献立を、ユーザＵにより選択された１種類以上の要素に基づいて推薦することが可能となる。
また、ユーザＵにより、たとえば「使い切り」など、在庫情報に関連する要素が選択された場合には、献立推薦部１０５は、在庫情報取得部１０１により取得された在庫情報と、重付部１０３により重み付けされた複数種類の要素の夫々とに基づいて、作成可能な複数日間の献立を推薦する。
これにより、ユーザ端末１は、食材を無駄にすることなく複数日間の献立を推薦することが可能となる。

特売情報取得部１０４は、特売期間内に購入すれば特売期間外に購入するよりも安価で購入可能な特売食材に関する情報としての特売情報を取得する。なお、特売情報には、割引特典が付与されたクーポンに関する情報も含まれる。特売情報取得部１０４により取得された特売情報は、特売ＤＢ４０３に記憶されて管理される。
これにより、ユーザ端末１により推薦される献立には、特売食材を含めることができる。このため、ユーザＵに対し経済的なメリットを享受させることが可能となる。
具体的には、特売情報取得部１０４は、サーバ２により取得され管理されている特売情報を所定のタイミングで取得する。例えば、ユーザＵが来店可能なスーパーマーケットの広告に記載された特売情報がサーバ２によって管理されている場合、ユーザ端末１が当該特売情報を毎日取得するようにしても良い。なお、ここでいう「広告」には、新聞の折り込みチラシや、ホームページの記載等が含まれる。
また、特売情報を取得する具体的な手法については特に限定されない。例えばユーザＵが、ユーザ端末１を操作することにより、インターネット上のＷｅｂサイトに掲載された特売情報をダウンロードできるようにしても良い。また、ユーザ端末１は、内蔵されるカメラ（図示せず）等で新聞の折り込みチラシ等を撮像し、その撮像結果に基づいて特売情報を自動認識する、といった手法を採用しても良い。あるいは、インターネット上のＷｅｂサービスからＡＰＩ接続によって特売情報をサーバ２に一旦格納し、特売情報取得部１０４が取得しても良い。インターネット上のＷｅｂサービスからＡＰＩ接続によって特売情報を特売情報取得部１０４が直接取得しても良い。ユーザ端末１上で稼働する特売情報を取得・管理するアプリケーションから特売情報取得部１０４が特売情報を取得しても良い。

また、献立推薦部１０５は、在庫食材に含まれていない食材（以下「在庫外食材」と呼ぶ）を１以上含む献立を推薦することができる。
具体的には例えば、在庫食材に大根が含まれていない場合には、大根は在庫外食材となる。このとき、献立推薦部１０５は、在庫外食材としての大根を追加することで、在庫食材と組み合わせて作成可能な複数日間の献立を推薦することもできる。また、設定された要素に基づいて推薦すべき献立に大根が食材として必要にもかかわらず、大根が在庫食材に無かった場合、在庫外食材としての大根を調達すべき旨を提案することもできる。

また、献立推薦部１０５は、特売情報に基づいて、特売情報に係る特売食材を材料に含む推薦献立を作成する。
具体的には例えば、特売情報取得部１０４により取得された特売情報に、ユーザＵの行きつけのスーパーマーケットで販売されている大根の価格が、本日限り１本５０円であるという情報が含まれている場合を想定する。このとき、献立推薦部１０５は、当該特売情報をユーザ端末１に表示するとともに、大根を材料に含む推薦献立を表示する。
この場合、献立の推薦は、大根を材料に含むことを必須とする以外は、要素受付部１０２により受付けられた要素に基づいて行っても良いし、大根を材料に含むことを必須とするのみで、要素受付部１０２により受付けられた要素に基づかずに行っても良い。
また、当該表示した推薦献立の指定を、後述する指定献立受付部１０７がユーザＵから受け付けたとき、在庫情報に基づき推薦された当該日、または、当該日および当該日以降の献立を、ユーザＵが指定した推薦献立に変更するようにしても良い。

指定食材受付部１０６は、ユーザＵが指定する食材（以下「指定食材」と呼ぶ）を受付ける。すると、献立推薦部１０５は、当該指定食材を材料に含む推薦献立をユーザ端末１に表示する。
この場合も、献立の推薦は、指定食材を材料に含むことを必須とする以外は、要素受付部１０２により受付けられた要素に基づいて行っても良いし、指定食材を材料に含むことを必須とするのみで、要素受付部１０２により受付けられた要素に基づかずに行っても良い。また、当該表示した推薦献立の指定を、後述する指定献立受付部１０７がユーザＵから受け付けたとき、在庫情報に基づき推薦された当該日、または、当該日および当該日以降の献立を、ユーザＵが指定した推薦献立に変更するようにしても良い。
これにより、ユーザＵは、所望の食材を使用した献立を作成したいと考えた場合、ユーザ端末１を操作することにより、当該食材を指定することができる。
このとき、ユーザＵによって指定された食材が在庫食材である場合には、献立推薦部１０５は、当該在庫食材を使用して作成可能な献立を推薦する。

これに対して、ユーザＵにより指定された食材が在庫外食材である場合には、献立推薦部１０５は、推薦すべき献立を作成するためには、当該在庫外食材を調達する必要がある旨を提示する。
具体的には例えば、ユーザＵが、今夜は牛肉を食べたいと考えた場合、ユーザ端末１を操作することにより、食材ＤＢ４０２に記憶された１種類以上の食材の中から所望の食材として「牛肉」を指定する。
このとき、牛肉が在庫食材である場合には、献立推薦部１０５は、牛肉を使用して作成可能な推薦献立をユーザ端末１に表示する。
これに対して、牛肉が在庫外食材である場合には、指定食材受付部１０６は、牛肉が在庫外食材である旨を献立推薦部１０５に通知し、献立推薦部１０５は、牛肉を使用して作成可能な推薦献立とともに、推薦すべき献立を作成するためには牛肉を調達する必要がある旨をユーザ端末１に表示する。

指定献立受付部１０７は、献立推薦部１０５により、在庫食材を１種類以上含む複数の献立が推薦された場合に、当該複数の献立の中から、ユーザＵにより指定された献立（以下「指定献立」と呼ぶ）を受付ける。また、献立推薦部１０５は、推薦すべき指定献立を指定食材受付部１０６に通知し、指定食材受付部１０６は、必要となる食材を献立ＤＢから特定して、当該食材を指定食材受付部１０６に通知する。指定食材受付部１０６は、当該食材が在庫食材か在庫外食材かを献立推薦部１０５に通知する。当該食材が在庫外食材である場合、献立推薦部１０５は、当該在庫外食材を調達する必要がある旨をユーザ端末１に表示する。
これにより、ユーザＵは、ユーザ端末１により推薦された複数種類の献立の中から、所望の献立を作成したいと考えた場合、ユーザ端末１を操作することにより、当該献立を指定することができる。
指定献立受付部１０７は、例えば、ユーザＵが献立名をユーザ端末１から直接入力するなど、ユーザの操作に基づいて指定献立を献立推薦部１０５から受付けても良い。
具体的には例えば、ユーザＵは、今夜は「すき焼き」を食べたいと考えた場合には、献立名として「すき焼き」を入力するなど、ユーザ端末１を操作することにより、献立ＤＢ４０４に記憶された１種類以上の献立の中から、所望の献立として「すき焼き」を指定する。すると、指定献立受付部１０７は、ユーザＵにより指定された「すき焼き」を指定献立として受付ける。
このとき、献立ＤＢ４０４から、「すき焼き」を作成するために必要となる食材として、「牛肉」を特定し、が在庫外食材に該当する場合には、献立推薦部１０５は、「すき焼き」を作成するためには牛肉を調達する必要がある旨を献立推薦部１０５に通知し、その旨をユーザ端末１に表示する。

リアル献立取得部１０８は、ユーザＵにより実際に作成された献立（即ちリアル献立）を取得する。
具体的には、ユーザＵは、自身が実際に作成した献立の内容を、ユーザ端末１の入力部１７を操作することにより入力する。入力部１７に入力された内容は、リアル献立としてリアル献立取得部１０８によって取得される。
これにより、ユーザ端末１は、献立推薦部１０５により推薦された複数日間の推薦献立と、同期間に作成されたリアル献立とを比較するための情報を取得することができる。
なお、ユーザＵが、リアル献立を、ユーザ端末１の入力部１７を操作することにより入力する手法は特に限定されない。例えば、ユーザＵが手入力によってリアル献立の内容を入力しても良い。また、ユーザ端末１が、内蔵されるカメラ等（図示せず）を用いて日々のリアル献立を撮像し、当該撮像画像基づいてリアル献立の具体的内容を自動認識させる、といった手法を採用しても良い。また、献立推薦部１０５が表示した推薦献立の中からユーザＵが選択したものを、献立推薦部１０５がリアル献立としてリアル献立取得部１０８に通知しても良い。

比較部１０９は、１種類以上の要素毎に定められた所定の比較基準に基づいて、推薦献立とリアル献立とを比較する。
具体的には例えば、「栄養バランス」という要素における比較基準は、献立を構成する１以上の食材毎に含有される栄養素の種類及び量とすることができる。この場合、推薦献立とリアル献立との夫々を構成する１以上の食材毎に、含有される栄養素の種類及び量を比較できるようにしても良い。
また例えば、「使い切り」という要素における比較基準は、所定の期間内に使い切ることができなかった食材の種類及び量とすることができる。この場合、推薦献立とリアル献立との夫々を構成する１以上の食材毎に、所定の期間内に使い切ることができなかった食材の種類及び量を比較できるようにしても良い。
比較部１０９は、所定期間ごとに達成すべき一定の数値と、所定期間のリアル献立から算出される数値とを比較しても良い。

達成度算出部１１０は、比較部１０９による比較結果に基づいて、１種類以上の要素毎の達成度を算出する。
具体的な例として、リアル献立の食材に含有される栄養素の種類及び量が、推薦献立の食材に含有される栄養素の種類及び／又は量、あるいは、所定期間ごとに達成すべき一定の種類及び／又は量よりも大幅に少なかった場合を想定する。この場合、「栄養バランス」という要素の比較結果に基づいて算出されたリアル献立の達成度は、１種類以上の要素毎に正規化処理を行うことにより、例えば推薦献立「１００」に対する達成度が「４０」であったといった値とすることが可能となる。あるいは、達成度を、各栄養素毎の比較結果を並列させた値の集合として、（脂質，ビタミン・ミネラル，糖質）＝（８０，４０，１００）などとしても良い。
このように、要素毎に予め定められた比較基準に基づいて、推薦献立に対するリアル献立の達成度を算出することにより、ユーザＵは、自身の過去の実績を容易に確認することができる。
これにより、ユーザＵは、反省すべき点は反省し、良かった点は今後も維持することとして、要素毎の達成度を将来の献立の決定に生かすことができる。

また、要素毎に数値で算出された達成度は、後述する図１０に示すようなグラフで表示させることができる。これにより、ユーザＵは、複数種類の要素毎の達成度を一見して把握することができるため、何の要素について課題があるのかを容易に認識することが可能となる。
なお、本実施形態における達成度は、数値及びグラフで表示する手法を採用しているが、この手法に限定されない。例えば、数値ではなく達成度をイメージで認識できるような絵やキャラクターであってもよいし、色彩の違いによって達成度を示しても良い。

次に、図４を参照して、複数種類の要素の夫々についての重み付けをユーザＵに行わせるための具体的手法を説明する。
図４は、複数種類の要素の夫々について重み付けの指定をユーザＵに行わせるための具体的手法の一例を示すレーダーチャートである。

図４に示す要素Ｐ１乃至Ｐ５は、いずれもユーザ端末１がユーザＵに献立を推薦するために必要となる要素である。具体的には例えば、「栄養バランス」という要素Ｐ１、「使い切り」という要素Ｐ２、「好み」という要素Ｐ３、「お買い得」という要素Ｐ４、「予算」という要素Ｐ５とすることができる。
図４のレーダーチャートにプロットされている値は、複数種類の要素の優先度（即ち重み付けの度合）を正規化して表示した値である。図４のレーダーチャートにプロットされている値のうち、「１」の優先度が一番低く、「５」の優先度が一番高い。また、要素Ｐ１乃至Ｐ５の夫々の優先度合を示す値は実線で結ばれている。なお、各要素の重み付け度合を示す値のデフォルト値は破線で示された「３」である。
このように複数種類の要素の夫々について、重み付け度合を示す数値を放射線状に配置させることにより、複数種類の要素の夫々の重み付け度合を一見して比較することができる。なお、重み付け度合を示す数値を放射線状に配置させる手法は特に限定されないが、ユーザ端末１の表示部１６に図４に示すようなレーダーチャートを表示させ、ユーザＵが当該レーダーチャート上の数値を任意に設定できるようにしても良い。この場合、ユーザＵにより入力された数値（重み付け度合を示す数値）に基づいて、重付部１０３が複数種類の要素の夫々に対し重み付けを行うこととなる。

図４の例では、要素Ｐ１の重み付け度合を示す値は「３」であり、要素Ｐ２の重み付け度合を示す値は「４」であり、要素Ｐ３の重み付け度合を示す値は「５」であり、要素Ｐ４の重み付け度合を示す値は「２」であり、要素Ｐ５の重み付け度合を示す値は「１」であることが示されている。ユーザ端末１は、この重み付けの度合に基づいて献立をユーザＵに推薦することとなる。
レーダーチャートの設定の仕方の例として、例えば、各要素の値の総和が等しくなるようにレーダーチャートの形をユーザＵが変更できるようにしても良い。変更の前後で各要素の値の総和が等しく、かつ、ユーザＵが指示した要素と他の要素のレーダーチャートでの位置関係に基づいて、ユーザＵが指示した要素の値の変更に応じて、他の要素の値を変更しても良い。例えば、レーダーチャート上で、すべての要素の値が「３」として表示された状態で、第１要素（Ｐ１）の値を２単位増やす指示をユーザＵから受け付けたら、自動的に第１要素に隣接する第２要素（Ｐ２）と第５要素（Ｐ５）を１単位ずつ減らし、第３要素と第４要素の値を変えないようにレーダーチャートの形を変形しても良い。また、第１要素（Ｐ１）の値を６増やす指示をユーザＵから受け付けたら、自動的に第１要素に隣接する第２要素（Ｐ２）と第５要素（Ｐ５）を２単位ずつ減らし、第３要素と第４要素の値を１単位ずつ減らすようにレーダーチャートの形を変形しても良い。そして、第１要素（Ｐ１）の値を各要素の値の総和まで増やす指示をユーザＵから受け付けたら、第２要素ないし第５要素の値を０にしても良い。または、ビンチアウトの操作を受け付けたら、すべての要素の値を増やすようにしても良い。このようなレーダーチャートの変更の仕方によって、ユーザがすべての要素を逐一指定しなければならない煩わしさを回避することができ、また、ユーザの操作にしたがった、レーダーチャートのスムーズな変形が可能となる。

次に、図５を参照して、図３の機能的構成を有するユーザ端末１が実行する献立推薦処理について説明する。
図５は、図３のユーザ端末１が実行する複数日間の献立推薦処理の流れを説明するフローチャートである。

図５に示すように、ユーザ端末１では、次のような一連の処理が実行される。
ステップＳ１において、在庫情報取得部１０１は、在庫食材に関する情報を在庫情報として取得する。在庫情報取得部１０１により取得された在庫情報は、在庫ＤＢ４０１に記憶されて管理される。
ステップＳ２において、要素受付部１０２は、ユーザＵにより選択された１種類以上の要素を受付ける。

ステップＳ３において、重付部１０３は、要素受付部１０２により受付けられた要素が複数種類存在するか否かを判定する。
要素受付部１０２により受付けられた要素が複数種類存在する場合には、ステップＳ３においてＹＥＳであると判定されて、処理はステップＳ４に進む。一方、要素受付部１０２により受付けられた要素が１つである場合には、ステップＳ３においてＮＯであると判定されて、処理はステップＳ４をスキップしてステップＳ５に進む。

ステップＳ４において、重付部１０３は、所定の判断基準に基づいて、複数種類の要素の夫々に対し重み付けを行う。
ステップＳ５において、特売情報取得部１０４は、特売情報を取得する。
ステップＳ６において、献立推薦部１０５は、在庫ＤＢ４０１に記憶されている在庫情報と、特売ＤＢ４０３に記憶されている特売情報と、献立ＤＢ４０４に記憶されている献立に必要となる食材と、要素受付部１０２により受付けられた１種類以上の要素とに基づいて、作成可能な複数日間の献立を推薦する。要素受付部１０２により受付けられた要素に、たとえば「使い切り」など、在庫情報に関連する要素が存在しない場合、献立推薦部１０５は、特売ＤＢ４０３に記憶されている特売情報と、献立ＤＢ４０４に記憶されている献立に必要となる食材と、要素受付部１０２により受付けられた１種類以上の要素とに基づいて、作成可能な複数日間の献立を推薦しても良い。これにより献立推薦処理は終了となる。
以上のような一連の処理がユーザ端末１によって実行されることにより、複数日間の献立が１種類以上の要素に基づいて推薦される。

次に、図６を参照して、ユーザ端末１が実行する複数日間の献立推薦処理のロジックについて説明する。
図６は、要素受付部１０２により受付けられた要素に、在庫情報に関連する要素が存在する場合に、図３のユーザ端末１が実行する献立推薦処理のロジックを示すイメージ図である。

図６に示すように、食材Ｖの在庫量は、横軸を経時的要素としての賞味期限、縦軸を食材Ｖの調達量（在庫量）とする多角形Ｙで示される。食材Ｖの在庫量は、追加調達しない限り日々の消費によって次第に少なくなり、最終的に無くなることとなる。例えば日付Ｄ１の時点で調達された食材Ｖは、推薦献立Ａと推薦献立Ｂを作成する際に使用され、日付Ｄ３の時点で在庫ゼロの状態となる。このため、日付Ｄ３の時点で献立Ｃに食材Ｖを使用することはできない。
このように、ユーザ端末１は、少なくとも在庫食材の量と食材毎に異なる賞味期限とを考慮しながら、ユーザＵに対し好適となる献立の推薦を行う。在庫ＤＢ４０１に在庫情報として記憶されている食材毎に、図６に示すような、在庫量と推奨献立に基づく在庫量の変化（予定）を示す図をユーザ端末１に表示しても良い。在庫量の変化は、後述するリアル献立取得部１０８に通知されたリアル献立と、リアル献立を作った時点前後に撮像した冷蔵庫等内の写真に基づいてユーザ端末１が画像処理等により認識した当該写真に含まれる在庫食材の変化とを用いて学習し、予測しても良い。

次に、図７を参照して、ユーザ端末１が実行する献立推薦処理の具体例について説明する。
図７は、ユーザ端末１が実行する献立推薦処理の具体例を示すイメージ図である。なお、図７では、説明を簡略化させるために、ユーザ端末１により推薦される献立を夕食のみとし、推薦される献立の種類も１品又は２品としている。

図７では、横軸は時間、複数の縦軸は連続する日付Ｄ１乃至Ｄ６（例えば７月１日乃至７月６日）、Ｙ１は在庫食材、Ｙ２は月予算、またＹ２ａは、月予算の日割額と次回の買出日Ｂ２（日付Ｄ４）までの日数（３日間）との積で求められる予算額（以下「デフォルト予算」と呼ぶ）を示している。なお、日付Ｄ４を当日とする。
具体的には、日付Ｄ１は、ユーザＵによる食材の買出しが行われる買出日Ｂ１に該当したものとする。そして、ユーザＵによる食材の買出しと、当該買出しによりユーザＵが調達した食材に関する情報のユーザ端末１への入力とが行われると、ユーザ端末１の在庫情報取得部１０１により在庫食材に関する在庫情報が取得される。即ち、日付Ｄ１（買出日Ｂ１）時点の在庫食材Ｙ１は、在庫情報として在庫ＤＢ４０１に記憶される。具体的には、「しらたき」、「人参」、「キャベツ」、「ジャガイモ」、及び「豚バラ肉」の合計５種類の食材の夫々についての在庫情報が在庫ＤＢ４０１に記憶される。買出しによりユーザＵが調達した食材に関する情報は、ユーザＵがユーザ端末１に直接入力しても良く、買出した食材を冷蔵庫に保管する前後に撮像した冷蔵庫等内の写真に基づいて、ユーザ端末１が画像処理等で当該写真に含まれる在庫食材の変化を認識し、その認識結果に基づいて取得しても良い。

なお、図７に示すように、日付Ｄ１の時点において、これら５種類の食材の夫々の在庫量は、多角形Ｙ１ａ乃至Ｙ１ｅで示されており、日々の使用によって最終的に無くなることとなる。例えば「しらたき」の在庫量を示す多角形Ｙ１ａは、日付Ｄ１では使用されなかったが、日付Ｄ２で使用されたために日付Ｄ３の時点では在庫が無い状態となっている。
また、日付Ｄ１時点における月予算Ｙ２の残額（以下「残予算額」と呼ぶ）は、同日の買出し後の金額、即ち、月予算Ｙ２からデフォルト予算Ｙ２ａを減じた額（Ｙ２−Ｙ２ａ）となる。残予算額は、実際に買出しに要した金額Ｙ２ａ’（図示なし）を、ユーザＵがユーザ端末１から入力し、（Ｙ２−Ｙ２ａ’）としても良い。あるいは、残予算額は、ユーザ端末１上の家計簿管理アプリケーションなどが管理する実際に買出しに要した金額Ｙ２ａ’’（図示なし）を取得して、（Ｙ２−Ｙ２ａ’’）としても良い。

ユーザ端末１の要素受付部１０２は、ユーザＵにより選択された１種類以上の要素を受付ける。図７の例では、「使い切り」という要素がユーザＵによって選択された場合を想定して説明する。
要素受付部１０２によって「使い切り」という要素が受付けられると、献立推薦部１０５は以下の処理を実行する。即ち、在庫情報取得部１０１により取得された、しらたき、人参、玉ネギ、ジャガイモ、及び豚バラ肉についての在庫情報と、要素受付部１０２により受付けられた「使い切り」という要素とに基づいて、作成可能な複数日間の献立をユーザＵに推薦する。
具体的には、ユーザＵの月予算Ｙ２の範囲内で、賞味期限が最も短い食材、又は残価が最も高い食材を使い切ることを優先させた複数日間の献立が推薦される。
図７の例では、日付Ｄ１の夕飯については、人参、玉ネギ、ジャガイモ、及び豚バラ肉を使用した「カレー」が推薦される。
日付Ｄ２の夕飯については、しらたき、人参、玉ネギ、ジャガイモ、及び豚バラ肉を使用した「肉じゃが」が推薦される。なお、日付Ｄ２の夕飯の時点で、しらたき、ジャガイモ、豚バラ肉を使い切ることになる。
日付Ｄ３の夕飯については、人参と玉ネギを使用した「野菜炒め」が推薦される。その後、日付Ｄ３の夕飯の時点で、玉ネギを使い切ることになる。
日付Ｄ４の夕飯については、唯一在庫として残っている人参を使用した「人参スープ」が献立として推薦される。
日付Ｄ５の夕飯については、在庫食材が無いため、日付Ｄ１で作成したカレーの冷凍ストックである「カレー（解凍）」が献立として推薦される。
以上が、日付Ｄ１（買出日Ｂ１）の時点の在庫情報に基づいて推薦された献立となる。
そして、過去である日付Ｄ１、日付Ｄ２、日付Ｄ３において、ユーザＵが、献立推薦部１０５が表示した推薦献立の中から実際に夕食として作ったものを選択すると、献立推薦部１０５がリアル献立としてリアル献立取得部１０８に通知するとともに、献立ＤＢ４０４からリアル献立で使われる食材を取得して、当該食材に係る在庫情報の在庫量から減じて、在庫情報を更新しても良い。在庫情報の更新は、夕食を作った時点前後に撮像した冷蔵庫等内の写真に基づいて、ユーザ端末１が画像処理等で当該写真に含まれる在庫食材の変化を認識し、その認識結果に基づいて行っても良い。

また、日付Ｄ４当日において、ユーザＵが、ユーザ端末１により日付Ｄ４の夕飯の献立として推薦されている「人参スープ」以外の献立である「人参ソテー」と「ビーフハンバーグ」とを作成したいと考えたとする。つまり、ユーザＵが、当初推薦された献立ではなく、他の献立に変更したいと考えたとする。このような場合、ユーザＵは、ユーザ端末１を操作することにより、献立の変更をすることができる。
この操作によって、指定献立受付部１０７が、献立推薦部１０５から「人参ソテー」と「ビーフハンバーグ」とを指定献立として受付ける。このとき、指定献立受付部１０７が、献立ＤＢ４０４から「人参ソテー」と「ビーフハンバーグ」を作成するために必要となる食材である「人参」と「牛ひき肉」を特定し、指定食材受付部１０６に通知する。指定食材受付部１０６は、在庫ＤＢ４０１を検索し、「人参」は在庫食材、「牛ひき肉」は在庫外食材と判定し、献立推薦部１０５に通知する。献立推薦部１０５は、「ビーフハンバーグ」を作成するためには牛ひき肉を調達する必要がある旨を提示する。
ここで、ユーザＵが実際に在庫外食材である「牛ひき肉」を購入すると、「牛ひき肉」の在庫量は多角形Ｙ１ｇで示されることとなる。「牛ひき肉」の購入に伴う在庫ＤＢ４０１へ「牛ひき肉」の在庫情報としての登録は、ユーザＵがユーザ端末１から入力しても良いし、購入時点前後に撮像した冷蔵庫等内の写真に基づいて、ユーザ端末１が画像処理等で当該写真に含まれる在庫食材の変化を認識し、その認識結果に基づいて行っても良い。

また、「本日（ｔｏｄａｙ）」である日付Ｄ４の時点で、「本日限り」で「うなぎ」が大安売りされることが新聞の折込みチラシに掲載されたとする。この場合、特売情報取得部１０４は、当該情報を特売情報として取得する。特売情報は、インターネット上のＷｅｂサービスからＡＰＩ接続によって特売情報をサーバ２に一旦格納し、特売情報取得部１０４が取得しても良い。インターネット上のＷｅｂサービスからＡＰＩ接続によって特売情報を特売情報取得部１０４が直接取得しても良い。ユーザ端末１上で稼働する特売情報を管理するアプリケーションから特売情報取得部１０４が特売情報を取得しても良い。
すると、献立推薦部１０５は、当該特売情報に基づいて、日付Ｄ４限定で大安売りされる「うなぎ」を調達することができる旨を表示し、「うなぎ」の購入の有無を確認することができる。
なお、特売情報に基づいた食材（図７の例では「うなぎ」）を提示する手法、及び特売食材の購入の有無を確認する手法は特に限定されない。例えば後述する図８に示すように、ユーザ端末１の表示領域Ｈ２に特売情報を表示させることにより、特売食材を購入することができる旨を提示し、かつ、購入の有無を確認する手法を採用しても良い。図１１に示すように、ユーザ端末１の表示領域Ｈ６に特売情報を表示させることにより、特売食材を購入することができる旨を提示し、かつ、購入の有無を確認する手法を採用しても良い。
献立推薦部１０５による、「うなぎ」を購入することができる旨の提示に対し、ユーザＵが所定の手法を用いて購入の承諾を行うと、献立推薦部１０５によって日付Ｄ５の夕飯として推薦される献立が、当初推薦された「カレー（解凍）」から「ウナギの蒲焼」に変更される。あるいは、予め購入希望の食材（図７の例では「うなぎ」）の指定を受け付けておき、購入希望の食材を含む特売情報を取得したら、購入の承諾を経ずに、当初推薦された献立（図７の例では「カレー（解凍）」）から特売情報に含まれる食材を使用した献立（図７の例では「ウナギの蒲焼」）に変更しても良い。
ここで、ユーザＵが実際に特売食材である「うなぎ」を購入すると、「うなぎ」の在庫量は多角形Ｙ１ｆで示されることとなる。「うなぎ」の購入に伴う在庫ＤＢ４０１へ「うなぎ」の在庫情報としての登録は、ユーザＵがユーザ端末１から入力しても良いし、購入時点前後に撮像した冷蔵庫等内の写真に基づいて、ユーザ端末１が画像処理等で当該写真に含まれる在庫食材の変化を認識し、その認識結果に基づいて行っても良い。

このように、日付Ｄ４の献立が「人参スープ」から「ビーフハンバーグ」と「人参ソテー」とに変更され、また、日付Ｄ５の献立が「カレー（解凍）」から「ウナギの蒲焼」に変更されると、献立推薦部１０５による予算変更が行われる。
つまり、献立の変更に伴い買出日Ｂ２（日付Ｄ４）における予算に変更が生じることとなる。具体的には、図７に示すように、買出日Ｂ２（日付Ｄ４）におけるデフォルト予算Ｙ２ｂに、献立変更に伴う追加の予算Ｙ２Ｃがプラス計上されることとなる。
このため、日付Ｄ４の時点における残予算額は、Ｙ２−（Ｙ２ａ＋Ｙ２ｂ＋Ｙ２ｃ）で求められるが、この残予算額が、予め定められた月予算Ｙ２の最低額（以下「最低月予算」と呼ぶ）の日割額と、月の残日数との積から、在庫食材を金額換算した額（以下「在庫残価」と呼ぶ）を引いた額よりも少なくなった場合には、所定の手法を用いた警告がユーザＵに発せられる。即ち、次式（１）が成り立つ場合には、食材を購入するための予算が残り僅かであるとして、その旨の警告がユーザＵに発せられる。
残予算額＜最低月予算／月日数×残日数−在庫残価 ・・・（１）

次に、ユーザ端末１が複数日間の献立を推薦するための具体的手法について説明する。
図８は、図３のユーザ端末１が過去のリアル献立と将来の推薦献立をユーザ端末１に表示させた場合のイメージ図である。なお、説明を簡略化させるため、ユーザ端末１により推薦される献立を夕食のみとし、推薦される献立の種類も１品としている。

図８に示すように、ユーザ端末１の表示領域Ｈ１には、月間カレンダーが表示され、各日付の欄には、リアル献立と、ユーザ端末１により推薦された複数日間の夕飯の献立とが、文字ボタンＭ又は図形ボタンＣで表示されている。また、カレンダー上に「ｔｏｄａｙ」と表示された２０１７年１月１２日が、ユーザＵがユーザ端末１を閲覧している当日となる。
即ち、当日である２０１７年１月１２日より前の日付の欄に表示された献立はリアル献立となり、２０１７年１月１２日より後の日付の欄に表示された献立はユーザ端末１により推薦された複数日間の献立となる。
このように、ユーザ端末１に表示されるカレンダーには、ユーザＵの過去の実績に基づいたリアル献立と、ユーザ端末１により推薦された複数日間の将来の献立とを同時に表示させることができる。このため、ユーザＵは、過去と将来についての献立を一見して把握することができる。

具体的には例えば、リアル献立が表示されている日付の欄のうち、２０１７年１月１日のリアル献立は「おせち」である。ここで、「おせち」と表示された文字ボタンＭがユーザＵによって押下されると、「おせち」の作成に実際に使用された食材や、「おせち」の撮像画像、「おせち」に対するユーザＵの家族からの評価やコメント等の情報が表示される。

また、２０１７年１月２日のリアル献立はカップラーメンである。このように、ユーザＵが一見して献立の内容を把握できるような献立については、文字ボタンＭでなく図形ボタンＣを表示させることもできる。
また、青果、精肉、鮮魚等の生鮮食料品のみならず、カップラーメンや缶詰等の保存食料品も在庫情報に含めることができる。

また、推薦献立が表示されている日付の欄のうち、２０１７年１月１４日の献立は「焼肉」である。ここで、「焼肉」と表示された文字ボタンＭがユーザＵによって押下されると、「焼肉」の作成に必要となる食材や「焼肉」の作成方法が記載されたレシピ等の情報が表示される。
これにより、ユーザＵは、推薦された献立（焼肉）を作成するための情報を容易に入手することができる。ユーザＵが、ユーザ端末１から、推薦献立が表示されている日付の欄を押下して、当該日付の詳細画面（図示なし）を表示させて、献立を「焼肉」から別の献立に変更しても良い。この操作によって、指定献立受付部１０７が、献立推薦部１０５から指定献立を受付ける。

また、２０１７年１月１８日の夕飯として推薦された献立はカップラーメンである。ここで、カップラーメンを示す図形ボタンＣがユーザＵによって押下されると、カップラーメンの銘柄毎の在庫量等の情報を表示させることもできる。これによりユーザＵは、推薦された献立（カップラーメン）の在庫量を容易に把握することができる。

また、２０１７年１月５日の欄に表示された５００円硬貨を表す図形は、表示されている日付が買出日Ｂであることを示している。これにより、ユーザＵは、自身が食材の買出しを行った日と、買出しに行くべき日とを一見して把握することができる。なお、１カ月のうちで将来の買出日Ｂをいつにするかについては、ユーザ端末１が、在庫情報と月予算Ｙ２とに基づいて提案しても良いし、ユーザＵが自身のスケジュールに合わせて指定しても良い。また、ユーザ端末１により提案された買出日Ｂを、ユーザＵが自身のスケジュールに合わせて修正しても良い。買出日Ｂの修正は、５００円硬貨を表す図形をドラッグして修正後の日付に対応する位置に移動しても良いし、修正したい買出日Ｂに対応した日付の欄を押下して、当該日付の詳細画面を表示し、「買出日」イベントの日付を変更しても良い。

また、上述したように、推薦献立は、ユーザＵの希望に応じて別の献立に変更することができる。また、献立ではなく「外食」に変更することもできる。また、ユーザＵが予め特定の日を外食の日として指定することもできる。
このように、ユーザＵによって外食の日として指定された日については、カレンダー上の日付の欄に外食を示す文字ボタンＧを表示させることもできる。例えば、図８の例では、２０１７年１月８日が外食した日であり、２０１７年１月２２日と２０１７年１月２８日とが外食予定日として指定された日である。ここで、ユーザＵによって文字ボタンＧが押下されると、ユーザＵが実際に訪れた、あるいはこれから行くことを予定している具体的なレストランの店舗名やジャンル（例えば和食、洋食、中華等）等の情報を表示させることができる。これから行くことを予定している具体的な店舗名やジャンルは、設定された要素や、実際に訪れた店舗に基づいて推薦しても良い。

また、ユーザ端末１の表示領域Ｈ２には、ユーザＵがユーザ端末１を閲覧している日における在庫情報等の情報が、表示項目毎に表示される。
具体的には、在庫情報を示す表示項目である「食材ストック」と、ユーザＵがユーザ端末１を閲覧している日が買出日Ｂに該当する場合はその情報を示す表示項目である「今日の買出」と、月予算Ｙ２の残予算額を示す表示項目である「食費算」と、特売情報を示す表示項目である「特売・クーポン」と、ユーザＵがユーザ端末１を閲覧している日の献立に関する情報を示す表示項目である「今日の献立」とが表示される。

図８の例では、表示領域Ｈ２に表示される表示項目のうち「食材ストック」には、人参を示す図形及び「×２」という文字と、豚ロース肉を示す図形及び「２００ｇ」という文字と、「Ｍｏｒｅ．．．」という文字で表された文字ボタンＳとが表示されている。
これにより、ユーザＵは、在庫食材として、少なくとも「人参」を２本、「豚ロース肉」を２００ｇ保有していることを把握することができる。また、ユーザＵは、「Ｍｏｒｅ．．．」という文字で表された文字ボタンＳを押下することにより、「人参」と「豚ロース肉」以外の在庫食材の量を表示させることができる。

表示領域Ｈ２に表示される表示項目のうち「今日の買出」には、「￥５００」という金額と、鮮魚のアジを示す図形及び「×２」という文字と、青果のキャベツを示す図形及び「×１／２」という文字とが表示されている。
これにより、ユーザＵは、本日の買出しにおける予算が「￥５００」であり、かつ、本日購入すべき食材が、「アジ」を２尾、「キャベツ」を１／２個であることを把握することができる。

表示領域Ｈ２に表示される表示項目のうち「食費残」には、「￥９，５００」という金額と、「予算実績グラフを見る」という文字で表された文字ボタンＴとが表示されている。
これにより、ユーザＵは、月予算Ｙ２の残予算額が「￥９，５００」であることを把握することができる。また、ユーザＵは、「予算実績グラフを見る」という文字で表された文字ボタンＴを押下することにより、図示はしないが、月予算Ｙ２に対する購入実績を表示させることができる。

表示領域Ｈ２に表示される表示項目のうち「特売・クーポン」には、うなぎの蒲焼を示す図形及び「￥１，０００」という金額と、「購入・取得」という文字からなるボタンＫとが表示されている。
これにより、ユーザＵは、特売情報として「うなぎの蒲焼」が１パックあたり「￥１，０００」であることを把握することができる。また、ユーザＵは、「購入・取得」という文字からなるボタンＫを押下することにより、本日又は翌日以降の献立が「うなぎの蒲焼」に変更される。なお、上述したように、推薦献立が変更されると、残予算額にも変更が生じることとなる。

表示領域Ｈ２に表示される表示項目のうち「今日の献立」には、「人参スープ」の文字と、「変更」という文字からなる文字ボタンＬとが表示されている。
これにより、ユーザＵは、本日の献立が「人参スープ」であることを把握することができる。また、ユーザＵは、「変更」という文字からなる文字ボタンＬを押下することにより、本日の献立を「人参スープ」から別の献立に変更することもできる。
ユーザ端末１は、以上のような具体的手法を用いて、複数日間の献立を表示する。これにより、ユーザＵは、複数日間の献立を確認することができる。

次に、図９を参照して、図３の機能的構成を有するユーザ端末１が実行する達成度算出処理について説明する。
図９は、図３のユーザ端末１が実行する達成度算出処理の流れを説明するフローチャートである。

図９に示すように、ユーザ端末１では、次のような一連の処理が実行される。
ステップＳ２１において、リアル献立取得部１０８は、リアル献立を取得する。
ステップＳ２２において、比較部１０９は、１種類以上の要素毎に定められた所定の比較基準に基づいて、推薦献立とリアル献立とを比較する。比較部１０９の別の例としては、所定期間（例えば１日）ごとに設定された達成すべき一定の数値と、所定期間のリアル献立から算出される数値とを比較しても良い。
ステップＳ２３において、達成度算出部１１０は、比較部１０９による比較結果に基づいて、１種類以上の要素毎の達成度を算出する。これにより達成度算出処理は終了となる。
以上のような一連の処理がユーザ端末１によって実行されることにより、ユーザＵは、推薦献立に対するリアル献立の達成度合いを容易に把握することができる。

次に、ユーザ端末１が図９に示す達成度算出処理によって算出された要素毎の達成度を表示するための具体的手法について説明する。
図１０は、図３のユーザ端末１により算出された要素毎の達成度を表示する具体的手法の一例としてのグラフ（以下「達成度グラフ」と呼ぶ）である。

図１０に示すように、達成度グラフは、横軸が年月、縦軸が達成度で表されている。達成度グラフ上にプロットされている３本の折線は、いずれもユーザＵによって指定された要素Ｐ１乃至Ｐ３を示している。また、図１０の例では、要素Ｐ１乃至Ｐ３の夫々の達成度を、最高値が「１００」、最低値が「０」となるように正規化させた値を表示させている。
具体的には例えば、「栄養バランス」という要素Ｐ１と、「使い切り」という要素Ｐ２と、「好み」という要素Ｐ３という３つの要素が固定要素として指定され、これら３つの要素Ｐ１乃至Ｐ３に基づいて１月から７月までの７カ月間に渡る献立がユーザ端末１によって推薦されたとする。
この場合、推薦献立と、リアル献立とが比較されることにより、又は、所定期間ごとに設定された達成すべき一定の数値と、所定期間のリアル献立から算出される数値とが比較されることにより、要素Ｐ１乃至Ｐ３の夫々についての達成度を月毎に算出することができる。なお、図１０の例では、横軸は月毎の単位で表示されているが、日毎でもよいし、年毎、あるいは四半期毎等、あらゆる期間を単位として表示することができる。

具体的には、要素Ｐ１（栄養バランス）は、２０１７年１月の達成度が８０であったが、２０１７年２月から４月に渡って達成度５０以下となり、その後２０１７年５月から７月は達成度６０以上の水準を維持している。即ち、ユーザＵは、リアル献立が栄養的にバランスがとれてきているということを一見して把握することができる。
また、要素Ｐ２（使い切り）は、２０１７年１月の達成度が５０であり、その後も月によって上下はするが、一貫して達成度５０以上を維持しており、２０１７年７月には、３要素（要素Ｐ１乃至Ｐ３）の中で一番高い達成度８０となっている。即ち、ユーザＵは、リアル献立によって在庫食材が効率良く経済的に使い切られているということを一見して把握することができる。
また、要素Ｐ３（好み）は、２０１７年１月の達成度が１０であり、その後も月によって多少の上下はするが、一貫して達成度３０以下を推移している。また、２０１７年５月以降上昇傾向にあるが、２０１７年７月の時点において、３要素（要素Ｐ１乃至Ｐ３）の中で一番低い達成度３０となっている。即ち、ユーザＵは、リアル献立がユーザＵの好みに即した献立ではないということを一見して把握することができる。
これにより、ユーザＵは、反省すべき点は反省し、良かった点は今後も維持することとして、将来の献立の決定に活かすことができる。

次に、ユーザ端末１が、ユーザＵが買い出しをする際に必要な情報を推薦する具体的手法について説明する。
図１１は、特売情報と在庫情報から献立を推薦する具体的手法の一例を示すイメージ図である。

図１１に示すように、ユーザ端末１の表示領域Ｈ３乃至Ｈ６には、ユーザＵが買出しをする際に有用な情報が表示される。
表示領域Ｈ３には、月日を示すカレンダーが週単位で表示される。図１１の例では、１２月５日の月曜日（本日）から１２月１１日の日曜日までの１週間を示すカレンダーが表示されている。
このカレンダーの中から、ユーザＵによって任意の日が選択されると、当該任意の日における在庫食材の在庫情報が表示される。将来の日付が選択された場合は、推奨献立に基づく在庫量の変化（予定）を反映した当該日付における在庫情報が表示される。なお、図１１の例では、１２月５日の月曜日（本日）がユーザＵによって選択されている。

表示領域Ｈ４には、在庫ＤＢ４０１に記憶されている在庫情報が表示される。図１１の例では、ユーザＵによって指定された日（１２月５日）における在庫情報が表示されている。具体的には、ガラムマサラ、にんにく、牛肉（カレー用）、なす、人参、ジャガイモ、玉ネギ、小麦粉、カレールー、カレー粉が在庫情報として表示されている。

表示領域Ｈ５には、特売ＤＢ４０３に記憶されている特売情報が表示されている。図１１の例では、ユーザＵによって指定された日（１２月５日）における特売情報が表示されている。具体的には、豚のこま切れ肉（￥５８／１００ｇ）、アジ（￥１３４／尾）、人参（￥５８／本）、キャベツ（￥７２／個）が特売情報として表示されている。

表示領域Ｈ６には、表示領域Ｈ４に表示されている在庫情報と、表示領域Ｈ５に表示されている特売情報と、ユーザＵにより選択された要素Ｐ１乃至Ｐ５とに基づいて、複数の献立が表示されている。なお、リアル献立ＤＢ４０５を参照して、表示された献立を実際に作成した直近の日付も併せて表示される。
また、表示領域Ｈ６には、「大人気！」という文字が表示されたボタンＪが設けられている。ユーザＵが、このボタンＪを押下すると、在庫情報と特売情報に含まれる食材を使ったものであって、インターネット上で料理レシピが公開されている評価が高いオリジナル献立（以下「大人気献立」と呼ぶ）が表示される。これにより、ユーザＵは、大人気献立に関する情報を容易に取得することができる。

図１１の例では、献立ＤＢ４０４に記憶されている献立の中から、豚のこま切れ肉、人参、ジャガイモ、及びカレールーを材料とする「カレー」と、豚肉、人参、及びみそを材料とする「豚汁」と、きゃべつ、にんにく、及びパスタ麺を材料とする「パスタ」と、アジを材料とする「大人気献立」とが抽出されている。
このように、表示領域Ｈ６には、特売情報に含まれる食材を使った複数の献立が表示される。具体的には、カレーを示す図形と、豚汁を示す図形と、パスタを示す図形と、ボタンＪとが表示されている。そして、これらの図形の１つ以上を選択して、１２月５日の献立に追加することができる。なお、１２月５日の他の推薦献立は、追加された献立を含む形で献立推薦部１０５が算出し直しても良い。１２月５日の推薦献立として、献立が追加される前に推薦されていた献立を、ユーザＵがユーザ端末１から削除しても良い。

図１１に示すように、カレーを作成するために必要となる食材（即ち材料）のうち、人参、ジャガイモ、及びカレールーは在庫食材に該当し、豚のこま切れ肉は特売情報に含まれるため、ユーザＵが豚のこま切れ肉を購入することにより作成することができる献立として、「カレー」が推薦されている。「カレー」を作成するために必要となる食材（例えば、「ローリエ」）が在庫情報又は特売情報に含まれていなくても良い。この場合は、在庫外食材（「ローリエ」）を購入する必要がある食材として表示する。同様に、豚汁、パスタ、及び大人気献立についても、在庫食材と特売情報に含まれる食材を使用することができる献立として表示領域Ｈ６に表示されている。なお、図示しないが、特売情報に含まれる食材を購入することによって、在庫情報に含まれるどの食材を使用し、どの推薦献立を作ることができるかをユーザＵが確認することができるように、ユーザＵがユーザ端末１から特売情報に含まれる食材（例えば、「豚のこま切れ肉」）のアイコンを選択すると、「豚のこま切れ肉」のアイコンと、推薦献立に使用される在庫食材（例えば、「人参」「ジャガイモ」「カレールー」）のアイコンとを結ぶ破線（３本）が表示され、かつ／又は、「豚のこま切れ肉」を使った推薦献立（「カレー」、「豚汁」）のアイコンがハイライト表示されても良い。
あるいは、図示はしないが、ユーザＵがユーザ端末１から特売情報に含まれる食材（例えば、「豚のこま切れ肉」）のアイコンを選択すると、当該アイコンと「豚のこま切れ肉」を使った推薦献立（「カレー」、「豚汁」）のアイコンとを結ぶ破線（２本）が表示され、かつ／又は、当該推薦献立（「カレー」、「豚汁」）と推薦献立に使用される在庫食材（例えば、「人参」「ジャガイモ」「カレールー」）のアイコンとを結ぶ破線（３本）が表示されても良い。

また、推薦献立として表示領域Ｈ６に表示される献立は、ユーザＵの家族が好む献立とすることもできる。この場合、ユーザ端末１による献立の推薦が行われる際、「好み」という要素に基づいていることになる。
具体的には、リアル献立を撮像した画像Ｅや、リアル献立に関する情報（日付、献立名等）をリアル献立ＤＢ４０５に記憶させる。そして、事前にユーザＵの家族からリアル献立についての評価及び／又はコメントを募り、その結果をリアル献立に紐付けてリアル献立ＤＢ４０５に記憶させておく。評価及び／又はコメントは、リアル献立ＤＢ４０５に替えて／ともに、リアル献立に対応する献立に関する情報として献立ＤＢ４０４に記憶させても良い。なお、ユーザＵの家族から評価及び／又はコメントを募る手法は特に限定されない。例えばユーザＵは、ＳＮＳ（ｓｏｃｉａｌ ｎｅｔｗｏｒｋｉｎｇ ｓｅｒｖｉｃｅ）を利用して、ユーザＵの家族に対しリアル献立の人気投票を行ってもよい。また、ユーザ端末１にインストールされた所定のアプリケーションプログラムを利用して評価及びコメントを募ってもよい。これにより、ユーザ端末１は、ユーザＵの家族によるリアル献立に対する評価及びコメントの実績に基づいた献立を推薦することができる。

以上、本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

例えば、上述した実施形態では、ユーザＵにより選択される「１種類以上の要素」の例として「栄養バランス」、「使い切り」、「和食」、「好み」、「野菜」が例示されている。しかしながら、これらの要素は例示に過ぎない。複数種類ある献立の中から所定の献立が推薦する際に考慮し得るあらゆる内容のものを「１種類以上の要素」として採用することができる。

また、図７の例では、横軸が日付で区切られているが、横軸を区切る単位（即ち献立を推薦する単位）は日付に限定されない。例えば朝食、昼食、夕飯といった単位で区切られてもよい。

また、図８では、ユーザ端末１が推薦する複数日間の献立として、１カ月間の献立が例示されている。しかしながら、ユーザ端末１が献立を推薦する期間は１カ月間に限定されない。あらゆる期間の献立を推薦することができる。例えば、２月ケ間、四半期間といった期間の献立を推薦することができる。

また、図２に示す各ハードウェア構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。

また、図３に示す機能ブロック図は、例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行出来る機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは、特に図３の例に限定されない。

また、機能ブロックの存在場所も、図３に示す場所に限定されず、任意でよい。例えばユーザ端末１側の機能ブロックの少なくとも一部をサーバ２側に設けてもよいし、その逆でもよい。
そして、１つの機能ブロックは、ハードウェア単体で構成しても良いし、ソフトウェア単体との組み合わせで構成しても良い。

各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

このようなプログラムを含む記録媒体は、各ユーザにプログラムを提供するために装置本体とは別に配布される、リムーバブルメディアにより構成されるだけではなく、装置本体に予め組み込まれた状態で各ユーザに提供される記録媒体等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に添って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
例えば、図４のステップＳ１において、在庫情報取得部１０１は、ユーザＵが保有する在庫食材に関する情報を在庫情報として取得する。しかし、在庫情報は、献立推薦部１０５が複数日間の献立の推薦を行う時点で適切に管理されていれば足りる。このため、在庫情報は、ステップＳ６において献立推薦部１０５が複数日間の献立の推薦を行う処理よりも前のいずれかの時点から在庫ＤＢ４０１に記憶され管理されていればよい。

以上まとめると、本発明が適用される情報処理装置は、次のような構成を取れば足り、各種各様な実施形態を取ることができる。
即ち、本発明が適用される情報処理装置（例えば図１のユーザ端末１）は、
食材の在庫に関する情報を在庫情報として取得する在庫情報取得手段（例えば図３の在庫情報取得部１０１）と、
前記在庫情報取得手段により取得された前記在庫情報に基づいて、作成可能な複数日間の献立を推薦する献立推薦手段（例えば図３の献立推薦部１０５）と、
を備える。
これにより、献立を所定の要素に基づいて推薦する手法を提供することができる。

また、１種類以上の要素を受付ける要素受付手段（例えば図３の要素受付部１０２）をさらに備え、献立推薦手段（例えば図３の献立推薦部１０５）は、前記在庫情報取得手段により取得された前記在庫情報と、前期要素受付手段により受け付けられた前記１種類以上の要素とに基づいて、作成可能な複数日間の献立を推薦しても良い。
また、前記献立推薦手段により推薦される前記献立の作成に必要となる食材には、前記在庫に含まれない食材としての在庫外食材を含むことができる。
これにより、ユーザが在庫として保有する食材と、それ以外の食材とに関する献立を、所定の要素毎に推薦する手法を提供することができる。

また、ユーザ（例えば図１のユーザＵ１）により指定された指定食材を受付ける指定食材受付手段（例えば図３の指定食材受付部１０６）をさらに備え、
前記献立推薦手段はさらに、
推薦すべき献立の作成にあたって、当該指定食材が在庫情報に含まれない場合は、前記指定食材を調達する必要がある旨を提示することができる。
これにより、ユーザＵは、所望の食材を使用した献立を作成したいと考えた場合、ユーザ端末１を操作することにより当該食材を指定することができる。

また、所定の期間内に購入すれば当該所定の期間外に購入するよりも安価で購入可能な特売食材に関する情報としての特売情報を取得する特売情報取得手段（例えば図３の特売情報取得部１０４）をさらに備え、
前記献立推薦手段はさらに、
特売情報に基づいて推薦すべき献立の作成することができる。
これにより、ユーザ端末１から推薦される献立に、特売食材を含めることができるため、ユーザＵに対し経済的なメリットを享受させることが可能となる。

また、１以上の献立の中から、ユーザにより指定された献立を指定献立として受付ける指定献立受付手段（例えば図３の指定献立受付部１０７）をさらに備え、
前記献立推薦手段はさらに、
前記指定献立の作成にあたって、在庫外食材が必要となる場合、当該在庫外食材を調達する必要がある旨を提示することができる。
これにより、ユーザＵは、所望の献立を作成したいと考えた場合、ユーザ端末１を操作することにより、当該献立を指定することができる。

また、前記要素受付手段により受付けられた前記要素が複数種類ある場合に、所定の判断基準に基づいて、前記複数種類の要素の夫々に対し重み付けを行う重付手段（例えば図３の重付部１０３）をさらに備え、
前記献立推薦手段はさらに、
前記在庫情報取得手段により取得された前記在庫情報と、前記重付手段により重み付けされた前記複数種類の要素の夫々とに基づいて、１以上の献立を推薦することができる。
これにより、ユーザＵは、複数の目的に基づいた献立を作成したいと考えている場合に、複数の目的の夫々についての優先度合を付与することができる。

また、ユーザにより実際に作成された献立をリアル献立として取得するリアル献立取得手段（例えば図３のリアル献立取得部１０８）と、
前記１種類以上の要素毎に定められた所定の比較基準に基づいて、前記献立推薦手段により推薦された前記献立と前記リアル献立とを比較する比較手段（例えば図３の比較部１０９）と、
前記比較手段による比較結果に基づいて、前記１種類以上の要素毎の達成度を算出する達成度算出手段（例えば図３の達成度算出部１１０）と、
をさらに備えることができる。
これにより、ユーザＵは、自身の過去の実績を容易に確認することができる。

１：ユーザ端末
２：サーバ
１１：ＣＰＵ
１２：ＲＯＭ
１３：ＲＡＭ
１４：バス
１５：入出力インターフェース
１６：表示部
１７：入力部
１８：記憶部
１９：通信部
２０：ドライブ
３０：リムーバブルメディア
１０１：在庫情報取得部
１０２：要素受付部
１０３：重付部
１０４：特売情報取得部
１０５：献立推薦部
１０６：指定食材受付部
１０７：指定献立受付部
１０８：リアル献立取得部
１０９：比較部
１１０：達成度算出部
２０１：特売情報収集部
４０１：在庫ＤＢ
４０２：食材ＤＢ
４０３：特売ＤＢ
４０４：献立ＤＢ
４０５：リアル献立ＤＢ
Ｂ，Ｂ１，Ｂ２：買出日
Ｃ，Ｇ，Ｋ，Ｌ，Ｍ，Ｓ，Ｔ：ボタン
Ｄ１，Ｄ２，Ｄ３，Ｄ４，Ｄ５，Ｄ６：日付
Ｈ１，Ｈ２，Ｈ３，Ｈ４，Ｈ５，Ｈ６：表示領域
Ｎ：ネットワーク
Ｐ１，Ｐ２，Ｐ３，Ｐ４，Ｐ５：要素
Ｕ，Ｕ１，Ｕｎ：ユーザ
Ｙ，Ｙ１，Ｙ１ａ，Ｙ１ｂ，Ｙ１ｃ，Ｙ１ｄ，Ｙ１ｅ，Ｙ１ｆ，Ｙ１ｇ：多角形（在庫食材）
Ｙ２，Ｙ２ａ，Ｙ２ｂ，Ｙ２ｃ：月予算

Claims (7)

1. ユーザの食材の在庫に関する情報を在庫情報として取得する在庫情報取得手段と、
   前記ユーザにより選択された１種類以上の要素を示す情報を要素情報として受付ける要素受付手段と、
   前記在庫情報取得手段により取得された前記在庫情報と、前記要素受付手段により受付けられた前記要素情報とに基づいて、作成可能な複数日間の献立であって前記ユーザに推薦すべき献立を示す情報を、推薦献立情報として生成して、前記ユーザが認識可能な所定の出力デバイスに対して出力する献立推薦手段と、
   前記ユーザにより実際に作成された献立を示す情報をリアル献立情報として取得するリアル献立取得手段と、
   前記要素情報により示される前記１種類以上の要素毎に定められた所定の比較基準に基づいて、前記推薦献立情報と前記リアル献立情報とを比較する比較手段と、
   前記比較手段による比較結果に基づいて、前記要素情報により示される前記１種類以上の要素毎の達成度を算出する達成度算出手段と、
   を備える情報処理装置。
2. 前記ユーザにより指定された指定食材を示す情報を指定食材情報として受付ける指定食材受付手段をさらに備え、
   前記献立推薦手段はさらに、
   前記指定食材情報に基づいて、前記推薦献立情報を生成して前記所定の出力デバイスに出力し、
   前記指定食材が前記在庫情報に含まれない場合、前記指定食材を前記ユーザが調達する必要がある旨を示す情報を、前記出力デバイスに出力する、
   請求項１に記載の情報処理装置。
3. 所定の期間内に購入すれば当該所定の期間外に購入するよりも安価で購入可能な特売食材に関する情報としての特売情報を取得する特売情報取得手段をさらに備え、
   前記献立推薦手段はさらに、
   前記特売情報に基づいて前記推薦献立情報を生成して、前記出力デバイスに出力する、
   請求項１又は２に記載の情報処理装置。
4. １以上の献立の中から、前記ユーザにより指定された献立を示す情報を指定献立情報として受付ける指定献立受付手段と、
   前記指定献立に従った料理の作成に必要な食材のうち、前記在庫情報に含まれない食材が存在する場合、当該食材を調達する必要がある旨を示す情報を前記出力デバイスに送信する出力手段と、
   をさらに備える請求項１乃至３のうちいずれか１項に記載の情報処理装置。
5. 前記要素受付手段により受付けられた前記要素が複数種類ある場合に、所定の判断基準に基づいて、前記複数種類の要素の夫々に対し重み付けを行う重付手段をさらに備え、
   前記献立推薦手段はさらに、
   前記在庫情報取得手段により取得された前記在庫情報と、前記重付手段により重み付けされた前記複数種類の要素の夫々とに基づいて、１以上の前記献立情報を生成して、前記所定の出力デバイスに出力する、
   請求項２乃至４のうちいずれか１項に記載の情報処理装置。
6. 情報処理装置が実行する情報処理方法であって、
   ユーザの食材の在庫に関する情報を在庫情報として取得する在庫情報取得ステップと、
   前記ユーザにより選択された１種類以上の要素を示す情報を要素情報として受付ける要素受付ステップと、
   前記在庫情報取得ステップにより取得された前記在庫情報と、前記要素受付ステップにより受付けられた前記要素情報とに基づいて、作成可能な複数日間の献立であって前記ユーザに推薦すべき献立を示す情報を、推薦献立情報として生成して、前記ユーザが認識可能な所定の出力デバイスに対して出力する献立推薦ステップと、
   前記ユーザにより実際に作成された献立を示す情報をリアル献立情報として取得するリアル献立取得ステップと、
   前記要素情報により示される前記１種類以上の要素毎に定められた所定の比較基準に基づいて、前記推薦献立情報と前記リアル献立情報とを比較する比較ステップと、
   前記比較ステップによる比較結果に基づいて、前記要素情報により示される前記１種類以上の要素毎の達成度を算出する達成度算出ステップと、
   を含む情報処理方法。
7. 情報処理装置を制御するコンピュータに、
   ユーザの食材の在庫に関する情報を在庫情報として取得する在庫情報取得ステップと、
   前記ユーザにより選択された１種類以上の要素を示す情報を要素情報として受付ける要素受付ステップと、
   前記在庫情報取得ステップにより取得された前記在庫情報と、前記要素受付ステップにより受付けられた前記要素情報とに基づいて、作成可能な複数日間の献立であって前記ユーザに推薦すべき献立を示す情報を、推薦献立情報として生成して、前記ユーザが認識可能な所定の出力デバイスに対して出力する献立推薦ステップと、
   前記ユーザにより実際に作成された献立を示す情報をリアル献立情報として取得するリアル献立取得ステップと、
   前記要素情報により示される前記１種類以上の要素毎に定められた所定の比較基準に基づいて、前記推薦献立情報と前記リアル献立情報とを比較する比較ステップと、
   前記比較ステップによる比較結果に基づいて、前記要素情報により示される前記１種類以上の要素毎の達成度を算出する達成度算出ステップと、
   を含む制御処理を実行させるプログラム。

Images