特開 2022-11077 情報処理方法、プログラム、情報処理装置及び学習モデルの生成方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022011077

(43)【公開日】2022-01-17

(54)【発明の名称】情報処理方法、プログラム、情報処理装置及び学習モデルの生成方法

(51)【国際特許分類】

   G06Q 30/06 20120101AFI20220107BHJP

   G06N 20/00 20190101ALI20220107BHJP

   G06Q 30/02 20120101ALI20220107BHJP

【ＦＩ】

G06Q30/06 330

G06N20/00

G06Q30/02 300

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2020111965

(22)【出願日】2020-06-29

(71)【出願人】

【識別番号】000253503

【氏名又は名称】キリンホールディングス株式会社

(74)【代理人】

【識別番号】100114557

【弁理士】

【氏名又は名称】河野 英仁

(74)【代理人】

【識別番号】100078868

【弁理士】

【氏名又は名称】河野 登夫

(72)【発明者】

【氏名】岡田 理志

(72)【発明者】

【氏名】太田 惣介

(72)【発明者】

【氏名】川橋 綾乃

(72)【発明者】

【氏名】黒川 雄司

(72)【発明者】

【氏名】森木 博之

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049BB02

5L049BB08

5L049BB53

(57)【要約】

【課題】顧客に適切なビール飲料を提案する情報処理方法等を提供すること。
【解決手段】一つの側面に係る情報処理方法は、顧客の属性を取得し、前記顧客から複数の質問に対する回答を取得し、取得した顧客の属性及び複数の回答を入力した場合に提案すべきビール、発泡酒、新ジャンルビールまたはビールテイスト飲料を含むビール飲料に関するビール情報を出力する学習モデルに、前記顧客の属性及び複数の回答を入力して提案すべきビール飲料に関するビール情報を出力し、出力したビール情報に基づき提案したビール飲料の履歴を前記顧客に対応付けて記憶し、前記履歴に基づき、前記顧客に対して提案するビール飲料を変更することを特徴とする。
【選択図】図１

【特許請求の範囲】

【請求項1】

顧客の属性を取得し、
前記顧客から複数の質問に対する回答を取得し、
取得した顧客の属性及び複数の回答を入力した場合に提案すべきビール、発泡酒、新ジャンルビールまたはビールテイスト飲料を含むビール飲料に関するビール情報を出力する学習モデルに、前記顧客の属性及び複数の回答を入力して提案すべきビール飲料に関するビール情報を出力し、
出力したビール情報に基づき提案したビール飲料の履歴を前記顧客に対応付けて記憶し、
前記履歴に基づき、前記顧客に対して提案するビール飲料を変更する
情報処理方法。

【請求項2】

前記学習モデルを通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致する場合、該ビール飲料とは異なるビール飲料に変更する
請求項１に記載の情報処理方法。

【請求項3】

前記学習モデルは、ビール飲料の特性を示す複数の特性値を出力し、
ビール飲料に対応付けて複数の特性値を記憶した記憶部を参照して、前記学習モデルから出力された複数の特性値との類似度が高いビール飲料を抽出する
請求項１または２に記載の情報処理方法。

【請求項4】

前記学習モデルを通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致する場合、次に類似度が高いビール飲料に変更する
請求項３に記載の情報処理方法。

【請求項5】

前記学習モデルを通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致し、かつ、前記ビール飲料のフィードバック結果が否定を示している場合、異なるビール飲料に変更する
請求項１から４のいずれか一つに記載の情報処理方法。

【請求項6】

各ビール飲料は、各ビール飲料の複数の特性値に基づく教師なし学習により、複数のカテゴリに分類されており、
前記学習モデルを通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致する場合、該ビール飲料と同一カテゴリに属するビール飲料を抽出する
請求項１から５のいずれか一つに記載の情報処理方法。

【請求項7】

顧客の属性を取得し、
前記顧客から複数の質問に対する回答を取得し、
取得した顧客の属性及び複数の回答を入力した場合に提案すべきビール、発泡酒またはビールテイスト飲料を含むビール飲料に関するビール情報を出力する学習モデルに、前記顧客の属性及び複数の回答を入力して提案すべきビール飲料に関するビール情報を出力し、
出力したビール情報に基づき提案したビール飲料の履歴を前記顧客に対応付けて記憶し、
前記履歴に基づき、前記顧客に対して提案するビール飲料を変更する
処理をコンピュータに実行させるプログラム。

【請求項8】

顧客の属性を取得する第１取得部と、
前記顧客から複数の質問に対する回答を取得する第２取得部と、
取得した顧客の属性及び複数の回答を入力した場合に提案すべきビール、発泡酒またはビールテイスト飲料を含むビール飲料に関するビール情報を出力する学習モデルに、前記顧客の属性及び複数の回答を入力して提案すべきビール飲料に関するビール情報を出力する出力部と、
出力したビール情報に基づき提案したビール飲料の履歴を前記顧客に対応付けて記憶する記憶部と、
前記履歴に基づき、前記顧客に対して提案するビール飲料を変更する変更部と
を備えることを特徴とする情報処理装置。

【請求項9】

顧客の属性及び複数の質問に対する回答と、提案すべきビール、発泡酒またはビールテイスト飲料を含むビール飲料に関するビール情報と、提案したビール情報に対する前記顧客のフィードバックとを含む第１訓練データを取得し、
顧客の属性及び複数の質問に対する回答と、属性及び複数の回答を入力した場合にビール情報を出力する学習モデルから出力されるビール情報が、前記顧客に前記学習モデルによって既に提案したビール情報と一致した場合に変更されたビール情報と、変更された該ビール情報に対する前記顧客のフィードバックとを含む第２訓練データと取得し、
前記第１訓練データ及び第２訓練データを用いて前記学習モデルを生成する
処理をコンピュータに実行させる学習モデルの生成方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理方法、プログラム、情報処理装置及び学習モデルの生成方法に関する。

【背景技術】

【0002】

特許文献１には、顧客が商品（例えば、日本酒）を指定するための言語データを解析し、商品に関する情報を記憶する記憶部に記憶された商品の中から顧客にレコメンド（提案）する商品を出力することを特徴とするレコメンド装置が開示されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１９－１３９６６３号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、特許文献１に係る発明は、過去の提案履歴を参照せず、顧客に前回提案した商品を再度提案するおそれがある。

【0005】

一つの側面では、顧客に適切なビール飲料を提案する情報処理方法等を提供することにある。

【課題を解決するための手段】

【0006】

一つの側面に係る情報処理方法は、顧客の属性を取得し、前記顧客から複数の質問に対する回答を取得し、取得した顧客の属性及び複数の回答を入力した場合に提案すべきビール、発泡酒、新ジャンルビールまたはビールテイスト飲料を含むビール飲料に関するビール情報を出力する学習モデルに、前記顧客の属性及び複数の回答を入力して提案すべきビール飲料に関するビール情報を出力し、出力したビール情報に基づき提案したビール飲料の履歴を前記顧客に対応付けて記憶し、前記履歴に基づき、前記顧客に対して提案するビール飲料を変更することを特徴とする。

【発明の効果】

【0007】

一つの側面では、顧客に適切なビール飲料を提案することが可能となる。

【図面の簡単な説明】

【0008】

【図1】ビール飲料の提案システムの概要を示す説明図である。

【図2】サーバの構成例を示すブロック図である。

【図3】顧客ＤＢのレコードレイアウトの一例を示す説明図である。

【図4】店舗ＤＢのレコードレイアウトの一例を示す説明図である。

【図5】商品ＤＢのレコードレイアウトの一例を示す説明図である。

【図6】履歴ＤＢのレコードレイアウトの一例を示す説明図である。

【図7】情報収集ＤＢのレコードレイアウトの一例を示す説明図である。

【図8】端末の構成例を示すブロック図である。

【図9】ビール飲料の提案システムの処理動作を示す機能ブロック図である。

【図10】ビール情報出力モデルを説明する説明図である。

【図11】提案すべきビール飲料とは異なるビール飲料に変更する際の処理手順を示すフローチャートである。

【図12】提案すべきビール飲料とは異なるビール飲料に変更する際の処理手順を示すフローチャートである。

【図13】ビール飲料を提案するサブルーチンの処理手順を示すフローチャートである。

【図14】端末で顧客の属性を受け付ける画面の一例を示す説明図である。

【図15】端末で複数の質問に対する回答を受け付ける画面の一例を示す説明図である。

【図16】変更前のビール飲料を表示する画面の一例を示す説明図である。

【図17】変更後のビール飲料を表示する画面の一例を示す説明図である。

【図18】ビール飲料のフィードバック結果を受け付ける際の処理手順を示すフローチャートである。

【図19】フィードバック結果に基づいてビール飲料を変更する際の処理手順を示すフローチャートである。

【図20】端末でフィードバックを受け付ける画面の一例を示す説明図である。

【図21】実施形態３のサーバの構成例を示すブロック図である。

【図22】カテゴリ分類ＤＢのレコードレイアウトの一例を示す説明図である。

【図23】同一カテゴリに属するビール飲料に変更する際の処理手順を示すフローチャートである。

