見落としやすいバグ30選｜3分類で防ぐ確認手順

2026 7/27

2026年7月27日 2026年7月27日

リリース直前、テストの時間が足りず、品質を妥協したまま出してしまう。そんな状態で本番を迎え、後からバグが発覚してクライアントの信頼を損なう。受託開発の現場でくり返される痛みではないでしょうか。こうした痛みの多くは、正しい手順では通ってしまう見落としやすいバグが原因です。

やっかいなのは、機能としては「動いてしまう」不具合です。正しい手順では問題なく通るため、開発者もテスト担当も気づかないまま通過します。こうした抜け漏れは、少しの操作のズレや環境の違いで初めて表面化します。だからこそ、エラーで止まるバグよりも本番まで生き残りやすいのです。

本記事では、現場のテスターが実際に「あれ？」と引っかかってきた一次観点を30個集め、「画面・操作」「仕様と動きのズレ」「環境依存」の3分類に整理しました。兼任体制で抜け漏れに悩む方の、リリース前チェックリストとしてお使いください。

なぜ「動くのに危ないバグ」は見落とされるのか

見落としが起きる根本には、テストする人の「通る道」の偏りがあります。開発者は仕様を理解しているぶん、無意識に正しい入力・正しい順番で操作します。その結果、想定外の使い方をされる経路がまるごと抜け落ちます。

開発者は、自分が作った正常系の道しか通らない傾向があります。エラーになるはずの操作や、ユーザーが「うっかり」やる操作は、作った本人ほど再現しにくいものです。ここに、動くのに危ないバグが潜みます。

さらに兼任体制では、この盲点が固定化しやすくなります。開発とテストを同じ人が担うと、コードを書いたときの思い込みがそのままテストにも持ち込まれるためです。時間に追われるほど「自分が確認した範囲」だけで安心してしまいます。

テストの心構えとしても、この点は昔から指摘されてきました。高橋寿一『知識ゼロから学ぶソフトウェアテスト』では、G・J・マイヤーズの「エラーは見つからないだろうという仮定のもとにテストの計画を立ててはいけない」という言葉が紹介されています。「たぶん大丈夫」で組んだ計画は、まさにその「たぶん」の部分を素通りします。

もうひとつ前提として押さえたいのが、バグの偏りです。同書では、バグは特定の部分に集中して存在する「バグ偏在の法則」も取り上げられています。やみくもに全体を触るより、出やすい場所に観点を当てるほうが効率的だという考え方です。

言い換えれば、テストの精度は「どこに、どんな観点をぶつけるか」で決まります。時間が限られる受託開発では、この選択と集中が現実的な武器になります。だからこそ、感覚ではなく言語化された観点リストが要になるのです。

バグを全部見つけることはできないと割り切る
「出やすい場所」と「見落としやすい観点」を先に決めておく
正常系だけでなく、異常な入力・操作・環境を意図的に通す

こうした前提は感覚論ではなく、公的な調査からも裏づけられます。IPA（情報処理推進機構）の「ソフトウェア開発分析データ集」のような公的資料では、開発工程ごとの不具合の傾向がデータとして整理されています。自社の肌感覚を、こうした客観的な資料と照らし合わせておくと説得力が増します。

上長や経営者に体制強化を提案する場面でも、この視点は役立ちます。「なんとなく不安だから」ではなく、「抜け漏れが集中する領域に手が回っていない」と具体的に語れるからです。客観的な傾向と自社の実例をセットで示すと、費用対効果の議論に持ち込みやすくなります。

見落とし観点を防ぐ第一歩は、「全部は見つからない」と認めたうえで観点を持つことです。次章から、その観点を3つに分けて具体化していきます。

参考: IPA「ソフトウェア開発分析データ集」

見落としやすいバグを3つに分類する

なぜ観点を「分類」するのでしょうか。理由は、分類がそのままチェックリストになるからです。頭の中の暗黙知を並べ替えて名前をつけると、抜けている列がひと目で分かるようになります。

本記事で使う3分類は次のとおりです。それぞれ、バグが表面化する「きっかけ」が異なります。

分類	何がきっかけで表面化するか	代表的な症状
画面・操作	ユーザーの見え方・触り方	はみ出し、当たり判定、多重送信
仕様と動きのズレ	入力値やロジックの境界	境界の誤判定、バリデーション抜け
環境依存	端末・ブラウザ・文字コード	スマホでの崩れ、文字化け

