JP7458745B2

JP7458745B2 - 給食のメニュー作成支援システム及び給食のメニュー作成支援方法

Info

Publication number: JP7458745B2
Application number: JP2019199771A
Authority: JP
Inventors: 美穂植田; 隆至島; グェン・トアン・ドゥク; グェン・フィ・レ
Original assignee: 株式会社Leoc
Priority date: 2019-11-01
Filing date: 2019-11-01
Publication date: 2024-04-01
Anticipated expiration: 2039-11-01
Also published as: JP2021072032A

Description

この発明は、給食のメニュー作成支援システム及び給食のメニュー作成支援方法に関し、給食の品目（皿数）を中心にメニューを選択することで、品目の多様化を図ることができるようにしたものである。

従来、献立構成要素として主食、主菜、及び副菜等を含む１食の献立を作成するにあたり、その１食の献立が所定の栄養バランスを充足し、かつ各献立構成要素をなす個々のメニューを容易に決定できるようにした献立の作成方法が知られている（例えば特許文献１の段落番号「０００７」参照）。

特開２０１９－０８２８０８号公報

しかし、上記した従来の献立の作成方法では、利用者の意見が献立（メニュー）に反映されず、一方的に献立が決定されてしまうという問題点があった。
そこで、各請求項にそれぞれ記載された各発明は、上記した従来の技術の有する問題点に鑑みてなされたものであり、その目的とするところは、次の点にある。

（請求項１～７）
請求項１～７に記載の各発明は、次の点を目的とする。
すなわち、請求項１～７に記載の各発明は、利用者が設定した利用者設定条件を第１メソッドとしてモデリングすることで、献立であるメニューの決定に利用者の意見を反映させ、且つ給食の品目（皿数）を中心にメニューを選択することで、品目の多様化を図ることができるようにしたものである。

これに加え、請求項１～７に記載の各発明は、ＡＩ（人工知能）の数理計画問題を解くことにより、利用者が設定した第１メソッドと、内部的に決定された第２メソッドとの最適化を図ることができるようにしたものである。

各請求項にそれぞれ記載された各発明は、上記した各目的を達成するためになされたものであり、各発明の特徴点を図面に示した発明の実施の形態を用いて、以下に説明する。
なお、カッコ内の符号は、発明の実施の形態において用いた符号を示し、本発明の技術的範囲を限定するものではない。
また、図面番号も、発明の実施の形態において用いた図番を示し、本発明の技術的範囲を限定するものではない。

（請求項１）
請求項１に記載の発明は、給食のメニュー作成支援システムであって、次の点を特徴とする。
第１に、メニューの採否を判定するメニュー判定条件には、利用者が設定可能な複数の利用者設定条件と、前記利用者設定条件と異なり、利用者が設定不能であり、内部的に設定された複数の内部設定条件と、を含む。
第２に、前記利用者設定条件には、一食当たりの品目の個数、及び各品目の食事の種類を選択可能な食事設定条件と、日の食事には朝食、昼食、夕食の三食を少なくとも含み、前記三食を一日として、メニューを作成する指定期間を設定する期間指定条件と、を含む。

第３に、給食のメニュー作成支援システムには、次の構成を含む。
（１）メニュー条件受入部
メニュー条件受入部は、利用者が設定した前記利用者設定条件を受け入れ可能なものである。
（２）条件モデリング部
条件モデリング部は、前記メニュー条件受入部が受け入れた前記利用者設定条件を、一致・不一致の二択の解として出力し、第１メソッドとしてモデリングするものである。

（３）メソッド記憶部
メソッド記憶部は、前記条件モデリング部によりモデリングされた前記第１メソッド、及び予めモデリング化された前記内部設定条件である第２メソッドを記憶可能なものである。
（４）料理選択部
料理選択部は、前記品目に１個の関数をそれぞれ割り当て、前記期間指定条件により設定された前記指定期間の複数の前記関数より関数群を構成し、前記関数群に属する前記関数毎に、料理マスタに記憶された料理群中から料理を選択するものである。

（５）条件判定部
条件判定部は、前記料理選択部により選択された前記料理について、前記メソッド記憶部に記憶された前記第１メソッド及び前記第２メソッドを用いて判定するものである。
（６）メニュー出力部
メニュー出力部は、前記条件判定部による判定結果が全て前記一致の場合に、給食のメニュー作成支援データとして出力するものである。
を備えていることを特徴とする。

（請求項２）
請求項２に記載の発明は、給食のメニュー作成支援システムであって、上記した請求項１に記載の発明の特徴点に加え、次の点を特徴とする。
すなわち、前記条件判定部は、数理計画問題を解くことにより、前記第１メソッド及び前記第２メソッドを判定している。

（請求項３）
請求項３に記載の発明は、給食のメニュー作成支援システムであって、上記した請求項１又は請求項２に記載の発明の特徴点に加え、次の点を特徴とする。
第１に、前記メニュー条件受入部には、都道府県別に定められた食品構成が記憶される。
第２に、前記利用者設定条件には、前記都道府県のうち一つを設定することで、前記メニュー条件受入部に記憶された前記都道府県別に定められた食品構成条件として展開され、その結果、前記都道府県別の前記食品構成を満たす設定条件を含んでいる。

（請求項４）
請求項４に記載の発明は、給食のメニュー作成支援システムであって、上記した請求項１～３のいずれか１項に記載の発明の特徴点に加え、次の点を特徴とする。
第１に、前記料理マスタに記憶される前記料理群には、前記料理として、和食料理と洋食料理とを少なくとも含む和洋折衷である複数の一般料理と、前記一般料理以外であって、日本人の文化に根付いた複数の特定日本料理と、が含まれる。

第２に、前記内部設定条件には、前記一食に含まれる複数の前記品目の１個として、前記特定日本料理が選択された場合に、前記一食の残りの前記品目を、前記一般料理に含まれる和食料理から選択する日本料理選択条件が含まれている。

（請求項５）
請求項５に記載の発明は、給食のメニュー作成支援システムであって、上記した請求項１～４のいずれか１項に記載の発明の特徴点に加え、次の点を特徴とする。
すなわち、前記料理マスタに記憶される前記料理群には、通常の定食スタイルと異なる特別指定料理が含まれている。

（請求項６）
請求項６に記載の発明は、給食のメニュー作成支援システムであって、上記した請求項１～５のいずれか１項に記載の発明の特徴点に加え、次の点を特徴とする。
第１に、前記利用者設定条件には、前記一食のメニュー原価の入力値であるメニュー原価条件と、前記期間指定条件のうちの前記一食を年中行事実施時のイベント食として指定するイベント食設定条件と、前記イベント食設定条件で指定された前記イベント食の材料費の入力値であるイベント食材料費条件と、を含む。

第２に、前記条件モデリング部は、前記メニュー条件受入部を介して受け入れた前記メニュー原価条件を、一致・不一致の二択の解として出力する第３メソッドとしてモデリングするとともに、前記メニュー条件受入部を介して前記イベント食材料費条件が受け入れられた場合に、前記メニュー原価条件から前記イベント食材料費条件を除外し、第４メソッドとしてモデリング化する。

第３に、前記メソッド記憶部は、前記第３メソッド及び前記第４メソッドを記憶する。
第４に、前記条件判定部は、前記メソッド記憶部に記憶された前記第３メソッド及び前記第４メソッドを用いて判定している。

