WO2011037221A1

WO2011037221A1 - 献立決定支援装置、献立決定支援プログラムおよび献立決定支援プログラムを記憶した記憶媒体

Info

Publication number: WO2011037221A1
Application number: PCT/JP2010/066675
Authority: WO
Inventors: 布施寿美; 湯浅夏樹; 岩井俊幸; 山森小織; 東喜子; 井伊幸恵; 鈴木薫; 杉山幸代; 大島朋子
Original assignee: シャープ株式会社
Priority date: 2009-09-28
Filing date: 2010-09-27
Publication date: 2011-03-31

Abstract

１つ以上の料理からなる献立の提案における条件設定を含むユーザからの入力操作を受け付ける入力部と、入力された前記条件設定に基づいて、適した料理をデータベースから検索する制御部と、検索結果をユーザに提示する出力部と、提示された料理に対してのユーザの評価を受け付ける評価入力部と、を備え、前記制御部は、前記条件設定と前記ユーザの評価とに基づいて、適した料理を再検索する機能を備えることを特徴とする献立決定支援装置。先に献立決定支援装置側からユーザに対し、献立提案日の設定条件に基づいて献立レシピを検索し提案を行うことで、ユーザは自ら検索条件を考えなくても、献立決定支援装置と対話をしながら好みの献立レシピを容易に見つけることができる。

Description

献立決定支援装置、献立決定支援プログラムおよび献立決定支援プログラムを記憶した記憶媒体

　本発明は、献立決定支援装置に関する。

　食卓に提供する料理の種類・順序等を示す献立を考える際に、レシピ本を参照する方法の他に、一つの手助けとして、インターネット上の献立レシピサイトを閲覧し、その中のレシピを参考にする方法がある。インターネット上の献立レシピの情報量は膨大であるが、その中から献立レシピを探すために、作りたい献立の諸条件を入力して検索を行うことで、ある程度、献立の候補を絞ることができる。また、過去に登録していたお気に入りページを閲覧し、その中からレシピを探すこともできる。

　しかしながら、日々の献立となると、自らが毎回、検索条件を考えながら入力して、検索結果の中から探したりすることは面倒である。また、検索結果の件数が多く、その中に作りたいレシピが無い場合は、見つかるまで検索を続けなければならない煩わしさがある。

　従来技術として、ユーザ所望の情報（献立）を提供するために、ユーザの個人情報や対話入力文字情報からユーザの好みに近い情報を検索し、また、検索中もユーザを飽きさせないよう画面に対話やりとりが表示されるよう考慮された下記特許文献１に記載の技術がある。

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

　上記ユーザ支援装置では、ユーザの個人情報や対話画面上での入力文字情報からユーザの好みに近い情報（献立）を検索し、また、対話画面上でのやりとりを楽しむことで、ユーザが欲しい情報を見つけるまでの気持ちの負担を軽くするよう考慮されているが、献立決定支援装置側からの対話やりとりに関する具体的な提案（問いかけ）手段やユーザの好みの情報を抽出する具体的な手段が明確ではなかった。

　本発明は、上記課題に基づいて提案するもので、ユーザは献立を考える際、最初から検索条件を考えなくても、献立決定支援装置側からの献立に関する提案（問いかけ）に答えていくことで、好みの献立レシピを見つけることができる装置を提供することを目的とする。

　本発明によれば、献立決定支援装置から献立に関連した問いかけを先に行い、ユーザは問いかけに対して簡易な操作方法で回答する。対話情報からユーザの好み等を抽出し、献立検索を行う。

　また、献立が決定するまでの処理を学習させ、ユーザ好みの条件にあった献立提供までの時間を短縮することもできる。

　本発明の一観点によれば、１つ以上の料理からなる献立の提案における条件設定を含むユーザからの入力操作を受け付ける入力部と、入力された前記条件設定に基づいて、適した料理をデータベースから検索する制御部と、検索結果をユーザに提示する出力部と、提示された料理に対してのユーザの評価を受け付ける評価入力部と、を備え、前記制御部は、前記条件設定と前記ユーザの評価とに基づいて、適した料理を再検索する機能を備えることを特徴とする献立決定支援装置が提供される。これにより、対話形式で、最終的にユーザの望む献立を提示しやすくなる。

　提示された料理に対しての前記ユーザの評価が、「その料理に決める」という第１の評価と、「気になるがその料理は今回は選択しない」という第２の評価と、の少なくとも２種類であり、前記第１の評価の場合には、その評価を行った料理を今回提案する献立を構成する料理の一品に決定すると共に、その料理のレシピデータに基づいて条件設定を変更して次の料理の検索を行い、前記第２の評価の場合には、その評価を行った料理のレシピデータに基づいて条件設定を変更して再検索を行うことが好ましい。

　本明細書は本願の優先権の基礎である日本国特許出願２００９－２２２４４２号の明細書および／または図面に記載される内容を包含する。

　献立決定支援装置側からユーザに対し、先に献立提案日の設定条件に基づいて献立レシピを検索し提案を行うため、ユーザは自ら検索条件を考えることなく、献立決定支援装置と対話をしながら好みの献立レシピを簡易に見つけることができる。

　また、ユーザが好みの献立レシピをどのような条件のもとで見つけたかという情報をユーザデータベースに登録し、その登録情報を献立提案日の検索条件のデータとして活用することで、ユーザ好みのレシピの抽出処理が明確になる。

本発明の第１の実施の形態に係る献立決定支援装置の一構成例を示す機能ブロック図である。図１の記憶部の一構成例を示す機能ブロック図である。レシピデータベースが保持するレシピデータの構成とデータ例を示す図である。献立決定支援装置が献立の提案を行う過程および仕組みの流れを示すフローチャート図である。図４Ａの続きである。対話メッセージ抽出処理について、対話を取得するための設定条件からユーザに対話メッセージを表示するための抽出方法を示す図である。図４のフローチャート図のステップＳ４０２の記念日データ取得条件、ユーザが登録した記念日データベースのデータ例を示す図である。図４のフローチャート図のステップＳ４０５、Ｓ４０６で、レシピ提案の候補に設定するか、設定しないかの選択判断条件となる記念日レシピ検索条件設定のデータの一例を示す図である。図４のフローチャート図のステップＳ４０７の行事データ取得条件、行事データベースが保持するデータの一例を示す図である。図４のフローチャート図のステップＳ４１０、Ｓ４１１で、レシピ提案の候補に設定するか、設定しないかの選択判断条件となる行事レシピ検索条件設定のデータの一例を示す図である。天気データベースが保持するレシピの分類基準データ例を示す図である。天気データベースに設定された気温、湿度の値の条件および図４のフローチャート図のステップＳ４１４、Ｓ４１５において、制御部が取得した天気情報をもとに設定条件にあった天気レシピの検索条件を設定するまでの処理について説明するフローチャート図である。在庫データベースにユーザが登録した在庫食材データ例を示す図である。図４のフローチャートのステップＳ４１８、Ｓ４１９、Ｓ４２０において、在庫データがあるかないかの取得条件およびユーザが在庫食材を使ったレシピ提案を選択するかしないか、それぞれの在庫レシピ検索条件設定のデータの一例を示す図である。旬食材データベースが保持している地域ごとの旬食材データ例を示す図である。図４のフローチャート図のステップＳ４２３、Ｓ４２４，Ｓ４２５において、旬食材データがあるかないかの取得条件およびユーザが旬食材を使ったレシピ提案を選択するかしないか、それぞれの旬食材レシピ検索条件設定のデータ例を示す図である。図４のフローチャート図のステップＳ４２６の詳細手順を示す処理フローである。図４のフローチャート図のステップＳ４２６において、制御部が献立に関するいくつかの質問メッセージを出力部を介して入力部に表示したイメージ画面を示す図である。好みのレシピデータベースが保持するデータ例を示す図である。制御部により好みのレシピデータベースに登録されたレシピを各項目別に分類し、ユーザが選択した条件を比率で示したデータ図である。図４のフローチャート図のステップＳ４２７において、制御部がユーザからの選択情報および質問画面での回答情報に基づき、レシピ提案の優先順位条件の設定方法について示したデータ図である。制御部が図２０で示すレシピ提案の優先順位条件に基づき、ユーザが選択した各項目の検索設定条件により多数のレシピが検索された場合、好みのレシピデータからのレシピ抽出処理手段を示した図である。図４のフローチャート図のステップＳ４３１において、制御部が次の提案レシピまたは他のレシピを検索するための設定条件データ例を示す図である。図４のフローチャート図のステップＳ４３１において、制御部が次の提案レシピまたは他のレシピを検索する段階で、入力部に条件追加変更画面を表示させるデータおよびその選択条件に従った検索設定条件データを示す図である。図４のフローチャート図のステップＳ４２７において、制御部が提案レシピを出力部を介して入力部に表示したイメージ画面を示す図である。図４のフローチャート図のステップＳ４３２において、制御部が出力部を介して入力部にレシピデータに含まれる各項目を表示するか否かを定義するデータ示す図である。入力部にてユーザが記念日のデータを入力する画面例である。図４のフローチャート図のステップＳ４０４、Ｓ４０９において入力部に表示された対話メッセージの表示画面例である。本発明の第２の実施の形態に係る献立決定支援装置の構成図である。本発明の第５の実施の形態において、献立決定後に、買い物チェックリストを作成したり、食材の在庫量調整を行ったりする処理を示すフローチャート図である。買い物リストの例を示す図である。在庫リストの例を示す図である。料理が２品の場合のタイムチャートの例を示す図である。料理が２品の場合のタイムチャートの別の例を示す図である。料理が３品の場合のタイムチャートの例を示す図である。料理が３品の場合のタイムチャートの別の例を示す図である。レシピデータの中の「調理手順」のデータを示す図である。本発明の第７の実施の形態に係る献立決定支援装置の機能ブロック図である。本発明の第７の実施の形態において、レシピデータベースが保持するレシピデータの構成とデータ例を示す図である。本発明の第７の実施の形態において、地域食材データベースが保持している地域食材テーブルの構成とデータ例を示す図である。本発明の第７の実施の形態において、献立決定支援装置が献立を提案する過程を示す処理フローである。図４０のステップＳ４０９の詳細手順を示す処理フローである。本発明の第８の実施の形態において、制御部がレシピデータベースの「出来上がりイメージ」欄の画像データを用いて献立を提案する基準を説明する図である。本発明の第８の実施の形態において、制御部がレシピデータベース１４１の「出来上がりイメージ」欄の画像データを用いて献立を１品のみ提案する基準を説明する図である。本発明の第８の実施の形態において、料理の出来上がりイメージのうちＲＧＢ値を算出する際に用いる色または座標を指定したレシピデータの例を示す図である。本発明の第９の実施の形態において、ユーザデータベースが格納する選択履歴情報の構成とデータ例を示す図である。出力部の画面表示イメージを示す図である。本発明の第１０の実施の形態において、地域食材データベースが保持する食材種類情報の構成とデータ例を示す図である。本発明の第１０の実施の形態において、ユーザが同じ食材を連続して希望した場合の献立提案例を示す図である。本発明の第１３の実施の形態において、レシピデータに含まれる各項目を表示するか否かを定義するデータを示す図である。本発明の第１５の実施の形態において、旬の時期が同じ、または旬の時期が近い単位で地域をグループ分けした例を示す図である。図５０と同じ内容のデータを日本地図上に示した図である。プルダウンメニューから宮城県を選択した例を示す図である。郵便番号から地域情報を取得する場合の入力および表示例である。電話番号から地域情報を取得する場合の入力および表示例である。似た気候の地域をグループ分けした例を示す図である。図５５に示した地域のグループ分けを日本地図上に示した図である。日時設定画面の１例を示す図である。カレンダー上で日付を指定する画面例である。月日入力欄に月日を数値入力する画面例である。プルダウンメニューで月日を選択する画面例である。本発明の第２５の実施の形態に係る献立決定支援装置１００の構成図である。本発明の第１７の実施の形態に係る献立提案装置１００の機能ブロック図である。本発明の第１７の実施の形態において、レシピデータベースが格納するレシピ情報の構成とデータ例を示す図である。本発明の第１７の実施の形態において、レシピの分類基準を示す図である。本発明の第１７の実施の形態において、制御部が献立を提案する処理を説明するフローである。本発明の第１８の実施の形態において、レシピ情報の構成とデータ例を示す図である。本発明の第１８の実施の形態において、レシピの分類基準を示す図である。本発明の第１９の実施の形態において、制御部が調理時間に基づいて献立を提案する処理を説明するフローである。本発明の第２１の実施の形態において、出力部が提示するレシピ情報の一例を示す図である。図６９と同じ料理を異なる調理器具で調理する際のレシピ情報を示す図である。本発明の第２２の実施の形態に係る献立提案装置とその周辺機器の構成を示す図である。食材毎に色で分類したデータの一例を示す図である。次の提案レシピまたは他のレシピを検索する際、食材毎の色のバランスを配慮したレシピ提案の検索条件設定を示す図である。

　１６０…入力部、２１０…対話（問いかけ）メッセージ抽出処理部、２１１…対話（問いかけ）メッセージデータベース、２２０…データベース検索手段、２３０…レシピ抽出処理部、２４０…レシピ情報データベース、２５０…ユーザ登録情報データベース、２５１…記念日データベース、２５２…在庫データベース、２５３…好みのレシピデータベース、２６０…システム登録データベース、２６１…行事データベース、２６２…天気データベース、２６３…旬食材データベース。

＜第１の実施の形態＞
　本明細書中においては、献立全体を構成する料理一品一品を「料理」と記載し、一つ又は複数の料理を組み合わせた献立全体を「献立」と、「献立」と「料理」のどちらを指す場合もありうる場合は「献立料理」と記載する。つまり、献立とは、一品以上の料理を含み、ユーザから入力された条件にしたがって提案するものであり、主食のみの献立もありうるし、主食と副菜などからなる献立もありうると定義する。また、「レシピ」とは、「料理の作り方などの情報」である。

　図１は、本発明の第１の実施の形態に係る献立決定支援装置１００の一構成例を示す機能ブロック図である。図１に示すように、献立決定支援装置１００は、日付特定部１１０と、地域特定部１２０と、天気情報取得部１３０と、記憶部１４０と、制御部１５０と、入力部１６０と、出力部１７０と、を備える。

　日付特定部１１０は、現在日時等を特定する。例えばタイマなどを用いて日付特定部１１０を構成することができる。予約調理を行う場合には、調理時間を特性するようにしても良い。

　地域特定部１２０は、献立決定支援装置１００の現在位置を、地域単位で特定する。ここでいう地域とは、旬の食材や特産品がそれぞれに異なる程度の大きさの範囲を指し、後述の旬食材データベース２６３における地域と同程度の範囲であることが好ましい。地域を特定する手法には、任意の公知技術を用いることができる。例えばＧＰＳを用いて現在位置を特定する、などの手法が考えられる。これから、ユーザが向かう地域を特定するようにしても良い。

　天気情報取得部１３０は、ネットワークを介して献立決定支援装置１００に接続されており、インターネット上で公開されている天気情報等を取得する。天気に関する情報とは、例えば指定した日時／地域の晴れ／曇り／雨といった天気、最高・最低・平均温度等、平均湿度などを表す情報のことである。過去の平均気温との差異を関数としても良い。但し、天気情報取得部１３０は、必ずしもネットワークを介して天気情報を取得する必要はなく、所望の天気情報が得られれば、天気情報を取得する具体的な手法は任意でよい。

　記憶部１４０は、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）やソリッドステートデバイス（不揮発性メモリ）などの記憶装置で構成される。構成内容については、後述の図２で説明する。

　制御部１５０は、献立決定支援装置１００の現在位置（地域）と日付、天気情報、および記憶部１４０が格納している各データベースを用いて、提案する献立を決定し、出力部１７０より出力する処理を制御する。献立を決定する過程については後述の図４等で説明する。

　入力部１６０は、献立を提案するよう献立決定支援装置１００に指示するためにユーザが使用する操作指示部である。提案に際しての条件設定を入力することもできる。入力部１６０は、例えばキーボード、キーパッド、タッチパッド、マウス、トラックボールなどの形態で実現することができる。外部端末からの有線・無線入力であっても良い。また、操作メニューを表示するための画面表示部などを適宜備える。

　出力部１７０は、制御部１５０が決定した提案する献立を出力する。出力形式は、例えば液晶ディスプレイなどを用いた画面表示によるものでもよいし、提案する献立の内容を記述したデータとして出力するものでもよい。画面表示デバイスについては、入力部１６０と共通化してもよい。外部端末への有線・無線出力であっても良い。

　図２は、記憶部１４０の構成内容であり、対話メッセージ抽出処理部２１０、データベース検索部２２０、レシピ抽出部２３０、レシピ情報データベース２４０、ユーザ登録情報データベース２５０、システム登録データベース２６０を備える。それぞれの詳細な構成を示す図を括弧内に示している。

　対話（問いかけ）メッセージ抽出処理部２１０は、ユーザ登録情報データベース２５０およびシステム登録データベース２６０の情報をもとに、データベース検索部２２０を介してユーザの条件に適した対話メッセージを抽出する。メッセージ抽出処理の詳細については、後述の図５で説明する。

　対話（問いかけ）メッセージデータベース２１１は、「今日は○○ちゃんの誕生日ですね。記念日にちなんだレシピを提案しましょうか」というような定型的な対話メッセージのデータベースが格納されている。メッセージ抽出処理と同様メッセージデータベースの詳細については、後述の図５で説明する。　データベース検索部２２０は、レシピ情報データベース２４０、ユーザ登録情報データベース２５０、システム登録データベース２６０の情報からユーザの条件に適したレシピの検索を実行する。検索部の詳細については、後述の図２０で説明する。

　レシピ抽出処理部２３０は、レシピ情報データベース２４０からユーザの条件に適したレシピを抽出する。抽出処理部の詳細は、後述の図２１で説明する。

　レシピ情報データベース２４０は、料理毎に料理名、材料、味、食感、色などの基本データを保持するデータベースである。詳細は後述の図３で説明する。

　ユーザ登録情報データベース２５０は、ユーザに依存する属性に関連する、記念日データベース２５１、在庫データベース２５２、好みのレシピデータベース２５３で構成され、ユーザ毎にカスタマイズするためのデータを格納するデータベースである。

　記念日データベース２５１は、ユーザが誕生日などの記念日に関する諸情報を登録したデータを保持する。

　在庫データベース２５２は、ユーザが自宅にある食材を登録したデータを保持する。また、献立決定支援装置１００により提案されたレシピの材料を、買い物リストとして登録したデータを保持する。詳細は後述の図１２で説明する。

　好みのレシピデータベース２５３は、ユーザの好みのレシピデータ、ユーザが好みのレシピを決めるまでの履歴データを保持する。この情報データは、入力部１６０にてユーザにより追加、消去等の編集ができる。詳細は後述の図１８で説明する。

　システム登録データベース２６０は、ユーザに依存しない属性に関連する、システムに内蔵された行事データベース２６１、天気データベース２６２、旬食材データベース２６３から構成され、ユーザ毎にカスタマイズするためのデータを格納するデータベースである。

　行事データベース２６１は、暦上の行事とその行事に関連した食材、料理のデータを保持する。

　天気データベース２６２は、天気情報取得部１３０により取得した天気情報および気温、湿度の値をもとにしたレシピを提案するために、気温、湿度の値の条件を設定したデータを保持する。また、条件にあわせたレシピの分類基準データを保持する。詳細は後述の図１０、図１１で説明する。

　旬食材データベース２６３は、地域および月毎の旬の食材、特産品のリストを保持する。詳細は後述の図１４で説明する。なお、地域固有の食材のリスト以外に、一般的な食材のリストを保持してもよい。以下では一般食材のリストについての説明は省略する。

　本発明における献立決定支援装置１００は、制御部１５０、出力部１７０が相当する。

　日付特定部１１０、地域特定部１２０、天気情報取得部１３０、制御部１５０は、これらの機能を実現する回路デバイスなどのハードウェアを用いて構成することもできるし、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）やマイコンなどの演算装置とその動作を規定するソフトウェアプログラムを用いて構成することもできる。後者のソフトウェアプログラムは、本発明における「献立決定支援装置」に相当する。

　図３は、レシピ情報データベース２４０が保持するレシピデータの構成例とデータ例を示す図である。レシピ情報データは、個々の料理の詳細情報を保持するデータである。以下、レシピ情報データが有する各情報欄について説明する。

（図３：「料理名」欄）
　「料理名」欄は、当該レシピデータが記述している料理の料理名を保持する。料理名そのものに、献立を提案する際に用いることのできる情報が含まれている場合もある。制御部１５０は、例えば現在の季節が冬であれば、料理名に「冷」などの寒さを連想させる文字を含むものを、提案する献立の対象から除外することができる。また、料理名にユーザ好みの料理の文字が含まれている場合、優先的に提案することもできる。どのようなキーワードを含む料理を除外するか、優先的に提案するかをユーザ登録情報データベース２５０に格納し、ユーザ毎にカスタマイズすることもできる。

（図３：「料理材料」欄）
　「材料」欄は、当該レシピデータが記述している料理を作るために用いられる食材データを保持する。特に、地域の旬の食材や特産品、在庫食材、ユーザ好みの食材を使用した献立を優先的に提案するとき、本欄が保持するデータを有効に活用することができる。

（図３：「種類」「ジャンル」欄）
　「種類」欄、「ジャンル」欄は、当該レシピデータが記述している料理の大まかな分類を表すデータを保持する。例えば、主食を「ごはんもの、麺類、その他の主食」にわけ、主食にもおかずにもなりうるものは、両方に分類しておいてもよい。制御部１５０は、１品目として例えば「ご飯もの」が決定された場合、２品目以降は「ご飯もの」以外の料理を提案するようにする。同様に、１品目として例えば「和食」が決定された場合、２品目以降もなるべく「和食」料理を提案するようにすることができる。