抜け漏れは、3分類に整理すればチェックリストになります。ばらばらの失敗談も、どのきっかけで起きるかで並べ直せば、次回そのまま確認手順として回せます。

分類のかたちに正解はありません。Copeland『ソフトウェアテスト技法』でも、欠陥分類について「一番役に立つのは自分自身の分類、つまり自分で作成した分類である」と述べられています。既存の枠から出発し、自社で実際に出たバグを足し引きして育てるのが最良のやり方です。

大切なのは、最初から完璧な分類を目指さないことです。Copelandは「唯一の正しい分類は存在しない」とも述べています。カテゴリの境界が多少あいまいでも、重なりがあっても、実際に使えれば十分だという割り切りです。

自社版チェックリストへ育てるコツは次の3点です。

まず本記事の3分類を土台にする
過去に本番で出したバグを、3分類のどこに入るか振り分ける
案件特有の観点（決済・予約など）を列として追加する

この振り分け作業自体に大きな価値があります。「なぜこのバグを見落としたか」を分類名で言語化すると、同じ穴を次回は塞げるからです。個人の失敗談が、チーム共有の資産に変わります。

観点の洗い出しそのものを体系的に押さえたい方は、テスト観点の洗い出し手順を体系的に確認するもあわせてご覧ください。分類と洗い出しはセットで効きます。

分類1：画面・操作で起きるバグ

ユーザーが最初に触れるのは画面です。ここでのバグは「動くけれど気持ち悪い」ものが多く、放置すると信頼感をじわじわ削ります。表示崩れ、当たり判定、表記のばらつきの3系統に分けて見ていきます。

表示崩れ・はみ出し系

長い文字列や大きな画像が枠を突き破る、文字数ちょうどの最長データで表示がはみ出す、ダークモードで文字が背景と同化して読めない、といった症状です。デザインどおりの短い文言では起きないため、開発者の手元では再現しにくいのが特徴です。

スクロール中に読み込みが遅れ、表示が一瞬乱れるのも同じ系統です。高速回線の開発機では気づきにくく、低速回線で初めて表に出ます。

操作の当たり判定・多重送信系

ボタンの反応領域が小さすぎて押せない、あるいは大きすぎて隣を巻き込む。送信ボタンを連打してリクエストが重複し、二重登録が起きる、というのも定番です。

連打の問題は特に軽視されがちです。マウスでの手動テストでは無意識にゆっくり操作するため、まず再現しません。しかし本番のユーザーは、反応が遅いと感じれば迷わず連打します。その結果、同じ申込が二重に登録される、決済が二度走る、といった実害につながります。

UIの連打だけでは、競合バグを偽陰性で見逃します。回線を低速化して連打する、開発者ツールで同一リクエストを同時に発行する、といった負荷のかけ方も併用し、サーバ側で二重実行が弾かれるか（冪等キー・二重POST防止）まで確認します。

表記ゆれ・状態表示のばらつき系

同じ操作なのに画面ごとにラベルが違う、必須マークが付いているのに実は必須でない、といった不一致です。読点の有無やローディング表示の有無がそろっていないだけでも、ユーザーは不安になります。

こうしたばらつきは、画面ごとに担当者や実装時期が違うほど発生します。一枚ずつ見れば完成度が高くても、横に並べると統一感が崩れているのです。ユーザーは複数画面を行き来するため、この不統一に敏感に反応します。

実例	見落とす理由	確認方法
文字数ギリギリで表示がはみ出す	平均的な長さでしか試さない	有効な上限ちょうどの最長文字列で表示を目視
ボタンの当たり判定が小さい／大きい	マウスでは押せてしまう	スマホの指タップで反応領域の端を確認
ボタン連打で送信リクエストが重複する	手動テストでは連打しない	回線を絞って連打／同一リクエストを同時発行／サーバ側の二重POST防止を確認
スクロール時に読み込みが遅れ表示が乱れる	高速回線でしか確認しない	低速回線で読み込み途中の表示を確認
同機能でラベルが違う（ログイン／Sign in）	画面ごとに担当・時期が異なる	全画面の同一操作を横断で見比べる
読点の有無など文言表記が不統一	一画面ずつ作ると気づけない	同種の文言を全画面で並べて確認
ローディング表示の有無が画面でばらつく	画面単位で実装する	全画面で待機中の表示有無をそろえる
必須マークがあるのに必須でない	表示とバリデーションの担当が別	マーク付き項目を空で送信して挙動確認
ダークモードで文字が見えなくなる	標準テーマでしか確認しない	各テーマ・配色で全画面を目視