請求項７に記載の発明は、コンピュータが実行する給食のメニュー作成支援方法であって、次の点を特徴とする。
第１に、メニューの採否を判定するメニュー判定条件には、利用者が設定可能な複数の利用者設定条件と、前記利用者設定条件と異なり、利用者が設定不能であり、内部的に設定された複数の内部設定条件とを含む。
第２に、前記利用者設定条件には、一食当たりの品目の個数、及び各品目の食事の種類を選択可能な食事設定条件と、一日の食事には朝食、昼食、夕食の三食を少なくとも含み、前記三食を一日として、メニューを作成する指定期間を設定する期間指定条件と、を含む。

第３に、給食のメニュー作成支援方法には、次の工程を含む。
（１）条件受入工程
条件受入工程は、利用者が設定した前記利用者設定条件を受け入れる工程である。
（２）
条件モデリング工程は、受け入れた前記利用者設定条件を、一致・不一致の二択の解として出力し、第１メソッドとしてモデリングする工程である。

（３）メソッド記憶工程
メソッド記憶工程は、前記第１メソッド、及び予めモデリング化された前記内部設定条件である第２メソッドを記憶可能な工程である。
（４）料理選択工程
料理選択工程は、前記品目に１個の関数をそれぞれ割り当て、前記期間指定条件により設定された前記指定期間の複数の前記関数より関数群を構成し、前記関数群に属する前記関数毎に、料理マスタに記憶された料理群中から料理を選択する工程である。

（５）料理判定工程
料理判定工程は、選択された前記料理について、記憶された前記第１メソッド及び前記第２メソッドを用いて判定する工程である。
（６）メニュー出力工程
メニュー出力工程は、料理判定結果が全て前記一致の場合に、給食のメニュー作成支援データとして出力する工程である。

本発明は、以上のように構成されているので、以下に記載されるような効果を奏する。
（請求項１～７）
請求項１～７に記載の各発明によれば、次のような効果を奏する。
すなわち、請求項１～７に記載の発明によれば、利用者が設定した利用者設定条件を第１メソッドとしてモデリングすることで、献立であるメニューの決定に利用者の意見を反映させ、且つ給食の品目（皿数）を中心にメニューを選択することで、品目の多様化を図ることができるようにしたものである。

これに加え、請求項１～７に記載の各発明によれば、ＡＩ（人工知能）を数理計画問題を解くことにより、利用者が設定した第１メソッドと、内部的に決定された第２メソッドとの最適化を図ることができるようにしたものである。

給食のメニュー作成支援システムのサーバの説明するための説明図である。給食のメニュー作成支援システムの概要を説明するための説明図である。利用者の入力画面を説明するための説明図である。図３の下側に続く、入力画面を説明するための説明図である。図４の下側に続く、入力画面を説明するための説明図である。利用者に対する出力画面を説明するための説明図である。指定期間と変数とを説明するための説明図である。料理マスタの登録画面を説明するための説明図である。第１食材と第２食材との関係を説明するための説明図である。図５に対応し、次の操作により変化した状態の説明図である。図１０に対応し、次の操作により変化した状態の説明図である。図１１に対応し、次の操作により変化した状態の説明図である。

（給食のメニュー作成支援システム10）
図２中、10は、給食のメニュー作成支援システム（以下、「本システム10」という。）である。
本システム10は、大別すると、次の構成を有する。
なお、次の（１）及び（２）については後述する。
（１）通信端末20
（２）サーバ30
なお、システム10の構成として、（１）通信端末20、（２）サーバ30を例示したが、これに限定されず、図示しないが、物流システムと連携させてもよい。

（給食）
「給食」は、施設毎で提供されるものである。
「給食」のうち、保険医療機関における給食には、次の種類が含まれる。
（１）一般治療食
「一般治療食」は、呼称として「常食」とも呼ばれている。
（２）特別治療食
特別治療食は、呼称として、病態など、施設毎に独自の名称が設定されている。

上記「保険医療機関における給食」のうち、本システム10は、上記「一般治療食」に対するメニュー判定に対応している。
治療を目的とした栄養素などのコントロールは必要としないものの、医師が発行した食事箋に基づき、患者の全身的な栄養状態の改善を図り、良好な栄養状態を維持することにより、疾病の治療に間接的に貢献することを目的に調製されるものである。

一方、介護保険施設における給食には、次の種類が含まれる。
（３）一般食（呼称：入居者食）」
「一般食」は、呼称として「入居者食」とも呼ばれている。
（４）療養食（呼称：介護報酬算定の対象となる食事名称“例：糖尿病食、肝臓病食、腎臓病食・・”）」
「療養食」は、称呼として、介護報酬算定の対象となる食事名称、例えば「糖尿病食」、「肝臓病食」、「腎臓病食」などと呼ばれている。

上記「介護保険施設における給食」のうち、本システム10は、上記「一般食」に対するメニュー判定に対応している。
疾病治療の直接手段として、利用者の年齢、病状等に対応した栄養量及び内容を有することは必要としないものの、入居者の主治医が発行する食事箋に基づき、年齢、性別、生活活動レベルを考慮した栄養価基準への意識と、終身利用をされる方も多いため、食事への楽しみ、身体機能を考慮し、五感を満たすことを目指した食事の調製がされるものである。
上記は、診療報酬（保険医療機関）、介護報酬（介護保険施設・保険医療機関における療養病棟等）の算定対象となる食事メニューに適応するものである。

（通信端末20）
通信端末20は、インターネット等のネットワークに接続されたＰＣ等である。
通信端末20には、図３～図５に示すように入力用の画面を有し、利用者が利用者設定条件等を入力可能なものである。通信端末20から入力された利用者設定条件は、インターネットを通じて、後述するサーバに30に送信され、図１に示すように、メニュー判定条件31として入力される。

また、通信端末20には、サーバ30からメニュー判定条件31に対するメニュー判定結果36が、インターネットを通じて送信される。通信端末20には、図６に示すように、給食のメニューがカレンダー形式で出力用の画面が表示される。
なお、通信端末20として、ＰＣを例示したが、これに限定されず、ノートＰＣ、タブレット、スマートフォン、携帯電話、ＰＨＳ、ＰＤＡ、ノートＰＣ、タブレット等の移動体通信端末や携帯情報端末でもよい。
また、ネットワークとして、インターネットを例示したが、これに限定されず、専用線でもよい。

（サーバ30）
サーバ30は、図１に示すように、インターネットを通じて通信端末20から送信されるメニュー判定条件31の入力を契機として、メニュー判定結果36を作成し、作成したメニュー判定結果36を通信端末20に出力するものである。
なお、サーバ30は、物理サーバでもよいし、クラウドサーバでもよい。

（メニュー判定条件31）
メニュー判定条件31は、サーバ30において、メニューの採否を判定するためのものである。
メニュー判定条件31には、大別すると、次の条件を含む。
なお、次の（１）及び（２）については、後述する。
（１）利用者設定条件
（２）内部設定条件

なお、メニュー判定条件31として、（１）利用者設定条件、（２）内部設定条件の計２個の条件を例示したが、これに限定されず、例えば病院や施設等の提供先や、或いは例えば患者や入居者等の食べる人や家族等の意見を「条件」として取り込めるようにしても良い。

（利用者設定条件）
利用者設定条件は、利用者が設定可能なものであり、複数有る。
利用者設定条件は、図３に示すように、通信端末20の画面を使用して、利用者が設定可能なものである。
なお、利用者設定条件の具体例については、図３を用いて後述する。

