Railsルーティングの基本を初心者向けに解説！routes.rbの書き方と実務での活用ポイント

バックエンド開発•2025/2/6

はじめに

Railsでアプリケーションを開発する際、ルーティングは大切な構成要素のひとつです。
ルーティングの正しい理解と管理ができると、機能を追加したり変更したりするときもスムーズに進められます。
しかし初心者の皆さんにとっては、routes.rbファイルに書かれた独自の構文や、resourcesなどの便利メソッドの使い方が少しわかりづらいかもしれません。
そこで本記事では、Railsルーティングの基本を丁寧に解説します。
MVCとの関連性から実務的な活用シーンまでを織り交ぜながら進めますので、はじめてRailsを触る方でも安心して読み進めてください。

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

ルーティングの役割とMVCとの関係
Rails特有のルーティング記法（get, postなど）
resourcesを使ったルーティングの利点やカスタマイズ方法
ネストされたルートや名前空間の設定方法
実務で考えるべきルーティング設計のポイント

ここからは順を追って、具体例を交えながら理解を深めていきましょう。

Railsルーティングとは？

Railsのルーティングは、ブラウザからのリクエストをコントローラの特定アクションへ振り分ける仕組みです。
たとえばURLが/articlesにアクセスされたとき、Railsはどのコントローラのどのアクションを呼び出すかを、routes.rbファイルに定義されたルーティング情報から判断します。
こうした仕組みによって、フレームワーク側が適切にリクエストをハンドリングし、開発者はMVCの役割分担に沿ってコードを書き分けられるわけです。

ルーティングが果たす役割

Railsでルーティングを設定すると、以下のようなメリットがあります。

URLからアクションへ直感的に結びつけられる

指定したURLパターンに対して、コントローラとアクションを明示的に対応できます。

可読性が高まる

他の開発者が見ても、どのURLがどの処理に対応しているかを把握しやすくなります。

保守性が向上する

ルーティングを分かりやすく整理しておけば、機能追加や修正が発生したときも追従が容易です。

RailsはMVCアーキテクチャを採用しているため、モデル、ビュー、コントローラが役割を分担しています。
ルーティングはその入り口部分を担うことで、アプリケーション全体の流れをスムーズにつなげる重要なポジションにあるのです。

MVCとの関係

Railsアプリケーションは、URLからのリクエストがまずルーティングを通り、次にコントローラへ渡されます。
コントローラはモデルを使ってデータを取得・加工し、それをビューに渡して画面表示に役立てます。
この一連の流れの最初のステップを、ルーティングが司っているのがポイントです。

もしルーティングが適切に設定されていないと、リクエストがどのコントローラのどのアクションに渡るのか曖昧になります。
結果として意図した画面や処理に辿り着けないことが多くなるでしょう。
逆にルーティングをしっかり理解しておけば、どんなURLでどんな処理を行うかをコントロールできるため、開発効率が大きく向上します。

基本的なルーティングの書き方

routes.rbファイルには、Railsが提供するメソッドを用いてパスを定義していきます。
もっとも基本的な形は、HTTPメソッドとパス、そしてコントローラ#アクションをセットで指定するやり方です。

単一リソースへのパスを定義する

たとえば、GET /helloというリクエストをhello_controllerのindexアクションへ振り分けたい場合は、以下のように書きます。


get 'hello', to: 'hello#index'

ここではHTTPメソッドにgetを指定し、続けてURLパス'hello'を記述しています。
to:の後ろにコントローラ名#アクション名を指定することで、リクエストが届いたときに呼び出すアクションを決定しています。

複数リソースへのパスを定義する

複数のURLパターンを一気に定義したい場合、個別に書く方法と**resourcesメソッド**を活用する方法があります。
たとえば以下のように複数行を使って記述する方法はわかりやすいですが、URL数が増えると行数が膨大になりがちです。


get    'articles',     to: 'articles#index'
get    'articles/:id', to: 'articles#show'
post   'articles',     to: 'articles#create'
patch  'articles/:id', to: 'articles#update'
delete 'articles/:id', to: 'articles#destroy'

