結合テスト仕様書の書き方 記載項目・テスト観点・サンプル構成と作成手順を解説

結合テスト仕様書を作ろうとして、「単体テストと何が違うのか」「どの粒度で書けばいいのか」「そもそも何を確認する工程なのか」で手が止まる場面は珍しくありません。テンプレートを探しても現場ごとに構成が違い、そのまま使えるものが見つからないという声もよく聞きます。

結合テストは、単体では正しく動いていた機能同士をつないだときに、画面遷移のずれやデータ受け渡しの不整合、権限による挙動の差が表面化する工程です。だからこそ、実装後に思いついた順で確認するのではなく、どの結合点で何を見るのかを先に整理した文書が必要になります。

本記事では、結合テスト仕様書の役割と他工程との違いから、書くべき項目、観点の洗い出し方、作成手順、網羅性の担保、そしてよくある失敗と効率化の方法までを順番に整理します。読み終えたときに、自社のプロジェクトで使える構成を組み立てられる状態を目指します。

確認したいポイント	結論	詳細
結合テスト仕様書は何を定義する？	機能同士の結合点と確認内容	画面からAPI、APIからDBなど処理が受け渡される箇所で、何をどう確認するかを事前に定義します。
単体テストとの線引きは？	対象がひとつか複数か	単体は部品ひとつの動作、結合は複数要素をまたいだ連携が対象です。重複させないことが前提です。
どんな観点を入れればいい？	遷移・データ・権限・異常・連携	画面遷移、データ受け渡し、ロールによる差異、異常系と境界、外部連携の5分類で整理すると漏れにくくなります。
網羅できているかの判断は？	要件IDとの突き合わせ	ケースに要件IDを紐づけ、ケース0件の要件がないかを機械的に確認する方法が最も確実です。

この記事でわかること

• 結合テスト仕様書の役割と、単体テスト・総合テストとの明確な線引き
• 仕様書に必ず載せるべき管理情報とテストケース欄の項目構成
• 結合点ごとに観点を洗い出し、テストケースへ落とし込むまでの手順
• 要件とのトレーサビリティや完了基準など、網羅性を担保する考え方
• 粒度のばらつきや更新漏れなど、現場で起きやすい失敗の回避策

▼ 開発・品質管理の業務をどこまで効率化できるか整理したい方へ 生成AIを使ったドキュメント作成支援や業務自動化の進め方、支援内容、導入までの流れをまとめた資料をご用意しています。 検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

結合テスト仕様書とは何を定義する文書か

結合テスト仕様書を正しく作るには、ほかのテスト文書との役割の違いを先に押さえておくことが欠かせません。ここが曖昧なままだと、単体テストの焼き直しになったり、総合テストと内容が重複したりして、文書が増えるだけで実務に効かない状態になります。

結合テスト仕様書が担う役割

結合テスト仕様書の最大の役割は、連携部分の確認を属人化させないことです。開発担当者の頭の中だけに確認項目がある状態では、担当が変わった途端に観点が抜け落ちます。文書として残すことで、実施者、開発者、レビュー担当の間で認識を揃えられます。

もう1つの役割が、確認の証跡を残すことです。いつ、誰が、どの条件で、どのような結果を得たのかが記録されていれば、後から不具合が見つかったときに「この工程では確認済みだったのか」を判断できます。品質管理の土台としての側面です。

つまり結合テスト仕様書は、テストを実施するための手順書であると同時に、プロジェクト内で情報を共有し、後から検証できるようにするための記録でもあります。この二面性を意識すると、書くべき項目が自然に決まってきます。

単体テストとの違い

単体テストは、個別の関数、メソッド、画面部品、処理単位が仕様どおりに動くかを確認します。対象は「ひとつの部品」で、内部設計の正しさを検証する工程です。入力チェックのロジックが想定どおりに動くかを確かめるのは、単体テストの領域になります。

一方の結合テストは、それらを組み合わせたときに正しく連携するかを見ます。画面からAPI、APIからデータベース、登録処理から一覧への反映、申請から通知送信まで。処理が受け渡されるところが対象だと考えると線引きしやすくなります。

