ログイン機能があるシステムでは開発時にも毎回ログインするのか？新人エンジニア向けに実務の考え方を解説

こんにちは。ゆうせいです。

今回は、ログイン機能があるシステムを開発するときに、「開発中も毎回ログインするのか？」という疑問について解説します。

新人エンジニアにとって、この疑問はかなり自然です。

ログイン画面を作ったあと、一覧画面、登録画面、編集画面、管理画面などを確認するたびにログインするのは面倒ですよね。

では、開発中はログインを省略してもよいのでしょうか。

結論から言うと、開発時でも「ログインを通して確認すべき場面」と「ログインを省略して効率化してよい場面」があります。

ただし、本番環境でログインを省略できるような作りにしてはいけません。

開発効率のための近道と、セキュリティ事故につながる抜け道は、はっきり分けて考える必要があります。

ログインは何のためにあるのか

まず、ログイン機能の役割を確認しましょう。

ログインは、単に「画面に入るための扉」ではありません。

ログインには、主に次の役割があります。

認証とは、「本人確認」です。

たとえば、社員証を見せて会社に入るようなものです。

認可とは、「権限確認」です。

会社に入れたとしても、社長室やサーバールームに誰でも入れるわけではありませんよね。

システムでも同じです。

一般ユーザー、管理者、営業担当、開発者など、ユーザーの種類によって使える機能が違う場合があります。

開発時にも毎回ログインするべきなのか

開発時に毎回ログインするべきかどうかは、確認したい内容によって変わります。

つまり、「ログインをテストしたい」のか、「ログイン後の機能を開発したい」のかを分けて考える必要があります。

たとえるなら、学校の校門の警備をテストしたいなら、毎回校門を通る必要があります。

でも、教室の机の配置を確認したいだけなら、毎回校門チェックの動作を細かく確認する必要はありません。

ログインも同じです。

実務では毎回手入力でログインし続けるとは限らない

実務の開発現場では、開発中に毎回ユーザーIDとパスワードを手で入力し続けるとは限りません。

なぜなら、開発効率が悪くなるからです。

たとえば、一覧画面のHTMLを少し直して確認するたびに、ログイン画面へ戻され、IDとパスワードを入力していたら、かなり時間がかかります。

そこで、開発環境では次のような工夫をすることがあります。

ここで大事なのは、「ログインを無視する」のではなく、「開発環境だけ安全に効率化する」という考え方です。

やってはいけない危険な省略

新人エンジニアが特に注意すべきなのは、ログインチェックをコメントアウトするようなやり方です。

たとえば、次のような考え方は危険です。

// 開発中だからログインチェックを外しておく
// if (loginUser == null) {
//     return "redirect:/login";
// }

このようにログインチェックをコメントアウトすると、あとで戻し忘れる可能性があります。

本番環境にそのまま反映されたら、ログインしていない人でも画面に入れてしまうかもしれません。

これはかなり危険です。

開発中の楽をするために、セキュリティの穴を作ってはいけません。

ドアの鍵が面倒だからといって、鍵を外して家を建てるようなものです。

開発中は便利かもしれませんが、本番で大事故になります。

おすすめは「環境ごとに設定を分ける」こと

実務では、開発環境、テスト環境、本番環境で設定を分けます。

Spring Bootでは、プロファイルを使って環境ごとの設定を切り替えることがよくあります。

たとえば、開発環境ではdev、本番環境ではprodというプロファイルを使うイメージです。

application-dev.properties
application-prod.properties

開発環境だけログイン補助を有効にし、本番環境では絶対に無効にするようにします。

大切なのは、コードのコメントアウトで切り替えるのではなく、設定で切り替えることです。

Spring Bootで開発用ログインを作る考え方

Spring Bootでログイン機能を作っている場合、開発用ログインを用意することがあります。

ただし、開発用ログインは本番環境で動かないようにする必要があります。

たとえば、開発環境だけ使えるControllerを作るなら、プロファイルで制御します。

package com.example.demo.controller;

import com.example.demo.model.LoginUser;
import jakarta.servlet.http.HttpSession;
import org.springframework.context.annotation.Profile;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;

@Controller
@Profile("dev")
public class DevLoginController {

    @GetMapping("/dev-login")
    public String devLogin(HttpSession session) {

        LoginUser loginUser = new LoginUser();
        loginUser.setUserId(1);
        loginUser.setUserName("開発用ユーザー");
        loginUser.setRole("ADMIN");

        session.setAttribute("loginUser", loginUser);

        return "redirect:/cars";
    }
}