（内部設定条件）
内部設定条件は、利用者設定条件と異なり、利用者が設定不能であり、内部的に設定されたものであり、複数有る。
なお、内部設定条件の具体例については、後述する。

（利用者設定条件）
利用者設定条件には、次の条件を含んでいる。
なお、利用者設定条件は、次の（１）食事設定条件及び（２）期間指定条件に限定されない。
（１）食事設定条件
（２）期間指定条件
なお、利用者設定条件は、次の（１）食事設定条件及び（２）期間指定条件に限定されず、後述するが、「各食事の中で、『調理工程難度高』を２度以上採用しない」等がある。

（食事設定条件）
食事設定条件は、一食当たりの品目の個数（皿数）、及び各品目の食事の種類を選択可能なものである。
食事設定条件としては、図３に示すように、「一食」とし、「食事区分」として、次の「三食」について入力している。
（１）朝食
（２）昼食
（３）夕食

なお、「食事区分」は、（１）朝食、（２）昼食、（３）夕食の「三食」を例示したが、これに限定されず、に限定されず、図３に示すように、例えば（４）「１５時、その他」、（５）「２０時、その他」の両方、或いは一方を含んでいても良い。

ここで、「その他」とは、３度の食事（朝、昼、夕）以外にも提供が必要な食事を示す。例えばアスリート向けであれば、「１０時や１５時や２１時頃の「補食」（回数、タイミングは年齢、競技により異なる）」、介護保険施設であれば、「１０時や１５時頃の「間食」又は「おやつ」（回数、タイミングは施設により異なる）」、医療保険施設であれば、「成長期の年齢層の一般治療食（常食）の「補食」（医療機関により提供タイミング、提供方法は異なる）」、保育園での１０時や１５時の「間食」又は「おやつ」（回数、タイミングは園の方針により異なる）」等を指すものである。

（朝食）
「朝食」の品目の個数（皿数）としては、図３に示すように、例えば計「６品目」（６皿）を設定している。
なお、品目の個数（皿数）としては、計「６品目」（６皿）を例示したが、これに限定されず、例えば３～５品目としてもよいし、或いは「７品目」としてもよい。

また、「朝食」の各品目の食事の種類としては、計「６品目」のうち、例えば１品目「主食」、２品目「汁椀」、３品目「副菜」、４品目「小鉢」、５品目「ご飯のとも」、６品目「ドリンク」を設定している。

食事の種類として、（１）「主食」、（２）「汁椀」、（３）「副菜」、（４）「小鉢」、（５）「ご飯のとも」、（６）「ドリンク」の６種類を例示したが、これに限定されず、図３の「昼食」において例示した（７）「主菜」、（８）「デザート皿」を含んでいてもよい、或いは「夕食」において例示した（９）「主食」、（１０）「汁椀」等を含んでいてもよい。

（昼食）
「昼食」の品目の個数（皿数）としては、図３に示すように、例えば計「５品目」（５皿）を設定している。
「昼食」の各品目の食事の種類としては、計「５品目」のうち、例えば１品目「主食」、２品目「主菜」、３品目「副菜」、４品目「小鉢」、５品目「デザート皿」に設定している。

（夕食）
「夕食」の品目の個数（皿数）としては、図３に示すように、例えば計「５品目」（５皿）である。
「夕食」の各品目の食事の種類としては、計「５品目」のうち、例えば１品目「主食」、２品目「汁椀」、３品目「主菜」、４品目「副菜」、５品目「小鉢」に設定している。

（期間指定条件）
期間指定条件は、一日の食事には朝食、昼食、夕食の三食を少なくとも含み、三食を一日として、メニューを作成する「指定期間」を設定するものである。
「指定期間」としては、図３に示すように、初日「２０１９年５月１８日（土）」から終日「２０１９年５月３１日（土）」の１４日、２週間を設定している。
なお、「指定期間」として、１４日、２週間を例示したが、これに限定されず、１～１３日や、１５日以上としてもよいし、或いは週単位、月単位で設定できるようにしても良い。

（本システム10の構成）
本システム10には、図１に示すように、次の構成を含む。
なお、次の（１）～（６）については後述する。
（１）メニュー条件受入部32（Json Parser）
（２）条件モデリング部33（Constraints Model）
（３）メソッド記憶部
（４）料理選択部37（DB Utils）
（５）条件判定部34（Solution Var）
（６）メニュー出力部35（Json Builder）

なお、本システム10の構成として、上記した（１）～（６）の構成を例示したが、これに限定されず、例えば「（６）メニュー出力部35」を省き、「（５）条件判定部34」の判定結果を、図２に示すサーバ30にそのまま送信し、サーバ30側に「（６）メニュー出力部35」を設けてもよい。

（メニュー条件受入部32）
メニュー条件受入部32は、利用者が設定した利用者設定条件を受け入れ可能なものである。

（条件モデリング部33）
条件モデリング部33は、メニュー条件受入部32が受け入れた利用者設定条件を、一致・不一致の二択の解として出力し、第１メソッドとしてモデリングするものである。

（メソッド記憶部）
メソッド記憶部は、条件モデリング部33によりモデリングされた第１メソッド、及び予めモデリング化された内部設定条件である第２メソッドを記憶可能なものである。
第２メソッドは、内部設定条件を用い、前述した条件モデリング部33によりモデリング化される。
メソッド記憶部は、図１中に図示しないが、ハードディスク等の記憶装置を用いている。

（料理選択部37）
料理選択部37は、品目に１個の関数をそれぞれ割り当て、期間指定条件により設定された指定期間の複数の関数より関数群を構成し、関数群に属する関数毎に、料理マスタ38（Database）に記憶された料理群中から料理を選択するものである。

（条件判定部34）
条件判定部34は、料理選択部37により選択された料理について、メソッド記憶部に記憶された第１メソッド及び第２メソッドを用いて判定するものである。

条件判定部34は、ＡＩ（人工知能）を用い、数理計画問題を解くことにより、「第１メソッド」及び「第２メソッド」を判定している。
なお、「ＡＩ」、「数理計画問題」、「モデリング」、「第１メソッド」及び「第２メソッド」については後述する。

（メニュー出力部35）
メニュー出力部35は、条件判定部34による判定結果が全て一致の場合に、給食のメニュー作成支援データとして出力するものである。

（ＡＩ）
本システム10は、「ＡＩ」（人工知能）を用い、最適化のため、「数理計画問題」を解くことで、図１に示す料理マスタ38に記憶された料理群中から料理を選択し、条件モデリング部33によりモデリング化された「第１メソッド」及び「第２メソッド」を、条件判定部34により判定することで、メニューを作成している。

ここで、「数理計画問題」とは，「与えられた条件の下で，望ましさの尺度を表す何らかの関数の最小値（最大値）を求め，さらにその最小値（最大値）を与える不特定要素の値を決定する」という問題である。

「『数理計画問題』を解く」ためには、具体的には、次のステップを実行している。
ステップは、条件モデリング部33及び条件判定部34により実行される。
なお、次の（１）～（６）のステップについては、別途後述する。

（１）変数生成ステップ
変数生成工程においては、指定期間と食事種類の構成から全て料理を格納する変数を生成する。
（２）値セット抽出ステップ
値セット抽出ステップにおいては、データベース（料理マスタ38）から各変数に該当する値セットを抽出する。

