サニティテストとは スモークテストとの違いと実施タイミング・項目の決め方を解説

「バグを修正したビルドを受け取ったが、いきなり全項目のテストをやり直すのは時間がかかりすぎる」。開発と検証を繰り返す現場では、日常的に発生する状況です。

サニティテストは、修正が意図どおりに反映されているかを短時間で確認するテストです。本格的な検証に入る前に、そもそもテストを進められる状態かを見極める役割を持ちます。

ただし、この用語には注意が必要です。スモークテストとの違いを説明する記事が多数ある一方で、公式の用語集では両者が同義語として扱われています。この食い違いが、現場での混乱を生んでいます。

この記事では、サニティテストの役割と他のテストとの違いを整理したうえで、用語の揺れをどう扱うか、実施のタイミング、項目の決め方、そして自動化との組み合わせまでを順に整理します。

確認したいポイント	結論	詳細
サニティテストとは？	修正が正しく反映されたかの確認	改修後に、修正箇所とその周辺が意図どおり動くかを短時間で確認するテストを指します。
スモークテストとの違いは？	狭く深くか、広く浅くか	サニティは修正箇所を絞って深く、スモークはシステム全体を広く浅く確認するとされます。
用語は統一されている？	公式の用語集では同義語扱い	ISTQBの用語集では区別されていません。チーム内で定義を合意しておく必要があります。
項目はどれくらい？	短時間で終わる範囲に絞る	増やしすぎると、迅速に確認するという本来の目的が成り立たなくなります。

この記事でわかること

• サニティテストが担う役割と、実務で使われる場面
• スモークテスト、リグレッションテスト、再テストとの違いの整理
• 公式の用語集では同義語とされている事実と、現場での扱い方
• 実施するタイミングと、テスト項目を選ぶときの判断基準
• 自動化に向く部分と向かない部分、そしてよくある失敗への対策

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

サニティテストとは

サニティテストは、プログラムの変更やバグ修正が行われた後、その修正が期待どおりに機能しているかを迅速に確認するテストです。あわせて、他の部分に予期せぬ影響が出ていないかも見ます。

特徴は、対象を絞り込んで短時間で終えることです。全機能を確認するのではなく、変更が加わった箇所とその周辺だけに焦点を当てます。

本格的なテストの前段階に位置づけられる

実施されるのは、開発者が修正を完了し、テストチームがそれを受け取った直後です。本格的な回帰テストに入る前の予備的な確認という位置づけになります。

ここで問題が見つかれば、その時点で開発側に差し戻します。修正が正しく入っていないビルドで数日かけて全項目を消化しても、その工数は無駄になるためです。

テストチームの工数を守るための仕組みだと捉えると、目的が理解しやすくなります。動かないものをテストし続ける状態を防ぐことが狙いです。

名前の由来

サニティ（sanity）は、正気、健全さを意味する語です。「まともに動く状態か」を確かめるという含みがあります。

対になる語としてよく登場するスモークテストは、電子機器の電源を入れて煙が出ないかを確かめる作業に由来するとされています。どちらも、深く調べる前の最低限の確認という点で共通しています。

日本語で定訳がなく、そのままカタカナで使われるため、意味の理解が人によってばらつきやすい用語でもあります。

実務での目的

現場で期待される効果は、主に次の3点です。

• 手戻りの防止：修正が入っていないビルドで検証を進めてしまう事態を避ける
• コストの削減：全項目の再テストを毎回行わずに済ませる
• 開発サイクルの高速化：短時間で合否を判断し、次の工程へ素早く進める

修正のたびに全項目をやり直していては、開発の反復速度が落ちます。サニティテストは、その間を埋める現実的な妥協点として機能します。

用語の定義が揺れているという問題

この用語を扱ううえで、最初に知っておくべき事実があります。サニティテストという言葉には、広く共通した定義が存在しません。

公式の用語集では同義語とされている

ソフトウェアテストの技術者資格を運営するISTQBの用語集では、サニティテストはスモークテストの同義語として扱われています。コンフィデンステストも同じ扱いです。

そこでのスモークテストの定義は、計画した全テストケースのサブセットであり、プログラムの必須機能が正常に動作することを確認するもの、とされています。主要機能を網羅し、細かな点は無視するという説明です。

実務では別概念として使われることが多い

一方で、実務の現場や多くの解説記事では、サニティテストとスモークテストを別のものとして説明しています。この説明も広く受け入れられています。

