Rustのパターンマッチにおける網羅性チェックの仕組みと安全な実装テクニック

2026年5月24日

基本文法・制御構文

Rustプログラミングにおいて、安全性と信頼性を支える最も強力な機能の一つが「パターンマッチ」です。

Rustのコンパイラは、すべての可能性が考慮されているかどうかを厳密にチェックする「網羅性チェック(Exhaustiveness Check)」を備えています。

この仕組みにより、開発者は実行時の予期せぬエラーを未然に防ぎ、堅牢なアプリケーションを構築することが可能になります。

本記事では、Rustのパターンマッチがどのようにして網羅性を担保しているのか、その内部的な仕組みから安全なコードを書くための実践的なテクニックまでを詳しく解説します。

目次 [ close ]

パターンマッチにおける網羅性チェックの基本概念

Rustのmatch式は、対象となる値の型が取り得るすべての状態をカバーしている必要があります。

コンパイラは、定義されたパターンがその型の全ドメイン(値の範囲)を網羅しているかを静的に解析します。

もし一つでも考慮漏れがある場合、コンパイルエラーが発生し、プログラムの実行を許可しません。

この仕組みは、他の言語におけるswitch文で発生しがちな「考慮不足によるバグ」を根本から排除します。

例えば、特定の列挙型(Enum)に新しいバリアントを追加した際、すべてのmatch式を修正しなければコンパイルが通りません。

これは、大規模なリファクタリングにおいて「修正漏れによる実行時クラッシュ」を防ぐための強力なセーフティネットとなります。

網羅性チェックを支えるコンパイラの仕組み

Rustコンパイラ(rustc)は、パターンマッチを解析する際に「有用性(Usefulness)」という概念を使用します。

各アーム(マッチの選択肢)が、それ以前のアームでカバーされていない新しい値をカバーしているかどうかを判定します。

最終的に、すべてのパターンの組み合わせが「空(empty)」になるまで分解され、未カバーの領域が残っていないかを確認します。

この解析は、特に列挙型や構造体、さらには数値の範囲指定などが組み合わさった複雑なパターンでも正確に行われます。

内部的には、パターンの集合を「スペースパルショニング(空間分割)」のような手法で管理しています。

これにより、開発者は複雑な条件分岐であっても、論理的な漏れがないことを数学的に保証された状態でコードを書くことができます。

列挙型(Enum)での網羅性担保の具体例

列挙型は、網羅性チェックが最も効果を発揮する場面の一つです。

以下のコード例では、すべてのバリアントを網羅していない場合にコンパイルエラーが発生することを確認できます。

Rust

enum Status {
    Active,
    Inactive,
    Pending,
}

fn process_status(status: Status) {
    // Pendingのケースを記述していないため、コンパイルエラーになります
    match status {
        Status::Active => println!("有効です"),
        Status::Inactive => println!("無効です"),
    }
}

実行結果

error[E0004]: non-exhaustive patterns: `Status::Pending` not covered

このように、コンパイラは具体的に「どのパターンが不足しているか」を教えてくれます。

不足しているバリアントを追加することで、実行時の不整合を未然に防ぐことができます。

ワイルドカードパターンの利点とリスク

網羅性を満たす手軽な方法として、アンダースコア _ を使用したワイルドカードパターンがあります。

ワイルドカードは、それまでに記述したパターンに合致しなかった「その他すべて」をキャッチします。

しかし、便利な反面、安全性の観点からは注意が必要なテクニックでもあります。

ワイルドカードの安易な利用が招く問題

将来的に列挙型へ新しいバリアントが追加された際、ワイルドカードがあるとコンパイルエラーが発生しません。

これは、本来新しいバリアントに対して個別の処理を書くべき場所で、意図せず「デフォルト処理」が実行されてしまうリスクを意味します。

特にビジネスロジックの根幹に関わる部分では、ワイルドカードを避け、すべてのケースを明示的に記述することが推奨されます。

Rust

enum UserRole {
    Admin,
    Member,
    Guest,
    // 将来的に Moderator が追加されたとする
}

