Q. 検収で見つかった不具合は「バグ」か「仕様変更」か？開発会社と意見が分かれたときの判断と話し合い方

2026年6月13日2026年10月4日

受け入れテスト（検収）で気になる動きを見つけて報告したら、開発会社から「それは仕様どおりです。直すなら仕様変更として別途お見積もりします」と返ってきた。こちらは「不具合なのだから無償で直してもらえるはず」と思っている。検収の場面で、バグか仕様変更かの意見が分かれるのはよくあることです。

「検収で見つかった不具合を報告したら、開発会社に『仕様変更です』と言われた。バグじゃないの？どっちが正しいのか判断できない…」

先に結論をお伝えします。バグか仕様変更かは「どちらの感覚が正しいか」ではなく、「双方が合意した資料と比べて、完成物がずれているか」で判断します。合意した資料どおりに動いていないならバグ（契約との不一致）、資料どおりに動いているが業務に合わないなら仕様変更、資料に書かれていないならグレーです。そしてグレーの部分は、白黒をつけるより「今回どう直すか・費用をどう分けるか・次からどう書くか」を話し合って決めるほうが、結果的に早く解決します。

この記事では、検収中にバグか仕様変更かで意見が分かれたときの判断方法、よくあるグレーゾーン、判断表、揉めずに話し合うコツ、合意の残し方、次の案件での防ぎ方を解説します。

短い回答：物差しは「合意した資料との照合」

まず、検収で見つかった事象を次の3つに分けて考えます。

状態	判断の目安	基本の扱い
合意した資料と違う動きをする	バグ（契約との不一致）に近い	開発会社に修正を求める
資料どおりに動くが、業務に合わない	仕様変更に近い	費用・納期を確認して入れるか判断する
資料に書かれていない・どちらにも読める	グレー	事実を並べて協議し、落としどころを決める

ここでいう「合意した資料」とは、契約書だけではありません。要件定義書（＝作るものを文章で決めた資料）、設計書、承認した画面イメージ、打ち合わせの議事録、メールでのやり取りなど、双方が確認・承認したものすべてが判断材料になります。

注意したいのは、発注者の「こう動くのが普通だと思っていた」という感覚だけでは、バグの根拠としては弱いということです。逆に開発会社の「書いていないので仕様外です」も、書かれた内容を実現するのに当然必要な動きであれば、通りにくいことがあります。どちらも、資料を前に置いて話すのが出発点です。

背景：なぜ検収で「バグか仕様か」が揉めるのか

検収は「契約どおりか」を確かめる場だから

検収（＝納品物が契約どおりかを確認して受け取ること）で見るのは、あくまで「約束したものができているか」です。公的なひな型で、その考え方を確認しておきましょう。

📰 出典：IPA（情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」

IPAが公開しているモデル契約書（受託開発用）のひな型では、発注者は検査仕様書（＝何をどうテストすれば合格かを決めた資料）に基づいて、ソフトウェアがシステム仕様書と合っているかを点検します。検査に合格しない場合は、不合格の具体的な理由を書面で伝えて修正を求め、その理由が認められるときは、開発会社が協議のうえ定めた期限内に無償で修正する、という流れが示されています。

つまり、無償修正の対象になるかどうかの基準は「システム仕様書と合っているか」です。仕様書に書かれていないことは、この物差しでは測れません。ここにグレーが生まれます。

発注者は「業務」、開発会社は「仕様書」で見ている

検収をする発注者の担当者は、実際の業務を思い浮かべながら操作します。そのため「この操作で止まるのは困る」「この表示では現場が迷う」と感じたものを、すべて不具合として報告しがちです。

一方、開発会社は仕様書と設計書を基準にテストをしています。仕様書どおりに動いているなら、開発会社にとっては「正しく作れている」状態です。どちらも自分の立場で誠実に見ているからこそ、評価がずれるのです。

契約不適合と「発注者の指示」の関係

検収後に見つかった不具合は、一般に契約不適合責任（＝納品物が契約の内容に合っていないときに、開発会社が修正などの責任を負うこと）の問題になります。IPAのモデル契約書のひな型では、検収後にシステム仕様書との不一致（バグも含む）が見つかった場合、発注者は修正などを求めることができるとされています。

ただし同じひな型では、発注者が提供した資料や発注者の指示が原因で生じた不適合には、原則としてこの責任が及ばないとも定めています（開発会社がその指示が不適当だと知りながら伝えなかった場合を除く）。「発注者が指定したとおりに作ったら業務に合わなかった」ケースは、バグではなく仕様変更として扱われやすいということです。

