JP7053931B1 - 不具合原因を推定するための方法、プログラム、システム、及び装置 - Google Patents

Abstract

【課題】ゲームログデータから不具合原因を推定することが可能な方法を提供する。【解決手段】本発明の一実施形態の方法は、ユーザにより選択されたアクションに応じて進行し、ゲーム状態が更新されるゲームにおいて、ゲームログデータから不具合原因を推定するための方法であって、異常を示すラベルが付与されたログデータ配列である異常ログデータ配列のうちの一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常を示すラベルが付与されたログデータ配列である正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定するステップ、を含む。【選択図】図１

Description

本発明は、不具合原因を推定するための方法、プログラム、システム、及び装置に関し、特にゲームログデータから不具合原因を推定するための方法、プログラム、システム、及び装置に関する。

近年、ネットワークを通じて複数のプレイヤが参加可能なオンラインゲームを楽しむプレイヤが増えている。当該ゲームは、携帯端末装置がゲーム運営者のサーバ装置と通信を行うゲームシステムなどにより実現され、携帯端末装置を操作するプレイヤは、他のプレイヤと対戦プレイを行うことができる。

ゲーム運営者は、ゲームを提供するにあたっては、ゲームプログラムを検査してバグを検出しておく必要がある。一般的に、このような検査を効率化する技術は、Ｑｕａｌｉｔｙ Ａｓｓｕｒａｎｃｅ（ＱＡ）技術と呼ばれる。

特許第６４３８６１２号

「Ｃｙｇａｍｅｓ、ゲームデバッグ自動化 ＡＩシステム開発」、[online]、[令和３年７月２７日検索]、インターネットURL:https://www.nikkan.co.jp/articles/view/00591096

ＱＡを行うゲームとして、カードやキャラクタなどの組み合わせ（以下、「カード組み合わせ」という。）に応じて様々なアクションが実行されるデジタルコレクタブルカードゲーム（ＤＣＣＧ）と呼ばれるカードゲームが挙げられる。カードの種類の増大は、ゲームの戦略性を飛躍的に向上させる一方で、検証するべき状況の数も爆発的に増大させる。このように爆発的に増大するカード組み合わせについて、人力でのテストプレイにより網羅的に検証することは、膨大な人数と膨大な時間を投入する必要があるため、極めて困難であった。ＱＡに関するシステムとしては、例えば特許文献１はユーザにより実行される可能性がより高いアクションの推論を行い、ゲームプログラムを検査することが可能なシステム等を開示している。またＱＡに関するシステムとしては、例えば、ＡＩ技術を用いたゲームデバッグの自動化が実現されている（非特許文献１）。

このような中で、ゲーム運営者にとっては、ゲームにおける組み合わせパターンに由来する不具合の原因が分かれば、ゲーム運営やゲーム開発の更なる効率化が期待できるため、その不具合原因を推定することが求められていた。本発明は、このような課題を解決するためになされたものであり、ゲームログデータから不具合原因を推定することが可能な方法等を提供することを目的とする。

〔１〕本発明の一実施形態の方法は、
ユーザにより選択されたアクションに応じて進行し、ゲーム状態が更新されるゲームにおいて、ゲームログデータから不具合原因を推定するための、コンピュータにより実行される方法であって、該ゲーム状態は複数のゲーム状態要素を含んで構成され、該ゲームログデータは複数のログデータ配列を含み、ログデータ配列の各々は正常又は異常を示すラベルが付与されるものであり、該方法は、
異常を示すラベルが付与されたログデータ配列である異常ログデータ配列のうちの一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常を示すラベルが付与されたログデータ配列である正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定するステップ、を含む方法である。

〔２〕本発明の一実施形態では、
前記決定するステップは、一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータにおいて存在する度合に基づく値の、該組み合わせがゲームログデータに含まれる正常ログデータ配列において存在する度合に基づく値に対する比率が所定値以上であるときに、該組み合わせが不具合を発生させる原因であると決定することを含む、〔１〕に記載の方法である。

〔３〕本発明の一実施形態では、
ログデータ配列の各々に対して正常又は異常を示すラベルを付与するステップを含む、〔１〕又は〔２〕に記載の方法である。

〔４〕本発明の一実施形態では、
前記方法は、
一の異常ログデータ配列が含む不具合発生前のアクションに関連するゲーム状態が含むゲーム状態要素から所定のゲーム状態要素を抽出するステップを含み、
前記決定するステップは、一の異常ログデータ配列が含む不具合発生前のアクションと前記抽出された所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定することを含む、〔１〕から〔３〕のいずれか１つに記載の方法である。

〔５〕本発明の一実施形態では、
前記決定するステップは、一の異常ログデータ配列が含む不具合発生直前の１つのアクションと該アクションの直前のゲーム状態が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定することを含む、〔１〕から〔４〕のいずれか１つに記載の方法である。

〔６〕本発明の一実施形態では、
前記決定するステップは、一の異常ログデータ配列が含む不具合発生直前の２以上のアクションと該２以上のアクションの各々の直前のゲーム状態の各々が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定することを含む、〔１〕から〔４〕のいずれか１つに記載の方法である。

〔７〕本発明の一実施形態のプログラムは、〔１〕から〔６〕のいずれか１つに記載の方法の各ステップをコンピュータに実行させる。

〔８〕本発明の一実施形態の推定システムは、
ユーザにより選択されたアクションに応じて進行し、ゲーム状態が更新されるゲームにおいて、ゲームログデータから不具合原因を推定するための推定システムであって、該ゲーム状態は複数のゲーム状態要素を含んで構成され、該ゲームログデータは複数のログデータ配列を含むものであり、該推定システムは、
ログデータ配列の各々に対して正常又は異常を示すラベルを付与し、
異常を示すラベルが付与されたログデータ配列である異常ログデータ配列のうちの一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常を示すラベルが付与されたログデータ配列である正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定する、推定システムである。

〔９〕本発明の一実施形態の推定装置は、
ユーザにより選択されたアクションに応じて進行し、ゲーム状態が更新されるゲームにおいて、ゲームログデータから不具合原因を推定するための推定装置であって、該ゲーム状態は複数のゲーム状態要素を含んで構成され、該ゲームログデータは複数のログデータ配列を含み、ログデータ配列の各々は正常又は異常を示すラベルが付与されており、
異常を示すラベルが付与されたログデータ配列である異常ログデータ配列のうちの一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常を示すラベルが付与されたログデータ配列である正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定する、推定装置である。

本発明によれば、ゲームログデータから不具合原因を推定することができる。

本発明の一実施形態の推定装置のハードウェア構成を示すブロック図である。 本発明の一実施形態の推定装置の機能ブロック図である。 ユーザの端末装置のディスプレイに表示される本実施形態のゲームのゲーム画面の一例である。 ＲｅｐｌａｙｌｏｇＭａｔｒｉｘ_nの一例を示す図である。 本発明の一実施形態の推定装置の推定処理を示すフローチャートである。決定処理を示すフローチャートである。

