UT・IT・STとは？テスト工程の略語と意味の違いを一覧で解説

テスト工程の略語が会議や見積書に飛び交う理由

システム開発の現場では、UT・IT・STといったテスト工程の略語が会議や見積書の中で当然のように使われます。開発ベンダーにとっては日常用語であるため、発注側への説明が省かれるケースも少なくありません。

略語を知らないまま発注を進めるとどうなるか

テスト工程の略語を理解していない状態で開発を進めると、具体的に3つの場面で判断が機能しなくなります。

• 進捗確認：「現在ITフェーズです」と報告を受けても、何がどこまで完了しているのかを把握できない
• 品質判断：テスト結果のエビデンスを見ても、どの工程で何を検証した結果なのかを読み解けない
• スケジュール管理：見積書に「ST：5営業日」と記載されていても、その工程の重さや承認タイミングを判断できない

発注側が意思決定者として機能するには、ベンダーと同じ言語でテスト工程を認識できていることが前提になります。

本記事で解説する略語の一覧と読み方

本記事では、開発現場で頻出するテスト工程の略語を発注側の視点から整理します。まずV字モデルを使って工程全体の位置関係を示し、UT（Unit Test：単体テスト）・IT（Integration Test：結合テスト）・ST（System Test：システムテスト）の目的と実施内容をそれぞれ解説します。さらにUAT・RT・ATなどの周辺略語や、現場によって読み方が異なるケースへの対処方法も取り上げます。

テスト工程の全体像 — V字モデルで工程の位置関係を把握する

V字モデルとは何か — 開発工程とテスト工程の対応関係

UT・IT・STの違いを理解するうえで、まず押さえておきたいのが「V字モデル」です。V字モデルとは、開発工程とテスト工程の対応関係を視覚的に示したフレームワークです。左側に上流から下流へ続く開発工程を、右側に対応するテスト工程を配置し、全体をV字型に表します。

具体的な対応関係は以下のとおりです。

• 詳細設計 ← 対応 → UT（単体テスト）：個々のプログラム単位の動作を確認する
• 基本設計 ← 対応 → IT（結合テスト）：複数のモジュールを組み合わせた連携を確認する
• 要件定義 ← 対応 → ST（システムテスト）：システム全体が要件を満たすかを確認する

この対応構造が重要な理由は、「何の設計に基づいてテストするか」が工程ごとに異なるからです。テスト工程の略語は単なる順番の名称ではなく、それぞれが検証する設計レベルを指し示しています。

テストは後ろから積み上げる — なぜ順番が重要なのか

V字モデルではテストをUT→IT→STの順に実施します。この順番には明確な理由があります。小さな単位の動作を先に保証しておかなければ、複数モジュールを組み合わせた際にどこで問題が起きたかを特定しにくくなるためです。

発注側の担当者にとって重要なのは、各テストフェーズの略語が「確認の範囲と責任の所在」を示しているという点です。会議や見積書でこれらの略語が登場したとき、どの設計レベルに対応したテストかを把握しておくと、ベンダーとの認識のずれを防ぎやすくなります。

UT（Unit Test）とは — 単体テストの目的と実施内容

UT（Unit Test）は「単体テスト」とも呼ばれ、「ユーティー」と読みます。システムを構成する最小単位のモジュールや関数が、設計どおりに動作するかを個別に確認するテスト工程です。

UTが確認する範囲 — モジュール単位とは何を指すか

UTが対象とするのは、システム全体ではなく「部品」の単位です。具体的には、ログイン処理を担う関数・金額を計算するロジック・データを変換する処理など、機能を構成する最小のコード単位を指します。それぞれを単独で動かし、想定した入力に対して正しい出力が返るかを検証します。

UTを実施するのは開発者自身です。コードを書いたエンジニアが、実装と並行してテストを行うケースが一般的です。開発の最も早い段階で実施されるため、バグを早期に発見・修正しやすく、後工程への影響を最小限に抑える効果があります。

発注側が押さえるべきUT工程の確認ポイント

発注側がUTを確認する際は、以下の点を開発会社に問い合わせておくと、品質管理の精度が高まります。

• エビデンスの形式：テスト仕様書・テスト結果一覧・スクリーンショットなど、どの形式で納品されるかを事前に確認します
• テスト網羅率（カバレッジ）：全体のコードのうち何割がテストされているかを示す指標です。一般的には80％以上を目安とするケースが多いです
• 実施者と承認フロー：開発者本人だけでなく、レビュアーが結果を確認する体制になっているかを確かめます

