実務用語集
意味を知っているだけでは面接では足りません。各用語に「面接での使い方」の例文を 添えています。全 41 語。
コントローラーに業務ロジックを詰め込みすぎて肥大化した状態を指す、避けるべきアンチパターンです。コントローラーは本来「リクエストを受け取り、処理を適切な場所に振り分け、レスポンスを返す」交通整理役に徹するべきで、金額計算や在庫チェックといった業務ルールまで抱えると、テストしづらく再利用もできず、修正の影響範囲も読めなくなります。ロジックをサービス層やモデルへ切り出して薄く保つのが定石です。
🎤 面接での使い方
コントローラーに業務ロジックを書きすぎるとFat Controllerになり保守しづらくなるので、処理はサービス層に切り出してコントローラーは薄く保つよう意識しています。
アプリケーションを Model（データと業務ロジック）・View（画面表示）・Controller（両者の仲介）の3つの役割に分けて設計する考え方です。役割ごとに責務を分離することで、画面を変えてもデータ処理に影響が出ない、ロジックを個別にテストできる、といった保守性が得られます。Laravelはこの構造を前提にしており、Eloquentが Model、Bladeが View、Controllerクラスが Controller に対応します。
🎤 面接での使い方
LaravelはMVCが基本で、Modelがデータ、Viewが表示、Controllerがその仲介という役割分担だと理解しています。責務を分けることで保守しやすくなる設計だと考えています。
コントローラーとモデルの間に置く、業務ロジック専用の層です。「注文を確定する」「ポイントを付与する」といった複数の処理をまとめた手続きを、専用のサービスクラスに集約します。こうすることでコントローラーが薄くなり、同じロジックを複数の画面やAPIから再利用でき、業務ルールだけを対象にテストを書けるようになります。ロジックの置き場所を明確にすることで、チーム開発でも修正箇所が探しやすくなります。
🎤 面接での使い方
業務ロジックはサービス層にまとめることで、コントローラーを薄く保ちつつ処理を再利用しやすくする目的で使います。テストもロジック単位で書きやすくなると理解しています。
クラスが必要とする依存オブジェクトを、開発者に代わって自動的に生成し組み立てて渡してくれる仕組みです。あるクラスが別のクラスを使うとき、自分でnewして用意する代わりに「これが必要」と宣言するだけで、コンテナが適切なインスタンスを注入してくれます。依存関係の管理を一箇所に任せられるため、テスト時に本物の代わりにモックへ差し替えるといった切り替えも容易になります。LaravelのサービスコンテナがこのDIコンテナにあたります。
🎤 面接での使い方
DIコンテナは依存オブジェクトの生成と注入を自動でやってくれる仕組みで、Laravelではサービスコンテナがその役割を担っていると理解しています。
あるクラスが使う別のオブジェクト（依存）を、そのクラス自身が内部で作るのではなく、外から渡してもらう設計手法です。自分でnewしてしまうと相手のクラスと強く結びついてしまいますが、外から受け取る形にしておけば、テスト時に偽物（モック）へ差し替えたり、実装を後から入れ替えたりが簡単になります。疎結合でテストしやすい設計を実現するための基本的な考え方です。
🎤 面接での使い方
依存性注入は依存オブジェクトを外から渡す設計で、クラス同士の結合を弱くしてテストや差し替えをしやすくする目的で使うものだと理解しています。
Laravel特有の書き方で、複雑な仕組みの裏側を隠し、静的メソッドのように短く呼び出せる窓口を提供する機能です。たとえば Cache::get() のような呼び出しは、内部ではサービスコンテナに登録された実体へ橋渡しされています。見た目は静的呼び出しですが実体はコンテナ経由なので、テスト時にはモックへ差し替えることもできます。手軽さと、裏側の差し替えやすさを両立させるための仕組みです。
🎤 面接での使い方
ファサードはCacheやDBのように静的メソッド風に短く書ける窓口で、裏ではサービスコンテナ経由で実体を呼んでいるため、テスト時に差し替えもできると理解しています。
Laravelにおけるクラスの依存関係を管理し、必要なオブジェクトを生成・注入してくれる中核の仕組みで、いわばLaravel版のDIコンテナです。どのインターフェースにどの実装を割り当てるかをあらかじめ登録しておけば、コンストラクタで型を指定するだけで適切なインスタンスが自動で渡されます。アプリ全体の依存の組み立てを一元管理できるため、疎結合な設計とテストのしやすさを支える基盤になっています。
🎤 面接での使い方
サービスコンテナはLaravelが依存関係を管理して自動でインスタンスを注入してくれる仕組みで、コンストラクタで型を指定するだけで使える点が便利だと理解しています。
アプリケーション内で特定のクラスのインスタンスを一つだけ生成し、それを使い回すデザインパターンです。毎回newして作り直す代わりに同じ実体を共有するため、生成コストの高いオブジェクトや、状態を一箇所で管理したいオブジェクトに向いています。Laravelのサービスコンテナでは singleton として登録することで、そのクラスをアプリ内で常に同一インスタンスとして注入させることができます。
🎤 面接での使い方
シングルトンはインスタンスを一つだけ作って使い回すパターンで、Laravelではサービスコンテナにsingletonとして登録することで実現できると理解しています。
データの取得や保存の処理を専用のクラス（リポジトリ）にまとめ、業務ロジック側からはデータの保存先を意識せずに扱えるようにする設計パターンです。コントローラーやサービスが直接Eloquentを叩く代わりにリポジトリ越しにやり取りすることで、データアクセスの実装が一箇所に集約され、テスト時にデータ層を差し替えやすくなります。ただし小規模では過剰になることもあり、採用は規模とのバランスで判断します。
🎤 面接での使い方
リポジトリパターンはデータアクセス処理を専用クラスに集約する設計で、業務ロジックを保存先の詳細から切り離してテストしやすくする目的で使うものだと理解しています。
データベースの1行を1つのオブジェクトに対応させ、そのオブジェクト自身が保存や更新、検索といったデータ操作のメソッドを持つ設計パターンです。$user->save() のように、モデルオブジェクトが直接自分をデータベースに反映できます。直感的で書きやすい反面、データと業務ロジックが同じクラスに集まりやすい特徴があります。LaravelのEloquentはこのアクティブレコード方式を採用しています。
🎤 面接での使い方
アクティブレコードはDBの1行をオブジェクトに対応させ、そのオブジェクトが保存や検索のメソッドを持つ方式で、LaravelのEloquentがこれを採用していると理解しています。
Object-Relational Mapping の略で、データベースのテーブルやレコードをプログラム上のオブジェクトとして扱えるようにする仕組みです。SQLを直接書く代わりに、オブジェクトのメソッドやプロパティ経由でデータを操作できるため、コードが読みやすくなり、データベースの種類の違いも吸収しやすくなります。LaravelではEloquentがORMにあたります。便利ですが、裏で発行されるSQLを意識しないとN+1問題などの性能劣化を招く点には注意が必要です。
🎤 面接での使い方
ORMはDBのテーブルをオブジェクトとして扱えるようにする仕組みで、SQLを直接書かずに操作できる反面、裏のクエリを意識しないと性能問題が出ると理解しています。
同じ操作を何度繰り返しても、結果が1回実行したときと変わらない性質のことです。たとえば「この注文を確定する」という処理に冪等性があれば、通信エラーでユーザーが二度送信してしまっても、注文が二重に作られることはありません。ネットワークの再送やキューの再実行が起こりうる場面で、二重処理を防ぐために重要な考え方で、一意キーやステータス判定を使って実現します。
🎤 面接での使い方
冪等性は同じ処理を何度実行しても結果が変わらない性質で、二重送信や再送による二重登録を防ぐために意識すべき考え方だと理解しています。
Laravelに標準で付属するコマンドライン実行ツールです。php artisan という形で呼び出し、コントローラーやモデルといったファイルの雛形生成、マイグレーションの実行、キャッシュのクリア、ルート一覧の確認など、開発に必要な多くの作業をコマンド一つで行えます。手作業を減らして定型作業を自動化できるため、開発効率とチーム内での手順の統一に役立ちます。独自コマンドを追加することもできます。
🎤 面接での使い方
Artisanはphp artisanで使うLaravel標準のコマンドツールで、ファイルの雛形生成やマイグレーション実行など定型作業を効率化する目的で使うと理解しています。
Laravelに標準搭載されているORMで、データベースのテーブルをモデルクラスとして扱えるようにします。User::find(1) や $user->save() のように、SQLを書かずに直感的なメソッドでデータを取得・保存できます。テーブル間の関連もリレーションとして定義でき、関連データも簡単にたどれます。アクティブレコード方式を採用しており書きやすい一方、便利さゆえにN+1問題など発行クエリへの意識を怠りやすい点には注意します。
🎤 面接での使い方
EloquentはLaravel標準のORMで、SQLを書かずにモデル経由でデータを操作できる仕組みです。便利ですがN+1問題には注意が必要だと理解しています。
Laravelに付属するテンプレートエンジンで、HTMLの中にデータの埋め込みや条件分岐、繰り返しを簡潔に書けるようにするものです。二重波括弧の記法で変数を出力でき、その際に自動でエスケープ処理が行われるためXSS対策になります。レイアウトの共通化やコンポーネント化の仕組みも備えており、画面の重複を減らせます。MVCのViewを担う部分で、表示ロジックを整理して書くのに使います。
🎤 面接での使い方
BladeはLaravelのテンプレートエンジンで、HTMLに変数や分岐を書け、出力時に自動エスケープされるためXSS対策になる点が特徴だと理解しています。
データベースのテーブル構造の変更を、PHPのコードとしてファイルに記録し、コマンドで適用・巻き戻しできる仕組みです。「usersテーブルにカラムを追加する」といった変更を手作業でDBに加える代わりにマイグレーションファイルで管理するため、変更履歴がGitに残り、チーム全員が同じ手順で同じDB構造を再現できます。環境ごとのDBのズレを防ぎ、変更を安全にやり直せる点が大きな利点です。
🎤 面接での使い方
マイグレーションはDBの構造変更をコードで管理する仕組みで、変更履歴を残しチーム全員が同じDB構造を再現できるようにする目的で使うと理解しています。
データベースに初期データやテスト用のダミーデータをまとめて投入するための仕組みです。開発を始めるときに必要なマスタデータや、動作確認用のサンプルレコードをコードとして定義しておき、コマンドで一括登録できます。手作業でデータを入れ直す必要がなくなり、チーム内で同じ状態のデータを再現できるため、開発やテストの環境を揃えるのに役立ちます。マイグレーションと組み合わせて使うのが一般的です。
🎤 面接での使い方
シーダーは初期データやテスト用データをコードで一括投入する仕組みで、チーム内で同じデータ状態を再現して開発やテストを揃える目的で使うと理解しています。
リクエストがコントローラーに届く前、あるいはレスポンスが返る前に、共通の処理を挟み込むための仕組みです。ログインしているかの認証チェック、CSRFトークンの検証、アクセスログの記録などを、各コントローラーに書く代わりにミドルウェアとして一箇所にまとめられます。処理をパイプラインのように連ねられるため、横断的な関心事をコントローラーから分離でき、コードの重複を防いで見通しをよくできます。
🎤 面接での使い方
ミドルウェアはリクエストがコントローラーに届く前に共通処理を挟む仕組みで、認証チェックなどの横断的な処理を一箇所にまとめる目的で使うと理解しています。
URLに含まれるIDから対応するモデルを、Laravelが自動で取得してコントローラーに渡してくれる機能です。たとえば /users/1 というルートで、コントローラーの引数に User 型を指定しておくと、ID=1のUserが自動で検索されて渡されます。存在しなければ自動で404を返してくれます。自分でfindして存在チェックする定型コードを省けるため、コントローラーが簡潔になり、記述漏れによるバグも防げます。
🎤 面接での使い方
ルートモデルバインディングはURLのIDから対応するモデルを自動取得してコントローラーに渡す機能で、findと存在チェックの定型コードを省けると理解しています。
入力値のバリデーションルールと認可のチェックを、専用のリクエストクラスにまとめる仕組みです。コントローラーの中でバリデーションを書く代わりにFormRequestに切り出すことで、コントローラーが本来の処理に集中でき、同じ検証ルールを複数箇所で再利用できます。検証に通らなければ自動でエラーを返してくれるため、コントローラーには「検証済みの安全なデータ」だけが渡ってきます。責務分離とコントローラーの軽量化に役立ちます。
🎤 面接での使い方
FormRequestはバリデーションと認可を専用クラスに切り出す仕組みで、コントローラーを薄く保ちつつ検証ルールを再利用しやすくする目的で使うと理解しています。
ユーザーから送られてきた入力値が、想定した形式や条件を満たしているかを検証する処理です。必須項目が入っているか、メールアドレスの形式か、文字数は適切かなどをルールとして定義し、満たさない場合はエラーメッセージを返します。不正なデータや欠けたデータがそのまま処理やDBに流れ込むのを防ぐ、安全性の要となる仕組みです。Laravelではルールを宣言的に書け、FormRequestに切り出して整理することもできます。
🎤 面接での使い方
バリデーションは入力値が想定した形式や条件を満たすか検証する処理で、不正なデータが処理やDBに入るのを防ぐために必ず行うべきものだと理解しています。
ユーザーからのリクエストがLaravelに届いてからレスポンスを返すまでに、どんな順序で処理が流れていくかという一連の流れを指します。エントリーポイントを通り、フレームワークが起動し、ミドルウェアを通過し、ルーティングで対応するコントローラーが呼ばれ、結果がレスポンスとして返されます。この流れを理解しておくと、認証をどこで挟むか、エラーがどの段階で起きているかを判断でき、問題の切り分けや設計の見通しがよくなります。
🎤 面接での使い方
リクエストライフサイクルはリクエストが届いてからレスポンスを返すまでの処理の流れで、これを理解すると認証を挟む場所や不具合の切り分けがしやすくなると考えています。
PHPのパッケージ（ライブラリ）を管理するツールで、Laravel本体や外部ライブラリの導入・更新・依存関係の解決を自動で行ってくれます。必要なパッケージとそのバージョンを設定ファイルに記録しておくことで、チームの誰が環境を作っても同じ組み合わせのライブラリを再現できます。npmのPHP版と考えると分かりやすく、Laravelプロジェクトを始める際にも欠かせない基盤ツールです。
🎤 面接での使い方
ComposerはPHPのパッケージ管理ツールで、ライブラリの導入や依存解決を自動化し、チーム全員が同じライブラリ構成を再現できるようにするものだと理解しています。
php artisan tinker で起動する、Laravelの対話型実行環境です。アプリの設定を読み込んだ状態でPHPコードを1行ずつ試せるため、Eloquentでデータを取得して中身を確認したり、書いたロジックの挙動をその場で検証したりできます。わざわざ画面を作らなくても動作を確かめられるので、開発中の動作確認やデバッグ、データの調査に便利です。本番データを扱う際は操作に注意が必要です。
🎤 面接での使い方
Tinkerはphp artisan tinkerで起動する対話型環境で、Eloquentの挙動やロジックをその場で試して確認できるため、開発中のデバッグに便利だと理解しています。
時間のかかる処理を後回しにして、リクエストのレスポンスを速く返すための仕組みです。メール送信や画像処理といった重い処理をその場で実行する代わりに、ジョブとしてキューに積んでおき、裏側のワーカーが順番に処理します。ユーザーを待たせずに応答でき、大量の処理も分散して捌けます。ただし失敗時の再実行が起こりうるため、同じジョブが二度実行されても問題ないよう冪等性を意識した設計が求められます。
🎤 面接での使い方
キューは重い処理をジョブとして積んで裏で非同期に実行する仕組みで、レスポンスを速く返す目的で使い、再実行に備えて冪等性を意識すべきだと理解しています。
クロスサイトリクエストフォージェリという攻撃を防ぐための仕組みです。これは、ログイン中のユーザーが気づかないうちに悪意あるサイトから不正なリクエストを送らされてしまう攻撃です。Laravelはフォーム送信時に予測不能なトークンを埋め込み、サーバー側でそれを検証することで、正規の画面から来たリクエストだけを受け付けます。Bladeでトークンを出力し、ミドルウェアが自動で検証するため、開発者は仕組みを理解して正しく組み込むことが重要です。
🎤 面接での使い方
CSRF保護はログイン中のユーザーになりすました不正リクエストを防ぐ仕組みで、Laravelがトークンを埋め込んで検証してくれると理解しています。
フォームなどから送られてきた複数の入力値を、一括でモデルに割り当てて保存する便利な機能です。ただし、無防備に使うと、ユーザーが本来変更できないはずの項目（たとえば権限フラグ）まで書き換えられてしまう脆弱性につながります。Laravelでは fillable で更新を許可するカラムを明示するか、guarded で保護するカラムを指定することで、この危険を防ぎます。便利さと安全性を両立させるために、許可範囲を明確にすることが重要です。
🎤 面接での使い方
マスアサインメントは入力値を一括でモデルに割り当てる機能ですが、fillableで許可項目を明示しないと想定外の値まで書き換えられる危険があると理解しています。
テーブル同士のつながりを、Eloquentのモデル上でメソッドとして定義する機能です。たとえばユーザーが複数の投稿を持つといった関係を hasMany や belongsTo として書くと、$user->posts のように関連するデータを簡単にたどれます。SQLの結合を意識せずに関連データを扱える一方で、繰り返し呼ぶとN+1問題を招きやすいため、必要な関連はEager Loadingでまとめて取得する配慮が求められます。
🎤 面接での使い方
リレーションはテーブル同士のつながりをモデル上で定義する機能で、関連データを簡単にたどれる反面、N+1問題を避けるためEager Loadingを併用すべきだと理解しています。
レコードを実際にデータベースから消すのではなく、削除された日時を記録することで「削除済み」として扱う仕組みです。Laravelでは deleted_at カラムを使い、通常の検索からは自動的に除外されつつ、データ自体は残ります。誤って消してしまったデータを復元できたり、削除の履歴を追えたりするため、重要なデータの扱いで安全性が高まります。物理削除に比べてテーブルが肥大化しやすい点は運用上考慮します。
🎤 面接での使い方
ソフトデリートはデータを物理削除せずdeleted_atで削除済みとして扱う仕組みで、誤削除の復元や履歴確保のために使うものだと理解しています。
複数のデータベース操作を一つのまとまりとして扱い、すべて成功したときだけ確定し、途中で失敗したらすべてなかったことにする仕組みです。たとえば「口座Aから引いて口座Bに足す」処理は、片方だけ成功すると残高が狂うため、両方まとめて成功か失敗かにする必要があります。この全か無かの保証により、データの整合性を保てます。Laravelでは処理をトランザクション内で囲むことで、途中でエラーが出たら自動で巻き戻せます。
🎤 面接での使い方
トランザクションは複数のDB操作を一まとめにして、全部成功か全部取り消しかを保証する仕組みで、データの整合性を守るために使うものだと理解しています。
トランザクションが信頼できるために備えるべき4つの性質の頭文字です。原子性（Atomicity＝全か無か）、一貫性（Consistency＝ルールを壊さない）、独立性（Isolation＝同時実行しても互いに干渉しない）、永続性（Durability＝確定したら消えない）を指します。これらが保証されることで、複数人が同時に操作したり途中で障害が起きたりしても、データが矛盾した状態にならずに済みます。データベースの信頼性を語るうえでの基本用語です。
🎤 面接での使い方
ACIDは原子性・一貫性・独立性・永続性の4つの性質で、トランザクションが信頼できる形でデータの整合性を保つための基本条件だと理解しています。
「同時に更新される衝突が起きるだろう」と悲観的に想定し、データを読む段階でロックをかけて、他の人が触れないようにしてから処理する方式です。在庫数のように、少しの同時更新でも狂うと困るデータで使われます。確実に競合を防げる一方で、ロックしている間は他の処理が待たされるため、性能面の負荷やデッドロックのリスクがあります。トランザクションの中で対象行を確保して使うのが典型です。
🎤 面接での使い方
悲観ロックは更新の衝突を想定して先に行をロックし他者に触らせない方式で、在庫のような競合が致命的なデータに使うものだと理解しています。
「衝突はめったに起きないだろう」と楽観的に考え、通常はロックせずに処理を進め、更新の直前に「読んだときから変わっていないか」を確認する方式です。多くはバージョン番号や更新日時の列を使い、他人が先に更新していたら失敗させてやり直させます。ロックしない分だけ同時実行の性能に優れますが、衝突時のリトライ処理を用意しておく必要があります。競合が少ない場面に向いた方式です。
🎤 面接での使い方
楽観ロックはロックせず進めて更新直前にバージョンで変更を検知する方式で、競合が少ない場面で性能を保ちつつ衝突を防ぐために使うと理解しています。
一覧のデータをまず1回のクエリで取得し、そのあと各要素の関連データを1件ずつ取りにいくことで、合計で N+1 回もクエリが発行されてしまう性能問題です。たとえば10人のユーザーとその所属部署を表示する際、ユーザー取得の1回に加えて部署を10回引くと計11回になります。件数が増えるほどクエリ数が膨れ上がり、表示が遅くなります。関連を事前にまとめて取るEager Loadingで解消するのが定石です。
🎤 面接での使い方
N+1問題は一覧取得後に関連データを1件ずつ引いてクエリが大量に発行される性能問題で、Eager Loadingでまとめて取得して解消すると理解しています。
関連するデータを、あとから1件ずつ取りにいくのではなく、最初にまとめて取得しておく手法です。LaravelのEloquentでは with を使い、ユーザー一覧を取るのと同時にそれぞれの関連データも少ないクエリでまとめて読み込めます。これによりN+1問題を防ぎ、クエリ数を大幅に減らして表示を高速化できます。関連データを使うことが分かっている一覧表示などで、あらかじめ読み込んでおくのが効果的です。
🎤 面接での使い方
Eager Loadingは関連データを最初にまとめて取得する手法で、withを使ってN+1問題を防ぎクエリ数を減らし表示を高速化する目的で使うと理解しています。
PHPのコードの書き方を統一するために定められた、コーディングスタイルの標準規約です。インデントの取り方、波括弧の位置、命名の作法などを共通ルールとして定めており、これに従うことで誰が書いてもコードの見た目が揃います。スタイルが統一されると、レビューで本質的な議論に集中でき、他人のコードも読みやすくなります。チーム開発では自動整形ツールと組み合わせて、規約を機械的に守らせるのが一般的です。
🎤 面接での使い方
PSR-12はPHPのコーディングスタイル標準で、これに従うと書き方が揃ってレビューや可読性が向上するため、チーム開発で守るべきものだと理解しています。
これまで正常に動いていた機能が、別の修正や機能追加をきっかけに壊れてしまう現象、いわゆる「デグレ（後戻り）」のことです。一箇所を直したつもりが、思わぬところに影響して既存の動作を崩してしまうことがあります。これを防ぐには、変更のたびに既存機能が壊れていないかを確認する必要があり、自動テストを用意しておくことでリグレッションを早期に検知できます。安全に変更を重ねるうえで避けたい事象です。
🎤 面接での使い方
リグレッションは修正が原因で既存機能が壊れる現象で、これを防ぐために自動テストを用意して変更のたびに既存動作を確認すべきだと理解しています。
Gitを使ったチーム開発で、ブランチをどう分けてどう合流させるかを決めた運用ルールの一つです。本番用のブランチ、開発用のブランチ、機能ごとの作業ブランチなどを役割で分け、決まった流れでマージしていきます。ルールを共有することで、複数人が並行して作業しても混乱せず、リリースの管理や不具合の切り分けがしやすくなります。プロジェクトの規模に応じて、より簡素なブランチ戦略が選ばれることもあります。
🎤 面接での使い方
Gitフローはブランチの役割と合流の流れを決めた運用ルールで、複数人が並行開発しても混乱せずリリースを管理できるようにするものだと理解しています。
書いたコードを、マージ前に他のメンバーが読んで確認するプロセスです。バグや設計の問題を早い段階で見つけられるだけでなく、命名や書き方の統一、知識の共有にもつながります。指摘は個人への批判ではなくコードをよくするための対話であり、なぜその実装にしたかを説明できることも大切です。多くのチームではプルリクエストを通じてレビューを行い、承認を得てからマージする流れをとっています。品質を保つ要の一つです。
🎤 面接での使い方
コードレビューはマージ前に他の人がコードを確認する工程で、バグの早期発見や書き方の統一、知識共有につながる大切なプロセスだと理解しています。
コードが期待どおりに動くかを自動で検証する仕組みです。関数やクラスといった小さな単位を対象にするのが単体テスト、リクエストから一連の動作をまとめて確認するのがFeatureテストで、Laravelは両方を書ける環境を備えています。テストを用意しておくと、修正のたびに既存機能が壊れていないかをすぐ確認でき、リグレッションを防げます。安心してコードを変更し続けるための土台であり、チーム開発では重視されます。
🎤 面接での使い方
テストはコードが期待通り動くか自動で確認する仕組みで、単体テストとFeatureテストを書いておくと修正時のリグレッションを防げると理解しています。
データベースの接続情報やAPIキーといった、環境ごとに異なる設定や秘密の値を、コードとは別のファイルにまとめて管理する仕組みです。Laravelでは .env ファイルに記述し、これはGitの管理対象から外すことで、パスワードなどの機密情報がリポジトリに漏れるのを防ぎます。開発・本番など環境ごとに値を変えられるため、同じコードのまま接続先を切り替えられます。設定を安全に分離するための基本的な仕組みです。
🎤 面接での使い方
環境変数はDB接続情報やAPIキーなど環境ごとに異なる値を.envに分離する仕組みで、Git管理から外して機密情報の漏洩を防ぐ目的で使うと理解しています。