第7回「Rails基礎力を固める模擬問題で学ぶ試験対策」認証・認可の実践設計

2026年5月20日

みなさん、こんにちは。

前回は、認証（Authentication）と認可（Authorization）の基本的な違いと、その設計の考え方について整理しました。ログイン状態を確認する認証と、操作の可否を判断する認可は、似ているようで役割が異なり、この区別がコントローラ設計の質に大きく影響することを確認しました。

今回はその続編として、より実践的な認可設計に踏み込みます。実務では単純に「ログインしているか」「所有者か」だけではなく、管理者権限の扱いや、ネストされたリソースに対する制御、さらに不正アクセス時のハンドリングなど、複雑な条件を考慮する必要があります。

Rails 技術者認定ベーシック試験でも、こうした応用的な設計の理解が問われることがあります。単なるコードの暗記ではなく、「どのように設計すべきか」という視点で理解を深めていきましょう。

管理者権限を含む認可設計

認可の代表的なパターンの一つが、「管理者であれば例外的に操作を許可する」というケースです。

def authorize_user
redirect_to posts_path unless @post.user == current_user || current_user.admin?
end

このように書くことで、

投稿の作成者であれば編集可能
管理者であれば他人の投稿も編集可能

というルールをシンプルに表現できます。

ここで重要なのは、「条件を追加するのではなく、ルールとして整理する」という視点です。認可ロジックは複雑になりやすいため、条件分岐が増えるほど可読性が低下します。可能な限りシンプルにまとめることが重要です。

ネストリソースと認可

もう一つ重要なのが、ネストされたリソースに対する認可です。たとえば、ユーザーに紐づく投稿を扱う場合を考えます。

def set_post
@post = current_user.posts.find(params[:id])
end

このように書くことで、

ログインユーザーに紐づく投稿のみ取得
他人の投稿にはアクセスできない

という制御が可能になります。

これは非常に重要で、「取得時点で認可をかける」という設計です。別途 authorize_user を書かなくても、安全性を担保できます。

エラーハンドリングと認可

認可に失敗した場合の扱いも重要です。

def authorize_user
redirect_to root_path, alert: “権限がありません”
end

単にリダイレクトするだけでなく、ユーザーに理由を伝えることで、UX（ユーザー体験）を損なわない設計になります。

さらに実務では、例外処理を使うこともあります。これにより、不正なIDアクセスや権限違反を一括で処理できます。

rescue_from ActiveRecord::RecordNotFound, with: :not_found

def not_found
redirect_to root_path
end

模擬問題

問題1

次のコードの説明として最も適切なものを1つ選びなさい。

def authorize_user
redirect_to root_path unless current_user.admin?
end

ログインしていないユーザーを制限する
管理者以外のユーザーを制限する
投稿の所有者のみ許可する
すべてのユーザーを許可する

正解

解説

このコードは current_user.admin? を条件としているため、「管理者かどうか」を判定しています。したがって、管理者以外のユーザーはリダイレクトされます。このコードでの処理は、認証ではなく認可です。「ログインしているか」ではなく、「どの権限を持っているか」を判定している点が重要です。

問題2

次のコードの設計として最も適切な説明を1つ選びなさい。

@post = current_user.posts.find(params[:id])

params を安全に変換している
Strong Parameters を実装している
認可をリソース取得時に行っている
before_action を使っていないため不適切

正解

解説

このコードは、「ログインユーザーに紐づく投稿のみを取得する」ことで認可を実現しています。他人の投稿IDを指定しても、該当レコードが見つからないためエラーになります。このコードは、「取得時に認可をかける」という設計であり、非常に安全かつシンプルな方法です。

問題3

認可に失敗した場合の処理として最も適切なものを1つ選びなさい。

何もせず処理を続行する
params を書き換える
redirect_to で別ページへ遷移する
current_user を nil にする

正解

解説

認可に失敗した場合は、処理を継続せず、安全な場所へリダイレクトするのが基本です。これにより、不正な操作を防ぐことができます。1 のように処理を続けてしまうと、権限のない操作が実行される可能性があります。2 や 4 は認可とは関係のない処理です。認可は「許可されていない場合にどうするか」まで含めて設計することが重要です。

まとめ

今回は、認証・認可の基本から一歩進み、より実践的なコントローラ設計について整理しました。特に重要なのは、「どこで認可を行うか」という視点です。アクション内で判定するだけでなく、リソース取得時に制御したり、管理者権限を組み合わせたりすることで、より安全でシンプルな設計が可能になります。また、認可は単に条件を書くことではなく、「ルールとして整理すること」が重要です。条件が増えるほどコードは複雑になりますが、責務を分離し、適切な場所に配置することで、可読性と保守性を保つことができます。

次回は、ビューやヘルパーとの連携に焦点を当て、「表示とロジックの分離」という観点から、より実践的な設計について考えていくことにします。MVC の役割をさらに深く理解し、アプリケーション全体を見通せるようにしましょう。