JP6411639B2 - 食材提案装置、食材提案方法及び食材提案プログラム - Google Patents

Description

本発明は、食材提案装置、食材提案方法及び食材提案プログラムに関する。

食事、運動、睡眠等の生活習慣は、人間の健康状態に重要な影響を及ぼす。そのなかでも食事は、とりわけ重要である。健康状態は人間の外面にも表れるので、食事は、美容面からも重要である。さらに食事は、人間にとって楽しみでもあり、適切な工夫を行い食材、献立を選択することによって、飽きずに健康維持が実行できる。このようなことを背景に、近時、食事選択を支援する技術が多く世に出ている。

特許文献１の生産流通システムは、健康状態、栄養素、食材、献立、食材の産地及び店舗を関連付けたテーブルを記憶している。そして、健康状態の入力を受け付けると、その健康状態に対応する栄養素、食材、献立、食材の産地及び店舗を表示する。特許文献２の献立支援装置は、食材、栄養素、栄養素の閾値及び献立を関連付けたテーブルを記憶している。そして、食材の在庫量の変化を常時監視しており、ある食材の在庫量が減少するのを検出すると、その食材に含まれる栄養素が摂取されたとみなし、摂取量の減少分と閾値とを比較する。減少分が閾値を超過すると、特許文献２の献立支援装置は、その栄養素を含む献立を表示する。

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

特許文献１の生産流通システムが記憶するテーブルでは、健康状態と栄養素とが１対１に対応している。さらに、食材と栄養素も１対１に対応している。すると、ある１つの健康状態を改善するための食材が１つに決まり、ユーザにとっての選択肢がなくなる。また、同時に多くの健康状態を改善しようとするユーザには、ユーザが選択し切れない数の食材が提案されることになる。提案された食材には、ユーザにとって不要（有害）な栄養素が含まれていることもある。そして、特許文献１の生産流通システムは、ユーザが摂取した食材を記録する手段を有さない。全体として、特許文献１の生産流通システムは、多忙なビジネスパーソンがレストラン等を探すのには向いているが、健康意識が高く、自炊をする人には向いていない。

特許文献２の献立支援装置は、ユーザの健康状態を直接問うものではなく、ユーザがどのような食材の在庫量を減少させたかを問うだけである。よって、在庫量が減少しないような食材の摂取（外食、出前等）は捨象される。また、特許文献２の献立支援装置が表示するのは、食材ではなく献立である。そもそも、表示された献立がユーザの好みに一致するとは限らない。仮に一致しても、ユーザが、その献立を調理するための食材のうち、健康状態の改善のためには不要な食材を入手できない場合もある。この場合、健康状態の改善のために必要な食材が入手できるにもかかわらず、その献立を断念するという本末転倒が生じる。特許文献２の献立支援装置もまた、複数の必要な食材を買いだめしておき、別々の献立として別々の機会に摂取する、というようなユーザには向かない。

そこで、本発明は、自身の方法及びタイミングで食材を調理し摂取しようとするユーザに対し、症状の改善のために真に必要な食材を、適当な数の候補として提案することを目標とする。特に、候補の数については、症状の入力数が少なくても充分な数の候補を提案し、逆に症状の入力数が多くても、複数の症状の改善に同時に寄与する少数の候補を提案する等、柔軟に調整することを目標とする。さらに、提案された食材及びそのうちユーザに選択された食材を適宜に記録することを目的とする。

本発明の食材提案装置は、症状と栄養素との組み合わせごとに、症状の改善に対する栄養素の有効度が記憶される症状・栄養素情報と、食材と栄養素との組み合わせごとに、食材に含まれる栄養素の含有量が記憶される食材・栄養素情報と、が格納される記憶部と、ユーザが複数の症状を入力するのを受け付ける症状受付処理部と、受け付けた複数の症状に基づいて、症状・栄養素情報を検索し、受け付けた複数の症状の改善に対する有効度を栄養素ごとに取得する必要栄養素決定部と、取得した有効度と、食材・栄養素情報に記憶される食材ごとの含有量とに基づいて、食材ごとにスコアを算出し、算出したスコアの大小関係に基づき、予め設定された任意の数だけユーザに対して提案する食材を決定する食材候補決定部と、決定した食材を表示する食材候補表示処理部と、を有し、食材・栄養素情報は、食材に関連付けて、嗜好係数を記憶しており、食材候補表示処理部は、表示した食材をユーザが選択するのを受け付け、食材候補決定部は、嗜好係数に基づいてスコアを算出し、表示した食材と選択を受け付けた食材との比率に基づき、嗜好係数を更新することを特徴とする。
その他の手段については、発明を実施するための形態のなかで説明する。

本発明によれば、自身の方法及びタイミングで食材を調理し摂取しようとするユーザに対し、症状の改善のために真に必要な食材を、適当な数の候補として提案することができる。

食材提案装置の構成の一例を説明する図である。 問診画面の一例を示す図である。 食材提案画面の一例を説明する図である。 達成率推移画面の一例を示す図である。 会話画面の一例を示す図である。 症状受付情報の一例を示す図である。 食材提案情報の一例を示す図である。 症状・栄養素情報の一例を示す図である。 症状・栄養素情報の一例を示す図である。 食材・栄養素情報の一例を示す図である。 食材・栄養素情報の一例を示す図である。 食材群情報の一例を示す図である。 処理手順のフローチャートである。 （ａ）及び（ｂ）は、有効度の学習を説明する図である。

以降、本発明を実施するための形態（“本実施形態”と言う）を、図等を参照しながら詳細に説明する。本実施形態において、食材提案装置のユーザは、携帯可能な端末装置からネットワークを介して食材提案装置にアクセスし問診画面等（詳細後記）を視認する。

（用語）
症状とは、ユーザが自身の健康状態について心配している点である。例えば症状の代表例として、血圧が高い、血糖値が高い、肥満である等、特定の疾病との関連が明確なものが挙げられる。症状は、必ずしも特定の疾病との関係が明確なものである必要はない。例えば、肌のキメが乱れている、肌にくすみがある、肌が脂っぽい、化粧ノリが悪い、目のクマが目立つ、髪がまとまらない、フケが多い、口臭がきつい、体がだるい、胃の調子が悪い、食欲がない、肩が凝る、等も症状となり得る。また、症状は、身体的なものだけではなく、心理的なものも含む。例えば、集中力がない、イライラする等もまた、症状となり得る。

さらに、症状は、食生活や生活パタンの乱れ等の生活習慣自体、生活習慣の改善に取り組む途上での苦しみを含んでもよい。例えば、夜食を頻繁に取る、朝寝坊する、禁煙の離脱症状がある、等も症状となり得る。本実施形態は、食材提案装置が表示する問診画面に対してユーザが症状を入力する例を記述する。しかしながら、ユーザに負担を課すことなく、食材提案装置は、ユーザが日常使用する体組織計、血圧計、歩数計、睡眠計等の機器から即時的又は事後的に測定値を受け付けてもよい。さらに、健康診断結果、医師等との対面で取得された問診結果等が利用可能である場合、食材提案装置は、それらのデータを記憶する装置からそれらのデータを受け付けてもよい。