この違いを意識せずに書くと、単体テストで確認済みの入力チェックを結合テストでも並べてしまい、工数だけが膨らみます。結合テスト仕様書に載せるのは「つながりを確認するケース」に限る、と決めておくのが実務的です。

総合テスト・受入テストとの違い

総合テストは、システム全体が要件を満たしているかを確認する工程です。性能、セキュリティ、障害時の挙動といった非機能要件も対象に含まれます。結合テストは外部設計の正しさ、総合テストは要件定義の正しさを検証するという対応関係で整理すると分かりやすくなります。

受入テストは、発注者側が業務として使えるかを判断するテストです。開発側の視点ではなく、利用部門の業務手順に沿って確認します。同じ画面を触っていても、目的も判定者も異なるため、仕様書の粒度や書き方も変わります。

なお、結合テストの範囲は現場によって幅があります。プログラム同士の結合に重きを置く場合もあれば、業務手順に沿った画面・帳票の連携を重視する場合もあります。プロジェクト開始時にどの範囲を指すのかを合意しておくことが、後の認識ずれを防ぎます。

どの設計書と対応するのかを決めておく

結合テスト仕様書は、基本設計書（外部設計書）を根拠に作成します。画面遷移図、機能一覧、インターフェース仕様、業務フローが主な入力情報になり、これらに書かれた連携が実際に成立するかを確認する形です。

根拠となる設計書を明示しておくと、レビューのときに突き合わせができます。「この観点はどの設計書のどの記述から来ているのか」が追えれば、確認漏れも過剰なテストも発見しやすくなります。

逆に、根拠なしに経験だけでケースを並べると、担当者ごとに濃淡が出ます。設計書に記載がない連携を見つけた場合は、テストケースを足す前に設計書側の不足を疑うほうが、結果的に品質が上がります。

結合テスト仕様書に記載する項目

ここからは具体的な構成に入ります。仕様書は大きく、文書全体の管理情報を書くヘッダー部と、個々の確認内容を並べるテストケース部の2層で構成します。項目を増やしすぎず、埋める意味のある欄だけを残すのが実務のコツです。

ヘッダー部に書く管理情報

ヘッダー部には、プロジェクト名、対象システムとサブシステム、テストフェーズ、対象バージョン、作成者、作成日、承認者、改訂履歴を記載します。誰がいつ作り、誰が承認したのかが追えないと、後から内容の妥当性を検証できません。

あわせて、テストの目的と対象範囲、対象外とする範囲も明記します。「何をテストしないか」を書いておくことで、レビュー時に「なぜこの機能が入っていないのか」という議論を先に片付けられます。

テスト環境の情報も忘れずに残します。使用するサーバー、データベースのバージョン、ブラウザ、外部連携先がテスト用か本番相当か。環境が違えば結果も変わるため、再現性を担保するうえで必須の情報です。

テストケース部の基本的な列構成

個々のケースには、テストケースID、対応する要件IDまたは機能ID、テスト観点、前提条件、テストデータ、操作手順、期待結果、判定欄、実施者、実施日、備考を並べるのが基本形です。

このうち省略されがちなのが前提条件と期待結果の具体性です。「正常に表示されること」では判定者によって解釈が変わります。「一覧の1行目に登録した受注番号が表示され、ステータスが未処理であること」まで書いて初めて、誰が実施しても同じ判定になります。

操作手順は番号付きで、1ステップ1動作に分けます。1つの欄に複数の操作をまとめて書くと、どこで失敗したのかが記録に残りません。結合テストは複数画面をまたぐケースが多いため、ここを丁寧に書く効果は特に大きくなります。

前提条件とテストデータの扱い

結合テストでは、前工程の処理結果が次の確認の前提になるケースが頻繁に出てきます。「申請済みのデータが1件存在する状態」といった前提を明記しないと、実施順が変わっただけで結果が変わってしまいます。

テストデータは、仕様書内に直接書く方法と、別紙のデータ一覧を参照する方法があります。件数が多い場合は別紙にまとめ、仕様書からはデータIDで参照する形にすると、データ変更時の修正範囲が小さく済みます。

また、実施の順序に依存するケースは、依存関係が分かるようにグループ化しておきます。シナリオ単位でまとめ、その中では上から順に実施するというルールにしておくと、担当者が変わっても再現できます。

