スモークテストを「ただの起動確認」で終わらせない――CI/CDとAI時代の高速品質ゲート設計

作成日: 2026-10-08
スクランブル研究所プログラミングラボ
想定読者: Web / API / モバイル / インフラ / QA / テックリード / AIコーディング支援を利用するエンジニア
想定タグ: testing, qa, githubactions, playwright, ai

はじめに

「スモークテストをしましょう」と言われたとき、何を思い浮かべるでしょうか。

アプリが起動するか。トップページが開くか。APIが200を返すか。ログインできるか。あるいは、リリース直後にcurlを数本投げる作業を想像するかもしれません。

どれも間違いではありません。しかし、スモークテストの本質を「起動確認」だけで捉えると、その価値をかなり小さく見積もることになります。

スモークテストの価値は、壊れたビルドや壊れたデプロイを、詳細なテスト工程へ流さないことにあります。言い換えると、これはテストケースの種類であると同時に、開発工程に置く「高速な品質ゲート」です。

ISTQB Glossary は smoke testing を “A test type to gain sufficient confidence that a test object is ready for planned testing.” と定義しています。予定しているテストへ進める程度の信頼を得るためのテスト、という考え方です。

MDN Web Docs も、スモークテストは重要なソフトウェア機能に対する機能テストまたは単体テストから構成され、より詳細なテストの前に実施すると整理しています。MDN が挙げる問いは「プログラムが正しく起動するか」「主要な操作が機能するか」「簡単なユーザーを保存できるか」といった、まさに“先へ進めるか”の確認です。

この考え方を現代の開発に持ち込むと、スモークテストは次のような場所に置けます。

Pull Request を作った直後
develop / main 相当ブランチへ統合する前後
ステージングへデプロイした直後
本番リリース直後
大きな設定変更・DBマイグレーション・外部API切替の直後
障害復旧後の最初の確認

さらにAIコーディング支援が普及した現在は、別の意味でもスモークテストが重要になっています。

AIは短時間で大量のコード、テストコード、設定ファイルを生成できます。しかし「生成できること」と「重要な利用経路が壊れていないこと」は別問題です。AIが開発速度を上げるほど、変更後に最低限の健全性を高速確認する仕組みが必要になります。

本稿では、スモークテストを「用語の解説」で終わらせず、CI/CD、自動化、Playwright、GitHub Actions、API、DB、モバイル、外部サービス、AIレビューまでつなげます。

1. Smokeという名前は何を意味するのか

スモークテストという言葉は、もともとハードウェアの世界で、組み立てた機器に電源を入れたとき「煙が出ないか」を確認するような初期検査の比喩として広まりました。

ソフトウェアでは文字どおり煙を見るわけではありません。けれど発想は同じです。

細かい性能測定や境界値検証へ進む前に、

起動するか
最重要機能が反応するか
重大な依存先につながるか
完全に壊れていないか

を先に見る。

ここで重要なのは「スモークテスト＝雑なテスト」ではないことです。

雑なのではなく、目的が違うのです。

詳細テストは、正しさを深く確かめるためにあります。スモークテストは、その詳細テストを行う価値のある状態かを高速に判断するためにあります。

たとえばログイン処理を考えます。

詳細な認証テストなら、正しいIDとパスワードだけでなく、間違ったパスワード、存在しないユーザー、ロック、期限切れ、MFA、セッション期限、CSRF、rate limit、remember me、logout後の再アクセスなど、多数のケースを見るでしょう。

一方、スモークテストではまず「代表的なテストユーザーでログインでき、主要画面へ遷移できる」ことを確認します。

この一本が失敗しているのに、MFAの境界ケースを何十件も回しても、多くの場合は意味がありません。

この“先へ進む価値があるか”という視点が、スモークテストを理解する鍵です。

2. ISTQBの定義を実務の言葉へ翻訳する

ISTQBの定義を実務向けに翻訳すると、次の問いになります。

「このビルド、この環境、このデプロイは、予定している詳細テストを始めてもよい状態か？」

この問いに短時間で答えるのがスモークテストです。

ここには三つの要素があります。

2.1 重要なところを見る

全機能は見ません。重要な経路を選びます。

重要とは、単に利用頻度が高いという意味だけではありません。

壊れるとサービス全体が使えない
多数の機能が依存している
売上や業務継続に直結する
障害時の影響が大きい
デプロイで壊れやすい
外部依存や環境依存が強い

こうしたものが候補です。

2.2 短時間で終わる

スモークテストはフィードバック速度が価値です。

20分、30分、1時間とかかる巨大なスイートを「スモーク」と呼ぶと、本来の役割が薄れます。

絶対的な時間に唯一の正解はありませんが、PRごとに回すなら数分程度を目標にした方が運用しやすいでしょう。ステージング全体の確認でも、可能なら10分程度までに収めたいところです。

2.3 失敗したら止める

スモークテストは単なる参考情報ではなく、品質ゲートとして使うと効果が大きくなります。

PRをマージしない
詳細E2Eを開始しない
リリースジョブを進めない
本番トラフィックを切り替えない

といった制御に接続します。

「失敗しても後段は普通に進む」なら、そのテストはゲートとしては機能していません。

3. 単体・統合・E2E・回帰・サニティとの違い

スモークテストは、テストレベルと完全に直交する概念ではありません。

スモークテストの中身には、単体テストが含まれることも、APIテストが含まれることも、E2Eが含まれることもあります。重要なのは「何の技法を使ったか」より、「何の目的で選ばれた短いセットか」です。

単体テスト

関数、クラス、モジュールなど小さな単位を確認します。

高速なので、重要な単体テストをスモークスイートの一部に含めることは可能です。ただし単体テストだけでは、デプロイ環境、ネットワーク、DB、認証、フロントとバックエンドの結合までは保証できません。

統合テスト

複数コンポーネントの接続を確認します。

APIとDB、サービス間通信、キュー、外部APIアダプタなどはスモークテストと相性が良い領域です。特に設定ミス、環境変数不足、接続先違いは統合点で起きやすいためです。

E2E

利用者視点でシステム全体を通します。

E2Eは一般に遅く、壊れやすく、保守コストも高めです。しかし最重要導線を1〜数本だけスモークとして残すのは非常に有効です。

回帰テスト

変更によって既存機能が壊れていないかを広く確認します。

スモークは回帰テストより狭く、速いことが一般的です。スモークが通ったあとに回帰テストへ進む、という関係が分かりやすいでしょう。

サニティテスト

この用語は現場差がかなりあります。

一般には、ある修正や狭い変更範囲に対して「直ったか」「周辺が最低限おかしくないか」を重点的に見るテストとして説明されることがあります。一方で、sanity と smoke をほぼ同義で使うチームもあります。