こうした表記や状態の不一致は、見た目だけの問題ではありません。吉井健文『フロントエンド開発テスト入門』では、要素が持つ「暗黙のロール」やアクセシブルネームの考え方が解説されています。同じ「ボタン」でも名前が違えば、支援技術やユーザーには別物として扱われるという視点です。

同じ機能なのにラベルが違うと、ユーザーは別機能だと誤解します。画面単位で作ると気づけないため、同じ操作を全画面で横断的に見比べる確認が有効です。

分類2：仕様と動きのズレで起きるバグ

見た目は正しくても、内部のロジックが仕様とズレているケースです。ここは動作確認が「正しい値」に偏るほど見落とします。画面のバグと違って目に見えないため、意識して条件を作らないと表に出てきません。入力値の境界、認証・検索のロジック、バリデーションの3系統で整理します。

入力値の境界・型のズレ系

最も温床になりやすい領域です。数値項目に小数や負数を入れられる、半角指定の欄に全角を入れると黙って消える、といった症状が典型です。過去日付で予約や送信ができてしまう、という日付の境界も同じ系統です。

認証・検索のロジック抜け系

過去日付で予約や送信ができてしまう、検索窓にスペースだけ入れると全件ヒットする、といったズレが見逃されがちです。

認証まわりでは、より深刻なズレも潜みます。たとえばパスワード再設定用のURLで、なぜか以前のアカウントにログインできてしまう。これは再設定リンクのトークンが使用後も失効しない、あるいは別ユーザーに紐づいてしまう、といった機序で起こります。確認方法としては、使用済みや期限切れの再設定リンクをもう一度使う、別アカウントで発行したリンクを使い回す、といった試し方が有効です。正規の手順しか試さないと永遠に気づけません。

バリデーションとエラー表示の欠落系

ユーザーを最も困らせる領域です。チェックボックス未チェックのまま次に進める、エラーは出るのにどの項目が誤りか分からない、というのは離脱の直接原因になります。

住所欄のハイフンの有無を許容していない、カンマと小数点を同じ扱いにしてしまう、指定外の拡張子のファイルを添付できてしまう、といった細かなズレも同じ系統です。開発者は「正しい形式」を知っているため、ユーザーが自由に入れる多様な表記を試しません。ここで弾かれると、ユーザーは何が悪いのか分からないまま離脱します。

実例	見落とす理由	確認方法
過去日付で予約・送信できる	未来日付だけで動作確認する	下限−1／下限／下限＋1と上限−1／上限／上限＋1の両側を試す
再設定URLで以前のアカウントにログインできる	正規の手順しか試さない	使用済み・期限切れの再設定リンクを再利用／別アカウント発行のリンクを使い回す
検索でスペースだけで全件ヒットする	有効なキーワードしか入れない	空・スペースのみ・記号のみで検索
「a」「A」「あ」が同じ件数でヒットする	正しいキーワードしか試さない	仕様で正規化ルールの要否を確定し、実装が一致するか確認
半角指定の欄に全角を入れられる／入れると消える	正しい形式しか入れない	全角・半角を相互に入れて保持を確認
数値欄に小数・負数を入れられる	正の整数しか想定していない	小数・マイナス・ゼロを入力
未チェックのまま次に進める	正しく操作すれば止まる	あえて必須を飛ばして進める
カンマと小数点を同じ扱いにする	「正しい数値」しか入れない	桁区切りカンマ・小数点を混在入力
エラー文で誤り箇所が分からない	開発者は原因を知っている	初見の視点でメッセージだけ読む
指定外の拡張子のファイルを挿入・添付できる	許可形式しかアップしない	許可外・偽装拡張子で添付を試す

検索まわりの表記ゆれは、即バグとは限らない点に注意が必要です。大文字小文字や全角半角、ひらがなとカタカナを区別すべきかどうかは仕様で決まります。まず仕様で正規化ルールの要否を確定し、その仕様に実装が一致しているかを確認する、という順序で見ます。「A」でも「a」でも「あ」でも同じ件数がヒットするのが正しいのか誤りなのかは、仕様との一致で判断します。

境界での取りこぼしは、技法として体系化されています。Copeland『ソフトウェアテスト技法』では「境界にはたくさんの欠陥が潜んでいる」と述べられ、境界値に注目したテストの重要性が示されています。上限・下限とそのすぐ隣の値を必ず確認する、という発想です。具体的には、下限−1／下限／下限＋1、上限−1／上限／上限＋1の両側を基本形として当てます。

