JP7496503B2 - 献立提案システム、献立提案方法、プログラム、情報処理方法、及び情報処理装置 - Google Patents

Description

本開示は、一般に、献立提案システム献立提案方法、プログラム、情報処理方法、及び情報処理装置に関する。より詳細には、対象期間における献立を提案する献立提案システム、献立提案方法、プログラム、情報処理方法、及び情報処理装置に関する。

特許文献１には、買い物の効率を向上させるための情報処理装置が開示されている。この情報処理装置は、購入予定額取得部、目標額取得部、及び商品情報出力部を有する。購入予定額取得部は、購入予定額を取得する。購入予定額は、顧客が購入しようとしている商品の合計金額である。目標額取得部は、購入金額の目標額を取得する。商品情報出力部は、目標額と購入予定額との差分に基づいて商品を決定する。そして商品情報出力部は、決定した商品の商品情報を出力する。

特開２０１７－１８２５５４号公報

特許文献１に開示される情報処理装置では、店舗で顧客が買い物をする上で、目標額に収まるように、目標額と購入予定額との差分に基づいて商品（食材）を決定する。しかし、例えばある対象期間内の献立を提案する場合、目標額（目標値）と購入予定額との差分（つまり金額）に基づいて献立（食材等）を決定するだけでは、本当に顧客（ユーザ）の所望する献立の提案が行われない可能性がある。

本開示は上記事由に鑑みてなされ、提案する献立内容の改善を図ることができる、献立提案システム、献立提案方法、プログラム、情報処理方法、及び情報処理装置を提供することを目的とする。

本開示の一態様の献立提案システムは、評価部と、処理部と、実績取得部と、を備える。前記評価部は、対象期間における献立を提案する。前記処理部は、前記評価部が提案した前記献立をユーザに提示する。前記実績取得部は、前記対象期間の途中における任意のタイミングにおいて、前記評価部が提案した前記献立に対する実績を前記ユーザから取得する。前記評価部は、前記対象期間の開始から前記タイミングまでの間において、前記評価部が提案した前記献立の内容に関する第１情報と、前記実績取得部が取得した前記実績に関する第２情報と、に差分がある場合、前記差分に応じた前記ユーザに対する還元に関する還元処理と、前記対象期間のうちの前記タイミング以降の残りの期間に対する前記献立の内容を変更して再提案する再提案処理と、の少なくとも一方を行う。

本開示の一態様の献立提案方法は、評価ステップと、処理ステップと、実績取得ステップと、を含む。前記評価ステップでは、対象期間における献立を提案する。前記処理ステップでは、前記評価ステップが提案した前記献立をユーザに提示する。前記実績取得ステップでは、前記対象期間の途中における任意のタイミングにおいて、前記評価ステップが提案した前記献立に対する実績を前記ユーザから取得する。前記評価ステップでは、前記対象期間の開始から前記タイミングまでの間において、前記評価ステップが提案した前記献立の内容に関する第１情報と、前記実績取得ステップが取得した前記実績に関する第２情報とに差分がある場合、前記差分に応じた前記ユーザに対する還元に関する還元処理と、前記対象期間のうちの前記タイミング以降の残りの期間に対する前記献立の内容を変更して再提案する再提案処理と、の少なくとも一方を行う。

本開示の一態様のプログラムは、１以上のプロセッサに、前記献立提案方法を実行させる。

本開示の一態様の情報処理方法は、第１処理ステップと、第２処理ステップと、第３処理ステップと、を含む。前記第１処理ステップでは、対象期間における献立を取得し、取得した前記献立をユーザに提示する。前記第２処理ステップでは、前記対象期間の途中における任意のタイミングにおいて、前記第１処理ステップが提示した前記献立に対する実績を前記ユーザから取得する。前記第３処理ステップでは、前記対象期間の開始から前記タイミングまでの間において、前記第１処理ステップが提示した前記献立の内容に関する第１情報と、前記第２処理ステップが取得した前記実績に関する第２情報と、に差分がある場合、前記差分に応じた前記ユーザに対する還元に関する還元処理と、前記対象期間のうちの前記タイミング以降の残りの期間に対する前記献立の内容を変更して再提案する再提案処理と、の少なくとも一方の処理により得られた情報を前記ユーザに提示する。

本開示の一態様の情報処理装置は、処理部を備える。前記処理部は、第１処理機能と、第２処理機能と、第３処理機能と、を有する。前記第１処理機能では、対象期間における献立を取得し、取得した前記献立をユーザに提示する。前記第２処理機能では、前記対象期間の途中における任意のタイミングにおいて、前記第１処理機能が提示した前記献立に対する実績を前記ユーザから取得する。前記第３処理機能では、前記対象期間の開始から前記タイミングまでの間において、前記第１処理機能が提示した前記献立の内容に関する第１情報と、前記第２処理機能が取得した前記実績に関する第２情報と、に差分がある場合、前記差分に応じた前記ユーザに対する還元に関する還元処理と、前記対象期間のうちの前記タイミング以降の残りの期間に対する前記献立の内容を変更して再提案する再提案処理と、の少なくとも一方の処理により得られた情報を前記ユーザに提示する。

本開示によれば、提案する献立内容の改善を図ることができる、という利点がある。

図１は、一実施形態に係る献立提案システムを備える献立支援システムの概略構成図である。 図２は、同上の献立支援システムにおける提示装置のブロック構成図である。 図３Ａは、同上の献立支援システムにおける対象期間を説明するための図である。 図３Ｂは、同上の献立支援システムにおける条件情報に関する概念図である。 図４は、同上の献立支援システムにおける動作を説明するためのフローチャート図である。 図５は、一実施形態の第１実施例～第４実施例に係る献立提案システムのブロック構成図である。 図６は、一実施形態の第１実施例に係る献立提案システムにおける動作を説明するためのフローチャート図である。 図７は、一実施形態の第２実施例に係る献立提案システムにおける動作を説明するためのフローチャート図である。 図８は、一実施形態の第３実施例に係る献立提案システムにおける動作を説明するためのフローチャート図である。 図９は、一実施形態の第４実施例に係る献立提案システムにおける動作を説明するためのフローチャート図である。

（１）概要
以下の実施形態において説明する各図は、模式的な図であり、各図中の各構成要素の大きさ及び厚さそれぞれの比が、必ずしも実際の寸法比を反映しているとは限らない。

本実施形態の一の形態に係る献立提案システム（ここではサーバ１：図１参照）は、対象期間Ｔ１に対する食費に関する目標値Ａ１（図３Ａ参照）に基づいて、対象期間Ｔ１における献立を提案する。献立（情報）は、献立提案システムを利用するユーザ５（図１参照）に提案される。

ここでいう献立情報は、調理メニュー（名）、使用する食材の名称、食材の種類（肉類、魚介類、豆類、穀類、生鮮野菜、生鮮果実、きのこ類といったジャンル）、及び食材の分量やサイズ等を含むレシピ（調理法）に関する情報を含むことを想定する。ここでは一例として、献立提案システムは、献立だけでなく、中食又は外食に関する情報（レストラン店等の店舗情報）も提案する。言い換えると、献立提案システムは、自宅等で調理する食事だけなく、飲食店で提供される食事に関する提案も可能に構成される。以下では、メニューの品数に関わらず（１品でも複数品でも）調理メニュー及びレシピをまとめて、単に「献立」と呼ぶことがある。言い換えると、献立は、１又は複数のレシピに関する情報を含む。

ところで、いわゆる「サブスクリプション方式」の料金支払いのサービスが注目されている。サブスクリプション方式は、例えばユーザが、ある有効期限（月単位又は年単位等）で契約を行い、利用料金を支払うことで、その有効期限における「物」を継続的に使用できる形態のサービスである。そして、本実施形態では一例として、献立提案システムが、サブスクリプションサービス提供に利用される形態を想定して説明する。

献立提案システムを利用するユーザ５は、献立提案システムを提供する者（以下「献立提供者」と呼ぶ）と契約を行い、例えば月額３万円（定額）を献立提供者に支払う。その結果、献立提案システムは、食費「３万円」を目標値Ａ１として１ヵ月（対象期間Ｔ１）の献立を提案する。また献立提供者は、食配事業者３（図１参照）とも契約をしており、ユーザ５が決定した献立に対応する食材Ｂ１に関する食配要求を行う。食配事業者３は、食配要求を受けることで、食配要求に応じた食材Ｂ１をユーザ５の自宅（住宅２００）まで配達する。要するに献立提案システムは、食材Ｂ１の配達サービスと連携した定額型の献立提案サービスをユーザ５に提供できるように構成される。

以下では、ある住宅２００の家族に着目して献立提案システムが利用される場合を一例に説明する。説明の便宜上、住宅２００の家族のうち、例えば家庭内の調理を行う者（調理者Ｘ１）である一人（母親）が、献立提案システムを利用することを想定する。しかし、献立提案システムを利用するユーザ５の数は特に限定されず、家族全員（母親、父親、子供）でもよい。また献立提案システムは、組織又は団体の単位でも利用され得る。また以下では、献立提案の対象期間Ｔ１は、「１ヵ月間」として説明するが、特に限定されず、１日間、１週間、数ヵ月間、又は１年間等でもよい。

ここで献立提案システム（サーバ１）は、図１に示すように、評価部１２と処理部１１とを備えている。評価部１２は、対象期間Ｔ１の途中における任意のタイミングｔ１において献立に関する評価を行う。処理部１１は、評価部１２の結果に基づいて所定の処理を行う。評価部１２は、提案された献立の内容に関する第１情報と、提案された献立に対する実績に関する第２情報とに基づいて、評価を行う。第１情報及び第２情報はいずれも、対象期間Ｔ１の開始からタイミングｔ１までの間における情報である。

詳細は後述するが、ここでいう「献立に対する実績」は、ユーザ５が、提案された献立を採用したという実績、及び提案された献立を不採用（キャンセル）にしたという実績等を含み得る。提案される献立数は１つとは限らず、２つ以上であれば、どの献立を採用しどの献立を不採用にしたかという実績も「献立に対する実績」に含まれる。さらに「献立に対する実績」は、ユーザ５が、献立の内容の一部（例えば食材の一部）を変更した上で採用したといった実績も含み得る。

ここでいう「所定の処理」は、評価の結果により得られた献立をユーザ５に提示する処理を含み得る。また「所定の処理」は、第１情報と、第２情報との差分に応じた還元に関する処理を含み得る。さらに「所定の処理」は、対象期間Ｔ１のうち、タイミングｔ１以降の残りの期間Ｔ２（図３Ａ参照）に対する献立の内容を変更する処理を含み得る。

本実施形態の献立提案システムによれば、任意のタイミングｔ１における献立を評価する際に、タイミングｔ１までに提案した献立（提案履歴）及び献立に対する実績（採用／不採用履歴）に基づいて評価する。そして、評価の結果に基づいて所定の処理が行われる。そのため、日々変化する要素（食費の残額等）に加えて、対象期間Ｔ１内における過去の提案履歴、及び採用／不採用履歴が反映された最新の献立提案を行える。結果的に、提案する献立内容の改善を図ることができる、という利点がある。

本実施形態では、ユーザ５が所有（例えば携帯）する情報端末に相当する提示装置２（図１参照）から、提案される献立（情報）が出力（提示）される。ここでいう「情報端末」は、例えばスマートフォン、又はタブレット端末等である。「提示」は、例えば、タッチパネル式の液晶ディスプレイ又は有機ＥＬ（Electro-Luminescence）ディスプレイを含む表示部２５Ａ（図１参照）からの画面出力によって行われることを想定する。しかし、提示装置２は、携帯型の端末に限定されず、例えば据置型のパーソナルコンピュータであってもよい。また「提示」は、画面出力に限られず、画面出力の代わりに又は画面出力に加えて、音声出力によって行われてもよい。例えば提示装置２は、人工知能（ＡＩ：Artificial Intelligence）技術を適用したスマートスピーカ、いわゆるＡＩスピーカによって実現されてもよい。提示装置２は、スマートテレビでもよい。提示装置２は、携帯型の端末ではない場合、住宅２００内のキッチン等に設置され得る。

提示装置２から提示される献立情報は、調理メニュー及びレシピに関するテキスト情報及び画像情報（静止画又は動画）を含み得る。

本実施形態の別の形態に係る献立提案方法は、対象期間Ｔ１に対する食費に関する目標値に基づいて、対象期間Ｔ１における献立を提案する。献立提案方法は、評価ステップと、処理ステップと、を含む、評価ステップにて、対象期間Ｔ１の途中における任意のタイミングにおいて献立に関する評価を行う。処理ステップにて、評価ステップの結果に基づいて所定の処理を行う。評価ステップにて、対象期間Ｔ１の開始からタイミングｔ１までの間において、提案された献立の内容に関する第１情報と、提案された献立に対する実績に関する第２情報とに基づいて、評価を行う。

この献立提案方法においても、提案する献立内容の改善を図ることができる、という利点がある。

本実施形態では、献立提案システムの機能（例えば評価部１２及び処理部１１の機能）が全て、１又は複数の提示装置２と通信可能なサーバ１に集約して組み込まれているものとする。したがって、以下では、「献立提案システム」をサーバ１と呼ぶことがある。しかし、献立提案システムの機能のうちの少なくとも一部の機能が、サーバ１以外の装置に組み込まれてもよい。またサーバ１は、１台のサーバ装置から構成されることを想定するが、複数台のサーバ装置から構成されてもよいし、そのようなサーバ装置が、例えばクラウド（クラウドコンピューティング）を構築してもよい。