（３）値セット絞込ステップ
値セット絞込ステップにおいては、献立（メニュー）の構成に関する判定条件から各変数の値セットを絞る。
（４）関数生成ステップ
関数生成ステップにおいては、各制約（条件）を変数の関数として表している。

（５）目標関数作成ステップ
目標関数作成ステップにおいては、「目標関数」を作っている。
（６）献立検索ステップ
献立検索ステップにおいては、全ての制約を満たす献立を検索する。

（変数生成ステップ）
変数生成ステップにおいては、第１に、判定条件から下記の情報を抽出する。
記
・開始日
・終了日
・食事種類の構成

第２に、全ての料理を格納する変数を定義する。
変数の数は、下記の通りである。
記
・「変数の数」＝「１日の料理数」 × 「指定期間の日数」

「変数の数」は、例を挙げると、下記の通りである。
記
・「１日の料理の数」＝ 6（朝食）＋ 5（昼食）＋５（夕食） = 16（皿数）
・指定期間＝ 2019年5月31日（最終日） - 2019年5月18日（初日） = 14（日数）
・変数の数＝ 16 × 14 ＝ 224

・上記「224変数」は、「ｘ」を用いて、図７に示すように、下記の通り定義される。
記
・x₁,x₂,...,x₂₂₄
その中、「x₁,x₂,...x₆」が2019年5月31日（最終日）の朝食の料理、「x₇,x₈,...x₁₁」が2019年5月31日の昼食の料理を、「x₂₂₀,x₂₂₁,...x₂₂₄」が2019年5月18日（初日）の夕食の料理を表示する。

（値セット抽出ステップ）
値セット抽出ステップにおいては、データベース（料理マスタ38）を参照して、各変数に対して、下記の判定条件に該当する料理を読み取る。
記
・判定条件１：停止フラグが「１」でない。
「１」でない場合には、現在、使用されている。
例えば、図８に示す料理マスタ38の「停止」の欄が参照すると、「１」が無く、全て現在使用されている。
これに対し、「停止」の欄に「１」が設定されている場合には、現在、使用されていない。

・判定条件２：種類がマッチする
例えば、「x₈」は、図７に示すように、「昼食」の２品目で「主菜」である（図３参照）。このため、「x₈」に、図８に示すように、「食名」の「主菜」の中から選択、すなわち「料理コード」の「KA0017」～「KA0031」のうちの一つが選択されている場合には、「変数」と「種類」、すなわち「食名」とがマッチする。
これに対し、「x₈」に、「食名」の「副菜」の中から選択、すなわち「料理コード」の「KA0032」～「KA0035」のうちの一つが選択されている場合には、「変数」と「種類」、すなわち「食名」とがマッチしない。

料理マスタ38には、図８に示すように、食名（食事の種類）毎に分類され、「料理コード」を用いて料理名が蓄積されている。
例えば、「x₈」は、図７に示すように、「昼食」の２品目で「主菜」である（図３参照）。「主菜」は、図８に示すように、「料理コード」の「KA0017」～「KA0031」である。「KA0017」～「KA0031」の１５種類の中から、一つがランダムに選択され、初期値、例えば「KA0021」（料理名：豚肉の生姜焼き）として設定される。その後、「x₈」には、「KA0022」、「KA0023」・・・「KA0031」、「KA0017」・・・「KA0020」の順に「料理コード」が設定される。
「料理コード」として、一つをランダムに選択することで、メニューの重複選択を防止している。

（値セット絞込ステップ）
値セット絞込ステップにおいては、図３及び図４に示すように、「ご飯の日」、「パンの日」、「麺の日」、「丼の日」、「納豆の日」、「飲み物」、「カット野菜」等の「日指定の特定料理」（「曜日」及び朝食～夕食の「食事種類」）から変数の値セットを絞る。
「日指定の特定料理」は、「メニュー判定条件」のうち、「利用者設定条件」の一つに該当する。
例えば、「x₉₇、x₂₀₉」が第三土曜日の朝食と第四土曜日の朝食の主食を表すので、この条件から「x₉₇、x₂₀₉」の値セットは「食パン45g × 2枚」のみになる。

（関数生成ステップ）
関数生成ステップにおいては、各制約（条件）を変数の関数として表している。
例えば、制約（条件）は、下記の通りである。
記
・「設定条件１」：各食事の中で、「調理工程難度高」を２度以上使用しない。
なお、「調理工程」は、「高」と、中・低度等のそれ以外がある。
「設定条件１」は、「メニュー判定条件」のうち、「内部設定条件」の一つに該当する。

該当関数は、下記の通りである。
記
・判定条件には14日があり、各日に朝食、昼食、夕食の３つの食事種類がある。
・合計で「14 × 3 = 42」の食事種類がある。
・上記「条件１」を表すため、42個の関数を生成する。
42個の関数は、下記の「数１」の通りとする。
記

そうすると、第一日の「朝食」に対して、「条件１」は下記の関数で表される。
「x₁,x₂,...x₆」中、「調理工程難度高」を２度以上使用しない場合には、式としては下記の「数２」で表される。
記

「x₁,x₂,...x₆」中、「調理工程難度高」を、２度を越えて使用している場合（３度以上）には、式としては下記の「数３」で表される。
記

同様に、第一日目の「朝食」に対する「条件１」は、下記の「数４」で表される。
記

最後の日の「夕食」に対する「条件１」は、下記の「数５」で表される。
記

（目標関数作成ステップ）
目標関数作成ステップにおいて、目標関数を作っている。
下記の「数６」は、先に説明した関数生成ステップで生成された「条件１」、制約２（条件２）、・・・、制約ｎ（条件ｎ）を表す全ての関数として、目標関数「Ｆ」は下記の「数６」の和で定義する。
記

式としては、下記の「数７」の通りである。
記

ただし、下記の「数８」は、各関数の値範囲を標準化し、又、制約（条件）の優先度を表す「重み」である。
記

例えば、上記に説明したように、下記の「表９」が「条件１」を表すので、下記の「表９」の関数の値範囲が「０」から「６」までである。
記

しかし、材料費の制約を表す、下記の「表１０」の関数の値範囲が「１００」までに上がる可能性がある。
記

そうすると、「数９」の関数の値（「０」から「６」）と、「数１０」の関数の値（１００）に大きい「偏り」がある。
この「偏り」を排除するため、下記の「数１１」を「大きく」、下記の「数１２」を「小さく」設定することで、「偏り」を標準化する。
記

本「目標関数作成ステップ」及び先に説明した「関数生成ステップ」は、「メソッド」の「モデリング化」に相当する。具体的には、「目標関数作成ステップ」及「関数生成ステップ」は、図１に示す条件モデリング部33を中心に実行される。
本例では、「設定条件１」（「調理工程難度高」を２度以上使用しない）という、「メニュー判定条件」のうち、「内部設定条件」を、「第２メソッド」としてモデリング化している。
なお、「メニュー判定条件」のうち、「利用者設定条件」についても、「内部設定条件」と同様に、「第１メソッド」としてモデリング化している。

（献立検索ステップ）
献立検索ステップにおいては、下記の通り、全ての制約を満たす献立を検索する。
記
第１に、下記の「数１３」が、「０」となる、「x₁,x₂,...,x₂₂₄」の値を検索する。
記

