Webアプリにログイン機能を追加する

前のチュートリアルでは、WebアプリへDatabaseを追加して、入力したデータを保存できるようにしました。

次は、ユーザー登録・ログイン機能を追加して、「誰が使っているか」を識別できるWebアプリへ進みます。

ユーザー
↓
ログイン
↓
本人確認
↓
Session
↓
そのユーザーのデータだけ取得
↓
画面に表示

ログイン機能が使えるようになると、ユーザーごとのTodo、メモ、予約、顧客データなどを分けて扱えるようになります。

認証とは？

認証は、「今アクセスしている人が誰なのか」を確認する仕組みです。

ユーザー
↓
ログイン
↓
本人確認
↓
認証成功
↓
サービスを利用

メールアドレスとパスワードを使う方法だけでなく、Googleなど外部サービスのアカウントを使ってログインする方法もあります。

認証と認可の違い

開発では「認証」と「認可」という言葉が出てきます。

認証
↓
あなたは誰？

認可
↓
あなたはこの操作をしていい？

たとえばログインできたとしても、他人のデータまで編集できてよいわけではありません。

本人確認をしたあと、そのユーザーに許可されたデータ・機能だけ使えるようにする必要があります。

今回追加する機能

前回までに作ったアイデア整理アプリへ、次の機能を追加する想定で進めます。

• ユーザーがログインできる
• ログイン状態を確認できる
• ユーザーごとにIdeaを保存できる
• 自分のIdeaだけ表示される
• 未ログイン時のアクセスを制御する
• ログアウトできる

これまで

Idea
↓
全データ

今回

User A
↓
User AのIdea

User B
↓
User BのIdea

STEP 1：認証方法を決める

認証には複数の方法があります。

• メールアドレス＋パスワード
• Googleログイン
• GitHubログイン
• メールリンク
• 外部の認証サービス

初心者が最初に実装する場合は、認証処理をすべて自作するより、現在の技術構成に合った実績のある認証ライブラリやサービスを利用する方が安全です。

現在のプロジェクトを確認してください。

このWebアプリへログイン機能を追加したいです。

まず、
現在の技術構成に合う認証方法を提案してください。

条件:
・認証をゼロから自作しない
・現在もメンテナンスされている方法を優先
・既存のDatabase構成を考慮
・不要な依存関係を増やさない
・セキュリティを優先

まだインストールやコード変更はしないでください。

候補と、それぞれのメリット・注意点を説明してください。

STEP 2：Userデータを考える

ユーザーを識別するために、DatabaseへUser情報を持つ構成があります。

シンプルに考えると、たとえば次のような情報です。

User

id
name
email
createdAt

実際に必要なカラムは使用する認証方法によって異なります。

認証ライブラリが必要なテーブルやカラムを自動管理する場合もあります。

STEP 3：IdeaとUserを紐付ける

これまでのIdeaデータには、「誰が作ったIdeaなのか」という情報がありませんでした。

そこでUserとの関係を持たせます。

User

id: user_1

↓

Idea

id: idea_1
title: AI記事
userId: user_1

これによって、そのIdeaがどのユーザーのものなのか分かるようになります。

User A
├─ Idea 1
├─ Idea 2
└─ Idea 3

User B
├─ Idea 4
└─ Idea 5

STEP 4：AIにDatabase変更を設計させる

認証機能を入れる前に、現在のDatabaseとの関係を整理します。

現在のIdeaアプリへ認証を追加します。

要件:
・ログインユーザーを識別する
・IdeaをUserへ紐付ける
・自分のIdeaだけ表示する

まずDatabase構成を調査してください。

確認:
・現在のIdea Schema
・Userモデルがすでにあるか
・認証関連テーブルの有無
・Ideaへ追加が必要なフィールド
・既存データへの影響
・必要になるMigration

まだSchema変更やMigrationは実行しないでください。

変更案だけ報告してください。

