スモークテストとは？CI/CDへの組み込みと対象選定・失敗時の判断を実装者向けに解説

スモークテストは、ビルドやデプロイの直後に主要機能だけを短時間で通し、後続のテストを始めてよい状態かを判定する検証です。実装者にとっての本体は、語源よりも「どのケースをこの門に入れ、失敗したら何を巻き戻すか」という設計判断のほうにあります。この記事では、ISTQB用語集が示す定義と用語上のねじれ、リグレッションテストやヘルスチェックとの役割の違い、対象の選定基準と実行時間の予算、PlaywrightやGitHub Actions・AWS CodeDeploy・helm testでの組み込み実装までを、コードと判断基準の粒度で整理します。

まとめ：スモークテストは後続工程の門であり、判定は数分で終える設計にする

スモークテストの役割は欠陥を洗い出すことではありません。壊れたビルドに後続工程の時間を投じる事故を防ぐ門として働きます。この目的から逆算すれば、対象は収益・認証・データ書き込みという3系統の主経路に絞られ、境界値や異常系は入りません。

実行時間の予算は5分以内。10分を超えると開発者はパイプラインの完了を待たなくなり、門は形だけ残って機能しなくなります。ケース数の目安は15件から30件、1ケース10秒前後という換算です。

失敗時の扱いも先に決めます。本番デプロイ後のスモークが落ちたら即ロールバック、外部依存の一時失敗と切り分けられる場合のみ1回だけ再実行する。この線引きがない現場では、失敗が「たぶんフレーキー」で流され、門としての価値が失われます。サニティテストとの用語上の関係は本文で扱います。

スモークテストの定義と語源・ISTQB用語集が示す対象範囲の考え方

まず用語の輪郭を固めます。スモークテストは工程名ではなく、テストケースの集合の性質を指す言葉です。

ISTQB用語集が定義する全テストケースのサブセットという条件

ISTQB用語集は、スモークテストを「計画されたテストの開始前に、コンポーネントまたはシステムが正しく動作するかを判定するため、主要機能を網羅するテストスイート」と定義しています。条件は主要機能の網羅と、計画されたテストより前に置かれることの2点。

実装上で効いてくるのは「サブセット」という性質です。専用ケースを書き起こすより、既存のテスト資産からタグで抜き出す形が保守の面で有利になります。専用スイートとして独立させると、本体のテストが更新されてもスモーク側が取り残され、通っているのに壊れている状態を招きます。

電子機器の通電試験に由来する語源と現場に残った合否判断の粒度の考え方

語源は電子回路の試作品に電源を投入し、発煙しないかを見る試験です。示しているのは合否判断の粒度で、煙が出たかどうかという二値しか問いません。抵抗値のずれは、この段階の関心ではありません。

ソフトウェアでの対応は明快です。トップページが200を返すか、ログインが成功するか、注文が1件登録されるか。判定はいずれも成否の二値に落ちます。逆に「レスポンスが平常時より30%遅い」といった連続量の評価は向きません。性能劣化の検知は監視系に持たせ、門の判定を曇らせない構成にします。

サニティテストが同義語として並ぶ用語上のねじれと現場の使い分け

ISTQB用語集ではサニティテスト・コンフィデンステスト・インテークテストがスモークテストの同義語として登録されています。標準の側は両者を区別していません。一方の現場では、システム全体がざっくり動くかを見るのがスモーク、特定の修正箇所とその周辺だけを局所的に確かめるのがサニティ、という使い分けが流通しています。

どちらかが誤りという話ではなく、標準用語としては同義、実務の会話では役割分担と二重に理解しておけば足ります。ビルド検証テスト（BVT、Build Verification Test）も同じ対象を指す業界的な別名です。チーム内では定義論に時間を使わず、「デプロイ直後に走る集合」「修正確認だけを走らせる集合」のようにパイプライン上の位置で呼び分けたほうが誤解が起きません。

リグレッションテストとヘルスチェックとの役割の違いを3軸で整理

スモークテストは前後の工程と混同されやすく、境界を決めないと同じケースが二重に走ります。網羅範囲・実施タイミング・判定対象の3軸で切り分けます。

リグレッションテストとの違いは網羅範囲と実施タイミングの2点に集約

どちらも既存機能の破壊を検知しますが、範囲と位置が逆向きです。スモークは主経路を浅く広く、リグレッションは影響範囲を深く網羅します。

順序関係も固定です。スモークが落ちた状態でリグレッションを走らせても、大量の失敗が並ぶだけで原因の切り分けに寄与しません。門とリグレッションを通した後に置く探索的テストのチャーターとセッション運用も、この順序を前提にします。範囲選定と自動化の考え方はリグレッションテスト（回帰テスト）の目的と範囲選定で扱っているため、本記事では門としての役割に絞ります。

