1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

「大災害が起きると乱数発生器が偏る」を、17年分の実データで検証した

1
Last updated at Posted at 2026-08-21

TL;DR

  • 「人類の集合意識が乱数に影響する」と主張する Global Consciousness Project (GCP) の公開アーカイブ(1998-2015、17年分)を全部落として検証した
  • 事前に手順を凍結してから大地震90件を検定 → p = 0.89、偏りなし
  • ところが窓を後から選んでいいことにすると、9.11で「3,894分の1」、3.11で「387分の1」という数字が作れる
  • でも同じ探索を何も起きていない日にやると、120日全部で同じくらいの「異常」が出る。3.11に至っては普通の日の平均以下
  • 結論:「偏りがあると言える」。ただし何も起きていない日についても同じことが言える

コードとデータ取得手順は全部載せます。


1. GCPとは何か

プリンストン大学の Roger Nelson らが1998年から2015年まで続けたプロジェクトです。世界最大70箇所に**ハードウェア乱数発生器(EGG と呼ぶ)**を設置し、毎秒データを送らせ続けました。

主張はこうです。

大勢の人間が同じ出来事に強く注意を向けると、世界中の乱数発生器が「揃って」ランダムでなくなる。

ポイントは「1台が0か1に偏る」ではなく、**バラバラのはずの装置が同じ方向に動く(同期する)**という主張です。9.11のときに「偶然なら1兆分の1」の偏りが出た、というのが看板になっています。

物理学的な機序は提示されていません。ただ、データは全部公開されています。なので検証できます。

2. なぜGCPのデータを使うのか

「量子乱数発生器のログを使えばいいのでは」と思うかもしれません。使えません。

市販のQRNG(ID Quantique の Quantis など)も NIST Randomness Beacon も、出力に**ホワイトニング(乱数抽出・ハッシュ)**をかけています。NIST Beacon は SHA-512 のハッシュチェーンを通しています。

後処理は偏りを除去するための仕組みなので、入力側にどんな微小な偏りがあっても出力からは数学的に消えます。この検証には原理的に使えません。

生に近い物理乱数の大規模アーカイブは、GCP自身のものが実質唯一です。皮肉ですが、主張する側のデータで検証するのが最も強い検証になります。「データが悪かった」と言い逃れできないので。

3. データの形式

取得エンドポイントはこれです。

https://global-mind.org/cgi-bin/eggdatareq.py?z=1&year=2011&month=3&day=11&idate=Yes

実装するときに踏んだ罠を先に書いておきます。

事項 実際の挙動
stime/etime 無視される。常に丸1日返ってくる
圧縮 Content-Encoding: gzip が付くので requests が透過解凍する。r.content は素のCSV
サイズ 展開 20.7MB / 再圧縮 5.3MB(1日あたり)

中身はこうです。

10,4,200,"Trial size"                    ← 1試行 = 200ビット
11,1,67,"Eggs reporting"                 ← この日は67台
12,"gmtime",,1,37,102,103,105,...        ← 列見出し = EGG ID
13,1299801600,,99,98,103,108,101,...     ← 毎秒1行、各EGGの「200ビット中1が何個か」
13,1299801601,,95,98,98,101,97,...

毎秒、各EGGが200回コインを投げて表の数を報告していると思えばいいです。期待値100、標準偏差 √50 ≈ 7.07。

データ品質は極めて良好でした。

項目 実測(2011-03-11の1日分) 理論値
平均 99.9915 100
標準偏差 7.0715 7.0711
試行数 5,395,702 —

小数第4位まで一致します。

4. 測る量:W(その6時間、どれだけ「揃った」か)

GCP自身が使っている統計量(ネットワーク分散)をそのまま使います。相手の土俵で戦うためです。

Z_it     = (x_it - 100) / sqrt(50)        # 各EGGが100からどれだけズレたか
netvar_t = (Σ_i Z_it)² / N_t              # その1秒、全EGGが揃っていたか
W        = (Σ_t netvar_t - n) / sqrt(2n)  # 窓全体を標準化

netvar がミソです。EGGがバラバラなら +1 と −1 が打ち消し合ってゼロ近くになる。揃っていると打ち消されず大きくなる。

