異常系と準正常系の違いを徹底解説！定義や具体例・テストの使い分け

システム開発の設計やテストで「異常系・準正常系の違い」が分からず、考慮漏れに不安を感じていませんか？この境界が曖昧だと、品質低下や手戻りの原因になります。本記事では、両者の定義や具体例、テスト設計の使い分けをエンジニア視点で徹底解説します。この記事を読めば、現場で迷わず適切なエラーハンドリングを設計できるようになり、堅牢でユーザーに優しいシステム構築が可能になります。

記事のポイント

• 準正常系は「仕様で定義された想定内の例外処理」を指し、異常系は「システム障害や実行環境の問題など、主に業務ロジックの外側（インフラ・実行環境）に起因するエラー」を指します（これらも通常は仕様として定義されます）。
• 準正常系の設計ではユーザーを迷わせないエラー表示が重要であり、異常系ではデータの整合性保護と安全な停止・復旧が最優先されます。
• HTTPステータスコードとの対応（4xx：準正常系 / 5xx：異常系）は概念的な類比として使われることがありますが、厳密には別の分類軸であることに注意が必要です。
• これらの定義は業界で統一されておらず、組織やプロジェクトによって異なるため、チーム内での合意形成が不可欠です。

異常系と準正常系の違いと定義の考え方

システム開発の設計やテスト工程において、 「 正常系 」 以外に考慮すべきケースとして 「 準正常系 」 と 「 異常系 」 があります。これらは混同されやすい概念ですが、設計の目的や対処法が大きく異なるため、定義を明確に使い分けることが重要です。

[!IMPORTANT] 「準正常系」「異常系」の定義は業界で統一されていません。 組織やプロジェクトによって「エラーは全て準正常系」「仕様書にないものは全て異常系」など、切り分け方が異なるのが一般的です。本記事では、多くの現場で採用されている一般的な考え方を基に解説します。

正常系・準正常系・異常系の三つの分類と役割

ソフトウェアの挙動を整理する際、一般的に以下の三つのパターンに分類して考えるのが効率的です。

正常系 は「 ハッピーパス 」とも呼ばれ、サービスが提供する価値そのものを指します。一方で、 準正常系 と 異常系 は、その価値を損なわないための「 防御策 」としての役割を担っています。

準正常系は「想定内のエラー」異常系は「通常フローとは異なる障害系の事象（発生自体は想定される）」

両者の最も大きな違いは、その事象が 「 アプリケーションのロジックとして想定されているか 」 という点にあります。

• 準正常系（ 仕様内の例外処理 ） アプリケーションの仕様としてあらかじめ定義されている例外ルートです。「 入力フォームに数字以外が入った場合にエラーメッセージを出す 」といった挙動は、プログラムが意図した通りに制御されている状態であり、アプリケーションの挙動としては正常に制御されているため「正常な機能の一部」とも捉えられますが、テスト観点では通常の正常系とは区別して扱われます。
• 異常系（ 障害系の例外処理 ） 通常の業務フロー外で発生するシステム障害や例外的事象によって、処理の継続に影響を与える可能性がある状態を指します。これらはシステム資源の制約や外部要因によるものが多く、業務ロジックとは別レイヤ（インフラ・運用・リトライ制御など）での対応が必要になるケースが多くなります。

このように、 準正常系 は「 設計済みの業務例外 」、 異常系 は「 通常フローとは異なる障害系の事象（発生自体は想定される） 」と捉えると実務に即した整理ができます。

Kindle Unlimited

IT専門書も30日間無料で読み放題

1冊数千円する専門書から、ビジネス書、実用書、雑誌まで幅広いジャンルが定額で読み放題。ITスキルの向上はもちろん、日々の情報収集や教養を深めるのにも最適です。

• 📚 技術書も月額定額で読み放題
• 📱 マルチデバイス対応
• ✨ 30日間の無料体験

無料で30日間試してみる

違いを明確に区別すべき理由と品質向上へのメリット

