Ruby on Railsで覚えておきたい“規約”まとめ：Railsらしいコードを書くための基本ルール

Ruby on Railsは「規約より設定（Convention over Configuration）」という思想のもとに作られています。
つまり、すべてを設定で指定しなくても、あらかじめ決められた“お約束”＝規約に従うことで、シンプルで効率的な開発ができるようになっているのです。

しかし、Railsの規約を知らないままコードを書いてしまうと、思わぬエラーや予期しない挙動に悩まされることになります。
この記事では、Rails開発を行う上で必ず覚えておきたい主要な規約を分かりやすく解説します。
これらを理解することで、より“Railsらしい”開発ができるようになります。

MVC構造に基づくディレクトリ規約

Railsは「MVC（Model・View・Controller）」というアーキテクチャを厳密に採用しています。
各役割ごとに配置する場所が明確に決まっており、この規約に従うことが基本です。

  • Model（app/models）：データの管理、ビジネスロジックを担当。
    例）user.rb、post.rb など。
  • View（app/views）：画面の見た目を担当。
    例）app/views/users/index.html.erb
  • Controller（app/controllers）：リクエストを受け取り、適切な処理を行ってViewへ渡す。
    例）users_controller.rb

ファイルを別の場所に置いたり、名前を変えるとRailsが自動的に認識しなくなるため、ディレクトリ構造の規約は特に重要です。

クラス名とファイル名の命名規約

Railsでは「クラス名とファイル名の対応」にも明確なルールがあります。
これを覚えておかないと、uninitialized constant というエラーが出やすくなります。

  • クラス名は キャメルケース（例：UserAccount）
  • ファイル名は スネークケース（例：user_account.rb）
  • モデルは単数形（例：user.rb）
  • コントローラは複数形（例：users_controller.rb）

Railsは内部で自動的に「単数形・複数形」を認識して関連付けを行っているため、命名を間違えると関連付けが機能しなくなります。

テーブル名とモデル名の規約

モデルとデータベースのテーブル名の対応関係にも明確な規約があります。

  • モデル名：単数形（User）
  • テーブル名：複数形（users）

Railsは自動的にモデル名からテーブル名を推測します。
たとえば Book モデルを作成すれば、自動的に books テーブルを参照します。
そのため、あえて違うテーブル名を使いたい場合は self.table_name = 'custom_table' を指定する必要があります。

コントローラとルーティングの命名規約

Railsでは、URLとコントローラ・アクションの対応も規約で決まっています。
routes.rb によって自動的にルートを生成する「resources」を使うのが基本です。

resources :users

この1行で、以下のルーティングが自動生成されます。

HTTPメソッドパスコントローラ#アクション
GET/usersusers#index
GET/users/:idusers#show
POST/usersusers#create
PATCH/users/:idusers#update
DELETE/users/:idusers#destroy

このように、コントローラ名が複数形、アクション名が英単語の現在形で統一されています。
規約に沿うことで、ルーティングを毎回細かく書く必要がありません。

カラム命名規約とタイムスタンプ

Railsでは、データベースのカラム名にも一定のルールがあります。
特に、Railsが自動的に扱うカラム名を知っておくと便利です。

  • id：主キーとして自動的に設定される
  • created_at：レコード作成日時
  • updated_at：レコード更新日時
  • deleted_at：論理削除でよく使用される（手動設定）

これらのカラムは特別な設定をしなくても、ActiveRecordが自動的に値を管理してくれます。
Railsの“魔法のような便利さ”の正体は、こうした規約にあります。

アソシエーションの命名規約

Railsのモデル間の関係（アソシエーション）にも規約があります。
たとえば「ユーザーが複数の投稿を持つ」関係を表す場合、次のように記述します。

class User < ApplicationRecord
  has_many :posts
end

class Post < ApplicationRecord
  belongs_to :user
end

ここで重要なのは、has_many :posts の :posts がモデル Post の複数形である点です。
Railsはこの規約をもとに、関連付けのキーやテーブル名を推測します。
もし命名を誤ると、自動的な関連付けがうまく機能しません。

ビューとパーシャル（部分テンプレート）の規約

Railsでは、app/views 以下に配置されるテンプレートも規約に従って呼び出されます。

たとえば users#index アクションであれば、デフォルトで以下のファイルが呼び出されます。

app/views/users/index.html.erb

また、ビューの共通部分を切り出すときには、パーシャル（部分テンプレート）という命名規約を使います。

_app_header.html.erb

ファイル名の先頭にアンダースコア（_）を付けるのがルールで、呼び出しは次のように行います。

<%= render 'app_header' %>

Railsのテンプレートシステムはこの規約を自動で認識して読み込んでくれます。

マイグレーションファイルの規約

マイグレーションファイルは、命名にタイムスタンプが付くことが特徴です。
たとえば以下のようになります。

20251008091234_create_users.rb

この数字は「作成日時」を意味し、Railsはこの順序に従ってマイグレーションを実行します。
また、ファイル内のクラス名はキャメルケースで記述します。

class CreateUsers < ActiveRecord::Migration[7.0]
  def change
    create_table :users do |t|
      t.string :name
      t.timestamps
    end
  end
end

このように、クラス名とファイル名にも密接な対応関係があります。

テストファイルとRSpecの規約

Railsでは、テストも命名規約に従う必要があります。
test/models/user_test.rb のように、モデル名に _test.rb を付けたファイルが自動的にテスト対象として認識されます。

RSpecを使う場合も同様に、spec/models/user_spec.rb という形で統一します。
ファイル名とクラス名の対応を守ることで、RSpecが自動的に対象クラスを推測してくれます。

規約に従うことで得られるメリット

Railsの規約を理解し、正しく守ることで次のようなメリットがあります。

  1. コードが短くなる
    設定ファイルや冗長な記述を減らせるため、開発スピードが上がる。
  2. チーム開発がしやすくなる
    誰が書いても同じ構造・命名になるため、可読性が高い。
  3. 自動化・スキャフォールドが効く
    Railsの自動生成コマンドが正しく動くのは規約に従っているから。
  4. 学習コストが下がる
    Railsコミュニティ全体で同じルールが共有されている。

まとめ

Ruby on Railsは「規約より設定」という思想によって、開発者の手間を減らし、スピーディーな開発を可能にしています。
しかしその“魔法”の裏には、数多くの明確な規約が存在します。

  • ディレクトリ構造（MVC）
  • クラス名とファイル名
  • モデルとテーブルの対応
  • コントローラとルーティング
  • ビューとパーシャル
  • アソシエーションやマイグレーションのルール

これらを理解して守ることこそが、Railsを「Railsらしく」使いこなす第一歩です。
慣れてくると、これらの規約は“縛り”ではなく、“強力な味方”になります。

Railsの哲学を活かし、スマートで美しいコードを書けるエンジニアを目指しましょう。

タイトルとURLをコピーしました