スモークテストとは？目的・サニティテストとの違い・項目の選び方を解説

ビルドが通ったはずなのに、テスト環境を開いたらログイン画面すら表示されない。デプロイ直後に主要機能が丸ごと動かず、テストチームの半日が無駄になった。こうした事故を防ぐための最初の関門がスモークテスト（Smoke Test）です。

この記事では、スモークテストの定義と語源から、混同されやすいサニティテスト・リグレッションテスト・確認テストとの違い、実施するタイミング、テスト項目の選び方、チェックリスト例、CI/CDへの自動化の組み込み方、そしてよくある失敗までを実務目線で解説します。

スモークテストとは？定義と語源

スモークテストの定義

スモークテスト（Smoke Test / Smoke Testing）とは、新しく作られたビルドやデプロイされたシステムに対して、「本格的なテストを始めてよい状態か」を短時間で判定する簡易テストです。ビルドが起動するか、ログインできるか、主要画面が開くか、基幹となる機能がひととおり動くかといった、システムの生死に関わる最小限の確認だけを行います。

重要なのは、スモークテストが「品質を保証するテスト」ではなく「後続テストへ進む可否を決めるゲート（門番）」だという点です。細かな不具合を洗い出すことは目的ではありません。スモークテストが失敗した時点でそのビルドは差し戻され、テスト工程には進みません。この性質から、ビルド検証テスト（BVT：Build Verification Test）、ビルド受入テスト（BAT：Build Acceptance Test）、コンフィデンステストなどとも呼ばれます。

「スモーク（煙）」という名称の由来

名称の由来は電子工学・ハードウェア開発の慣習にあります。新しく組み立てた基板に初めて通電したとき、煙が出れば設計や配線に致命的な問題があり、そこから先の詳細な検査をしても意味がありません。逆に煙が出なければ、少なくとも回路として成立しているとみなして次の検証に進めます。

この「まず火を入れて煙が出ないかを見る」という考え方がソフトウェア開発に持ち込まれ、ビルドに火を入れて（起動して）致命的な破綻がないかを見るテストがスモークテストと呼ばれるようになりました。「煙が出なければ合格」という比喩が、テストの浅さと判定の速さをよく表しています。

配管・建築分野の「煙試験」とは別物

なお「スモークテスト」という言葉は、配管の漏れ検査や建築物の気流・排煙経路の確認を指す用語としても使われます。発煙管やスモークマシンで実際に煙を流し、漏れや流れを目視する検査です。同じ名称ですが、本記事で扱うソフトウェアテストとは目的も手法もまったく異なる技術分野の用語です。検索時に工具・発煙管の商品情報が混在するのはこのためです。

スモークテストの目的と重要性

壊れたビルドを後続工程に流さない

最大の目的は「そもそも動かないビルド」でテスト工程を開始してしまう事態を防ぐことです。ログインができないビルドに対して数百件のテストケースを消化しようとしても、ほぼ全件が同一原因で失敗します。原因調査・起票・再テストの手間だけが積み上がり、テスト結果からは何の品質情報も得られません。

スモークテストを入口に置けば、この状態を数分から数十分で検知して差し戻せます。テスト担当者が丸一日を空費するリスクを、わずかな確認時間で回避できるという費用対効果の高さが、スモークテストが重視される理由です。

不具合の早期発見と手戻りコストの抑制

不具合は、発見が遅れるほど修正コストが増大します。原因箇所の特定が難しくなり、影響範囲が広がり、修正後の再テスト範囲も膨らむためです。スモークテストを毎ビルド・毎デプロイで実行していれば、「直前の変更が原因である」と切り分けられるため、調査時間そのものを大きく削減できます。

開発チームとテストチームの合意点になる

スモークテストの項目は「このシステムで絶対に壊れてはいけない機能は何か」を明文化したものでもあります。開発側とテスト側が同じチェックリストを共有することで、「テスト可能な状態」の基準が言語化され、ビルドの受け渡しをめぐる認識のずれや押し問答が起きにくくなります。

スモークテストと他のテストの違い

スモークテストは、サニティテストやリグレッションテストと混同されがちです。まず全体像を表で整理します。

サニティテストとの違い

最も混同されやすいのがサニティテスト（Sanity Test）です。両者は「短時間で行う絞り込んだテスト」という点は共通しますが、見る対象が正反対です。

• スモークテスト：システム全体を広く浅く。「全体が生きているか」を見る。項目は毎回ほぼ固定。
• サニティテスト：変更・修正された機能を狭く深く。「今回の変更が正しく入っているか」を見る。項目は変更内容によって毎回変わる。

