1 エラー種別の概要
エラー種別とは、ソフトウェアや情報システムが遭遇する異常を、共通の枠組みで分類したものです。分類は、発生原因、観測される挙動、利用者への影響、復旧や再発防止に必要な情報の有無といった観点を組み合わせて設計されます。適切な種別設計により、障害の切り分けが速まり、同種の不具合が繰り返される確率を下げ、利用者や運用担当者への説明品質も向上します。
エラーは、例外（例外処理）、ログ出力、監視アラート、返却コード、メトリクスなどを通じて観測されます。そのため「分類の粒度」と「見るべき情報」を、実装方式や利用環境に合わせて決めることが中核になります。粒度が粗すぎると原因の特定や対策が滞り、細かすぎると運用負荷と誤分類が増えるため、バランスが重要です。
1.1 エラー分類の目的
1.1.1 原因調査の効率化
エラー種別は、発生した異常を既知のパターンに割り当てることで、原因の候補を短い手順で絞り込みます。たとえば同じ「失敗」でも、入力由来、内部処理由来、外部依存由来でログや確認手順が変わるため、種別があると調査経路が明確になります。結果として、再現・切り分けに必要な時間が短縮されます。
また、種別が統一されると、過去事例との照合が容易になります。類似の事象が同一カテゴリに集約されるため、同種の修正履歴や暫定対応を参照しやすくなります。
1.1.2 利用者影響の把握
エラー種別は、技術的な失敗だけでなく、利用者が経験する機能停止、遅延、部分的な不具合の程度を把握するためにも使われます。たとえば特定機能だけが失敗するケースは全体障害とは扱いが異なり、サポート対応やコミュニケーションの内容も変わります。
さらに、利用者影響の見積もりがしやすい種別体系は、優先度付けに直結します。運用では「件数」だけでなく「重要度」が問題解決の順序を決めるため、影響観点を含む分類が望まれます。
1.2 分類軸の考え方
1.2.1 発生原因（入力・内部・外部）
分類は、まず原因の所在を大まかに分けるのが基本です。入力に由来するものは、ユーザー入力、外部から受け取るデータ、APIリクエストの不整合などが該当します。内部は、アプリケーションのロジック、状態管理、依存関係の扱い、実装上の欠陥が中心です。外部は、ネットワーク経路、外部サービス、認証基盤、周辺インフラといった組み合わせが関わります。
原因の区分は、ログ取得点や再現手順の設計にも影響します。入力系は入力検証とサニタイズ、内部系はコード経路の点検、外部系はタイムアウトや応答検証といった観点で対処が変わります。
1.2.2 影響範囲（単一機能・全体）
同じ原因でも、影響の広がり方は異なります。あるエラーが単一の機能やエンドポイントに限定される場合、利用者は限定的に影響を受け、復旧もその範囲に閉じます。一方で共通コンポーネント（認証、設定ロード、データアクセス層など）に起因する場合は、全体への波及が起こりやすくなります。
影響範囲を軸に含めることで、アラートの緊急度や巻き戻し・停止判断の根拠が整理されます。運用時に「いつ何を止めるか」を決める上で有効です。
2.3 挙動（再試行可能・不可）
挙動の軸は、復旧のために再試行が妥当かどうかを判断する材料になります。再試行可能なケースは、単発の通信失敗や、一時的な混雑などが該当し得ます。再試行が望ましくないケースは、検証不全による恒常的な拒否、権限の欠如、破損データのように、条件が整わない限り結果が変わらないものです。
この区分は、リトライ戦略の設計に直結します。無差別な再試行は負荷や二次被害を増やすため、種別ごとに「いつ・どの程度」試すかを決める必要があります。
2 エラー種別の代表的なカテゴリ
エラー種別のカテゴリは、実装をまたいで共通理解を作るための骨格として機能します。代表的なカテゴリは、実行時の異常、入力・データ由来の問題、外部依存に関わる失敗、システム環境に起因する障害に大別できます。これらは組み合わせも起こり得るため、分類の優先順位（主因をどれに置くか）を決めると整理が進みます。
2.1 実行時エラー
2.1.1 例外（例外的事象）
例外は、処理が通常の前提から外れたときに発生する事象として扱われます。プログラミング言語の例外機構や、フレームワークが提供するエラー処理の中で観測されることが多いです。例外は発生点と原因がセットで記録される場合があり、スタックトレースや例外クラス名が分類の手掛かりになります。
ただし例外は症状であることもあり、同じ例外でも入力要因や外部要因が背景にある場合があります。そのため、例外をそのまま最終カテゴリにせず、原因の区分と整合させるのが実務上のポイントです。
2.1.2 リソース枯渇（メモリ、ハンドル等）
リソース枯渇は、メモリ、スレッド、ファイルディスクリプタ、ネットワークソケット、外部接続数などの資源が不足し、処理継続が困難になる状態を指します。システム負荷の増加、リーク（解放漏れ）、設定上限の不適合などが背景にあることがあります。
観測としては、割り当て失敗、タイムアウトの増加、応答遅延の悪化などに現れます。種別化しておくと、キャパシティ計画、コード修正、設定調整を切り分けやすくなります。
2.2 入力・データ関連エラー
2.2.1 バリデーション不全
バリデーション不全は、受け取った値が期待される形式や制約を満たさないために処理が成立しない状態です。必須項目の欠落、型の不一致、長さ制約違反、値域外、相関条件（例：開始日時が終了日時より後）などが代表例です。
この種別は利用者側の入力修正で解消する可能性が高いため、ユーザーへの説明やエラー表示の設計に特に重要になります。あわせて、誤入力を減らすUIやクライアント側の検証も検討対象になります。
2.2.2 形式不正（構文、スキーマ）
形式不正は、構文やスキーマの違反によって解釈できない状態を指します。JSONの括弧不整合、XMLのタグ不整合、メッセージのエンベロープ欠落、期待するフィールド構造が欠けるなどが含まれます。
バリデーション不全が「値としては型が合うが制約に違反」になりやすいのに対し、形式不正は「読み取りや整形自体が成立しない」寄りです。ログでは解析エラーの位置や受信サイズなどを関連付けると、改善につながりやすくなります。
2.2.3 データ整合性違反
データ整合性違反は、複数の要素間の関係が矛盾しているために成立しない状態です。外部キーの不整合、重複制約の破れ、一貫性条件（例：参照されるはずのレコードが存在しない）、整合更新の不完全などが該当します。
背景としては、同時実行制御の不備、途中失敗による部分更新、移行データの欠落などが考えられます。種別化すると、DB設計やトランザクション境界、データ移送手順の見直しへつなげられます。
2.3 外部依存エラー
2.3.1 ネットワーク障害
ネットワーク障害は、通信経路の不安定さ、到達性の欠如、遅延、パケット損失などにより、外部とやりとりできない状態です。タイムアウト、接続拒否、DNS失敗、TLS確立の失敗などの形で観測されます。
復旧にはリトライが有効な場合もありますが、過剰な試行は負荷とコストを増やします。種別により「一時的なものとして扱う範囲」と「即時で切り替える範囲」を決められます。
2.3.2 外部サービス応答不整合
外部サービス応答不整合は、要求に対する応答が期待とずれ、処理が継続できなくなる状態です。ステータスコードは成功でも本文構造が欠落している、必須フィールドが欠ける、整合性チェックに失敗する、といったケースが含まれます。
この種別は「通信できたが内容が合わない」ため、形式不正や整合性違反と重なる場合があります。分類上は主因を外部サービスの応答品質に置くなど、ルールを明確にすると混乱が減ります。
2.3.3 認証・認可失敗
認証・認可失敗は、利用者やシステムが必要な権限を持たない、または資格情報が正しくないために、外部連携が拒否される状態です。トークン期限切れ、署名検証の不一致、権限のスコープ不足、ロール紐付けの欠如などが該当します。
この種別は、再試行しても改善しないことが多いため、資格情報の更新や構成の点検へ誘導する必要があります。ユーザー向けには「入力の誤り」ではなく「アクセス権の不足」など適切な説明に切り分けると混乱が減ります。
2.4 システム・環境エラー
2.4.1 設定不備
設定不備は、構成値の欠落や不整合により、アプリケーションが期待通りに動作できない状態です。環境変数が設定されていない、接続先のURLが誤っている、タイムアウト値が極端、機能フラグが想定外に有効化されているなどが含まれます。
これはデプロイ手順や構成管理の問題に結びつきやすいため、変更履歴と合わせて追跡する設計が有効です。種別化することで、再発時に原因が構成側へ早く到達します。
2.4.2 権限不足
権限不足は、実行環境で必要な操作が許可されないために失敗する状態です。OSレベルの権限、コンテナの実行権限、クラウドIAM、管理者ロールの不足などが背景になります。
この種別は再試行では解消しにくく、権限設計の見直しが中心になります。ログには操作対象（リソース種別）と拒否理由（可能ならエラー文）を残すと、対応が迅速になります。
2.4.3 ファイル入出力障害
ファイル入出力障害は、ディスク容量不足、ファイルパス不正、読み取り不能、書き込み失敗、権限制約、ロック競合などにより、ストレージ操作が成立しない状態です。キャッシュやテンポラリファイルの作成失敗も含まれ得ます。
観測にはI/O例外、容量メトリクスの悪化、生成物の欠落などが現れます。対策は空き容量の確保、保存先の見直し、例外時の後処理（クリーンアップ）などに分岐します。
3 計測・観測に基づくエラー種別
エラー種別は、コード内部の事象だけでなく、外部から観測される指標によっても定義できます。返却コード、ログ、監視アラートなどは、運用の判断材料になるため、種別体系と整合した情報設計が重要です。ここでは代表的な観測手段を用いた分類方法を整理します。
3.1 返却コード（ステータスコード）
3.1.1 HTTP系エラー
HTTP系エラーでは、ステータスコードと応答本文が分類の入口になります。たとえばクライアントの入力不備に近い失敗、認証や認可に関する失敗、サーバ内部の異常、存在しない資源に関する失敗といった粒度で整理できます。
運用では「見かけのコード」と「実際の原因」を一致させることが望まれます。実装が不適切だと、分類が有名無実になり、原因調査の効率が下がります。
3.1.2 アプリケーション固有コード
アプリケーション固有コードは、業務要件やドメインに即した粒度でエラーを表す仕組みです。HTTPのステータスでは表現しきれない分岐（例：特定帳票の状態不一致、在庫引当のルール違反）を識別しやすくします。
この方式は、クライアントの挙動制御やユーザー通知の文言選定にも利用できます。一方でコード設計が増殖すると管理が難しくなるため、命名規約や廃止方針を含むガバナンスが必要です。
3.2 ログでの分類
3.2.1 ログレベル（情報・警告・エラー）
ログレベルは、事象の重要度を示すための基本軸です。情報は経過記録、警告は注意を要する状態、エラーは失敗として扱うことが多いです。運用側ではレベルに応じてアラートの閾値や通知経路を分けられます。
ただし、レベル設定は実装者の裁量に依存しやすいため、ガイドラインの整備が重要です。誤って警告をエラー扱いにするとノイズが増え、逆にエラーが情報扱いだと検知が遅れます。
3.2.2 構造化ログ（フィールド設計）
構造化ログは、単なるテキストではなく、キー・バリュー形式などで情報を整理した記録です。エラー種別、リクエストID、ユーザー識別子の扱い（匿名化有無）、対象機能、タイムスタンプ、例外名、相関IDなどをフィールドとして持たせます。
種別体系とフィールド設計を結び付けると、集計や検索が容易になります。さらに、欠損や形式ゆらぎが起きにくい設計にすると、追跡性が向上します。
3.3 監視・アラートでの分類
3.3.1 SLI/SLO観点のエラー
監視では、サービス目標（SLI/SLO）に基づいてエラーを扱います。成功率の低下や応答時間の悪化、特定エンドポイントの失敗率増加など、利用者体験に近い指標に紐づけることで、技術的な原因よりも「何がどれだけ悪化したか」を明確にできます。
ただし、SLI/SLOが拾えるのは観測可能な結果です。観測点と内部分類をつなぐ設計（例：失敗率の急増が特定種別に対応する）を行うと、対策までの距離が縮まります。
3.3 通知ルールと抑制
通知ルールと抑制は、アラートの質を左右します。たとえば短時間の一過性エラーは抑制し、一定期間継続する場合のみ通知する、特定の種別だけは重大度を上げる、重複通知をまとめるなどの工夫があります。
過剰な通知は疲弊を招きます。逆に抑えすぎると重大事象の発見が遅れるため、通知間隔、閾値、復旧時通知の要否といった設計要素を検討します。
4 エラー処理・運用設計
エラー処理・運用設計は、単に例外を握りつぶさないこと以上を意味します。再試行の可否、代替動作、ユーザーへの説明、再発防止のための学習ループを、種別体系と結び付けて設計することで、運用の再現性が高まります。
4.1 例外処理の方針
4.1.1 再試行（リトライ）とバックオフ
再試行は、失敗の性質が一時的である場合に有効です。ネットワーク途絶や混雑など、時間を置くと改善する可能性があるときに適用されます。バックオフは、短い間隔の連続再試行による負荷増大を避けるための待機戦略で、段階的な増加やランダム要素の導入などが考えられます。
種別体系により、リトライ対象を絞り込むと事故を防げます。たとえば形式不正や権限不足は再試行しても変化しないため、即時の失敗として扱うほうが安全です。
4.1.2 フォールバックと代替動作
フォールバックは、主経路で失敗した際に別の経路へ切り替える設計です。キャッシュを使う、簡易レスポンスに切り替える、非同期処理へ回す、別の外部プロバイダへ迂回するなどの選択肢があります。
代替動作は常に良いとは限らず、整合性や品質のトレードオフが生じます。そのため種別ごとに許容される妥協点を定義し、ユーザーが受け取る内容の意味を明確にする必要があります。
4.2 ユーザー向けメッセージ
4.2.1 誤解を避ける表現
ユーザー向けメッセージは、技術的詳細をそのまま出すのではなく、理解可能な言葉に翻訳します。入力由来の問題なら修正方法に誘導し、権限や認証の問題なら手続きや確認事項を示します。内部エラーの場合でも、原因究明中である旨や次の行動を提示すると混乱が減ります。
メッセージは誤解を招くとサポート負担が増えます。抽象的な「不明なエラー」を避け、種別に応じて粒度のある説明を用意するのが望ましいです。
4.2.2 影響範囲の提示
影響範囲の提示は、ユーザーが「自分だけが困っているのか」「サービス全体が不調なのか」を判断する材料になります。全体障害に近い場合は復旧見込みや現在可能な代替（たとえば一部機能のみ利用可能）を示します。
個別失敗であれば、該当入力や対象項目を指し示すことで解決の近道になります。種別に基づいてメッセージを分岐させると、一貫性が保たれます。
4.3 再発防止と改善
4.3.1 ルートコーズ分析
ルートコーズ分析（RCA）は、表面的な失敗処理ではなく根本要因を特定するための手順です。エラー種別を起点に、発生条件、変更点、関連するメトリクス、ログの時系列を追い、因果の連鎖を整理します。
種別設計が整っていれば、類似事象の再発パターンも見えやすくなります。その結果、コード修正だけでなく、設定、運用手順、監視閾値、データ品質対策まで含めた是正案を作りやすくなります。
4.3.2 テスト戦略（異常系）
異常系テストは、成功経路の確認だけでは覆いきれない失敗パターンを検証する考え方です。入力不正、外部応答の欠落、一時的な通信断、タイムアウト、リソース不足などを、種別体系に対応づけて網羅します。
テストは再試行やフォールバックの振る舞いまで含めると効果が高いです。さらに、ログや返却コードが期待どおりに出るかを確認することで、運用での観測性も担保できます。
5 よくある誤分類と注意点
エラー種別の運用では、分類の意図と観測される情報がズレることで誤分類が発生しがちです。誤分類は原因調査の停滞、誤った暫定対応、通知ノイズ増大につながるため、典型的な落とし穴を把握しておくことが重要です。
5.1 「症状」と「原因」の混同
症状と原因を混ぜると、カテゴリが増殖し、対策が空回りします。たとえば「タイムアウト」という観測結果を原因として扱うと、ネットワーク要因、相手側の過負荷、内部の遅延など多様な背景を一括してしまいます。
観測結果はあくまで手がかりであり、分類は根本要因に寄せるのが基本です。例外の種類やログの一部だけで判断せず、可能な範囲で上流・下流の文脈を確認すると整理が進みます。
5.2 標準化不足による分類のばらつき
分類語や粒度の規約がないと、チームや担当者ごとに呼び方が変わり、集計が難しくなります。たとえば同じ入力不正でも「形式不正」「バリデーション」「データ不一致」などに分散すると、統計上の意味が薄れます。
標準化では、カテゴリ一覧、優先順位、必須フィールド、命名規則、例外扱いの方針を決めることが有効です。運用開始後も学習として更新し、古い定義が残らない仕組みを整えます。
5.3 ログ欠損による追跡不能
ログ欠損は、原因調査の最終到達点を奪う問題です。特に例外時に関連情報（相関ID、対象機能、入力の要約、外部応答の抜粋、時系列）が失われると、種別の価値が下がります。
欠損の原因として、例外処理が途中で中断されている、ログ出力が例外の影響で失敗している、PIIや機密を隠す設計が過剰で必要情報まで削っているなどがあります。種別体系に必要な最小限の観測項目を定義し、欠損時にも追跡できる冗長性を検討することが重要です。