（図３：「味」欄）
　「味」欄は、当該レシピデータが記述している料理の大まかな味の種類を表すデータを保持する。制御部１５０は、例えば子供向けの献立を提案するよう指示されたときは、本欄が「辛」になっている料理を除外し、「甘」になっている料理を優先的に提案することができる。また、お年寄り向けの献立を提案するよう指示されたときは、「塩辛い」になっている料理を除外した料理を優先的に提案してもよい。

（図３：「食感」欄）
　「食感」欄は、当該レシピデータが記述している料理の食感を表すデータを保持する。制御部１５０は、例えば１品目として提案した料理の食感と異なる食感を有する料理を２品目以降に提案することにより、献立に多様性を持たせることができる。また、例えばお年寄り向けの献立を提案するよう指示されたときは、本欄が「硬い」になっている料理をなるべく除外するようにすることができる。

（図３：「色」欄）
　「色」欄は、当該レシピデータが記述している料理の色を表すデータを保持する。制御部１５０は、複数の料理を提案する場合、本欄の値を用いて、彩りのよい組み合わせを提案することができる。本欄の値は、料理全体の色を表すものとしてもよいし、食材毎に色を保持してもよい。例えばユーザから記念日データベース２５１のうち、お誕生日にちなんだ料理を提案するよう指示されたときは、本欄の色の種類が２色以上使われている料理を優先的に提案することができる。

（図３：「定番」欄）
　「定番」欄は、当該レシピデータが記述している料理が定番料理であるか否かを表すデータを保持する。

（図３：「イベント」欄）
　「イベント」欄は、当該レシピデータが記述している料理がどのような場面に向いている料理かを表わすデータを保持する。制御部１５０は、例えばユーザから記念日データベース２５１のうち、お誕生日にちなんだ料理を提案するよう指示されたときは、本欄が「お祝い」、「パーティ」になっている料理を優先的に提案することができる。

（図３：「手間／所要時間」欄）
　「手間／所要時間」欄は、当該レシピデータが記述している料理を作るために要する時間を表すデータを保持する。本欄の値は、提案された料理のなかからユーザが料理を選択する際の目安になる。例えばユーザが急いでいるときは、本欄の値が小さい料理が選択される場合が多いと考えられる。

（図３：「調理器具欄）
　「調理器具」欄は、当該レシピデータが記述している料理を作るときにユーザが使用する調理器具のリストを保持する。制御部１５０は、例えば暑い日には、調理者の体感温度を考慮し、コンロやフライパンなど暑さを感じやすい調理器具を使用する料理を提案しないようにするなど、料理を提案する際に本欄の値を参考情報として用いることができる。また、オーブンや炊飯器など調理を開始してしまえばその後は出来上がりまで何もしなくてよい調理器具を使用する料理を、フライパンなどのように常に付き添っていなければならない調理器具を使用する料理とセットにして提案する、といったこともできる。

また、調理者が調理器具によって暑さを感じるか感じないかの分類をしてもよい。

（図３：「調理場所」欄）
　「調理場所」欄は、当該レシピデータが記述している料理を作るときにユーザが使用する調理場所のリストを保持する。制御部１５０は、例えば、ガス台、レンジ台などのその調理に適切な調理場所のデータを保持する。

（図３：「調理方法」欄）
　「調理方法」欄は、当該レシピデータが記述している料理の調理方法を表すデータを保持する。ここでいう調理方法の種別とは、詳細な調理工程のことではなく、焼く、煮るといった大まかな調理手法のことである。制御部１５０は、献立の多様性の観点から、１品目に提案した料理の調理方法と２品目以降に提案する料理の調理方法を変えることが望ましい。

（図３：「調理時間」欄）
　「調理時間」欄は、「調理方法」欄の各調理方法に要する時間を保持する。

（図３：「出来上がり料理温度」欄）
　「出来上がり料理温度」欄は、当該レシピデータが記述している料理を美味しく飲食できる温度を表すデータを保持する。人が、温かく、または、冷たく、美味しいと感じる温度は、一般的に体温との差が２５度以上であることや、保温機能のある弁当箱の保温温度が５０度前後～６０度前後であるものが多いことから、例えば「温かい料理＝５５度以上」、「冷たい料理＝１２度以下」とする。常温については日本工業規格で定められている５度～３５度を参考に、「常温料理＝１５～３５度」とする。制御部１５０は、現在の季節が冬であれば、本欄の値が小さい料理を、提案する献立の対象から除外することができる。保持するデータは、例えば同じ汁物でも、味噌汁は６５度前後、甘みの強い汁粉などは多少低めの５０度程度のほうが美味しく感じられるという、温度の違いを考慮することが望ましい。

（図３：「出来上がりイメージ」欄）
　「出来上がりイメージ」欄は、当該レシピデータが記述している料理が完成した時のイメージを示す画像データを保持する。制御部１５０は、「色」欄に代えて、または「色」欄と併せて本欄から料理の色合いを抽出し、彩りのよい料理の組み合わせを提案することができる。

（図３：「調理手順」欄）
　「調理手順」欄は、当該レシピデータが記述している料理の詳細な調理手順を記述したデータを保持する。本欄は、各手順ごとの調理時間や使用する調理器具を記載することができる。また、ユーザが当該料理を実際に作ることができるか否かを判断するためなどの参考情報として用いることができる。また、料理を作る際に本欄を出力部１７０で画面表示させて参考にすることもできる。

（図３：「天気によるレシピ分類」欄）
　「天気によるレシピ分類」欄は、当該レシピデータが記述している料理がどのような天気に適しているかを示す情報を保持する。レシピ情報は、個々のレシピ毎に、料理名、料理材料（食材）、および（出来上がり）料理温度の少なくともいずれかを表す情報を保持する。

（図３：「カロリー」欄）
　「カロリー」欄は、調理後の料理のカロリーを示す欄である。

（図３：「食材費用」欄）
　「食材費用」欄は、調理に必要な食材の費用を示す欄である。

（図３：「食材毎の色ポイント」欄）
　「食材毎の色ポイント」欄は、当該レシピに含まれる食材の色の合計を色別にポイントで示す欄である。図３に示すデータは、１食材を１ポイントとして示しているが、ポイントの計算方法は適宜変更してもよい。

　図４は、献立決定支援装置１００が献立提案を行う過程および仕組みをフローチャート図で示したものである。以下、図４のフローチャートの各ステップについて説明する。

（図４：ステップＳ４０１：開始）
　献立決定支援装置１００が動作を開始すると、日付特定部１１０は現在日付を取得し、制御部１５０に出力する。

（図４：ステップＳ４０２：記念日データ取得条件の有無）
　制御部１５０は、日付特定部１１０より取得した日付を用いて記念日データベース２５１を検索し、取得した日付の条件にあう記念日データが有った場合、ステップＳ４０３へ進む。条件にあうデータが無かった場合、ステップＳ４０５へ進む。記念日データ取得条件については、後述の図６で説明する。

（図４：ステップＳ４０３：初めての提案かどうか）
　制御部１５０は、献立決定支援装置１００が日付特定部１１０より取得した日付と同じ日に初めて動作されたかどうかの確認処理を行う。初めて動作していた場合は、ステップＳ４０４へ進み、２回目以降の場合は、ステップＳ４０５へ進む。

（図４：ステップＳ４０４：メッセージ表示「提案しましょうか」）
　制御部１５０は、取得した日付の条件にあう記念日レシピを提案してほしいかどうか、ユーザに選択するよう促すメッセージを入力部１６０に画面表示させる。例えば、取得した日付が記念日データベース２５１に登録された誕生日データと一致した場合、「今日は○○ちゃんの誕生日ですね。記念日にちなんだレシピを提案しましょうか。」というようなメッセージを表示させる。ユーザは入力部１６０の画面で「ＹＥＳ」、「ＮＯ」のどちらかの選択を行う。「ＹＥＳ」の場合は、ステップＳ４０６へ進み、「ＮＯ」の場合は、ステップＳ４０５へ進む。このようにすると、大切な記念日を忘れることなく、記念日行事を実行する際にふさわしい料理を提供することが可能となる。

（図４：ステップＳ４０５：記念日レシピ検索条件設定ＯＦＦ）
　制御部１５０は、ステップＳ４０４でユーザにより「ＮＯ」が選択された時点で、記念日レシピ検索条件設定を除外し、ステップＳ４０７へ進む。記念日レシピ検索条件設定については、後述の図７で説明する。

（図４：ステップＳ４０６：記念日レシピ検索条件ＯＮ）
　制御部１５０は、ステップＳ４０４でユーザにより「ＹＥＳ」が選択された時点で、記念日レシピ検索条件設定をレシピ提案の候補に設定したままステップＳ４２７へ進む。記念日レシピ検索条件設定については、後述の図７で説明する。

（図４：ステップＳ４０７：行事データ取得条件の有無）
　制御部１５０は、日付特定部１１０より取得した日付を用いて行事データベース２６１を検索し、取得した日付の条件にあう行事データが有った場合、ステップＳ４０８へ進む。条件にあうデータが無かった場合、ステップＳ４１０へ進む。行事データ取得条件については、後述の図８で説明する。

（図４：ステップＳ４０８：初めての提案かどうか）
　制御部１５０は、献立決定支援装置１００が日付特定部１１０より取得した日付と同じ日に初めて動作されたかどうかの確認処理を行う。初めて動作していた場合は、ステップＳ４０９へ進み、２回目以降の場合は、ステップＳ４１０へ進む。これにより、同じ提案の場合には、重複した処理を排除することができる。

（図４：ステップＳ４０９：メッセージ表示「提案しましょうか」）
　制御部１５０は、取得した日付の条件にあう行事レシピを提案してほしいかどうか、ユーザに選択するよう促すメッセージを入力部１６０に画面表示させる。例えば、取得した日付が行事データベース２５２に登録された３月３日のひな祭りデータと一致した場合、「今日はひな祭りですね。行事にちなんだレシピを提案しましょうか。」というようなメッセージを表示させる。ユーザは入力部１６０の画面で「ＹＥＳ」、「ＮＯ」のどちらかの選択を行う。「ＹＥＳ」の場合は、ステップＳ４１１へ進み、「ＮＯ」の場合は、ステップＳ４１０へ進む。

（図４：ステップＳ４１０：行事レシピ検索条件設定ＯＦＦ）
　制御部１５０は、ステップＳ４０９でユーザにより「ＮＯ」が選択された時点で、行事レシピ検索条件設定を除外し、ステップＳ４１２へ進む。行事レシピ検索条件設定については、後述の図９で説明する。

（図４：ステップＳ４１１：行事レシピ検索条件設定ＯＮ）
　制御部１５０は、ステップＳ４０９でユーザにより「ＹＥＳ」が選択された時点で、行事レシピ検索条件設定をレシピ提案の候補に設定したままステップＳ４２７へ進む。行事レシピ検索条件設定については、後述の図９で説明する。

（図４：ステップＳ４１２：お天気データ取得条件の有無）
　制御部１５０は、日付特定部１１０より取得した日付、地域特定部１２０より取得した地域情報、天気情報取得部１３０より取得した天気、温度、湿度等を用いて、天気データベース２６２を検索し、取得した天気、温度、湿度の値の条件にあうデータが有った場合、ステップＳ４１３へ進む。条件にあうデータが無かった場合、ステップＳ４１４へ進む。天気データ取得条件については、後述の図１１で説明する。

（図４：ステップＳ４１３：メッセージ表示「提案しましょうか」
　制御部１５０は、取得した天気、温度、湿度の値の条件にあう行事レシピを提案してほしいかどうか、ユーザに選択するよう促すメッセージを入力部１６０に画面表示させる。例えば、取得した天気、温度、湿度の値が天気データベース２６２に設定された暑い日の条件と一致した場合、「今日は暑いですね。お天気にちなんだ（さっぱりした）レシピを提案しましょうか。」というようなメッセージを表示させる。ユーザは入力部１６０の画面で「ＹＥＳ」、「ＮＯ」のどちらかの選択を行う。「ＹＥＳ」の場合は、ステップＳ４１５へ進み、「ＮＯ」の場合は、ステップＳ４１６へ進む。

（図４：ステップＳ４１４：お天気レシピ検索条件設定ＯＮ）
　制御部１５０は、ステップＳ４１２での処理において条件にあうデータが無かった時点で、天気レシピ検索条件をレシピ提案の候補に設定したままステップＳ４１６へ進む。

（図４：ステップＳ４１５：お天気レシピ検索条件設定ＯＮ）
　制御部１５０は、ステップＳ４１３でユーザにより「ＹＥＳ」が選択された時点で、天気レシピ検索条件設定をレシピ提案の候補に設定したままステップＳ４２６へ進む。天気レシピ検索条件設定については、後述の図１１で説明する。

（図４：ステップＳ４１６：在庫データ取得条件の有無）
　制御部１５０は、在庫データベース２５２を検索し、在庫データが登録されていた場合、ステップＳ４１７へ進む。在庫データが登録されていなかった場合、ステップＳ４１８へ進む。

（図４：ステップＳ４１７：メッセージ表示「提案しましょうか」）
　制御部１５０は、在庫データベース２５２に登録されていた食材を使ったレシピを提案してほしいかどうか、ユーザに選択するよう促すメッセージを入力部１６０に画面表示させる。例えば、在庫数が多い食材（じゃがいも）があった場合、「じゃがいもが残っています。在庫の食材を使ったレシピ提案しましょうか。」というようなメッセージを表示させる。ユーザは入力部１６０の画面で「ＹＥＳ」、「ＮＯ」のどちらかの選択を行う。「ＹＥＳ」の場合は、ステップＳ４１９へ進み、「ＮＯ」の場合は、ステップＳ４２０へ進む。

（図４：ステップＳ４１８：在庫レシピ検索条件設定ＯＮ）
　制御部１５０は、ステップＳ４１６で在庫データが登録されていなかった時点で、在庫レシピ検索条件をレシピ提案の候補に設定したままステップＳ４２１へ進む。

（図４：ステップＳ４１９：在庫レシピ検索条件設定ＯＮ）
　制御部１５０は、ステップＳ４１７でユーザにより「ＹＥＳ」が選択された時点で、在庫レシピ検索条件設定をレシピ提案の候補に設定したままステップＳ４２６へ進む。在庫レシピ検索条件設定については、後述の図１３で説明する。

（図４：ステップＳ４２０：在庫レシピ検索条件を除外条件に設定ＯＮ）
　制御部１５０は、ステップＳ４１７でユーザにより「ＮＯ」が選択された時点で、在庫レシピ検索条件設定を除外条件に設定し、Ｓ４２１へ進む。

（図４：ステップＳ４２１：旬食材データ取得条件の有無）
　制御部１５０は、日付特定部１１０より取得した日付、地域特定部１２０より取得した地域情報を用いて旬食材データベース２６３を検索し、取得した日付、地域情報の条件にあう旬食材データが有った場合、ステップＳ４２２へ進む。条件にあうデータが無かった場合、ステップＳ４２３へ進む。旬食材データ取得条件については、後述の図１５で説明する。

（図４：ステップＳ４２２：メッセージ表示「提案しましょうか」）
　制御部１５０は、取得した日付、地域情報の条件にあう旬食材レシピを提案してほしいかどうか、ユーザに選択するよう促すメッセージを入力部１６０に画面表示させる。例えば、取得した日付、地域情報が旬食材データベース２６３に登録された条件と一致し、旬食材が「たけのこ」の場合、「たけのこが美味しい時期になりました。旬の食材を使ったレシピを提案しましょうか。」というようなメッセージを表示させる。ユーザは入力部１６０の画面で「ＹＥＳ」、「ＮＯ」のどちらかの選択を行う。「ＹＥＳ」の場合は、ステップＳ４２４へ進み、「ＮＯ」の場合は、ステップＳ４２５へ進む。

（図４：ステップＳ４２３：旬食材レシピ検索条件設定ＯＮ）
　制御部１５０は、ステップＳ４２１で条件にあう旬食材データが無かった時点で、旬食材レシピ検索条件をレシピ提案の候補に設定したままステップＳ４２６へ進む。

（図４：ステップＳ４２４：旬食材レシピ検索条件設定ＯＮ）
　制御部１５０は、ステップＳ４２２でユーザにより「ＹＥＳ」が選択された時点で、旬食材レシピ検索条件設定をレシピ提案の候補に設定したままステップＳ４２６へ進む。旬食材レシピ検索条件設定については、後述の図１５で説明する。

（図４：ステップＳ４２５：旬食材レシピ検索条件を除外条件に設定）
　制御部１５０は、ステップＳ４２２でユーザにより「ＮＯ」が選択された時点で、旬食材レシピ検索条件設定を除外条件に設定し、Ｓ４２６へ進む。

（図４：ステップＳ４２６：献立についての質問メッセージ表示）
　制御部１５０は、献立に関するいくつかの質問メッセージを入力部１６０に画面表示させる。ユーザは、後述の図１６で説明する手順に従って回答または条件を入力し、制御部１５０はその条件指定を受け付ける。なお、ユーザは、本ステップで回答または条件を入力しないでスキップすることもできる。回答または条件を入力した場合もスキップした場合もいずれにおいてもその条件を設定したまま、Ｓ４２７へ進む。ユーザは入力部１６０の画面から、好みのレシピデータベース２５３を閲覧できるようにしてもよい。

（図４：ステップＳ４２７：優先順位条件に従い提案）
　制御部１５０は、ステップＳ４０１からステップ４２６まで取得した処理データに基づき、レシピ提案の優先順位条件を設定し、その条件に従いレシピ情報データベース２４０の中からレシピ検索処理を行い、ステップＳ４２８へ進む。レシピ提案の優先順位条件については、後述の図２０で説明する。

（図４：ステップＳ４２８：提案レシピ＆メッセージ表示）
　制御部１５０は、ステップＳ４２８で得られたレシピを献立として提案する。提案するレシピの内容は、出力部１７０を介してユーザに提示され、「以下のレシピでいかがでしょうか」等のメッセージを入力部１６０に画面表示させる。また、制御部１５０は、表示されたレシピに「今日作るレシピ（決まり）」、「気になるレシピ（保留）」等を区別できるチェックマーク機能を設け、ユーザに選択するよう促すメッセージを入力部１６０に画面表示させる。ユーザはこのチェックマークをチェックすることにより、提案された料理（レシピ）を、「今作りたい（決まったレシピ）」or「気になるが今回は選択しない、すなわち、今回は作らないが今後作ってみたい（保留）」と評価することができ、またこれらのチェックマークをいずれもチェックしないことにより「そのレシピには興味がない」と評価することができる。ユーザがいずれかのレシピを選択（チェックマークにチェック）した場合は、ステップＳ４２９へ進み、いずれも選択しなかった場合はステップＳ４３１へ進む。また、このステップで提案レシピが検索されなかった場合、「提案メニューがありません」「検索条件を増やしてください」等のメッセージを表示してもよく、その場合はステップＳ４３１へ進む。

（図４：ステップＳ４２９：メッセージ表示）
　制御部１５０は、ステップＳ４２８で選択されたレシピと履歴情報を好みのレシピデータベース２５３に自動で登録する。なお、ユーザは自動で登録されたレシピを閲覧、削除等の編集を行うことができる。

（図４：ステップＳ４３０：メッセージ表示）
　制御部１５０は、ステップＳ４２８でユーザが選択したレシピを入力部１６０に画面表示させる。また、制御部１５０は、表示されたレシピに「レシピの詳細を見る」、「他のレシピも探す」等を選択できるチェックマーク機能を設け、ユーザに選択するよう促すメッセージを入力部１６０に画面表示させる。ユーザが「レシピの詳細を見る」を選択した場合は、ステップＳ４３２へ進み、「他のレシピも探す」を選択した場合はステップＳ４３１へ進む。なお、ユーザがいずれも選択しない場合はＳ４３３へ進み、提案終了したものとする。

（図４：ステップＳ４３１：次の提案開始：条件追加）
　制御部１５０は、ステップＳ４２８、ステップ４３０までのユーザの選択条件を設定したまま、Ｓ４０１へ進む。なお、制御部１５０は次の提案の処理を開始する前に、ユーザに選択条件を変更するかどうか選択するよう促すメッセージを入力部１６０に画面表示させる。また、ユーザがステップＳ４２６へ進めるよう選択できるようにしてもよい。次の提案設定条件については、図２２、図２３で説明する。

（図４：ステップＳ４３２）
　制御部１５０は、図３で説明したレシピデータの内容を画面表示させる。表示する項目の詳細は図２５で説明する。

（図４：ステップＳ４３３：提案終了）
　制御部１５０は、提案終了したことを示すメッセージを入力部１６０に画面表示させる。なお、ユーザが選択したレシピの食材を買い物リストにするかどうか選択できるよう入力部１６０に画面表示してもよい。

　図５は、対話メッセージ抽出処理部２１０について、対話を取得するための設定条件からユーザに対話メッセージを表示するための抽出方法について説明した図である。

（図５：５０１）
　制御部１５０は、対話メッセージ抽出処理部２１０を介して、記念日データベース２５１に登録された記念日と日付特定部１１０より取得した提案日の日付が一致した場合（提案日＝記念日データ登録日）、「今日は○○ちゃんの誕生日ですね。記念日にちなんだレシピを提案しましょうか」というようなメッセージを対話（問いかけ）メッセージデータベース２１１から抽出し、出力部１７０に表示させる。

