ゲームのデバッグとQA｜AIゲーム開発のバグ報告・優先度・自動テスト

2026年10月4日

ゲームの不具合は、作っている間ずっと生まれ続けます。それを見つけて報告し、原因を探して直し、直ったことを確かめるのがデバッグと QA（Quality Assurance、品質保証）です。開発の初めから行う作業ですが、中心になるのは βROM（ベータ版）からマスターアップまでの仕上げの段階です。この連載では、この段階をポストプロダクション（仕上げ）と呼びます。資料によっては、発売後の運営を指すこともあります（全体の流れは「ゲーム開発の全工程マップ」）。

本記事では、テスト計画とチェックリスト、バグ報告の書き方、重さと優先度の付け方、バグ管理の道具、修正の確認と回帰テスト、自動テスト、ログと動作環境の確認、セーブデータのテストまでを、個人〜少人数の開発を基準にまとめます。後半では、AI エージェントにテストを書かせたりログを読ませたりするときの進め方と、筆者が実際に踏んだ落とし穴を紹介します。

夕宮たいだ

ふぁ……みんな〜、今日はデバッグと QA の話だよぉ。「たまに落ちる」って報告、もらっても困っちゃうよねぇ。直せる報告の書き方から、一緒に見ていこ〜。

テストプレイ・プレイテスト・QA の違い

ひとことで：テストプレイは作り手の確認、プレイテストは遊ぶ人の体験の確認、QA は仕様どおりに動くか・出荷してよいかの確認です。

呼び方	確かめること	主に誰が	見つかるもの
テストプレイ（試し遊び）	作ったものが動くか、手触りはどうか	作った本人・チーム	組み込みの誤り、手触りの問題
プレイテスト	狙いどおりに遊ばれるか、面白いか	作っていない人	迷う所、飽きる所、伝わらない所
QA（品質保証）	仕様どおりに動くか、出荷してよいか	テスト担当、QA 会社	不具合（再現手順・重さ・頻度）

呼び方は会社によって違い、日本の現場では QA の作業を「デバッグ」と呼ぶこともあります。この記事では、QA＝不具合を見つけて報告し、直ったことを確かめる活動、デバッグ＝報告された不具合の原因を探して直す作業として書きます。2つは「見つける→直す→確かめる」の輪でつながっています。

大きな会社では、QA の専門部署や外部の QA 会社がテスト計画に沿って確かめます。個人や少人数では作り手がこの輪を自分で回すので、手順と道具で抜けを減らします。遊ぶ人の体験を確かめる方法は「プレイテストのやり方」で扱います。

テスト計画とチェックリスト

ひとことで：何を・どこまで・どの環境で確かめるかを先に決め、項目を表にして漏れなく回します。

テスト計画は長い文書でなくてかまいません。範囲（全編か、変更した所か）、環境（OS・機種・解像度・入力機器）、合格の基準（例：出荷を止める不具合が0件）、担当と期間、報告の置き場所の5つが決まっていれば十分です。チェックリストは区分ごとに作ると漏れが減ります。

区分	確かめること（例）
機能	全ステージを最初から最後まで遊べる。ノベルなら選択肢の全分岐、カードゲームなら全カードの効果
進行	ソフトロック（ゲームは動いているのに先へ進めない状態）が無い。取り返しのつかない要素の扱い
画面	解像度とウィンドウ・全画面の切り替え、文字のはみ出し、UI の重なり
入力	キーボード・マウス・コントローラー、キー設定の変更、途中での抜き差し、連打と同時押し
セーブ	保存と読み込み、途中で終了したとき、古い版のセーブ、クラウド保存
言語	全言語での文字化け・はみ出し・未翻訳、フォントに無い文字
性能	フレームレート、読み込み時間、長く遊んだときのメモリの増え方
動作環境	性能の低い PC、OS の版、ノート PC、Steam Deck
配布	ストアに書いた機能がすべて入っている、配布物に要らないファイルが無い

本格的に確かめる前に、主な機能が動くかだけを短く確かめるテストをスモークテストと呼びます（ISTQB の用語集）。「起動→タイトル→最初の面を少し遊ぶ→セーブ→終了」のような数分の手順を決め、新しいビルドのたびに最初に行います。ここで止まるビルドは、詳しいテストに回しません。性能の測り方は「リアルタイム最適化チェックリスト」、翻訳の確認は「ゲームのローカライズ」で扱います。

バグ報告の書き方

ひとことで：別の人が同じ手順で同じ不具合を起こせるように、事実を決まった項目で書きます。

