疑似乱数と本物の乱数の違いとは - どうやって区別するのかを整理

乱数の話は、かなり違うものが全部 ランダム という一語で呼ばれるので、すぐ話がずれます。Math.random() のような計算で作る数列も、熱雑音やクロックジッタのような物理現象から得る数列も、見た目だけならどちらもそれなりにバラけて見えるからです。

ただ、実務ではこの違いを曖昧にしたままだと、こういう判断を誤りやすくなります。

• シミュレーションで再現したいのに毎回結果がぶれる
• パスワード再発行トークンを、予測しやすい乱数で作ってしまう
• 統計検定に通っただけで「本物の乱数だ」と思ってしまう
• 逆に、疑似 と聞いただけで全部危険だと誤解する

この記事では、疑似乱数とは何か、本物の乱数とは何か、どうやって区別するのか を、実務で判断しやすい形で整理します。特に、出力の見た目ではなく、生成器の構成で見ることを主眼にします。

記事中の内容は、2026 年 4 月時点で確認できる NIST、IETF、OS、言語公式資料を前提に整理しています。

目次

1. まず結論（ひとことで）
2. この記事でいう「疑似乱数」と「本物の乱数」
3. まず一枚で整理
   • 3.1. 関係図
   • 3.2. 用語の最短整理
4. 疑似乱数とは何か
   • 4.1. ひとことで言うと
   • 4.2. 普通の PRNG と CSPRNG は分けて考える
5. 本物の乱数とは何か
   • 5.1. ひとことで言うと
   • 5.2. 物理乱数も、そのまま使うとは限らない
6. 何が違うのか
   • 6.1. 生成元
   • 6.2. 再現性
   • 6.3. 予測可能性
   • 6.4. 速度と運用
7. どうやって区別するのか
   • 7.1. 出力だけでは、原則として区別しきれない
   • 7.2. まず見るべきは、生成器の設計
   • 7.3. 次に、統計検定で明らかな欠陥を探す
   • 7.4. セキュリティ用途では、攻撃者視点で見る
8. 用途ごとに、どれを使うべきか
   • 8.1. 最小の使用例
9. よくある誤解
10. 実務で迷ったときの判断表
11. まとめ
12. 参考資料

この記事の知識マップ

この記事は、seedと内部状態から決定論的に数列を作る疑似乱数(PRNG)と、熱雑音などの物理現象をエントロピー源に持つ本物の乱数(NRBG)の違いを整理し、実務で使われる安全な乱数APIの多くが物理エントロピー源でseedしたCSPRNG/DRBGのハイブリッド構成であることを示す。出力の見た目だけでは両者を区別できず、統計検定(NIST SP 800-22)も証明ではなく欠陥検出にとどまるため、区別は生成アルゴリズムやseedの出所といった生成器の構成を確認して行うべきだとする。鍵・トークン・nonce・セッションIDのようなセキュリティ用途では、時刻など予測可能な値でseedするとトークンを推測されアカウント乗っ取りにつながりかねず、BCryptGenRandomや.NETのRandomNumberGenerator、Pythonのsecretsといった OS・言語標準のsecure RNG APIを使うべきだとしている。

flowchart LR
    accTitle: 疑似乱数と本物の乱数の違いの知識マップ
    accDescr: 疑似乱数(PRNG)と本物の乱数(NRBG)の違い、実務のCSPRNG/DRBGがエントロピー源とのハイブリッド構成であること、統計検定が証明ではなく欠陥検出にとどまること、予測可能なseedがトークン予測攻撃につながることを示す図。
    prng["疑似乱数(PRNG)"]
    true_random_number_generator["本物の乱数(NRBG/TRNG)"]
    csprng_drbg["暗号学的疑似乱数(CSPRNG/DRBG)"]
    entropy_source["エントロピー源"]
    statistical_test_suite["統計検定(NIST SP 800-22)"]
    predictable_seed["予測可能なseed(時刻・PIDなど)"]
    seed_prediction_attack["seed推測攻撃"]
    account_takeover["アカウント乗っ取り"]
    bcryptgenrandom["BCryptGenRandom"]
    dotnet_randomnumbergenerator[".NET RandomNumberGenerator"]
    linux_getrandom["getrandom()"]
    python_secrets_module["Pythonのsecretsモジュール"]
    java_securerandom["Java SecureRandom"]
    security_token_generation["鍵・トークン・nonce・セッションIDの生成"]
    simulation_reproducibility["シミュレーション・テストの再現性"]
    session_id["セッションID"]
    csprng_drbg -->|"前提とする"| entropy_source
    true_random_number_generator -->|"前提とする"| entropy_source
    csprng_drbg -.->|"で確認できる"| statistical_test_suite
    true_random_number_generator -.->|"で確認できる"| statistical_test_suite
    predictable_seed -->|"原因になり得る"| seed_prediction_attack
    seed_prediction_attack -.->|"原因になり得る"| account_takeover
    csprng_drbg -->|"防止する"| seed_prediction_attack
    bcryptgenrandom -.->|"実装を担う"| csprng_drbg
    dotnet_randomnumbergenerator -->|"利用する"| csprng_drbg
    linux_getrandom -->|"利用する"| csprng_drbg
    python_secrets_module -->|"利用する"| csprng_drbg
    java_securerandom -->|"利用する"| csprng_drbg
    csprng_drbg -->|"推奨される対応"| security_token_generation
    prng -->|"用いるのは非推奨"| security_token_generation
    prng -->|"推奨される対応"| simulation_reproducibility
    prng -->|"用いるのは非推奨"| session_id

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全16件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

