外部結合テストとは 内部結合テストとの違い・観点と項目例、進め方と注意点を解説

「単体テストも内部結合テストも問題なく終わったのに、連携先とつないだ途端に不具合が噴出した」。システム開発の現場で繰り返し起きる状況です。

外部結合テストは、自社のシステムと他システムとの連携が仕様どおりに動くかを検証する工程です。結合テストを2段階に分けたときの後半にあたり、ITb（Integration Test B）と呼ばれます。

この工程が難しいのは、技術的な内容よりも自社だけで完結しないという点にあります。相手先の都合でスケジュールが動き、環境が用意されず、データの整合が取れない。準備不足のまま入ると、期間の大半を調整に費やすことになります。

この記事では、外部結合テストの位置づけと内部結合テストとの違いから、確認すべき観点、具体的な項目例、進め方の手順、そして特有の難所への対処までを順に整理します。

確認したいポイント	結論	詳細
外部結合テストとは？	他システムとの連携を検証する工程	結合テストを2段階に分けたときの後半で、サブシステム間や外部システムとのデータ連携を確認します。
内部結合テストとの違いは？	検証する範囲が内側か外側かの違い	内部は同一サブシステム内の機能連携、外部はサブシステム間や他システムとの連携を対象にします。
何を確認する？	仕様どおりにデータが渡るか	項目の値と形式、業務シナリオの一気通貫、異常時の挙動、タイミングのずれが主な観点になります。
最大の難所は？	相手先との調整と環境の確保	自社だけで完結しないため、スケジュール、環境、データの3点について事前の合意が欠かせません。

この記事でわかること

• 外部結合テスト（ITb）の位置づけと、内部結合テスト（ITa）との具体的な違い
• インターフェース、業務シナリオ、異常系など確認すべき6つの観点
• API連携、ファイル連携、外部サービス連携それぞれのテスト項目の例
• 連携一覧の作成から完了判定までを通した6ステップの進め方
• 相手先との調整や環境確保など、この工程に特有の難所と現実的な対処法

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発の依頼範囲の決め方、費用と期間の目安を1冊にまとめました。社内での検討材料としてご活用いただけます。 ▶ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

外部結合テストとは｜結合テストの後半にあたる工程

ソフトウェアのテストは、一般に単体テスト、結合テスト、システムテスト、運用テストという順で進みます。外部結合テストは、このうち結合テストに含まれる工程です。

規模の大きなシステムでは、結合テストを2段階に分けて実施することがあります。前半を内部結合テスト、後半を外部結合テストと呼び、段階的に結合の範囲を広げていくという考え方です。

IPA（情報処理推進機構）が公開する共通フレーム2013は、開発から運用までのライフサイクルで必要な作業項目と役割を包括的に規定し、関係者が同じ言葉で話せるようにすることを目的としています。工程の呼び方が現場ごとに違うという問題は、まさにこうした共通化が必要とされる領域です。

ITbと呼ばれる理由と位置づけ

結合テストは英語でIntegration Testと表記します。これを2段階に分けたとき、前半をITa（Integration Test A）、後半をITb（Integration Test B）と呼びます。外部結合テストはITbにあたり、「外結」と略されることもあります。

この呼び方は国際規格で定義された正式な用語ではなく、日本国内の開発現場で広く使われている実務的な表現です。そのため、組織によって範囲の定義が微妙に異なるという点は認識しておく必要があります。

プロジェクトに参加した際は、まず自社と相手先で「外部結合テストで何をどこまで確認するのか」の認識を合わせます。ここがずれたまま進むと、テスト工程の終盤で抜けが発覚します。

何を確認する工程なのか

外部結合テストで確認するのは、サブシステム間、あるいは他システムとの機能連携が意図どおりに動くかという点です。単体テストや内部結合テストで個々の部品と自社内の連携が確認済みであることが前提になります。