順序としては、スモークテストで全体の生存を確認し、その後にサニティテストで変更箇所を確認する流れが一般的です。なお現場によっては両者を厳密に区別せず、まとめて「スモーク」と呼ぶこともあります。用語の定義に固執するより、チーム内で「どの範囲を、いつ、誰が確認するのか」を合意しておくことのほうが重要です。

リグレッションテスト（回帰テスト）との違い

リグレッションテストは「変更によって既存機能が壊れていないか」を網羅的に確認するテストです。範囲が広く実行時間も長いため、通常はスモークテストを通過したビルドに対して実施します。

両者は「既存機能を確認する」点が似ていますが、スモークテストは網羅性を意図的に捨てているのが決定的な違いです。スモークテストが合格しても品質は何も保証されません。あくまで「リグレッションテストを始めてよい」という意味しか持ちません。

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

確認テスト（リテスト）は、報告した個別の不具合が修正されたかをピンポイントで検証するテストです。対象は起票済みの不具合そのものに限定され、再現手順をなぞって現象が消えたことを確認します。システム全体を対象とするスモークテストとは、粒度も目的も異なります。

受入テストとの違い

受入テスト（UAT）は、発注者や利用部門が「業務で使えるか」を判断するテストです。判定者が利用者側であり、判定基準も技術的な動作ではなく業務要件の充足度になります。一方スモークテストの判定者は開発・テストチームであり、判定基準は「動くかどうか」だけです。ただし受入テストの環境に初めてデプロイした直後にも、環境固有の問題を検知するためスモークテストを実施しておくと安全です。

スモークテストはいつ実施するのか

ビルド直後（テスト環境への受け渡し時）

最も基本的なタイミングが新しいビルドをテスト環境に配置した直後です。デイリービルドを採用しているプロジェクトでは、毎朝のビルド完了後にスモークテストを実行し、合格したビルドだけをその日のテスト対象とする運用が定着しています。ここで不合格になれば、テストチームは前日のビルドで作業を継続するか、開発チームの修正を待つかを即座に判断できます。

デプロイ後（ステージング・本番環境）

環境が変われば、アプリケーションのコードが同じでも壊れます。環境変数の設定漏れ、DB接続情報の誤り、証明書の期限切れ、外部APIのエンドポイント差異、ロードバランサやCDNの設定ミス——これらはコード上のテストでは検出できません。

そのため、ステージング環境および本番環境へのデプロイ直後にもスモークテストを実行します。本番環境で実行する場合は、決済処理や外部への通知など副作用のある操作を含めない設計にするか、テスト専用アカウントを用意しておく配慮が必要です。ここで異常を検知したら、速やかにロールバックを判断します。

CI/CDパイプライン内での自動実行

GitHub ActionsやGitLab CI、Jenkins、CircleCIなどのCI/CDツールを利用している場合は、パイプラインのステージとしてスモークテストを組み込みます。ビルド成功後に自動実行し、失敗したらデプロイジョブを中断する構成にすれば、壊れたビルドが後続環境に流れること自体を仕組みで防げます。

誰が実施するのか

実施者はプロジェクトの体制によって異なりますが、次のいずれかが一般的です。

• 開発者：ビルドをテストチームに渡す前の自己検証として実施する
• QA・テスト担当者：ビルド受領時の受入判定として実施する
• CI/CDパイプライン：人手を介さず自動実行する（推奨）

実務では「開発者がビルド前に自動スモークテストを回し、テストチームが環境反映後に短時間の手動確認を行う」といった二段構えを取るプロジェクトも多く見られます。重要なのは実施責任者を明確に決めておくことで、曖昧なままだと「誰も見ていないビルド」が流通してしまいます。

スモークテストに含める項目の選び方

選定の4つの基準

スモークテストの成否は項目選定でほぼ決まります。次の4つの基準に照らして選ぶと、過不足のないセットになります。

1. 起動するか：アプリケーションやサーバーが正常に立ち上がり、トップページがエラーなく表示されるか
2. ログインできるか：認証が通り、権限に応じた画面に遷移するか。認証が壊れていれば以降のテストは一切実施できません
3. 主要画面が開くか：利用頻度の高い画面が表示され、致命的なエラーが出ないか
4. 基幹機能が動くか：そのシステムの存在意義にあたる中核機能（ECなら購入、業務システムなら申請・承認など）が最低限成立するか