判定欄とエビデンスの残し方

判定欄は、合否だけでなく未実施・保留・対象外といった状態も表現できる形にしておきます。進捗を集計するときに、未実施と不合格が区別できないと、残作業量の見積もりを誤ります。

エビデンスは、画面キャプチャ、ログ、データベースの状態など、何をどこまで残すかをプロジェクト内で統一します。全ケースでキャプチャを取るのか、不合格時のみ取るのか。基準がないまま始めると、後半になって手戻りが発生します。

保存場所も仕様書から参照できるようにしておきます。各自のローカルに散らばると、第三者が検証できません。共有フォルダのパスやチケット番号を備考欄に書く運用にしておくと、証跡としての価値が保てます。

▼ ドキュメント作成の負担を減らす方法を相談したい方へ 仕様書やテストケースの作成をどこまで型化・自動化できるかは、現場の運用によって答えが変わります。 現状をうかがったうえで、無理のない進め方をご提案します。 ＞ 相談予約はこちら

結合テストで確認すべき観点

項目の枠が決まったら、次は中身です。結合テストの観点は「つながり方の種類」で分類すると漏れにくくなります。ここでは実務で押さえておきたい5つの切り口を順に見ていきます。

画面間・機能間の遷移

最も基本的なのが、画面遷移が設計どおりに成立するかです。正常な遷移だけでなく、戻るボタン、キャンセル、ブラウザバック、直接URLを入力したときの挙動まで含めると、実際の利用に近い確認になります。

遷移時に前の画面で入力した値が引き継がれるか、逆に引き継がれてはいけない値が残っていないかも確認します。単体では正しく動いていた画面が、遷移元によって異なる状態になるのは、結合テストで初めて見つかる典型的な不具合です。

データの受け渡しと整合性

画面からAPI、APIからデータベースへとデータが渡る過程で、桁数、型、文字コード、日付形式、丸め方が意図どおりに保たれているかを確認します。単体テストでは各層が正しくても、境界で欠落や変換が起きることがあります。

登録した内容が一覧や帳票に正しく反映されるか、更新や削除が関連するデータに波及するか、といった整合性も対象です。マスタを更新したときに、過去のトランザクションデータが影響を受けないかも見落とされやすいポイントになります。

同時に複数のユーザーが同じデータを操作した場合の挙動も、結合テストで確認しておきたい観点です。排他制御が設計どおりに働くかは、単体では検証できません。

権限・ロールによる挙動の差異

業務システムでは、同じ画面でもロールによって表示項目や操作可否が変わる設計が一般的です。管理者、一般ユーザー、参照専用など、定義されたロールごとに確認ケースを用意します。

ここで見落とされやすいのが、画面上のボタンが非表示になっているだけで、直接リクエストを送れば処理が通ってしまうケースです。表示の制御と実行の制御は別物なので、両方を確認する観点を入れておきます。

異常系と境界のケース

正常系だけを並べた仕様書は、結合テストとしては不十分です。必須項目が未入力のまま次画面へ進もうとした場合、上限を超える件数を登録した場合、処理の途中で通信が切れた場合など、想定される異常をケースに落とします。

エラーが起きたときの挙動も確認対象です。適切なメッセージが表示されるか、データが中途半端な状態で残っていないか、ログに必要な情報が出力されているか。復旧の可否まで含めて見ておくと、運用開始後の負担が減ります。

すべての異常系を網羅しようとすると際限がないため、影響度と発生可能性で絞り込みます。業務が止まるもの、データが壊れるものを優先し、表示崩れの類は後回しにするという優先順位付けが現実的です。

外部システム連携とタイミング

外部システムとの連携がある場合、正常応答だけでなく、エラー応答、タイムアウト、想定外の形式のデータが返ってきた場合の挙動を確認します。相手側の都合で起きる事象は、こちらで制御できないぶん備えが必要です。

バッチ処理が絡む場合は、実行タイミングによる差も観点になります。オンラインで登録した直後にバッチが動いた場合、日付をまたいだ場合など、時間軸の条件を明示してケースを作ります。