STEP 5：パスワードを平文で保存しない

メールアドレスとパスワード方式を採用する場合でも、ユーザーのパスワードをそのままDatabaseへ保存してはいけません。

NG

password = "mypassword123"

↓

Databaseへそのまま保存

一般的には、適切なパスワードハッシュ処理を行う実績のあるライブラリや認証サービスを使います。

STEP 6：環境変数を準備する

認証サービスやOAuthを利用すると、Client ID・Secret・認証用Secretなどの秘密情報が必要になる場合があります。

それらはコードに直接書かず、環境変数として管理します。

AUTH_SECRET=[REDACTED]

GOOGLE_CLIENT_ID=[REDACTED]

GOOGLE_CLIENT_SECRET=[REDACTED]

実際の環境変数名は、利用する認証方法の公式ドキュメントに従います。

STEP 7：.gitignoreをもう一度確認する

認証を追加すると秘密情報が増えるため、Git管理対象を再確認します。

git status

.env や .env.local など秘密情報を含むファイルがGitへ追加されていないか確認します。

秘密情報を含むファイルは、適切に .gitignore へ設定します。

STEP 8：まず認証だけ動かす

いきなり「認証＋Database＋Ideaの権限管理」を全部実装するのではなく、小さく進めます。

① ログインできる
↓
② ログアウトできる
↓
③ 現在のユーザーを取得できる
↓
④ IdeaへUserを紐付ける
↓
⑤ 自分のIdeaだけ取得する

最初はログイン・ログアウトだけを完成させます。

STEP 9：ログイン画面を作る

認証方法に合わせてログイン画面を用意します。

ログイン画面

↓

Googleでログイン

または

メール
パスワード

↓

ログイン

AIへ依頼するときは、認証ロジックと見た目を同時に大きく変えすぎないようにします。

現在選択した認証方式に合わせて、
ログイン画面を実装してください。

条件:
・既存デザインに合わせる
・スマートフォン対応
・認証ライブラリの公式手順に従う
・独自認証ロジックを追加しない
・関係ない画面を変更しない

実装前に変更予定ファイルを報告してください。

STEP 10：Sessionとは？

ログイン後、そのユーザーがログイン済みであることをアプリ側で扱うためにSessionという仕組みが使われます。

ログイン
↓
認証成功
↓
Session
↓
「このユーザーはログイン済み」
↓
ページを移動しても状態を確認

Sessionの具体的な実装方式は認証ライブラリによって異なります。

初心者は内部仕様をすべて暗記するより、まず「現在のユーザーを安全に確認する仕組み」と理解すれば十分です。

STEP 11：ログインユーザーを確認する

ログインできたら、アプリ側で現在のユーザーを取得できるか確認します。

現在のSessionを使って、
ログインユーザーを取得してください。

確認したいもの:
・user id
・name
・email

ただし、
秘密情報や認証Tokenを画面へ表示しないでください。

最初は開発環境で、正しいユーザーを取得できているか確認します。

STEP 12：未ログインユーザーのアクセスを制御する

ログインが必要な画面を誰でも開ける状態では意味がありません。

未ログインの場合はログイン画面へ移動させるなど、アクセスを制御します。

Dashboardへアクセス
↓
Session確認

ログイン済み
↓
表示

未ログイン
↓
ログイン画面へ

この処理は画面上でボタンを隠すだけでは不十分です。

サーバー側でも権限を確認する

「削除ボタンを非表示にしたから安全」とは限りません。

データを取得・変更する処理側でも、現在のユーザーがその操作をしてよいか確認する必要があります。

削除リクエスト
↓
現在のユーザー確認
↓
そのIdeaの所有者か確認
↓
一致
↓
削除

不一致
↓
拒否

STEP 13：Idea保存時にUser IDを追加する

新しいIdeaを作るとき、ログイン中のユーザーIDを一緒に保存します。

ログインユーザー
↓
userId = user_1

