StableBuild が生まれた理由：本番環境のビルド障害から始まった事業

StableBuild の出発点は、事業のプレゼン資料ではありませんでした。

繰り返されるビルドの失敗でした。

Edge Impulse の創業チームは、本番環境で40以上のコンテナを運用していました。しかし数週間おきに、アプリケーションコードとはほとんど、あるいはまったく関係のない理由で、ビルドが失敗していました。

Docker のベースイメージが変わる。apt パッケージの配布場所が変わる。バージョンを固定していたにもかかわらず、Python の依存関係に変化が生じる。配布元から必要なファイルが消える。

厄介なのは、ビルドが失敗することだけではありません。いつ失敗するかも問題でした。

本番環境向けのビルドが失敗しても、「来週の木曜日に対応しよう」と予定を組めることはほとんどありません。ビルドできなければ、修正版を確実にリリースできないからです。

誰かが作業を中断し、依存関係のどこに変更があったのかを調べ、環境を更新し、再テストしなければなりません。その修正が、別の問題を引き起こさないかも確認する必要があります。

この対応には、昨日まで動いていたコードが、なぜ今日はビルドできないのかを調査・判断できる、経験豊富なエンジニアの力が求められます。

AI の活用によって調査や修正を効率化できる場合もあります。ただし、トークン使用量に応じた利用料に加え、エンジニアによるコードレビューや動作確認も必要です。AI を使っても、対応にかかる時間や人件費の負担がなくなるわけではありません。

この繰り返される問題が、StableBuild の生まれた理由です。

プロダクトより先に、解決すべき問題があった

Edge Impulse は、エッジデバイス上で機械学習を開発・展開するためのツールを提供する企業として、Jan Jongboom と Zach Shelby によって設立されました。その後、主要なエッジ AI プラットフォームへと成長し、2025年に Qualcomm の傘下に入りました。

しかし、規模のあるソフトウェアプラットフォームの多くがそうであるように、Edge Impulse にも、顧客が目にするプロダクトの裏側に課題がありました。自社のソフトウェアを、継続して再ビルドできる状態に保つ必要があったのです。

そのビルドは、チームが管理できない公開インフラに依存していました。Docker イメージ、OS のパッケージリポジトリ、Python パッケージ、URL から取得するファイル。どれも、ソフトウェア開発ではごく一般的な依存先です。

いずれかが変わるまでは、問題ありません。

ここに、現代のソフトウェア開発が抱える難しさがあります。Git リポジトリでバージョンを管理していても、ビルド環境の依存先は、Git の管理範囲を大きく超えていることが少なくありません。

Dockerfile を変えていない。ロックファイルも変えていない。アプリケーションコードも変えていない。それでも、今日ビルドしたものが、昨日ビルドしたものと異なる可能性があります。

これが、依存関係のドリフトです。

最悪の場合、依存関係は単に変化するだけではありません。取得できなくなります。

ビルドの失敗は、想像以上に広い範囲へ影響する

ビルドが失敗すると、まず CI がエラーを示します。しかし、実際の影響はそれだけではありません。

緊急のバグ修正をリリースする必要があるのに、コンテナを再ビルドできない。そうなると、依存関係の問題は、プロダクトの問題になります。

修正内容がセキュリティに関わるものであれば、セキュリティの問題にもなります。顧客が対応を待っていれば、事業上の問題にもなります。そして、修復できるほど構成を理解しているシニアエンジニアが一人か二人しかいなければ、組織の問題にもなります。

StableBuild のサービス開始時の記事でも、顧客が数週間おきにこうした障害に直面していることを紹介していました。対応には緊急性があり、経験豊富なエンジニアの関与を必要とすることが多い。さらに、依存関係の更新がシステムの別の部分に影響する可能性があるため、慎重なテストも必要になる。このパターンが繰り返されていました。

Jan Jongboom と Zach Shelby が解決したかったのは、この問題です。そのために、両氏は StableBuild を支援しました。

Edge Impulse は最初の顧客となり、すでに本番環境で運用していたコンテナ全体に StableBuild を導入しました。

この順序には意味があります。

StableBuild は、その問題の存在を市場に説明する前から、実際の本番環境で課題を解決していました。

スクリプトだけでは解決できないのか