以下、図面を参照して、本発明の実施形態について説明する。本発明の実施形態の推定装置１０は、ユーザ（プレイヤ）により選択されたアクションに応じて進行し、ゲーム状態が更新されるゲームにおいて、ゲームログデータから不具合原因を推定するための推定装置である。例えば上記のゲームは、あるゲーム状態においてユーザがアクションを選択すると、選択されたアクション（攻撃やイベントなど）が実行され、ゲーム状態が更新されるようなゲームであり、例えば対戦型カードゲームである。

推定装置１０は、１又は複数の装置を含んで構成される不具合原因を推定するための推定システムの１つの例であるが、以下の実施形態においては、説明の便宜上、１つの装置として説明する。本実施形態では、ゲーム状態又はアクションは、ゲーム状態のデータ又はアクションのデータを意味することができる。

本実施形態において説明する対戦型カードゲーム（本実施形態のゲーム）は、一般的なオンラインゲームと同様に、１又は複数のサーバ装置を含んで構成されるゲームサーバにより提供される。ゲームサーバは、ゲーム用のアプリケーションであるゲームプログラムを記憶し、ゲームをプレイする各ユーザの端末装置とネットワークを介して接続される。各ユーザが端末装置にインストールされたゲームアプリを実行している間、端末装置はゲームサーバと通信を行い、ゲームサーバは、ネットワークを介したゲームサービスを提供する。このとき、ゲームサーバは、ゲームに関するログデータであるゲームログデータを記憶する。当該ゲームログデータは、複数のログデータ配列（ログデータ要素配列）を含み、１つのログデータ配列は、複数のログデータ要素を含む。例えば１つのログデータ配列は、１つのバトルの履歴を示すものであり、当該バトルに関する複数のログデータ要素を含むものである。また、例えば１つのログデータ要素は、１つのゲーム状態においてユーザが実行したアクションを示すデータや当該１つのゲーム状態を示すデータである。ただし、ログデータ配列の各々は、１つのバトル以外の所定のイベント又は所定の時間などに関連する複数のログデータ要素を含むログデータ要素の集合とすることもできる。例えば、ゲームログデータはリプレイログであり、ログデータ配列はリプレイログ要素配列であり、ログデータ要素はリプレイログ要素である。

本実施形態では、クライアント（ユーザの端末装置）、ゲームサーバ、データベースサーバ、通信用サーバ等の、ゲームサービスを構成する全ての要素の仮想化、すなわち、エンドツーエンドの仮想化を実現した仮想環境が用いられる。その仮想環境において、ＡＩが自動プレイを行うことにより、ゲームサービスの挙動をログデータとして取得することができる。この仕組みにより、リプレイログへのラベル付けを容易に実装することができる。１つの例では、当該仮想環境は、自動プレイ中にエラーを検出することなく終了できた場合のログデータに「正常」というラベルを付与し、自動プレイ中にエラーを検出した場合のログデータに「異常」というラベルを付与する。このような構成とすることにより、リプレイログへのラベル付けを容易に行うことが可能となる。ただし、本実施形態では、説明の便宜上、推定装置１０がラベルを付与する機能を備えるものとして説明する。なお、仮想環境に関する技術は、例えば特開２０１９－１９３７０２号公報に記載されている。ただし、ログデータの取得方法は、上記の方法に限定されない。

本実施形態のゲームは、複数のカードを含んで構成される所有カード群からユーザがカードを選択して当該カードを場（ゲームフィールド）４３に出すことで、カードやクラスの組み合わせに応じて様々なイベントが実行されて進行する。また本実施形態のゲームは、ユーザ端末装置を操作するユーザ自身である自ユーザと他のユーザ端末装置を操作する他ユーザの各々が所有カード群からカードを選択して場４３に出して対戦する対戦ゲームである。本実施形態のゲームにおいて、各カード４１は、カードＩＤ、カード種別、ヒットポイント、攻撃力、属性などのパラメータを含むカード定義情報を有し、各クラスは、クラス定義情報を有する。

図３は、ユーザの端末装置のディスプレイに表示される本実施形態のゲームのゲーム画面の一例である。ゲーム画面は、自ユーザと他ユーザのカードバトルのゲーム画面４０を示すものである。ゲーム画面４０は、自ユーザの手札４２ａと、他ユーザの手札４２ｂとを示している。手札４２ａ及び手札４２ｂは、キャラクタ、アイテム又はスペルに関連付けられたカード４１を含む。ゲームは、自ユーザが他ユーザの手札４２ｂのカード４１を確認できないように構成される。ゲーム画面４０は、自ユーザの山札４４ａ及び他ユーザの山札４４ｂも示している。なお、自ユーザ又は他ユーザは、実際のプレイヤではなく、ゲームＡＩなどのコンピュータにより操作されてもよい。

各ユーザが所有する所有カード群は、ユーザの手札４２（４２ａ又は４２ｂ）及びユーザの山札４４（４４ａ又は４４ｂ）から構成され、一般的にカードデッキと呼ばれるものである。ユーザが所有する各カード４１が手札４２に含まれるか山札４４に含まれるかは、ゲームの進行に応じて決定される。手札４２は、ユーザが選択可能であり、場４３に出すことが可能なカード群であり、山札４４は、ユーザが選択不可能なカード群である。所有カード群は、複数のカード４１から構成されるものであるが、ゲームの進行上、所有カード群は１枚のカード４１から構成される場合もある。なお、各ユーザのカードデッキは、すべて異なる種類のカード４１により構成されてもよいし、同じ種類のカード４１を一部含んで構成されてもよい。また、自ユーザのカードデッキを構成するカード４１の種類は、他ユーザのカードデッキを構成するカード４１の種類と異なってもよい。また、各ユーザが所有する所有カード群は、手札４２のみから構成されてもよい。

ゲーム画面４０は、自ユーザの選択したキャラクタ４５ａと、他ユーザの選択したキャラクタ４５ｂとを示す。ユーザが選択するキャラクタ４５ａ、４５ｂは、カードと関連付けられるキャラクタとは異なるものであり、所有カード群のタイプを示すクラスを定める。本実施形態のゲームは、クラスに応じて、ユーザが所有するカード４１が異なるように構成される。１つの例では、本実施形態のゲームは、各ユーザのカードデッキを構成することができるカードの種類が、クラスに応じて異なるように構成される。ただし、本実施形態のゲームは、クラスを含まないこともできる。この場合、本実施形態のゲームは、上記のようなクラスによる限定を行わず、ゲーム画面４０は、自ユーザの選択したキャラクタ４５ａと、他ユーザの選択したキャラクタ４５ｂとを表示しないものとすることもできる。