これらを明確に区別して設計・テストを行うことには、以下のようなメリットがあると考えられます。

1. テスト網羅性の向上 「 エラー 」を一括りにせず分類することで、テストケースの漏れを防ぎ、より堅牢なシステムを構築しやすくなります。
2. ユーザー体験（ UX ）の最適化 準正常系 では「 ユーザーにどう修正してもらうか 」という視点が重要ですが、 異常系 では「 システムをいかに安全に停止・復旧させるか 」という視点が求められます。
3. 運用コストの削減 エラーの性質が分かれば、ログの出力レベルや監視の優先順位を適切に設定でき、トラブル発生時の初動対応を迅速化できる可能性が高まります。

品質の高いシステムを実現するためには、これら三つの系をバランスよく設計に組み込むことが不可欠と言えるでしょう。

実務で役立つ準正常系と異常系の具体例と設計手法

設計やテストの現場では、具体的にどのようなケースが 準正常系 や 異常系 に該当するのかを整理しておくことが重要です。ここでは、実務でよく遭遇するシナリオを例に挙げながら、それぞれの設計手法について解説します。

準正常系の具体例：入力バリデーションや業務ルールの逸脱

準正常系 は、プログラムとしては正しく動いているものの、入力データや業務ルールが要件を満たしていない状態を指します。これらは「 起こり得る例外 」として、あらかじめ処理を組み込んでおく必要があります。

ユーザーの操作ミスによるエラーハンドリング

もっとも一般的な 準正常系 の例は、入力フォームでのバリデーションエラーです。

• メールアドレスの形式が正しくない
• 必須項目が空欄のまま送信された
• パスワードの文字数が足りない

これらはシステム障害ではなく、ユーザーへの適切なフィードバックによって解決されるべき事象と考えられます。

在庫不足や期限切れなどのビジネスロジックエラー

業務アプリケーションにおいて、システムの整合性を保つための「 ルール違反 」も 準正常系 に含まれます。

• ECサイトで購入ボタンを押したが、直前に在庫が切れた
• 有効期限が切れたクーポンコードが入力された
• 銀行振込で残高が不足している

これらは「 業務フロー上の例外 」であり、エラー画面を表示してユーザーに次のアクションを促す設計が求められます。

異常系の具体例：インフラ障害や外部サービスの停止

異常系 は、主にインフラや外部要因、またはアプリケーション内部の想定外の障害に起因し、業務ロジックとは別レイヤで対処が必要となるトラブルを指すことが多いようです。

データベース接続失敗やサーバーのダウンタイム

システムが稼働するために必要なコンポーネントが利用不能になるケースです。

• DBサーバーへの接続タイムアウト
• API連携している外部サービスのシステムダウン
• ネットワークの瞬断による通信エラー

これらは、リトライ処理の検討や、システムを安全に停止させる（ フェイルセーフ ）設計が必要になるでしょう。

ディスク容量不足やメモリリークによるシステム停止

サーバーリソースの限界によるトラブルも 異常系 の代表例です。

• ログファイルが肥大化し、ディスク容量がいっぱいになる
• メモリリークが発生し、プロセスが強制終了する
• CPU使用率が高騰し、レスポンスが返らなくなる

これらは、アプリケーション側の工夫だけでなく、インフラ監視や自動復旧の仕組みとセットで検討されるのが一般的です。

準正常系と異常系で異なるテスト設計とリカバリ方針

準正常系 と 異常系 では、テストの目的やエラー発生時の対処法が大きく異なります。以下の表に、その違いをまとめました。

準正常系はUXを意識した適切なエラーメッセージの表示

準正常系 の設計では、ユーザーを迷わせないことが最優先されます。「 システムエラーが発生しました 」といった抽象的な表現ではなく、「 在庫が不足しています 」のように、 何が原因でどうすれば解決するか を明示することが、品質の高いUX（ ユーザー体験 ）につながると考えられます。

異常系はシステムの堅牢性とデータ整合性の保護