食材とは、ユーザが市場で入手可能な自然食品又はその加工品である。一般的に、ユーザは複数の食材を入手し、独自の方法で調理し献立として摂取する。食材は、調理の前段階にあり、調理の後段階にある献立とは異なる。例えば、にんじん、ピーマン及びたまねぎは、食材である。ユーザは、これらの食材を調理して、チャーハン、野菜炒め等の献立を作ることができる。因みに、プレーンヨーグルトは、自然食品である牛乳を工場で加工したものである。この加工は、ユーザによって行なわれるものではない。したがって、牛乳及びプレーンヨーグルトの両者が食材となり得る。

栄養素とは、ユーザが日常的に経口摂取することが可能であり、症状の改善に対する有効度及び食材に含まれる含有量が測定可能である化学的物質である。栄養素は、法的に表示義務を課されている栄養成分であるタンパク質、カリウム、カルシウム等だけでなく、それ以外にも、乳酸菌、消化酵素、クエン酸等を含み得る。

（食材提案装置）
図１に沿って、食材提案装置１の構成を説明する。食材提案装置１は、一般的なコンピュータである。食材提案装置１は、中央制御装置１１、主記憶装置１２、補助記憶装置１３及び通信装置１４を有する。また、食材提案装置１は、入力装置及び出力装置（図示せず）を有していてもよい。これらは、バスによって相互に接続されている。補助記憶装置１３は、症状受付情報３１、食材提案情報３２、症状・栄養素情報３３、食材・栄養素情報３４及び食材群情報３５を記憶している（詳細後記）。主記憶装置１２における症状受付処理部２１、必要栄養素決定部２２、食材候補決定部２３及び食材候補表示処理部２４はプログラムである。以降、“○○部は”と主体を記した場合は、中央制御装置１１が、補助記憶装置１３から○○部を読み出し、主記憶装置１２にロードしたうえで、○○部の機能（詳細後記）を実現するものとする。

端末装置２は、ネットワーク３を介して、食材提案装置１と通信可能である。端末装置２は、一般的な携帯型のコンピュータである。端末装置２は、入力装置１５及び出力装置１６を有している。入力装置１５及び出力装置１６は、タッチスクリーン等の、一体型の入出力装置であってもよい。端末装置２はまた、ネットワーク３を介して、外部システム４と通信可能である。外部システム４は、例えば受け付けた食材に対してその食材を使用する献立の例を出力する（食材メーカ等が運営する）システムである。

（問診画面）
図２に沿って、問診画面５１を説明する。食材提案装置１の症状受付処理部２１は、端末装置２の出力装置１６に問診画面５１を表示する。問診画面５１は、問診欄５２ａ、５２ｂ、５２ｃ、・・・を有する。問診欄５２ａは、ユーザに対して症状の有無を問う質問文“キメの乱れが気になりますか？”５３ａ、“はい”ボタン５４ａ及び“いいえ”ボタン５５ａを有する。問診欄５２ｂは、質問文“毛穴は目立つほうですか？”５３ｂ、“はい”ボタン５４ｂ及び“いいえ”ボタン５５ｂを有する。問診欄５２ｃは、質問文“胃の調子が気になりますか？”５３ｃ、“はい”ボタン５４ｃ及び“いいえ”ボタン５５ｃを有する。

症状受付処理部２１は、ユーザが各質問文に対して、“はい”ボタン又は“いいえ”ボタンのいずれかを押下するのを受け付ける。ユーザが“登録”ボタン５６を押下すると、症状受付処理部２１は、症状受付情報３１の新たなレコードを作成する（詳細後記）。

（食材提案画面）
図３に沿って、食材提案画面６１を説明する。食材提案装置１の食材候補表示処理部２４は、端末装置２の出力装置１６に食材提案画面６１を表示する。食材提案画面６１は、食材アイコン６２ａ、６２ｂ、６２ｃ、・・・、基準時点６３、“確定”ボタン６４、“献立のヒント”ボタン６５及び“お勧め変更”ボタン６６を有する。食材アイコン６２ａ等は、問診画面５１（図２）において入力された“はい”に対応する質問文の症状（複数ある場合もある）を改善する食材を示している。

食材候補表示処理部２４は、ユーザが任意の１又は複数の食材アイコンを押下する（仮選択する）のを受け付ける。すると、食材候補表示処理部２４は、仮選択マーク６７を食材アイコンに付す。食材候補表示処理部２４は、仮選択マーク６７が付された食材アイコンをユーザが再度押下するのを受け付けると、仮選択を解除し仮選択マーク６７を消す。

続いて、食材候補表示処理部２４は、少なくとも１つの食材が仮選択されている状態でユーザが“確定”ボタン６４を押下する（確定選択する）のを受け付ける。すると、食材候補表示処理部２４は、仮選択マーク６７が付された食材アイコンを確定選択状態にする（例えば符号６８のように強調表示をする）。そして、食材候補表示処理部２４は、表示されたすべての食材及び確定選択された食材を、食材提案情報３２に記憶する（詳細後記）。その後さらにユーザは、既に確定選択している食材以外の食材を仮選択し、次いでその食材を追加的に確定選択することもできる。

食材候補表示処理部２４は、少なくとも１つの食材が確定選択（又は仮選択）されている状態で、ユーザが“献立のヒント”ボタン６５を押下するのを受け付ける。すると、食材候補表示処理部２４は、ネットワーク３を介して外部システム４にアクセスする。そして、確定選択（又は仮選択）されている食材を使用する献立の例を取得したうえで、食材提案画面６１の任意の領域に取得した献立を表示する。基準時点６３は、現時点の月日であってもよいし、提案された食材をユーザが摂取し終わる期限の月日（例えば、現時点の月日の３日後）であってもよい。“お勧め変更”ボタン６６については、詳細を後記する。

（症状受付情報）
説明の都合上、図４及び図５の説明を後回しにして、先に図６に沿って、症状受付情報３１を説明する。症状受付情報３１においては、ユーザＩＤ欄１０１に記憶されたユーザＩＤに関連付けて、ユーザ名欄１０２にはユーザ名が、送信時点欄１０３には送信時点が、症状ＩＤ欄１０４には症状ＩＤが、症状欄１０５には症状が、回答欄１０６には回答が記憶されている。

ユーザＩＤ欄１０１のユーザＩＤは、ユーザを一意に特定する識別子である。ユーザは、食材提案装置１のユーザであり、端末装置２のユーザでもある。
ユーザ名欄１０２のユーザ名は、ユーザの氏名である。
送信時点欄１０３の送信時点は、ユーザが“登録”ボタン５６（図２）を押下した時点の年月日時分秒である。
症状ＩＤ欄１０４の症状ＩＤは、症状を一意に特定する識別子である。
症状欄１０５の症状は、前記した症状である。なお、質問文はもともと、例えば“キメの乱れが気になりますか？”という疑問文である。ここでは単純化及びわかり易さのために、“キメが乱れている”という肯定文が症状として記載されている。
回答欄１０６の回答は、“はい”又は“いいえ”のいずれかである。

