Herokuのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Herokuのシステム開発は、6つの段階で進みます。前半は要件整理と方式・環境の選定、中盤は設計・開発とテスト、後半は稼働と定着です。各段階の完了条件を決めてから次へ進むと、業務と技術の抜け漏れを抑えやすくなります。

費用の目安と見積もりの確認点も取り上げます。全体像は、完全ガイドの記事もご覧ください。

▼全体ガイドの記事
・Herokuのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Herokuのシステム開発の全体像

Herokuのシステム開発では、アプリを実行するPaaSに、データベースやキャッシュ、外部連携を組み合わせます。

認証、監視、デリバリーも、あわせて組み合わせる要素です。

サーバーやOSの調達と初期設定は減らせますが、業務要件やアプリの品質は自動では整いません。そのため、何を作るかと、安全に使い続けるための条件を最初に定めます。

Herokuが担う範囲と利用企業に残る範囲

Herokuが担うのは、アプリを動かす実行基盤と、データや開発フローを支える機能です。

• デプロイと実行：Git、Docker、Heroku CLIからコードをデプロイし、WebやWorkerをdynoで動かせます。
• データ・ジョブ：Heroku Postgresは業務データに、Key-Value Storeはキャッシュやジョブキューに使えます。
• 開発フロー：PipelinesやReview Appsを使うと、アプリ、環境変数、ログ、デプロイを同じ運用フローに載せられます。

残る部分は、利用企業と開発会社が担います。中心は、認証・権限、入力値の検証、脆弱性対応です。ほかに、個人情報、バックアップ復元、データの正確性も両者の担当になります。

Heroku公式の共有責任モデルでも、基盤の保護と、顧客側のアプリ・アカウント・アクセス管理は分けて示されています（出典：Heroku公式「Security, Privacy, and Compliance」、2025年）。そのため、責任の境界は要件定義書に書いておく必要があります。書かないと、「Herokuが面倒を見てくれる」という認識違いが起きます。

採用時に決める実行環境と移行出口

必要な接続環境や監査要件によって、候補となる実行環境が変わります。

• Common Runtime：一般的なWebサービスや社内ツールが候補です。
• Private Spaces：ネットワーク分離、固定アウトバウンドIP、閉域接続が必要な場合に検討します。
• Shield Private Spaces：高度な監査・規制要件がある場合の候補です。
• 選定条件：機密性や利用地域を確かめたうえで、同時接続数、復旧目標、接続先ネットワークも照らし合わせます。

法令への対応は、プラン名だけで完了とみなさず、要件ごとに確認します。

2026年2月、Herokuは新機能の拡大よりも、安定性・セキュリティ・信頼性・サポートを重視すると発表しました。その方針は、sustaining engineeringモデルへの移行です（出典：Heroku公式「An Update on Heroku」、2026年2月）。

既存の利用は継続できますが、新規のEnterprise Account契約は提供されません。そのため、新規システムでは契約条件、サポート窓口、5年後の選択肢を確認します。

AWSなどへ移せる出口を設計段階から残すため、納品物にはソースコード、DBスキーマ、データ出力、CI/CD設定、構成図を含めます。

Herokuのシステム開発の進め方

開発は6フェーズに分け、各フェーズの完了条件を決めてから次へ進みます。

業務側と技術側が、同じ資料を見ながら確認します。

画面を作る前に、データの正、認証方式、運用時間、障害時の代替手段を決めておくことが大切です。

1. 要件を整理し、業務と非機能の条件を言語化します。
2. Herokuを含む開発方式と実行環境の選定。
3. 運用を含めた設計と、システムの開発。
4. 正常系以外を含むテストと、受け入れ条件の確認。
5. 移行とリリース判定を経た、安全な稼働。
6. 利用状況の確認と、運用・改善の定着。

フェーズ1: 要件整理で業務と非機能を言語化

要件整理では、まず現行業務を洗い出します。そのうえで、システム化の前に確認する項目を次のとおり整理します。

• 現行業務：Excel、メール、紙、FAX、既存DB、Salesforce、手作業の例外を一覧にします。
• 業務の流れ：誰がいつ何を入力し、誰が承認し、後工程でどのデータを使うかを記録します。
• 標準化：不要な作業や重複入力をそのままデジタル化せず、業務の標準化とシステム化を分けて扱います。
• 業務要件：利用者の役割・権限、例外、データ項目・保存期間、承認経路が対象です。