検索アルゴリズムは、下記のように行う。
記
（１）「x₁,x₂,...,x₂₂₄」をランダムに初期化する。
初期化値は、下記の「数１４」と仮定する。
記

（２）数１４を固定して、下記の「数１５」が最小となる「x₁」を探索する。
記

探索後の「x₁」の値を、下記の「数１６」と仮定する。
記

（３）下記の「数１７」を固定して、下記の「数１８」が最小になる「x₂」を探索する。
記

探索後の「x₂」の値を下記の「数１９」と仮定する。
記

第２に、上記のループを「Ｆ」が「０」になる、又は「タイムアウト」になるまで繰り返し実行する。
「タイムアウト」になっても「Ｆ」が「０」にならなければ「エラー」を出力する。
そうでなければ、「最終結果」を出力する。
その結果、「x₁,x₂,...,x₂₂₄」の値には、料理マスタ38に記憶された「料理コード」が割り振られる。すなわち、１４日間の３食の各料理の種類が決定され、「料理コード」を文字に変換して表示すると、図６に示すように、１４日間のメニューが決定される。

本「献立検索ステップ」は、第１メソッド及び第２メソッドを用いた判定に相当する。
具体的には、「献立検索ステップ」は、図１に示す条件判定部34を中心に実行される。

（材料費制約のモデリング）
材料費制約のモデリングは、次の通りである。
なお、次の（１）～（３）については後述する。
（１）材料費の制約の定義
（２）最小値と最大値との定義
（３）第２関数（数２２）及び第３関数（数２３）の計算

（材料費の制約の定義）
材料費の制約を表す下記の「数２０」に示す関数を、下記の「数２１」に示すように、定義し、「数２０」を「第１関数」という。
記

下記の「数２２」は、「日毎の材料費が指定された最小値と最大値の間に入らなければいけない」こと、及び「指定期間内の材料費の平均値が最小値と最大値の平均値を超えてはいけない」という条件を意味し、「第２関数」という。
上記「最小値」には、図４に示すように、例えば「献立原価」の「材料費」の「100」円が相当する。
前記「最大値」には、例えば「800」円が相当する。
前記「平均値」には、例えば「100 + 800 / 2 = 450」円が相当する。
記

下記の「数２３」は、指定期間内の材料費の平均値ができるだけ最小値と最大値の平均値に近くにする」という条件を意味し、「第３関数」という。
記

（最小値と最大値との定義）
下記の「式」の最小値を「LOWER_COST」、最大値を「UPPER_COST」と定義する。「MEAN_COST」は、「LOWER_COST」と「UPPER_COST」との「平均値」を意味する。
記
（式）MEAN_COST = (LOWER_COST + UPPER_COST) / 2
具体的には、「LOWER_COST」（最小値）は、図４に示すように、例えば「100」円が相当する（LOWER_COST = 100）。
「UPPER_COST」（最大値）には、例えば「800」円が相当する（UPPER_COST = 800）。
「MEAN_COST」（平均値）には、例えば「450」円が相当する（MEAN_COST = 450）。

（第２関数（数２２）及び第３関数（数２３）の計算）
第２関数（数２２）と第３関数（数２３）とは、下記のように計算される。
記
・「Ａ」で計算された第ｎ日目の材料費の合計が、「C_n」と仮定する。
・また、第ｎ日目の第ｉ目料理の材料費を、下記の「数２４」と仮定する。
記

そうすると、「C_n」が第ｎ日目の全ての料理の「数２４」の合計となる。
第ｎ日目の材料費に対する制約を、下記の「数２５」と表示する。
記

「ａ_n」、「ｂ_n」という二つの「変数」を定義する。
・「LOWER_COST < = C_n」の条件に一致している場合には、「ａ_n = 0」とする。
上記条件と不一致の場合には、「ａ_n = LOWER_COST - C_n」とする。

・「C_n <= UPPER_COST」の条件に一致している場合には、「ｂ_n = 0」とする。
上記条件と不一致の場合には、「ｂ_n = C_n - UPPER_COST」とする。

・上記「数２５」は、下記の「数２６」の「式」の通りである。
記

「Ｓ」が指定期間内の材料費の合計（つまり、「Ｓ」が「C_n」の合計）とすると、「数２２」に示す「第２関数」は、下記のように定義される。
記
・「MEAN_COST × 指定期間の日数> S」であれば、下記の「数２７」の合計と定義される。
記

・そうでなければ、下記の「数２８」の合計と定義される。
記

「数２３」に示す「第３関数」は、下記のように定義される。
記
・「S - (MEAN_COST - 15) × 指定期間の日数＞＝ 0」であれば、下記のように定義される。
記

・そうでなければ、下記の「数３０」と定義される。
記

（本システム10）
上記した構成を有する本システム10の作用・効果は、次の通りである。
特定給食施設における品数（皿数）は、喫食者の身体状況、身体機能、疾病種別、施設方針により異なり、一定ではない。品数が変化しても汎用性を持たせていることにより対応が可能である。
また、人間の思考でパターン化された料理の組み合わせ外の多様化された組み合わせが新たに生み出され、日本人の食事摂取基準２０１５（厚労省・令和元年９月５日現在）に基づき、栄養価の制限が理由で食べることができないと諦めていた方も希望を見いだせる食事が生み出されることが期待でき、栄養価の制限が理由で通常の料理から調味料配分を変化させて考案していた料理が一般の味覚を満たす通常の料理を提供することができることが期待される。

（給食のメニュー作成支援方法）
上記した構成を有する本システム10を用いた給食のメニュー作成支援方法には、次の工程を含む。
なお、次の（１）～（６）の工程については、後述する。
（１）条件受入工程
（２）条件モデリング工程
（３）メソッド記憶工程
（４）料理選択工程
（５）料理判定工程
（６）メニュー出力工程
なお、本方法として、（１）～（６）の工程を例示したが、これに限定されず、例えば「（５）料理判定工程」を省き、「（５）料理判定工程」の判定結果を、図２に示すサーバ30にそのまま送信し、サーバ30側において「（６）メニュー出力工程」を実行するようにしてもよい。

（条件受入工程）
条件受入工程は、利用者が設定した前記利用者設定条件を受け入れる工程である。
ここで、「条件受入工程」は、後述する実施の形態では「ステップ１」が相当する。

（条件モデリング工程）
条件モデリング工程は、受け入れた前記利用者設定条件を、一致・不一致の二択の解として出力し、第１メソッドとしてモデリングする工程である。
ここで、「条件モデリング工程」は、後述する実施の形態では「ステップ２．１」が相当する。

（メソッド記憶工程）
メソッド記憶工程は、前記第１メソッド、及び予めモデリング化された前記内部設定条件である第２メソッドを記憶可能な工程である。

（料理選択工程）
料理選択工程は、前記品目に１個の関数をそれぞれ割り当て、前記期間指定条件により設定された前記指定期間の複数の前記関数より関数群を構成し、前記関数群に属する前記関数毎に、料理マスタに記憶された料理群中から料理を選択する工程である。
ここで、「料理選択工程」は、後述する実施の形態では「ステップ２．２」が相当する。

（料理判定工程）
料理判定工程は、選択された前記料理について、記憶された前記第１メソッド及び前記第２メソッドを用いて判定する工程である。
ここで、「料理判定工程」は、後述する実施の形態では「ステップ３」が相当する。