（食材提案情報）
図７に沿って、食材提案情報３２を説明する。食材提案情報３２においては、ユーザＩＤ欄１１１に記憶されたユーザＩＤに関連付けて、ユーザ名欄１１２にはユーザ名が、送信時点欄１１３には送信時点が、提案食材欄１１４には提案食材が、提案数欄１１５には提案数が、選択数欄１１６には選択数が記憶されている。
ユーザＩＤ欄１１１のユーザＩＤは、図６のユーザＩＤと同じである。
ユーザ名欄１１２のユーザ名は、図６のユーザ名と同じである。
送信時点欄１１３の送信時点は、ユーザが“確定”ボタン６４（図３）を押下した時点の年月日時分秒である。

提案食材欄１１４の提案食材は、食材候補決定部２３が決定し、食材候補表示処理部２４が食材提案画面６１（図３）の食材アイコン６２ａ等として表示した食材とそのスコア（詳細後記）との組み合わせである。食材とスコアとの組み合わせは、“（ ）”又は“〈 〉”で囲まれている。“（ ）”は、その食材が表示されたもののユーザによって確定選択されなかったことを示す。“〈 〉”は、その食材が表示され、ユーザによって確定選択されたことを示す。
提案数欄１１５の提案数は、提案された（表示された）食材の数である。つまり、“（ ）”及び“〈 〉”の数である。
選択数欄１１６の選択数は、ユーザによって確定選択された食材の数である。つまり、 “〈 〉”の数である。

（症状・栄養素情報）
図８に沿って、症状・栄養素情報３３を説明する。症状・栄養素情報３３は、縦軸に症状を有し、横軸に栄養素を有するマトリクス（行列）を含む。そして、縦軸と横軸との交点のセルに、その症状の改善に対するその栄養素の有効度を示す値が記憶されている。さらに具体的には、縦軸には、症状ＩＤが症状とともに並んでいる。ここでの症状ＩＤ及び症状は、図６の症状ＩＤ及び症状と同じである。図８では、症状は全部で１０個あるが、ユーザはその数を任意に設定可能である。なお、“質問周期”については後記する。横軸には、栄養素ＩＤ（j０１、j０２、・・・）が栄養素（タンパク質、カリウム、・・・）とともに並んでいる。栄養素ＩＤとは、前記した栄養素を一意に特定する識別子である。図８では、栄養素は全部で１２個あるが、ユーザはその数を任意に設定可能である。もちろん、各症状の改善に効果のある栄養素は、実際には例示された１２個以外にも存在する（図８は、説明用の簡略図である）。

図８の１０行１２列のマトリクスの成分を“Ｓ_ｉ，ｊ”（ｉ＝１，２，・・・，１０、ｊ＝１，２，・・・，１２）と表わすことができる。詳細は後記するが、症状・栄養素情報３３の任意の行のすべての成分（有効度の値）からなるベクトルを“Ｓ_{ｉ，ａｌｌ}”と表すことができる。同様に、症状・栄養素情報３３の任意の列のすべての成分からなるベクトルを“Ｓ_{ａｌｌ，ｊ}”と表すことができる。

（質問周期）
症状が変化する時間的スケールは、症状により異なる。例えば、飲酒による不調（二日酔い等）は、翌日又は翌々日には改善される。したがって、症状受付処理部２１が１日ごとに、“飲酒による不調が残っていますか？”のような質問文を表示することには意味がある。その一方で、便秘の改善には１週間程度を要し、肌の症状の改善には１か月程度を要し、高血圧の改善には数カ月を要する。

そこで、症状・栄養素情報３３は、症状に関連付けて質問周期を記憶している。症状受付処理部２１は、前回その症状の有無を問う質問文を表示した後、質問周期の日数が経過するまでの期間は、当該質問文を表示しないものとする。または、症状受付処理部２１は、質問周期の日数が経過するまでの期間は、 “はい”ボタン又は“いいえ”ボタンのうち前回の回答である方を強調表示（デフォルト表示）する。そして、症状の変化がある場合にのみ、ユーザが他方のボタンを押下するのを受け付けてもよい。

図９もまた、症状・栄養素情報３３である。ただし、図９においては、各交点のセルに、“Ｓ_ｉ，ｊ”の具体的な値が記憶されている。この値が有効度である。有効度は正負の値及び“０”を取り得る。単純化された例としては、有効度は以下の４つの値のうちのいずれかである。図９もこの例に倣うが、図９には偶々“−１”の記載はない。
“２”は、その症状の改善に対して、その栄養素が非常に有効であることを示す。
“１”は、その症状の改善に対して、その栄養素が有効であることを示す。
“０”は、その症状の改善に対して、その栄養素が無効であることを示す。
“−１”は、その症状の改善に対して、その栄養素が有害であることを示す。

（食材・栄養素情報）
図１０に沿って、食材・栄養素情報３４を説明する。食材・栄養素情報３４は、縦軸に食材を有し、横軸に栄養素を有するマトリクス（行列）を含む。そして、縦軸と横軸との交点のセルに、その食材に含まれるその栄養素の含有量を示す値が記憶されている。さらに具体的には、縦軸には、食材ＩＤが食材とともに並んでいる。食材ＩＤとは、食材を一意に特定する識別子である。図１０では、食材は全部で１６個あるが、ユーザはその数を任意に設定可能である。なお、“食材群”、“嗜好係数”及び“旬係数”については後記する。横軸には、図８及び図９と同様に、栄養素ＩＤが栄養素とともに並んでいる。図１０においても、栄養素は全部で１２個あるが、ユーザはその数を任意に設定可能である。もちろん、各食材は、実際には例示された１２個以外の栄養素も含む（図１０は、説明用の簡略図である）。本実施形態においては、症状・栄養素情報３３（図８、図９）の横軸と、食材・栄養素情報３４（図１０、図１１）の横軸とは、栄養素の数、種類及び配列順序において、完全に一致していることが前提になっている。

図１０の１６行１２列のマトリクスの成分を“Ｆ_ｋ，ｊ”（ｋ＝１，２，・・・，１６、ｊ＝１，２，・・・，１２）と表わすことができる。詳細は後記するが、食材・栄養素情報３４の任意の行のすべての成分（含有量の値）からなるベクトルを“Ｆ_{ｋ，ａｌｌ}”と表すことができる。同様に、食材・栄養素情報３４の任意の列のすべての成分からなるベクトルを“Ｆ_{ａｌｌ，ｊ}”と表すことができる。なお、ここでは、マトリクスの構造を説明するために、“Ｆ_{ａｌｌ，ｊ}”に言及したが、本実施形態において以降“Ｆ_{ａｌｌ，ｊ}”が使用されることはない。

図１０に再度注目すると、食材・栄養素情報３４においては、食材に関連付けて、食材群Ｃ_ｋ、嗜好係数Ｔ_ｋ及び旬係数Ｈ_ｋが記憶されている。