【図24】ビール情報出力モデルの更新処理の手順を示すフローチャートである。

【発明を実施するための形態】

【0009】

以下、本発明をその実施形態を示す図面に基づいて詳述する。

【0010】

（実施形態１）
実施形態１は、ビール飲料の提案履歴に基づいて、該ビール飲料とは異なるビール飲料に変更する形態に関する。ビール飲料は、ビール、発泡酒、新ジャンル及びビールテイスト飲料等を含む。新ジャンル（第三のビール）は、麦芽比率５０％未満の発泡酒に麦由来のスピリッツを加えたもの、または、糖類、ホップ、水及び麦芽以外のもの（穀物等政令で定めるもの）を原料として発酵させたもの等である。なお、本実施形態では、ビール飲料の例を説明するが、ワイン、日本酒、焼酎、ウイスキー等の他の種類の飲料にも同様に適用される。

【0011】

図１は、ビール飲料の提案システムの概要を示す説明図である。本実施形態のシステムは、情報処理装置１及び情報処理端末２を含み、各装置はインターネット等のネットワークＮを介して情報の送受信を行う。

【0012】

情報処理装置１は、種々の情報に対する処理、記憶及び送受信を行う情報処理装置である。情報処理装置１は、例えばサーバ装置、パーソナルコンピュータまたは汎用のタブレットＰＣ（パソコン）等である。本実施形態において、情報処理装置１はサーバ装置であるものとし、以下では簡潔のためサーバ１と読み替える。

【0013】

情報処理端末２は、顧客の属性及び複数の質問に対する回答の受付、並びに、提案されたビール飲料の受信及び表示等を行う端末装置である。情報処理端末２は、例えばスマートフォン、携帯電話、アップルウォッチ（Apple Watch:登録商標）等のウェアラブルデバイス、タブレット、パーソナルコンピュータ端末等の情報処理機器である。以下では簡潔のため、情報処理端末２を端末２と読み替える。

【0014】

本実施形態に係るサーバ１は、顧客の属性、及び顧客から複数の質問に対する回答を端末２から取得する。サーバ１は、取得した顧客の属性及び複数の回答を入力した場合に提案すべきビール、発泡酒またはビールテイスト飲料を含むビール飲料に関するビール情報を出力する学習モデルに、顧客の属性及び複数の回答を入力して提案すべきビール飲料に関するビール情報を出力する。

【0015】

サーバ１は、学習モデルにより出力したビール情報に基づいてビール飲料を提案し、提案したビール飲料の履歴を顧客に対応付けて記憶する。サーバ１は、顧客に提案したビール飲料が、前回提案したビール飲料と一致するか否かを判定する。サーバ１は、顧客に提案したビール飲料が、前回提案したビール飲料と一致すると判定した場合、該ビール飲料とは異なるビール飲料に変更する。

【0016】

図２は、サーバ１の構成例を示すブロック図である。サーバ１は、制御部１１、記憶部１２、通信部１３、入力部１４、表示部１５、読取部１６及び大容量記憶部１７を含む。各構成はバスＢで接続されている。

【0017】

制御部１１はＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を含み、記憶部１２に記憶された制御プログラム１Ｐを読み出して実行することにより、サーバ１に係る種々の情報処理、制御処理等を行う。なお、図２では制御部１１を単一のプロセッサであるものとして説明するが、マルチプロセッサであっても良い。

【0018】

記憶部１２はＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等のメモリ素子を含み、制御部１１が処理を実行するために必要な制御プログラム１Ｐ又はデータ等を記憶している。また、記憶部１２は、制御部１１が演算処理を実行するために必要なデータ等を一時的に記憶する。通信部１３は通信に関する処理を行うための通信モジュールであり、ネットワークＮを介して、端末２等との間で情報の送受信を行う。

【0019】

入力部１４は、マウス、キーボード、タッチパネル、ボタン等の入力デバイスであり、受け付けた操作情報を制御部１１へ出力する。表示部１５は、液晶ディスプレイ又は有機ＥＬ（electroluminescence）ディスプレイ等であり、制御部１１の指示に従い各種情報を表示する。

【0020】

読取部１６は、ＣＤ（Compact Disc）－ＲＯＭ又はＤＶＤ（Digital Versatile Disc）－ＲＯＭを含む可搬型記憶媒体１ａを読み取る。制御部１１が読取部１６を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、大容量記憶部１７に記憶しても良い。また、ネットワークＮ等を介して他のコンピュータから制御部１１が制御プログラム１Ｐをダウンロードし、大容量記憶部１７に記憶しても良い。さらにまた、半導体メモリ１ｂから、制御部１１が制御プログラム１Ｐを読み込んでも良い。

【0021】

大容量記憶部１７は、例えばＨＤＤ（Hard disk drive:ハードディスク）、ＳＳＤ(Solid State Drive:ソリッドステートドライブ)等の記録媒体を備える。大容量記憶部１７は、顧客ＤＢ（データベース：database）１７１、店舗ＤＢ１７２、商品ＤＢ１７３、履歴ＤＢ１７４、情報収集ＤＢ１７５及びビール情報出力モデル１７６を含む。顧客ＤＢ１７１は、顧客に関する情報を記憶している。店舗ＤＢ１７２は、店舗に関する情報を記憶している。商品ＤＢ１７３は、ビール飲料等の商品に関する情報を記憶している。履歴ＤＢ１７４は、顧客に提案したビール飲料の提案履歴を記憶している。情報収集ＤＢ１７５は、質問及びフィードバックに関する情報を記憶している。

【0022】

なお、本実施形態において記憶部１２及び大容量記憶部１７は一体の記憶装置として構成されていても良い。また、大容量記憶部１７は複数の記憶装置により構成されていても良い。更にまた、大容量記憶部１７はサーバ１に接続された外部記憶装置であっても良い。

【0023】

なお、本実施形態では、サーバ１は一台の情報処理装置であるものとして説明するが、複数台により分散して処理させても良く、または仮想マシンにより構成されていても良い。

【0024】

図３は、顧客ＤＢ１７１のレコードレイアウトの一例を示す説明図である。顧客ＤＢ１７１は、顧客ＩＤ列、ニックネーム列、パスワード列、メールアドレス列、性別列、年齢列、よく飲むお酒列、飲用頻度列、飲酒シーン列及び質問に対する回答列を含む。顧客ＩＤ列は、各顧客を識別するために、一意に特定される顧客のＩＤを記憶している。ニックネーム列は、顧客のニックネームを記憶している。パスワード列は、ログイン用のパスワードを記憶している。メールアドレス列は、顧客のメールアドレスを記憶している。性別列は、顧客の性別を記憶している。年齢列は、顧客の年齢を記憶している。

【0025】

よく飲むお酒列は、顧客がよく飲むお酒の種類を記憶している。飲用頻度列は、ビール飲料の飲用頻度を記憶している。飲用頻度は、例えば「1回/週」または「ほぼ毎日」等である。飲酒シーン列は、お酒を飲みたくなるシーン情報を記憶している。飲酒シーン列には、例えば「家飲み派」または「外飲み派」等が記憶されている。質問に対する回答列は、顧客への複数の質問に対する回答を記憶している。

【0026】

図４は、店舗ＤＢ１７２のレコードレイアウトの一例を示す説明図である。店舗ＤＢ１７２は、店舗ＩＤ列、店舗名称列、取扱商品ＩＤ列及び取扱開始日列を含む。店舗ＩＤ列は、各店舗を識別するために、一意に特定される店舗のＩＤを記憶している。店舗名称列は、店舗の名称を記憶している。取扱商品ＩＤ列は、店舗の取扱商品（提案対象となる商品）ＩＤを記憶している。取扱開始日列は、店舗が商品を取り扱った開始日を記憶している。

【0027】

図５は、商品ＤＢ１７３のレコードレイアウトの一例を示す説明図である。商品ＤＢ１７３は、商品ＩＤ列、商品種類列、銘柄列及び特性列を含む。なお、本実施形態では、商品がビール飲料である例として説明する。商品ＩＤ列は、各ビール飲料を識別するために、一意に特定されるビール飲料のＩＤを記憶している。商品種類列は、ビール飲料の種類を記憶している。ビール飲料の種類は、ビール、発泡酒、新ジャンル及びビールテイスト飲料を含む。

【0028】

ビールは、麦芽、ホップ及び水を原料として発酵させたものである。または、ビールは、麦芽、ホップ、水及び麦その他政令で定める物品を原料として発酵させたものであり、ただし、その原料中当該政令で定める物品の重量の合計が麦芽の重量の１００分の５０を超えないものに限る。発泡酒は、麦芽又は麦を原料の一部とした酒類で発泡性を有するものであり（アルコール分が２０％未満のもの）、ビールよりも麦芽の使用割合が少ない。新ジャンルは、その他の醸造酒とリキュールの２つに分類されている。その他の醸造酒（発泡性）は、穀類、糖類、その他の物品を原料として発酵させ、アルコール分２０％未満、エキス分２度以上の酒類である。リキュール（発泡性）は、麦芽比率５０％未満の発泡酒にスピリッツを加えたものでエキス分が２％以上のものである。ビールテイスト飲料は、アルコール分が含まれない、もしくは１％未満のアルコール分を含む飲料である。