本実施形態の献立提案システムは、例えば、ユーザ５に関連する履歴情報（提案履歴、採用／不採用履歴等）を管理し、機械学習により、ユーザ５の生活パターン（生活習慣、生活リズム）及び嗜好性により合った献立を決定して提案する。

（２）詳細
以下、本実施形態に係る献立提案システム（サーバ１）を備える献立支援システム１００の構成について、図１～図４を参照しながら詳しく説明する。

（２．１）全体構成
サーバ１は、上述の通り、対象期間Ｔ１（例えば１ヵ月の単位）に対する食費に関する目標値Ａ１（例えば３万円）に基づいて、対象期間Ｔ１における献立を提案する。ここでは一例として、図３Ａに示すように、４月１日～４月３０日の１ヵ月を対象期間Ｔ１とする。上述の通り、対象期間Ｔ１に対する食費は、定額（例えば３万円）として予め設定されている。サーバ１を利用するユーザ５は、献立提供者に４月分の食費として定額３万円を支払うことで、献立提案を受けることができる。さらにユーザ５は、提案された献立を採用する意思を示せば、その献立に必要な食材Ｂ１が、住宅２００まで食配事業者３によって配達されるというサービス（食配サービス）も受けることができる。

サーバ１は、例えば、ユーザ５から、４月１日～４月３０日の１ヵ月分の献立（１ヵ月単位の計画献立）の提案要求を、４月１日より前（例えば３月３０日）に受けると、ユーザ５からの要求に応じて「献立」を提案する提案処理を実行する。以下、これを「初回提案」と呼ぶ。「初回提案」は、例えば、目標値Ａ１（例えば３万円）に基づいて決定された、４月１日～４月３０日の１ヵ月分の全ての献立提案（概案）となる。またサーバ１は、対象期間Ｔ１の開始から任意のタイミングｔ１（図３Ａの例では４月７日）において、ユーザ５から提案要求を再度受け付けることも可能である。以下、「初回提案」から２回目以降の提案を「期間内提案」と呼ぶ。「期間内提案」の要求は、４月１日～４月３０日の間であれば、回数に制限なく可能である。「期間内提案」は、任意のタイミングｔ１の時点における残額に基づいて決定された、タイミングｔ１以降における献立提案となる。「タイミングｔ１以降における献立提案」は、タイミングｔ１から最終日（４月３０日）までの残り全期間分の献立でもよいし、タイミングｔ１から最終日より手前の日までの期間分の献立でもよいし、タイミングｔ１の当日分のみの献立でもよい。

献立支援システム１００は、１又は複数の提示装置２と、サーバ１（献立提案システム）と、を備えている。献立支援システム１００は、住宅２００内に設置されるルータ６を更に備えている。ここでは上述の通り、住宅２００に住む家族のうち母親（ユーザ５）に着目して説明する。つまり、母親（ユーザ５）が日々の家族全員分の食事を調理している調理者Ｘ１とする。したがって、主に母親（ユーザ５）が、献立支援システム１００から、日々の献立に関する支援を所望する者となる。もちろん、臨時的に母親以外の家族（例えば父親）が調理者Ｘ１となる可能性もある。本実施形態では、図１に示すように、母親（ユーザ５）が提示装置２を所有（携帯）している。

提示装置２は、上述の通り、一例としてスマートフォン等の携帯型の情報端末を想定する。提示装置２は、それを携帯するユーザ５が住宅２００内に居る場合、宅内に設置のルータ６と通信可能に接続される。提示装置２は、ルータ６と、例えばＷｉ－Ｆｉ（登録商標）等の規格に準拠した無線通信を行う。ルータ６は、宅内の各種の調理家電とも通信可能に接続され得る。ルータ６と通信可能な各種の調理家電としては、（電子）レンジ装置、冷凍・冷蔵庫、オーブン、及び炊飯器等である。提示装置２は、ルータ６を介して、これらの調理家電と無線通信可能である。また住宅２００内にＨＥＭＳ（Home Energy Management System）が導入されていれば、ＨＥＭＳのコントローラも、ルータ６と通信可能に接続される。ルータ６は、インターネット等のネットワークＮＴ１（図１参照）と接続されている。提示装置２、及び各種の調理家電は、ルータ６を介して、住宅２００の外部のサーバ１と通信可能となっている。提示装置２は、それを携帯するユーザ５が住宅２００外に居る場合、通信事業者が提供する携帯電話網（キャリア網）又は公衆無線ＬＡＮ（Local Area Network）等を介して、ネットワークＮＴ１に接続される。なお、サーバ１については、次の欄で詳しく説明する。

提示装置２は、図２に示すように、通信部２１と、制御部２２と、記憶部２３と、入力部２４と、出力部２５と、検知部２６とを備えている。提示装置２には、サーバ１及びレンジ装置等の調理家電と通信して、献立に関するＧＵＩ（Graphical User Interface）を提示するための専用のアプリケーションソフト（以下、単に「献立アプリ」と呼ぶ）が予めインストールされている。

通信部２１は、サーバ１及びレンジ装置等の調理家電と通信するための通信インタフェースである。提示装置２は、通信部２１を介して、サーバ１及びレンジ装置等の調理家電とデータの送信及び受信を行う。

制御部２２は、提示装置２の全体的な制御、すなわち、通信部２１、制御部２２、記憶部２３、入力部２４、出力部２５、及び検知部２６を制御するように構成される。制御部２２は、例えば、１以上のプロセッサ（マイクロプロセッサ）と１以上のメモリとを含むコンピュータシステムにより実現され得る。つまり、１以上のプロセッサが１以上のメモリに記憶された１以上のプログラム（アプリケーション）を実行することで、制御部２２として機能する。プログラムは、ここでは制御部２２のメモリに予め記録されているが、インターネット等の電気通信回線を通じて、又はメモリカード等の非一時的な記録媒体に記録されて提供されてもよい。

記憶部２３は、読み書き可能なメモリで構成されている。記憶部２３は、例えばフラッシュメモリである。記憶部２３は、制御部２２の外部に設けられているが、制御部２２の内部に設けられていてもよい。すなわち、記憶部２３は、制御部２２の内蔵メモリであってもよい。記憶部２３は、種々のデータを記憶する。

入力部２４は、ユーザ５からの入力操作を受け付けるユーザインタフェースであり、ここでは提示装置２に付設されるタッチパネル式のディスプレイ（表示部２５Ａ）が入力部２４としての機能を兼ねている。要するにユーザ５の指先等による表示部２５Ａの表示画面への操作（タップ操作等）により、ユーザ入力が受け付けられる。また提示装置２に付設されるマイクロホンも、入力部２４としての機能を兼ねてもよい（音声入力）。入力部２４は、献立アプリに関するユーザ入力を受け付ける。

特に入力部２４は、ユーザ５が個別に取得した食材Ｂ２（図１参照）に関する食材情報を入力する。ここでいう「ユーザ５が個別に取得した食材Ｂ２」とは、食配事業者３によって配達される食材Ｂ１とは違って、ユーザ５自身が、食品スーパー等の店舗４（図１参照）で購入、或いは知人や親類等から譲り受けた食材に相当する。また入力部２４は、提案した献立について採用を示すユーザ入力、又は提案した献立についてキャンセルを示すユーザ入力を受け付ける。また入力部２４は、提案した献立の内容のうち少なくとも一部の内容の変更を示すユーザ入力を受け付ける。

出力部２５は、種々の情報をユーザ５に出力（提示）するユーザインタフェースであり、ここでは提示装置２に付設されるタッチパネル式の表示部２５Ａが、出力部２５としての機能を兼ねている。また提示装置２に付設されるスピーカも、出力部２５としての機能を兼ねてもよい。出力部２５は、献立アプリに関する情報をユーザ５に出力する。

特に出力部２５は、表示部２５Ａから、サーバ１から受信する献立情報に関する画像データや文字列データを出力したり、スピーカから献立情報に関する音声データを出力したりして、「献立提案」を実行する。

検知部２６は、自機（提示装置２）を携帯するユーザ５の現在地を検知するように構成される。検知部２６は、例えば、ＧＰＳ（Global Positioning System）等の衛星測位システムを用いて現在の自機の位置情報を取得し、その位置情報に基づき、提示装置２を携帯するユーザ５の現在地を検知する。制御部２２は、検知部２６により検知されたユーザ５の現在地に関する情報を、通信部２１を介して、サーバ１に送信する。

ユーザ５は、提示装置２にて献立アプリを起動し、献立提供者から予め付与されているユーザＩＤ及びパスワードを、ログイン画面にて入力することで、ユーザＩＤに紐づけされた献立に関する種々のサービス提供を受けることができる。

ユーザ５は、提示装置２において、任意のタイミングで献立アプリを起動し、入力部２４を通じて、献立提案を所望するための操作入力を行うと、提示装置２は、ユーザＩＤ等を含む献立要求信号をサーバ１に送信する。ここでいう操作入力は、例えば、ユーザ５が献立提案を受けたい対象期間Ｔ１を指定するための入力である。したがって、送信される献立要求信号には、ユーザ５から指定される対象期間Ｔ１に関する情報も含む。もし対象期間Ｔ１に関するユーザ指定が存在しなければ、デフォルトとして献立要求信号を送信した当日（１日分）のみが、対象期間Ｔ１として設定されてもよい。サーバ１は、提示装置２から献立要求信号を受信したことをトリガーとして、対象期間Ｔ１の食費を目標値Ａ１（定額３万円）以内に収めつつ、そのユーザ５に見合った献立提案ができるように、ＡＩ（Artificial Intelligence）技術を利用した献立の提案処理を実行する。

（２．２）サーバ
サーバ１は、住宅２００の外部に設置されている。サーバ１は、例えば献立提供者によって運用され得る。サーバ１は、上述の通り、一例として１台のサーバ装置から構成される。

サーバ１は、献立情報に関するサービスを受けるユーザ５から、提示装置２等を介して種々の情報を収集して管理する。サーバ１は、ユーザ５の個人情報（ユーザＩＤ、氏名、住所、電話番号、及びメールアドレス情報等）を管理している。またサーバ１は、提示装置２の識別情報、ユーザＩＤ、及びパスワードを管理している。さらにサーバ１は、住宅２００の所在情報、及び住宅２００内の調理家電の識別情報等を管理している。なお、母親以外の家族（父親及び子供等）も、自身が所有する提示装置２に献立アプリをインストールして、献立支援システム１００からサービス提供を受けられるようにしてもよい。この場合、複数のユーザ５のユーザＩＤが１つのグループ（家族）として構成されていることを示すグループ情報の設定を、サーバ１に登録できてもよい。献立提案は、家族単位で、各ユーザ５の提示装置２にて出力されてもよい。

特にユーザ５と提案提供者との間でサブスクリプション方式による１ヵ月単位の定額制の献立提案サービスの契約が締結されているため、サーバ１は、ユーザ５との契約内容に関する情報も、ユーザＩＤと対応付けして管理している。具体的には、サーバ１は、そのユーザ５から支払い受ける月額食費、及び対象期間Ｔ１に関する情報も管理している。対象期間Ｔ１は、例えば１ヵ月単位で自動継続される契約が成され得る。

上述したユーザ５に関する情報は、ユーザデータＭ２（図１参照）としてサーバ１で管理される。なお、サーバ１は、住宅２００以外のユーザ５（例えば他の住宅）への献立情報のサービス提供も行っていて、他のユーザ５の情報も収集して、ユーザデータＭ２として管理する。

サーバ１は、図１に示すように、通信部１０と、制御部Ｃ１と、記憶部１５とを備えている。

通信部１０は、ネットワークＮＴ１を介して、ユーザ５の提示装置２及び調理家電、並びに食配事業者３が運用する外部サーバ又はスマートフォン等の情報端末と、双方向に通信するための通信インタフェースである。通信部１０は、ユーザが個別に取得した食材に関する食材情報を取得する取得部に相当する。

記憶部１５は、読み書き可能なメモリで構成されている。記憶部１５は、例えばフラッシュメモリである。記憶部１５は、制御部Ｃ１の外部に設けられているが、制御部Ｃ１の内部に設けられていてもよい。すなわち、記憶部１５は、制御部Ｃ１の内蔵メモリであってもよい。記憶部１５は、種々のデータを記憶する。特に記憶部１５は、図１に示すように、飲食物データＭ１、及びユーザデータＭ２を記憶（格納）している。

制御部Ｃ１は、サーバ１の全体的な制御処理を行うように構成される。制御部Ｃ１は、例えば、１以上のプロセッサ（マイクロプロセッサ）と１以上のメモリとを含むコンピュータシステムにより実現され得る。つまり、１以上のプロセッサが１以上のメモリに記憶された１以上のプログラム（アプリケーション）を実行することで、制御部Ｃ１として機能する。プログラムは、ここでは制御部Ｃ１のメモリに予め記録されているが、インターネット等の電気通信回線を通じて、又はメモリカード等の非一時的な記録媒体に記録されて提供されてもよい。

ここで制御部Ｃ１は、図１に示すように、処理部１１と、評価部１２と、条件設定部１３と、学習部１４とを有している。言い換えると、制御部Ｃ１は、処理部１１としての機能、評価部１２としての機能、条件設定部１３としての機能、及び学習部１４としての機能を有している。