（旬係数）
自然物である食材に対して、自然条件の観点から入手しやすい季節（時期）とそうでない季節を定義することができる。自然条件の観点から入手しやすい季節を、その食材の旬と呼ぶ。旬は、当然食材ごとに異なるし、同じ食材であっても地域ごとに異なる。現在では、栽培・養殖技術の進歩により大抵の食材は季節を問わずに入手可能になっている。しかしながら、同じ食材であっても自然の恵みに育まれた場合と、人工的に育成された場合とでは、おのずと品質に差異が生じる。旬係数Ｈ_ｋは、例えば、“０≦Ｈ_ｋ≦２”の範囲を有する値である。

補助記憶装置１３は、食材ごとに旬の季節（例えば月）が記憶される旬テーブル（図示せず）を格納しているものとする。そして、食材候補決定部２３は、現時点が旬の季節にあれば、旬係数を“２”に近付ける。現時点が旬の季節になければ、旬係数を“０”に近付ける。このように、旬係数は、“１”を基準として常時変化する。ただし、季節感のない加工品の食材については、その旬係数は“１”の近辺に固定され、殆ど変化しない。

（嗜好係数）
特定のユーザが特定の期間に特定の食材を確定選択した回数を、そのユーザにその期間にその食材が提案された（食材提案画面６１に表示された）回数で除算した値を、“選択率”として定義する。嗜好係数Ｔ_ｋは、選択率に応じて、例えば、０≦Ｔ_ｋ≦２の範囲の値を取る。具体的には、嗜好係数の初期値は“１”である。食材候補決定部２３は、常時選択率を監視しており、選択率が所定の閾値を超える場合、嗜好係数に対して例えば“１.２”を乗算する（上限は“２”である）。同様に、食材候補決定部２３は、選択率が所定の（別の）閾値に満たない場合、嗜好係数に対して例えば“０.８”を乗算する。特例として、医師等の判断によりそのユーザがその食材の摂取を禁止されている又は制限されている場合（アレルギーである食材等）、嗜好係数には“−１”が固定的に設定される。図１０からは直接読み取れないが、このように、嗜好係数は、食材、ユーザ及び期間の組み合わせに対して定義されることに留意するべきである。

（食材群）
食材候補決定部２３は、症状の改善に対して有効な栄養素を含有する食材をユーザに提案する。しかしながら、ユーザが同じ食材ばかり摂取していると、栄養バランスが崩れ、むしろ健康を害するリスクが高まる。このような偏りを防止するには、共通の栄養素を含有するもの同士で、食材をいくつかの食材群に分類し、各食材群から少なくとも１つの食材が提案されるようにすればよい。食材群については、図１２の説明としても後記する。

図１１もまた、食材・栄養素情報３４である。ただし、図１１においては、各交点のセルに、“Ｆ_ｋ，ｊ”の具体的な値が記憶されている。この値が含有量である。含有量は正の値及び“０”を取り得る。単純化された例としては、含有量は以下の４つの値のうちのいずれかである。図１１もこの例に倣う。
“３”は、その食材がその栄養素を特に多く含むことを示す。
“２”は、その食材がその栄養素を多く含むことを示す。
“１”は、その食材がその栄養素を含むことを示す。
“０”は、その食材がその栄養素を含まないことを示す。

（有効度と含有量）
ある食材に対して、含有量は一意に定義される。例えば、“さつまいも”は（採取された年の自然条件にも微妙に左右されるが）、ほぼ一定の化学的組成を有し、各栄養素の含有量はほぼ一定であると考え得る。一方、ある症状に対して、有効度が一意に定義されるかと言えば必ずしもそうではない。個々のユーザの体質、ある地理的条件における人間集団の体質によって、有効度は変化し得る。

例えば、ユーザ“ｕ０１”に“キメが乱れている”という症状がある場合、“ビタミンＡ”が有効であるが、“ビタミンＥ”は無効であるとする。ところが、例えば、ユーザ“ｕ０２”に同じ“キメが乱れている”という症状がある場合、“ビタミンＥ”が有効であるが、“ビタミンＡ”は無効である、ということがあり得る（あくまでも説明目的の例であり、生理学的検証はしていない）。つまり、症状・栄養素情報３３の各有効度（Ｓ_ｉ，ｊ）は、個人又は人間集団の体質そのものであり、各有効度を最適な値に更新していくことが、適切な食材の提供のためには重要である。

（食材群情報）
図１２に沿って、食材群情報３５を説明する。食材群情報３５においては、食材群ＩＤ欄１２１に記憶された食材群ＩＤに関連付けて、食材群欄１２２には食材群が記憶されている。
食材群ＩＤ欄１２１の食材群ＩＤは、食材群を一意に特定する識別子である。ここでは、１、２、・・・、７の数字が割り当てられている。
食材群欄１２２の食材群は、食材群の名称である。この名称によって、各食材群がどのような食材を含むかがおよそわかるようになっている。
食材は、いずれかの分類に属する。ユーザは、“１”〜“７”の食材群のそれぞれから少なくとも１つの食材を摂取することが好ましい。なお、食材群を細分化する程度（粒度）はユーザの設定次第である。例えば、“果物”をさらに産地別に分類してもよいし、“油脂類”をさらに動物性及び植物性に分類してもよい。

（処理手順）
図１３に沿って、処理手順を説明する。
ステップＳ２０１において、食材提案装置１の症状受付処理部２１は、問診を実行する。具体的には、第１に、症状受付処理部２１は、問診画面５１（図２）を端末装置２の出力装置１６に表示する。このとき、症状受付処理部２１は、症状・栄養素情報３３の質問期間欄を参照し、前回に症状の有無を問う質問文を表示した後、現時点までに質問周期の日数が経過していない質問文を表示しないものとする。または、前回の回答の“はい”ボタン又は“いいえ”ボタンのいずれかをデフォルト表示するものとする。

第２に、症状受付処理部２１は、ユーザが問診欄５２ａ等のそれぞれに対して“はい”ボタン又は“いいえ”ボタンのいずれかを押下し、その後“登録”ボタン５６を押下するのを受け付ける。症状受付処理部２１は、このとき、端末装置２から、ユーザ名、ユーザＩＤ及び“登録”ボタン５６が押下された時点も受け付ける。
第３に、症状受付処理部２１は、ステップＳ２０１の“第２”において受け付けたデータに基づいて、症状受付情報３１（図６）の新たなレコードを作成し、記憶する。このとき記憶されるレコードの数は、問診欄の数（質問文の数）に等しい。

ステップＳ２０２において、食材提案装置１の必要栄養素決定部２２は、症状行ベクトルを取得する。具体的には、第１に、必要栄養素決定部２２は、ステップＳ２０１の“第３”において記憶された症状受付情報３１のレコードのうち、回答欄１０６の回答が“はい”であるレコードの症状ＩＤを取得する。
第２に、必要栄養素決定部２２は、ステップＳ２０２の“第１”において取得した症状ＩＤを検索キーとして、症状・栄養素情報３３（図９）を検索し、該当するベクトル“Ｓ_{ｉ，ａｌｌ}”をすべて取得する。このとき、取得されるベクトルを“症状行ベクトル”と呼ぶ。症状行ベクトルの数は、ユーザが押下した“はい”ボタンの数に等しい。