そのため実務では、辞書的な違いを争うより、リポジトリのREADMEやテスト戦略に自分たちの定義を残す方が重要です。

たとえば、

smoke: 全体の重要経路を広く浅く
sanity: 今回の変更箇所を狭く重点的に

と定義しておけば、チーム内の意思疎通はかなり楽になります。

4. 良いスモークテストの５つの性質

4.1 速い

フィードバックが遅いと、開発者は待てなくなります。

待てないテストは、やがてスキップされます。スキップされる品質ゲートは存在しないのと同じです。

4.2 重要経路を通る

“簡単だから選んだテスト”ではなく、“壊れたら困るから選んだテスト”であるべきです。

4.3 判定が明確

人が画面を見て「たぶん大丈夫」と判断するのではなく、可能な範囲で機械的に判定します。

HTTP status、レスポンスschema、特定要素の表示、DBの整合、キュー投入確認など、合格条件を具体化します。

4.4 再現しやすい

実行するたびに結果が変わると、ゲートとして信用されません。

テストデータ、時刻、乱数、外部サービス、ネットワーク遅延などの影響を減らします。

4.5 失敗時に原因へ近づける

「Smoke failed」だけでは不十分です。

最低限、どのステップで、何を期待して、実際は何が起きたか、対象commit、対象環境、主要ログが分かるようにします。

5. 何をスモークに入れるべきか――５つの選定軸

軸A: ユーザー価値

ユーザーがサービスを使う上で欠かせない導線です。

ECなら商品閲覧、カート、購入。SNSならログイン、タイムライン、投稿。管理画面ならログイン、一覧、更新。

軸B: システム依存

多くの機能が依存している基盤です。

認証、DB、キャッシュ、ストレージ、メッセージキュー、Feature Flagなどです。

軸C: 変更頻度

頻繁に触る場所は壊れる確率も高くなります。

軸D: 過去障害

過去に何度も壊れたポイントはスモーク候補です。

軸E: 環境差

ローカルでは動くがCIや本番で壊れやすいところです。

環境変数、CORS、証明書、DNS、時刻、リージョン、権限などが該当します。

この５軸で候補を並べ、最小セットを作ります。

6. APIのスモークテスト

APIはスモークテストを始めやすい領域です。

最初はcurlだけでも構いません。

set -euo pipefail

curl -fsS "$BASE_URL/health"
curl -fsS "$BASE_URL/api/books?limit=1"
curl -fsS -H "Authorization: Bearer $TOKEN" "$BASE_URL/api/me"

-f を使えば4xx / 5xxで失敗扱いにできます。

ただし、ステータスコードだけでは足りない場合があります。

HTTP 200でもbodyにエラーが入る設計なら、終了コードだけでは検出できません。

response="$(curl -fsS "$BASE_URL/health")"
echo "$response" | jq -e '.status == "ok"'

さらに重要なのは「healthが200なら全部OK」と思わないことです。

health endpoint がプロセス生存しか見ていないなら、DBが落ちていても200になるかもしれません。

用途に応じて、

liveness: プロセスが生きているか
readiness: トラフィックを受けられるか
dependency check: DBや外部依存が使えるか

を分けると、判定の意味が明確になります。

7. Web UIのスモークテスト

Web UIではPlaywrightのようなE2Eフレームワークが便利です。

Playwrightはテストにタグを付け、grepで対象だけを実行できます。公式ドキュメントでもタグ付けと絞り込みが説明され、APIリファレンスでは @smoke の例も示されています。

import { test, expect } from '@playwright/test';

test('top page opens', {
  tag: '@smoke',
}, async ({ page }) => {
  await page.goto('/');
  await expect(page.locator('main')).toBeVisible();
});

test('login works', {
  tag: '@smoke',
}, async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill(process.env.E2E_USER!);
  await page.getByLabel('Password').fill(process.env.E2E_PASSWORD!);
  await page.getByRole('button', { name: 'ログイン' }).click();
  await expect(page).toHaveURL(/dashboard/);
});

実行:

npx playwright test --grep @smoke

ここでUI検証を細かくしすぎないことが重要です。

色、ピクセル位置、細かな文言差、すべてのボタン、すべてのバリデーションを確認し始めると、回帰テストになります。

スモークで確認したいのは、

ページが開く
主要操作が開始できる
最重要フローが完了できる

といった生命線です。

8. GitHub Actionsで品質ゲートにする

GitHub Actionsでは、.github/workflows 配下のYAMLでワークフローを定義します。

name: smoke

on:
  pull_request:
  push:
    branches:
      - develop

jobs:
  smoke:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run test:smoke

設計したいのは「いつ、どのレベルのスモークを回すか」です。

Level 1: PR Smoke

目的は「この変更をレビュー・統合候補として扱ってよいか」。

短く、速くします。

Level 2: Integration Smoke

developなど統合ブランチで、複数サービス・DB・認証などを含めます。

Level 3: Post-deploy Smoke

実際にデプロイされた環境を確認します。

本番では副作用の強い操作を避け、read-onlyや専用テストデータを中心に設計します。

9. スモークテストを速く保つ技術

テストは増えます。

何もルールを決めないと、最初は2分だったスモークスイートが半年後に25分になることがあります。これは珍しい話ではありません。品質を上げようとしてケースを足し続けた結果、いつの間にか「毎回実行するには重すぎるスイート」になるからです。

そこで、スモークテストには追加条件を決めておきます。

たとえば次です。

重要経路に直接関係する
失敗したら後段テストを止める価値がある
過去に重大障害を検出した
既存の高速テストでは代替できない
実行時間予算を大きく壊さない

逆に、次のようなものは後段へ回した方がよいことが多いでしょう。

細かい表示崩れ
低頻度機能の全パターン
境界値の網羅
長時間処理
大量データ
全ブラウザ・全端末の組み合わせ
本番で副作用が強い操作

スモークスイートには「入れる判断」だけでなく「外す判断」が必要です。

さらに、テストごとの実行時間を計測しておくと、遅いケースを早く見つけられます。

例えばPR Smokeの予算を5分と決めた場合、単体で2分かかるケースを新規追加するなら、その価値を説明できる必要があります。

テストケース数ではなく、「フィードバックまで何分か」を品質指標にする発想です。

10. flaky testは品質ゲートの敵

flaky testとは、コードが同じでも成功したり失敗したりする不安定なテストです。

通常のテストでも問題ですが、スモークテストでは特に深刻です。

なぜならスモークは「止める」ために使うからです。

不安定なゲートは、開発者にこう学習させます。

またflakyだろう。再実行すればいい。

この状態になると、本当に壊れたときも見逃されやすくなります。

対策は、失敗時にretryを増やすだけではありません。