評価部１２は、対象期間Ｔ１に対する食費に関する目標値Ａ１に基づいて、献立に関する評価（処理）を行うように構成される。ここでは評価処理の実行タイミングは、基本的には、提示装置２から献立要求信号を受信したタイミングを想定する。しかし、評価処理の実行タイミングは、特に限定されず、評価部１２は、定期的に（例えば毎日０時に）契約している全ユーザ５分の献立に関する評価を自動的に行い、その評価結果をユーザ５と対応付けてユーザデータＭ２として記憶部１５に記憶してもよい。

評価部１２は、提示装置２から献立要求信号を受信すると、献立要求信号に基づき、対象期間Ｔ１（ここでは４月１日～４月３０日）を特定する。上述の通り、ユーザ５と提案提供者との間では、例えば、サブスクリプション方式により１ヵ月単位の定額制による献立提案サービスの契約が締結されており、対象期間Ｔ１は、契約に基づく１ヵ月単位の期間である。献立要求信号を受信したタイミングが、対象期間Ｔ１（４月１日～４月３０日）の開始より前（例えば３月３０日）であれば、評価部１２は、「初回提案」用に、契約単位の期間である対象期間Ｔ１全体の献立に関する評価を一度行う。ここで評価部１２は、献立要求信号に含まれるユーザＩＤに基づき、そのユーザ５に対応する月額食費（ここでは３万円）に関する情報を記憶部１５のユーザデータＭ２から抽出し、その月額食費を目標値Ａ１に設定する。

評価部１２は、提案する献立の食費が対象期間Ｔ１の全体の目標値Ａ１を超えないという条件（以下、「目標条件」という）を満たすように、４月１日～４月３０日の３０日分の毎日の一食ごとの献立を決定する。例えば評価部１２は、目標値Ａ１（３万円）÷対象期間Ｔ１の日数（３０日）により、１日概ね１０００円以内に収めるように献立を決定する。評価部１２は、そのユーザ５の契約内容に応じて、朝、昼、晩の全三食分の献立提案を行ってもよいし、晩のみの献立提案を行ってもよい。

評価部１２は、飲食物データＭ１に基づき、１日概ね１０００円以内に収めるように献立を決定する。なお、必ずしも全日数が平均値の１０００円以内になる必要はない。提示装置２を通じてユーザ５からの指定があれば、平日は、８５０円以内といった少し低めの献立に設定され、土日祝日（又は特別な日）は１２００円以内といった少し高めの献立に設定されるように調整があってもよい。

学習部１４は、ユーザ５に関する履歴情報が持つ構造、特徴を分析してクラスタリング等を行い、ユーザ５ごと（家庭等のグループ単位でもよい）の、機械学習のモデルを生成する。生成されたモデルは、ユーザＩＤと対応付けしてユーザデータＭ２として、記憶部１５に記憶される。評価部１２は、学習部１４が生成したモデルも考慮することで、そのユーザ５の生活パターン及び嗜好により合った献立組立て案を生成する。履歴情報が持つ特徴の例としては、例えば、ユーザ５が体重又は血圧を気にして低カロリー又は減塩のメニューが採用されやすい傾向が強いという特徴、ユーザ５が土曜日の夕飯を軽食で済ませる傾向が強いという特徴等があり得る。

条件設定部１３は、条件情報Ｄ１を設定するように構成される。評価部１２は、目標条件を満たしつつ、条件設定部１３が設定した条件情報Ｄ１に基づいて献立を決定する。ここでいう条件情報Ｄ１は、図３Ｂに示すように、ユーザ５の生活パターン（生活習慣、生活リズム）、ユーザ５の嗜好性、栄養バランス、食材の在庫、及びユーザ５の「こだわり」等に関する情報を含む。また条件情報Ｄ１は、（後述する）ユーザ５から受け付ける献立の変更又はキャンセルに関する情報、及びユーザ５のカレンダー情報も含む。

生活パターン及び嗜好性に関する情報は、ユーザ５が継続的に献立支援システム１００を利用していれば、学習部１４がユーザ５の過去（例えば前月、又は前々月等）の利用実績から抽出する特徴量に基づく情報である。生活パターン及び嗜好性に関する情報は、学習部１４が生成するモデルともリンクしている。

栄養バランスに関する情報は、主食（ごはん、パン）、副菜（野菜、きのこ、いも、海藻）、主菜（肉、魚、卵、大豆）、牛乳・乳製品、及び果物等の割合を、ユーザ５の性別及び年齢に応じて、バランス良く提案するための情報である。評価部１２は、栄養バランスを考慮した献立の評価を行う。

食材の在庫に関する情報は、食配事業者３が管理する食材の在庫とリンクした情報である。サーバ１は、食配事業者３が運用する外部サーバ（又は情報端末）から、ネットワークＮＴ１を介して、食配事業者３が管理している食材の在庫に関する情報（在庫情報）を受信し、飲食物データＭ１として記憶部１５に記憶している。食配事業者３の側で、食材の生産者（例えば農家等）から、新鮮な食材の入荷があれば、都度その入荷情報をサーバ１に送信して、サーバ１は、記憶部１５の飲食物データＭ１を更新する。評価部１２は、在庫情報を考慮した献立の評価を行う。評価部１２は、対象期間Ｔ１における季節もの（旬）の食材が入荷されると、その食材を優先的に使った献立を決定することもある。

また在庫情報は、食配事業者３の在庫だけでなく、ユーザ５の住宅２００側（冷凍・冷蔵庫等）で保管している食材の在庫に関する情報も含む。言い換えると、サーバ１は、食配等によりユーザ５に届けられた食材の在庫も、ユーザデータＭ２として記憶部１５に記憶している。

評価部１２は、食材に関する管理期限も考慮して評価を行う。ここでいう管理期限は、例えば、消費期限（又は賞味期限）を想定するが、ユーザ５又は食配事業者３が任意に設定した期限でもよい（例えば消費期限より手前に設定した期限等）。サーバ１は、上述の通り、食配事業者３やユーザ５における食材の在庫を管理しており、評価部１２は、消費期限が近い食材を優先的に用いたレシピの献立の評価を行う。

飲食物データＭ１は、食配事業者３の在庫情報以外にも、調理メニュー及びレシピに関するマスタ情報も含む。サーバ１は、外部のサーバ又は個人から投稿される新しい調理メニュー及びレシピに関する情報を取得すると、飲食物データＭ１を更新する。

さらに飲食物データＭ１は、ユーザ５が自宅で調理する調理メニュー及びレシピに関する情報だけでなく、外食（又は中食）に関する情報も含む。サーバ１は、飲食店７（図１参照）を含む複数の外食店に関するグルメ情報、予約情報及びクーポン情報等といった外食情報を統合的に管理し様々なサービス提供をしている外部のサーバと連携している。サーバ１は、外食情報も、飲食物データＭ１として記憶部１５に記憶している。

ユーザ５の「こだわり」に関する情報は、ユーザ５が提示装置２を通じて適宜に入力される情報である。「こだわり」に関する情報は、ある食材の「好き嫌い」を指定する情報、カロリーや塩分、糖質等に配慮した「栄養改善目標」を指定する情報、及び、子供や老年者を含む「家族構成」といった情報である。評価部１２は、ユーザ５の「こだわり」を考慮した献立の評価を行う。

処理部１１は、評価部１２の結果に基づいて所定の処理を行うように構成される。ここでいう「所定の処理」は、基本処理として、評価部１２の結果に関する情報（献立）を、情報端末（ユーザ５の提示装置２）に送信して提示させる処理を含む。また「所定の処理」は、評価部１２の結果、すなわち「提案履歴」をユーザＩＤと対応付けして、記憶部１５のユーザデータＭ２に記憶させる処理を更に含む。

処理部１１は、評価部１２で決定された献立に関する献立情報（調理メニュー及びレシピに関するテキスト情報及び画像情報）を含む信号（献立提示信号）を生成して、通信部１０を介して献立要求信号の送信元であるユーザ５の提示装置２へ送信する。処理部１１は、献立提示信号を提示装置２に送信して、提示装置２の出力部２５から献立情報を出力させる。ただし、対象期間Ｔ１が１ヵ月（４月１日～４月３０日）といったように比較的長期間である場合、各家庭にとっては、１週間以上先の献立提案までは望まない場合もある。処理部１１は、対象期間Ｔ１にわたる評価部１２の結果（献立）を記憶部１５に記憶しつつも、提示装置２に提示させる献立については、１週間分又は１０日分等のように小分けにして献立提示信号に含めて送信してもよい。

提示装置２の通信部２１は、献立提示信号を受信すると、制御部２２は、出力部２５として機能する表示部２５Ａの表示画面に、献立情報を表示させる。献立情報は、表示部２５Ａの表示画面において、日にちごと（又は曜日ごと）、並びに朝食、昼食、及び夕食ごと（一食ごと）に、調理メニューと、その調理メニューに対応する合計の食費代とが分かるように表示される。ユーザ５が、メニュー名の表示領域又はメニューの画像領域にタップ操作等を行うことで、更に詳細な情報（調理に必要な食材名及び分量に関する情報、食材費、調理方法（どの調理家電を使用するか等）、及び塩分やカロリー等の情報）が表示され得る。

ユーザ５は、対象期間Ｔ１（４月１日～４月３０日）の献立のうち、例えば４月１日～７日までの７日分に関する献立について採用の意思を示す操作入力を入力部２４に行うと、提示装置２は、その採用結果を含む献立採用信号を生成してサーバ１に送信する。この場合、提示装置２は、４月８日～４月３０日の献立については保留（採用でも不採用でもない）という結果を献立採用信号に含める。

サーバ１では、献立採用信号を受信すると、処理部１１は、提案した献立に対するユーザ５の採用／不採用履歴（実績）をユーザＩＤと対応付けして、記憶部１５のユーザデータＭ２に記憶させる。さらに処理部１１は、採用を示す献立に対応する食材Ｂ１の配達に関する要求処理を実行する。言い換えると、献立支援システム１００は、提案した献立について採用を示すユーザ入力を受け付けた場合、献立に対応する食材Ｂ１の配達に関する要求処理を実行する。具体的には、処理部１１は、食配事業者３が運用する外部サーバ（又は情報端末）に、ユーザ５が採用を示した献立で使用する食材Ｂ１に関する情報（食材名及び分量等）、及び配達先（ユーザ５の氏名、住所、電話番号等）を含む配達要求信号を送信する。献立提供者は、食配事業者３に対して、ユーザ５から支払われる定額３万円の中から、配達の対象となった食材Ｂ１の食材費をユーザ５に代わって支払う（決済の代行）。

そして、食配事業者３は、サーバ１から受信した配達要求信号にて指定された配達先へ、食材Ｂ１を配達する。食材Ｂ１は、遅くても４月１日の調理に間に合うように配達されることが好ましい。

献立提案システム（サーバ１）は、提示装置２の入力部２４を通じて、提案した献立の内容のうち少なくとも一部の内容の変更（レシピ単位でもよい）を示すユーザ入力を受け付けることも可能である。また献立提案システム（サーバ１）は、提示装置２の入力部２４を通じて、諸事情（出張や旅行で不在、又は外食予定等）により、１日～数日分の献立、或いはある１日の一食分の献立をキャンセルするというユーザ入力を受け付けることも可能である。

提示装置２は、そのような内容の変更又はキャンセルに関する結果も献立採用信号に含めてサーバ１に送信する。サーバ１は、そのような内容の変更又はキャンセルに関する結果も、ユーザ５の採用／不採用履歴（実績）として記憶部１５のユーザデータＭ２に記憶させる。

提示装置２は、出力部２５から、提案した献立について採用、変更、又はキャンセル等に関する操作入力をユーザ５に催促するメッセージ（文字列データ又は音声データ）を出力することが好ましい。

さらに献立提案システム（サーバ１）は、提示装置２の入力部２４を通じて、提案される全献立の見直しを要求するユーザ入力を受け付けることも可能である。サーバ１は、提示装置２から全献立の見直し要求に関する信号を受信すると、評価部１２に、最初に提案した献立とは異なる内容の献立を作成させて、再度提示装置２に表示させる。

ここで評価部１２は、提案した献立の内容のうち少なくとも一部の内容の変更を示すユーザ入力を受け付けた場合、その変更後の献立の内容が、目標値Ａ１及び食材の栄養バランスを満たすか否かについて評価する。例えば、ある１日の夕飯を調理メニュー（Ａ）から、調理メニュー（Ｂ）に変更するユーザ入力を付け付けた場合、調理メニュー（Ｂ）の食材費が高く、目標条件を満たしにくくなる場合がある。或いは、変更された調理メニュー（Ｂ）は、数日前の夕飯のメニューと同じであれば、栄養バランスに偏りが出る可能性がある。献立提案システム（サーバ１）は、目標値Ａ１及び栄養バランスを満たさないと評価した場合、目標値Ａ１及び栄養バランスを満たすような別の献立を作成して再提案する（例えば、調理メニュー（Ｂ）で使用する食材を少し変更する等）。献立提案システム（サーバ１）は、評価部１２の評価結果を通知する通知部（ここでは通信部１０に相当）を備えている。そして、献立提案システム（サーバ１）は、ユーザ５が変更した内容では目標値Ａ１及び栄養バランスを満たしにくいことを、通信部１０（通知部）を介して、提示装置２からアラートし、さらに再提案の献立を提示する。言い換えると、「所定の処理」は、目標値Ａ１及び栄養バランスを満たさないと評価された場合に、目標値Ａ１及び栄養バランスを満たす献立について再提案する処理を更に含む。

