ゲーム会社のガチャ炎上を防ぐ監査フローの属人化をPMが解消した話
はじめに
「なぜガチャで炎上するゲーム会社があるのか？」
その答えの一つが、複雑な監査フローの属人化にあります。スマホゲームのガチャは年間数千億円の市場ですが、一つのミスが返金・売上没収につながる高リスク業務でもあります。
本記事では、そんなガチャ監査フローが「誰も全体を把握していない」状態になっていた現場を、PMとしてAIを活用して可視化・改善した実例をご紹介します。
この記事の対象読者
- プロジェクトマネージャー・リーダー（メイン）
- ゲーム業界のプランナー・運営担当
- 業務フロー改善に興味のあるビジネスパーソン
※技術的な詳細も含みますが、コードを書けない方でも実践できる内容です
現場で起きていた問題
ゲーム業界の構造とガチャ監査
多くのスマホゲームは「開発担当」（ゲーム制作）と「パブリッシング担当」（運営・配信）に分かれています。今回は開発会社が作ったゲームを、パブリッシング会社が各国でサービス運営する構造です。
ガチャ監査は、景品表示法等の規制により必須の業務です。有利誤認や誤表記は即座に返金や売上没収につながるため、ガチャの表記や確率が正しく実装されているかを厳格にチェックする必要があります。
※今回のケースでは、開発会社が別の国で規制の厳しい日本でパブリッシングしている関係上ガチャの監査が躓きやすいという前提があります。
パブリッシング会社のガチャ監査業務の実態
ゲームプランナーの仕事は多岐にわたり、彼らがやりたいことは手堅い運営よりも「ユーザーに喜んでもらいたい」「売上を上げたい」「自分のタイトルで一発当てたい」といった熱い思いを持っている場合が多いです。
そのため、ガチャの監査フローや引き継ぎなどは重要な業務であるにも関わらず、優先度が下がりがちです。優先度が下がると当然「やらされ仕事」になり、チームによっては文言をコピペして前例に則った監査資料しか出さなくなります。
何代も引き継がれた結果
意味を深く理解しないまま何代か引き継がれると、何のための監査で何のための資料なのか誰もわからなくなります。前任者の記憶は遥か昔のものとなり、売上を上げるという本業の片手間で行う監査にフローが綺麗に整備されているケースは珍しいのが現実です。
そういう状況で事故は起こります。
相談を受けた経緯
監査チームから「あるチームの監査資料にミスが多すぎる、差し戻しが多すぎるから何とかしてほしい」という相談が来ました。
運営チームが相談に来た際、最初は正直面倒そうな顔をしており、彼らにとって煩わしい業務という印象が否めませんでした。しかし、話を丁寧に聞いて課題を明確にしていくと、一つ解決するたびに彼らの温度が急上昇するのを感じました。
当然です。意味のわからない労働で本来やるべき業務の時間を削られ、辛い運用をしていたのですから。
明らかになった3つの課題
ヒアリングの結果、以下の3つの課題が浮かび上がりました：
- ガチャの監査フローを正確に誰も把握していない問題
- 運営チームがゲームのログを抽出するのに制約が多すぎる問題
-
ゲームのマスターデータが外国語と日本語を突合検索するのにDB化されていない問題
（スプレッドシートのGASのみで格闘していた）
今回は1つ目の「ガチャの監査フローを正確に誰も把握していない問題」について解決した手順をご紹介します。残りの2つについては、次回以降の記事で詳しく解説予定です。
PMとして意識したポイント
1. ステークホルダー管理の基本
今回の関係者は以下の通りでした：
- 現場運営チーム（実作業者）
- 監査チーム（品質管理者）
- 前任者（フロー設計者）
- 管理職（意思決定者）
重要なのは、根気よくヒアリングをして、たとえ図にしたときに証言が覆っても、個人の意見を尊重し誰も責めずにみんなの意見を拾い上げていく作業でした。
現場担当者の「面倒くさい」という感情も、重要な情報として捉えました。
2. 「私の言うことが絶対」の罠
途中で気づいたのは、私の提案に対して誰も反対意見を言わなくなったことです。これは危険なサインで、実際には：
- 本当は違う意見がある可能性
- 現場の実情と合わない解決策になるリスク
- 押し付けられた感による実行時の抵抗
- 筆者が考えた仕組みだから平気だろう！とういう慢心
そのため、意識的に「他の案はないか？」「懸念点はないか？」を繰り返し確認しました。
実際に監査フローの修正では当日に、あわや監査漏れというヒヤリハットが発生しました。
3. 課題の構造化
感情的な不満（「面倒くさい」「よくわからない」）を、具体的な問題に分解することで、解決可能な課題に変換しました。
解決アプローチ
解決方法は、PMとして当然やるべきことを着実に実行しただけです：
ステップ1: 情報収集フェーズ
- 現関係者からヒアリング - 現在の認識を把握
- 前任者にヒアリング - 過去の経緯を確認
- フローを作った担当にヒアリング - 本来の意図を理解
- メモを作成 - 収集した情報を整理
ステップ2: 可視化フェーズ
- AIで図を作成 - 収集した情報をフロー図に変換
ステップ3: 検証・修正フェーズ
- 現関係者にヒアリング - 認識違いを修正
- 現担当者とフロー作成者にヒアリング - そもそもの背景を確認
- 既存フロー完成 - 現状の正確なフローを確定
ステップ4: 改善提案フェーズ
- 新規フロー提案 - ヒアリングで得た不満点や非効率な点をシステム担当者として整理
- 全員でレビュー - 現関係者全員で新規フローを検討
- 新規フロー完成 - 改善されたフローを確定
ステップ5: 自動化フェーズ
最後に、バッチなど自動化できるものは自動化して納品しました。
使用したAIツールと具体的手順
ツール
- AI: Gemini
- 図作成: draw.io（Mermaid記法対応）
実際のプロンプトと手順
ヒアリングで収集した情報を以下のようにまとめ、Geminiに投げました：
プロンプト: 「マーメイドで以下のメモをフロー図にしてください」
○処理フロー
-メンテナンス前
・開発社がgitにソースをコミット（開発デプロイ用）
・開発社がパブリッシング社のタイトル運営チームに、マスターデータをzip化（csv+json）（A）と暗号化ツールを渡す
・パブリッシング社の監査チームがガチャの監査資料（B）（D）を元に、タイトル運営チームのガチャシミュレーターの結果と（A'）を比較し問題がないことを確認
・開発社がパブリッシング社の検証環境、ステージングにデプロイ。マスターデータ（B'）
-メンテナンス直前
・パブリッシング社が検証完了後にステージングのマスターデータ（B'）を保存
-メンテナンス中
・開発社がパブリッシング社の本番環境、各ワールドにデプロイ。マスターデータ（A'）
・パブリッシング社の監査チームが、本番環境のマスターデータ（A'）・ステージングのマスターデータ（A'）の完全一致を確認
・パブリッシング社のタイトル運営チームが検証をし、問題がなければメンテナンス終了
出力調整のコツ
- 初回出力: 基本的なフロー図が生成される「Mermaidの記法エラーが発生しやすいため、エラーメッセージをコピペして修正を依頼」
- 1回目修正: エラーと出力されたマーメイドを貼り付けて直す
- 2回目修正: AIができない場合は、自分で直す
3-4回の修正指示で、現場で使える精度の図が完成しました。
よくある失敗パターン（今回は回避できた）
1. 技術的解決に走ってしまう
「フローが複雑だからシステムで自動化しよう」と、現場の声を聞かずに技術で解決しようとする失敗パターンです。
2. 上司の意見を優先してしまう
管理職の「こうすべき」という意見を優先し、実際に作業する現場担当者の意見を軽視してしまうパターンです。
3. 完璧な解決策を求めすぎる
一度にすべての問題を解決しようとして、結果的に何も進まなくなるパターンです。今回は3つの課題の待ち時間に他の課題を進めるといった形で
同時着手はしない形で優先度を決めて対応したことで結果として短期間で解決しました。
改善前後の比較
既存フロー（改善前）
問題点:
- そもそも全体像を誰も理解していない！
- 各工程の意味が明確になっていない
- 手動確認作業が多数存在
新規フロー（改善後）
改善点:
- 主要担当者は全体像を理解してかつ図がある！
- 開発社・パブリッシング社・各チームの作業の意味を明確化
- 自動化可能な確認作業を特定
成果と改善効果
成果
乗り気でなかった運営チームが監査フローだけでなく業務改善をした全てに対して「正式なレポートを提出します」と割と異例の対応をされるくらいの成果でした。（レポートは現段階で未提出）
フローの整備については、監査チームが「全てのパブリッシングタイトルに展開します！」と前のめりになるくらいの反響がありました。
マスターのDB化でゲームの仕様理解が4割から7割に向上するという画期的な結果を生みました。
課金物に関しては原則10割の理解です。
※信じられない数値かもしれないですが、日本のパブリッシングの力が弱いと上記のような現象も発生したりします。
海外のパブリッシングタイトルかつ、日本の優先度が低いためかなり辛い状況で運用していたようで、そこを強く感謝されました。
PMとして学んだこと
- 「当然のこと」を当然にやる価値 - 基本的なPMスキルでも、現場では見落とされがちなポイントが多い
- ステークホルダーの感情変化に注目 - 「面倒そう」から「前のめり」への変化が成功の指標
- AIは手段、ヒアリングが本質 - 技術的ツールよりも人の話を聞くことが最重要
PMが最初にやるべき3つのこと
1. 全ステークホルダーの声を平等に聞く
- 現場担当者の本音（面倒、わからない等）
- 管理者の期待値と制約
- 前任者・設計者の本来の意図
2. 「正解を知っている」前提を捨てる
最初から解決策を持って臨むのではなく、まずは現状を正確に把握することに集中する。
3. 解決策を提示する前に課題を構造化する
感情的な不満を、具体的で解決可能な問題に分解する。
次回予告
次回は「運営チームがゲームのログを抽出するのに制約が多すぎる問題」について、PMとしてどのようにセキュリティ・権限管理・技術的制約の間でバランスを取りながら解決したかをご紹介する予定です。
まとめ
今回の事例で重要だったのは、特別な技術力ではなく「基本的なPMスキルを着実に実行する」ことでした。GeminiとMermaid記法は確かに便利でしたが、それ以上に重要だったのは：
- 関係者全員の話を平等に聞くこと
- 課題を感情ではなく構造で捉えること
- 段階的に改善していくこと
PMとして最も価値があったのは、現場の「面倒くさい」という感情を「具体的な改善課題」に変換できたことだと考えています。
この記事は実際のゲーム業界でのPM業務を基に執筆しています。具体的な社名や製品名は伏せていますが、多くの組織で似たような課題が存在すると考えられます。
Discussion