エンジニアであれば、こう考えるかもしれません。

「それなら、自分たちでキャッシュすればいい」

実際に、多くの企業がそうしています。

社内に Docker ミラーを構築する。パッケージプロキシを運用する。リポジトリのスナップショットを取得する。重要なファイルを自社で管理するストレージにコピーする。プライベートレジストリを維持する。

いずれも有効な方法です。

問題は、何千もの開発チームが、実質的に同じインフラを個別に構築することになる点です。

誰かがホスティングし、監視し、パッチを適用しなければなりません。ストレージと通信の費用もかかります。そして障害が起きれば、仕組みを理解して対応できる人が必要です。

その時点で、社内の対処策は、もう一つの本番システムになっています。

この違いが、StableBuild を社内の技術的な解決策から、一つの事業へと発展させました。

各チームがキャッシュ、過去の状態を保持するミラー、プロキシ、保存の仕組みを個別に構築・運用する代わりに、StableBuild は共通の基盤を構築し、利用企業に提供します。各社が重複して負担していたホスティングや運用を、サービス全体で担う仕組みです。

利用者から見た変化は、決して派手ではありません。それも、このサービスの利点です。

Dockerfile は、これまでどおり Dockerfile です。pip も apt も、使い慣れたツールのままです。

StableBuild が変えるのは、これらのツールが依存関係を取得する場所と、昨日取得した依存関係を明日も取得できるかどうかです。

現在の基盤には、保存した内容が変わらない Docker のプルスルーキャッシュ、Python や OS パッケージの過去の状態を保持するミラー、任意のファイルや URL から取得した内容を変更されない形で保存するキャッシュが含まれています。

多くの開発チームがいずれ自ら構築することになる基盤を、自社で構築せずに利用できるようにしたもの。それが StableBuild です。

ビルドの再現性は、基本的な条件から始まる

再現可能なビルドを実現するには、さまざまな要素を考慮する必要があります。

コンパイラ、環境変数、タイムスタンプ。ビルド時のパスや、実行するたびに結果が変わり得るツールも影響します。

しかし、その前に確認すべき、もっと基本的なことがあります。

そのビルドが依存していたファイルを、今も取得できるでしょうか。

取得できなければ、ビルドの再現は大幅に難しくなります。

依存関係の参照先を記録していることと、その依存関係を手元に保持していることは、同じではありません。

たとえば、次のように指定しても、そのパッケージが永久に配布され続けるわけではありません。

package==1.4.2

Docker タグも、対応するイメージが永久にホストされ続けることを保証しません。

URL はアーカイブではありません。公開パッケージリポジトリは、自社の過去の開発環境を保存するための記録庫でもありません。

決定論的ビルド、つまり同じ入力から同じ結果を得られるビルドに向けて、StableBuild が取り組んでいるのは、この部分です。外部から取得するファイルを保存し、後から同じものを再び取得できるようにします。

これは仮定のリスクではない

めったに起きない問題に備えた対策のように聞こえるかもしれません。

しかし、最近の事例は、そうではないことを示しています。

2026年9月、Docker Hub から minio/minio と minio/mc のリポジトリが消えました。これらのイメージを参照していたプロジェクトでは、CI パイプラインの停止、結合テストの失敗、新規デプロイの起動失敗が相次いで報告されました。Readest、Apache Gravitino、Apache Sedona、Milvus でも、イメージを取得できなくなったことによる障害が記録されています。

これらのプロジェクトのコードが、突然不正なものになったわけではありません。配布元から必要なイメージを取得できるという前提が、成り立たなくなったのです。

NVIDIA にも、同じ問題の別の例があります。

CUDA コンテナのサポートポリシーでは、古いコンテナイメージが EOL を迎え、削除される場合があります。そのため、CUDA のタグを具体的に指定していても、イメージの配布が終了すれば、ビルドはできなくなる可能性があります。StableBuild は、NVIDIA CUDA のビルドに関するこの問題を、数年にわたって取り上げてきました。

ここで重要なのは、次の違いです。

バージョンの固定は「何を取得するか」を指定します。保存は「それを引き続き取得できる状態」を維持します。

適切に管理されたソフトウェアサプライチェーンには、その両方が必要です。

なぜ木本真理究が、この課題に取り組むのか