たとえばECサイトであれば、商品ページに在庫管理システムの在庫数が正しく表示されるか、購入確定後に決済代行サービスへ正しく連携されるかといった確認が該当します。

また、基幹システムから会計システムへのデータ連携、勤怠システムから給与システムへの月次データ受け渡しなども典型例です。業務が複数のシステムをまたいで成立している箇所が、そのまま検証の対象になります。

V字モデルにおける対応関係

テスト工程は、設計工程と対になる形で位置づけられます。これがV字モデルと呼ばれる考え方です。外部結合テストは、基本設計や外部設計で定めた内容を検証する工程にあたります。

具体的には、外部設計で作成したインターフェース仕様書が検証の根拠になります。どの項目を、どの形式で、どのタイミングで渡すのかという取り決めが、そのままテストケースの元になります。

この対応関係を意識しておくと、テストケースの抜けを設計書から機械的に洗い出せます。逆に、仕様書が曖昧なままだと、何を確認すればよいかを毎回議論することになります。

内部結合テストとの違い

混同されやすい2つの工程ですが、検証する範囲、関係者、見つかる不具合の性質という3つの点で明確に異なります。

検証する範囲が違う

最も基本的な違いです。内部結合テストは同一サブシステム内のモジュール間の連携、外部結合テストはサブシステム間や他システムとの連携を対象にします。

たとえば「一覧画面で項目を選択すると詳細画面が表示される」という画面遷移は、同一システム内で完結するため内部結合テストの範囲です。

一方で「システムAからシステムBへデータを送信する」という処理は、システムをまたぐため外部結合テストで確認します。境界がどこにあるかを設計段階で明確にしておくことが、両者の切り分けの前提になります。

関係者と調整の重さが違う

実務上、この差が最も大きく影響します。内部結合テストは自チームだけで完結しますが、外部結合テストは相手先との合意なしには1件も実施できません。

相手が社内の別部門であればまだしも、別会社が開発しているシステムや外部のサービスが相手になると、環境の準備、日程の確保、担当者の稼働すべてに調整が必要になります。

そのため、外部結合テストの工数見積もりでは、テストの実施時間より調整の時間を厚く見る必要があります。ここを軽視した計画は、ほぼ確実に遅延します。

見つかる不具合の性質が違う

内部結合テストで見つかるのは、主にプログラムの実装誤りです。分岐条件の誤り、値の受け渡しミスといった、自チーム内で修正できるものが中心になります。

対して外部結合テストで見つかるのは、仕様の解釈違いに起因する不具合が多くを占めます。項目の桁数の認識が違う、日付の形式が違う、必須と任意の扱いが違うといったものです。

この種の不具合は、どちらが直すのかという議論から始まります。技術的な修正より、合意形成のほうに時間がかかるという点が、この工程の特徴です。

どこで線を引くかは案件ごとに決める

ここまで区別して説明してきましたが、実際の線引きはプロジェクトによって異なります。前述のとおりITaとITbは正式な規格用語ではないためです。

サブシステム間の連携を内部結合テストに含める組織もあれば、社内であっても別チームが担当する範囲はすべて外部結合テストとする組織もあります。

重要なのは、どちらの呼び方が正しいかではなく、抜けと重複がないことです。テスト計画の段階で、どの連携をどの工程で確認するかを一覧にして関係者で確認します。

外部結合テストで確認する6つの観点

何を確認すべきかが曖昧なままだと、正常系を1回通しただけで完了としてしまいます。本番で問題になるのは、たいてい正常系以外です。ここでは押さえておくべき観点を6つに整理します。

観点1｜インターフェース仕様どおりにデータが渡るか

最も基本的な観点です。送信側が渡した値が、受信側で仕様どおりに解釈されるかを確認します。項目の対応、桁数、データ型、必須と任意の扱いが主な確認点になります。

