ホーム > 特許ランキング > 株式会社 ディー・エヌ・エー
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-01-10
(45)【発行日】2024-01-18
(54)【発明の名称】電子ゲーム情報処理装置及び電子ゲーム情報処理プログラム
(51)【国際特許分類】
A63F 13/67 20140101AFI20240111BHJP
A63F 13/5375 20140101ALI20240111BHJP
A63F 13/49 20140101ALI20240111BHJP
G06N 3/044 20230101ALI20240111BHJP
G06N 20/00 20190101ALI20240111BHJP
【ＦＩ】
A63F13/67
A63F13/5375
A63F13/49
G06N3/044
G06N20/00 130
【請求項の数】
7
(21)【出願番号】P 2020052475
(22)【出願日】2020-03-24
(65)【公開番号】P2021151320
(43)【公開日】2021-09-30
【審査請求日】2023-03-10
(73)【特許権者】
【識別番号】599115217
【氏名又は名称】株式会社 ディー・エヌ・エー
(74)【代理人】
【識別番号】110001210
【氏名又は名称】弁理士法人ＹＫＩ国際特許事務所
(72)【発明者】
【氏名】田中 一樹
(72)【発明者】
【氏名】佐藤 勝彦
【審査官】鈴木 崇雅
(56)【参考文献】
【文献】特開２０１９－０９５９７３（ＪＰ，Ａ）
【文献】特開２０１３－０８４１７５（ＪＰ，Ａ）
【文献】国際公開第２０２０／００３６７０（ＷＯ，Ａ１）
【文献】国際公開第２０１０／０２７０３４（ＷＯ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ａ６３Ｆ １３／００－９８
Ａ６３Ｆ ９／２４
Ｇ０６Ｎ ３／０２－１０
Ｇ０６Ｎ ２０／００
(57)【特許請求の範囲】
【請求項1】
電子ゲームのプレイ進行に応じて生じた順番に配列されたゲーム状態列を含む前記電子ゲームのログデータに含まれる、前記配列における第１範囲に含まれる複数のゲーム状態からなる第１ログと、前記第１範囲より狭い第２範囲に含まれるゲーム状態からなる第２ログを学習データとして用い、前記第１ログの特徴を表す第１特徴ベクトル及び前記第２ログの特徴を表す第２特徴ベクトルを生成し、前記第１特徴ベクトルと前記第２特徴ベクトルを同一の特徴空間に埋め込み、前記第１ログと前記第２ログとの間の関連度が高い程、前記特徴空間において前記第１特徴ベクトルと前記第２特徴ベクトルを近付け、前記第１ログと前記第２ログとの間の関連度が低い程、前記特徴空間において前記第１特徴ベクトルと前記第２特徴ベクトルを遠ざけるように学習モデルを学習するモデル学習部と、を備えることを特徴とする電子ゲーム情報処理装置。
【請求項2】
プレイヤによる前記電子ゲームのプレイにより得られた、ゲーム状態列からなるプレイデータを前記学習モデルに入力することで生成され前記特徴空間に埋め込まれた注目特徴ベクトルに基づいて、前記プレイデータを評価するプレイデータ評価部と、をさらに備えることを特徴とする請求項１に記載の電子ゲーム情報処理装置。
【請求項3】
前記プレイデータ評価部は、予め定められたイベントゲーム状態列を学習済みの前記学習モデルに入力することで生成され前記特徴空間に埋め込まれた、前記イベントゲーム状態列の特徴を表すイベント特徴ベクトルと、前記電子ゲーム内で発生するイベントに関するイベント情報とが関連付けられたイベントデータベースを参照し、前記注目特徴ベクトルと前記イベント特徴ベクトルとの類似度が所定の類似度閾値以上であると評価した場合に、前記電子ゲームにおいて、前記イベント特徴ベクトルに関連付けられた前記イベント情報が示すイベントを実行する、ことを特徴とする請求項２に記載の電子ゲーム情報処理装置。
【請求項4】
前記プレイデータ評価部は、前記注目特徴ベクトルと前記イベント特徴ベクトルとの類似度が所定の類似度閾値以上となり、且つ、現在の前記電子ゲームのプレイ状況が所定のプレイ状況条件を満たしたと評価した場合に、前記電子ゲームにおいて、前記イベント特徴ベクトルに関連付けられた前記イベントを実行する、ことを特徴とする請求項３に記載の電子ゲーム情報処理装置。
【請求項5】
前記イベント情報は、言語表現されたプレイヤへのアドバイスであり、前記イベントは、プレイヤに対する前記アドバイスの出力である、
ことを特徴とする請求項３又は４に記載の電子ゲーム情報処理装置。
【請求項6】
前記電子ゲームの前記ログデータに含まれる複数のゲーム状態を学習済みの前記学習モデルに入力することで生成され前記特徴空間に埋め込まれた複数の特徴ベクトルの一部であって、所定の学習用基準特徴ベクトルとの間の類似度が所定の類似度閾値以上である複数の学習用特徴ベクトルに基づいて、前記電子ゲームをプレイする人工知能エージェントを学習させるエージェント学習部と、をさらに備えることを特徴とする請求項１に記載の電子ゲーム情報処理装置。
【請求項7】
コンピュータを、電子ゲームのプレイ進行に応じて生じた順番に配列されたゲーム状態列を含む前記電子ゲームのログデータに含まれる、前記配列における第１範囲に含まれる複数のゲーム状態からなる第１ログと、前記第１範囲より狭い第２範囲に含まれるゲーム状態からなる第２ログを学習データとして用い、前記第１ログの特徴を表す第１特徴ベクトル及び前記第２ログの特徴を表す第２特徴ベクトルを生成し、前記第１特徴ベクトルと前記第２特徴ベクトルを同一の特徴空間に埋め込み、前記第１ログと前記第２ログとの間の関連度が高い程、前記特徴空間において前記第１特徴ベクトルと前記第２特徴ベクトルを近付け、前記第１ログと前記第２ログとの間の関連度が低い程、前記特徴空間において前記第１特徴ベクトルと前記第２特徴ベクトルを遠ざけるように学習モデルを学習するモデル学習部と、
として機能させることを特徴とする電子ゲーム情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、電子ゲーム情報処理装置及び電子ゲーム情報処理プログラムに関する。
【背景技術】
【0002】
従来、電子ゲームを提供する電子ゲーム情報処理装置が知られている。電子ゲームでは、ゲームプレイ中にゲーム内の状態であるゲーム状態が刻々と変化するところ、電子ゲーム情報処理装置において、ゲーム状態を評価することが行われていた。ゲーム状態を評価することで、例えば、特定のゲーム状態においてプレイヤが行うべき操作の示唆などを行うことができる。
【0003】
例えば、特許文献１には、あるゲーム状態において使用すべきキャラクタを出力するように学習器を学習させ、学習済みの学習器に現在のゲーム状態を入力すると、当該ゲーム状態で使用すべきキャラクタが出力される電子ゲーム情報処理装置が開示されている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開２０１９－９５９７３号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
上述のように、ゲームプレイを進めていくに応じてゲーム状態が刻々と変化するが、従来においては、ある特定のゲーム状態に対する評価が行われていた。換言すれば、従来は、複数のゲーム状態の遷移を考慮した上でゲーム状態の評価を行うことが難しかった。
【0006】
さらに、ゲーム状態の遷移を考慮するに当たり、大局的なゲーム状態の遷移（より多くの複数のゲーム状態における状態の遷移）と、局所的なゲーム状態の遷移（より少ない複数のゲーム状態における状態の遷移）の一方又は両方を考慮するのが望ましい。例えば、大局的なゲーム状態の遷移を考慮することで、プレイヤのゲームプレイにおける大局的な傾向が把握でき、局所的なゲーム状態の遷移を考慮することで、プレイヤのゲームプレイにおける局所的な動向が把握でき、両方を考慮することで、大局的な傾向を鑑みつつ局所的な動向を把握することができる。
【0007】
本発明の目的は、電子ゲームのプレイにより得られたゲーム状態列からなるプレイデータに関する、ゲーム状態列における大局的なゲーム状態の遷移を考慮した評価、ゲーム状態列における局所的なゲーム状態の遷移を考慮した評価、及び、ゲーム状態列における大局的なゲーム状態の遷移及び局所的なゲーム状態の遷移の双方を考慮した評価を、同じ処理によって実行可能とすることにある。
【課題を解決するための手段】
【0008】
本発明は、電子ゲームのプレイ進行に応じて生じた順番に配列されたゲーム状態列を含む前記電子ゲームのログデータに含まれる、前記配列における第１範囲に含まれる複数のゲーム状態からなる第１ログと、前記第１範囲より狭い第２範囲に含まれるゲーム状態からなる第２ログを学習データとして用い、前記第１ログの特徴を表す第１特徴ベクトル及び前記第２ログの特徴を表す第２特徴ベクトルを生成し、前記第１特徴ベクトルと前記第２特徴ベクトルを同一の特徴空間に埋め込み、前記第１ログと前記第２ログとの間の関連度が高い程、前記特徴空間において前記第１特徴ベクトルと前記第２特徴ベクトルを近付け、前記第１ログと前記第２ログとの間の関連度が低い程、前記特徴空間において前記第１特徴ベクトルと前記第２特徴ベクトルを遠ざけるように学習モデルを学習するモデル学習部と、を備えることを特徴とする電子ゲーム情報処理装置である。
【0009】
望ましくは、プレイヤによる前記電子ゲームのプレイにより得られた、ゲーム状態列からなるプレイデータを前記学習モデルに入力することで生成され前記特徴空間に埋め込まれた注目特徴ベクトルに基づいて、前記プレイデータを評価するプレイデータ評価部と、をさらに備えることを特徴とする。
【0010】
望ましくは、前記プレイデータ評価部は、予め定められたイベントゲーム状態列を学習済みの前記学習モデルに入力することで生成され前記特徴空間に埋め込まれた、前記イベントゲーム状態列の特徴を表すイベント特徴ベクトルと、前記電子ゲーム内で発生するイベントに関するイベント情報とが関連付けられたイベントデータベースを参照し、前記注目特徴ベクトルと前記イベント特徴ベクトルとの類似度が所定の類似度閾値以上であると評価した場合に、前記電子ゲームにおいて、前記イベント特徴ベクトルに関連付けられた前記イベント情報が示すイベントを実行する、ことを特徴とする。
【0011】
望ましくは、前記プレイデータ評価部は、前記注目特徴ベクトルと前記イベント特徴ベクトルとの類似度が所定の類似度閾値以上となり、且つ、現在の前記電子ゲームのプレイ状況が所定のプレイ状況条件を満たしたと評価した場合に、前記電子ゲームにおいて、前記イベント特徴ベクトルに関連付けられた前記イベントを実行する、ことを特徴とする。
【0012】
望ましくは、前記イベント情報は、言語表現されたプレイヤへのアドバイスであり、前記イベントは、プレイヤに対する前記アドバイスの出力である、ことを特徴とする。
【0013】
望ましくは、前記電子ゲームの前記ログデータに含まれる複数のゲーム状態を学習済みの前記学習モデルに入力することで生成され前記特徴空間に埋め込まれた複数の特徴ベクトルの一部であって、所定の学習用基準特徴ベクトルとの間の類似度が所定の類似度閾値以上である複数の学習用特徴ベクトルに基づいて、前記電子ゲームをプレイする人工知能エージェントを学習させるエージェント学習部と、をさらに備えることを特徴とする。
【0014】
また、本発明は、コンピュータを、電子ゲームのプレイ進行に応じて生じた順番に配列されたゲーム状態列を含む前記電子ゲームのログデータに含まれる、前記配列における第１範囲に含まれる複数のゲーム状態からなる第１ログと、前記第１範囲より狭い第２範囲に含まれるゲーム状態からなる第２ログを学習データとして用い、前記第１ログの特徴を表す第１特徴ベクトル及び前記第２ログの特徴を表す第２特徴ベクトルを生成し、前記第１特徴ベクトルと前記第２特徴ベクトルを同一の特徴空間に埋め込み、前記第１ログと前記第２ログとの間の関連度が高い程、前記特徴空間において前記第１特徴ベクトルと前記第２特徴ベクトルを近付け、前記第１ログと前記第２ログとの間の関連度が低い程、前記特徴空間において前記第１特徴ベクトルと前記第２特徴ベクトルを遠ざけるように学習モデルを学習するモデル学習部と、として機能させることを特徴とする。
【発明の効果】
【0015】
本発明によれば、電子ゲームのプレイにより得られたゲーム状態列からなるプレイデータに関する、ゲーム状態列における大局的なゲーム状態の遷移を考慮した評価、ゲーム状態列における局所的なゲーム状態の遷移を考慮した評価、及び、ゲーム状態列における大局的なゲーム状態の遷移及び局所的なゲーム状態の遷移の双方を考慮した評価を、同じ処理によって実行することができる。
【図面の簡単な説明】
【0016】
【図1】本実施形態に係る電子ゲームシステムの構成概略図である。
【図2】本実施形態に係るゲームサーバの構成概略図である。
【図3】ログデータの例を示す概念図である。
【図4】学習モデルの構成概略図である。
【図5】戦略特徴ベクトルと戦術特徴ベクトルの特徴空間への埋め込み処理の概念を示す概念図である。
【図6】特徴空間の概念を示す概念図である。
【図7】学習済みの学習モデルにより得られた特徴空間の利用例を示す図である。
【図8】特徴空間内におけるイベント情報としてのアドバイスが関連付けられたイベント特徴ベクトルを示す概念図である。
【図9】プレイヤに向けて出力されたアドバイスの第１の例を示す図である。
【図10】プレイヤに向けて出力されたアドバイスの第２の例を示す図である。
【図11】ＡＩエージェントの学習データをゲームログＤＢから抽出する処理の概念を示す概念図である。
【図12】本実施形態に係るゲームサーバの処理の流れを示すフローチャートである。
【発明を実施するための形態】
【0017】
図１は、本実施形態に係るゲームシステム１０の構成概略図が示されている。ゲームシステム１０は、ゲームシステム１０により提供される電子ゲーム（以下「本ゲーム」と記載する）のプレイヤが使用するプレイヤ端末１２、及び、電子ゲーム情報処理装置としてのゲームサーバ１４を含んで構成されている。プレイヤ端末１２とゲームサーバ１４は、通信回線１６を介して互いに通信可能に接続されている。通信回線１６は、例えばインターネットあるいはローカルエリアネットワーク（ＬＡＮ）などによって構成される。なお、図１には、プレイヤ端末１２が１つだけ示されているが、ゲームシステム１０には、複数のプレイヤが使用する複数のプレイヤ端末１２が設けられてよい。
【0018】
本実施形態におけるゲームシステム１０においては、本ゲームを動作させるためのゲームプログラムはゲームサーバに記憶されており、プレイヤ端末１２からゲームサーバにアクセスすることで、プレイヤに本ゲームが提供される。
【0019】
本ゲームは、複数のプレイヤが相互に影響し合うゲームであり、ゲームに参加した複数のプレイヤの利得の総和がゼロになる、いわゆるゼロサムゲームである。ゼロサムゲームとしては、例えば、自プレイヤが勝ちとなった場合、他プレイヤが負けとなるゲームが挙げられる。また、本ゲームとしては対戦型のゲームであってよい。対戦型のゲームにあっては、例えば、複数のプレイヤが交互にゲーム操作を行う（例えば自プレイヤのターンが来たら操作を行い、他プレイヤのターンの間は操作できない）ことを繰り返すゲームであってよい。そのような対戦型のゲームとしては、例えば、オセロ、将棋、囲碁、麻雀、ポーカーなどが挙げられる。対戦型ゲームにおいて、プレイヤの対戦相手は他のプレイヤであってもよいし、コンピュータであってもよい。
【0020】
プレイヤ端末１２は、一般的なコンピュータであってよく、例えばパーソナルコンピュータや携帯端末（例えばタブレット端末やスマートフォン）である。プレイヤ端末１２は、例えばＣＰＵ（Central Processing Unit）あるいはマイクロコンピュータなどを含んで構成されるプロセッサ、例えばネットワークアダプタなどを含んで構成される通信インターフェイス、例えばマウス、キーボード、あるいはタッチパネルなどを含んで構成される入力インターフェイス、例えば液晶ディスプレイなどを含んで構成されるディスプレイ、例えばハードディスク、ＲＡＭ（Random Access Memory）、あるいはＲＯＭ（Read Only Memory）などを含んで構成されるメモリなどを含んで構成される。
【0021】
図２には、ゲームサーバ１４の構成概略図が示されている。本実施形態では、ゲームサーバ１４はサーバコンピュータにより構成されるが、以下に説明する機能を発揮する限りにおいて、ゲームサーバ１４はどのような装置であってもよい。
【0022】
通信インターフェイス２０は、例えばネットワークアダプタなどを含んで構成され、通信回線１６を介してプレイヤ端末１２と通信する機能を有するものである。
【0023】
メモリ２２は、例えばハードディスク、ＲＡＭ、あるいはＲＯＭなどを含んで構成される。メモリ２２には、ゲームサーバ１４の各部を機能させるための電子ゲーム情報処理プログラムが記憶される。また、メモリ２２には、本ゲームのゲームプログラムが記憶される。電子ゲーム情報処理プログラムとゲームプログラムは一体となったプログラムであってもよい。また、図２に示される通り、メモリ２２には、ゲームログＤＢ（データベース）２４、学習モデル２６、イベントＤＢ２８、及び、ＡＩ（人工知能；Artificial Intelligence）エージェント３０が記憶される。
【0024】
ゲームログＤＢ２４は、本ゲームをプレイヤがプレイすることで得られる、本ゲームのプレイ履歴を示すログデータを記憶するデータベースである。プレイヤが本ゲームをプレイする度に、ログデータがゲームログＤＢ２４に蓄積されていく。本ゲームは複数のプレイヤによってプレイされ得るところ、ゲームログＤＢ２４においては、プレイヤ毎に区別されてログデータが記憶されてもよい。
【0025】
プレイヤが本ゲームのプレイを進めていくにつれ、本ゲーム内の状態であるゲーム状態が刻々と変化する。ゲームログＤＢ２４に記憶されるログデータには、本ゲームのプレイ進行に応じて生じた順番に配列された複数のゲーム状態からなるゲーム状態列が含まれる。
【0026】
以下の説明においては、本ゲームがオセロゲームである場合の例に説明する。図３に、ゲームログＤＢ２４に記憶されるログデータＬｏｇの例が示されている。言うまでもなく、オセロゲームは、自プレイヤと対戦相手（敵プレイヤ又は敵コンピュータ）が１対１で対戦する対戦ゲームであり、自プレイヤと対戦相手が交互に盤に石を置いていくというゲームである。オセロゲームにおいては、ゲーム状態は盤の状態となる。自プレイヤ又は対戦相手が盤に石を置く度に盤の状態が変化し、すなわちゲーム状態が遷移する。ログデータＬｏｇは、複数のゲーム状態（盤の状態）を含んで構成される。
【0027】
図３に示すように、ログデータＬｏｇにおいて、ゲーム状態列の配列における第１範囲に含まれる複数のゲーム状態からなる第１ログとしての戦略ログＳ、及び、第１範囲より狭い第２範囲に含まれる複数のゲーム状態からなる第２ログとしての戦術ログＴを観念上定義し得る。第１範囲及び第２範囲は予め本ゲームのゲームプランナなどによって設定される。本実施形態では、戦略ログＳ及び戦術ログＴはゲーム状態列において連続する複数のゲーム状態を含んで構成される。
【0028】
戦略ログＳを画定する第１範囲は、プレイヤ（自プレイヤ及び対戦相手を含む）の本ゲームにおけるプレイの大局的な傾向を把握するのに十分な数のゲーム状態を含むように設定される。換言すれば、戦略ログＳに基づいて、プレイヤの本ゲームにおけるプレイの大局的な傾向を把握できる。本実施形態のように、対戦型の電子ゲームにあっては、電子ゲームにおけるプレイの大局的な傾向は、プレイヤの「戦略」と呼ぶことができる。戦略とは、電子ゲームにおいて勝つための長期的なゲーム進行方針とも言える。オセロゲームにおいては、戦略の例としては、例えば、「攻撃型」あるいは「守備型」などがある。なお、戦略は、本ゲームの開始から終了まで（オセロゲームなら初手から終局まで）一貫して変わらない場合もあるが、途中で変更される場合もある。
【0029】
一方、戦術ログＴを画定する第２範囲は、プレイヤの本ゲームにおけるプレイの局所的な動向を把握するのに十分な数のゲーム状態を含むように設定される。換言すれば、戦術ログＴに基づいて、プレイヤの本ゲームにおけるプレイの局所的な動向を把握できる。もちろん、戦術ログＴに含まれるゲーム状態の数は、戦略ログＳに含まれるゲーム状態の数よりも少ない。本実施形態のように、対戦型の電子ゲームにあっては、電子ゲームにおけるプレイの局所的な傾向は、プレイヤの「戦術」と呼ぶことができる。戦術とは、短期的あるいは具体的な方策とも言える。オセロゲームにおいては、戦術の例としては、例えば、「右上を攻める」あるいは「左下を攻める」などがある。
【0030】
学習モデル２６は、ゲームログＤＢ２４に記憶されたログデータ、より詳しくは、上述の戦略ログＳ及び戦術ログＴを学習データとして用い、戦略ログＳの特徴を表す第１特徴ベクトルとしての戦略特徴ベクトル、及び、戦術ログＴの特徴を表す第２特徴ベクトルとしての戦術特徴ベクトルを同一の特徴空間に埋め込むように出力するように学習される。特に学習モデル２６は、戦略ログＳと戦術ログＴの関連性が高い程、当該特徴空間において戦略特徴ベクトルと戦術特徴ベクトルを近付け、戦略ログＳと戦術ログＴの関連性が低い程、当該特徴空間において戦略特徴ベクトルと戦術特徴ベクトルを遠ざけるように学習される。学習モデル２６の学習は、後述のモデル学習部３４によって実行される。学習モデル２６の構成の詳細及び学習方法の詳細については、モデル学習部３４の処理と共に後述する。
【0031】
イベントＤＢ２８には、例えば本ゲームのゲームプランナなどによって予め定めされたゲーム状態列であるイベントゲーム状態列を、学習済みの学習モデル２６に入力することで生成され上記特徴空間に埋め込まれたイベント特徴ベクトルと、本ゲーム内で発生するイベントに関するイベント情報が関連付けられて記憶される。イベントはゲームプランナによって様々なイベントが設定されてよい。イベントとしては種々のイベントを設定し得るが、本実施形態におけるイベントは、本ゲームをプレイ中のプレイヤに対するアドバイスを出力するイベントであり、イベント特徴ベクトルに関連付けられるイベント情報は、言語表現されたアドバイスである。なお、本実施形態では、イベントＤＢ２８には、イベント特徴ベクトルとイベント情報が関連付けられて記憶されるが、イベントゲーム状態列とイベント情報とを関連付けてイベントＤＢ２８に記憶するようにしてもよい。
【0032】
ＡＩエージェント３０は、本ゲームをプレイする人工知能プログラムである。ＡＩエージェント３０は、種々の構造を取ることができ、例えば、多層ニューラルネットワークを含んで構成される。ＡＩエージェント３０は、後述のエージェント学習部３８により学習される。ＡＩエージェント３０の学習方法の詳細については、エージェント学習部３８の処理と共に後述する。
【0033】
プロセッサ３２は、例えばＣＰＵ、ＧＰＵ（Graphics Processing Unit）あるいはマイクロコンピュータなどを含んで構成され、メモリ２２に記憶された電子ゲーム情報処理プログラムに従ってゲームサーバ１４の各部を制御する。また、図２に示される通り、プロセッサ３２は、電子ゲーム情報処理プログラムによって、モデル学習部３４、プレイデータ評価部３６、及び、エージェント学習部３８としても機能する。
【0034】
モデル学習部３４は、ゲームログＤＢ２４に記憶されたログデータにおいて定義された、戦略ログＳと戦術ログＴを学習データとして用いて、学習モデル２６を学習させる。本実施形態では、モデル学習部３４は、さらに、コンテキストデータを学習データに加える。コンテキストデータは、各ゲーム状態と関連付けられたデータであり、すなわちゲーム状態列に対応するデータ列から構成される。コンテキストデータとは、戦略ログＳ及び戦術ログＴに含まれる各ゲーム状態に関連する、本ゲームに関するゲーム状態（オセロゲームの場合は盤の状態）以外の情報である。本明細書では、特に、コンテキストデータは、プレイヤの戦略又は戦術に関連するデータである。例えば、あるゲーム状態となったときのプレイヤの属性情報（例えばプレイヤのレベルなど）や、ゲーム内設定（例えばカードゲームであればプレイヤのデッキに入っているキャラクタなど）などがコンテキストデータに含まれる。以下、学習モデル２６の構造の詳細と共に、モデル学習部３４の処理を説明する。
【0035】
図４は、学習モデル２６の構成概略図である。図４において、学習モデル２６の下部に記載されたＳｉ
ｐ，Ｓｉ
ｎは戦略ログＳを表し、Ｔｉ
ｐ，Ｔｉ
ｎは戦術ログＴを表し、Ｃｉ
ｐ，Ｃｉ
ｎはコンテキストデータを表す。変数ｉは学習データである戦略ログＳ、戦術ログＴ、及びコンテキストデータのセットを識別する変数である。ｐはポジティブサンプルを表し、ｎはネガティブサンプルを表す。ポジティブサンプルとは、後述するネガティブサンプルと対比される概念であり、本実施形態においては、戦略ログＳｉ
ｐに関連する（関連度が関連度閾値より高い）戦術ログがＴｉ
ｐであり、戦略ログＳｉ
ｐに関連しない（関連度が関連度閾値より低い）戦術ログがＴｉ
ｎであり、戦術ログＴｉ
ｐに関連する戦略ログがＳｉ
ｐであり、戦術ログＴｉ
ｐに関連しない戦略ログがＳｉ
ｎである。例えば、戦術ログＴの特徴が戦略ログＳに沿ったものである場合、両者の関連度が高くなり、戦術ログＴの特徴が戦略ログＳに沿ったものでない場合、両者の関連度が低くなる。例えば、戦略ログＳが「攻撃型」の特徴を示す場合、戦術ログＴの特徴が攻撃的である場合は両者の関連度が高いと言え、戦術ログＴの特徴が守備的である場合は両者の関連度が低いと言える。
【0036】
本実施形態では、Ｐｉ＝（Ｓｉ
ｐ，Ｔｉ
ｐ，Ｃｉ
ｐ）からなるポジティブサンプルと、Ｎｉ＝（Ｓｉ
ｎ，Ｔｉ
ｎ，Ｃｉ
ｎ）からなるネガティブサンプルとのセット（Ｐｉ，Ｎｉ）を学習データとして用いる。ポジティブサンプルとネガティブサンプルに対する学習モデル２６の各部における処理は同様であるため、学習モデル２６の各部の説明においては、ポジティブサンプルに対する処理を例に説明する。
【0037】
なお、戦略ログＳ及び戦術ログＴは、それぞれ複数のゲーム状態からなるところ、これらを学習モデル２６に入力するに先立って、各ゲーム状態は、学習モデル２６の入力に適したデータ、例えば、数値を要素とするベクトルに変換される。
【0038】
ゲーム状態列からなる戦略ログＳｉ
ｐは、戦略側ＲＮＮ（リカレントニューラルネットワーク；Recurrent Neural Network）５０に入力される。具体的には、戦略側ＲＮＮ５０には、戦略ログＳｉ
ｐに含まれる複数のゲーム状態が順次入力される。戦略側ＲＮＮ５０は、あるゲーム状態を入力された時の出力が、次のゲーム状態と共に入力される再帰結合を持つニューラルネットワークである。つまり、戦略側ＲＮＮ５０は、順次入力されるゲーム状態から、それまでに入力された１又は複数のゲーム状態の特徴を表す中間出力を出力する。これにより、直前に入力されたゲーム状態に基づいて出力された中間出力を参照しながら、今回入力されたゲーム状態に対する中間出力を出力することができる。戦略ログＳｉ
ｐに含まれる最後のゲーム状態の中間出力が、戦略側ＲＮＮ５０の出力となる。また、複数のゲーム状態の中間出力を集約した出力が、戦略側ＲＮＮ５０の出力であってもよい。当該出力は戦略ログＳｉ
ｐ全体の特徴を表すものとなる。
【0039】
ゲーム状態列からなる戦術ログＴｉ
ｐは、戦術側ＲＮＮ５２に入力される。具体的には、戦術側ＲＮＮ５２には、戦術ログＴｉ
ｐに含まれる複数のゲーム状態が順次入力される。戦術側ＲＮＮ５２の構造は戦略側ＲＮＮ５０と同様であり、戦術側ＲＮＮ５２の出力は、戦術ログＴｉ
ｐ全体の特徴を表す出力となる。
【0040】
コンテキスト埋め込み層５４は、例えばOne hotベクトルなどの離散的表現で表されたコンテキストデータに基づいて、その意味を表す分散表現であるコンテキスト特徴ベクトルを生成する。
【0041】
戦略側埋め込み層５６は、戦略側ＲＮＮ５０の出力（戦略ログＳｉ
ｐの特徴を表す出力）に基づいて、その特徴を表す分散表現である戦略特徴ベクトルを生成する。好適には、戦略側埋め込み層５６は、コンテキスト埋め込み層５４が出力したコンテキスト特徴ベクトルを考慮して、換言すればコンテキスト特徴ベクトルの特徴も表す、戦略特徴ベクトルを生成する。
【0042】
戦術側埋め込み層５８は、戦術側ＲＮＮ５２の出力（戦術ログＴｉ
ｐの特徴を表す出力）に基づいて、その特徴を表す分散表現である戦術特徴ベクトルを生成する。好適には、戦術側埋め込み層５８は、コンテキスト埋め込み層５４が出力したコンテキスト特徴ベクトルを考慮して、換言すればコンテキスト特徴ベクトルの特徴も表す、戦術特徴ベクトルを生成する。戦術特徴ベクトルの次元数は、戦略特徴ベクトルと同一となっている。
【0043】
戦略側埋め込み層５６及び戦術側埋め込み層５８は、それぞれ、生成した戦略特徴ベクトル及び戦術特徴ベクトルを同一の特徴空間に埋め込む。戦略側埋め込み層５６は、複数の学習データが入力されることで複数の戦略特徴ベクトルを特徴空間に埋め込むが、互いの特徴が類似している程、特徴空間において複数の戦略特徴ベクトルを近づけ、互いの特徴が類似していない程、特徴空間において複数の戦略特徴ベクトルを遠ざけるように埋め込む。戦術側埋め込み層５８も同様に、複数の学習データが入力されることで複数の戦術特徴ベクトルを特徴空間に埋め込むが、互いの特徴が類似している程、特徴空間において複数の戦術特徴ベクトルを近づけ、互いの特徴が類似していない程、特徴空間において複数の戦術特徴ベクトルを遠ざけるようにする。
【0044】
さらに、戦略側埋め込み層５６は、自身が出力した戦略特徴ベクトルと、戦術側埋め込み層５８が出力した戦術特徴ベクトルの関連度が高い程、特徴空間において当該戦略特徴ベクトルと当該戦術特徴ベクトルを近付け、当該戦略特徴ベクトルと当該戦術特徴ベクトルの関連度が低い程、特徴空間において当該戦略特徴ベクトルと当該戦術特徴ベクトルを遠ざけるようにする。戦略特徴ベクトルと戦術特徴ベクトルの関連度とは、すなわち、戦略ログＳと戦術ログＴの関連度である。
【0045】
図５に、当該処理の概念が示されている。図５において、ｓｉ
ｐは戦略特徴ベクトルを表し、ｔｉ
ｐは戦術特徴ベクトルを表す。図５においては、互いに関連する戦略特徴ベクトルｓｉ
ｐと戦術特徴ベクトルｔｉ
ｐとが近付けられ、互いに関連しない戦略特徴ベクトルｓｉ
ｐと戦術特徴ベクトルｔｉ
ｎ、及び、戦略特徴ベクトルｓｉ
ｎと戦術特徴ベクトルｔｉ
ｐが遠ざけられる様子が示されている。
【0046】
上記の条件に従って、各戦略特徴ベクトルと各戦術特徴ベクトルを同一の特徴空間に埋め込むこと（換言すれば、上記の条件に従って、各戦略特徴ベクトルと各戦術特徴ベクトルの特徴空間における位置を決定すること）は、所定の目的関数を最小化することで実現される。目的関数Ｌは、例えば以下の式１で表される。
【0047】
【数1】
【0048】
式１において、Ｌｓは戦略特徴ベクトルｓｉ
ｐに関する損失を表し、式２で算出される。式２において、Ｂは学習データの総数（バッチサイズ）を表す。また、αは調整項である。式２における｜｜ｓｉ
ｐ－ｔｉ
ｐ｜｜２
２は、互いに関連している戦略特徴ベクトルｓｉ
ｐと戦術特徴ベクトルｔｉ
ｐとの間の特徴空間におけるＬ２ノルム（ユークリッド距離）の２乗であり、｜｜ｓｉ
ｐ－ｔｉ
ｎ｜｜２
２は、互いに関連していない戦略特徴ベクトルｓｉ
ｐと戦術特徴ベクトルｔｉ
ｎとの間の特徴空間におけるＬ２ノルムの２乗である。なお、［ｘ］＋は、ｍａｘ（ｘ，０）を意味する。すなわち、ｘが正の値なら［ｘ］＋＝ｘ、ｘが負の値なら［ｘ］＋＝０となる。式２によれば、Ｌｓを最小化することは、互いに関連している戦略特徴ベクトルｓｉ
ｐと戦術特徴ベクトルｔｉ
ｐとの間の特徴空間におけるＬ２ノルムをより小さくし（すなわち両特徴ベクトルを近付け）、互いに関連していない戦略特徴ベクトルｓｉ
ｐと戦術特徴ベクトルｔｉ
ｎとの間の特徴空間におけるＬ２ノルムをより大きくする（すなわち両特徴ベクトルを遠ざける）ことで実現される。
【0049】
また、式１において、Ｌｔは戦術特徴ベクトルｔｉ
ｐに関する損失を表し、式３で算出される。式３における｜｜ｓｉ
ｎ－ｔｉ
ｐ｜｜２
２は、互いに関連していない戦略特徴ベクトルｓｉ
ｎと戦術特徴ベクトルｔｉ
ｐとの間の特徴空間におけるＬ２ノルムの２乗である。式３によれば、Ｌｔを最小化することは、互いに関連している戦略特徴ベクトルｓｉ
ｐと戦術特徴ベクトルｔｉ
ｐとの間の特徴空間におけるＬ２ノルムをより小さくし（すなわち両特徴ベクトルを近付け）、互いに関連していない戦略特徴ベクトルｓｉ
ｎと戦術特徴ベクトルｔｉ
ｐとの間の特徴空間におけるＬ２ノルムをより大きくする（すなわち両特徴ベクトルを遠ざける）ことで実現される。
【0050】
また、式１におけるＬｓ及びＬｔは、以下の式４及び式５で表されてもよい。
【0051】
【数2】
【0052】
式４におけるｆ（ｓｉ
ｐ，ｔｉ
ｐ）は、互いに関連している戦略特徴ベクトルｓｉ
ｐと戦術特徴ベクトルｔｉ
ｐとの間の特徴空間におけるコサイン類似度を表し、ｆ（ｓｉ
ｐ，ｔｉ
ｎ）は、互いに関連していない戦略特徴ベクトルｓｉ
ｐと戦術特徴ベクトルｔｉ
ｎとの間の特徴空間におけるコサイン類似度を表す。なお、コサイン類似度を表す関数ｆは以下のとおりである。
【0053】
【数3】
【0054】
式４によれば、Ｌｓを最小化することは、互いに関連している戦略特徴ベクトルｓｉ
ｐと戦術特徴ベクトルｔｉ
ｐとの間の特徴空間におけるコサイン類似度をより大きくし（すなわち両特徴ベクトルを近付け）、互いに関連していない戦略特徴ベクトルｓｉ
ｐと戦術特徴ベクトルｔｉ
ｎとの間の特徴空間におけるコサイン類似度をより小さくする（すなわち両特徴ベクトルを遠ざける）ことで実現される。
【0055】
式５におけるｆ（ｓｉ
ｎ，ｔｉ
ｐ）は、互いに関連していない戦略特徴ベクトルｓｉ
ｎと戦術特徴ベクトルｔｉ
ｐとの間の特徴空間におけるコサイン類似度を表す。式５によれば、Ｌｔを最小化することは、互いに関連している戦略特徴ベクトルｓｉ
ｐと戦術特徴ベクトルｔｉ
ｐとの間の特徴空間におけるコサイン類似度をより大きくし（すなわち両特徴ベクトルを近付け）、互いに関連していない戦略特徴ベクトルｓｉ
ｎと戦術特徴ベクトルｔｉ
ｐとの間の特徴空間におけるコサイン類似度をより小さくする（すなわち両特徴ベクトルを遠ざける）ことで実現される。
【0056】
上述のように学習モデル２６を学習することで、図６に示すように、互いに関連度が高い戦略特徴ベクトルと戦術特徴ベクトルとが近くに埋め込まれ、互いに関連度が低い戦略特徴ベクトルと戦術特徴ベクトルとが遠くに埋め込まれた特徴空間ＦＳが形成される。また、特徴空間ＦＳにおいては、類似する戦略特徴ベクトル同士が近くに埋め込まれ、類似する戦術特徴ベクトル同士も近くに埋め込まれる。なお、図６では、便宜上特徴空間ＦＳが２次元で表現されているが、特徴空間ＦＳはそれ以上の多次元の空間である。
【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】
１０ ゲームシステム、１２ プレイヤ端末、１４ ゲームサーバ、２０ 通信インターフェイス、２２ メモリ、２４ ゲームログＤＢ、２６ 学習モデル、２８ イベントＤＢ、３０ ＡＩエージェント、３２ プロセッサ、３４ モデル学習部、３６ プレイデータ評価部、３８ エージェント学習部。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】