ヘルスチェックとの違いはプロセス生存と業務機能の到達性で分かれる線引き

ヘルスチェックとスモークテストは、デプロイ直後に走る点だけが共通しています。判定対象は別です。ヘルスチェックが答えるのは「このプロセスはリクエストを受け付けられるか」、スモークテストが答えるのは「業務が1件完了するか」です。

具体例で差が出ます。マイグレーションが未適用でカラムが足りず、注文登録だけが失敗する障害を考えてください。接続プールは正常なのでReadinessプローブは200を返し続け、ヘルスチェックは通過します。この穴を埋めるのがスモークテストで、両者は代替ではなく直列に置く関係です。プローブの分離と閾値の決め方はヘルスチェックにおけるLivenessとReadinessの分離にまとめています。

テストピラミッドのどの層に置くかで決まる配分とスモーク集合の重複

スモークテストはピラミッドの独立した層ではありません。E2E層から選び出した小さな部分集合として置かれます。層として新設すると、E2Eの本数がそのまま二重になります。

配分の目安を示します。E2Eケースが200件ある構成なら、タグを打って抜き出すのは20件前後、比率で1割前後です。これを超えると実行時間の予算に収まりません。各層の本数配分はテストピラミッドにおける単体・結合・E2Eの配分を前提にしてください。単体テストや結合テストを含める構成も理屈では成立しますが、デプロイ済みの実環境に対する検証という目的から外れます。

クリティカルパスから逆算するスモークテスト対象の選定基準と時間予算

スモークテストの設計で最も失敗しやすいのが対象選定です。基準を決めずに「重要そうなケース」を集めると、半年で100件に膨らんで門が詰まります。

収益・認証・データ書き込みから逆算するクリティカルパスの洗い出し手順

選定は機能一覧からの積み上げではなく、事業が止まる経路からの逆算で行います。次の順序で洗い出します。

1. 収益が発生する経路を1本ずつ書き出す（購入完了、契約申込、決済確定）
2. その経路に必須の認証・認可を書き出す（ログイン、権限判定、トークン発行）
3. 各経路で発生するデータ書き込みを1件特定する（注文レコード、在庫減算）
4. 外部システムとの連携点のうち、失敗が業務停止に直結するものだけを残す
5. 残った経路をユーザー操作の単位に翻訳し、1経路1ケースに落とす

ECサイトなら「ログインして商品を1点購入し、注文番号が返る」という1本が最優先ケースとして残ります。読み取り専用の画面表示は、収益経路の途中に含まれる場合を除いて選びません。カタログ検索が壊れていても注文が通る構成なら、検索は対象外という判断です。

実行時間を5分以内に収めるための予算配分とケース数の上限の目安

時間予算を先に決め、そこにケースを収めます。逆順にするとケースが増え続けます。予算は5分。内訳はブラウザやコンテナの起動に60秒、ケース実行に180秒、レポート出力と後片付けに60秒という配分が現実的な線です。

ケース実行180秒を1ケース10秒で割ると18件。並列度を2に上げれば30件台まで伸びますが、書き込みを伴うケースは競合を招くため直列に残します。件数を増やす前に、ログイン後に注文とマイページ表示をまとめて確認するように、1ケース内で複数の検証を束ねるほうが効率的です。実行速度を落とす主因は待機処理の書き方にあるため、E2Eテストのベストプラクティスとツール選定で扱っている明示的待機の設計を流用してください。

境界値や外部依存などスモークに含めてはいけないケースの除外基準

除外の基準を明文化しておくと、ケースの膨張を止められます。次の類型は入れません。

• 境界値・異常系（入力エラー表示、上限値チェック）は後続のリグレッション側へ
• 自社が制御できない外部SaaSの実通信に依存するケースはスタブに差し替える
• 実行に3分以上かかるバッチ処理は、キューへの投入までで判定を打ち切る
• レイアウト崩れやスクリーンショット比較は判定が不安定になるため対象外
• 複数ユーザーの同時操作を前提とする排他制御の検証は競合を招くため除外

決済の実通信を外す判断には抵抗が出ますが、外部の障害で自社のデプロイが止まる構成は門の設計として破綻しています。本番の決済経路を継続的に確かめたい場合は、スモークではなく合成監視の側に置くのが筋です。

CI/CDパイプラインへスモークテストを組み込む実装パターン4種

ここからは実装です。スモーク集合の切り出し、起動契機、デプロイ制御との連結を代表的な4構成で示します。記述は2026年8月時点の各公式ドキュメントに基づきます。

Playwrightのtag指定と–grepでスモーク集合を切り出す実装

Playwrightはテスト宣言時にtagオプションを渡す方式でタグを付けられます。タグは@で始める規約です。test('注文が完了する', { tag: '@smoke' }, async ({ page }) => { ... })のように書き、実行側はnpx playwright test --grep @smokeで絞り込みます。テストタイトルに@smokeを含める旧来の書き方も有効です。