非機能の条件では、同時利用者数や目標応答時間、稼働時間、RTO・RPOを定めます。バックアップ復元、監査ログ、MFA・SSO、データ保管地域も確認し、Must・Should・Couldで優先順位を付けます。

Mustの受け入れ条件を文章にしておくと、「そこまで必要とは聞いていない」という追加見積もりを抑えやすくなります。

フェーズ2: Herokuを含む方式と環境の選定

同じ要件で、Heroku、AWS・AzureなどのIaaS、SaaS・パッケージ、オンプレミス、ハイブリッドを比べます。

独自の顧客体験や、API、短期検証、段階的な機能追加を重視する場合は、Herokuが候補です。

一方で、特殊なネットワーク、重いバッチ、細かなOS制御、既存基幹との強い結合があるなら、他方式も検討します。選ぶ基準は、技術者の好みより業務価値と運用負担です。

Heroku内では、Common RuntimeとPrivate Spacesのどちらを使うかを決めます。あわせて、WebとWorkerのプロセス数や、Postgresの可用性と容量も決めます。

また、キャッシュやファイルの保存先も選びます。特に、Salesforce連携は、業務の即時性、データ量、更新の競合で方式を比べます。

• Heroku Connect：Salesforceとのデータ同期を担います。
• AppLink：HerokuアプリをAPIとして公開する役割です。
• Platform Events：イベント連携の用途で使います。
• REST API・MuleSoft：要件に応じて連携方式を選びます。

選定資料には、採用理由に加えて、不採用理由と将来の移行条件も残しておきます。

フェーズ3: 運用できる形の設計と開発

運用と変更管理を見据えて、設計と開発で決める内容を次のとおり整理します。

• 基本設計：画面、業務フロー、権限、データ、外部連携、環境、監視、バックアップと復旧を決めます。
• 処理設計：非同期処理、再送回数、重複実行の防止方法を設計します。
• データ保存：永続化が必要なファイルは外部ストレージに置き、dynoの一時領域だけには保存しません。
• 構成管理：ソース、DB、初期データ、移行、環境変数、秘密情報、Buildpackやコンテナ設定を管理対象にします。
• 開発・検証：環境を分け、Pull RequestごとにReview Appsを使い、CIで静的解析と自動テストを通します。

Heroku-26はUbuntu 26.04 LTSベースで、2031年4月末までサポートが予定されています（出典：Heroku Dev Center「Heroku-26 stack is now generally available」、2026年5月）。

なお、新規アプリでは当面Heroku-24が既定です。そのうえで、採用するスタックと依存ライブラリを検証環境で確認します。

フェーズ4: 正常系以外のテスト

テストでは、次の種類の確認を行います。

• 機能：単体テスト、結合テスト、業務シナリオテスト、受け入れテスト。
• 性能と安全性：負荷テスト、セキュリティテスト。
• データ移行：移行リハーサルを行い、移行前後のデータを照合します。

業務テストでは、権限外の閲覧、申請の二重登録、外部停止時の状態保持、承認途中データの再開を確認します。画面の表示だけでなく、こうした業務上の動きまで確かめて、初めて業務テストといえます。

テスト仕様書には、前提条件、操作、期待結果を書きます。実績、証跡、判定も残します。

さらに、データ移行では移行元と移行先を照合します。件数、必須項目、文字化け、日付・金額の変換、重複、権限、関連付けが対象です。

負荷テストでは、平均値だけでなくピーク時の同時接続数、キュー滞留、DB接続数、外部APIの制限、タイムアウトを確認します。基準を超えた場合は、dyno増加、SQL改善、処理分割のどれで対応するかを決めます。

フェーズ5: 安全な切り替えと稼働

稼働準備から初期監視まで、切り替えは次の順で進めます。

1. リリース判定会で、不具合、移行結果、バックアップ、監視、連絡網、ロールバック条件、利用者教育を確かめます。
2. 新旧システムを並行稼働できるなら、重要業務から段階的に切り替えます。
3. 稼働直後は、システムと業務の状況を重点的に見ます。

手順書には、担当者、開始と完了の条件、所要時間、戻し方を記します。読み上げて実施できる粒度にそろえます。