【0029】

銘柄列は、ビール飲料のブランドを記憶している。特性列は、オリジナルエキス（ＯＥ）列、真正エキス（ＥＲ）列、真正発酵度（ＲＤＦ）列、外観エキス（ＡＥ）列、外観発酵度（ＡＤＦ）列及びアルコール分列を含む。

【0030】

オリジナルエキス列は、ビール飲料中のオリジナルエキス濃度を示す値を記憶している。真正エキス列は、ビール飲料中の真正エキス（可溶性蒸発残渣）の濃度を示す値を記憶している。真正発酵度列は、真正発酵度を示す値を記憶している。外観エキス列は、ビール飲料中の外観エキスの濃度を示す値を記憶している。外観発酵度列は、外観発酵度を示す値を記憶している。アルコール分列は、ビール飲料のアルコール度数を記憶している。

【0031】

なお、ビール飲料の特性に関しては、例示したオリジナルエキス、真正エキス、真正発酵度、外観エキス、外観発酵度及びアルコール分のほかに、他の特徴パラメータを含んでも良い。例えば特性には、外観最終発酵度、苦味価、エキス分、残存発酵度、ｐＨ、色度、酢酸エチル、n-プロパノール、イソブタノール、イソアミルアルコール、イソアミルアセテート、アミルアルコール、活性アミルアルコール、アセトアルデヒド、ダイアセチル、アミノ酸硫酸イオン、リン酸イオン、クエン酸、コハク酸、リンゴ酸、酢酸、乳酸、イソ酪酸、カプリル酸、カプリン酸、総ポリフェノール、βグルカン、濁度、泡持ち時間、炭酸ガス、リナロール、α酸、イソα酸、Ｓ‐フラクションの各分析値、使用される酵母（上面発酵酵母または下面発酵酵母）、商品名中に日本国内地域名が含まれるか否かの情報、または、麦芽、ホップ、小麦、糖類、香辛料、果物、野菜、米もしくは味噌を原材料として使用しているか否かの情報等の特徴パラメータがさらに含まれても良い。

【0032】

図６は、履歴ＤＢ１７４のレコードレイアウトの一例を示す説明図である。履歴ＤＢ１７４は、顧客ＩＤ列、提案ビール飲料ＩＤ列、フィードバック結果列及び提案日時列を含む。顧客ＩＤ列は、顧客を特定する顧客ＩＤを記憶している。提案ビール飲料ＩＤ列は、顧客に提案したビール飲料のビール飲料ＩＤを記憶している。フィードバック結果列は、提案されたビール飲料のフィードバック結果を記憶している。フィードバック結果は、例えばフィードバックの複数の項目に対する回答等である。提案日時列は、顧客にビール飲料を提案した日時情報を記憶している。

【0033】

図７は、情報収集ＤＢ１７５のレコードレイアウトの一例を示す説明図である。情報収集ＤＢ１７５は、管理ＩＤ列、種類列、問題ＩＤ列、問題列及び回答候補列を含む。管理ＩＤ列は、各情報収集用のデータを識別するために、一意に特定される情報収集用のデータのＩＤを記憶している。種類列は、情報収集用のデータ種類を記憶している。種類列には、例えば「質問」または「フィードバック」等が記憶されている。問題ＩＤ列は、顧客に対して提出する質問ＩＤまたはフィードバックの項目ＩＤを記憶している。問題列は、顧客に対して提出する質問またはフィードバックの項目を記憶している。回答候補列は、問題に対する回答の選択肢を記憶している。

【0034】

図８は、端末２の構成例を示すブロック図である。端末２は、制御部２１、記憶部２２、通信部２３、入力部２４及び表示部２５を含む。各構成はバスＢで接続されている。

【0035】

制御部２１はＣＰＵ、ＭＰＵ等の演算処理装置を含み、記憶部２２に記憶された制御プログラム２Ｐを読み出して実行することにより、端末２に係る種々の情報処理、制御処理等を行う。なお、図８では制御部２１を単一のプロセッサであるものとして説明するが、マルチプロセッサであっても良い。記憶部２２はＲＡＭ、ＲＯＭ等のメモリ素子を含み、制御部２１が処理を実行するために必要な制御プログラム２Ｐ又はデータ等を記憶している。また、記憶部２２は、制御部２１が演算処理を実行するために必要なデータ等を一時的に記憶する。

【0036】

通信部２３は通信に関する処理を行うための通信モジュールであり、ネットワークＮを介して、サーバ１等と情報の送受信を行う。入力部２４は、キーボード、マウスまたは表示部２５と一体化したタッチパネルでも良い。表示部２５は、液晶ディスプレイ又は有機ＥＬディスプレイ等であり、制御部２１の指示に従い各種情報を表示する。

【0037】

図９は、ビール飲料の提案システムの処理動作を示す機能ブロック図である。端末２は、顧客の属性の入力を受け付ける。顧客の属性は、性別、年齢、最もよく飲むお酒、ビール飲料の飲用頻度、飲酒シーン（例えば、家飲み派、外飲み派等）を含む。端末２は、予めサーバ１の情報収集ＤＢ１７５に記憶された複数の質問をサーバ１から取得し、取得した複数の質問を画面に表示する。

【0038】

質問は、顧客の属性に合うビール飲料を提案するための情報収集用の問題である。例えば、質問が「エスニック料理は好きですか？」、「日本酒は甘口派ですか？辛口派ですか？」、または「流行に敏感な方ですか？」等であっても良い。なお、本実施形態では、予めサーバ１の情報収集ＤＢ１７５に記憶された質問を端末２に送信したが、これに限るものではない。例えば、質問を予め端末２の記憶部２２に記憶しても良い。端末２は、顧客から複数の質問に対する回答の入力を受け付ける。

【0039】

端末２は、取得した顧客の属性及び複数の回答をサーバ１に送信する。サーバ１は、端末２から送信された顧客の属性及び複数の回答を受信して顧客ＤＢ１７１に記憶する。具体的には、サーバ１は顧客ＩＤを割り振って、ニックネーム、性別、年齢、よく飲むお酒、ビール飲料の飲用頻度、飲酒シーン及び複数の回答を一つのレコードとして顧客ＤＢ１７１に記憶する。

【0040】

サーバ１は、顧客の属性及び複数の回答を入力した場合に提案すべきビール、発泡酒またはビールテイスト飲料を含むビール飲料に関するビール情報を出力するビール情報出力モデル１７６に、受信した顧客の属性及び複数の回答を入力して提案すべきビール飲料に関するビール情報を出力する。ビール情報は、ビール飲料の特性を示す複数の特性値を含む。なお、ビール情報出力モデル１７６を用いてビール情報を出力する処理に関しては後述する。

【0041】

サーバ１は、ビール情報出力モデル１７６から出力されたビール情報に基づきビール飲料を提案する。具体的には、サーバ１は、ビール情報出力モデル１７６から出力されたビール飲料の複数の特性値と、商品ＤＢ１７３に記憶された各種のビール飲料に対応付けた複数の特性値との類似度を算出する。類似度の算出処理に関しては、例えば、ビール飲料の特性値をベクトル化し、ベクトル間距離を用いて算出する手法、k-means等のクラスタリング、またはコサイン類似度等、従来既知の手法を用いることができる。

【0042】

サーバ１は、類似度が最も高いビール飲料を今回提案するビール飲料として商品ＤＢ１７３から抽出する。なお、単純に類似度が高いビール飲料を抽出する処理に限るものではない。例えば、ビール飲料の登録日から指定期間内の、類似度が高いビール飲料を優先的に提案することができる。具体的には、類似度の所定閾値（例えば、７０％）が予め設けられた場合、サーバ１は、算出した類似度が所定閾値以上であるすべてのビール飲料ＩＤを商品ＤＢ１７３から取得する。サーバ１は、取得したビール飲料ＩＤに基づいて、店舗ＤＢ１７２から指定期間内のビール飲料を抽出する。指定期間とは、例えばビール飲料の取扱開始日（登録日）から３ヶ月以内等である。サーバ１は、抽出した指定期間内のビール飲料の中から類似度が最も高いビール飲料を抽出する。

【0043】

サーバ１は、抽出したビール飲料を顧客ＩＤに対応付けて履歴ＤＢ１７４に記憶する。具体的には、サーバ１は顧客ＩＤに対応付けて、抽出したビール飲料ＩＤ及び抽出日時を一つのレコードとして履歴ＤＢ１７４に記憶する。サーバ１は顧客ＩＤに基づいて、該顧客に前回提案したビール飲料を履歴ＤＢ１７４から取得する。サーバ１は、抽出したビール飲料が、前回提案したビール飲料と一致するか否かを判定する。

【0044】

サーバ１は、抽出したビール飲料が、前回提案したビール飲料と一致すると判定した場合、該ビール飲料とは異なるビール飲料に変更する。例えば、上述した類似度によるビール飲料提案の例として、該ビール飲料を次に類似度の高いビール飲料に変更する。なお、前回の提案日が所定期間（例えば、半年）以上前である場合、ビール情報出力モデル１７６を通じて顧客に提案するビール飲料を変更しなくても良い。