除外や複合条件も指定できます。スモークだけを外すなら--grep-invert @smoke、いずれかのタグに一致させるなら--grep "@smoke|@critical"、両方を持つケースに限定するなら先読みで--grep "(?=.*@smoke)(?=.*@critical)"という書き方。既存のE2E資産にタグを打つだけで済むため、専用スイートを別ディレクトリに切り出す構成より保守が軽くなります。付与漏れを防ぐには、新規ケース追加時のレビュー観点に「スモーク対象か否か」を1項目加えることです。

GitHub Actionsのdeployment_statusで公開後に起動する構成

デプロイ完了後にスモークを走らせる契機として素直なのがdeployment_statusイベントです。ワークフローでon: deployment_statusを宣言し、ジョブ条件にif: github.event.deployment_status.state == 'success'を置けば、デプロイ成功時だけ起動します。対象URLはgithub.event.deployment_status.environment_urlから受け取り、テスト側のbaseURLに渡す構成。

プルリクエスト段階でも同じ集合を使い回せます。pull_request側ではスモークだけを走らせて数分で返し、全件はscheduleで夜間に回す二段構成が有効です。失敗時のトレースをactions/upload-artifactで保存しておくと、再現待ちの往復が減ります。環境変数に本番の認証情報を流す構成にはせず、権限を購入と参照だけに絞ったスモーク専用アカウントを用意してください。

CodeDeployのAfterAllowTestTrafficに検証を差し込む構成

Amazon ECSのBlue/Greenデプロイでは、AppSpecファイルのhooksセクションにLambda関数を割り当てて検証を差し込めます。ライフサイクルイベントの実行順はBeforeInstall、AfterInstall、AfterAllowTestTraffic、BeforeAllowTraffic、AfterAllowTrafficです。

スモークを置くべき位置はAfterAllowTestTrafficです。テストリスナーが新タスクセットへトラフィックを流した後に発火するため、本番利用者を巻き込まずに実環境の応答を確かめられます。フック関数は結果をputLifecycleEventHookExecutionStatusでSucceededまたはFailedとして返し、Failedならロールバックへ向かう流れです。1時間以内に通知が届かない場合はデプロイ失敗として扱われる仕様のため、実行時間は余裕を持って収めます。

EC2やオンプレミス構成では最後のイベントValidateServiceにスクリプトを置きます。timeoutの既定値は3600秒ですが、スモークの趣旨からは300秒程度が妥当です。本番トラフィックで裏側だけを先に検証する手法との併用はダークローンチで裏側だけを検証する実装で整理しています。

Kubernetes環境でhelm testを使う場合の制約と代替手段

Helmでは、テンプレートにhelm.sh/hook: testアノテーションを付けたPodまたはJobを定義し、helm testコマンドで実行します。コンテナが終了コード0で終われば成功判定です。テストリソースもフックの一種であるため、helm.sh/hook-weightで実行順を制御し、helm.sh/hook-delete-policyで後片付けの方針を指定できます。

制約は2つあります。ひとつはhelm testが導入や更新の完了後に別コマンドとして走る点で、失敗が自動でロールバックを起こすわけではありません。パイプライン側で終了コードを受けてhelm rollbackを呼ぶ処理が必要です。もうひとつは実行環境がクラスタ内のPodになるため、外部からのユーザー操作を再現する経路とは条件が変わることです。クラスタ内部の疎通確認をhelm testに任せ、ブラウザ操作を伴うスモークは外部のCIランナーから流す二層構成が落としどころになります。

スモークテスト失敗時のロールバック判断とフレーキー対策・見送り条件

門を作ったあとに残るのは運用の問題です。失敗をどう扱うかを決めていない門は、数か月で無視されるようになります。ここは条件を付けて言い切ります。

スモーク失敗を即ロールバックに直結させる条件と例外の切り分け方

原則は単純です。本番環境に対するスモークが失敗したら、原因調査より先に巻き戻します。調査を先に置くと、障害時間が調査時間と等しくなります。

例外は1つだけ設けます。失敗の原因が外部依存の一時的な応答異常だと自動判定できる場合に限り、1回だけ再実行する。判定材料は失敗時のステータスコードとエラー種別で、接続タイムアウトや502のように自社コードの欠陥と切り分けられるものに限ります。期待値との不一致、つまりアサーション失敗は再実行の対象にしません。再実行回数を2回以上にする設定は入れないでください。3回試して通ればよいという運用は、確率的に通る門を許容することと同義です。

フレーキー化したスモークが無視される門へ劣化する兆候と再建の手順

劣化の兆候は数値で捕まえられます。スモークの失敗のうち、コード修正を伴わずに再実行で通ったものの比率を毎週集計してください。この比率が10%を超えた時点で、開発者は失敗を本気で受け取らなくなります。20%を超えたら門は実質的に機能していません。

