ハクソク

世界を動かす技術を、日本語で。

クラウドを構築しています

2026年4月23日原文(crawshaw.io)

概要

  • exe.devを立ち上げた個人的な動機についての説明
  • 現在のクラウドサービスへの不満と課題の指摘
  • 新しいクラウドの理想像とその実現方法の提案
  • exe.devが解決を目指す技術的問題点の具体例
  • 今後の展望と読者へのメッセージ

exe.devを作る理由

  • 既存クラウドサービス への根本的な不満

    • 個々のVMごとの制約
    • ディスクI/Oやネットワークコストの不合理
    • APIや抽象化の複雑さ、使いにくさ

  • 「コンピュータが好き」 という純粋な動機

    • 小型マイコンからサーバーまで、あらゆるコンピュータを楽しむ姿勢
    • しかし、現代クラウドには「好き」になれない違和感

  • クラウド抽象化の「形の悪さ」

    • VMがCPU/メモリに紐付いている仕組みの非効率
    • 本来なら、好きなだけVMを走らせたいという理想
    • 現状ではgVisorやネスト仮想化などで無理やり実現、オーバーヘッドや管理コスト増

  • PaaSやKubernetesの限界

    • 各クラウドごとに異なる抽象化で学習コスト増
    • 途中で発覚する仕様制限やパフォーマンス問題
    • Kubernetesは「本質的な問題解決ではなく、上塗り」に過ぎないという認識

  • ストレージとネットワークの問題

    • SSD時代なのにリモートブロックデバイスのI/O性能が極端に低い
    • ネットワーク出口コストが高騰、ベンダーロックインが進行
    • 真に使いやすいクラウドを求める声

  • これまでのクラウド利用の“我慢”からの脱却

    • 15年以上続く「仕方なく使う」状況
    • しかし、今こそ「直すべき時」だと確信

新しいクラウドの必要性とエージェントの登場

  • AIエージェントの普及が転機

    • コーディングの容易化でソフトウェア量が激増
    • 個人や小規模チームが「自分専用の実行環境」を必要とする時代
    • Jevonsパラドックス的に、使いやすいクラウドの需要が拡大

  • 従来クラウド抽象化の限界

    • エージェントも従来クラウドの制約には苦戦
    • APIや設計上の制約が、エージェントの利便性を阻害

exe.devが目指すものと実現方法

  • 資源単位での提供

    • VM単位ではなく、CPU・メモリ単位でリソースを提供
    • ユーザー自身が好きなだけVMを起動可能

  • セキュリティと利便性の両立

    • TLSプロキシ・認証プロキシを標準装備
    • 新規VMが直接インターネットに晒されない設計

  • 高性能なストレージとグローバル展開

    • ローカルNVMeストレージ＋非同期レプリケーション
    • 世界各地にリージョンを設置、Anycastネットワークで低遅延化

  • 今後の開発予定

    • 静的IPや自動スナップショットなどの機能強化
    • データセンターでの物理サーバー設置からネットワーク設計まで再構築

  • 「自分が本当に使いたいクラウド」の実現

    • 自分自身がワクワクするクラウドサービスの構築
    • その価値を多くの人に届けたいという思い

まとめとメッセージ

  • exe.devは「好き」になれるクラウド を目指す
    • 技術者としての純粋な情熱
    • 既存クラウドの不満を根本から解決する挑戦
    • 皆さんにとっても役立つサービスとなることを願う

Hackerたちの意見

すごい背景ですね。OPはTailscaleの共同創業者の一人なんですね。

伝統的なクラウド1.0の企業は、デフォルトで3000 IOPSのVMを売ってるけど、あなたのノートPCは500k持ってる。デフォルトを正しく設定すること（そしてそのコストを正しくすること）は、スタック全体を慎重に考える必要がある。彼らにたくさんの幸運を祈るよ！ビジョンを尊敬してるし、確実にターゲット顧客なんだけど、いつも通りの道を辿るんじゃないかと心配してる。素晴らしい理想から始まっても、成功が増すにつれて利益も必要になるからね。クラウドベンダーの価格設定は、しばしばコストに基づいていない。損失を出しているサービスもあれば、利益を大きく得ているサービスもある。これらは慎重に選ばれていることが多い。顧客がしっかりコミットしたときにのみコストが上がるタイプのもの—帯域幅、NATゲートウェイなど。でも、OPはこれを知っていると思う。