一方で 異常系 では、ユーザーへの通知以上に「 データの保護 」が重要視されます。例えば、決済処理中にDB接続が切れた場合、二重課金やデータの不整合が起きないよう、確実に トランザクションをロールバック する設計が不可欠です。また、運用担当者が迅速に気づけるよう、エラーログの出力レベルを「 ERROR 」や「 FATAL 」に設定し、アラート通知を飛ばす仕組みが一般的とされています。

異常系・準正常系の違いを正しく理解するためのまとめ

今回のまとめ：振り返りチェックリスト

• 「準正常系」は仕様内の例外処理、「異常系」は通常フローとは異なる障害系の事象と定義を整理する
• 準正常系はユーザーが自己解決できるエラー表示を、異常系はデータの不整合防止と安全な復旧を最優先にする
• 注意： HTTPコード（4xx/5xx）との対応はあくまで類比であり、プロジェクトごとの定義を優先すること
• 重要： 準正常系と異常系の区分に絶対的な標準はないため、チーム内での共通認識を揃えるのが第一歩

システム開発における 正常系 ・ 準正常系 ・ 異常系 の分類は、単なる用語の整理ではなく、システムの品質と信頼性を支える重要な指針となります。これまでの内容を踏まえ、改めて全体を整理しましょう。

正常系・準正常系・異常系の比較一覧

設計やテストの現場で迷った際は、以下の比較表を参考に役割を再確認することが推奨されます。

実装イメージによる違いの理解

プログラムの構造で見ると、 準正常系 は業務ロジックとして制御されることが多く、 異常系 は例外処理（try-catchなど）で扱われることが多いですが、これは実装方針に依存します。

1
function purchaseProduct(user, product) {
2
  try {
3
    // 【 準正常系 】：ビジネスルール上のエラー（ 想定内 ）
4
    if (user.balance < product.price) {
5
      return "残高が不足しています。チャージしてください。"; // UXを意識したメッセージ
6
    }
7

8
    // 【 正常系 】：メインの処理
9
    executePayment(user, product);
10

11
  } catch (error) {
12
    // 【 異常系 】：システム的な障害系の例外事象（ 通常フロー外 ）
13
    logError(error); // 開発者・管理者への通知
14
    rollbackTransaction(); // データ不整合の防止
15
    return "システムエラーが発生しました。時間をおいて再度お試しください。";
16
  }
17
}

違いを意識した設計がもたらすメリット

準正常系 と 異常系 を明確に区別して設計することで、以下のようなメリットが期待できると考えられます。

• テスト精度の向上 ：「 ユーザーのミス 」と「 システムの故障 」を分けてテスト項目を作ることで、確認漏れが少なくなります。
• コストの最適化 ：全ての異常事態に完璧な自動復旧を備えるのは困難ですが、発生頻度の高い 準正常系 に注力することで、効率的に品質を高められます。
• 運用負荷の軽減 ：エラーログの出力レベルを適切に分けることで、運用担当者が「 今すぐ対応すべき障害（ 異常系 ）」を即座に判断できるようになります。

システム設計の初期段階からこれらの境界線を意識しておくことが、結果として ユーザーに優しく、かつトラブルに強いシステム の構築につながると言えるでしょう。

ITナレッジライフ

スタブ・ドライバ・モックとは？初心者でも理解できる覚え方を紹介！

ソフトウェアテストに欠かせない「スタブ」「ドライバ」「モック」の違いや使い分けを解説します。初心者でも覚えやすいよう、具体例や語感を使った覚え方を紹介します。テストの基礎をしっかり理解し、実践に役立てましょう！

ITエンジニアにお勧めの本

ベストセラー

世界一流エンジニアの思考法

Amazonで詳細を見る 🔴 楽天で見る

文系社会人のためのIT資格の歩き方: 文系のあなたに最適な道をご提案します (YKcreate kiki)

Amazonで詳細を見る

エンジニアを説明上手にする本 相手に応じた技術情報や知識の伝え方

Amazonで詳細を見る 🔴 楽天で見る