2026/04/23 13:44
雲を作っています。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
このテキストの主なメッセージは、従来の非効率的なモデルを上回る柔軟性と直接的なハードウェア制御を実現するため、新たなクラウドインフラストラクチャプラットフォーム exe.dev をローンチするものです。著者は、現行のクラウドオファーリングが本質的に欠陥を持つと主張しており、開発者を必要とする特定の CPU、メモリ、またはストレージコンポーネントを個別に購入することを可能にするのではなく、硬固なリソースバンドルに追い詰めてしまうからです。この非効率性は、特にリモートブロックデバイスにおいてローカル代替案（例：標準的な MacBook の NVMe と対比するクラウド SSD）に比べて入出力速度が劇的に低下することにより、高いコストとパフォーマンスのペナルティを生み出しています。
既存のシステムもまた、プロジェクトを破綻させるベンダー固有の制限や不透明なプラットフォーム制約に苦しんでおり、Kubernetes のような解決策は往々にして構造的なインフラストラクチャの問題を解決するのではなく、単なる不完全な回避策に過ぎません。これらを修正するために、exe.dev は高価なオーバーヘッドや高額なデータエグレス料なしでユーザーが生ハードウェアをプロビジョニングすることを可能にしています。ネイティブアーキテクチャを提供することで、このプロジェクトは AI エージェントによる過剰なトークン消費を解決し、企業が常時新しい制限的なベンダー要件に適応するという循環から脱出することを支援します。最終的には、業界を高効率コンピューティングの真のニーズへと転換することを目指しています。
本文
クラウドの構築に取り組んでいます。
2026 年 4 月 22 日
本日、資金調達のお知らせを発信します。より広いオーディエンスを相手に文章を書くという性質上、これは当然ながら正式で慎重な発表です。そうあるべきなのです。規模が増大するにつれ、文章は必然的に個人的な色彩を排さざるを得ません。しかしながら、私はなぜこのようにしているのか、その内面から少しだけ率直に記述してみたいと思います。
exe.dev を構築することの目標は何でしょうか？既に私が共同創設者となるスタートアップがあり、それは非常にうまく機能しており、私が当初携わり設計・構築に深く関わった製品そのものほど、今も愛しています。
いったい何があったのでしょうか。私がまた新たな会社を立ち上げ、すべての苦痛を味わうことを選んだ理由とは。他の創始者の方々は、私が再び「フライパン」に戻ってしまいそうであることを不信と驚きで見ています。（さらに言えば、経験を踏まえると、まだ直面しなければならない苦痛が山積していることに気づくのが早すぎるかもしれません。）真面目に考えると、答えを出すのは難しい問いです。「大きな理由」、あるいは原理、社会的必要性、または単なる挑発を超えた動機などを探し求めるからです。しかし、私が信じるには、その真相ははるかにシンプルであり、少なくとも一部の人は驚くほど単純なのです。
私はコンピューターが好きです。
いくつかの技術コミュニティでは、そんな発言は異様に受け取られるかもしれません。（「この家では、コンピューターを呪うぞ！」という気もします。）確かに、コンピューターは非常にイライラさせられます。でも私はコンピューターが大好きで、ずっとそうでした。コンピューターにさまざまなことをさせることは本当におもしろいです。苦しい面もありますが、その結果は十分に報われます。マイクロコントローラーからデスクトップ、スマートフォン、そして世界中のデータセンターに設置されたサーバーまで、あらゆる種類のハードウェアが我喜欢です。
だからこそ、私が「現在のクラウドを好きではない」と認めるのは大きな決断となります。
本来、コンピューターが好きなのです。BSD を PC に直接インストールしたり、Linux VM を利用したりすること自体は素晴らしいものです。Windows や BeOS、Novell NetWare も楽しめました。かつて OS/2 Warp を導入し、それを使い込んだ思い出も輝かしいものです。今日の Linux は特に強力であり、無限の可能性を秘めています。製品が数ページにも及ぶクラウド環境であればあるほど、それは単に「Linux VM の集合体」に過ぎません。しかもそれらは API 駆動型です。もし私がそうなら天国にいるはずです。
しかし、試してみたすべてのクラウド製品は失敗しています。一部には優れたものもありますが、クラウドベンダーが下ろす選択によって、常に制約されており、自分のやりたいことをコンピューターに実現するのが困難です。
これらの問題はユーザートラセや不良な API 設計だけでなく、現代のクラウドの基本的な構成要素自体が誤った形状をしていることに起因しています。VM が問題なのは、CPU やメモリのリソースに縛りされているからです。私は自分で CPU、メモリ、ディスクを購入して、その上で VM を動かしたいのです。Linux VM は別の Linux の cgroup で実行されるプロセスなので、既存のコンピューター上で好きなだけ起動可能になるはずです。それを今日のアプライドクラウド環境でするとするには、隔離を自ら担う必要があります（gVisor やネスト型仮想化による単一クラウド VM での実装など）が、これにはネスティングによるパフォーマンス劣化が伴います。結果として、私の VM に向けてリバースプロキシを実行・管理せざるを得なくなるのです。すべては「クラウドの抽象化」の形状が誤っていたからです。
クラウド側では、「PaaS（プラットフォーム即サービス）」システムでこれを解決しようとしています。しかしそれはコンピューターより本質的に能力を制限された抽象化であり、特定のベンダーに特化しています。各計算ベンダーごとに新しいソフトウェア開発手法を学び、プロジェクトの半分近くが進む段階で「普通には簡単だったことが、ある奥深く埋もれたプラットフォーム固有の限界によってほぼ不可能になってしまう」という事態が発生します。「これが唯一の選択肢だ」と思った瞬間、必ずといってよいほど不完全な抽象化によって裏切られます。ノー・サンクスです。
次にストレージの問題。クラウドベンダーは、リモートブロックデバイス（あるいはさらに制限され、遅い S3 などのもの）を使うように促します。当初、リモートブロックデバイスの導入は、ハードドライブがコンピュータで使われていたことから意味がありましたが、良いバッファリング実装があれば、シーケンシャルな読み書きのパフォーマンスには害はありませんでした。ハードドライブのランダムシーク時間は約 10ms なので、イーサネット経由のリモートストレージ接続での往復遅延（RTT）が 1ms でも許容可能なコストです。これはハードドライブ向けに優れた製品であり、クラウドベンダーの標準インスタンスタイプから「ディスクサイズ」という次元を完全に除去する点で、ベンダーの業務を大幅に軽減します。
しかしその後、我々はすべて SSD に切り替えました。シーク時間は 10 ミリ秒から 20 マイクロ秒へ劇的に改善されました。優秀なリモートブロックシステムにおけるネットワーク RTT を Heroic な努力により少しだけ削減しましたが、リモートシステムの IOPS オーバーヘッドは HDD の場合の 10% から SSD では 10 倍以上に跳ね上がりました。EC2 VM に 20 万 IOPS を設定するのは非常に手間がかかり、その特権のために月額 1 万円を支払わなければなりません。私の MacBook では 50 万 IOPS が標準です。なぜクラウドインフラを低速なディスクで制限しているのでしょうか。
最後にネットワークの問題。ハイパースケール企業は優れたネットワークを持っていますが、それを地球の代償に使い、他のベンダーとの取引を極めて困難にしています。クラウドプロバイダーから GB を転送する際の標準単価は、通常のデータセンターでサーバーをラックする場合の 10 倍です。中程度のボリュームになると、その倍率はさらに悪化します。確かに月間 XX メンション規模の支出があれば料金は大幅に良くなりますが、私の多くのプロジェクトは「XX メンション」というレベルであり、その m が付かないのです。根本技術自体は優秀ですが、ここに限界が設けられ、あなたが構築するものが絶対に安価になりえないようになっています。
さらにクラウド API は痛いです。Kubernetes などのプロジェクトが登場し、エンジニアの苦痛を少し緩和するための「痛み紙」を提供しています。しかし VM を Kubernetes で扱うのは困難で、クラウドはあなたにネスト型仮想化を用いてすべて手作業で行わせないためです。ディスクも同様で、Kubernetes が設計された当時、Google は実際に使いやすそうなリモートブロックデバイスを提供しておらず、今日でもクラウド間で共通パターンを適用して「痛み紙」を貼っても、遅いままです。ネットワークについても同様で、もし簡単にできれば、隣接するオープンなデータセンターからのプライベートリンクで数つのシステムだけを接続し、クラウド支出のゼロ桁を削減できるはずです。Kubernetes を不正行為だとか、本物の製品開発を避けるための artificial make-work と見なそうとする誘惑はありますが、実情はもっと深刻です：それは「クラウドを移植可能かつ使いやすいようにする」という不可能な問題を解決しようとする製品なのです。達成不可能です。
抽象的な問題には新たな抽象化の上に重ねるだけでは解決できません。Kubernetes を良くしようとするのは本質的に不可能であり、（確かに高品質の）チークを豚に塗るような行為です。
私たちはこれら Miserable なクラウド環境で 15 年間苦しく生きてきました。ソフトウェアスタックの不愉快な部分に対処する際にも同様ですが、鼻をくしゃみして耐え、できるだけ頻度を減らそうとしてきましたが、今回はこれを解決する時です。
なぜなら何かが変わったからです：エージェントが登場しました。（実際には、共同創設者のジョシュと共に LLM をプログラミングに活用したいと考えて tinkering し始めたところ、LLM が必要なのはより良い伝統的な抽象化であることが分かりました。）エージェントはコードを書くことを最も容易にしてくれるため、ソフトウェアの量は増え続けるでしょう。経済学者はこれを「ジェボンスのパラドックス」と呼ぶでしょう。私たち每一个人が趣味や仕事のためにより多くのプログラムを書くようになるからです。私たちはそれらを独自に実行し、友人や同僚と簡単に共有でき、最小限のオーバーヘッドを持つプライベートな場所を必要としています。
私達の生活におけるソフトウェアの総量が増えるにつれ、これまでイライラさせた痛みに過ぎなかったクラウドは、はるかに大きな痛みとなります。我々は多くのコンピューティングパワーを必要とし、管理もしやすくなりたいのです。エージェントもそれを一部助けてくれます。あなたの認証情報を任せておけば、AWS API をあなたのために駆動してくれるでしょう（ただし時折、本番 DB を削除してしまうことも）。しかしエージェントも、抽象化の根本的な限界と我々が直面する課題に苦戦します。思考のために使われるコンテキストウィンドウの百分率ほど多く必要となり、問題解決のために使えるはずのコンテキストではなく、クラウドを無理に機能させるために使われてしまいます。
なので、私たちはこれを修正します。本日 exe.dev でリリースしたものは、VM リソースの隔離問題を解決しています：個別の VM をプロビジョニングする代わりに、CPU とメモリのリソースを取得し、望む VM を実行できます。TLS プロキシと認証プロキシは私が新しい VM をそのままインターネット上に公開したくないので用意しました。ディスクはローカルの NVMe であり、ブロックが非同期でマシン外に複製されます。全世界にリージョンを用意し、ユーザーは近くで機械を動かしたいからです。また、すべてのグローバルユーザーに対して低遅延のエントリーポイントを提供するために、any_cast ネットワークを採用しています（これによりすぐにいくつかの新しいワクワクする機能を開発できます）。
ここで構築すべきことはまだ多くあります。静的 IP アドレスのような明らかなものから、自動的な履歴ディスクスナップショットへのアクセス方法を与えるといった UX 上の課題まで含まれます。これらもすべて実装していきます。同時に、私たちは最初に戻り、データセンターでコンピューターをラックし、ソフトウェアスタックの每一層を再考し、ネットワーク接続のあらゆる選択肢を探求するつもりです。
ですから、私はクラウドを作っています。本当に自分が使いたいようなクラウドです。それが皆様にも有用であることを願っております。