StableBuild の CEO で、フランス生まれ・東京出身の木本真理究（Mariku Kimoto）は、依存関係を、開発の裏側にある細かな要素ではなく、インフラとして捉えています。その考え方は、短い開発サイクルを超えて、長期間の信頼性が求められるシステムに携わってきた経験に根差しています。

木本の開発経験は、組み込みシステム、IoT、医療技術、インフラ、創業初期の企業にまで及びます。

StableBuild 以前には、医療系 IoT デバイスを開発するスタートアップ、サイマックスで、ハードウェアの設計・製造からファームウェア、クラウドソフトウェアまで、幅広い技術領域を担当しました。

その後、株式会社エピグノの創業チームに CTO として加わり、病院向けシステムの開発に加えて、顧客対応やチームの拡大にも携わりました。さらに、AI/IoT 通信プラットフォームを提供する SORACOM では、シニアエンジニアリングマネージャーとして複数のチームを統括し、社内制度や業務プロセスの整備に携わりました。在籍中には、同社が株式上場（IPO）を果たしました。

これらの仕事には、共通点があります。ソフトウェアが次週のリリースまで動けばよい、という環境ではないことです。

組み込み機器は、何年も使い続けられることがあります。医療システムは、外部の提供元がパッケージを削除したからといって、簡単に停止してよいものではありません。インフラを支えるソフトウェアも、最初のビルドを取り巻いていた技術環境が変わった後まで、保守を続ける必要があります。

こうした環境では、依存関係も、自分たちが責任を持つシステムの一部です。

木本は、学業でも技術分野を専門としてきました。École Centrale de Nantes と慶應義塾大学のダブルディグリー修士課程を修了した後、慶應義塾大学で博士号を取得。

その間も、スタートアップや開発の現場で働いていました。

ただし、StableBuild にとって重要なのは、学位や役職の一覧ではありません。その経験を通じて培われた、エンジニアとしての考え方です。

システムを動かし続ける必要があるなら、そのシステムが依存するものも管理できなければなりません。

同じ仕組みを各社で作り直すことが、コストを増やす

StableBuild は、共通の依存関係管理基盤と捉えることもできます。

100社のソフトウェア企業が、それぞれ過去の Docker イメージを確実に取得できるようにしたいと考えたとします。

各社がミラーを構築し、ストレージ費用を払い、キャッシュを設定し、監視する。保存の方針を決め、Docker 側に変更があれば対応する。

そして同じことを、Python パッケージでも行います。Debian や Ubuntu のパッケージでも、その他のファイルでも繰り返します。

技術的には、実現可能です。しかし、経済的には重複が生じています。業界全体で、100の開発チームが、ほぼ同じ役割を持つ100の基盤を維持するために費用を負担していることになるからです。

StableBuild のモデルは、この基盤を一つ構築し、共通で利用できるようにすることです。

信頼できるビルド基盤を必要とする規模には達している一方で、社内のイミュータブルな Docker ミラーの保守にエンジニアを割り当てると、本来のプロダクト開発に支障が出る。そうした企業にとって、特に有用な仕組みです。

StableBuild は、更新を止めるためのものではない

古い依存関係を保存することは、その依存関係をいつまでも安全で適切なものとして扱うことではありません。

セキュリティパッチは必要です。フレームワークは改善されます。古いコンテナも、いずれは置き換えなければなりません。

重要なのは、移行のタイミングを誰が決めるかです。

必要な依存関係を保持していなければ、配布元での削除によって、計画していた更新が緊急対応に変わる可能性があります。

以前の依存関係を引き続き取得できれば、チームは既知の環境を再構築し、変更点を把握し、移行先をテストしたうえで、計画的に移行できます。

その方が、健全な開発プロセスです。

ビルドの再現性を確保するのは、変更を避けるためではありません。自分たちの判断で変更できるようにするためです。

なぜ公開レジストリに、いつまでも依存してはいけないのか

公開レジストリは、永久保存を約束するためのものではないからです。

公開レジストリは、優れた配布の仕組みです。Docker Hub、PyPI、Ubuntu や Debian のリポジトリ、NVIDIA NGC は、いずれも非常に有用です。

