JP7433833B2 - 献立提供システム - Google Patents

Description

本発明は、献立提供システムおよびコンピュータプログラムに関する。

ユーザの健康に関する要望、嗜好、目的に合致した献立を在庫食材の中から選択し安全にユーザに配送することを管理するシステムは知られている（特許文献１）。

また、日々発信される特売情報やレシピ情報を加工し格納し、これら情報と個人情報、店舗情報とを段階的につき合わせることで、サービス利用者に最適な献立とレシピを煩わしい作業をすることなく提供するシステムも知られている（特許文献２）。

さらに、ユーザの購入した食材のうち保存期限の近い食材を優先して使用するようにユーザに通知するシステムも知られている（特許文献３）。

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

特許文献１では、ユーザの嗜好および目的などの情報に基づいて、ユーザに最適な献立を演算し、その最適な献立を調理するための食材を用意してユーザへ送る。しかし、特許文献１では、ユーザが購入済の食材またはこれから購入予定の食材に基づいて、ユーザへ献立を提案するものではなく、そのユーザに最適な献立を実現するための食材を提供するものである。

特許文献２では、特売情報を利用した献立をユーザへ提案するものであり、特許文献１について述べたと同様に、ユーザの手持ちの食材または購入予定の食材に適した献立を提案するものではない。

特許文献３では、ユーザの保存している食材の保存形態（冷凍状態かなど）および保存期限を考慮した料理をユーザへ提案する。しかし、特許文献３では、レシートの記載内容を解析して食材の種類と量を特定し、消費したはずの量を自動的に減算するため、現在の食材の量および状態と整合しない可能性がある。

従来技術では、ユーザの手持ちの食材またはこれから購入予定の食材をコンピュータシステムへ登録するのに、レシートを印刷したり、あるいはキーワードを入力したりする必要があり、ユーザの手間がかかり、ユーザにとって使い勝手が低い。

また、従来技術では、食材の購入時の状態はコンピュータシステムにより把握できるが、その後の食材の状態の変化を把握することができない。ユーザは、例えば、大根１本、キャベツ１玉、人参１本などの通常状態の食材を一回の調理で使い切ることは少なく、必要な量だけ消費する。さらに、例えば、人参を乱切りにして保存するなどのように、食材を通常状態とは異なる形状で保存することもある。従来技術では、このような食材の状態変化に追従することができない。したがって、従来技術では、例えば、千切りのキャベツが大量に残っている場合に、コンピュータシステムがロールキャベツを提案することも考えられるが、千切り状態のキャベツではロールキャベツを調理することはできず、ユーザにとっての利便性が低い。

さらに、友人知人、親戚などから野菜、米、魚などの食材を譲られることがあるが、これらにレシートは付随しないため、友人知人等から譲られた食材をコンピュータシステムへ登録することができず、有効に利用することができない。仮に、ユーザがキーボードから食材の種類および量をコンピュータシステムへ登録する場合、ユーザの手間がかかり、やはりユーザにとっての使い勝手が低い。

本発明は、上記問題に鑑みてなされたもので、その目的は、ユーザにとっての使い勝手を向上できるようにした献立提供システムおよびコンピュータプログラムを提供することにある。

上記課題を解決すべく、本発明の一つの観点に従う献立提供システムは、取得された食材の画像を解析することにより、食材の種類、量および状態を判定する食材画像判定部と、食材画像判定部の判定結果に基づいて、前記食材を用いて調理可能な献立候補を検索する献立候補検索部と、を備え、検索された献立候補をユーザへ提供する。

本発明によれば、食材の画像からその食材の種類、量および状態を判定し、この判定された食材を用いて調理可能な献立候補を検索し、ユーザへ提案することができる。

献立提供システムの全体構成図。 食材画像の判定結果を示す説明図。 ユーザ情報を示す説明図。 食事履歴情報を示す説明図。 栄養情報を示す説明図。 常備品情報を示す説明図。 レシピ応答情報を示す説明図。 食材画像を判定する処理を示すフローチャート。 献立提案処理を示すフローチャート。 ユーザへ提案する画面の説明図。 献立提供システムの構成例を示す図。 献立提供システムの他の構成例を示す図。 献立提供システムのさらに別の構成例を示す図。 第２実施例に係り、食材画像の判定処理を示すフローチャート。

以下、図面に基づいて、本発明の実施の形態を説明する。本実施形態に係る献立提供システムは、食材の画像に基づいて、その食材の種類、量および状態を判定し、その判定された食材を用いて調理可能な献立（献立の候補）を提案する。ユーザは、献立提供システムへ食材の画像を送るだけでよく、文字または音声で食材の種類などをシステムへ登録する必要がなく、ユーザにとっての使い勝手が向上する。

