テスト自動化しない方がいいケース7選｜QAエンジニアの実務判断基準

🐙 ソースコードはこちら GitHub — automated-testing-portfolio 💼 仕事のご依頼はこちら LinkedIn — Yoshitsugu Baba
2026.06.06

テスト自動化を進めるQAエンジニアが見落としがちな「自動化すべきでないテスト」「自動化に向かないテストケース」を7選で解説します。探索的テスト・外部サービス連携・UX評価など、自動化すると逆にROI（費用対効果）が悪化する具体的なケースと、手動・部分自動化・監視を使い分ける実務判断基準を紹介します。

「自動化できる＝自動化すべき」ではありません。自動化すべきでないテストを見極めることが、長続きする自動化の条件です。

📌 この記事はこんな方におすすめ

  • 自動化を進めているが「何でも自動化」してメンテコストが爆発した経験がある方
  • 自動化の対象選定に迷っているQAエンジニア・テストリード
  • チームに「自動化しない判断基準」を共有したい方
  • 費用対効果の高い自動化戦略を構築したい方

✅ この記事を読むと得られること

  • 自動化しない方がいいテストケース7つの具体的な内容と理由がわかる
  • 「自動化できる」と「自動化すべき」の違いが明確になる
  • 各ケースに対する実務での対処法・代替手段がわかる

👤 この記事を書いた人

QAエンジニア・テスト自動化エンジニアとして15年以上の実務経験を持つ Yoshi が執筆。「全部自動化しよう」としてメンテナンスコストが膨らんだ失敗を経験したからこそ、「自動化しない判断」の重要性を実感しています。

📌 結論（3つのポイント）

  • 自動化しない方がいいテストケースとは「感性・判断・一回性・外部依存・高コストセットアップ」が絡むもの
  • 「自動化できる技術がある」≠「自動化すべき」。ROI（Return on Investment：費用対効果）が合うかどうかが判断基準
  • 自動化しないテストを手動で効率よくこなすことも、QAエンジニアの重要なスキルセット

「PlaywrightでE2Eテストを書けるようになった」「pytestでAPIテストを自動化できた」——スキルが上がるほど、「これも自動化できる」という誘惑が増えます。

しかし、自動化できるからといって自動化すべきとは限りません。この記事では実務経験から厳選した「自動化しない方がいいテストケース7選」を、具体的なケースレベルで解説します。

💡 この記事の前提：「自動化しない」は「何もしない」ではありません。実務では完全自動化・部分自動化（モック化・前処理だけ自動化）・Synthetic Monitoring・手動の組み合わせが現実的な選択肢です。この記事では「完全な自動化テストコードを書くべきでないケース」にフォーカスして解説します。

📖 関連記事との使い分け

📋 この記事の目次

  1. ① 画面の見た目・レイアウトの目視確認
  2. ② UI/UXの「使いやすさ」評価
  3. ③ 感性・直感を使う探索的テスト
  4. ④ 仕様確定前・プロトタイプ段階の機能テスト
  5. ⑤ 一回限りのデータ移行・環境構築テスト
  6. ⑥ 外部決済・SNS認証など第三者サービスの実環境テスト
  7. ⑦ セットアップコストがテスト実行時間を大幅に超えるテスト
  8. 無理な自動化がFlakyテストを生む理由
  9. 判断チェックリスト
  10. FAQ

自動化しない方がいいテストケース7選とは？早見表

まず7つのケースを一覧で確認しましょう。

#テストケースの種類自動化NG理由手動代替
①画面の見た目・レイアウトの目視確認「美しいか」の判断は人間にしかできない✅
②UI/UXの「使いやすさ」評価ユーザー満足度はPass/Failで測れない✅
③感性・直感を使う探索的テスト「なんか怪しい」は自動化できない✅
④仕様確定前・プロトタイプ段階の機能テスト毎週変わる仕様に追いつけない✅
⑤一回限りのデータ移行・環境確認テスト二度と使わないコードに投資する意味なし✅
⑥外部決済・SNS認証など第三者サービスの実環境テストCAPTCHA・レート制限・実課金が壁になる✅
⑦セットアップコストがテスト実行時間を大幅に超えるテスト準備工数がROIを完全に食いつぶす✅

① 画面の見た目・レイアウトの目視確認とは？

「ボタンが正しい位置にあるか」「フォントサイズが統一されているか」「ホバー時のアニメーションが滑らかか」——こうした視覚的な確認は、ツールで合否判定できる性質のものではありません。

自動化が難しい具体的なケース

  • ブランドカラーの「温かみ」「洗練度」の評価
  • レスポンシブデザインの「自然な崩れ方」の確認
  • アニメーション・トランジションの滑らかさ
  • 複数フォントが混在した際の可読性評価
  • ダークモード切替時の配色バランス
