「テスト観点はすべて網羅しました」という報告は、地図の道をすべて歩きましたという報告と同じくらい疑ってよいものです。ゲームの操作、機種、通信状態の組み合わせは、人が試せる量をはるかに超えるからです。この記事では、ゲーム開発のQA（品質保証）の本体は観点を増やすことではなく、今回は確かめないと決める判断にある、という見方を示します。AIに観点を出させる時代ほど、その判断が人の手に残る理由も考えます。
QAは、どこまで確かめるかを決める全体の戦略です
ゲーム開発のQAは、完成品のバグ探しだけではありません。開発の初めからリリース後まで、品質を確かめ、高めていく活動です。仕様どおりに動くかという機能面に加え、動作の軽さや遊びやすさといった機能以外の面も対象にし、上流の工程に働きかけて問題を未然に防ぐことも含みます。
よく混同される言葉との関係は次のとおりです。
QAが全体の戦略で、QCはその中の検査、テストは欠陥を見つける手段、デバッグは見つかった欠陥を直す作業です。この区別で大事なのは、テストとデバッグが「何をするか」の言葉であるのに対し、QAは「何を確かめ、何を確かめないか」を決める側の言葉だという点です。仕事の流れも、テスト計画、テスト設計、実行、バグの報告と追跡、再テストと分析の順に回り、最初の計画の段階で、確かめる観点と人と日程が決まります。
観点の一覧が厚いほど安心できるわけではありません
確かめる対象は広く、代表的なテストだけでも、機能、互換性、パフォーマンス、ユーザビリティ、ローカライズ、プラットフォームの技術要件を満たすかのコンプライアンス、セキュリティ、マルチプレイヤー、修正で既存の機能が壊れていないかのリグレッションと並びます。Unityのゲーミングレポート2025では、開発者の64%がオンラインや協力プレイ型のゲームに取り組んでいるとされ、通信と同時接続の観点は増える一方です。これとは別に、面白さや難易度の釣り合いを確かめるプレイテストもあります。
ここで起きやすいのが、観点の一覧を厚くすることで安心する習慣です。300行ある観点表は、安心の厚みではあっても判断の厚みではありません。どの行を今回はやらないのかが書かれていなければ、優先順位を決める仕事を先送りしただけだからです。期日が来た時点で手の回らなかった行は、誰も決めないまま捨てられます。
「念のため全部やっておいて」という指示も同じ構造です。指示の形をしていますが、中身は判断の放棄です。全部はできないと分かっている以上、何を落とすかは現場の残業時間と手が空いた順番が決めることになります。
捨てる基準を先に言葉にするのが、観点選びの手法です
観点の選び方として知られる三つの手法も、捨てる判断の道具として読むと役割がはっきりします。
- リスクベースドテスト：起こりやすさと、起きたときの影響の大きさでリスクを評価し、高いところに労力を集めます。裏返せば、低いところに労力を割かないと宣言する手法です
- 探索的テスト：台本に頼らず、テスターの経験で動かしながらその場で観点を見つけます。台本で見逃しやすい組み合わせに強い一方、何を試さなかったかは記録しないと残りません
- シナリオテスト：チュートリアルから最初のクエスト完了まで、のように、プレイヤーの一連の体験を通しで確かめます。どの体験の流れを優先するかを選ぶことでもあります
どの手法を使うにしても、決めておくべきことは三つあります。何を守るためのテストか（目的）、期日と人員でどこまでできるか（制約）、どの基準で優先度を付けるか（評価基準）です。この三つが言葉になっていれば、捨てた観点についても「この基準でこう判断した」と後から説明できます。
ただし、捨ててはいけない観点もあります。プラットフォームの技術要件のように、満たさなければ出せないものは、リスクの高低で選ぶ対象ではなく、最初から外せない制約です。どこからが選べる観点で、どこからが外せない制約なのか。その線を引くこと自体が、QAの判断に含まれます。
AIは観点を増やすのが得意で、捨てるのは人に返してきます
観点の洗い出しは、AIが得意とする作業の一つです。ChatGPTを自分用にカスタマイズしたGPTsに役割と手順を固定しておけば、仕様書を渡すたびに、観点ごとの確認項目を表で返させることもできます。自社の観点一覧や過去のバグ報告の傾向を知識として渡せば、チームの経験も反映されます。
ただ、AIに「漏れなく」と頼むと、漏れのない一覧が返ってきます。その漏れのなさは、捨てる作業を丸ごと人に押し戻す形で実現されています。ですから、頼み方の重心は「もっと出して」ではなく、捨てるための材料を出させる側に置くのが筋です。
あなたはゲームQAのテスト設計担当です。渡された仕様書から確認項目を表にし、
各項目に起こりやすさと影響の大きさを高、中、低で付けてください。
そのうえで、期日までに確かめきれない場合に後回しにしてよい項目と、その理由を分けて示してください。
プラットフォームの技術要件にかかわる項目は、後回しの候補に入れないでください。
仕様書にない前提を置いたときは、その前提を明記してください。この頼み方でも、最後に何を落とすかを決めるのは人です。AIが付けた高、中、低は、仕様書から読み取れた範囲の推定であり、そのゲームの売り方や遊び手の層まで知っているわけではありません。どこまでAIの採点を信じてよいかは、作品とチームによって変わり、一般的な答えはありません。
あなたのチームの観点表には、今回やらないと決めた行と、その理由が書かれているでしょうか。リリース後に見つかったバグは、確かめ忘れたものでしょうか、それとも誰かが確かめないと決めたものでしょうか。
この記事の背景にある考え方は、拙著『ChatGPT 誰でも1時間でできる！ はじめてのGPTsのつくり方』の3章9節「テストとダミーデータ」に書きました。自分で作ったAIの出来を、良いケース、悪いケース、普通のケースの最低3種類で確かめるという話で、そこには「GPTの利点のひとつは、このダミーデータを簡単に作成できることです。」とあります。この節を読むと、観点を出してくれるAIそのものを、都合の良い例だけで信じていないかを、自分で点検できるようになります。
自分の仕事に効くAIは、誰が作るべきか。
『ChatGPT 誰でも1時間でできる！ はじめてのGPTsのつくり方』
要件を日本語で書き出せば、それがそのままAIを動かす。現場の知識を持つ人が自分で作り、育てる、内製化のための本です。
読み終えたとき、手元に残るもの
- 目的、役割、入力、出力をそろえる要件定義の型
- 評価基準と判断基準を持たせる考えるGPTの作り方
- テスト用のダミーデータで直していく手順
- 複数のGPTを分業と協業でつなぐ設計
画面や機能の記述は2024年時点のものです。仕事を分解し、基準を言葉にする考え方は今も変わりません。