依存性が消えてもビルドを再現する - StableBuild が入力を安定させる仕組み

ある朝、出社すると自社プロダクトが動かなくなっている場面を想像してみてください。

コードは誰も変更していないのに、CI（継続的インテグレーション）が真っ赤になっています。昨日まではすべて正常に動作し、ビルドも通過していました。しかし今、チームが問題の原因を探している間も顧客は待たされており、経営陣からは「何があったのか」と説明を求められています。彼らにとっては誰の責任かは関係ありません。壊れたプロダクト、不満を抱くユーザ、そして失われるかもしれない収益だけです。

原因は、イメージが消えたことによる Dockerfile のビルド失敗、パッケージの削除、パブリックレジストリのレート制限（利用制限）、あるいは上流サーバーの応答停止かもしれません。

繰り返しになりますが、あなたのコードは何も変わっていません。

変わったのは、ビルドへの「入力要素」です。

現代のビルドは、Git リポジトリ内にあるもの以上に依存しているため、この違いは非常に重要です。ビルド処理では、チームの管理外にあるインフラから、Docker イメージ、OS パッケージ、Python パッケージ、バイナリ、アーカイブ、その他さまざまなファイルをダウンロードしています。

大抵の場合、それは完璧に機能します。

……ダメになる瞬間までは。

StableBuild は、まさにその領域のために存在します。

StableBuild は、あなたのビルドパイプラインと、Docker Hub、PyPI、Ubuntu、Debian、Alpine、外部ファイルの URL といった上流ソース（アップストリーム）との間に位置します。一度 StableBuild 経由でアーティファクト（依存ファイル）を取得すれば、そのアーティファクトは保存され、後からパブリックなインターネットに対して「昨日の環境を再現してほしい」と頼むことなく、まったく同じものを再取得できるようになります。例えば StableBuild の Docker ミラーは、変更不可能なプルスルーキャッシュ（pull-through cache）として機能し、パッケージミラーによって Python や OS のパッケージを過去の特定状態に固定することができます。

考え方は非常にシンプルです。

ビルドが変わるのは「あなたが変更を加えたとき」であるべきであり、「上流の誰かが勝手に変更したとき」であってはなりません。

これは、「再現可能なビルド（Reproducible Builds）」を実現する上で極めて重要な要素です。

コードを変更していないのにビルドが失敗した経験が一度でもあるなら、ここから先の話にもきっと心当たりがあるはずです。

再現可能なビルド（Reproducible Build）とは？

「再現可能なビルド」とは、簡単に言えば「同じソースコードとビルド入力から再度実行した際に、まったく同じ結果を生成できるビルド」のことです。

そして、それを実現するために最初に必要なのは、驚くほどシンプルです。

「同じ入力要素が、今も存在していること」です。

ここで1つ、重要な技術的補足があります。

依存関係を安定させるだけでは、すべてのビルドがバイト単位で完全に一致する（byte-for-byte reproducible）わけではありません。タイムスタンプ、コンパイラ、環境変数、ビルドパス、非決定的な動作をするツールなど、ビルドプロセスの他の要素も出力結果に影響を与えます。Debian が公開している再現可能なビルドに関するガイドラインでも、こうした非決定性の原因を多く扱っています。

StableBuild が解決するのは、さらに根本的な問題です。

そもそも『同じ外部入力』を今すぐ手に入れることができるか？

Docker イメージが消滅していたり、パッケージが削除されていたり、過去のビルドで使った URL が現在では別なファイルを返すようになっている場合、何かを再現するための安定した土台そのものが存在しないことになります。

StableBuild は、その土台が足元から崩れるのを防ぎます。

プルスルーキャッシュ（Pull-through Cache）とは？

プルスルーキャッシュとは、自社のビルドと上流のレジストリ／リポジトリの間に配置されるキャッシュです。

ビルドが初めてアーティファクトをリクエストした際、キャッシュは上流からそれらを取得してコピーを保存し、ビルド側に返します。

例えば、Dockerfile で以下のように参照しているとします。

python:3.12-slim