⚠️ VisRegについての補足：Visual Regression Testing（VisReg）ツール（Percy・Applitools等）は、ピクセル差分やAIベースの比較で「前回との変化」を検知できます。デザインシステムとベースライン比較を組み合わせれば、一定の自動判定も可能です。ただし「その変化がデザイン意図として良いか悪いか」の最終判断は人間が行うケースがほとんどです。VisRegは目視確認を省力化する有効なツールですが、デザインの品質評価を完全に代替するものではない、という理解が実務では適切です。
💡 実務での対処法：UIの数値的な確認（要素の存在・テキスト内容・クリック可否）は自動化し、見た目の品質評価は定期的な手動レビューセッションに分離するのがベストプラクティスです。

② UI/UXの「使いやすさ」評価とは？

「このフォームは直感的に操作できるか」「エラーメッセージは理解しやすいか」「ナビゲーションの導線は自然か」——ユーザー体験の品質はPass/Failで数値化できません。

自動化が難しい具体的なケース

  • 新規ユーザーが「迷わず操作できるか」の評価
  • エラーメッセージの「わかりやすさ」確認
  • 画面遷移の「流れの自然さ」チェック
  • モバイルでの「タップしやすさ」評価
  • 高齢者・障害を持つユーザーへのアクセシビリティ体験確認
⚠️ 注意：アクセシビリティ（WCAG準拠・ARIAラベル・コントラスト比）のチェックは自動化できます（axe-core等）。しかし「実際に使ってみてどう感じるか」というUX体験の評価は自動化できません。この2つを混同しないようにしましょう。
💡 実務での対処法：ユーザビリティテストは少人数（5名程度）での手動セッションが効果的です。「操作中に詰まった箇所」「声に出した不満」を記録する方法（Think-Aloud法）が実務でよく使われます。

③ 感性・直感を使う探索的テストとは？

「なんかここの動きが怪しい」「このパラメータを変えたらどうなるだろう」——QAエンジニアの経験と直感から生まれるテストです。既存の判断記事でも触れていますが、この記事では「どんな場面で探索的テストが威力を発揮するか」をより具体的に掘り下げます。

⚠️ 補足：monkey testing・fuzz testing・AI-assisted testing など「探索的に近いアプローチ」は存在します。ただしこれらは「ランダム入力で予期しない挙動を探す」ものであり、「熟練QAエンジニアが仮説を立てながら試す」という人間主導の探索的テストの本質部分は代替できていません。この記事では後者の「人間の判断・直感が核となる探索的テスト」を対象としています。

探索的テストが特に有効な具体的なシーン

  • バグが集中する境界付近の調査：自動化テストがパスしているのに本番でバグが出た直後
  • 新機能の初回リリース前：仕様書に書かれていない組み合わせを試す
  • リファクタリング後の回帰確認：コード変更の意図しない影響を探る
  • セキュリティ・脆弱性の調査：攻撃者の視点でシステムを試す（ペネトレーションテスト的なアプローチ）
💡 実務Tip：探索的テストを「なんとなくやる」のではなく、チャーター（目的・対象・時間）を決めてセッションベースで実施すると品質が上がります。「30分でログイン周辺のエラーハンドリングを探索する」という形で構造化するのが実務でのベストプラクティスです。

④ 仕様確定前・プロトタイプ段階の機能テストとは？

開発初期はUIも仕様も毎週変わります。この段階で自動化テストを書くと、仕様変更のたびにテストコードの修正が発生し、結果的に「テストコードのメンテナンス専任者」になってしまいます。

自動化が早すぎるサインの具体例

状況自動化の判断理由
デザインカンプが週単位で変わっている❌ まだ早いセレクターが毎週壊れる
APIのレスポンス構造が未確定❌ まだ早いスキーマ変更のたびにテストが落ちる
ステージング環境が安定していない❌ まだ早いFlakyテストが量産される
仕様が3ヶ月間変わっていない✅ 自動化検討安定した仕様に投資できる
リリース済みで毎回手動確認している✅ 自動化すべき繰り返しコストを削減できる
💡 実務Tip：「仕様が3ヶ月変わっていないか」は自動化開始のひとつの目安です。ただしチームの開発サイクルや製品フェーズによって適切なタイミングは異なります。重要なのは「仕様変更のたびにテストコードが壊れる頻度が高すぎないか」を確認することです。それ以前は探索的テストで品質を担保しながら、仕様が安定してから自動化するのが無駄のない進め方です。

⑤ 一回限りのデータ移行・環境構築テストとは？

