【Rails初心者向け】モデル名は自由につけていいの？Railsの命名規則（Convention）をマスターしよう！

はじめに

こんにちは！
前回の記事でrails g modelコマンドについて解説しましたが、こんな疑問が湧いてきませんか？

「TweetモデルやUserモデルって、もしかしてRails側であらかじめ用意されている特別な名前なの？」
「もしそうなら、他にどんなモデル名があるんだろう？」
「自分が作りたい機能に、どのモデル名を使えばいいか分からない時はどうしよう…？」

僕もまさに同じ疑問を持ちました。「Tweetという名前だからツイートっぽい機能が作れるのか？」なんて思っていた時期もあります。

結論から言うと、その考え方は大きな誤解でした。この記事では、なぜそれが誤解なのか、そしてRailsの根幹にある「設定より規約」という超重要な思想について解説していきます！

大いなる勘違い：「モデル名」はRailsに用意されているものではない

まず、核心から。

モデル名は、Railsによってあらかじめ決められているものでは一切ありません。

UserやTweet、Postといった名前は、あくまで開発者である私たちが、アプリケーションで管理したい「モノ」や「概念」に応じて自由に名付けているだけです。

• Twitter風アプリを作りたい → 「ツイート(Tweet)」という概念を扱いたい → Tweetモデルを作成
• ブログを作りたい → 「記事(Post)」や「コメント(Comment)」を扱いたい → PostモデルやCommentモデルを作成
• ECサイトを作りたい → 「商品(Product)」や「注文(Order)」を扱いたい → ProductモデルやOrderモデルを作成

このように、モデル名は作りたいアプリケーションの仕様によって、開発者がゼロから考えて命名します。

本当の魔法は「設定より規約(Convention over Configuration)」という思想

「じゃあ、なんでTweetって名前だけでRailsは色々やってくれるの？」

その秘密が、Railsの最も重要な設計思想である「設定より規約（Convention over Configuration）」にあります。

これは、「いちいち細かい設定を書かせなくても、決まった命名規則（規約）に従ってさえくれれば、あとはRailsが全部よしなにやってあげるよ！」 という考え方です。

この規約の代表例が、モデル・データベース・コントローラ間の連携です。

要素	命名規則（規約）	例
モデル	単数形・キャメルケース	Tweet
データベースのテーブル	複数形・スネークケース	tweets
コントローラ	複数形・キャメルケース+Controller	TweetsController
ビューのフォルダ	複数形・スネークケース	app/views/tweets/

この規約に従うことで、

• Tweetモデルは、自動的にtweetsテーブルと通信してくれる。
• TweetsControllerは、自動的にTweetモデルを操作する司令塔だと認識される。
• TweetsControllerのアクションは、自動的にapp/views/tweets/フォルダ内のビューファイルを探しに行く。

といった連携が、一切の設定ファイルなしに実現されるのです。
私たちがrails g model Tweetと打った時にRailsがよしなにファイルを作ってくれたのも、すべてこの規約のおかげです。

引用元について
この「設定より規約」という考え方は、Railsの生みの親であるDHH（David Heinemeier Hansson）が提唱したもので、Railsの公式サイトであるRailsガイドにもその哲学が明記されています。

Railsの哲学では「設定より規約」(Convention Over Configuration) が重要視されています。これは、Railsは何かを達成するための「正しい」方法があると仮定し、その方法に従うことを推奨するという意味です。

引用元: Active Record の基礎 - Railsガイド

じゃあ、自分がどのモデルを使えばいいかわからない時は？

モデル名が自由だと分かったところで、次に「じゃあ自分の作りたい機能には、どんな名前のモデルが必要なの？」という疑問が出てきますね。

これは、アプリケーションの設計そのものを考えるプロセスです。以下のステップで考えてみましょう。

1. アプリで管理したい「名詞」を洗い出す

   • 自分が作りたいアプリの主役は誰で、どんなモノが登場しますか？それを「名詞」で書き出してみましょう。
   • 例：料理レシピサイトの場合 → 「ユーザー(User)」「レシピ(Recipe)」「材料(Ingredient)」「レビュー(Review)」など。

2. それぞれの「名詞」が持つ情報を考える

   • 洗い出した名詞が、どんなデータを持つべきか考えます。これがテーブルのカラムになります。
   • 例：「レシピ」なら… title（タイトル）、instructions（作り方）、cooking_time（調理時間）など。

3. 「名詞」同士の関係性を考える

   • 名詞同士がどう関係しているかを考えます。これがモデルのアソシエーション（has_manyなど）になります。
   • 例：「ユーザー」はたくさんの「レシピ」を投稿できる (User has_many :recipes)
   • 例：「レシピ」は一人の「ユーザー」に属している (Recipe belongs_to :user)
   • 例：「レシピ」はたくさんの「材料」を持つ (Recipe has_many :ingredients)

この1〜3で考えた「名詞」が、そのままあなたの作るべきモデル名になります！

おわりに

• モデル名はRailsが決めるのではなく、開発者である私たちが自由に決める。
• ただし、Railsが定めた命名規則（規約）に従う必要がある。
• 規約に従えば、Railsが裏側で様々な設定を自動で行ってくれる。

「どんなモデルが必要か？」を考えることは、アプリケーションの骨格を設計する、開発の最も面白くて重要な部分です。最初は難しく感じるかもしれませんが、このプロセスに慣れることが、Railsエンジニアとしての大きな一歩になります。

ぜひ、自分の作りたいアプリケーションの「名詞」を考えるところから楽しんでみてください！