fn check_permission(role: UserRole) {
    match role {
        UserRole::Admin => println!("全権限あり"),
        _ => println!("一般権限のみ"), // Moderator追加時にここを通ってしまう
    }
}

この場合、新しいロールが追加された際に「権限設定を忘れる」というミスを誘発しやすくなります。

安全性を優先するなら、多少記述が長くなっても各バリアントを個別に列挙すべきです。

構造体とスライスパターンの網羅性

Rustのパターンマッチは、単純な列挙型だけでなく、複雑なデータ構造に対しても網羅性をチェックします。

構造体のデストラクト(解体)においても、すべてのフィールドが考慮されているか、あるいは意図的に無視されているかが確認されます。

また、スライスや配列のパターンマッチでも、要素の数や値の範囲に基づく網羅性チェックが働きます。

Rust

fn process_slice(data: &[i32]) {
    match data {
        [] => println!("空のデータです"),
        [first] => println!("要素は1つです: {}", first),
        [first, second] => println!("要素は2つです: {}, {}", first, second),
        _ => println!("3つ以上の要素があります"),
    }
}

スライスの場合、長さが動的であるため、最終的にはワイルドカード _ や .. (残りすべて)が必要になることが多いです。

しかし、固定長配列の場合は、すべての要素パターンを網羅することでワイルドカードなしの記述が可能です。

ガード条件(Match Guards)と網羅性の関係

matchのアームには、ifキーワードを用いた追加の条件式(ガード)を記述できます。

ガード条件を使用すると、パターンが一致しても条件を満たさない場合はそのアームは実行されません。

ここで注意すべきは、コンパイラはガード条件の内容までは考慮して網羅性を判定できないという点です。

Rust

fn check_value(x: Option<i32>) {
    match x {
        Some(n) if n > 0 => println!("正の数"),
        Some(n) if n <= 0 => println!("0以下の数"),
        None => println!("値なし"),
        // コンパイラは上記2つのSomeで全数値をカバーしていると判断できない
        // そのため、以下のSome(_)が必要になります
        Some(_) => unreachable!(), 
    }
}

人間から見れば n > 0 と n <= 0 で全範囲をカバーしていることがわかります。

しかし、Rustのコンパイラは実行時の複雑な条件を静的に解決しないため、安全側に倒して「未網羅」と判定します。

このような場合は、最後にガードなしのパターンを置くか、unreachable!() マクロを活用して意図を明示するのが一般的です。

非網羅的な列挙型の設計 (non_exhaustive)

ライブラリを開発する場合、将来的にバリアントを増やす可能性がある列挙型を公開することがあります。

そのまま公開すると、利用者がすべてのバリアントを match で書き並べていた場合、ライブラリのアップデート時に利用者のコードが壊れて(コンパイルエラーになって)しまいます。

これを防ぐために、Rustには #[non_exhaustive] という属性が用意されています。

Rust

#[non_exhaustive]
pub enum ErrorKind {
    NotFound,
    PermissionDenied,
}

この属性が付与された列挙型を外部クレートから利用する場合、match 式で必ずワイルドカード _ を含めることが強制されます。

これにより、ライブラリ側が将来新しいバリアントを追加しても、利用者のコードの互換性を保つことができます。

ライブラリ設計者にとって、APIの柔軟性と安全性を両立させるための不可欠なテクニックです。

安全な実装のためのベストプラクティス

パターンマッチをより安全に運用するために、以下のポイントを意識しましょう。

項目	推奨されるアクション	理由
ドメイン固有のEnum	ワイルドカードを避け、全列挙する	仕様変更時の修正漏れをコンパイルエラーで検知するため。
ガード条件の利用	最後にフォールバックのアームを置く	コンパイラの網羅性解析の制限を補完するため。
外部ライブラリのEnum	`non_exhaustive` を考慮する	アップデートによる破壊的変更を最小限に抑えるため。
大きなEnumの分解	ネストしたmatchを活用する	一つのmatch文が肥大化して可読性が下がるのを防ぐため。