Railsのresource / resourcesとは？RESTfulなルーティングの基本をやさしく解説

はじめに

Railsでアプリケーションを作成するとき、ルーティングを設定する場面があります。
しかし、プログラミングが初めての方にとっては、ルーティングという言葉自体が少しとっつきにくく感じるかもしれません。

とくに resource と resources という書き方があって、「単数形と複数形で何が違うのだろう？」と思うことがあるでしょう。
この記事では、Railsにおける RESTfulなルーティング の考え方と、それを簡単に設定できる resource / resources について、初心者の方でもわかりやすいように解説します。

最後まで読むことで、Railsのルーティング設定に対する理解が深まり、実務レベルでの応用ポイントもしっかり押さえられます。

この記事を読むとわかること

• RESTfulルーティング とは何か
• resource と resources の違い
• Railsでルーティングを設定するときの実際の書き方
• 実務レベルでの活用例と注意点

RailsのRESTfulルーティングとは

RESTfulという考え方

Railsのルーティングを学ぶ上で、まず理解しておきたいのが REST (Representational State Transfer) という概念です。
RESTはWebアプリケーションの設計スタイルの一種で、以下のような特徴を持っています。

• HTTPメソッド（GET, POST, PATCH, DELETEなど）を明確に使い分ける
• 同じURL（エンドポイント）であっても、操作内容によってHTTPメソッドを変え、目的を区別する
• 「ユーザー」「記事」「コメント」など、対象となるリソースの操作を共通のルールで行う

Railsは、このRESTの考え方をコントローラと連動させる形で強力にサポートしています。
各リソース（たとえばユーザー情報やブログ記事など）ごとに、一連のCRUD操作（Create, Read, Update, Delete）をまとめて定義しやすいのが特徴です。

Railsが自動生成するルーティング

Railsには、RESTの基本的なルールに沿ったルーティングを簡単に設定できる仕組みがあります。
それが resource / resources を使う方法です。
この2つを書くだけで、ユーザーやブログ記事などのリソースを操作するための複数のルートを、Railsが自動的に生成してくれます。

Railsのルーティングファイル config/routes.rb において、たとえば以下のように書くことが多いです。

コピー
resources :users

この1行だけで、ユーザーの一覧表示や詳細表示、新規作成、編集などのアクションに対応するルートが自動生成されます。
具体的には、index, show, new, create, edit, update, destroy といった複数のパスとHTTPメソッドの対応がまとめて定義されます。

resource と resources の違い

Railsを学び始めると「単数形と複数形で何が違うの？」と疑問に思うかもしれません。
ここでは、それぞれの特徴を初心者の方にわかりやすいように整理してみます。

resourceの特徴

resource :profile のように、単数形（resource）を使うと、以下のようなルーティングが生成されます。

• GET /profile : プロフィールの表示（showアクションに対応）
• GET /profile/new : 新規作成フォームの表示（newアクションに対応）
• POST /profile : 新規登録（createアクションに対応）
• GET /profile/edit : 編集フォームの表示（editアクションに対応）
• PATCH/PUT /profile : 更新（updateアクションに対応）
• DELETE /profile : 削除（destroyアクションに対応）

見てのとおり、単数形で定義するとURLにリソースID（たとえば /profile/1 のようなもの）が入りません。
このため、プロフィールや設定画面のように「1つのリソースだけが存在する」というケースに適しています。

resourcesの特徴

resources :users のように、複数形（resources）で書くと、以下のような複数のルートが自動で生成されます。

• GET /users : ユーザー一覧（indexアクション）
• GET /users/new : ユーザー新規作成フォーム（newアクション）
• POST /users : ユーザー新規登録（createアクション）
• GET /users/:id : ユーザー詳細（showアクション）
• GET /users/:id/edit : ユーザー情報の編集フォーム（editアクション）
• PATCH/PUT /users/:id : ユーザー情報の更新（updateアクション）
• DELETE /users/:id : ユーザー情報の削除（destroyアクション）