バグ報告の目的は、直す人が不具合を再現できるようにすることです。Mozilla の「Bug Writing Guidelines」は、再現手順を報告の「最も大事な部分」とし、1件の報告に1つの不具合、事実と推測を分けて書くことを勧めています。ゲームでは次の項目にそろえます。

項目	書くこと	例
タイトル	どこで・何をすると・どうなるか	3面のボスを倒した直後にポーズすると、操作できなくなる
環境	ビルドの版、OS、解像度、入力機器	0.9.2（10月3日のビルド）／Windows 11／1920×1080／コントローラー
再現手順	最小限の手順を番号付きで	①3面を始める ②ボスを倒す ③撃破の演出中にポーズする ④ポーズを解除する
期待した結果	本来どうなるべきか	演出の後、結果画面へ進む
実際の結果	見たままを書く	画面は動いているが、どのボタンも効かない
頻度	何回試して何回起きたか	5回中5回
画像・動画・ログ	起きた瞬間と、ログの該当部分	動画（約15秒）、終了直前のログ20行
重さ	次の節の基準で	A（進行不能）

「ボス戦でたまに固まる」では、どのボスか、何をしたときか、何回に1回か、固まるとはどういう状態かがわかりません。

特に気をつけたいのは、症状に名前を付けて決めつけないことです。筆者の開発中の将棋ゲームの実験版では、「フリーズする」と思い込んでいた不具合の本当の原因は、画面に表示されないダイアログ（確認の小窓）が入力を塞いでいたことでした。「フリーズ」と書くと、処理が止まっていると読まれます。「画面は動いているが、クリックが効かない」と見たままを書けば、原因の探し方が変わります。

バグ報告の型。タイトル・環境・再現手順・期待した結果・実際の結果・頻度・添付・重さの8項目と、「たまに固まる」ではなく見たままを書く例 — 図1：別の人が同じ手順で再現できるように、決まった項目で書く

夕宮たいだ

タイトル・環境・手順・期待・実際・頻度。この型で書いておけば、あとで自分が直すときも楽なんだぁ。便利でしょ？

重さと優先度の付け方

ひとことで：重さ（どれだけ困るか）と優先度（どの順に直すか）を分けて付け、出荷を止める不具合をはっきりさせます。

テストの用語集の ISTQB は、重さ（severity）を「欠陥が開発や運用に与える影響の度合い」、優先度（priority）を「（ビジネス上の）重要さの度合い」と分けています（Severity・Priority、ISTQB 用語集 3.4版）。重さは不具合そのものの性質で、優先度は「いつ直すか」というチームの判断です。重さの段階は、たとえば次のように決めます。A〜C の3段階は一例で、段階の数や呼び方は会社によって違います。

重さ（例）	基準	例
A：出荷を止める	強制終了、進行不能、セーブの消失、課金や実績の誤り	ボス撃破後に操作できなくなる
B：直してから出したい	遊べるが目立つ誤り、回避できる進行の問題	特定の手順で BGM が止まる
C：余裕があれば直す	見た目や文言の小さな誤り	影が1ドットずれる

優先度は、重さに頻度（全員が通る場所か）、目立つ場所か（最初の数分、体験版の範囲、ストアのスクリーンショットに映る画面）、直す危険（直すと別の所が壊れそうか）、期日（審査や発売日までの残り時間）を加えて決めます。たとえば、タイトル画面の誤字は重さ C でも優先度は高くなります。何を「出荷を止める不具合」とするかは、テストを始める前に決めておきます。

不具合の重さ（A〜C）と優先度を上げる要素の2軸。全員が通る所の進行不能はすぐ直し、めったに起きない強制終了は原因を調べてから判断、タイトル画面の誤字は早く直し、影のずれは後回し — 図2：重さは不具合の性質、優先度は直す順番。2つを分けて付ける

夕宮たいだ

重さと優先度、いっしょにしちゃいがちだよねぇ……むずかしいねぇ。「どれだけ困るか」と「どの順に直すか」は別もの、って分けるのがコツなんだぁ。

バグ管理の道具

ひとことで：報告を1か所に集め、「新規→対応中→修正済み→確認済み」の状態で追える道具を使います。

道具	向く規模	特徴
表計算（スプレッドシート）	個人〜数人	手軽で、項目を自由に作れる。同時編集や履歴には弱い
GitHub の Issues	個人〜少人数（コードを GitHub で管理している場合）	コードの変更と結び付けられる。報告の型を用意できる
タスク管理ツール、専用のバグ管理システム	少人数〜大きなチーム	担当・期日・状態を細かく管理できる