（メニュー出力工程）
メニュー出力工程は、料理判定結果が全て前記一致の場合に、給食のメニュー作成支援データとして出力する工程である。
ここで、「メニュー出力工程」は、後述する実施の形態では「ステップ４」及び「ステップ５」が相当する。

（実施例１）
つぎに、本システム10の実施例１～１０について説明する。
まず、「実施例１」について説明する。
「実施例１」は、次の点を特徴とする。
第１に、メニュー条件受入部32には、都道府県別に定められた食品構成が記憶されている。
第２に、設定条件には、都道府県のうち一つを設定することで、メニュー条件受入部32に記憶された都道府県別に定められた食品構成条件として展開され、その結果、都道府県別の食品構成を満たす設定条件を含んでいる。
すなわち、利用者が、都道府県のうち一つを設定することで、メニュー条件受入部32に記憶された食品構成を満たす食品分類を含む料理が、料理マスタ38にある料理群より選択される。

具体的には、図１０～図１２に示すように、利用者が「利用者設定条件」の一つとして、都道府県のうち一つを、例えば選択することで設定できるようにしている。
まず、「食品構成」の欄の「利用」を選択すると、図５及び図１０に示すように、「利用せず」から「利用」に変化し、「食品構成数量設定」のボタンが有効（アクティブ）になる。「食品構成数量設定」のボタンを選択すると、図１１に示すように、「都道府県」の選択画面が表示される。「都道府県」の選択画面において、例えば「東京」を選択すると、図１２に示すように、「食品構成数量入力」が表示される。
以降、「東京」に適合した食品構成数量設定内にある料理群から料理が選択される。

（実施例１の課題・目的）
判定時に採用する食品は全て「食品分類（文部科学省公表日本食品標準成分表2015年版七訂追補2018より）」が登録されている（令和元年9月5日現在）。
一方、食品構成は都道府県毎に定められており、それぞれの食品構成に示される食品群名称も、食品分類もそれぞれが都道府県毎に異なる。

特定給食施設において、1日あたり食品群毎にどれだけ摂取する必要があるかという摂取目標量設定は「食品構成」である。この食品構成は各都道府県指定の食品構成の表示となっており、施設毎に喫食者の年齢、性別、生活活動レベル等を考慮して作成されるため、同一の値は存在しない。

これを満たすメニュー判定を行うために、利用者が判定時に都道府県を選択し、食品構成（食品群毎）の重量を登録することができる。この重量をおおよそ満たすことを目標に判定を行う。
健康増進法（厚労省）より、特定給食施設における栄養管理、健康増進法施行規則の栄養管理の基準に定められた事項を遵守することを考慮している。
なお、保険医療機関においては、上記に加えて日本人の食事摂取基準2015（厚労省）をベースとした院内約束食事箋における一般治療食（常食）の食品構成を、介護保険施設においては上記に加えて日本人の食事摂取基準2015（厚労省）をベースとした約束食事箋における一般食（入居者食）の食品構成を遵守することを考慮している。また、約束食事箋とは施設毎に定められているものである。
ここで、「日本人の食事摂取基準」とは、日本の厚生労働省が、健康な個人または集団を対象として、国民の健康の維持・増進、エネルギー・栄養素欠乏症の予防、生活習慣病の予防、過剰摂取による健康障害の予防を目的として制定したエネルギー及び各栄養素の摂取量の基準をいう。

（健康増進法の一部引用）
参考として、「健康増進法」の第２１条には、下記の通り規定されている。
記
（特定給食施設における栄養管理）
第２１条特定給食施設であって特別の栄養管理が必要なものとして厚生労働省令で定めるところにより都道府県知事が指定するものの設置者は、当該特定給食施設に管理栄養士を置かなければならない。
２前項に規定する特定給食施設以外の特定給食施設の設置者は、厚生労働省令で定めるところにより、当該特定給食施設に栄養士又は管理栄養士を置くように努めなければならない。
３特定給食施設の設置者は、前２項に定めるもののほか、厚生労働省令で定める基準に従って、適切な栄養管理を行わなければならない。

（健康増進法施行規則（厚生労働省令）の一部引用）
参考として、「健康増進法施行規則」（厚生労働省令）の第９条には、下記の通り規定されている。
記
（栄養管理の基準）
第９条法第２１条第３項の厚生労働省令で定める基準は、次のとおりとする。
１当該特定給食施設を利用して食事の供給を受ける者（以下「利用者」という。）の身体の状況、栄養状態、生活習慣等（以下「身体の状況等」という。）を定期的に把握し、これらに基づき、適当な熱量及び栄養素の量を満たす食事の提供及びその品質管理を行うとともに、これらの評価を行うよう努めること。
２食事の献立は、身体の状況等のほか、利用者の日常の食事の摂取量、嗜好等に配慮して作成するよう努めること。
３献立表の掲示並びに熱量及びたんぱく質、脂質、食塩等の主な栄養成分の表示等により、利用者に対して、栄養に関する情報の提供を行うこと。
４献立表その他必要な帳簿等を適正に作成し、当該施設に備え付けること。
５衛生の管理については、食品衛生法（昭和２２年法律第２２３号）その他関係法令の定めるところによること。

なお、本システム10は、次の「医療関連サービス振興会」の審査内容を充たすように各種機能において配慮している。
すなわち、食事提供においての最も多種多様に及ぶ厳重な管理が必要な保険医療機関における給食の提供を企業が行うための信頼を得るために第三者機関である「医療関連サービス振興会」における指定サービス認定者（医療に係る業務を業務委託する場合の企業基準は医療法に定められている。）と成るべく、基準を充たすことが保険医療機関からの信頼・信用を得る最も近道であり、しいては医療に適合する給食等サービス事業者の認定は介護保険施設へも同様の信頼・信用を得られるものと考えている。

（実施例２）
本システム10の「実施例２」について説明する。
「実施例２」は、次の点を特徴とする。
第１に、料理マスタ38に記憶される料理群には、料理として、和食料理と洋食料理とを少なくとも含む和洋折衷である複数の一般料理と、一般料理以外であって、日本人の文化に根付いた複数の「特定日本料理」と、が含まれる。
ここで、「和食料理と洋食料理とを少なくとも含む」とは、それ以外に「多国籍料理」を含んでいてもよいという意味である。
ここで、「特定日本料理」には、例えば「スシ」、「ソバ」、「天ぷら」等がある。

第２に、内部設定条件には、一食に含まれる複数の品目の１個として、特定日本料理が選択された場合に、一食の残りの品目を、一般料理に含まれる和食料理から選択する日本料理選択条件が含まれている。
ここで、「和食料理」は、図８に示すように、「風味」として「和風」として記憶されている。なお、「風味」としては、「和風」のほか、「洋風」、「中華」等が設定可能である。

（実施例２の課題・目的）
一般に特定給食施設における食事内容は、「和洋折衷」が一般的であり、「五感を刺激し満たす料理の構成」でバラエティに富んだものを提供することが多いが、特定給食施設で長期に渡り喫食する場合個人の嗜好通りの食事ではないために、食への希望を見失われることも少なくない。

日本人であれば本能的に好まれる「代表的な日本食（和食）」に関しては、代表的なもの（例えば、スシ、ソバ、天ぷら等）が選択された場合に、その料理構成は全て和風の料理で構成されるようにしている。
なお、本出願人は、1990年代から保険医療機関、介護保険施設で、「手打ち蕎麦、握り寿司」を提供した給食会社である。「（食事時間が）早い」「不味い」「冷たい」という病院給食のイメージを変えるべく、代表的な日本食（和食）の提供にこだわり続けてきた。これらを代表的な日本食を特定給食施設で提供できることは喜びに繋がり、当該サービスの提供を未来永劫受け継いでいく必要があるものとして、本システム10の構成の一つとして採用している。