本番データの移行確認、旧システムから新システムへの切り替え検証、特定イベント期間中だけ必要なテスト——これらは「一生に一度しか実行しない」テストです。

一回限りテストの具体例

  • DBスキーマ変更後の既存データ整合性確認（移行後に1回だけ実行）
  • クラウド移行時のデータ件数・内容の突合チェック
  • 年に一度の大型セール期間中だけ必要な在庫・価格テスト
  • 外部システム統合時の初回データ取込み確認
⚠️ 注意：「データ移行テスト」という名称でも、同様の移行が定期的に発生するバッチ処理の場合は自動化を検討すべきです。「一回性かどうか」が判断のポイントです。
💡 実務での対処法：一回限りのテストはSQLスクリプトやスプレッドシートによるチェックリストが現実的です。自動化コードを書く工数を、テスト設計と実行結果の文書化に充てる方が価値が高いです。

⑥ 外部決済・SNS認証など第三者サービスの実環境テストとは？

Stripe・PayPal・LINE Login・Google OAuthなど、外部サービスと連携した機能の実環境テストには、自動化の大きな壁があります。これは既存の判断記事では詳しく触れていないポイントです。

自動化を阻む具体的な壁

壁の種類具体的な問題代替手段
CAPTCHAボット判定で自動化が阻まれるテスト環境でCAPTCHA無効化
レート制限短時間に大量リクエストでBANされるモックサーバーで代替
実課金テストのたびに実際の決済が走るリスクサンドボックス環境を利用
SMS/メール認証実機へのOTP到達を自動取得できないテスト用仮想番号サービス
OAuth認証フロー外部サービスのUI変更で突然壊れる認証部分をモック化してAPI層でテスト
💡 実務Tip：外部サービス連携のテストは「完全自動化か手動か」の二択ではありません。実務では次のような中間戦略がよく使われます。

  • モック化＋API層テスト：外部サービスをモックに差し替えて自動化できる範囲をカバー
  • Synthetic Monitoring：本番環境に対して定期的に軽量な疎通確認スクリプトを実行
  • Observability（監視）で補完：外部連携のエラー率・レスポンスタイムをダッシュボードで監視
  • 月次手動確認：決済フローの最終確認（実課金→キャンセルまで）は月1回の手動確認で十分なケースが多い

「自動化しない＝何も対策しない」ではなく、監視・モック・部分自動化を組み合わせて品質を担保するのが実務のベストプラクティスです。

⑦ セットアップコストがテスト実行時間を大幅に超えるテストとは？

「テスト自体は3秒で終わるのに、前提条件を作るのに3時間かかる」——このようなケースでは、自動化のROIが完全に逆転します。

セットアップコストが高い具体的なケース

  • 特殊なハードウェア環境が必要なテスト：特定GPUモデル・NFC対応デバイス・産業用機器との接続確認
  • 複雑な初期データが必要なテスト：「3年分の購買履歴を持つユーザー」でしか再現しない処理の確認
  • 外部の人間の操作が必要なテスト：「別の担当者が承認する」「サポートが対応する」など人を挟むフロー
  • タイミングに依存するテスト：「深夜バッチ実行後」「月末決算処理後」にしか確認できない状態
  • ライセンスコストが高いツールが必要なテスト：特定業務システムとの連携で高額ライセンス環境が必要
⚠️ 判断の目安：「テストの自動化コスト ＞ 手動で何回実行するコストの合計」になるなら、手動の方が合理的です。特にセットアップに工数がかかる場合は、この逆転が起きやすいです。
💡 実務Tip：セットアップコストが高いテストは「テストデータ作成スクリプト」「環境セットアップのドキュメント化」だけを自動化し、テスト実行自体は手動にするという折衷案が実務では有効です。

自動化すべきか判断するチェックリストとは？

迷ったときはこのチェックリストを使ってください。3つ以上「はい」なら自動化を検討、2つ以下なら手動優先です。

チェック項目はいいいえ
同じテストを月2回以上実行するか？✅❌
合否の判断基準が明確に数値・文字で定義できるか？✅❌
仕様が3ヶ月以上変わっていないか？✅❌
外部サービス・実課金・物理デバイスへの依存がないか？✅❌
テスト環境を安定して再現できるか？✅❌
人間の感性・直感・判断なしに合否を決められるか？✅❌
自動化コードの保守に割ける工数があるか？✅❌

FAQ

Q. FlakyテストはなぜCI/CDに悪影響を与えるのですか？