本実施形態のゲームの詳細としては、以下のようなゲームを想定している。
・１つの対戦（カードバトル）が複数のターンを含む対戦ゲームである。
・カードデッキは、４０枚のカード４１から構成され、対戦開始時における各ユーザの手札４２と山札４４のカード４１の合計は、各々４０枚である。
・自ユーザ又は他ユーザは、各ターンにおいて、自身のカード４１を選択するなどの操作を行うことにより、相手のカード４１若しくはキャラクタ４５を攻撃することができ、又は、所定の効果若しくはイベントを発生させることができる。
・カード４１は、ユーザ１の手札４２ａ、ユーザ２の手札４２ｂ、ユーザ１の山札４４ａ、ユーザ２の山札４４ｂ、場４３、墓場、消滅、拡張的な場所Ａ、拡張的な場所Ｂ、又は無のいずれかの場所に存在する。
・一のカード４１が一のユーザの手札４２から場４３に出された場合、一のユーザの手札４２から１枚カードが減り、場４３のカードが一枚増える。
・場４３に出されたカード４１は、他のカード４１が場に出されることにより、消滅するか、墓場に置かれるか、又は他の拡張的な場所に置かれる。
・カード４１は、手札４２から場４３に出したときに効果を発動して新たなカードを生成するカードを含み、生成されたカード（トークンカード）は、対戦開始時の各ユーザの手札４２と山札４４のカード４１に含まれないカードである。
・トークンカードの枚数は、カードデッキを構成するカード４１により異なるが、２０枚程度であることが多い。
・手札４２又は山札４４にあるカード４１は、強化効果などの状態変化をすることがある。
・手札４２にあるカード４１は、他のカード４１と融合することがある。
・墓場に置かれたカード４１は、場４３に戻ることがあり、又は無に置かれることがある。
・場４３に出されたカード４１は、進化や状態変化などの付加的な状態を持つ。
リプレイログは、上述するような情報の履歴を網羅的に含むものとすることができる。上述の本実施形態のゲームは、１つの例示であって、これに限定されるものではないが、本実施形態の推定装置１０が対象とするゲームは、所定の枚数のカードが、状態変化を伴いながら所定の場所を移動し、勝敗が決するようなゲームである。

図１は本発明の一実施形態の推定装置１０のハードウェア構成を示すブロック図である。推定装置１０は、プロセッサ１１、入力装置１２、表示装置１３、記憶装置１４、及び通信装置１５を備える。これらの各構成装置はバス１６によって接続される。なお、バス１６と各構成装置との間には必要に応じてインタフェースが介在しているものとする。推定装置１０は、一般的なサーバやＰＣ等と同様の構成を含む。

プロセッサ１１は、推定装置１０全体の動作を制御する。例えばプロセッサ１１は、ＣＰＵである。プロセッサ１１は、記憶装置１４に格納されているプログラムやデータを読み込んで実行することにより、様々な処理を実行する。プロセッサ１１は、複数のプロセッサから構成されてもよい。

入力装置１２は、推定装置１０に対するユーザからの入力を受け付けるユーザインタフェースであり、例えば、タッチパネル、タッチパッド、キーボード、マウス、又はボタンである。表示装置１３は、プロセッサ１１の制御に従って、アプリケーション画面などを推定装置１０のユーザに表示するディスプレイである。

記憶装置１４は、主記憶装置及び補助記憶装置を含む。主記憶装置は、例えばＲＡＭのような半導体メモリである。ＲＡＭは、情報の高速な読み書きが可能な揮発性の記憶媒体であり、プロセッサ１１が情報を処理する際の記憶領域及び作業領域として用いられる。主記憶装置は、読み出し専用の不揮発性記憶媒体であるＲＯＭを含んでいてもよい。補助記憶装置は、様々なプログラムや、各プログラムの実行に際してプロセッサ１１が使用するデータを格納する。補助記憶装置は、情報を格納できるものであればいかなる不揮発性ストレージ又は不揮発性メモリであってもよく、着脱可能なものであっても構わない。

通信装置１５は、ネットワークを介してユーザ端末又はサーバなどの他のコンピュータとの間でデータの授受を行うことが可能なモジュール、デバイス、又は装置である。通信装置１５は、無線通信用のデバイスやモジュールなどとすることもできるし、有線通信用のデバイスやモジュールなどとすることもできる。

推定装置１０は、ゲームに関するログデータであるリプレイログを、ゲームサーバから取得できるように構成される。リプレイログは、１つのバトルごとのログデータであるリプレイログ要素配列を複数含んで構成される。リプレイログは、ゲーム状態のデータ及びアクションのデータを含む。例えばリプレイログ要素配列の各々は、時間の経過に沿って並べられたゲーム状態のデータ及びアクションのデータを含む。この場合、ゲーム状態のデータやアクションのデータの各々がリプレイログ要素である。１つの例では、リプレイログ要素配列は、ターンごとかつユーザごとの、各ユーザが選択したカード４１と、これに関連する攻撃の情報とを含む。１つの例では、リプレイログ要素配列は、ターンごとかつユーザごとの、各ユーザが選択したカード４１と、これに関連する発生した所定の効果又はイベントの情報とを含む。ただし、リプレイログ要素配列は、１つのバトル以外の予め決められた単位ごとのログデータであってもよい。

ゲーム状態のデータは、ゲーム内のすべての場所（例えばユーザ１の手札４２ａ、ユーザ２の手札４２ｂ、ユーザ１の山札４４ａ、ユーザ２の山札４４ｂ、場４３、墓場、消滅、操縦、融合素材、無）に存在するカード４１に関するデータを含む。ゲーム状態のデータの各々は、ゲームの進行に応じたその時々のゲーム状態に対応するデータである。ただし、ゲーム状態は、少なくとも、ユーザがゲームプレイを通じて、例えばゲーム操作やゲーム画面上の表示を通じて、視認又は認知できる情報を示すものであれば、上記に限定されない。

アクションは、あるゲーム状態においてユーザ操作により実行され、当該ゲーム状態を変化させうるものである。例えばアクションは、一のカード４１若しくはキャラクタ４５の他のカード４１若しくはキャラクタ４５に対する攻撃であり、又は一のカード４１若しくはキャラクタ４５による所定の効果若しくはイベントの発生などである。例えばアクションは、ユーザがカード４１などを選択することにより実行される。アクションのデータの各々は、ゲーム状態の各々においてユーザにより選択されたアクションに対応するデータである。１つの例では、アクションのデータは、一のゲーム状態において、ユーザが攻撃させようとするカード４１と攻撃対象のカード４１を選択したことを示すデータを含む。１つの例では、アクションのデータは、一のゲーム状態において、ユーザが使用するカード４１を選択したことを示すデータを含む。

本実施形態では、リプレイログは、場４３の状態を示す木構造のテキストデータのゲーム状態のデータと、そのゲーム状態においてユーザが実行したアクションのデータの列により定義される。１つのリプレイログ要素配列Ｒｅｐｌａｙｌｏｇ_nは、初期のゲーム状態と最初のアクションの対と、アクションの影響を受けた結果としてのゲーム状態と次のアクションの対とを含み、かつ最終的に勝敗が決した最終のゲーム状態で終端した配列又は進行が不可能なエラーが生じた最終のゲーム状態で終端した配列であり、式（１）で表すことができる。