【0045】

なお、ビール飲料の変更処理に関しては、ビール飲料の特性値の類似度に限るものではない。例えば、ビール飲料と同じカテゴリに分類された複数のビール飲料の中から、人気ランキングが最上位であるビール飲料を抽出し、提案したビール飲料を抽出したビール飲料に変更しても良い。なお、上述した各種処理を端末２側で実行しても良い。

【0046】

サーバ１は、変更したビール飲料を今回提案するビール飲料として端末２に送信する。端末２は、サーバ１から送信されたビール飲料を受信して画面に表示する。なお、サーバ１は、抽出したビール飲料が、前回提案したビール飲料と一致していないと判定した場合、該ビール飲料を変更せずにそのままに端末２に送信する。

【0047】

続いて、ビール情報出力モデル１７６を用いてビール情報を出力する処理を説明する。図１０は、ビール情報出力モデル１７６を説明する説明図である。ビール情報出力モデル１７６は、人工知能ソフトウェアの一部であるプログラムモジュールとして利用される。ビール情報出力モデル１７６は、パラメータを学習済みの機械学習モデルである。例えばサーバ１は、顧客の属性及び複数の質問に対する回答を訓練データとして用い、ビール情報出力モデル１７６を生成（構築）する。訓練データは、顧客の属性と複数の回答に対し、ビール情報を関連付けて作成する組合せのデータである。

【0048】

図１０に示すように、サーバ１はビール情報出力モデル１７６として決定木モデルを生成する。例えばサーバ１は、アンサンブル学習の一種である勾配ブースティングの手法を用いてビール情報出力モデル１７６を生成する。すなわち、サーバ１は、訓練データを用いて一の弱識別器（決定木）を生成し、生成した弱識別器による予測値と実測値との誤差（正確には残差）に基づいて次の弱識別器を逐次生成していく。サーバ１は、前の弱識別器の学習結果を考慮するように、予測値と実測値との誤差によって定義される損失関数の勾配を参照して弱識別器を逐次生成し、最終的な識別器、すなわちビール情報出力モデル１７６を生成する。

【0049】

なお、上述した学習方法のほかに、例えば複数の弱識別器を並列的に生成するバギング等、その他のアンサンブル学習を行っても良い。また、アンサンブル学習以外の学習方法でビール情報出力モデル１７６を生成しても良い。例えばサーバ１は、ランダムフォレスト法を用いてビール情報出力モデル１７６を生成する。具体的には、サーバ１は訓練データからサンプリングされた学習データに基づいて、非終端ノードにおいて識別（分類）に用いる素性項目をランダムに選択することで、相関の低い複数の決定木を作成し、当該複数の決定木を用いてビール情報出力モデル１７６を生成する。

【0050】

なお、ビール情報出力モデル１７６に入力する入力データに対して次元削減が適用されても良い。

【0051】

上述の如く、サーバ１は、顧客の属性及び複数の質問に対する回答を訓練データとして用いて、ビール情報出力モデル１７６を生成する。また、本実施の形態では顧客の属性及び複数の質問に対する回答を訓練データとして用いるものとするが、これに限るものではない。例えば、気温、湿度、季節、日時、店舗が扱う食事のジャンル等の情報を訓練データに含めても良い。

【0052】

サーバ１は、顧客の属性及び複数の質問に対する回答を顧客ＤＢ１７１から取得し、訓練用の入力パラメータとして用いて、出力パラメータが正解値と近似するようにビール情報出力モデル１７６を生成する。ビール情報は、ビール飲料の特性を示す複数の特性値である。具体的には、サーバ１は、入力される顧客の属性及び複数の回答に対応付けたビール飲料の複数の特性値を正解値として、機械学習モデル（決定木モデル等）にパラメータを学習させることにより、ビール情報出力モデル１７６を生成する。

【0053】

サーバ１は、生成したビール情報出力モデル１７６を用いて、ビール飲料の複数の特性値を推定する推定結果を出力する。図示のように、顧客に対し、「オリジナルエキス」、「真正エキス」、「真正発酵度」、「外観エキス」、「外観発酵度」、「アルコール分」、「エキス分」、「残存発酵度」、「ｐＨ」、「色度」それぞれの値が、「１３．８」、「５．５」、「６０．５」、「３．８」、「７０．３」、「５％」、「２２．６」、「６．７」、「５．２」、「２６０」である推定結果が出力される。なお、出力層から出力される推定結果は上述した形式にかぎるものではない。例えば推定結果は、醸造所または副原料の使用有無を離散的に示す値（例えば「０」又は「１」の値）であっても良く、連続的な確率値（例えば「０」から「１」までの範囲の値）であっても良い。なお、上述したビール飲料の特性値を用いて説明したが、出力結果として他の特性値（例えば、酢酸エチル、イソブタノール、イソアミルアルコール等の値）の図示及び説明を省略する。

【0054】

また、顧客からのフィードバック結果に基づいて訓練データを作成し、作成した訓練データを用いてビール情報出力モデル１７６を再学習することができる。具体的には、サーバ１は、顧客ＩＤに基づいて履歴ＤＢ１７４から顧客のフィードバック結果を取得する。サーバ１は、取得したフィードバック結果（フィードバックの項目に対する回答）を分析し、顧客の好みに合わせたビール飲料ＩＤを抽出する。例えば、顧客に提案したビール飲料に対し、「お飲みになったビールの味はいかがですか？」であるフィードバックの項目に対する回答が、「美味しかった」または「とても美味しかった」である場合、サーバ１は該ビール飲料のビール飲料ＩＤを抽出する。または、顧客に提案したビール飲料に対し、「今飲んだビールは何杯目ですか？」であるフィードバックの項目に対する回答が、「３杯目以上」である場合、サーバ１は、該ビール飲料のビール飲料ＩＤを抽出する。

【0055】

サーバ１は、抽出したビール飲料ＩＤに基づいて、商品ＤＢ１７３からビール飲料の複数の特性値を読み出す。サーバ１は、読み出したビール飲料の複数の特性値を、顧客の属性及び複数の回答に対応付けて組合せの訓練データを作成する。サーバ１は、作成した訓練データを用いて、上述した学習処理と同様に、ビール情報出力モデル１７６を再学習する。なお、訓練データに関しては、「美味しかった」または「とても美味しかった」等の高い評価に対応するビール飲料の収集に限定せず、例えば「美味しくなかった」または「いまいち」等の低い評価に対応するビール飲料に基づいて作成されても良い。

【0056】

なお、本実施の形態ではビール情報出力モデル１７６が決定木であるものとして説明するが、ビール情報出力モデル１７６は決定木に限定されず、決定木以外のＣＮＮ（Convolutional Neural Network）、Ｒ－ＣＮＮ（Regions with Convolutional Neural Networks）、ＳＶＭ（Support Vector Machine）、ベイジアンネットワーク、または回帰木等の任意の学習アルゴリズムで構築された学習済みモデルであって良い。

【0057】

なお、本実施形態では、ビール情報出力モデル１７６から出力されたビール情報がビール飲料の複数の特性値である例を説明したが、これに限るものではない。例えば、ビール飲料に関するビール情報がビール飲料ＩＤであっても良い。すなわち、ビール情報出力モデル１７６に顧客の属性及び複数の回答を入力して、提案すべきビール飲料のビール飲料ＩＤを出力する。

【0058】

図１１及び図１２は、提案すべきビール飲料とは異なるビール飲料に変更する際の処理手順を示すフローチャートである。なお、顧客の基本情報（例えば、ニックネーム、メールアドレス等）が予め顧客ＤＢ１７１に登録される。具体的には、端末２は、受け付けた基本情報をサーバ１に送信する。サーバ１は、端末２から送信された基本情報を受信する。サーバ１は顧客ＩＤを割り振って、受信した基本情報を顧客ＩＤに対応付けて顧客ＤＢ１７１に記憶する。そして、登録済みの顧客に対し、ログイン処理を行う。

【0059】

端末２の制御部２１は、顧客がログイン済みであるか否かを判定する（ステップＳ２９１）。制御部２１は、顧客が既にログイン済みであると判定した場合（ステップＳ２９１でＹＥＳ）、後述するステップＳ２０１処理に遷移する。制御部２１は、顧客がログインしていないと判定した場合（ステップＳ２９１でＮＯ）、制御部２１は、顧客ＩＤ及びパスワードを含む認証情報を通信部２３によりサーバ１に送信する（ステップＳ２９２）。なお、認証情報に関しては、顧客ＩＤ及びパスワードに限定せず、例えば指紋認証または顔認証用の情報であっても良い。

【0060】

サーバ１の制御部１１は、端末２から送信された認証情報を通信部１３により受信する（ステップＳ１９１）。制御部１１は、受信した認証情報に基づいて認証処理を行い（ステップＳ１９２）、認証結果（ログイン成功、またはログイン失敗等）を通信部１３により端末２に送信する（ステップＳ１９３）。端末２の制御部２１は、サーバ１から送信された認証結果を通信部２３により受信する（ステップＳ２９３）。制御部２１は、受信した認証結果に基づいて、ログインに成功したか否かを判定する（ステップＳ２９４）。