本実施形態では、食材の種類と量だけでなく、その状態（例えば、通常状態の食材との形状の差異）をも判別して考慮するため、食材の状態に適した献立を検索してユーザへ提案することができる。

さらに本実施形態では、判定された食材を用いて調理可能な、所定の料理ジャンルに属する複数の料理を含む献立をユーザへ提案することができる。すなわち、和食、洋食、中華料理といった共通の料理ジャンルに属する、まとまりのある食事をユーザへ提案することができる。

さらに本実施形態では、判定された食材の栄養情報（どのような栄養素がどれだけ含まれているかなどの情報）とユーザの食事履歴情報も考慮して、ユーザに適した献立を提案することができる。

図１～図１３を用いて第１実施例を説明する。図１は、献立提供システムの全体構成図である。献立提供システムは、例えば、献立提案部１０と、ユーザ端末２０と、レシピ管理部３０とを含む。

献立提案部１０は、ユーザから入力された食材画像を判定することにより、その食材を利用して調理可能な献立をレシピ管理部３０から取得し、取得された献立をユーザへ提案する。献立提案部１０は、例えば、献立候補検索部１１と、食材画像判定部１２と、栄養評価部１３と、ユーザ情報管理部１４と、栄養情報取得部１５と、情報提供部１６とを備える。

献立提案部１０は、食材画像の判定結果と栄養評価部１３の評価とユーザ情報管理部１４からの情報とに基づいて、判定された食材から調理可能な料理を複数含む献立を提案する機能である。

献立提案部１０は、例えば、主菜候補を抽出する主菜候補抽出部１１１と、副菜候補を抽出する副菜候補抽出部１１２と、汁物候補を抽出する汁物候補抽出部１１３を含むことができる。少なくとも主菜候補と副菜候補とは、共通の料理ジャンルに属する。

食材画像判定部１２は、入力された食材画像から機械学習により、その食材の種類と量および状態を判定する。食材画像の判定結果の情報については、図２で後述する。

栄養評価部１３は、栄養情報取得部１５から取得される栄養情報に基づいて、食材および献立の栄養を評価する。栄養評価部１３は、食材画像の判定結果に基づいて、各食材がどのような栄養素をどれだけ有するか評価する。また、栄養評価部１３は、判定された食材から調理可能な料理の持つ栄養素も評価する。さらに、栄養評価部１３は、ユーザ情報管理部１４から取得されるユーザの食事履歴情報に基づいて、直近の所定期間にユーザが摂った食事の栄養を評価する。

ユーザ情報管理部１４は、ユーザ情報およびユーザの食事履歴を管理する。ユーザ情報の詳細は、図３で後述する。食事履歴情報の詳細は、図４で後述する。

栄養情報取得部１５は、食材の栄養素の情報を栄養評価部１３へ供給する。栄養情報取得部１５は、例えば食品成分表などに記載されている情報をあらかじめ記憶しておくこともできるし、あるいは、図示せぬ外部の情報提供装置から食材の栄養情報を必要に応じて取得してもよい。

情報提供部１６は、献立候補検索部１１により検索された献立候補の情報をユーザ端末２０へ提供する。情報提供部１６は、ユーザ端末２０からの指示または情報を受信し、献立候補検索部１１に引き渡すこともできる。献立候補検索部１１は、例えば、ユーザ端末２０から指定された食材を中心とする主菜を含む献立候補を検索することができる。

ユーザ端末２０は、献立提供システムを利用するユーザにより使用される。ユーザ端末２０は、例えば、デスクトップ型またはノートブック型のパーソナルコンピュータ、タブレット端末、スマートフォン、携帯情報端末などのように構成される。ＶＲ（Virtual Reality）またはＡＲ（Augmented Reality）などに使用されるゴーグル型端末をユーザ端末２０として用いてもよい。

ユーザ端末２０は、例えば、食材画像取得部２１と、常備品情報取得部２２と、ユーザインターフェース部２３とを備える。図中では、ユーザインターフェースをＵＩと略記している。

食材画像取得部２１は、調理素材としての食材の画像を取得して、献立提案部１０の食材画像判定部１２へ送信する。食材画像取得部２１は、例えば、図示せぬカメラによって食材を撮影してもよいし、あるいは、図示せぬメモリに格納された食材画像ファイルを読み出してもよい。食材画像取得部２１は、複数の食材を含む一つの画像を取得して食材画像判定部１２へ送信することもできるし、あるいは、一つの食材の画像を取得して食材画像判定部１２へ送信することもできる。