境界値と異常入力は、最も見落としやすいバグの温床です。この領域を効率よく押さえるには、境界値のバグを効率的に見つける方法を読むが参考になります。あわせて、エラー表示の抜けを防ぐ設計手順を確認するで、誤り箇所が伝わる設計もチェックしておくと安心です。

分類3：環境依存で起きるバグ

自分の開発機では完璧なのに、ユーザーの環境では崩れる。これが環境依存のバグです。開発と同じ端末・ブラウザでしか確認しないと、まるごと抜け落ちます。画面サイズ、文字コード・入力デバイス、操作モデルの3系統で見ます。

環境依存が怖いのは、ユーザーごとに条件が違い、再現が難しい点です。「自分のPCでは出ない」という一言で調査が止まり、本番で放置されがちです。だからこそ、開発機と違う条件を意図的に作る観点が要ります。

画面サイズ・レイアウト崩れ系

スマホで一気に表面化します。PCでは整っていたヘッダーが、ログイン名が長いと崩れる。端末を回転させるとボタンが隠れる、ソフトキーボードが出ると入力欄が隠れる、といった症状です。端末のフォントサイズを大きくしていたり、ブラウザをズームしていたりするだけでも、レイアウトはずれます。

文字コード・入力デバイス依存系

絵文字や環境依存文字で文字化けする、スマホで添付したファイル名が文字化けする、数値入力欄なのに日本語キーボードが立ち上がる、などが挙げられます。

見落とされやすい理由は明快です。使用済みメールアドレスで再登録するとエラーになる、といった挙動は、正しい値だけを入れていれば一度も踏みません。文字化けに至っては、テストデータに絵文字や機種依存文字を入れる習慣がなければ、そもそも発生の機会がありません。

操作モデルの差異系

PCとスマホの「触り方」の違いから生まれます。ホバー前提のUIがタップでは機能しない、スワイプで前画面に戻ると入力内容が消える、都道府県選択のポップアップが出ない、といったズレです。これらはPCのブラウザでは絶対に再現せず、実機を触って初めて分かります。

実例	見落とす理由	確認方法
PCでは正常だがスマホで崩れる	開発機はPCが中心	実機スマホで主要画面を確認
ログイン名が長いとヘッダーが崩れる	短い名前で確認する	長い名前・長いメールで表示確認
絵文字・環境依存文字で文字化けする	半角英数しか入れない	絵文字・機種依存文字を入力
使用済みメールで再登録するとエラー	新規メールしか使わない	登録済みメールで再登録を試す
スマホとPCでタップ・ホバー操作差	PCのマウス操作で確認する	実機のタップ操作で再現
数値入力欄なのに日本語キーボードが出る	入力できれば良しとする	実機で入力欄ごとのキーボード種別を確認
スワイプで戻ると入力が消える／エラー	ブラウザの戻る操作を試さない	入力途中でスワイプ・戻る操作
端末回転でヘッダー・ボタンが隠れる	縦画面でしか見ない	縦横を切り替えて操作確認
都道府県選択のポップアップが出ない	開発機では表示される	実機の各OS・ブラウザで選択操作
スマホで添付ファイル名が文字化けする	PCでしか添付を試さない	実機から日本語名ファイルを添付
ソフトキーボードで入力欄が隠れる	物理キーボードで確認する	実機でキーボード表示中の入力欄を確認

こうした差異を毎回すべて手で追うのは大変です。吉井健文『フロントエンド開発テスト入門』では、レスポンシブレイアウトの崩れを画像比較で検知するビジュアルリグレッションテストが紹介されています。複数の画面幅でスクリーンショットを比べ、意図しない見た目の変化を機械的に拾う考え方です。

PCで正常でも、スマホでは崩れるのが前提です。実機での確認は欠かせません。スマホ特有の不具合をどう検証するかは、スマホ端末特有の不具合検証の進め方を見るで具体的に解説しています。

見落としやすいバグを減らすリリース前チェックの流れ

観点リストは、作るだけでは効果が出ません。限られた時間で回す「順番」と「進め方」があってこそ機能します。ここでは、リリース前に抜け漏れを拾うための流れを整理します。

拡充した30の観点をすべて一巡するのは、現実には難しいものです。時間がなければ、本番での被害が大きく、かつやらかしやすい観点から先に当てます。

時間がなければ、まずここから当てる優先観点