（１）
ここで、Ｒｅｐｌａｙｌｏｇ_nはｎ番目のリプレイログ要素配列を示し、Ｓｔａｔｅ_iは、ｉ番目のゲーム状態を示し、Ａｃｔｉｏｎ_iは、ｉ番目に実行されたアクションを示し、Ｓｔａｔｅ_eは、勝敗、引き分け、又は無効試合などの最終のゲーム状態を示す。なお、ｎ番目のリプレイログ要素配列Ｒｅｐｌａｙｌｏｇ_nのＳｔａｔｅ_iとＡｃｔｉｏｎ_iであることを明示するため、式（１）は、以下の式で表すこともできる。

以下の説明において、

のｎのような上付き添字は、特に言及が無い限り、Ｒｅｐｌａｙｌｏｇを識別するための識別番号又は識別子に対応する文字として示される。

１つの例では、ゲームの１つの場面の状態を表すＳｔａｔｅ_iは、ゲーム内のすべての場所に存在するカード４１の集合であり、式（２）に示すベクトルＳｖ_i（Ｓｔａｔｅベクトル）で表すことができる。

（２）
ここで、ｃａｒｄ₁～ｃａｒｄ_kは、各カードを示すカード要素であり、カードの状態をｃａｒｄ．ｓｔａｔｅとしてカードのＩＤ内にエンコードしたものであり、Ｓｖ_iは、式（２）に示すように、ｋ次元のベクトルとして表される。対戦開始時の２人のユーザの手札４２と山札４４のカード４１の合計が８０枚であり、ゲームの進行中に生成されるトークンカードが約２０枚であることから、ｋは、大凡１００である。本実施形態では、説明の便宜上、以下ではｋ＝１００として説明するが、この値に限定されない。また本実施形態では、ｃａｒｄ₁～ｃａｒｄ_kは、ｋ種類のカードを示すものである。

本実施形態では、カードの状態は、表１に示す２６通りであり、ｃａｒｄ₁～ｃａｒｄ_kの各々において２６通りのＩＤを持つ。このように、状態の異なるカードは、異なる識別子を持つように構成される。

このように、ｃａｒｄ．ｓｔａｔｅを用いたＳｔａｔｅ_iを用いることにより、ゲームのある特定のシーンの状態を、ｋ次元の数値ベクトルとしてエンコードすることができる。また、このベクトルの次元数は、１つのバトル内では不変であるため、Ｓｔａｔｅベクトルの配列を、行列としてモデル化することができる。したがって、式（３）に表すように、１つのリプレイログ要素配列（ｒｅｐｌａｙｌｏｇ_n）は、１つの行列、ＲｅｐｌａｙｌｏｇＭａｔｒｉｘ_nとしてモデル化できる。

（３）

１つの例では、ゲーム内に２０００種類のカードがあるとき、Ｓｔａｔｅベクトルは、ｃａｒｄ_j（ｊ＝１～２０００）の２０００次元のベクトルである。この場合、ゲームの１つの場面の状態を５２０００（＝２０００×２６）個のＩＤの組み合わせとして表現することができる。なお、この場合、１つのバトル（リプレイログ要素配列）において、多くの種類のカードは出現せず、出現しないカードは、表１に示す２６通りのいずれの状態でもないため、表１に示すＩＤを持たないこととなる。

図２は本発明の一実施形態の推定装置１０の機能ブロック図である。推定装置１０は、ラベリング部２１、ゲーム状態配列データ生成部２２、アクション配列データ生成部２３、データ抽出部２４、及び決定部２５を備える。本実施形態においては、記憶装置１４に記憶されている又は通信装置１５を介して受信したプログラムがプロセッサ１１により実行されることによりこれらの機能が実現される。このように、各種機能がプログラム読み込みにより実現されるため、１つのパート（機能）の一部又は全部を他のパートが有していてもよい。ただし、各機能の一部又は全部を実現するための電子回路等を構成することによりハードウェアによってもこれらの機能は実現してもよい。

ラベリング部２１は、リプレイログに含まれるリプレイログ要素配列の各々に対して正常又は異常を示すラベルを付与する。ラベリング部２１は、正常終了したリプレイログ要素配列に対しては正常を示すラベルを付与し、異常終了したリプレイログ要素配列に対しては異常を示すラベルを付与する。このようにして、リプレイログが含むリプレイログ要素配列は、正常を示すラベルが付与されたリプレイログ要素配列である正常ログデータ配列（正常ログデータ要素配列）の集合Ｒと、異常を示すラベルが付与されたリプレイログ要素配列である異常ログデータ配列（異常ログデータ要素配列）の集合Ｉとに分けられる。本実施形態では、ゲームサービスを構成する全ての要素の仮想化を実現した仮想システムが、ゲームサービスの挙動をログデータとして取得することができる。１つの例では、仮想システムは、１０万回以上のバトルを実行し、バトルの結果、クライアント側のエラーログ、サーバ側のエラーログ、及びリプレイログのスナップショットなどを網羅的に保存する。なお、ラベルを付与することは、フラグを立てることなどの同等の機能を意味することができる。

１つの例では、ラベリング部２１は、式（４）に示すｌａｂｅｌ関数を用いて実現される。

（４）
ｌａｂｅｌ関数は、ｉ番目のＲｅｐｌａｙｌｏｇ_iに対応するクライアント側又はサーバ側ログデータであるｃｓｌｏｇ＿ｉを参照する。ｃｓｌｏｇ＿ｉは、Ｒｅｐｌａｙｌｏｇ_iに関連付けて、ゲームサーバと、ゲームが実行されるクライアントとに記憶されるログである。ｌａｂｅｌ関数は、Ｒｅｐｌａｙｌｏｇ_iが正常終了した場合はＲｅｇｕｌａｒラベルを返却し、Ｒｅｐｌａｙｌｏｇ_iが異常終了した場合、すなわち不具合が発生した場合はＩｒｒｅｇｕｌａｒラベルを返却する。

ｌａｂｅｌ関数は、ログデータ内の文字列照合のみで実装することができる。例えば、無効試合（ＮＯ ＣＯＮＴＥＳＴ）の場合、サーバ側のエラーログ内に“ＮＯ ＣＯＮＴＥＳＴ”という文字列が記録されているため、ｌａｂｅｌ関数は、この文字列を検索することで不具合が生じたか否かを判定することができる。例えば、クライアント側エラーの場合、ｌａｂｅｌ関数は、“ＮｕｌｌＰｏｉｎｔｅｒＥｘｃｅｐｔｉｏｎ”のようなスタックトレースに出力される所定のエラー文字列を照合することにより、不具合が生じたか否かを判定することができる。