ユネスコ無形文化遺産に和食が登録されたことが全てであるように、日本人であれば誰しもが本能的に「食べたい」と思う料理の一つである。
介護保険施設においては人生の幕が閉じるまでの時間を過ごされる方も多く、外出・外食が不可能となった方々が「食べたい」と思い浮かべる我が国の伝統的な食文化（和食）を特定給食施設でも、日常の中で食することができることを保持することへの考慮と特定給食施設でも、日本の食文化に触れることで「思い出す」「忘れない」ためである。

（実施例３）
本システム10の「実施例３」について説明する。
「実施例３」は、料理マスタ38に記憶される料理群には、通常の定食スタイルと異なる「特別指定料理」が含まれている、ことを特徴とする。
ここで、「特別指定料理」には、例えば「麺類」、「丼物」等がある。

「特別指定料理」については、図３に示すように、利用者設定条件の一つとして、「麺の日設定」、「丼の日設定」として、曜日、及び食事の種類、例えば三食の別を個別に設定できるようになっている。

（実施例３の課題・目的）
ここで、「通常の定食スタイル」とは、異なる「特別指定料理」として「麺類、丼物」等がある。
「特別指定料理」は、厨房（調理場）における盛付業務が通常よりも複雑なものとなり、かつ喫食者への配膳手順も特殊なものとなる。
「特別指定料理」は喫食者の身体状況、身体機能、疾病の種別等を考慮した複雑難解な食事提供のシステムが必要となる。更に特別指定料理は多くの方に好まれ期待されることが多い。

「特別指定料理」を、日常のルーティーンとして混乱なく美味しさを失わずに提供するために、特定給食施設では週に１度提供曜日を固定している。
これにより、温度管理、喫食者に配膳されるまでの時間計測が肝となる（特に「麺類」）が提供曜日の固定化を可能にすることで各部門の人員体制を整え、メニューを個性化させ、喫食者への楽しみを提供し、一番大切な美味しさの確保に繋げることが可能となる。
日常の定食スタイルから変化を加えた食事の定期提供が行え、喫食者への満足に繋がる時間を提供できる。献立を変化に富ませ、個性化させることができる。

（実施例４）
本システム10の「実施例４」について説明する。
「実施例４」は、次の点を特徴とする。
第１に、利用者設定条件には、一食のメニュー原価の入力値であるメニュー原価条件と、期間指定条件のうちの一食を年中行事実施時のイベント食として指定するイベント食設定条件と、イベント食設定条件で指定されたイベント食の材料費の入力値であるイベント食材料費条件と、を含む。

「メニュー原価条件」については、図４に示すように、「献立原価」として、「材料費」の上限値と下限値とを設定できるようにしている。

「イベント食設定条件」については、図５に示すように、指定期間のうち、日付及び食事の種類、例えば三食の別を設定できるようにしている。
「イベント食材料費条件」については、図５に示すように、イベント食毎に、「イベント時の材料費」を個別に入力できるようにしている。
例えば、「イベント時の材料費」として、図５に示すように、「５／２１」の「火」において、「昼」に「４００」円と入力している。

第２に、条件モデリング部は、メニュー条件受入部を介して受け入れたメニュー原価条件を、一致・不一致の二択の解として出力する第３メソッドとしてモデリングするとともに、メニュー条件受入部を介してイベント食材料費条件が受け入れられた場合に、メニュー原価条件からイベント食材料費条件を除外し、第４メソッドとしてモデリング化する。

第３に、メソッド記憶部は、第３メソッド及び第４メソッドを記憶する。
第４に、条件判定部34は、メソッド記憶部に記憶された第３メソッド及び第４メソッドを用いて判定している。
条件判定部34による判定の結果、図６に示すように、給食のメニューがカレンダー形式により表示され、このとき、「５／２１」の「火」において「昼」は、「空白」となり、当日は「昼」に「イベント食」が提供される。

（実施例４の課題・目的）
特定給食施設のうち、保険医療機関においては患者給食を喫食者の方は、入院時食事療養費等を自己負担いただくが、年中行事実施時のイベント食提供時が実施されても、追加料金をいただくことなくお楽しみいただくために、年中行事実施時のイベント食提供があっても他の食事でバランスを取るようにメニュー判定も行うことを可能にしており、その方針は施設により異なる為、あらゆる条件にも対応できるよう、汎用性を持たせている。

同時に指定栄養素についても、あくまで許容範囲内ではあるが、通常の厳重な栄養管理から許容範囲内で年中行事実施時のイベント食の献立を考案し、前後で栄養価の過不足を調整できるように判定を行う。
これにより、四季の移り変わりを楽しむ日本の年中行事に係る食文化を特定給食施設の食事を通じて生きることへの楽しみを感じてもらうことを目的としている。

（実施例５）
実施例５は、カット野菜の採用（なし・あり）の設定についてである。
施設における、調理場（厨房）の環境や人員に応じた適切なメニュー判定を実施するために、下処理済である「カット野菜（千切り人参、みじん切りたまねぎ、たけのこ短冊切り5mm、など）」を採用した料理の使用有無を利用者が自由に選択できる仕組みを採用している。
労働者人口の減少に伴う日本の来るべき未来に備え、汎用性ある機能とした。

（実施例５の課題・目的）
実施例５は、日々のメニュー内容に応じて調理従事者の業務量が偏らないように考慮しており、メニューが指定の時間に安定提供することを目的としている。

（実施例６）
実施例６は、栄養補助食品・強化食品の採用（なし・あり）の設定についてである。
保険医療機関（関連法規上の病院・医院の表現名称）や介護保険施設などの特定給食施設における食事内容は、喫食者の身体状況、身体機能、疾病に基づき、食事摂取基準2015年版（令和元年9月5日現在として、令和2年4月1日より食事摂取基準2020年版へ切替予定）と約束食事箋、各施設基準に則った食事が必要であるが、特定の栄養素について、通常よりも制限や補給が必要な場合に、特定の食材に頼りがちになる場合がある。
そのため、栄養補助、強化食品を採用することにより、平常時の食事内容と大きくかけ離れることのない内容となるように考慮している。

（実施例６の課題・目的）
実施例６は、特定給食施設における食事は、喫食中に食教育を行うこともひとつの目的であるために、食教育が必要な喫食者（患者、入居、入所者）の生活環境、経済状況に応じた食事内容となるように、汎用性があることを目的としている。

（実施例７）
実施例７は、指定栄養素設定（１日、１週間）についてである。
保険医療機関、介護保険施設等の特定給食施設における給食は、日本人の食事摂取基準2015年版（厚労省）、約束食事箋・食品構成表（各施設毎算出、作成）を基準としている。1日毎にこの基準値を下回らない値、又は完全一致するメニュー（献立）作成を行う必要があるが、当該施設における喫食者（患者、入所、入居者）の大半は1週間以内の短期間の食事摂取者は極めて少ない。
文中、基準値や成分表情報は、本書作成時、令和１年９月５日現在のものである。
そのため、１日分として基準を満たす必要がある栄養素、1週間平均で基準を満たす必要がある栄養素基準値を利用者が施設特性に応じて設定できる仕様とした。