最初の要求時、StableBuild はイメージを取得します。一度 StableBuild を通過すると、そのイメージは保存され、イミュータブル（変更不可）として扱われます。これにより、その後のリクエストでは、上流のタグがその時点で何を指しているかに左右されることなく、常に同じコンテナを返すことができます。

ここが重要なポイントです。

「キャッシュ」と「不変の依存関係（Immutable Dependency）」は同義ではありません。

一般的なキャッシュは、一定時間が経つと期限切れになり、上流から再取得します。もし上流のアーティファクトが更新されていれば、キャッシュの中身も新しいバージョンに置き換わってしまいます。

StableBuild の目的は異なります。

一度取得したアーティファクトは、ビルドが元々使用していた依存関係として保持できます。

つまり、単に「ダウンロードの高速化」ではありません。

「上流の変更が、知らないうちに自分の変更になってしまうことを防ぐ」

この違いは、すべてのビルドがパブリックなソースに直接アクセスし続けた場合に何が起きるかを考えると、重要性が明白になります。

なぜ Docker Hub や PyPI、パブリック OS ミラーから直接取得してはいけないのか？

パブリックリポジトリは「配信インフラ」としては優秀ですが、あなたのビルド環境の「永久的な履歴記録」として作られているわけではないからです。

これが原因でトラブルが起きる典型的なケースが4つあります。

1. 依存関係が消える

イメージは非推奨になり、パッケージのバージョンは削除され、リポジトリは閉鎖され、ファイルは移動し、公開者が古いリリースを整理します。

これらには正当な理由がある場合もあります。

しかし、3年前に作成したプロダクションリリースには関係ありません。

そのリリースを再ビルドする必要があるとき、今手に入る最新のものではなく、「そのリリースが作られた当時に存在していた依存関係」が必要なのです。

2. 可変な参照（ミュータブルタグ）が変更される

バージョン名のように見えるタグであっても、必ずしも中身が変更不可であるとは限りません。

可変タグを参照している場合、公開者がタグの参照先を更新すると、誰も Dockerfile を触っていないのに異なるアーティファクトが読み込まれてしまいます。これこそが、過去のビルドのデバッグを困難にする非表示の現象です。

3. レート制限は「他人の運用方針」である

開発者がノート PC から数回イメージをプルする程度なら、レジストリの制限に気づかないかもしれません。

しかし CI 環境は異なります。

並列ジョブ、頻繁なビルド、一時的な（ephemeral）ランナーは、短時間で大量のリクエストを発生させます。その結果、レジストリ側が「今回のプル上限に達した」と判断し、正当なビルドが突然失敗し始めます。

コードに問題はなく、依存関係にも問題がないのに、ビルドが失敗するのです。

4. 上流の障害が「自社の障害」になる

ビルド時にパブリックレジストリを必須とする場合、そのレジストリの稼働率がそのまま自社のビルドパイプラインの稼働率に組み込まれることになります。上流がダウンすれば、復旧を待つしかありません。

これらの問題は、決して珍しいものではありません。だからこそ厄介なのです。

ソフトウェア自体には何も変更がないにもかかわらず、再ビルドに失敗する可能性があります。

もし1つでも心当たりがあるなら、次に気になるのは「StableBuild が実際に何を保存できるのか？」でしょう。

StableBuild が実際に保存・保護するもの

StableBuild は現在、主に4つの依存関係領域をカバーしています。

依存関係の領域	StableBuild が保存するもの	従来チームが頼りがちだった代替策
コンテナイメージ	Docker および OCI イメージ（変更不可能な状態で保存）	Docker Hub への直接接続、自前のプライベート Docker レジストリ、その他のレジストリプロキシ
OS パッケージ	過去の Ubuntu、Debian、Alpine パッケージ	ライブ状態の apt/apk リポジトリ、または自前で維持するミラー
Python パッケージ	過去の PyPI パッケージおよびその依存関係	パブリックな PyPI、または自前のパッケージプロキシ
外部ファイル	URL から取得されるファイル	curl、wget、リリースサーバー、任意の外部 URL

ビルドの該当部分の接続先を StableBuild に向けるだけで、通過した依存関係がキャプチャされます。

ワークフローを新しいビルドシステムに変える必要はありません。