Wは「この窓の間、世界の乱数発生器はいつもより揃っていたか」を表す1つの数字です。

  • W = 0 → まったく普通
  • W = +2 → いつもより揃っていた ← GCPが主張する方向
  • W = −2 → いつもよりバラバラだった

5. 検証手順を「凍結」する

ここが本記事の肝です。

GCPが批判される最大の理由は解析の後付けです。独立解析によれば、Nelson自身が事前登録していた4時間の窓では9.11に有意差は出ていません。発表された数字は「最初の衝突から4時間後に始まる約30分」という窓から出ていて、その窓はデータを見たあとに選ばれています。

いわゆる狙撃手の誤謬です。

壁に向かって矢を射る。当たった場所を見てから、その周りに的を描く。そして「ど真ん中に当てた」と言う。

なので今回は、データに触れる前に以下を決めて git にコミットし、そのハッシュを記録してから解析しました。

事象リスト : USGS カタログから M≥7.5 を機械的に抽出(1998-08-01〜2015-12-31)
             → 98件。窓幅より近接する事象は大きい方に統合 → 90件
             events.csv の sha256 も記録
窓         : ±3時間の1つだけ。代替案を用意しない
統計量     : GCPのネットワーク分散 → Stouffer Z で90件を統合
対照       : 各事象を ±7,14,...,70日ずらした窓(1事象あたり20件)
             7の倍数なので UTC の時刻と曜日が固定される
判定       : 片側 経験的 p < 0.05
公表       : 帰無でも結果をそのまま出す

矢を射る前に的を描いて、釘で打ちつけたわけです。

事象選択に人間の判断を一切入れないのが重要です。「重大そうだから」で選べる時点で終わりです。

6. 結果1:事前登録した検定 → 偏りなし

1,988日分(約4GB)をダウンロードして回した結果です。

events used  : 90 / 90
Stouffer Z   : -1.2855
one-sided p  : 0.8924
verdict      : 帰無仮説を棄却する証拠なし

観測された方向は**GCPの主張と逆(負)**でした。

指標 値
事象ごとのW 平均 −0.1355(H1は正を予測)
正 / 負 43件 / 47件 — ほぼコイン投げ
最大のW +1.977
東日本大震災 M9.1 W = +0.376

fig2_distribution.png
(キャプション: 大地震のときのWは普通の日と見分けがつかない)

青い線が大地震90件、灰色が災害と無関係な1,786窓です。重なっています。

p = 0.8924 の意味はこうです。

でたらめでも、89%の確率で今回より「GCPに有利な」結果が出る。

感度分析(外れ値の扱いを変えたもの)も含めて、3通りすべてで同じ結論でした。

手順 p値
凍結手順(主要結果) 0.8905
|W|≥5 を除外 0.8574
|W|≥3 を除外 0.8694

7. 結果2:後付けなら「偏り」は作れる

ここからが面白いところです。わざと的を後から描いてみます。

窓幅9通り(±5分〜±12時間)× ずらし幅97通り(−12時間〜+12時間を15分刻み)= 873通りを総当たりし、一番都合のいい窓だけを採用します。

fig3_grid.png
(キャプション: 9.11の周辺で873通りの窓を試した結果)

赤いマスが「揃っていた」窓です。この中から1つ選べばいい。

結果:

事件 採用された窓 best W naive p 見出し
9.11 10分幅、衝突の 2.25時間後 +3.474 0.000257 「3,894分の1」
3.11 5分幅、地震の 10.5時間後 +2.797 0.002581 「387分の1」

見出しになる数字が出ました。 しかも構造がNelsonの発表と瓜二つです(短い窓・事件の数時間後)。

3.11の窓に注目してください。「地震の10.5時間後から、わずか5分間」。事前にこんな窓を予言できる人はいません。

8. なぜそれが無意味なのか

同じ873通りの探索を、何も起きていない120日に適用します。

fig4_manufactured.png
(キャプション: 探索すればどの日でも異常は出る)

対照120日の best-W : 平均 +2.940  最小 +1.922  最大 +4.227
9.11               : +3.474   (対照の88%より上)  補正後 p = 0.132
3.11               : +2.797   (対照の38%より上)  補正後 p = 0.628

何も起きていない日でも、探せば必ず +1.9 以上の「異常」が見つかります。 そして3.11の「387分の1の異常」は、普通の日の平均を下回っています。

