Q. なぜガチャを検証するのか
A. 人間はミスをする生き物だから

ガチャとは？

小難しい言葉で表現すれば「ランダム型アイテム提供方式」となり、CESAのガイドラインでは以下のように定義されています。(1)

文字、絵、符号等を電磁的に表示した、ネットワークゲーム上で使用できるキャラクター、アイテム等（以下、アイテム等）を、偶然性を利用してアイテム等の種類が決まる方法によって提供する方式をいう。

ソーシャルゲームでは石と呼ばれている課金やゲームプレイによって得られるアイテムを消費してガチャを実行することが一般的でしょう。
ソーシャルゲームとは切っても切り離せない要素であり、売り上げの大部分はガチャによって支えられています。

なぜガチャを検証するのか

ガチャを検証する理由は諸説ありますが、個人的な所感としては「プレイヤーとの信頼を壊さないため」というところに尽きるでしょう。
ガチャというシステムは、プレイヤーに重い課金を強いることができながらランダムという運の要素が非常に強い仕組みを用いることからプレイヤーへの負担が非常に大きいシステムです。ガチャの結果によってゲームそのものへのモチベーションに大きく影響することもあります。
ガチャ関連の不具合はプレイヤーに与える不信感が非常に大きく、ひとたび問題を起こしてしまえば信頼の回復には多大なる時間を必要とします。ましてや消費者庁からの措置命令(いわゆる消費者庁コラボ)を受けた場合の影響は計り知れません。

ガチャ機能においてプレイヤーとの信頼関係を構築するうえで重要となる要素として確率表記があります。CESAのガイドラインでは有料ガチャにおいて提供される全てのガチャアイテムについての確率表記を行うように定められています。(1)

有料ガチャにおいては、以下の各号に示す事項を、ユーザーが容易に認識できる場所または方法により表示するものとする。
A) 有料ガチャにより取得できるガチャアイテムの一覧
B) 特定の有料ガチャにおいて、重複するガチャアイテムを入手する可能性がある場合、その旨

確率表記がガチャの仕様としてガイドラインで定められた背景にはガチャに対するプレイヤーの不信感があります。(2)
確率表記は法律で定められた義務ではありませんが、確率表記をしていないゲームにはプレイヤーから信頼を得ることは不可能に近いと言っても過言ではないでしょう。
確率表記を行うのであれば、表記された確率と実際の確率が相違していると判断されれば景品表示法違反に問われることとなりますから、なおさらガチャ自体の排出確率を検証することは必ず行わなければいけません。

「データの設定をミスなく行えば問題ない」として検証を行わない選択をしてはいけません。なぜなら人間はミスをする生き物という事実は変わらないのです。ミスが起きることを前提として、検証という仕組みでミスが世に出てしまうことを防ぐことが大事なのです。

ガチャ検証ではQAでカバーできない範囲を検証することが目的となります。
QAではガチャとしての機能が正しく動作しているかどうかをチェックできますが、排出確率の正しさや排出されるアイテムを全て網羅するようなチェックは試行回数が膨大となるため難しくなります。
機械的に数百万回の試行を行うことでQAではチェックできない要素について検証を行うことが可能です。

ガチャ検証を行うスコープ

実際にガチャ検証を行う場合、どの部分についてどのような検証を行うべきなのかが焦点となります。

排出確率

排出確率の検証はガチャ検証の本質どころか本丸です。
排出確率を検証するためには十分な試行回数を設定する必要があります。十分な試行回数とは、設定された排出アイテムの中で最も低い確率のものの確率が収束されると期待される回数です。極端に低い確率のアイテムがある場合を除けば、たいていは100万回ほどの試行回数で十分に足りるかと思われます。
十分な試行回数でガチャを実行し、期待値と実測値が許容される誤差の範囲内に収まっていれば問題ないと言えるでしょう。

排出アイテム

排出が期待されるアイテムの全てが排出されていることと、排出されてはいけないアイテムが排出されていないかどうかの2点について検証を行う必要があります。

検証以外での注意点

ガチャの実装

検証では問題なくランダムだと言えたが、実装に問題がありプレイヤーの実行時にはランダムになっていないことがあったという事例があります。
個人的な経験に基づく感覚ですが、ガチャの実装については徹底してシンプルな設計を行うべきだと思っています。シンプルであればあるほど副作用が少なくなるからです。

データ構造

実装と同様にシンプルな構造を持たせるべきです。データ構造は仕様を濃く反映しますので、ガチャの仕様もまたシンプルである方が望ましいと言えます。
そうは言っても仕様をシンプルにするというのは難しいことです。可能な限りでシンプルさを保ちながら要件を満たすように設計するところに着地できれば良いと思います。

ガチャではないガチャ

ゲームにおいてはガチャだけがガチャではありません。
ロジェ・カイヨワが自身の著書である「遊びと人間」の中で、遊びのすべてに通じる不変の性質として競争・運・模擬・眩暈の4要素を提唱したように、ゲームと運は切っても切り離せない関係にあると言えます。(3)

有料ガチャ以外の抽選要素については確率表記を行う必要はありません。しかし、ランダムという要素がプレイヤーに大きな負担を与えることは言うまでもなく、ランダムが関わる要素で不具合が発生すればガチャと同様にプレイヤーの信頼を大きく損ねます。
有料ガチャと同等の検証でなくとも、何らかの形で全ての抽選要素に機械的な検証を行う必要があると思います。

検証不足によって想定される問題