実際の責任の範囲や期間は、個別の契約書によって異なります。金額が大きい場合や判断に迷う場合は、契約書を手元に置いたうえで弁護士などの専門家に相談してください。

検収でよくあるグレーゾーン5つ

資料に書かれていないことほど、意見が分かれます。検収で特に揉めやすいのは次のようなケースです。

1. 例外処理（書かれていないケースの動き）

「入力を途中でやめたら」「同じボタンを2回押したら」「取引先コードが存在しなかったら」など、通常の流れ以外の動きです。仕様書に書かれていないことが多く、発注者は「当然エラーを出してくれると思った」、開発会社は「想定外の操作」と考えがちです。

判断のヒントは、その例外が業務上どのくらい起きるかと、起きたときの影響の大きさです。データが壊れる・二重登録されるなど業務に実害があるものは、書かれていなくても「当然備えるべき品質」として修正を相談しやすい部分です。

2. 画面の見た目・使い勝手

文字の大きさ、ボタンの位置、並び順、色などです。承認した画面イメージがあれば、それと比べれば判断できます。画面イメージどおりなら、「使いにくい」は基本的に仕様変更の扱いになります。

画面イメージと実物で差がある場合も、「画面イメージは参考図」という扱いだったかどうかで話が変わります。どの資料が「正」なのかを最初に確認しましょう。

3. 性能（速さ・同時に使える人数）

「検索に10秒かかる」「月末に全員が使うと重い」といった問題です。性能は非機能要件（＝機能そのものではなく、速さ・安定性・セキュリティなどの品質の条件）と呼ばれ、数値で決めていない案件が少なくありません。

📰 出典：IPA（情報処理推進機構）「非機能要求グレード」紹介ページ

IPAの「非機能要求グレード」は、発注者と開発者の認識の行き違いを防ぐ目的で、非機能要求の項目を一覧にし、要求レベルを段階的に示したものです。こうした基準で数値を決めていなかった場合、「遅い」は主観の話になりやすく、グレーとして協議することになります。

4. 他システムとの連携

会計ソフトや既存の顧客管理システムなどとの連携で起きる問題です。「連携先の仕様書どおりに作ったが、実際の連携先の動きが違った」「連携先のデータに想定外の値が入っていた」など、原因が開発会社の成果物の外にあることもあります。

連携先の情報を誰が提供したのか、見積もりの前提条件に連携先の動きがどう書かれていたかが判断材料になります。

5. データの中身・テスト環境の違い

テスト用のデータでは動いたのに、本番に近いデータでは動かない、というケースです。データの件数や形式が見積もりの前提と違っていたのか、開発会社の作りが甘かったのかで扱いが変わります。

「バグか仕様変更か」の判断表

グレーゾーンも含めて、判断の目安を1つの表にまとめます。あくまで一般的な目安で、最終的には個別の契約と資料の内容で決まります。

状況	バグに近い	仕様変更に近い	グレー（協議）
仕様書・設計書との関係	書かれた動きと違う	書かれたとおりに動く	書かれていない／どちらにも読める
画面	承認した画面イメージと違う	画面イメージどおりだが使いにくい	画面イメージが「参考」扱いだった
例外処理	データが壊れる・止まるなど明らかな欠陥	発注者が新たにルールを追加したい	エラー表示の内容・出し方の好み
性能	合意した数値を満たさない	合意後に利用人数・件数を増やした	数値を決めていなかった
他システム連携	合意した連携仕様どおりに動かない	連携先・連携項目を後から追加した	連携先の実際の動きが資料と違った
原因	開発会社の作りの誤り	発注者の指示・提供資料どおりに作った	双方の確認不足

表で仕分けると、1件の「不具合」の中に、バグの部分と仕様変更の部分が混ざっていることにも気づきます。機能や画面の単位に分けて1つずつ判断すると、話し合いがかみ合いやすくなります。

揉めずに話し合うための具体的な対処4つ

対処1：事実を1枚の表にまとめる

最初に、意見が分かれている事象を1件ずつ表にします。感情や評価ではなく、事実だけを並べるのがポイントです。

事象（何をしたら、何が起きたか）
期待していた動きと、その根拠（どの資料の何ページ、どの日の議事録か）
開発会社の見解と、その根拠
業務への影響（業務が止まる／回避策がある／見た目だけ）

根拠の欄が空いている項目は、発注者側の「つもり」だった可能性があります。逆に開発会社の根拠が空いていれば、そこは確認を求めてよい部分です。