└

多くのクラウドベンダーは、IOPSや帯域幅に対して高い料金を請求してくる。 編集: これを読む前に投稿したけど、彼が指摘している2つは同じだね。

└

ちょっと気になったから、実際にテストしてみた。fioを使って、Hetzner（cx23, 2vCPU, 4 GB）で ~3900 IOPS（読み書き）で、平均レイテンシは ~2.1 ms、99.9パーセンタイルは ~5 ms、最大は ~7 ms。DigitalOcean（SFO1 / 2 GB RAM / 30 GB Disk）も ~3900 IOPS（同じ！）で、平均レイテンシは ~2.1 ms（同じ！）、99.9パーセンタイルは ~18 ms、最大は ~85 ms（！！）。シーケンシャルなddを使った場合、Hetznerは1.9 GB/s、DOは850 MB/s。どちらも低価格プランだけど、Hetznerは4ユーロで、DOのインスタンスは$18だよ。

└

クラウドベンダーの価格設定は、しばしばコストに基づいていない。ビジネス101では、価格設定はコストに基づいていないと教えられる。トップダウンとボトムアップの価格設定と呼んでもいいけど、基本的な原則として「ウィジェットを作るのに$Xかかるから、1.y * $Xで製品を$Yで売る」というのは、実際の価格設定の仕組みではないんだ。

└

3000 IOPS もしそれが本当なら、クラウドプロバイダーがユーザーをS3みたいな独自のクラウドストレージを使ったマイクロサービスアーキテクチャに押し込むための意図的な決定なのかなって思う。そうすると、シンプルなサーバーでもオンマシンDBができなくなるし。

すごい資金調達だね、おめでとう！私はDropboxのコメント担当者だってことが分かるよ。自分でexeが提供するものを持っていて、これらの抽象化が他の人にどれだけの価値を提供しているかに驚いてる！自分のハードウェアで一回限りのコンテナを立ち上げたり、下げたり、非同期エージェントを動かしたり、Tailscaleの認証を使ったり、チームが名前で簡単に共有したり接続したりできるんだ。

└

投資は人間関係や未来のビジョン、チームへの信頼、そして有料顧客の数といった成長指標によって行われるんだ。今の技術自体はあまり価値がないね。

私はただHetznerを使ってるだけ。クラウド企業が提供するものは本当に高すぎる。自分のPostgresをHAセットアップとバックアップで運用してるけど、これがRDSやCloudSQLのサービスの10分の1の価格で、10年間ダウンタイムなしで運用できてる。グラファナから収集したメトリクスを使ってインスタンスを自動スケールしてるし、私たちには問題なく動いてる。Webhookでオートスケーラーを設定してるから、すごくシンプルで、今まで失敗したこともない。もうGCPやAWSを使う理由が分からない。私のサービスはすべて完全にHAで、バックアップも毎日ちゃんと動いてる。

└

企業がクラウドサービスを利用するのは、社内サーバーの管理や運用を減らしたいからだよね。彼らにとっては、適切な人材を雇うのとトレードオフなんだ。でも、あなたが言う通り、適切な人を見つけられれば、自分でやる方がずっと安く済むこともあるよね。

└

同意するよ。昔は自分のソフトウェアにHerokuやRenderスタイルのプラットフォームを使ってたけど、今はただLinuxサーバーにDocker ComposeとCronジョブを使ってる。Cronジョブは毎分docker pull（最新のイメージをダウンロード）とdocker up -d（新しいバージョンがあれば切り替え）を実行してる。HTTPSのためにCaddyを前に置いてる。これが何年も安くて信頼できるんだ。

└

正直、ヘッツナーはすごく好きなんだけど、最近はかなり不安定なんだよね。https://status.hetzner.com/ このページでは、いつも同時にいくつかのインシデントが発生してる。彼らのサービスには感謝してるけど、もう少し安定してほしいな。

└

最近は、ベアメタルサーバーにSSHで接続して、ClaudeにPostgresを設定してもらうだけで済むんだ。仕事はこれで終わり。最初から5倍速いサーバーを使えるから、オートスケーリングなんて必要ないよ。

Hacker Newsで議論の続きを見る