Rails 8の認証ジェネレータとDeviseはどっちを使う？違い・生成コード・移行の判断基準まで解説

Rails 8 で bin/rails generate authentication という認証ジェネレータが標準搭載されました。これを見て「じゃあ、もう Devise は要らないの？」「新規アプリはどっちで作るのが正解なんだろう？」と迷っていませんか？

結論から言うと、どちらが上というわけではなく、要件次第で使い分けるものです。この記事では、Rails 8 の認証ジェネレータが実際に何を生成するのか、Devise と何が違うのか、そして「既存の Devise アプリを乗り換えるべきか」までを、実務で認証を組んできた立場から整理します。読み終わる頃には、あなたのプロジェクトでどちらを選べばいいかがハッキリするはずです。

まず結論：どっちを使えばいい？

細かい比較は後半でしますが、先に判断の軸だけ渡しておきます。両者が「標準で用意してくれる機能の量」を並べると、違いが一目で分かります。

ひとことで言えば、「自分たちで管理したいなら標準ジェネレータ、任せたいなら Devise」です。標準ジェネレータは生成されたコードが全部自分のアプリの中に置かれるので中身を読んで改造できます。Devise は gem がよしなにやってくれる代わりに、中身はブラックボックス寄りになります。

Rails 8 の認証ジェネレータとは（何が生成されるのか）

Rails 8 では、次のコマンド一発で認証の土台が丸ごと生成されます。外部 gem は一切使いません。

bin/rails generate authentication
bin/rails db:migrate

「認証まわりって、モデル・コントローラ・マイグレーション…と自分で書くと地味に時間がかかる」——その一式をまとめて用意してくれるのがこのジェネレータの狙いです。生成される主なファイルは次のとおりです。

ポイントは、これらが「あなたのアプリのコード」として生成されること。app/models/user.rb も app/controllers/concerns/authentication.rb も、開けばそのまま読めて、好きに書き換えられます。gem の中に隠れていないのが標準ジェネレータの一番の特徴です。

実際に認証をかけてみる（STEP1 → STEP2）

生成されただけだと「で、どう使うの？」となりますよね。ログイン必須にする流れを、最小構成から見ていきましょう。

STEP1：全体をログイン必須にする

生成された Authentication concern は、ApplicationController に include 済みです。この状態で require_authentication（未ログインならログイン画面へ飛ばす before_action）がデフォルトで効くので、基本は「全ページ認証必須」からスタートします。コントローラ内では Current.user でログイン中のユーザーを取得できます。

class ArticlesController < ApplicationController
  def index
    # ここに来られる時点でログイン済み
    @articles = Current.user.articles
  end
end

STEP2：一部のページだけ公開する

トップページやサインアップ画面など、ログインしていなくても見せたいページもありますよね。そのときは allow_unauthenticated_access を使って、アクション単位で認証をスキップします。

class HomeController < ApplicationController
  # index と about は未ログインでも見られる
  allow_unauthenticated_access only: %i[index about]

  def index; end
  def about; end
end

Devise の before_action :authenticate_user! が「必要なところに認証を足していく」発想なのに対し、Rails 8 標準は「まず全部閉じておいて、公開したいところだけ開ける」という逆の発想です。安全側に倒れているのは嬉しいポイントです。

生成された認証でよく使うメソッド一覧

生成された Authentication concern が用意してくれる、実際によく使うメソッドをまとめておきます。「あのメソッド何だっけ？」となったときの早見表にどうぞ。

Devise との違いを比較表で整理する

「機能量」と「コントロールのしやすさ」がトレードオフになっている、と捉えると分かりやすいです。主要な違いをまとめました。

パスワードのハッシュ化はどちらも BCrypt、Cookie も署名付きで、セキュリティの土台は同等です。差が出るのは「標準で付いてくる機能の量」と「コードを自分で持つか gem に任せるか」の部分です。

セッションを Session モデルとして DB に持つ設計には、Cookie だけで完結する方式には無いメリットがあります。ログイン中のセッションが1件のレコードとして存在するので、次のようなことが素朴なコードで実現できます。

• 特定のセッションだけ強制ログアウトさせる（「このデバイスからログアウト」ボタンなど）
• パスワード変更時に、それ以外の全セッションを一括で失効させる（乗っ取り対策）
• 管理画面から特定ユーザーを強制ログアウトさせる（不正利用が疑われた場合の対応）

# 自分以外の全セッションを失効（パスワード変更時など）
Current.user.sessions.where.not(id: Current.session.id).destroy_all

# 特定ユーザーを強制ログアウト（管理画面から）
user.sessions.destroy_all

