バグ・不具合・エラーの違いとは？発注者が知るべき判断軸

「バグが見つかりました」「不具合報告です」「想定外のエラーが発生しました」――開発会社からこうした連絡が次々と入ってくると、似ているようで微妙にニュアンスが違う言葉に戸惑った経験はないでしょうか。

発注者の立場では、これらの言葉が出てきた瞬間に判断しなければならないことが山積みです。社内エスカレーションは必要か。経営層への第一報はどう書くか。本番リリースは止めるべきか。追加費用は誰が負担するのか。「とりあえず直してください」と返した数日後に「これは仕様変更扱いです」と追加見積もりを提示され、社内で板挟みになる――そんな経験を一度でもされた方は少なくないはずです。

用語の輪郭が曖昧なままでは、ベンダーとの会話に共通言語がなく、議論が噛み合わなくなります。さらに厄介なのは、「バグ＝開発会社が無償で直すもの」という思い込みが、実は契約形態や種類によっては成り立たないという事実です。仕様の伝達不足が原因の「仕様バグ」では、発注者側にも応分の責任が生じる可能性があります。

本記事では、バグ・不具合・エラーの違いを発注者目線で整理し、報告を受けたときに使える判断軸を提供します。用語整理から始めて、バグの種類分類、深刻度を見極める3つの軸、報告を受けた直後に確認すべき5項目、そして契約不適合責任の基本までを順に解説します。読み終える頃には、次にベンダーから「バグが出ました」と連絡が来たとき、何を確認すれば社内判断・契約交渉に進めるかが見えているはずです。

なお、本記事は「報告を受けた後の事後対応」に焦点を当てます。「そもそもバグを減らすにはどうするか」という事前防止の議論は、テスト自動化のコスト効果と導入判断で別途整理していますので、興味があれば合わせてご確認ください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

バグ・不具合・エラーの違いを発注者目線で整理する

最初に、3つの用語の関係を発注者目線で整理します。エンジニアの間でも使い分けは流派が分かれますが、ベンダーからの報告を読み解くうえでは「原因→結果→事象」という階層関係を押さえると混乱が減ります。

エラー・バグ・不具合の関係（原因→結果→事象）

国際的に広く参照される IEEE のソフトウェア用語標準（IEEE Std 610.12-1990）では、3つの用語はそれぞれ次のように整理されています。

• エラー（error）: 人間の判断ミスや認識違いそのもの。要件の読み違い、コーディング上の勘違いなど「原因」にあたる
• バグ（bug）／欠陥（defect / fault）: エラーの結果としてプログラム内に作り込まれた「欠陥」。ソースコード・設定・データ構造のどこかに残った具体的な誤り
• 不具合・故障（failure）: バグが実行時に表面化し、システムが想定どおりに動かない「事象」

つまり、エラー（人の判断ミス）→ バグ（プログラム上の欠陥）→ 不具合（外から見える事象）という流れになります。

発注者として知っておきたいのは、ベンダーが「エラーが出ました」と言うとき、それが画面上のエラーメッセージを指しているのか、設計上の判断ミスを指しているのかで意味がまったく異なる点です。日本語の業務会話では「エラー」が「画面に出た赤いメッセージ」を指すことが多いため、IEEE の定義とずれます。報告を受けたときに「いまの『エラー』はどの意味でしょうか」と一言確認するだけで、認識のずれを早期に防げます。

「障害」「故障」など隣接用語との関係

実務では「障害」「故障」「インシデント」といった用語も飛び交います。発注者として最低限押さえておきたい関係は次の通りです。

「不具合」は事象を広くカバーする総称、「障害」はその中でも本番サービスに影響している状態、と覚えると整理がつきます。ベンダーが「障害です」と言ってきた場合は、本番ユーザーに影響が出ている前提で動く必要があります。

発注者がベンダー報告で注目すべき言葉の使い分け

報告メールやSlackでベンダーが使う言葉の傾向には、ある程度のパターンがあります。

• 「バグが見つかりました」: 開発・テスト段階で発見された欠陥。本番影響はまだない可能性が高い
• 「不具合報告です」: 事象として動かない状態が確認された。本番か検証環境かを要確認
• 「障害が発生しています」: 本番サービスに影響が出ている。緊急対応モード
• 「想定外のエラーで…」: 例外処理されていない事象。深刻度は中身次第

ベンダーがどの言葉を選んだかから、本番影響の有無や対応緊急度をある程度推測できます。あくまで推測なので、後述するチェックリストで裏取りすることをおすすめします。

バグの種類と発注者にとっての意味

「バグが見つかりました」と一言で言われても、その中身によって責任の所在も対応方針もまったく違ってきます。発注者として最低限切り分けておきたい種類を整理します。

仕様バグ（要件定義・仕様確定段階の問題）