GitHub では、リポジトリの .github/ISSUE_TEMPLATE フォルダに報告の型を置けます。入力欄を作れる Issue forms を使えば、前の節の項目を必須の欄にできます（GitHub Docs）。

どの道具でも、状態の流れをそろえます。新規（報告された）→再現済み（別の人が再現できた）→対応中→修正済み（直したビルドの版を書く）→確認済み（直ったことを確かめた）。直さないものは直さない（仕様どおり、または見送り）として理由を残します。報告の前には同じ不具合が書かれていないかを探し、重なったら1つにまとめます。

修正の確認と回帰テスト

ひとことで：直ったかを確かめ（確認テスト）、直したことで別の所が壊れていないかも確かめます（回帰テスト）。

ISTQB の用語集では、確認テスト（confirmation testing）を「欠陥を直した後に、その欠陥による故障が再び起きないことを確かめるテスト」、回帰テスト（regression testing）を「変更していない部分に欠陥が入り込んだり、表に出たりしていないかを確かめるテスト」としています。

確認テストは、報告と同じ手順・同じ環境で行う。直した人とは別の人が確かめると、思い込みを防げる
回帰テストは、直した所とつながる機能を中心に行う。過去に直した不具合の手順をチェックリストに足していくと、再発を防げる
自動テストがあるなら、不具合を1件直すたびに、その不具合を再現するテストを1本足す

修正は、直す人が「直した」と言った時点ではなく、確かめた時点で完了です。出荷の前に QA を終えてよい目安は、たとえば次の3つがそろったときです（基準は会社や契約で違います）。

重さ A の不具合が0件になった
重さ B の不具合は、直したか、直さない理由を決めた
最後のビルドでスモークテストと全部の自動テストが通り、配布版を遊ぶ人と同じ手順で起動して確かめた

自動テスト

ひとことで：人の手では回しきれない確認を、プログラムに毎回同じ手順で行わせます。

種類	確かめること（例）
単体テスト	ダメージの計算、役の判定、カードの効果など、ルールの関数が正しい答えを返すか
画面を出さないテスト	画面を描かずに（ヘッドレスで）処理を走らせ、1局・1面を最後まで進められるか
通しのスモークテスト	配布用の実行ファイルが起動し、タイトルから最初の面まで進めるか
乱数の種の固定	同じ乱数の種なら毎回同じ結果になるか（リプレイ・中断からの再開・不具合の再現に必要）
画面の撮影比較	決まった場面の画面を撮り、前の版と比べて崩れていないか

主なエンジンには、テストのための仕組みがあります。

Godot：コマンドラインの --headless で、画面を出さずに実行できる（公式ドキュメント）。テストの道具は、GUT や GdUnit4 などのアドオンか自前のスクリプト
Unity：Unity Test Framework で、エディターの中で動かす Edit Mode のテストと、ゲームの実行中に動かす Play Mode のテストを書ける（Unity マニュアル）
Unreal Engine：Automation Test Framework に、単体・機能・スモーク・負荷（Content Stress）・画面の撮影比較などの区分がある（UE 5.8 ドキュメント）

乱数の種を固定するテストには注意点があります。Godot の公式ドキュメントは、同じ種からは同じ並びの乱数が得られるとする一方、乱数を作る計算方法そのものは実装の詳細で頼るべきではない、と書いています（RandomNumberGenerator）。エンジンの版を上げたら、種を固定したテストの結果が変わっていないかを最初に確かめます。

開発用の機能（ステージを選べるメニュー、全部が見える表示など）はテストに欠かせませんが、製品版に残ると事故になります。筆者の麻雀ゲームでは、開発用の機能を「開発用デバッグ」のボタンにまとめ、Godot の OS.is_debug_build()（デバッグ用の書き出しかどうかを返す）で、製品版の書き出しでは自動で消えるようにしています。

クラッシュログと動作環境の確認

ひとことで：落ちたときの手がかり（ログ）を残せるようにし、遊ぶ人の環境と起動のしかたで確かめます。

ゲームが強制終了（クラッシュ）したときの手がかりになるログ（動作の記録）は、エンジンが決まった場所に書き出します。2026年10月時点の公式ドキュメントでは、Godot はデスクトップで既定で user://logs/godot.log に書き、5本まで残します（ログの説明。4.5 以降は独自のログの処理も追加できる）。Unity の Windows の製品版は %USERPROFILE%\AppData\LocalLow\会社名\製品名\Player.log です（Log files）。ログの先頭にゲームの版・OS・解像度・言語・乱数の種を書き出しておくと、再現が速くなります。購入者向けの案内にも、ログの場所と送り方を書いておきます。

