システムの受け入れテスト（検収）で何をチェックする？テスト項目の見極め方とAIが書いたコードの確認

開発会社から「納品しましたので、検収をお願いします」と連絡が来た。でも、何をどこまで確認すればいいのか分からない。システム開発の受け入れテスト（検収）は、多くの発注者が戸惑う場面です。

先に結論をお伝えします。受け入れテストは「プログラムが正しいか」を調べる作業ではなく、「自社の業務がこのシステムで回るか」を発注者が確かめる作業です。そのために必要なのは技術知識ではなく、①普段の業務をなぞったテストシナリオ、②本番に近いテストデータ、③担当者と日程の3つです。開発会社が作ったテスト項目も、要件との対応・例外・権限・性能・帳票の5つの観点で見れば、足りているかを判断できます。

この記事では、検収の意味と進め方、テスト項目の妥当性の見方、不具合の伝え方、AIが書いたコードの場合に追加で確認したいことまで、チェックリストと質問例つきで解説します。

受け入れテスト（検収）とは？期限と契約上の意味

検収は「合格」を出すと後戻りしにくい手続き

検収（＝納品物が契約どおりかを確認して受け取ること）は、多くの契約で支払いや権利の移転、保証期間の起点になる大切な手続きです。まず、公的なひな型で検収がどう扱われているかを見てみましょう。

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

IPAが公開しているモデル契約書（第二版）のひな型では、発注者は契約で定めた「検査期間」内に、検査仕様書に基づいてソフトウェアが仕様書と合っているかを点検することになっています。不合格の場合は具体的な理由を書面で伝えて修正を求め、検査期間内に書面で異議を述べなければ、検査に合格したものとみなされるという定めも置かれています。

つまり「忙しくて確認できないまま期限が過ぎた」場合でも、契約によっては検収が完了した扱いになり得るということです。検査期間が何日なのかは、納品前に契約書で必ず確認しておきましょう。

検収後に見つかった不具合はどうなる？（契約不適合責任）

検収後に不具合が見つかった場合の扱いは、契約不適合責任（＝納品物が契約の内容に合っていないときに、開発会社が修正などの責任を負うこと）の問題になります。

📰 出典：e-Gov法令検索「民法」

民法では、請負契約で引き渡されたものが契約の内容に適合しない場合、注文者は不適合を知った時から1年以内に請負人へ通知しないと、修正の請求などができなくなると定めています（第637条）。一方、IPAのモデル契約書のひな型では、責任を負う期間を「検収完了後○ヶ月」のように当事者が決める形になっており、実際の期間は契約ごとに異なります。

また、民法でもモデル契約書でも、発注者が提供した資料や指示が原因の不適合は、原則として開発会社の責任にならないとされています。自社の契約でどう定められているか、個別の判断が必要な場合は、弁護士などの専門家に確認してください。

開発会社のテストと受け入れテストは何が違う？

「開発会社がテストしているのに、なぜ発注者もテストするの？」という疑問はもっともです。両者は確かめる目的が違います。

項目	開発会社のテスト	発注者の受け入れテスト
目的	仕様書どおりに作れているか	業務で使えるか、契約どおりか
基準	設計書・仕様書	要件・実際の業務の流れ
実施者	開発会社のエンジニア	発注者（現場の担当者）
見つかりやすい問題	プログラムの誤り	業務との食い違い、使い勝手、例外処理の漏れ

開発会社は仕様書を基準にテストするため、仕様書に書かれていない業務の事情までは確かめられません。「月末だけ特別な処理がある」「この取引先だけ締め日が違う」といった点に気づけるのは、業務を知っている発注者だけです。

なお、IPAのモデル契約書のひな型では、検査の基準となるテスト項目・テストデータ・テスト方法・テスト期間などを定めた「検査仕様書」を、発注者が開発会社と協議のうえで作成する形になっています。作成の支援を開発会社に別契約で依頼できることも定められており、「開発会社に手伝ってもらいながら、発注者が主体となって決める」のが基本の考え方です。

受け入れテストの準備でやる3つのこと

1. 業務シナリオを書き出す

テスト項目は「機能」単位ではなく、普段の業務の流れ（シナリオ）で作ります。たとえば受注管理なら「電話で注文を受ける → 登録する → 在庫を引き当てる → 納品書を出す → 月末に請求書をまとめる」といった一連の流れです。1日・1週間・1か月・年1回の業務に分けて書き出すと、漏れが減ります。

