HerokuからBuildへの移行

まだ検討段階の方へ。2つのプラットフォームの違いと、それぞれどのようなチームに適しているかはBuildとHerokuの比較をご覧ください。このページでは、移行したときに技術的に何が変わるかを説明します。

BuildはBuildpack、API、CLIのいずれのレベルでもHeroku互換です。Herokuで標準的な構成のアプリケーションは、ほとんどがコードを変更せずにBuild上で動作します。以下では、Herokuと完全には一致しない部分を取り上げます。

そのまま移行できるか

	そのまま移行	補足
Buildpack	可	Heroku Buildpackをそのまま利用できます
Dockerfileによるビルド	可	Buildpackの代替として利用可能
プロセスタイプ	可	`web`とworkerのプロセス。Procfileもそのまま使えます
Config vars	可	同じ概念、同じ名称。インポートも可能
パイプライン	可	Buildではリージョンをまたいだ昇格も可能
レビューアプリ	可	Buildでは「レビュー環境」。概念は同じです
Postgres	可	Buildが運用
キーバリューストア	可	Buildが運用
アドオン	要確認	主要なものは網羅。特定のアドオンに依存している場合は事前にご確認ください
リクエストタイムアウト	変わる	Herokuは30秒固定。Buildはアプリケーション単位で設定可能
Dynoの定期再起動	変わる	Herokuは約24時間ごとに再起動。Buildにスケジュールによる再起動はありません
アドオンの運用主体	変わる	Buildの自社アドオンは、パートナーのインフラではなくBuild自身のハードウェア上で動作します

概念と用語

Herokuの概念のほとんどは1対1で対応します。

Heroku	Build	補足
Dyno	Dyno	同じ単位
Dynoタイプ（Standard-1X、Performance-M）	Dynoサイズ	サイズは1対1で対応し、Dyno時間で課金
Buildpack	Buildpack	Heroku Buildpackをそのまま利用できます
Config var	Config var	同じ概念、同じ名称
パイプライン	パイプライン	Buildはリージョンをまたいだ昇格が可能
レビューアプリ	レビュー環境	同じ概念
アドオン	アドオン	BuildのアドオンはBuildのインフラ上で動作
Private Space	Private Space	同じ概念、同じ名称。構成によってはBuild側で追加費用が発生する場合があります
`heroku` CLI	`bld` CLI	ほぼ同じコマンド体系です。CLIガイドをご覧ください

コンピュートと実行環境

DynoサイズはHerokuと1対1で対応し、月間のDyno時間プールから消費される形で課金されます。Dynoサイズをご覧ください。

BuildではDynoと並べて仮想マシンを動かせるほか、自身のKubernetesネームスペースへkubectlで直接アクセスできます。Herokuはどちらも提供しておらず、実行基盤のコントロールプレーンをお客様が操作する手段はありません。

リクエストタイムアウト。 Herokuのルーターはリクエストに30秒の上限を課しており、この値は変更できません。Buildではリクエストタイムアウトをアプリケーション単位で設定します。

実行環境のポリシー。 Herokuでは固定されている項目のいくつかを、Buildはアプリケーション単位の設定項目として提供しています。App Policiesでは、リクエストタイムアウト、WebSocketの有効化、共有プロセスネームスペース、TLSパススルー、一時証明書の発行、ウェブアプリケーションファイアウォール、耐崩壊性を設定できます。App Settingsでは、スタック、Buildpackの選択と順序、ビルドキャッシュ、リージョンを指定します。いずれもアプリケーション単位の設定です。設定をご覧ください。

再起動。 Herokuは約24時間ごとにすべてのDynoを再起動します。Buildにスケジュールによる再起動はありません。再起動が必要な場合は、耐崩壊性の設定で、一定時間の経過後にプロセスを自動再起動できます。メモリリークへの備えなどに有効です。

パイプラインでの昇格。 Buildのイメージはアプリケーション単位・リージョン単位のため、ビルドをリージョン間で昇格できます。Herokuのパイプライン昇格は単一リージョン内に限られます。CI/CDとパイプラインをご覧ください。

ビルドの同時実行。 Buildは同時ビルド数に制限を設けていません。Herokuの制限はアカウント単位で、その状態によって変わります。同時ビルドは、未認証アカウントで1件、認証済みかつ支払い実績のないアカウントで10件、支払い実績のある認証済みアカウントで300件です。多数のアプリケーションを一度に再デプロイする移行作業は、この上限が実際に効いてくる場面です。

セッションの記録。 シェルおよびexecのセッションは記録され、アプリケーションのアクティビティログから再生できます。Herokuに同等の機能はありません。

データサービス

どちらのプラットフォームもマネージドのPostgresとキーバリューストアを提供し、複数のアプリケーションからの接続にも対応しています。Buildの自社アドオンは、コンピュートと同じハードウェア上で単一のチームが運用しています。内訳は、Schema To Go（PostgreSQL）、Ave To Go（MariaDB）、Sequel To Go（Microsoft SQL Server）、Cache To Go（Redis）、Donkey To Go（MongoDB）、Spandex To Go（ElasticsearchおよびOpenSearch）、そしてトランザクションメール向けのMailer To GoとAI推論向けのInfer To Goです。いずれもBuildが請求し、プランに含まれるアドオンクレジットから充当されます。パートナーアドオンはBuild経由でプロビジョニングできますが、提供と請求はパートナー側が行います。アドオンサービスをご覧ください。