【0061】

制御部２１は、ログインに成功していないと判定した場合（ステップＳ２９４でＮＯ）、ステップＳ２９１処理に遷移する。制御部２１は、ログインに成功したと判定した場合（ステップＳ２９４でＹＥＳ）、顧客の属性の入力を入力部２４により受け付ける（ステップＳ２０１）。なお、ログインによる顧客の属性の受付処理に限るものではない。例えば、ローカルストレージまたはクッキー等を利用して顧客の属性を取得することができる場合、顧客の属性の入力を省略しても良い。サーバ１の制御部１１は、大容量記憶部１７の情報収集ＤＢ１７５から複数の質問を取得する（ステップＳ１０１）。制御部１１は、取得した複数の質問を通信部１３により端末２に送信する（ステップＳ１０２）。

【0062】

端末２の制御部２１は、サーバ１から送信された複数の質問を通信部２３により受信し（ステップＳ２０２）、受信した複数の質問を表示部２５により表示する（ステップＳ２０３）。制御部２１は、顧客から複数の質問に対する回答の入力を入力部２４により受け付ける（ステップＳ２０４）。制御部２１は、顧客ＩＤと、受け付けた顧客の属性及び複数の回答とを通信部２３によりサーバ１に送信する（ステップＳ２０５）。

【0063】

サーバ１の制御部１１は、端末２から送信された顧客ＩＤ、顧客の属性及び複数の回答を通信部１３により受信する（ステップＳ１０３）。制御部１１は、受信した顧客の属性及び複数の回答を顧客ＩＤに対応付けて顧客ＤＢ１７１に記憶する（ステップＳ１０４）。制御部１１は、顧客の属性及び複数の回答を入力した場合に提案すべきビール、発泡酒またはビールテイスト飲料を含むビール飲料に関するビール情報を出力するビール情報出力モデル１７６を用いて、ビール情報を出力する（ステップＳ１０５）。制御部１１は、ビール情報出力モデル１７６から出力されたビール情報に基づきビール飲料を提案する（ステップＳ１０６）。なお、ビール飲料提案のサブルーチンについては後述する。

【0064】

制御部１１は、提案したビール飲料を顧客ＩＤに対応付けて履歴ＤＢ１７４に記憶する（ステップＳ１０７）。制御部１１は顧客ＩＤに基づいて、該顧客に前回提案したビール飲料を履歴ＤＢ１７４から取得し、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致するか否かを判定する（ステップＳ１０８）。制御部１１は、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致していないと判定した場合（ステップＳ１０８でＮＯ）、後述するステップＳ１１１処理に遷移する。

【0065】

制御部１１は、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致すると判定した場合（ステップＳ１０８でＹＥＳ）、該ビール飲料とは異なるビール飲料に変更する（ステップＳ１０９）。例えば制御部１１は、類似度に基づいてビール飲料を提案する場合、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料を次に類似度の高いビール飲料に変更する。制御部１１は、変更後のビール飲料を顧客ＩＤに対応付けて履歴ＤＢ１７４を更新する（ステップＳ１１０）。

【0066】

制御部１１は、提案したビール飲料を通信部１３により端末２に送信する（ステップＳ１１１）。端末２の制御部２１は、サーバ１から送信されたビール飲料を通信部２３により受信し（ステップＳ２０６）、受信したビール飲料を表示部２５により画面に表示する（ステップＳ２０７）。

【0067】

なお、本実施形態では、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が前回提案したビール飲料と一致する場合、異なるビール飲料に変更する例を説明したが、これに限るものではない。例えば、顧客に提案したビール飲料の履歴に基づいて、所定の連続回数（例えば、３回）同じビール飲料を提案した場合、該ビール飲料とは異なるビール飲料に変更しても良い。

【0068】

なお、上述した変更方式に限らず、例えば、杯数ごとに異なるビール飲料に変更しても良い。例えば、１杯目のビール飲料に対し、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料を次に類似度の高いビール飲料に変更する。２杯目のビール飲料に対し、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料を３番目に類似度の高いビール飲料に変更する。

【0069】

図１３は、ビール飲料を提案するサブルーチンの処理手順を示すフローチャートである。制御部１１は、例えばコサイン類似度を用いて、ビール情報出力モデル１７６から出力されたビール飲料の複数の特性値と、商品ＤＢ１７３に記憶された各種のビール飲料に対応付けた複数の特性値との類似度を算出する（ステップＳ１０）。制御部１１は、類似度の所定閾値（例えば、７０％）を記憶部１２から取得する（ステップＳ１１）。制御部１１は、算出した類似度が所定閾値以上であるすべてのビール飲料ＩＤを商品ＤＢ１７３から取得する（ステップＳ１２）。

【0070】

制御部１１は、取得したビール飲料ＩＤに基づいて、店舗ＤＢ１７２から指定期間内（例えば、取扱開始日から３ヶ月以内等）のビール飲料を抽出する（ステップＳ１３）。制御部１１は、抽出した指定期間内のビール飲料の中から類似度が最も高いビール飲料を抽出し（ステップＳ１４）、サブルーチンを呼び出した元の処理にリターンする。

【0071】

図１４は、端末２で顧客の属性を受け付ける画面の一例を示す説明図である。該画面は、顧客属性入力欄１１ａ及び確定ボタン１１ｂを含む。顧客属性入力欄１１ａは、顧客の属性の入力を受け付けるための入力欄である。確定ボタン１１ｂは、顧客から入力された顧客の属性をサーバ１に送信するためのボタンである。図示のように、顧客の属性（お客様の情報）は、ニックネーム、性別、年齢、最もよく飲むお酒、ビール飲料の飲用頻度、飲酒シーン（家飲み派または外飲み派）等を含む。

【0072】

端末２は、確定ボタン１１ｂのタッチ（クリック）操作を受け付けた場合、顧客属性入力欄１１ａにより入力した顧客の属性をサーバ１に送信する。サーバ１は、端末２から送信された顧客の属性を受信し、受信した顧客の属性を顧客ＩＤに対応付けて顧客ＤＢ１７１に記憶する。なお、一度受け付けた顧客の属性が顧客ＤＢ１７１に記憶された場合、または、顧客の属性がローカルストレージ等から取得された場合、端末２は、２回目からステップＳ２０１の処理（図１１）を省略しても良い。なお、顧客ＩＤ等を含むログイン用の認証情報を該画面で入力させても良く、または別のログイン画面で入力させても良い。

【0073】

図１５は、端末２で複数の質問に対する回答を受け付ける画面の一例を示す説明図である。該画面は、進捗表示欄１２ａ、質問表示欄１２ｂ及び回答候補ボタン１２ｃを含む。進捗表示欄１２ａは、質問の回答の進捗状況を表示するための表示欄である。例えば、回答済み及び回答中の質問の番号を実線枠で示し、未回答の質問の番号を点線枠で示しても良い。質問表示欄１２ｂは、質問の内容を表示するための表示欄である。回答候補ボタン１２ｃは、質問に対して回答の候補（選択肢）を選択するためのボタンである。

【0074】

サーバ１は、情報収集ＤＢ１７５に記憶された複数の質問を取得して端末２に送信する。端末２は、サーバ１から送信された複数の質問を受信して画面に表示する。質問は、例えば「朝食は和食派？洋食派？最も多いものでお答えください。」である。端末２は、いずれかの回答候補ボタン１２ｃのタッチ操作を受け付けた場合、該質問に対して該当する回答を取得して次の質問を表示する。例えば端末２は、「和食派」である回答候補ボタン１２ｃのタッチ操作を受け付けた場合、「和食派」である回答を取得する。端末２は、次の質問を質問表示欄１２ｂに表示する。

【0075】

端末２は、顧客ＩＤ、及び回答候補ボタン１２ｃにより選択した複数の回答をサーバ１に送信する。サーバ１は、端末２から送信された顧客ＩＤ及び複数の回答を受信し、受信した複数の回答を顧客ＩＤに対応付けて顧客ＤＢ１７１に記憶する。

【0076】

図１６は、変更前のビール飲料を表示する画面の一例を示す説明図である。図１６では、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致していない場合、該ビール飲料（変更前のビール飲料）を変更せずにそのまま顧客に提案する際の画面例を図示している。該画面は、キャラクタ６１、ビール表示欄７１、注文ボタン７２、キャンセルボタン７３を含む。キャラクタ６１は、顧客への案内を行うキャラクタである。図示のように、端末２は変更前のビール飲料に対し、悩んでいる表情を見せるキャラクタをキャラクタ６１に表示している。

【0077】

端末２は、キャラクタ６１を画面上部の表示領域に表示すると共に、そのキャラクタ６１のセリフとして、ビール表示欄７１に表示するビール飲料を勧める旨のコメント（テキスト）を表示する。セリフは、例えば「○○さまへのおすすめビールはこちらです。」、または「次回の提案に頑張る！」等であっても良い。なお、セリフに関しては、テキストに限らず、音声であっても良い。

【0078】

