B2B向けのAIチャットボットSaaS「シルボ」開発中のお話

順調に開発が進んでいたのですが、バックエンドのホスティング先として使っていた**Render（レンダー）で、ある「壁」にぶつかりました。 そこで今回、思い切ってRailway（レイルウェイ）**へお引越しを敢行。その理由と手順をログとして残します。

なぜRenderからRailwayへ？

まずは技術スタックの整理です。

  • Frontend: Next.js (Vercel)
  • Backend: Python / FastAPI (今回の主役)
  • Database: Neon (PostgreSQL)

これまではバックエンドをRenderの無料プランで動かしていました。しかし、チャットボットという性質上、以下の問題が発生しました。

1. 無料プランの「コールドスタート」が遅すぎる

Renderの無料プランは、一定時間アクセスがないとサーバーがスリープします。再起動には15秒以上かかり、チャットボットとしては致命的なタイムラグになります。
これは別システムを使い10秒ごとに自動アクセスを行い回避する事もできますが、運用上不安要素になるので却下

2. 有料プラン（月$7）は「量産」に向かない

スリープを防ぐには月額7ドルの有料プランが必要です。「7ドルなら安いじゃん」と思うかもしれませんが、「小規模なアプリをたくさん作っていくと固定費だけで月70ドル（約1万円）…。まだ収益化前のアプリにこれは痛い。

3. Railwayなら「使った分だけ」

そこで目をつけたのがRailwayです。

（キャプション：Ship software peacefully. その名の通り、平和にデプロイできます）

  • 使用量ベース課金: 小規模アプリなら月$1〜2程度で収まることが多い。
  • セキュリティ: SOC 2 Type I取得済みで、B2B向けとしても安心。
  • $5分の無料クレジット: 最初のお試し枠がある（※プランによる）。

つまり、**「アプリを量産しても、使われていないアプリにはお金がかからない」**という、個人開発者に最適なプラットフォームなのです。

移行手順（驚くほど簡単でした）

「サーバー移行」と聞くと面倒そうですが、コードの変更はたった1ファイルのみ。あとは設定画面ポチポチで終わりました。

STEP 1：Procfileの作成

まず、ローカルのプロジェクト（backendフォルダ直下など）に Procfile という名前のファイル（拡張子なし）を作ります。これがないとRailwayが「どうやってアプリを起動すればいいの？」と迷ってしまいます。

Procfileの中身:

Plaintext

web: uvicorn app.main:app --host 0.0.0.0 --port $PORT

※ app.main:app の部分は、ご自身のFastAPIのファイル構成に合わせて書き換えてください。

これをGitHubにプッシュしておきます。

STEP 2：Railwayでプロジェクト作成

Railwayのアカウントを作り、「New Project」→「Deploy from GitHub repo」を選択します。

（キャプション：GitHubリポジトリを選択してスタート）

自分のリポジトリを選びます。

STEP 3：設定（ここがつまずきポイント！）

デプロイが始まると、最初は**ビルドエラー（Build failed）**になるかもしれません。 これは、FastAPIのファイルがリポジトリのルートではなく、サブディレクトリ（/backendなど）にある場合に起こります。

（キャプション：Settings画面の「Root Directory」）

  • Settingsタブ に移動
  • Root Directory を /backend に設定（ご自身の構成に合わせて）

これでRailwayが正しい場所を見つけてくれます。

STEP 4：公開URLの発行

次に、外部（フロントエンド）からアクセスするためのURLを発行します。

（キャプション：Networkingタブでドメインを生成）

  • Networkingタブ に移動
  • 「Public Networking」の Generate Domain をクリック

これで xxx-production.up.railway.app のようなURLが発行されます。 ※もしボタンが押せない場合は、デプロイが完全に失敗している可能性があります。一度Logsを確認してみましょう。

STEP 5：環境変数の設定

DBの接続情報やAPIキーを設定します。

（キャプション：Variablesタブで環境変数を一括登録）

  • Variablesタブ に移動
  • 「Raw Editor」を使うと、.env ファイルの中身をコピペで一気に貼り付けられるので便利です。

必要な変数例：

  • DATABASE_URL (Neonの接続URL)
  • OPENAI_API_KEY
  • SECRET_KEY
  • CORS_ORIGINS (VercelのフロントエンドURLを許可)

デプロイが完了したら、ブラウザで https://発行されたURL/api/health などにアクセスして、動いているか確認しましょう。

STEP 6：フロントエンド（Vercel）側の設定変更

最後に、フロントエンドが新しいRailwayのサーバーを見に行くように設定を変更します。

（キャプション：Vercelの環境変数設定画面）

VercelのSettings → Environment Variablesへ行き、バックエンドのURLを指定している変数（例：BACKEND_URL や NEXT_PUBLIC_API_URL）を、先ほどRailwayで発行したURLに書き換えます。

その後、Vercel側で「Redeploy」を行えば移行完了です！

まとめ：Renderのサービスは停止して完了！

動作確認ができたら、Render側のサービスを「Suspend（停止）」または削除して、課金を止めましょう。

今回の移行のポイント:

  1. コード修正はほぼ不要: Procfile を追加しただけ。
  2. DB移行なし: Neon（外部DB）を使っていたので、接続先を変えるだけで済みました。
  3. コスト最適化: 固定費（$7）から、使用量ベース（~$1〜2）へ。

これで、今後新しいボットやツールを思いついたときに、固定費を気にせずガンガン「量産」できる環境が整いました。開発で「とりあえずデプロイしたいけど、Heroku有料だしRenderもスリープするし…」と迷っている方は、Railwayが今の最適解かもしれません。

← 開発録・ブログ一覧に戻る