理屈は単純で、873回も試せば偶然「3,894分の1」の目が1回くらい出るからです。期待値で 873 × 0.000257 ≈ 0.22回。数日ぶん探せばまず出ます。

これが多重比較です。

fig1_contrast.png
(キャプション: 同じデータ、違うのは窓を後から選んだかだけ)

数え方 9.11 の p値 解釈
探索を隠す(Nelson式) 0.000257 「1兆分の1!」の作り方
探索を数える(正しい) 0.132 ごく普通。証拠にならない

水増し率は9.11で 515倍、3.11で 243倍 でした。

9. 自分の結果からも「発見」は作れる

事前に宣言してあった二次解析として、震源地の現地時刻で90事象を4群に分けた。GCPの仮説は「集合的注意」なので、もし何かあるなら現地が昼間(すぐ人が気づく)の方が強く出るはず、という予測が立つ。

fig5_localtime.png
(キャプション: 現地時刻で分けても、どの時間帯にも効果はない)

群 n W平均 Stouffer Z 片側p
夜間 00-06 20 −0.124 −0.554 0.624
午前 06-12 22 −0.102 −0.476 0.705
午後 12-18 21 +0.054 +0.247 0.338
夜 18-24 27 −0.319 −1.659 0.950

昼(12-18)と夜間(00-06)の平均差は +0.178、並べ替え検定の両側 p = 0.548 で差なし。「人が起きている時間帯に限れば効く」という逃げ道は塞がった。

ただし注目してほしいのは、午後だけがプラスという点だ。GCPが予測する方向で、しかも「人が起きていてすぐ気づく時間帯」という筋書きにも合う。ここだけ抜き出せば「昼間に起きた地震では乱数が偏る傾向が見られた」と書ける。

書けるが、意味はない。4群あれば1群くらいプラスに振れるのは当たり前で、p = 0.338 は何も言っていない。1群あたり20件強しかないので検出力も弱い。

自分の研究の中にも、切り取れば主張に使える部分はある。切り取らずに全部出すかどうかだけが違う。

10. おまけ:GCPデータには地雷がある

検証中に見つけた、GCPデータを扱う人が確実に踏む罠を共有します。

対照窓の標準偏差が理論値1.0のはずが 8.42 と異常に大きく、原因を追ったところ——

1,791窓のうち、たった4窓で「1台のEGGだけが値 0 を大量に吐いて」いました。

日付 該当EGG 0 の出現率
2005-08-08 1026 8.1%
2008-03-24 2042 12.2%
2011-04-27 2080 32.3%

0 は「200ビット中1が0個」を意味し、正常なRNGでは確率 2⁻²⁰⁰。事実上ありえません。ハードウェア故障が「欠測」ではなく「リテラルの0」として記録されているわけです。

同じ日の他のEGGは全て正常(mean(Z)≈0、sd≈1.00)でした。

この4窓を除くと sd = 1.027 となり理論値どおりになります。空欄だけを欠測扱いすると刺さります。

対策としては、EGG単位でこう弾くのが確実です。

# 正常なEGGなら 86,400サンプルで mean(Z) は ±0.01 に収まる
m, s = np.nanmean(Z, axis=0), np.nanstd(Z, axis=0)
bad = (np.abs(m) > 0.1) | (s < 0.8) | (s > 1.25)
Z[:, bad] = np.nan

11. まとめ

「大災害のとき乱数は偏るか?」への答えは、「偏ると言える。ただし何も起きていない日についても同じことが言える」。

だから9.11だけ、3.11だけを取り出して主張するのは無意味です。主張したいなら、事前に窓を1つ決めて、それだけを見なければならない。

そうやって90事象でやった結果が p = 0.89、偏りなし でした。

この記事で本当に言いたいのは、GCPが間違っているということより、手順を先に決めて公開しておかないと、善意でも簡単に「発見」が作れてしまうということです。873通り試せる自由があるだけで、水増し率は数百倍になります。

自分のデータ分析で、こう自問するといいと思います。

  • この窓幅・この閾値は、データを見る前に決めたか?
  • 試した組み合わせを全部数えているか?
  • 同じ手順を「何も起きていないデータ」に当てたらどうなるか?

3番目が一番効きます。

参考

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?