　この場合に、対話メッセージデータベース２１１に格納される定型的な対話メッセージをベースにして、提案日が記念日データベース２５１に登録された記念日の前日だった場合（提案日+（１日）＝記念日データ登録日）、「もうすぐ○○ちゃんの誕生日ですね。記念日にちなんだレシピを提案しましょうか。」というようなカスタマイズされたメッセージを抽出（作成）し表示させる。すなわち、定型的な対話メッセージは、ユーザの属性（名称、誕生日など）に依存しないメッセージのベースであり、これをベースにして、ユーザの属性に依存するカスタマイズされたメッセージ（名前○○が入っているメッセージ等）を表示させることができる。カスタマイズするためには、ユーザに依存する属性をユーザ毎にカスタマイズするためのデータを格納するユーザ登録情報データベース２５０と、システムに内蔵され、ユーザに依存しない属性を、ユーザ毎にカスタマイズするためのデータを格納するシステム登録データベース２６０と、を用いることができる。

　提案日が記念日データベース２５１に登録された記念日の２日前だった場合も、前日だった場合と同様のメッセージを表示させてもよいし、異なる表現でメッセージを表示させてもよい。提案日に対して、登録された記念日の何日前からメッセージを表示させるか、記念日が過ぎてもメッセージを表示させるかの設定条件はユーザによって設定することができる。なお、メッセージ表示画面には記念日の名称、日付等を表示してもよい。

（図５：５０２）
　制御部１５０は、対話メッセージ抽出処理部２１０を介して、行事データベース２６１に登録された行事日、例えば３月３日のひな祭りと日付特定部１１０より取得した提案日の日付が一致した場合（提案日＝行事データ登録日）、「今日はひな祭りですね。行事にちなんだレシピを提案しましょうか。」というようなメッセージを抽出し、入力部１６０に表示させる。行事データベース２６１に登録された行事日、例えば３月３日のひな祭りが提案日の前日だった場合（提案日＋（１日）＝行事データ登録日）、「もうすぐひな祭りですね。行事にちなんだレシピを提案しましょうか。」というようなメッセージを抽出し表示させる。提案日が行事データベースに登録された行事日の２日前だった場合も、前日だった場合と同様のメッセージを表示させてもよいし、異なる表現でメッセージを表示させてもよい。提案日に対して、登録された行事日の何日前からメッセージを表示させるか、行事日が過ぎてもメッセージを表示させるかの設定条件はユーザによって設定できる。メッセージ表示画面には、行事の名前、日付等を表示してもよい。

（図５：５０３）
　制御部１５０は、日付特定部１１０より取得した日付、地域特定部１２０より取得した地域情報、天気情報取得部１３０より取得した情報が、例えば「気温：１０度」、「湿度：４０％」だった場合、対話メッセージ抽出処理部２１０を介して、天気データベース２６２に設定された条件に従って処理を行い、寒い日と判断されれば、「今日は寒いですね。暖かいレシピを提案しましょうか。」というようなメッセージを抽出し、入力部１６０に表示させる。メッセージ表示画面には、取得した日付、天気情報等を表示してもよい。天気データベース２６２の設定条件についての詳細は、後述の図１１で説明する。

（図５：５０４）
　制御部１５０は、対話メッセージ抽出処理部２１０を介して、在庫データベース２５２に登録された食材が日付特定部１１０より取得した提案日に１個以上登録されていて、例えばその食材が「玉ねぎ」の場合、「玉ねぎが残っています。在庫を使ったレシピを提案しましょうか。」というようなメッセージを抽出し、入力部１６０に表示させる。メッセージ表示画面には、取得した日付、在庫リスト等を在庫数が多いものから順番に表示するようにしてもよい。

（図５：５０５）
　制御部１５０は、対話メッセージ抽出処理部２１０を介して、日付特定部１１０より取得した提案日、地域特定部１２０より取得した地域情報と旬食材データベース２６３に登録された旬食材が一致し、例えばその旬食材が「さんま」の場合、「さんまが美味しい時期になりました。旬の食材を使ったレシピを提案しましょうか。」というようなメッセージを抽出し、入力部１６０に表示させる。メッセージ表示画面には、取得した日付、旬の食材リスト等を表示してもよい。

　図６は、図４のフローチャート図のステップＳ４０２の記念日データ取得条件、ユーザが登録した記念日データベース２５１を示す図である。制御部１５０は、ステップＳ４０２において設定された記念日データ取得条件と記念日データベース２５１の日付の一致を確認する。記念日データベース２５１は、月日、名前、タイトル、好きな食べ物、嫌いな食べ物以外にも項目を増やして登録することができる。また、記念日データ取得条件の設定日の期間を変更することができる。

　図７は、図４のフローチャート図のステップＳ４０５、Ｓ４０６で、レシピ提案の候補に設定するか、設定しないかの選択を行うベースとなる記念日レシピ検索条件設定のデータ例を示す図である。制御部１５０は、例えば、ステップＳ４０６でレシピ提案の候補に設定された場合、記念日データベース２５１の好きな食べ物に「ナポリタン、トマト」、嫌いな食べ物に「にら」が登録されているのを認識し、データベース検索手段２２０を介して、レシピ情報データベース２４０の中から、好きな食べ物に登録されている料理名、食材名を優先し、嫌いな食べ物は除外したレシピを検索する。他の例として、好きな食べ物、嫌いな食べ物どちらも登録されていない場合、レシピ情報データベース２４０の項目のイベントが「お祝、パーティ」、色が「２色以上」使われているレシピを優先し、色が「１色」しか使われていないレシピを除外したレシピを検索する。なお、Ｓ４０５でレシピ提案の候補に設定されなかった場合は、記念日レシピ検索条件設定データを除外して、次のステップに進む。

　図８は、図４のフローチャート図のステップＳ４０７の行事データ取得条件、行事データベース２６１が保持しているデータ例を示す図である。制御部１５０は、ステップＳ４０５において、設定された行事データ取得条件と行事データベース２６１の日付の一致を確認する。行事データベース２６１は、行事日の設定を変更することができ、また、行事データ取得条件の設定日、項目を増やして登録することができる。また、行事データ取得条件の設定日の期間を変更することができる。

　図９は、図４のフローチャート図のステップＳ４１０、Ｓ４１１で、レシピ提案の候補に設定するか、設定しないかの選択を行うもととなる行事レシピ検索条件設定のデータ例を示す図である。制御部１５０は、例えば、ステップＳ４１１でレシピ提案の候補に設定された場合、行事データベース２６１に登録されている、例えば、ひな祭りのレシピを提案する場合、データベース検索部２２０を介して、レシピ情報データベース２４０の中から「お寿司、はまぐり、菜の花」が登録されている料理名、食材名を優先し、例えば、お寿司の中にうなぎが入っていたら、食べ合わせの悪い「梅干し」を除外したレシピを検索する。他の例として、クリスマスのレシピを提案する場合、レシピ情報データベース２４０の項目の料理名、食材が「肉」、ジャンルが「洋食」、イベントが「パーティ」のレシピを優先し、色が「１色」しか使われていないレシピを除外したレシピを検索する。

　図１０は、天気データベース２６２が保持するレシピの分類基準データ例を示す図である。ここでは、図３における「天気によるレシピ分類」欄の「温レシピ」「冷レシピ」「保存レシピ」の分類基準を示した。以下、各分類基準について説明する。

（１）温レシピの分類基準
　レシピ名に「鍋、あったか、あつあつ、ほかほか」という文字が含まれているレシピ、料理温度が「温かい」レシピは、温かい料理である温レシピであるとみなす。

（２）冷レシピの分類基準
　レシピ名に「冷たい、冷製、冷や、あっさり、さっぱり」という文字が含まれているレシピ、材料に「レモン、酢、氷」を含むレシピ、料理温度が「冷たい」レシピは、冷たい料理である冷レシピであるとみなす。

（３）保存レシピの分類基準
　料理材料として、一般に保存期間が長い「根菜、缶詰、春雨、乾燥わかめ、ひじき、高野豆腐、レトルト食品」を用いるレシピは、保存に適した料理である保存レシピであるとみなす。この保存レシピは、例えば大雨、雪、台風などの悪天候時に調理者が外出することなく料理できるよう、家に備蓄されていると想定される材料を使った料理レシピを提案するために用いるとよい。ユーザは家の冷蔵庫や床下収納に常備されている食材、調味料を在庫データベース２５２に登録しておくこともでき、その食材を保存レシピとして分類してもよい。また、悪天候時に提案するレシピに限らず、天気情報に応じて提案する温レシピや冷レシピと適宜組み合わせてもよい。

（４）その他のレシピ
　上記分類条件に合致しないレシピは、中間レシピとして、暑い／寒いなどの温度をあまり感じない気温の時に提案するレシピとして用いるとよい。

　以上のように、天気データベース２６２には、各料理と気温の高低とを対応付ける情報が格納されている。温度の他に、天気（雨などの度合い（大雨、台風、小雨など））、湿度などでも良い。

　図１１は、天気データベース２６２に設定された気温、湿度の値の条件および図４のフローチャート図のステップＳ４１４、Ｓ４１５において、制御部１５０が取得した天気情報をもとに設定条件にあった天気レシピの検索条件を設定するまでの処理について説明するフローチャート図である。以下、図１１の各ステップについて説明する。

（図１１：ステップＳ１１００）
　制御部１５０は、日付特定部１１０より日付を、地域特定部１２０より地域情報を、天気情報取得部１３０より天気情報を、それぞれ取得する。

（図１１：ステップＳ１１０１）
　制御部１５０は、ステップＳ１１００で取得した日付と地域と天気情報（少なくとも気温と湿度）を、出力部１７０に出力する。

（図１１：ステップＳ１１０２～Ｓ１１０４）
　ステップＳ１１０１で取得した湿度が、例えば５０％未満である場合はステップＳ４０８へ進み、６０％以上８０％未満である場合はステップＳ１１０５へ進み、８０％以上である場合はステップＳ１１０６へ進み、それ以外（５０％以上６０％未満）の場合はステップＳ１１０７へ進む。

（図１１：ステップＳ１１０５～Ｓ１１０７）
　これらのステップは、湿度に起因する体感温度の差を補正するためのものである。湿度が８０％以上の場合は体感温度が高くなるので、制御部１５０は、実際の気温に３℃を加えた値を用いて以下の処理を行う。同様に、湿度が６０％以上８０％未満の場合は２℃を加え、５０％以上６０％未満の場合は１℃を加える。湿度が５０％未満の場合は、補正は行わない。

（図１１：ステップＳ１１０８～Ｓ１１０９）
　以上のステップから得られた温度が１８℃未満である場合はステップＳ１１１０へ進み、１８℃以上２５℃未満である場合はステップＳ１１１１へ進み、２５℃以上である場合はステップＳ１１１２へ進む。

（図１１：ステップＳ１１１０～Ｓ１１１２）
　制御部１５０は、以上のステップから得られた温度が１８℃未満である場合は寒い日であるとみなして温レシピを提案し、１８℃以上２５℃未満である場合は中間レシピを提案し、２５℃以上である場合は暑い日であるとみなして冷レシピを提案する。

　尚、暑い寒いは、前の日との関係などに依存する場合があるため、前の日からの変動幅や平均気温からの変動などに依存させるようにしても良い。

　以上、ステップＳ４１４、Ｓ４１５において、天気レシピの検索条件を設定した場合のレシピ提案方法について説明した。

　図１２は、在庫データベース２５２にユーザが登録した在庫食材データ例を示す図である。ユーザは入力部１６０の画面から自宅にある食材、数量等を登録することができる。また、このデータを買い物リストデータと連動させ、例えば、にんじんを買った場合は、自動的に在庫データに登録するようにし、にんじんを使ったら消去できるようにしてもよい。この在庫データが、図４のフローチャート図のステップＳ４１６においての在庫データ取得条件となる。

　図１３は、図４のフローチャート図のステップＳ４１８、Ｓ４１９、Ｓ４２０において、在庫データがあるかないかの取得条件およびユーザが在庫食材を使ったレシピ提案を選択するかしないか、それぞれの在庫レシピ検索条件設定のデータ例を示す図である。制御部１５０は、例えば、ステップＳ４１９でレシピ提案の候補に設定された場合、在庫データベース２５２を参照し、データベース検索部２２０を介して、レシピ情報データベース２４０の中から、在庫食材に登録されている料理名、食材名を含んだレシピを優先して検索する。検索条件の一例として、検索したレシピの食材が在庫食材に登録されている食材と比較し、食材が足りなかったとしてもそのレシピを検索条件設定に追加し提案してもよい。その場合、ユーザに例えば「キャベツ」が足りなかったら、「在庫食材にはキャベツがありませんでしたが、このレシピを提案しました。キャベツのかわりにほうれん草、小松菜白菜、など使用してはいかがでしょうか。」というようなメッセージを表示してもよい。なお、ステップＳ４２０で、ユーザが選択しなかった場合は、在庫食材をレシピ検索条件設定から除外して、次のステップに進む。

　図１４は、旬食材データベース２６３が保持している地域ごとの旬食材データ例を示す図である。旬食材データベース２６３は、各月の旬の食材および地域特産品の情報を、地域毎に保持している。この旬食材データが、図４のフローチャート図のステップＳ４２１においての旬食材データ取得条件となる。

　図１５は、図４のフローチャート図のステップＳ４２３、Ｓ４２４，Ｓ４２５において、旬食材データがあるかないかの取得条件およびユーザが旬食材を使ったレシピ提案を選択するかしないか、それぞれの旬食材レシピ検索条件設定のデータ例を示す図である。制御部１５０は、ステップＳ４２１で、旬食材データベース２６３を参照することにより、地域および月毎の旬の食材および地域特産品を把握できる。提案日に旬食材データの登録がなかった場合は、必ずしも提案日の旬食材または特産品を選択する必要はなく、例えば当月の前後２ヶ月以内であれば旬の食材または特産品の範囲に含むものとして検索条件を設定してもよい。旬食材または特産品をどの期間範囲内で選択するかについてのデータを、例えば旬食材データベース２６３に格納しておき、カスタマイズできるようにしてもよい。制御部１５０は、例えば、ステップＳ４２４でレシピ提案の候補に設定された場合、旬食材データベース２６３を参照し、データベース検索部２２０を介して、レシピ情報データベース２４０の中から、旬食材に登録されている料理名、食材名を含んだレシピを優先して検索する。なお、ステップＳ４２５で、ユーザが選択しなかった場合は、旬食材をレシピ検索条件設定から除外して、次のステップに進む。

　図１６は、図４のフローチャート図のステップＳ４２６の詳細手順を示す処理フロー図である。以下、図１６の各ステップについて説明する。

（図１６：ステップＳ１６０１）
　制御部１５０は、入力部１６０に、例えば「なにを使いたいですか？」などのメッセージを表示させる。ユーザは、例えば、冷蔵庫にある食材や、帰宅途中に買う予定の食材など、使いたい食材を指定する。本ステップでは、複数の食材を選択できるようにしておくことが望ましい。

　また、制御部１５０は、入力部１６０に、例えば「あるもの（食材）を調べますか？」などのメッセージを表示させ、ユーザが「調べたい」と回答した場合は、在庫データベース２５２、ネットワークに繋がった冷蔵庫の在庫データベース等から食材を指定することができる。

（図１６：ステップＳ１６０２）
　制御部１５０は、入力部１６０に例えば「誰が食べますか？」などのメッセージを表示させる。ユーザは、料理を食べる人物の種別、例えば、小さい子供、中高生～大人、お年寄り、などの人物種別を指定する。本ステップでは、複数の人物種別を指定できるようにしてもよい。

（図１６：ステップＳ１６０３）
　制御部１５０は、入力部１６０に例えば「料理の種類は？」などのメッセージを表示させる。ユーザは例えば、献立の提案を受けたいご飯もの、麺類、おかず、汁物等や、主食、主菜、副菜、汁物等の料理種別を指定する。本ステップでは、複数の料理種別を指定できるようにしてもよい。

（図１６：ステップＳ１６０４）
　制御部１５０は、入力部１６０に例えば「食べたいジャンルは？」などのメッセージを表示させる。ユーザは例えば、和食、洋食、中華、その他、おまかせ、などの料理ジャンルを指定する。本ステップでは、複数の料理ジャンルを指定できるようにしてもよい。

（図１６：ステップＳ１６０５）
　制御部１５０は、入力部１６０に例えば「料理の手間は？」などのメッセージを表示させる。ユーザは例えば、簡単、普通、手間がかかる、などの種別を指定する。本ステップでは、複数の種別を指定できるようにしてもよい。

　以上、図１６の各ステップの条件受付手順について説明したが、ユーザは図１６の各条件を入力せずそれぞれ個別にスキップすることもできるし、全ての条件をスキップすることもできる。スキップされた条件については、制御部１５０は特に希望条件はないものとして取り扱う。例えば、食べたいジャンルがスキップされた場合は、和食でも洋食でも中華でも何でも提案可能と判断する。

　図１７は、図４のフローチャート図のステップＳ４２６において、制御部１５０が献立に関するいくつかの質問メッセージを、出力部１７０を介して入力部１６０に表示したイメージ画面を示す図である。この画面での回答入力方法は、食材等をそのまま文字入力しても良いし、食材のリストから選択しても良いし、在庫データベース２５２から選択しても良い。食材を入力する際、例えば「豚薄切り肉」よりも詳細に「豚バラスライス」というように入力したり、選択したりすることができる。

１）何を使いたいか？　食材名で回答を求める。

２）誰が食べるか？　年齢層で回答を求める。

３）料理の種類は？　ご飯物など大きな種別で回答を求める。

４）食べたいジャンルは？　和食などのジャンルで回答を求める。

５）調理の手間は？　どの程度の手間をかけても良いかの回答を求める。

　図１８は、好みのレシピデータベース２５３が保持するデータ例を示す図である。図４のステップＳ４２８において、ユーザが「今日作る（これで決まり）」または「気になる（保留）」を選択した場合、制御部１５０は、それまでの選択履歴である日付、地域、天気、湿度、温度、対話画面でのユーザの選択情報、図３で説明したレシピ情報のレシピ名、食材等の全項目を好みのレシピデータベース２５３に登録する。この登録データをもとに、装置からの回答が得られる。

　図１９（ａ）、（ｂ）は、制御部１５０により、好みのレシピデータベース２５３に登録されたレシピを各項目別に分類し、ユーザが選択した条件を比率で示したデータ図である。例えば、記念日のレシピとして初めて「ナポリタン」を選択し登録した場合、図１８で説明したレシピ登録の各項目の選択率については１００％となる。次に記念日のレシピとして「ハンバーグ」を選択し登録した場合、レシピ名の「ナポリタン」の選択率は５０％となる。記念日の登録件数が増えるほど、レシピ名それぞれの選択率は低くなる。食材等他の項目の選択率についてもレシピ名と同様である。また、それぞれの選択項目である行事、天気、在庫、旬食材、指定食材、指定メンバー、指定種類、指定ジャンル、指定調理手間等についても同様に選択率が計算される。なお、ユーザは図４のフローチャート図のステップＳ４３０において、入力部１６０に表示された「チェックしたレシピを見る」という選択画面で、好みのレシピデータ２５３に登録された各選択項目別の登録件数、選択率等を閲覧することができる（図１９（ｂ））。この図は、登録状況を外観するものであり、登録の修正時などに役立てることができる。

　図２０は、図４のフローチャート図のステップＳ４２７において、制御部１５０がユーザからの選択情報および質問画面での回答情報に基づき、レシピ提案の優先順位条件の設定方法について示したデータ図である。図２０に示すように、選択項目と、希望あり、なしに基づく優先条件の設定の有無と、を示している。この図に基づいて、設定を行うことができる。

　図２１は、図２０で説明したレシピ提案の優先順位条件に基づき、制御部１５０が、ユーザが選択した各項目の検索設定条件により多数のレシピが検索された場合、好みのレシピデータ２５３からのレシピ抽出処理手段を示した図である。例えば、記念日レシピを提案するようユーザが選択し、図７の記念日レシピ検索条件設定に基づき多数のレシピが検索された場合、制御部１５０は、図４のフローチャート図のステップＳ４２８において出力部１７０を介して入力部１６０にレシピを表示する際、例えば５０件以上表示してもユーザは選択に不便を感じるため、ユーザが画面で閲覧しやすい件数に絞り込む必要がある。閲覧可能な件数は１０件～１５件が適切であるため、検索結果が多数の場合は、レシピ名および食材名＝在庫データベースに登録された材料が入っているレシピ、好みのレシピデータベースに登録された記念日レシピ＝過去３回分提案したレシピ、調理時間が短いレシピ、という優先順位を設定することで、ユーザへのレシピ提案の抽出処理の精度が上がると思われる。なお、画面表示するレシピ件数は、入力部１６０において、ユーザにより設定できるようにしてもよい。

　図２２は、図４のフローチャート図のステップＳ４３１において、制御部１５０が、次の提案レシピまたは他のレシピを検索するための設定条件データ例を示す図である。図４のフローチャート図のステップＳ４２８において提案表示されたレシピの中に、ユーザが作りたいレシピが無かった場合や、Ｓ４３０においてユーザが作りたいレシピは見つかったが他のレシピも探したい場合に図２２の条件が設定される。例えば、制御部１５０は、ユーザが作りたいレシピが無かった場合、ユーザが最初に選択した回答項目情報（記念日、行事、天気、在庫、旬、メンバー）の選択条件は初期設定のままステップＳ４０１に進み再度検索する。制御部１５０は、ユーザが作りたいレシピは見つかったが他のレシピも（もう１品）探したい場合、図２２に示すようにユーザが初期検索時に指定した食材、種類、ジャンル、手間の選択情報があればその情報基づいて選択条件および除外条件を設定し、その条件に従ってレシピ抽出処理部２３０を介してレシピ情報データベース２４０から抽出する。例えば、記念日レシピでナポリタンを作ることにした（この場合「決まったレシピ」＝「ナポリタン」となる）が、もう１品作りたい、他のレシピも探したいという場合、選択条件（優先して選択するための条件）に次の項目を設定する。決まったレシピをナポリタンとする。