決済・申込の二重送信（連打での重複実行）
過去日付での予約・送信
スマホでの表示崩れ・操作不能
エラー箇所が分からない表示
認証・パスワード再設定まわりの穴
数値欄の小数・負数・境界値
使用済みメールでの再登録

全量は資産として持ちつつ、初手はこの5〜8個に絞る。これが現実的な入口です。

そのうえで、余力に応じて回す順番を広げます。影響の大きい経路から先に押さえるのが原則です。

主要な業務フロー（登録・決済・予約など）を正常系で一巡する
各画面で3分類の観点を当てる（画面→仕様→環境の順）
発生時の被害が大きいものから優先的に深掘りする

次に、決めた観点を持ったうえで自由に触る進め方です。高橋寿一『知識ゼロから学ぶソフトウェアテスト』では、テストしながら次に試すことを考える探索的テストが取り上げられています。探索的テストは、実行しながら学び、その結果で次のテストをその場で設計する、設計と学習を同時に進める手法です。

探索的テストは、行き当たりばったりとは違います。「入力の境界を攻める」「この画面で表記ゆれを探す」といった目的を短く決め、その範囲を集中的に触ります。3分類は、この「今どの目的で見ているか」を見失わないための道しるべになります。

観点を持って一巡するだけでも、抜け漏れは大きく減ります。ただ闇雲に触るのではなく、3分類という地図を手に歩くのがポイントです。限られた時間でも、地図があれば同じ場所を二度歩く無駄が減ります。

最後に、見つけた見落としを次回に活かす記録です。バグを直して終わりにせず、「どの観点で見つかったか」を残します。それが自社版チェックリストの新しい1行になります。

記録は難しく考える必要はありません。バグ票に3分類のタグを1つ付けるだけで十分です。案件をまたいだ横断集計は任意で、余力があれば苦手な分類を数字で把握する程度でかまいません。苦手な分類に次回はより多くの時間を割く、という判断につながります。

用語や技法の共通言語をそろえたいときは、JSTQB（ソフトウェアテスト技術者資格認定）が公開する用語集などが参考になります。チーム内で言葉の定義を合わせておくと、指摘のやりとりがスムーズになります。

参考: JSTQB（ソフトウェアテスト技術者資格認定）

兼任体制の限界と、抜け漏れを構造で防ぐ選択肢

ここまで観点リストと確認手順を紹介してきました。ただ、正直に言えば、リストを持っていても埋まらない問題があります。それは「時間」です。

兼任体制では、開発の締め切りが迫るほどテストの時間が最初に削られます。観点があっても、それを一巡する時間そのものが確保できません。ここが構造的な弱点です。

もうひとつが「視点の固定」です。作った本人は、どうしても自分の想定した道を通ってしまいます。ある現場の振り返りでは、テスト担当がアプリの全体像を早い段階で把握できていれば、無駄な操作が減りトータルの作業時間が短縮できた、という教訓が共有されていました。第三者の目が入ると、正しい使い方の外側にある経路に気づきやすくなります。

同じ振り返りでは、一見遠回りに見える「全体像の把握」に最初に時間を投じたほうが、結果的にトータルの作業時間は短くなる、とも指摘されていました。個々の操作を速くこなすより、何をどの順で確認すべきかを整理するほうが効くという教訓です。これは兼任・外注を問わず、テストという作業に共通する性質だと言えます。

第三者の目は、作り手が通らない道を通るからこそ見落としを減らします。これは能力の差ではなく、立場の差から生まれる効果です。

もちろん、第三者に任せれば自動的に品質が上がるわけではありません。前述の振り返りでも、アプリの全体像を把握しないまま作業を始めると精度が下がる、と釘を刺されていました。観点リストや仕様の共有をセットで渡してこそ、第三者の目は活きます。本記事の3分類は、そのまま共有資料としても使えます。

体制を強化するかどうかは、費用対効果で考えるのが現実的です。専任を採用するほどの規模でなくても、繁忙期だけ第三者の目を借りる、といった選択肢もあります。判断軸を整理すると次のようになります。

判断軸	兼任のまま続ける	第三者の目を入れる
リリース前の時間確保	開発を優先すると削られる	テスト工数を独立して確保
見落としの傾向	作り手の視点に偏る	想定外の経路を通れる
本番バグの手戻り	発生時の対応で疲弊	事前検出でリスクを圧縮
コスト感	手戻り工数×単価が積み上がる	外注費はかかるが手戻りを圧縮