ステップＳ２０３において、必要栄養素決定部２２は、加算症状行ベクトルを取得する。具体的には、必要栄養素決定部２２は、ステップＳ２０２の“第２”において取得したすべての症状行ベクトルの各成分同士を合計し、合計結果を加算症状行ベクトルとする。
いま加算症状行ベクトルを“ΣＳ_{ｉ，ａｌｌ}”と表すと、以下の式１が成立している。
ΣＳ_{ｉ，ａｌｌ}＝αＳ_{ｉ，ａｌｌ}＋βＳ_{ｉ，ａｌｌ}＋γＳ_{ｉ，ａｌｌ}＋・・・ （式１）
ここで、式１の右辺の各項における添え字“ｉ”は、“はい”ボタンが押下された症状に対応している。例えばユーザが“はい”ボタンを押下した症状は、“キメが乱れている”（症状ＩＤはｉ０１）、“毛穴が目立つ” （症状ＩＤはｉ０３）及び“便秘である” （症状ＩＤはｉ０７）の３つであるとする。この場合、式１の右辺は、“αＳ_{１，ａｌｌ}＋βＳ_{３，ａｌｌ}＋γＳ_{７，ａｌｌ}”となる。α、β、γ、・・・は、症状ごとにユーザが予め設定する重みであり正の値を取り得る。以降の説明では、単純化のため、α＝β＝γ＝・・・＝１であるとして説明を続ける。しかしながら、例えば“キメが乱れている”ことを重視したいユーザは、Ｓ_{１，ａｌｌ}に乗算される重みを“２”に、他の重みを“１”に設定することもできる。

ステップＳ２０４において、食材提案装置１の食材候補決定部２３は、食材行ベクトルを取得する。具体的には、食材候補決定部２３は、食材・栄養素情報３４（図１１）の未処理の任意の１つのレコードの、食材群、嗜好係数、旬係数、及び、ベクトル“Ｆ_{ｋ，ａｌｌ}”を取得する。このとき取得されたベクトルを“食材行ベクトル”と呼ぶ。

ステップＳ２０５において、食材候補決定部２３は、ベクトルの内積を算出する。具体的には、食材候補決定部２３は、ステップＳ２０３において取得した加算症状行ベクトルと、ステップＳ２０４において取得した食材行ベクトルとの内積を算出する。内積とは、２つのベクトルの成分同士の積を合計したスカラ値である。

ステップＳ２０６において、食材候補決定部２３は、スコアを算出する。具体的には、食材候補決定部２３は、ステップＳ２０５において算出した内積に対し、ステップＳ２０４において取得した嗜好係数を乗算する。さらに、その乗算結果に対しステップＳ２０４において取得した旬係数を乗算し、スコアとする。

食材候補決定部２３は、ステップＳ２０４〜Ｓ２０６の処理を、食材・栄養素情報３４（図１１）のすべてのレコードについて繰り返す。当該繰り返し処理において、食材候補決定部２３は、食材ごとにスコアを算出することになる。繰り返し処理が終了した段階で食材候補決定部２３が保持しているデータの例は、以下の通りである。
（食材，スコア）＝（さつまいも，５），（さといも，４），（ゆであずき，６），（みかん，２），（レモン，１），（柿，３），（牛肩ロース肉，３），（牛もも肉，２），（豚肩ロース肉，４）
当該データを“食材スコアデータ”と呼ぶ。

ステップＳ２０７において、食材候補決定部２３は、食材を分類する。具体的には、食材候補決定部２３は、ステップＳ２０４において取得した食材群に基づいて、食材スコアデータを食材群ごとに分類する。この分類が終了した段階で、食材スコアデータは以下のようになっている。
（食材，スコア）_１＝（さつまいも，５），（さといも，４），（ゆであずき，６）
（食材，スコア）_２＝（みかん，２），（レモン，１），（柿，３）
（食材，スコア）_３＝（牛肩ロース肉，３），（牛もも肉，２），（豚肩ロース肉，４）
ここで添え字の“１”、“２”及び“３”は、食材群ＩＤである。図１２では食材群ＩＤは、７つ存在する。しかしながら、ここでは簡単化のため、食材群ＩＤは３つ存在するものとする。

ステップＳ２０８において、食材候補決定部２３は、スコアの大きい順に食材を並び替える。この並び替えが終了した段階で、食材スコアデータは以下のようになっている。
（食材，スコア）_１＝（ゆであずき，６），（さつまいも，５），（さといも，４）
（食材，スコア）_２＝（柿，３），（みかん，２），（レモン，１）
（食材，スコア）_３＝（豚肩ロース肉，４），（牛肩ロース肉，３），（牛もも肉，２）

ステップＳ２０９において、食材候補決定部２３は、表示するべき食材を決定する。具体的には、第１に、食材候補決定部２３は、食材群別候補数を取得する。食材群別候補数とは、（食材群ＩＤ，候補数）＝（１，２），（２，２），（３，２）のようなデータである。食材候補決定部２３は、ユーザが自身に対して提示される食材の候補の数を食材群ごとに予め設定するのを受け付け、そのデータを食材群別候補数として補助記憶装置１３に記憶しておく。前記の候補数の例では、ユーザは、食材群“１”、食材群“２”及び食材群“３”のそれぞれから、２つずつ食材の候補を提案されることを望んでいることがわかる。

第２に、食材候補決定部２３は、ステップＳ２０９の“第１”において取得した食材群別候補数に基づいて、スコアの大きい順に、候補数に等しい食材の候補を特定する。この特定が終了した段階で、食材スコアデータは以下のようになっている。
（食材，スコア）_１＝（ゆであずき，６），（さつまいも，５）
（食材，スコア）_２＝（柿，３），（みかん，２）
（食材，スコア）_３＝（豚肩ロース肉，４），（牛肩ロース肉，３）

ステップＳ２１０において、食材提案装置１の食材候補表示処理部２４は、食材を表示する。具体的には、第１に、食材候補表示処理部２４は、食材提案画面６１（図３）を端末装置２の出力装置１６に表示する。より具体的には、食材アイコンとして、“ゆであずき”、“さつまいも”、“柿”、“みかん”、“豚肩ロース肉”及び“牛肩ロース肉”を表示する。食材候補表示処理部２４は、食材群ごとに、かつ、スコアの大きい順に食材アイコンを並べてもよい。

第２に、食材候補表示処理部２４は、ユーザが食材を確定選択するのを受け付ける。いま、ユーザは、前記の６つの食材アイコンのうち、“さつまいも”、“みかん”及び“牛肩ロース肉”を確定選択したとする。このとき、食材候補表示処理部２４は、端末装置２から、ユーザ名、ユーザＩＤ及び“確定”ボタン６４が押下された時点も受け付ける。
第３に、食材候補表示処理部２４は、ステップＳ２１０の“第２”において受け付けたデータに基づいて、食材提案情報３２（図７）の新たなレコードを作成し、記憶する。前記の例では、食材候補表示処理部２４は、新たなレコードの提案食材として、“（ゆであずき，６），〈さつまいも，５〉，（柿，３），〈みかん，２〉，（豚肩ロース肉，４），〈牛肩ロース肉，３〉”を記憶することになる。
その後、処理手順を終了する。