見落としやすいのが形式の細部です。日付が「2026/09/13」なのか「20260913」なのか、金額に小数点を含むのか、コード値の前ゼロを保持するのか。こうした点は仕様書に書かれていないことも多く、実際につないで初めて発覚します。

文字コードと文字種も確認します。機種依存文字、外字、絵文字、半角カナが渡ったときにどうなるかは、実際のデータで試さないと分かりません。

観点2｜業務シナリオが端から端まで通るか

個々の連携が動くことと、業務が成立することは別です。利用者が実際に行う一連の操作を、最初から最後まで通して確認します。

ECサイトであれば、商品を選ぶ、在庫を確認する、購入手続きに進む、決済する、受注データが基幹システムに登録される、出荷指示が倉庫システムに渡るという流れを1本のシナリオとして実行します。

この観点でテストすると、個別の連携では見えなかったデータの不整合が浮かび上がります。前工程で作られたIDが後工程で見つからない、といった問題が典型です。

観点3｜異常系とエラー処理

実務で最も抜けやすく、本番障害に直結する観点です。相手システムが応答しない、エラーを返す、想定外の値を返すという状況で、自システムが正しく振る舞うかを確認します。

• 通信エラー：相手が停止している、ネットワークが切れた場合の挙動とリトライ
• タイムアウト：応答が返らない場合に何秒で打ち切り、その後どうするか
• 業務エラー：相手側がエラーコードを返した場合の画面表示とログ記録
• 不正データ：桁あふれ、必須項目の欠落、存在しないコード値を受け取った場合

特にリトライの設計は要注意です。同じ処理を再送した結果、二重登録が発生するという事故は珍しくありません。重複を防ぐ仕組みが機能するかまで確認します。

観点4｜タイミングと非同期処理

リアルタイム連携とバッチ連携が混在するシステムでは、処理の順序が問題になります。先に届くはずのデータが後から届いたとき、どうなるかを確認します。

夜間バッチの実行中に画面から更新が入った場合、日をまたぐ処理で日付の扱いがずれる場合、同じデータに対して複数の処理が同時に走る場合。これらは机上では見つけにくく、実際に動かして初めて表面化します。

処理が失敗した後の再実行も確認します。バッチが途中で止まったとき、最初からやり直すのか、途中から再開するのかによって、必要な仕組みが変わります。

観点5｜性能とデータ量

少件数では問題なく動いても、本番相当の量を流すと破綻することがあります。実運用で想定される最大件数を流して、時間内に処理が終わるかを確認します。

特に注意が必要なのがバッチ連携です。月次で数万件、年次で数十万件といったピークの件数で試さないと、本番の締め処理で時間内に終わらないという事態が起こります。

APIの場合は、同時アクセス数と相手側の流量制限を確認します。1分あたりの呼び出し回数に上限が設けられているサービスは多く、制限を超えると処理が失敗します。

観点6｜セキュリティと権限

外部と接続する以上、避けて通れない観点です。認証情報が正しく扱われているか、通信が暗号化されているか、権限のないデータにアクセスできないかを確認します。

証明書の有効期限、APIキーの管理方法、通信経路の制限といった設定面も対象に含めます。テスト環境では通っていた通信が、本番のファイアウォール設定では遮断されるという事例は頻発します。

また、連携するデータに個人情報が含まれる場合は、取り扱い範囲が契約や社内規程に沿っているかも確認します。技術的に動くかどうかとは別の観点です。

連携方式別のテスト項目例

観点を実際のテスト項目に落とし込む際は、連携方式ごとに考えると抜けが減ります。ここでは代表的な4つの方式について例を挙げます。

API連携の項目例

リアルタイムでシステム同士がやり取りする方式です。リクエストとレスポンスの1往復ごとに確認項目を設けます。

• 正常なリクエストに対して期待どおりのレスポンスが返る
• 必須パラメータを欠いた場合に、仕様どおりのエラーコードが返る
• 認証エラー、権限エラーの場合の挙動とメッセージ
• タイムアウト時のリトライ回数と、上限到達後の処理
• 流量制限に達した場合の待機と再送
• レスポンスの項目が想定外の値だった場合の耐性