仕様バグは、コード自体は仕様書どおりに正しく書かれているが、その仕様書自体が誤っていた、もしくは曖昧だった、というケースです。例として次のような状況が該当します。

• 受入テストで「数量0の場合は注文できない」と要求したが、仕様書には書かれていなかった
• 「翌営業日扱い」の定義が発注者・ベンダー間で食い違っていた
• 例外パターン（休日、月跨ぎ等）の取り扱いを要件定義で詰めていなかった

仕様バグは、要件定義の精度や発注者・ベンダー間のコミュニケーション品質が原因です。契約形態にもよりますが、純粋な仕様バグの場合は仕様変更扱い・追加見積もりとなることもあり、発注者側にもコスト負担が発生し得ます。

実装バグ（コーディング段階の問題）

実装バグは、仕様書は正しいが、コード上の記述ミスで仕様どおりに動かないケースです。

• 計算式の符号を逆にしている
• ループの終了条件を間違えている
• nullチェックを忘れていて特定条件で落ちる

実装バグは原則としてベンダー側の責任範囲です。請負契約であれば、保証期間内は無償で補修されるのが通常です。

環境バグ・潜在バグ・性能バグ・セキュリティバグ

そのほかにも次のような分類が登場します。発注者として最低限「種類によって性質が違う」ことを認識しておくと、ベンダーとの会話で齟齬を減らせます。

• 環境バグ: 開発環境では動くが本番環境では動かないなど、インフラ・設定差分に起因する欠陥
• 潜在バグ: ある特定の条件下でしか発現しないため、通常テストでは見つかりにくい欠陥
• 性能バグ: 機能としては動くが、応答時間・スループットが要件を満たしていない欠陥
• セキュリティバグ: 脆弱性として情報漏洩・不正アクセスを許す可能性のある欠陥。深刻度はほぼ常に「致命的」寄り

セキュリティバグについては、情報漏洩リスクが現実化した場合に契約上の損害賠償・通報義務・行政報告など別レイヤーの対応が必要になります。発見の連絡を受けた時点で、技術的な修正だけでなく法務・広報を含めた対応体制に切り替える判断が必要です。

種類によって責任の所在はどう変わるか（早見表）

「バグ＝必ずベンダー責任」ではないことを早見表でまとめます。あくまで一般論であり、最終的には契約書の文言・要件定義書の合意範囲で判断する必要があります。

ここで重要なのは、「仕様バグ」と「実装バグ」の切り分けが責任議論の土台になる点です。ベンダーから「これは仕様変更扱いです」と言われたとき、「仕様書のどの箇所に何が書かれていて、要件定義の議事録にどう残っているか」を冷静に突き合わせる作業が、発注者の最初の仕事になります。

バグの深刻度を判断する3つの軸

種類が切り分けられたら、次に判断したいのは「どれくらい急いで対応すべきか」です。経営層から「いま動かしているサービスは大丈夫なのか」と聞かれたとき、明確に答えられる軸を持っておきましょう。

深刻度はおおむね次の3軸で判断できます。Sky Tech Blog をはじめ多くの開発現場で採用されている考え方です（不具合の重大度の定義について（Sky Tech Blog） などを参照）。

1. 影響の大きさ: 業務全体が止まるのか、一部機能だけか、見た目の問題か
2. 再現性: 100%再現するのか、特定条件のみか、ごくまれにしか起きないか
3. 回避手段の有無: 暫定的に運用で回避できるか、代替手段がまったくないか

これらを組み合わせて、社内では「致命的／重大／軽微」の3段階で整理すると経営層への説明もスムーズです。

発注者として注意したいのは、「再現性が低い＝深刻度が低い」とは限らない点です。たとえば「100回に1回しか起きないが、起きると決済データが消える」というバグは、再現性が低くても致命的に分類すべきです。再現性は「対応の難しさ」を示す指標であって、「影響の大きさ」を直接示す指標ではありません。

経営層への第一報では、「深刻度：重大／影響：受注画面の特定条件で送信失敗／再現性：特定ブラウザ・特定金額帯／回避手段：別経路で受注対応中」のように、3軸を分けて整理して伝えると、過剰な不安を煽らずに状況を正確に共有できます。

バグ報告を受けたときに発注者が確認すべき5つのこと

ここからは、実際に「バグが見つかりました」と連絡を受けた瞬間に何を確認すべきかをチェックリスト形式で整理します。本文中でも触れた通り、報告を受けた直後の確認の質が、その後の意思決定・契約交渉・社内エスカレーションの精度を大きく左右します。

なお、本番リリース後にバグ報告が立て続けに発生した場合のトリアージ・連絡体制の組み立て方は、リリース後バグ多発の対応フローで別途整理しています。本記事のチェックリストと合わせて参照すると、報告対応から体制設計までを一貫して進められます。