ビール表示欄７１は、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料に関するビール情報を表示するための表示欄である。例えば端末２は、提案するビール飲料の製品名、説明文、及び製品画像をビール表示欄７１に表示する。また、端末２は、提案するビール飲料のビアスタイル、アルコール度数（濃度）、カロリー、製造元（ブルワリー）、製造地域等、ビール飲料の詳細なプロフィールを表示する。ビアスタイルとは、ＩＰＡ（インディアペールエール）、ヴァイツェン等、原料、製法、アルコール度数等に応じたビールの分類を指す。その他にも端末２は、当該ビール飲料の風味（ボディ、酸味、甘味、香り、苦み等）を複数の尺度で表すレーダーチャートを表示する。なお、レーダーチャートは、例えばサーバ１が商品ＤＢ１７３に記憶されているビール飲料の複数の特性値を加工することで自動的に作成しても良く、または本システムの管理者等が人手で作成しても良い。

【0079】

注文ボタン７２及びキャンセルボタン７３は、提案されたビール飲料を注文する（飲む）か否かを選択するための操作オブジェクトである。注文ボタン７２が操作された場合、提案されたビール飲料が注文される。この場合、例えばサーバ１は該ビール飲料の注文処理を行い、該ビール飲料の注文を店舗スタッフに通知する。なお、注文ボタン７２が操作された場合、注文数量の入力または注文内容の確認等を行う確認画面が先に表示されても良い。なお、店舗の発注システムとの連携が可能な場合、提案されたビール飲料の注文処理が店舗のサーバで行われても良い。キャンセルボタン７３が操作された場合、提案されたビール飲料は注文されずに処理を終了する。この場合、例えばサーバ１は別のビール飲料（類似度が次に高いビール飲料等）を選択して提案画面に表示させても良く、あるいは一連の提案処理を終了しても良い。

【0080】

図１７は、変更後のビール飲料を表示する画面の一例を示す説明図である。なお、図１６と重複する内容については同一の符号を付して説明を省略する。図１７では、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料（変更前のビール飲料）が、前回提案したビール飲料と一致する場合、該ビール飲料とは異なるビール飲料（変更後のビール飲料）を顧客に提案する際の画面例を図示している。

【0081】

サーバ１は、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致すると判定した場合、変更後のビール飲料に関するビール情報、及び顧客への案内を行うキャラクタ（画像またはアイコン等）を端末２に送信する。端末２は、受信した変更後のビール飲料に関するビール情報をビール表示欄７１に表示する。図１６と同様に、ビール情報は、変更後のビール飲料の製品名、説明文、製品画像、ビアスタイル、アルコール度数（濃度）、カロリー、製造元（ブルワリー）、製造地域、または該変更後のビール飲料の風味を複数の尺度で表すレーダーチャート等を含む。

【0082】

端末２は、受信したキャラクタをキャラクタ６１に表示する。サーバ１は、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料を変更した場合、キャラクタ６１の表示態様を変更させる。具体的には、サーバ１は、キャラクタ６１の表情、及びキャラクタ６１のコメントを変更前のものから変更する。例えばサーバ１は、図１７に示すように、変更後のビール飲料を提案した場合、図１６の画面からキャラクタ６１の表情を自信のある表情に変更する。または、端末２は、「気くばりのすすめ！」のようなセリフをキャラクタ６１のコメントに表示しても良い。

【0083】

また、該画面は、変更前ビール表示欄７４をさらに含む。変更前ビール表示欄７４は、変更前のビール飲料に関するビール情報を表示するための表示欄である。サーバ１は、変更前のビール飲料に関するビール情報を取得して端末２に送信する。端末２は、サーバ１から送信された変更前のビール飲料に関するビール情報を変更前ビール表示欄７４に表示する。変更前ビール表示欄７４に表示されているビール情報は、例えば変更前のビール飲料の製品名及び説明文等を含む。

【0084】

また、該画面は、候補欄７５をさらに含む。候補欄７５は、ビール表示欄７１に表示されている変更後のビール飲料以外の他のビール飲料を候補として表示するための表示欄である。端末２は、候補欄７５に、一又は複数の他のビール飲料を製品画像、製品名等を候補として表示する。具体的には、例えばサーバ１は、ビール表示欄７１に表示されている変更後のビール飲料の次に類似度が高いビール飲料を抽出し、抽出したビール飲料に関するビール情報を端末２に送信する。端末２は、サーバ１から送信された次に類似度が高いビール飲料に関するビール情報を受信し、受信した該ビール情報を候補欄７５に表示する。なお、変更後のビール飲料以外の他のビール飲料の選択手法は、類似度に限定されるものではない。例えば提供開始日を提案すべきビール飲料の選択基準とした場合、提供開始日が次に新しいビール飲料を候補としても良く、候補とするビール飲料はその選択手法に依る。

【0085】

なお、上述した変更前のビール飲料に関するビール情報、変更後のビール飲料に関するビール情報、及び候補とする変更後のビール飲料に関するビール情報がサーバ１から同時に端末２に送信されても良い。

【0086】

注文ボタン７２が操作された場合、提案された変更後のビール飲料が注文される。この場合、例えばサーバ１は該ビール飲料の注文処理を行い、該ビール飲料の注文を店舗スタッフに通知する。なお、注文ボタン７２が操作された場合、注文数量の入力または注文内容の確認等を行う確認画面が先に表示されても良い。なお、店舗の発注システムとの連携が可能な場合、提案されたビール飲料の注文処理が店舗のサーバで行われても良い。キャンセルボタン７３が操作された場合、提案された変更後のビール飲料は注文されずに処理を終了する。この場合、例えばサーバ１は、候補欄７５に表示されている候補とするビール飲料をビール表示欄７１に表示させて良く、あるいは一連の提案処理を終了しても良い。

【0087】

また、該画面は、変更前注文ボタン７４ａ及び候補注文ボタン７５ａをさらに含む。変更前注文ボタン７４ａは、変更前ビール表示欄７４に表示されているビール飲料を注文するための操作オブジェクトである。変更前注文ボタン７４ａが操作された場合、変更前のビール飲料が注文される。候補注文ボタン７５ａは、候補欄７５に表示されているビール飲料を注文するための操作オブジェクトである。候補注文ボタン７５ａが操作された場合、候補とする変更後のビール飲料が注文される。

【0088】

変更前のビール飲料、変更後のビール飲料、候補とする変更後のビール飲料のいずれかが注文された場合、サーバ１は、注文されたビール飲料の注文内容を履歴ＤＢ１７４に記憶する。注文内容は、例えばビール飲料ＩＤ、注文数量及び注文日時等を含む。また、ビール飲料の注文の有無に応じて、ビール情報出力モデル１７６を再学習することができる。例えば、提案した変更後のビール飲料を顧客が注文しなかった（飲まない）場合、提案した変更後のビール飲料の特性値を修正（例えば顧客が注文した別のビール飲料の特性値に変更）し、修正後の特性値を再学習の正解値としてビール情報出力モデル１７６を更新する。また、候補とする変更後のビール飲料が注文された（飲みたい）場合、提案した変更後のビール飲料の特性値を修正（例えば候補とする変更後のビール飲料の特性値に変更）し、修正後の特性値を再学習の正解値としてビール情報出力モデル１７６を更新する。

【0089】

本実施形態によると、顧客の属性及び複数の質問に対する回答に基づき、ビール情報出力モデル１７６を用いて提案すべきビール飲料に関するビール情報を出力することが可能となる。

【0090】

本実施形態によると、ビール飲料の提案履歴に基づいて、前回提案したビール飲料と一致する場合に異なるビール飲料に変更することが可能となる。

【0091】

本実施形態によると、前回提案したビール飲料とは異なるビール飲料を変更することにより、提案の重複性を回避することができるため、顧客に適切なビール飲料を提案することが可能となる。

【0092】

（実施形態２）
実施形態２は、提案すべきビール飲料が前回提案したビール飲料と一致する場合、該ビール飲料のフィードバック結果を考慮して異なるビール飲料に変更する形態に関する。なお、実施形態１と重複する内容については説明を省略する。

【0093】

サーバ１は、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致し、かつ、該ビール飲料のフィードバック結果が否定を示していると判定した場合、異なるビール飲料に変更する。例えば、顧客に提案したビール飲料に対し、「お飲みになったビールの味はいかがですか？」であるフィードバックの項目に対する回答が、「美味しくなかった」、「いまいち」、「普通」、「美味しかった」及び「とても美味しかった」となる５段階評価が採用される例として説明する。例えばサーバ１は、顧客に前回提案したビール飲料Ａの味に対する「美味しくなかった」、「いまいち」または「普通」である否定を示しているフィードバック結果を受け付けた場合、ビール飲料Ａとは異なるビール飲料Ｂに変更する。

【0094】

図１８は、ビール飲料のフィードバック結果を受け付ける際の処理手順を示すフローチャートである。サーバ１の制御部１１は、大容量記憶部１７の情報収集ＤＢ１７５からフィードバックの複数の項目を取得する（ステップＳ１２１）。制御部１１は、顧客に提案したビール飲料ＩＤと、取得したフィードバックの複数の項目とを通信部１３により端末２に送信する（ステップＳ１２２）。

