- アプリ開発
Heroku本番運用3年の学び ― 強みと、運用でわかったこと


Herokuの強み ― 実際に効いた4つのポイント
3年運用してきて、Herokuを使っていて良かったと感じるのは次の4点です。
強み1:必要なものが1つのプラットフォームに揃う
Web・API・cron・DB・ストレージが別サービスに散ると、認証もネットワークも監視も請求もバラバラになります。Herokuはアプリを置けばHTTPSまで付いてきて、データベースも同じ画面から足せます。「どこに何があるか」を追いかける時間が、そもそも発生しません。
強み2:git push から本番リリースまでが速い
HerokuではGitHubと連携することで、「git push」するだけでシステムをリリースすることができます。最初のリリースまでの速度は、そのままプロジェクトの成否に関わると言っても過言ではありません。インフラ構築に2週間かけずに済むのは、それ自体が価値だと考えています。
強み3:運用に必要な周辺機能を、必要になってから足せる
定期実行が要る、ログをSlackに流したい、外向き通信のIPを固定したい。運用が始まってから出てくる要望に、アドオンを足すだけで応えられます。最初から全部を設計し切らなくてよいというのは、実務ではかなり大きい利点です。
強み4:構成が標準的なので、あとで別の環境に移しやすい
最初の環境を一生使うとは限りません。Herokuは公式buildpackとPostgresという一般的な構成なので、あとで別の環境へ載せ替えるときの障壁が低くなります。
Herokuで実際に何を利用してきたか
実際に使っている機能とアドオンは以下のようなものになります。(あくまで一例です)
| アプリ実行 | Dyno(Web / worker)、Procfileによる起動制御 |
|---|---|
| ビルド | 公式buildpack(Node.js / PHP)など |
| データベース | Heroku Postgres |
| Salesforce連携 | Heroku Connect |
| 定期実行 | Heroku Scheduler |
| デプロイ | Heroku Pipelines、Review Apps |
| 監視・通知 | Papertrailでログを収集し、エラーをSlackへ自動通知 |
| ネットワーク | Fixie(外向き通信のIP固定)、IP制限 |
| 障害時の見せ方 | エラーページ / メンテナンスページのカスタマイズ |
このうち、実運用で特に効いているものを3つ紹介します。
Review Apps
プルリクエストを出すと、検証用の環境が自動で立ち上がります。「この画面、実際に触って確認したい」という依頼に、URLをお渡しするだけで応えられます。レビューの質が変わりました。
Papertrail から Slack への通知
ログを人間が見に行く運用は続きません。エラーレベルなどの条件で検索を保存しておき、引っかかったらSlackに飛ばしています。
運用してみた実感としては、通知を作ることよりも、ノイズを削る作業のほうが本体でした。調査済みで対応不要なエラーを除外条件に積み上げていくことで、「鳴ったら見る」状態を維持しています。
Heroku Connect
Salesforceに入っているデータを、コードを書かずにPostgresへ同期できる仕組みです。Salesforceを業務基盤にされているお客様のシステムでは、これがあるかないかで構成がまるごと変わります。
※ Heroku Connectがあるから、Herokuをシステム基盤として選択するということが多い印象です。
運用でわかったこと ― 直面した制約
実際に運用する中で、Heroku固有の制約には以下のようなものがありました。
リクエストは30秒でタイムアウトとなる
Herokuのルーターは30秒でタイムアウトします。設定で短くすることはできますが、長くすることはできません。CSVダウンロードや画像の一括ダウンロードで、実際に詰まりました。
対処は設計側で行います。非同期ジョブにする、ストリーミングで返す、事前に生成してストレージから配る。制約が先にあるぶん、最初から素直な設計に寄せられるという言い方もできます。
メモリ超過はアプリを落とす
画像データをサーバー側でメモリに展開している箇所があり、メモリ逼迫のアラートが鳴り続けたことがありました。原因を特定し、データを展開せずそのまま返す形に変更したところ、メモリ使用量のグラフが目に見えて落ち着きました。
Herokuはメモリ超過を明確なエラーコードで知らせてくれるので、原因調査の起点はつかみやすいと感じています。
エラーコードは「結果」しか教えてくれない
「アプリが落ちた」というルーター側のエラーは出ますが、なぜ落ちたのかはアプリ側のログを見に行かないとわからない場合がありました。
実際、リリースしたのにアクセスできず、調べてみたら起動コマンドの定義漏れだった、ということが2回ありました。ログを確認する癖がつくまでは、ここで時間を使うことになります。
まとめ ― 3年運用して
ここまで、Herokuの強みを4つ、運用で当たった制約を3つ挙げてきました。
必要なものが一箇所に揃っていて、リリースは速く、足りないものは後から足せて、いざとなれば別の環境にも移せる。
規模の小さい立ち上げに向いているのはもちろんですが、お客様の業務の中心で動くシステムでも、これらの強みを活かして開発のスピードを保ったまま構築できました。
制約はあるものの、30秒の壁もメモリ超過も、事前に把握して設計に織り込んでおけば、安定して動かし続けられます。率直に言って、3年運用してきて、困った場面よりも助かった場面のほうが多かったです。
運用の中で、ただHerokuの操作方法覚えるのではなく、「30秒リクエストがタイムアウトする前提でどう設計するか」などの「インフラも交えてシステム設計をどうするか」について、学ぶことができたと感じています。
補足:2026年2月の発表について
2026年2月6日、Herokuは公式ブログ「An Update on Heroku」で今後の開発方針を発表しています。Salesforceが投資をAI領域に集中させるため、Herokuは新機能の開発を行わず、セキュリティ・安定性・信頼性・サポートの維持に専念する体制(sustaining engineering model)へ移行する、という内容です。
発表で示されている主な内容は次のとおりです。
- 新機能の開発は行われない
- 新規のお客様向けには、Enterprise Account契約が提供されない
- クレジットカードでのご利用は、新規・既存ともに料金・課金・サービスに変更なし
- アプリ、パイプライン、Team、アドオンといったコア機能への影響はなし
本記事で紹介した強みや制約は、あくまで弊社がこれまでHerokuを運用してきた中で得た経験にもとづくものです。これから新規にHerokuの利用を検討される場合は、この発表の内容もあわせて考慮に入れていただき、最新の情報については、Herokuの公式アナウンスをご確認ください。
ドコドア エンジニア部
このブログでは、アプリ開発の現場で培ったフロントエンド、バックエンド、インフラ構築の知識から生成AI活用のノウハウまで、実践的な情報をアプリ開発に悩む皆様へ向けて発信しています!
【主な技術スタック】 Flutter / Firebase / Svelte / AWS / GCP / OpenAI API