上の例では、調理メニューの単位による変更例を説明したが、調理メニューのレシピ単位でもよい。例えば、調理メニュー（Ａ）で使用する食材（Ｃ）を、食材（Ｃ）とは生産地が異なる食材（Ｄ）に変更したり、或いは食材（Ｃ）を、有機栽培された食材（Ｅ）に変更したりすることも可能である。

ところで、提案した献立に対してユーザ５が一部不採用とする場合がある。例えば、４月３日に外食予定があることが事前に分かっていれば、その日の献立で使用する食配は不要となる。そのため、ユーザ５は、提案を受けた時点（例えば３月３０日）で、４月３日の献立を事前にキャンセル（不採用）することを示す入力を行うことになる。

「初回提案」は、対象期間Ｔ１の開始より前に行われる可能性が高い提案であるため、その時点では、対象期間Ｔ１内におけるユーザ５へ献立を提案した提案履歴、及び提案した献立に対するユーザ５の採用／不採用履歴（実績）は存在しない。したがって、評価部１２は、「初回提案」では、対象期間Ｔ１内の履歴情報（ここでいう履歴は、上述した前月又は前々月の利用実績といった対象期間Ｔ１より前の履歴とは異なる）を用いずに献立を決定する。

次に「期間内提案」のケースを説明する。評価部１２は、対象期間Ｔ１の途中における任意のタイミングｔ１（図３Ａ参照）において献立に関する（再）評価を行うように構成される。そして、評価部１２は、対象期間Ｔ１の開始からタイミングｔ１までの間において、提案された献立の内容に関する第１情報（提案履歴）と、提案された献立に対する実績に関する第２情報とに基づいて評価を行う。つまり、「初回提案」とは違って「対象期間Ｔ１の途中」であることから、対象期間Ｔ１の開始からタイミングｔ１までの履歴情報（第１情報及び第２情報）が存在する。ここでは、第２情報は、提案された献立におけるレシピごと（具体的には調理メニューの食材ごと）の実績に関する。

例えば、ユーザ５が、図３Ａに示すように、４月７日の時点（タイミングｔ１）において（７日当日分の献立は採用済みとする）、提示装置２の入力部２４を通じて、献立提案を所望するための操作入力を行ったとする。すると、サーバ１の評価部１２は、「初回提案」で説明した条件情報Ｄ１に加えて、対象期間Ｔ１の開始からタイミングｔ１までの第１情報及び第２情報に基づいて、４月８日以降の献立について再評価する。

言い換えると、評価部１２は、第１情報及び第２情報に加えて、食材の栄養バランス及びユーザの嗜好性のうち少なくとも一方（ここでは両方）に関連する条件情報Ｄ１に基づいて、評価を行う。そのため、さらに提案する献立内容の改善を図ることができる。また評価部１２は、第１情報及び第２情報に加えて、食材に関する管理期限に基づいて、評価を行う。そのため、管理期限が切れてしまう食材の発生を抑えつつ、提案する献立内容の改善を図ることができる。

具体的には、評価部１２は、４月１日～４月７日までの第２情報に基づき、その期間内の食費を割り出し、定額の３万円（目標値Ａ１）から、割り出した食費を差し引き、その残額に基づいて、タイミングｔ１以降の期間における献立を再評価（再演算）する。

簡単な例で言えば、献立提案システム（サーバ１）が、４月１日～４月７日の７日間について１日１０００円の食費の献立を提案していて、それに対してユーザ５が、提案されたその７日間の献立をそのまま採用したとする。評価部１２は、３００００－１０００×７＝２３０００円（残額）に基づき、４月８日以降の残りの期間Ｔ２（図３Ａ参照）に関する献立を再評価する。つまり、評価部１２は、「初回提案」時に決定して記憶部１５に記憶した「提案履歴」における「４月８日～４月３０日」の献立に比べて、タイミングｔ１の時点の状況により沿った内容となるように献立を再評価する。

ただし、実際には上述のような簡単な例に留まらず、目標条件を満たす限り、提案される毎日の献立の食費は、均一に１０００円というわけではなく、９５０円の日もあれば、１０５０円の日もあり得る。また４月１日～４月７日までの提案した献立に対してユーザ５が一部キャンセルしていた場合がある。例えば、４月１日～４月７日までの提案した献立に対して、４月３日に外食予定があれば、提案を受けた時点（例えば３月３０日）で、４月３日の献立を事前にキャンセル（不採用）し、４月３日を除く６日分の献立を採用していた場合がある。

処理部１１は、任意のタイミングｔ１の時点で、第１情報（提案履歴）と第２情報（採用／不採用履歴）との差分に基づき、献立のキャンセルを受け付けていれば、例えば、ユーザ５がその日外食（又は中食）をしたと見なす。そして、処理部１１は、キャンセルされた献立の食費（例えば１０００円）を、タイミングｔ１以降の残りの期間Ｔ２における献立の食費となるように繰り越す。そして、評価部１２は、２３０００＋１０００＝２４０００円（残額）に基づき、タイミングｔ１以降の残りの期間Ｔ２に関する献立を再評価する。結果的に、献立のキャンセルが発生することで、タイミングｔ１以降の残りの期間Ｔ２における献立の内容が、「初回提案」時の献立に比べて、同じ種類の食材でも高品質（高級）な食材に変更して少し豪華な調理メニューに変更され得る。

言い換えると、処理部１１の「所定の処理」は、第１情報と、第２情報との差分に応じた還元に関する処理を含み、この場合の「還元」は、タイミングｔ１以降の献立の食費への差額分の「繰り越し」である。この「繰り越し」は、当月（対象期間Ｔ１）内での繰り越しではなく、翌月（例えば５月）の食費に繰り越されてもよい。

また「還元」は、差額分の繰り越しではなく、差額分に相当するポイントバックという態様で、ユーザ５に戻されてもよい。累積した「ポイント」は、一定のポイントに到達すると、献立提供者が発行する商品カタログに掲載されている商品に交換可能であってもよく、その商品の１つとして、例えば差額分に対応する飲食店７（図１参照）のクーポン券又は割引券であってもよい。クーポン券又は割引券は、郵送される紙の実物でもよいし、データとして管理されていて、提示装置２からクーポン券を飲食店７で使用することを示す入力を行うことで、クーポン券の使用情報をサーバ１から飲食店７側の端末に送信されてもよい。

差分に応じた「還元」が行われた場合（特に食材の品質アップという態様で行われる場合）、献立提案システム（サーバ１）は、その旨を提示装置２からユーザ５に通知する。また献立提案システム（サーバ１）は、還元が「繰り越し」として適用されるか「ポイントバック」として適用されるかの選択を、提示装置２からのユーザ入力によって決定できるように構成される。

献立提案システム（サーバ１）は、還元がポイントバックとして適用される場合、タイミングｔ１以降の残りの期間Ｔ２のどこかで（例えば日曜日等）、ポイントの利用が可能な飲食店７を含む外食を提案してもよい。また上述の通り、提示装置２の検知部２６は、ＧＰＳ等を用いてユーザ５の現在地を検知し、その検知結果に関する情報をサーバ１に送信している。そこで、サーバ１は、例えば、ユーザ５が還元されたポイントの利用が可能な店舗の近くを移動中であれば、その店舗に関する情報をプッシュ通知してもよい。

このように第１情報と第２情報とに差分が生じた場合に、ユーザ５に対して「還元」が行われるため、ユーザ５へ提供するサービスの向上を図ることができる。

ところで、本実施形態のサーバ１は、外食に関して、ポイントバックの適用に関わらず、ユーザ５の嗜好又はユーザ入力等に応じて、適度に外食に関する提案を行う。例えば、サーバ１は、提案した献立についてキャンセルを示すユーザ入力を受け付けた場合、外食に関する提案処理を実行する。またサーバ１は、ユーザ５のカレンダー情報も管理しており、例えば４月２０日は結婚記念日等といった特別な日であることを示す情報が提示装置２を通じて事前に登録されていれば、そのような特別な日に外食を提案する。ユーザ５が外食を採用すれば、上述の通り、ユーザ５に対する還元が行われる。この場合、ユーザ５が調理だけでなく外食という選択を行いやすくでき、利便性が向上される。またサーバ１と外食サービスを提供する飲食店側との連携を行いやすくできる。

またユーザ５は、食配による食材Ｂ１とは別に、食材Ｂ２を店舗４で購入したり、知人や親戚等から貰い受けたりする可能性がある。そこで、本実施形態のサーバ１は、提示装置２を通じて、食配による食材Ｂ１とは別に取得した食材Ｂ２の登録を受け付け可能に構成される。ユーザ５は、提示装置２の入力部２４にて、取得した食材Ｂ２の食材名や、分量、取得日（例えば購入日）、消費期限、（購入した場合は）食材費等の食材情報を入力すると、提示装置２は、食材情報をサーバ１に送信する。購入した食材Ｂ２を包装する包装材等に一次元コード又は二次元コードが付与されている場合、提示装置２の撮像部（カメラ等）で当該コードを読み取ることで、提示装置２は、食材情報をサーバ１に送信してもよい。サーバ１は、食材Ｂ２の食材情報を、上述したユーザデータＭ２におけるユーザ５の在庫情報に反映させる。

そして、本実施形態では、この「食材Ｂ２の食材情報」も、提案された献立に対する実績に関する第２情報に含まれる。サーバ１は、通信部１０を通じて食材情報を取得した場合には、食材情報に相当する費用を、食費（目標値Ａ１）から除き、かつ食材Ｂ２を利用するように献立を提案する。具体的には、評価部１２は、取得した食材情報から食材費を推定し（購入した場合はユーザ入力された食材費を適用）、その食材費をタイミングｔ１以降の献立の食費から差し引いた残額で献立を再評価する。特に、評価部１２は、食材Ｂ２の消費期限も考慮した上で、食材Ｂ２を優先的に利用する献立を提案する。処理部１１は、提案する献立の食材に食材Ｂ２が含まれる場合には、そのことをユーザ５が視覚的に容易に分かる態様で献立を提示装置２に表示させる。ユーザ５が食材Ｂ２を含む献立を採用した場合、処理部１１は、食材Ｂ２を除く食材に関する情報を含む配達要求信号を食配事業者３が運用する外部サーバ（又は情報端末）に送信する。この場合、食材Ｂ２を利用した献立も提案されるため、対象期間Ｔ１に対する目標値Ａ１を厳守しつつ、食材Ｂ２の無駄を無くしやすくできる。

またユーザ５は、提案された献立に対して採用を示して実際に食材Ｂ１も配達されたものの、その後急遽、外食又は中食を取ったことに起因して、ある日の一食分の献立の調理をしなかった（実績）という状況が発生する可能性もある。本実施形態のサーバ１は、対象期間Ｔ１の途中の任意のタイミングｔ１で、提示装置２へのユーザ入力を通じて、「事後キャンセル」も受け付けるように構成される。この場合、該当する日の献立に対応する食材Ｂ１が未だユーザ５の側で消費されずに保管されていることになる。そのため、サーバ１は、事後キャンセルに関する情報を受信すると、ユーザデータＭ２におけるユーザ５の在庫情報を修正する。更にサーバ１は、その食材Ｂ１の消費期限を考慮した上で、急遽未消費となった食材Ｂ１を優先的に利用するように、タイミングｔ１以降に関する献立を再評価する。またこの場合、外食を証明する情報（飲食店７が発行した領収書に関する情報等）がサーバ１に送信されると、事後キャンセルの対象となった献立の食材費に相当する還元が、ユーザ５に対して行われてもよい。

なお、対象期間Ｔ１の途中の任意のタイミングｔ１に、提案した献立の内容のうち少なくとも一部の内容の変更を示すユーザ入力を受け付けた場合、評価部１２は、その変更後の献立の内容が、目標値Ａ１及び食材の栄養バランスを満たすか否かについて評価する。この変更は、提案された献立に対して未だ採用を示す入力を行っていない保留状態の献立、つまり未だ食材が配達（購入）されていない献立に対する変更であり、「事前変更」に相当する。サーバ１は、目標値Ａ１及び栄養バランスを満たさないと評価された場合、その旨を提示装置２の出力部２５からアラート（通知）する。さらにサーバ１は、タイミングｔ１以降の残りの期間Ｔ２に対して、目標値Ａ１及び食材の栄養バランスを満たすような別の献立を作成して再提案する。再提案の献立は、提示装置２の出力部２５から提示される。言い換えると、「所定の処理」は、目標値Ａ１及び栄養バランスを満たさないと評価された場合に、タイミングｔ１以降の残りの期間Ｔ２に対して、目標値Ａ１及び栄養バランスを満たす献立について再提案する処理を更に含む。

さらにユーザ５は、提案された献立に対して採用を示して実際に食材Ｂ１が配達されたものの、ある１日の一食に関して提案されていた調理メニュー（Ａ）を、急遽、調理メニュー（Ｂ）に変更した（実績）という状況が発生する可能性もある。本実施形態のサーバ１は、対象期間Ｔ１の途中の任意のタイミングｔ１で、提示装置２へのユーザ入力を通じて、「事後変更」も受け付けるように構成される。この場合、タイミングｔ１の時点で、ユーザ５の側で実際に保管されている食材と、サーバ１の側で管理するユーザ５の在庫情報とに差異が生じている可能性が高い。そのため、サーバ１は、事後変更に関する情報を受信すると、ユーザデータＭ２におけるユーザ５の在庫情報を修正し、食材Ｂ１の消費期限を考慮した上で、タイミングｔ１以降に関する献立を再評価する。

