アミューズメント・エンタメ・ゲームメーカーでのAI活用術

アミューズメント・エンタメ・ゲームメーカーに、そもそもAIは必要なのか

ゲームメーカーのAI活用を考えるときの判断軸は、2つだけです。同じ判断を月に何回繰り返しているか、そしてその判断を間違えたときに何が起きるか。この2つがどちらも大きい業務ほど、AIを入れる値打ちが出ます。

この軸で見ると、AIが効くのは次のような業務です。

• デバッグ期間に積み上がる不具合報告の仕分けと、直す順番の割り当て
• 使用素材やキャラクター名が、許諾の範囲に収まっているかの洗い出し
• 販売店やロケーションから届く問い合わせの、機種ごとの切り分け

いずれも 社内に基準がすでにある 判断を、期限に追われながら何度も繰り返しています。

反対に、ロケテストの手応えをもとに難易度や配当を詰める作業には、AIを入れないほうがよいと考えます。遊び終えた客がもう一度硬貨を入れるかどうかは、筐体の前の表情や店員の声から読むしかないためです。

権利元との許諾交渉も同じで、相手が自社のキャラクターをどう扱ってほしいかは、その場のやりとりでしか分かりません。

ただし、この線引きは業務ごとに変わります。同じ企画資料でも、競合機種の動向をまとめる作業と、コラボ相手に見せる提案の骨子を決める作業では、向き不向きが違います。次のセクションでは、 機種企画から販売後まで の工程に分けて見ていきます。

機種企画から販売・サポートまで、負荷が大きいのはどの工程か

ゲームメーカーの仕事は、機種やタイトルの企画から販売後の対応まで、一方向に流れていきます。工程ごとに並べると、基準に照らして繰り返している作業と、その場の手応えで決めている作業がはっきり分かれます。

負荷が最も集中するのは デバッグ の工程です。マスターアップの日と量産の日程が先に押さえられているため、報告の件数が増えても後ろへずらせません。

デバッグ担当者は報告を一つずつ読み、進行が止まる症状なのか、特定の筐体でしか出ない症状なのか、見た目の崩れかを見分けます。操作部やメダルの払い出しに絡むものは、実機を前にしないと再現条件が定まらず、切り分けだけで時間が過ぎていきます。

順番づけを誤ると、急がなくてよいものに手が入り、出荷後に店頭で止まる不具合が残ります。ここに手を入れると、担当者は仕分けではなく 修正そのもの に時間を使えます。制作・実装の担当者にとっても、直す順番が朝の時点で見える状態になります。

一方、「極小」とした量産・出荷は、基板を筐体に組み込み、動きを目視で確かめて箱詰めする工程です。現物を手で扱う作業が中心で、判断の基準を文章にして持たせる場面がほとんどありません。

アミューズメント・エンタメ・ゲームメーカーで最初に取り組むべきAI活用、3つ

手をつける順番は、第1セクションの2軸で決まります。繰り返しの回数が多く、間違えると店頭や権利元に影響が出る業務が先です。この業種では、不具合報告の順番づけ、素材の許諾確認、販売店とユーザーからの問い合わせの切り分けがそこに当たります。

積み上がる不具合報告に、先に順番をつける

デバッグ担当者が不具合管理の表に報告を登録した時点で、仕組みが動きます。AIは社内で定めた重篤度の区分と、過去の機種で同じ症状をどう扱ったかの記録を照らし、進行が止まるものか、筐体の操作部に関わるものか、表示の崩れかを見分けて順位をつけます。

結果は不具合管理の表計算ソフトに、優先度と担当の候補として書き込まれます。いまはデバッグリーダーが報告を読んで一つずつ順番を決めていますが、仕組みが入ると、 並び替えの済んだ一覧 を上から確かめる形に変わります。

並び順を見るのはデバッグリーダーです。この症状を残したまま出荷してよいかという判断は、品質保証の責任者が持ちます。

使った素材の許諾漏れを、出荷前に洗い出す

二つめは、きっかけが日程の側にあります。マスターアップ前の決まった時期に、制作物の保管先へ集まった素材の一覧を合図として動きます。AIは使用範囲と期限を書いた社内の許諾台帳と、過去に権利元から指摘を受けた事例を突き合わせ、確認が要る箇所を抜き出します。