pip や uv といったツールはカスタムパッケージインデックスをサポートしていますし、Docker ビルドはレジストリ URL を、apt や apk は代替リポジトリに対応しています。

StableBuild は、既存のワークフローに自然に組み込めるよう設計されています。

重要なのは、「チームのソフト開発やビルド方法を一から作り直す」ではなく、「ソフトウェアが依存しているものが、足元で勝手に変わらないようにすること」です。

これらの入力要素が固定されれば、次のプロセスもずっと容易になります。それは「リリースに実際何が含まれていたかを証明すること」です。

これは「SBOM」とどう関係するのか？

非常に深い関係があります。

SBOM（Software Bill of Materials：ソフトウェア部品表）とは、ソフトウェアに含まれる、あるいは関連する構成要素の一覧リストのことです。リリースの「構成要素の明細書」と考えるとわかりやすいでしょう。

これはセキュリティ、脆弱性管理、監査、ソフトウェアの出所（プロベナンス）確認において非常に有用です。しかし、「その依存関係が存在したことを知っていること」と、「そのソフトウェアを生成した『正確な依存関係』を今でも取得できること」の間には実用上の大きな違いがあります。

SBOM は「目録」であり、「タイムマシン」ではありません。

古いパッケージが消えたり、上流のアーティファクトが変更されたりした場合、SBOM を見れば「何が含まれるべきだったか」は分かりますが、当時の元の入力が入手できなければ、そのリリースを再現して調査することは難しくなります。

StableBuild 自体は、SBOM の生成や検証を行うものではありません。その役割はさらに上流（インフラ層）にあります。

ビルドが依存していた外部依存関係を保存することで、後からそれらのアーティファクトを利用可能な状態に保ちます。

これにより、エンジニアリングチームやセキュリティチームが以下のような質問に答える際の強固な土台となります。

• このリリースには「具体的に」何が入っていたのか？
• それらの構成要素を「今日でも」取得できるか？
• それを作成した環境を「再現」できるか？
• 脆弱性のある依存関係が含まれている過去のリリースはどれか？
• 依存関係の半分を置き換えることなく、影響を受けるバージョンを「再ビルド」できるか？

元の入力の一部が失われていれば、ビルドを意味ある形で再構築することはできません。

そして、この問いに答えることは、エンジニアリングチーム以外の第三者から説明を求められたとき、単なる「開発上の利便性」以上の意味を持つことになります。

EU サイバーレジリエンス法（CRA）にも関係するのか？

はい。ただし StableBuild 自体が単体でコンプライアンス適合を提供する製品というわけではありません。

EU サイバーレジリエンス法（Cyber Resilience Act: CRA）は、EU 域内で販売される「デジタル要素を含む製品」に対してサイバーセキュリティ上の義務を課す法律です。

なぜこれが重要なのでしょうか？ 自社が EU 圏内でソフトウェアや接続機能を持つデジタル製品を販売している場合、CRA によってサイバーセキュリティ、脆弱性報告、ドキュメント作成に関する法的な義務が生じるからです。

この規制は全般的に2027年12月11日から適用されますが、悪用されている脆弱性や深刻なインシデントに関する一部の報告義務は、それより早い2026年9月11日から適用開始されます。

これにより、コンポーネントの特定、脆弱性の取り扱い、ドキュメント化、ソフトウェアの出所確認は、抽象的なセキュリティ概念ではなく、日常的な運用上の課題となります。

影響を受けるリリースを調査する際、関与している依存関係のバージョンを把握することは大事です。そして、それらの依存関係を実際に取得できることはさらに重要です。

StableBuild は、ビルド入力を保存することでこのプロセスを支援します。ただし、製品を CRA に準拠させるものではなく、脆弱性管理、報告プロセス、セキュリティ管理、ドキュメント作成、法的助言に代わるものでもありません。

StableBuild が解決するのは、より限定されたインフラ上の問題です。

「調査や再ビルドに必要なアーティファクトが、今もそこにある状態をつくる」

これは当たり前のように思えますが、リリースから3年後に依存関係が消失したとき、それが決して「当たり前」ではなかったと実感することになります。