常備品情報取得部２２は、ユーザの使用可能な常備品の情報を取得する。常備品とは、食材の調理に使用する物品であって、ユーザがほぼ常に使用可能な物品である。常備品としては、例えば、塩、胡椒、醤油、味噌、酢、七味、バター、食用油、マヨネーズ、カレールー、シチュールーなどの調味料、米または缶詰などの食品をあげることができる。なにが常備されているかは、通常、ユーザ毎に異なる。

ユーザインターフェース部２３は、献立提案部１０とユーザ端末２０との間で情報を交換する。すなわち、ユーザインターフェース部２３は、献立提案部１０からの情報をユーザへ提示したり、あるいは、ユーザからの指示および情報を献立提案部１０へ入力したりする装置である。ユーザ端末２０とユーザインターフェース部２３とは物理的に別体に構成されて、無線通信などで接続されてもよい。

図２は、食材画像の判定結果を示す。一つの食材画像Ｉｍｇ１には、野菜、魚、肉といった複数の食材が含まれている。食材画像判定部１２は、機械学習の手法を用いることにより、食材画像Ｉｍｇ１に含まれる各食材の種類、量、状態を判定する。

図２の下側に、食材画像判定部１２による食材判定結果Ｔ１の例を示す。食材判定結果Ｔ１は、例えば、画像ＩＤ Ｃ１１と、食材ＩＤ Ｃ１２と、食材名Ｃ１３と、分量Ｃ１４と、第１状態Ｃ１５と、第２状態Ｃ１６とを管理する。

画像ＩＤ Ｃ１１は、食材画像Ｉｍｇ１を特定する識別子である。食材ＩＤ Ｃ１２は、食材画像Ｉｍｇ１に含まれる各食材を特定する識別子である。食材名Ｃ１３は、「食材の種類」に該当する。分量Ｃ１４は、「食材の量」に該当する。分量Ｃ１４は、全重量と可食部分の重量との２つを併記することもできる。第１状態Ｃ１５は、「食材の状態」に該当し、例えば食材の形状を示す。食材の形状には、その食材の通常状態での形状と、その食材の加工後の形状とが含まれる。第２状態Ｃ１６は、食材の鮮度を示す。例えば、食材が冷凍状態であるか否か、食材がラッピングされているか否かなどのように、第３の状態、第４の状態などをさらに管理することもできる。

図２では、一つの食材画像Ｉｍｇ１に含まれる複数の食材を判定する例を示すが、これに代えて、一つの食材画像に含まれる一つの食材を判定することもできる。例えば、ユーザが、スーパーマーケットなどで所望の食材を撮影しながら、店舗内を移動するような場合である。さらに、ユーザは、図示せぬ冷蔵庫内の食材を取り出して食卓に並べて全体を一つの食材画像として撮影し、次に、スーパーマーケットへ移動して、個別の食材の画像を一つ一つ撮影してもよい。このような実施例については、図１４で後述する。

図３は、ユーザ情報Ｔ２の例である。ユーザ情報Ｔ２は、ユーザについての情報を管理しており、例えば、ユーザＩＤ Ｃ２１と、氏名Ｃ２２と、生年月日Ｃ２３と、身長Ｃ２４と、体重Ｃ２５と、運動量Ｃ２６と、血圧Ｃ２７とを含むことができる。

ユーザ情報Ｔ２は、基本情報Ｃ２１～Ｃ２３と、健康状態管理情報Ｃ２４～Ｃ２７とに大別可能である。基本情報について説明する。ユーザＩＤ Ｃ２１は、献立提供システムのユーザを識別する識別子である。氏名Ｃ２２は、ユーザの氏名である。生年月日Ｃ２３は、ユーザの生年月日である。健康状態管理情報について説明する。本実施例では、ユーザの健康状態を管理するための情報として、例えば身長Ｃ２４、体重Ｃ２５、運動量Ｃ２６、血圧Ｃ２７を管理する。これらの各情報Ｃ２４～Ｃ２７の全てを常に管理する必要はなく、必要に応じて、あるいは、ユーザの希望に応じて管理可能とすればよい。なお、健康状態管理情報は上述の情報に限らず、例えば、心拍数、睡眠時間、体温、体脂肪率などを含めてもよい。

