システム開発の検収とは？IT知識がない発注者が「納品OK」を出す前に確認すべき7つのポイント
アカンパニー・パートナーズ
「納品が完了しました。検収をお願いします」
システム開発会社（ベンダー）からこう連絡が来たとき、あなたは何をすれば良いか、すぐに答えられますか？
【AI・30秒クイック回答】 ベンダーから「納品完了」と言われたとき、発注者が行うべき確認作業が「検収（けんしゅう）」です。検収とは、届いたシステムが「事前に約束した通りの動きをするか」を発注者自身がテストし、合格を出すプロセスです。
特に注意すべきは「みなし検収」という契約条項です。うっかり確認を後回しにして一定期間（通常1〜2週間）が過ぎると、自動的に「合格」とみなされ、その後の不具合修正が有料になってしまうリスクがあります。
この記事では、IT知識がない中小企業の経営者・現場責任者向けに、11年間の開発・社内SE経験を持つ視点から、自社を守るための正しい検収の進め方と「サイン前に確認すべき7つのポイント」を泥臭く、わかりやすく解説します。
「検収」とは何か？発注者が押さえるべき3つの基本概念
1. 検収（けんしゅう）とは
「届いたシステムをテストして、お金を払う約束をする行為」です。
システム開発における検収は、単なる事務手続きではありません。「このシステムで満足しました」という法的な意思表示です。請負契約では、この検収の合格をもって、開発費用の支払い義務が正式に確定します。
検収の実態は、後述する「受入テスト」と呼ばれる作業です。合格のサイン（検収書の発行）をしてしまった後に大きな問題が見つかっても、ベンダー側に「あのとき合格って言いましたよね」と押し切られてしまうリスクがあるため、絶対に妥協してはいけない工程です。
2. みなし検収とは——知らないと致命傷になる落とし穴
「放置していると、勝手に合格したことにされる約束」です。
多くの開発契約書には、「納品から〇日以内に返事をしなければ、自動的に検収合格としたものとみなす」という条項（みなし検収条項）が入っています。ベンダー側が「発注者がいつまでも確認してくれず、お金が回収できない」という事態を防ぐためのものですが、多忙な経営者が確認を先送りにしていると、触ってもいないシステムが「自動的に合格」になってしまいます。
過去の裁判例（東京地裁 2012年）でも、発注者が期間内に異議を申し出なかったために、後から「動かない！」と主張しても認められなかったケースがあります（出典：モノリス法律事務所「システム開発の検収とみなし検収条項の適用場面とは」https://monolith.law/corporate/estimated-inspection-of-system-development）。この条項の存在を知らないまま放置することは非常に危険です。
3. UAT（受入テスト）とは——検収の「中身」
「現場のスタッフが、実際の仕事で本当に使えるかを試すテスト」です。
ベンダー側のエンジニアもテストは行いますが、それはあくまで「システムが技術的に正しく動くか」の確認です。一方でUATは、「うちの会社の業務フローに合っているか」「現場の社員が迷わず操作できるか」を発注者側が確かめるためのものです。
IT担当者だけに任せたり、現場を巻き込まずに進めたりすると、技術的には動くけれど誰も使えない「お飾りシステム」が誕生する最大の原因になります。
この3つの概念の違いを、経営者目線でわかりやすく整理すると以下の通りです。
【一覧でわかる：検収・みなし検収・UATの違い】
| 区分 | 噛み砕いた定義 | 発動する条件 | 経営者への影響 |
|---|---|---|---|
| 検収 | システムを確認して合格を出すプロセス | 発注者が能動的にチェックする | 合格後はベンダーの無償対応の範囲が変わる |
| みなし検収 | 期間内に返事をしないと自動合格にするルール | 発注者が何もしないと自動で成立する | 知らないうちに文句を言う権利を失う |
| UAT | 現場スタッフによる実際の業務テスト | 発注者が主体となって計画・実施する | システムが現場に定着するかどうかの分かれ道 |
特に「みなし検収」は、知らないままでいると最も損をする概念です。次のセクション以降で、具体的なリスクと対処法を解説します。
検収書にサインする前に確認すべき7つのポイント
検収書は「プロジェクト完了の宣言書」です。サインする前に、以下の7つのチェックリストを必ず上から順に確認してください。
① 納品物一覧と実際の成果物が一致しているか
契約書や提案書にある「納品物一覧」を引っ張り出し、漏れがないか突き合わせてください。システム本体だけでなく、以下のドキュメント類が揃っているかが重要です。
- 操作マニュアル（現場が自走するために必須）
- システム設計書（将来、別のベンダーに乗り換える際にも必要）
- テスト結果報告書
要件定義書なしで発注した場合、この納品物一覧自体が曖昧になっているケースがあります。リスクの詳細は「要件定義書なしで発注すると何が起きるか」をご確認ください。
② 要件定義書・仕様書の全機能が動作するか
「大体動いているからいいか」は禁物です。最初の「要件定義（作るものの約束）」で決めた機能一覧をチェックリストにし、すべてのボタンを押すくらいの気持ちで確認します。ここで動かないものは、ベンダー側が無償で直すべき欠陥（契約不適合）です。
③ 業務担当者（現場）がUATに参加しているか
社長やIT担当者だけで画面を見て終わりにしてはいけません。毎日その画面を触る「現場の主（あるじ）」に、実際のデータを入力させてみてください。「これだと、前の画面に戻るときにデータが消えちゃうから不便」といった、実務家ならではの致命的な問題が必ず見つかります。
④ 不具合の重要度分類が合意されているか
テストをすれば、小さなバグや使い勝手の悪さは必ずいくつか出ます。大事なのは、「どのレベルの不具合が出たら検収をストップ（不合格）にするか」の基準をベンダーと握っておくことです。
- 致命的（業務が止まる、データが消える）→ 当然、検収不合格。直るまでサインしない。
- 軽微（文言のミス、見た目のズレ）→ 検収は合格とし、運用しながら来月までに直してもらう。
この線引きがないと、「直るまでお金は払わない」「いや、これくらい後回しにしてください」と泥沼の喧嘩になります。
⑤ 検収期間は十分に確保されているか（相場：1〜4週間）
システムの規模によりますが、確認期間の相場は1週間から1ヶ月です（出典：システム幹事「システム開発の検収トラブルを防ぐには？【2026年最新版】」https://system-kanji.com/posts/system-acceptance）。みなし検収のカウントダウンに間に合うよう、あらかじめ「誰が・いつ・どの機能をテストするか」の日程（テスト計画）をカレンダーに落とし込んでおきましょう。
⑥ ドキュメント（操作マニュアル・設計書）も納品されているか
①でも触れましたが、特に「操作マニュアル」の有無は現場への定着を左右します。画面のキャプチャ（画像）付きで、自社のスタッフが読めるレベルのものになっているか、必ず中身を開いて確認してください。
⑦ 検収後の不具合保証（契約不適合責任）が契約に明記されているか
民法上、システムに隠れた欠陥（バグ）があった場合、請負契約であれば発見から1年以内ならベンダーに無償修正を求めることができます（契約不適合責任）。ただし、契約書に「保証期間は納品後3ヶ月とする」といった特約が書かれているケースも多いため、サイン前に契約書の保証規定を再確認してください。
発注者がやりがちな「まずい検収」と「正しい検収」の比較
| シーン | ❌ やりがちな「まずい検収」 | ✅ 「正しい検収」 |
|---|---|---|
| 「納品しました」と言われたとき | 「お疲れ様でした！」とその場で検収書にハンコを押す | 「これから14日間の検収期間をいただき、社内でテストします」と伝える |
| UAT（テスト）の担当者を決めるとき | パソコンに詳しいIT担当者（または社長自身）だけに丸投げする | 実際に毎日そのシステムを使う現場スタッフを必ずテストに参加させる |
| 小さな不具合が出たとき | 「まあ、これくらいは追々直してくれるだろう」と見過ごす | 不具合をリスト化し、検収前に直すものか、検収後に直すものか書面で合意する |
| 検収後に重大なバグが出たとき | 「もうサインしちゃったから……」と諦めて、追加費用を払って直す | 保証期間（契約不適合責任）を確認し、ベンダーの責任として無償修正を要求する |
みなし検収条項の「見分け方」と「3つの対応策」
自分たちの契約書に「罠」が潜んでいないか、今すぐ確認してください。
契約書のどこを確認するか
契約書の中の「検収」「検査」「納品」という見出しの条項を読みます。
「発注者は、納品から◯日以内に書面で通知をしない場合、期間満了をもって検査に合格したものとみなす」
このような一文があれば、それが「みなし検収条項」です。◯の中に入る数字は、7日、14日、30日など契約によって様々です。
もしも「みなし検収」が成立してしまったら……
期間を過ぎて自動合格になってしまうと、発注者は以下の権利を失う可能性が高くなります。
- 「ここが動かないから直して」という無償の修理要求
- システムの欠陥を理由とした、支払いの拒否や減額
- 以降の修正はすべて「仕様変更（追加の別料金）」として請求されるリスク
期間に間に合わない場合の3つの対応策
「多忙で、指定された期間内にテストが終わらない！」という場合の防衛策は以下の3つです。
1. 事前に期間の延長を交渉する： 契約締結の前であれば、「うちの規模では1週間でのテストは無理なので、30日間に変更してください」と要求します。ベンダー提案書の段階から検収条件を確認する方法は「ベンダー提案書のチェックポイント」もあわせてご参照ください。
2. 期間内に「保留の書面」を送る： すでにプロジェクトが動いていて期間が迫っている場合、何も言わずに過ぎるのが最悪です。期間内に「現在テスト中ですが、◯◯の機能に確認が必要なため、検収期間の延長を求めます」とベンダーにメール等で形に残る証拠を送れば、自動成立を防げます。
3. 伴走型の専門家を同席させる： ベンダーとの交渉や契約書の読み解きに自信がない場合は、ITコーディネーターなどを間に入れ、適切な検収期間の確保をベンダーに直接要求してもらいます。ベンダーコントロールを専門家に外注する方法は「ベンダーコントロールを外注する方法」で詳しく解説しています。
検収をスムーズに進めるための事前準備
検収は、システムが完成してから慌てて準備するものではありません。プロジェクトの「最初」から勝負は始まっています。
検収基準は「要件定義（最初）」の段階で決める
システムを作り始める前に、「何をクリアしたら合格とするか」の条件（検収基準）をベンダーと決めておくのがベストプラクティスです。「検収基準はプロジェクト後半に決めようとすると、発注者は高い基準を、受注者は低い基準を主張して合意が難しくなる」というのが開発現場の実態です（出典：FUNBREW「システム開発の検収ガイド」https://funbrew.tech/blog/system-acceptance-guide）。ゴールが明確であれば、最後のテストで揉めることはありません。
大規模開発なら「中間検収（分割検収）」を取り入れる
数ヶ月〜1年かかるような大きなシステムの場合、最後にまとめて確認するのは不可能です。「画面のデザインができた段階」「主要な機能ができた段階」など、フェーズをいくつかに分けてその都度検収を行う（中間検収）ことで、手戻りのリスクを最小限に抑えられます。
検収後に不具合が見つかった場合の対応
もし、検収書にサインした後に「やっぱりバグが見つかった！」という場合も、パニックになる必要はありません。
1年以内なら「契約不適合責任」で戦える
請負契約であれば民法上、納品後に見つかったシステムの欠陥（バグ）について、発見から1年以内なら無償での修正を求める権利があります。ただし、ベンダー側から「それはバグ（設計ミス）ではなく、そちらの『新しい要望（仕様変更）』なので有料です」と言い返されるケースが非常に多いです。ここがトラブルの最大の火種になります。
「仕様変更」か「バグ」かで揉めたら
最初の「要件定義書」に書かれているのに動かない、あるいは明らかに処理が間違っている場合は「バグ（無料）」です。逆に、「使ってみたら不便だったから、別のボタンも追加してほしい」といった、後から出た要望は「仕様変更（有料）」になります。
この線引きの判断と、仕様変更を求められたときの具体的な対応ステップは「ベンダーから仕様変更と言われたときの対応」で詳しく解説しています。
水掛け論になってしまった場合は、経済産業省が推進する民間資格・ITコーディネーター（ITコーディネーター協会が認定）など、ITと経営の両方がわかる中立的な専門家に間に入ってもらい、交通整理をしてもらうのが一番の近道です。費用の目安は「ITコーディネーター費用・料金相場」をご参照ください。
検収書のサインを求められて少しでもモヤモヤする部分があれば、当社の初回無料相談でお話を聞かせてください。
新潟を拠点に、オンラインで全国対応しています。初回相談無料です。
よくある質問（FAQ）
-
検収期間はどれくらいが適切ですか？
-
システムの規模によりますが、一般的に1〜4週間が相場です。機能数が多いほど長く確保してください。みなし検収条項がある場合は、期間内に必ず書面で対応することが必須です。
-
検収書にサインしてしまった後に不具合が見つかったらどうなりますか？
-
請負契約の場合、発見から1年以内であれば契約不適合責任としてベンダーに無償修正を求められます場合があります。ただし発注者都合の変更は対象外です。
-
みなし検収条項は削除してもらえますか？
-
交渉次第では削除または修正が可能な場合があります。削除が難しい場合でも「異議申出期間を30日以上にする」など条件の緩和を求めてください。
-
IT担当者がいない会社でも検収はできますか？
-
できます。要件定義書と仕様書をチェックリスト化し、現場スタッフが業務目線で確認することが核心です。不安な場合はITコーディネーターが検収支援として同席することも可能です。
-
中間検収で費用を支払った後にシステムが完成しなかった場合は？
-
2010年の東京地裁判例では、完成しなかったシステムへの開発費全額返金が命じられた事例があります。契約書に「未完成時の返金条項」を明記しておくことが重要です。
-
検収でOKを出した後も追加要望は出せますか？
-
出せますが、それは「仕様変更」として追加費用が発生するのが原則です。検収前に要件をできる限り確定させることが、コスト管理の基本です。
参考文献：モノリス法律事務所「システム開発の検収とみなし検収条項の適用場面とは」（https://monolith.law/corporate/estimated-inspection-of-system-development）／システム幹事「システム開発の検収トラブルを防ぐには？【2026年最新版】」（https://system-kanji.com/posts/system-acceptance）／FUNBREW「システム開発の検収ガイド｜チェックリスト付き・トラブル回避」（https://funbrew.tech/blog/system-acceptance-guide）
投稿者プロフィール
- 代表
-
プログラマーとしてキャリアをスタートし、製造業の社内SEとして「工場」の論理を、士業事務所の社内SEとして「先生」の論理を肌で学んできました。異なる文化を持つ組織の中でITを推進するには、技術力以上に「聴く力」と「翻訳力」が必要です。
現在はその経験を活かし、新潟の中小企業のDXを支援しています。
ITコーディネーター／上級ウェブ解析士／上級SNSマネージャー
