スモークテストの自動化｜作り方とCI組み込みの実践手順

2026 8/31

2026年8月31日

詳細なテストを進めた後半で、「そもそもログインできていなかった」「主要画面が真っ白だった」と気づいた経験はないでしょうか。土台が崩れていたと分かると、それまでの時間はほぼ無駄になります。この手戻りを防ぐのが、リリースやビルドのたびに最低限の動作を機械的に確かめる仕組み、すなわちスモークテストの自動化です。

この記事では、確認項目の洗い出しから実装レイヤの設計、CIへの組み込み、環境別の安全設計、軽さを保つ運用、チーム導入までを、実践手順として順に解説します。コピペの手がかりになる最小コード例も載せます。

なお、スモークテストの定義やサニティ・回帰との違いといった基礎は、後述の関連記事へ送客します。本記事は「作り方と回し方」に絞ります。

スモークテストの自動化が手戻りを防ぐ理由

自動化の全体像に入る前に、スモークが何のためにあるのかを押さえます。役割を取り違えると、確認項目もCIの組み方もぶれてしまいます。

詳細テストの後半で崩れる「手戻り」の構造

詳細テストの後半で重大な欠陥に気づくと、原因の切り分けや再テストで工数が膨らみます。土台が動かない状態で細部を検証しても、その結果は信頼できません。だからこそ、テストの入口で「生存確認」を済ませておく必要があります。

スモークの一次的役割は「ビルドの生存確認」

スモークの一次的な役割は、そのビルドやデプロイが後続の詳細テストに耐えられるかを見極める「生存確認（build verification）」です。スモークはまず、ビルドが後続テストに進めるだけの状態かを確かめる関門です。

デグレ（以前は動いていた機能の破壊）の検知は、この生存確認をCIで繰り返し回した結果として得られる副次的な効果と位置づけると整理しやすくなります。

自動テスト全般の位置づけについて、林尚平『ソフトウェアテスト自動化の教科書』は「自動テストの目的はコスト削減と効率化であり、役割はデグレ確認である」と述べています。この言及は自動テスト全体に向けたものです。創造力を要する不具合出しは人が担い、繰り返しの確認は機械に任せる、という役割分担が土台になります。

最低限の生存確認とは何か

スモークで確認する「最低限」とは、次のようなものです。

アプリケーションが起動し、主要画面が表示されること
ログインなど、利用の前提となる認証が通ること
主要な業務動線が入口から出口まで通ること
外部連携やデータベースへの疎通が取れていること
全面的なエラー画面（真っ白・500エラー等）が出ていないこと

スモークテストの定義・目的・項目選びの基礎はスモークテストとは何かを確認するを、サニティテストとの違いや実施タイミングの整理はサニティチェックとの違いを見るをご覧ください。本記事ではこれらの違いに深入りせず、実践へ進みます。

スモークテストのクリティカルパスの洗い出し方

自動化の設計は「何を確認するか」を決めることから始まります。ここで軸になるのがクリティカルパスです。

クリティカルパスとは

クリティカルパスとは、そこが止まると業務そのものが成立しなくなる中核の動線を指します。ログイン、主要画面の表示、中核業務の1往復などが典型です。

洗い出しの手順

洗い出しは、次の手順で進めると迷いません。

主要ユースケースを列挙する（ユーザーが必ず通る操作の流れ）
各動線を「利用頻度」と「停止時の影響度」で評価する
頻度と影響度が高いものから優先し、最小セットに絞り込む
絞ったものを合否条件つきの確認項目に落とす

スモークで守るべきは網羅性ではなく、業務が止まる動線を確実に押さえることです。あれもこれもと欲張らないのが肝心です。

主要ユースケースの列挙に迷ったら、実際の利用データが手がかりになります。アクセスログやアクセス解析で利用回数の多い画面・操作を上位から拾い、そこに「止まると売上や業務が直接止まるか」という影響度の観点を掛け合わせます。頭の中だけで決めると、開発者目線で目立つ機能に偏りがちなので、事実ベースで優先度を裏づけるのが安全です。

洗い出しの結果は、次の表に整理すると優先度が可視化できます。

機能・動線	想定される影響	利用頻度	スモーク対象	合否条件
ログイン認証	全機能が利用不能	高	要	HTTP 2xx かつダッシュボード要素が可視かつ画面に「エラー/500」文言なし
トップ・主要画面表示	業務開始不可	高	要	主要画面がエラーなく描画
主要業務の1往復	中核業務が停止	高	要	登録から完了まで通過
検索・一覧表示	情報到達性が低下	中	要	代表条件で結果が返る
外部サービス連携	決済・通知等が停止	中	要	疎通が確認できる
管理画面の詳細設定	影響は局所的	低	不要	詳細テスト側で担保