このように本実施形態では、対象期間Ｔ１の途中の任意のタイミングｔ１において、第１情報と第２情報とに基づき、献立を再評価し、タイミングｔ１以降の残りの期間Ｔ２に対する献立の内容を変更する。言い換えると、処理部１１の所定の処理は、対象期間Ｔ１のうち、タイミングｔ１以降の残りの期間Ｔ２に対する献立の内容を変更する処理を含む。

なお、契約開始日が月の途中から始まる場合、その月だけ対象期間Ｔ１は、開始日から月末までとなり、初回提案は、開始日の数日前となり、目標値Ａ１も開始日から月末までの食費となり得る。

ところで、上述した対象期間Ｔ１の途中の任意のタイミングｔ１は、ユーザ５からの提示装置２の入力部２４を通じて、献立の提案、変更、又はキャンセル等を所望するための操作入力を受け付けたタイミングであった。つまり、タイミングｔ１は、ユーザ５からの能動的なアクションに依存するタイミングであった。しかし、タイミングｔ１は、ユーザ５にとって受動的なタイミングにもなり得る。本実施形態のサーバ１は、特定の食材に関する費用が仕入れにより変動したという情報を取得すると、ユーザが未購入の食材を利用している献立について再提案する。

例えば農作物の豊作又は不作によって同じ種類の食材でも価格が変動し得る。サーバ１は、食配事業者３から食材の価格変動に関する情報を取得すると、評価部１２は、ユーザ５に提案済みで、かつ採用を保留した状態にある献立を再評価する。具体的には、提案済みの献立内に雨天続きにより不作となり価格が高騰した特定の食材が存在していれば、その食材の使用を避けて献立を立案する。逆に豊作により価格が下落した特定の食材が存在していれば、その食材を使用した献立を立案する。そして、処理部１１は、食材の価格変動に応じて献立を再評価した旨を、プッシュ通知等によって提示装置２から知らせる。したがって、価格変動する食材に追従した、より良い献立提案を行える。

なお、特定の食材に関して価格が安くなった場合、その差額を上述したポイントバックによってユーザ５に還元されてもよい。

（２．３）動作説明
以下、本実施形態における献立支援システム１００の動作について、図４を参照しながら簡単に説明する。以下の動作説明における順序は、単なる一例であって特に限定されない。なお、以下では、対象期間Ｔ１の途中の任意のタイミングｔ１で献立提案が要求される場合について説明する。

住宅２００内において、調理者Ｘ１であるユーザ５は、提示装置２にて献立アプリを起動して自分のユーザＩＤ及びパスワードを入力してログインする。さらにユーザ５は、献立アプリを通じて、献立の提案を要求する操作入力を行う。提示装置２は、ユーザ５からの操作入力に応じて、サーバ１に献立要求信号を送信する。

サーバ１は、献立要求信号を受信する（ステップＳ１）。サーバ１は、タイミングｔ１の時点における献立に関する評価を行う。サーバ１は、そのユーザＩＤに対応する第１情報（提案履歴）と第２情報（採用／不採用履歴）とに基づいて献立の再評価を行う（評価ステップ）。すなわち、サーバ１は、タイミングｔ１の時点での、第１情報及び第２情報に基づいて、そのユーザＩＤに対応する食費の残額を演算し、またタイミングｔ１以降における一食当たりの食費を算出する（ステップＳ２）。そして、サーバ１は、一食当たりの食費を目安に、ユーザ５に関する条件情報Ｄ１及び（機械学習の）モデルに基づき、タイミングｔ１以降に関する献立組合せ案を生成する（ステップＳ３）。

そして、サーバ１は、生成した献立組合せ案に基づき、対象期間Ｔ１の食費の総額を演算する（ステップＳ４：評価計算）。サーバ１は、新たに提案する献立組合せ案の食費を含む対象期間Ｔ１の食費の総額が、目標値Ａ１を超えないという「目標条件」が満たされるまで（ステップＳ５）、献立組合せ案を生成し、評価計算を実行する。すなわち、サーバ１は、評価結果が「目標条件」を満たしていなければ（ステップＳ５：Ｎｏ）、ステップＳ３に戻り、別の献立組合せ案を生成する。

サーバ１は、評価結果が「目標条件」を満たしていれば（ステップＳ５：Ｙｅｓ）、提示装置２からその献立組合せ案を提案（表示）する（ステップＳ６：処理ステップ）。すなわち、サーバ１は、献立提示信号を提示装置２に送信する。

提示装置２は、献立提示信号を受信すると、提案された献立を表示部２５Ａに表示させる。ユーザ５は、提案された献立を採用（又は変更、キャンセル等）するための操作入力を行うと、献立採用信号を生成してサーバ１に送信する。

サーバ１は、献立採用信号を受信すると（ステップＳ７）、献立採用信号に応じて（採用した献立があれば）、食配事業者３に食配を依頼する（ステップＳ８）。すなわち、サーバ１は、配達要求信号を生成して食配事業者３側の端末に送信する。

このように本実施形態のサーバ１（献立提案システム）によれば、任意のタイミングｔ１における献立を（再）評価する際に、タイミングｔ１までに提案した献立（提案履歴）及び献立に対する実績（採用／不採用履歴）に基づいて（再）評価する。そして、（再）評価の結果に基づいて所定の処理（提案の実行）が行われる。そのため、日々変化する要素（食費の残額等）に加えて、対象期間Ｔ１内における過去の提案履歴、及び採用／不採用履歴が反映された最新の献立提案を行える。結果的に、提案する献立内容の改善を図ることができる、という利点がある。

特に調理者Ｘ１（ユーザ５）にとっては、様々な要素（家族の好み、栄養バランス、食材の消費期限、月の食費代、メニューの偏り）を考慮した上で、日々の献立を立案して、食材の買い物をすることは、大きな負担となり得る。しかし、本実施形態の献立提案システムを利用することで、調理者Ｘ１（ユーザ５）の負担を軽減できる。

（３）変形例
上記実施形態は、本開示の様々な実施形態の一つに過ぎない。上記実施形態は、本開示の目的を達成できれば、設計等に応じて種々の変更が可能である。また、上記実施形態に係る献立提案システム（サーバ１）、提示装置２、及びこれらを備える献立支援システム１００と同様の機能は、情報提示方法、コンピュータプログラム、又はコンピュータプログラムを記録した非一時的記録媒体等で具現化されてもよい。

例えば、献立支援システム１００における提示装置２の機能は、提示装置２の処理方法、コンピュータプログラム、又はコンピュータプログラムを記録した非一時的記録媒体等で具現化されてもよい。提示装置２の処理方法は、献立に対する実績を取得するステップと、実績をサーバ１に送信するステップと、評価の結果に関する情報をサーバ１から受信するステップと、評価の結果に関する情報を出力するステップと、を含む。提示装置２の機能は、提示装置２の１以上のプロセッサに、上記の処理方法を実行させるプログラムで具現化され得る。

以下、上記実施形態の変形例を列挙する。以下に説明する変形例は、適宜組み合わせて適用可能である。以下では、上記実施形態を「基本例」と呼ぶこともある。

本開示における献立提案システム（サーバ１）、提示装置２、及びこれらを備える献立支援システム１００は、コンピュータシステムを含んでいる。コンピュータシステムは、ハードウェアとしてのプロセッサ及びメモリを主構成とする。コンピュータシステムのメモリに記録されたプログラムをプロセッサが実行することによって、本開示における献立提案システム（サーバ１）、提示装置２、及びこれらを備える献立支援システム１００としての機能が実現される。プログラムは、コンピュータシステムのメモリに予め記録されてもよく、電気通信回線を通じて提供されてもよく、コンピュータシステムで読み取り可能なメモリカード、光学ディスク、ハードディスクドライブ等の非一時的記録媒体に記録されて提供されてもよい。コンピュータシステムのプロセッサは、半導体集積回路（ＩＣ）又は大規模集積回路（ＬＳＩ）を含む１ないし複数の電子回路で構成される。ここでいうＩＣ又はＬＳＩ等の集積回路は、集積の度合いによって呼び方が異なっており、システムＬＳＩ、ＶＬＳＩ（Very Large Scale Integration）、又はＵＬＳＩ（Ultra Large Scale Integration）と呼ばれる集積回路を含む。さらに、ＬＳＩの製造後にプログラムされる、ＦＰＧＡ（Field-Programmable Gate Array）、又はＬＳＩ内部の接合関係の再構成若しくはＬＳＩ内部の回路区画の再構成が可能な論理デバイスについても、プロセッサとして採用することができる。複数の電子回路は、１つのチップに集約されていてもよいし、複数のチップに分散して設けられていてもよい。複数のチップは、１つの装置に集約されていてもよいし、複数の装置に分散して設けられていてもよい。ここでいうコンピュータシステムは、１以上のプロセッサ及び１以上のメモリを有するマイクロコントローラを含む。したがって、マイクロコントローラについても、半導体集積回路又は大規模集積回路を含む１ないし複数の電子回路で構成される。

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

基本例では、食費に関する目標値Ａ１は、定額の金額（３万円）であった。しかし、献立提案システムは、ユーザ５が、目標値Ａ１を、例えば月の単位で変更できてもよい。例えば４月の目標値Ａ１は３万円で、５月の目標値Ａ１は４万円でもよい。また目標値Ａ１は、金額であることに限定されず、金額が別の形態に換算されたもの（ポイント等）でもよい。

基本例では、食配サービスと連携したサブスクリプションを前提に説明したが、特に限定されない。例えば、献立提案システムは、対象期間Ｔ１における献立を提案すると、ユーザ５が自身で全ての食材を購入してもよい。この場合、ユーザ５は、献立提案者に対して、献立提案システムに関する（食材費を含まない）使用料だけを支払うことになる。

（４）実施例
以下、上記実施形態における第１実施例～第４実施例について列挙する。以下に説明する各実施例においては、上記実施形態と共通する点については説明を省略する。まず、各実施例に共通する構成について図５を用いて説明する。図５は、一実施形態の第１実施例～第４実施例に係る献立提案システム（ここではサーバ１）のブロック構成図である。なお、図５では、図１に示す構成のうち、第１実施例～第４実施例の説明で登場しない構成については省略している。また、図５では、提示装置２はネットワークＮＴ１に直接接続されているが、ルータ６を介して接続されていてもよい。

サーバ１は、通信部１０と、処理部１１と、評価部１２と、記憶部１５と、を備える。また、通信部１０は、以下に説明する目標値取得部１０１の機能と、実績取得部１０２の機能と、費用情報取得部１０３の機能と、を有している。なお、以下では、上記実施形態において処理部１１が実行していた「所定の処理」の少なくとも一部の処理は、第１実施例～第４実施例においては評価部１２が実行することとして説明する。

目標値取得部１０１は、対象期間Ｔ１に対する食費に関する目標値Ａ１を取得する。ここでは、目標値取得部１０１は、ユーザ５が献立提供者との契約を行う時点で、例えばユーザ５が所有する提示装置２との間で通信することにより、目標値Ａ１を取得する。具体的には、ユーザ５は、提示装置２の入力部２４において、目標値Ａ１を設定する入力操作を行う。すると、提示装置２は、入力部２４が受け付けた目標値Ａ１を通信部２１を介してサーバ１へ送信する。これにより、目標値取得部１０１は、目標値Ａ１を取得する。以降、目標値取得部１０１は、ユーザ５と献立提供者との契約が終了するまでの間において、ユーザ５が目標値Ａ１を変更する場合に限り、目標値Ａ１を取得することになる。

実績取得部１０２は、対象期間Ｔ１の途中における任意のタイミングｔ１において、評価部１２が提案した献立に対する実績をユーザ５から取得する。ここでは、実績取得部１０２は、例えばユーザ５が所有する提示装置２との間で通信することにより、実績を取得する。具体的には、ユーザ５は、任意のタイミングｔ１において、提示装置２の入力部２４にて実績を入力する操作を行う。すると、提示装置２は、入力部２４が受け付けた実績を通信部２１を介してサーバ１へ送信する。これにより、実績取得部１０２は、実績を取得する。

実績は、評価部１２が提案した献立に対するユーザ５の採用／不採用の履歴を含む。具体的には、実績には、提案された献立をユーザ５が採用したという実績、提案された献立をユーザ５が不採用にした（キャンセルした）という実績、提案された献立の内容の一部（例えば食材の一部）を変更した上で採用したといった実績が含まれ得る。この変更した食材には、ユーザ５が個別に取得した食材Ｂ２が含まれ得る。

費用情報取得部１０３は、食材に関する費用についての費用情報を取得する。ここでは、費用情報は、食材の仕入れ値の予測値を含む。具体的には、費用情報取得部１０３は、例えばインターネット等のネットワークＮＴ１を介して、食材についての食配事業者３の過去の販売計画若しくは今後の販売計画、卸売市場の卸値の過去の変動情報若しくは今後の予測変動情報、食材の産地における気象情報若しくは気象予測情報、又は食材の産地における過去の出荷実績、出荷計画、若しくは出荷予測情報等を取得する。そして、費用情報取得部１０３は、これらの情報を総合考慮して、食材の仕入れ値の予測値を算出することにより取得する。なお、費用情報取得部１０３は、食材の仕入れ値の予測値を提供するサービス事業者から、食材の仕入れ値の予測値を取得してもよい。

