はじめに
はじめまして＆こんにちは。
AppReviewチーム配属の＠kuniyosh1です。
ゲーム全般大好きです！
月日の流れは早いもので、昨年初めてアドベントカレンダーの記事を書かせていただいてから、約1年が経過しました。
油断していると一瞬で歳を重ねてしまうので、価値ある毎日を過ごせるようにしていきたいものです。
僕はここ最近 某デジタルカードゲーム にめちゃくちゃハマっています！
次世代スマホカードゲームとして人気を博しているのですが、個人的にはオフラインの大会が活発なところに惹かれています。
先日も都内近郊のとある大会へ参加してきたのですが、そこでは自分よりも12歳も年下のゲーム友達ができました。
また、会社の同僚とも一緒に大会に参加するようになったりと、ゲームをきっかけに、趣味の輪が少しずつ広がりを見せています。
今後も大会には積極的に参加して、ゲームライフを満喫していこうと思います！
さて、このあとの本題では、AppReviewチーム内で行っている「企画審査」という業務において、AI導入による効率化に挑戦しましたが、 失敗してしまった 件について書いていきたいと思います。
本題の前に
プロジェクトの内容について触れる前に、「企画審査」という業務について簡潔に説明させてください。
企画審査とは、ゲームに実装される各企画や、ゲームに連動したSNSキャンペーンなど、自社で企画される各企画・仕様に対して、各種法令・社内ルール・業界ガイドラインなどの観点から、違反がないかを検知し、リスクを未然に防ぐ事を目的にした業務です。
例えば、ゲーム内のアイテムを販売する企画であれば、「販売物のおまけの価格が法令に準拠しているか」などを社内ルールに照らしてチェックしています。
（以前こちらの記事でも紹介しています)
挑戦のきっかけ
昨今のAIブームの先陣を切るべく、弊社部署内でも様々な業務にAIを活用していこうという動きが活発になっていました。
僕が所属するAppReviewチームでも、各社員ともAI活用を試し始めており、そんな中で僕は企画審査へのAI導入に取り組み始めました。
AI導入の目的は、審査対象に法令的な懸念がないかを判断するまでの 時間の短縮＝効率化 です。
導入前は、下記のようなイメージでAIを作りたいと考えていました。
構成としては、プロンプトに審査対象企画の仕様を入力すれば、各種社内ルールをソースとして取り込んだAIが即座に仕様の懸念点を洗い出し、それに関連する社内ルールの原文を提示してくれるというものです。
判断の時間を短縮すること と、社内ルールが書かれた ドキュメントを探す時間を短縮すること を狙いとしています。
果たしてイメージ通りに行くのでしょうか。
AI調査
昨今は様々なAIが台頭してきており、それぞれ独自の特徴を持っています。
そのため、まずは審査判断を任せるのに、どのAIが適しているのか、各AIの機能を調査してみました。
企画審査の業務特性上、大量の社内ルールに照らして企画の懸念点を見つける必要があるため、 ドキュメントをソースとして保持できることは最低条件 として、且つ約50件も存在する各種ルールのドキュメントを取り込むことができ、それらのソースに照らして、プロンプトとして入力された企画仕様の懸念点を網羅的に洗い出せる精度も必要でした。
今回の調査対象は、「ChatGPT」「Gemini」「NotebookLM」「Copilot」の4つです。
Geminiについては、Gemini内の機能として備わっている「Gem」を対象に調査しました。
※Gemとは特定のソースや性格を記憶させた、自分専用のGeminiです。
調査結果は下記となりました。
調査は2025年9月～10月頃に実施したものであるため、現在とは状況が変わっている可能性や、調査情報の誤りについてはご留意ください。
-
ソースの保持
GemとNotebookLMは、特定のドキュメントをソースとして保持することが可能でした。
Copilotは会話単位で毎回ソースを入力する必要があり、且つソースのアップロード件数に1日あたりの上限があるようでした。
ChatGPTはドキュメントをソースとして保持する機能はありませんでした。 -
ソースの上限
NotebookLMのソース上限数が圧倒的で、これにより今回利用するAIはほぼNotebookLMに決まったようなものでした。 -
回答の精度
GemとNotebookLMは、ソースを参考にして仕様の懸念点を洗い出すことができました。
ChatGPTとCopilotは、ソースは設定していなかったものの、一般的な知見から仕様に対する懸念を洗い出すことができました。
回答内容については、どのAIも網羅的に懸念を洗い出せており、精度は問題なさそうに見えました。 -
画像の解析
審査対象が画像である場合のために調査をしました。
NotebookLM以外は、プロンプトに画像を送ることが可能でした。
結論として、大量の社内ルールやガイドラインを元に判断をしなければならないという業務特性上から、より多くのソースを保持できる NotebookLMを使用することに決めました。
画像の解析は出来ないものの、通常の企画審査において画像をチェックする頻度はそう高くなく、また画像の内容をプロンプトに言語化できれば回答自体は得られるので、そこは問題ないと判断しました。
AIの作成
早速、審査判断に必要な社内ルールを全てドキュメント化し、それらをソースとして読み込ませた「審査判断LM」を作成しました。
LMは、読み込んだソースを元に自分がどのようなAIであるかを要約してくれるのですが、今回作成したAIの要約内容がこちら。
ゲーム内課金、ガチャ設計、各種法令など、社内ルールに則って総合的な審査判断ができるAIが出来上がったようです。
AIの精度を試すために、ゲームの新ガチャ実装における懸念点について質問をしてみました。
弊社の審査観点の流出を保護する目的で、具体的なAIの判断結果を載せることはできませんが、上記の仕様に対して、 社内ルールで懸念がありそうなポイントを網羅的、且つ精度高く抽出 できており、また 審査判断に必要な情報を追加で質問してくれたり と、とても優秀なAIのように感じます。
しかし、一見すると十分実用的なのですが、 結果的には効率化はできませんでした。
一体なぜなのか。
失敗の理由
効率化ができなかった理由は、 AIで効率化すべき箇所を見誤った ためでした。
審査業務は、プロダクトから提出される企画の仕様を隅々まで把握し、どこに懸念があるのかをチェック・判断する業務です。
そのため、まず企画の仕様を把握する必要がありますが、これには一定の時間を要します。
今回僕は、審査の判断部分をAI化できれば、作業時間を短縮できると思って狙いを定めましたが、実際には、 判断部分は人間でもAIでも大きな作業時間の差はありませんでした。
そして、時間が掛かっていたのは、その前段である「仕様の把握や整理」であるということも分かりました。
また、プロンプトに関連するルール検索も機能はしましたが、熟練メンバーはすでにルールを熟知しており、把握できているルールを検索できても効率化には繋がらず、こちらも不発となりました。
そして、企画審査において時間の掛かっている仕様の把握・整理の部分についてですが、ここはAIの導入が難しい領域でした。
要因としては、AIの判断に対して人の目によるチェックが必須であるため、人の目で仕様を把握する時間は必要であることや、プロンプトを作成するためにも、人の目による仕様の把握・整理が必要なことなどが挙げられます。
結果として、AIによる作業時間の短縮は失敗に終わりました。
振り返り
今回の失敗の振り返りは以下です。
-
シミュレーションが甘かった
今回は始めから決め打ちで「審査の判断部分」にAIを導入しようと、取り組みを進めていました。
取り組みを始める前からNotebookLMを含む各AIをチーム全体で触ってきており、 AIでも精度の高い審査判断ができるという所感を持っていた ためです。
一方で、 精度の高い判断ができるという点と、効率化ができるという点を結びつけることは出来なかった のですが、そこに気付くのが遅かったと思います。
具体的な取り組みを始める前に、AI導入後の業務フローを詳細にシミュレーションできていれば、時間が掛かっているのは判断部分ではなく、その前段の仕様把握であることに気付けていたかもしれませんし、そこに気付けていれば、作成するAIの方向性もまだ検討できたのではないかと思います。
まとめ
効率化という当初の狙いは叶いませんでしたが、AIと人の判断を合わせることで、網羅的なチェックが可能になり、審査観点の漏れの防止に繋がる（＝審査の精度が上がる）という点においては、今回のAIを作成した価値を大いに感じています。
また、今回は特定のゲームタイトルに紐づかない、汎用的な審査判断ができるAIを作成して効率化を試みましたが、まだ試せていないAIの形（例えば特定のタイトルに特化したAIなど）もあると思いますし、今回は効率化が難しいと判断した企画審査の仕様把握時間に対しても、有効な効率化手段がないのか、さらに調査はしてみたいと思っています。
そして、 プロンプトの作成に時間のかからない業務においては、効率化の余地が大きい という発見は、今回の大きな学びです。
この学びを活かすべく、現在いくつかのタイトルで既に導入している、表記チェック作業のAI化について、他タイトルへの汎用化に向けて調査・検討を進めています。
この取り組みについては、また機会があればご紹介できれば良いなと思っています！
ここまで読んでいただき、ありがとうございました！