合否条件をアサーションに落とす

対象を決めたら、合否条件を機械が判定できるアサーションの粒度まで落とします。「ログインできる」ではなく、「HTTP 2xx が返り、特定要素が可視で、画面に『エラー/500』の文言がない」といった形です。この粒度で書くと、そのまま自動化スクリプトの仕様になります。

スモークの実装レイヤ設計：API/ヘルスチェックとUI(E2E)の使い分け

同じ「生存確認」でも、どの層で確認するかで速度と安定性は大きく変わります。ここを設計しないと、遅くて不安定なスモークになりがちです。

層で速度・安定性が変わる

起動・認証・DBや外部への疎通・主要APIの応答は、HTTPのヘルスチェックやAPIレベルで軽く速く確認できます。一方、UI(E2E)は本物のブラウザを動かすため確認の説得力は高いものの、遅く、環境差で不安定になりやすい層です。

確認は下の層ほど速く安定し、上の層ほど遅く壊れやすい、という前提でレイヤを選びます。

層別マッピング表

確認内容ごとに推奨レイヤを対応づけると、設計が明快になります。

確認内容	推奨レイヤ	理由
プロセス起動・死活	ヘルスチェック(HTTP)	最速・最安定で即時判定できる
認証・トークン発行	API	UIを介さず認証系だけを軽く確認
DB・外部連携の疎通	API/ヘルスチェック	依存先の生存を低コストで検知
主要APIの応答・ステータス	API	レスポンスとコードで機械判定しやすい
中核業務の1〜2往復	UI(E2E)	実際の画面遷移でしか担保できない部分に限定

どこから始めるか

始め方はシンプルです。まずヘルスチェックとAPIレベルで疎通と応答を固め、そのうえで中核業務の1〜2往復だけをUI(E2E)で確認します。UIを増やしすぎないことが、軽さと安定の両立につながります。

たとえば「ログインして予約を1件登録する」動線なら、ログインと予約登録のAPIをAPIレベルで叩いて成功レスポンスを確認し、画面遷移そのものの確認だけをE2Eに任せる、という分担が考えられます。同じ動線でも、判定のほとんどをAPIに寄せるほど実行は速く安定します。「E2Eでしか確認できないことは何か」を都度問い直すと、UIの本数を最小限に保てます。

手動と自動化の線引き

すべてを自動化する必要はありません。自動化には向く確認と向かない確認があり、線引きを誤るとコストばかりかさみます。

自動化に向く／向かない

期待結果が明確で毎回同じ手順を繰り返すものは自動化に向きます。逆に、仕様の隙を突く創造的な不具合出しや一度きりの確認は、人が担うほうが効率的です。期待結果が一意に決まり、繰り返し実行するものだけを自動化の対象にします。

ROIと繰り返し

スクリプト作成にはコストがかかるため、ROIの視点が欠かせません。自動化は一度書けば終わりではなく、繰り返し実行して初めて投資を回収できます。単発の確認を自動化しても、作成コストに見合いません。

確認内容	期待結果の明確さ	実行頻度	推奨	理由
ログイン・主要動線の生存確認	明確	毎回	自動	繰り返しでROIが立つ
主要画面の表示・疎通確認	明確	毎回	自動	判定が機械化しやすい
意地悪な入力・境界の探索	曖昧	都度	手動	発想力が必要
新機能の初回探索的テスト	曖昧	単発	手動	自動化コストに見合わない
見た目の微妙な崩れ	判定が難しい	都度	手動中心	人の目が有効

手動に残すもの

スモークで機械化するのは生存確認に絞り、探索や意地悪テストは手動で残します。この棲み分けが、軽くて信頼できるスモークにつながります。自動化する対象そのものの選び方は自動化対象の選び方を見るで詳しく整理しています。

スモークテストの自動化をCIに組み込む手順

確認項目とレイヤが決まったら、実行を仕組みに落とし込みます。ここがスモークテストの自動化の核心です。人が思い出したときに走らせるのではなく、決まったタイミングで必ず走る状態にします。

実行タイミングを設計する

実行タイミングは目的に応じて設計します。

タイミング	目的	対象範囲	失敗時の扱い
ビルド後	生成物が起動するかの即時確認	起動・主要画面	ゲート（次工程を止める）
デプロイ後	環境反映後の疎通確認	主要動線・外部連携	ゲート（公開を止める）
定時・毎朝	環境全体の健全性の定点観測	クリティカルパス一式	通知のみ（要因調査）

テスト対象の作り方にも注意が必要です。E2Eを長期運用する観点から、吉井健文『フロントエンド開発のためのテスト入門』は、Flaky（時々失敗する）対策の一つとして「Build済みのアプリケーションサーバーをテスト対象とする」ことを挙げています。開発サーバーではなくビルド済みアプリを対象にすると、環境差による不安定さを抑えられます。