・「種類：おかず（指定がなければ条件設定しなくてもよい）」
・「ジャンル：決まったレシピと同じジャンル（洋食）」
・「手間：決まったレシピが簡単＝簡単」
・「味：決まったレシピと異なる味（酸）」
・「食感：決まったレシピと異なる食感（柔らかい、ツルツル）」
・「色：決まったレシピと異なる色（赤、緑、橙）」
・「調理方法：決まったレシピと異なる調理方法（炒める、茹でる）」
　また、除外条件（選択から除外するための条件）に次の項目を設定する。

・「種類：麺類」
・「手間：決まったレシピが簡単＝手間がかかる」
・「味：決まったレシピと同じ味」
・「食感：決まったレシピと同じ食感」
・「色：決まったレシピと同じ色」
・「調理器具：決まったレシピと同じ調理器具（ガス台、なべ、フライパン）のレシピ＝１品まで（３品以上にならないようにする）
・「調理方法：決まったレシピと同じ調理方法」を設定する。

　制御部１５０は、上記の検索条件を優先してレシピを提案する。

　図２３は、図４のフローチャート図のステップＳ４３１において、制御部１５０が次の提案レシピまたは他のレシピを検索する段階で、入力部１６０に条件追加変更画面を表示させるデータおよびその選択条件に従った検索設定条件データを示す図である。質問１）から５）に応じて、例えば、ユーザがステップＳ４２８で作りたいレシピが無かった場合、ユーザが入力部１６０の画面で、食材、メンバー、種類、ジャンル、手間、天気、旬、行事、記念日の各項目をユーザの希望により追加変更すると、制御部１５０は図２３のそれぞれの項目の検索条件を優先してレシピを提案する。また、ユーザは入力部１６０の画面にて好みのレシピデータベース２５３に登録されたレシピを優先して検索するかどうか選択できるようにしてもよい。

　図２４は、図４のフローチャート図のステップＳ４２７において、制御部１５０が提案レシピを、出力部１７０を介して入力部１６０に表示したイメージ画面を示す図である。ここでは出力部１７０が画面表示デバイスを備え、画面表示によってユーザに献立を提案することを想定する。制御部１５０は、複数の料理を組み合わせた献立を提案するとき、献立内の各料理が使用する食材の偏りについて配慮する。具体例の詳細については、＜第１０の実施の形態＞で説明する。

　図２５は、図４のフローチャート図のステップＳ４３２において、制御部１５０が出力部１７０を介して入力部１６０にレシピデータに含まれる各項目を表示するか否かを定義するデータを示す図である。レシピデータの各項目は、出力部１７０で提案結果を表示するか否かをユーザの好みによりカスタマイズできるようにしておくことが望ましい。例えば、人によって「辛いか」、「所要時間はどのくらいか」などを表示画面に表示していた方が便利と感じる人もいるからである。制御部１５０は、出力部１７０にレシピデータの内容を画面表示するよう指示する際、図２５に示すデータを読み込み、表示項目を調節する。図２５のデータは、例えばユーザ毎のカスタマイズ情報として、ユーザ登録情報データベース２５０などに格納しておくとよい。このように、設定をするように構成することで、ユーザの意向により適切なカスタマイズが可能である。

　図２６は、入力部１６０において、ユーザが記念日のデータを入力する様子を示す画面の表示例を示す図である。図２６に示すように、画面表示には、記念日入力画面との表示と、日にち、タイトル（名前）、好きな食べ物、苦手な食べ物、カレンダー、内容とそのスクロールバー、登録入力ボタンなどが配置されている。現在の表示では、２００９年９月１日にポイント（カーソル）が合わせられており、その日の登録データを入力していく画面である。参照ボタンを設けて、適切な入力を選択できるようにしても良い。

　図２７は、図４のフローチャート図のステップＳ４０４、Ｓ４０９において入力部１６０に表示された対話メッセージの表示画面例を示す図である。図２７（ａ）に示すように、装置側からユーザに対して、例えば、「今日は○○ちゃんの誕生日ですね。記念日にちなんだレシピを提案しましょうか」などの問いかけがあり、これに対して、「Ｙｅｓ」、「Ｎｏ」のボタンで応答することができるようになっている。また、図２７（ｂ）に示すように、「明日（３月３日）はひな祭りですね。記念日にちなんだレシピを提案しましょうか」などの問いかけがなされ、同様にＹｅｓ、Ｎｏの応答が可能である。

　以上のように、本発明の第１の実施の形態に係る献立決定支援装置１００は、ユーザが誕生日などの記念日に関する諸情報を登録したデータを保持する記念日データベース２５１、ユーザが自宅にある食材を登録したデータを保持する在庫データベース２５２、ユーザが好みのレシピを登録したデータおよびユーザが好みのレシピを決めるまでの履歴データを保持する好みのレシピデータベース２５３、暦上の行事とその行事に関連した食材と料理のデータを保持する行事データベース２６１、天気情報取得部１３０により取得した天気情報および気温、湿度の値をもとにしたレシピを提案するために、気温、湿度の値の条件を設定したデータを保持する天気データベース２６２、月毎の旬の食材および特産品を地域毎に保持する旬食材データベース２６３を備える。制御部１５０はこれを用いて、ユーザの選択情報にあわせて条件にあったレシピを対話メッセージ抽出処理２１０、データべース検索手段２２０、レシピ抽出処理２３０を介して、レシピ情報データベース２４０から検索してユーザに提案することができる。

＜第２の実施の形態＞
　図２８は、本発明の実施の形態２に係る献立決定支援装置１００の構成例を示す図である。本発明の第２の実施の形態における献立決定支援装置１００は、第１の実施の形態と同様の構成例を有するが、各機能部が物理的に複数の装置に分割されて構成されている点が異なるため、ここでは献立決定支援装置と称する。以下、各装置について説明する。

　端末装置２００（クライアント端末）は、リモコン装置、携帯端末などであり、日付特定部１１０、地域特定部１２０、天気情報取得部１３０、入力部１６０、出力部１７０を備える。端末装置２００は、ユーザが手にとって所望の献立を探すためのものであり、携帯型の装置として構成されていることが望ましい。

　サーバ３００は、例えば、装置内に設けられる機能部であり、日付特定部１１０、地域特定部１２０、天気情報取得部１３０、記憶部１４０、制御部１５０、入力部１６０、出力部１７０を備える。サーバ３００は、端末装置２００から献立を提案するようリクエストを受け、上述の第１の実施の形態で説明した献立提案処理を実行して、端末装置２００に提案内容を提示するのが一般的である。サーバ３００は、端末装置２００が送信するリクエストや検索条件の指定を受け付ける検索条件入力部１６０を備える。サーバ３００は、異なるユーザが使用する複数の端末装置２００からのリクエストに応じられるように、ユーザＩＤなどにより識別されてデータが管理されるような構成としてもよい。

　表示装置４００は、第２出力部４１０を備える。第２出力部４１０は、好適には、端末装置２００が備える出力部１７０よりも大きな画面表示部である。ユーザは、端末装置２００の出力部１７０で献立を見ることもできるし、例えば調理を開始するときは、より大画面の第２出力部４１０でレシピデータを見ながら調理をする、といった使い分けをすることもできる。

　電子機器（電化製品）装置５００は、入力部１６０、出力部１７０を備える。電子機器（電化製品）装置には、冷蔵庫、電子レンジ、オーブンレンジ、炊飯器、モニタ、テレビ、電話、ファクシミリ、デジタルフォトフレーム、パーソナルコンピューターを含む。

　端末装置２００、サーバ３００、表示装置４００、電子機器（電化製品）装置５００は、ネットワーク６００によって接続されており、互いにデータを送受信することができる。好適には、ネットワーク６００は無線ネットワークであり、各装置が無線通信によって相互に通信できることが好ましい。

　各装置を無線で接続すれば、端末装置２００を携帯端末装置（パーソナルコンピューター、電子手帳、携帯電話、携帯ゲーム機、電子手帳なども含まれる）によって構成することができる。これによりユーザは、場所を選ばずに献立を検討することができ、また、献立を決めた後に、買い物の際に持参することができる。

＜第３の実施の形態＞
　以上の第１～第２の実施の形態で説明した献立決定支援装置１００は、電子機器に組み込んでその電子機器に献立提案機能を付加するように構成してもよい。例えば以下のような電子機器に組み込む例が考えられる。

（組み込み例のその１：電子レンジ）
　電子レンジに献立決定支援装置１００を組み込み、ユーザが電子レンジを用いた料理を作り易くすることができる。この場合、調理器具として電子レンジを用いる料理を優先的に提案するようにしてもよい。

（組み込み例その２：冷蔵庫）
　冷蔵庫に献立決定支援装置１００を組み込む場合、冷蔵庫のもつ庫内の在庫管理機能と献立決定支援装置１００が連動し、在庫する食材およびその食材を用いる料理を優先的に提案するようにしてもよい。

（組み込み例その３：携帯電話、電子手帳）
　携帯電話または電子手帳に献立決定支援装置１００を組み込む場合、献立を決めた後、買い物する食材がある場合の買い物メモを記憶・表示できる機能を搭載してもよい。

＜第４の実施の形態＞
　以上の第１～第３の実施の形態で説明した献立決定支援装置１００の機能は、ＣＰＵなどの演算装置が実行するプログラムとして実装することができる。例えば、日付特定部１１０、地域特定部１２０、天気情報取得部１３０、記憶部１４０、制御部１５０、入力部１６０、出力部１７０の機能を本発明に係る献立決定支援プログラムとして実装し、演算装置に実行させることにより、献立決定支援装置１００の機能を実現することができる。

　また、前記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能を献立決定支援装置１００にすでに記録されているＯＳ（Ｏｐｅｒａｉｎｇ　Ｓｙｓｔｅｍ）などのプログラムとの組み合わせで実現してもよい。

　上記プログラムをコンピュータ読み取り可能な記憶媒体に記録して、この記憶媒体に記録されたプログラムをＣＰＵに読み込ませ、実行することにより、献立決定支援装置１００の各機能部の処理を実現してもよい。

　上記プログラムを格納した「記憶媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ、ＳＲＡＭ、フラッシュメモリ、ＤＶＤ、ブルーレイディスク等のコンピュータ読み取り可能な可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置などのことをいう。さらには、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。

＜第５の実施の形態＞
　献立決定後に、買い物チェックリストを作成したり、食材の在庫量調整を行ったりする処理の一例を図２９に示す。ステップＳＣ１０１で、選択された献立に含まれている料理の食材をリスト化する。例えば選択された献立に料理１、料理２、料理３が含まれ、それぞれの料理の食材として、以下の食材が含まれていたとする。

料理１の食材：　トマト1/2個、ジャガイモ2個
料理２の食材：　トマト1個半、ジャガイモ3個
料理３の食材：　トマト1/2個、ジャガイモ1/2個
　以上の例であれば、上記食材をリスト化すると、以下のようになる。

　トマト：　2個半
　ジャガイモ：　5個半
　次に、ステップＳＣ１０２で、リスト化された各食材について、在庫量に基づいて「買う量」を設定する。例えば、それぞれの在庫量が以下のようであったとする。

　トマト：　1/2個
　ジャガイモ　6個
　そうすると、買う量としては
　トマト2個　　　（2個半－1/2個＝2個であるため。）
　ジャガイモ0個　（使う量(５個半)より、在庫量(6個)の方が多いため。）
となる。

　次に、ステップＳＣ１０３において、買うものと、そのものの量をリスト表示する。

　上記の例では以下のようになる。

　トマト　2個
　ここで、利用者は、他にも買いたいものを追加入力することもできる。例えば、「ジャガイモを今回買う必要はないが、在庫量を増やしておきたいので、３個買っておこう」と思った場合には、「ジャガイモ　3個」を手入力することで、リスト表示内容を、
　トマト　　　2個
　ジャガイモ　3個
とすることもできる。

　また、例えば、「トマトは２個買えば良いと表示されているが、さらに余分に１個買っておきたい」と思ったら、「２個」と表示されている部分をタッチして数量の増減をすることができる。

　そして、この買い物リストで、左にある□はチェック用のマーク欄（チェックボックス）であり、そのものを購入した場合にはチェックマークをつけることができる。一般的には、買い物をするときに手入力（ペンタッチなど）でチェックすることになるが、お財布ケータイ等の電子ウォレットで購入する場合や、ネットスーパーで購入する場合など、購入したものの種類と個数を自動的に判別できる手法を利用すれば、自動的にチェックボックスにチェックが付くようにすることもできる。この処理はステップＳＣ１０４で行われ、チェックの入った食材は実際に購入されたものと認識される。この買い物リストの例を図３０に示す。

　次に、ステップＳＣ１０５において、在庫量に今回買い物で買った量を加算する。例えば上記例において、在庫量は
　トマト 1/2個
　ジャガイモ　6個
であり、買った量は
　トマト　　　2個
　ジャガイモ　3個
であった場合には、
在庫量は、
　トマト 2個半
　ジャガイモ　9個
となる。

　このような在庫リストの例を図３１に示す。この図３１で示されているように、在庫リストにおいては、「購入日」ごとに同じ食材を別の行に表示することもできる。例えば、上記例において、もともとの在庫量は、
　食材　　　　個数　　　購入日
　トマト　　　1/2個　　2010/1/8
　ジャガイモ　6個　　　2009/12/28
であったとし、2010/1/10に以下のものを購入したとする。

　トマト　　　2個
　ジャガイモ　3個
すると、
在庫リストは
　食材　　　　個数　　　購入日
　トマト　　　1/2個　　2010/1/8
　トマト　　　2個　　　2010/1/10
　ジャガイモ　6個　　　2009/12/28
　ジャガイモ　3個　　　2010/1/10
となる。

　その後、実際にこの装置でレシピを見ながら調理を行なうと、ステップＳＣ１０６において、調理した献立で使用した食材の量が、在庫の量から減算される。上記例においては、調理した献立で使用した食材の量は、
　トマト 2個半
　ジャガイモ 5個半
であるので、調理後の在庫量は
　トマト　　　0個
　ジャガイモ　3個半
となる。

　購入日も表示する在庫リストにおいては、調理者が古い食材から使うものと仮定し、以下のような在庫リストになる。

　食材　　　　個数　　　購入日
　ジャガイモ　1/2個　　2009/12/28
　ジャガイモ　3個　　　2010/1/10
　尚、本実施の形態による装置で把握していない料理を作成した場合や、買い物をした場合など、本実施の形態による装置で保存している在庫リストと実際の在庫との間に差異が生じる場合がある。そこで、在庫リスト画面から、在庫リストの編集（食材の追加削除、個数の変更、購入日の修正など）ができるようになっている。個数管理については１／２個単位を基本とするが、ユーザの設定により、１個単位や、１／８個単位等、自由に設定することができる。

＜第６の実施の形態＞
　次に、調理する際に、複数の料理を並行して調理する作業を支援する仕組みについて説明する。本発明の実施の形態によるレシピデータ中の「調理手順」の各ステップには、メタデータとして以下の情報を付加することができる。

　１）調理者の関与度（食材を洗う、切る、炒める等、調理者が主体的に行う作業の場合は「大」、煮込んだり、茹でたり、蒸したり、電子レンジで温めたり、オーブンで焼いたり等、調理機器が主体となって調理され、調理者が他の作業に取り掛かれる場合は「小」、魚を焼く等、調理者がある程度関与し続ける必要がある場合は「中」となる。）
　２）調理リソース（コンロ、オーブンレンジ、流し（まな板や調理台を含んでも良い）、鍋、フライパン等）
　３）調理時間（標準的には何分くらい時間がかかるステップであるか）
　上記のそれぞれのメタデータのフォーマット例を例えば以下のように記載する。

　４）調理者関与度：大＝<S 100>、中＝<S 50>、小＝<S 0>
　５）調理リソース：コンロ＝<R CONRO>、オーブンレンジ＝<R OVEN>、トースター＝<R TOASTER>、流し＝<R SINK>、調理台＝<R WORKTOP>、まな板＝<R BOARD>、ボウル＝<R BOWL>、深鍋＝<R POT>、浅鍋＝<R PAN>、フライパン＝<R FRYPAN>、焼き網＝<R GRIDIRON>、蒸し器＝<R STEAMER>
　６）調理時間：5分＝<T 5> or <T 5m>、30秒＝<T 0.5> or <T 0.5m> or <T 30s>、1時間＝<T 60> or <T 60m> or <T 1h>
　例えば、図の例（ナポリタン）では以下のようにメタデータが付加される。

　(1)玉ネギは縦薄切りに、マッシュルーム（缶詰でもよい）は縦に4～5つに切る。<S 100> <R SINK> <T 3>
　(2)ベーコンは細切りに、ピーマンは縦半分に切って細切りにする。<S 100> <R SINK> <T 3>
　(3)沸騰したお湯に塩を加え、スパゲティを入れゆでる。<S 0> <R CONRO> <R POT> <T 15>
　(4)フライパンにサラダ油大さじ2を熱して玉ネギ、ベーコンを炒め、次にマッシュルーム、ピーマンも加えて炒め合わせる。その中にゆでたスパゲティ－を入れ塩コショウをし、ケチャップ、ウスターソースで味を調える。<S 100> <R CONRO> <R FRYPAN> <T 8>
　このようなメタデータに基づき、各料理ごとのタイムチャートを表示する。タイムチャートとは、例えば、長さが調理時間に対応し、色が調理者関与度（関与度が高いと色が濃い）に対応するようなチャートであり、見た目により調理の様子がわかりやすくなっているものである。そして、ある料理の調理者関与度の低いステップの調理時間が、他の料理のあるステップの調理時間よりも長い場合は、それらの料理はそのステップにおいて並行調理が可能であるが、このタイムチャートを各料理ごとに表示することで、並行調理可能であることを調理者にわかりやすく示すことができる。

　例えば、トマトサラダの調理手順が以下のとおりであるとする。

(1)トマトは洗って薄切りにする。<S 100> <R SINK> <T 3>
(2)酢とサラダ油を合わせてドレッシングを作る。<S 100> <R SINK> <T 3>
(3)器にトマトを盛り、(2)のドレッシングをかける。<S 100> <R SINK> <T 3>
そうすると、上記「ナポリタン」と「トマトサラダ」のタイムチャートは図３２のようになり、「ナポリタン」の茹で時間の間に、「トマトサラダ」を作れることがユーザにもわかりやすく表示されることになる。

　この例で調理する際には、このタイムチャートの重ねあわせに従って、ナポリタンの手順(3)の次にトマトサラダの手順(1)(2)(3)が順次表示され、その後ナポリタンの手順(4)が表示されていることがわかる。

　各料理のタイムチャートは、調理者が左右に動かすことができるようになっているが、例えば図３３のように動かすと、色が濃い（調理者関与度が高い）手順が重なるので、並行調理が困難であることがわかる。加えて、調理リソースの重なりについても、例えば「流し×２」のように表示される。

　また、例えば、キャベツ炒めの調理手順が以下のとおりであるとする。

(1)キャベツは芯を除き、4cmくらいの角切りにする。<S 100> <R SINK> <T 5>
(2)ネギを薄切りにし、ショウガは皮をむいて薄切りにする。<S 100> <R SINK> <T 5>
(3)フライパンにサラダ油を熱して、ショウガを炒める。<S 100> <R CONRO> <R FRYPAN> <T 3>
(4)キャベツ、ネギを入れ、2分ほど炒め、塩、こしょう、醤油で味を調える。<S 100> <R CONRO> <R FRYPAN> <T 3>
　そうすると、上記「ナポリタン」と「トマトサラダ」と「キャベツ炒め」のタイムチャート例は、図３３や図３４のようになる。このように、各料理のタイムチャートはユーザが自由に左右（時間的には前後）に移動可能であり、その際の重なり具合に応じて、例えば図３３のように、点線がある時間帯では「コンロとフライパンが二つ必要である」ということも明示される。

　ユーザは、各料理をどの順番で、またどこの隙間時間で料理するかをこのタイムチャートを見たり動かしたりしながら決めると、実際の献立手順は、タイムチャートに従って指示を出してくれるようになる。例えば、図３５のタイムチャートで料理をしようとユーザが決めたとすると、本発明の装置は、次の順番で献立手順を示してくれる。

　　・　ナポリタンの(1)
　　・　ナポリタンの(2)
　　・　ナポリタンの(3)
　トマトサラダの(1)　（この際に「ナポリタンをゆでている間にトマトサラダを作ってしまいましょう」というメッセージを出してからトマトサラダの(1)の手順を示すことも可能。このようなメッセージは、先の料理（この例ではナポリタン）の(3)（後の料理（この例ではトマトサラダ）が重なっている部分の手順）の料理手順から「ゆでる」「蒸す」など、時間のかかる調理方法を抽出し、「（先の料理名）を（抽出した調理方法の動詞を連用形表示）ている間に（後の料理名）を作ってしまいましょう」という形で機械的に表示が可能である。）
　　・　トマトサラダの(2)
　　・　トマトサラダの(3)
　　・　ナポリタンの(4)
　　・　キャベツ炒めの(1)
　　・　キャベツ炒めの(2)
　　・　キャベツ炒めの(3)
　　・　キャベツ炒めの(4)
　以上に見てきたように、このタイムチャートを利用することで、ユーザは各料理の隙間時間を事前に把握することができ、隙間時間を有効活用して各料理を効率よく調理することができるようになる。

