Rails本番環境での環境変数の設定をわかりやすく解説

はじめに

Railsで本番環境を運用するうえで、環境変数をどのように設定・管理すべきか悩む方は多いのではないでしょうか。
本番環境ではデータベースの接続情報やAPIキーなど、外部に漏らしては困る情報を安全に扱う必要があります。
しかし、やみくもにコード内へ直接書くとセキュリティ面や可読性の問題が生じます。
そこで活躍するのが環境変数の仕組みです。
適切に活用すれば、プロジェクトごとの設定管理をシンプルにしつつ、情報漏洩のリスクを減らすことができます。

本記事では、Railsの本番環境での環境変数の設定方法について、初心者にもわかりやすく解説します。
具体的な利用シーンやセキュリティ対策をはじめ、複数の手法やそれぞれのメリット、注意点をしっかりと確認していきましょう。

この記事を読むとわかること

• 環境変数の基本的な仕組みとメリット
• Rails本番環境での環境変数の代表的な設定方法
• 実務でよく利用されるパターンとセキュリティ上の注意点
• Dockerなど複数の環境を扱う場合のポイント
• 運用・管理のコツやアプリケーションを安全に保つための考え方

環境変数とは

環境変数とは、プログラムが動作する際に外部から与えられる変数のことです。
具体的には、オペレーティングシステムやシェルなどに値を設定しておき、それをアプリケーション側で読み取ることで設定を使い分けられる仕組みを指します。
Railsを含む多くのアプリケーションは、この環境変数を読み込んで接続情報や機能の有効/無効などを切り替えます。

環境変数を使う大きなメリットの一つは、ソースコードに秘密情報や環境固有の設定を埋め込まなくて済むことです。
例えば、本番環境でだけ別のデータベースを使いたい場合、ソースコードに直書きすると誰でもその情報にアクセスできてしまいます。
しかし、環境変数として外部から渡すようにすれば、ソースコードと機密情報を切り離して管理できます。
結果的にセキュリティリスクが下がり、同じコードベースで複数の環境を運用できるようになります。

また、他のメリットとして設定ファイルを増やさずに済む点が挙げられます。
たとえば開発環境やテスト環境、本番環境それぞれで別の設定が必要な場合、環境変数をうまく使えばファイルを複数作らなくても一元的に管理しやすくなります。

Rails本番環境での環境変数設定が重要な理由

本番環境は、実際にユーザーがアクセスする環境です。
外部のサービスと連携するAPIキーや機密情報が増えるうえに、もし設定を誤ればアプリケーションが動かなくなるリスクもあります。
そのため、本番特有の情報は安全かつ確実に取り扱わなければなりません。

Railsアプリケーションでは、デフォルトで開発・テスト・本番といった複数の環境が用意されています。
実務上、本番環境だけで追加される設定も少なくありません。
たとえばメール送信の認証情報、決済サービスのキー、SNS連携のコールバックURLなど、それぞれ環境変数として別々に管理しないと、万が一ソースコードに埋め込んでしまえば誰でも閲覧できる状態となってしまいます。

一方で、ソースコードから設定を切り離す手段としては、単純にYAMLファイルやRubyファイルへ書くやり方も考えられます。
しかしこうした方法は、開発チームのメンバーが誤ってコードをリポジトリにコミットしてしまうリスクを高める可能性があります。
このようなリスクを回避するためにも、Railsでは本番環境の設定を環境変数で管理することが強く推奨されます。

また、継続的に本番環境を運用・更新していくうえでの利便性にも注目しましょう。
環境変数であれば、サーバー上の設定だけを変更すればよく、ソースコードのデプロイをやり直す必要がありません。
結果的にリリース作業がスムーズになり、ダウンタイムを最小化できます。

実務でよく利用するパターン

本番環境でRailsが使用する環境変数には、さまざまな種類があります。
ここでは代表的な3つの利用例を挙げてみます。

データベースの接続情報

本番環境のデータベース名、ユーザー名、パスワード、ホスト情報などを、ENV["DATABASE_NAME"] などの形で環境変数に格納するケースです。
これによりリポジトリ上の database.yml に秘密情報を直接記載せずに済みます。