このように一覧表示から詳細表示、更新、削除までを個別に書いていくと、メンテナンス時に手間がかかるケースもあります。
こうした状況に対応するために提供されているのがresourcesという仕組みです。
後ほど詳しく解説しますが、まとめてCRUD操作のURLを生成してくれるので、基本的にはresources :articlesのように書く方がスッキリします。

コントローラとアクションを指定する記法

Railsでは、HTTPメソッドごとにget, post, patch, deleteなどのメソッドを呼び出す記法と、matchを使った記法があります。
ただし一般的には、HTTPメソッドを明示的に指定する形で書くほうがわかりやすいため、最初はgetやpostを使うやり方を覚えるのがおすすめです。

get, post, patch, delete の基本

Railsがサポートする主なHTTPメソッドは以下の通りです。

get
post
patch
put
delete

patchとputはいずれも更新リクエストで使われますが、Railsの一般的な慣習では部分的更新にpatchを使うのが一般的です。
実装上は、HTMLフォームから送信する場合に隠しフィールドを用意してpatchを送るケースが多いです。
これらのメソッドをそれぞれ明確に記述しておくと、アプリケーションの振る舞いを把握しやすくなります。

controller#action の指定方法

前述のように、to:オプションを利用してコントローラ名#アクション名を指定するのが基本です。
例としては次のようになります。


get 'profile', to: 'users#show'
post 'signup', to: 'registrations#create'

もしコントローラを分かりやすいようにadminやapiなどで名前空間を切っている場合は、以下のように記述することもあります。


get 'dashboard', to: 'admin/dashboard#index'

こうすると、app/controllers/admin/dashboard_controller.rbファイルのindexアクションが呼び出されます。

Named Routesの使いどころ

RailsはNamed Routesという機能を提供しています。
これは、特定のルートに名前を付けておくことで、テンプレートやコントローラからURLを呼び出すときにヘルパーメソッドを使えるようにする仕組みです。

ヘルパーメソッドでURLを簡単に呼び出す

Named Routesを使うと、たとえばarticles_pathやarticle_path(@article)のような形でURLを生成できます。
URLをハードコーディングせずに済むため、ルートが変更になってもヘルパー名さえ変わらなければ参照先を統一的に管理できるメリットがあります。

Railsはresources :articlesなどを定義すると自動的にNamed Routesも作成してくれます。
この便利な機能によって、コードの可読性と保守性が格段に向上します。

例: articles_path, new_article_path など

resources :articlesを定義すると、以下のようなヘルパーメソッドが使えます。

articles_path → 記事の一覧ページへのURLを返す
new_article_path → 新規作成フォームへのURLを返す
article_path(@article) → 個別記事詳細へのURLを返す

コントローラやビューでこれらを呼び出すだけで、対応するURL文字列を生成してくれるため、便利です。
もしURLパターンを変更しても、Named Routesは基本的に同じヘルパーメソッド名を維持するため、アプリケーション内のリンク修正を最小限に抑えられます。

Resourceベースのルーティング

Railsルーティングを語るうえで外せないのが、resourcesメソッドです。
これはCRUD操作に必要なルートを自動生成してくれる仕組みで、Railsのメリットを象徴する機能のひとつと言えます。

resources :articles のメリット

resources :articlesと書くだけで、一覧表示、詳細表示、新規作成、更新、削除などのパスがひととおり揃います。
そのため、CRUD機能を提供するテーブルに対しては原則この書き方を利用するのが定石です。
こうしてまとめることで、コード量を大幅に削減できるだけでなく、一貫性のあるURL設計を実現できます。


resources :articles

上記の1行を書くだけで、次の7つのアクションへのルートを定義できます。

index
show
new
create
edit
update
destroy

URLは/articlesや/articles/:id/editといった形で自動生成され、これらのURLに対応するNamed Routesも同時に作られます。

only, except などのオプション

もし上記の7つ全部が必要ない場合は、onlyオプションやexceptオプションを使って不要なルートを除外することができます。
たとえばshowとindexだけにしたい場合は次のように書きます。


resources :articles, only: [:index, :show]