【0095】

端末２の制御部２１は、サーバ１から送信されたビール飲料ＩＤ及びフィードバックの複数の項目を通信部２３により受信し（ステップＳ２２１）、受信した複数の項目を表示部２５により表示する（ステップＳ２２２）。制御部２１は、顧客から複数の項目に対する回答の入力を入力部２４により受け付ける（ステップＳ２２３）。制御部２１は、顧客ＩＤ、ビール飲料ＩＤ、及び受け付けた複数の回答を含むフィードバック結果を通信部２３によりサーバ１に送信する（ステップＳ２２４）。

【0096】

サーバ１の制御部１１は、端末２から送信されたフィードバック結果を通信部１３により受信する（ステップＳ１２３）。制御部１１は、受信したフィードバック結果を大容量記憶部１７の履歴ＤＢ１７４に記憶する（ステップＳ１２４）。具体的には、制御部１１は、顧客ＩＤ及びビール飲料ＩＤに対応付けてフィードバック結果列に、フィードバックの複数の項目に対する回答を記憶する。

【0097】

図１９は、フィードバック結果に基づいてビール飲料を変更する際の処理手順を示すフローチャートである。なお、図１２と重複する内容については同一の符号を付して説明を省略する。サーバ１の制御部１１は、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致すると判定した場合（ステップＳ１０８でＹＥＳ）、顧客ＩＤ及びビール飲料ＩＤに基づいて大容量記憶部１７の履歴ＤＢ１７４から該ビール飲料のフィードバック結果を取得する（ステップＳ１１２）。フィードバック結果は、例えば「Ｎｏ１（お飲みになったビールの味はいかがですか？）：美味しくなかった、Ｎｏ２（どういう食事と一緒にビールを飲みましたか？）：つまみと、Ｎｏ３（今飲んだビールは何杯目ですか？）：１杯目」等である。

【0098】

制御部１１は、該ビール飲料のフィードバック結果が否定を示しているか否かを判定する（ステップＳ１１３）。例えば、ビール飲料のフィードバックの項目Ｎｏ１に対する回答が「美味しくなかった」、「いまいち」または「普通」である場合、制御部１１は、該ビール飲料のフィードバック結果が否定を示していると判定する。また、ビール飲料のフィードバックの項目Ｎｏ１に対する回答が「美味しかった」、または「とても美味しかった」である場合、制御部１１は、該ビール飲料のフィードバック結果が肯定を示していると判定する。

【0099】

制御部１１は、該ビール飲料のフィードバック結果が否定を示していると判定した場合（ステップＳ１１３でＹＥＳ）、ステップＳ１０９の処理を実行してビール飲料を変更する。例えば制御部１１は、類似度（例えば、コサイン類似度）に基づいてビール飲料を提案した場合、類似度の値の高い順に出力候補とする複数のビール飲料を特定する。制御部１１は、特定した複数のビール飲料から該ビール飲料を次に類似度の高いビール飲料に変更する。または、制御部１１は該ビール飲料と同一カテゴリに属する複数のビール飲料から、人気ランキング１位のビール飲料を抽出し、該ビール飲料を抽出したビール飲料に変更する。すなわち、ビール飲料の変更処理に関しては、上述した処理方式に限定せず、任意のアルゴリズムが採用されても良い。制御部１１は、該ビール飲料のフィードバック結果が肯定を示していると判定した場合（ステップＳ１１３でＮＯ）、ステップＳ１１１の処理に遷移する。

【0100】

図２０は、端末２でフィードバックを受け付ける画面の一例を示す説明図である。該画面は、ロゴ表示欄１４ａ、ビール飲料表示欄１４ｂ、項目表示欄１４ｃ、回答候補ボタン１４ｄ及び項目進捗表示欄１４ｅを含む。ロゴ表示欄１４ａは、ビール飲料のロゴを表示するための表示欄である。ビール飲料表示欄１４ｂは、ビール飲料の名称及びアルコール度数を表示するための表示欄である。

【0101】

項目表示欄１４ｃは、フィードバックの項目を表示するための表示欄である。回答候補ボタン１４ｄは、フィードバックの項目に対して回答候補を選択するためのボタンである。なお、回答候補ボタン１４ｄは、テキストではなく、数値またはアイコン（例えば、星マーク等）で表現されるボタンであっても良い。項目進捗表示欄１４ｅは、フィードバックの複数の項目における回答の進捗状況を表示するための表示欄である。例えば、回答済み及び回答中の項目の番号を実線枠で示し、未回答の項目の番号を点線枠で示しても良い。

【0102】

サーバ１は、情報収集ＤＢ１７５に記憶されたフィードバックの複数の項目を取得し、商品ＤＢ１７３に記憶されたビール飲料の名称（銘柄）及びアルコール度数を取得する。サーバ１は、取得したフィードバックの複数の項目、ビール飲料の名称及びアルコール度数を端末２に送信する。端末２は、サーバ１から送信されたフィードバックの複数の項目、ビール飲料の名称及びアルコール度数を受信する。端末２は、受信したフィードバックの複数の項目を項目表示欄１４ｃに表示し、ビール飲料の名称及びアルコール度数をビール飲料表示欄１４ｂに表示する。フィードバックの項目は、例えば「○○さんがお飲みになったビールの味はいかがでしたか？」等である。端末２は、いずれかの回答候補ボタン１４ｄのタッチ操作を受け付けた場合、該項目に対して該当する回答を取得して次の項目を表示する。例えば、端末２は、「普通」である回答候補ボタン１４ｄのタッチ操作を受け付けた場合、「普通」である回答を取得する。端末２は、次の項目を項目表示欄１４ｃに表示する。

【0103】

端末２は、顧客ＩＤ、ビール飲料ＩＤ及び回答候補ボタン１４ｄにより選択した複数の回答をサーバ１に送信する。サーバ１は、端末２から送信された顧客ＩＤ、ビール飲料ＩＤ及び複数の回答を受信し、受信した複数の回答（フィードバック結果）を顧客ＩＤ及びビール飲料ＩＤに対応付けて履歴ＤＢ１７４に記憶する。

【0104】

本実施形態によると、ビール飲料のフィードバック結果を考慮することにより、顧客のニーズを的確に把握し、そのニーズに合致する的確なビール飲料を提案することが可能となる。

【0105】

（実施形態３）
実施形態３は、提案すべきビール飲料が前回提案したビール飲料と一致する場合、該ビール飲料と同一カテゴリに属するビール飲料に変更する形態に関する。なお、実施形態１～２と重複する内容については説明を省略する。

【0106】

図２１は、実施形態３のサーバ１の構成例を示すブロック図である。なお、図２と重複する内容については同一の符号を付して説明を省略する。大容量記憶部１７には、カテゴリ分類モデル１７７及びカテゴリ分類ＤＢ１７８が記憶されている。カテゴリ分類モデル１７７は、人工知能ソフトウェアの一部であるプログラムモジュールとして利用され、各ビール飲料の複数の特性値に基づく学習により、各ビール飲料を複数のカテゴリに分類する学習済みモデルである。カテゴリ分類ＤＢ１７８は、カテゴリ分類モデル１７７を通じて分類したカテゴリの分類情報を記憶している。

【0107】

図２２は、カテゴリ分類ＤＢ１７８のレコードレイアウトの一例を示す説明図である。カテゴリ分類ＤＢ１７８は、カテゴリＩＤ列及び商品ＩＤ列を含む。カテゴリＩＤ列は、各カテゴリを識別するために、一意に特定されるカテゴリのＩＤを記憶している。商品ＩＤ列は、商品を特定するための商品ＩＤを記憶している。

【0108】

続いて、変更対象となるビール飲料を、該ビール飲料と同一カテゴリに属するビール飲料に変更する処理を説明する。まず、ビール飲料におけるカテゴリが分類されていない場合、サーバ１はカテゴリ分類モデル１７７を用いて、各ビール飲料を複数のカテゴリに分類する。なお、本実施形態では、教師なし学習アルゴリズムを用いてカテゴリ分類の例を説明する。教師なし学習（unsupervised learning）とは、入力データのみを大量に与えることで、入力データがどのような分布をしているか学習し、対応する教師出力データを与えなくても、入力データに対して圧縮・分類・整形等を行う装置で学習する手法である。

【0109】

具体的には、サーバ１は各ビール飲料ＩＤに基づいて、商品ＤＢ１７３から各ビール飲料の特徴データ（複数の特性値）を取得する。サーバ１は、取得した各ビール飲料の特徴データをカテゴリ分類モデル１７７に入力する。カテゴリ分類モデル１７７は、特徴データを受け付け、受け付けた特徴データのベクトル表現に基づいて、クラスタリングすることによって、各ビール飲料と関連するカテゴリを決定する。カテゴリ分類モデル１７７は、例えばｋ－ｍｅａｎｓ、ランダムフォレスト等のモデルを含んでいても良い。サーバ１は、カテゴリ分類モデル１７７を通じて決定したカテゴリに対し、カテゴリＩＤを割り振る。サーバ１は、割り振ったカテゴリＩＤと各ビール飲料ＩＤとに対応付けてカテゴリ分類ＤＢ１７８に記憶する。