CRA はその重要性を示す一例ですが、再現可能なソフトウェアへのシフトは規制の枠を超えて広がっています。

「再現可能なビルド」はソフトウェアサプライチェーンの重要なトピックになりつつある

これは単に規制対応だけの話ではありません。

Debian プロジェクトは何年も前から再現可能なビルドを推進してきました。Debian 13 のリリースノートでは、バイト単位で再現可能なパッケージビルドに向けた大幅な進展が記載されており、インストール済みパッケージの再現性状態を確認する debian-repro-status のようなツールも導入されています。

これは、ソフトウェアサプライチェーンの扱い方における広範な意識の変化を反映しています。

もはや、単に「ソースコードはこちらです」と言えるだけでは不十分です。

チームに求められているのは、次の問いに答えられることです。

「どのソースから、どの依存関係の、どのバージョンを使って、どんなビルド環境で作成されたのか？そして、それを再現できるか？」

StableBuild はその方程式のすべてを解決するわけではありません。「依存関係の保持」という部分を解決します。

そして上流のインターネットが更新されても、プロダクション環境のソフトウェアがそのまま残っている場合、依存関係の保持は驚くほど重要になります。

プライベート Docker レジストリを自前で立てるべきか？

解決しようとしている問題によります。

独自の内部コンテナイメージを公開・管理したり、内部配信ワークフローを構築したり、広範なアーティファクト管理環境を制御したい場合は、プライベート Docker レジストリが正解となるでしょう。

StableBuild が解決するのは、より特定の問題です。

「ミラーインフラ全体を自分たちで運用することなく、外部のビルド依存関係を利用可能かつ変更不可（イミュータブル）に保つにはどうすればよいか？」

Docker に関して言えば、StableBuild は Docker Hub の「変更不可能なミラー」および「プルスルーキャッシュ」として機能します。Python や OS パッケージについては過去のミラーを保持し、URL から取得される任意のファイルも扱います。

したがって、実際の要件が「依存している Docker イメージやパッケージが消えたり変わったりするのを防ぎたいだけ」であるならば、そのためだけに別のインフラを構築・運用する必要はないかもしれません。

また、より広範なリポジトリ管理カテゴリを検討しているなら、Artifactory や Nexus といったツールも候補に挙がるでしょう。

Artifactory や Nexus との違いは？

すでに Artifactory や Nexus を正常に運用しており、チームが満足しているなら、そのまま使い続けてください。すでに問題を解決しているインフラからわざわざ移行する必要はありません。

リポジトリマネージャー（Artifactory や Nexus）は、組織がより広範なアーティファクト管理機能を必要としており、関連するインフラやワークフローを自前で運用できるリソースがある場合に適しています。

これらを使ったことがない方向けに説明すると、Artifactory や Nexus は、エンジニアリングチームがソフトウェアパッケージ、コンテナイメージ、その他のビルドアクティファクトを保存・プロキシ・整理・管理するための実績あるシステムであり、多くの大企業で採用されています。

違いは「それを運用し続けるために何が必要か」という点です。

要件が「外部依存関係を保存し、変更不可にし、依存関係の保持を『社内の新たなプラットフォームプロジェクト』にすることなくビルドを動かし続けること」という限定的なものである場合、StableBuild は魅力的な選択肢となります。

特に、「アーティファクトリポジトリの運用」を誰かの業務内容に追加したくない小〜中規模のエンジニアリングチームにとって非常に価値があります。

StableBuild はどのような人・チーム向けか？

特定のプロファイルだけに限定されるわけではありません。共通しているのは、「将来、同じソフトウェアを再びビルドできるようにすることを重視している」という点です。

具体的には以下のようなチームが対象となります。

