Railsでrescue_fromを使った例外処理の基本！初心者向けJSONレスポンスの書き方

1. Railsの例外処理とは？

1. Railsの例外処理とは？

Ruby on Rails（レイルズ）は、Webアプリケーション開発に使われる人気のフレームワークです。実際の開発では、エラー（例外）が発生することがあります。たとえば、存在しない記事を見ようとしたときや、データの保存に失敗したときなどです。例外処理（れいがいしょり）とは、こういったトラブルが発生したときに、アプリが止まらずに対応するしくみです。

Railsでは、rescue_from（レスキュー・フロム）という方法を使って、例外をキャッチし、エラーに対して適切なレスポンス（返答）を返すことができます。

2. rescue_fromの基本的な使い方

2. rescue_fromの基本的な使い方

rescue_fromは、Railsのコントローラの中で使うメソッドです。特定の種類のエラーが起きたときに、別のメソッドを呼び出すことができます。これにより、エラー内容に応じて、ユーザーにわかりやすいエラーメッセージを返したり、ログを記録したりできます。

以下は、存在しないデータにアクセスしたときの「404エラー」をJSON形式で返す例です。

class ApplicationController < ActionController::Base
  protect_from_forgery with: :null_session

  rescue_from ActiveRecord::RecordNotFound, with: :render_404

  private

  def render_404(exception)
    render json: { error: 'データが見つかりませんでした。' }, status: :not_found
  end
end

3. よく使うステータスコード：404・422・500

3. よく使うステータスコード：404・422・500

例外に応じて、次のようなHTTPステータスコードを使い分けることが一般的です。

• 404 Not Found：指定したデータが見つからないとき。
• 422 Unprocessable Entity：バリデーションエラーなど、データが不正なとき。
• 500 Internal Server Error：予期しないバグやサーバー側のエラー。

それぞれの例に対応したrescue_fromの書き方を見てみましょう。

4. 422エラーとバリデーションの例

4. 422エラーとバリデーションの例

ユーザーが送ってきたデータに問題があるとき、422エラーとして返すことができます。

class ApplicationController < ActionController::Base
  rescue_from ActiveRecord::RecordInvalid, with: :render_422

  private

  def render_422(exception)
    render json: { error: '入力内容が正しくありません。', details: exception.record.errors.full_messages }, status: :unprocessable_entity
  end
end

5. 500エラーのハンドリング例

5. 500エラーのハンドリング例

コードのバグなどで、予想外のエラーが発生することがあります。このときは、500エラーとして処理します。ただし、開発中はそのままエラーを表示したほうが原因を特定しやすいため、本番環境だけに設定するのが一般的です。

class ApplicationController < ActionController::Base
  rescue_from StandardError, with: :render_500

  private

  def render_500(exception)
    logger.error exception.message
    logger.error exception.backtrace.join("\n")
    render json: { error: 'サーバー内部でエラーが発生しました。' }, status: :internal_server_error
  end
end

6. JSONレスポンスとは？

6. JSONレスポンスとは？

JSON（ジェイソン）とは、Webでよく使われるデータ形式の一つで、「{"name":"山田"}」のように鍵と値をセットで表します。スマートフォンアプリやJavaScriptとRailsを連携する際によく使われ、機械でも人間でも読みやすいのが特徴です。

今回のように、エラーの情報もJSONで返すことで、ユーザーにとっても開発者にとってもわかりやすくなります。

7. rescue_fromを複数使うときの注意点

7. rescue_fromを複数使うときの注意点

rescue_fromは、どのエラーに対して、どのメソッドで処理するかを明示的に書く必要があります。同じ種類のエラーを複数回指定すると、後に書かれたものが優先されます。

また、StandardErrorはすべての例外の親にあたるため、先に記述すると他のエラーがキャッチされないことがあります。順番にも注意しましょう。

8. よくあるエラーとデバッグ方法

8. よくあるエラーとデバッグ方法

rescue_fromを設定したのに、うまく動かないことがあります。例えば：

• 対象のエラークラスが違っている（例：RecordNotFoundと書くべきところをNotFoundにしている）
• privateメソッドが呼び出せない場合
• JSON形式が意図通りに出力されない

そんなときは、loggerを使ってエラーの中身をログに出すと、原因が分かりやすくなります。

def render_500(exception)
  logger.error exception.message
  logger.error exception.backtrace.join("\n")
  render json: { error: 'サーバーエラーが発生しました。' }, status: :internal_server_error
end

まとめ

まとめ