ゲーム状態配列データ生成部２２は、一のリプレイログ要素配列から、ゲーム状態のデータを時間順に並べたゲーム状態配列データ（ＲｅｐｌａｙｌｏｇＭａｔｒｉｘ_n）を生成する。ゲーム状態配列データ生成部２２は、集合Ｒが含むリプレイログ要素配列の各々と、集合Ｉが含むリプレイログ要素配列の各々において、ゲーム状態配列データを生成する。１つの例では、ゲーム状態配列データは、生成元のリプレイログ要素配列と関連付けられている。

１つの例では、ゲーム状態配列データ生成部２２は、式（５）に示すｅｎｃｏｄｅ＿ｓｔａｔｅ関数を用いて実現される。

（５）
ｅｎｃｏｄｅ＿ｓｔａｔｅ関数は、リプレイログ要素配列Ｒｅｐｌａｙｌｏｇ_nが含むすべてのゲーム状態を式（２）で示すＳｔａｔｅベクトルに変換し、式（３）で示すＲｅｐｌａｙｌｏｇＭａｔｒｉｘ_nに変換する。ＲｅｐｌａｙｌｏｇＭａｔｒｉｘ_nは、Ｓｔａｔｅベクトルの配列であり、ｉ番目のＳｔａｔｅベクトル

は、当該リプレイログ要素配列において初期のゲーム状態からｉ回変化したゲーム状態に対応するベクトルである。Ｓｔａｔｅベクトルの各々は、ゲーム中に扱われる１００枚のカードの状態を網羅的に記録したものである。

図４は、ＲｅｐｌａｙｌｏｇＭａｔｒｉｘ_nの一例を示す図である。行の要素のｃ₁～ｃ₂₆₀₀は、ｃａｒｄ₁～ｃａｒｄ₁₀₀の各々の２６の状態を表し、例えばｃ₁～ｃ₂₆は、ｃａｒｄ₁の２６の状態を表す。列の要素は、各々Ｓｔａｔｅベクトルに対応し、１行目がＳｖ₀、最終行目がＳｖ_eに対応し、上から下へ時間順に並んでいる。行列の各要素は、「０」か「１」が格納され、そのときのゲーム状態が含むカード状態であれば「１」が格納され、そうでない場合は「０」が格納される。

アクション配列データ生成部２３は、一のリプレイログ要素配列から、アクションのデータを時間順に並べたアクション配列データを生成する。アクション配列データ生成部２３は、集合Ｒが含むリプレイログ要素配列の各々においてアクション配列データＲａｃｔｉｏｎを生成し、集合Ｉが含むリプレイログ要素配列の各々においてアクション配列データＩａｃｔｉｏｎを生成する。１つの例では、アクション配列データは、生成元のリプレイログ要素配列と関連付けられている。

１つの例では、アクション配列データ生成部２３は、式（６）に示すｅｎｃｏｄｅ＿ａｃｔｉｏｎ関数を用いて実現される。

（６）
ｅｎｃｏｄｅ＿ａｃｔｉｏｎ関数は、リプレイログ要素配列を受け取り、リプレイログ要素配列が含むアクションのデータを抽出したＲａｃｔｉｏｎ又はＩａｃｔｉｏｎのアクション配列データを生成する。

は、Ｒｅｐｌａｙｌｏｇ_nの最初のアクションを示し、

は、Ｒｅｐｌａｙｌｏｇ_nの最後のアクションを示す。集合Ｒが含むα番目のＲｅｐｌａｙｌｏｇ_αから生成されるアクション配列データＲａｃｔｉｏｎと、集合Ｉが含むβ番目のＲｅｐｌａｙｌｏｇ_βから生成されるアクション配列データＩａｃｔｉｏｎは、式（７）、式（８）のようにモデル化される。

（７）

（８）

データ抽出部２４は、一の異常ログデータ配列が含む不具合発生前のアクションに関連するゲーム状態が含むカード要素から所定のカード要素を抽出する。所定のカード要素は、ゲーム状態が含むカード要素の少なくとも一部のカード要素である。１つの例では、データ抽出部２４は、不具合原因を推定する対象の異常ログデータ配列の各々において、異常ログデータ配列が含む不具合発生前のアクションに関連するゲーム状態が含むカード要素から所定のカード要素を抽出する。本実施形態では、データ抽出部２４は、一の異常ログデータ配列が含む不具合発生直前のアクションの直前の１つのゲーム状態が含むカード要素から所定のカード要素を抽出する。

１つの例では、データ抽出部２４は、式（９）に示すｃｏｍｂｉｎａｔｉｏｎ関数を用いて実現される。

（９）
ｃｏｍｂｉｎａｔｉｏｎ関数は、１つのゲーム状態を示すＳｔａｔｅベクトルから、カード要素ｗ個（ｃａｒｄ₀、ｃａｒｄ₂…ｃａｒｄ_q）の組み合わせを抽出（出力）する。データ抽出部２４は、ｃｏｍｂｉｎａｔｉｏｎ関数を用いて、一の異常ログデータ配列が含む不具合発生直前のアクションの直前の１つのゲーム状態（Ｓｔａｔｅベクトル）が含むカード要素から、カード要素ｗ個の組み合わせを抽出する。このカード要素ｗ個が、所定のカード要素であり、Ｓと呼ぶ。カード要素Ｓは、予め決められたｗ個（１≦ｗ≦ｋ）のカード要素であってもよいし、設定された規則に従ってゲーム状態に応じて抽出されたｗ個のカード要素であってもよい。なお、式（９）において、ｃａｒｄ₀、ｃａｒｄ₂…ｃａｒｄ_qの表記は１つの例示であって、これに限定されない。１つの例では、データ抽出部２４は、アクション配列データＩａｃｔｉｏｎにより不具合発生直前のアクションを認識し、該アクションの直前の１つのゲーム状態Ｓｔａｔｅベクトルを取得し、該ゲーム状態が含むカード要素Ｓを抽出し、出力する。

決定部２５は、不具合原因を推定する対象の一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のカード要素との組み合わせがリプレイログに含まれる異常ログデータ配列において存在する（含まれる）度合と、該組み合わせがリプレイログに含まれる正常ログデータ配列において存在する（含まれる）度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定する。１つの例では、決定部２５は、一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のカード要素との組み合わせがリプレイログに含まれる異常ログデータ配列において存在する度合に基づく値の、該組み合わせがリプレイログに含まれる正常ログデータ配列において存在する度合に基づく値に対する比率が所定値以上であるときに、該組み合わせが不具合を発生させる原因であると決定する。本実施形態では、決定部２５は、一の異常ログデータ配列が含む不具合発生直前の１つのアクションと該アクションの直前の１つのゲーム状態が含む所定のカード要素との組み合わせがリプレイログに含まれる異常ログデータ配列において存在する度合と、該組み合わせがリプレイログに含まれる正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定する。