APIキーや外部サービスの認証情報

サードパーティのサービスと連携するときに必要なキーやシークレット情報を環境変数に入れておくやり方です。
例えば、決済サービスやSNS連携などが典型例です。
安全性が求められるため、ソースコードから切り離して管理する必要があります。

Railsのログやメール設定

Railsのログレベルやメール送信時のSMTPサーバー情報を環境変数で制御することも多いです。
ログの保存先やメール送信ドメインなども本番環境と開発環境で別々に設定したいケースがあります。

Railsでの環境変数の管理方法の全体像

Railsでは、環境変数を読み込む仕組み自体は標準のRuby機能（ENVハッシュ）に頼っているため、基本的にはOS側で設定された値を取得します。
それをさらに便利に扱うため、以下のようなパターンがよく利用されます。

1. OSの環境変数として直接設定する

サーバーやホスティング環境で export KEY=VALUE のように設定し、Railsからは ENV["KEY"] で利用するパターンです。

2. Railsのcredentialsやsecretキーを利用する

公式が用意するファイル暗号化の仕組みを使って、本番環境の秘密情報を扱う方法です。
実務でもセキュアな管理方法として活用されます。

3. dotenv-railsなどのGemを利用する

.env ファイルに設定を記述し、それをRails起動時に読み込むという流れです。
ただし、本番環境で .env ファイルを管理する際は注意が必要です。

どの手法を選ぶかは、デプロイ先のサーバー環境や運用体制によって異なります。
例えばHerokuのようなPaaSでは、アプリケーションのダッシュボードから環境変数を設定するパターンが主流です。
一方で自社サーバーやクラウド上の仮想マシンで運用する場合には、OSの設定やコンテナオーケストレーションの仕組み（DockerやKubernetesなど）と連携するケースが多いでしょう。

パターン1 OSの環境変数として設定する

最もシンプルな方法が、OS上の環境変数として直接設定するパターンです。
たとえば、Linux系サーバーであれば、/etc/environment や ~/.bash_profile などへ export 文を書くことで環境変数を設定します。

メリット

• シンプルで余計なGemや設定ファイルが不要
• OS単位で管理できるため、アプリケーション側のファイルに漏れずセキュア

注意点

• サーバーごとに環境変数を管理する必要があり、複数のサーバーを運用する場合は設定の同期が難しくなる
• デプロイのたびに変更がある場合は手間がかかるため、自動化が必須になることが多い

実際の運用では、CI/CDパイプラインを導入しているチームならば、デプロイ前のスクリプトで環境変数を設定する手法と組み合わせる場合もあります。

パターン2 Railsのcredentialsを利用する

Railsには、本番環境などで使う機密情報を暗号化して管理できる仕組みがあります。
config/credentials.yml.enc や config/master.key というファイルを見かけたことがある方も多いでしょう。
この仕組みを利用すれば、ソースコード上には暗号化されたファイルのみが残り、Gitリポジトリに平文でキー情報が載るリスクを下げられます。

使い方の概要

• Railsプロジェクト内で bin/rails credentials:edit を実行
• エディタが開き、YAML形式で秘密情報を追記
• 保存すると暗号化され、config/credentials.yml.enc に書き込まれる

本番環境では config/master.key を渡すことで復号が可能になり、Railsからは Rails.application.credentials.xxxx の形で値を取得できます。
xxxx の部分が設定したキー名です。

メリット

• Rails公式の暗号化機能で安全に情報を保管できる
• Gitリポジトリに鍵（master.key）を含めなければ、万が一漏れても暗号化されているので被害を最低限に抑えられる

注意点

• 本番環境に master.key を渡すタイミングをどうするか設計が必要
• 仕組み自体をチームで理解していないと、復号や編集が難しくなりがち

パターン3 dotenv-railsなどのGemを利用する

dotenv は、.env ファイルに記述した値を環境変数として読み込むための仕組みです。
Rails用としては dotenv-rails というGemがよく利用されます。
開発環境やテスト環境での設定は .env.development や .env.test とファイルを分けて管理できるため、チーム内で手軽に導入しやすいです。