1. まず結論（ひとことで）

先に、かなり雑ですが実務で役立つ言い方をすると、こうです。

• 疑似乱数は、内部状態とアルゴリズムから決定論的に作る数列です
• 本物の乱数は、熱雑音やジッタなどの物理現象をエントロピー源に持つ数列です
• ただし、実務で使う安全な乱数 API の多くは、物理乱数をそのまま返すのではなく、エントロピー源で seed した DRBG / CSPRNG を返します
• なので、見た目がランダムか だけでは区別できません。見るべきなのは、生成器の構成、seed の入り方、reseed、health test です
• シミュレーションや再現試験では、疑似乱数の再現性が武器になります
• 鍵、トークン、nonce のようなセキュリティ用途では、OS や言語が提供する安全な乱数 API を使うのが基本です

要するに、まずはこの 3 つを分けて考えると外しにくいです。

1. それは 普通の PRNG の話なのか
2. それは 暗号学的 PRNG / CSPRNG / DRBG の話なのか
3. それは 物理エントロピー源を持つ NRBG / TRNG の話なのか

2. この記事でいう「疑似乱数」と「本物の乱数」

この話では、単に 乱数 と言うと対象が広すぎます。なので、先に意味を固定します。

• 疑似乱数（PRNG）: seed と内部状態から、決定論的な手順で数列を生成するもの。同じ条件なら同じ列が出ます
• 暗号学的疑似乱数（CSPRNG / DRBG）: 疑似乱数の一種ですが、予測困難性を重視したものです。NIST SP 800-90A は、この deterministic random bit generator を定義しています
• 本物の乱数: 日常語としては 真性乱数 や 物理乱数 を指すことが多いです。NIST では NRBG（non-deterministic random bit generator）が近い言い方で、エントロピー源を常に参照し、正常時には full entropy の出力を持つものとして説明されています

呼び方が分野ごとに違うので、日常語と規格用語の対応も先に固定しておきます。以降は、左端の列の呼び方で通します。

2 点だけ補足します。

• NIST SP 800-90A / 90B / 90C が使う語は、DRBG、NRBG、entropy source です。CSPRNG と TRNG は規格の用語ではなく、実務や文献で広く使われている呼び方です
• 日本語では 疑似 と 擬似 の両方が使われます。この記事では 疑似乱数 に統一しています。参考資料の文書名だけは原文どおりです

ここで大事なのは、疑似乱数 と 危険な乱数 は同義ではないことです。

たとえば、線形合同法や単純な 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 は 再現はできるが、外からは予測しにくいように作る乱数
• 本物の乱数は 物理現象からエントロピーを取り出す乱数

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. まず見るべきは、生成器の設計

7.1 の答えは「出力だけでは無理」でした。では何を見るのか。見るのは、出力ではなく生成器そのものです。

同じ一様分布に見える 2 つの列があっても、片方は seed から計算で作られ、もう片方は物理現象から取られています。この違いは、列をいくら眺めても表に出てきません。作り方を確認して初めて分かります。つまり、区別は「観測」ではなく「確認」の作業です。

確認する項目は、次の 5 つです。

• 生成アルゴリズムは何か
  • 単純な PRNG なのか、DRBG / CSPRNG なのか
• seed はどこから来るか
  • 固定 seed、時刻、PID 程度なのか
  • OS のエントロピー源から来るのか
• reseed するか
  • 起動時に一度だけ seed して終わりか
  • 運用中も再投入されるか
• エントロピー源の検証があるか
  • min-entropy の評価
  • health test
  • 故障検知
• どの API を使っているか
  • 自前実装か
  • OS / 言語の標準 API か