ファイル連携の項目例

CSVや固定長ファイルを受け渡す方式です。ファイルの中身だけでなく、受け渡しの運用面まで含めて確認します。

• ファイル名の命名規則、配置先フォルダ、権限が仕様どおりか
• ヘッダー行、トレーラー行、件数チェックが正しく機能するか
• 文字コード（UTF-8、Shift_JISなど）と改行コードの一致
• 0件のファイルが届いた場合、ファイル自体が届かない場合の挙動
• 同じファイルが二重に配置された場合の重複防止
• 取り込み失敗時に、ファイルを退避して再取り込みできるか

画面をまたぐ業務フローの項目例

利用者の操作が複数システムをまたぐ場合の確認です。シナリオ単位で1件とし、各画面での表示内容と裏側のデータを両方見ます。

• 一連の操作を通して業務が完了し、各システムに正しくデータが残る
• 途中で処理を中断した場合、不整合なデータが残らない
• 遷移先のシステムで、引き継いだ情報が正しく表示される
• 権限のないユーザーが遷移した場合に、適切に制御される

外部サービス連携の項目例

決済代行、配送、地図、メール配信といった社外サービスとの連携です。相手の仕様を変更できないという前提での確認になります。

多くのサービスにはサンドボックス環境（検証用の環境）が用意されています。まずここで一通りの動作を確認し、その後に本番相当の環境で最終確認を行うという二段構えが基本です。

確認すべきは、サービス側のエラーパターンを網羅できているかという点です。決済であれば、カード拒否、限度額超過、二重決済防止、返金処理まで含めて試します。

仕様の解釈が分かれやすい箇所については、外部設計の段階で明文化しておくことが前提になります。書き方の考え方は要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集も参考になります。

テスト計画の妥当性や体制づくりからご相談いただけます 観点は分かっても、自社の連携で何が抜けているかの判断は簡単ではありません。計画段階からご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

外部結合テストの進め方｜6ステップ

この工程は、実施そのものより準備で成否が決まります。順を追って整理します。

ステップ1｜連携一覧を作成する

最初にやるべきは、このシステムが外部とやり取りするすべての接点を一覧にすることです。ここが漏れると、そのままテストの漏れになります。

一覧には、連携相手、連携方式、方向（送信か受信か）、タイミング（リアルタイムかバッチか）、対象データ、想定件数、担当者を記載します。外部設計書のインターフェース定義から機械的に作成できます。

この一覧が、そのままテスト範囲の合意資料になります。相手先とも共有し、認識に齟齬がないかを確認しておきます。

ステップ2｜テスト計画で範囲と体制を決める

連携一覧をもとに、何を、いつ、誰が、どこまで確認するかを計画に落とします。特に重要なのが、相手先との役割分担と完了基準です。

不具合が出たときに、どちらが調査を主導するのか。修正の判断は誰がするのか。日程を変更する場合の連絡先はどこか。これらを事前に決めておかないと、問題が起きた瞬間に手が止まります。

スケジュールには、相手先の都合で動く前提のバッファを明示的に組み込みます。実施日をぎりぎりに置くと、1度の延期でリリース全体が押します。

ステップ3｜環境とデータを準備する

外部結合テストには、両者がつながる環境が必要です。この環境の確保が、実際には最も時間のかかる作業になることが少なくありません。

ネットワークの疎通、ファイアウォールの設定、証明書の配置、アカウントの発行。これらは自社だけでは完結せず、相手先の情報システム部門の作業を待つことになります。

テストデータも同様です。両者のマスタデータが一致していないと、テストは1件も通りません。顧客コード、商品コード、部門コードといった共通のキーを事前に突き合わせておきます。

ステップ4｜疎通確認を先に済ませる