動作環境は、OS の版、GPU のメーカー、メモリの少ない PC、解像度と画面の縦横比、拡大率（高 DPI）、複数のモニター、コントローラーの種類と途中での接続・切断を組み合わせて確かめます。さらに、遊ぶ人と同じ起動のしかたでも確かめます。筆者の麻雀ゲームでは、通常の起動のときだけ表示が日本語に固定される不具合がありました。テストでは起動の引数で言語を指定していたため、再現しなかったのです。

Steam Deck に対応するなら、互換性のレビューの基準も確かめます。2026年10月時点の公式ドキュメント（Steam Deck and Steam Machine Compatibility Review）では、評価は Verified（認証済み）・Playable（プレイ可能）・Unsupported（非対応）・Unknown（不明）の4つです。Verified には、既定の操作設定でコントローラーだけで全内容に届く、画面のボタン表示が使っている入力と一致する、1280×800 で文字の高さが最小9ピクセル（推奨12ピクセル）以上、既定の設定で 800p・30fps 程度の遊べるフレームレートが出る、などが求められます。結果は互換性の表示だけに影響し、販売できるかどうかには影響しません（移植全般は「ゲームの移植とマルチプラットフォーム」）。なお、Steam のビルドの審査で見るのは、対応 OS で起動するか、ストアに書いた機能が入っているか、ゲーム内課金が Steam の決済を使うか、などで、品質全体を確かめてくれるわけではありません。

セーブデータのテスト

ひとことで：保存と読み込みだけでなく、壊れたとき・版が変わったとき・途中で終わったときを確かめます。

セーブデータが消える・読めなくなる不具合は、遊んだ時間ごと失わせるので、重さを最上位に置きます。次の場面を確かめます。

保存の途中で強制終了したとき（電源が切れた想定）、ファイルが壊れていたとき
古い版で作ったセーブを新しい版で読むとき、新しい版のセーブを古い版で開いたとき（ベータ版のブランチから戻したときなど）
保存先の容量が足りない、書き込みが禁止されているとき
クラウド保存で、別の PC から続きを遊ぶとき。体験版のセーブを製品版に引き継ぐとき

筆者の麻雀ゲームでは、セーブの保守の方針として、すべてのファイルに版番号を持たせる、安全に書き込む（一時ファイルに書く→控えを取る→入れ替える）、壊れていたら隔離して一度だけ知らせる、過去の版のセーブを保存しておいてテストに使う、と決めています。表示と中身の食い違いにも注意します。筆者の作品の1つでは、Steam の自動クラウド保存で同期するファイルの指定が0件のままなのに、ストアの機能の欄には「Steam クラウド」と表示されていました。設定画面を見るだけでなく、実際に別の PC で続きから遊べるかを確かめます。

夕宮たいだ

ぁぅ……セーブが消えるのは、何十時間ぶんの思い出が消えるってことなんだよねぇ。壊れたときの確認まで、ちゃんとやっておこうねぇ。

AIゲーム開発でのQA・デバッグ

ひとことで：テストを書く・ログを読む・報告を整える作業は AI が速く、何を出荷を止める不具合とするかと最後の確認は人が決めます。

小さな確認と全部の確認の2段構え

AI エージェントはコードを速く変えるので、確認の回数も増えます。変更のたびに全部のテストを回すと待ち時間が長くなり、かといって確認を省くと、壊れたまま先へ進んでしまいます。そこで確認を2段に分けます。重心は「テストを書く」作業から、「どの段で何を確かめるか」を決める設計の側へ移ります。

段	いつ	中身
小さな確認	文言・1画面・数値など小さな変更のたび	全スクリプトの文法チェック＋変更した所のテスト（数十秒）
全部の確認	大きな変更、ビルドを渡す前、作業の区切り	全テスト＋配布用の書き出し＋起動の確認

小さな確認に通っても、「大きな問題はなさそう」という意味でしかありません。作業の区切りでは必ず全部の確認を通します。AI に作業を頼むときも、どちらの段を通してから報告するかを依頼文に書いておきます。「小さな確認を通した」と「全部の確認を通した」は、意味が違うからです。