連携先がテスト環境を用意できない場合は、スタブを使うかどうかを決めておきます。スタブで確認した範囲と実機で確認すべき範囲を仕様書上で区別しておくと、後工程で何が残っているかが明確になります。

結合テスト仕様書の作成手順

項目と観点が揃ったら、実際に書き進めます。いきなりケースを書き始めるのではなく、対象範囲の洗い出しから順に進めるほうが、結果的に早く仕上がります。4つのステップで整理します。

対象範囲と結合点を洗い出す

最初にやるのは、今回の結合テストで確認する範囲を決め、その中にある結合点をすべて列挙することです。画面遷移図と機能一覧、インターフェース仕様を並べ、処理が受け渡される箇所に印を付けていきます。

業務フローに沿ってテストする方針なら、フロー図を起点にします。顧客の業務がどう流れ、その中でどの画面と帳票が順に使われるのかを追い、その並びをそのままシナリオの骨格にします。

この段階では粒度をそろえることを優先し、細かい条件はまだ考えません。結合点の一覧ができた時点で関係者に見せ、抜けがないかを確認してから次に進むと手戻りが減ります。

観点を整理してテストケースに落とす

洗い出した結合点それぞれに対して、前章の5つの観点を当てはめます。「この結合点では遷移と権限を見る」「ここはデータ整合性と異常系を見る」というように、観点と結合点の組み合わせで表を作ると、抜けが目に見えるようになります。

その表をもとに、1行1ケースへ展開します。このとき、1ケースで複数のことを確認しようとしないのがポイントです。失敗したときに原因が特定できなくなり、再実施の範囲も広がってしまいます。

ケース数が想定より多くなった場合は、観点の優先度を見直します。すべてを同じ重みで確認するのではなく、業務への影響が大きい結合点に厚く配分するほうが、限られた期間では効果的です。

前提条件とテストデータを準備する

ケースが固まったら、実施に必要なデータを整理します。どのマスタにどんな値が入っている必要があるのか、トランザクションデータはどの状態から始めるのかを、ケース単位で洗い出します。

データの準備は想像以上に時間がかかる工程です。仕様書ができてから慌てて用意するのではなく、ケース作成と並行して進めるほうがスケジュールが安定します。準備の担当者と期限も、この段階で決めておきます。

個人情報を含むデータを扱う場合は、本番データの持ち込み可否を必ず確認します。マスキングが必要なら、その手順自体も文書に残しておくと、次のプロジェクトでも使えます。

レビューで抜け漏れを潰す

仕上げはレビューです。設計書と仕様書を突き合わせ、設計変更が反映されているか、根拠のないケースが混ざっていないかを確認します。作成者以外の目を通すことで、思い込みによる抜けが見つかります。

レビューの観点も事前に決めておくと質が安定します。網羅性、期待結果の具体性、粒度の統一、前提条件の明記、この4点をチェックリスト化しておけば、レビュー担当が変わっても水準が保てます。

指摘事項は必ず記録に残し、修正後に再確認します。指摘件数は品質の指標にもなるため、後から振り返るときの材料としても価値があります。

▼ 品質管理のプロセス見直しからご相談いただけます テスト工程の設計、ドキュメントの型化、AIを使った効率化まで、現場の課題に合わせて進め方をご提案します。 何から着手すべきか整理したい段階でも構いません。 ＞ 相談予約はこちら

網羅性と完了基準をどう担保するか

仕様書が完成しても、「これで十分か」の判断は簡単ではありません。主観だけに頼らず、追跡可能な仕組みと定量的な目安を組み合わせることで、説明できる品質判断に近づきます。

要件IDとのトレーサビリティ

最も効果があるのが、要件や設計項目のIDをテストケースに紐づけることです。要件一覧とテストケース一覧を突き合わせれば、どの要件が何件のケースで確認されているかが機械的に分かります。

ケースが0件の要件があれば、それが抜けです。逆に、どの要件にも紐づかないケースがあれば、過剰か、あるいは設計書に記載漏れがあるかのどちらかになります。この突き合わせだけで、主要な漏れはかなり潰せます。

IDの付け方は、プロジェクト開始時に決めておきます。途中から変えると対応関係の維持が難しくなるため、多少冗長でも最初から拡張しやすい体系にしておくほうが安全です。