本番のテストケースに入る前に、最小限のデータを1件だけ流して、つながることを確認します。この段階を省略すると、環境の問題と実装の問題が混ざって切り分けができなくなります。

疎通確認では、接続できること、認証が通ること、何らかの応答が返ることだけを見ます。データの中身が正しいかどうかは、この段階では問いません。

疎通確認は、テスト開始予定日より前に済ませておくのが理想です。ここでつまずくと、確保した実施日程がまるごと無駄になります。

ステップ5｜シナリオを実施して記録する

計画に沿ってテストを実施します。外部結合テストでは、両者の担当者が同時に立ち会う時間帯を確保するのが基本です。片方だけで実施すると、問題が起きたときの調査が翌日以降になります。

記録は、実施日時、実行者、送信したデータ、受信したデータ、判定結果をセットで残します。通信ログや連携ファイルの実物を証跡として保管しておくと、後から原因を追う際に役立ちます。

不具合が出た場合は、どちら側の問題かを決めつけずに、まず事実だけを共有します。「そちらのデータがおかしい」から始めると、調査より先に対立が生まれます。

ステップ6｜完了基準で判定する

全ケースを実施したら、事前に定めた完了基準に照らして判定します。「すべて消化した」だけでは完了の根拠になりません。

一般的な基準は、計画したケースの消化率、未解決の不具合件数とその重要度、再テストの完了状況です。重大な不具合が残っている場合は、その扱いを関係者で合意したうえで次工程に進みます。

IPAが公開するソフトウェア開発分析データ集では、技術者の経験と勘に頼るのではなく、実際のプロジェクトデータにもとづく定量的な管理が必要だと述べられています。判定を感覚で行わないための拠り所として、こうした指標の考え方が役立ちます。

外部結合テスト特有の難所と対処

ここからは、計画どおりに進まない典型的なパターンと、その現実的な対処法を整理します。いずれも事前に手を打てるものです。

相手先の都合でスケジュールが動く

最も頻発する問題です。相手側の開発が遅れている、担当者が別案件で稼働できない、環境が用意できないといった理由で、予定していた日程が動きます。

対処は2つあります。1つは、実施日程を早めに押さえ、余裕をもった位置に置くこと。もう1つは、相手先の進捗を定期的に確認する場を設けることです。

「予定日の1週間前に確認したら、まだ着手していなかった」という事態を避けるには、週次で状況を共有する仕組みが必要です。待つのではなく、こちらから取りに行く姿勢が求められます。

テスト環境が用意されない

相手先に検証用の環境がなく、本番環境しか存在しないというケースもあります。この場合、本番でテストするわけにはいかないため、別の手段が必要です。

現実的な選択肢はスタブによる代替です。相手システムの応答を模擬するプログラムを自作し、まずはそれとつないで自社側の実装を確認します。

ただし、これはあくまで暫定策です。スタブは自分たちが理解した仕様に基づいて作るため、解釈が間違っていればスタブも間違ったままになります。実機での確認を完全に置き換えることはできません。

テストデータの整合が取れない

両者のマスタが揃っていないために、テストが進まないという状況です。自社では登録されている顧客コードが、相手側には存在しないといったケースです。

対処は、テストで使用するデータを事前に一覧化し、両者で同じものを登録しておくことです。「テスト用顧客A」「テスト用商品001」といった共通のデータセットを決めておきます。

本番相当のデータを使いたい場合は、個人情報の扱いに注意します。氏名や連絡先はマスキングしたうえで、件数と分布だけを再現するのが一般的な進め方です。

不具合の原因切り分けが難しい

自社側の実装なのか、相手側の実装なのか、環境の問題なのか。どこに原因があるか分からないまま時間が過ぎるというのが、この工程の最大の消耗要因です。

切り分けを速くするには、両者が同じ情報を見られる状態を作ります。送信したデータの実物、受信したデータの実物、それぞれのログ。この3点が揃えば、大半は短時間で判別できます。