筆者は Godot 4 で、画面を出さずに走らせる自前のテストを使っています。提出時の自動テストの確認項目は、「つみこめ！イカサマ魔法麻雀」で約3.2万件、開発中の将棋ゲームで8.2万件、同じエンジンから派生させたカードゲームで66万件で、どれも失敗は0件でした。小さな変更は約30秒の簡易版で確かめます。また、テストは弱い CPU で行います。強い CPU は1手に10秒かかることがあり、自動の計測が2時間たっても終わらないからです。

AI に任せやすいこと

自動テストを書く：直した不具合ごとに、再発を防ぐテストを1本足す
ログを読ませて原因を絞る：エラーの行、直前の操作、起きた条件の共通点を探す
再現手順を作る：曖昧な報告から、試しながら最小の手順まで削る。本当に再現できたことを、記録や動画で示させる
バグ報告を整える：重複をまとめ、抜けている項目を指摘し、重さの案を付ける
届いたログを集計する：テスターや購入者のログを読み、同じ原因らしいものを束ねて件数の多い順に並べる
チェックリストを作る：仕様書と変更点から、確かめる項目を書き出す

人が決めること

何を「出荷を止める不具合」とするか。個々の不具合で出荷を止めるかどうか
「直さない（仕様どおり・見送り）」の判断
AI が「直した」と報告した重い不具合を、報告と同じ手順で自分でも確かめること
実機と、遊ぶ人と同じ起動のしかたでの最後の確認

落とし穴

壊れたテストが「見かけだけ合格」になる：文法の誤りで読み込めなかったテストは実行されず、失敗0件のまま件数だけが減ります。筆者は小さな確認でも最初に全スクリプトの文法チェックを走らせ、テストの総数も見ています。また、Codex に麻雀ゲームを試し遊びさせたときには、「実行時のエラーがテストの失敗に数えられていない」という穴も見つかりました（「プレイテストのやり方」）
AI の修正で別の所が壊れる：変更を小さく分け、そのたびに回帰テストを回します。テストを消したり、期待する値を書き換えて合格させたりしないよう、依頼文で禁止しておきます
テストが本物のセーブデータを汚す：筆者の麻雀ゲームでは、テストが筆者の実際の設定を既定値で上書きし、実績を書き込む事故がありました。今は、テストの前に本物のファイルを退避して終わったら戻し、テスト用の保存先を分けて（隔離して）います
同じ乱数の種で結果が変わる：筆者は「同じ種なら同じ結果」をテストで守っています。これが崩れると不具合を再現できず、AI に原因を探させることもできません
ログに含まれる個人情報：購入者から届いたログには、パソコンのユーザー名を含むフォルダのパスなどが入っていることがあります。外部の AI サービスに渡す前に消します

テストの実行を作業の手順に組み込む方法は「CLAUDE.md 完全ガイド」「Claude Code MCP・Hooks活用ガイド」で扱っています。

依頼文の例

書き方の基本は「Claude Code プロンプト設計」「Codexプロンプト設計」で解説しています。

Goal: 報告「3面のボス撃破直後にポーズすると操作できない」を直し、再発を防ぐテストを足す
Context: 再現手順とログは報告に添付。テストは tests/ に置き、乱数の種を固定して書く
Done when: 足したテストが修正前に失敗し、修正後に通る。全テストが通り、テストの総数が減っていない
Constraints: 既存のテストを消したり期待する値を変えたりしない（必要なら理由を書いて相談する）。
  テストは一時フォルダの保存先で動かし、本物のセーブデータに触れない

夕宮たいだ

テストを消して「全部合格！」にするの、絶対ダメだよぉ。テストの数が減ってないかも、毎回見てねぇ。

よくある失敗と対処

ひとことで：多くは「再現できない報告」「確かめずに閉じる」「テストの仕組みの穴」から起きます。

失敗	起きること	対処
「たまに落ちる」だけの報告	誰も再現できない	手順・頻度・環境・ログをそろえる
1件の報告に複数の不具合	一部だけ直って閉じられる	1件の報告に1つの不具合
重さと優先度を混ぜる	目立つが軽いものばかり直る	分けて付け、出荷を止める基準を先に決める
直したら確かめずに閉じる	直っていない、別の所が壊れる	確認テストと回帰テストを行う
テスト用の起動だけで確かめる	遊ぶ人の環境でだけ起きる	配布版・通常の起動・実機で確かめる
テストの件数を見ない	見かけだけの合格	文法チェックを先に走らせ、総数も見る
テストが本物のセーブを使う	設定や記録が消える	退避と隔離
終盤にまとめてテストする	不具合が多すぎて直しきれない	開発中から小さく回す