まず原因を分類します。

テストコードの待機条件
非同期処理
時刻依存
ランダム値
テストデータ衝突
外部サービス
ネットワーク
環境性能
並列実行競合
cleanup不足

UIテストでは固定sleepを避け、要素や状態の変化を待つ方が安定します。

悪い例:

await page.waitForTimeout(3000);
await expect(page.getByText('保存しました')).toBeVisible();

改善例:

await expect(page.getByText('保存しました')).toBeVisible({
  timeout: 5000,
});

「3秒待てばたぶん出る」ではなく、「期待状態になるまで最大5秒待つ」に変えています。

retryも便利ですが、retryが必要になった理由を消してはいけません。

おすすめは、

retry前の失敗を記録する
flaky率を測る
一定率を超えたら修正対象にする
直せない場合は一時的にsmokeから外す
ただしIssueを残す

という運用です。

11. テストデータ設計

スモークテストは短くても、データ設計が雑だと壊れます。

典型的な問題は、共有の固定ユーザーをすべてのCIが同時に更新することです。

PR AとPR Bのテストが同時に走り、同じユーザーの表示名や設定を更新すれば競合します。

改善策には次があります。

run IDを含む一意データ
専用namespace
test tenant
前処理で作成、後処理で削除
transaction rollback
read-onlyデータ
fixture
seeded database

たとえばGitHub Actionsのrun IDをテストデータ名に使うと衝突を減らせます。

const suffix = process.env.GITHUB_RUN_ID ?? Date.now().toString();
const email = "smoke+" + suffix + "@example.test";

ただし、cleanupの失敗にも備える必要があります。

テスト終了時に削除するだけでなく、一定期間以上古いテストデータを定期削除する仕組みがあると安心です。

本番スモークではさらに慎重になります。

「テスト注文」を本番に作るなら、会計、在庫、通知、分析、CRM、配送へ影響しない仕組みが必要です。

それが難しい場合は、本番では公開ページ、health、read-only APIだけに限定し、書き込み系はステージングで保証する方が安全です。

12. スモーク失敗時の運用を先に決める

スモークテストは、成功時より失敗時に価値が問われます。

失敗してから「これどうする？」と相談を始めると、リリース直前ほど判断がぶれます。

最低限、次を明文化します。

誰が一次確認するか
再実行を何回まで許すか
flaky扱いの条件
リリースを止める条件
例外承認できる人
例外理由をどこへ残すか
後追いIssueを必須にするか
失敗ログを何日保管するか
本番で失敗した場合のrollback条件
smoke自体が壊れた場合の扱い

「急いでいるから今回は無視」が積み重なると、ゲートは形骸化します。

例外を認めるなら、例外そのものを記録可能にします。

例えばPRコメントやIssueに次を残します。

失敗テスト
失敗理由
flakyと判断した根拠
誰が承認したか
いつまでに直すか
関連Issue

「通してしまった」ではなく、「例外として通した」という記録にします。

タグ設計で避けたいこと

一番ありがちな失敗は、タグを文章化してしまうことです。

api-smoke-critical-fast

のように全部を1タグへ押し込むより、
api
smoke
critical
fast

と独立させます。
そうすると将来的に、
smoke AND api
regression AND anime
critical AND api
fast AND NOT flaky

のような選択ができます。
もう一つ重要なのは、ブランチ名や日付をタグにしないことです。

pr-110
2026-10-08
api-firstCommit

などはテスト分類ではなく、実行履歴・CI・レポート側のメタデータとして管理した方がきれいです。
今回のAPIスモークテストから正式なルールにするなら、

タグ = テストそのものが持つ恒久的な性質
実行履歴 = PR・ブランチ・日時など、その実行時点の情報

と分離するのが、かなり重要な設計原則になります。

13. AI時代にスモークテストが重要になる理由

AIコーディング支援は、変更の速度と量を増やします。

これは大きな利点です。しかしレビューする人間の認知帯域は、同じ速度では増えません。

つまり、

コード生成が速い
リファクタリング範囲が広い
複数ファイルが一度に変わる
テストコードも生成される
設定ファイルも変更される
API仕様や型もまとめて変わる

という状況で、人間だけが「全部大丈夫か」を毎回目視判断するのは難しくなります。

そこで重要なのが、AIが変更しても壊してはいけない最低限の契約をスモークテストとして固定することです。

AIがコードを書いても、人がコードを書いても、

healthが通る
認証できる
主要APIが返る
最重要画面が開く
代表的な保存が通る

という契約は同じです。

この固定された契約が、AI開発の速度を安全側へ寄せます。

AIを導入したからテストを減らすのではなく、変更速度が上がったからこそ「短時間で壊れていないことを確認する仕組み」を強くする、と考える方が自然です。

14. AIに任せやすいこと

AIはスモークテストの補助者として非常に優秀です。

14.1 テスト候補の提案

diffを見せて、

「この変更で壊れる可能性がある主要経路と、スモークテスト候補を挙げて」

と依頼できます。

AIは変更ファイル、呼び出し関係、ルーティング、型、既存テストから候補を整理できます。

14.2 テストコードの草案

OpenAPI、ルーティング定義、React画面、既存テストを材料に、pytest、Playwright、shellの草案を作れます。

ここで「草案」と書いているのが重要です。

生成されたテストが仕様を正しく表現しているかは、人間が確認します。

14.3 失敗ログの要約

CIログが数千行あっても、

最初の失敗
二次エラー
推定原因
関連変更
次に見るファイル

を整理できます。

失敗ログの量が多い環境ほど効果があります。

14.4 不足テストの指摘

PRレビューで、

「変更された重要経路に対して、既存smokeがカバーしていない点はあるか」

と確認できます。

14.5 flaky候補の分析

過去ログから、特定ケースだけ再実行率が高い、特定時間帯で失敗する、特定runnerで遅いなどの傾向を見つける補助に使えます。

14.6 ドキュメント更新

スモークテストを追加したとき、

README
テスト一覧
実行方法
失敗時の対応
関連Issue

を同時更新させることもできます。

テストコードと文書が乖離するのを防ぎやすくなります。

15. AIに任せてはいけないこと

一方で、AIへ丸投げしない方がよい領域があります。

15.1 何が重要かの最終決定

AIはコードから依存関係を推測できます。しかし事業上の重要度までは、コードだけでは分かりません。

売上、法的義務、顧客契約、運用上の優先順位などは人間の文脈が必要です。

15.2 合否基準

「200なら成功」「5秒以内なら成功」「在庫差分がゼロなら成功」といった基準は、人間が要件として固定します。

AIに毎回判断させると、PRごとにゴールポストが動きます。

15.3 本番で許される副作用

AIが生成したテストが、本番でユーザー作成、メール送信、決済、削除を行うと危険です。