テストケース密度と検出バグ密度の目安

定量的な判断材料としてよく使われるのが、規模あたりのテストケース数と検出バグ数です。IPA（情報処理推進機構）が公開する「ソフトウェア開発 分析データ集 2022」では、累計5,546プロジェクトの定量データをもとに、結合テストと総合テストの規模あたりテストケース数や検出バグ数が四分位で整理されています（出典：IPA「ソフトウェア開発 分析データ集 2022」）。

ただし、この種の数値をそのまま当てはめるのは危険です。IPAは検出バグを現象数と原因数に分けて集計しており、同じプロジェクトでも数え方を変えれば密度は変わります。1つの原因が10画面で再現すれば、現象数では10件、原因数では1件です。

テストケースの数え方も同様で、1シナリオを1件とする現場と、確認項目ごとに1件とする現場では、同じテストでも数倍の差が出ます。比較する前に、自社の集計単位をそろえることが前提になります。

完了基準の決め方

完了基準は、テスト開始前に文書化しておきます。全ケースの実施完了、未解決の重大不具合が0件、発見した不具合の原因分析と横並び確認の完了といった条件を、関係者の合意のもとで定めます。

消化率だけを基準にすると、消化を急ぐ力学が働いて品質が落ちます。不具合の発生傾向が収束しているか、同種の不具合が他の箇所に潜んでいないかまで確認する条件を含めておくほうが、実態に即した判断になります。

開始基準も同じく重要です。単体テストが完了していない機能を結合テストに持ち込むと、単体レベルの不具合で工程が止まります。前工程の完了を開始条件として明記しておいてください。

再テストと回帰テストの扱い

不具合を修正したら、その箇所の再テストと、影響範囲の回帰テストが必要になります。仕様書上で「このケースはどの修正に対して再実施したのか」が追えるようにしておくと、終盤の混乱を避けられます。

回帰テストの範囲は、修正の影響が及ぶ結合点から決めます。ここでも要件IDとの紐づけが効いてきます。修正した機能に関連するケースを機械的に抽出できれば、範囲の判断に時間を取られません。

▼ 「この進め方で品質は担保できるか」から相談できます 完了基準の設計、ドキュメント運用、工数のかけどころなど、プロジェクトの実態に合わせた判断をご一緒に整理します。 ＞ 相談予約はこちら

現場で起きやすい失敗と回避策

結合テスト仕様書がうまく機能しない原因は、いくつかのパターンに集約されます。事前に知っておけば避けられるものばかりなので、着手前に目を通しておくと無駄が減ります。

単体テストの焼き直しになっている

最も多いのが、入力チェックや計算ロジックの確認が延々と並び、連携の確認がほとんどないという状態です。工数はかかっているのに、結合テストでしか見つからない不具合を見逃してしまいます。

回避策は、ケースを書く前に「このケースは2つ以上の要素をまたいでいるか」を問う習慣をつけることです。1つの画面や1つの処理で完結する確認は、単体テストに戻します。

粒度がばらばらで比較できない

複数人で分担すると、1行の重みが人によって大きく変わるという問題が起きます。ある人は1シナリオを1行にまとめ、別の人は確認項目ごとに行を分ける。この状態では進捗率も密度も意味を持ちません。

着手前にサンプルを1つ作り、「この粒度で書く」と合意しておくのが最も確実です。数行の見本があるだけで、認識のずれは大幅に減ります。

設計変更が反映されない

開発中の仕様変更が仕様書に反映されないまま実施され、本来確認すべき連携が抜け落ちるというケースもよく起きます。変更管理と仕様書の更新が切り離されていることが原因です。

変更が発生したら、影響するテストケースを洗い出すところまでを一連の作業として定義しておきます。あわせて改訂履歴を残し、どのバージョンの設計に対するテストなのかを明示しておいてください。

エビデンスが散らばって検証できない

実施は終わっているのに、証跡が各担当者の手元に散らばっていて第三者が確認できないという状態も少なくありません。監査や障害調査の場面で困ることになります。

保存場所と命名規則を最初に決め、仕様書からたどれるようにしておきます。ファイル名にテストケースIDを含めるだけでも、突き合わせの手間は大きく変わります。

