ゲーム(オンライン・ソーシャル)に、そもそもAIは必要なのか
ソーシャルゲーム運営のAI活用を考えるとき、判断軸は2つです。同じ判断を月に何度繰り返しているか、そしてその判断を間違えたときに何が起きるか。この2つが両方大きい業務ほど、AIを入れる価値が出ます。
運営中のタイトルは、深夜や休日もプレイヤーが遊び続けています。AIが効くのは、次のような業務です。
- 問い合わせフォームに届く不具合報告やアカウント引き継ぎの相談の仕分け
- メンテナンスや不具合が起きたときの、お知らせ文と補填内容の下書き
- 課金額の大きいプレイヤーへの個別対応の履歴整理と、次の打ち手の案出し
どれも、過去の対応記録や社内で定めた区分という決まった基準に照らして、同じ判断を繰り返しています。
一方、コラボ先との許諾交渉や、ガチャの提供割合の最終決定にはAIを入れないほうがよいと考えます。交渉は相手のIP方針をその場でくみ取る場です。ガチャの設計は、運営がプレイヤーに対して責任を負うことに意味があるからです。
ただ、この線引きは業務ごとに変わります。同じお知らせ文でも、定型のメンテナンス告知と、不具合のお詫び文とでは向き不向きが違います。次のセクションでは、運営の業務を工程に分けて見ていきます。
運営企画からデータ分析まで、負荷が大きいのはどの工程か
ソーシャルゲームの運営は、一本の流れで進むというより、役割の違うチームが同時に動いています。工程ごとに見ると、決まった区分に沿って繰り返す作業と、相手や状況を見て毎回考える作業がはっきり分かれます。
| 業務工程 | 主な作業 | AI活用の余地 |
|---|---|---|
| 運営企画 | イベント・新機能の立案、コラボ企画の提案資料づくり | 中:過去の実績から提案の型を起こせる |
| IP許諾交渉 | コラボ先とのレギュレーション調整、条件のすり合わせ | 極小:相手のIP方針を見て毎回変わる判断 |
| 実装・デバッグ | 機能の実装、リリース前の動作確認 | 小:不具合報告の整理までにとどまる |
| リリース告知 | お知らせ文の作成、公式コミュニティへの投稿 | 中:定型の告知なら下書きを任せられる |
| カスタマーサポート | 問い合わせの一次対応、個別対応の記録管理 | 大:区分の仕分けと回答案づくりを任せられる |
| 障害対応 | 障害告知の作成、補填内容の周知 | 大:状況の記録から告知の下書きを起こせる |
| 不正・法務点検 | チート挙動の抽出、ガチャ表記の点検 | 大:定めた基準での突き合わせを任せられる |
| データ分析 | KPIの集計、離脱要因の整理、広告効果の集計 | 中:数値の集計と傾向の整理を任せられる |
負荷が最も集中するのはカスタマーサポートの工程です。プレイヤーは深夜も休日も遊んでいるため、不具合報告や課金に関する相談が途切れずに届きます。
オペレーターは一通ずつ本文を読み、アカウント引き継ぎの失敗なのか、課金したアイテムが反映されない話なのか、ガチャの結果への不満なのかを見分けます。課金に関わる内容は金銭のやりとりに直結するうえ、返信が遅れればその不満が公式コミュニティに書き込まれ、タイトルの評判そのものに響きます。
ここに手を入れると、オペレーターは仕分けではなく、返信の中身を整える作業に時間を使えます。不具合報告が区分ごとにまとまることで、実装・デバッグの担当者が直すべき順番も見えやすくなります。
一方、「極小」としたIP許諾交渉は、コラボ先が自社のIPをどう扱ってほしいかを聞き取り、表現の可否や期間を詰める仕事です。相手ごとに前提が変わるため、人が向き合う工程として残ります。
ゲーム(オンライン・ソーシャル)で最初に取り組むべきAI活用、3つ
最初に手をつけるなら、繰り返し発生していて、かつ間違えるとプレイヤーの課金や評判に響く業務です。第1セクションの2軸で見ると、問い合わせの仕分け、障害時のお知らせ文、個別対応の打ち手づくりがこれに当たります。
届いた問い合わせを、AIに先に仕分けてもらう
問い合わせフォームが送信されたとき、または窓口のメールに不具合報告が届いたときに仕組みが動きます。AIは社内で定めた区分表と過去の対応記録を参照し、内容がアカウント引き継ぎの失敗か、課金アイテムの未反映か、ガチャや不具合への不満かを判定します。
判定結果は問い合わせ管理の表計算ソフトに行として追記され、参照すべき定型文と担当窓口の候補も並びます。いまはオペレーターが一通ずつ読んで区分を決めていますが、仕組みが入ると、区分済みの一覧を確認する作業に変わります。
区分を確かめるのはサポート責任者です。補填を出すか、アカウントを復旧するかといった、プレイヤーの資産に関わる判断は運営責任者が決めます。
障害のお知らせと補填の告知を、待たせずに出す
深夜にサーバーが落ちたとき、プレイヤーがまず求めるのは原因の解説ではなく、いま何が起きていて、いつ遊べるようになるのかの告知です。障害の記録が所定の保存先に書き込まれた時点が起点になります。AIは発生時刻・影響範囲・復旧見込みと、過去の障害時のお知らせ文を読み取り、告知の下書きを組み立てます。
下書きは文書作成ソフトのファイルとして保存され、運営担当者に業務チャットで知らせが届きます。白紙から書き起こしていた作業が、下書きに補填内容を書き足す形に変わります。
読み合わせるのは運営担当者です。影響範囲の記述と復旧見込みの表現を確かめます。何をどれだけ配るかという補填の決定は、運営責任者が負います。
課金額の大きいプレイヤーへの打ち手を、記録から組み立てる
三つめは、きっかけが日付の側にあります。毎週決まった曜日に、課金記録とログイン状況の更新を合図として仕組みが動きます。AIは社内で定めた優良プレイヤーの区分と、これまでの個別対応の履歴を照らし合わせ、対応先の候補ごとに、経緯と次の打ち手をまとめた提案資料の下書きを起こします。
提案資料は文書作成ソフトのファイルとして所定のフォルダに保存され、対応待ちの候補が一覧表にも並びます。記憶を頼りに相手を探し、経緯を追い直していた作業が、下書きに目を通すところから始まる形になります。
下書きに目を通すのは運営担当者です。個別に特典を出すかどうかは、ガチャや課金の公平性に関わるため、運営責任者が決めます。
業務に組み込むまでの4ステップ
ここでは「ユーザーサポートへの問い合わせ内容の分類分析」を例にします。新しいシステムを作る話ではなく、いまある問い合わせフォームと表計算ソフトの間に、情報の通り道を引く作業です。
1. 使う情報がどこにあるかを決める
仕分けに使う情報は、すでに社内にあります。
- フォームの本文とプレイヤーの識別番号
- 過去の問い合わせへの返信記録と、そのときの区分
- 不具合報告と修正状況の一覧
新しく作るものはありません。窓口ごとに散らばっているなら、一つの保存先に集めます。
2. 何をきっかけに動かすかを決める
フォームが送信されたとき、または窓口のメールに届いたときを起点にします。思い出して始める形にすると、イベント直後ほど後回しになり、使われなくなります。
3. 判断の基準を設定しておく
どの内容をどの区分に入れるのかを文章にし、一箇所にまとめて設定しておきます。AIは毎回そこを参照します。オペレーターが頭の中でやっている見分けを、外に書き出す作業です。
- 課金したアイテムが反映されない訴えは、不満の有無を問わず最優先の区分に入れる
- アカウント引き継ぎの失敗は、本人確認が要るため別窓口に回す区分にする
- ガチャの結果への不満と、提供割合の表記への指摘は別の区分に分ける
この工程がいちばん時間がかかります。境目の見分けは人によって揺れているため、すり合わせが要ります。一度書き留めれば、担当者が替わっても使い回せます。
4. 結果の戻り先と、確認する人を決める
判定結果は問い合わせ管理の表計算ソフトに行として追記し、業務チャットでサポート責任者に知らせます。サポート責任者は始業時に一覧を開き、最優先の区分から順に担当を割り振ります。
先に知っておきたい、つまずきやすい3か所
- 大量の同じ報告に、重い一通が埋もれる:イベント直後は同じ不具合の報告が集中します。乗っ取りの申告がふつうの不具合報告と同じ言葉で書かれていると、AIは件数の多い区分にまとめ、対応が後回しになります。本人確認や資産の移動に触れる語を含むものは、区分を問わず先に通知する設定にします。
- ガチャの表記点検を、告知文の中だけで済ませる:提供割合の点検をお知らせ文だけで突き合わせると、実装されている設定値とずれたまま出てしまいます。景品表示法の有利誤認に触れるおそれがあるため、実装側の設定値を参照先に含めておきます。
- フォームの項目を変えて、仕分けが止まる:問い合わせフォームは、イベントや不具合に応じて項目を足すことがあります。項目名が変わると流れが止まるため、フォームを直す手順の中に、区分の基準を見直す作業を組み込んでおきます。
ゲーム(オンライン・ソーシャル)のAI活用は、どこから考えればいいか
AIが効くのは、過去の対応記録や社内の区分という決まった基準に照らして同じ判断を繰り返す業務で、コラボ先との交渉やガチャの設計は人が担う側に残ります。紹介した3つは、いずれも基準が記録として手元にあり、確認する人も決めやすい業務です。
すべてを一度に進める必要はありません。まずは一つの業務から始めれば十分です。そのとき必要なのは、問い合わせフォームや過去の返信記録、表計算ソフトといった、すでに運営の中にあるツールと情報です。