その整理では、スモークテストはシステム全体を広く浅く確認するもの、サニティテストは特定の変更箇所とその周辺を狭く深く確認するもの、とされます。実施のタイミングも異なるとされます。

どちらが正しいという問題ではありません。公式の用語集は資格試験と国際的な共通言語のための定義であり、現場の使い分けはそれとは別の実務上の慣習として発展したものです。

チームで定義を合意しておく

この状況で最も避けるべきなのは、定義を確認しないまま作業を進めることです。「サニティテストをお願いします」という指示が、人によって違う内容を意味してしまいます。

対策は単純で、プロジェクトの開始時にテストの種類とその定義を一覧にまとめ、関係者で合意することです。名前は何でも構いません。何をどこまで確認するのかが揃っていればよいのです。

テスト計画書に、各テストの目的、対象範囲、実施タイミング、合否基準を記載します。この一覧があると、外部にテストを委託する際の認識合わせにもそのまま使えます。

この記事では以降、実務で広く使われている「修正箇所を狭く深く確認する」という意味でサニティテストを扱います。

他のテストとの違い

似た目的を持つテストがいくつかあります。それぞれの役割を整理しておくと、使い分けの判断がしやすくなります。

スモークテストとの違い

最も比較される相手です。実務での一般的な整理では、次のように区別されます。

• スモークテスト：システム全体を広く浅く。起動する、ログインできる、主要画面が開くといった最低限の動作を確認する
• サニティテスト：修正箇所を狭く深く。特定の変更が意図どおり反映され、周辺に影響が出ていないかを確認する

確認する順序としては、スモークが先、サニティが後という関係になります。まず全体が起動するかを見て、次に今回の修正内容を見るという流れです。

ただし前章のとおり、この区別は公式に定義されたものではありません。チームによっては両方をまとめて1つの工程として扱うこともあります。

リグレッションテストとの違い

リグレッションテスト（回帰テスト）は、修正によって既存の機能が壊れていないかを網羅的に確認するテストです。デグレードの検出が目的になります。

サニティテストとの違いは範囲と深さです。サニティは影響が及びそうな範囲に絞って短時間で行い、リグレッションは既存機能全体を対象に時間をかけて実施します。

サニティテストで問題がなければ、リグレッションテストに進むという順序が一般的です。サニティで止まったビルドをリグレッションに回しても、時間の無駄になります。

再テスト（確認テスト）との違い

再テストは、報告した不具合が修正されたことを、その不具合の再現手順で確認するテストです。対象は個々の不具合票になります。

サニティテストはこれを含みつつ、周辺への影響も見ます。修正された不具合が直っていることに加え、その修正で他が壊れていないかまでを確認範囲に含めるという違いです。

実務では、再テストとサニティテストをまとめて実施することも多くあります。不具合票を消化しながら、あわせて周辺機能も触るという進め方です。

4つのテストを一覧で整理する

混乱を避けるため、目的と範囲で並べておきます。実施の順序としては、上から下へ進みます。

• スモークテスト：全体が動くか。範囲は広く、深さは浅い。所要時間は最も短い
• 再テスト：報告した不具合が直ったか。範囲は個々の不具合
• サニティテスト：修正が意図どおりか。範囲は修正箇所とその周辺
• リグレッションテスト：既存機能が壊れていないか。範囲は広く、時間もかかる

この4つを毎回すべて実施する必要はありません。修正の規模とリリースの重要度に応じて、どこまでやるかを決めます。

テスト工程の設計や体制づくりからご相談いただけます 違いは分かっても、自社の開発でどこまで確認すべきかの判断は別の問題です。工程の設計からご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

実施するタイミング

いつ行うかによって、確認すべき内容も変わります。主に3つの場面があります。

修正版のビルドを受け取った直後

最も典型的な場面です。開発者から修正版が渡されたら、本格的な検証に入る前にサニティテストを実施します。

ここで修正が反映されていないことが判明すれば、すぐ差し戻せます。数分から十数分の確認で、数日分の工数を守れる可能性があります。

受け取ってすぐに実施することが重要です。他の作業を挟んでから着手すると、問題の発見が遅れ、開発側の手戻りも大きくなります。

本格的なテストに入る前の判定として

テストフェーズの開始条件として位置づける方法です。サニティテストに合格しなければ、その先の工程に進まないというルールにします。

この運用にすると、テストチームが不安定なビルドに振り回されなくなります。開発側にとっても、どの水準まで作り込んでから渡すべきかが明確になります。