　調理手順の別の例を図３６に示す。図３６に示すように、調理手順のデータは、ユーザに読んでもらうための文章のデータと、本ツールで利用するためのメタデータとが含まれている。左側の作り方から関与度までが文章のデータであり、右側はメタデータである。

　以下、図３６の右側のメタデータを説明する。

　1行目は、手順１の「牛肉は一口大に切り」に対応する。<T 3> は、この手順に3分要することを意味する。<R BORAD> は、この作業にまな板を使うことを意味する。<R WORKTOP> は、この作業に調理台を使うことを意味する。<S 100> は、この作業には調理人がほぼ100％関与する（関与度大である）ことを意味する。この作業は調理人が調理台にまな板をおいて牛肉を切る作業をする必要があるので、調理人の関与度が大になる。

　2行目は、手順２の「しょうゆとみりんで下味をつける」に対応する。<T 1> は、この作業に1分要することを意味する。<R BOWL> は、この作業にボウルを使うことを意味する。<R WORKTOP> は、この作業に調理台を使うことを意味する。<S 0> は、この作業には調理人はほとんど関与しないでよい（関与度小である）ことを意味する。この作業はボウルの中にしょうゆとみりんを入れ、手順１で一口大に切った牛肉を漬け込んで1分待つ作業であるから、最初の数秒でしょうゆとみりんの中に牛肉を漬け込んだ後は調理人はただ1分待つだけで良い。したがって、関与度小となっている。

　3行目は、手順３の「レタスは洗ってちぎる。」に対応する。<T 2> は、この作業に2分要することを意味する。<R SINK> は、この作業にシンクを使うことを意味する。<S 100> は、この作業には調理人がほぼ100％関与する（関与度大である）ことを意味する。この作業は調理人がシンクでレタスを洗ってちぎる作業をする必要があるので、調理人の関与度が大になる。

　4行目は、手順４の「卵をほぐし」に対応する。<T 1> は、この作業に1分要することを意味する。<R BOWL> はこの作業にボウルを使うことを意味する。<R WORKTOP> は、この作業に調理台を使うことを意味する。<S 100> は、この作業には調理人がほぼ100％関与する（関与度大である）ことを意味する。この作業は調理人がボウルに卵を割って、ほぐす作業をする必要があるので、調理人の関与度が大になっている。

　5行目は、手順５の「ねぎを切る」に対応する。<T 3> は、この作業に3分要することを意味する。<R BORAD> は、この作業にまな板を使うことを意味する。<R WORKTOP> は、この作業に調理台を使うことを意味する。<S 100> は、この作業には調理人がほぼ100％関与する（関与度大である）ことを意味する。この作業は調理人が調理台にまな板をおいてねぎを切る作業をする必要があるので、調理人の関与度が大になっている。

　6行目は、手順６の「卵を炒めて取り出す」に対応する。<T 1> は、この作業に1分要することを意味する。<R FRYPAN> は、この作業にフライパンを使うことを意味する。<R CONRO> は、この作業にコンロ（ガスコンロ、IHコンロなど）を使うことを意味する。<S 100> は、この作業には調理人がほぼ100%関与する（関与度大である）ことを意味する。この作業は調理人がフライパンで卵を炒める必要があるので、調理人の関与度が大になる。

　7行目は、手順７の「肉を強火で炒め、色が変わったらねぎとご飯を入れ、味を調える。卵を混ぜ、レタスを加えて、さっと混ぜます。」に対応する。<T 4> は、この作業に4分要することを意味する。<R FRYPAN> は、この作業にフライパンを使うことを意味する。<R CONRO> は、この作業にコンロ（ガスコンロ、IHコンロなど）を使うことを意味する。<S 100> は、この作業には調理人がほぼ100%関与する（関与度大である）ことを意味する。この作業は調理人がフライパンで肉を炒めたり、ねぎとご飯と混ぜたり、卵やレタスを混ぜたりする必要があるので、調理人の関与度が大になる。

＜第７の実施の形態＞
　図３７は、本発明の第７の実施の形態に係る献立決定支援装置１００の機能ブロック図である。図３７に示すように、献立決定支援装置１００は、地域特定部１２０、日付特定部１１０、記憶部１４０、制御部１５０、入力部１６０、出力部１７０を備える。

　地域特定部１２０は、献立決定支援装置１００の現在位置を、地域単位で特定する。ここでいう地域とは、旬の食材や特産品がそれぞれに異なる程度の大きさの範囲を指し、後述の地域食材データベース１４２における地域と同程度の範囲であることが好ましい。地域を特定する手法には、任意の公知技術を用いることができる。例えばＧＰＳを用いて現在位置を特定する、などの手法が考えられる。

　日付特定部１１０は、現在日時を特定する。例えばタイマなどを用いて日付特定部１１０を構成することができる。

　記憶部１４０は、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）などの記憶装置で構成され、レシピデータベース１４１、地域食材データベース１４２、ユーザデータベース１４３を格納している。

　制御部１５０は、献立決定支援装置１００の現在位置（地域）と日付、および記憶部１４０が格納している各データベースを用いて、提案する献立を決定し、出力部１７０より出力する。献立を決定する過程については後述する。

　入力部１６０は、献立を提案するよう献立決定支援装置１００に指示するためにユーザが使用する操作指示部である。提案に際しての条件設定を入力することもできる。入力部１６０は、例えばキーボード、キーパッド、タッチパッド、マウス、トラックボールなどの形態で実現することができる。また、操作メニューを表示するための画面表示部などを適宜備える。

　出力部１７０は、制御部１５０が決定した提案する献立を出力する。出力形式は、例えば液晶ディスプレイなどを用いた画面表示によるものでもよいし、提案する献立の内容を記述したデータとして出力するものでもよい。画面表示デバイスについては、入力部１６０と共通化してもよい。

　レシピデータベース１４１は、料理毎に料理名、材料、味、食感、色などの基本データを保持するデータベースである。詳細は後述の図３８で説明する。

　地域食材データベース１４２は、地域および月毎の旬の食材、特産品のリストを保持する。詳細は後述の図３９で説明する。なお、地域固有の食材のリスト以外に、一般的な食材のリストを保持してもよい。以下では一般食材のリストについての説明は省略する。

　ユーザデータベース１４３は、レシピデータベース１４１または地域食材データベース１４２をユーザ毎にカスタマイズするためのデータを格納するデータベースである。

　本発明における「献立提案部」は、制御部１５０と出力部１７０とが対応する。

　地域特定部１２０、日付特定部１１０、制御部１５０は、これらの機能を実現する回路デバイスなどのハードウェアを用いて構成することもできるし、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）やマイコンなどの演算装置とその動作を規定するソフトウェアプログラムを用いて構成することもできる。後者のソフトウェアプログラムは、本発明における「献立決定支援プログラム」に相当する。

　図３８は、レシピデータベース１４１が保持するレシピデータの構成とデータ例を示す図である。レシピデータは、個々の料理の詳細情報を保持するデータである。以下、レシピデータが有する各情報欄について説明する。

（図３８：「料理名」欄）
　「料理名」欄は、当該レシピデータが記述している料理の料理名を保持する。料理名そのものに、献立を提案する際に用いることのできる情報が含まれている場合もある。制御部１５０は、例えば現在の季節が冬であれば、料理名に「冷」などの寒さを連想させる文字を含むものを、提案する献立の対象から除外することができる。どのようなキーワードを含む料理を除外するかをユーザデータベース１４３に格納し、ユーザ毎にカスタマイズすることもできる。

（図３８：「料理材料」欄）
　「料理材料」欄は、当該レシピデータが記述している料理を作るために用いられる食材リストを保持する。特に、地域の旬の食材や特産品を使用する献立を提案するときに、本欄が保持するデータを有効に活用することができる。

（図３８：「種類」「ジャンル」欄）
　「種類」欄、「ジャンル」欄は、当該レシピデータが記述している料理の大まかな分類を表すデータを保持する。制御部１５０は、１品目として例えば「ご飯もの」が決定された場合、２品目以降は「ご飯もの」以外の料理を提案するようにする。同様に、１品目として例えば「和食」が決定された場合、２品目以降もなるべく「和食」料理を提案するようにすることができる。

（図３８：「味」欄）
　「味」欄は、当該レシピデータが記述している料理の大まかな味の種類を表すデータを保持する。制御部１５０は、例えば子供向けの献立を提案するよう指示されたときは、本欄が「甘」になっている料理を優先的に提案することができる。

（図３８：「食感」欄）
　「食感」欄は、当該レシピデータが記述している料理の食感を表すデータを保持する。制御部１５０は、例えば１品目として提案した料理の食感と異なる食感を有する料理を２品目以降に提案することにより、献立に多様性を持たせることができる。また、例えばお年寄り向けの献立を提案するよう指示されたときは、本欄が「硬い」になっている料理をなるべく除外するようにすることができる。

（図３８：「色」欄）
　「色」欄は、当該レシピデータが記述している料理の色を表すデータを保持する。制御部１５０は、複数の料理を提案する場合、本欄の値を用いて、彩りのよい組み合わせを提案することができる。本欄の値は、料理全体の色を表すものとしてもよいし、食材毎に色を保持してもよい。

（図３８：「定番」欄）
　「定番」欄は、当該レシピデータが記述している料理が定番料理であるか否かを表すデータを保持する。

（図３８：「手間／所要時間」欄）
　「手間／所要時間」欄は、当該レシピデータが記述している料理を作るために要する時間を表すデータを保持する。本欄の値は、提案された料理のなかからユーザが料理を選択する際の目安になる。例えばユーザが急いでいるときは、本欄の値が小さい料理が選択される場合が多いと考えられる。

（図３８：「調理器具」欄）
　「調理器具」欄は、当該レシピデータが記述している料理を作るときにユーザが使用する調理器具のリストを保持する。制御部１５０は、例えば暑い日には、コンロやフライパンなど暑さを感じやすい調理器具を使用する料理を提案しないようにするなど、料理を提案する際に本欄の値を参考情報として用いることができる。また、オーブンや炊飯器など調理を開始してしまえばその後は出来上がりまで何もしなくてよい調理器具を使用する料理を、フライパンなどのように常に付き添っていなければならない調理器具を使用する料理とセットにして提案する、といったこともできる。

（図３８：「調理方法」欄）
　「調理方法」欄は、当該レシピデータが記述している料理の調理方法を表すデータを保持する。制御部１５０は、献立の多様性の観点から、１品目に提案した料理の調理方法と２品目以降に提案する料理の調理方法を変えることが望ましい。

（図３８：「出来上がり料理温度」欄）
　「出来上がり料理温度」欄は、当該レシピデータが記述している料理を美味しく飲食できる温度を表すデータを保持する。人が、温かく、または、冷たく、美味しいと感じる温度は、一般的に体温との差が２５度以上であることや、保温機能のある弁当箱の保温温度が５０度前後～６０度前後であるものが多いことから、例えば「温かい料理＝５５度以上」、「冷たい料理＝１２度以下」とする。常温については日本工業規格で定められている５度～３５度を参考に、「常温料理＝１５～３５度」とする。制御部１５０は、現在の季節が冬であれば、本欄の値が小さい料理を、提案する献立の対象から除外することができる。保持するデータは、例えば同じ汁物でも、味噌汁は６５度前後、甘みの強い汁粉などは多少低めの５０度程度のほうが美味しく感じられるという、温度の違いを考慮することが望ましい。

（図３８：「出来上がりイメージ」欄）
　「出来上がりイメージ」欄は、当該レシピデータが記述している料理が完成した時のイメージを示す画像データを保持する。制御部１５０は、「色」欄に代えて、または「色」欄と併せて本欄から料理の色合いを抽出し、彩りのよい料理の組み合わせを提案することができる。

（図３８：「調理手順」欄）
　「調理手順」欄は、当該レシピデータが記述している料理の詳細な調理手順を記述したデータを保持する。本欄は、ユーザが当該料理を実際に作ることができるか否かを判断するためなどの参考情報として用いることができる。また、料理を作る際に本欄を出力部１７０で画面表示させて参考にすることもできる。

　図３９は、地域食材データベース１４２が保持している地域食材テーブル１４２１の構成とデータ例を示す図である。地域食材テーブル１４２１は、各月の旬の食材および地域特産品の情報を、地域毎に保持している。制御部１５０は、地域食材テーブル１４２１を参照することにより、地域および月毎の旬の食材および地域特産品を把握できる。

　制御部１５０は、必ずしも当月の旬の食材または特産品を選択する必要はなく、例えば当月の前後２ヶ月以内であれば旬の食材または特産品の範囲に含むものとして取り扱ってもよい。旬の食材または特産品をどの期間範囲内で選択するかについてのデータを例えばユーザデータベース１４３に格納しておき、カスタマイズできるようにしてもよい。

　図４０は、献立決定支援装置１００が献立を提案する過程を示す処理フローである。以下図４０の各ステップについて説明する。

（図４０：ステップＳ４０１）
　地域特定部１２０と日付特定部１１０は、それぞれ献立決定支援装置１００が設置されている地域と現在日付を取得し、制御部１５０に出力する。

（図４０：ステップＳ４０２）
　制御部１５０は、地域特定部１２０と日付特定部１１０より取得した地域と日付を用いて地域食材データベース１４２を検索し、該当する地域の旬の食材と特産品のリスト（地域食材リスト）を取得する。

（図４０：ステップＳ４０３）
　制御部１５０は、ステップＳ４０２で取得した地域食材を使用する料理をレシピデータベース１４１から検索し、得られた料理を献立として提案する。このとき、ユーザデータベース１４３が保持しているユーザ毎のカスタマイズ情報を加味してもよい。以下のステップＳ４０７、Ｓ４１０でも同様である。提案する献立の内容は、出力部１７０を介してユーザに提示される。

（図４０：ステップＳ４０４）
　制御部１５０は、提案する献立のいずれかを選択するよう促すメッセージを入力部１６０に画面表示させる。ユーザはいずれかの献立を選択するか、もしくは他の献立を提案するよう指示する。ユーザがいずれかの献立を選択した場合はステップＳ４１２へ進み、いずれも選択しなかった場合はステップＳ４０５へ進む。

（図４０：ステップＳ４０５）
　制御部１５０は、ステップＳ４０２で取得した地域食材に代えて、またはこれに追加して、地域食材データベース１４２または規定の食材リストより他の食材のリストを取得して入力部１６０に画面表示させ、ユーザに提案する。

（図４０：ステップＳ４０６）
　制御部１５０は、提案する食材のいずれかを選択するよう促すメッセージを入力部１６０に画面表示させる。ユーザはいずれかの食材を選択するか、もしくはいずれの食材も希望に合致しない旨を指示する。ユーザがいずれかの食材を選択した場合はステップＳ４０７へ進み、いずれも選択しなかった場合はステップＳ４０９へ進む。

（図４０：ステップＳ４０７）
　制御部１５０は、ステップＳ４０６でユーザが選択した食材を使用する料理をレシピデータベース１４１から検索し、得られた料理を献立として提案する。提案する献立の内容は、出力部１７０を介してユーザに提示される。

（図４０：ステップＳ４０８）
　制御部１５０は、提案する献立のいずれかを選択するよう促すメッセージを入力部１６０に画面表示させる。ユーザはいずれかの献立を選択するか、もしくは他の献立を提案するよう指示する。ユーザがいずれかの献立を選択した場合はステップＳ４１２へ進み、いずれも選択しなかった場合はステップＳ４０９へ進む。

（図４０：ステップＳ４０９）
　制御部１５０は、献立を提案するための条件を入力するようユーザに促すメッセージを入力部１６０に画面表示させる。ユーザは、後述の図４１で説明する手順にしたがって条件を入力し、制御部１５０はその条件指定を受け付ける。

（図４０：ステップＳ４１０）
　制御部１５０は、ステップＳ４１０で指定された条件を用いてレシピデータベース１４１と地域食材データベース１４２を検索し、得られた料理を献立として提案する。条件を満たす料理が見つからなかった場合は、「お勧めできる料理がありませんので条件を見直してください。」のようなメッセージを表示し、ステップＳ４０９に戻るようにしてもよい。また、条件を満たす料理がなくても、「条件にあう提案メニューがありませんでしたので、○○からのお勧めを探しました」等のメッセージを表示した後、代替案の料理候補を提案するようにしてもよい。

（図４０：ステップＳ４１１）
　制御部１５０は、提案する献立のいずれかを選択するよう促すメッセージを入力部１６０に画面表示させる。ユーザはいずれかの献立を選択するか、もしくは他の献立を提案するよう指示する。ユーザがいずれかの献立を選択した場合はステップＳ４１２へ進み、いずれも選択しなかった場合はステップＳ４０９へ戻る。

（図４０：ステップＳ４１２）
　制御部１５０は、選択された料理の詳細レシピを出力部１７０に画面表示させる。制御部１５０は、その料理を確定してよいか否かを問い合わせるメッセージを入力部１６０に画面表示させる。ユーザはその料理を確定するか否かを指示する。確定しない場合は、ステップＳ４０９やＳ４１０などに戻るようにしてもよい。

　図４１は、図４０のステップＳ４０９の詳細手順を示す処理フローである。以下、図４１の各ステップについて説明する。

（図４１：ステップＳ５０１）
　制御部１５０は、入力部１６０に例えば「なにを使いたいですか？」などのメッセージを表示させる。ユーザは例えば、冷蔵庫にある食材や、帰宅途中に買う予定の食材など、使いたい食材を指定する。本ステップでは、複数の食材を選択できるようにしておくことが望ましい。

（図４１：ステップＳ５０２）
　制御部１５０は、入力部１６０に例えば「誰が食べますか？」などのメッセージを表示させる。ユーザは、料理を食べる人物の種別、例えば、小さい子供、中高生～大人、お年寄り、などの人物種別を指定する。本ステップでは、複数の人物種別を指定できるようにしてもよい。

（図４１：ステップＳ５０３）
　制御部１５０は、入力部１６０に例えば「料理の種類は？」などのメッセージを表示させる。ユーザは例えば、献立の提案を受けたいご飯もの、めん類、おかず、汁物等や、主食、主菜、副菜、汁物等の料理種別を指定する。本ステップでは、複数の料理種別を指定できるようにしてもよい。

（図４１：ステップＳ５０４）
　制御部１５０は、入力部１６０に例えば「食べたいジャンルは？」などのメッセージを表示させる。ユーザは例えば、和食、洋食、中華、その他、おまかせ、などの料理ジャンルを指定する。本ステップでは、複数の料理ジャンルを指定できるようにしてもよい。

　以上、献立決定支援装置１００が献立を提案する過程を説明した。なお、ユーザは図４１の各条件を入力せずそれぞれ個別にスキップすることもできる。スキップされた条件については、制御部１５０は特に希望条件はないものとして取り扱う。例えば、食べたいジャンルがスキップされた場合は、和食でも洋食でも中華でも何でも提案可能と判断する。

　以上のように、本実施の形態７に係る献立決定支援装置１００は、月毎の旬の食材および特産品を地域毎に保持する地域食材データベース１４２を備える。制御部１５０はこれを用いて、地域と日付に合わせた献立をレシピデータベース１４１から検索してユーザに提案することができる。

＜第８の実施の形態＞
　第７の実施の形態では、レシピデータベース１４１と地域食材データベース１４２とを用いて、地域と日付に合わせた献立を提案する手法を説明した。本発明の第８の実施の形態では、料理の出来上がりイメージを用いて提案献立をより絞り込む手法を説明する。第８の実施の形態に係る献立提案装置１００の構成は、第７の実施の形態と概ね同様であるため、以下では差異点を中心に説明する。

　図４２は、第８の実施の形態において、制御部１５０がレシピデータベース１４１の「出来上がりイメージ」欄の画像データを用いて献立を提案する基準を説明する図である。以下、制御部１５０が実行する処理について説明する。なお、ここでは、ユーザが１品目の料理として「カレーライス」を選択済みであり、２品目として「サラダ」を提案するよう要求した場合を想定する。レシピデータベース１４１には、２種類のサラダ「サラダ１」、「サラダ２」のレシピデータが格納されているものとする。

（ステップ１：ＲＧＢ値を抽出する）
　制御部１５０は、図４０のステップＳ４０３、Ｓ４０７、Ｓ４１０において、レシピデータベース１４１より料理の一覧を取得した後、「カレーライス」、「サラダ１」、「サラダ２」の「出来上がりイメージ」欄の画像データを取得する。制御部データ１４０は、取得した画像データのうち代表的な色のＲＧＢ値を取得する。代表的な色として、例えば画像データのうち最も多く使用されている色を用いることができる。例えば、図４２のカレーライスの料理イメージ中で最も多く使用する色を（ｒ０，ｇ０，ｂ０）、サラダ１の料理イメージ中で最も多く使用する色を（ｒ１，ｇ１，ｂ１）、サラダ２の料理イメージ中で最も多く使用する色を（ｒ２，ｇ２，ｂ２）、とすることができる。

（ステップ２：料理間のＲＧＢベクトル距離を算出する）
　制御部１５０は、「カレーライス」のＲＧＢ値を基準として、「カレーライス」と「サラダ１」、「サラダ２」のＲＧＢ値のベクトル距離を算出する。ここでいうＲＧＢ値のベクトル距離とは、ＲＧＢ値を座標値とする点を３次元座標上に配置したときに得られる各点間の距離のことである。