逆に、一部のアクションだけ不要な場合にはexceptオプションが便利です。


resources :articles, except: [:destroy]

このように必要なアクションだけを厳選して定義することで、ルーティングファイルの可読性を高めることができ、セキュリティ上のリスクも減らせます。

ネストされたルーティング

Railsではリソース間に親子関係がある場合、ネストされたルーティングを使って表現できます。
たとえば記事に対してコメントを紐付けるようなケースです。
URLにも構造的な階層を持たせることで可読性を高め、関連リソースがわかりやすくなる利点があります。

子リソースとの関連を表現する

具体的には次のように書きます。


resources :articles do
  resources :comments
end

こうすると、URLは/articles/:article_id/comments/:idのように、記事IDの下にコメントIDがぶら下がる形で定義されます。
記事ごとにコメントを管理するイメージがURL上にも反映されるため、利用者や開発者にとって視覚的に理解しやすくなります。

ネストルートにおけるパスの生成

ネストされたルートでは、Named Routesもネストした形で生成されます。
たとえばarticles_comments_path(@article)のように呼び出せば、特定の記事に紐づいたコメントの一覧パスが返ってきます。
さらに個別のコメントにアクセスする場合にはarticle_comment_path(@article, @comment)といった形式です。

ただしネストの階層が深くなりすぎるとURLが複雑になるため、実務上は2階層くらいで抑えるのが一般的です。
必要に応じて、コントローラやビュー側での設計も意識しておくことが大切です。

カスタムルーティング

Railsのルーティングはresourcesメソッドだけでなく、カスタムルートを設定して独自のURLパターンを定義することもできます。
ユーザーにとってわかりやすいURLを提供したい場合や、外部サービスとの連携時にパスを指定したい場合などに役立ちます。

メンバーとコレクション

resourcesメソッド内では、memberとcollectionというブロックを使い、単一リソースや複数リソース対象のアクションを追加できます。


resources :articles do
  member do
    get 'preview'
  end

  collection do
    get 'search'
  end
end

ここでmemberはURL内に/:idが含まれるルートとして生成されるため、ある特定の記事を対象にした処理に向いています。
一方でcollectionはIDの指定を伴わないルートですので、すべての記事を対象にする検索などに向いています。

ルーティング制約( constraints )の使いどころ

Railsのルーティングでは、パスパラメータの形式に制約をかけたい場合にconstraintsオプションが使えます。
たとえば数字しか受け付けたくない場合は、:idの部分に正規表現を指定できます。


get 'profiles/:id', to: 'profiles#show', constraints: { id: /\d+/ }

こうすることで、数値以外のパスがマッチしないようになります。
実務ではユーザー名を英数字に限定したい、あるいはファイル拡張子を制限したいなどのケースで活用されることがあります。

ルートの制約や名前空間

Railsはアプリケーションが大規模化してくると、管理画面やAPI向けなど機能の種類によってURLを分けたい場面が出てきます。
そんなときに有効なのが、 名前空間 (namespace) やスコープ (scope)を活用する方法です。

namespace :admin などで管理画面を切り分ける