確認チェックリスト

各項目について、ベンダーへの確認文の例を添えます。

1. 発生条件・再現性

「再現手順を教えてください。100%再現しますか、それとも特定条件のみでしょうか。発見されたのは本番か、検証環境か、開発環境か」

2. 影響範囲

「影響を受けるユーザーは何名規模ですか。影響を受ける業務領域（受注・在庫・会計など）はどこですか。データ破損は発生していますか」

3. 回避策の有無

「現時点で暫定的に運用で回避する手段はありますか。回避するとして、業務効率や精度にどの程度影響しますか」

4. 本番影響

「本番環境で起きていますか。すでに何件の業務が影響を受けていますか。データの巻き戻し・補正は必要ですか」

5. 契約上の保証期間

「契約書上、本件の修正対応は保証期間内ですか。仕様変更ではなく契約不適合（旧瑕疵）として扱える事案ですか」

5番目は契約書の確認が必要です。請負契約の場合、検収後一定期間（一般的に半年〜1年）は無償補修の対象となるケースが多くあります。詳細は次のセクションで解説します。

バグの責任範囲は保証期間・契約形態で変わる

発注者がもっとも気にする「これはうちが追加費用を払うべきか、それともベンダーが無償で直すべきか」という問いに、明確な答えを出すには契約形態と契約不適合責任の基本を知る必要があります。

契約形態（請負／準委任）で責任の重さが変わる

システム開発で使われる主な契約形態は次の2つです。

• 請負契約: 仕事の完成（=合意した仕様どおりの成果物を納品すること）を約束する契約。完成責任があり、契約不適合があれば修補・損害賠償・代金減額の対象となる
• 準委任契約: 業務の遂行を約束する契約。完成責任はなく、善管注意義務に基づく業務遂行が約束される

請負契約のほうが受託側の責任は重く、「合意した仕様どおりに動かない」状態は契約不適合として扱われます。一方、準委任契約は時間・労力をベースに業務を提供する性質のため、「動かない＝必ず無償補修」とはなりません。

ベンダーから「バグです」と連絡を受けたとき、まずは契約書を開いて「請負か準委任か」「成果物の定義は何か」を確認するのが出発点になります。

契約不適合責任の基本（バグ＝必ず瑕疵ではない）

2020年の民法改正により、従来「瑕疵担保責任」と呼ばれていた制度は「契約不適合責任」に再構成されました。請負契約において、引き渡された目的物が「契約の内容に適合しない」場合、注文者（発注者）は履行追完請求（修補請求）・代金減額請求・損害賠償請求・契約解除といった対応を取れます。

ここで重要なのは、「バグがあること」がそのまま「契約不適合」になるわけではないという点です。プログラムには一定の不具合が含まれることが避けがたく、実務上もリリース時点でゼロバグを保証することは現実的でないと考えられています。

この点について、ソフトウェア開発紛争で繰り返し引用される裁判例として、東京地裁平成9年2月18日判決があります。同判決は、システムに大小60項目を超える不具合があると主張した発注者と、補修対応を続けたベンダーとの紛争を扱ったものです。判決内容を発注者目線で要約すると、おおむね次の3点に整理できます（プログラムのバグの法的扱い（東京地判平9.2.18）（法とITの話）、システム開発上のバグ・不具合と請負人の瑕疵担保責任（ひびき法律事務所） 参照）。

• プログラムにバグが存在すること自体は避けがたく、バグの存在のみをもって直ちに瑕疵（契約不適合）にあたるとは判断されない
• バグがシステムの機能に軽微とは言えない支障を生じさせ、かつ遅滞なく補修されない・代替措置も講じられない場合は瑕疵にあたる
• バグの数が著しく多く、しかも順次発現してシステムの稼働に支障を及ぼす場合も瑕疵にあたる

※上記は判決原文の逐語引用ではなく、発注者の判断軸として再構成した著者要約です。原文の文言・厳密な射程は、リンク先の解説および判決原本でご確認ください。

実務的に発注者の判断軸に翻訳すると次のようになります。

つまり、バグの存在そのものではなく、「補修されないまま放置されたか」「業務にどの程度の支障が出ているか」が法的な判定軸になります。発注者として「バグがあるから即座に契約解除」「全額返還を要求」と感情的に動くと、かえって不利な交渉になる可能性があるため注意が必要です。

契約不適合責任の制度趣旨・通知期間・損害賠償の範囲などの基礎知識をより詳しく押さえたい場合は、瑕疵担保責任・契約不適合責任とは｜システム開発での違いと発注者の対処法で発注者向けに整理しています。本記事の責任切り分けの議論と合わせてご確認ください。

保証期間内・期間外でどう変わるか