ただし、本番環境で .env ファイルを運用する際は要注意です。
Git管理から外していても、サーバー上にそのまま平文で置かれるわけですから、サーバーにアクセスできる人なら誰でも中身が読めてしまいます。
そのため、本番環境ではさらなるセキュリティ対策が必要になるケースが多いです。
たとえばサーバー全体のアクセス制御を強化したり、.env ファイルを暗号化して管理したり、あるいはそもそも本番環境ではdotenvを使わないなどの工夫が求められます。

具体的な設定手順の例

ここでは、OSの環境変数としてデータベース情報を設定し、Railsの database.yml から読み取る基本的な例を紹介します。

OS側で環境変数を設定

Linux系の例として、.bash_profile や ~/.bashrc に以下のように記述します。

コピー
export DATABASE_NAME=my_production_db
export DATABASE_USER=my_user
export DATABASE_PASS=my_password
export DATABASE_HOST=127.0.0.1

書き終えたらターミナルを再起動するか、 source ~/.bashrc のように読み込み直せば有効になります。

database.ymlでの設定

次に、Railsプロジェクトの config/database.yml に以下のように記述します。

コピー
production:
  adapter: postgresql
  encoding: unicode
  database: <%= ENV["DATABASE_NAME"] %>
  username: <%= ENV["DATABASE_USER"] %>
  password: <%= ENV["DATABASE_PASS"] %>
  host: <%= ENV["DATABASE_HOST"] %>

この例では、 ENV["DATABASE_NAME"] などの変数を通じてOS側の値を取得する仕組みになっています。
あとはRailsが起動するときに、設定した環境変数が自動で読み込まれます。

実務で気をつけたいセキュリティ面

本番環境の環境変数で扱う情報は、サービスの根幹を揺るがすような大切なデータが含まれる可能性があります。
たとえばデータベースのパスワードや決済サービスの秘密鍵などが漏れると、取り返しのつかない被害を生むかもしれません。
以下のポイントに注意しましょう。

外部への公開リポジトリに含めない

誤って環境変数が書かれたファイルをGitリポジトリに含めたまま公開してしまう事例は後を絶ちません。
.gitignore などで .env などを除外するのはもちろん、credentialsやマスターキーも含めて、秘匿ファイルの取り扱いルールをチームで決めておくと良いです。

アクセス権限を最小限に

サーバー内に環境変数を設定する場合は、そのサーバーへのSSHアクセス権限を厳格に管理します。
また、デプロイ時の自動化ツールでキーを設定する際にも、担当者以外が編集できないように制限することが重要です。

ログ出力に注意

万が一Railsのログやコンソールで環境変数の値を出力してしまうと、それがログファイルに残り第三者に閲覧されるかもしれません。
デバッグ時に puts ENV["KEY"] のようなコードを残しておかないよう注意しましょう。

デプロイ環境ごとの設定を整理する

本番環境だけではなく、ステージング環境や開発環境など、複数の環境を運用する場合は多いものです。
それぞれに異なるAPIキーやデータベース名が必要になる場合、以下のようなルールで運用すると管理しやすくなります。

環境ごとにプレフィックスをつける

例: PROD_DATABASE_NAME、STG_DATABASE_NAME、DEV_DATABASE_NAME

• 環境ごとに.envファイルやRailsのcredentialsを分ける
• CI/CDパイプラインのステージごとに設定ファイルを切り替える

どの方法を選んでも、本番環境とステージング環境が混在しないようにしっかりと区別することがポイントです。
誤ってステージングのキーを本番に使ってしまうとサービスが動かなくなったり、データが混ざってトラブルが発生する恐れがあります。

Dockerを使った本番環境での設定例

Dockerコンテナを使って本番環境を構築する際も、環境変数は重要な役割を果たします。
Dockerイメージをビルドしたあと、実行時にコンテナへ環境変数を渡すことが一般的です。

Docker Composeを利用する場合

docker-compose.yml で environment セクションを使い、設定を記述するか、 .env ファイルを読み込む方法がよくあります。
以下はイメージ例です。