図４は、食事履歴情報Ｔ３の例である。食事履歴情報Ｔ３は、ユーザの食事の履歴を管理しており、例えば、ユーザＩＤ Ｃ３１と、日付Ｃ３２と、時刻Ｃ３３と、複数のレシピＩＤ Ｃ３４～Ｃ３７とを含む。

ユーザＩＤ Ｃ３１は、図３中のユーザＩＤ Ｃ２１と同様である。日付Ｃ３２は、食事をした日付である。時刻Ｃ３３は、食事をした時刻である。時刻Ｃ３３は、開始時刻でもよいし、終了時刻でもよい。献立提供システムからユーザ端末２０へ献立候補（レシピ群）を提供した時刻でもよい。あるいは、献立候補を提供した時刻に調理所要時間を加えた時刻でもよい。

レシピＩＤは、料理を識別する識別子である。複数のレシピＩＤ Ｃ３４～Ｃ３７は、一回の食事でユーザが摂った料理の内容を示している。朝食、昼食、おやつ、夕食、夜食などのように、食事のタイミングによって、料理の品数は異なる場合がある。すなわち、毎回の食事には、少なくとも一つの料理（レシピＩＤ）が含まれる。献立提供システムは、一つのレシピＩＤのみをユーザ端末２０へ送信したり、複数のレシピＩＤをユーザ端末２０へ送信したりする。

図５は、栄養情報Ｔ４の例を示す。栄養情報Ｔ４は、食材の栄養を管理する。栄養情報Ｔ４は、例えば、食材ＩＤ Ｃ４１と食材名Ｃ４２と基準単位Ｃ４３とを含む基本情報と、カロリーＣ４４と炭水化物Ｃ４５とタンパク質Ｃ４６と脂質Ｃ４７といった栄養素情報とを含む。栄養素情報は、基準単位の食材に含まれる栄養素の量である。栄養素情報には、図５に示すものに限らず、各種ビタミン、ミネラル、アミノ酸なども含まれる。

図６は、常備品情報Ｔ５の例である。常備品情報Ｔ５は、ユーザが調理に関して常備している物品を管理する情報である。常備品情報Ｔ５は、例えば、常備品ＩＤ Ｃ５１と常備品名と常備品の種別との基本情報と、カロリーＣ５４と塩分Ｃ５５とタンパク質Ｃ５６と脂質Ｃ５７といった成分情報とを含む。成分情報には、上述のカロリー等以外の情報を含むこともできる。

図７は、レシピ応答情報Ｔ６の例である。レシピ応答情報Ｔ６は、献立提案部１０からの要求に対して返信される。レシピ応答情報Ｔ６は、例えば、応答ＩＤ Ｃ６１と、料理名Ｃ６２と、食材Ｃ６３と、使用量Ｃ６４と、調理法Ｃ６５と、主菜Ｃ６６と、第１副菜Ｃ６７と、第２副菜Ｃ６８と、汁物Ｃ６９と、栄養Ｃ６Ａと、ジャンルＣ６Ｂとを含んでいる。

応答ＩＤ Ｃ６１は、レシピ応答情報Ｔ６を識別する識別子である。料理名Ｃ６２は、一つまたは複数のレシピから構成される料理の名称である。食材ＩＤ Ｃ６３は、料理に使用される一つまたは複数の食材を特定する情報である。使用量Ｃ６４は、調理に際して使用される食材の量である。調理法Ｃ６５は、主菜、各副菜、汁物の調理方法を示す情報である。調理法Ｃ６５の情報は、テキスト、静止画像、イラスト、動画像、音声などを組み合わせて構成することができる。

主菜ＩＤ Ｃ６６は、主菜を特定する識別子である。第１副菜ＩＤ Ｃ６７は第１副菜を特定する識別子である。第２副菜ＩＤ Ｃ６８は、第２副菜を特定する識別子である。汁物ＩＤ Ｃ６９は、汁物を特定する識別子である。栄養Ｃ６Ａは、一食分の料理に含まれる栄養素の種類と栄養素ごとの量を示す。ジャンルＣ６Ｂは、料理名Ｃ６２で特定される一食の料理が属するジャンルを示す。

レシピ応答情報Ｔ６は、図７の構成に限らない。要するに共通のジャンルに属する一食分の料理をユーザが調理することができる情報が含まれていればよい。

図８は、食材画像判定処理のフローチャートである。食材画像判定部１２は、食材画像取得部２１から食材画像を取り込み（Ｓ１１）、機械学習の手法を用いて食材画像に含まれる食材の種類、量、状態を判定する（Ｓ１２）。そして、食材画像判定部１２は、その判定結果を献立候補検索部１１などへ出力する（Ｓ１３）。