5 つとも調べ切る必要はありません。上から順に見て、答えが出た時点で止めてかまいません。実務では、いちばん上の 生成アルゴリズムは何か と、いちばん下の どの API を使っているか の 2 つで決まることがほとんどです。

この観点で見れば、かなりのケースは区別できます。

• 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 をセキュリティ用途に流用している

このあたりは、見た目がそれっぽい だけでは防げません。

具体的に何が起きるかを、1 つ書いておきます。

パスワード再発行トークンを、現在時刻を seed にした PRNG で作っているとします。攻撃者は、まず自分のアカウントで再発行を要求し、届いたトークンを 1 つ手に入れます。トークンと、要求した時刻が分かれば、seed の候補は その前後の数秒ぶん まで絞れます。あとは候補ごとに同じアルゴリズムを回し、狙った相手のトークンとして出てくる値を順に試すだけです。

このとき、攻撃者は暗号を破っていません。生成器を手元で再現しただけです。その乱数列が統計検定に通っていたかどうかも関係ありません。seed の候補を数え上げられる時点で、その値は攻撃者にとって乱数ではないからです。

同じ話は、セッション ID、招待コード、ワンタイムパスワード、公開フォルダーに置く一時ファイル名にも当てはまります。推測されても大した被害はない と言い切れないものは、すべて secure RNG 側で作るべきです。

IPA も、セキュリティ関連 API や既存ライブラリを把握して、安易な自前実装を避けることを勧めています。Python でも secrets モジュールを、random より優先して使うよう明記されています。Java では SecureRandom がその位置づけです。

結局、セキュリティでは 疑似乱数か本物か より、安全な seed / entropy と安全な API を使っているか のほうが重要です。

8. 用途ごとに、どれを使うべきか

実装レベルでの無難な選び方はこうです。

• 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 です。

8.1. 最小の使用例

一覧だけでは手が動かないので、代表的な 2 つだけ実際の形を載せます。どちらも、seed を自分で用意しない点が共通しています。seed の調達は API 側の仕事です。

C#（.NET 8）では、System.Security.Cryptography.RandomNumberGenerator の静的メソッドを使います。

using System;
using System.Security.Cryptography;

// 0 以上 100 未満の整数を、偏りなく取る
int n = RandomNumberGenerator.GetInt32(0, 100);

// トークン用に 32 バイト取り、URL に載せられる文字列にする
byte[] bytes = RandomNumberGenerator.GetBytes(32);
string token = Convert.ToBase64String(bytes)
    .Replace('+', '-')
    .Replace('/', '_')
    .TrimEnd('=');

GetInt32 を使うのは、単に「バイト列を範囲で割った余り」にすると端の値だけ出やすくなるからです。範囲指定が必要なときは、自分で剰余を取らずにこちらを使います。

Python（3.6 以降）では、secrets モジュールです。

import secrets

# URL に載せられる安全なトークン
token = secrets.token_urlsafe(32)

# 0 以上 100 未満の整数
n = secrets.randbelow(100)

対比として、次は同じ用途に使ってはいけない書き方です。

import random

# NG: random は再現性のための PRNG で、セキュリティ用途向けではない
token = "".join(random.choices("abcdefghijklmnopqrstuvwxyz0123456789", k=32))

random と secrets は、どちらも見た目にはばらけた文字列を返します。違いは出力ではなく、どこから来た乱数かです。random は Mersenne Twister を使う再現性重視の PRNG で、Python 公式ドキュメントでも、秘密の管理には secrets を使うよう案内されています。

9. よくある誤解

9.1. 統計検定に通れば、本物の乱数である

違います。それで言えるのは、露骨な偏りが見えにくい くらいです。

9.2. 本物の乱数なら、常に安全である

違います。物理源の故障、偏り、実装不備、health test の欠如で品質は崩れます。

9.3. 疑似乱数は、全部危険である

違います。CSPRNG / DRBG は、むしろ実務の安全な乱数 API の中核です。

9.4. セキュリティ用途では、raw の物理乱数だけを直接使うべきである

そうとも限りません。実際は、物理エントロピー源 + CSPRNG の組み合わせが一般的です。

9.5. random や Math.random() でも十分ばらけるから、token に使える

用途が違います。見た目のばらつきと、攻撃者からの予測困難性は別です。

10. 実務で迷ったときの判断表

迷ったときの考える順番はこうです。

1. 同じ結果を再現したいか
   • はい → 通常の PRNG
   • いいえ → 次へ
2. 攻撃者に予測されると困るか
   • はい → OS / 言語標準の secure RNG
   • いいえ → 品質要件と速度で選ぶ