「『どの資料のどこに書いてあるか』で話してもらえると、私たちも社内で確認しやすくなります。『普通はこうでしょう』だけだと、どう判断していいか迷ってしまうんです」

対処2：「第三者の目」を入れる

当事者どうしだと、どうしても自分に有利な読み方をしてしまいます。次のような人に、資料を見てもらうのも一つの方法です。

社内でその案件に直接関わっていない人（別部署の管理職など）
開発会社側のプロジェクト責任者（現場担当者より一段上の人）
契約やITに詳しい外部の専門家

「この資料を初めて読んだ人なら、どちらの意味に取るか」という視点で考えると、どちらの読み方に無理があるかが見えやすくなります。

対処3：白黒ではなく「落としどころ」を選択肢で出す

グレーの部分は、どちらかが100%正しいと言い切れないことがほとんどです。二択にせず、次のような妥協案を並べて話し合います。

妥協案	向いている場面
今回は開発会社が修正し、次回から仕様書に明記する	修正が小さく、業務への影響が大きい
修正費用を双方で按分する	双方に確認不足があった
簡易な対応（回避策・注意書き・運用ルール）で済ませる	発生頻度が低い、費用に見合わない
リリース後の改修に回す	今すぐでなくても業務が回る
仕様変更として正式に見積もる	明らかに新しい要望が含まれている

IPAのモデル契約書のひな型でも、紛争が起きたときは、裁判などの手続きの前に、まず当事者の協議の場（連絡協議会）で十分に話し合い、それでもまとまらなければ代表者どうしの協議で解決を図る、という段階的な流れが示されています。話し合いで決めることが、最初の選択肢だということです。

対処4：合意した内容を書面に残す

結論が出たら、必ず書面に残します。IPAのモデル契約書のひな型では、仕様の変更は「変更管理書」に変更の理由・詳細・費用・スケジュールなどを書き、双方の責任者が承認して確定させる流れになっています。小さな案件でも、次の項目をメールや記録票で残しておくと安心です。

【検収時の判断記録】
・管理番号／事象の内容：
・判断結果：バグとして修正／仕様変更／グレー（協議のうえ決定）
・根拠とした資料：（資料名・ページ・日付）
・対応内容：（修正・簡易対応・次回改修など）
・費用：無償／有償（金額）／按分（割合）
・対応期限と再テストの範囲：
・次回以降の扱い：（仕様書への追記など）
・確認者：発注者側 ○○／開発会社側 ○○（日付）

この記録は、検収後に同じような事象が見つかったときの判断の基準にもなります。

話し合いで注意したいこと

検査期間を過ぎないようにする：協議中でも、検査期間内に不合格の理由を書面で伝えておくことが大切です。モデル契約書のひな型では、期間内に書面で異議を述べないと合格とみなされる定めがあります。自社の契約の定めを確認しましょう
「全部バグ」「全部仕様」で押し通さない：1件ずつ仕分けたほうが、結果的に発注者の主張も通りやすくなります
支払いの保留を交渉材料にしない：関係がこじれ、修正作業そのものが止まることがあります。支払い条件は契約に沿って扱い、判断に迷えば専門家に相談しましょう
口頭の「じゃあ直しておきます」で終わらせない：無償なのか有償なのか、いつまでなのかが曖昧なまま進むと、後で再び揉める原因になります

後から出てきた要望を仕様変更として進める場合の判断や手順は、システム開発の途中で仕様変更したい！どこまで変えていい？判断の物差しと進め方も参考にしてください。

次の案件で防ぐには：受入条件を先に決める

バグか仕様変更かの争いの多くは、「何ができたら合格か」が決まっていないことから生まれます。次の案件では、開発が始まる前、遅くとも設計が固まった段階で、次のことを決めておきましょう。

受入条件（＝何ができたら合格とするか）を文章にする：「○○の操作で××が表示される」のように、確認できる形で書く
例外のケースを業務側から書き出す：「月に数回こういうことがある」という例外は、発注者にしか分からない情報です
性能は数値で決める：「検索は○秒以内」「同時に○人が使える」など
どの資料が「正」かを決める：画面イメージは確定版か参考図か、議事録の決定事項はどう扱うか
検査仕様書（受け入れテストの項目）を事前に共有する：モデル契約書のひな型でも、検査仕様書は発注者が開発会社と協議のうえ作る流れです。事前に見せておけば「その確認は仕様外です」というずれを早めに見つけられます