真の再現性はどこにあるのか——DockerとNixを「供給網の現実」で読み解く、実装と監査の要点です

今日の深掘りポイント

• 再現性は一枚板ではなく、環境・依存・ビルド手順・成果物・メタデータ（SBOM/プロベナンス）の層で評価する必要があるのが現実です。
• Dockerは「実行時の均質化」に長ける一方で、ビルド過程の決定論性は素のままでは担保されず、Base ImageのDigest固定やネットワーク遮断などの運用規律が要になります。
• Nixは依存関係とビルド入力を厳密に固定することで「ビルドの決定論性」に強みがあり、監査・再実行性の核として据えると相性が良いです。
• 供給網の信頼性を測るなら「同一アーティファクトを誰が、どこで、どう作ったか」を示すプロベナンスとSBOMの自動生成・伝搬が必須です。
• 結論は二者択一ではなく、Nixで決定論的に生成した成果物をOCIイメージへ落とし、Docker Build/Runtimeで配布・隔離・検査を回すハイブリッドが現実解です。

はじめに

ビルドの「完全再現性」は、もはや職人芸ではなく、監査可能性と供給網信頼性のコア要件になりました。地政学リスクや規制強化の波の中で、SLSAのような枠組みは「再現できたか」ではなく「再現できるとなぜ言えるか」を問います。DockerとNixはしばしば比較の俎上に載りますが、両者の射程は重なりつつも本質が違います。読者の現場に必要なのは、ツールの好悪ではなく「どの層の再現性をどの手段で、どの証跡で担保するか」の設計図です。本稿では、その骨格を提示します。

深掘り詳細

事実整理：両者が解く課題と、仕様・実装の手がかりです

• Docker/OCIの強み

  • 実行環境の均質化（カーネル共有を前提としたコンテナ分離）と、配布単位としてのOCIイメージの標準化が柱です。OCIイメージはコンテンツアドレス可能（Digest）で固定可能です［仕様の一次情報: Open Container Initiative Image Spec］です。
  • 近年のBuildKitは、ビルド時にSBOMとプロベナンス（in-toto/SLSA準拠）のアテステーションを生成・添付でき、供給網メタデータの自動化が進みました［Docker公式ドキュメント: Build Attestations］です。
  • ただし、多くのDockerfileはビルド時にパッケージレジストリへネットワークアクセス（例: apt-get update）を行い、時点やミラー差分で出力が揺れやすいです。Digest固定とミラーのスナップショット運用などを組み合わせないと「決定論的なビルド」にはなりにくいです。

• Nixの強み

  • Nixはパッケージや環境を「純粋関数的」にモデル化し、ビルド出力（/nix/store以下のパス）に依存・ビルド入力のハッシュを織り込む設計です。結果として、同一の入力集合から同一の出力を得やすく、環境の一貫性を機械的に再現できます［Nix公式マニュアル］です。
  • ネットワーク使用の制御、依存の厳密固定、ビルドプロセスの宣言的記述により、監査時に「なにが入力だったか」を説明しやすいです。
  • 一方で、学習コストや既存エコシステムとの接合（既存スキャナ、既存CI/CD、チームのスキル分布）が導入障壁になりやすいです。OCIイメージへの落とし込みは可能ですが、運用設計の重心が「ビルド」に寄る分、周辺の道具立てが必要になります。

• 規格・標準の観点

  • SLSAはレベルが上がるほど「プロベナンスの信頼性」「ビルドのHermetic性・再現性」を求めます。Dockerはアテステーション生成でメタデータ面を強化し、Nixは決定論的なビルド基盤として適合させやすい性質を持ちます［SLSA公式］です。

参照（一次・公式）

• OCI Image Spec（Digestによるコンテンツアドレス化）: https://github.com/opencontainers/image-spec
• Docker Build Attestations（SBOM/Provenance）: https://docs.docker.com/build/attestations/
• SLSA（Supply-chain Levels for Software Artifacts）: https://slsa.dev
• Nix Manual: https://nixos.org/manual/nix/stable/
• 背景記事（比較の俯瞰）: Docker versus Nix — The Quest for True Reproducibility | The New Stack

インサイト：再現性を「層」で設計し、役割分担で解決するのが近道です

• 再現性の5層モデルで考えると腑に落ちます。
  1. 実行環境の均質化（Runtime）、
  2. 依存の固定（Dependencies）、
  3. ビルド手順の決定論化（Build Steps）、
  4. 成果物の識別と配布（Artifacts/OCI）、
  5. 証跡（SBOM/Provenance/署名）です。
  • Dockerは1と4に強く、近年は5も機能が揃い、2・3は運用規律とレシピの書き方に依存しがちです。
  • Nixは2と3が中核で、1と4は別レイヤ（OCI化やランタイム）に委ねる設計が現実的です。5はビルド段階の完全性説明に寄与しますが、配布時のアテステーション生成・署名は別途パイプラインで担保するとよいです。