Cookie に署名付きトークンを詰めるだけの方式だと、サーバー側にセッションの実体が無いため「特定の1件だけ失効させる」が原理的に難しくなります。Devise の trackable も直近ログイン情報の記録止まりで、同じような取り消しはできません。標準ジェネレータのほうが、複数セッションを DB に持てるぶんこの点は細かく扱えます。

一番のハマりどころ：標準ジェネレータに「新規登録」は無い

ここが Devise から来た人が必ずつまずくポイントです。Rails 8 の認証ジェネレータには、ユーザーの新規登録（サインアップ）フローが意図的に含まれていません。生成されるのは「ログイン」と「パスワードリセット」だけ。「ユーザー作成画面が無い！」と焦らないでください。仕様です。

とはいえ実装は難しくありません。User 用のコントローラを1つ足して、作成後に start_new_session_for でそのままログインさせるだけです。

class RegistrationsController < ApplicationController
  allow_unauthenticated_access only: %i[new create]

  def new
    @user = User.new
  end

  def create
    @user = User.new(user_params)
    if @user.save
      start_new_session_for(@user)   # 登録後そのままログイン
      redirect_to root_path, notice: "ようこそ！"
    else
      render :new, status: :unprocessable_entity
    end
  end

  private

  def user_params
    params.require(:user).permit(:email_address, :password, :password_confirmation)
  end
end

この「足りない機能は自分で薄く足す」という感覚が肌に合うなら標準ジェネレータは快適ですし、「そこも用意しておいてよ」と思うなら Devise のほうがラクです。どちらを心地よく感じるかは、選択の良い判断材料になります。

ケース別のおすすめ

「で、自分の場合は？」に答えるために、よくあるケースで整理します。

Rails 8 標準ジェネレータが向くケース

• 個人開発・小〜中規模で、ユーザーは User 1種類
• 認証の中身を理解して、自分でコントロールしたい
• 依存 gem を増やしたくない・アップデートに振り回されたくない
• 学習目的で「セッションやトークンの扱い」を体で覚えたい

Devise が向くケース

• メール確認・アカウントロック・SNS ログインなど、機能要件が最初から多い
• User と Admin など複数のモデルで認証したい
• 認証は既製品に任せて、事業のコードに集中したい（時短優先）
• チームに Devise の知見があり、情報も探しやすい

迷ったときのひとことルールは、「機能要件がまだ薄い・認証を自分たちで管理したい → 標準／機能てんこ盛り・とにかく早く → Devise」。新規の小さめアプリなら標準ジェネレータから始めて、要件が膨らんできたら Devise を検討、という順番が現実的です。

既存の Devise アプリは乗り換えるべき？

すでに Devise で動いているアプリを、わざわざ標準ジェネレータに置き換える必要は基本的にありません。動いている認証は資産ですし、confirmable や lockable を使い込んでいるなら、それを手作りで再現するコストのほうが高くつきます。

Devise はカスタマイズしながら長く使えます。たとえば「パスワード変更とプロフィール更新を分ける」といった実務でよくある調整も、gem を捨てずに実現できます（このあたりはDeviseをカスタマイズしてプロフィール更新とパスワード変更を分ける方法で詳しく書いています）。乗り換えを考えるのは、「Devise の機能をほとんど使っていない」「依存を減らして自分たちで管理したくなった」ときくらいで十分です。

逆に、これから作る新規アプリなら、まず標準ジェネレータを試すのは十分アリです。生成されたコードを読むだけでも「Rails の認証ってこう組まれているのか」が分かり、いざ Devise を使うときの理解も深まります。Rails 自体の環境構築から始める場合はmacOSにRuby on Railsをインストールを、そこから先の作り方はboilerplateを作成してGithubのTemplate Repositoryにする方法も合わせてどうぞ。

まとめ

Rails 8 の認証ジェネレータと Devise の使い分けを、最後にもう一度整理します。

• Rails 8 標準：generate authentication でコードを自分のアプリに生成。中身を読める・自分たちで管理できる。ただし新規登録は自分で実装
• Devise：機能が最初から豊富で時短。複数モデル・OAuth・メール確認が要るならこちら
• セキュリティの土台（BCrypt・署名付き Cookie）はどちらも同等。差は「機能量」と「コントロール性」
• 判断軸は「自分たちで管理したい標準 / 任せたい Devise」。新規の小さめアプリは標準から、機能要件が多いなら Devise

「認証は Devise 一択」だった時代から、選択肢が1つ増えました。どちらも触ってみると、Rails の認証の仕組みそのものへの理解が確実に深まります。まずは新しいアプリで generate authentication を叩いて、生成されたコードを眺めてみてはいかがでしょうか。

スポンサーリンク