UTのエビデンスは、後工程の品質トレーサビリティにも影響します。纏まった形式で受け取れるよう、契約・要件定義の段階で明文化しておくことが望ましいです。

IT（Integration Test）とは — 結合テストの目的と実施内容

IT（Integration Test：インテグレーションテスト）は、日本語で「結合テスト」と呼ばれるテスト工程です。UTで個別に検証済みのモジュールやコンポーネントを組み合わせ、それらが連携して正しく動作するかを確認することが主な目的です。

単体では問題がなかった部品同士をつなぐと、インターフェースの仕様ズレや呼び出し順序の誤りといった問題が初めて表面化するケースがあります。ITはそうした「結合した際に生じる不具合」を早期に発見するために設けられているフェーズです。

IT1・IT2とは — 内部結合と外部結合の違い

ITはさらに細分化され、IT1（内部結合テスト）とIT2（外部結合テスト）に分けて実施されるプロジェクトが少なくありません。

• IT1（内部結合）：同一システム内のモジュール間の連携を確認します。たとえば、受注処理モジュールが在庫管理モジュールを正しく呼び出し、データを受け渡せているかどうかが検証対象になります。
• IT2（外部結合）：外部システムやAPIとの接続を確認します。決済サービスや基幹システムとのデータ連携など、自社システムの境界をまたぐインターフェースが主な確認範囲です。

IT1とIT2を明確に分けることで、問題が発生したときに「内部の連携ミスか、外部接続の仕様違いか」を切り分けやすくなります。発注側がベンダーと進捗を確認する際も、どちらの結合テストまで完了しているかを把握しておくと、品質状況の判断精度が上がります。

ITフェーズで検出されやすい問題の傾向

ITで発見される不具合には、以下のような傾向があります。

• モジュール間で受け渡すデータの型や桁数が一致していない
• 処理の呼び出し順序が設計と異なり、後続処理が正常に起動しない
• 外部APIのレスポンス形式が想定と異なり、エラーハンドリングが機能しない
• 複数モジュールが同一リソースを同時に更新するタイミングで競合が発生する

これらはUTの段階では検出が難しく、ITで初めて顕在化しやすい問題です。発注側の立場では、ITが完了している状態を「部品の動作確認が済んだ段階」ではなく「連携を含めた動作確認が済んだ段階」として捉えることが、工程管理上の誤認識を防ぐポイントになります。

ST（System Test）とは — システムテストの目的と実施内容

ST（System Test）は、日本語で「システムテスト」と呼ばれるテスト工程です。UT・ITを経て個々の機能や連携が確認された後、システム全体を一つの完成品として捉え、要件定義書や仕様書に定めた内容どおりに動作するかを確認します。

確認の対象は機能の正確性だけにとどまりません。性能・負荷・セキュリティ・操作性など、システムが本番環境で求められる非機能要件も含めて検証します。実施主体はベンダー側のQAチームや開発会社であり、発注側ではなく提供側が品質を保証する工程という位置づけです。

STの合格基準はどう設定するか

STの完了を判断するには、あらかじめ合格基準を文書化しておくことが重要です。一般的には以下のような基準が設定されます。

• 要件定義書に記載された全機能のテストケースを消化していること
• 重大度の高いバグ（致命的・高）が未解決のまま残っていないこと
• 性能要件（レスポンスタイムや同時接続数など）を満たしていること
• テスト結果報告書がベンダーから正式に提出されていること

発注側はST完了報告を受け取った際に、これらの基準が満たされているかをレビューする立場になります。報告書の内容が曖昧な場合は、未解決バグの一覧や性能測定データの提出を求めることが判断の精度を高めます。

STと受け入れテスト（UAT）はなぜ別工程なのか

STはベンダーが「仕様どおりに作れたか」を確認する工程です。一方、その後に実施される受け入れテスト（UAT：User Acceptance Test）は、発注側が「業務に使えるか」を確認する工程です。確認する主体も、問いかける観点も異なります。