１つの例では、決定部２５は、式（１０）に示す相関ルール学習関数（ＳｉｍｕｌａｔｅｄＣｏｎｆｉｄｅｎｃｅ関数）を用いて実現される。

（１０）
ここで、Ａ_pは、不具合原因を推定する対象の不具合の発生直前のアクションを示し、Ｓ_pはＡ_pの直前のゲーム状態が含むカード要素Ｓを示し、ｆｒｅｑ（Ａ_p，Ｓ_p｜Ｓ_p∈Ｉ）は、リプレイログに含まれる異常ログデータ配列においてＳ_pを含むゲーム状態とＡ_pがこの順番（時間順）で存在（出現）する頻度を示す。換言すると、ｆｒｅｑ（Ａ_p，Ｓ_p｜Ｓ_p∈Ｉ）は、リプレイログに含まれる異常ログデータ配列におけるＡとＳの共起頻度を示す。Ｓ’_pは、正常ログデータ配列に含まれるＳ_pと同一のカード要素Ｓを示し、ｆｒｅｑ（Ａ_p，Ｓ’_p｜Ｓ’_p∈Ｉ）は、リプレイログに含まれる正常ログデータ配列においてＳ’_pを含むゲーム状態とＡ_pがこの順番（時間順）で存在（出現）する頻度を示す。相関ルール学習関数は、不具合発生直前のアクションＡ_pと、その直前のゲーム状態が含むカード要素Ｓ_pとの、不具合発生に関する相関関係の強さを示すものである。決定部２５は、相関ルール学習関数の出力値が閾値ｔを超えるＡ_pとＳ_pとのペアを、「不具合を引き起こす原因要素」として特定する。決定部２５は、相関ルール学習関数を実装する場合、最初にｆｒｅｑ（Ａ_p，Ｓ_p｜Ｓ_p∈Ｉ）を計算し、計算値が閾値ｉｔを超えるＡ_pとＳ_p（Ｓ’_p）のペアをｆｒｅｑ（Ａ_p，Ｓ’_p｜Ｓ’_p∈Ｉ）の計算対象として、当該関数を用いる。なお、式（１０）は、ゼロによる除算を防止するために１などの所定値を分母に加えてもよい。或いは、分子や分母に所定の値を加算又は減算することにより、相関関係の出力値を調整してもよい。

１つの例では、決定部２５は、ｆｒｅｑ（Ａ_p，Ｓ_p｜Ｓ_p∈Ｉ）を算出するとき、ＩａｃｔｉｏｎからアクションＡ_pと同じアクションＡ_iを抽出し、Ｓｔａｔｅベクトルを参照して抽出したアクションＡ_iの直前のゲーム状態に含まれるカード要素がＳ_pと同じものを含む異常ログデータ配列の数を算出する。この場合、決定部２５は、ｆｒｅｑ（Ａ_p，Ｓ’_p｜Ｓ’_p∈Ｉ）を算出するとき、ＲａｃｔｉｏｎからアクションＡ_pと同じアクションＡ_iを抽出し、Ｓｔａｔｅベクトルを参照して抽出したアクションＡ_iの直前のゲーム状態に含まれるカード要素がＳ_p（Ｓ’_p）と同じものを含む正常ログデータ配列の数を算出する。

次に、本発明の一実施形態の推定装置１０の推定処理について図５に示したフローチャートを用いて説明する。

ステップ１０１において、ラベリング部２１は、リプレイログに含まれるリプレイログ要素配列の各々に対して正常又は異常を示すラベルを付与する。

ステップ１０２において、データ抽出部２４は、不具合原因を推定する対象の一の異常ログデータ配列が含む不具合発生前のアクションに関連するゲーム状態が含むカード要素から所定のカード要素を抽出する。

ステップ１０３において、決定部２５は、不具合原因を推定する対象の一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のカード要素との組み合わせがリプレイログに含まれる異常ログデータ配列において存在する度合と、該組み合わせがリプレイログに含まれる正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定する。

次に、本発明の実施形態の推定装置１０の主な作用効果について説明する。

本実施形態では、ゲームを構成するサービスすべてをエンドツーエンドで仮想化し、その仮想環境から、ゲームサービスの挙動をログデータとして取得することができる。この仕組みにより、リプレイログ要素配列の各々に対する正常又は異常を示すラベルの付与を容易に実装することができる。そして本実施形態では、決定部２５は、不具合原因を推定する対象の一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のカード要素との組み合わせがリプレイログに含まれる異常ログデータ配列において存在する度合と、該組み合わせがリプレイログに含まれる正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定する。

不具合原因の推定に関しては、従来、プログラム解析技術を用いるアプローチや、バグレポートにデータマイニング技術を適用するアプローチがあるが、これらは、ＰＶＰゲームにおける無効試合や、クライアント／サーバ間のデータや挙動の不整合などのゲーム固有の不具合を網羅的に検出することはできなかった。特に、近年のゲームは、プログラムコード本体よりも、ゲーム内で使用するデータが果たす役割が増大しており、従来技術では検出できない、データ由来の不具合が多発している。

本実施形態のような構成とすることにより、原因を明らかにするためには人手の解析を必要とした、ゲームにおける組み合わせパターンに由来する不具合の原因を、ゲームログから自動的に見つけ出す（推定する）ことが可能となる。これにより、ゲーム運営やゲーム開発の更なる効率化を実現することが可能となる。

また本実施形態の推定装置１０の大きな優位性は、これまで死蔵されてきた膨大な量の正常系リプレイログを、データマイニングにおける相関ルール学習（本実施形態における相関ルール学習関数の算出）に適用可能な情報資源に変換できることである。本実施形態が示す方式のように、ゲームを構成するサービスすべてをエンドツーエンドで仮想化し、その仮想環境から得られるあらゆるログデータを対象としてデータマイニングを適用する方式は提案されていない。このような仮想環境によるリプレイログを活用することにより、デバッグをより効率化することが可能となる。

また本実施形態の推定方法は、ターン制の対戦ゲームに幅広く適用可能なものであり、人間のプレイ傾向を模倣するＡＩによるデバッグを様々なジャンルに広げることが可能となる。また本実施形態の不具合を推定するための方法は、リプレイログが継続的に拡張される場合に対応可能な方法であり、長期間運用されるゲームタイトルに適したものである。また本実施形態においては、ＡＩが自動プレイを担うため、新たにリリースされた新規カードに対しても、ゲームログデータから不具合原因を推定することが可能となる。また本実施形態における相関ルール学習は、極めて汎用性の高いアルゴリズムであり、特定のゲームジャンルや特定のデータには依存していない。したがって、ゲームのルールの変化に応じて、自動的にリプレイログ行列の次元数を増減させられるため、メンテナンスコストを低減させることが可能となる。

上記の作用効果は、特に言及が無い限り、他の実施形態や変形例においても同様である。