（変形例１：無作為な候補決定）
前記では、食材候補決定部２３は、スコアの大きいものから順に提案するべき食材の候補を決定している。しかしながら、このようなルールを厳密に適用すると、入力された症状に対し、常に同じ食材の組み合わせが提案されることになりがちである。そこで、食材候補決定部２３は、以下のパタン１又はパタン２の処理を実行してもよい。
（パタン１）
・食材群のそれぞれについて、所定の閾値以上のスコアを有する食材をｐ個取得する。
・ｐ個の食材のうちから、食材群別候補数ｑに等しい個数（但しｑ＜ｐ）の食材を無作為に取得する。
パタン１によれば、類似のスコアを有する食材のうち、１つだけが常に候補として取得されることを回避できる。

（パタン２）
・食材群のそれぞれから、それぞれの食材群別候補数に等しい個数の食材を無作為に抽出し、異種の食材群の候補からなる食材候補の集合を作成する。集合は、複数取得されることになる。
・集合に含まれる食材のスコアを合計し、その合計スコアの最も大きい集合を提案するべき食材の候補とする。
パタン２によれば、スコアが小さい食材であっても、他のスコアが大きい食材の助けを借りて、候補となることができる。

ユーザは、食材提案画面６１（図３）を視認し、“好きな食材が少ない”、“同じような食材ばかり表示される”等の印象を持ったとする。このとき、食材候補決定部２３は、ユーザが“お勧め変更”ボタン６６を押下するのを受け付け、パタン１又はパタン２を実行する。そして、食材候補表示処理部２４は、その結果決定された食材の食材アイコンを表示する。よって、食材アイコンの一部が入れ替わり、ユーザの飽きを予防できる。

（変形例２：確率に基づく候補決定）
仮にスコアが小さくても、その食材が表示される候補となる可能性を高める方策として、食材候補決定部２３は、以下のパタン３の処理を実行してもよい。
（パタン３）
・スコアに対して、スコアの値よりも有意に大きい所定の正の値を加算し、補正後スコアとする。例えば、さつまいものスコアが“２”であった場合、その“２”に“１００”を加算し、“１０２”を補正後スコアとする。
・その食材の補正後スコアがすべての食材の補正後スコアの合計に占める比率に比例する確率で、表示するべき食材の候補を決定する。

いま、さといものスコアが“６”であり、さつまいものスコアが“２”であるとする。さつまいもは、自身のスコア“２”では、さといもに対抗しにくい（６−２＝４のスコアの差異がある）。パタン３によれば、さといもの補正後スコア“１０６”に対し、さつまいもの補正後スコアは“１０２”となる。さらに、すべての食材の補正後スコアの合計が“６２０”であったとする。すると、さといも及びさつまいもは、それぞれ“０.１７１＝１０６／６２０”及び“０.１６５＝１０２／６２０”の確率で食材の候補となり得る。選択される確率の差異は、０.１７１−０.１６５＝０.００６となり、さつまいもは、より候補となりやすくなる。

（変形例３：気になる症状なし）
改善するべき症状が客観的には存在していても、ユーザがそのことに気付いていない場合も多い。このとき、ユーザは、“気になる症状がないということですか？”と言う質問文に対して“はい”で回答することになる。しかしながら、このようなユーザに対しても、何らかの食材候補をなんらかの根拠で提案することが、隠れた症状を改善するためには必要である。そこで、図９の“ｉ１０”の行のベクトル“Ｓ_{１０，ａｌｌ}”の各成分をどのように決めるかが問題になる。そこで、必要栄養素決定部２２は、以下のパタン４の処理を実行してもよい。

（パタン４）
・図９において、すべての栄養素の列のベクトル“Ｓ_{ａｌｌ，ｋ}”（但し、“ａｌｌ”は、“１０”を含まない）の成分を合計する。
・合計値の大きい順に所定の数（例えば“５”）の栄養素を特定する。
・特定された栄養素に対応する有効度を“１”とする行のベクトル“Ｓ_{１０，ａｌｌ}”を作成する。ベクトル“Ｓ_{１０，ａｌｌ}”が有する１２個の成分のうち、５個は“１”となる。

（変形例４：“わからない”）
ユーザは、質問文に対して、“はい”又は“いいえ”のいずれかを常に容易に判断できるとは限らない。そこで、症状受付処理部２１は、問診画面５１において、追加的に“わからない”ボタンを各問診欄５２ａ等に表示してもよい。そして、必要栄養素決定部２２は、“わからない”を“はい”と同じであると看做して、症状行ベクトルを取得する。しかしながら、“わからない”の場合、必要栄養素決定部２２は、症状行ベクトルの各成分にｔ（０＜ｔ＜１）を乗算する。ユーザは、自身が他人よりも慎重な性格であると信じている場合、ｔを大きい値に設定し、そうでない場合は、ｔを小さい値に設定する。

（変形例５：“完了”後のポイント付与等）
ユーザが候補として表示された食材のすべてを確定選択することを、“完了する”と言う。なお、ユーザが完了すると、食材提案情報３２（図７）の選択数を提案数で除算した比率（達成率）が１００％になる。食材候補表示処理部２４は、常時達成率を監視し、ユーザが完了したことを検知した時点で以下の処理のうちのいずれかを実行してもよい。
・ユーザに対してポイントを与える。ここでのポイントは、例えば確定選択された食材の生産者（販売者）が発行する電子マネーであってもよい。
・特定の食材群に含まれる食材を次回以降、表示するべき食材の候補に加える。この食材群は、例えば、特に他の食材の摂取に影響を与えないお菓子のような“ご褒美”的な食材を専ら含んでいてもよい。

（変形例６：達成率推移画面）
達成率が１００％にならなくても１００％に徐々に近づいていることが可視化されると、ユーザは完了に向けての動機を維持しやすくなる。そこで、食材候補表示処理部２４は、任意のタイミングで以下の処理を実行してもよい。
・食材提案情報３２（図７）の送信時点、提案食材、提案数及び選択数、及び、食材・栄養素情報３４（図１１）の食材群に基づき、ユーザの達成率を、時系列かつ食材群ごとに算出する。
・算出した達成率の推移を、達成率推移画面７１（図４）として端末装置２の出力装置１６に表示する。

（変形例７：会話画面）
ユーザが質問文のそれぞれに対して丁寧に回答する時間を有さない場合も多い。また、複数の質問文に対して一通り回答した直後に、追加的に“はい”となるような症状を思いつくことも多い。メインの問診画面５１（図２）に対して補助的又は省力的に使用できる画面があれば便利である。そこで、症状受付処理部２１等は、以下の処理を実行してもよい。

・症状受付処理部２１は、ユーザが端末装置２の入力装置１５に対して任意のタイミングで所定の指示（“会話”ボタン（図示せず）の押下等）を入力するのを受け付ける。
・症状受付処理部２１は、端末装置２の出力装置１６に、会話画面８１（図５）を表示する。会話画面８１には、吹き出し“今気になることはありますか？”８２が表示されている。
・症状受付処理部２１は、ユーザが任意の方法で症状を入力するのを受け付ける。ここで、ユーザは、症状受付処理部２１が表示する症状の選択肢のなかから１又は複数の症状を選択してもよいし、症状をテキスト入力してもよいし、音声入力してもよい。症状受付処理部２１は、入力結果を、例えば、吹き出し“疲労感があります”８３として表示する。