先にも書きましたが、有料ガチャにおける確率表記と実測値の乖離は景品表示法違反に問われる可能性があります。
プレイヤーの信頼を大きく損ねてしまえば、アクティブの減少から売り上げの減少に直結します。IPやデベロッパーにまで不信感が広がってしまえば他のタイトルにまで影響を及ぼすかもしれません。いわゆる消費者庁コラボと呼ばれる消費者庁からの措置命令が下れば課徴金を課されるかもしれません。

実際に検証を行う際の注意点

実際にガチャを検証する場合はガチャの実行をシミュレートするプログラムを実装することになります。

可能な限り本番と同等の環境・手順で動作させる

可能な限り本番と同等の環境で動作させるべきです。これは乱数生成ライブラリなどの挙動について完全に一致させる必要があるからです。
ガチャの試行も、実際にプレイヤーがガチャを実行する際の処理を無駄のない範囲でシミュレートすべきです。検証とプレイヤーの実行でズレが発生するという問題を防ぐことができます。

検証プログラムだけでなく、確率表記も同一環境で実行し生成する必要があります。決してExcelの計算結果をコピーして使用してはいけません。
ガチャ検証において試行結果と比較する先は確率表記です。確率表記に誤りがあれば全てが間違ってしまいます。

確率テーブルが違う場合は分けて検証する

稀によくあるミスなのですが、単発ガチャを実行するだけで検証完了としてしまう事例がありました。確かに試行回数が十分に大きい場合はOKと言える範囲に確率が収まりますが、10連ガチャの10連目確定枠の確率が検証できません。
ガチャ検証はガチャ単位ではなく確率テーブル(または抽選テーブル)ごとに検証を行う必要があります。10連の1～9連目は通常テーブルだが10連目はレアリティの確率が変わるなど、特に10連ガチャについては確率テーブルが実行回数によって変わる仕組みが用意されているかと思います。その場合には1～9連目と10連目は分離して検証を行う必要があります。

検証をやりやすくするためのユーザービリティ

ガチャ検証に使用するツールは検証を行う作業者のことを考えてUI/UXを設計・実装できるとよいと思います。ガチャ検証はガチャの更新毎に発生するタスクであり、運営において大きな負荷となります。少しでも作業者の負担を軽減できるようにすべきです。
例えば先に書いたような10連ガチャでは、1～9連目と10連目を別々に選択して実行させるよりも、1つのガチャを選択して実行すれば単発・10連1～9連目、10連10連目が全て実行されるような実装をすべきでしょう。
ガチャ検証の実装はサーバーサイドエンジニアの担当となることが多いかと思われます。普段はJSONや Protocol Buffersを出力するだけですが、良いUI/UXを考えて設計・実装を行う能力は、管理・デバッグツールの実装にも役立つでしょう。

検証結果によってNGが出た場合の対処

時と場合によって、検証結果でNGが出てしまうこともあるかと思います。その場合は様々な原因が考えられますが、大きくガチャの実装、ガチャ検証の実装、確率表記の実装、データ設定の4点に絞ることができます。

ガチャの実装

使用している乱数生成ライブラリの仕様、またはバグによって確率に誤差が生まれている
- 使用するライブラリの変更
データが特定の設定の場合に起きうるバグ
- バグの修正
実装方法に不備がある(抽選以外での排出アイテムの操作など)
- 不具合の修正
- 仕様通りであれば仕様そのものの修正

ガチャ検証の実装

検証方法の不備(確定枠の未考慮など)
- 正しい検証方法の設定と実装の修正
検証プログラムのバグ
- バグの修正

確率表記の実装

確率を算出するプログラムが同一環境で実行されていない(計算結果の誤差など)
- 運営フローの見直し
確率表記プログラムのバグ
- バグの修正

データ設定

データ設定のミスによる想定外の動作
- データチェックの実装

ガチャ検証を統括している部署があるのなら、そこにガチャ実装のソースコードやマスターデータを提出する必要があるかもしれません。そういう部署が無くても、可能な限りのチェックを複数人で行ったうえで問題が無いと言い切れる状態でなければ、そのデータをリリースしてはいけません。

ガチャについて思うこと

ガチャに関する暗い話題が出てくるたびに、過去に携わったプロジェクトのディレクターが「課金していただく」と言っていたことを思い出します。課金は当たり前の行為ではなく、ゲームを有利に進めて楽しむための仕方のない行為だという想いが込められていました。

「1行のログの向こうには1人のユーザーがいる」という言葉があります。ソシャゲにおいては「1行のガチャ実行ログの向こうには1人のプレイヤーが3,000円を払っている」と言えるでしょう。売り上げや管理画面で見える数字だけを見ていると感覚がマヒしがちですが、1人のプレイヤーが10連1回3,000円という金額を払った想いを大事にしていきたいものですね。

以上、ソーシャルゲームの開発・運営に7年ほど携わったサーバーサイドエンジニアの駄文でした。

参考文献

(1). CESA. ネットワークゲームにおけるランダム型アイテム提供方式運営ガイドライン. CESA（一般社団法人コンピュータエンターテインメント協会）公式ページ. 2016. https://www.cesa.or.jp/action/for-stakeholders/provide-items/, 2024-11-20 参照

(2). 信原一貴. ガチャ確率公開、各社の対応は？　2強メーカー「予定なし」の理由. withnews. 2016. https://withnews.jp/article/f0160626001qq000000000000000w03610701qq000013534a. 2024-11-20 参照

(3). ロジェ・カイヨワ. 遊びと人間 (講談社学術文庫 920). 日本. 講談社. 1990. 390p