処理部１１は、評価部１２が提案した献立をユーザ５に提示する。ここでは、処理部１１は、例えばユーザ５が所有する提示装置２との間で通信することにより、評価部１２が提案した献立を提示装置２へ送信する。これにより、提示装置２では、評価部１２が提案した献立が出力（提示）される。ここでいう「評価部１２が提案した献立」は、後述する初回提案機能により「初回提案」された献立の他、後述する期間内提案機能により「期間内提案」された献立、言い換えれば対象期間Ｔ１の途中において再提案された献立を含み得る。

評価部１２は、初回提案機能と、期間内提案機能と、還元機能と、を有する。初回提案機能は、対象期間Ｔ１が開始される以前において、目標値取得部１０１が取得した目標値Ａ１を超えないように、記憶部１５に記憶されている飲食物データＭ１に基づいて、対象期間Ｔ１における献立を提案する、つまり「初回提案」を行う機能である。言い換えれば、初回提案機能においては、評価部１２は、目標値取得部１０１が取得した目標値Ａ１に基づいて、対象期間Ｔ１における献立を提案する。

期間内提案機能は、対象期間Ｔ１の途中における任意のタイミングｔ１において、実績取得部１０２が取得した実績に基づいて、残りの期間Ｔ２における献立を再提案する、つまり「期間内提案」を行う機能である。具体的には、評価部１２は、対象期間Ｔ１の開始からタイミングｔ１までの間において、評価部１２が提案した献立（つまり、初回提案した献立）の内容に関する第１情報と、実績取得部１０２が取得した実績に関する第２情報と、を比較する。そして、評価部１２は、第１情報と第２情報とに差分がある場合、対象期間Ｔ１のうちのタイミングｔ１以降の残りの期間Ｔ２に対する献立の内容を変更して再提案する再提案処理を実行する。ここで、第１情報と第２情報との差分は、例えば献立を採用しなかったり、献立の一部を変更して採用したり等する場合に生じ得る。

還元機能は、期間内提案機能と同様に、対象期間Ｔ１の途中における任意のタイミングｔ１における、実績取得部１０２が取得した実績に基づいた機能である。還元機能においては、評価部１２は、期間内提案機能とは異なり、第１情報と第２情報とに差分がある場合、差分に応じたユーザ５に対する還元に関する還元処理を実行する。還元処理は、タイミングｔ１以降の献立の食費への差額分の繰り越しであってもよいし、差額分に相当するポイントバックであってもよい。

なお、評価部１２は、初回提案機能及び期間内提案機能のいずれで献立を提案する場合においても、地域情報を考慮してもよい。ここでいう地域情報は、ユーザ５が住む地域の情報であって、当該地域で比較的多く使用される食材、当該地域でのみ生産される食材、当該地域で比較的多く採用される献立、又は当該地域でのみ採用される献立等の情報を含み得る。この場合、ユーザ５には、ユーザ５が住む地域ならではの献立が提案又は再提案されやすくなることから、ユーザ５の要望に見合ったサービスを提供しやすくなり、好ましい。

（４．１）第１実施例
以下、上記実施形態における第１実施例について図６を用いて説明する。図６は、一実施形態の第１実施例に係る献立提案システム（ここではサーバ１）における動作を説明するためのフローチャート図である。第１実施例では、対象期間Ｔ１の途中の任意のタイミングｔ１において、一部の献立をユーザ５がキャンセルしたという実績を実績取得部１０２が取得することとして説明する。

まず、目標値取得部１０１は、対象期間Ｔ１に対する食費に関する目標値Ａ１を取得する（Ｓ１１）。処理Ｓ１１は、献立提案方法における目標値取得ステップＳＴ１に相当する。次に、評価部１２は、初回提案機能により、目標値取得部１０１が取得した目標値Ａ１を超えないように、対象期間Ｔ１における献立を提案する（Ｓ１２）。処理Ｓ１２は、献立提案方法における評価ステップＳＴ２に相当する。そして、処理部１１は、評価部１２が提案した献立を提示装置２へ送信することにより、初回提案された献立をユーザ５に提示する（Ｓ１３）。処理Ｓ１３は、献立提案方法における処理ステップＳＴ３に相当する。

その後、対象期間Ｔ１の途中の任意のタイミングｔ１において、ユーザ５が提示装置２を操作して、評価部１２が提案した献立に対する実績を入力したこととする。すると、実績取得部１０２は、タイミングｔ１において当該実績をユーザ５から取得する（Ｓ１４）。処理Ｓ１４は、献立提案方法における実績取得ステップＳＴ４に相当する。

そして、評価部１２は、対象期間Ｔ１の開始からタイミングｔ１までの間における、評価部１２が提案した献立の内容に関する第１情報と、実績取得部１０２が取得した実績に関する第２情報とを比較する（Ｓ１５）。比較の結果、第１情報と第２情報とに差分が無い場合（Ｓ１５：Ｎｏ）、評価部１２は特に何も実行しない。一方、献立の一部にキャンセルが発生することで第１情報と第２情報とに差分がある場合（Ｓ１５：Ｙｅｓ）、評価部１２は、キャンセルされた献立の食費を、残り期間Ｔ２における食費に繰り越すように目標値Ａ１を再設定する（Ｓ１６）。そして、評価部１２は、再設定された目標値Ａ１を超えないように、タイミングｔ１以降の残り期間Ｔ２における献立を再提案する（Ｓ１７）。処理Ｓ１５～Ｓ１７は、献立提案方法における評価ステップＳＴ２に相当する。そして、処理部１１は、評価部１２が再提案した献立を提示装置２へ送信することにより、再提案された献立をユーザ５に提示する（Ｓ１８）。処理Ｓ１８は、献立提案方法における処理ステップＳＴ３に相当する。

このように、第１実施例においては、評価部１２は、キャンセルされた献立の食費を残り期間Ｔ２の食費に繰り越すという還元処理と、残り期間Ｔ２における献立を再提案する再提案処理と、の両方を実行している。

（４．２）第２実施例
以下、上記実施形態における第２実施例について図７を用いて説明する。図７は、一実施形態の第２実施例に係る献立提案システム（ここではサーバ１）における動作を説明するためのフローチャート図である。第２実施例では、対象期間Ｔ１の途中の任意のタイミングｔ１において、献立の一部でユーザ５が個別に取得した食材Ｂ２を用いたという実績を実績取得部１０２が取得する点で、第１実施例と相違する。なお、処理Ｓ１１～Ｓ１４は第１実施例と共通するので、図７では処理Ｓ１１～Ｓ１４の図示を省略している。

評価部１２は、対象期間Ｔ１の開始からタイミングｔ１までの間における、評価部１２が提案した献立の内容に関する第１情報と、実績取得部１０２が取得した実績に関する第２情報とを比較する（Ｓ２１）。比較の結果、第１情報と第２情報とに差分が無い場合（Ｓ２１：Ｎｏ）、評価部１２は特に何も実行しない。一方、献立の一部にユーザ５が個別に取得した食材Ｂ２を用いることで第１情報と第２情報とに差分がある場合（Ｓ２１：Ｙｅｓ）、評価部１２は、残り期間Ｔ２における食費から当該食材Ｂ２の食材費を除くように目標値Ａ１を再設定する（Ｓ２２）。そして、評価部１２は、再設定された目標値Ａ１を超えないように、タイミングｔ１以降の残り期間Ｔ２における献立を再提案する（Ｓ２３）。この場合、評価部１２は、ユーザ５が個別に取得した食材Ｂ２を優先的に使用するように、残り期間Ｔ２における献立を再提案する。処理Ｓ２１～Ｓ２３は、献立提案方法における評価ステップＳＴ２に相当する。そして、処理部１１は、評価部１２が再提案した献立を提示装置２へ送信することにより、再提案された献立をユーザ５に提示する（Ｓ２４）。処理Ｓ２４は、献立提案方法における処理ステップＳＴ３に相当する。

（４．３）第３実施例
以下、上記実施形態における第３実施例について図８を用いて説明する。図８は、一実施形態の第３実施例に係る献立提案システム（ここではサーバ１）における動作を説明するためのフローチャート図である。第３実施例では、実績取得部１０２が取得した実績ではなく、費用情報取得部１０３が取得した費用情報に基づいて献立を再提案する点で、第１実施例及び第２実施例と相違する。なお、処理Ｓ１１～Ｓ１４は第１実施例と共通するので、図８では処理Ｓ１１～Ｓ１４の図示を省略している。

対象期間Ｔ１において、費用情報取得部１０３は、定期的に費用情報を取得する（Ｓ３１）。そして、評価部１２は、費用情報取得部１０３が取得した費用情報に基づいて、ユーザ５に食材を配送する時点で食材の仕入れ値の予測値が変動するか否かを監視する（Ｓ３２）。費用情報取得部１０３が取得する費用情報は、評価部１２が提案する献立に含まれる可能性のある全ての食材についての情報であってもよいし、一部の特定の食材についての情報のみであってもよい。

監視の結果、食材の仕入れ値の予測値に変動がない場合、言い換えれば、食材の仕入れ値の予測値が基準範囲内に収まっている場合（Ｓ３２：Ｎｏ）、評価部１２は、特に何も実行しない。一方、食材の仕入れ値の予測値に変動がある場合、言い換えれば、食材の仕入れ値の予測値が基準範囲を逸脱する場合（Ｓ３２：Ｙｅｓ）、評価部１２は、ユーザ５が未購入の食材を利用している献立について再提案する（Ｓ３３）。処理Ｓ３２，Ｓ３３は、献立提案方法における評価ステップＳＴ２に相当する。

具体的には、評価部１２は、食材の仕入れ値の予測値が基準範囲よりも高い場合、当該食材が含まれないように献立を再提案する。また、評価部１２は、食材の仕入れ値の予測値が基準範囲よりも低い場合、当該食材を含むように献立を再提案する。後者の場合、評価部１２は、当該食材の仕入れ値の差額分を再提案時以降の残りの期間における食費に繰り越したり、ユーザ５にポイントバックしたりする等の還元処理を実行してもよい。また、評価部１２は、ユーザ５の「こだわり」を考慮して、ユーザ５の好きな食材の仕入れ値の平均値が一定価格未満となる場合、当該食材を優先的に献立に含むように、献立を再提案してもよい。そして、処理部１１は、評価部１２が再提案した献立を提示装置２へ送信することにより、再提案された献立をユーザ５に提示する（Ｓ３４）。処理Ｓ３４は、献立提案方法における処理ステップＳＴ３に相当する。

（４．４）第４実施例
以下、上記実施形態における第４実施例について図９を用いて説明する。図９は、一実施形態の第４実施例に係る献立提案システム（ここではサーバ１）における動作を説明するためのフローチャート図である。第４実施例では、一部の献立にキャンセルが発生した場合に、まずユーザ５に対して外食に関する情報を提示する点で、第１実施例と相違する。つまり、第４実施例では、評価部１２は、提案した献立についてキャンセルを示すユーザ入力を実績取得部１０２が取得した場合、外食を提案する、又は外食で利用可能なクーポン情報若しくは割引情報を提供する処理を実行する。なお、処理Ｓ１１～Ｓ１４は第１実施例と共通するので、図９では処理Ｓ１１～Ｓ１４の図示を省略している。

評価部１２は、対象期間Ｔ１の開始からタイミングｔ１までの間における、評価部１２が提案した献立の内容に関する第１情報と、実績取得部１０２が取得した実績に関する第２情報とを比較する（Ｓ４１）。比較の結果、第１情報と第２情報とに差分が無い場合（Ｓ４１：Ｎｏ）、評価部１２は特に何も実行しない。一方、献立の一部にキャンセルが発生することで第１情報と第２情報とに差分がある場合（Ｓ４１：Ｙｅｓ）、評価部１２は、ユーザ５が献立をキャンセルした日の日付情報を、通信部１０及びネットワークＮＴ１を介して外食事業者へ通知する（Ｓ４２）。ここでいう外食事業者は、例えばレストラン等のユーザ５に対して飲食物を提供する事業者、又は弁当若しくは総菜等をユーザ５に宅配する事業者等を含み得る。

評価部１２は、通信部１０及びネットワークＮＴ１を介して、ユーザ５が献立をキャンセルした日に利用可能なクーポン情報を外食事業者から取得する（Ｓ４３）。そして、評価部１２は、例えば処理部１１と提示装置２との間の通信により、取得したクーポン情報をユーザ５に提供する（Ｓ４４）。なお、クーポン情報は、評価部１２を介さずに、外食事業者から直接ユーザ５に対して提供されてもよい。この場合でも、評価部１２から外食事業者に対する日付情報の通知を契機としてクーポン情報がユーザ５に提供されるため、評価部１２が間接的にユーザ５にクーポン情報を提供している、と言える。

ここで、クーポン情報は、対象となる外食事業者にユーザ５が提示する情報である。ユーザ５は、対象となる外食事業者にクーポン情報を提示することにより、クーポン情報に対応する飲食物の提供サービスを享受したり、クーポン情報に対応する飲食物の割引サービスを享受したりすることが可能である。クーポン情報に対応する飲食物は、例えば目標値Ａ１を超えないような範囲の値段の物、又はユーザ５が既に蓄積しているポイントで利用可能な物を含み得る。また、クーポン情報に対応する飲食物は、ユーザ５が献立をキャンセルした日から数日前までの献立と同じジャンルの物は含まれないのが好ましい。さらに、クーポン情報に対応する飲食物は、ユーザ５がキャンセルした日の献立の栄養バランスと同等の物であるのが好ましい。