production-safeの定義は人間が持つべきです。

15.4 ゲート解除

AIが「おそらくflakyなので無視してよい」と判断して、自動でゲート解除する設計は危険です。

AIは提案まで。解除はルールまたは人間の責任で行う方が安全です。

15.5 secretの扱い

AIにCIログを渡すときも、token、cookie、個人情報が含まれていないか確認します。

ログ要約の便利さと情報保護は別問題です。

16. AIでテストを生成するときのプロンプト設計

「スモークテストを書いて」だけでは広すぎます。

次のように条件を固定します。

対象:
- Node.js API
- GET /health
- GET /api/books
- GET /api/me
- POST /api/books

目的:
- Pull Requestごとに3分以内で終了するsmoke suite

制約:
- 外部課金APIは呼ばない
- 本番データは変更しない
- flakyになりやすいsleep固定待機は禁止
- 合格条件を明示する
- 失敗時にendpoint名とstatusを出力する

出力:
- tests/smoke/*.spec.ts
- npm script
- GitHub Actions job

AIに自由度を与える場所と、固定する場所を分けるのがポイントです。

特に「目的」「実行時間」「副作用」「合否条件」「出力場所」は明示した方がよいでしょう。

17. Core SmokeとImpact Smoke

AIを使うと、PRのdiffに応じて実行するスモークを変える発想が出てきます。

これは有効ですが、完全動的にするのは危険です。

おすすめは二層構造です。

Core Smoke

どんな変更でも必ず走る固定セット。

起動
health
認証
最重要API
最重要画面

Impact Smoke

diffや変更領域に応じて追加するセット。

payments配下が変わった → 決済接続
authが変わった → login / logout
DB migration → 代表CRUD
front routing → 主要画面遷移
storage adapter → upload / download

AIはImpact Smokeの選定補助に使えます。

Core SmokeはAI判断で外さない。

これが重要です。

Coreを固定すると、AIの推論が外れても最低限の契約は残ります。

18. タグ設計

規模が大きくなると、タグ設計が効きます。

例:

@smoke
@regression
@auth
@api
@ui
@db
@critical
@readonly
@production-safe
@external

Playwrightではタグを付け、grepで絞り込めます。

npx playwright test --grep "@smoke"

本番向けに、smokeかつproduction-safeだけを実行する考え方もあります。

タグは「検索用文字列」ではなく、テスト運用の分類です。

命名ルールをREADMEに残し、誰でも同じ意味で使えるようにします。

19. 観測するメトリクス

スモークテストも運用すれば改善できます。

おすすめの指標は次です。

実行時間
成功率
flaky率
再実行率
失敗したテスト上位
本物の障害検出数
false positive
smoke通過後に詳細テストで即死した件数
MTTRへの寄与
テストケース数の増減
PR待ち時間
deploy後失敗率

重要なのは「通過率100%」を目的にしないことです。

壊れているのに100%通るテストは価値がありません。

逆に、いつも赤いテストも価値が下がります。

求めたいのは「壊れたときに赤く、正常なときに安定して緑になる」ことです。

20. 「スモークが通った」の意味を過大評価しない

スモークテストが通ったからといって、品質保証が完了したわけではありません。

スモークが示すのは、

少なくとも重要な入口は生きており、次の確認へ進めそうだ

という程度です。

セキュリティ、性能、アクセシビリティ、境界値、ブラウザ互換、障害耐性、長時間安定性などは別途確認が必要です。

スモークテストは“品質の証明”ではなく、“次へ進む許可”です。

この言い方をチーム内で共有すると、「smoke通ったからQA不要」という誤解を防げます。

21. 実務スモークテスト設計カタログ

ここからは、実際に何をスモークテストへ入れるかを具体化します。各ケースは、すべてのシステムで必須という意味ではありません。自分たちの重要経路、障害履歴、環境依存、事業影響に照らして採用してください。

21-1. API: health endpoint

対象領域: API
主目的: プロセスと最低限のサービス状態
代表操作: GET /health
合格条件: 200かつstatus=ok
主な注意点: DBまで見るかを仕様化する
推奨実行タイミング: PR・deploy

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。プロセスと最低限のサービス状態が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「200かつstatus=ok」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「DBまで見るかを仕様化する」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「200かつstatus=ok」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-2. API: readiness

対象領域: API
主目的: トラフィック受入可否
代表操作: GET /ready
合格条件: 依存サービスを含めready
主な注意点: 重い依存確認を入れすぎない
推奨実行タイミング: deploy

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。トラフィック受入可否が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「依存サービスを含めready」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「重い依存確認を入れすぎない」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「依存サービスを含めready」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-3. API: 認証付きプロフィール

対象領域: API/Auth
主目的: 認証基盤とtoken検証
代表操作: GET /api/me
合格条件: 200かつuser id存在
主な注意点: テストtokenの期限管理
推奨実行タイミング: PR・integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。認証基盤とtoken検証が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「200かつuser id存在」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「テストtokenの期限管理」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「200かつuser id存在」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-4. API: 代表一覧

対象領域: API
主目的: routing・DB read・serialize
代表操作: GET /api/items?limit=1
合格条件: 200かつ配列schema
主な注意点: データ0件を許容する仕様を明記
推奨実行タイミング: PR

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。routing・DB read・serializeが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「200かつ配列schema」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「データ0件を許容する仕様を明記」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「200かつ配列schema」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-5. API: 代表作成

対象領域: API
主目的: validation・DB write
代表操作: POST /api/items
合格条件: 201かつid発行
主な注意点: cleanup必須
推奨実行タイミング: integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。validation・DB writeが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「201かつid発行」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「cleanup必須」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「201かつid発行」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-6. API: 更新

対象領域: API
主目的: 更新処理と競合制御
代表操作: PATCH /api/items/:id
合格条件: 200かつ更新反映
主な注意点: 共有fixture競合
推奨実行タイミング: integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。更新処理と競合制御が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「200かつ更新反映」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「共有fixture競合」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「200かつ更新反映」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-7. API: 削除

対象領域: API
主目的: 削除経路
代表操作: DELETE test resource
合格条件: 規定status
主な注意点: 本番では原則実行しない
推奨実行タイミング: staging

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。削除経路が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「規定status」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「本番では原則実行しない」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「規定status」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-8. Web: トップページ

対象領域: Web
主目的: 配信・JS起動・主要DOM
代表操作: browser open
合格条件: main表示
主な注意点: 外部広告等を待たない
推奨実行タイミング: PR・deploy

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。配信・JS起動・主要DOMが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「main表示」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「外部広告等を待たない」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「main表示」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-9. Web: ログイン

対象領域: Web/Auth
主目的: フォームからsessionまで
代表操作: ログイン操作
合格条件: dashboard遷移
主な注意点: MFA環境差を分離
推奨実行タイミング: PR・integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。フォームからsessionまでが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「dashboard遷移」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「MFA環境差を分離」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「dashboard遷移」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-10. Web: 主要ナビゲーション

対象領域: Web
主目的: routing
代表操作: トップから主要画面へ遷移
合格条件: URLとheading一致
主な注意点: 細かい表示は回帰へ
推奨実行タイミング: PR

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。routingが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「URLとheading一致」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「細かい表示は回帰へ」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「URLとheading一致」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-11. Web: 保存

対象領域: Web
主目的: UI→API→DB
代表操作: フォーム保存
合格条件: 完了表示と再読込
主な注意点: 一意データ生成
推奨実行タイミング: integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。UI→API→DBが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「完了表示と再読込」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「一意データ生成」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「完了表示と再読込」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-12. Web: 検索

対象領域: Web
主目的: query→API→render
代表操作: 代表キーワード検索
合格条件: 結果領域表示
主な注意点: 検索結果件数を固定しすぎない
推奨実行タイミング: integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。query→API→renderが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「結果領域表示」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「検索結果件数を固定しすぎない」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「結果領域表示」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-13. Web: ファイルアップロード

対象領域: Web/Storage
主目的: 署名URL・storage・metadata
代表操作: 小さなfixture upload
合格条件: 完了とmetadata
主な注意点: 大容量性能試験は別
推奨実行タイミング: integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。署名URL・storage・metadataが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「完了とmetadata」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「大容量性能試験は別」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「完了とmetadata」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-14. Mobile: 起動

対象領域: Mobile
主目的: bundleと初期化
代表操作: cold start
合格条件: 初期画面到達
主な注意点: 端末全組合せをsmokeにしない
推奨実行タイミング: build

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。bundleと初期化が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「初期画面到達」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「端末全組合せをsmokeにしない」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「初期画面到達」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-15. Mobile: 認証

対象領域: Mobile/Auth
主目的: secure storage・API
代表操作: ログイン
合格条件: home到達
主な注意点: OS権限dialogを制御
推奨実行タイミング: integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。secure storage・APIが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「home到達」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「OS権限dialogを制御」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「home到達」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-16. DB: 接続

対象領域: DB
主目的: credential・network
代表操作: SELECT 1
合格条件: 成功
主な注意点: 接続だけで業務schemaは保証しない
推奨実行タイミング: deploy

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。credential・networkが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「成功」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「接続だけで業務schemaは保証しない」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「成功」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-17. DB: migration

対象領域: DB
主目的: schema整合
代表操作: migration後の代表query
合格条件: 期待column利用可
主な注意点: rollback戦略も別途検証
推奨実行タイミング: deploy

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。schema整合が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「期待column利用可」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「rollback戦略も別途検証」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「期待column利用可」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-18. Cache: read/write

対象領域: Cache
主目的: Redis等接続
代表操作: set/get test key
合格条件: 一致
主な注意点: TTLとnamespace
推奨実行タイミング: integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。Redis等接続が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「一致」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「TTLとnamespace」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「一致」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-19. Queue: enqueue/dequeue

対象領域: Messaging
主目的: broker・consumer
代表操作: test message送信
合格条件: consumer処理完了
主な注意点: 非同期waitをpolling化
推奨実行タイミング: integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。broker・consumerが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「consumer処理完了」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「非同期waitをpolling化」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「consumer処理完了」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-20. Object Storage

対象領域: Storage
主目的: credential・bucket
代表操作: fixture put/get
合格条件: hash一致
主な注意点: cleanup
推奨実行タイミング: integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。credential・bucketが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「hash一致」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「cleanup」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「hash一致」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-21. Email adapter

対象領域: External
主目的: メール連携
代表操作: sandbox送信
合格条件: provider accepted
主な注意点: 本番宛先禁止
推奨実行タイミング: staging

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。メール連携が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「provider accepted」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「本番宛先禁止」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「provider accepted」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-22. Payment adapter

対象領域: External/Payment
主目的: 決済接続
代表操作: sandbox auth
合格条件: 規定success
主な注意点: 本番課金禁止
推奨実行タイミング: staging

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。決済接続が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「規定success」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「本番課金禁止」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「規定success」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-23. Feature Flag

対象領域: Platform
主目的: flag provider
代表操作: flag取得
合格条件: 期待type
主な注意点: default fallback確認
推奨実行タイミング: integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。flag providerが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「期待type」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「default fallback確認」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「期待type」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-24. Secrets

対象領域: Platform
主目的: secret injection
代表操作: 必要secret参照
合格条件: 空でない・format妥当
主な注意点: 値自体をログ出力しない
推奨実行タイミング: deploy

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。secret injectionが壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「空でない・format妥当」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「値自体をログ出力しない」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「空でない・format妥当」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-25. CORS

対象領域: Web/API
主目的: origin設定
代表操作: preflight
合格条件: 許可header
主な注意点: 環境ごとの差
推奨実行タイミング: deploy

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。origin設定が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「許可header」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「環境ごとの差」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「許可header」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-26. DNS/TLS

対象領域: Infra
主目的: 公開到達性
代表操作: HTTPS request
合格条件: 証明書有効・200
主な注意点: 期限監視は別途
推奨実行タイミング: deploy

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。公開到達性が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「証明書有効・200」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「期限監視は別途」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「証明書有効・200」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-27. Observability

対象領域: Ops
主目的: ログ・trace入口
代表操作: test request
合格条件: request id確認
主な注意点: テストが監視ノイズにならない
推奨実行タイミング: deploy

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。ログ・trace入口が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「request id確認」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「テストが監視ノイズにならない」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「request id確認」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-28. Scheduler/Cron

対象領域: Batch
主目的: 定期処理定義
代表操作: dry-runまたはmanual dispatch
合格条件: 処理開始可能
主な注意点: 時刻依存を固定
推奨実行タイミング: staging

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。定期処理定義が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「処理開始可能」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「時刻依存を固定」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「処理開始可能」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-29. AI API integration

対象領域: AI
主目的: モデルAPI接続
代表操作: 最小prompt
合格条件: schema受領
主な注意点: 出力内容の完全一致を要求しない
推奨実行タイミング: integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。モデルAPI接続が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「schema受領」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「出力内容の完全一致を要求しない」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「schema受領」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

21-30. Multi-service critical path

対象領域: Distributed
主目的: 複数サービス結合
代表操作: gateway→service→DB
合格条件: 最小business response
主な注意点: 失敗点をtrace可能にする
推奨実行タイミング: integration

このケースをスモークへ採用する理由は、詳細な網羅性ではなく、後段テストを実行する前提そのものを短時間で確認できる点にあります。複数サービス結合が壊れている状態では、その上に積み上がる多数のテストが連鎖的に失敗する可能性があります。そのため、まず代表操作で入口を確認し、失敗した場合は後段へ進まず原因を切り分けます。

実装時には、成功条件を曖昧な文章だけで残さず、機械判定できる形へ落とします。今回なら「最小business response」を中心に、HTTP status、schema、画面要素、DB結果、message stateなど、対象に適したassertionを置きます。逆に、スモークの段階で詳細な境界値や大量パターンを追加しすぎないことも重要です。ここで確認したいのは“完全に正しいか”ではなく、“主要経路が生きていて、次のテストへ進めるか”だからです。

自動化では、失敗時の診断性も設計します。最低限、対象ケース名、環境、commit SHA、期待値、実値、主要ログを残します。UIなら失敗時スクリーンショット、APIならstatusと安全な範囲のresponse body、分散システムならrequest IDやtrace IDを保存すると切り分けが速くなります。

特に注意すべき点は「失敗点をtrace可能にする」です。スモークテストは頻繁に実行されるため、1回では小さな副作用でも、PRごと・デプロイごとに積み重なると大きな問題になります。本番環境で実行する場合は production-safe の分類を分け、読み取り専用、専用データ、sandbox、dry-runなどを優先します。

AIを使う場合、このケースのテストコード草案、assertion候補、失敗ログ要約、diffからの実行推奨までは任せやすい領域です。一方、「最小business response」という合格条件自体をPRごとにAIが勝手に変更する設計は避けます。合否基準は人間が管理する仕様・テスト戦略・コードレビューの対象として固定し、AIはその契約を実装・検証する補助者として利用します。

運用開始後は、このケースが本当に価値を出しているかを定期的に見直します。実行時間が長くなっていないか、flaky率が高くないか、実際の障害を検出したことがあるか、逆に詳細テストで即座に見つかる重大障害を素通りしていないかを確認します。スモークテストは一度作って終わりではなく、障害・変更・アーキテクチャの変化に合わせて育てる品質ゲートです。

22. 導入手順――最初の一週間でやること

ここまで読んで「考え方は分かったが、どこから始めればいいか」と感じた場合は、最初から大規模なテスト基盤を作る必要はありません。

一週間の導入プランとして、次の順番を勧めます。

Day 1: 重要経路を五つ決める

チームで30分だけ話し、次の問いに答えます。

これが壊れたらサービスを使えないものは何か
過去によく壊れたものは何か
デプロイ直後に毎回人が確認しているものは何か
認証・DB・外部サービスのうち最重要は何か
ユーザーが最初に到達する価値は何か

ここで五つ程度に絞ります。

Day 2: 手動で実行してみる

いきなり自動化せず、curl、ブラウザ、既存テストコマンドで実行します。

目的は「本当に数分で確認できるか」「合否条件が曖昧でないか」を確かめることです。

Day 3: 自動化する

shell、pytest、Jest、Vitest、Playwrightなど、既存スタックに合う方法で自動化します。

新しいツールを入れること自体を目的にしません。

Day 4: CIへ接続する

Pull Requestまたはdevelopへのpushで実行します。

最初からrequired checkにして開発を止めることへ不安がある場合、数日間は結果を観測し、flakyがないことを確認してからrequiredにしても構いません。

Day 5: 失敗時のルールを決める

再実行回数
担当
例外承認
ログ保存
flaky対応

を決めます。

Day 6: AIレビューを試す

PR差分をAIに渡し、Core Smokeに加えて必要なImpact Smokeを提案させます。

提案をそのまま採用せず、人間が「本当に重要か」を確認します。

Day 7: 振り返る

実行時間、失敗回数、ノイズを確認します。

最初の一週間で「完璧なテスト」を作るのではなく、「毎回使われる小さなゲート」を作ることが成功条件です。

23. Pull Requestレビュー用チェックリスト

スモークテストの追加・変更をレビューするときは、次を確認します。

本当に重要経路か
失敗したら後段を止める価値があるか
合格条件が明確か
実行時間予算を守れるか
既存テストと重複しすぎていないか
外部サービス依存を増やしすぎていないか
テストデータは衝突しないか
cleanupできるか
固定sleepを使っていないか
failure artifactを残せるか
secretをログへ出さないか
本番実行時の副作用は安全か
AIが生成した期待値に仕様上の根拠があるか
retryで本当の問題を隠していないか
誰がこのテストを保守するか分かるか

このチェックリストは、テストの「正しさ」だけでなく「運用できるか」を見るためのものです。

テストはコードなので、保守対象です。

24. AIレビュー用プロンプト

以下は、Pull Requestに対してAIへテスト観点のレビューを依頼するときの例です。

このPull Requestのdiffと既存テストを確認してください。

目的:
重要機能が壊れていないことを数分で確認するSmoke Testの不足をレビューする。

必ず分けて出力:
1. Core Smokeで常に必要なもの
2. 今回のdiffにより追加実行したいImpact Smoke
3. SmokeではなくRegressionへ回すもの
4. 本番で実行してはいけない副作用のあるケース
5. flakyになりそうなポイント
6. 失敗時に残すべきログ・artifact

制約:
- 合否基準を勝手に緩めない
- retry追加だけで問題を隠さない
- sleep固定待機を推奨しない
- secret値をログ出力しない
- 既存仕様に根拠がない期待値を発明しない
- Core Smokeをdiffだけを理由に外さない

この依頼では、AIに「テストを書け」だけでなく、「分類してレビューせよ」と求めています。

AIが得意なのは候補の列挙と比較です。

最終判断はテックリード、開発者、QAなど、人間が持ちます。

25. GitHub Actionsで本番安全なスモークを分ける

PRと本番後では、同じテストをそのまま使えないことがあります。

本番では書き込み、削除、メール送信、課金などを避けたいからです。

そのため、タグやjobを分けます。

name: smoke

on:
  pull_request:
  workflow_dispatch:

jobs:
  pr-smoke:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run test:smoke

  production-safe:
    if: github.event_name == 'workflow_dispatch'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright test --grep "@production-safe"

実際には、Environment保護、承認、secret、OIDC、IP制約など、プロジェクトのセキュリティ要件と組み合わせます。

「スモークだから安全」ではありません。

テストコードも本番に対して操作をするプログラムです。

26. スモークテストと監視は同じではない

スモークテストとsynthetic monitoringは似ています。

どちらも重要導線を自動的に確認できます。

違いは目的とタイミングです。

スモークテストは、変更やデプロイの節目で「次へ進めるか」を判定する品質ゲートとして使うことが中心です。

synthetic monitoringは、リリース後も継続的にユーザー行動を模倣し、サービスが動き続けているかを見る用途が中心です。

同じテストロジックを一部共有することは可能です。

ただし、監視頻度、アラート、本番データへの副作用、認証情報、timeoutは別設計にした方が安全です。

例えばログインのproduction-safe smokeをデプロイ直後に一度実行するのと、5分ごとに24時間実行するのでは、アカウントロックやアクセスログへの影響がまったく違います。

27. スモークテストとSLO

成熟したシステムでは、スモークの合否を単純な機能可否だけでなく、サービスレベルと結びつけたくなることがあります。

例えば、

主要APIが応答する
かつ一定時間以内
かつ依存サービスがready

という条件です。

ただし性能条件を厳しく入れすぎると、CI環境やネットワークノイズによってflakyになりやすくなります。

そのため、

PR Smoke: 主に機能可否
Staging Smoke: 軽い応答時間条件
Performance Test: 本格的な負荷・統計
Monitoring / SLO: 本番継続観測

と役割を分ける方が扱いやすいでしょう。

28. ドキュメントとして残すべきもの

スモークテストはコードだけ残しても、数か月後に意図が分からなくなることがあります。

最低限、次をREADMEまたはテスト戦略へ残します。

定義

自分たちのチームでSmokeをどう定義するか。

実行方法

ローカルとCIでどう実行するか。

対象

Core Smokeの一覧。

タグ

smoke、production-safe、authなどの意味。

実行タイミング

PR、develop、release、deploy後など。

失敗時のルール

retry、担当、例外承認。

本番安全性

何をしてよく、何をしてはいけないか。

所有者

誰が見直すか。

履歴

重大障害を受けて追加されたケースなら、そのIssueへのリンク。

テストが「なぜ存在するか」を保存すると、不要に見えて消されたあと同じ障害が再発する問題を減らせます。

29. TeamSunstripeでの実践モデル

TeamSunstripeのAPIやWeb開発へ当てはめるなら、次のようなモデルが考えられます。

Core Smoke

公開サービスのhealth
API共通処理
認証
代表的なread API
代表的なwrite API
主要Web画面

Domain Smoke

books、anime、wiki、story、newsなど、各ドメインの代表的なAPIを一つずつ持つ。

すべての詳細ケースを毎回実行するのではなく、「そのドメインの入口が生きている」ことを確認します。

Impact Smoke

PRの変更領域に対応して追加実行します。

例えばwiki APIを変更したならwiki系の追加ケース、DB共通層を変更したなら複数ドメインの代表read、認証を変更したなら認証付きAPIを広めに実行します。

Post-deploy

本番では、health、公開GET、production-safeな認証確認などに限定します。

この構造なら、APIの数が増えても「全テストを毎PRで全部回す」状態を避けつつ、最低限の信頼を維持できます。

30. プログラミングラボの現場会話

神崎レオン / API Lead

「API開発で一番困るのは、詳細テスト以前に“そもそも入口が死んでいる”状態を後から見つけることです。health、認証、代表GET、代表POST、DB疎通。この数本だけでも先に通せれば、その後の調査コストはかなり下がります」

白石律 / API Platform

「CIでは全部を毎回回すより、PRごとに短いsmoke、develop統合で少し広いsmoke、デプロイ後にproduction-safeなsmoke、と三段階に分けたいです。速さが価値なので、スモークに何十分もかかるなら設計を見直した方がいい」

真壁景 / Data & DB

「DB系は“接続できた”だけでは弱いですね。読み取り一件、必要ならテスト用の書き込みとrollbackまで。ただし本番データを壊さないことが最優先。環境ごとに実行可能なケースを分ける必要があります」

雨宮澄花

「フロント側では、トップ画面、認証、主要導線一本、保存一回くらいをsmokeで明示しておくと扱いやすいです。UIを細かく検証しすぎると回帰テストになるので、“ユーザーが最重要操作を始められるか”に絞りたいですね」

黒羽みちる

「分析の観点では、スモークテストの価値は“何件通ったか”だけではありません。どの段階で失敗したか、平均実行時間、flaky率、検出した障害の種類を記録すると、品質ゲートそのものを改善できます」

博士知愛

「つまり、むずかしいテストをいっぱいやる前に、“この子ちゃんと立って歩ける？”を先に見るんだね。そこで転んでいたら、先にそこを直す！」

ルート・ドキュメンツ

「定義、実行条件、責任範囲、失敗時の扱いを文書化してください。“スモークテスト”という名前だけ共有して、各人が別の意味で使う状態が最も危険です」

この会話で出ている論点は、スモークテストを長く運用する上で重要です。

「何をテストするか」だけでなく、「どこで止めるか」「誰が判断するか」「どう記録するか」まで含めて設計します。

31. 最小構成から始めるなら五本

最初から完璧なスモーク基盤を作る必要はありません。

おすすめの初手は五本です。

アプリまたはサービスが起動する
health / readiness が成功する
認証できる
最重要GETが成功する
最重要POSTまたはUIフローが成功する

これをCIに入れ、実行時間を測ります。

その後、実際の障害や変更履歴を見ながら育てます。

最初から100ケース作って運用に失敗するより、五本を毎日確実に使う方が価値があります。

32. まとめ

スモークテストを一言で表すなら、

詳細テストへ進む前に、重要経路が生きていることを短時間で確認する品質ゲート

です。

重要なのは、ケース数を増やすことではありません。

重要なものを選ぶ
速くする
安定させる
合否を明確にする
失敗したら止める
失敗理由を追えるようにする
後段テストと役割分担する
本番副作用を制御する
定義と意図を文書化する

これが基本です。

そしてAI時代には、さらに次を加えます。

AIにテスト候補を提案させる
AIにテストコード草案を作らせる
AIに失敗ログを要約させる
AIにdiffからImpact Smokeを提案させる
AIにドキュメント更新を補助させる
ただしCore Smokeと合否基準は人間側で固定する
本番副作用やゲート解除をAI任せにしない

AIは、品質ゲートを壊す存在にも、強化する存在にもなります。

違いを生むのは、AIそのものより「人間が何を契約として固定したか」です。

まずは五本で構いません。

起動、health、認証、代表GET、代表的な保存。

それを毎回、確実に、速く通す。

スモークテストは地味ですが、開発の速度が上がるほど価値が増す仕組みです。

参考資料

ISTQB Glossary — Smoke testing
https://glossary.istqb.org/en_US/term/smoke-testing
MDN Web Docs — Smoke test（日本語）
https://developer.mozilla.org/ja/docs/Glossary/Smoke_Test
GitHub Docs — GitHub Actions ワークフロー構文
https://docs.github.com/ja/actions/reference/workflows-and-actions/workflow-syntax
Playwright — Annotations / Tags
https://playwright.dev/docs/test-annotations
Playwright — Test API
https://playwright.dev/docs/api/class-test

管理情報

スクランブル研究所調査: TeamSunstripe/ReportFiles Issue #124
プログラミングラボ現場整理: TeamSunstripe/programming Issue #4
開発ブランチ: qiita/smoke-testing-with-ai/develop
記事: qiita/smoke-testing-with-ai/2026-10-08-smoke-testing-with-ai.md
Qiita Skill: skills/qiita-technical-article/SKILL.md
作成日: 2026-10-08

追補（2026-10-08）：AI-TDD、学習カリキュラム、テスト改変防止

スモークテストとTDDは別の軸

スモークテストは、主要な入口が動いているかを確かめるテストの目的・選び方です。TDD（テスト駆動開発）は、テストを先に用意して実装を進める開発の進め方です。TDDのテストがそのままスモークに適するとは限らず、スモークの中にTDD由来のケースが入ることもあります。

TDDではテストケースを洗い出し、次に実現する振る舞いのテストを書き、まず失敗（Red）を確認し、最小実装で成功（Green）させ、振る舞いを維持しながら整理（Refactor）します。この一連の流れはMartin Fowlerの説明とも一致します。

AIと進めるなら「人間が受け入れ条件を定義 → AIがテスト案を出す → 人間が期待値を確認 → Redの証拠を保存 → AIが実装 → Green → Refactor → 回帰・スモーク」という手順にします。Redの失敗は、実装が未完了だから起きているのか、環境不備・依存不備・テスト自身のバグなのか区別しなければなりません。

AIによるテスト改変をどう防ぐか

「テスト変更禁止」は一律の永続禁止ではなく、実装担当エージェントが自分の都合で期待値を変える行為を制限するルールとします。仕様変更で期待値を直す必要があるときは、理由、差分、承認者を記録し、人間によるレビューを行います。

仕様・受け入れ条件の承認者は人間
テスト担当AIと実装担当AIの役割を分離
実装担当AIは承認なしで受け入れテストの期待値を変更しない
CI側でテストファイルの変更を検知し、必要に応じてCODEOWNERS等のレビューを要求
テストの無効化、skip、only、閾値緩和、retry増加をレビュー対象にする
Redのログ、Greenのログ、テスト差分、実装差分をPRに残す

CLAUDE.mdやSkillの指示はエージェントの振る舞いを案内するものですが、強制力のあるアクセス制御やブランチ保護の代わりにはなりません。保護にはCI、レビュー、権限設定を組み合わせます。

AIテスト駆動という言葉の三つの意味

用法	対象	例
AI支援TDD	開発手法	AIとRed→Green→Refactor
AIによるテスト生成	テスト設計の自動化	境界値、スモーク候補、テストコード案
AI機能の評価（evals）	AI出力そのものの品質	正確性、安全性、構造、再現性の評価

これらは混同しないことが重要です。AI機能のevalsは、通常のHTTP 200や画面表示だけでは十分に検証できないため、評価データ、採点基準、変動への扱いを別途定義します。

学習カリキュラムへの接続

LEVEL	提案
LEVEL 2 指示設計	「合格すべきテスト」と「実行コマンド」を完了条件に加える
LEVEL 4 計画→実装→テスト	Red→Green→Refactorを演習へ追加
LEVEL 5 CLAUDE.md	テストコマンド、期待値変更の承認ルール、ログ出力ルール
LEVEL 7 Skill	smoke-testの候補選定、実行、証跡保存、失敗時停止を再利用
LEVEL 8 サブエージェント	テスト設計と実装を別役割で実行・レビュー
LEVEL 10 安全	本番へ進める前にproduction-safe smokeを実行

ここでのLEVELはユーザー提供のカリキュラム案に基づく対応付けです。公開する正式版では対象教材の現行定義との照合を行います。

ギルドサイトのスモーク候補

提供されたテスト仕様書のケース番号を仮の追跡キーとして使います。実際のテスト仕様書本文との突合は未実施のため、実装着手前に操作・期待値・前提条件を確認してください。

候補	テストID	確認したい主要機能
登録と遷移	T-001	ニックネーム登録後にダッシュボードへ進む
初期状態	T-010	初期ランクF、XP 0
永続化	T-020	チェック操作のJSON保存
記事表示	T-040	解説ページの表示
設定保持	T-050 / T-052	テーマ切替と再読み込み後の保持

この5系統が5分以内で安定して回るかを試し、遅い場合は軽量なCore Smokeと後段の回帰へ分けます。本番で状態変更するテストは実行しない、または安全な専用環境に限定します。

calcRank()で学ぶAI-TDD

XP閾値の仕様表がある前提で、まずその表に対応する境界値テストを作り、失敗を確認します。続いてAIにPHP実装を依頼し、テストを通します。仕様値が未確定ならAIに閾値を推測させず、テスト期待値を保留します。

// 例示：閾値は仕様確定後に置き換える
// $this->assertSame('F', calcRank(0));
// $this->assertSame('E', calcRank($documentedThresholdE));

この例は説明用であり、実際のPHPテストコードの実行・検証結果ではありません。

現場での合意――🔠 プログラミングラボ💻

神崎レオン（API）「スモークは統合の入口です。TDDで単体の正しさを先に確かめても、デプロイ後のDB接続までは保証できません。両方必要です」

白石律（Platform）「CLAUDE.mdに『テストを直すな』だけ書くのは弱い。CIで差分を検知して、人間が承認した場合だけ変更できる仕組みへつなげます」

真壁景（DB）「ランク境界の仕様を決めずにAIへテスト生成させると、仕様までAIが発明してしまいます。仕様を先に固定しましょう」

黒羽みちる（分析）「RedとGreenの証拠、テスト改変回数、実行時間、flaky率を追えば、AI支援が本当に改善につながったか比較できます」

博士知愛（学習支援）「まず『こう動いてほしい』をテストにして、まだ動かないのを確かめて、それから作るんだね！」

ルート・ドキュメンツ（管理）「その約束は記事だけでなく、Skillと開発手順、レビューの記録にも残しましょう」

参考資料

Martin Fowler, Test Driven Development: https://martinfowler.com/bliki/TestDrivenDevelopment.html
Playwright, Annotations: https://playwright.dev/docs/test-annotations
Playwright, Command line: https://playwright.dev/docs/test-cli
ISTQB Glossary（日本語）: https://istqb-glossary.page/jp/スモークテスト-smoke-test/

更新情報

追補: 2026-10-08。資料: ユーザー提供のClaude・Gemini整理メモ。元チャットURLは参照導線として扱い、リンク先の会話内容自体を外部検証したものではありません。