　カレーライスの画像のＲＧＢ値が（ｒ０，ｇ０，ｂ０）、サラダ１の画像のＲＧＢ値が（ｒ１，ｇ１，ｂ１）、サラダ２の画像のＲＧＢ値が（ｒ２，ｇ２，ｂ２）である場合、それぞれのベクトル距離は下記（式１）（、式２）で算出することができる。

（ステップ３：ベクトル距離が最も離れている料理を提案する）
　制御部１５０は、カレーライスのＲＧＢ値からのベクトル距離が長いほうのサラダを優先して提案する。優先して提案するとは、例えば優先する料理を先に提案する、優先する料理のみを提案する、などのように、ユーザに対する訴求度がより高い方法で提示することをいう。以下でも同様である。

　制御部１５０は、上記手法により、カレーライスの色彩と組み合わせると献立全体としての彩りがよくなるサラダを提案することができる。

　図４３は、制御部１５０がレシピデータベース１４１の「出来上がりイメージ」欄の画像データを用いて献立を１品のみ提案する基準を説明する図である。献立を１品のみ提案する場合には、図４２で説明した場合とは異なり基準となる料理が存在しないため、１つの料理の画像データ内で色のＲＧＢベクトル値を算出することになる。具体的には、１つの料理の画像データ内で複数の点を設定し、各点間のＲＧＢベクトル距離を算出する。

　図４３に示す例では、制御部１５０は画像データ内の４つの点を任意に選択し、各点のＲＧＢ値を取得する。点１のＲＧＢ値が（ｒ１，ｇ１，ｂ１）、点２のＲＧＢ値が（ｒ２，ｇ２，ｂ２）、点３のＲＧＢ値が（ｒ３，ｇ３，ｂ３）、点４のＲＧＢ値が（ｒ４，ｇ４，ｂ４）であるとする。これらの点１～４間のベクトル距離の合計は、（点１－点２間）＋（点１－点３間）＋（点１－点４間）＋（点２－点３間）＋（点２－点４間）＋（点３－点４間）であり、下記（式３）で表すことができる。

　上記（式３）で１／６を乗算しているのは、値を正規化するためである。上記（式３）で算出できる値が大きいほど、色のバリエーションに富む料理であるといえる。制御部１５０は、提案する献立の候補が複数存在するとき、この値が大きいものを優先することにより、彩りのよい献立を提案することができる。

　また、図４２で示した例において、各料理のＲＧＢベクトル距離を複数点について比較したい場合には、制御部１５０は、各点の全ての組み合わせについてＲＧＢベクトル距離を求め、その平均を求める。これにより、図４２～図４３と同様の処理を行うことができる。例えば、カレーライスの画像のＲＧＢ値が（ｒ０１，ｇ０１，ｂ０１）と（ｒ０２，ｇ０２，ｂ０２）で、サラダ１の画像のＲＧＢ値が（ｒ１１，ｇ１１，ｂ１１）と（ｒ１２，ｇ１２，ｂ１２）で、サラダ２の画像のＲＧＢ値が（ｒ２１，ｇ２１，ｂ２１）と（ｒ２２，ｇ２２，ｂ２２）であるとすると、カレーライスとこれらのサラダとの距離は以下の式で求められる。

　制御部１５０は、カレーライスのＲＧＢ値からのベクトル距離が長いほうのサラダを提案する。上記（式４）、（式５）で１／４を乗算しているのは、値を正規化するためである。一般的には、料理ＡのＲＧＢ値がｍ個で表わされ、料理ＢのＲＧＢ値がｎ個で表わされる場合は、各ＲＧＢ値の距離の和をｍ×ｎで割ればよいということになる。

　図４４は、料理の出来上がりイメージのうちＲＧＢ値を算出する際に用いる色または座標を指定したレシピデータの例を示す図である。料理の画像データのＲＧＢ値を抽出する際には、皿などの食器や背景などの部分を除外して料理の部分のみから抽出することが望ましい。そこで図４４では、レシピデータ内に「サンプル色」欄を設けた。同欄には、料理の代表的な色のサンプル値、または出来上がりイメージの画像内で代表的な色を有する部分の座標値を保持する。制御部１５０は、本欄が保持する色または座標を用いて、料理の代表色を定めることができる。

　制御部１５０は、例えば食器形状の周縁部分を検出して除外すべき部分を自動判別するようにしてもよいが、「サンプル色」欄を設ける手法の方が簡便で処理負荷も少ない点で便宜である。

　また、以上では、色の距離を用いて彩りの良い献立を提案する方法を説明したが、これ以外の方法として、献立中の各料理の使われている色の総数に基づいて彩りの良い献立を提案する方法もある。例えばカレーライスの「サンプル色」が「黄土色、白、赤」、サラダ１の「サンプル色」が「緑、白、赤」、サラダ２の「サンプル色」が「緑、黄、赤」だった場合、「カレーライスとサラダ１」のサンプル色の合計は「黄土色、白、赤、緑」の4色なのに対し、「カレーライスとサラダ２」のサンプル色の合計は「黄土色、白、赤、緑、黄」の5色なので、「カレーライスとサラダ２」という献立の方が彩り豊かという判定ができる。したがって、この二つの献立の中では「カレーライスとサラダ２」の方を優先的に提案することになる。　以上のように、本発明の第８の実施の形態によれば、レシピデータベース１４１は料理の色彩についての情報を「出来上がりイメージ」欄の画像データまたは「サンプル色」欄に保持しており、制御部１５０は、その色彩情報を用いて色のバリエーションが多くなる献立を提案する。これにより、視覚的イメージのよい献立提案を行うことができる。また色彩バリエーションが豊かな献立は、食材の種類が豊富で栄養面なども優れているものと想定され、視覚的観点のみならず健康的観点からも好ましい。

　また、第８の実施の形態によれば、制御部１５０は料理のＲＧＢ値のベクトル距離が離れているほど色彩バリエーションが豊富であるものと取り扱う。これにより、料理の色彩の豊富さを、演算処理の上で取り扱い易い定量的な手法で算出することができ、処理負荷などの観点から好都合である。

＜第９の実施の形態＞
　本発明の第９の実施の形態では、ユーザの好みを献立提案に反映する構成と動作例を説明する。本第９の実施の形態に係る献立決定支援装置１００の構成は第７～８の実施の形態と概ね同様であるため、以下では差異点を中心に説明する。

　図４５は、ユーザデータベース１４３が格納する選択履歴情報１４３１の構成とデータ例を示す図である。制御部１５０は、図４０で説明した処理フローにおいてユーザより献立または食材の選択を受け付けると、その選択内容を選択履歴情報１４３１に格納する。これにより、ユーザが過去に選択した料理名、材料名、料理の種類やジャンルなどの履歴がユーザデータベース１４３に蓄積されることになる。

　制御部１５０は、食材や献立を提案するとき、ユーザが過去に選択した回数が多いものを優先して提案する。具体的には、例えば図４０のステップＳ４０３、Ｓ４０５、Ｓ４０７、Ｓ４１０などにおいて食材や献立を提案する際に、過去に選択された回数の多いものを先に提案するようにする。これにより、提案する食材や献立にユーザの嗜好を反映させることができる。

＜第１０の実施の形態＞
　本発明の第１０の実施の形態では、食材が偏らないように工夫して献立を提案する構成と動作例を説明する。本第１０の実施の形態に係る献立決定支援装置１００の構成は、第７～第９までの実施の形態と概ね同様であるため、以下では差異点を中心に説明する。

　図４６は、出力部１７０の画面表示イメージを示す図である。ここでは出力部１７０が画面表示デバイスを備え、画面表示によってユーザに献立を提案することを想定する。制御部１５０は、複数の料理を組み合わせた献立を提案するとき、献立内の各料理が使用する食材の偏りについて配慮する。以下に具体例を挙げる。

（例１：ユーザが指定した食材（以下、「指定食材」という）の場合）
　指定食材を使用した料理だけを提案する。指定食材が複数の場合は、指定食材を使用する料理を同程度ずつ提案してもよい（人参料理2品、大根料理2品など）。また、指定食材が非常に多い場合は、指定食材を全て使用する料理から優先し、少なくとも１つ以上の指定食材を使用した料理を提案するようにする。

（例２：ユーザが指定していない食材（以下、「指定外食材」という）の場合）
　提案数が少ない場合は、指定外食材が重複しないように料理を提案するが、多い場合は、指定外食材を使用する料理を、各２０％程度までに抑えて提案するようにしてもよい。

　肉類や魚など、料理の味等の特性を決めるのに重要な鍵となる食材（以下、「主要食材」という）についても、基本的には上記例１、例２と同様に考えてよいが、１品目が決まり、2品目以降を提案するときは、できるだけ主要食材が重複しないように料理を選定することが好ましい。同じ主要食材を持つ料理を一度に食べるのを好まないユーザが多いと考えられるからである。

　主要食材を含む食材名を料理名と併せて画面表示すれば、ユーザが料理名と食材名を参考にしながら最終選択をすることができるので便宜である。図４６の例では、料理１と料理２は主要食材Ａ、料理２と料理５は主要食材Ｂ、料理４は主要食材Ｃを用いることが分かる。

　いずれの食材が主要食材であるかについては、例えばレシピデータの「料理材料」欄が保持する各食材のうち主要食材であるものに、その食材が主要食材である旨の属性を付与しておくことにより把握できる。図３８に示した例では、食材「むき栗」に「メイン」属性がついているので、制御部１５０は「むき栗」が主要食材であることが分かる。

　その他、レシピデータの「料理名」欄の値から主要食材を判断することもできる。例えば料理名に「鶏肉の○○」、「○○豆腐」などのように食材名が含まれていれば、その食材が主要食材であると判断することもできる。食材名が複数含まれていればそれぞれを主要食材とする。

　「肉の○○」「魚の○○」などのように大まかな食材名のみが料理名に含まれる場合には、具体的な食材を料理名のみから特定することができない。この場合は、全食材の中から肉や魚に属するものを適宜選び、当該料理における主要食材として取り扱うこともできる。

　図４７は、本第１０の実施の形態において地域食材データベース１４２が保持する食材種類情報１４２２の構成とデータ例を示す図である。食材種類情報１４２２は、食材がどの種類に属するかを記述した情報である。

　食材種類情報１４２２は、各食材の「材料」、「種類」、「旬」、「主要食材可否」についての情報を保持する。図４７に示す例では、食材「秋刀魚」は種類「魚」に属することが記載されている。

　項目「旬」は、当該食材がよくとれおいしい時期を示す。この項目は、制御部１５０が季節にあった料理を提案するときの判断材料とすることができる。

　項目「主要食材可否」は、その食材が主要食材になり得る（○）か、そうでない（×）かを示すものである。

　図４８は、ユーザが同じ食材を連続して希望した場合の献立提案例を示す図である。ここでは２日間連続した例を示した。短期間に同じ献立を提案するとユーザにとって新鮮味に欠けるため、このような場合は同じ食材を使用する異なる献立を提案することが望ましい。

　図４８では、１日目は主要食材Ａ～Ｃを使用する料理１～５を提案し、２日目は同じ主要食材Ａ～Ｃを使用する料理１１～１５を提案する例を示した。具体的には、1日目に料理１を選択したので、2日目は、料理１の優先度を下げて提案することを表している。

　これにより、ユーザが短期間の間に同じ食材を希望した場合でも、ユーザを飽きさせない献立提案を行うことができる。

　図４８のような献立提案を行うためには、例えばユーザデータベース１４３に直近１週間程度の献立履歴を格納しておき、次回提案時には献立履歴に含まれる料理を提案しないかまたは優先度を下げて提案する、といった手法が考えられる。

　以上のように、本第１０の実施の形態によれば、制御部１５０は、複数の料理を含む献立を提案する際に、同一の食材が献立内に含まれる割合について、指定食材の場合は、提案する全ての献立に含まれてよいので１００％とし、指定外食材の場合は２０％程度に抑える。ただし、指定外食材については、提案する献立の数が少なくなるほど、同一の食材が献立内に含まれる割合を少なくすることが望ましい。これにより、ユーザは常に新鮮な献立提案を受けることができる。食材のバリエーションが豊富になることにより、栄養面も良好になると考えられるので、健康の観点からも好ましい。

　また、本第１０の実施の形態において、制御部１５０は、同一の食材を使用する献立を短期間内に提案するときは、同じ料理をなるべく提案しないように、例えば直近（例：１週間程度）に提案した料理の優先度を下げるなどして献立を提案する。これにより、同一の食材を使用する場合でも新鮮味のある献立を提案することができる。

　さらに、図４６または図４８の献立提案画面において、急いでいるユーザの便宜のため、調理時間の短い料理の横に「時短」などのマークを画面表示し、ユーザが調理時間の短い献立を選び易くするようにしてもよい。

　なお、図４６および図４８の献立対案画面において、表示される「メニュー」は「献立料理」を示す。

＜第１１の実施の形態＞
　第１０の実施の形態では、食材がなるべく重ならないように献立を提案することを説明した。同様の観点から、制御部１５０は、調理方法がなるべく重複しないように献立料理を提案することもできる。同じ調理方法を用いる料理は味も似ているかもしくは同種の味になる可能性があり、献立のバリエーションの観点から好ましくないからである。

　ただし提案数が多い場合は、例えば、おかずは一般的に「煮る」調理方法を用いる料理が多いため、他の調理方法より多く提案するなど、料理の種類により重複の程度を変えるようにしてもよい。

　本第１１の実施の形態に係る献立決定支援装置１００の構成は、第１０の実施の形態と同様である。

＜第１２の実施の形態＞
　以上の実施の形態（第７から第１１）において、図４１の処理フローでユーザが入力するその他の条件として、例えば「ＮＧ食材」、「ＮＧ調理法」なども考えられる。

　「ＮＧ食材」とは、ユーザが好まない食材があれば登録しておいてもらうものである。ＮＧ食材がある場合、制御部１５０は、当該ユーザへ献立を提案するときは、ＮＧ食材が含まれるものを必ず除外するようにする。

　「ＮＧ調理法」とは、ユーザが好まない調理法があれば登録しておいてもらうものである。ＮＧ調理法がある場合、制御部１５０は、当該ユーザへ献立を提案するときは、ＮＧ調理法を用いる料理を必ず除外するようにする。

　これらの条件については、あらかじめユーザデータベース１４３に同様の情報を格納しておき、制御部１５０がこれを読み出して献立提案時に用いるようにしてもよい。同様に、ユーザが積極的に使いたい食材または献立料理をユーザデータベース１４３に格納しておき、制御部１５０がこれを読み出して献立提案時に用いるようにしてもよい。

　上記の他、ユーザが定番料理を好むか否かの情報をユーザデータベース１４３に格納しておいてもよい。ユーザの定番料理に対する嗜好として、自分が作り慣れている定番料理を好んで選択する場合と、定番以外の料理を選択して自分のレパートリーを増やそうとする場合とがある。ユーザデータベース１４３に各ユーザの定番料理に関する嗜好を格納しておけば、制御部１５０はこれを読み出してユーザの嗜好に応じて提案する献立の傾向を調整することができる。

＜第１２の実施の形態＞
　制御部１５０が献立を１品のみ提案する際に考慮する条件として、例えば、以下のようなものが考えられる。条件の優先順に列挙する。

（条件１）旬の食材（カレンダー、ＧＰＳ機能から検知または任意入力）
（条件２）季節に合わない料理名のものを除外する
（条件３）希望の食材（任意入力）
（条件４）対象人物（任意入力）
（条件５）料理の種類（任意入力）
（条件６）料理ジャンル（任意入力）
（条件７）写真の彩りのよい献立
（条件８）ＮＧ食材
（条件９）定番料理の利用
　制御部１５０が複数の料理を組み合わせた献立を提案する際、１品目の候補を提案する優先順の例を以下に示す。

（条件１）料理の種類（任意入力）
（条件２）旬の食材（カレンダー、ＧＰＳ機能から検知）
（条件３）季節に合わない献立名のものを除外する
（条件４）希望の食材（任意入力）
（条件５）ＮＧ食材
（条件６）ジャンル（任意入力）
（条件７）食べる対象（任意入力）
（条件８）写真の彩りのよい献立
（条件９）定番献立の利用
　制御部１５０は、２品目以降の料理は例えば以下の優先順で提案する。

（条件１０）料理の種類
（条件１１）旬の食材
（条件１２）季節に合わない献立名のものを除外する
（条件１３）希望の食材
（条件１４）ＮＧ食材
（条件１５）最初の料理で決まった食材を除外
（条件１６）最初の料理で決まった食感を除外
（条件１７）最初の料理で決まった調理方法を除外
（条件１８）最初の料理との色の距離が大きくなる献立を選択
　このように、優先順序を考慮した組み合わせで条件を設定すると、ユーザの嗜好にあった栄養価の高い献立を提案することが可能になる。なお、献立候補の提案画面に表示する候補数は、いくつであってもよく、条件を満たす順にあらかじめ決められた数を表示するようにしてもよい。献立候補の提案画面において、「お勧めは○○件です」のようなメッセージを表示し、献立候補の総数を示すようにしてもよい。出力部１７０上の表示方法（形態やサイズなど）により、ユーザが見やすい件数に違いが出てくることが考えられるからである。

＜第１３の実施の形態＞
　図４９は、レシピデータに含まれる各項目を表示するか否かを定義するデータ示す図である。レシピデータの各項目は、出力部１７０で提案結果を表示するか否かをユーザの好みによりカスタマイズできるようにしておくことが望ましい。例えば、人によって「辛いか」、「所要時間はどのくらいか」などを表示画面に表示していた方が便利と感じる人もいるからである。

　制御部１５０は、出力部１７０にレシピデータの内容を画面表示するよう指示する際、図４９に示すデータを読み込み、表示項目を調節する。図４９のデータは、例えばユーザ毎のカスタマイズ情報として、ユーザデータベース１４３などに格納しておくとよい。

＜第１４の実施の形態＞
　以上の第７～１３の実施の形態において、入力部１６０は、特定の機能を操作するための専用の操作キーを備えてもよい。操作キーは例えば以下のようなものを含む。

（操作キー例その１：「検索」キー）
　「検索」キーは、ユーザが献立の提案をするよう献立決定支援装置１００に指示するときに操作するキーである。ユーザが条件を入力した後に「検索」キーを操作すると、それらの条件が制御部１５０に出力される。

（操作キー例その２：「戻り」キー）
　「戻り」キーは、現在の表示画面から前回の表示画面に戻る操作を行うキーである。

（操作キー例その３：「最初へ」キー）
　「最初へ」キーは、現在の食材や献立の選択・提案をすべてキャンセルし、初期画面に戻る操作を行うキーである。初期画面に戻る前に「すべての条件入力がクリアされますがよろしいですか？」のような注意を促す表示を行うようにしてもよい。以下のような動作例が考えられる。

（操作キー例その３：「最初へ」キー：動作例その１）
　献立決定支援装置１００の電源を入れると、ステップＳ４０１～Ｓ４０３を実行する。以降いずれかの画面で「最初へ」キーを押すと、初期画面が表示される。初期画面には、メッセージ「何を提案しましょうか？それとも条件入力しますか？」と表示され、ユーザが“献立提案”を選択すると図４０のステップＳ４０１を開始し、“食材提案”を選択するとステップＳ４０５を開始する。また、“条件入力”を選択した場合は、ステップＳ４０９を開始する。

（操作キー例その３：「最初へ」キー：動作例その２）
　献立決定支援装置１００の電源を入れた直後に献立の提案をするのではなく、「何を提案しましょうか？それとも条件入力しますか？」というメッセージを表示するようにする。以降は動作例その１と同じ動作とする。

（操作キー例その４：「詳細」キー）
　「詳細」キーは、料理の詳細を表示する操作を行うキーである。献立候補の提案画面において、ユーザが詳しい内容を見たい料理を選択して操作すると、レシピカードの内容が表示される。

（操作キー例その５：「キープ」キー）
　「キープ」キーは、提案されている献立候補の中で好みの料理にマークする操作を行うキーである。他の料理も見た上で、キープマークのついている料理だけを表示させ、その中から最終的に選択する献立を決定することができる。

（操作キー例その６：「また今度」キー）
　「また今度」キーは、提案された献立候補の中で好みだったが、例えば、食材が入手できずに作れない、時間が掛かりすぎるので今日は作れない、などの料理にマークする操作を行うキーである。このようなマークが付いた料理は、次回以降の献立提案の際に、他の条件に合えば、優先的に表示順を上位にもってくるようにしてもよい。「また今度」キーによりマークされた料理は、「お気に入り料理」としユーザデータベース１４３に格納される。たとえば、献立候補として、「お気に入り料理」だけを表示させるようしてもよい。

（操作キー例その７：「これに決めた」キー）
　「これに決めた」キーは、現在提案されている献立候補の中から最終的に選択した献立を決定する操作を行うキーである。

（操作キー例その８：「やめる」キー）
　「やめる」キーは、現在提案されている献立候補の中に気に入ったものがない場合、提案を受けるのを止める操作を行うキーである。

（操作キー例その９：「料理の追加」キー）
　「料理の追加」キーは、最初に入力した料理数の条件に対して、「もう一品」追加する操作を行うキーである。

（操作キー例その１０：「食材の追加」キー）
　「食材の追加」キーは、現在提案されている献立候補の中に、気に入ったものがない場合に、他の食材を追加する操作を行なうキーである。また、気に入った献立はあったが、さらに他の食材を追加したい場合の操作を行う場合にも用いることができる。

＜第１５の実施の形態＞
　本発明の第１５の実施の形態では、地域の特定について説明する。献立決定支援装置１００の構成は、第７～１４の実施の形態と同様である。