STを通過したシステムであっても、実際の業務フローに照らすと操作手順が煩雑だったり、現場の運用ルールと合わない箇所が見つかるケースは少なくありません。この差を埋めるためにUATは独立した工程として設けられています。STの完了をもって発注側が即座に本番稼働を承認するのではなく、UATを経て最終的な受け入れ判断を行う流れが標準的です。

UT・IT・STの違いを一覧で比較 — 目的・実施者・確認範囲の対応表

UT・IT・STの3つのテストフェーズは、目的・実施主体・確認対象のいずれも異なります。以下の比較表では、一般的な解説でよく使われる軸に加えて、問題発見コストと発注側の関与度という2つの軸を追加しています。発注側が工程承認や予算管理を判断する際の参考にしてください。

発注側にとって特に重要なのは、STの段階での関与度が最も高いという点です。STで発見された問題は修正コストが跳ね上がりやすいため、UTやITの完了条件（テスト合格基準）をベンダーと事前に合意しておくことが、全体的な品質管理コストの抑制につながります。

周辺略語も押さえる — UAT・RT・ATなど他のテスト略称の意味

UT・IT・ST以外にも、開発会社との打ち合わせや見積書の中で略語が登場することは少なくありません。意味を把握しておくことで、会議の場での確認ミスや認識齟齬を防ぐことができます。

UAT（User Acceptance Test）とは — 受け入れテストと何が違うか

UAT（User Acceptance Test）は、発注側のユーザーや担当者が実際にシステムを操作し、要件どおりに動作するかを確認するテストです。日本語では「ユーザー受け入れテスト」と呼ばれます。

AT（Acceptance Test：受け入れテスト）と混同されやすいですが、UATは特に「ユーザー視点での確認」に重点を置いており、業務フローに沿った操作感や使い勝手まで評価対象に含まれます。ATはより広義の受け入れ確認全般を指す場合があるため、ベンダーとの間でどちらの意味で使っているかを確認しておくことが重要です。

RT（Regression Test）とは — リリース直前に実施する退行テストの役割

RT（Regression Test）は「退行テスト」または「リグレッションテスト」とも呼ばれます。機能追加やバグ修正を行った際に、既存の機能が意図せず壊れていないかを確認するテストです。

リリース直前や改修のたびに実施されることが多く、「修正が別の箇所に影響していないか」を検証する目的で使われます。開発が進むほど重要性が増すテストフェーズです。

その他のテスト略語一覧 — PT・AT・ETの意味

以下に、会議や仕様書で目にすることがある略語をまとめます。

• PT（Performance Test：性能テスト）：同時アクセス数や処理速度など、システムの負荷耐性を確認するテストです。
• AT（Acceptance Test：受け入れテスト）：発注側が納品物を検収する前に行う確認テストの総称です。UATを含む広義の概念として使われることがあります。
• ET（Exploratory Test：探索的テスト）：テスト担当者が仕様書に縛られず、自らシナリオを考えながら不具合を探すテスト手法です。

これらの略語は、現場やベンダーによって使い方が異なるケースがあります。略語が出てきた際は、その場で定義を確認する習慣をつけておくと、認識齟齬を防ぎやすくなります。

略語の読み方が現場によって異なるケース — 混乱を避けるための認識合わせ

UT・IT・STの意味は、必ずしも業界全体で統一されているわけではありません。同じ略語でも、会社やプロジェクトによって指す内容が異なるケースがあります。発注側がこの点を把握しておかないと、見積書や進捗報告の解釈がずれ、手戻りや認識齟齬の原因になります。

「IT」は情報技術（Information Technology）と同じ略語 — 文脈で使い分ける

「IT」という略語は、一般的には「Information Technology（情報技術）」を指す言葉として広く知られています。しかしソフトウェア開発の現場では、「Integration Test（結合テスト）」の略語としても使われます。同じ会議の中で「ITの予算」と「ITが終わった」という発言が混在すると、意味の取り違えが起こりやすくなります。

さらに、結合テストを「IT1」「IT2」と段階分けしている現場も少なくありません。IT1をサブシステム内の連携確認、IT2をシステム間の連携確認と定義するケースがある一方、プロジェクトによって定義の粒度や範囲は異なります。ベンダーが当然の前提としている定義が、発注側の理解と一致していない場合があります。

「ST」についても同様です。多くの現場ではSystem Test（システムテスト）を指しますが、一部のプロジェクトや企業では「受け入れテスト（Acceptance Test）」に近い意味合いで使われることがあります。UATと明確に区別されないまま「ST完了」と報告されると、発注側が想定していた確認範囲と実態がずれるリスクがあります。