こちらは「複数のリソース」を扱うのに適していて、URLのパターンに :id が入るのがポイントです。
データベースに複数のユーザーが存在する場合、それぞれにIDが割り当てられ、/users/1, /users/2 のようにアクセスできるようになります。

使い分けのポイント

上記を踏まえ、初心者の方がよく迷うのが「resourceとresourcesをどっちを使えばいい？」という問題です。

• もし対象となるリソースが1つだけ存在するもの（ユーザーのマイページやサイト設定など）であれば resource
• もし同じ種類のデータが複数存在するもの（複数のユーザーや記事、コメントなど）であれば resources

このように考えればシンプルです。
最初から深く悩む必要はなく、単一のページか複数レコードがあるかどうかで使い分けを判断するとよいでしょう。

実際のルーティング例

routes.rbでの書き方

Railsアプリのルーティングは、config/routes.rb というファイルに記述します。
たとえばユーザー管理をしたい場合、以下のように書くと多数のルートがまとめて生成されます。

コピー
Rails.application.routes.draw do
  resources :users
end

実際に rails routes のコマンドをターミナルで実行すると、上記の設定で自動生成されたルート一覧が表示されます。
一覧には index, show, new, create, edit, update, destroy といった名前付きルートが表示され、それぞれのHTTPメソッドやURLパターンが確認できるはずです。

一方で、プロフィールページなどを単一リソースとして扱いたい場合は、以下のように書きます。

コピー
Rails.application.routes.draw do
  resource :profile
end

このように設定すると、/profile というURLが基本となり、IDなし のルートが作られます。

onlyやexceptオプション

Railsでは、作成されるルートを限定するために only や except オプションをよく使います。
たとえば以下のように書くと、index と show のルートだけが生成され、不要なものは作られません。

コピー
resources :users, only: [:index, :show]

逆に、except を使えば指定したものだけを除外する形でルートを作れます。
実務では「新規ユーザー登録は管理者だけが行うから new や create は不要」というようなケースがよくあるため、こうしたオプションを活用すると便利です。

ネスト（入れ子）したルーティング

ブログ記事に対してコメントを紐づけたい場合など、リソース同士の階層関係を表現したいことがあります。
Railsでは、以下のように書くことで「ネストしたルーティング」を作ることができます。

コピー
Rails.application.routes.draw do
  resources :posts do
    resources :comments, only: [:create, :destroy]
  end
end

この場合、生成されるパスは /posts/:post_id/comments のように、親リソース（posts）のIDを含む形になります。
実務では、コメントがどの記事に対するコメントかを区別するために有用です。

コントローラとアクションの役割

RailsのMVC構造

Railsには、 モデル (Model) ・ビュー（View）・コントローラ（Controller） という基本的な構造があります。 ルーティングが受け取ったリクエストは、指定されたコントローラのアクションに処理を委ねる仕組みになっています。

たとえば resources :users が自動生成したルートは、UsersController の index, show, new, create, edit, update, destroy の各アクションと対応します。
そして、そのアクションの中でモデルを操作し、最終的にビューへデータを渡すのが典型的な流れです。

CRUDアクションとHTTPメソッド

RESTfulルーティングでは、CRUDアクション と呼ばれる4つの基本的な操作が重要視されます。
それぞれに、Railsでは次のようなアクションが割り当てられます。

• Create: create アクション (HTTPメソッドはPOST)
• Read: index（一覧表示） と show（詳細表示） (HTTPメソッドはGET)
• Update: update アクション (HTTPメソッドはPATCH/PUT)
• Delete: destroy アクション (HTTPメソッドはDELETE)

たとえばユーザーを新しく追加したいときは、ブラウザから POST /users というリクエストを送ります。
それが UsersController#create というアクションにつながり、そのアクション内で新しいユーザーを作成します。

このように、HTTPメソッド と コントローラのアクション が対になる形で処理が行われるのが、RESTfulルーティングの特徴です。

RESTfulなルーティングがもたらすメリット

URL設計がわかりやすい