Ideaを作成
↓
title
content
userId = user_1

↓
Database保存

これによってIdeaの所有者が分かるようになります。

Idea作成処理を更新してください。

要件:
・ログイン必須
・Sessionから現在のUser IDを取得
・IdeaへUser IDを保存
・ブラウザから送られたUser IDは信用しない
・未ログインの場合は保存しない

既存の保存処理を確認してから変更してください。

なぜブラウザから送られたUser IDを信用しない？

ユーザーがブラウザから送る値は変更できる可能性があります。

そのため、

フォーム

userId = user_1

のように送られてきた値をそのまま所有者として扱うのではなく、サーバー側で現在のログインユーザーを確認します。

ブラウザが送ったUser ID

ではなく

↓

Sessionから取得したUser ID

STEP 14：自分のIdeaだけ取得する

一覧表示するときも、Database内のIdeaをすべて取得してはいけません。

現在ログインしているユーザーのIdeaだけ取得します。

Session
↓
userId = user_1
↓
Database
↓
userId = user_1 のIdeaだけ取得
↓
画面表示

Idea一覧取得処理を変更してください。

要件:
・ログインユーザーをSessionから取得
・そのUser IDに紐づくIdeaだけ取得
・他ユーザーのIdeaを返さない
・未ログインの場合は取得しない

現在のDatabase Queryを確認してから変更してください。

STEP 15：2ユーザーでテストする

ユーザーごとのデータ分離を確認するには、複数ユーザーで試すのが分かりやすいです。

User A

Idea A1
Idea A2

↓

ログアウト

↓

User B

Idea B1

↓

User Bには
Idea A1 / A2 が見えない

これが確認できれば、基本的なデータ分離が機能しています。

STEP 16：URLを直接入力しても確認する

画面上のリンクからアクセスできないだけでは十分ではありません。

保護したいページのURLを直接入力しても、未ログイン状態で見られないことを確認します。

未ログイン

↓

/dashboard

を直接開く

↓

ログイン画面へ
または
アクセス拒否

STEP 17：ログアウトを確認する

ログアウト後も保護ページが見られてしまわないか確認します。

ログイン
↓
Dashboard
↓
ログアウト
↓
Session終了
↓
Dashboardへアクセス
↓
ログインを要求

STEP 18：認証エラーを確認する

正常にログインできる場合だけではなく、失敗時の動作も確認します。

• 認証がキャンセルされた
• 必要な環境変数がない
• 認証サービスとの接続に失敗した
• Sessionが無効になった

利用者に分かりやすいエラー表示になるか確認しましょう。

STEP 19：ログへ秘密情報を出さない

認証エラーを調査するとき、Token・Cookie・Secretなどをログへそのまま出さないように注意します。

STEP 20：Database Migrationを確認する

Userや認証関連テーブル、Ideaとの関係追加によってDatabase構造が変わる場合があります。

Migrationを実行する前に内容を確認します。

今回のMigrationをレビューしてください。

確認:
・追加されるテーブル
・追加されるカラム
・削除されるもの
・型変更
・既存データへの影響
・本番実行時のリスク

まだMigrationは実行しないでください。

特に既存データがあるアプリでは注意が必要です。

STEP 21：git diffを確認する

git status
git diff

認証追加では変更ファイルが増えやすいため、要件外の変更がないか確認します。

現在の認証実装をレビューしてください。

確認:
・変更ファイル
・認証処理
・Session処理
・権限確認
・Database変更
・秘密情報
・不要な依存関係
・既存機能への影響

まだ追加修正はしないでください。

STEP 22：公開前チェックをする

利用可能なテストやチェックを実行します。

公開前チェックをしてください。

確認:
・lint
・型チェック
・build
・利用可能なテスト
・ログイン
・ログアウト
・未ログインアクセス
・ユーザーごとのデータ分離
・Database接続
・秘密情報

失敗している項目があれば、
成功とは報告しないでください。

