決定性と再現性（ビルドと実行の再現可能性）

決定性と再現性は別物

まず2つの語を厳密に分けます。**決定性（determinism）**は「同じ入力に対して常に同じ出力を返す」という、関数・プログラムの性質です。**再現性（reproducibility）**は「ある実行や成果物を、後から別の時刻・別のマシンで同じものとして再生できる」という、運用上の達成です。決定的なプログラムは再現しやすいが、非決定的なプログラムでも非決定性の源を記録・固定すれば再現はできます。

非決定性の源は有限個に整理できます。実行時では時刻、乱数、並行スケジューリング、ハッシュ集合の反復順、メモリアドレス（ASLR）、浮動小数点の演算順序、未初期化メモリやデータ競合といった未定義動作。ビルド時ではタイムスタンプ、ファイル列挙順、絶対パス、並列化の非決定、埋め込まれる環境変数です。源を1つずつ潰すのが本質で、魔法はありません。

再現可能ビルド（reproducible builds）

再現可能ビルドとは、同一のソースと同一の宣言された環境から、常にビット単位で同一の成果物を生成する性質です。ハッシュが一致すれば、誰がいつどこでビルドしても同じ物だと数学的に確認できます。崩す犯人は決まっています。

実務の標準は SOURCE_DATE_EPOCH 環境変数です。これに Unix 時刻を入れておくと、対応ツールチェーンは __DATE__ 相当やアーカイブの mtime をその固定値に差し替えます。ファイル順は、glob の結果がファイルシステム依存で並ぶため、処理前に明示的にソートします。デバッグ情報の絶対パスは、コンパイラの prefix-map 機能（作業パスを定数文字列へ写像する）で消します。これらをすべて満たして初めて、2回のビルドのハッシュが一致します。

時刻・乱数・環境という外部入力

実行時非決定性の第一群は、プログラムが暗黙に読み込む隠れた入力です。現在時刻、乱数、環境変数、プロセスID、ホスト名はどれも実行ごとに変わります。これらを関数内部で直接呼ぶと、その関数は決定的でなくなり、テストもできません。

解決は依存性注入です。時刻なら「現在時刻を返すクロック」を引数として渡し、テストでは固定時刻を返す偽物に差し替えます。乱数なら、グローバルな乱数源ではなく明示的にシードした乱数生成器を持ち回します。擬似乱数は本来決定的な系列で、同じシードからは同じ列が出る（仕組みは擬似乱数生成器の内部を参照）ので、シードを記録すれば失敗を完全に再現できます。

# 非決定的: 内部で隠れた入力を読む
def make_token():
    return hash(time.now() + random())   # 毎回違う、テスト不能

# 決定的: 隠れた入力を引数へ持ち上げる（注入）
def make_token(clock, rng):
    return hash(clock.now() + rng.next()) # clock と rng を固定すれば再現可能

この「隠れた入力を引数へ持ち上げる」設計は、純粋関数化と同義です。副作用と外部依存を境界に押し出すほど、中核ロジックは決定的になり、テストの安定性が上がります。

並行・スケジューリングによる非決定性

第二群は並行実行です。スレッドの実行順序はOSスケジューラが決め、実行ごとに変わります。共有状態に対する読み書きの順序が変われば結果も変わり、データ競合があれば結果は未定義になります。ここで「同じ並行プログラムが毎回同じ結果」を保証するのは一般に不可能で、できるのは正しさ（線形化可能性など）を保つことと、テスト時に順序を制御することの2点です。

並行バグの再現は、スケジュールを操作して初めて可能になります。決定的スケジューラを差し込んで全インターリーブを系統的に探索する、競合をサニタイザで動的検出する、操作を記録して再生する（record/replay）といった手法を使います（具体的な技法は並行プログラムのテストで扱います）。要点は、並行性は「シードを固定すれば再現」とはいかず、スケジュール自体を制御対象に含める必要があることです。

暗黙の順序：ハッシュ反復とアドレス

見落としやすい非決定性が、コレクションの反復順です。多くのハッシュ集合・ハッシュマップは内部バケットの並びで反復し、その順序は実装・要素・場合によっては起動ごとのハッシュ種に依存します。for k in some_set の結果順をあてにしたコードは、環境が変われば壊れます。さらに一部言語は、ハッシュ衝突を突く攻撃を防ぐため起動ごとにハッシュ種をランダム化するので、同じ集合でも反復順が毎回変わります。

# 反復順に依存した出力は非決定的になりうる
for key in hashset:        # 順序は実装・ハッシュ種依存、保証されない
    emit(key)

# 決定化: 反復前に明示ソート、または順序保持コンテナを使う
for key in sorted(hashset):
    emit(key)

同様に、ポインタやオブジェクトの既定ハッシュがメモリアドレス由来だと、ASLR（アドレス空間配置のランダム化）で実行ごとに変わります。アドレスを順序や出力に混ぜないこと、出力直前に安定なキーで整列することが鉄則です。

浮動小数点の非結合性

最も厄介なのが浮動小数点です。実数の加算は結合則 (a+b)+c = a+(b+c) を満たしますが、浮動小数点加算は丸めのため結合則を満たしません。各演算後に最近接表現へ丸めるので、足す順序が変われば丸めの入り方が変わり、ビット単位で異なる結果になります（丸めの原理は浮動小数点数の内部）。

# 桁の大きく違う値で順序により結果が変わる例
(1e16 + -1e16) + 1.0   →  1.0    # 先に 1e16 同士が相殺し 0.0、そこへ 1.0 が残る
1e16 + (-1e16 + 1.0)   →  0.0    # -1e16+1.0 が 1e16 に丸められ 1.0 が消えてから相殺

この性質が再現性を直撃するのは並列リダクションです。総和を複数スレッドで部分和に分割して最後に合算すると、合算の結合のされ方がスレッド数や分割幅で変わり、実行構成ごとに結果のビットが変わります。GPUや自動ベクトル化、reduceの並列実装は速度のために順序を自由に組み替えるため、これが日常的に起きます。

制御の実務：注入・固定・記録

非決定性を制御する手順は、源ごとに同じ骨格を持ちます。(1) 隠れた入力を境界へ追い出し（注入可能にする）、(2) テスト・本番で値を固定（クロック・シード・スケジュール）、(3) 再現に必要な情報を記録（シードやスケジュールをログ・成果物に残す）。失敗時はその記録から同じ実行を再生します。

依存ライブラリのバージョンが揺れれば実装が変わり、反復順や演算順も変わりえます。ロックファイルで依存を固定する話は依存関係管理に属し、再現性の前提条件の1つです。

まとめ

決定性は性質、再現性は達成であり、両者は分けて考えます。実行時の非決定性は時刻・乱数・並行スケジューリング・ハッシュ反復順・アドレス・浮動小数点の演算順序・未定義動作という有限の源に分解でき、それぞれを境界への注入と値の固定で制御します。並行性だけはシード固定では足りず、スケジュール自体を制御・記録・再生する必要があります。浮動小数点加算が非結合であるため、並列リダクションは構成ごとにビットが変わり、ビット再現には演算順序の固定が要ります。ビルド側では時刻・ファイル順・絶対パスを正規化し、成果物のハッシュ一致という明快な基準で再現可能ビルドを検証します。源を1つずつ潰すこの規律が、フレーキーテストを消し、デバッグを「手元で再現する」状態へ引き戻し、配布物の信頼を支えます。