監視では、まずエラーログと応答時間を見ます。dyno、DB接続、ジョブ失敗の状態も追います。外部連携の遅延と問い合わせ件数も、合わせて確認します。

障害に備えて、誰が一次切り分けを行い、何分以内に開発会社へ連絡し、どの条件でロールバックするかを、契約と運用表に記します。

サービスが動いていても、業務が止まれば成功とはいえません。そのため、現場の処理が完了するところまで確認します。

フェーズ6: 利用状況の管理と改善の定着

定着には、操作説明会の後も続く役割別の支援と、継続的な改善の仕組みが要ります。

• 利用支援：説明会のあとも、役割別手順書、FAQ、窓口、マスタ更新担当、権限申請を整えます。
• 利用状況：利用率、処理時間、差し戻し、入力ミス、問い合わせ分類を毎月見て、未利用機能や迂回業務を探します。
• 効果測定：要件整理の段階で指標を決め、改善の優先順位を説明できる状態にします。
• 定期保守：スタック、アドオン、脆弱性、バックアップ復元、障害訓練、アクセス権を定期的に点検します。

特定の担当者だけが復旧できる状態を避けるため、外部監視、IaC、標準SQL、コンテナ、12-Factorを取り入れます。

半年または一年ごとに、継続利用、構成変更、他クラウドへの移行を、TCOとリスクで見直します。

Herokuのシステム開発費用と月額料金の相場

費用は、初期の開発・導入費と、公開後のHeroku実費、外部サービス費、保守・改善費に分けて考えます。

Heroku固有の開発会社相場を示す公的統計はありません。そのため、開発費はリサーチノートと一般的な業務システムの工数から算出した推定です。

料金は契約、為替、税、利用量で変わります。そのため、以下の金額は予算を組むための目安です。

開発・導入費の規模と連携による違い

開発費の推定レンジは、システム規模や必要な連携によって異なります。

• PoC・社内ツール：代表業務の検証を含めて、100万〜300万円程度です。
• 小規模業務システム：ログイン、権限、複数画面、Postgres、外部連携を含め、300万〜1,000万円程度です。
• 中規模案件：顧客ポータル、受発注、予約、複数ロール、移行、負荷試験を含め、1,000万〜3,000万円程度です。
• 大規模案件：複雑な基幹連携、規制対応、24時間運用を含め、3,000万円〜1億円超も想定されます。

金額は、要件の複雑さを反映した推定です。確定した価格として扱う前に、見積もりで前提を確かめることが大切です。

期間の目安は、PoCが1〜2か月、小規模が2〜5か月、中規模が5〜10か月です。工数は、要件定義10〜15%、設計25〜35%、実装・テスト45〜60%、移行・教育・リリース5〜10%と仮置きします。

期間を延ばしやすいのは、Salesforceの項目整理と複雑な承認です。データ品質の不良や社内承認の遅れも、要因になります。

公式料金の積み上げ（dyno・DB・アドオン）

料金の主な内訳は、dyno、データサービス、追加の運用サービスです。

• dyno：Eco月5ドル、Basic月7ドル、Standard-1X月25ドル、Standard-2X月50ドル。
• データサービス：Postgres Standard-0は月50ドルから、Key-Value Store Miniは月3ドル、Premium 0は月15ドルから。
• 追加サービス：ログ、エラー監視、メール、ファイル、バックアップ、Private Spaces、Shield、VPN・SIEMも対象になります。
• 小規模本番：公式サービスの実費だけで、月1万〜10万円程度が目安です。
• 中規模本番：複数環境、常時稼働、冗長化、監視を含めると、月10万〜100万円超になる場合があります。

Heroku公式料金表では、各dynoが上記の月額です。Ecoは30分間アクセスがないと休止します。そのため、常時稼働の本番ではBasic以上を検討します。

1ドル=150円で換算すると、dyno一つあたり約750円、約1,050円、約3,750円、約7,500円です。実際の請求額ではありません（出典：Heroku公式料金表、2026年8月確認）。

Web用とWorker用、開発・ステージング・本番を分ける場合、dyno料金は台数分だけ積み上がります。

データサービスや追加機能の利用料は、別に加算されます。一方で、検証アプリは月額数千円から始められます。