Rails（レイルズ）における例外処理は、堅牢なWebアプリケーションやAPIを構築する上で欠かせない要素です。今回学習したrescue_fromは、コントローラ全体で共通のエラーハンドリングを可能にする非常に強力なツールです。これを使うことで、予期せぬエラーが発生してもアプリケーションがクラッシュすることなく、ユーザーに対して適切なメッセージや適切なHTTPステータスコード（404、422、500など）をJSON形式で返すことができます。

特にモダンなWeb開発においては、フロントエンド（ReactやVue.jsなど）やモバイルアプリと連携することが多いため、エラーが発生した際に「何が原因で失敗したのか」を機械的に判別しやすいJSON形式で伝えることが重要です。ActiveRecord::RecordNotFoundやActiveRecord::RecordInvalidといったRails特有の例外を適切にキャッチし、共通のメソッド（render_404やrender_422など）に集約することで、コードの可読性とメンテナンス性が劇的に向上します。

実践的な実装例：データベース操作と例外処理

ここで、実際にデータベース（SQL）の操作とRailsのコードがどのように連動して例外を投げるのか、具体的なシミュレーションを見てみましょう。例えば、ユーザー情報を管理するusersテーブルがある場合を想定します。

id | name     | age | email
---+----------+-----+-----------------------
1  | 佐藤健一 | 28  | sato@example.com
2  | 鈴木愛   | 22  | suzuki@example.com
3  | 高橋裕二 | 35  | takahashi@example.com
4  | 田中花子 | 30  | tanaka@example.com
5  | 伊藤博   | 45  | ito@example.com

この状態で、存在しないID「99」を指定してデータを取得しようとするSQLが発行されたとします。

SELECT *
FROM users
WHERE id = 99;

このSQLの結果、レコードは見つかりません。RailsのUser.find(99)というメソッドはこの時にActiveRecord::RecordNotFoundという例外を発生させます。これをrescue_fromで処理しない場合、ユーザーには無機質なエラー画面が表示されてしまいますが、適切に設定していれば以下のようなJSONレスポンスを返すことができます。

{
  "status": 404,
  "error": "Not Found",
  "message": "指定されたユーザー（ID: 99）は見つかりませんでした。"
}

バリデーションエラー（422）の具体例

次に、データの更新時にバリデーション（入力チェック）に引っかかった場合を考えます。メールアドレスが空ではいけないというルールがある場合、以下のようなSQLが実行されようとしますが、Rails側でエラーを検知します。

# Rails側での更新処理の例
begin
  user = User.find(1)
  user.update!(email: "") # ここでバリデーションエラーが発生
rescue ActiveRecord::RecordInvalid => e
  # rescue_fromを使っている場合は、自動的にrender_422などが呼ばれる
end

このとき、データベースの中身は変更されず、以下のような状態が維持されます。

id | name     | age | email
---+----------+-----+-----------------------
1  | 佐藤健一 | 28  | sato@example.com
2  | 鈴木愛   | 22  | suzuki@example.com
3  | 高橋裕二 | 35  | takahashi@example.com
4  | 田中花子 | 30  | tanaka@example.com
5  | 伊藤博   | 45  | ito@example.com

そして、クライアント側には以下のような詳細なエラー内容が返却されます。

{
  "error": "入力内容が正しくありません。",
  "details": [
    "メールアドレスを入力してください",
    "メールアドレスは不正な形式です"
  ]
}

本番環境での運用上の注意

rescue_from StandardErrorを使用して500エラーをキャッチする際は注意が必要です。開発環境（development）でこれを行ってしまうと、エラーのスタックトレース（どこでエラーが起きたかの詳細）が隠されてしまい、デバッグが非常に困難になります。そのため、以下のように条件分岐を行うか、本番環境の設定ファイルで制御するのがプロのやり方です。

class ApplicationController < ActionController::Base
  # 本番環境のみ、予期せぬエラーを共通の500エラー画面にする
  if Rails.env.production?
    rescue_from StandardError, with: :render_500
  end

  private

  def render_500(e)
    # ログには詳細を記録し、ユーザーには簡潔なメッセージを出す
    ExceptionNotifier.notify_exception(e) # 通知サービスなどを使う例
    render json: { error: "システムエラーが発生しました。時間をおいて再度お試しください。" }, status: 500
  end
end

例外処理をマスターすることは、単に「エラーを隠す」ことではありません。エラーが起きたときに「何が起きたのかを正しく伝え、システムの安定性を保つ」ための技術です。Railsが提供するrescue_fromを使いこなし、ユーザーにとっても開発者にとっても優しいアプリケーションを目指しましょう。