合否の基準を事前に文書化しておくことが前提です。基準がないと、その場の判断で「まあ進めましょう」となり、ルールが形骸化します。

リリース直前の最終確認として

本番環境へ反映した直後に、主要な機能が動くことを確認する場面でも使われます。環境の違いによる問題を早期に検出する目的です。

検証環境では動いていたのに本番では動かない、という事態は珍しくありません。設定値、接続先、証明書といった環境固有の要素が原因になります。

この確認は、リリース手順書の中にリリース後の確認手順として組み込んでおきます。誰が何を確認するかを事前に決めておけば、深夜作業でも判断に迷いません。

テスト項目の決め方

サニティテストの成否は、項目の選び方で決まります。多すぎれば時間がかかり、少なすぎれば見逃します。

修正箇所そのものを確認する

最初に入れるのは、今回修正された内容が意図どおり動くかという項目です。不具合票や変更依頼の内容から、そのまま導き出せます。

確認するのは、修正前に発生していた問題が起きないことと、修正によって期待される挙動になっていることの2点です。片方だけでは不十分です。

正常系だけでなく、境界値や異常系も1件は入れます。修正が特定の条件でしか効いていないというケースを検出できます。

影響範囲を絞り込む

次に、その修正が波及しそうな箇所を選びます。ここが最も判断力を要する部分です。

手がかりになるのは、変更されたソースコードの範囲です。共通処理に手を入れたなら、それを使っているすべての機能が候補になります。特定の画面だけの修正なら、範囲は限定されます。

開発者に影響範囲を確認するのが最も確実です。「どこに影響しますか」と聞くだけで、テスト項目の精度が大きく上がります。この確認を省略しないでください。

件数と実行時間の目安

短時間で終えることが前提であるため、時間の上限を先に決めます。現場でよく使われる目安は、手動なら15分程度、自動化していれば5分程度です。

件数に換算すると、10件から20件程度に収まることが多くなります。修正の規模が大きい場合はこれを超えますが、1時間を超えるならサニティテストの範囲を逸脱しています。

時間内に収まらない場合は、リグレッションテストとして別に計画します。サニティテストに詰め込むと、迅速な判断という目的が達成できなくなります。

項目を増やしすぎない

最も多い失敗が、項目の肥大化です。「念のため」で追加された項目が積み重なり、気づけば実施に半日かかる状態になります。

こうなると、実施が後回しにされるようになります。結果として、当初防ぎたかった「動かないビルドで時間を失う」事態が再発します。

対策は、項目を追加するときに何かを削るというルールを設けることです。上限件数を決めておき、超える場合は優先度の低い項目を外します。

実施の手順

実際の進め方を5つのステップで整理します。準備に時間をかけすぎないことが、この工程では特に重要です。

ステップ1｜修正内容を把握する

何がどう変わったのかを確認します。不具合票の内容、変更されたモジュール、開発者のコメントが情報源になります。

この情報が不十分だと、次のステップで影響範囲を判断できません。開発側に、修正内容と影響範囲を記載してもらう運用にしておくと効率が上がります。

ステップ2｜影響範囲を特定する

修正が波及しうる機能を洗い出します。共通処理か個別処理か、データベースの構造に変更があるかといった観点で判断します。

判断に迷う場合は、範囲を広めに取ります。ただし広げすぎると時間が超過するため、優先順位をつけて上位から確認します。

ステップ3｜項目を選ぶ

既存のテストケースから該当するものを抽出するか、新たに項目を書き起こします。毎回ゼロから作らず、前回の項目を土台にすると効率的です。

サニティテスト用のテストケース一覧をあらかじめ用意しておき、修正内容に応じて必要なものを選ぶという運用もあります。

ステップ4｜実施して判定する

項目に沿って実行し、結果を記録します。合否の判定基準を事前に決めておくことが前提です。

1件でも重大な不具合が出たら、その時点で差し戻すというルールが一般的です。軽微な不具合をどう扱うかも、あらかじめ決めておきます。

判断に迷う結果が出たら、進めずに確認します。「たぶん問題ない」で先へ進むと、後工程で大きな手戻りになります。

ステップ5｜結果を記録して次工程へ渡す

実施日時、実施者、対象ビルド、項目ごとの結果を記録します。どのビルドで何を確認したかが後から追える状態にします。

合格した場合は、本格的なテストフェーズへ進むことを関係者に伝えます。不合格の場合は、どの項目が失敗したかを添えて開発側へ差し戻します。