初期費用だけでなくTCOでの判断

初期開発費に、12か月または60か月分のHeroku実費、保守、監視、外部サービス、移行・教育費を加えたTCOで比べます。

初期開発500万〜800万円、プラットフォームと監視が月3万〜10万円、保守が月10万〜30万円の場合、1年目は約700万〜1,280万円です。

これは計算の一例で、特定案件の価格を断定するものではありません。見積書の前提条件を入れ替えて比較します。

Herokuのシステム開発の見積もりのポイント

見積もりは、画面数だけでなく、業務ルール、データ、非機能、運用、成果物を同じ粒度で示してもらいます。

候補先には共通のRFPと質問票を渡し、価格・工数・前提・除外項目を比べます。安い見積もりでも、契約後の追加費用につながる未包含の作業が含まれていないかを確認します。

要件・データ・非機能を見積もりの前提

見積もりの前提は、要件、データ、非機能の条件がそろって初めて定まります。RFPには、その条件を業務・画面、連携・移行、非機能などの領域ごとに書き込みます。

• 業務・画面：対象業務、利用者数、権限、画面・帳票、CSV、通知。
• 連携・移行：外部API、Salesforce連携、移行データ量、対象テーブル、件数、欠損・重複、文字コード、名寄せ。
• 非機能：保管地域、稼働時間、ピーク同時接続数、応答時間、RTO・RPO、監査ログ、バックアップ、サポート時間。
• 移行計画：リハーサル、停止時間、移行後の照合方法。
• Salesforce連携：正とするデータ、許容遅延、更新競合、失敗時の再送、API制限、停止時の業務継続。

要件が曖昧なまま一式の価格を比べると、契約後に追加開発が増えやすくなります。そのため、未確定の項目は「未定」と書き、開発会社に仮定と追加費用の幅を示してもらいます。

同じ条件と成果物で複数社を比較

同じ条件で、構成、見積もりの内訳、納品物、開発会社の実績を比べます。

• 構成：構成図、dyno・環境数、各プラン、Private SpacesやShield、監視・ログ・バックアップ。
• 費用内訳：工程別の工数・単価、前提、除外項目、変更時の精算方法。
• 工程：要件定義、設計、実装、テスト、移行、教育、リリース、保守を分けて示してもらいます。
• 納品物：要件・設計書、DB・API仕様、テスト仕様と結果、移行・運用手順、監視・CI/CD設定、権限一覧。
• 担当会社：公式Partner掲載は品質や料金の保証ではないため、担当者、類似構成、障害対応、リファレンスを面談で確かめます。

障害対応表、環境構築手順、将来移行用のデータ出力方法も、納品物として確認します。

価格と並べて見るリスクと運用契約

料金と納期だけでなく、障害対応や個人情報の扱いを契約条件で確認します。

• 障害対応：対応時間、一次受付と開発対応の分担、SLA、復旧目標、バックアップ保持期間。
• 変更対応：脆弱性、スタック更新、アドオンの終了や値上げへの対応。
• 料金区分：通常運用、軽微改修、緊急対応、大規模追加開発を分けて定めます。
• 個人情報：実行環境、MFA・SSO、アクセスログ、暗号化、委託先管理を見ます。

月額保守が安くても、調査や復旧が別料金なら、障害時に予算と判断が止まります。

また、越境移転や漏えい時の連絡と報告も確認します。個人情報保護委員会は、サーバーの所在地だけでなく、外国事業者による個人データの取扱いも確認する考え方を示しています。

委託先の監督や安全管理措置も、確認の対象です（出典：個人情報保護委員会「外国事業者のクラウドでサーバーが国内の場合」）。

法令適合の判断を、プラン名だけに任せないことが必要です。

Herokuのシステム開発でよくある質問

料金や技術だけでなく、事業継続性、既存システムとの連携、運用体制も含めて判断します。

Herokuのシステムは月額いくらから始められますか？

検証用途なら、公式料金表上、Eco月5ドル、Basic月7ドル、Key-Value Store Mini月3ドルなどから始められます。一方、本番ではPostgres、複数dyno、ステージングが加わります。さらに、ログや監視のほか、バックアップと外部サービスも加わります。

小規模の公式サービス実費は、月1万〜10万円程度が目安です（出典：Heroku公式料金表、2026年8月確認）。