• 供給網の現実に沿うなら「Nixで決定論的にビルド → OCIへ落とす → Dockerで配布・実行 → BuildKitでSBOM/プロベナンスをアテスト → レジストリで署名検証・ポリシー適用」という直列構成が監査適合度と運用性のバランスが良いです。
• 監査可能性は「同一化」より「説明可能性」です。たとえビット単位の完全一致に届かない場面でも、入力・手順・環境を固定し、いつでも同条件で再実行可能、かつその証跡（SBOM/プロベナンス）を一緒に配布できれば、規制下の審査を抜けやすくなります。
• 仮説ですが、短期的に「Docker-onlyで徹底運用」するより、「Nixでビルドの決定論性を確保し、その出力をDockerの配布・検査の強みで覆う」ほうが、SLSA準拠やマルチ地域展開での審査コストが逓減しやすいはずです。これは審査資料の作成が「事後調査」から「ビルド時自動生成のメタデータ提出」に置き換わるためです。

運用と監査の観点：現場で滑るポイントと緩和策です

• よくある揺らぎの起点
  • latestタグのBase Image、タイムゾーン・ロケール、非決定的コンパイル（埋め込みビルド時刻や絶対パス）、ネットワーク越しの時点依存取得、並列コンパイルの非決定性です。
• 典型的な緩和
  • OCIイメージはDigest固定、ミラーはスナップショット基盤経由で取得、環境変数でロケール固定、ビルド時刻はSOURCE_DATE_EPOCHのような規律を採用、ネットワーク遮断ビルドまたは厳密検証付きの取得に限定、コンパイラフラグでパス埋め込みを正規化です。
  • Nixを導入する場合は、Binary Cacheの信頼モデルと鍵管理、社内キャッシュの運用（可用性・スケール）を先に設計するのが肝です。外部キャッシュ依存は審査時の説明責任が増します。

将来の影響と標準化の行方

• メタデータの国際標準化が進み、SBOM（SPDX/CycloneDX）とプロベナンス（in-toto/SLSA）が「納品物の必須添付書類」化していく流れが強まります。ここでDockerのアテステーション生成機能はデファクトのゲートになります。
• 一方で、ビルドの決定論性は「成果物の真正性」に直結し、複数地域・複数ベンダで同一成果物を再現する要件が増えるはずです。NixやBazelなど、Hermetic Buildを前提にする手法の存在感は相対的に増します。
• ハイブリッド化は進みます。企業は「ビルドはNix、配布とランタイムはDocker/OCI、検証はレジストリ＋クラスターのポリシーエンジン」という役割分担で、監査・運用・人材育成のバランスを取る動きが加速します。これにより、供給網の分断や地政学的なミラー障害にも強い体制を整えやすくなります。

セキュリティ担当者のアクション

• 自社の「再現性の定義」を明文化します。ビット単位一致か、機能同等か、再現期限（何年後まで）と再現時の証跡要件（SBOM/プロベナンス/署名）を決めます。
• Docker運用の最低限ルールを即日化します。
  • Base ImageはDigest固定、タグ禁止。
  • BuildKitを標準化し、ビルド時にSBOMとプロベナンスを常時生成・添付。
  • 依存取得はスナップショット化・ハッシュ検証前提にし、ビルド時ネットワークは原則遮断もしくは限定ホワイトリスト化。
• Nixの導入は「開発環境の統一」から小さく始めます。まずはDev環境とCIビルダーをNixで揃え、依存の固定と再実行性を体感させます。次に「Nixでビルド→OCI出力→レジストリへ」のパスを一本通します。
• 検証と封じ込めの二重化を設けます。レジストリ入庫時とクラスター入場時の双方で、署名・SBOM・プロベナンス検証を行い、逸脱を拒否します。
• 監査対応の運用基盤を用意します。ビルドログ、環境定義、SBOM/プロベナンスは成果物と同じ保管階層に紐づけ、検索・照会を自動化します。外部審査の質問票に即応できる形にまとめます。
• 依存キャッシュと鍵管理を設計します。NixのBinary CacheやDockerレジストリの可用性、署名鍵の保全・ローテーション・委任の運用を標準手順に落とし込みます。
• 成果の計測指標を設定します。環境再現に要する時間、ビルドの揺らぎ率、逸脱検知率、監査資料の作成工数などを四半期でウォッチし、投資効果を可視化します。

参考情報

• OCI Image Spec: https://github.com/opencontainers/image-spec
• Docker Build Attestations: https://docs.docker.com/build/attestations/
• SLSA（Supply-chain Levels for Software Artifacts）: https://slsa.dev
• Nix Manual: https://nixos.org/manual/nix/stable/
• 背景記事: Docker versus Nix — The Quest for True Reproducibility | The New Stack

最後に。ツール選定は議論が熱くなりがちですが、供給網の信頼は「どの層を、どの証跡で、どれだけ自動化できたか」の設計勝負です。DockerとNixはライバルではなく、再現性という山の別ルートです。組み合わせ方にこそ、貴社ならではの競争力が宿るはずです。