ログの出力レベルをテスト期間中だけ詳細にするという準備も有効です。本番想定の設定のままだと、必要な情報が記録されていないことがあります。

仕様の解釈違いが後から発覚する

テスト中に「そういう意味だとは思わなかった」という会話が出たら、それは設計工程の積み残しです。この段階での仕様変更は、双方に手戻りを生みます。

予防策は、外部設計の段階でインターフェース仕様書を両者で読み合わせ、サンプルデータを添えて合意しておくことです。文章だけの仕様書は、必ず解釈の幅を生みます。

実際の値が入ったサンプルを1件添えるだけで、認識の差は大きく減ります。仕様書に「日付：YYYYMMDD形式」と書くより、「日付：20260913」と書くほうが誤解が起きません。

発注側として確認しておきたいこと

システム開発を外部に委託している立場であれば、外部結合テストの計画をそのまま受け取るのではなく、いくつかの点を確認します。ここでの見落としは、後の追加費用や納期延長につながります。

自社が担う作業が計画に含まれているか

外部結合テストでは、発注側にしかできない作業が必ず発生します。既存システムを運用している情報システム部門との調整、社内のネットワーク設定、既存データの提供などです。

これらが計画に入っていないと、テスト開始日になって「そちらの準備待ちです」という状況になります。連携一覧を受け取った時点で、自社側の作業を洗い出しておきます。

委託範囲の考え方についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方でも整理しています。

相手先との調整責任がどちらにあるか

連携相手が既存ベンダーや外部サービスの場合、誰が窓口になって調整するのかを契約段階で決めておきます。ここが曖昧だと、両者が相手の対応を待つ状態になります。

一般に、既存システムを保守しているベンダーとの調整は、発注側が窓口になるほうがスムーズです。契約関係がない開発ベンダーからの依頼には、相手が応じる義務がないためです。

調整に必要な期間も見込んでおきます。相手先が対応するには、その会社の中でも稟議や工数確保が必要であり、依頼してすぐ動くとは限りません。

完了基準が定義されているか

「テストが終わった」という判断を誰がどう下すのかを確認します。基準がないと、不具合が残ったまま次工程に進む、あるいは終わらないまま延々と続くという両極端になります。

確認すべきは、テストケースの網羅範囲、消化率の目標、残存不具合の許容水準、そして判定を行う会議体です。これらが計画書に記載されていない場合は、記載を求めます。

社内に開発の知見が少なく判断に自信が持てない場合は、計画段階から支援を受ける方法もあります。進め方はシステム開発｜AIを活用した開発支援で紹介しています。

まとめ

外部結合テストは、結合テストを2段階に分けたときの後半にあたり、サブシステム間や他システムとの連携が仕様どおり動くかを検証する工程です。ITbとも呼ばれますが、正式な規格用語ではないため、範囲の定義はプロジェクトごとに確認が必要です。

確認すべき観点は、インターフェースの整合、業務シナリオの一気通貫、異常系とエラー処理、タイミングと非同期、性能とデータ量、セキュリティと権限の6つです。特に異常系は抜けやすく、本番障害に直結します。

進め方は、連携一覧の作成から始めます。計画で役割分担と完了基準を決め、環境とデータを準備し、疎通確認を先に済ませてから本番のケースに入ります。

この工程の難しさは技術面よりも調整面にあります。相手先の都合で動く前提でスケジュールを組み、こちらから進捗を確認しに行くという姿勢が、遅延を防ぐ最大の要素です。

まずは、自社のシステムが外部とやり取りしている接点をすべて洗い出すところから始めてください。一覧ができれば、何をどこまで確認すべきかは自然と見えてきます。

システム開発の進め方から、無料で相談できます 受け取ったテスト計画の妥当性を判断したい、社内に開発の知見がなく不安があるといった段階のご相談も承っています。営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