Herokuはどのようなシステムに向いていますか？

Herokuの適性は、実現したいサービスと必要なインフラ制御で見極めます。

• 向いている用途：API、顧客向けポータル、SaaS、社内業務ツール、Salesforceを補う独自アプリ。
• 検証・拡張：短期検証をGitベースのデプロイ、Pipelines、Review Appsで小さく始め、利用状況を見て拡張できます。
• 比較が必要な用途：細かなOS・ネットワーク制御、特殊な低遅延、巨大データ処理、強いベンダー指定が必要なシステム。

2026年の方針変更を踏まえ、新規の長期案件は、契約、ロードマップ、移行性を確認したうえで採用します。

SalesforceとHerokuはどのように連携しますか？

Salesforceとの連携は、どの処理を実現するかで方式が変わります。

• Heroku Connect：SalesforceオブジェクトとHeroku Postgresを同期します。
• AppLink：HerokuアプリをAPIとして公開します。
• イベント・API連携：Platform Events、REST API、MuleSoftを要件に応じて使います。

定期・継続同期、API呼び出し、非同期イベントのどれを実現するかで選択します（出典：Heroku Dev Center「Integrating Heroku and the Salesforce Platform Overview」、2025年更新）。

2026年4月のAppLink更新では、新規連携にSalesforceのexternal client appsが推奨されました。一方で、従来のconnected apps向けの指定は非推奨です（出典：Heroku Dev Center「Heroku AppLink now supports Salesforce external client apps」、2026年4月）。

本番とSandboxの接続先を分け、認証、権限、API制限、失敗時の再送、監査ログをテスト仕様に含めます。

Herokuの開発会社には何を確認すればよいですか？

開発会社の技術力、成果物、保守体制を、同じ観点で確認します。

• 技術・障害対応：構成図を説明でき、Postgresや外部連携の障害対応経験があるか。
• 環境・試験：Private SpacesやShieldの選定、データ移行、負荷試験を担当できるか。
• 納品・保守：設計書、テスト結果、CI/CD、ソース、移行手順、日本語窓口、SLAを提供するか。
• 移行性・実績：AWSなどへの移行を妨げない契約か。近い規模・連携・規制要件の事例があるか。

Heroku公式Customer Storyには、LaunchPad LabがKawasakiのアプリを手がけた事例があります。この事例では、30年以上のデータ統合やPrivate Spacesを扱い、4か月未満で提供しました。

ただし、同じ期間で完了するとは限りません（出典：Heroku公式Customer Story「How LaunchPad Lab Built Kawasaki’s App on Heroku in 4 Months」）。

自社の要件と体制に置き換えて、工数の根拠を確認します。

まとめ

Heroku開発は、要件整理と選定に始まり、設計・開発とテストを経て、稼働と定着へ進みます。そのなかで、利用者、データ、権限を明確にしておくと、抜け漏れを減らせます。例外と応答・復旧目標を定め、監査と連携先も明確にしておきます。

候補には、Common Runtime、Private Spaces、Shield、Heroku Postgres、Salesforce連携方式が挙がります。選ぶときは、明確にした条件に合わせて判断します。

発注前に確認するチェックリスト

発注前に確認する条件を、要件、データ、運用、契約の観点で並べます。

• 要件：Must要件と受け入れ条件。
• データ：データの正と移行範囲。
• 安全性・復旧：認証・権限・監査ログ、RTO・RPO、バックアップ復元。
• 性能・構成：同時接続数、応答時間、Heroku環境、dyno、アドオン。
• 連携・成果物・保守：障害時の継続策、ソースコードの権利、窓口、SLA、移行出口。

未定の項目があれば、仮定、追加費用、再見積もりの条件を見積書に明記してもらいます。

Herokuを採用するかの判断（運用とTCO）

採用の判断では、Herokuの使い方と長期運用の条件を合わせて確認します。

• 用途：小さく始めて素早く改善したいWebサービスや業務システムに合います。
• 継続性：2026年の方針変更を踏まえ、契約、サポート、セキュリティ、月額TCO、データ・クラウド移行を比較します。
• 発注管理：価格だけで決めないために、6フェーズの完了条件とチェックリストを開発会社との共通資料にします。

▼全体ガイドの記事
・Herokuのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。