　図５０は、旬の時期が同じ、または旬の時期が近い単位で地域をグループ分けした例を示す図である。制御部１５０は、図５０の表を入力部１６０に画面表示させ、ユーザは自分が住んでいる地域を同表の中から選択する。地域特定部１２０は、その選択結果によって献立決定支援装置１００が置かれている地域を特定する。

　図５１は、図５０と同じ内容のデータを日本地図上に示した図である。制御部１５０は、図５１を入力部１６０に画面表示させ、地図上でユーザにいずれかの地域を選択させるようにしてもよい。この他、地図上から都道府県単位で選択できるようにしてもよい。地域特定部１２０は、その選択結果によって献立決定支援装置１００が置かれている地域を特定する。

　図５２～図５４は、ユーザが地域を指定するその他の手法を示す図である。制御部１５０は、各図が示す入力画面を入力部１６０に画面表示させ、ユーザにいずれかの地域を選択させる。地域特定部１２０は、その選択結果によって献立決定支援装置１００が置かれている地域を特定する。以下、各図について説明する。

　図５２は、プルダウンメニューから宮城県を選択した例を示す図である。

　図５３は、郵便番号から地域情報を取得する場合の入力および表示例である。郵便番号を３桁以上入力することで、地域を検索することが可能になる。ここでは郵便番号「９８０」と入力した例を示す。この時点で、地域が「宮城県仙台市内」であることが分かる。郵便番号と地域の対応関係については、あらかじめ対応関係データを地域特定部１２０が保持しておくなどして把握すればよい。

　図５４は、電話番号から地域情報を取得する場合の入力および表示例である。電話番号として市外局番を２桁以上入力することで、地域を検索することが可能になる。ここでは市外局番「０２」と入力した例を示した。市外局番「０２」から始まる地域は、「宮城県」、「山形県」、「福島県」、「新潟県」、「長野県」、「群馬県」、「栃木県」、「茨城県」の８つである。入力桁数が少ない場合、この例のように複数の地域が対象となることがあるため、それら複数の地域の中から、献立を提案してほしい地域を選択できるようにしてもよい。

　図５５は、似た気候の地域をグループ分けした例を示す図である。これは、地域の分け方を都道府県単位にこだわらず、より柔軟に分けたものである。制御部１５０は、図５５のようにグループ分けした表を入力部１６０に画面表示させ、ユーザに選択させる。地域特定部１２０は、その選択結果によって献立決定支援装置１００が置かれている地域を特定する。

　地域の分け方と、地域食材データベース１４２が格納している食材リストの地域区分とが一致していると処理の上で都合がよいが、必ずしも一致していなくともよい。

　図５６は、図５５に示した地域のグループ分けを日本地図上に示した図である。制御部１５０は、図５５の表に代えて図５６の地図を入力部１６０に画面表示させ、地図上でユーザに地域を選択させるようにしてもよい。

　以上、本第１５の実施の形態では、地域の特定について説明した。

＜第１６の実施の形態＞
　本発明の第１６の実施の形態では、日付の特定について説明する。献立決定支援装置１００の構成は、第７～１５の実施の形態と同様である。

　図５７は、日時設定画面の１例を示す図である。制御部１５０は、入力部１６０に図５７のような日時設定画面を表示させ、ユーザに現在日時を入力させる。ここでは「２００９年１０月１５日１５時３０分」を入力した例を示した。日付特定部１１０はその入力を受け取ると、内部時刻をその日時に設定する。時刻は１２時間制および２４時間制のどちらでも設定可能にしておくことが望ましい。現在、社会一般ではどちらも使われているからである。

　日付特定部１１０は、現在日時を設定した後は、内部のタイマなどにより自動的に日時を進め、以後はいつでも現在日付を特定することができる。制御部１５０は、その日付に対応する旬の地域食材や特産品を用いる献立を提案する。

　図５８～図６０は、日付を自動的に特定することに代えて、献立を提案してもらいたい日付をユーザが指定する際に用いる画面例を示す。制御部１５０は、入力部１６０に各図が示すいずれかの画面を表示させる。ユーザはその画面上で日付を入力する。日付特定部１１０は、その入力に基づき献立を提案すべき日付を特定する。以下、各図について説明する。

　図５８は、カレンダー上で日付を指定する画面例である。

　図５９は、月日入力欄に月日を数値入力する画面例である。

　図６０は、プルダウンメニューで月日を選択する画面例である。

　以上、本実施の形態では、日付の特定について説明した。

＜第１７の実施の形態＞
　図６２は、本発明の第１７の実施の形態に係る献立提案装置１００の機能ブロック図である。献立提案装置１００は、天気情報取得部１３０、レシピデータベース１４１、制御部１５０、入力部１６０、出力部１７０を備える。

　天気情報取得部１３０は、ネットワーク６００を介して天気情報提供装置８００に接続されており、天気情報提供装置２００より天気に関する情報を取得する。天気に関する情報とは、例えば指定した日時／地域の晴れ／曇り／雨といった天気、温度、湿度などを表す情報のことである。天気情報取得部１３０は、必ずしもネットワーク６００を介して天気情報提供装置８００より天気情報を取得する必要はなく、所望の天気情報が得られれば、天気情報を取得する具体的な手法は任意でよい。

　レシピデータベース１４１は、後述の図６３で説明するレシピ情報を格納している。

　制御部１５０は、献立提案装置１００の全体動作を制御する。また、天気情報取得部１３０が取得した天気情報に対応するレシピを、レシピデータベースが格納しているレシピ情報から検索して取得する。詳細は後述する。

　入力部１６０は、ユーザがレシピ情報の検索条件などを入力するためのインタフェースである。具体的には、操作ボタン、リモコン受光部、ネットワークを介して検索条件を受信するデータインタフェース、などの形態で入力部１６０を実装することができる。

　出力部１７０は、制御部１５０が取得したレシピ情報を出力する。具体的には、レシピ情報を画面表示する画面表示部、ネットワークを介してレシピ情報を出力するデータインタフェース、などの形態で出力部１７０を実装することができる。

　天気情報取得部１３０、制御部１５０は、これらの機能を実現する回路デバイスなどのハードウェアを用いて構成することもできるし、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）などの演算装置とその動作を規定するソフトウェアを用いて構成することもできる。

　レシピデータベース１４１は、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）などの記憶装置と、レシピ情報を保持するデータファイルなどを用いて構成することができる。

　本第１７の実施の形態における「献立提案部」は、制御部１５０が相当する。

　図６３は、レシピデータベース１４１が格納するレシピ情報の構成とデータ例を示す図である。レシピデータベース１４１は、個々の料理のレシピ情報を料理毎に保持するデータベースである。レシピ情報は、当該料理がどのような天気に適しているかを示す情報を、図６３の「天気によるレシピ分類」欄に保持する。レシピの分類の仕方については、次の図６４で改めて説明する。図６３の太線で記載した○は、○で囲まれた項目が当該レシピに適用されることを示している。

　また、レシピ情報は、個々のレシピ毎に、料理名、料理材料（食材）、および（出来上がり）料理温度の少なくともいずれかを表す情報を保持する。図６３では、その他の情報も保持する例を示した。これら以外の情報を併せて保持してもよい。

　図６４は、レシピの分類基準を示す図である。ここでは、図６３における「天気によるレシピ分類」欄の「温レシピ」、「冷レシピ」、「保存レシピ」の分類基準を示した。以下、各分類基準について説明する。

（３）保存レシピの分類基準
　料理材料として、一般に保存期間が長い「根菜、缶詰、春雨、乾燥わかめ、ひじき、高野豆腐、レトルト食品」を用いるレシピは、保存に適した料理である保存レシピであるとみなす。この保存レシピは、例えば大雨、雪、台風などの悪天候時に調理者が外出することなく料理できるよう、家に備蓄されていると想定される材料を使った料理レシピを提案するために用いるとよい。また、悪天候時に提案するレシピに限らず、天気情報に応じて提案する温レシピや冷レシピと適宜組み合わせてもよい。

　以上のように、本発明では、各料理をどのような場合に優先して提案すべきかを示す、各料理と気温の高低とを対応付ける情報がレシピデータに格納されている。

　以上、本第１７の実施の形態に係る献立提案装置１００の構成について説明した。次に、献立提案装置１００の動作について説明する。

　図６５は、制御部１５０が献立を提案する処理を説明するフローである。以下、図６５の各ステップについて説明する。

（図６５：ステップＳ４００）
　ユーザは、入力部１６０を介して、献立を提案するように献立提案装置１００へ指示する。このとき、日付や地域を付加的な条件として指定し、その条件に対応する天気に適した献立を提案するように指示してもよい。特に指定がない場合には、当日の同時間帯における既定地域の天気に適した献立を提案するものとする。

（図６５：ステップＳ４０１）
　制御部１５０は、ステップＳ４００で特定した日付と地域の天気情報（少なくとも気温と湿度）を取得するよう、天気情報取得部１３０に指示する。天気情報取得部１３０は、その日付と地域の天気情報を取得し、制御部１５０に出力する。

（図６５：ステップＳ４０２～Ｓ４０４）
　ステップＳ４０１で取得した湿度が５０％未満である場合はステップＳ４０８へ進み、６０％以上８０％未満である場合はステップＳ４０５へ進み、８０％以上である場合はステップＳ４０６へ進み、それ以外（５０％以上６０％未満）の場合はステップＳ４０７へ進む。

（図６５：ステップＳ４０５～Ｓ４０７）
　これらのステップは、湿度に起因する体感温度の差を補正するためのものである。湿度が８０％以上の場合は体感温度が高くなるので、制御部１５０は、実際の気温に３℃を加えた値を用いて以下の処理を行う。同様に、湿度が６０％以上８０％未満の場合は２℃を加え、５０％以上６０％未満の場合は１℃を加える。湿度が５０％未満の場合は、補正は行わない。

（図６５：ステップＳ４０８～Ｓ４０９）
　以上のステップから得られた温度が１８℃未満である場合はステップＳ４１０へ進み、１８℃以上２５℃未満である場合はステップＳ４１１へ進み、２５℃以上である場合はステップＳ４１２へ進む。

（図６５：ステップＳ４１０～Ｓ４１２）
　制御部１５０は、以上のステップから得られた温度が１８℃未満である場合は寒い日であるとみなして温レシピを提案し、１８℃以上２５℃未満である場合は中間レシピを提案し、２５℃以上である場合は暑い日であるとみなして冷レシピを提案する。

　以上、本第１７の実施の形態に係る献立提案装置１００の動作例を説明した。

　以上のように、本第１７の実施の形態によれば、レシピデータベース１４１は、天気情報と料理の特性を対応付ける対応情報として、図６３の「天気によるレシピ分類」欄に示す情報を格納している。同欄に示す情報は、図６４で説明したように、当該料理が温かい天気に適しているのか、それとも寒い天気に適しているのかといった特性を表している。制御部１５０は、この情報を用いることにより、天気情報取得部１３０が取得した天気情報に適した特性を有する献立を、適切に提案することができる。

＜第１８の実施の形態＞
　本発明の第１８の実施の形態では、第１７の実施の形態で説明した構成に加えて、調理時間を考慮して献立を提案するための構成と動作例を説明する。第１７の実施の形態で説明した献立提案装置１００は、主に出来上がった料理を食べる者の観点から献立を提案するが、本第１８の実施の形態では、調理者の調理負担の観点を導入する。献立提案装置１００の構成は第１７の実施の形態と同様であるため、以下では差異点を中心に説明する。

　図６６は、本第１８の実施の形態におけるレシピ情報の構成とデータ例を示す図である。本第１８の実施の形態におけるレシピ情報は、第１７の実施の形態の図６３で説明した構成に加え、新たに「調理器具（暑さを感じさせる）」欄、「調理器具（暑さを感じさせない）」欄、「調理方法」欄、「調理時間」欄を有する。

　「調理器具（暑さを感じさせる）」欄は、当該料理の調理を行なう際に必要となる調理器具のうち、調理者が調理工程で暑さを感じ易いものを列挙する情報を保持する。

　「調理器具（暑さを感じさせない）」欄は、当該料理の調理を行なう際に必要となる調理器具のうち、調理者が調理工程で暑さをさほど感じないものを列挙する情報を保持する。

　「調理方法」欄は、当該料理の調理を行なう際に用いる調理方法の種別を保持する。ここでいう調理方法の種別とは、詳細な調理工程のことではなく、焼く、煮るといった大まかな調理手法のことである。

　「調理時間」欄は、「調理方法」欄の各調理方法に要する時間を保持する。

　以上、本第１８の実施の形態に係る献立提案装置１００の構成について説明した。次に、調理工程が献立提案に与える影響について説明する。一般に、調理工程は、出来上がり料理が食べる者に与える「暑さ／寒さ」などの印象に影響を与えると思われる。以下ではこれらの影響について説明する。

　図６７は、本第１８の実施の形態におけるレシピの分類基準を示す図である。図６７では、第１７の実施の形態の図６４で示した分類基準に加え、新たに「調理方法」欄を設けた。レシピ情報に同欄を設けたことに対応させたものである。すなわち、調理方法と出来上がり料理の「暑さ／寒さ」などの印象には、ある程度の相関があると考えられるため、これをレシピ分類基準に反映したものである。本第１８の実施の形態では、料理を食べる者が調理方法に起因して感じる温度を考慮し、以下の新たな基準を設けた。

（１）温レシピの分類基準
　レシピ情報の「調理方法」欄に「生」または「和える」を含む料理は、温レシピの対象から除外する。

（２）冷レシピの分類基準
　レシピ情報の「調理方法」欄に「揚げる」または「炒める」を含む料理は、食べる者が暑さを感じ易いため、冷レシピの対象から除外する。

　以上、本第１８の実施の形態では、調理工程で用いられる調理方法および調理器具が出来上がり料理に与える影響を考慮してレシピを分類することを説明した。

　なお、調理方法に基づく分類は、調理者が調理工程で感じる暑さ／寒さに基づく分類であると考えることもできる。同観点によれば、例えば「調理器具（暑さを感じさせる）」に含まれる調理器具を使用する料理も、冷レシピの対象から除外してもよい。

＜第１９の実施の形態＞
　調理方法種別とその調理時間は、出来上がり料理が食べる者に与える印象の他、調理者が調理過程で受ける「暑さ／寒さ」などの印象にも影響を与える。そこで本発明の実施の形態Ｂ３では、調理工程における調理方法種別とその調理時間に着目し、これらが調理者に与える影響を勘案して献立を提案する動作例を説明する。献立提案装置１００の構成は第１７～１８の実施の形態と同様であるため、以下では差異点を中心に説明する。

　調理者が暑さを感じやすい調理方法を長時間使用すれば、調理者が調理過程で暑さを感じる可能性は高まる。そこで本第１９の実施の形態において、制御部１５０は、図６６に示す「調理方法」欄毎の「調理時間」欄の値を合算し、これに基づき、温レシピ／中間レシピ／冷レシピのいずれかを提案する。１例として、第１７の実施の形態の図６５で説明した手法に代えて以下の図６８で説明する手法を採用することが考えられる。

　図６８は、制御部１５０が調理時間に基づいて献立を提案する処理を説明するフローである。以下、図６８の各ステップについて説明する。

（図６８：ステップＳ７０１）
　制御部１５０は、図Ｂ４のステップＳ４０１～Ｓ４０７を実行する。

（図６８：ステップＳ７０２）
　制御部１５０は、レシピデータベース１４１が格納している各レシピ情報について、各調理方法の調理時間を合算する。レシピ情報内に合算時間があらかじめ記録されていればその値を用いてもよい。

（図６８：ステップＳ７０３～Ｓ７０４）
　以上のステップから得られた温度が１８℃未満である場合はステップＳ７０５へ進み、１８℃以上２５℃未満である場合はステップＳ７０６へ進み、２５℃以上である場合はステップＳ７０７へ進む。

（図６８：ステップＳ７０５～Ｓ７０７）
　制御部１５０は、以上のステップから得られた温度が１８℃未満である場合は寒い日であるとみなして合計調理時間の長いレシピを提案し、１８℃以上２５℃未満である場合は合計調理時間が中間のレシピを提案し、２５℃以上である場合は暑い日であるとみなして合計調理時間が短いレシピを提案する。合計調理時間の長短は、例えば適当な閾値を基準として、合計調理時間がその閾値より長いか短いかにより判断すればよい。

　以上のように、本第１９の実施の形態において、制御部１５０は、調理時間を基準として献立を提案する。これにより、献立提案装置１００は、調理者が調理工程で感じる暑さを勘案した献立を提案することができる。

＜第２０の実施の形態＞
　以上の第１７～１８の実施の形態では、出来上がり料理そのものが感じさせる暑さ／寒さを勘案して献立を提案する手法を説明した。また、第１９の実施の形態では、調理工程で調理者が感じる暑さ／寒さを勘案して献立を提案する手法を説明した。本第２０の発明の実施の形態では、これらの手法のいずれを優先的に用いるか、あるいは各手法をどのように組み合わせるかについて、以下の（組み合わせ手法例１）～（組み合わせ手法例４）を例示する。献立提案装置１００の構成は、第１７～１９の実施の形態と同様である。

（組み合わせ手法例１）出来上がり料理を優先する
　制御部１５０は、第１７の実施の形態で説明した手法（図６５）を採用し、料理そのものが食べる者に与える暑さ／寒さなどの印象を基準に、献立を提案する。ただし、図６６に示すようなレシピ情報を出力部１７０からユーザに提示し、ユーザが最終的に献立を決定する際に、調理工程で調理者が感じる暑さ／寒さなどの印象を参考にできるようにする。

（組み合わせ手法例２）調理者を優先する
　制御部１５０は、本第１９の実施の形態で説明した手法（図６８）を採用し、調理工程が調理者に与える暑さ／寒さなどの印象を基準に、献立を提案する。ただし、図６６に示すようなレシピ情報を出力部１７０からユーザに提示し、ユーザが最終的に献立を決定する際に、料理そのものが食べる者に与える暑さ／寒さなどの印象を参考にできるようにする。

（組み合わせ手法例３）料理と調理者をともに勘案する
　制御部１５０は、第１７の実施の形態で説明した手法（図６５）と、本第１９の実施の形態で説明した手法（図６８）とのそれぞれに、所定の優先度を付与しておく。さらに、レシピ情報中の暑さを感じさせる文字の多さや調理時間の長短などに応じて、より詳細に優先度を付与してもよい。制御部１５０は、各手法を個別に実行し、上記優先度が高い順に出力部１７０を介してユーザに提示する。

（組み合わせ手法例４）いずれを優先するかユーザが指定する
　ユーザは、出来上がり料理そのものが感じさせる暑さ／寒さと、調理工程で調理者が感じる暑さ／寒さとのいずれを優先して献立を提案すべきかを、入力部１６０を介して指定する。制御部１５０は、その指定に応じていずれかの手法を用いる。

　以上、本第２０の実施の形態では、出来上がり料理そのものが感じさせる暑さ／寒さを勘案して献立を提案する手法と、調理工程で調理者が感じる暑さ／寒さを勘案して献立を提案する手法との組み合わせについて例示した。

＜第２１の実施の形態＞
　本発明の第２１の実施の形態では、第１９の実施の形態で説明した、各調理方法種別の合計調理時間に基づき献立を提案する手法を発展させ、各調理方法種別または各調理器具の特性を勘案して献立を提案する手法を説明する。献立提案装置１００の構成は、第１７～２０の実施の形態と同様である。

　本第２１の実施の形態において、制御部１５０は、図６８のステップＳ７０２を実行する際に、各調理方法種別の調理時間を単純に合算するのではなく、各調理方法に重み係数を乗算した上で合算する。例えば以下のような計算式を用いることができる。

　合計調理時間＝（和える時間×０）＋（焼く時間）＋（煮る時間×０．５）＋（揚げる時間）＋（蒸す時間×０．２）＋（炒める時間）＋（茹でる時間×０．５）
　上記式において、和える時間に乗じている０、煮る時間と茹でる時間に乗じている０．５、蒸す時間に乗じている０．２が、上述の重み係数に相当する。この重み係数は、各調理方法種別または各調理器具に起因して調理者が暑さを感じる程度を表す係数である。重み係数の設定基準について、以下に説明する。

（設定基準１）調理方法に起因する重み係数
　煮る調理工程、蒸す調理工程、茹でる調理工程では、調理者は調理中にキッチンから離れることができるため、暑さを感じる程度は少ないと考えられる。同様に、和える工程では熱調理を行なわないため、調理者は調理方法に起因する暑さを感じないと考えられる。そこでこれらの調理方法に関しては、１未満の重み係数を設定し、実質的に暑さを感じる時間は実調理時間よりも少なくなるものと仮定した。具体的な数値は、上記に限られるものではない。

（設定基準２）調理器具に起因する重み係数
　図６６の「調理器具（暑さを感じさせない）」欄に記載されている調理器具を用いる調理工程では、調理者は暑さを感じずに調理を行なうことができるため、その調理方法種別に関しては重み係数を０に設定する。例えばレンジを使って蒸す場合には、蒸す時間に重み係数０を乗算する。

　制御部１５０は、上記重み係数を各調理方法種別に乗算した上で求めた合計調理時間に基づき、献立を提案する。合計調理時間を献立提案の基準としない場合には、求めた合計調理時間を参考情報として出力部１７０を介しユーザに提示するのみでもよい。

　図６９は、出力部１７０が提示するレシピ情報の１例を示す図である。図６９において、「調理時間」欄の下に新たに「暑さを感じる調理時間」欄を設けた。同欄には、上記重み係数を乗算して求めた合計調理時間が記載されている。煮る工程は重み係数０．５が乗算されているので、暑さを感じる調理時間は１．５分となっている。また同レシピではレンジを用いて蒸すため、蒸す工程は重み係数０が乗算され、暑さを感じる調理時間から除外されている。