判断に迷ったら「これが壊れていたら、その日のテストが成立しないか？」と自問してください。答えがYESなら含める、NOなら含めない、という基準がもっとも実務的です。

含めないほうがよい項目

逆に、次のような項目はスモークテストに入れるべきではありません。

• 異常系・境界値のテスト：入力エラーや例外処理の検証は、後続の機能テストの役割です
• 表示崩れやレイアウトの細部：業務が止まらない不具合は対象外です
• 実行に長時間かかる処理：夜間バッチや大量データ処理は、スモークテストの時間制約に合いません
• 不安定で失敗しやすい項目：偶発的に落ちる項目を入れると、判定そのものが信用されなくなります

スモークテストのチェックリスト例

Webシステムを想定した、汎用的なスモークテストのチェックリスト例です。自社のシステムに合わせて、基幹機能の部分を差し替えて利用してください。

項目数は10〜20件程度に収めるのが目安です。No.12のバージョン確認は軽視されがちですが、「古いビルドをテストしていた」という事故を防ぐ効果が大きいため、最初に置くことを推奨します。

スモークテストの実施方法

手動でのスモークテスト

チェックリストに沿って人が操作する方法です。導入コストがゼロに近く、立ち上げが速いのが利点で、開発初期や項目が固まっていない段階に適します。一方、実行のたびに人手がかかり、回数が増えるほど負担が積み上がるうえ、確認漏れや判断のばらつきも生じます。

手動で運用する場合でも、チェックリストを文書として固定し、実施記録を残すことが前提です。担当者の記憶に頼った「なんとなくの動作確認」はスモークテストとは呼べません。

自動スモークテスト

スモークテストは自動化と最も相性のよいテストです。項目が固定的で、頻繁に繰り返し実行され、判定結果が明確という3条件がそろっているためです。テスト自動化の導入対象を1つだけ選ぶなら、まずスモークテストから着手するのが定石といえます。

ブラウザ操作を伴うE2Eの確認にはPlaywright、Cypress、Seleniumなどが、API層の疎通確認にはcurlやPostman（Newman）、各言語のHTTPクライアントが使われます。全項目を無理にE2Eで組む必要はなく、ヘルスチェックやAPI疎通のように軽量な手段で確認できるものはそちらに寄せると、実行時間と保守コストを抑えられます。

GitHub Actionsへの組み込み例

デプロイ後にスモークテストを実行し、失敗したらパイプラインを止める構成の例です。

name: deploy-and-smoke

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to staging
        run: ./scripts/deploy.sh staging

  smoke-test:
    needs: deploy
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install dependencies
        run: npm ci
      - name: Health check
        run: |
          curl --fail --retry 5 --retry-delay 10 \
            https://staging.example.com/healthz
      - name: Run smoke tests
        run: npx playwright test --grep @smoke
        env:
          BASE_URL: https://staging.example.com
      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: smoke-report
          path: playwright-report/

ポイントは3つです。①needsでデプロイ完了後に実行する、②timeout-minutesで上限時間を設けて長時間化を防ぐ、③--grep @smokeのようにタグでスモーク対象のみを抽出する。テストコード側に@smokeタグを付けておけば、同じテスト資産からスモーク用のサブセットを切り出せます。

本番デプロイに組み込む場合は、スモークテストの失敗を検知して自動ロールバックを実行するジョブを後段に置くと、障害時間をさらに短縮できます。

実務基準：何分以内に終わらせるべきか

スモークテストは「速さ」が価値の大半を占めます。結果が出るまで1時間かかるようでは、判定を待たずに作業が進んでしまい、ゲートとして機能しません。目安は次のとおりです。

本番環境では、異常を検知してからロールバックするまでの時間がそのまま障害時間になるため、他より厳しい基準を設定します。限界ラインを超えたら項目を増やすのではなく、減らすか高速な確認手段に置き換える——この原則を守ることが、スモークテストを形骸化させないための鍵です。

スモークテストでよくある失敗と対策

失敗1：項目を増やしすぎて長時間化する

最も多い失敗です。障害が起きるたびに「次から確認しよう」と項目が追加され、いつの間にか1時間かかるテストに肥大化します。こうなると誰も待たなくなり、スモークテストは実質的に機能を失います。

対策：項目数と実行時間に上限を設け、追加する際は必ず何かを削るルールにします。削った項目は捨てるのではなく、リグレッションテストのスイートへ移します。四半期に一度など、定期的な棚卸しの機会を設けるのも有効です。

失敗2：失敗しても止めずに進めてしまう