図９は、献立提案部１０による献立提案処理のフローチャートである。献立提案部１０は、食材画像判定部１２の判定結果Ｔ１と、ユーザ情報Ｔ２と、食事履歴情報Ｔ３と、栄養情報Ｔ４と、栄養情報Ｔ４と、常備品情報Ｔ５とを取得する（Ｓ２１）。

献立提案部１０の栄養評価部１３は、取得した情報に基づいて、所定期間における献立の栄養素の合計と、食材画像の判定結果から得られる食材の栄養素の合計とをそれぞれ算出し、献立の栄養を評価する（Ｓ２２）。

所定期間とは、例えば、現在から所定日数だけ前の期間であり、栄養のバランスが取れているか判定するための期間である。所定期間は、ユーザが任意に設定できるようにしてもよい。栄養評価部１３は、栄養の評価に際して、栄養情報Ｔ４に登録された各食材の栄養素をその食材の使用量に応じて利用する。評価対象の栄養素は、ユーザが任意に設定できるようにしてもよい。例えば、糖質制限ダイエットをしているユーザの場合、炭水化物、タンパク質、脂質を中心に献立の栄養を評価してもよい。

献立提案部１０は、ユーザの食事履歴情報Ｔ３と食材画像の判定結果から得られる食材の栄養素とに基づいて、ユーザに不足している栄養素を検出すると、その不足している栄養素を補うことのできる食材を抽出する（Ｓ２３）。例えば、ユーザにより指定された栄養素について閾値を設定し、所定期間内に摂取された栄養素の合計値が閾値以下の場合に、不足している栄養素であると判定することができる。判定対象の栄養素は複数設定することができる。ユーザが全て設定してもよいし、幾つかの栄養素については、献立提案部１０が自動的に設定してもよい。閾値は、ユーザが設定してもよいし、公的機関などで推奨された値を用いてもよい。

献立提案部１０は、食材画像から判定された食材を用いて調理可能な献立を検索するか判定する（Ｓ２４）。献立提案部１０は、食材画像から判定された食材だけでは栄養素の合計が閾値に達しない場合（Ｓ２４：ＮＯ）、追加すべき食材をユーザ端末２０へ送信し、ユーザにその追加食材の購入を提案する（Ｓ２５）。

例えば、食材画像から判定された食材が緑黄色野菜ばかりであり、魚または肉などのタンパク質を多く含む食材が全く含まれておらず、しかもユーザのタンパク質摂取量が閾値よりも低い場合、献立提案部１０は、判定された食材だけでは栄養素の面で適切な献立を提案できないと判定することができる。

これに対し、判定された食材だけで献立候補を検索可能な場合（Ｓ２４：ＹＥＳ）、献立提案部１０は、以下に詳述するように、主菜の候補と複数の副菜の候補と汁物の候補とをレシピ管理部３０から取得し（Ｓ２６～Ｓ３４）、ユーザ端末２０を介してユーザへ提示する（Ｓ３５）。

主菜の候補を算出する処理を説明する。献立提案部１０は、主菜の候補（あるいは、主食および主菜の候補）を取得する。すなわち、献立提案部１０は、主菜の候補について、それに使用される食材の種類、量、料理名、ジャンルなどを取得する（Ｓ２６）。料理のジャンルとは、上述の通り、料理の種類および調理方法などを分類する情報である。料理のジャンルの例として、和食、洋食、中華、揚げ物、煮込みなどがある。

献立提案部１０は、食材画像の判定結果（食材名、量、状態）Ｔ１と常備品情報Ｔ５とに基づいて、レシピ管理部３０から主菜候補を取得する。

献立提案部１０は、次の全ての条件を満たす料理を主菜候補を選択する。第１に必要な食材は判定結果の食材に含まれていること、第２に常備品または判定結果の食材以外に必要な食材がないこと、第３に必要な食材の量は判定結果の食材の量以下であること、第４に判定結果の食材の状態に適合していること、である。例えば、判定結果の食材が「千切り状態のキャベツ」である場合、その食材からロールキャベツを作ることはできないため、判定結果の食材の状態と適合していないと判定される。

献立提案部１０は、ステップＳ２６で取得された主菜候補の中から、過去にユーザに提案された主菜候補およびそれに類似する主菜候補を除外する（Ｓ２７）。