　図７０は、図６９と同じ料理を異なる調理器具で調理する際のレシピ情報を示す図である。同レシピでは、蒸し器を用いて蒸すため、蒸す工程は重み係数０．２が乗算され、暑さを感じる調理時間は０．６分となっている。このように、同じ料理でも調理器具によって調理者が感じる暑さが異なるので、図６９とは異なるレシピとみなすことができる。なお、ユーザに混乱を与えないため、同じ料理レシピでも、異なる調理器具を使う場合は、料理名に調理器具の違いがわかるような表示をすると便宜である。

　以上のように、本第２１の実施の形態によれば、制御部１５０は、調理方法種別または調理器具の特性に起因して調理者が暑さを感じる程度を反映した重み係数を、各調理方法種別の調理時間毎に乗算した上で、合計調理時間を求める。これにより、実際の調理工程において調理者が感じる暑さをより忠実に反映した献立提案を行なうことができる。

　また、本第２１の実施の形態において、重み係数を反映した合計調理時間を出力部１７０からユーザに提示することにより、ユーザは調理過程で感じる暑さを参考にして献立を選択することができる。これにより、調理者の負担を軽減することができる。

＜第２２の実施の形態＞
　図７１は、本第２２の実施の形態に係る献立提案装置１００とその周辺機器の構成を示す図である。本第２２の実施の形態において、入力部１６０と出力部１７０は、ネットワーク６００を介してクライアント端末４００と接続されている。その他の構成は、第１７～２１の実施の形態と同様である。

　ユーザは、クライアント端末４００～ネットワーク６００を介して、献立提案装置１００に対し、献立を提案するように献立提案装置１００へ指示する。このとき、図６５のステップＳ４００と同様に、日付や地域を付加的な条件として指定し、その条件に対応する天気に適した献立を提案するように指示してもよい。入力部１６０はその指示を受け取って制御部１５０に出力する。制御部１５０は、第１７実施の形態Ｂ１～５で説明した手法を用いて献立を決定し、出力部１７０～ネットワーク６００を介してクライアント端末４００に送信する。

　以上のように、本第２２の実施の形態によれば、ユーザはネットワーク６００を介して、遠隔地から献立提案を得ることができる。

＜第２３の実施の形態＞
　第２２の実施の形態において、制御部１５０は、クライアント端末４００のＩＰアドレスなどに基づきクライアント端末４００の所在地域を特定し、その地域における天気情報を取得するよう天気情報取得部１３０に指示するようにしてもよい。これにより、ユーザは地域を指定することなく献立提案を得られるので、操作負担が軽減される。なお、クライアント端末４００の地域を特定する手法は、任意の公知技術を用いることができる。本第２３の実施の形態における「地域特定部」は、制御部１５０が相当する。

　さらには、特定地域の天気情報を取得した際、地域の気温と温度によって簡単な質問画面を出してもよい。

　例えば、気温２４℃、湿度６０％の天気情報を取得した場合、図６５のステップＳ４０５により、気温＝２４℃＋２℃＝２６℃となるので、制御部１５０は「暑い日」であると判定する。そこで、制御部１５０は出力部１７０を介して『今日は暑いですね。さっぱりしたお料理を作りましょうか？』という質問メッセージを表示する。ユーザが『ＹＥＳ』を選択すれば、制御部１５０はレシピデータベース１４１から冷レシピを検索する。ユーザが『ＮＯ』を選択すれば、ユーザが使いたい食材などの条件入力を行なう画面を出力部１７０に表示し、ユーザの選択にしたがって献立提案を進めていく。

＜第２４の実施の形態＞
　以上の第１７～２３の実施の形態では、気温と湿度の関係に基づき体感温度を設定し、これに基づいて献立を提案する手法を説明した。その他、例えば不快指数と体感温度の関係に基づき献立を提案することもできる。

　本第２４の実施の形態において、制御部１５０は、不快指数の計算式である、「不快指数＝０．８１×気温＋０．０１×相対湿度（０．９９×温度―１４．３）＋４６．３」を用いて、天気情報取得部１３０が取得した天気情報に基づき不快指数を設定する。

　制御部１５０は、例えば不快指数０～６０なら温かいレシピ、不快指数６１～７０なら中間レシピ、不快指数７１～１００なら冷たいレシピ、を提案する。これにより、不快指数が低く寒い日には温かいレシピを提案することができる。

＜第２５の実施の形態＞
　図６１は、本第２５の発明の実施の形態に係る献立決定支援装置１００の構成図である。本第２５の実施の形態における献立決定支援装置１００は、第７～１６の実施の形態と同様の構成を有するが、各機能部が物理的に複数の装置に分割して構成されている点が異なるため、ここでは献立決定支援システムという。以下、各装置について説明する。

　端末装置２００（クライアント端末）は、地域特定部１２０、日付特定部１１０、入力部１６０、出力部１７０を備える。端末装置２００は、ユーザが手にとって所望の献立を探すためのものであり、携帯型の装置として構成されていることが望ましい。

　サーバ３００は、記憶部１４０、制御部１５０を備える。サーバ３００は、端末装置２００から献立を提案するようリクエストを受け、第１７の実施の形態で説明した献立提案動作を実行して端末装置２００に提案内容を提示する。サーバ３００は、端末装置２００が送信するリクエストや検索条件の指定を受け付ける検索条件入力部（図示せず）を備える。サーバ３００は、異なるユーザが使用する複数の端末装置２００からのリクエストに応じられるような構成としてもよい。

　表示装置４００は、第２出力部４１０を備える。第２出力部４１０は、好適には、端末装置２００が備える出力部１７０よりも大きな画面表示部を有する。ユーザは端末装置２００の出力部１７０で献立を見ることもできるし、例えば調理を開始するときはより大画面の第２出力部４１０でレシピデータを見ながら調理をする、といった使い分けをすることもできる。

　端末装置２００、サーバ３００、表示装置４００は、ネットワーク６００によって接続されており、互いにデータを送受信することができる。好適には、ネットワーク６００は無線ネットワークであり、各装置が無線通信によって相互に通信できることが好ましい。

　各装置を無線接続すれば、端末装置２００を携帯端末装置（電子手帳、携帯電話、携帯ゲーム機、電子手帳なども含まれる）によって構成することができる。これによりユーザは、場所を選ばずに献立を検討することができ、また、献立を決めた後に、買い物の際に持参することができる。

＜第２６の実施の形態＞
　以上の第７～２５の実施の形態で説明した献立決定支援装置１００（以下、「献立決定支援装置」を含む）は、他の電子機器に組み込んでその電子機器に献立提案機能を付加するように構成してもよい。例えば以下のような電子機器に組み込む例が考えられる。

（組み込み例その１：電子レンジ）
　電子レンジに献立決定支援装置１００を組み込み、ユーザが電子レンジを用いた料理を作り易くすることができる。この場合、調理器具として電子レンジを用いる料理を優先的に提案するようにしてもよい。

＜第２７の実施の形態＞
　以上の第７～２６の実施の形態で説明した献立決定支援装置１００の機能は、ＣＰＵなどの演算装置が実行するプログラムとして実装することができる。例えば、地域特定部１２０、日付特定部１１０、制御部１５０の機能を本発明に係る献立決定支援プログラムとして実装し、演算装置に実行させることにより、献立決定支援装置１００の機能を実現することができる。

＜第２８の実施の形態＞
　図７２は、食材毎に「赤」、「白」、「黄」、「緑」、「黒」で分類したデータの一例を示す図である。色毎に１食材を1ポイントと数える。例えば、ナポリタンのレシピの場合、図７２の分類データ表に当てはめると、スパゲティは麺なので「白」１ポイント、玉ねぎは「白」1ポイント、マッシュルームはきのこ類なので「黒」1ポイント、ベーコンは「赤」1ポイント、ピーマン「緑」1ポイントとなる。

　図７３は、図２２で説明した図４のフローチャート図のステップＳ４３１において、制御部１５０が、次の提案レシピまたは他のレシピを検索するための設定条件データ例に加え、食材毎の色のバランスを配慮したレシピ提案の検索条件を設定した図である。図４のフローチャート図のステップＳ４２８において提案表示されたレシピの中に、ユーザが作りたいレシピが無かった場合や、Ｓ４３０においてユーザが作りたいレシピは見つかったが他のレシピも探したい場合に図２２の条件に加え、図７２の条件が設定される。例えば、ユーザが１品目のレシピをナポリタンに決めた場合、図７２の分類データ表に当てはめると、スパゲティは麺なので「白」１ポイント、玉ねぎは「白」1ポイント、マッシュルームはきのこ類なので「黒」1ポイント、ベーコンは「赤」1ポイント、ピーマン「緑」1ポイント、合計５ポイントとなる。この場合、決めたレシピに含まれる食材の色別のポイントは、「赤」１ポイント、「白」２ポイント、「黄」０ポイント、「緑」１ポイント、「黒」１ポイントとなり、決めたレシピに含まれる色の割合が一番多いのが「白」２ポイント、一番少ないのが「黄」０ポイントとなる。制御部１５０は、もう１品レシピを検索する際、全ての色の割合が均等になるように、１品目に決めたナポリタンの食材の色の割合が少ない「黄」に分類された食材を優先して提案する。制御部１５０は、次のレシピ候補として例えば、「黄」に分類された卵、かぼちゃ２ポイント、「赤」に分類された人参１ポイント、「緑」に分類されたブロッコリー１ポイント、「黒」に分類されたわかめ１ポイントが含まれたレシピを抽出すると、それぞれの色の合計が全て２ポイントとなり、また割合も１００％となるため、食材毎の色のバランスの良いレシピを提案することができる。なお、本実施の形態では、１食材を１ポイントとして説明したが、ポイントの計算方法は適宜変更できるようにしてもよい。

＜第２９の実施の形態＞
　冷蔵庫にたくさんの食材が入っている時など、使いたい食材の種類が多い場合は、それら使いたい食材だけで作れるレシピを提示してくれると、わざわざ買い物などをしなくても今家にあるものだけを使って作れることになるので、ありがたいと感じる利用者が多い。このための仕組みとして、以下の評価式を使う方法が考えられる。

　そのレシピの食材買い足し必要度＝（そのレシピで使う食材のうち「使いたい食材」ではない食材の種類数）／（そのレシピで使う食材の種類数）×１００％
　検索された各レシピについて、上記「食材買い足し必要度」を計算し、この値が小さいものから順に利用者に提示することで、利用者はできるだけ買い物が不要なレシピを優先的に確認することができるようになる。

　また、冷蔵庫に古い食材が入っている時など、「この食材は絶対に使いたい」と利用者が考えている場合は、その食材を使うレシピが優先的に提示されると、その食材を使い切りやすくなって、ありがたいと感じる利用者が多い。このための仕組みとして、以下の評価式を使う方法が考えられる。

　そのレシピの食材使いきり度＝（「使いたい食材」に含まれている食材のうち、そのレシピで使う食材の種類数）／（「使いたい食材」の種類数）×１００％
　検索された各レシピについて、上記「食材使いきり度」を計算し、この値が大きなものから順に利用者に提示することで、「使いたい」と思っている食材を確実に使ったレシピを優先的に確認することができるようになる。

　さらに、ユーザに「買い物不要優先」か「食材使いきり優先」かを選択してもらった上で、上記「食材買い足し必要度」と、「食材使いきり度」を両方とも計算する方法も考えられる。例えば、ユーザが「買い物不要優先」を選択した場合は、検索されたレシピリストをまず「食材買い足し必要度」の小さい順にソーティングし、「食材買い足し必要度」が同じ値になっているレシピ同士の間では「食材使いきり度」が大きいレシピを優先して提示するようにすれば良い。

　また、ユーザが「食材使いきり優先」を選択した場合は、検索されたレシピリストをまず「食材使いきり度」の大きい順にソーティングし、「食材使いきり度」が同じ値になっているレシピ同士の間では「食材買い足し必要度」が小さいレシピを優先して提示するようにすれば良い。

　また、食材の在庫管理機能を備える場合は、在庫の食材の種類が豊富なときは自動的に「買い物不要優先」にし、在庫の食材のうち消費期限が切れそうなもの（または購入してから一定期間以上経過するもの）が存在するときは、それら消費期限がきれそうな食材（または購入してから一定期間以上経過した食材）を使い切るようなレシピを優先して提案するように「食材使いきり優先」を自動的に選択する仕組みを導入すると良い。

　本発明は、電子レンジ、電子オーブン、ＰＣを用いた献立提示装置などに利用可能である。

　本明細書で引用した全ての刊行物、特許および特許出願をそのまま参考として本明細書にとり入れるものとする。

Claims

　１つ以上の料理からなる献立の提案における条件設定を含むユーザからの入力操作を受け付ける入力部と、
　入力された前記条件設定に基づいて、適した料理をデータベースから検索する制御部と、
　検索結果をユーザに提示する出力部と、
　提示された料理に対してのユーザの評価を受け付ける評価入力部と、
を備え、
　前記制御部は、前記条件設定と前記ユーザの評価とに基づいて、適した料理を再検索する機能を備えることを特徴とする献立決定支援装置。
　提示された料理に対しての前記ユーザの評価が、
「その料理に決める」という第１の評価と、
「気になるがその料理は今回は選択しない」という第２の評価と、
の少なくとも２種類であり、
　前記第１の評価の場合には、その評価を行った料理を今回提案する献立を構成する料理の一品に決定すると共に、その料理のレシピデータに基づいて条件設定を変更して次の料理の検索を行い、
　前記第２の評価の場合には、その評価を行った料理のレシピデータに基づいて条件設定を変更して再検索を行うことを特徴とする請求項１に記載の献立決定支援装置。
　さらに、
　現在日時である日付を特定する日付特定部と、
　現在位置である地域を特定する地域特定部と、
　天気情報を取得する天気情報取得部と、
　ユーザを特定する情報を記憶するユーザ情報データベースと、の少なくともいずれかを備え、
　前記制御部は、前記条件設定と、特定された前記日付と前記地域と前記天気と前記特定されたユーザとの少なくともいずれかと、に基づいて、適した料理を検索することを特徴とする請求項１又は２に記載の献立決定支援装置。
　さらに、
　料理毎に料理名、材料、味、食感、色を含む基本データを保持するレシピ情報データベースと、
　ユーザに依存する属性をユーザ毎にカスタマイズするためのデータを格納するユーザ登録情報データベースと、
　システムに内蔵され、ユーザに依存しない属性を、ユーザ毎にカスタマイズするためのデータを格納するシステム登録データベースと、を備え、
　前記制御部は、
　前記レシピ情報データベースおよび前記システム登録データベースの情報からユーザの条件に適したレシピの検索を実行するデータベース検索部と、
　前記ユーザ登録情報データベースおよび前記システム登録データベースの情報をもとに、前記データベース検索部を介してユーザの条件に適した対話メッセージを、定型の対話メッセージを格納する対話メッセージデータベースから抽出しカスタマイズする対話メッセージ抽出処理部と、を有することを特徴とする請求項１から３までのいずれか１項に記載の献立決定支援装置。
　さらに、ユーザの好みのレシピデータ、ユーザが好みのレシピを決めるまでの履歴データを保持する好みのレシピデータベースを備え、
　前記好みのレシピデータベースを考慮してユーザの条件に適したレシピを抽出することを特徴とする請求項４に記載の献立決定支援装置。
　前記レシピ情報データベースは、前記レシピデータが記述している料理が完成した場合の色彩を含む出来上がりイメージを提供する画像データを保持することを特徴とする請求項４に記載の献立決定支援装置。
　前記レシピ情報データベースは、前記天気情報と対応して、天気に適したレシピを提案するレシピ分類データを保持することを特徴とする請求項４に記載の献立決定支援装置。
　記念日に応じた献立を提案する記念日データベースを備え、前記現在日時が前記記念日と一致した場合に、記念日であることをユーザに報知することを特徴とする請求項４に記載の献立決定支援装置。
　行事データベースを備え、前記現在日時が行事のある日時と一致した場合に、前記行事に応じた献立を提案することを特徴とする請求項４に記載の献立決定支援装置。
　前記天気データベースを備え、取得した前記天気情報に応じた献立を提案することを特徴とする請求項４に記載の献立決定支援装置。
　前記日時情報に基づいて、旬に応じた献立を提案する旬食材データベースを備えることを特徴とする請求項４に記載の献立決定支援装置。
　前記レシピ情報データベースは、前記レシピデータが記述している料理の調理手順を記述したデータを保持し、
　前記データに基づいて、複数の料理の調理手順をタイムチャートとして表示することを特徴とする請求項４に記載の献立決定支援装置。
　食材の在庫を管理する在庫管理手段を備え、前記データベース検索部は、前記在庫管理手段が管理する食材の在庫に基づいてレシピを提案することを特徴とする請求項４に記載の献立決定支援装置。
　前記対話メッセージ抽出処理部は、請求項５から１２までに記載の取得条件に適したメッセージを抽出してユーザに報知することを特徴とする献立決定支援装置。
　前記データベース検索部は、請求項６から１２までのいずれか１項に記載の取得条件に加えて、ユーザが選択した取得条件の登録件数に応じて、レシピの選択傾向又は提案優先順位を変更することを特徴とする献立決定支援装置。
　請求項１から１５までのいずれか１項に記載の献立決定支援装置が、調理装置と一体又は別体となっていることを特徴とする献立決定支援システム。
　前記献立決定支援システムを構成する電子機器が、電子レンジ、携帯電子機器又は冷蔵庫であることを特徴とする請求項１６に記載のシステム。
　コンピュータを用いて請求項１から請求項１５までのいずれか１項に記載の献立決定支援装置の機能を実現するためのプログラム。
　請求項１８に記載のプログラムを記憶するコンピュータ読み取り可能な記憶媒体。
　前記在庫管理手段は、食材の在庫データに、提案された献立に使用される食材の量を反映させることを特徴とする請求項１３に記載の献立決定支援装置。
　地域食材データベースを備え、前記地域特定部は、現在位置を食材や特産品により区別される地域単位で特定することを特徴とする請求項３から１２までに記載の献立決定支援装置。
　選択済みの第１の料理と、これから選択する候補である第２の料理と、の画像の色データを基準とした距離を求めて、前記第１の料理と色合いが適した前記第２の料理を提案することを特徴とする請求項３から１２までに記載の献立決定支援装置。
　前記ユーザ情報データベースが、ユーザが過去に選択した条件を含む選択履歴情報を格納しており、選択された回数の多いものほど優先して食材又は献立が提案されることを特徴とする請求項３から１２までに記載の献立決定支援装置。
　前記入力部によりユーザが指定する指定食材が入力されている場合には、前記指定食材を優先して用いる献立が提案されることを特徴とする請求項３から１２までに記載の献立決定支援装置。
　複数の料理を含む献立が提案される際に、前記指定食材とそれ以外の指定外食材とで、含まれる割合を前記指定食材が高くなるように変更することを特徴とする請求項３から１２までに記載の献立決定支援装置。
　複数の料理を含む献立が提案される際に、調理方法が重ならないように献立が提案されることを特徴とする請求項３から１２までに記載の献立決定支援装置。
　前記入力部によりユーザが指定するＮＧ食材又はＮＧ調理法が入力されている場合には、前記ＮＧ食材又は前記ＮＧ調理法を除外して用いる献立が提案されることを特徴とする請求項３から１２までに記載の献立決定支援装置。
　選択条件に優先順位を付して献立を提案させることを特徴とする請求項３から１２までに記載の献立決定支援装置。
　前記レシピ情報データに含まれる各項目について表示の有無を選択可能としたことを特徴とする請求項３から１２までに記載の献立決定支援装置。
　前記入力部は、料理又は食材の追加キーを備えていることを特徴とする請求項３から１２までに記載の献立決定支援装置。
　前記地域単位を区分けして表示させる表示制御部を有することを特徴とする請求項２１に記載の献立決定支援装置。
　前記レシピ情報データベースは、個々の料理がどのような天気に適しているかを示す情報を含むことを特徴とする請求項４から１２までに記載の献立決定支援装置。
　さらに、調理器具、調理方法、調理時間の少なくともいずれかを考慮して、前記天気との関係で、適した温／冷レシピを提案することを特徴とする請求項３２に記載の献立決定支援装置。
　前記調理方法種別毎に前記調理時間欄の値を合算して、適した温／冷レシピを提案することを特徴とする請求項３３に記載の献立決定支援装置。
　前記調理方法種別の調理方法に重み係数を付与した後に前記調理時間欄の値を合算することを特徴とする請求項３４に記載の献立決定支援装置。
　請求項３３に記載の提案のベースと請求項３４に記載の提案のベースとの組み合わせにより最終提案を行うことを特徴とする献立決定支援装置。
　献立の提案をネットワーク経由で受信する受信部を有することを特徴とする請求項１から１２までのいずれか１項に記載の献立決定支援装置。
　不快指数と体感温度とに基づいて、献立を提案することを特徴とする請求項３２から３７までのいずれか１項に記載の献立決定支援装置。
　各食材を色により分類し、使用する食材の色のバランスに基づいて、献立を提案することを特徴とする請求項４から１２までに記載の献立決定支援装置。
　料理の提案の優先順位として、「買い物不要優先」又は「食材使いきり優先」を選択できることを特徴とする請求項１または２に記載の献立決定支援装置。
　さらに食材の在庫管理機能を備え、在庫食材の種類数や消費期限に応じて、前記「買い物不要優先」であるか前記「食材使いきり優先」であるかを自動的に選択することを特徴とする請求項４０に記載の献立決定支援装置。