Bryan CantrillとSteve TuckのOxide、on-premをpublic cloudの体験へ戻す

Bryan CantrillとSteve Tuckは、Oxideを「自社サーバー版のpublic cloud」としてではなく、rack-scale computerとして立ち上げた。

Steve Tuckは製品を「A product that allows the rest of the market that runs on-premises IT access to cloud computing」と表現している。出典

冒頭：cloudの体験を所有する

Oxideの出発点は、cloudの操作感とon-premisesの所有権を対立させないことだった。

公式homepageも「On-prem that feels like the public cloud」と掲げ、rack、CLI、API、Consoleを一つの体験として見せている。出典

創業：halfではなく全体を作る

Bryan CantrillとSteve Tuckは、hardwareだけ、あるいはsoftwareだけでは顧客体験を制御できないと考えた。

Steve Tuckの言葉では「You can't control that experience when you only do half the equation」だった。出典

転機・苦労：minimum viable productが大きい

この構想は、通常のSaaSのように小さく始めにくい。

公式show notesには、hardwareを作り、hypervisorを整え、control planeと運用を成立させる難しさが「The minimum viable product is really, really big」と記録されている。出典

2023年7月には最初のOxide rackを出荷した。

顧客がrackを搬入し、電源とnetworkingを与えれば、その日のうちにpublic cloudに似たsoftware experienceへ進めることを目指した。出典

成長・成功：説明と資本を積み上げる

Oxideは技術だけを公開したのではない。

Oxide and Friendsで製品、製造、運用、資金調達を語り、GitHubではcontrol plane、SDK、consoleなどの周辺を公開してきた。出典 出典

2025年8月にはSeries Bの1億ドル、2026年2月にはSeries Cの2億ドルを扱う公式show notesが公開された。

これは、rack-scale computerを成立させるための長い開発と製造を、資本面でも継続する転機だった。出典 出典

結び：所有権を含むcloud

Bryan Cantrillは「You bought the computer, it belongs to you」と語っている。出典

Oxideの物語は、cloudかon-premisesかの二択をやめ、操作体験はcloudのまま、計算機は顧客のものにするという再定義だ。

Oxideの顧客は、public cloudの弾力性は欲しいが、規制・security・latency・economics・データ所有の理由から自社設備を持つ企業だ。

公式show notesでBryan Cantrillはon-premisesのelastic infrastructureを「public cloudに閉じ込めるべきではない」と説明し、Steve Tuckは製品をrack-scale computerと定義している。出典

つまりOxideは、汎用serverを安く売る会社ではない。

hardware、hypervisor、control plane、API、consoleを一つの運用体験に束ね、cloudの操作感と自社所有を同時に満たす。

設備投資を許容できる顧客に絞るからこそ、一般的なIaaSとの正面衝突を避けられる。

参入障壁は、rack hardwareとcontrol planeを同時に設計するsystems knowledge、製造・保守の経験、そして運用データの蓄積にある。

OmicronはOxide Rackのcontrol plane、DropshotはRustからREST APIを公開する基盤、ProgenitorはOpenAPI client generatorとして公開されている。出典 出典

単なるロゴやAPIではなく、顧客の所有する計算機を一日以内に使える状態へ持っていく統合力が模倣しにくい。

強いnetwork effectが中心の事業ではない。

rackを導入する顧客が増えても、SNSのように利用者同士が直接価値を交換するわけではないからだ。

ただし、弱い間接効果はある。

公開されたRust repository、SDK、console、podcastが採用候補者・顧客・協力者を呼び、そこで得た知見が次のhardware/software改善へ戻る。

これはnetwork effectというより、透明なtechnical ecosystemの複利だ。出典

主な対象は、規制・data sovereignty・latency・コスト・予測可能性のために自社設備を持ちたい企業のCTO、platform team、SRE、研究機関だ。

public cloudのUIとAPIを求めるが、計算資源そのものは自社で所有したいチームに向く。

逆に、初期費用を抑えたい小規模チーム、従量課金だけを望む個人開発者、周辺managed serviceを大量に使う企業には適合しにくい。

第一は、hardwareとsoftwareを分離せず、rack全体を一つのproductとして設計したことだ。

公式show notesは「You can't control that experience when you only do half the equation」というSteve Tuckの説明を記録している。出典

第二は、透明性をdistributionに変えたこと。

Oxide and Friends、GitHubのcontrol plane、RFD関連の公開活動が、難しいhardwareを顧客と開発者が理解するための長い説明になっている。出典

最大のリスクは、顧客が大きな設備投資と運用変更を受け入れる必要があることだ。

公式show notesでも、購入前にtest driveを求める声や、install・logistics・support契約への質問が記録されている。出典

また、public cloudが持つ周辺サービスの広さを一社で再現するのは難しい。

Oxide自身も「minimum viable product is really, really big」と説明しており、hardware supply chain、firmware、hypervisor、control planeを同時に成熟させる複雑さが残る。出典

成長の核は、enterprise salesとfounder-led technical contentを組み合わせることだ。

Oxide and Friendsは2025年にSeries B、2026年にSeries Cを取り上げ、資金調達と製品の考え方を自社の声で説明している。出典 出典

このチャネルは大量のself-serve獲得には向かないが、rack-scaleの購買を検討する少数の技術責任者には効く。

代わりに、販売サイクル、導入支援、製造能力が成長の制約になる。

主要チャネル: founder-led content, Oxide and Friends podcast, open-source GitHub, enterprise sales, technical community

Oxideから学べるのは、顧客が欲しいものをsoftwareの機能一覧だけで定義しないことだ。

顧客が買うのはrack、control plane、support、所有権を含む一つの運用結果である。

二つ目は、難しい市場ほど説明そのものをproduct surfaceにすること。

Oxideはpodcastと公開repositoryを通じて、なぜon-premが必要なのか、なぜhardwareまで触るのかを繰り返し説明している。出典

日本で展開するなら、金融・製造・通信・研究機関のdata sovereigntyと低遅延を入口に、public cloudの代替ではなく「所有できるcloud experience」として売るのが現実的だと考える。

ただし、日本では導入後の保守網、電源・設置、既存SIerとの責任分界が購買条件になる。

技術説明だけでなく、国内のinstall・support・compliance運用をパッケージにしないと、rackの差別化が調達プロセスで消える。