コピー
version: "3"
services:
  web:
    build: .
    environment:
      - DATABASE_NAME=${DATABASE_NAME}
      - DATABASE_USER=${DATABASE_USER}
      - DATABASE_PASS=${DATABASE_PASS}
      - DATABASE_HOST=${DATABASE_HOST}
    ports:
      - "3000:3000"
    command: bundle exec rails s -e production

この例では、.env ファイルに書かれた値を docker-compose.yml 内で展開し、コンテナへ受け渡しています。
ただし本番環境では .env ファイルをどこまで安全に扱うか慎重に検討しましょう。

Dockerfile内での設定

本番でDockerfileを直接使う場合でも、ビルド時には環境変数をハードコードしない方が望ましいです。
可能な限りビルド済みイメージは共通にしておき、実行時の docker run -e "KEY=VALUE" の形で渡すと、イメージに機密情報を含めず済みます。

もし複数の環境がある場合の整理方法

大規模なアプリケーションや複数のクライアント向けにRailsをホスティングするケースでは、環境変数が多くなりがちです。
この場合、OS側のファイルやDocker Composeの設定が煩雑になってしまうことがあります。

例えば以下のような方法で対応すると、設定の重複やミスが減る傾向にあります。

ディレクトリ構造で管理

サービスごとにフォルダを分け、envファイルを用途別に整理

設定管理ツールの導入

ChefやAnsible、Terraformのようにサーバー構成管理やインフラ構成管理を自動化するツールを使い、環境変数もまとめて記述

クラウドのSecret Managerサービスを利用

AWSやGCPなどのクラウドでは、Secret Managerなどの機能を使って機密情報を集中管理する方法が考えられます

Rails側では、どの環境変数が必要なのかをドキュメント化しておくことも重要です。
アプリケーションをアップデートした際に新しいキーが追加されることもあるので、更新履歴を追える形にしておくとメンテナンス性が高まります。

運用・管理のポイント

本番環境で安全に運用するためには、日々の管理やチーム体制も含めた運用フローを整えることが大切です。
最後に、管理面のポイントをいくつか整理してみましょう。

定期的な見直し

新しい機能を追加してAPIキーを増やしたり、サードパーティのサービスを変更したりすると、環境変数も更新が必要です。
その都度チーム内で「どこに、何のキーを、どのように設定したか」を共有し、定期的に見直す習慣をつけると良いでしょう。

鍵のローテーション

もし鍵情報やパスワードが漏洩してしまったら、即座にローテーション（再発行）できるように準備しておくと安心です。
たとえば発行元のサービスで新しいトークンを取得して、環境変数を更新し、古いトークンは失効させる流れをスムーズに行えるかどうか検討しておきましょう。

自動テストでの確認

環境変数が欠けている、あるいは値がおかしいといった状態でRailsが正しく動作するか、事前にテストを実行しておくと大きな障害を回避できます。
本番リリース前に最低限のテスト項目を用意し、環境変数の存在や型チェックを行うのも有効です。

まとめ

Rails本番環境での環境変数の設定は、セキュリティの確保と運用の効率化の両面で欠かせない要素です。
環境変数の基本を理解し、OSレベルで設定するパターン、Railsのcredentialsを利用するパターン、dotenvのようなGemを使うパターンなど、それぞれの特性や注意点を踏まえて自分たちのプロジェクトに合った方法を選択しましょう。

本番環境では機密情報を扱うことが多いため、ソースコードへの書き込みは厳禁です。
また、複数環境にまたがる運用では、設定の重複や混乱が起こりがちなので、仕組みづくりや管理ルールの策定が重要になります。
運用段階でも、定期的な見直しやキーのローテーションを実施しながら、日々のデプロイにおいてセキュリティリスクを最低限に抑えていく必要があります。

環境変数を適切に扱えば、Railsアプリケーションは安全かつ柔軟に動作しやすくなります。
初心者の皆さんはまずはシンプルな手法から始め、徐々にチームやインフラに合わせた最適な管理手法を模索してみてください。