バグなのか仕様なのか——「グレーゾーン」の判断プロセス
はじめに
「これはバグですか、それとも仕様ですか？」
ゲーム開発の現場でこの問いが発せられるとき、それはたいてい 誰も正解を持っていない状態 を意味する。QAエンジニアは「想定外の動作が起きている」と言い、プログラマーは「自分は仕様通りに作った」と言い、プランナーは「そんなケースは想定していなかった」と言う。
この三者が噛み合わないのは、「実装後に炎上する仕様書」の共通点でも触れているように、そもそも仕様書がグレーゾーンをカバーしていないからだ。しかしプランナーにとって必要なのは、問いが来た瞬間に何をすべきか というプロセスを持つことだ。
この記事では「バグ」と「仕様」の定義の整理から始め、グレーゾーンに分類される主要パターン、現場での判断フロー、そして「バグが仕様になる」という現象の歴史的事例まで掘り下げる。
第一章：そもそも「バグ」とは何か
定義の問題
バグの最もシンプルな定義は「開発者が想定していなかった挙動」だ。どれほど巧みに動いていても、開発者が意図していないならバグと言ってよい。[1]
より形式的な定義では、仕様書（要求仕様）から逸脱した動作 をバグ、あるいはデフェクト（欠陥）と呼ぶ。「デフェクト」は「期待された仕様」と「実際の動作」の差分であり、コードそのものの問題に限定されない。[2]
| 用語 | 意味 | 主な発見時期 |
|---|---|---|
| バグ（Bug） | コードが意図せず誤った動作をする | テスト中 |
| デフェクト（Defect） | 仕様・要件との乖離 | テスト後期〜リリース後 |
| エラー（Error） | 開発者の判断ミスや記述ミス | 開発中 |
しかし現場ではこの3つを厳密に使い分けることは少なく、「バグ」という言葉が最も広い概念として使われている。
「仕様書に書かれていない＝バグ」は正しいか？
QAの基本原則として「仕様書に書かれていない機能はテスト対象にならない」がある。つまり 仕様書に記載がなければ、何が起きても「バグ」と判定できない。[3]
これは逆説的に「仕様書の穴」がグレーゾーンを生む、ということを意味する。仕様書に境界条件が書かれていなければ、その境界での動作は「正しいかどうかを判定できない状態」になる。開発者の観点でも、デバッガーやプレイヤーは、どこまでが開発者の想定した挙動なのかを知る術を持たず、頼れるのは仕様書などゲーム外へアウトプットされた情報に限られるが、それにも限界がある。[4][1]
第二章：グレーゾーンの5パターン
グレーゾーンに分類される事象には、いくつかの典型的なパターンがある。
パターン1：「仕様書に書いていない」
最も多いケース。仕様書が正常系しかカバーしておらず、例外ケースや状態の組み合わせが未定義のまま、QAが不審な動作を発見する。[5]
例：「スタン状態のキャラクターが特定のスキルを使うとゲームがフリーズする」
→ スタン時の行動制限は仕様書に明記されているが、「そのスキルがスタン中に使用された場合」が未定義
この場合の「正しい答え」は仕様書にないため、プランナーが意図を持って判断する必要がある。
パターン2：「バグが面白い」——エマージェントゲームプレイ
意図していなかった挙動が、プレイヤーにとって面白い体験を生み出しているケースだ。
歴史上最も有名な事例の一つが、Quake シリーズで広まった ロケットジャンプ だ。ロケットランチャーの爆発によるノックバックは敵だけでなく発射した自分自身にも働き、これをジャンプと組み合わせると通常では届かない高所へ到達できる。id Software は自分への大ダメージから「自殺行為で誰もやらない」と考えており、この挙動を前提にマップを設計していなかったが、発見後はレベルデザインに取り込み、Team Fortress 2 などの後継作では 意図的な設計要素として組み込まれた。[6][20][21]
スペースインベーダーの「名古屋撃ち」も同様だ。インベーダーは自機の1画素下から弾を発射し、さらにもう1画素下の地点で砲台への着弾を判定する仕様だった。このため砲台がインベーダーの直下に密着すると、プログラム上は着弾判定ができず、砲台が一方的に攻撃できる「バグ」が生じた。プレイヤーはこれを発見し、上級テクニックとして活用した。[7]
こうした「バグが面白さを生む」現象を エマージェントゲームプレイ と呼ぶ。「複数のルールやメカニクスが設計通りに機能しながら、開発者が意図しなかった形で相互作用して生まれるゲームプレイ」と定義される。[8][6]
パターン3：「修正できないから仕様にする」——現実的妥協
開発現場の正直な話として、「修正する工数・リスクが修正によるメリットを上回る」と判断したバグが、事実上「仕様です」とされるケースがある。[9]
Aバグ（進行不能・クラッシュ系）の修正に追われるデバッグ終盤、Bバグ（修正しないと質が落ちる）の一部は修正が間に合わず保留になり、「これはもとから意図したものだ」と後から言い切ることになる。[9]
これは開発者の誠実さの問題ではなく、リソース制約の現実 だ。重要なのは「仕様化した」という意思決定を文書として残し、将来のバージョンで対処するかどうかの判断材料にすることだ。[4]
パターン4：「プレイヤーには嬉しいが設計上は問題」——有利バグ
ランダム性のあるゲームにおいて、乱数の仕組みを利用してプレイヤーが有利になる挙動が発生するケースだ。[10]
例えば、特定のタイミングでアプリを終了・再起動すると報酬の抽選がやり直せる「乱数ずらし」に相当するバグが発見された事例では、バグを報告したコミュニティが「この挙動は許容してほしい」と主張し、開発者・プレイヤー間で対立が生じた。有利バグは「プレイヤーが意図的に利用する可能性がある」という点で、単純な不具合より複雑な判断を要する。[10]
パターン5：「他システムとの相互作用」——複合バグ
複数のルールが組み合わさって生じる挙動で、どの仕様書にも単独では「悪い」と書かれていないが、全体として想定外の結果になるケースだ。意図しない不具合のこともあれば、判断の末に仕様として残されることもある。[11]
Minecraft の「無限水源（infinite water source）」がこの境界の難しさを示す。水源ブロックを2つ向かい合わせに置くと、その間の流水ブロックが新たな水源ブロックに変化し、汲み出しても無限に再生する。物理的には「無から水を生み出す」挙動であり、長らくコミュニティでは「バグか仕様か」が議論されてきた。しかし Minecraft はこれを修正せず、むしろ Java Edition では水源生成のオン・オフを切り替えるゲームルール（waterSourceConversion）として明示的に扱っている。一方で溶岩には同じ仕組みを与えておらず、既定では溶岩源は再生しない。つまり「複数のルールの相互作用で生じた挙動を、開発側が意図的に仕様として残した」境界事例である。[12][13]
第三章：現場での判断プロセス
ステップ1：「重大性（Severity）」と「優先度（Priority）」を分ける
判断の最初のステップは、重大性と優先度を別々に評価すること だ。[14][15]
| 概念 | 定義 | 誰が判断するか |
|---|---|---|
| 重大性（Severity） | 技術的にどれだけシステムへの影響が大きいか | QAエンジニア |
| 優先度（Priority） | ビジネス観点でいつ修正すべきか | プロデューサー・プランナー・PM |
重大性が高くても優先度が低いケースと、重大性が低くても優先度が高いケースが存在する：[15]
- 重大性：高 / 優先度：低 の例：プライバシーページが表示されないバグ（機能的には深刻だが、緊急性は低い）
- 重大性：低 / 優先度：高 の例：トップページのゲームタイトルにスペルミスがある（機能的影響は軽微だが、リリース前なら即座に修正すべき）
この2つを混同すると、「バグとして重大性を強調すれば修正が速くなる」という誤った駆け引きが生まれ、チームの判断が歪む。[16]
ステップ2：バグランクで分類する
多くのゲーム開発現場では、発見された不具合を A/B/C（または S1/S2/S3）のランク で分類する：[14][9]
| ランク | 定義 | 対応 |
|---|---|---|
| Sバグ / Aバグ（Blocker/Critical） | 進行不能、クラッシュ、データ破損、フリーズ | 原則として修正必須。リリース不可 |
| Bバグ（Major） | 修正しないとゲームの質が著しく低下する | 可能な限り修正。間に合わなければ仕様化の検討 |
| Cバグ（Minor/Trivial） | 軽微な見た目の問題、極低頻度の現象 | 余裕があれば修正。ほぼ仕様化されることが多い |
スコアリングによる優先度判断を導入したチームでは、「ユーザー影響度」「機能の壊れている程度」「ビジネス重要度」「法務・セキュリティリスク」を複数軸で評価し、合計スコアでランク付けするアプローチが有効とされている。[17]
ステップ3：グレーゾーンの「意思決定チェックリスト」
QAから「これはバグですか？」と問われたプランナーが最初に確認すべき問いは以下の6点だ：[2][5][4]
- 仕様書にこの動作の記述はあるか？（あれば仕様書との比較で判断できる）
- この動作はプレイヤーに不利益を与えるか？（データ損失・進行不能・不公平な体験）
- この動作はプレイヤーに意図せぬ有利をもたらすか？（乱数操作・無限入手など）
- この動作はプレイヤーが「意図された動き」と認識するか？（気づかなければ問題が表面化しない）
- 修正に伴うリスク（他への影響）はどの程度か？（連鎖バグのリスク）
- 修正するコストとしないコストを比較したとき、どちらが高いか？
この6点に答えた上で、「修正する・仕様化する・保留にする」のいずれかを決定し、文書に残す。口頭での判断だけでは同じ問いが繰り返される。[4]
ステップ4：「仕様化」の場合の文書化
「仕様化」という判断を下す場合、単に「修正しない」とバグチケットをクローズするだけでは不十分だ。以下を記録する：[16][4]
- 判断日・判断者
- 仕様化の理由（修正コストが高い / プレイヤーに実害がない / エマージェントとして価値があるなど）
- 将来の対応方針（次バージョンで検討する / 永続的に仕様とする / 状況が変われば再検討する）
これにより、「なぜこうなっているのか」が将来のチームメンバーにも伝わる。
第四章：「バグが仕様になる」という現象の構造
意図せず面白くなったバグが「仕様」に昇格する流れ
歴史的に有名なバグが正式な仕様として取り込まれたケースは複数ある。
- ロケットジャンプ（Quake → Team Fortress 2）：爆発のノックバックを利用した垂直移動。後継作では公式に設計要素として組み込まれた。[6][20]
- スペースインベーダーの「名古屋撃ち」：砲台がインベーダー直下に入ると当たり判定が機能しなくなるバグ。プレイヤーに上級テクニックとして認知された。[7]
- 格闘ゲームのキャンセル技：スト2では、通常技の硬直中に必殺技コマンドを入力すると硬直がキャンセルされる挙動が見つかった。プロデューサーの船水紀孝はプレイテスト中にこの連続技を偶然発見し、タイミングが難しすぎて実用にならないと考え、隠し要素として残した。後にデザイナーの西谷亮も、この挙動を不具合ではなく仕様として残したと語っている。現在では格闘ゲームの基幹システムとして設計に組み込まれている。[18][22][23]
これらの共通点は、「複数の仕様が設計通りに機能しながら相互作用した結果」である点だ。どれも「バグ」というよりは「仕様の想定外の組み合わせ」であり、意図せぬエマージェントゲームプレイの典型例だ。[6]
「仕様なのか仕様化したのか」は問いを変える
「仕様化された動作」と「最初から意図された動作」は、プレイヤーには区別できない。しかし開発チームの内部では意味が異なる：[18]
- 最初から意図された仕様：設計思想に基づいており、他の仕様との整合性がある
- 後から仕様化されたバグ：修正できなかった経緯がある。将来の類似実装で同じ問題が再発するリスクがある
この違いを記録しておかないと、次のバージョンで「この挙動は何のために存在するのか」がわからなくなる。先述の文書化がここでも重要になる。
第五章：プランナーが巻き込まれる「炎上パターン」
「バグか仕様か」がコミュニティに伝わるとき
プレイヤーに不利益なバグが放置されたとき、開発側が「仕様です」と回答するケースがある。このとき、コミュニティの受け取り方は「本当に最初から意図されていたのか、修正できないから仕様と言っているのか」を推測する段階に入る。[19]
事実として、デバッグ終盤に修正が間に合わないBバグが「仕様」として処理される例は少なくない。このことがコミュニティに知られると、「仕様です」という回答が「諦めた」「ユーザーをごまかしている」と解釈されやすい。[9]
炎上を避けるための対応原則：
- 「仕様です」の一言で終わらせない。「この挙動の意図」と「今後の対応方針」を合わせて伝える
- プレイヤーに不利益なバグを「仕様化」する場合は、「意図された仕様」ではなく「現時点では修正しない判断をした」という事実に誠実であること
- エマージェントゲームプレイのように「プレイヤーが楽しんでいるバグ」を修正する場合は、事前に理由を丁寧に説明する
プランナーの実践チェックリスト
- バグ報告を受けたとき、まず「仕様書にこの動作の記述があるか」を確認したか？
- 「重大性（Severity）」と「優先度（Priority）」を分けて評価したか？
- 「仕様化」という判断を下した場合、理由・判断者・将来の対応方針を記録したか？
- 「エマージェントゲームプレイ」の可能性（プレイヤーが面白がっている）を検討したか？
- 「有利バグ」の場合、コミュニティへの影響（不公平感・経済バランスの破壊）を評価したか？
- 「バグか仕様か」の判断を口頭だけで済ませず、チケット・仕様書・更新履歴に反映させたか？
「バグか仕様か」という問いに正解はない。あるのは「誰が・何をもとに・なぜその判断をしたか」という プロセスの透明性 だけだ。その透明性がチームを守り、プレイヤーとの信頼関係を保つ。
References
1. ゲームのバグって何なのか - ノアのWeblog - 仕様か否かをプレイヤーは見分けられず、開発者の想定こそがバグの基準になる、という論考。
2. Bug vs Defect: What Every QA Tester Needs to Know - バグとデフェクトの違い・原因・種類を整理したQA向け解説。
3. ゲーム開発に仕様書を求めるのは間違っているだろうか - テストケースは仕様書を基に作るため、仕様書に記載のない機能はそもそもテスト対象にならないと指摘。
4. QAエンジニアのバグの扱い方｜QAを楽しむ者 - note - 改修しないと判断したバグを計画的に後工程へ乗せる、QAのバグの扱い方を解説。
5. ゲーム開発、仕様のすれ違いはなぜ起こる？若手に伝えたいチームづくり - 仕様のすれ違いがなぜ起こるかを、UI不具合の実例から論じたチーム開発の記事。
6. Is Rocket Jumping a Glitch? - YouTube - ロケットジャンプがグリッチか否かを検証した動画。
7. コンピュータゲーム最大のバグ「弾が当たっても倒れない」 - TechFactory - インベーダーが自機の1画素下から弾を発射し、さらに1画素下で着弾を判定するため、砲台が直下に密着すると判定が機能しないと解説。
8. Rogers, LevelUp: The Guide to Great Video Game Design（PDF） - エマージェントゲームプレイの定義を扱うゲームデザイン書。
9. 【ゲーム開発】Aバグ、Bバグ、Cバグとは？ - のりブログ - デバッグ終盤に優先度の低いBバグがCバグへ降格する、という現場のバグランク運用を解説。
10. 炎上に巻き込まれてプレイヤーと開発者の仲裁に入った話 - note - 有利バグをめぐりコミュニティと開発者の間で生じた対立に、第三者が仲裁に入った経緯の記録。
11. ゲームの仕様書に必要なコト｜mTsuruta - note - ゲーム仕様書に必要な要素をまとめた記事。
12. Water - Minecraft Wiki - 水源ブロックを2つ向かい合わせると間に再生する水源ブロックが生成される仕組みと、Java Edition の waterSourceConversion ゲームルールを解説。
13. Lava - Minecraft Wiki - 溶岩は既定では隣接源ブロックによる無限源を生成しない（lavaSourceConversion 有効時のみ生成）ことを記述。
14. Bug Severity vs Priority: How to Manage Defect Fixing - QAMadness - S1〜S3のバグ重大度区分と、重大性・優先度の管理手法を解説。
15. Bug severity vs priority: the 5x5 matrix explained - BetterQA - 重大性と優先度を分けて評価する5×5マトリクスを解説。
16. Is It a Bug Or A Feature? Who Cares? - the agile admin - 「バグか機能か」の区別より優先度の合意が重要だと論じる記事。
17. バグの優先度判断基準/フローの適正化をスコアリングで行った話 - Zenn - ユーザー影響度などを複数軸でスコアリングし、バグの優先度判断を適正化した事例。
18. 仕様とバグの境界線はどこにあるのか - プログラマyasuhoの隠れ家 - 仕様とバグの境界は操作感の統一性にあるとする論考。
19. ゲームにおけるバグと仕様の違いとは - Yahoo!知恵袋 - バグと仕様の違いに関するQ&A。直したくないバグを「仕様」と呼ぶ場合があると指摘。
20. Rocket jumping - Wikipedia - ロケットジャンプの起源は不明確だが Quake と Team Fortress 2 で普及し、Quake シリーズでは意図的なメカニクスとして維持されたと解説。
21. Rocket Jump - Quake Wiki - id Software は自傷ダメージを理由に当初ロケットジャンプを想定せず、発見後にマップ設計へ取り込んだ経緯を記述。
22. Street Fighter II designer opens up about the cancelling ‘bug’ - Game Developer - デザイナー西谷亮が、キャンセル挙動を不具合ではなく仕様として残した経緯を語ったインタビュー記事。
23. Returning To Round One: The History Of Street Fighter - Game Informer - プロデューサー船水紀孝がプレイテスト中にコンボを偶然発見し、隠し要素として残したと証言。
この文書は、Perplexity、Claude、OpenAI Codex の3つのAIの支援を受けて著述されたものです。引用画像を除き、MIT License にて提供されています。