その後、評価部１２は、通信部１０及びネットワークＮＴ１を介して、ユーザ５の消費した外食費を取得する（Ｓ４５）。例えば、評価部１２は、ユーザ５が提示装置２を操作することで入力された外食費を取得してもよいし、ユーザ５が使用するクレジットカード等の決済事業者から外食費を取得してもよい。評価部１２は、残り期間Ｔ２における食費から外食費を除くように目標値Ａ１を再設定する（Ｓ４６）。そして、評価部１２は、再設定された目標値Ａ１を超えないように、タイミングｔ１以降の残り期間Ｔ２における献立を再提案する（Ｓ４７）。処理Ｓ４６，Ｓ４７は、献立提案方法における評価ステップＳＴ２に相当する。そして、処理部１１は、評価部１２が再提案した献立を提示装置２へ送信することにより、再提案された献立をユーザ５に提示する（Ｓ４８）。処理Ｓ４８は、献立提案方法における処理ステップＳＴ３に相当する。

ところで、献立提案システム（サーバ１）は、目標値取得部１０１を備えていなくてもよい。この場合、評価部１２は、目標値Ａ１に依らず、対象期間Ｔ１における献立を提案すればよい。例えば、評価部１２は、ユーザ５の家族構成及び／又は年齢等の入力を受け付けることで、受け付けた入力に応じて対象期間Ｔ１における献立を提案してもよい。また、例えば、評価部１２は、ユーザ５からのレシピの入力を受け付けることで、受け付けた入力に応じて対象期間Ｔ１における献立（受け付けたレシピを含む）を提案してもよい。

（５）まとめ
以上説明したように、第１の態様に係る献立提案システム（ここではサーバ１）は、対象期間（Ｔ１）に対する食費に関する目標値（Ａ１）に基づいて、対象期間（Ｔ１）における献立を提案する。献立提案システム（サーバ１）は、評価部（１２）と、処理部（１１）と、を備える。評価部（１２）は、対象期間（Ｔ１）の途中における任意のタイミング（ｔ１）において献立に関する評価を行う。処理部（１１）は、評価部（１２）の結果に基づいて所定の処理を行う。評価部（１２）は、対象期間（Ｔ１）の開始からタイミング（ｔ１）までの間において、提案された献立の内容に関する第１情報と、提案された献立に対する実績に関する第２情報とに基づいて、評価を行う。第１の態様によれば、提案する献立内容の改善を図ることができる。

第２の態様に係る献立提案システム（サーバ１）に関して、第１の態様において、所定の処理は、第１情報と、第２情報との差分に応じた還元に関する処理を含む。第２の態様によれば、第１情報と第２情報とに差分が生じた場合に、ユーザ（５）へ提供するサービスの向上を図ることができる。

第３の態様に係る献立提案システム（サーバ１）は、第１又は第２の態様において、ユーザ（５）が個別に取得した食材（Ｂ２）に関する食材情報を取得する取得部（通信部１０）を更に備える。献立提案システム（サーバ１）は、食材情報を取得した場合には、食材情報に相当する費用を、食費から除き、かつ食材（Ｂ２）を利用するように献立を提案する。第３の態様によれば、対象期間（Ｔ１）に対する目標値（Ａ１）を厳守しつつ、食材（Ｂ２）の無駄を無くしやすくできる。

第４の態様に係る献立提案システム（サーバ１）は、第１～第３の態様のいずれか１つにおいて、提案した献立についてキャンセルを示すユーザ入力を受け付けた場合、外食に関する提案処理を実行する。第４の態様によれば、ユーザ（５）が調理だけでなく外食という選択を行いやすくでき、利便性が向上される。また献立提案システム（サーバ１）と外食サービスを提供する飲食店側との連携を行いやすくできる。

第５の態様に係る献立提案システム（サーバ１）に関して、第１～第４の態様のいずれか１つにおいて、献立は、１又は複数のレシピに関する情報を含む。第５の態様によれば、利便性が更に向上される。

第６の態様に係る献立提案システム（サーバ１）に関して、第５の態様において、第２情報は、提案された献立におけるレシピごとの実績に関する。第６の態様によれば、より細かい評価及び提案を行うことができ、利便性が更に向上される。

第７の態様に係る献立提案システム（サーバ１）は、第１～第６の態様のいずれか１つにおいて、提案した献立について採用を示すユーザ入力を受け付けた場合、献立に対応する食材（Ｂ１）の配達に関する要求処理を実行する。第７の態様によれば、献立提案システム（サーバ１）を「食配サービス」との連携が容易に実現できる。

第８の態様に係る献立提案システム（サーバ１）に関して、第１～第７の態様のいずれか１つにおいて、対象期間（Ｔ１）に対する食費は、定額として予め設定されている。第８の態様によれば、献立に関する定額制のサブスクリプションサービス提供を実現しやすくなる。

第９の態様に係る献立提案システム（サーバ１）に関して、第１～第８の態様のいずれか１つにおいて、評価部（１２）は、第１情報及び第２情報に加えて、食材の栄養バランス及びユーザの嗜好性のうち少なくとも一方に関連する条件情報（Ｄ１）に基づいて、評価を行う。第９の態様によれば、さらに提案する献立内容の改善を図ることができる。

第１０の態様に係る献立提案システム（サーバ１）に関して、第１～第９の態様のいずれか１つにおいて、所定の処理は、対象期間（Ｔ１）のうち、タイミング（ｔ１）以降の残りの期間（Ｔ２）に対する献立の内容を変更する処理を含む。第１０の態様によれば、さらに提案する献立内容の改善を図ることができる。

第１１の態様に係る献立提案システム（サーバ１）に関して、第１～第１０の態様のいずれか１つにおいて、特定の食材に関する費用が仕入れにより変動したという情報を取得すると、ユーザが未購入の食材を利用している献立について再提案する。第１１の態様によれば、価格変動する食材に追従した、より良い献立提案を行える。

第１２の態様に係る献立提案システム（サーバ１）に関して、第１～第１１の態様のいずれか１つにおいて、評価部（１２）は、提案した献立の内容のうち少なくとも一部の内容の変更を示すユーザ入力を受け付けた場合、その変更後の献立の内容が、目標値（Ａ１）及び食材の栄養バランスを満たすか否かについて評価する。献立提案システム（サーバ１）は、評価部（１２）の評価結果を通知する通知部（通信部１０）を更に備える。所定の処理は、目標値（Ａ１）及び栄養バランスを満たさないと評価された場合に、タイミング（ｔ１）以降の残りの期間（Ｔ２）に対して、目標値（Ａ１）及び栄養バランスを満たす献立について再提案する処理を含む。第１２の態様によれば、提案した献立に対してユーザ（５）が直接変更する場合にも、目標値（Ａ１）及び栄養バランスを考慮した再提案を容易に実現でき、利便性が更に向上される。

第１３の態様に係る献立提案システム（サーバ１）に関して、第１～第１２の態様のいずれか１つにおいて、評価部（１２）は、第１情報及び第２情報に加えて、食材に関する管理期限に基づいて、評価を行う。第１３の態様によれば、管理期限が切れてしまう食材の発生を抑えつつ、提案する献立内容の改善を図ることができる。

第１４の態様に係る献立支援システム（１００）は、対象期間（Ｔ１）に対する食費に関する目標値（Ａ１）に基づいて、対象期間（Ｔ１）における献立を提案するサーバ（１）と、サーバ（１）と通信可能な提示装置（２）とを備える。サーバ（１）は、対象期間（Ｔ１）の途中における任意のタイミング（ｔ１）において献立に関する評価を行う評価部（１２）と、評価部の結果に基づいて所定の処理を行う処理部（１１）と、を備える。評価部（１２）は、対象期間（Ｔ１）の開始からタイミング（ｔ１）までの間において、提案された献立の内容に関する第１情報と、提案された献立に対する実績に関する第２情報とに基づいて、評価を行う。提示装置（２）は、献立に対する実績を入力する入力部（２４）と、実績をサーバ（１）に送信し、評価の結果に関する情報をサーバ（１）から受信する通信部（２１）と、評価の結果に関する情報を出力する出力部（２５）と、入力部（２４）、通信部（２１）及び出力部（２５）を制御する制御部（２２）と、を備える。第１４の態様によれば、提案する献立内容の改善を図ることが可能な献立支援システム（１００）を提供できる。

第１５の態様に係るプログラムは、第１４の態様における献立支援システム（１００）における提示装置（２）の１以上のプロセッサに、以下の方法を実行させるプログラムである。その方法とは、献立に対する実績を取得するステップと、実績をサーバ（１）に送信するステップと、評価の結果に関する情報をサーバ（１）から受信するステップと、評価の結果に関する情報を出力するステップと、を含む。第１５の態様によれば、提案する献立内容の改善を図ることが可能な、提示装置（２）に関する機能を提供できる。

第１６の態様に係る献立提案方法は、対象期間（Ｔ１）に対する食費に関する目標値に基づいて、対象期間（Ｔ１）における献立を提案する。献立提案方法は、評価ステップと、処理ステップと、を含む、評価ステップにて、対象期間（Ｔ１）の途中における任意のタイミングにおいて献立に関する評価を行う。処理ステップにて、評価ステップの結果に基づいて所定の処理を行う。評価ステップにて、対象期間（Ｔ１）の開始からタイミング（ｔ１）までの間において、提案された献立の内容に関する第１情報と、提案された献立に対する実績に関する第２情報とに基づいて、評価を行う。第１６の態様によれば、提案する献立内容の改善を図ることが可能な献立提案方法を提供できる。

第１７の態様に係るプログラムは、１以上のプロセッサに第１６の態様における献立提案方法を実行させるためのプログラムである。第１７の態様によれば、提案する献立内容の改善を図ることが可能な機能を提供できる。

第２～１３の態様に係る構成については、献立提案システムに必須の構成ではなく、適宜省略可能である。

また、実施の形態における献立提案システム（サーバ１）は、評価部（１２）と、処理部（１１）と、実績取得部（１０２）と、を備える。評価部（１２）は、対象期間（Ｔ１）における献立を提案する。処理部（１１）は、評価部（１２）が提案した献立をユーザ（５）に提示する。実績取得部（１０２）は、対象期間（Ｔ１）の途中における任意のタイミング（ｔ１）において、評価部（１２）が提案した献立に対する実績をユーザ（５）から取得する。評価部（１２）は、対象期間（Ｔ１）の開始からタイミング（ｔ１）までの間において、評価部（１２）が提案した献立の内容に関する第１情報と、実績取得部（１０２）が取得した実績に関する第２情報とに差分がある場合、差分に応じたユーザ（５）に対する還元に関する還元処理と、対象期間（Ｔ１）のうちのタイミング（ｔ１）以降の残りの期間（Ｔ２）に対する献立の内容を変更して再提案する再提案処理と、の少なくとも一方を行う。

これによれば、ユーザ（５）に提案する献立内容の改善を図ることができる。また、これによれば、ユーザ（５）へ提供するサービスの向上を図ることができる。

また、例えば、献立提案システム（サーバ１）は、対象期間（Ｔ１）に対する食費に関する目標値（Ａ１）を取得する目標値取得部（１０１）を更に備える。評価部（１２）は、目標値取得部（１０１）が取得した目標値（Ａ１）に基づいて、対象期間（Ｔ１）における献立を提案する。

これによれば、ユーザ（５）に提案する献立内容の改善を図ることができる。また、これによれば、ユーザ（５）へ提供するサービスの向上を図ることができる。

また、例えば、評価部（１２）は、ユーザ５が個別に取得した食材（Ｂ２）に関する食材情報を実績取得部（１０２）が取得した場合には、食材情報に相当する費用を、食費から除き、かつ食材を利用するように献立を提案する。

これによれば、対象期間（Ｔ１）に対する目標値（Ａ１）を厳守しつつ、食材（Ｂ２）の無駄を無くしやすくできる。

また、例えば、評価部（１２）は、提案した献立についてキャンセルを示すユーザ入力を実績取得部（１０２）が取得した場合、外食を提案する、又は外食で利用可能なクーポン情報を提供する処理を実行する。

これによれば、ユーザ（５）が調理だけでなく外食という選択を行いやすくでき、利便性が向上される。また献立提案システム（サーバ１）と外食サービスを提供する飲食店側との連携を行いやすくできる。

また、例えば、献立は、１又は複数のレシピに関する情報を含む。

これによれば、利便性が更に向上される。

また、例えば、第２情報は、提案された献立におけるレシピごとの実績に関する。

これによれば、より細かい評価及び提案を行うことができ、利便性が更に向上される。

また、例えば、評価部（１２）は、提案した献立について採用を示すユーザ入力を受け付けた場合、献立に対応する食材の配達に関する要求処理を実行する。

これによれば、献立提案システム（サーバ１）の「食配サービス」との連携が容易に実現できる。

また、例えば、対象期間（Ｔ１）に対する食費は、定額として予め設定されている。

これによれば、献立に関する定額制のサブスクリプションサービス提供を実現しやすくなる。

また、例えば、評価部（１２）は、第１情報及び第２情報に加えて、食材の栄養バランス及びユーザの嗜好性のうち少なくとも一方に関連する条件情報に基づいて、評価を行う。

これによれば、さらに提案する献立内容の改善を図ることができる。