【0110】

なお、カテゴリの分類処理に関しては、教師なし学習アルゴリズムに限らず、例えばＳＶＭ等の教師あり学習の機械学習に関する技術を用いて行われても良い。または、教師あり学習で学習したニューラルネットワークの中間層出力を取り出し、クラスタリングアルゴリズムとして用いても良い。

【0111】

なお、新商品となるビール飲料の入荷、またはビール飲料の販売中止等がある場合、サーバ１はカテゴリ分類モデル１７７を用いて、各ビール飲料を複数のカテゴリに再分類する。再分類処理に関しては、上述した分類処理と同様であるため、説明を省略する。

【0112】

次に、サーバ１は、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致すると判定した場合、該ビール飲料と同一カテゴリに属するビール飲料を抽出する。例えば、サーバ１は該ビール飲料と同一カテゴリに属する複数のビール飲料から、実施形態１と同様に、複数の特性値に基づいて類似度が高いビール飲料を抽出しても良い。または、サーバ１は該ビール飲料と同一カテゴリに属する複数のビール飲料から、人気ランキング順、価格の安い順、若しくは取扱開始日の新しい順に提案すべきビール飲料を抽出しても良い。サーバ１は、抽出したビール飲料を提案対象となるビール飲料として端末２に送信する。端末２は、サーバ１から送信されたビール飲料を受信して表示する。

【0113】

図２３は、同一カテゴリに属するビール飲料に変更する際の処理手順を示すフローチャートである。なお、図１２と重複する内容については同一の符号を付して説明を省略する。サーバ１の制御部１１は、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が、前回提案したビール飲料と一致すると判定した場合（ステップＳ１０８でＹＥＳ）、該ビール飲料と同一カテゴリに属するすべてのビール飲料ＩＤを抽出する（ステップＳ１１４）。具体的には、制御部１１は、該ビール飲料ＩＤに基づいて、カテゴリ分類ＤＢ１７８から該ビール飲料のカテゴリＩＤを取得する。制御部１１は、取得したカテゴリＩＤに基づいて、該カテゴリに属するすべてのビール飲料ＩＤをカテゴリ分類ＤＢ１７８から抽出する。制御部１１は、抽出したすべてのビール飲料ＩＤに基づいて、例えば取扱開始日の新しい順に変更対象となるビール飲料を商品ＤＢ１７３から取得する（ステップＳ１１５）。なお、制御部１１は、該ビール飲料と同一カテゴリに属する複数のビール飲料から、前回提案したビール飲料以外のビール飲料をランダムで選択しても良い。その後に、制御部１１はステップＳ１０９の処理を実行する。

【0114】

本実施形態によると、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が前回提案したビール飲料と一致する場合、該ビール飲料を該ビール飲料と同一カテゴリに属するビール飲料に変更することが可能となる。

【0115】

本実施形態によると、顧客の好みに合わせた最適なビール飲料を提案することが可能となる。

【0116】

（実施形態４）
実施形態４は、顧客のフィードバック結果を用いてビール情報出力モデル１７６を更新する形態に関する。顧客のフィードバック結果は、フィードバックの複数の項目に対する回答等である。なお、実施形態１～３と重複する内容については説明を省略する。

【0117】

ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が前回提案したビール飲料と一致していない場合、該ビール飲料（変更前のビール飲料）を変更せずそのまま顧客に提案する。また、ビール情報出力モデル１７６を通じて顧客に提案したビール飲料が前回提案したビール飲料と一致する場合、該ビール飲料とは異なるビール飲料（変更後のビール飲料）を顧客に提案する。これにより、フィードバック結果は、変更前のビール飲料に対するフィードバック結果と変更後のビール飲料に対するフィードバック結果を含む。いずれかのフィードバック結果には、ビール飲料に対する好み、杯数等の情報が含まれる。

【0118】

履歴ＤＢ１７４に記憶されたフィードバック結果をビール情報出力モデル１７６の再学習に用いる。具体的には、サーバ１は、変更前のビール飲料に対するフィードバック結果に基づいて第１訓練データを作成する。第１訓練データは、顧客の属性及び複数の質問に対する回答と、変更前のビール飲料に関するビール情報と、該ビール情報に対する顧客のフィードバックとを含む。サーバ１は、変更後のビール飲料に対するフィードバック結果に基づいて第２訓練データを作成する。第２訓練データは、顧客の属性及び複数の質問に対する回答と、変更後のビール飲料に関するビール情報と、該ビール情報に対する顧客のフィードバックとを含む。

【0119】

サーバ１は、作成した第１訓練データ及び第２訓練データに含まれている顧客の属性と、複数の質問に対する回答とを再学習用（訓練用）の入力データとし、提案したビール飲料を再学習用の正解値として学習を行い、ビール情報出力モデル１７６を更新する。

【0120】

この場合、サーバ１は、提案したビール飲料の注文の有無、注文後に入力されたフィードバックの複数の項目に対する回答等に応じて再学習を行うと好適である。例えばサーバ１は、提案したビール飲料を顧客が注文しなかった場合、提案したビール飲料の特性値を修正（例えば顧客が注文した別のビール飲料の特性値に変更）し、修正後の特性値を再学習の正解値としてビール情報出力モデル１７６を更新する。また、ビール表示欄７１ではなく候補欄７５に表示されたビール飲料が注文された場合、提案したビール飲料の特性値を修正（例えば候補とするビール飲料の特性値に変更）し、修正後の特性値を再学習の正解値としてビール情報出力モデル１７６を更新する。更にまた、例えばサーバ１は、顧客のフィードバック結果において、顧客が飲んだビール飲料に関する感想が否定的な回答であった場合、提案したビール飲料の特性値を修正（例えば感想に対する肯定的な回答に対応するビール飲料の特性値に変更）し、修正後の特性値を再学習の正解値としてビール情報出力モデル１７６を更新する。

【0121】

なお、上記の再学習手法は一例であって、本実施の形態はこれに限定されるものではない。例えばサーバ１は、ユーザが要望するビール飲料を問う質問がフィードバック結果に含まれる場合、その質問に対する回答（「もっとアルコール度数が高い方が良い」等）に応じて提案したビール飲料の特性値を変更（例えばアルコール分を変更）し、変更後の特性値を再学習用の正解値に用いてビール情報出力モデル１７６を更新しても良い。すなわち、フィードバックの複数の項目に対する回答の内容に応じて、再学習に用いるビール情報（特性値）の正解値を変更しても良い。

【0122】

このように、顧客のフィードバック結果等に基づき、本システムの運用を通じて提案の精度を向上させることができる。

【0123】

図２４は、ビール情報出力モデル１７６の更新処理の手順を示すフローチャートである。図２４に基づき、再学習を行ってビール情報出力モデル１７６を更新する際の処理内容について説明する。

【0124】

サーバ１の制御部１１は、再学習用のフィードバック結果を履歴ＤＢ１７４等から取得する（ステップＳ１３１）。制御部１１は、変更前のビール飲料に対して再学習用の第１訓練データを作成する（ステップＳ１３２）。第１訓練データは、顧客の属性、複数の質問に対する回答、変更前のビール飲料の特性値等のほか、変更前のビール飲料の注文の有無、注文後に入力されたフィードバックの複数の項目に対する回答等を含む。制御部１１は、変更後のビール飲料に対して再学習用の第２訓練データを作成する（ステップＳ１３３）。第２訓練データは、顧客の属性、複数の質問に対する回答、変更後のビール飲料の特性値等のほか、変更後のビール飲料の注文の有無、注文後に入力されたフィードバックの複数の項目に対する回答等を含む。

【0125】

制御部１１は、再学習用の第１訓練データ及び第２訓練データに基づいてビール情報出力モデル１７６を更新する（ステップＳ１３４）。例えば制御部１１は、提案したビール飲料を顧客が注文しなかった場合、損失関数が増大するようにビール情報出力モデル１７６のパラメータを更新する。また、例えば制御部１１は、提案したビール飲料に関する感想が肯定的又は否定的な回答であった場合、損失関数が減少又は増大するようにビール情報出力モデル１７６のパラメータを更新する。制御部１１は一連の処理を終了する。

【0126】

本実施形態によると、顧客のフィードバック結果を用いてビール情報出力モデル１７６を再学習することにより、ビール情報出力モデル１７６の推定精度を向上させることが可能となる。

【0127】

今回開示された実施形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

【符号の説明】

【0128】

１ 情報処理装置（サーバ）
１１ 制御部
１２ 記憶部
１３ 通信部
１４ 入力部
１５ 表示部
１６ 読取部
１７ 大容量記憶部
１７１ 顧客ＤＢ
１７２ 店舗ＤＢ
１７３ 商品ＤＢ
１７４ 履歴ＤＢ
１７５ 情報収集ＤＢ
１７６ ビール情報出力モデル
１７７ カテゴリ分類モデル
１７８ カテゴリ分類ＤＢ
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
１Ｐ 制御プログラム
２ 情報処理端末（端末）
２１ 制御部
２２ 記憶部
２３ 通信部
２４ 入力部
２５ 表示部
２Ｐ 制御プログラム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】