（実施例７の課題・目的）
実施例７は、治療や教育、身体機能を良好に保つことを目的とした食事、毎日の生活を送る食事が変化に富み、指定栄養素に縛られすぎない食事となる。

（実施例８）
実施例８は、判定実行回数の設定についてである。
指定条件、期間における判定が1度に最大５種まで同時判定する仕組みを採用している。これは判定時のユーザーが「ＡＩ」の結果から自由にセレクトすることが可能であることを目的とし、判定時にAIだけでは決定付けられない選択を最後に人間が実施する猶予を与えている。

（実施例８の課題・目的）
実施例８は、ＡＩが提案する内容に頼り切らず、その時に最適と見なすメニューを最終的に選出することができ、“これしかない”という状態は作らないように工夫している。

（実施例９）
実施例９は、料理の温度帯（保温、保冷料理数の考慮）についてである。
１食の食事内容の料理の温度帯が「保冷」「保温」をバランスよく構成させるために、ユーザーが設定しなくとも内部で温度構成も考慮した料理の組み合わせとなるような仕様としている（１食のうち、保冷料理は最低でも１品を含み、最大でも２品までとする）。

（実施例９の課題・目的）
実施例９は、人間の味覚と温度の関係でも一般的に実証されているように、体温の＋－２５～３５度、つまり温かい物は６０～７０度前後、冷たい物であれば０～１０度前後の温度帯が“おいしい”という気持ちになるため、多種多様な温度帯の料理を組み合わせることにより、満足度の高い食事を召し上がっていただくことへの考慮を目的とする。

10 給食のメニュー作成支援システム
20 通信端末
30 サーバ
31 メニュー判定条件
32 メニュー条件受入部
33 条件モデリング部
34 条件判定部
35 メニュー出力部
36 メニュー判定結果

Claims

メニューの採否を判定するメニュー判定条件には、
利用者が設定可能な複数の利用者設定条件と、
前記利用者設定条件と異なり、利用者が設定不能であり、内部的に設定された複数の内部設定条件とを含み、
前記利用者設定条件には、
一食当たりの品目の個数、及び各品目の食事の種類を選択可能な食事設定条件と、
一日の食事には朝食、昼食、夕食の三食を少なくとも含み、前記三食を一日として、メニューを作成する指定期間を設定する期間指定条件と、
を含み、
利用者が設定した前記利用者設定条件を受け入れ可能なメニュー条件受入部と、
前記メニュー条件受入部が受け入れた前記利用者設定条件を、一致・不一致の二択の解として出力し、第１メソッドとしてモデリングする条件モデリング部と、
前記条件モデリング部によりモデリングされた前記第１メソッド、及び予めモデリング化された前記内部設定条件である第２メソッドを記憶可能なメソッド記憶部と、
前記品目に１個の関数をそれぞれ割り当て、前記期間指定条件により設定された前記指定期間の複数の前記関数より関数群を構成し、前記関数群に属する前記関数毎に、料理マスタに記憶された料理群中から料理を選択する料理選択部と、
前記料理選択部により選択された前記料理について、前記メソッド記憶部に記憶された前記第１メソッド及び前記第２メソッドを用いて判定する条件判定部と、
前記条件判定部による判定結果が全て前記一致する場合に、給食のメニュー作成支援データとして出力するメニュー出力部と、
を備えていることを特徴とする給食のメニュー作成支援システム。
前記条件判定部は、
数理計画問題を解くことにより、前記第１メソッド及び前記第２メソッドを判定している、
ことを特徴とする請求項１に記載の給食のメニュー作成支援システム。
前記メニュー条件受入部には、
都道府県別に定められた食品構成が記憶され、
前記利用者設定条件には、
前記都道府県のうち一つを設定することで、前記メニュー条件受入部に記憶された前記都道府県別に定められた食品構成条件として展開され、その結果、前記都道府県別の前記食品構成を満たす設定条件を含んでいる、
ことを特徴とする請求項１又は請求項２に記載の給食のメニュー作成支援システム。
前記料理マスタに記憶される前記料理群には、
前記料理として、和食料理と洋食料理とを少なくとも含む和洋折衷である複数の一般料理と、
前記一般料理以外であって、日本人の文化に根付いた複数の特定日本料理と、
が含まれ、
前記内部設定条件には、
前記一食に含まれる複数の前記品目の１個として、前記特定日本料理が選択された場合に、前記一食の残りの前記品目を、前記一般料理に含まれる和食料理から選択する日本料理選択条件が含まれている、
ことを特徴とする請求項１～請求項３のいずれか１項に記載の給食のメニュー作成支援システム。
前記料理マスタに記憶される前記料理群には、
通常の定食スタイルと異なる特別指定料理が含まれている、
ことを特徴とする請求項１～請求項４のいずれか１項に記載の給食のメニュー作成支援システム。
前記利用者設定条件には、
前記一食のメニュー原価の入力値であるメニュー原価条件と、
前記期間指定条件のうちの前記一食を年中行事実施時のイベント食として指定するイベント食設定条件と、
前記イベント食設定条件で指定された前記イベント食の材料費の入力値であるイベント食材料費条件と、
を含み、
前記条件モデリング部は、
前記メニュー条件受入部を介して受け入れた前記メニュー原価条件を、一致・不一致の二択の解として出力する第３メソッドとしてモデリングするとともに、
前記メニュー条件受入部を介して前記イベント食材料費条件が受け入れられた場合に、前記メニュー原価条件から前記イベント食材料費条件を除外し、第４メソッドとしてモデリング化し、
前記メソッド記憶部は、
前記第３メソッド及び前記第４メソッドを記憶し、
前記条件判定部は、
前記メソッド記憶部に記憶された前記第３メソッド及び前記第４メソッドを用いて判定している、
ことを特徴とする請求項１～請求項５のいずれか１項に記載の給食のメニュー作成支援システム。
コンピュータが実行する給食のメニュー作成支援方法であって、
メニューの採否を判定するメニュー判定条件には、
利用者が設定可能な複数の利用者設定条件と、
前記利用者設定条件と異なり、利用者が設定不能であり、内部的に設定された複数の内部設定条件とを含み、
前記利用者設定条件には、
一食当たりの品目の個数、及び各品目の食事の種類を選択可能な食事設定条件と、
一日の食事には朝食、昼食、夕食の三食を少なくとも含み、前記三食を一日として、メニューを作成する指定期間を設定する期間指定条件と、
を含み、
利用者が設定した前記利用者設定条件を受け入れる条件受入工程と、
受け入れた前記利用者設定条件を、一致・不一致の二択の解として出力し、第１メソッドとしてモデリングする条件モデリング工程と、
前記第１メソッド、及び予めモデリング化された前記内部設定条件である第２メソッドを記憶可能なメソッド記憶工程と、
前記品目に１個の関数をそれぞれ割り当て、前記期間指定条件により設定された前記指定期間の複数の前記関数より関数群を構成し、前記関数群に属する前記関数毎に、料理マスタに記憶された料理群中から料理を選択する料理選択工程と、
選択された前記料理について、記憶された前記第１メソッド及び前記第２メソッドを用いて判定する料理判定工程と、
料理判定結果が全て前記一致する場合に、給食のメニュー作成支援データとして出力するメニュー出力工程と、
を含むことを特徴とする給食のメニュー作成支援方法。