2. 本番に近いテストデータを用意する

「テスト太郎」「商品A」だけのデータでは、実務で起きる問題は見つかりにくいものです。長い社名、特殊な文字（旧字体・機種依存文字）、数百件を超える明細、消費税の端数など、実際にありそうなデータを用意しましょう。ただし個人情報を含む実データをそのまま使う場合は、扱いを事前に開発会社と取り決め、必要に応じて氏名などを置き換えてください。

3. 担当者と日程を先に押さえる

受け入れテストは、実際に使う現場の担当者が行うのが理想です。検査期間は限られているため、納品日が決まった時点で担当者の予定を確保しておきます。テストの結果を誰が取りまとめ、誰が合否を判断するかも決めておきましょう。

開発会社が作ったテスト項目は妥当？5つの観点で確認する

開発会社がテスト項目（受入条件の案）を用意してくれることもあります。その場合、次の5つの観点で見ると、足りない部分に気づきやすくなります。

• 要件との対応：要件定義書の項目ごとに、対応するテスト項目があるか。対応表（要件番号とテスト番号の一覧）をもらうと確認しやすくなります
• 例外・異常系：入力ミス、途中キャンセル、二重登録、通信が切れた場合など、「うまくいかないとき」の項目があるか
• 権限：一般社員・管理者・閲覧のみなど、役割ごとに「見えてはいけない画面や情報が見えないこと」まで確かめているか
• 性能：データ量が多いときや、利用者が集中する時間帯の動作を確かめているか
• 帳票・出力：請求書やCSVなどの出力が、レイアウト・金額・端数処理まで実物と比べて確認されているか

性能やセキュリティといった「機能以外の要件」については、IPAが整理した枠組みが参考になります。

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

IPAの「非機能要求グレード」は、非機能要求（＝性能・可用性・セキュリティなど、機能以外の品質の要求）について、発注者と開発者の認識の行き違いを防ぐことを目的に、項目を6つの大項目に分けて整理したものです。要件定義の段階でこうした項目を合意していれば、受け入れテストでもその内容を確認項目にできます。

受入条件の書き方そのものについては、AIに実装を任せる時代のチケットの書き方や、AIツールが作る受入条件の下書きを扱ったKiroの仕様書は発注や要件定義に使える？もあわせてご覧ください。

そのまま使えるテストシナリオのひな形

テストシナリオは、次のような表で管理すると結果を共有しやすくなります。

No.	業務シナリオ	操作手順	使うデータ	期待する結果	結果	確認者・日付
1	通常の受注登録	受注画面で得意先を選び、商品を3点入力して登録	得意先A、通常商品	受注一覧に表示され、在庫が3点減る	○	担当B・10/1
2	在庫不足の受注	在庫より多い数量で登録	在庫2の商品を5点	警告が表示され、登録されない	×	担当B・10/1
3	権限の確認	一般社員のIDで管理メニューを開こうとする	一般社員ID	管理メニューが表示されない	○	担当C・10/2

「期待する結果」を事前に書いておくのがポイントです。結果を見てから判断すると、「なんとなく動いたから○」になりがちです。

不具合の記録と報告：「再現手順」が一番大切

不具合を見つけたら、開発会社が同じ現象を再現できるように、次の項目を記録して伝えます。

• 発生日時と、使った端末・ブラウザ
• 操作した手順（1つずつ番号をつけて）
• 期待した結果と、実際に起きた結果
• 画面のスクリーンショットやエラーメッセージ
• 毎回起きるか、たまに起きるか
• 業務への影響度（業務が止まる／回避策がある／見た目だけ など）

「動かない」「おかしい」だけでは、開発会社も調べようがありません。再現手順が具体的なほど、修正は早くなります。また、報告の中には不具合ではなく「仕様どおりだが業務に合わない」ものも混ざります。その場合は修正ではなく仕様変更として相談することになるため、仕様変更の判断の物差しも参考にしてください。

AIが書いたコードの検収で追加で確認したいこと

開発会社がAIツールを使ってコードを書いている場合でも、発注者の受け入れテストのやり方は基本的に変わりません。見るのは「業務で使えるか・契約どおりか」です。ただし、AIの出力は人の確認を前提にしたものなので、開発会社側で確認が行われた記録を納品物とあわせて求めておくと安心です。