・必要栄養素決定部２２は、前記した処理に準じて、症状行ベクトルを取得する。
・食材候補決定部２３は、前記した処理に準じて、表示するべき食材を決定する。ただし、ユーザは落ち着いて画面を視認できない状況にある場合が多い。よって、表示するべき食材の数は極力少ない方がよい（１つであってもよい）。
・食材候補表示処理部２４は、例えば、吹き出し“食材としてレモンをお勧めします”８４として、食材を表示する。

・食材候補表示処理部２４が食材提案画面６１（図３）を表示した後所定の時間が経過していない場合は、食材候補表示処理部２４は、注意メッセージ“お勧め食材にレモンを追加しました”８５を表示する。なお、ユーザが“お勧め食材を見る”ボタン８６を押下すると、食材候補表示処理部２４は、画面を食材提案画面６１（図３）に遷移する。遷移先の食材提案画面６１においては、食材アイコン“レモン”が、直前に表示された食材アイコンとともに表示されている（図３には図示せず）。

（変形例８：有効度の学習）
前記したように、症状・栄養素情報３３（図９）は、ユーザの（又はユーザの集団の）体質そのものを示しており、その有効度（Ｓ_ｉ，ｊ）は、適宜更新され、適切な食材の提供を担保しなければならない。そこで、必要栄養素決定部２２は、所定の周期ごとに（例えば、月末ごとに）バッチ処理等で以下の処理を実行する。

・必要栄養素決定部２２は、症状受付情報３１（図６）及び食材提案情報３２（図７）から、ある集団に属するすべてのユーザについての、直近の例えば１カ月間のデータを集計する。補助記憶装置１３は、ユーザＩＤに関連付けて、ユーザの住所、年齢、性別、勤務先名、業務内容（営業、内勤等）等を記憶したユーザ属性情報（図示せず）を記憶しているものとする。よって、必要栄養素決定部２２は、たとえば、Ａ社の女性営業職についてのデータを抽出できる。

・必要栄養素決定部２２は、集団に属する個々のユーザごとに、ある症状の改善度及びある食材の選択回数を算出する。ある症状の改善度とは、例えば、その症状についての“いいえ”の回数を、その症状についての“はい”の回数と“いいえ”の回数との和で除算した値であり、この値が大きいほど、健康状態はよい。
・必要栄養素決定部２２は、症状の改善度を横軸とし、食材の選択回数を縦軸とする座標平面（図１４（ａ）参照）に、ユーザを示す図形をプロットする。プロットされた図形の数は、例えば、Ａ社の女性営業職の数に一致する。そして、症状の改善度と食材の選択回数の相関係数ｒを算出する。周知のように、相関係数ｒは、“−１≦ｒ≦１”の範囲の値を取る。

・必要栄養素決定部２２は、このような処理を、すべての症状と食材との組み合わせについて繰り返す。すると、その組み合わせごとに相関係数が取得されることになる。
・相関係数ｒが所定の範囲（例えば０.８≦ｒ）にある症状及び食材の組み合わせを特定する。例えば、“キメが乱れている”及び“うなぎ”の組み合わせが特定されたとする。
・必要栄養素決定部２２は、食材・栄養素情報３４（図１１）の“うなぎ”の行のベクトル“Ｆ_１２，ｊ”を取得する。なお、うなぎの食材ＩＤは、“ｉ１２”である。

・必要栄養素決定部２２は、ベクトル“Ｆ_１２，ｊ”が示す含有量が“０”ではない栄養素を特定する。例えばここでは、栄養素“亜鉛”及び“ビタミンＥ”が特定されたとする。
・必要栄養素決定部２２は、症状・栄養素情報３３（図９）において、有効度“Ｓ_１，５ ”及び“Ｓ_１，７”の値をより大きな値で更新する。例えば、既存の値“１”に“１.５”を乗算した値で既存の値を更新する。なお、症状“キメが乱れている”の症状ＩＤは“ｉ０１”であり、栄養素“亜鉛”の栄養素ＩＤは“ｊ０５”であり、栄養素“ビタミンＥ”の栄養素ＩＤは“ｊ０７”である。

より一般的には、相関係数ｒに適用される第１の閾値をｒ_ｓ１とし、第２の閾値をｒ_ｓ２とする（−１＜ｒ_ｓ１＜０＜ｒ_ｓ２＜１）。有効度Ｓ_ｉ，ｊが“０”及び正負の数を取り得るとする。この前提で、相関係数ｒの値と、有効度Ｓ_ｉ，ｊの更新の仕方との対応関係は、以下の通りである。
・−１≦ｒ＜ｒ_ｓ１である場合、有効度Ｓ_ｉ，ｊを小さくする。
・ｒ_ｓ１≦ｒ＜ｒ_ｓ２である場合、有効度Ｓ_ｉ，ｊの更新は行なわない。
・ｒ_ｓ２≦ｒ≦１である場合、有効度Ｓ_ｉ，ｊを大きくする。

必要栄養素決定部２２は、特定のユーザについて同様の処理を実行してもよい（図１４（ｂ）参照）。図１４（ａ）の処理と図１４（ｂ）の処理を併せて実行した結果、Ａさんの属する集団における相関係数と、Ａさん個人の相関係数との差異が所定の閾値を超過することがある。この場合、必要栄養素決定部２２は、警告メッセージを出力する。警告メッセージは、Ａさんの端末装置２向けには、例えば“Ａさんの体質は周囲の方とやや異なります。専門家のアドバイスを受けることをお勧めします”である。職場の管理者の通信機器向けには、“Ａさんの体質は周囲の方とやや異なります。日常の健康管理について特にアドバイスしてあげてください”である。

（実施形態の効果）
本実施形態は、以下の効果を奏する。
（１）自身の方法及びタイミングで食材を調理し摂取しようとするユーザは、症状の改善のために真に必要な食材を、適当な数の候補として知ることができる。特に、候補の数については、症状の入力数が少なくても充分な数の候補を知り、逆に症状の入力数が多くても、複数の症状の改善に同時に寄与する少数の候補を知ることができる。
（２）ユーザは、食材に対する嗜好を反映したうえで、必要な食材を知ることができる。さらに、提案された食材及びそのうち自身が選択した食材を適宜に記録することができる。
（３）ユーザは、特定の食材群に偏ることなく、必要な食材を知ることができる。

（４）ユーザは、理解しやすい質問文に対して回答する型式で自身の症状を入力することができ、必要な食材及び自身が選択した食材を容易に視認できる。
（５）ユーザは、自身の体質に有効な栄養素を見直すことができる。
（６）ユーザは、回答が同じになる質問文に対し、繰り返し回答する必要がなくなる。
（７）ユーザは、ベクトルを使用した数量的演算により、高い確度で必要な食材を知ることができる。

なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、前記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウエアで実現してもよい。また、前記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウエアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際には殆どすべての構成が相互に接続されていると考えてもよい。