最小実装ハンズオン

まずE2Eスモークの最小スクリプトです。ログイン後に主要画面が表示され、エラー文言が出ていないことをアサーションで確認します。要素セレクタやURLはプレースホルダで示します。

`javascript // smoke.spec.js — 主要動線の生存確認 const { test, expect } = require(‘@playwright/test’);

test(‘ログインして主要画面が表示される’, async ({ page }) => { await page.goto(process.env.YOUR_APP_URL);

// ログイン await page.fill(‘#email’, process.env.SMOKE_USER); await page.fill(‘#password’, process.env.SMOKE_PASS); await page.click(‘button[type=”submit”]’);

// 主要画面の要素が可視であること await expect(page.locator(‘[data-testid=”dashboard”]’)).toBeVisible();

// 画面にエラー文言が出ていないこと await expect(page.locator(‘body’)).not.toContainText(‘500’); await expect(page.locator(‘body’)).not.toContainText(‘Error’); }); `

次に、これをCIで走らせるGitHub Actionsの smoke.yml です。スモークが失敗するとジョブが赤くなり、needs: で後続のデプロイが止まります。これがゲート化です。失敗時にはSlackへ通知します。

`yaml name: smoke on: push: branches: [main]

jobs: smoke: runs-on: ubuntu-latest steps:

uses: actions/checkout # バージョンは運用ポリシーに合わせて固定する
uses: actions/setup-node
run: npm ci
name: Run smoke tests

env: YOUR_APP_URL: ${{ secrets.YOUR_APP_URL }} SMOKE_USER: ${{ secrets.SMOKE_USER }} SMOKE_PASS: ${{ secrets.SMOKE_PASS }} run: npx playwright test smoke.spec.js

name: Notify Slack on failure

if: failure() run: curl -X POST -d ‘{“text”:”smoke failed”}’ ${{ secrets.SLACK_WEBHOOK }}

deploy: needs: smoke # smoke が成功しないと deploy は動かない（＝ゲート） runs-on: ubuntu-latest steps:

run: echo “smoke を通過したのでデプロイを実行”

段階的ゲート化と品質ゲート

スモークが失敗したら次工程へ進めない、という関門にして初めて手戻りを防げます。ただし導入初期はFlakyが残るため、いきなりハードゲートにすると開発が頻繁に止まります。

そこで段階運用を推奨します。初期は失敗しても止めない「通知のみ」（例：continue-on-error: true）で走らせ、pass率が安定してから needs: によるハードゲートへ昇格させます。CI全体でのスピードと品質の両立はCI/CDテスト自動化の導入手順を読む、関門としての設計は品質ゲートの作り方を見るで補完できます。

環境別スモークと本番の非破壊設計

スモークはステージングと本番デプロイ後の両方で走らせることが多く、環境によって設計が変わります。ここを分けないと、本番でデータを壊す事故につながります。

ステージングと本番で設計が変わる

ステージングは壊しても構わない環境なので、破壊的操作を含められます。一方、デプロイ後や定時の実行には本番が含まれ得ます。本番で走るスモークは、非破壊・read-only中心に設計するのが大原則です。

前掲のFlaky対策で挙げた「実行ごとのDBリセット」や「テストごとのテストユーザー作成」は、テスト／ステージング環境に限って有効な手段です。本番には適用しません。本番では参照系の確認や、後始末まで含めて安全に閉じる操作にとどめます。

環境別スモーク設計表

環境	目的	実行内容	破壊的操作	失敗時の扱い
テスト/ステージング	反映前の総合確認	認証・主要動線・登録更新まで	可（DBリセット・テストユーザー作成可）	ゲート（先へ進めない）
本番デプロイ後	公開可否の最終確認	ヘルスチェック・参照系・非破壊の主要動線	不可（read-only中心）	カナリア停止・ロールバック判断

合成監視との違いと版固定・ロールバック連動

本番の非破壊スモークは、常時定点観測する合成監視（Synthetic Monitoring）と似ていますが目的が異なります。スモークはデプロイ直後の一回性のゲート、合成監視は稼働中を継続的に見張る仕組みです。

さらにスモークは、版が固定された特定のビルド成果物に対して実行し、結果にその版を紐付けて記録します。こうしておくと、失敗時に「どの版で落ちたか」が明確になり、直前の版へ戻すロールバック判断の根拠として使えます。

本番デプロイ後のスモークは、段階公開（カナリアリリース）と組み合わせると効果的です。新しい版をまず一部のユーザーやサーバーにだけ配り、その範囲で非破壊スモークを通してから全体へ広げます。ここでスモークが落ちれば、影響を最小限にとどめたまま前の版へ戻せます。全ユーザーへ一斉公開してから異常に気づく場合に比べ、被害の範囲と気づくまでの時間を大きく縮められます。

「軽さ」を保つ運用と可観測性

スモークは、放っておくと太ります。安心を求めてケースを足し続けた結果、実行に時間がかかり、いつしか「軽い確認」ではなくなる失敗はよく起こります。

増やしすぎない

軽さを守る第一原則は、ケースを増やしすぎないことです。スモークは足し算ではなく引き算で維持する意識が肝心です。新しい確認を入れるなら、詳細テスト側へ移すべき項目がないかを同時に見直します。

Flaky対策・リトライ方針・並列実行

次の壁がFlaky、つまり時々落ちるテストです。原因が不安定だと結果が信用されず、失敗しても「また誤検知だろう」と流されます。対策の基本は次の通りです（DBリセット等は前述のとおりステージング限定）。

非同期処理の完了を明示的に待つ（固定待機を避ける）
リソースがテスト間で競合しないよう分離する
CI環境とローカルでCPUコア数などの条件を合わせる
落ちやすいケースは範囲・粒度が最適かを見直す
並列実行はテスト間の独立性を確保したうえで導入する

自動リトライには注意が必要です。安易なリトライはFlakyを覆い隠し、失敗が常態化する「オオカミ少年」を助長します。リトライは無条件に有効化せず、回数を限定し、リトライ発生を計測して原因追跡の対象にとどめます。

可観測性：フレーク率・実行時間・pass率

通知を出すだけでは運用は続きません。pass率・実行時間・フレーク率を継続的に計測し、変化を早期に捉えます。実行時間の増加はスモークの「太り」の兆候、フレーク率の上昇はFlaky悪化のサインです。悪化したケースは一時隔離（quarantine）して本流から外し、棚卸しのトリガーにします。動かないまま無効化された「塩漬け」ケースを放置しない運用が、信頼される自動テストの条件です。自動テストが形骸化する構造と防ぎ方はテスト自動化の塩漬けを防ぐで整理しています。

スモークテストをチームに導入するステップと上長への説明

仕組みが分かっても、いきなり全動線を自動化しようとすると頓挫します。導入は小さく始め、成功を確かめながら広げるのが定石です。

導入ステップ

進め方は次のステップに分解できます。

ステップ	やること	成果物	つまずきポイント
1 対象を絞る	最重要の1動線を選ぶ	クリティカルパス定義	欲張って広げすぎる
2 手動で確立	手順と合否条件を固める	確認項目チェックリスト	判定基準が曖昧なまま進む
3 自動化する	まずAPIで疎通、中核だけE2E化	スモークスクリプト	不安定なテストを量産する
4 CIへ組み込む	通知のみ→安定後にゲート化	パイプライン設定	最初からハードゲートで止まる
5 拡大する	動線を段階的に追加	拡張されたスモーク	一気に増やして重くする

スモールスタート

スモールスタートは、リスク管理の面でも理にかなっています。林尚平『ソフトウェアテスト自動化の教科書』は「最初は、2か月程度の短い期間で作業を進めて、リスクが無くなった時点で期間を広げていくと良い」と述べています。短い区切りで振り返り、手応えを確かめてから広げるほうが手戻りを抑えられます。

上長へのROI説明（before/after）

上長や開発メンバーへの説明は、技術ではなく効果で語るのが有効です。導入前後を並べると納得を得やすくなります。

before：詳細テストの後半で土台の欠陥に気づき、切り分けと再テストで工数が膨らむ
after：入口で生存確認が済み、詳細テストに安心して進める状態が作れる

説得力を持たせるなら、数字は捏造せず自社の実データから拾うのが鉄則です。直近で「土台が動かず手戻りした案件」を1つ思い出し、その切り分け・再テストにかかった人日をそのまま材料にします。「あの時の手戻りを、入口の数分の確認で防げた」と具体例で語れば、抽象的な効果論よりも上長の納得を得やすくなります。詳細テストへ安心して進むための投資だと位置づけるのが、説明の軸です。

やりがちなアンチパターン

導入がうまくいかないケースには共通の型があります。先回りして知っておくと回避できます。

アンチパターン	起きる理由	回避策
スモークが重い	不安から項目を足し続ける	クリティカルパスに絞り、棚卸しを定例化
落ちても放置	Flaky放置で結果が信用されない	Flaky対策を先に打ち、失敗を必ず対応
自動化が目的化	手段が目的にすり替わる	向く確認だけ自動化、探索は手動に残す
一気に全部自動化	早く成果を出そうと焦る	1動線から段階的に拡大する
本番で破壊的操作	ステージング前提の設計を流用	本番は非破壊・read-onlyに限定