再建の手順は削減から入ります。失敗履歴の多い順にケースを並べ、上位をスモーク集合から外す。削除ではなくリグレッション側へ移すだけです。次に残ったケースの待機処理を見直し、固定秒数の待機を条件待ちに置き換えます。この2段でおおむね収束します。直しながら門に残す判断は、修正が終わるまで門が壊れたままになるため採りません。外部依存を切り離す手当てはモックとスタブの違いとテストダブル5分類の整理が使えます。

スモークテストの導入を見送って構わない現場の条件と保守運用での代替

すべての現場に必要な仕組みではありません。次の条件が重なるなら見送って構いません。デプロイ頻度が月1回以下、リリース時に人が画面を触って確認する運用が定着、本番相当の検証環境を持たない構成。この3点が揃うと、自動化の構築と保守にかかる工数が手動確認の工数を上回ります。

逆に、次のいずれかに当てはまるなら投資は回収できます。週1回以上デプロイしている、デプロイ担当者が実装者と別、マイクロサービス構成で連携先の変更が自分のサービスを壊しうる。分岐はデプロイ頻度と人の分離にあり、システムの規模ではありません。テスト基盤を組む人手が社内にない場合は、パイプラインの構築から運用の引き取り・内製化までを保守運用・内製化支援で対応しています。着手は既存のE2E資産にタグを打つところからで足ります。

よくある質問

スモークテストの設計と運用で問い合わせの多い論点をまとめます。

スモークテストは誰が実施する工程になりますか？

担当者が押すのではなく、パイプラインが自動で走らせる形が基本です。人の起動に依存させると、忙しい日に飛ばされます。結果の一次受けは、デプロイを実行した担当者に固定してください。失敗通知の宛先がチーム全体になっている構成では誰も動かないため、実行者のアカウントへ直接届く設定にします。手動で実施する段階でも、確認者と手順書の版を記録に残す運用は変えません。

スモークテストは手動と自動のどちらで実施すべきですか？

デプロイ頻度で決まります。週1回以上デプロイしている構成なら自動化が前提です。手動だとリリースのたびに担当者が15分から30分を取られ、頻度が上がるほど負荷が線形に増えます。月1回以下で確認手順書が整備済みなら手動でも回ります。移行の順序としては、まず手順書のとおりに人が確認して所要時間とケースを確定させ、その集合だけを自動化するのが失敗の少ない進め方です。最初から自動化を目標にすると、対象が絞れないまま実装が膨らみます。

スモークテストのケース数は何件くらいが目安ですか？

実行時間5分の予算から逆算して15件から30件です。1ケース10秒で計算し、起動と後片付けに2分を確保した残りに収めます。E2Eケース全体が200件ある構成なら、タグで抜き出すのは20件前後、比率で1割前後という配分になります。件数が40件を超えたなら、ケースの追加ではなく1ケース内で複数の検証を束ねる方向に切り替えてください。ログイン後に注文とマイページ表示をまとめて確認する形にすれば、経路数を保ったまま件数を圧縮できます。

本番環境でスモークテストを実行しても問題ありませんか？

データ書き込みを伴うケースがあるため、設計なしに流すのは避けてください。実務では3つの手当てを入れます。スモーク専用のテストアカウントで権限を絞る、投入したデータを識別できる命名規約を付ける、集計処理からそのデータを除外する。Blue/Green構成が使えるなら、AWS CodeDeployのAfterAllowTestTrafficのようにテストリスナー経由で新環境だけに流す方式が安全です。この位置なら本番利用者のトラフィックは旧環境に残り、失敗してもロールバックで済みます。

スモークテストとヘルスチェックは両方必要ですか？

判定対象が違うため、両方を直列に置きます。ヘルスチェックはプロセスがリクエストを受け付けられるかを見る仕組みで、マイグレーション未適用のように業務機能だけが壊れている状態は検知できません。逆にスモークテストは数分に1回という頻度では回せないため、継続的な生存監視には向きません。デプロイ直後の1回はスモークで業務経路を確かめ、その後の定常監視はヘルスチェックとプローブに任せる役割分担にしてください。

関連記事

• リグレッションテスト（回帰テスト）とは？目的・範囲選定・自動化：通過後に走らせる本体側の範囲選定を扱っています。
• ヘルスチェックとは？LivenessとReadinessの分離と閾値設計：プローブ側の設計を閾値から解説しています。
• テストピラミッドとは？単体・結合・E2Eの配分と戦略設計：スモーク集合を抜き出す母体の層配分です。
• E2E（エンドツーエンド）テストのベストプラクティスとツール選定：1ケース10秒に収める待機処理の実装です。
• Page Object Model (POM)とは？テスト自動化の設計パターン：本体テストとケースを共有する構造化です。