１ 食材提案装置
２ 端末装置
３ ネットワーク
４ 外部システム
１１ 中央制御装置
１２ 主記憶装置（記憶部）
１３ 補助記憶装置（記憶部）
１４ 通信装置
１５ 入力装置
１６ 出力装置
２１ 症状受付処理部
２２ 必要栄養素決定部
２３ 食材候補決定部
２４ 食材候補表示処理部
３１ 症状受付情報
３２ 食材提案情報
３３ 症状・栄養素情報
３４ 食材・栄養素情報
５１ 問診画面
６１ 食材提案画面
７１ 達成率推移画面
８１ 会話画面

Claims (8)

1. 症状と栄養素との組み合わせごとに、前記症状の改善に対する前記栄養素の有効度が記憶される症状・栄養素情報と、
   食材と前記栄養素との組み合わせごとに、前記食材に含まれる前記栄養素の含有量が記憶される食材・栄養素情報と、
   が格納される記憶部と、
   ユーザが複数の前記症状を入力するのを受け付ける症状受付処理部と、
   前記受け付けた複数の症状に基づいて、前記症状・栄養素情報を検索し、
   前記受け付けた複数の症状の改善に対する前記有効度を前記栄養素ごとに取得する必要栄養素決定部と、
   前記取得した有効度と、前記食材・栄養素情報に記憶される前記食材ごとの前記含有量とに基づいて、前記食材ごとにスコアを算出し、
   前記算出したスコアの大小関係に基づき、予め設定された任意の数だけ前記ユーザに対して提案する前記食材を決定する食材候補決定部と、
   前記決定した食材を表示する食材候補表示処理部と、
   を有し、
   前記食材・栄養素情報は、
   前記食材に関連付けて、嗜好係数を記憶しており、
   前記食材候補表示処理部は、
   前記表示した食材を前記ユーザが選択するのを受け付け、
   前記食材候補決定部は、
   前記嗜好係数に基づいて前記スコアを算出し、
   前記表示した食材と前記選択を受け付けた食材との比率に基づき、前記嗜好係数を更新すること、
   を特徴とする食材提案装置。
2. 前記食材・栄養素情報は、
   前記食材に関連付けて、前記食材が属する食材群を記憶しており、
   前記食材候補決定部は、
   前記食材群のそれぞれから、前記ユーザに対して提案する前記食材を決定すること、
   を特徴とする請求項１に記載の食材提案装置。
3. 前記症状受付処理部は、
   前記ユーザが操作する端末装置に前記症状の有無を問う質問文を表示し、
   前記食材候補表示処理部は、
   前記端末装置に前記決定した食材をアイコンとして表示し、
   前記選択を受け付けた食材のアイコンを、それ以外のアイコンから区別される態様で表示すること、
   を特徴とする請求項２に記載の食材提案装置。
4. 前記必要栄養素決定部は、
   前記症状の改善度と前記食材が選択される回数と、に基づき、前記有効度を更新すること、
   を特徴とする請求項３に記載の食材提案装置。
5. 前記症状・栄養素情報は、
   前記症状に関連付けて、質問周期を記憶しており、
   前記症状受付処理部は、
   前記質問周期に基づいて、前記症状の有無を問う質問文を表示すること、
   を特徴とする請求項４に記載の食材提案装置。
6. 前記症状・栄養素情報は、
   複数の前記栄養素の前記有効度を成分に有する第１のベクトルが前記症状ごとに記憶されたものであり、
   前記食材・栄養素情報は、
   複数の前記栄養素の前記含有量を成分に有する第２のベクトルが前記食材ごとに記憶されたものであり、
   前記食材候補決定部は、
   前記第１のベクトルと前記第２のベクトルとの内積を算出することによって、前記スコアを算出すること、
   を特徴とする請求項１に記載の食材提案装置。
7. 食材提案装置の記憶部は、
   症状と栄養素との組み合わせごとに、前記症状の改善に対する前記栄養素の有効度が記憶される症状・栄養素情報と、
   食材と前記栄養素との組み合わせごとに、前記食材に含まれる前記栄養素の含有量が記憶される食材・栄養素情報と、
   を格納しており、
   前記食材提案装置の症状受付処理部は、
   ユーザが複数の前記症状を入力するのを受け付け、
   前記食材提案装置の必要栄養素決定部は、
   前記受け付けた複数の症状に基づいて、前記症状・栄養素情報を検索し、
   前記受け付けた複数の症状の改善に対する前記有効度を前記栄養素ごとに取得し、
   前記食材提案装置の食材候補決定部は、
   前記取得した有効度と、前記食材・栄養素情報に記憶される前記食材ごとの前記含有量とに基づいて、前記食材ごとにスコアを算出し、
   前記算出したスコアの大小関係に基づき、予め設定された任意の数だけ前記ユーザに対して提案する前記食材を決定し、
   前記食材提案装置の食材候補表示処理部は、
   前記決定した食材を表示装置に表示し、
   前記食材・栄養素情報は、
   前記食材に関連付けて、嗜好係数を記憶しており、
   前記食材候補表示処理部は、
   前記表示した食材を前記ユーザが選択するのを受け付け、
   前記食材候補決定部は、
   前記嗜好係数に基づいて前記スコアを算出し、
   前記表示した食材と前記選択を受け付けた食材との比率に基づき、前記嗜好係数を更新すること、
   を特徴とする前記食材提案装置の食材提案方法。
8. 食材提案装置の記憶部に対し、
   症状と栄養素との組み合わせごとに、前記症状の改善に対する前記栄養素の有効度が記憶される症状・栄養素情報と、
   食材と前記栄養素との組み合わせごとに、前記食材に含まれる前記栄養素の含有量が記憶される食材・栄養素情報と、
   を格納させ、
   前記食材提案装置の症状受付処理部に対し、
   ユーザが複数の前記症状を入力するのを受け付ける処理を実行させ、
   前記食材提案装置の必要栄養素決定部に対し、
   前記受け付けた複数の症状に基づいて、前記症状・栄養素情報を検索し、
   前記受け付けた複数の症状の改善に対する前記有効度を前記栄養素ごとに取得する処理を実行させ、
   前記食材提案装置の食材候補決定部に対し、
   前記取得した有効度と、前記食材・栄養素情報に記憶される前記食材ごとの前記含有量とに基づいて、前記食材ごとにスコアを算出し、
   前記算出したスコアの大小関係に基づき、予め設定された任意の数だけ前記ユーザに対して提案する前記食材を決定する処理を実行させ、
   前記食材提案装置の食材候補表示処理部に対し、
   前記決定した食材を表示する処理を実行させ、
   前記記憶部に対し、
   前記食材に関連付けて、嗜好係数が記憶される前記食材・栄養素情報を格納させ、
   前記食材候補表示処理部に対し、
   前記表示した食材を前記ユーザが選択するのを受け付ける処理を実行させ、
   前記食材候補決定部に対し、
   前記嗜好係数に基づいて前記スコアを算出し、
   前記表示した食材と前記選択を受け付けた食材との比率に基づき、前記嗜好係数を更新する処理を実行させること、
   を特徴とする前記食材提案装置を機能させるための食材提案プログラム。
   

Images