@Profile("dev")は、devプロファイルのときだけ、このControllerを有効にするという意味です。

本番環境でprodプロファイルを使えば、この開発用Controllerは有効になりません。

開発環境でだけ使う裏口を、本番では完全に閉じるイメージです。

ただし、このような開発用ログインを作る場合は、チームのルールに従ってください。

勝手に作ってはいけません。

ログイン済みユーザーをセッションに入れるとは何か

ログイン機能では、ログイン成功後にユーザー情報をセッションに入れることがよくあります。

セッションとは、ブラウザとサーバーの間で「同じ利用者の一連のアクセス」を管理する仕組みです。

たとえるなら、遊園地の入場リストバンドです。

入口でチケットを確認したあと、リストバンドを付けていれば、園内のアトラクションを利用できますよね。

Webシステムでも、ログイン成功後にセッションへユーザー情報を保存し、その後のアクセスでログイン済みか確認します。

session.setAttribute("loginUser", loginUser);

画面にアクセスされたときは、セッションからloginUserを取り出します。

LoginUser loginUser = (LoginUser) session.getAttribute("loginUser");

if (loginUser == null) {
    return "redirect:/login";
}

loginUserがnullなら、まだログインしていないという意味です。

その場合はログイン画面へ戻します。

ログインチェックは共通化する

新人エンジニアが最初にやりがちなのが、各Controllerに同じログインチェックを書くことです。

@GetMapping("/cars")
public String showCars(HttpSession session) {

    LoginUser loginUser = (LoginUser) session.getAttribute("loginUser");

    if (loginUser == null) {
        return "redirect:/login";
    }

    return "cars/list";
}

この書き方でも動きます。

しかし、画面が増えると、同じコードを何度も書くことになります。

一覧画面、登録画面、編集画面、削除画面、管理画面、検索画面。

全部に同じログインチェックを書くのは大変です。

そのため、実務ではインターセプターやSpring Securityを使って、ログインチェックを共通化します。

インターセプターとは、Controllerに処理が届く前に共通処理を挟む仕組みです。

たとえるなら、建物の各部屋の前で身分確認するのではなく、入口ゲートでまとめて確認するようなものです。

開発時にログインを省略するなら、共通部分で制御する

ログインチェックを各Controllerにバラバラに書いていると、開発時の切り替えも大変になります。

どこか1つだけチェックが漏れるかもしれません。

そのため、ログインチェックは共通化し、開発環境だけ例外を作るなら、その共通部分で制御するのが安全です。

たとえば、インターセプターで次のように考えます。

開発環境だけ特別な動作を入れる場合も、ここで管理します。

ただし、本番で無効になる設計にすることが必須です。

開発時にログインを毎回確認すべき場面

一方で、開発時でもログイン操作を必ず確認すべき場面があります。

ログイン機能そのものを開発しているときは、毎回に近いくらい丁寧に確認すべきです。

特に大切なのは、URL直打ち対策です。

ログイン画面から普通に遷移できないだけでは不十分です。

未ログインの人が、直接次のようなURLを打った場合も防ぐ必要があります。

/cars
/cars/new
/admin/users
/orders/1/edit

画面上にリンクがないから安全、ではありません。

URLを直接入力された場合でも、サーバー側でログインチェックする必要があります。

開発時にログインを省略してもよい場面

反対に、ログイン操作を毎回手で行わなくてもよい場面もあります。

たとえば、車一覧画面の表の幅を直しているだけなら、毎回ログインする必要性は低いです。

開発用ログインやセッション維持を使って、すぐ画面確認できるほうが効率的です。

ただし、ログイン省略によって本来の権限表示が見えなくなる場合は注意してください。

管理者だけに見えるボタンや、一般ユーザーには非表示にすべき項目を確認する場合は、実際の権限でログインして確認する必要があります。

テストではログインをどう扱うのか

テストでは、目的によってログインの扱いが変わります。

E2Eテストとは、End to Endテストの略です。

日本語では、最初から最後までの流れを確認するテストです。

たとえば、ログインして、車一覧を開き、登録画面で車を登録し、一覧に表示されることを確認するようなテストです。

この場合は、実際のユーザー操作に近いのでログインも含めて確認します。

一方で、DAOのSQLが正しいかだけを確認したいなら、ログイン画面を通る必要はありません。