Herokuが自社で運用しているのはPostgres、Key-Value Store、Kafkaで、それ以外はサードパーティのElementsパートナーが提供しています。

データベースの制御。 Herokuでは変更できない3つの項目が、Buildでは設定できます。共有バッファ、実効I/O同時実行数、最大並列ワーカー数などのPostgreSQLパラメータは、インスタンス単位でチューニングできます。コネクションプーリングは、Buildpackの導入ではなく設定の切り替えで有効にできます。週次のメンテナンス時間とベースバックアップ時間も、提供側から指定されるのではなく自分で選べます。

ポイントインタイムリカバリは、どちらのプラットフォームでも利用できます。

リージョン間の移設。 データストアはセルフサービスでリージョン間を移動できます。プロビジョニング、同期、切り替え、設定更新という一連の流れは画面上で追えます。Herokuには、稼働中のデータアドオンをセルフサービスでリージョン移動する手段はありません。

アドオンの代替。 Herokuのマーケットプレイスはこのカテゴリで最大規模であり、200を超えるアドオンがあります。Buildはそのうち広く使われているものを自社インフラ上で提供しています。特定のアドオンに依存しているアプリケーションでは、移行を計画する前に代替の有無をご確認ください。

ネットワークとリージョン

Buildは米国・EU・日本でのデータレジデンシーをすべてのプランで提供し、プライベートネットワーキングは標準、アプリ単位のマルチゾーンフェイルオーバーも利用できます。リージョンをご覧ください。

HerokuのCommon Runtimeは米国とEUです。それ以外のリージョンには有料のPrivate Spacesが必要です。Herokuにアプリケーション単位のゾーンフェイルオーバーはありません。

セキュリティとコンプライアンス

どちらのプラットフォームもSOC 2を取得しています。HerokuはCommon RuntimeとPrivate Spacesの両リージョンでSOC 1・2・3を取得しており、PCI DSSとHIPAAへの対応はShield製品に限られます。

SOC 2レポートとロールベースのアクセス制御は、どちらのプラットフォームでもプランによる制限がありません。Herokuは2026年8月にきめ細かなアクセス制御を全顧客へ開放しており、コンプライアンスレポートもサポート経由で取得できます。プランの要件は示されていません。

違いは、何をどのプランに含めるかです。BuildではSOC 2認証、プライベートネットワーキング、監査ログ、ロールベースのアクセス制御、Google Workspaceシングルサインオンがすべてのプランに含まれます。Herokuでは監査ログと全社シングルサインオンがエンタープライズアカウントの機能です。

このほかBuildには、Herokuのどのプランにも同等のものがない次の機能があります。

OWASP Core Rule Setを用いた、アプリ単位で切り替えられるウェブアプリケーションファイアウォール
ビルドごとに生成されるSPDX形式のソフトウェア部品表（SBOM）
コンテナイメージの脆弱性スキャン。レポートはイメージ単位で確認可能
アプリケーションのアクティビティログから再生できる、記録済みのシェルおよびexecセッション

セキュリティをご覧ください。

課金モデル

単位が変わります。HerokuはDynoごと、アドオンごとに月額で課金します。Buildは月間のDyno時間プールで課金し、稼働中のリソースがそこから差し引かれます。アドオンクレジットと人数無制限のシートも同じ金額に含まれます。

1 Dyno時間は、Standard-1X Dynoを1時間動かした分です。より大きなサイズはサイズに比例して多く消費し、Performance-Mは1時間あたり8 Dyno時間を使用します。キャパシティを見積もる際は、この数値が基準になります。

具体的なコスト比較はBuildとHerokuの比較を、プランごとのキャパシティはBuildの料金をご覧ください。

移行

Buildは、接続したHerokuアカウントからアプリケーション、config vars、アドオン設定をインポートできます。アプリケーションを検証する間、両方のプラットフォームを並行して動かすことも可能です。エンジニアによる移行サポートは、エンタープライズプランのすべてのお客様に標準で含まれています。Buildへの移行をご覧ください。

よくある質問

Heroku BuildpackはBuildで動作しますか？

はい、そのまま動作します。BuildはDockerfileによるビルドにも対応しています。

Dynoサイズは1対1で対応しますか？

はい。HerokuでN単位として課金されるDynoは、Buildでは実時間1時間あたりN Dyno時間を消費します。

Private Spacesに相当するものはありますか？

Buildにも同じ名称のPrivate Spacesがあります。プライベートネットワーキングはすべてのプランで標準であり、米国以外のリージョンもプランを変更することなく利用できます。構成によってはPrivate Spacesに追加費用が発生する場合があります。

30秒のタイムアウト対策は引き続き必要ですか？

タイムアウト自体への対策は不要になります。Buildではリクエストタイムアウトがアプリケーション単位の設定のため、Herokuの30秒固定を避ける目的だけで切り出していた処理は、その方が適していれば元の処理内に戻せます。

Dynoは毎日再起動されますか？

いいえ。Buildにスケジュールによる再起動はありません。日次の再起動によって状態のクリアやメモリの解放を行っている場合は、耐崩壊性の設定で、一定時間経過後の再起動を明示的に指定してください。

最終確認日: 2026年9月7日