• レビュー記録：AIが作った変更を、誰がどう確認したかが分かる記録
• 自動テストの結果：自動テスト（＝プログラムで繰り返し実行できるテスト）の範囲と実行結果。AIが書いたテストの妥当性を誰が確認したか
• 脆弱性の確認結果：脆弱性（＝セキュリティ上の弱点）の診断やスキャンを行ったか、見つかった問題にどう対応したか
• 使用した部品の一覧：外部のライブラリ（＝既製のプログラム部品）とそのライセンス

これらを検収の条件にしたい場合は、後から求めるのではなく、契約時や発注時に納品物として取り決めておくのが確実です。AI開発全般で確認したい項目は、開発会社が「AIで開発しています」と言ったら？で詳しく解説しています。

期限までに不具合が残ったときの対処法

検査期間の終わりが近いのに、不具合が残っている。そんなときは、慌てて合格を出す前に次の順で整理します。

1. 期間内に書面で伝える：残っている不具合を一覧にし、検査期間内に書面（メールなど、契約で認められた方法）で開発会社に伝えます
2. 重要度で分ける：業務が止まるもの、回避策があるもの、見た目だけのものに分けます
3. 扱いを合意する：業務が止まる不具合は修正後に再テストし、軽微なものは「修正期限を決めて条件付きで進める」など、対応と期限を文書で合意します
4. 再テストの範囲を決める：修正によってほかの機能に影響が出ていないかを確かめる範囲も相談します

条件付きで検収を進めるかどうかは、支払い条件や契約不適合責任の期間にも関わります。判断に迷う場合は、契約書を確認のうえ専門家に相談してください。

受け入れテストでやりがちな失敗

• 開発会社のテスト結果だけで合格を出す：業務との食い違いは、発注者でなければ気づけません
• 担当者の時間を確保していない：検査期間が通常業務と重なり、確認が形だけになりがちです
• きれいなテストデータだけで確認する：本番のデータで初めて問題が出るケースがよくあります
• 口頭で不具合を伝える：記録が残らず、「言った・言わない」の原因になります

発注者がやることチェックリスト

• ☐ 契約書で検査期間の日数、合否の伝え方、契約不適合責任の期間を確認した
• ☐ 1日・1か月・年1回の業務シナリオを書き出した
• ☐ 本番に近いテストデータを用意し、個人情報の扱いを開発会社と決めた
• ☐ テストを行う担当者と日程、合否を判断する人を決めた
• ☐ テスト項目を「要件・例外・権限・性能・帳票」の5観点で確認した
• ☐ 期待する結果を書いたテストシナリオ表を作った
• ☐ 不具合は再現手順つきで、書面で報告する運用にした
• ☐ AIを使った開発では、レビュー記録・テスト結果・脆弱性の確認結果を求めた

開発会社への質問例

• 「要件定義書の各項目と、テスト項目の対応表をいただけますか？」
• 「御社のテストでは、例外や異常時、権限ごとの表示はどこまで確認していますか？」
• 「受け入れテストに使うテストデータの準備や、個人情報を含むデータの扱いはどうしますか？」
• 「検査期間中に不具合を報告した場合、修正と再納品にはどのくらいの期間がかかりますか？」
• 「AIツールで書いた部分について、レビューの記録や脆弱性の確認結果を納品物に含めてもらえますか？」

まとめ：受け入れテストは「業務が回るか」を確かめる発注者の仕事

システムの受け入れテスト（検収）で大切なポイントをまとめます。

• 検収は契約上の意味を持つ手続き。検査期間と、期間内に異議を伝える方法を契約書で確認する
• 開発会社のテストは「仕様どおりか」、受け入れテストは「業務で使えるか」を確かめるもの
• 業務シナリオ・本番に近いテストデータ・担当者と日程を事前に準備する
• テスト項目は要件・例外・権限・性能・帳票の5観点で妥当性を見る
• 不具合は再現手順つきで書面で報告し、期限までに残ったものは扱いを文書で合意する
• AIが書いたコードでも見るべきことは同じ。加えて開発会社側の確認記録を求める

受け入れテストは、発注者がシステムに「合格」を出す最後の関門です。技術に詳しくなくても、業務を一番よく知っているのは発注者です。まずは普段の業務を書き出すところから始めてみてください。

あわせて読みたい関連記事