STEP 23：Vercelへ認証用環境変数を設定する

ローカルで設定した認証用環境変数は、GitHubへPushしません。

そのためVercel側にも必要な値を設定します。

Local

.env.local

↓

認証設定

Vercel

Environment Variables

↓

同じ役割の値を設定

PreviewとProductionで別の値を使う場合は、それぞれ正しく設定します。

STEP 24：Previewで認証を確認する

ローカルで成功しても、公開URLでは認証設定が異なる場合があります。

Preview URLで確認します。

□ ログインできる

□ ログアウトできる

□ Sessionが維持される

□ 未ログイン時は保護ページを見られない

□ 自分のIdeaだけ見える

□ 他ユーザーのIdeaが見えない

□ Idea保存時に正しいUser IDが紐づく

OAuthではRedirect URLにも注意する

Googleなど外部サービスのログインを使う場合、認証後に戻るURLの設定が必要になることがあります。

ユーザー
↓
Google
↓
認証
↓
Webアプリへ戻る

localhost・Preview・ProductionでURLが異なるため、利用する認証サービスの設定と公式ドキュメントを確認しましょう。

STEP 25：Productionで確認する

Previewで問題がなければ、現在のGit運用に従って本番へ反映します。

Local
↓
Feature Branch
↓
Preview
↓
認証テスト
↓
Main
↓
Production
↓
本番でも確認

Productionでも最低限、ログイン・ログアウト・データ分離を確認します。

ユーザー削除も考える

将来的に実サービスとして提供する場合は、ユーザー退会時の処理も考える必要があります。

• Userを削除するのか
• 関連データも削除するのか
• 一定期間保持するのか
• 匿名化するのか

どの方法が適切かはサービス内容や法的要件によって異なります。

ログイン機能を追加すると何が作れる？

認証とDatabaseを組み合わせることで、作れるサービスの幅がさらに広がります。

• 個人Todo
• メモサービス
• 会員サイト
• 顧客管理
• 予約サービス
• 学習管理
• ユーザーダッシュボード
• SaaS

ログイン機能追加の基本フロー

認証方法を決める
↓
Userを設計
↓
認証ライブラリを導入
↓
環境変数
↓
ログイン
↓
Session
↓
アクセス制御
↓
IdeaとUserを紐付ける
↓
ユーザーごとに取得
↓
2ユーザーでテスト
↓
Preview
↓
Production

AIへ認証追加を依頼する基本テンプレート

目的:
Webアプリへ認証機能を追加する。

要件:
・ユーザーがログインできる
・ログアウトできる
・Sessionで現在のユーザーを確認
・未ログインユーザーは保護ページへ入れない
・IdeaをUserへ紐付ける
・自分のIdeaだけ表示する

条件:
・認証を独自実装しない
・現在の公式推奨方法を確認する
・既存Database構成を確認する
・秘密情報を表示しない
・関係ないコードを変更しない
・本番Databaseは変更しない
・不要なライブラリを追加しない

最初に現在のプロジェクトを調査してください。

まだコード変更・インストール・Migrationは実行しないでください。

報告:
1. 現在の構成
2. 推奨する認証方法
3. 必要なDatabase変更
4. 必要な環境変数
5. 変更予定ファイル
6. セキュリティ上の注意点
7. テスト方法
8. Productionへの影響

ここまででできるようになったこと

Webサービスを作る
↓
GitHub
↓
Vercel
↓
Database
↓
認証
↓
ユーザーごとのデータ

↓

本格的なWebアプリの基礎

ここまで進めば、単なるWebページではなく、ユーザーごとに情報を保存できるWebアプリの基本構造が見えてきます。

次に学ぶ

ログイン・Databaseまでできたら、次はWebアプリへAIそのものを組み込みます。

Webサービス
↓
Database
↓
ログイン
↓
AI API
↓
AI機能を持つWebサービス

WebアプリにAI機能を追加する →