3. 乱数源そのものの説明責任や監査が必要か
   • はい → 物理乱数源や認証済みサービスを検討
4. 自前実装したいか
   • その気持ちは分かりますが、乱数は外しやすいので、まず標準 API を使う

この順で見ると、疑似か本物か という二択だけで悩むより、かなり早く方針が決まります。

11. まとめ

疑似乱数と本物の乱数の違いを、いちばん雑だけれど実務で役立つ形で言うなら、こうです。

• 疑似乱数は計算で作る
• 本物の乱数は物理現象からエントロピーを取る
• でも実務の安全な乱数 API は、その中間にある entropy source + CSPRNG が主役

つまり、見るべきは 見た目 ではなく 構成 です。

• 出力だけで本物かどうかを断定することはできない
• 統計検定は欠陥検出には役立つが、証明にはならない
• セキュリティでは 予測できるか が本丸
• 再現性が要るなら PRNG、予測困難性が要るなら OS / 言語標準の secure RNG を使う

この順で捉えると、疑似乱数は偽物なのか という雑な対立から抜けられます。

12. 参考資料

1. NIST SP 800-90A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators deterministic random bit generator の基本文書です。

2. NIST SP 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation entropy source、validation、health testing の考え方を整理しています。

3. NIST SP 800-90C: Recommendation for Random Bit Generator (RBG) Constructions entropy source + DRBG の構成を整理しています。

4. NIST SP 800-22 Rev. 1a: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications 統計検定の位置づけを説明しています。検定は第一歩であり、証明ではないという点が重要です。

5. NIST Glossary: Non-deterministic Random Bit Generator (NRBG) true random に近い NIST 用語の確認に使えます。

6. RFC 4086: Randomness Requirements for Security セキュリティ用途での乱数と entropy source の注意点を整理しています。

7. Microsoft Learn: BCryptGenRandom function Windows の secure RNG API と、既定プロバイダの CTR_DRBG について説明しています。

8. Linux man page: getrandom(2) Linux で cryptographic purposes に使える乱数 API です。

9. Microsoft Learn: RandomNumberGenerator クラス .NET の暗号強度の高い RNG API です。

10. Python documentation: secrets — Generate secure random numbers for managing secrets Python でセキュリティ用途の乱数を扱う基本です。

11. Oracle Java Documentation: SecureRandom Java の secure RNG と seed / entropy の考え方がまとまっています。

12. IPA: 第3章 3.破られにくい暗号技術と擬似乱数の使用 seed の重要性、検定、API 利用の注意点が日本語で整理されています。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

疑似乱数と本物の乱数（真性乱数）の違いは何ですか？

疑似乱数（PRNG）は、seedと内部状態からアルゴリズムで決定論的に作る数列で、同じ条件なら同じ列が出ます。本物の乱数は、熱雑音や発振器のジッタのような物理現象をエントロピー源に持つ数列で、同じ条件で取り直しても同じ値列にはなりにくいです。ただし、実務で使う安全な乱数APIの多くは、物理乱数をそのまま返すのではなく、物理エントロピー源でseedしたCSPRNG / DRBGを返すハイブリッド構成です。

出力を見れば疑似乱数か本物の乱数か区別できますか？

有限個の出力列だけを見て本物の乱数だと断定することはできません。観測した列とまったく同じ列を返す決定論的プログラムはいつでも作れてしまうからです。区別するときは出力の見た目より、生成アルゴリズムは何か、seedはどこから来るか、reseedするか、エントロピー源の検証（min-entropy評価やhealth test）があるか、どのAPIを使っているかという生成器の構成を確認するほうが本質的です。

統計検定に通れば本物の乱数と言えますか？

言えません。統計検定の役割は証明ではなく欠陥検出に近いです。NIST SP 800-22でも、統計検定はあくまで第一歩であり、それだけで生成器の妥当性を絶対に証明するものではないとされています。うまく作られたCSPRNGも普通に検定を通りますし、逆に物理乱数源でもセンサーの偏りや故障で落ちることがあります。通れば露骨な欠陥は見えにくい、落ちれば何かがおかしい可能性が高い、という位置づけです。

セキュリティ用途ではどの乱数APIを使えばよいですか？

鍵、トークン、nonce、セッションIDのような用途では、OSや言語が提供する安全な乱数APIを使うのが基本です。具体的には、WindowsネイティブならBCryptGenRandom、.NETならSystem.Security.Cryptography.RandomNumberGenerator、Linuxならgetrandom()、Pythonならsecretsモジュール、JavaならSecureRandomです。現在時刻やプロセスIDでseedした自前実装や、random系APIのセキュリティ用途への流用は避けるべきです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。