プロジェクト開始前に定義を揃えるべき略語チェックリスト

こうした混乱を防ぐには、キックオフ時点で略語の定義を明文化することが有効です。以下の項目をベンダーに確認し、議事録や仕様書に記載しておくことを推奨します。

• UTの対象範囲：関数・クラス単位か、画面単位かなど、どの粒度を「単体」とみなすか
• ITの段階分け：IT1・IT2などの区分があるか、それぞれの確認範囲はどこまでか
• STとUATの関係：STとUATが別工程として設定されているか、STがUATを兼ねているか
• 各工程の完了条件：どのような基準をもって「完了」と判断するか

略語の意味を「なんとなく共有できている」と思い込んだまま進めると、テスト完了の判断基準や承認フローで認識がずれるリスクがあります。発注側がキックオフ時に定義を確認する習慣を持つことが、後工程の混乱を防ぐ最初の一手になります。

発注側が工程管理で意識すべきポイント — テスト完了の判断基準と承認フロー

テスト工程の略語（UT・IT・ST）を理解した上で、発注側が次に押さえるべきは「各フェーズをどのタイミングで完了と判断し、次工程への移行を承認するか」です。この判断を曖昧にしたまま進めると、後工程で手戻りが発生した際のコスト・スケジュール影響が大きくなります。

テスト完了報告書で確認すべき項目

ベンダーからテスト完了の報告を受けた際、以下の項目がエビデンスとして提示されているかを確認してください。

• テストケースの総数と消化数・合格数：「全100件中100件実施、合格率98%」のように数値で示されているか
• 未解決の不具合（バグ）の件数と重要度分類：件数だけでなく、重大度（致命的・高・中・低）ごとの内訳が明示されているか
• 次工程移行の判断根拠：残存バグを許容した理由と、対応時期の取り決めが記載されているか

特にUT（単体テスト）完了報告は開発者側で処理されがちなフェーズです。IT（結合テスト）やST（システムテスト）の完了報告と同様に、発注側が書面で確認する習慣を持つことが重要です。

手戻りが発生した場合の工程への影響と判断の流れ

STフェーズで重大な不具合が発見された場合、原因がUT・ITの検証漏れに起因するケースは少なくありません。この場合、修正対応だけでなく、前工程に遡った再テストが必要になり、スケジュールへの影響は複利的に拡大します。

発注側の意思決定者は、現場に対して次の問いを確認しておくとよいでしょう。

• この不具合はどのテストフェーズで検出できたはずか
• 再テストの対象範囲はどこまでか（ITのみか、UTに遡るか）
• リリース日を守るために品質基準を下げる場合、どのリスクを受け入れるか

手戻りが発生した際に「現場に任せる」だけでは、発注側がリスクの全体像を把握できないまま判断を迫られる事態になりかねません。各テストフェーズの完了条件と移行承認を契約・仕様の段階から明文化しておくことが、工程管理の実効性を高める基本です。

まとめ — テスト工程略語の理解が発注品質を左右する

UT（Unit Test：単体テスト）・IT（Integration Test：結合テスト）・ST（System Test：システムテスト）の三つは、それぞれ「個々の部品の動作確認」「部品間の連携確認」「システム全体の要件適合確認」という異なる目的を持ちます。確認する範囲も、実施する主体も、合否を判断する基準も工程ごとに異なります。

発注側にとってこれらの違いを把握することは、単なる知識習得ではありません。見積書に記載された工程の意味を誤解したまま承認すると、本来ST相当の確認が必要な箇所をIT止まりで納品されるリスクが生じます。逆に、どこまでが開発会社の責任範囲でどこからが発注側の検収範囲かを明確にするためにも、略語の定義を揃えておくことがプロジェクト品質の前提となります。

また、現場によってITを「インフラテスト」と読む場合があるなど、同じ略語でも意味が異なるケースは少なくありません。プロジェクト開始前に定義を文書化し、ベンダーと認識を合わせておくことが、後工程での手戻りを防ぐ実務的な対策です。

CLANEは開発支援の実務において、工程定義の明文化と各テストフェーズの品質基準の設定を、プロジェクト初期のすり合わせ項目として位置づけています。