作成と運用を効率化する方法

結合テスト仕様書の作成は、どうしても時間のかかる作業です。型化、ツール化、そして人の育成の3方向から手を打つことで、プロジェクトごとにゼロから積み上げる状態から抜け出せます。

テンプレートを標準化する

最初の一手は、社内で使う様式をひとつに決めることです。入力データ、操作手順、期待結果を同じ表形式で整理し、判定欄やエビデンスの残し方まで統一しておけば、案件をまたいだ比較やレビューが容易になります。

最初から項目を詰め込みすぎないことも大切です。最小限の構成から始め、実際に使ってみて足りなかった欄だけを追加していくほうが、定着します。使われない欄は削る前提で運用してください。

管理ツールで一元化する

表計算ソフトでの管理は手軽ですが、同時編集やバージョン管理、進捗の集計では限界が出ます。ケース数が数百を超えるようなら、テスト管理ツールやチケット管理ツールへの移行を検討する価値があります。

表計算ソフトを使い続ける場合でも、バージョン管理の仕組みに載せておくと変更履歴を追えます。どの時点の仕様書でテストしたのかが分かるだけで、後からの検証がしやすくなります。

生成AIを観点出しとケース作成に使う

近年増えているのが、生成AIを使った効率化です。設計書や画面遷移図をもとに観点の候補を出させ、人がそれを取捨選択するという使い方であれば、抜けの発見に役立ちます。

ただし、出力をそのまま仕様書にするのは避けてください。設計書に書かれていない前提を補って生成することがあり、確認すると事実と異なるケースが混ざります。あくまで叩き台として扱い、根拠との突き合わせは人が行う運用が安全です。

効果が出やすいのは、既存の仕様書を読み込ませて粒度の不統一や期待結果の曖昧な箇所を指摘させる使い方です。レビューの一次チェックとして使えば、人が見るべき論点に集中できます。業務全体の見直し方は業務効率化アイデア55選の記事でも整理しています。

書ける人を組織に増やす

ツールを入れても、観点を考えられる人がいなければ品質は上がりません。総務省の令和7年版情報通信白書では、日本企業がデジタル化に関して認識している課題として「人材不足」が48.7%と最も高く、他国と比べても突出していることが示されています（出典：総務省「令和7年版 情報通信白書」各国企業のデジタル化の状況）。

この状況で外部への委託だけに頼ると、社内に観点が蓄積されず、案件のたびに品質がばらつく構造になります。過去のプロジェクトで見つかった不具合を観点集としてまとめ、次のテスト設計に引き継ぐ仕組みを作ることが現実的な対策です。

担当を1人に任せきりにせず、レビューを通じて複数人が観点を共有する運用にしておくこと。この積み重ねが、結果的に最も確実な効率化になります。AIを含むスキルの育て方はAI研修の目的と選び方をまとめた記事も参考にしてください。

まとめ

結合テスト仕様書は、機能同士がつながる部分で何を確認するのかを事前に定義し、確認の証跡を残すための文書です。単体テストの延長として書くのではなく、処理が受け渡される結合点に焦点を当てることが出発点になります。

記載する項目は、管理情報を書くヘッダー部と、テストケースIDから判定欄までを並べるケース部の2層で構成します。特に前提条件と期待結果は、誰が実施しても同じ判定になる具体性まで書き込むことが重要です。

観点は、画面間の遷移、データの受け渡し、権限による差異、異常系と境界、外部連携とタイミングの5つで分類すると漏れにくくなります。作成は、結合点の洗い出し、観点の展開、データ準備、レビューという順で進めます。

網羅性は要件IDとのトレーサビリティで担保し、完了基準はテスト開始前に合意しておきます。そして、様式の標準化、ツールの活用、観点を書ける人を増やす取り組みを並行して進めることで、案件ごとの品質のばらつきを抑えられます。

▼ 開発プロセスの改善を、社内に定着する形で進めませんか 株式会社ネクストスケールでは、業務の棚卸しからドキュメント運用の設計、AI活用による効率化と社内への定着支援までを一貫してご支援しています。まずはお気軽にご相談ください。 ＞ 相談予約はこちら