• CI（継続的インテグレーション）を多用するチーム。 パブリックレジストリの制限、障害、依存関係の変更によってビルドが頻繁に落ちる場合、それらの入力をキャッシュして保存することで不安定さを排除できます。
• 小〜中規模のエンジニアリングチーム。 独自の依存関係インフラによる信頼性は欲しいが、レジストリクラスタや過去のパッケージミラー、複数のプロキシを自前で運用したくない場合。
• 長期運用されるソフトウェアを保守しているチーム。 今日存在する依存関係が、5年後にも存在するとは限りません。サポートサイクルが長いほど、過去の依存関係の利用可能性が極めて重要になります。
• 規制対象やセキュリティ要件が厳しい環境で働くチーム。 過去のリリースの内容を正確に把握する必要がある場合、保存された依存関係があれば再構築や調査が格段に容易になります。
• 古いソフトウェアを引き継いだデベロッパー。 問題は「今のアプリケーションをビルドすること」ではなく、「5年前のアプリケーションをなんとかビルドさせること」である場合があります。古いソフトウェアはエコシステムが進化してしまったことなど気にせず、それが作られた当時の世界をそのまま要求してきます。

よくある質問（FAQ）

Q. StableBuild は単なる「プルスルーキャッシュ」ですか？

いいえ、少し違います。

Docker に対してはプルスルーキャッシュの挙動を利用しますが、重要なのは「依存関係を取得した後に何が起きるか」です。アーティファクトは使い捨てのキャッシュデータとしてではなく、保存・保持されます。また、過去の OS や Python のパッケージリポジトリ、任意のビルドファイルもカバーするため、対応領域は Docker 単体よりも広範です。

Q. プライベート Docker レジストリの代わりになりますか？

場合によります。

目的が「自前でミラーインフラを運用せずにパブリックなコンテナ依存関係を保存すること」であれば、その目的専用のプライベート Docker レジストリを置き換えることができます。一方で、自社内部のイメージ管理、デプロイワークフロー、権限管理、アーティファクトの昇格管理などの用途でレジストリを使っている場合は、要件が異なります。

Q. StableBuild を使えば「再現可能なビルド」が保証されますか？

いいえ。

この区別は重要です。StableBuild は「依存関係の入力」を決定的（deterministic）かつ取得可能な状態に保つのを助けますが、ビルド内には依然として他の非決定的な要素が存在する可能性があります。StableBuild が防ぐのは、再現性の失敗における最も一般的な要因の1つである「外部依存関係の変更または消滅」です。

Q. StableBuild は SBOM を作成してくれますか？

現時点では作成しません。

現在 StableBuild は SBOM ソフトウェア部品表（Software Bill of Materials）の自動生成や検証は行っていません。今提供しているのは「ビルドの背後にある依存関係を保存し、後からの調査・再構築・セキュリティ検証を現実的にすること」です。

なお、ソース側で管理している依存関係から直接 SBOM を生成する機能は現在開発中です。既存の多くの SBOM ツールはビルド完了後の成果物をスキャンしますが、StableBuild のアプローチではビルドプロセスの中で既に把握・保存している依存関係情報を活用する予定です。

Q. 依存関係のアップデートができなくなりますか？

いいえ、いつでもアップデート可能です。

違いは、「いつ変更を適用するかを自分たちで決められる」という点です。新しい依存関係を取得し、テストし、アプリケーションを更新し、納得がいった段階で昇格させます。StableBuild はソフトウェアを永遠に凍結するためのものではなく、依存関係の変更を「事故」ではなく「意図的な選択」にするためのものです。

すでにトラブルが起きたビルドで試してみてください

StableBuild の有用性を理解するために、ビルドシステム全体を再設計する必要はありません。

• 依存関係の消失
• Docker Hub のレート制限
• パッケージの非公開化
• 外部ファイルのリンク切れ

などで過去に落ちたことのあるビルドを1つ選んでみてください。

その依存関係の参照先を StableBuild に向け、もう一度実行してみます。

StableBuild の Community プランは現在無料で提供されており、1 TB のトラフィックを含むリポジトリおよびミラーへのアクセスが可能です。新しいインフラ契約を結ぶことなく、ワークフローを試すことができます。

これが、このプロダクトの真の目的です。

ビルドが変わるかどうかを決めるのは、あなたの「コード」であるべきです。

削除されたパッケージ、可変なイメージタグ、レジストリのレート制限、切れた URL などに、その決定権を与えてはいけません。

過去に悩まされたビルドで、ぜひ一度試してみてください。

無料枠を使って依存関係をピン止めし、その違いを体感していただけます。