【Laravel】configと.envの使い分け
はじめに
本記事では、 Laravelのconfig
ファイルの設定を管理し活用する具体的な方法を解説していきます。
対象者
-
config
ファイルの使い道を知りたいエンジニア -
config
ファイルと.env
の違いを知りたい方 - Laravelの設定構造を知りたい方
前提知識:Laravelの設定構造
Laravelではアプリケーション設定を2層構造で管理します。
-
.env
:環境ごとに変化する値(パスワード、ホスト名、実行モードなど) -
config/*.php
:アプリ全体に適用する設計レベルの設定(アプリ名、タイムゾーン、DB接続定義など)
.env
に定義された値は、config/
ファイル内でenv()
関数により参照され、それらがconfig()
を通じて全アプリケーションから利用されます。
// .env
APP_NAME=MyApp
// config/app.php
'name' => env('APP_NAME', 'Laravel'),
// コード内で
config('app.name'); // → 'MyApp'
この2層構造により、チームでの環境差分の管理と設定の再利用性が高まります。
config
ファイルと.env
の対比
よく使うLaravelプロジェクトでは、config/
フォルダ内に多数の設定ファイルが用意されています。
ここでは、代表的な設定ファイルと、対応する.env
の設定値を紹介します。
config ファイル例 |
主な役割 |
.env の例 |
---|---|---|
app.php |
アプリケーション名、ロケール、タイムゾーンなど | APP_NAME, APP_ENV, APP_DEBUG |
database.php |
DB接続情報、ドライバ、接続先など | DB_CONNECTION, DB_HOST, DB_DATABASE など |
mail.php |
メール送信設定(SMTPなど) | MAIL_MAILER, MAIL_HOST, MAIL_PORT など |
queue.php |
キューの接続先・ドライバ | QUEUE_CONNECTION |
services.php |
APIキーなど外部サービス連携の情報 | STRIPE_KEY, MAILGUN_DOMAIN など |
logging.php |
ログの保存方法、チャネル設定 | LOG_CHANNEL, LOG_LEVEL |
broadcasting.php |
WebSocketやPusherの設定 | BROADCAST_DRIVER |
auth.php |
ログイン認証のガード・プロバイダ設定 | AUTH_GUARD |
session.php |
セッション保存方法、ライフタイム、ドライバ | SESSION_DRIVER, SESSION_LIFETIME |
cache.php |
キャッシュの保存方式・接続設定 | CACHE_DRIVER, REDIS_HOST など |
これらの.env
の値は、対応するconfig/
ファイルで env('キー名')
の形で参照され、config:cacheを通じてLaravel全体の挙動に影響を与えます。
config
と.env
の設計ポイント5選
ここからは、Laravelにおけるconfig
と.env
の役割分担を踏まえて、設計面でどのように活用していくか5つのポイントを紹介します。
.env
では環境定義、config/
では設計判断をする
1. .env
の値を直接コードで参照するのはNGです。
// 悪い例
if (env('IS_FEATURE_ENABLED')) {
// ...
}
これは config:cache
実行後に参照されなくなるため、本番環境で機能切り替えが効かなくなります。
正しくは config/xxx.php に定義します。
// config/feature.php
return [
'enabled' => env('IS_FEATURE_ENABLED', false),
];
使用側:
if (config('feature.enabled')) {
// ...
}
活用ポイント
-
.env
は実行環境の違いを吸収するためのもの -
config/
はアプリケーション設計上の意志やドメイン設定をする場所
2. ドメイン設定の共通化とテスト容易化
毎回ControllerやServiceに同じ設定値を書き込まないように分離し共通化する
// 書きがちな例
$limit = 30;
$threshold = 0.8;
これらをconfigに分離すると
// config/predict.php
return [
'limit' => 30,
'threshold' => 0.8,
];
// Service内
$limit = config('predict.limit');
メリット
- PHPUnitで設定値をmock可能に
- 複数プロジェクトで同じ設計値を再利用
- コードの見通しが良くなり保守しやすい
3. UI・機能の動的切り替えにも活用できる
ABテスト、UI変更、ロール別UIなど、環境に応じてビューや機能を切り替える場合にもconfigは有効です。
// config/layout.php
return [
'header' => env('APP_LAYOUT_HEADER', 'default'),
];
// view内
@includeIf('layouts.header.' . config('layout.header'))
活用ポイント
- ユーザーセグメント別のレイアウト切り替えにも応用可能
- Viewの分岐ロジックをBlade内に閉じ込められる
config()
は、一度の読み込みで使いまわせる
4. 設定ファイルはLaravel内部で初回読み込み後、キャッシュされます。毎回読み込んでもパフォーマンスには影響しません。
この特性を活かし、設定値をクラス間で「共通リソース」として参照できます。
// config/service.php
return [
'payment' => [
'api_key' => env('PAYMENT_API_KEY'),
],
];
// 任意の場所で
$apiKey = config('service.payment.api_key');
php artisan config:cache
を前提にした設計
5. 本番環境では .env
の読み込みを高速化するため、設定全体を一括でキャッシュする必要があります。
以下のコマンドを実行すると、bootstrap/cache/config.php
というファイルにすべての設定がまとめられて保存されます。
php artisan config:cache
注意点
-
.env
を直接env()
で読むと config:cache で破綻します - テスト環境と本番の設定差分を吸収できる構成にしておく
- 設定を変更後は、忘れずに configキャッシュをクリア・再生成
おわりに
私自身、Laravelを学び始めた当初は.envファイルで設定を完結させるものだと思い込み、config/ディレクトリ配下のファイル群の存在を意識せずに開発を進めていましたが、あるときから、設計と環境の責務を分離する2重の設定構造なのだと理解するようになりました。
本記事を通じて、configファイルが.envとの役割分担によって保守性・拡張性・再利用性を高められることを実感していただけたら幸いです。
株式会社ONE WEDGE
【Serverlessで世の中をもっと楽しく】
ONE WEDGEはServerlessシステム開発を中核技術としてWeb系システム開発、AWS/GCPを利用した業務システム・サービス開発、PWAを用いたモバイル開発、Alexaスキル開発など、元気と技術力を武器にお客様に真摯に向き合う価値創造企業です。
Discussion