Spring Securityを使う場合の考え方

Spring Bootで本格的にログイン機能を作る場合、Spring Securityを使うことが多いです。

Spring Securityを使うと、ログイン、ログアウト、認証、認可、CSRF対策などをフレームワーク側の仕組みで管理できます。

この場合も、開発時に毎回ログインするかどうかは、確認目的によって変わります。

Spring Securityを使う場合は、自己流でログインチェックをバラバラに書くより、フレームワークの仕組みに乗せたほうが安全です。

ただし、Spring Securityは最初は少し難しく感じるかもしれません。

新人エンジニアは、まず認証と認可の違いを理解してから学ぶとよいです。

開発用ユーザーを用意する

実務では、開発環境にテスト用ユーザーを用意することがよくあります。

1つの開発用ユーザーだけで全部確認しようとすると、権限チェックの漏れに気づきにくくなります。

管理者では動くけれど、一般ユーザーではエラーになる。

一般ユーザーに見えてはいけないボタンが見えている。

停止ユーザーでもログインできてしまう。

このような問題を見つけるには、複数のユーザー種別で確認する必要があります。

ログイン状態を長くする場合の注意

開発環境では、セッションタイムアウトを長めにすることがあります。

セッションタイムアウトとは、一定時間操作がない場合にログイン状態を切る仕組みです。

開発中にすぐログアウトされると不便なので、開発環境では長めにすることがあります。

ただし、本番環境で長すぎる設定にすると危険です。

開発環境の便利設定を本番に持ち込まない。

この意識がとても大切です。

新人エンジニアが覚えるべき判断基準

開発時に毎回ログインするか迷ったら、次の基準で考えてください。

この判断ができるようになると、開発効率とセキュリティのバランスを取りやすくなります。

大切なのは、手間を減らすこと自体は悪くないということです。

ただし、手間を減らすためにセキュリティを壊してはいけません。

開発時のおすすめ運用

ログイン機能があるシステムを開発するときは、次の運用がおすすめです。

特に、本番前の確認ではログイン省略を使わないでください。

実際のユーザーと同じようにログインし、権限を確認し、画面遷移を確認します。

開発中のショートカットは、あくまで開発中だけのものです。

まとめ

ログイン機能があるシステムでは、開発時にもログイン確認は必要です。

ただし、すべての作業で毎回手入力ログインをする必要はありません。

ログイン機能そのもの、権限チェック、本番に近い結合テストでは、実際にログインして確認するべきです。

一方で、HTMLのレイアウト確認、DAOやServiceの単体確認、開発中の細かい画面調整では、開発環境だけログイン補助やセッション維持を使って効率化することがあります。

一言でまとめるなら、開発時のログインは「毎回必ず手入力」ではなく、「確認目的に応じて、本物のログイン確認と開発用の効率化を使い分ける」ものです。

ただし、本番環境でログインを省略できるような抜け道を残してはいけません。

新人エンジニアは、認証、認可、セッション、ログアウト、URL直打ち対策、開発環境と本番環境の設定分離を順番に学んでください。

今後の学習では、まずセッションを使った簡単なログイン処理を作り、次にインターセプターでログインチェックを共通化し、最後にSpring Securityで本格的な認証と認可を学ぶとよいです。ログインは「面倒な入口」ではなく、システムを守る大切な門番だと考えましょう！

セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。

投稿者プロフィール

山崎講師代表取締役

セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。

学生時代は趣味と実益を兼ねてリゾートバイトにいそしむ。長野県白馬村に始まり、志賀高原でのスキーインストラクター、沖縄石垣島、北海道トマム。高じてオーストラリアのゴールドコーストでツアーガイドなど。現在は野菜作りにはまっている。

最新の投稿

• 新人エンジニア研修講師2026年6月16日Thymeleafのth:valueで送ることができる情報・できない情報を新人エンジニア向けに解説
• 新人エンジニア研修講師2026年6月16日生成AIはパターン認識しているだけなのか？肯定側と否定側から新人エンジニア向けに議論する
• 新人エンジニア研修講師2026年6月16日ログイン機能があるシステムでは開発時にも毎回ログインするのか？新人エンジニア向けに実務の考え方を解説
• 新人エンジニア研修講師2026年6月16日EclipseのSpring Bootで廃止メソッドの警告が出るのはどういうとき？新人エンジニア向けに解説