BuildとHerokuの比較
Herokuの手軽な開発体験はそのままに、現代のプロダクトチームに本当に必要な深さを備えています。
概要比較
概要
どちらのプラットフォームも、インフラを意識せずに開発できる点は共通しています。違いが表れるのは、アプリケーションが単純ではなくなったときに、その下に何があるかです。Herokuの抽象化は意図的に制約されており、高度な機能は従来エンタープライズプランに限定されてきました。Buildは同じ開発体験に、より深い制御を組み合わせます。Kubernetesへのアクセス、仮想マシン、マルチゾーンフェイルオーバー、セキュリティ機能は、いずれも標準搭載です。
Buildはフルスタッククラウドプラットフォームです。Herokuのようにハイパースケーラーのキャパシティを借りるのではなく、ハードウェアからランタイムまでを自社で所有・運用しています。この制御により、より優れたパフォーマンス、より高い安定性、そしてより低いコストをお客様に提供できます。
Herokuとは
Herokuは現代のPaaSを生み出した存在です。コードをつなぎ、プロセスを定義すれば、その下はすべてプラットフォームが引き受けます。このカテゴリの多くが今も踏襲している型を作りました。
その後、プラットフォームの進化はカテゴリ全体の動きより緩やかになりました。固定のリクエストタイムアウトと閉じたランタイムはそのままに、インフラへのアクセス、セキュリティ機能、ワークロードの柔軟性は他社で先へ進みました。開発体験は今も優れていますが、その上にある天井は動きませんでした。
Herokuはサステイニングエンジニアリングに移行しました
2026年2月、SalesforceはHerokuをサステイニングエンジニアリング体制に移行しました。セキュリティパッチ、安定性の維持、サポートは継続されますが、新機能の開発は停止し、エンタープライズアカウントの新規契約も販売されていません。
Herokuの強み
Heroku最大の強みは、その成熟度です。
マーケットプレイスは200以上のアドオンと7,800以上のBuildpackを擁してカテゴリを牽引しており、ドキュメントには長年の蓄積があり、その作法をすでに理解している開発者も数多くいます。
アプリケーションがHeroku固有の専門的なアドオンに強く依存している場合や、インフラの制御性よりエコシステムの成熟度を重視する場合は、Herokuの方が適している可能性があります。
Buildとの違い
同じ割り切り、ただし抜け道つき
どちらのプラットフォームも同じ取引をしています。デプロイ、ネットワーキング、実行環境の仕組みをプラットフォーム側が決めることで、チームがそれを考えずに済むようにする。お支払いいただいている価値の大半はここにあります。
違いは、ワークロードがその割り切りに収まらなくなったときに起こります。Herokuでは、抽象化の外に出る余地がほとんどありません。Buildには次の選択肢があります。
- 設定可能なアプリケーションの挙動
- ダイノと並べて動かせる仮想マシン
- 自身のKubernetesネームスペースへの直接アクセス
ほとんどの部分は抽象化の内側にとどまったまま、必要な1つのサービスだけ外に出る。プラットフォームを離れる必要はありません。
成長のたびに二重の負担を負うべきではありません
インフラへの要求が高まるのは、会社がうまくいっている証拠です。大口のお客様が現れ、より強力なアクセス制御を求める。セキュリティ部門が監査ログを要求する。トラフィックが伸びてマルチゾーンが必要になる。あるワークロードが標準の実行環境では収まらなくなる。
Herokuでは、この成長の局面で請求額と制約の両方が効いてきます。組織単位の管理機能、コンプライアンス機能、プライベートネットワーキングは、これまでチームをEnterpriseやShieldの製品へと押し上げてきました。
そして、Herokuがどのプランでも提供していない機能は、結局どこか別の場所で解決しなければなりません。
Baremetricsが成長するにつれて、Herokuを魅力的にしていた体験は次第に崩れていきました。チームはプラットフォームの制約に突き当たることや、コストが跳ね上がることを避けるためだけに、標準的でない回避策を持ち込むことになりました。
Buildはその成長の全体を前提に作られています。以下はすべて、最初のデプロイから標準プラットフォームの一部です。
- プライベートネットワーキング
- ロールベースのアクセス制御
- 監査ログ
- SOC 2認証
- Webアプリケーションファイアウォール
- SBOMの生成
- コンテナイメージのスキャン
- マルチゾーンのインフラ
始めたときのプラットフォームが、そのままスケールするときのプラットフォームです。成長によって変わるのは購入するキャパシティの量であって、使うことを許されるBuildのバージョンではありません。
Buildは今も開発が続いています
この違いは、2026年2月により大きな意味を持つようになりました。
Herokuのサポートは継続されますが、Salesforceは新機能の開発への投資を明確に停止しました。Buildは、現代的なアプリケーションのワークフローと新しく生まれる開発者のニーズに合わせて、プラットフォームの開発を続けています。
数年単位でプラットフォームを選ぶチームにとっては、両者が今できることと並んで、開発の方向性も判断材料になります。
料金
Herokuはダイノとアドオンをそれぞれ個別に課金します。Buildはコンピュート、アドオンクレジット、人数無制限のシート、そしてすべてのプラットフォーム機能を、ひとつの月額固定料金にまとめています。
一般的な小規模SaaSの本番構成で、BuildとHerokuを比較すると次のようになります。
1ダイノ時間は、Standard-1Xダイノを1時間動かした分です。より大きなサイズはその分だけ多く消費し、Performance-Mは1時間あたり8ダイノ時間を使用します。Herokuの価格は2026年9月時点の定価です。
35%以上低く、月あたり1,101ドル、年間で13,212ドルの削減になります。しかもBuild側にはまだ1,600ダイノ時間の余裕があります。
削減額はワークロードによって異なります。もしBuildの方が安くならなければ、請求書をお送りください。その金額を下回る価格をご提示します。
Herokuからの移行
HerokuのアプリケーションをBuildに取り込む作業は、直接連携により数分で完了します。
BuildをHerokuに接続すると、アプリケーションの構成と環境設定を自動的に取り込みます。その後、BuildとHerokuを並行して動かしながら検証し、準備が整ってから本番トラフィックを切り替えられます。
問題が起きた場合も、Buildのエンジニアリングチームが移行のプロセス全体を通してサポートします。
Buildはこの移行をシンプルに実現します。BuildはHerokuとの直接同期に対応しているためです。Baremetricsのチームは自分たちのペースで移行を進め、稼働を止めることなくワークロードをひとつずつBuildへ移していきました。
どちらを選ぶべきか
Herokuを使い続けるべき場合
- インフラの制御性より、エコシステムの成熟度を重視している
- Herokuのドキュメントと作法に蓄積された深さにチームが依存している
- 月々の利用額が小さく、今後も大きな成長を見込んでいない
- Buildに相当機能のない専門的なアドオンにアプリケーションが依存している
Buildに移行すべき場合
- 今も、これから必要になる機能も、すべてのプランに標準搭載されていてほしい
- ダイノごと・アドオンごとの課金ではなく、低く予測可能な月額料金にしたい
- プラットフォームを離れずに、設定可能なタイムアウト、Kubernetesアクセス、仮想マシンを使いたい
- 保守のみのプラットフォームではなく、今も開発が続いているプラットフォームを選びたい
詳細比較
よくある質問
Herokuはサービスを終了するのですか？
Herokuは2026年2月にサステイニングエンジニアリング体制へ移行しました。Salesforceはセキュリティ更新、安定性の維持、サポートを継続していますが、新機能の開発は停止しています。またエンタープライズアカウントの新規契約も提供されていません。
BuildはHerokuの代替としてそのまま使えますか？
一般的なHerokuアプリケーションであれば、かなり近い形でそのまま動きます。BuildはHeroku Buildpack、webおよびworkerのプロセスタイプ、config vars、パイプライン、レビュー環境、PostgresとRedisに対応しており、Herokuに近い形のAPIとほぼ同じ使い勝手のCLIを提供しています。多くのアプリケーションはコードを変更せずにデプロイできますが、Heroku固有のアドオンや特殊な挙動に依存している場合は移行作業が必要になることがあります。
HerokuがBuildより優れている点は何ですか？
Herokuははるかに大きなアドオンのエコシステム、より成熟したドキュメント、そして圧倒的に多くの開発者にとっての馴染みやすさを備えています。そのエコシステムに強く依存しているチームには、留まる十分な理由があります。
BuildはAWS上で動いていますか？
いいえ、Buildはハイパースケーラーから借りたキャパシティではなく、米国・欧州・日本のTier 3およびTier 4データセンターにある自社所有・自社運用のサーバー上で動いています。
Buildの運用にDevOpsエンジニアは必要ですか？
いいえ、Buildがデプロイ、ネットワーキング、インフラ、プラットフォーム運用を引き受けます。より深い制御が必要なチームは、標準のワークロードと並行して自身のKubernetesネームスペースにアクセスしたり、仮想マシンを動かしたりできます。
BuildはHerokuより安いですか？
同等の本番ワークロードであれば、Buildはシート、セキュリティ機能、プラットフォーム機能を標準で含めたうえでHerokuを下回るように設計されています。実際の差はダイノ、データベース、アドオン、そしてHerokuのプランによって変わります。同等の現在の請求書でBuildが下回らなければ、その請求書をお送りください。その金額を下回る価格をご提示し、12か月間その価格を維持します。