問題は、システムの信頼性を考える際に、こうした公開配布サービスが、永久的なコンテナイメージの保持も担ってくれると、暗黙に想定してしまうことです。

配布と長期保存は、異なる役割です。

公開レジストリの提供者は、古いイメージを整理することがあります。パッケージのメンテナは、ファイルを削除することがあります。企業や組織が、別の配布方法へ移行することもあります。

自社の本番システムが5年前の環境に依存していても、その変更を止めることはできません。

より確実なのは、配布には上流のリポジトリを利用し、過去のビルドを再現するためには、自分たちが管理できる基盤を使うことです。

StableBuild は、そのための基盤を提供します。

販売する前に、本番環境で実証されていた

StableBuild が生まれた順序には、意味があります。

最初に新しい市場分野を考え、そこに課題を持つ顧客を探したわけではありません。

顧客が先に存在していました。本番環境で稼働するソフトウェアがあり、ビルドの失敗があり、それに対応する開発チームの負担がありました。

その後に、プロダクトが生まれました。

Edge Impulse が StableBuild の最初の顧客になったのは、創業チームが、この基盤で何を解決すべきかをすでに理解していたからです。解決策を必要としていた企業が、その解決策の有効性を確かめる役割も果たしました。

「開発チームには、こうした問題があるかもしれない」という仮説よりも、はるかに確かな出発点です。

その問題は、すでに起きていたのです。

よくある質問

自社でキャッシュを運用すればよいのではありませんか？

もちろん、それも選択肢です。組織によっては、自社運用が適している場合もあります。

ただし、キャッシュは自社で責任を持って管理する対象になります。ストレージ、稼働状況、有効期限の方針、パッチ適用、通信帯域、データの複製、保守まで、チームが担わなければなりません。

StableBuild は、こうした基盤を自ら運用するよりも、サービスとして利用したいチームのためにあります。

StableBuild は、Docker イメージをキャッシュするだけのサービスですか？

いいえ。Docker イメージのキャッシュは、機能の一部です。

StableBuild は、Python パッケージや Linux のパッケージリポジトリについて、過去の状態を保持するミラーも運用しています。また、ビルド中に取得する任意のファイルも保存できます。

共通する考え方は、現代のソフトウェアが依存するさまざまなシステムから、ビルドに必要なファイルを保持することです。

StableBuild を使えば、すべてのビルドの再現性が保証されますか？

いいえ。ビルドの再現性には、依存関係の保持以外の要素も関わります。

StableBuild が対処するのは、外部の依存関係が変化する、削除される、取得できなくなるといった、ビルド結果を不安定にする重要な要因です。

自社で使用するツールやビルド手順によって、別の理由で結果が変わることもあります。

ソフトウェアが古くなるほど、この問題が重要になるのはなぜですか？

最初のリリースから時間が経つほど、外部の環境が当時と同じままであるとは考えにくくなるからです。

リポジトリは変化します。メンテナが交代したり、活動を終えたりします。イメージは削除され、URL は使えなくなり、インフラは置き換えられます。

一方で、古いソフトウェアは、最初にビルドされたときの環境を前提としています。

ソフトウェアを保守し続ける期間が長いほど、過去の依存関係を引き続き取得できることの価値は高まります。

ビルド基盤は、意識せずに使えるものであるべき

StableBuild の理想は、開発者がその存在をあまり意識せずに済むことです。

必要なイメージがある。必要なパッケージがある。過去の環境でもビルドできる。そして、チームが更新したいときに更新できる。

それが、このサービスの目的です。

木本にとっても、Edge Impulse で最初にこの問題に直面したエンジニアたちにとっても、開発ツールをもう一つ増やすこと自体が目的だったわけではありません。

開発チームが、いつの間にか当たり前のこととして受け入れていた障害を減らすことが目的でした。

依存関係が変わる。ビルドが失敗する。シニアエンジニアの半日が対応に消える。チームが修復する。そして、また次の障害を待つ。

StableBuild は、この繰り返しを当たり前にする必要はないと考えています。

プロダクトチームが時間を使うべきなのは、プロダクトの開発です。その開発に必要な基盤を、何度も作り直すことではありません。

ソフトウェアを変更するのは、外部の配布元が先に変わったからではなく、自分たちが変更を決めたときであるべきです。