本発明の他の実施形態では、上記で説明した本発明の実施形態の機能やフローチャートに示す情報処理を実現するプログラムや該プログラムを格納したコンピュータ読み取り可能な記憶媒体とすることもできる。また他の実施形態では、上記で説明した本発明の実施形態の機能やフローチャートに示す情報処理を実現する方法とすることもできる。また他の実施形態では、上記で説明した本発明の実施形態の機能やフローチャートに示す情報処理を実現するプログラムをコンピュータに供給することができるサーバとすることもできる。また他の実施形態では、上記で説明した本発明の実施形態の機能やフローチャートに示す情報処理を実現する仮想マシン又はクラウドシステムとすることもできる。

本発明の実施形態において、カード４１（カード群）は、キャラクタやアイテムなどの媒体（媒体群）とすることができ、所有カード群は、ユーザが所有する複数の媒体を含んで構成される所有媒体群とすることができる。例えば媒体群がキャラクタとアイテムの媒体により構成される場合、ゲーム画面４０は、カード４１として、キャラクタ又はアイテムそのものを示すこととなる。同様にして、カード要素は、カードに限定されない媒体要素であるゲーム状態要素とすることができる。

本発明の実施形態において、カード要素の各々が持つカードの状態は、２６通りに限定されず、任意の数の状態とすることができる。例えば、カードの状態について、ｃａｒｄ₁～ｃａｒｄ_kの各々において３０通りのＩＤを持ち、式（２）におけるｋ＝１００００の場合、図４に示すＲｅｐｌａｙｌｏｇＭａｔｒｉｘ_nの列の要素はＣ₁～Ｃ₃₀₀₀₀₀の３０万個となる。またカード要素のカードの状態が識別できれば、カード要素が持つカード状態の情報は、本実施形態が示す方法に限定されない。

本発明の１又は複数の実施形態では、式（２）に示すｃａｒｄ₁～ｃａｒｄ_kは、ｋ種類のカードを示すものであるが、ｋ種類のカードのうちの少なくとも一部のカードは、同一のカードであってもよい。この実施形態では、ゲーム状態配列データ生成部２２は、そのときのゲーム状態が含むカード状態に応じて、ＲｅｐｌａｙｌｏｇＭａｔｒｉｘ_nの行列の各要素に「０」又は「１」のいずれかを格納するように構成される。

本発明の１又は複数の実施形態では、式（２）に示すｃａｒｄ₁～ｃａｒｄ_kは、すべて種類が異なるｋ種類のカードを示すものとすることができる。この実施形態においては、ゲーム状態配列データ生成部２２は、ＲｅｐｌａｙｌｏｇＭａｔｒｉｘ_nの行列の要素に「０」又は「１」以外の数値又は情報を格納することができる。例えばある１つのゲーム状態において同一のカードの状態（ｃａｒｄ．ｓｔａｔｅ）を持つ同一のカードが複数枚（例えば３枚）存在する場合（例えばある１つのゲーム状態において同一のカードが１人のユーザの手札に複数存在する場合）、ゲーム状態配列データ生成部２２は、ＲｅｐｌａｙｌｏｇＭａｔｒｉｘ_nの行列の対応する要素に、その数量（例えば「３」）又は該数量に対応する情報を格納するように構成される。

本発明の実施形態においては、ゲームサービスをエンドツーエンドで仮想化し、その仮想環境から、ゲームサービスの挙動をログデータとして取得することができる。仮想環境においては、処理の高速化を目的としてヘッドレスモードでゲームが実行されるため、クライアントはディスプレイを備えなくてもよい。図３が示すゲーム画面の例示は、ゲームの内容を説明するためのものであって、実際にディスプレイにゲーム画面を表示する必要はない。

本発明の実施形態においては、推定装置１０以外の他のシステム、例えばゲームサービスをエンドツーエンドで仮想化した仮想環境が、ラベリング部２１の機能を備えることができ、この場合、推定装置１０は、ラベリング部２１の機能を備えなくてもよい。この実施形態では、推定装置１０は、正常又は異常を示すラベルが付与されたリプレイログを他のシステム（仮想環境）から受信できるように構成される。この実施形態では、図５に示すフローチャートはステップ１０１を含まなくてもよい。

本発明の変形例では、データ抽出部２４は、一の異常ログデータ配列が含む不具合発生直前のＭ個（Ｍ≧２）のアクションの各々の直前のゲーム状態の各々が含むカード要素から所定のカード要素を各々抽出する。

本変形例においては、例えばＭ＝２の場合、データ抽出部２４は、式（９）に示すｃｏｍｂｉｎａｔｉｏｎ関数の代わりに、式（１１）に示すｃｏｍｂｉｎａｔｉｏｎ関数を用いて実現される。

（１１）
ｃｏｍｂｉｎａｔｉｏｎ関数は、ゲーム状態配列データにおいて隣接する２つのＳｔａｔｅベクトルの各々から、カード要素ｗ個（ｃａｒｄ₀、ｃａｒｄ₂…ｃａｒｄ_q）の組み合わせを各々抽出（出力）する。データ抽出部２４は、ｃｏｍｂｉｎａｔｉｏｎ関数を用いて、一の異常ログデータ配列が含む不具合発生直前の２個のアクションの各々の直前のゲーム状態の各々が含むカード要素から、カード要素ｗ個の組み合わせを各々抽出する。この２個のカード要素ｗ個の組み合わせの各々が、所定のカード要素であり、Ｓと呼ぶ。ｗ個のカード要素は、予め決められたｗ個（１≦ｗ≦ｋ）のカード要素であってもよいし、設定された規則に従ってゲーム状態に応じて抽出されたｗ個のカード要素であってもよい。なお、式（１１）において、ｃａｒｄ₀、ｃａｒｄ₂…ｃａｒｄ_qの表記は１つの例示であって、これに限定されない。例えば、データ抽出部２４は、アクション配列データＩａｃｔｉｏｎにより不具合発生直前の２個のアクションを認識し、該アクションの各々の直前のゲーム状態Ｓｔａｔｅベクトルを各々取得し、該ゲーム状態の各々が含むカード要素Ｓを各々抽出し、出力する。

本変形例においては、決定部２５は、一の異常ログデータ配列が含む不具合発生直前の２以上のアクションと該２以上のアクションの各々の直前のゲーム状態の各々が含む所定のカード要素との組み合わせがリプレイログに含まれる異常ログデータ配列において存在する度合と、該組み合わせがリプレイログに含まれる正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定する。

本変形例においては、例えばＭ＝２の場合、決定部２５は、式（１２）に示す相関ルール学習関数（ＳｉｍｕｌａｔｅｄＣｏｎｆｉｄｅｎｃｅ関数）を用いて実現される。

