疑似乱数と真の乱数の違い【使い分けと判別】
乱数には「計算で作る疑似乱数」と「物理現象から作る本物の乱数」があります。見た目はどちらもバラけていますが、実務ではこの違いを理解していないと、次のような失敗が起きます。
- シミュレーションの再現が必要なのに、毎回結果が変わる
- パスワード用トークンを予測しやすい乱数で作ってしまう
- 統計検定に通っただけで「本物の乱数」と誤解する
1. まず結論
疑似乱数は、内部状態とアルゴリズムから計算で作る数列です。
本物の乱数は、熱雑音や電気的ジッタなどの物理現象を元に作る数列です。
ただし、実務で使われる安全な乱数は、物理乱数をそのまま返すのではなく、物理エントロピー源で seed(種)を入れた CSPRNG(暗号学的疑似乱数生成器)の出力です。
つまり、まず次の3つを区別して考えましょう。
- 通常の PRNG(疑似乱数生成器)
- CSPRNG / DRBG(暗号学的疑似乱数生成器)
- NRBG / TRNG(物理エントロピー源を持つ本物の乱数生成器)
2. 用語の整理
| 種類 | 作り方 | 再現性 | 目的 | 向く用途 |
|---|---|---|---|---|
| 通常の PRNG | 数式と内部状態 | あり | 速度・再現性 | シミュレーション、ゲーム、テスト |
| CSPRNG / DRBG | 暗号アルゴリズム + seed | あり(理論上) | 予測困難性 | 鍵生成、トークン、セッションID |
| 本物の乱数 / NRBG | 物理エントロピー源 | なし | 物理的不確定性 | seed供給、認証装置、監査が必要な抽選 |
3. 何が違うのか(4つの軸)
3.1 生成元
- 疑似乱数:アルゴリズムと内部状態
- 本物の乱数:物理エントロピー源
3.2 再現性
- 疑似乱数:同じ seed なら同じ結果(テストに有利)
- 本物の乱数:同じ条件でも違う結果になる
3.3 予測可能性
- 通常のPRNG:seedが漏れると先読みされやすい
- CSPRNG:内部状態が守られていれば予測されにくい
- 本物の乱数:物理源が健全なら予測困難だが、センサー不良には注意
3.4 速度
- 疑似乱数:高速・安定
- 本物の乱数:エントロピー収集や監視が必要で低速
4. どうやって区別するか
出力だけでは区別できない
有限個の出力列を見ても「本物の乱数」とは断定できません。同じ列を返すプログラムはいつでも作れるからです。
まず見るべきは生成器の設計
- どんなアルゴリズムか(単純なPRNGか、DRBGか)
- seedはどこから来るか(固定値か、OSのエントロピー源か)
- reseed(再シード)するか
- エントロピー源の検証(ヘルスチェック)があるか
- どのAPIを使っているか
統計検定は「欠陥検出」に使う
NIST SP 800-22などの統計検定は、明らかな偏りを見つけるのに有効です。ただし、合格しても「本物の乱数」の証明にはなりません。
5. 用途別の選び方
| 用途 | 推奨するもの | 理由 |
|---|---|---|
| シミュレーション、ゲーム | 通常のPRNG | 高速で再現可能 |
| テスト、バグ再現 | 通常のPRNG | 同じ入力を再現できる |
| 鍵、トークン、セッションID | OSの安全な乱数API | 予測困難性が必要 |
| 監査が重い抽選 | 物理乱数源 | 説明責任が重要 |
| 一般的なアプリの安全な乱数 | OS標準の安全API | 自前実装より安全 |
6. 言語別の安全な乱数API
- Windows:
BCryptGenRandom - .NET:
System.Security.Cryptography.RandomNumberGenerator - Linux:
getrandom() - Python:
secretsモジュール(randomモジュールは非推奨) - Java:
SecureRandom
7. よくある誤解
- 「統計検定に通れば本物の乱数」 → 違う。CSPRNGも普通に通る
- 「本物の乱数なら常に安全」 → 違う。センサー不良や設計不備で品質は落ちる
- 「疑似乱数は全部危険」 → 違う。CSPRNGは安全な乱数の中核
- 「
Math.random()でトークンを作ってよい」 → ダメ。見た目のバラつきと予測困難性は別
8. 迷ったときの判断順
- 同じ結果を再現したいか → Yes: 通常のPRNG / No: 次へ
- 攻撃者に予測されると困るか → Yes: OS標準の安全API / No: 速度で選ぶ
- 乱数源の説明責任や監査が必要か → Yes: 物理乱数源を検討
- 自前実装したいか → まず標準APIを使うことを検討
9. まとめ
- 疑似乱数は計算で作る。再現性が武器
- 本物の乱数は物理現象から作る。エントロピーが武器
- 実務の安全な乱数は物理エントロピー + CSPRNGの組み合わせ
- 見た目ではなく生成器の構成で判断する
- セキュリティ用途ではOS/言語標準の安全APIを使う
参考資料
- NIST SP 800-90A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators
- NIST SP 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation
- NIST SP 800-90C: Recommendation for Random Bit Generator (RBG) Constructions
- NIST SP 800-22 Rev. 1a: A Statistical Test Suite for Random and Pseudorandom Number Generators
- RFC 4086: Randomness Requirements for Security
- Microsoft Learn: BCryptGenRandom function
- Linux man page: getrandom(2)
- Microsoft Learn: RandomNumberGenerator クラス
- Python documentation: secrets — Generate secure random numbers for managing secrets
- Oracle Java Documentation: SecureRandom
- IPA: 第3章 3.破られにくい暗号技術と擬似乱数の使用
関連する記事
同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。
Windowsはなぜ今の形になったのか:開発者から見た歴代Windowsの進化
Windows 95からWindows 11までの変化を、見た目の年表ではなく、互換性、安定性、権限管理、ドライバ、Win32、.NET、セキュリティなどWindowsアプリ開発者の視点で整理します。
Windowsで「Windows によって PC が保護されました」が出る理由
Windowsアプリ配布時にSmartScreen警告が出る理由を、コード署名、EV/OV証明書、Azure Artifact Signing、MSIX、Microsoft Store、ClickOnce、社内配布、App Controlまで実務目線で整理します。
自動アップデートのセキュリティ設計
Windows アプリの自動アップデートを単なる便利機能ではなく信頼境界として設計するための要点を整理します。HTTPS だけでは守れない理由、署名付き metadata、クライアント側検証、鍵分離、fail-closed と rollback まで一通り把握できます。
ハッシュ方式の判定方法【文字列表現から特定】
ログや DB に残ったハッシュ文字列から方式を見分ける際の実務手順を、接頭辞・区切り・文字集合・長さ・保存元の文脈という五つの観点で整理します。誤判定しやすい例も含め、候補を素早く絞る判断材料が得られます。
WindowsのDLL名前解決の仕組み
Windows の DLL 名前解決を、redirection、API set、SxS manifest、Known DLLs、loaded-module list、検索順序、LoadLibraryEx などの API ごとの違いまで実務目線で読み解き、依存 DLL とハイ...
関連トピック
このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。
Windows技術トピック
Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。