テスト工程全体の設計や、外部に委託する場合の役割分担についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方も参考になります。

自動化との組み合わせ

繰り返し実施するテストであるため、自動化と相性がよい領域です。ただし、すべてを自動化すべきというわけではありません。

自動化に向く部分

毎回同じ手順で実行し、結果の判定が明確な項目は自動化の対象になります。ログインできる、主要画面が表示される、基本的な登録処理が通るといった内容です。

自動化すれば、実行時間が数分に短縮され、実施の負担がほぼゼロになります。人が判断するのは、失敗した項目だけという状態を目指します。

判定基準が数値や文字列で表現できる項目から着手すると、導入がスムーズです。画面の見た目の確認は自動化の難易度が上がります。

CI/CDへの組み込み

ビルドが完了したタイミングで自動的に実行する構成にすると、人が意識しなくても毎回サニティテストが走る状態になります。

結果が失敗であれば、その先の工程を止めるという設定にします。動かないビルドが下流に流れることを、仕組みとして防げます。

この構成にできると、サニティテストは工程ではなく仕組みになります。実施し忘れという問題そのものが発生しなくなります。

自動化しないほうがよい場合

修正内容に応じて毎回対象が変わる部分は、自動化の効果が出にくくなります。今回の修正箇所を確認する項目が、これに該当します。

維持のコストも考慮します。画面の構成が頻繁に変わる開発初期に自動テストを作り込むと、テストの修正に追われることになります。

共通部分は自動、修正箇所は手動という組み合わせが現実的です。すべてを自動化しようとせず、費用対効果の高い部分から着手します。

よくある失敗と対策

運用が崩れる原因には、共通したパターンがあります。事前に知っていれば防げるものを整理します。

項目が増えて実施されなくなる

最大の失敗要因です。前述のとおり、時間がかかるようになると実施が後回しにされます。

対策は、実行時間の上限をルールとして決めることです。超えたら項目を見直すという運用を、定期的に回します。

四半期に一度、項目一覧を棚卸しする時間を設けると、肥大化を防げます。使われていない項目、重複している項目を整理します。

合否の基準が曖昧

「だいたい動いていれば合格」という運用では、判断が人によってばらつきます。軽微な不具合が積み残されるという結果になります。

対策は、不具合の重要度を分類し、どの水準までなら通すかを決めておくことです。「機能が使えないものは不合格、表示の崩れは記録して通す」といった基準にします。

基準はテスト計画書に明記します。口頭の合意では、担当者が変わった時点で失われます。

影響範囲の見立てが甘い

修正箇所だけを確認し、周辺への影響を見ていないケースです。後のリグレッションテストで、修正が原因のデグレードが大量に出るという結果になります。

対策は、開発者への確認を手順に組み込むことです。修正内容と影響範囲を記載する欄を不具合票に設け、テスト側がそれを参照する運用にします。

共通処理への修正は特に注意します。1箇所の変更が広範囲に波及するため、影響範囲の特定に時間をかける価値があります。

記録が残らない

口頭で「問題ありませんでした」と伝えるだけの運用です。後から、どのビルドで何を確認したかが分からなくなります。

不具合が発覚したときに、いつの時点で混入したかを特定できません。原因の切り分けに余計な時間がかかります。

対策は、簡易な記録の様式を用意することです。項目ごとに合否を記入するだけの表で十分であり、凝った文書は必要ありません。

まとめ

サニティテストは、修正が意図どおり反映されているかを短時間で確認するテストです。本格的な検証に入る前の予備的な判定として機能します。

注意すべきは、用語の定義が揺れていることです。ISTQBの用語集ではスモークテストの同義語とされる一方、実務では別概念として使い分けられています。プロジェクト開始時に定義を合意しておく必要があります。

項目の選び方は、修正箇所そのものと、その影響範囲の2つが軸になります。開発者に影響範囲を確認するという一手間が、精度を大きく左右します。

そして最も注意すべきは、項目の肥大化です。時間がかかるようになると実施されなくなり、当初防ぎたかった事態が再発します。実行時間の上限をルールとして決めることが継続の条件です。

まずは自チームで、「サニティテスト」という言葉が何を指しているかを確認するところから始めてみてください。認識が揃っていないケースは、想像以上に多く見られます。

開発とテストの進め方から、無料で相談できます テスト工程が属人化している、自動化をどこから始めるか決めきれないといった段階のご相談も承っています。営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