Flakyテストが多いと「テストが落ちても実際のバグかどうかわからない」という状態になります。結果として「落ちても無視してマージする」文化が根付き、テスト全体への信頼が失われます。Flakyの根本原因として多いのは「仕様が不安定な段階での早期自動化」「外部依存が強いテストの自動化」です。まず「このテストは自動化すべきか」を見直すことが最初の対処法です。

Q. 探索的テストは完全に自動化できないのですか？

monkey testing・fuzz testing・AI-assisted testing など「探索的に近いアプローチ」を自動化することは可能です。ただしこれらは「ランダム入力や学習ベースで予期しない挙動を探す」ものです。「熟練QAエンジニアが仮説を立て、直感と経験をもとに試す」という人間主導の探索的テストの本質は、現状のツールでは再現できていません。探索的テストの「型」（セッションベーステスト・チャータード探索など）は自動化できませんが、その前後の準備や記録支援にツールを活用することは有効です。

Q. Visual Regression Testingは自動化の対象になりますか？

「前回との差分を検知する」用途なら自動化できます。Percy・Applitoolsなどのツールが代表的です。ただし「その差分が問題かどうか」の判断は人間が行う必要があります。VisRegは「変化の通知ツール」として自動化し、「判断」は手動で行うハイブリッドアプローチが実務では一般的です。

Q. 外部決済サービスのテストは完全に手動でやるべきですか？

サンドボックス環境が提供されている場合（Stripe・PayPalなど）はその範囲で自動化できます。自動化すべきでないのは「本番環境の実課金フロー」に限定されます。「サンドボックスで自動化 ＋ 本番の最終確認を月次手動」という組み合わせが現実的な選択です。

Q. 「自動化しない判断」をするとチームから理解を得にくいのですが？

「なぜ自動化しないか」を定量的に説明するのが効果的です。例えば「このテストケースの自動化に3日かかる。手動実行は15分、月1回だけ実行する」という場合、自動化コストを回収するには3年以上かかります。「3年後も同じ仕様でこのテストを使い続けるか？」を問うと、判断がブレにくくなります。実行頻度・仕様安定性・保守工数の3軸で試算することをおすすめします。

Q. 自動化しないテストはどう管理すればいいですか？

「手動テスト実施記録」として別管理するのが一般的です。TestRailやNotionなどのテスト管理ツールに「手動テスト専用」カテゴリを作り、実施者・日時・結果を記録します。「手動テストの標準化」がされていると、属人化を防ぎ品質が安定します。

無理な自動化がFlakyテストを生む理由とは？

「自動化しない方がいいテストを自動化する」と何が起きるか——その典型がFlakyテスト（実行するたびに結果が変わる不安定なテスト）です。

Flakyテストが生まれやすい状況

  • 仕様確定前に自動化：仕様変更のたびにテストが壊れ、直し続けた結果「なんとなく落ちるテスト」になる
  • 外部サービスに依存したまま自動化：外部API・ネットワーク・レスポンス速度の変動でランダムに落ちる
  • セットアップが複雑なテストを無理に自動化：前提条件の再現が不完全でテスト環境ごとに結果が変わる
⚠️ Flakyテストが招く最悪の状態：Flakyが増えると「テストが落ちても誰も気にしない」「CIが赤くても無視してマージする」という文化が生まれます。これは自動化をしていない状態より危険です。テストへの信頼を失うと、自動化に投資したコスト全体が無駄になります。
💡 対処法：Flakyテストが多いと感じたら「なぜこのテストが不安定なのか」を分析しましょう。多くの場合、「自動化すべきでないテストを無理に自動化している」か「テスト設計に問題がある」かのどちらかです。前者なら、潔く手動テストまたは部分自動化に切り替えることが正解です。

「全部自動化しよう」とするより、「これは自動化しない」と判断する方が、実は難しくて価値が高い。自動化しない判断を迷わずできるQAエンジニアは、チームの自動化戦略全体を健全に保てます。「自動化できる」と「自動化すべき」を常に区別することが、長続きする自動化の条件です。

📋 この記事のまとめ

  • 画面の見た目・UX評価は「人間の感性」が必要。VisRegは省力化ツールとして有効だが最終判断は人間が行う
  • 探索的テストはfuzz/monkey testingで近似できる部分もあるが、人間主導の仮説・直感は代替できない
  • 仕様確定前・一回限り・外部サービス実環境は自動化コストがROIを超えやすい
  • 外部サービスは「完全自動化か手動か」ではなく、モック・Synthetic Monitoring・監視の中間戦略が現実的
  • 無理な自動化はFlakyテストを量産し「誰も信用しないCI」を作る原因になる
  • 「自動化しない」と判断できることは、実装技術と同じくらい重要なQAエンジニアのスキル
タイトルとURLをコピーしました