例えば、ステップＳ２６で取得された主菜候補の中に「とんかつ」が含まれており、食事履歴情報Ｔ３には２日前の夕食として「ピカタ」が記録されている場合、献立提案部１０は、ステップＳ２６で取得された主菜候補から「とんかつ」を除外する。「とんかつ」と「ピカタ」とは共に豚肉を中心とする料理であり、類似するためである。過去にユーザへ提案された主菜候補と同一または類似する主菜候補を除外するのは、単調な献立が続いてユーザに飽きられるのを防止し、食事の楽しみを増加させると共に、栄養の偏りを防止するためである。

除外方法としては、（１）例えば、過去の料理を除外する、（２）類似料理を除外するに分けることができる。例えば、（１）ユーザに過去Ｘ日以内に提案した主菜候補は、既にユーザが食べていると推測し、除外する。また例えば、（２）ユーザに過去Ｙ日以内に提案した主菜候補に類似する主菜候補は除外する。所定日数Ｘ，Ｙの値および単位は任意に設定することができる。

献立提案部１０は、一つ目の副菜の候補に使用可能な食材(食材名、量、状態)を計算する（Ｓ２８）。すなわち、献立提案部１０は、食材画像の判定結果（食材名、量）から、ステップＳ２６，Ｓ２７で抽出された主菜候補で使用する食材を除く。主菜候補で使用予定の食材の量も考慮する。

献立提案部１０は、ステップＳ２８の結果に基づいてレシピ管理部３０を検索することにより、一つ目の副菜候補（第１副菜候補）について、使用する食材およびその量と、料理名とを取得する（Ｓ２９）。

第１副菜候補の取得方法を説明する。例えば、献立提案部１０は、第１副菜候補に使用可能な食材（食材名、量、状態）と常備品との情報とを用いて、レシピ管理部３０（レシピデータベースへのＡＰＩ（Application Programming Interface））を検索し、第１副菜候補を取得する。

献立提案部１０は、主菜候補を取得する場合と同様に、以下の条件を全て満たす料理を第１副菜候補として選択する。すなわち、第１に必要な食材は判定結果の食材に含まれていること、第２に常備品または判定結果の食材以外に必要な食材がないこと、第３に必要な食材の量は判定結果の食材の量以下であること、第４に判定結果の食材の状態に適合していること、第５に副菜であること、第６に主菜候補と同一の料理ジャンルに属すること、である。

これにより、献立提案部１０は、主菜候補で使用されているメインの食材とは異なる食材を用いた副菜であって、かつ、主菜候補と同じジャンルに属する副菜を第１副菜候補として取得することができる。