契約不適合責任を追及できる期間（保証期間・通知期間）は、契約書の規定によります。一般的なシステム開発契約では、検収完了後6ヶ月〜1年を「契約不適合の通知期間」として定めるケースが多く見られます。

実務的には、保証期間が切れる前に「保守運用契約」を結んでおくのが一般的です。保守契約に「軽微なバグ修正は月額の保守費用内」と明記されていれば、保証期間後も比較的スムーズに対応できます。逆に、保守契約なしで保証期間を過ぎたシステムは、たとえ実装バグであっても都度見積もりの追加費用対応となる可能性が高くなります。

なお、契約不適合責任についてはアイシア法律事務所の解説記事 など、法律事務所による発注者向け解説も公開されています。重大な案件の場合は専門家への相談を併せておすすめします。

発注者がやってはいけないバグ報告への対応

最後に、発注者が報告を受けたときにやりがちで、結果的に時間・コスト・関係性に悪影響を及ぼす失敗パターンを4つ挙げます。

パターン1: 用語の不一致のまま議論を進める

「バグです」「いえ、これは仕様です」――この応酬を、双方が同じ言葉の意味で使っているか確認せずに続けると、議論はかみ合わないまま時間だけが過ぎていきます。

対策として、報告を受けた最初の段階で「いまの『バグ』は実装バグですか、それとも仕様バグですか」「『仕様』というのは要件定義書のどの箇所に書かれていますか」と確認するクセを付けましょう。記事冒頭で触れた「原因→結果→事象」の階層を共通言語にすると、ベンダーとも会話の精度が上がります。

パターン2: 「とにかく直して」と丸投げする

スピード重視で「とにかく直してください」と返してしまうと、後から「これは仕様変更扱いなので追加費用です」と提示されたときに反論材料がなくなります。

対策は、修正依頼を出す前に「これは契約不適合扱いとしての修補依頼か、それとも仕様変更扱いとしての追加発注か」を口頭でも文面でも確認することです。たった一文の確認で、後の追加費用トラブルを大幅に減らせます。

パターン3: 再現条件・影響範囲を確認せず社内エスカレーション

経営層に「本番でバグが出ました」とだけ伝えると、過剰な対応を求められたり、逆に「軽微なのに大騒ぎした」と評価されたりします。

対策として、前述の5項目チェックリスト（発生条件・影響範囲・回避策・本番影響・保証期間）を最低限埋めてから報告するルールを自分の中で持ちましょう。経営層への第一報は「深刻度：重大／影響範囲：限定的／回避策あり／契約不適合該当の見込み」のように、判断材料をセットにして伝えるのが基本です。

パターン4: 保証期間・契約形態を確認せず追加費用を即承諾

ベンダーから「修正には追加費用が発生します」と言われたとき、契約書を開かずに承諾してしまうケースです。後から「これは契約不適合だったので無償補修の対象だった」と気付いても、一度承諾した案件を巻き戻すのは難しくなります。

対策は、追加費用が提示された時点で必ず「契約書の保証期間条項」「該当事象が契約不適合に該当しないと判断した根拠」をベンダーに文書で確認することです。即答せず、社内で契約書を確認する時間を確保しましょう。

まとめ｜バグ報告を受けたときの判断フレーム

ここまでの内容を、発注者が実際に使える判断フレームとして1つにまとめます。次にベンダーから「バグです」「不具合です」と連絡が来たとき、以下の順序で確認すれば、社内判断・契約交渉に必要な情報がそろいます。

このフレームの肝は、「バグ＝即・ベンダー責任」と短絡せず、種類と契約条件を冷静に切り分けることです。仕様バグは要件定義の責任分担、実装バグは契約不適合責任、性能バグは非機能要件の合意範囲――それぞれ判断軸が異なります。

発注者の役割は、ベンダーを追及することでも丸投げすることでもなく、契約と事実に基づいて適切な対応を引き出すことです。そのためには、報告を受けた瞬間に感情で動かず、本記事のフレームに沿って一つひとつ確認していく姿勢が、結果としてプロジェクト全体の品質と信頼関係を守ります。

なお、本番リリース後のバグ対応の体制設計（オンコール・SLA・連絡フロー等）について深掘りしたい場合はリリース後バグ多発の対応フローを、契約不適合責任の制度的な背景を整理したい場合は瑕疵担保責任・契約不適合責任とは｜システム開発での違いと発注者の対処法を、それぞれ合わせてご確認ください。社内のフロー設計を進める際には、法務・情シス・事業部門で連携して整備を進めることをおすすめします。

次にベンダーから「バグが出ました」と連絡が来たとき、本記事のフレームを思い出し、まずは冷静に「いまの『バグ』はどのレイヤーの話ですか」と一言確認するところから始めてみてください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。