また、例えば、献立提案システム（サーバ１）は、食材に関する費用についての費用情報を取得する費用情報取得部（１０３）を更に備える。評価部（１２）は、食材に関する費用が仕入れにより変動したという費用情報を費用情報取得部（１０３）が取得すると、ユーザ（５）が未購入の食材を利用している献立について再提案する。

これによれば、価格変動する食材に追従した、より良い献立提案を行える。

また、例えば、評価部（１２）は、食材の仕入れ値の予測値が基準範囲よりも高い場合、当該食材が含まれないように献立を再提案し、食材の仕入れ値の予測値が基準範囲よりも低い場合、当該食材を含むように献立を再提案する。

これによれば、価格変動する食材に追従した、より良い献立提案を行える。

また、例えば、評価部（１２）は、提案した献立の内容のうち少なくとも一部の内容の変更を示すユーザ入力を実績取得部（１０２）が取得した場合、その変更後の献立の内容が、目標値（Ａ１）及び食材の栄養バランスを満たすか否かについて評価する。献立提案システム（サーバ１）は、評価部（１２）の評価結果を通知する通知部（通信部１０）を更に備える。評価部（１２）は、目標値（Ａ１）及び栄養バランスを満たさないと評価された場合に、タイミング（ｔ１）以降の残りの期間（Ｔ２）に対して、目標値（Ａ１）及び栄養バランスを満たす献立について再提案する。

これによれば、提案した献立に対してユーザ（５）が直接変更する場合にも、目標値（Ａ１）及び栄養バランスを考慮した再提案を容易に実現でき、利便性が更に向上される。

また、例えば、評価部（１２）は、第１情報及び第２情報に加えて、食材に関する管理期限に基づいて、評価を行う。

これによれば、管理期限が切れてしまう食材の発生を抑えつつ、提案する献立内容の改善を図ることができる。

また、例えば、献立提案方法は、評価ステップ（ＳＴ２）と、処理ステップ（ＳＴ３）と、実績取得ステップ（ＳＴ４）と、を含む。評価ステップ（ＳＴ２）では、対象期間（Ｔ１）における献立を提案する。処理ステップ（ＳＴ３）では、評価ステップ（ＳＴ２）が提案した献立をユーザ（５）に提示する。実績取得ステップ（ＳＴ４）では、対象期間（Ｔ１）の途中における任意のタイミング（ｔ１）において、評価ステップ（ＳＴ２）が提案した献立に対する実績をユーザ（５）から取得する。評価ステップ（ＳＴ２）では、対象期間（Ｔ１）の開始からタイミング（ｔ１）までの間において、評価ステップ（ＳＴ２）が提案した献立の内容に関する第１情報と、実績取得ステップ（ＳＴ４）が取得した実績に関する第２情報とに差分がある場合、差分に応じたユーザ（５）に対する還元に関する還元処理と、対象期間（Ｔ１）のうちのタイミング（ｔ１）以降の残りの期間（Ｔ２）に対する献立の内容を変更して再提案する再提案処理と、の少なくとも一方を行う。

これによれば、ユーザ（５）に提案する献立内容の改善を図ることが可能な献立提案方法を提供できる。また、これによれば、ユーザ（５）へ提供するサービスの向上を図ることが可能な献立提案方法を提供できる。

また、例えば、プログラムは、１以上のプロセッサに、上記の献立提案方法を実行させる。

これによれば、ユーザ（５）に提案する献立内容の改善を図ることが可能な機能を提供できる。また、これによれば、ユーザ（５）へ提供するサービスの向上を図ることが可能な機能を提供できる。

また、例えば、情報処理方法は、第１処理ステップと、第２処理ステップと、第３処理ステップと、を含む。第１処理ステップでは、対象期間（Ｔ１）における献立を取得し、取得した献立をユーザ（５）に提示する。第２処理ステップでは、対象期間（Ｔ１）の途中における任意のタイミング（ｔ１）において、第１処理ステップが提示した献立に対する実績をユーザ（５）から取得する。第３処理ステップでは、対象期間（Ｔ１）の開始からタイミング（ｔ１）までの間において、第１処理ステップが提示した献立の内容に関する第１情報と、第２処理ステップが取得した実績に関する第２情報とに差分がある場合、差分に応じたユーザ（５）に対する還元に関する還元処理と、対象期間（Ｔ１）のうちのタイミング（ｔ１）以降の残りの期間（Ｔ２）に対する献立の内容を変更して再提案する再提案処理と、の少なくとも一方の処理により得られた情報をユーザ（５）に提示する。

これによれば、ユーザ（５）に提案する献立内容の改善を図ることが可能な情報処理方法を提供できる。また、これによれば、ユーザ（５）へ提供するサービスの向上を図ることが可能な情報処理方法を提供できる。

上記情報処理方法は、例えばユーザ（５）が所有する情報端末（２）で実行され得る。なお、上記情報処理方法において、還元処理及び再提案処理は、いずれも情報端末（２）で実行される必要はなく、例えば献立提案システム（サーバ１）で実行されればよい。

また、例えば、情報処理装置（情報端末２）は、処理部（制御部２２）を備える。処理部は、第１処理機能と、第２処理機能と、第３処理機能と、を有する。第１処理機能では、対象期間（Ｔ１）における献立を取得し、取得した献立をユーザ（５）に提示する。第２処理機能では、対象期間（Ｔ１）の途中における任意のタイミング（ｔ１）において、第１処理機能が提示した献立に対する実績をユーザ（５）から取得する。第３処理機能では、対象期間（Ｔ１）の開始からタイミング（ｔ１）までの間において、第１処理機能が提示した献立の内容に関する第１情報と、第２処理機能が取得した実績に関する第２情報とに差分がある場合、差分に応じたユーザ（５）に対する還元に関する還元処理と、対象期間（Ｔ１）のうちのタイミング（ｔ１）以降の残りの期間（Ｔ２）に対する献立の内容を変更して再提案する再提案処理と、の少なくとも一方の処理により得られた情報をユーザ（５）に提示する。

これによれば、ユーザ（５）に提案する献立内容の改善を図ることが可能な情報処理装置を提供できる。また、これによれば、ユーザ（５）へ提供するサービスの向上を図ることが可能な情報処理装置を提供できる。

上記情報処理装置において、第１処理機能、第２処理機能、及び第３処理機能は、１つの処理部で実行されてもよいし、機能ごとに異なる処理部で実行されてもよい。

１００ 献立支援システム
１ サーバ（献立提案システム）
１０ 通信部（取得部、通知部）
１０１ 目標値取得部
１０２ 実績取得部
１０３ 費用情報取得部
１１ 処理部
１２ 評価部
２ 提示装置（情報端末）
２１ 通信部
２２ 制御部
２４ 入力部
２５ 出力部
５ ユーザ
Ａ１ 目標値
Ｂ１、Ｂ２ 食材
Ｄ１ 条件情報
Ｔ１ 対象期間
ＳＴ１ 目標値取得ステップ
ＳＴ２ 評価ステップ
ＳＴ３ 処理ステップ
ＳＴ４ 実績取得ステップ
ｔ１ タイミング
Ｔ２ 残りの期間

Claims (17)

1. 対象期間における献立を提案する評価部と、
   前記評価部が提案した前記献立をユーザに提示する処理部と、
   前記対象期間の途中における任意のタイミングにおいて、前記評価部が提案した前記献立に対する実績を前記ユーザから取得する実績取得部と、を備え、
   前記評価部は、前記対象期間の開始から前記タイミングまでの間において、前記評価部が提案した前記献立の内容に関する第１情報と、前記実績取得部が取得した前記実績に関する第２情報と、に差分がある場合、前記差分に応じた前記ユーザに対する還元に関する還元処理と、前記対象期間のうちの前記タイミング以降の残りの期間に対する前記献立の内容を変更して再提案する再提案処理と、の少なくとも一方を行う、
   献立提案システム。
2. 前記対象期間に対する食費に関する目標値を取得する目標取得部を更に備え、
   前記評価部は、前記目標取得部が取得した前記目標値に基づいて、前記対象期間における前記献立を提案する、
   請求項１に記載の献立提案システム。
3. 前記評価部は、前記ユーザが個別に取得した食材に関する食材情報を前記実績取得部が取得した場合には、前記食材情報に相当する費用を、食費から除き、かつ前記食材を利用するように献立を提案する、
   請求項１又は２に記載の献立提案システム。
4. 前記評価部は、提案した前記献立についてキャンセルを示すユーザ入力を前記実績取得部が取得した場合、外食を提案する、又は前記外食で利用可能なクーポン情報を提供する処理を実行する、
   請求項１～３のいずれか１項に記載の献立提案システム。
5. 前記献立は、１又は複数のレシピに関する情報を含む、
   請求項１～４のいずれか１項に記載の献立提案システム。
6. 前記第２情報は、提案された前記献立におけるレシピごとの実績に関する、
   請求項５に記載の献立提案システム。
7. 前記評価部は、提案した前記献立について採用を示すユーザ入力を受け付けた場合、前記献立に対応する食材の配達に関する要求処理を実行する、
   請求項１～６のいずれか１項に記載の献立提案システム。
8. 前記対象期間に対する食費は、定額として予め設定されている、
   請求項１～７のいずれか１項に記載の献立提案システム。
9. 前記評価部は、前記第１情報及び前記第２情報に加えて、食材の栄養バランス及びユーザの嗜好性のうち少なくとも一方に関連する条件情報に基づいて、前記献立に関する評価を行う、
   請求項１～８のいずれか１項に記載の献立提案システム。
10. 食材に関する費用についての費用情報を取得する費用情報取得部を更に備え、
    前記評価部は、前記食材に関する費用が仕入れにより変動したという前記費用情報を前記費用情報取得部が取得すると、前記ユーザが未購入の食材を利用している献立について再提案する、
    請求項１～９のいずれか１項に記載の献立提案システム。
11. 前記評価部は、前記食材の仕入れ値の予測値が基準範囲よりも高い場合、当該食材が含まれないように前記献立を再提案し、前記食材の仕入れ値の予測値が前記基準範囲よりも低い場合、当該食材を含むように前記献立を再提案する、
    請求項１０に記載の献立提案システム。
12. 前記対象期間に対する食費に関する目標値を取得する目標取得部を更に備え、
    前記評価部は、提案した前記献立の内容のうち少なくとも一部の内容の変更を示すユーザ入力を前記実績取得部が取得した場合、その変更後の前記献立の内容が、前記目標値及び食材の栄養バランスを満たすか否かについて評価し、
    前記献立提案システムは、前記評価部の評価結果を通知する通知部を更に備え、
    前記評価部は、前記目標値及び前記栄養バランスを満たさないと評価された場合に、前記タイミング以降の残りの期間に対して、前記目標値及び前記栄養バランスを満たす献立について再提案する、
    請求項１～１１のいずれか１項に記載の献立提案システム。
13. 前記評価部は、前記第１情報及び前記第２情報に加えて、食材に関する管理期限に基づいて、前記献立に関する評価を行う、
    請求項１～１２のいずれか１項に記載の献立提案システム。
14. 対象期間における献立を提案する評価ステップと、
    前記評価ステップが提案した前記献立をユーザに提示する処理ステップと、
    前記対象期間の途中における任意のタイミングにおいて、前記評価ステップが提案した前記献立に対する実績を前記ユーザから取得する実績取得ステップと、を含み、
    前記評価ステップでは、前記対象期間の開始から前記タイミングまでの間において、前記評価ステップが提案した前記献立の内容に関する第１情報と、前記実績取得ステップが取得した前記実績に関する第２情報とに差分がある場合、前記差分に応じた前記ユーザに対する還元に関する還元処理と、前記対象期間のうちの前記タイミング以降の残りの期間に対する前記献立の内容を変更して再提案する再提案処理と、の少なくとも一方を行う、
    献立提案方法。
15. １以上のプロセッサに、
    請求項１４に記載の献立提案方法を実行させる、
    プログラム。
16. 対象期間における献立を取得し、取得した前記献立をユーザに提示する第１処理ステップと、
    前記対象期間の途中における任意のタイミングにおいて、前記第１処理ステップが提示した前記献立に対する実績を前記ユーザから取得する第２処理ステップと、
    前記対象期間の開始から前記タイミングまでの間において、前記第１処理ステップが提示した前記献立の内容に関する第１情報と、前記第２処理ステップが取得した前記実績に関する第２情報と、に差分がある場合、前記差分に応じた前記ユーザに対する還元に関する還元処理と、前記対象期間のうちの前記タイミング以降の残りの期間に対する前記献立の内容を変更して再提案する再提案処理と、の少なくとも一方の処理により得られた情報を前記ユーザに提示する第３処理ステップと、を含む、
    情報処理方法。
17. 処理部を備え、前記処理部は、
    対象期間における献立を取得し、取得した前記献立をユーザに提示する第１処理機能と、
    前記対象期間の途中における任意のタイミングにおいて、前記第１処理機能が提示した前記献立に対する実績を前記ユーザから取得する第２処理機能と、
    前記対象期間の開始から前記タイミングまでの間において、前記第１処理機能が提示した前記献立の内容に関する第１情報と、前記第２処理機能が取得した前記実績に関する第２情報と、に差分がある場合、前記差分に応じた前記ユーザに対する還元に関する還元処理と、前記対象期間のうちの前記タイミング以降の残りの期間に対する前記献立の内容を変更して再提案する再提案処理と、の少なくとも一方の処理により得られた情報を前記ユーザに提示する第３処理機能と、を有する、
    情報処理装置。

Images