疑似乱数と本物の乱数の違いとは - どうやって区別するのかを整理
乱数の話は、かなり違うものが全部 ランダム という一語で呼ばれるので、すぐ話がずれます。Math.random() のような計算で作る数列も、熱雑音やクロックジッタのような物理現象から得る数列も、見た目だけならどちらもそれなりにバラけて見えるからです。
ただ、実務ではこの違いを曖昧にしたままだと、次の判断を誤りやすくなります。
- シミュレーションで再現したいのに毎回結果がぶれる
- パスワード再発行トークンを、予測しやすい乱数で作ってしまう
- 統計検定に通っただけで「本物の乱数だ」と思ってしまう
- 逆に、
疑似と聞いただけで全部危険だと誤解する
この記事では、疑似乱数とは何か、本物の乱数とは何か、どうやって区別するのか を、実務で判断しやすい形で整理します。特に、出力の見た目ではなく、生成器の構成で見ることを主眼にします。
記事中の内容は、2026 年 4 月時点で確認できる NIST、IETF、OS、言語公式資料を前提に整理しています。
目次
- まず結論(ひとことで)
- この記事でいう「疑似乱数」と「本物の乱数」
- まず一枚で整理
- 3.1. 関係図
- 3.2. 用語の最短整理
- 擬似乱数とは何か
- 4.1. ひとことで言うと
- 4.2. 普通の PRNG と CSPRNG は分けて考える
- 本物の乱数とは何か
- 5.1. ひとことで言うと
- 5.2. 物理乱数も、そのまま使うとは限らない
- 何が違うのか
- 6.1. 生成元
- 6.2. 再現性
- 6.3. 予測可能性
- 6.4. 速度と運用
- どうやって区別するのか
- 7.1. 出力だけでは、原則として区別しきれない
- 7.2. まず見るべきは、生成器の設計
- 7.3. 次に、統計検定で明らかな欠陥を探す
- 7.4. セキュリティ用途では、攻撃者視点で見る
- 用途ごとに、どれを使うべきか
- よくある誤解
- 実務で迷ったときの判断表
- まとめ
- 参考資料
1. まず結論(ひとことで)
先に、かなり雑ですが実務で役立つ言い方をすると、こうです。
- 疑似乱数は、内部状態とアルゴリズムから決定論的に作る数列です
- 本物の乱数は、熱雑音やジッタなどの物理現象をエントロピー源に持つ数列です
- ただし、実務で使う安全な乱数 API の多くは、物理乱数をそのまま返すのではなく、エントロピー源で seed した
DRBG / CSPRNGを返します - なので、
見た目がランダムかだけでは区別できません。見るべきなのは、生成器の構成、seed の入り方、reseed、health test です - シミュレーションや再現試験では、疑似乱数の再現性が武器になります
- 鍵、トークン、nonce のようなセキュリティ用途では、OS や言語が提供する安全な乱数 API を使うのが基本です
要するに、まずは次の 3 つを分けて考えると外しにくいです。
- それは
普通の PRNGの話なのか - それは
暗号学的 PRNG / CSPRNG / DRBGの話なのか - それは
物理エントロピー源を持つ NRBG / TRNGの話なのか
2. この記事でいう「疑似乱数」と「本物の乱数」
この話では、単に 乱数 と言うと対象が広すぎます。なので、先に意味を固定します。
- 疑似乱数(PRNG): seed と内部状態から、決定論的な手順で数列を生成するもの。同じ条件なら同じ列が出ます
- 暗号学的擬似乱数(CSPRNG / DRBG): 擬似乱数の一種ですが、予測困難性を重視したものです。NIST SP 800-90A は、この deterministic random bit generator を定義しています
- 本物の乱数: 日常語としては
真性乱数や物理乱数を指すことが多いです。NIST ではNRBG(non-deterministic random bit generator)が近い言い方で、エントロピー源を常に参照し、正常時には full entropy の出力を持つものとして説明されています
ここで大事なのは、擬似乱数 と 危険な乱数 は同義ではないことです。
たとえば、線形合同法や単純な xorshift のような高速 PRNG と、CTR_DRBG や HMAC_DRBG のような CSPRNG は、どちらも決定論的ではありますが、セキュリティ上の意味はかなり違います。
3. まず一枚で整理
3.1. 関係図
まずは、概念の位置関係を 1 枚で見るのが早いです。
flowchart LR
NOISE["物理現象<br/>熱雑音・ジッタなど"] --> ENT["エントロピー源"]
ENT --> SEED["seed / reseed"]
SEED --> DRBG["DRBG / CSPRNG<br/>高速に乱数を展開"]
DRBG --> API["OS / ライブラリが返す乱数"]
STATE["内部状態 + 数式"] --> PRNG["通常の PRNG"]
PRNG --> OUT["見た目はランダムな数列"]
ここで大事なのは、アプリが受け取る 安全な乱数 API の出力は、右の 通常の PRNG とも、左の 生の物理ノイズ とも少し違うことです。
多くの実装は、左側のエントロピー源を使って seed / reseed し、その上で DRBG / CSPRNG で高速に展開した値を返します。NIST SP 800-90B と 800-90C は、まさにこの entropy source + deterministic generator の構成を整理する文書です。
3.2. 用語の最短整理
| 種類 | 何で作るか | 同じ条件で再現 | 何を強く求めるか | 向いている用途 |
|---|---|---|---|---|
| 通常の PRNG | 数式と内部状態 | できる | 速度、再現性 | シミュレーション、ゲーム、テスト |
| CSPRNG / DRBG | 暗号アルゴリズム + seed | できる | 予測困難性 | 鍵、トークン、nonce、セッション ID |
| 本物の乱数 / NRBG | 物理エントロピー源 | 基本できない | 物理的不確定性、エントロピー | seed 供給、認証装置、監査が重い抽選 |
最短で覚えるなら、こうです。
- 通常の PRNG は
再現できる乱数 - CSPRNG は
再現はできるが、外からは予測しにくいように作る乱数 - 本物の乱数は
物理現象からエントロピーを取り出す乱数
4. 擬似乱数とは何か
4.1. ひとことで言うと
疑似乱数は、内部状態を更新しながら、乱数らしく見える数列 を計算で作るものです。
同じ seed を入れ、同じアルゴリズムで、同じ回数だけ取り出せば、同じ値列が出ます。これは欠点に見えがちですが、シミュレーション、テスト、デバッグではむしろ大きな利点です。
再現できるからこそ、この seed でバグが出る、昨日の結果をもう一度比較したい という運用ができます。
4.2. 普通の PRNG と CSPRNG は分けて考える
ここがいちばん誤解されやすいところです。擬似乱数 = 偽物 = 使ってはいけない ではありません。
NIST SP 800-90A は、ハッシュ関数やブロック暗号を基盤にした deterministic random bit generator を定義しています。つまり、暗号用途で使われる乱数の中核も、かなりの部分は決定論的な生成器です。
違いは、ただの 乱数っぽさ ではなく、攻撃者から見た予測困難性にあります。
- 普通の PRNG
- 速い
- 再現しやすい
- 内部状態や seed が漏れると予測されやすい
- CSPRNG / DRBG
- これも決定論的
- ただし、内部状態が分からない前提で、出力を予測しにくいように設計される
- セキュリティ用途では、こちらを使う
なので、疑似乱数かどうか だけで安全性を判断すると、ほぼ外します。見るべきは どの擬似乱数か です。
5. 本物の乱数とは何か
5.1. ひとことで言うと
本物の乱数は、熱雑音、発振器のジッタ、アバランシェノイズ、量子現象のような物理的な不確定性からエントロピーを取り出すものです。
日常語では 真性乱数 や 物理乱数 と呼ばれます。NIST の用語では NRBG が近く、常にエントロピー源へアクセスし、正常に動いている限り full entropy の出力を持つ生成器 という位置づけです。
5.2. 物理乱数も、そのまま使うとは限らない
ここも大事です。本物の乱数だからといって、生の測定値をそのままアプリへ渡すとは限りません。
物理源には、次のような実務上の難しさがあります。
- 偏りがある
- 温度、電源、故障、劣化の影響を受ける
- 生の出力速度はそれほど高くないことがある
- ヘルスチェックなしでは、壊れていても気づきにくい
このため、NIST SP 800-90B では、エントロピー源の設計原則、min-entropy の考え方、validation test、health testing が重視されます。さらに実装全体としては、NIST SP 800-90C のように entropy source + DRBG の構成で使われることが多いです。
要するに、本物の乱数 は raw の神秘的な何かではなく、物理源、評価、監視、後処理まで含めて扱うものです。
6. 何が違うのか
乱数の違いは、単に ランダムに見えるか だけでは整理しきれません。少なくとも、次の 4 軸で見ると分かりやすいです。
6.1. 生成元
- 疑似乱数: アルゴリズムと内部状態
- 本物の乱数: 物理エントロピー源
ここは最も本質的な違いです。
6.2. 再現性
- 疑似乱数: 同じ seed なら再現できる
- 本物の乱数: 同じ条件で取り直しても同じ値列にはなりにくい
再現性は、テストでは強み、抽選では弱みになりえます。
6.3. 予測可能性
- 普通の PRNG: seed や内部状態が読めると先がかなり分かる
- CSPRNG: 内部状態が守られている前提で、先読みされにくいよう設計される
- 本物の乱数: 物理源が健全なら予測しにくいが、センサー不良や設計不備は別問題
セキュリティでは、この軸が最重要です。見た目のバラつきより、次を当てられるかどうかが効きます。
6.4. 速度と運用
- 疑似乱数: 高速、安定、実装しやすい
- 本物の乱数: エントロピー収集や監視が必要で、速度や実装コストに制約がある
このため、本番システムでは 本物の乱数だけ か 擬似乱数だけ かの二択ではなく、物理エントロピーで種を入れた CSPRNG がいちばん現実的です。
7. どうやって区別するのか
7.1. 出力だけでは、原則として区別しきれない
いちばん大事な答えはこれです。有限個の出力列だけを見て、これは本物の乱数だ と断定することはできません。
理由は単純で、いま観測した有限長の列とまったく同じ列を返す決定論的プログラムは、いつでも作れてしまうからです。極端に言えば、その列を配列や ROM に埋め込んで順番に返せばよいだけです。
だから、見た目が自然だから本物 とは言えません。NIST SP 800-22 でも、統計検定はあくまで第一歩であり、それだけで生成器の妥当性を絶対に証明するものではないとされています。
逆に言うと、良い CSPRNG は、出力だけを見てもかなり区別しにくいように作られます。ここで 区別できない のは、むしろ設計目標の側です。
7.2. まず見るべきは、生成器の設計
区別するときは、出力の見た目より、次を確認するほうが本質的です。
- 生成アルゴリズムは何か
- 単純な PRNG なのか、DRBG / CSPRNG なのか
- seed はどこから来るか
- 固定 seed、時刻、PID 程度なのか
- OS のエントロピー源から来るのか
- reseed するか
- 起動時に一度だけ seed して終わりか
- 運用中も再投入されるか
- エントロピー源の検証があるか
- min-entropy の評価
- health test
- 故障検知
- どの API を使っているか
- 自前実装か
- OS / 言語の標準 API か
この観点で見れば、かなりのケースは区別できます。
seed を固定すると毎回同じ列が出る→ 疑似乱数物理エントロピー源があり、validation / health test を前提にしている→ 本物の乱数源を持つ設計OS の secure RNG API を呼んでいる→ 多くは物理エントロピー + CSPRNGのハイブリッド
7.3. 次に、統計検定で明らかな欠陥を探す
統計検定は不要ではありません。むしろ重要です。ただ、役割は 証明 ではなく 欠陥検出 に近いです。
代表的には、次のような観点を見ます。
- 0 と 1 の偏り
- run の偏り
- 周期性
- 相関
- 近似エントロピー
- 線形複雑度
NIST SP 800-22 や、国内では CRYPTREC の乱数検定ミニマムセットがよく参照されます。これらは、その列におかしな偏りや構造がないか を調べるには有効です。
ただし、ここで合格しても 本物の乱数 とは言えません。うまく作られた CSPRNG も普通に通りえますし、逆に物理乱数源でも、センサーの偏りや故障で落ちることがあります。
検定の位置づけは、だいたいこうです。
- 通る: ひとまず露骨な欠陥は見えにくい
- 落ちる: 何かがおかしい可能性が高い
- だから本物と証明できる: そこまでは言えない
7.4. セキュリティ用途では、攻撃者視点で見る
パスワード再発行トークン、セッション ID、nonce、鍵生成のような用途では、問いは 本物かどうか だけでは足りません。
本当に見るべきは、攻撃者が次の値を予測できるかどうかです。
たとえば、
- 現在時刻だけで seed している
- プロセス ID や連番を混ぜただけ
- 自前実装で seed の質を評価していない
random系 API をセキュリティ用途に流用している
このあたりは、見た目がそれっぽい だけでは防げません。
IPA も、セキュリティ関連 API や既存ライブラリを把握して、安易な自前実装を避けることを勧めています。Python でも secrets モジュールを、random より優先して使うよう明記されています。Java では SecureRandom がその位置づけです。
結局、セキュリティでは 疑似乱数か本物か より、安全な seed / entropy と安全な API を使っているか のほうが重要です。
8. 用途ごとに、どれを使うべきか
| 用途 | 向いているもの | 理由 |
|---|---|---|
| シミュレーション、Monte Carlo、ゲームロジック | 通常の PRNG | 速く、seed で再現できる |
| テスト再現、バグ再現 | 通常の PRNG | 同じ入力を再現できる |
| 鍵、トークン、nonce、セッション ID | CSPRNG / OS の secure RNG API | 予測困難性が必要 |
| seed 供給、監査や説明責任が重い抽選 | 物理乱数源を持つ設計、または監査可能な仕組み | 物理エントロピーや証跡が重要 |
一般アプリ開発で 安全な乱数 が必要 |
OS / 言語標準の secure RNG | 自前実装より外しにくい |
実装レベルでは、次のような選び方が無難です。
- Windows ネイティブ:
BCryptGenRandom - .NET:
System.Security.Cryptography.RandomNumberGenerator - Linux:
getrandom() - Python:
secrets - Java:
SecureRandom
Windows の BCryptGenRandom は、Microsoft Learn で NIST SP800-90 の CTR_DRBG に準拠する既定プロバイダを説明しています。Linux の getrandom() も、乱数バイトを cryptographic purposes に使えると文書化されています。.NET の RandomNumberGenerator、Python の secrets、Java の SecureRandom も、それぞれ暗号用途を意識した API です。
9. よくある誤解
9.1. 統計検定に通れば、本物の乱数である
違います。それで言えるのは、露骨な偏りが見えにくい くらいです。
9.2. 本物の乱数なら、常に安全である
違います。物理源の故障、偏り、実装不備、health test の欠如で品質は崩れます。
9.3. 擬似乱数は、全部危険である
違います。CSPRNG / DRBG は、むしろ実務の安全な乱数 API の中核です。
9.4. セキュリティ用途では、raw の物理乱数だけを直接使うべきである
そうとも限りません。実際は、物理エントロピー源 + CSPRNG の組み合わせが一般的です。
9.5. random や Math.random() でも十分ばらけるから、token に使える
用途が違います。見た目のばらつきと、攻撃者からの予測困難性は別です。
10. 実務で迷ったときの判断表
迷ったら、次の順で考えると早いです。
- 同じ結果を再現したいか
- はい → 通常の PRNG
- いいえ → 次へ
- 攻撃者に予測されると困るか
- はい → OS / 言語標準の secure RNG
- いいえ → 品質要件と速度で選ぶ
- 乱数源そのものの説明責任や監査が必要か
- はい → 物理乱数源や認証済みサービスを検討
- 自前実装したいか
- その気持ちは分かりますが、乱数は外しやすいので、まず標準 API を使う
この順で見ると、疑似か本物か という二択だけで悩むより、かなり早く方針が決まります。
11. まとめ
疑似乱数と本物の乱数の違いを、いちばん雑だけれど実務で役立つ形で言うなら、こうです。
- 疑似乱数は計算で作る
- 本物の乱数は物理現象からエントロピーを取る
- でも実務の安全な乱数 API は、その中間にある
entropy source + CSPRNGが主役
つまり、見るべきは 見た目 ではなく 構成 です。
- 出力だけで本物かどうかを断定することはできない
- 統計検定は欠陥検出には役立つが、証明にはならない
- セキュリティでは
予測できるかが本丸 - 再現性が要るなら PRNG、予測困難性が要るなら OS / 言語標準の secure RNG を使う
この順で捉えると、疑似乱数は偽物なのか という雑な対立から抜けられます。
12. 参考資料
-
NIST SP 800-90A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators
deterministic random bit generator の基本文書です。 -
NIST SP 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation
entropy source、validation、health testing の考え方を整理しています。 -
NIST SP 800-90C: Recommendation for Random Bit Generator (RBG) Constructions
entropy source + DRBGの構成を整理しています。 -
NIST SP 800-22 Rev. 1a: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications
統計検定の位置づけを説明しています。検定は第一歩であり、証明ではないという点が重要です。 -
NIST Glossary: Non-deterministic Random Bit Generator (NRBG)
true randomに近い NIST 用語の確認に使えます。 -
RFC 4086: Randomness Requirements for Security
セキュリティ用途での乱数と entropy source の注意点を整理しています。 -
Microsoft Learn: BCryptGenRandom function
Windows の secure RNG API と、既定プロバイダのCTR_DRBGについて説明しています。 -
Linux man page: getrandom(2)
Linux でcryptographic purposesに使える乱数 API です。 -
Microsoft Learn: RandomNumberGenerator クラス
.NET の暗号強度の高い RNG API です。 -
Python documentation: secrets — Generate secure random numbers for managing secrets
Python でセキュリティ用途の乱数を扱う基本です。 -
Oracle Java Documentation: SecureRandom
Java の secure RNG と seed / entropy の考え方がまとまっています。 -
IPA: 第3章 3.破られにくい暗号技術と擬似乱数の使用
seed の重要性、検定、API 利用の注意点が日本語で整理されています。
関連する記事
同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。
自動アップデート機能のセキュリティ基本 - ダメなパターンとベストプラクティス
自動アップデートを便利機能ではなく信頼境界として扱うために、HTTPS だけで守れない理由、signed metadata、クライアント側検証、鍵分離、rollback と fail-closed、Windows で既存基盤を優先する考え方を整理します。
ハッシュ値の文字列表現からハッシュ方式を判定する方法 - 長さ・文字種・接頭辞で候補を絞る実務手順
ログや DB に残ったハッシュ文字列から方式を見分けるときは、接頭辞・区切り・文字集合・長さの順で見ると整理しやすいです。接頭辞付きの保存形式はかなり特定しやすい一方、単なる 16 進や Base64 は候補を絞るまでしかできません。
Windows での DLL の名前解決の仕組み - 検索順序、Known DLLs、API set、SxS を実務向けに整理
Windows の DLL 名前解決を、DLL search order、Known DLLs、loaded-module list、API set、SxS manifest、LoadLibrary 系 API の影響まで実務向けに整理します。
Windows の管理者特権が必要になるのはいつなのか - UAC、保護領域、設計上の見分け方
Windows で管理者特権が必要になる場面を、UAC、保護領域、サービス、ドライバ、per-user/per-machine 設計の観点から実務向けに整理します。
Windowsアプリで「管理者権限が必要な処理だけ」を分離する具体的な書き方
Windows アプリで UI を asInvoker のまま保ちつつ、管理者権限が必要な処理だけを helper EXE に分離する設計を、UAC、runas、名前付きパイプ、入力検証まで含めて具体的に整理します。
関連トピック
このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。
Windows技術トピック
Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。
このテーマがつながるサービス
この記事は次のサービスページにつながります。近い入口からご覧ください。
技術相談・設計レビュー
シミュレーション向けの再現性とセキュリティ向けの予測困難性をどう切り分けるか、乱数 API の選定や seed 設計から整理したい場合は、技術相談・設計レビューとして扱いやすいテーマです。