URL と HTTPメソッド から「何をしたいのか」が自明になるため、プロジェクトに参加した人が後からコードを読んでも理解しやすいです。
/users に GET なら一覧を表示、/users/:id に GET なら詳細を表示、/users/:id に PATCH なら更新する、という具合に動作がルール化されています。

コードの保守性が高まる

RailsによるRESTfulルーティングは、コントローラのアクション名とURLを一貫して整理できるので、機能が増えても構造が破綻しにくいです。
たとえば新しいリソースを追加したい場合も、同じように resources :articles などと書けば、似たルールのルーティングが自動的に生成されるので混乱が少なくなります。

テストやAPI化にも便利

同じパターンでURLや処理を管理しているため、テストを書くときやAPIとして公開するときにも効果的です。
RESTfulなルーティングはWeb APIの設計にも向いているため、後からAPIのエンドポイントを設ける場合でも整理がしやすくなります。

実務での活用シーン

ユーザー管理機能

登録・一覧表示・詳細確認・編集・削除など、一通りのユーザー管理機能は、resources :users と UsersController のアクションによってまとめて実装しやすくなります。
特に実務では「ユーザー情報を更新する」「特定ユーザーを削除する」といった一連の操作を頻繁に行うため、このRESTfulな仕組みのおかげでコントローラが煩雑になりにくいです。

設定画面の単一管理

「アプリケーション全体に対する設定はひとつしかない」というような場合には resource :setting のように単数形を使います。
この場合、GET /setting によって設定画面を表示し、PATCH /setting で設定を更新するという流れが自然に組み込めます。

ネストしたデータの例

ブログ記事とコメントのように、一つのデータに対して複数の子データを関連付けたいケースは多いです。
そのような場合にネストしたルーティングを使っておくと、「どの記事に対するコメントなのか」がURLパスに含まれるため、可読性が高く、デバッグの際も混乱が少なくなります。

よくあるエラーと対処法

No route matches [GET] エラー

ルーティングに存在しないURLへアクセスした場合によく見られるエラーです。
特に、誤って resources :user のように書いてしまっているケースでは、URLに :id が含まれない想定になるため、想定通りのパスが生成されません。
IDを含むURLを使いたいときは 複数形 の resources が正解です。

Uninitialized constant コントローラ名

ルーティング設定は正しいのに、実際に呼び出されるコントローラが未定義の場合に発生します。
たとえば resources :users を設定しているのに UsersController クラスが定義されていないと、このエラーになります。
コントローラのクラス名・ファイル名が正しいか確認しましょう。

予期しないパスが生成されてしまう

初心者の方には、単数形と複数形を混同してしまい、意図しないURLが生成されるケースが多いです。
rails routes コマンドで確認する癖をつけると、うまく設定できているかすぐに把握できます。

まとめ

Railsにおける resource / resources は、RESTfulなルーティング をとても簡単に実現してくれる強力な仕組みです。
単一リソースなら resource :設定名、複数リソースなら resources :モデル名（複数形） と書くだけで、CRUD操作に必要なURLパターンとHTTPメソッドが生成されます。

実務においても、同じ書き方で統一するだけで可読性や保守性がぐんと高まります。
初心者の方は最初のうち、コントローラのアクション名がどのルートと対応しているのかを一つひとつ確認すると良いでしょう。
「index は一覧を扱う」「show は1つのIDに対応する詳細を扱う」「new と create」「edit と update」という組み合わせをしっかり頭に入れておくと、疑問点が減っていくはずです。

そして、どうして単数形を使うのか、どうして複数形を使うのかの判断軸を知るだけで、使い分けは簡単にできます。
特に一つのリソースに限定した設定画面やプロフィール画面などは resource、複数のデータを管理する場合には resources というルールだけ覚えておけば、ほとんどのケースに対応可能です。

RESTfulルーティングを正しく理解し、Railsの設計に上手に活かせるようになれば、実務の効率や保守のしやすさが明確に向上するでしょう。
初めての方でも、ぜひこの仕組みに慣れて、Railsならではのわかりやすいコードを作り上げてみてください。