たとえば管理者向けの画面を切り分けたい場合、名前空間を定義してURLを/admin/*配下にまとめることができます。


namespace :admin do
  resources :users
  resources :articles
end

これでURLは/admin/usersや/admin/articlesという形になり、コントローラの呼び出し先もAdmin::UsersControllerやAdmin::ArticlesControllerになるのが特徴です。
見た目にも機能的にも管理者用のルーティングであることがわかるので、実務で多用されるパターンでしょう。

scope や module オプションの活用

似たような方法として、scopeやmoduleを使ってURLやコントローラのパスをカスタマイズする手段もあります。


scope module: :admin do
  resources :users
end

この例ではURLパスにadminが含まれない形で、コントローラだけAdminモジュールを使うことができます。
要件によってURLに名前空間を入れたくないときや、外部サービスとの連携で特定のプレフィックスを付けたくないときに活用すると便利です。

ルートの優先順位や注意点

Railsは上から下へ読み込みながらルーティングを判断します。
もし複数のルートが同じパスをマッチしそうになった場合、上に書かれているルートが優先される点には気をつけましょう。

routes.rbの記述順

たとえば次のように書いた場合は、先に定義したget 'profile'が優先されるため、下に書いたルートが呼ばれなくなります。


get 'profile', to: 'users#show'
get 'profile', to: 'profiles#index'

実際には同じパスを重複定義することはあまりありませんが、似たような正規表現やワイルドカードを使っていると、意図しないマッチが発生する場合もあるので気をつけたいところです。

使わなくなったルートの整理

プロジェクトが成長するにつれて、過去の実装で使わなくなったURLが残っていることは珍しくありません。
必要のないルートはコメントアウトや削除をして、定期的に整理する癖をつけると良いでしょう。

ルーティングが肥大化すると、チームでの開発時に「このURLって今でも使っているの？」と疑問を感じる場面が増えます。
定期的にroutes.rbを見直して、不要なエンドポイントを削ることを習慣化しましょう。

ルートと実務での具体的活用シーン

ここからは、実際の開発でルーティングをどう活かせるかをイメージしやすくするために、よくあるシーンを挙げてみましょう。

APIモードでのルーティング

RailsにはAPI専用モードがあり、ビューを返す代わりにJSONレスポンスのみを扱うケースがあります。
その際のルーティング定義も基本的には同じですが、コントローラでHTMLテンプレートを使わない分、軽量化される特徴があります。
resources :articles, defaults: { format: :json }のように書くと、JSONを返すエンドポイントとして設定しやすいです。

フロントエンドとの連携でのルーティング

Vue.jsやReactなど、フロントエンドのSPA（Single Page Application）と組み合わせて使うときには、RailsがバックエンドAPIの役割を果たすことが多いです。
その場合、ルーティングで管理するURLはほぼAPIエンドポイントになります。
フロントエンド側とは/api/v1/articlesのように名前空間を切り分けておくと、保守しやすくなるでしょう。

メンテナンスしやすいルーティング設計

実務では急な要件変更や、サービス拡大によるパスの増加が起こりがちです。
そうした場合でも、resourcesをベースに最低限のカスタマイズで運用できるように設計しておくのがおすすめです。
さらに、ネストの階層が深くなる前に名前空間を使うなど、早期に設計を見直す姿勢が大切です。

テスト環境でのルート確認方法

Railsには、ルーティングをすばやく確認できる便利なコマンドがあります。

`rails routes` コマンド

アプリケーションのルート一覧をターミナル上で確認したい場合は、プロジェクトルートディレクトリで以下のコマンドを実行します。


rails routes

実行すると、URLパターン、HTTPメソッド、コントローラ#アクション、Named Routeなどが一覧表示されます。
どんなパスが定義されているかを一目で把握できるため、ルーティングを変更したあとに動作確認をする際によく利用されるでしょう。

ルーティング変更時の注意点

ルーティングを変更する場合、フロントエンド側のリンクや既存のAPI呼び出しロジックとの整合性もチェックが必要です。
たとえばarticles_pathをposts_pathに変更したときには、コード全体でarticles_pathを参照している箇所がないか探す必要があります。
Named Routesを使っていれば検索が容易ですが、URLを直書きしている場合は漏れが出やすいので要注意です。

ルーティングを大幅に変更する際は、既存のURLをブックマークしているユーザーへの影響も考慮しましょう。
リダイレクト設定を入れて古いURLから新しいURLに誘導するなどの対応が必要になるケースもあります。

まとめ

Railsのルーティングは、MVCアプリケーションの入り口となる重要な機能です。
resourcesを活用した標準的なCRUDルートから、ネストや名前空間、カスタムルートまで、さまざまな書き方を組み合わせることで柔軟に要件に対応できます。
コードの保守性を高めるためにも、シンプルかつ見やすいルーティング設計を心がけることが大切です。

皆さんのプロジェクトでroutes.rbを編集するときには、ぜひここで紹介したポイントを意識してみてください。
そうすることで、アプリケーション全体の読みやすさや保守性が格段に向上するはずです。