（１２）
Ａ_p-1とＡ_pは、不具合原因を推定する対象の不具合の発生直前の２個のアクションを示し、Ｓ_p-1とＳ_pは、各々Ａ_p-1とＡ_pの直前のゲーム状態が含むカード要素ｗ個（カード要素Ｓ）を示す。ｆｒｅｑ（Ａ_p-1，Ａ_p，Ｓ_p-1，Ｓ_p｜Ｓ_p∈Ｉ）は、リプレイログに含まれる異常ログデータ配列において、Ｓ_p-1を含むゲーム状態とＡ_p-1とＳ_pを含むゲーム状態とＡ_pがこの順番（時間順）で存在（出現）する頻度を示す。Ｓ’_pとＳ’_p-1のそれぞれは、正常ログデータ配列に含まれるＳ_p-1とＳ_pと同一のカード要素Ｓを示し、ｆｒｅｑ（Ａ_p-1，Ａ_p，Ｓ’_p-1，Ｓ’_p｜Ｓ’_p∈Ｉ）は、リプレイログに含まれる正常ログデータ配列において、Ｓ’_p-1を含むゲーム状態とＡ_p-1とＳ’_pを含むゲーム状態とＡ_pがこの順番（時間順）で存在（出現）する頻度を示す。決定部２５は、相関ルール学習関数の出力値が閾値ｔを超えるＡ_p-1、Ａ_p、Ｓ_p-1、Ｓ_pの組み合わせを、「不具合を引き起こす原因要素」として特定する。決定部２５は、相関ルール学習関数を実装する場合、最初にｆｒｅｑ（Ａ_p-1，Ａ_p，Ｓ_p-1，Ｓ_p｜Ｓ_p∈Ｉ）を計算し、計算値が閾値ｉｔを超えるＡ_p-1、Ａ_p、Ｓ_p-1、Ｓ_pの組み合わせをｆｒｅｑ（Ａ_p-1，Ａ_p，Ｓ’_p-1，Ｓ’_p｜Ｓ’_p∈Ｉ）の計算対象として、当該関数を用いる。

本発明の変形例では、決定部２５の処理以外の配列データの生成やデータ抽出の方法などは、本実施形態で説明したゲーム状態配列データ生成部２２、アクション配列データ生成部２３、及びデータ抽出部２４の処理とは異なる処理を実行してもよい。この場合、図５に示すフローチャートはステップ１０２を含まなくてもよい。

本発明の変形例では、ゲーム内に２０００種類のカードがあるとき、Ｓｔａｔｅベクトルは、ｃ_j（ｊ＝１～２０００）のうち少なくとも１度出現したカードに関するカード要素Ｎ個を含むＮ次元ベクトルである。この場合、Ｎは、バトルごとに、すなわちリプレイログ要素群ごとに、異なる値となりうるものである。

以上に説明した処理又は動作において、あるステップにおいて、そのステップではまだ利用することができないはずのデータを利用しているなどの処理又は動作上の矛盾が生じない限りにおいて、処理又は動作を自由に変更することができる。また以上に説明してきた各実施例は、本発明を説明するための例示であり、本発明はこれらの実施例に限定されるものではない。本発明は、その要旨を逸脱しない限り、種々の形態で実施することができる。

１０ 推定装置
１１ プロセッサ
１２ 入力装置
１３ 表示装置
１４ 記憶装置
１５ 通信装置
１６ バス
２１ ラベリング部
２２ ゲーム状態配列データ生成部
２３ アクション配列データ生成部
２４ データ抽出部
２５ 決定部
４０ ゲーム画面
４１ カード
４２ 手札
４３ 場
４４ 山札
４５ キャラクタ

Claims (9)

1. ユーザにより選択されたアクションに応じて進行し、ゲーム状態が更新されるゲームにおいて、ゲームログデータから不具合原因を推定するための、コンピュータにより実行される方法であって、該ゲーム状態は複数のゲーム状態要素を含んで構成され、該ゲームログデータは複数のログデータ配列を含み、ログデータ配列の各々は正常又は異常を示すラベルが付与されるものであり、該方法は、
   異常を示すラベルが付与されたログデータ配列である異常ログデータ配列のうちの一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常を示すラベルが付与されたログデータ配列である正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定するステップ、を含む
   方法。
2. 前記決定するステップは、一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータにおいて存在する度合に基づく値の、該組み合わせがゲームログデータに含まれる正常ログデータ配列において存在する度合に基づく値に対する比率が所定値以上であるときに、該組み合わせが不具合を発生させる原因であると決定することを含む、請求項１に記載の方法。
3. ログデータ配列の各々に対して正常又は異常を示すラベルを付与するステップを含む、請求項１又は２に記載の方法。
4. 前記方法は、
   一の異常ログデータ配列が含む不具合発生前のアクションに関連するゲーム状態が含むゲーム状態要素から所定のゲーム状態要素を抽出するステップを含み、
   前記決定するステップは、一の異常ログデータ配列が含む不具合発生前のアクションと前記抽出された所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定することを含む、
   請求項１から３のいずれか１項に記載の方法。
5. 前記決定するステップは、一の異常ログデータ配列が含む不具合発生直前の１つのアクションと該アクションの直前のゲーム状態が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定することを含む、請求項１から４のいずれか１項に記載の方法。
6. 前記決定するステップは、一の異常ログデータ配列が含む不具合発生直前の２以上のアクションと該２以上のアクションの各々の直前のゲーム状態の各々が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定することを含む、請求項１から４のいずれか１項に記載の方法。
7. 請求項１から６のいずれか１項に記載の方法の各ステップをコンピュータに実行させるプログラム。
8. ユーザにより選択されたアクションに応じて進行し、ゲーム状態が更新されるゲームにおいて、ゲームログデータから不具合原因を推定するための推定システムであって、該ゲーム状態は複数のゲーム状態要素を含んで構成され、該ゲームログデータは複数のログデータ配列を含むものであり、該推定システムは、
   ログデータ配列の各々に対して正常又は異常を示すラベルを付与し、
   異常を示すラベルが付与されたログデータ配列である異常ログデータ配列のうちの一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常を示すラベルが付与されたログデータ配列である正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定する、
   推定システム。
9. ユーザにより選択されたアクションに応じて進行し、ゲーム状態が更新されるゲームにおいて、ゲームログデータから不具合原因を推定するための推定装置であって、該ゲーム状態は複数のゲーム状態要素を含んで構成され、該ゲームログデータは複数のログデータ配列を含み、ログデータ配列の各々は正常又は異常を示すラベルが付与されており、
   異常を示すラベルが付与されたログデータ配列である異常ログデータ配列のうちの一の異常ログデータ配列が含む不具合発生前のアクションと該アクションに関連するゲーム状態が含む所定のゲーム状態要素との組み合わせがゲームログデータに含まれる異常ログデータ配列において存在する度合と、該組み合わせがゲームログデータに含まれる正常を示すラベルが付与されたログデータ配列である正常ログデータ配列において存在する度合とに基づいて、該組み合わせが不具合を発生させる原因か否かを決定する、
   推定装置。

Images