世界中の数億人ものユーザーが、Windows XPの初回起動時に割り当てられるデフォルトのユーザー画像は完全なランダムで選ばれていると信じ込んでいた。2026年9月9日、マイクロソフトのベテランエンジニアであるRaymond Chen氏が公開したわずかなコードによって、四半世紀にわたりOS内部に秘められていたロジックがついに明らかになった。あの気まぐれに見えたアイコンの選定は決して単なるくじ引きではなく、極めて精密な計算プロセスによって導き出された必然の結果だったのだ。
1件のツイートから始まったコード考古学
2025年12月11日、Xenoと名乗るユーザーがTwitter（現X）上でひとつの問いを投げかけた。Windows XPで新しいユーザーアカウントを作成する際、どの画像を使用するかを決定する乱数生成ロジックはどうなっているのか、という疑問である。これは開発者コミュニティの間で20年以上も燻り続けていた謎だった。かつて2004年4月、Raymond Chen氏は自身のブログで「XPの画像はランダムに選ばれている」と軽く触れたことがあったが、ハードコアな開発者たちの探究心を満たすには到底足りなかった。彼らが求めていたのは大雑把な結論ではなく、具体的な実装コードとアルゴリズムの数理的導出だったのだ。
Raymond Chen氏はついに自身のブログ「The Old New Thing」で詳細なコードロジックを解説した。この記事はHacker Newsですぐさま333ポイント、162件ものコメントを集めて大きな反響を呼んだ。当時、自分のアカウントに割り当てられたのがギターであれ、花であれ、チェスの駒であれ、それはブラックボックスから適当に引かれたものではなかった。その背後には、厳密に設計された数学的フローが存在していたのだ。
初期シードは起動からの経過ミリ秒
Windows XPにおいて、これらの初期画像ファイルはシステムの深い階層に格納されていた。具体的なパスは %ALLUSERSPROFILE%\Application Data\Microsoft\User Account Pictures\Default Pictures である。OSは新規アカウントを作成するたび、このディレクトリから1枚の画像を抽出する必要があった。
ここで中核を担っていたのが、Windowsカーネル内部に標準で備わっている擬似乱数生成器 RtlRandomEx である。あらゆる擬似乱数アルゴリズムには初期シードが不可欠だ。マイクロソフトのエンジニアたちは、複雑なハードウェアエントロピー源を探す代わりに、GetTickCount() の戻り値をそのままシードとして渡す方式を採用した。このAPIは、システムが起動した瞬間から現時点までに経過した正確なミリ秒数を返す関数である。
**擬似乱数アルゴリズムには明確な入力条件が存在する。マシンが起動してからその瞬間に至るまでの正確なミリ秒数さえ記録されていれば、どの画像が選ばれるかは数学的に完全に予測可能だった。**ユーザーにとって予測不能に見えたのは単なる感覚に過ぎず、コードのレイヤーにおいては完全に再現可能な決定論的プロセスだったのである。
溜池サンプリングで走査を1回に圧縮
ファイル数が事前には定まらないディレクトリを扱う場合、教科書的なアプローチは「2回走査（Two-pass）」である。まずディレクトリ全体を走査して総ファイル数 n をカウントし、1から n までの乱数インデックスを生成した上で、もう一度最初から走査して該当位置のファイルを取得する。これが典型的なナイーブな手法だ。
しかしマイクロソフトのエンジニアたちはその道を選ばず、「1回走査（Single-pass）」アルゴリズムを導入した。ディレクトリを走査する間、システムが保持する変数はカウンター count と現在の当選要素 winner の2つだけである。エントリを1つ読み込むたびに count を1増やし、1/count の確率で winner を現在読み込んだ画像に置き換える。ディレクトリ全体の読み込みが終わった時点で、手元に残っている winner が最終的な結果となる。
図：selectRandomFromIterator 1回走査アルゴリズムのコード。出典：The Old New Thing
これは、まさに溜池サンプリング（Reservoir Sampling）における k=1 の古典的な特例である。n 個の要素からなる集合において、末尾の要素が選ばれる確率は厳密に 1/n となる。それが選ばれなかった場合、問題は手前の n-1 個の中から同様に均一に選定する再帰へと帰着する。ディレクトリ内にどれほど多くのファイルが存在していようとも、すべての画像が最終的に手元に残る確率は完全に均等な 1/n に保たれる。
数学理論とファイルシステムI/Oの妥協
なぜ単純明快な2回走査を退け、わざわざ溜池サンプリングを採用したのだろうか。その理由は、OSの根源的なボトルネックに隠されている。アカウント作成のフェーズにおいて、ファイルシステムの呼び出しにかかるオーバーヘッドは、CPUの単純な計算コストを遥かに上回る。とりわけ当時の低速な機械式ハードディスク（HDD）にとって、大量の小さなファイルを繰り返しトラバースする処理は極めて大きなレイテンシ要因だった。
走査を1回に抑えることで、ファイルシステムへのアクセス負荷は劇的に軽減された。さらにディレクトリ内のファイル数が処理の最中に変動したとしても、エラーを起こさず安全に完結できる。
2回走査を行う場合、1回目のカウント時と2回目の取得時との間でファイル構成が完全に静的でなければならない。もし最初のカウントとファイル抽出のわずかな隙間に別のプロセスが画像を移動・削除した場合、インデックスの範囲外アクセスやファイル未検出エラーが発生してシステムがクラッシュしかねない。1回走査のアプローチは、この危険なレースコンディションを見事に回避していた。
100枚スキャンで即時停止する安全弁
溜池サンプリングは数学的には無限の入力に対しても美しく機能する。カウンターが増加するにつれて手元の要素が置き換えられる確率は反比例して減少していく。しかし、商用OSのプロダクションコードが無制限のループを許容することは決してない。このコアロジックの中に、エンジニアたちは極めて現実的で力技とも言える防壁をハードコードしていた。
イテレータが読み込んだ画像が100枚に達した瞬間、アルゴリズムは直ちにループを強制脱出し、その時点で手元にある画像を確定値として返すのである。
図：Windows XP デフォルトのLunaインターフェース。出典：Wikipedia
**現場のシステムエンジニアたちは、純粋な数学的理論に盲従することはない。物理的な上限として100枚という境界線を設けたのは、万が一直下に100万件もの画像が配置されていた場合でも、起動プロセスが決してハングアップしないようにするためだった。**数学モデルは無限の母集団に対する完全な一様分布を要求するが、産業用コードが背負う最大の使命は「絶対にシステムを落とさないこと」なのだ。
偶然という幻想の裏に隠された精密な計算
Twitterでの素朴な疑問に話を戻そう。2001年から2014年にかけて、数え切れないほどの人々がWindows XPを初めて起動する瞬間の高揚感を味わった。画面に現れたサッカーボール、アヒル、あるいはアマガエルを見て、誰もがOSからの気まぐれなサプライズだと信じていた。起動プロセスのミリ秒単位の揺らぎなど、人間の感覚で知覚できるはずもない。わずか数千分の一秒の微細なブレが、人々の目には完全な偶然として映っていたのだ。
Raymond Chen氏の記事は、長年の疑問を氷解させただけでなく、往時のソフトウェアエンジニアリングの姿を鮮やかに今に伝えるタイムカプセルでもあった。メモリは乏しく、ディスクは遅かったあの時代、1行のコードにも徹底的なコスト意識が求められ、あらゆるエッジケースに堅牢な防御的プログラミングが施されていた。
25年前に割り当てられたあの初期画像は、決して闇雲に引かれたくじ引きなどではなかった。厳密なファイル境界と洗練されたサンプリングロジックによって、2世代にわたるユーザーへと届けられた、極めて精密な計算の結晶だったのである。
参考リンク：
- The Old New Thing
- HN
- Wikipedia