抜き出した結果は確認事項の一覧として文書作成ソフトのファイルに保存され、法務の担当者へ業務チャットで知らせが届きます。制作物を一つずつ開いて契約書と見比べていた作業が、 拾い上がった箇所 を当たるところから始まります。

一覧に目を通すのは法務の担当者です。権利元に確認を取るか、素材を差し替えるかの決定は、権利元との窓口を持つ責任者が下します。

販売店とユーザーの問い合わせを、機種ごとに分ける

この窓口には、ロケーションの店長からの「基板が立ち上がらない」という連絡と、エンドユーザーからのセーブデータの相談が同じ箱に届きます。フォームやメールが着いた時点で動き、AIは機種ごとの既知不具合の一覧と過去の対応記録を参照して、送り主の別と症状を見立てます。

見立てた内容はサポート管理の表に行として並び、部品の手配や現地対応が要りそうなものには印がつきます。受付担当が機種を聞き直してから調べ始めていた流れが、型番と過去事例のそろった状態から始まる形になります。

印の妥当性を確かめるのはサポート担当です。部品交換に出向くか、機器を引き上げるかという費用の伴う判断は、サービス部門の責任者が決めます。

業務に組み込むまでの4ステップ

ここでは「不具合報告（バグ）の分類・優先度判定」を例にします。新しいシステムを組む話ではなく、いま使っている不具合管理の表と、判断の基準の間に通り道を引く作業です。

1. 使う情報がどこにあるかを決める

順番づけに使う情報は、 すでに社内にそろっています 。

• 不具合管理の表にある報告本文、発生した機種、書き込んだ版
• 過去の機種で同じ症状をどう扱ったかの記録
• 出荷を止める条件を書いた社内の品質基準

新しく作るものはありません。開発チームごとに分かれているなら、一箇所にまとめます。

2. 何をきっかけに動かすかを決める

報告が管理表に登録された時点を起点にします。思い出して回す形にすると、報告が集中するマスターアップ直前ほど後回しになり、使われなくなります。

3. 判断の基準を設定しておく

何をもって重い症状とするのかを文章にし、一箇所にまとめて設定しておきます。AIは毎回そこを参照します。デバッグリーダーが経験から見分けている境目を、 外へ書き出す作業 です。

• 進行が止まる症状と、見た目の崩れは別の区分に分ける
• 硬貨やメダルの投入部、景品の払い出し機構に関わる症状は、再現率を問わず最上位に上げる
• 特定の筐体でしか出ない症状は、再現条件がそろうまで保留に回す

この工程がいちばん時間がかかります。境目の見立ては人によって揺れるため、すり合わせが要ります。一度書き留めれば、次の機種でもそのまま使い回せます。

4. 結果の戻り先と、確認する人を決める

判定した優先度は不具合管理の表に列として書き込み、最上位に上がったものだけ業務チャットでデバッグリーダーに知らせます。リーダーは始業時に一覧を開き、上から担当を割り当てます。

先に知っておきたい、つまずきやすい3か所

• 実機でしか出ない症状が、報告の文面から落ちる ：操作部や払い出し機構に絡む不具合は、どの個体で、どの版で、どう操作したときかが書かれていないと、AIは軽い区分へ寄せます。報告フォームに個体番号と版、直前の操作の順番を必須の項目として設けておきます。
• 許諾台帳が契約より遅れる ：楽曲や声の収録、コラボ相手のキャラクターは、使える範囲と期限が契約ごとに違います。台帳の更新が後回しになると、期限の切れた素材を通してしまいます。契約を結んだ時点で台帳に書き足す手順に組み込みます。
• 販売店とのやりとりが電話で終わる ：ロケーションからの連絡は電話が中心で、修理の経過が紙の報告書のまま残ります。AIが読める記録が増えないため、受付の時点で所定のフォームへ転記する運用にします。

アミューズメント・エンタメ・ゲームメーカーのAI活用は、どこから考えればいいか

AIが効くのは、 社内に基準がすでにある判断 を期限に追われて繰り返す業務で、ロケテストでの詰めや権利元との交渉は人の側に残ります。紹介した3つは、いずれも拠りどころが記録として手元にあり、確認する人も決めやすい業務です。

すべてに手をつける必要はありません。 まずは一つの業務から 始めれば十分です。不具合管理の表、許諾台帳、過去の対応記録といった、すでに開発と出荷の中で使っているものだけで着手できます。