続いて、献立提案部１０は、二つ目の副菜候補（第２副菜候補）に使用可能な食材(食材名、量、状態）を計算する（Ｓ３０）。献立提案部１０は、各食材の量について、第１副菜候補に使用される量を差し引く。献立提案部１０は、第１副菜候補の取得方法（選択方法）と同様に、以下の全ての条件を満たす第２副菜候補を選択する（Ｓ３１）。第１に必要な食材は判定結果の食材に含まれていること、第２に常備品または判定結果の食材以外に必要な食材がないこと、第３に必要な食材の量は判定結果の食材の量以下であること、第４に判定結果の食材の状態に適合していること、第５に副菜であること、第６に主菜候補と同一の料理ジャンルに属すること、である。

さらに、献立提案部１０は、汁物の候補に使用可能な食材（食材名、量、状態）を計算する（Ｓ３２）。献立提案部１０は、各副菜候補での食材の算出と同様に、第２副菜候補で使用予定の食材の種類および量を考慮する。例えば、主菜が「とんかつ」の場合に、汁物として「豚汁」が選択されないよう、食材のだぶりを防止するためである。

献立提案部１０は、レシピ管理部３０から汁物候補を取得する（Ｓ３３）。献立提案部１０は、以下の条件を全て満たす料理を第１副菜候補として選択する。すなわち、第１に必要な食材は判定結果の食材に含まれていること、第２に常備品または判定結果の食材以外に必要な食材がないこと、第３に必要な食材の量は判定結果の食材の量以下であること、第４に判定結果の食材の状態に適合していること、第５に汁物であること、第６に主菜候補と同一の料理ジャンルに属すること、である。なお、汁物を付けるか否かはユーザが任意に設定可能である。

献立提案部１０は、取得された主菜候補、各副菜候補および汁物候補を調理するためのレシピをレシピ管理部３０から取得し（Ｓ３４）、情報提供部１６からユーザ端末２０のユーザインターフェース部２３を介して、ユーザへ提案する（Ｓ３５）。

図１０の献立提案画面Ｇ１を用いて、献立提案部１０からユーザ端末２０へ送られる提案情報を説明する。

献立提案画面Ｇ１は、例えば、食材情報欄ＧＰ１１と、献立候補欄ＧＰ１２と、ＯＫボタンＧＰ１３と、取り消しボタンＧＰ１４を含む。献立提案画面Ｇ１は、単品料理の提案ではなく、ジャンルを共通にする一食分の献立候補について、料理名、作り方、栄養情報（調理後の栄養情報）を提案する。

栄養予測情報は、調理後の栄養情報に基づいて、主菜、各副菜、汁物のそれぞれの料理の栄養素を合算したものをユーザへ提示する。栄養予測情報とは、提案された一食分の候補を食べたときの各栄養素を予測した情報である。一食分の献立候補についての栄養情報Ｔ４と、ユーザの食事履歴情報Ｔ３とから栄養情報を予測することができる。

なお、献立候補を提案するに際して、その献立の特徴、または評価値などを合わせて表示してもよい。例えば、「この献立は、あなたのパワー回復に有効なビタミン群を多く含んでいます。お勧め度：４点」、「この献立は、睡眠時間の短いあなたの肌を守るコラーゲンやミネラルをたっぷり含みます。お勧め度：３．５点」のようなメッセージを添えてもよい。

図１１～図１３を用いて、献立提案システムをコンピュータシステムとして実現する場合の例を幾つか説明する。

図１１は、献立提案サーバ１００と、ユーザ端末２００と、レシピ提供サーバ３００とを通信ネットワークＣＮで接続した例を示す。献立提案サーバ１００は、図１の献立提案部１０としての役割を果たす。すなわち献立提案サーバ１００は、食材画像判定部１２と、ユーザ情報管理部１４と、栄養情報取得部１５と、栄養評価部１３と、献立候補検索部１１と、情報提供部１６とを備える。

献立提案サーバ１００は、例えば、マイクロプロセッサ（図中ＣＰＵ（Central Processing Unit））１０１と、メモリ１０２と、図示せぬ通信インターフェース部などを備えており、記憶媒体１０３との間で情報を読み書き可能である。マイクロプロセッサ１０１がメモリ１０２に格納された所定のコンピュータプログラムを読み込んで実行することにより、上述した各機能１１～１６が実現される。なお、ユーザ端末２００およびレシピ提供サーバ３００も同様に、マイクロプロセッサとメモリおよび通信インターフェース部（いずれも図示せず）を備えたコンピュータとして実現される。

本実施例の献立提案部１０を実現する所定のコンピュータプログラムの一部または全部は、記憶媒体１０３に固定させて流通させることができる。あるいは、所定のコンピュータプログラムを通信媒体を介してコンピュータにダウンロードさせることもできる。

ユーザ端末２００は、図１のユーザ端末２０としての役割を果たす。すなわち、ユーザ端末２００は、食材画像取得部２１と、常備品情報取得部２２と、ユーザインターフェース部２３とを備える。

レシピ提供サーバ３００は、レシピ管理部３０を実現するコンピュータである。

図１２は、献立提案システムを実現するコンピュータシステムの他の例である。図１２の構成例では、食材画像判定サーバ４００が献立提案サーバ１００Ａから切り離されて、別体のコンピュータとして設けられている。献立提案サーバ１００Ａと、ユーザ端末２００と、レシピ提供サーバ３００と、食材画像判定サーバ４００とは、通信ネットワークＣＮを介して接続されている。

ユーザ端末２００で取得された食事画像は、通信ネットワークＣＮを介して食材画像判定サーバ４００へ送信され、食材画像判定部１２により判定される。その判定結果は、食材画像判定サーバ４００から献立提案サーバ１００Ａへ通信ネットワークＣＮを介して送信される。献立提案サーバ１００Ａは、献立候補のレシピをレシピ提供サーバ３００から通信ネットワークＣＮを介して取得する。そして、献立提案サーバ１００Ａは、ユーザ端末２００へ提案情報を通信ネットワークＣＮを介して送信する。

図１３は、献立提案システムを実現するためのコンピュータシステムのさらに別の例を示す。この構成例では、食材画像判定部１２をユーザ端末２００Ｂに設ける。ユーザ端末２００Ｂは、食材画像取得部２１で取得した食材画像を食材画像判定部１２により判定し、その判定結果および常備品情報を献立提案サーバ１００へ通信ネットワークＣＮを介して送信する。以下の動作は同様であるため割愛する。

なお、ユーザは、食材画像判定部１２の判定結果が間違っている場合には、ユーザ端末２００Ｂのユーザインターフェース部２３を介して訂正することができる。さらに、図示を省略するが、図１２で述べた食材画像判定サーバ４００へ食材画像を送信し、その判定を依頼することもできる。ユーザ端末２００Ｂは、食材画像判定サーバ４００からの判定結果を受信すると、献立提案サーバ１００へ送信する。

このように構成される本実施例によれば、ユーザは、食材の画像をカメラ撮影などで取得するだけで、その食材画像に含まれる食材の種類（食材名）、量、状態に適した献立候補を得ることができ、ユーザにとっての使い勝手が向上する。

ユーザは、食材を購入したときのレシートを撮影したり、食材の名称と量をキーボードから入力したり、食材の名称と量を音声で読み上げたりする必要がない。

さらに、本実施例では、食材の種類と量だけでなく、食材の状態も考慮することができるため、その食材の状態に適した献立候補をユーザへ提案することができる。

さらに、本実施例では、主菜候補と各副菜候補（および汁物）の属する料理ジャンルを同一または類似にすることができるため、単品料理のレシピを個別に選択する場合に比べて、統一感のある一食分の献立のレシピを簡単に得ることができ、ユーザにとっての使い勝手が向上する。

図１４を用いて第２実施例を説明する。本実施例では、第１実施例との相違を中心に述べる。第１実施例では、一つの食材画像に複数の食材が含まれている場合を述べた。これに代えて、本実施例では、食材を一つずつ取り込んで判定させることができ、さらに、食材を加えながら献立候補を取得できるようにしている。

本実施例の食材画像判定部１２は、食材画像取得部２１から食材画像を取り込み（Ｓ１１）、その取り込んだ食材画像を判定させるか決定する（Ｓ１４）。取り込んだ食材画像を判定させる場合（Ｓ１４：ＹＥＳ）、食材画像を判定する（Ｓ１２）。判定しない場合（Ｓ１４：ＮＯ）、ステップＳ１１へ戻り、別の食材を取り込む。

食材画像判定部１２は、判定結果に基づく献立候補の提案を献立提案部１０へ依頼するか判定する（Ｓ１５）。提案を依頼する場合（Ｓ１５：ＹＥＳ）、食材画像判定部１２の判定結果（食材の種類、量、状態）は献立提案部１０へ送られる（Ｓ１３）。

このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに、本実施例では、食材の画像を個別に取得して判定させることができる。したがって、ユーザは、例えば、スーパーマーケットなどで食材を物色しながら、その食材を購入した場合の献立候補を確認することができる。

なお、本発明は、上述した実施形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。上述の実施形態において、添付図面に図示した構成例に限定されない。本発明の目的を達成する範囲内で、実施形態の構成や処理方法は適宜変更することが可能である。

また、本発明の各構成要素は、任意に取捨選択することができ、取捨選択した構成を具備する発明も本発明に含まれる。さらに特許請求の範囲に記載された構成は、特許請求の範囲で明示している組合せ以外にも組合せることができる。

１０：献立提案部、１１：献立候補検索部、１２：食材画像判定部、１３：栄養評価部、１４：ユーザ情報管理部、栄養情報取得部１５，情報提供部１６、２０：ユーザ端末、２１：食材画像取得部、２２：常備品情報取得部、２３：ユーザインターフェース部、３０：レシピ管理部

Claims (3)

1. 献立提供システムであって、
   取得された食材の画像を解析することにより、前記食材の種類、量および状態を判定する食材画像判定部と、
   前記食材画像判定部の判定結果に基づいて、前記食材を用いて調理可能な献立候補を検索する献立候補検索部と、
   を備え、
   前記食材の状態には、前記食材の状態に適した献立を検索するために、通常状態の食材との形状の差異が含まれており、
   前記献立候補には、複数の料理が含まれており、前記複数の料理は所定の料理ジャンルに属し、
   前記複数の料理には、主菜と少なくとも一つの副菜とが含まれており、前記主菜の料理ジャンルと同一の料理ジャンルに属する副菜が候補として選択され、
   前記検索された献立候補をユーザへ提供する献立提供システム。
2. 前記献立候補検索部は、ユーザの食事履歴と栄養に関する情報も考慮して、前記食材を用いて調理可能な献立候補を検索する、
   請求項１に記載の献立提供システム。
3. 前記食材画像判定部は、複数の食材が含まれる食材画像を解析することにより、前記各食材の種類、量および状態を判定する、
   請求項１に記載の献立提供システム。

Images