「今回の失敗は既知の問題だから」と例外を認め続けると、ゲートとしての意味が失われます。赤信号を無視する運用が常態化したテストは、いずれ誰も結果を見なくなります。

対策：失敗＝即差し戻しを原則とします。恒常的に失敗する項目があるなら、それは項目の設計かテスト環境に問題があるということです。例外運用ではなく、項目の修正か除外で対処します。

失敗3：不安定なテスト（Flaky Test）を放置する

実行するたびに結果が変わる不安定なテストが混ざると、失敗が出ても「また例のやつだろう」と扱われ、本物の障害を見逃します。

対策：待機処理を明示的な要素待ちに変える、テストデータを毎回初期化する、外部依存をモックに置き換えるなどで安定化を図ります。改善できない項目は、スモークテストから思い切って外します。

失敗4：スモークテスト合格を品質保証と誤解する

「スモークテストが通ったからリリースできる」という判断は危険です。スモークテストは広く浅い確認であり、機能の正しさも性能もセキュリティも検証していません。

対策：報告資料やパイプラインの表示上も、「テスト開始可否の判定」であることを明記します。リリース判定はリグレッションテストと受入テストの結果に基づいて行います。

失敗5：テスト環境と本番環境の差異を無視する

テスト環境でスモークテストに合格しても、本番環境の設定差異で動かないケースは頻繁に起こります。設定値、証明書、権限、外部連携先など、環境依存の要素は数多く存在します。

対策：デプロイ先の各環境で個別にスモークテストを実行する運用にします。環境ごとに接続先URLだけを差し替えて同じテストを流せるよう、テストコードを設計しておくと運用負荷を抑えられます。

スモークテストに関するよくある質問

Q. スモークテストとサニティテストはどちらを先に実施しますか？

A. 一般的にはスモークテストが先です。まずシステム全体が動作する状態かを確認し、その後で変更箇所を掘り下げるサニティテストを実施します。全体が起動しない状態で個別機能を調べても意味がないためです。

Q. スモークテストの項目数は何件が適切ですか？

A. 10〜20件程度が目安です。ただし件数そのものより実行時間で管理するほうが実務的です。自動なら5分以内、手動なら15分以内に収まる範囲で項目を選定してください。

Q. 小規模なプロジェクトでもスモークテストは必要ですか？

A. 必要です。むしろ人員が少ないプロジェクトほど、1人が半日を空費する影響が大きくなります。最初は「起動する・ログインできる・主要画面が開く」の3項目からでも十分に効果があります。

Q. スモークテストは自動化すべきですか？

A. 繰り返し実行するのであれば自動化を推奨します。項目が固定的で判定基準が明確なため、自動化の投資対効果が最も高いテストです。ただし項目が頻繁に変わる立ち上げ期は、まず手動でチェックリストを固めてから自動化に移行するほうが手戻りが少なくなります。

Q. スモークテストが失敗したらどうすればよいですか？

A. そのビルドを差し戻し、後続のテスト工程を開始しません。本番環境で失敗した場合はロールバックを検討します。原因が「アプリの不具合」か「環境設定の問題」か「テスト自体の不備」かを切り分けてから、修正の担当を決めてください。

Q. スモークテストは誰が作成すべきですか？

A. 開発チームとQAチームが共同で作成するのが理想です。「システムが動いているとはどういう状態か」の定義は、開発側の技術的な視点と、テスト側の業務的な視点の両方が必要になるためです。

まとめ

スモークテスト（Smoke Test）は、ビルドやデプロイの直後に「本格的なテストを始めてよい状態か」を短時間で判定するゲートです。電子機器に通電して煙が出ないかを見る検査を語源とし、広く浅い確認に徹する点に特徴があります。

• 目的は品質保証ではなく、後続テストへの可否判定
• サニティテストは「狭く深く」、スモークテストは「広く浅く」
• 実施タイミングはビルド直後・デプロイ直後・CI/CDパイプライン内
• 項目は「起動する／ログインできる／主要画面が開く／基幹機能が動く」を軸に10〜20件
• 実行時間は自動で5分以内、手動で15分以内を目標にする
• 最大の失敗要因は項目の増やしすぎによる長時間化

まずは3項目のチェックリストからでも構いません。「動かないビルドで半日を失う」事故を防ぐ仕組みを、今日から開発フローに組み込んでみてください。テスト項目の設計や自動化の導入にお悩みの場合は、ソフトウェアテスト代行サービス『テスター10』にお気軽にご相談ください。