この記事では、Ruby on Rails や MVC を理解し、 Rails を土台とした Rails API の全体像と処理の流れを解説します。
Rails / Rails API を学習していると、
- どこに何を書くのか
- MVCとは何なのか
- RailsとRails APIは何が違うのか
といった全体像が分からず、手が止まることがあります。
それらを解消するために、この記事を通して、
今後の学習や実装で迷わないための Rails / Rails API の基礎を作っていきましょう。
Railsとは何か？
Railsは、Rubyで書かれた Webアプリケーションを作るためのフレームワーク です。
Railsを使うと、
- 認証
- CRUD（データの作成・取得・更新・削除）
- バリデーション
といった Webアプリケーションで頻繁に必要になる機能を、比較的少ないコードで実装できます。
Railsの大きな特徴は、 Webアプリケーションを役割ごとに分けて設計するための「構造」が最初から用意されている という点です。
その代表的な考え方が MVC です。
MVCとは？
MVCとは、Railsで採用されている 「役割分担のルール」 です。
| 役割 | 名前 | 何をする？ |
|---|---|---|
| M | Model | データ・ビジネスロジック |
| V | View | 画面表示 |
| C | Controller | リクエストの受付・制御 |
Railsでは、この役割分担を前提にアプリケーションが作られています。
Modelの役割
Modelは、アプリケーションの中核となる層です。
データと、それに紐づく業務ルールを扱います。
主な役割は以下です。
- データベースとやり取りする
- データの正しさを保証する（バリデーション）
- 業務上のルール（ドメインロジック）を扱う
Railsでは、小〜中規模のアプリケーションでは、ドメインロジックをModelに書くことが一般的です。
たとえば、
- 「この状態では予約できない」
- 「特定の条件を満たしたときだけ更新できる」
といった “業務的な判断やルール” は、Modelに書かれることが多いです。
一方で、アプリケーションが大きくなり、
- ロジックが複雑になってきた
- 複数のModelをまたぐ処理が増えてきた
といった場合には、サービス層やドメイン層としてロジックを切り出す設計が取られることもあります。
※ まずは「Modelが業務ルールを扱う場所」と理解して問題ありません。
Controllerの役割
Controllerは、リクエストの入口となる調整役です。
- リクエストを受け取る
- どのModelの処理を呼ぶかを判断する
- 必要なデータをViewに渡す
重要なのは、Controller自身に複雑な処理を書かないことです。
Controllerは「流れをつなぐ役割」に専念します。
Viewの役割
Viewは、ユーザーに見せる画面を担当する層です。
- HTMLを生成する
- データを見やすく表示（整形）する
基本的に、ロジックは極力書かず、表示に集中します。
Rails APIとは？
Rails APIとは、「画面表示（View）を持たず、JSONを返すAPIを提供するRailsの使い方」 のことです。
つまり、アプリケーション全体で言うと、
- フロントエンド：React / Next.js
- バックエンド：Rails API
というような構成を前提としています。
Rails APIで使われるMVC
Rails APIでは、MVCのそれぞれの役割が以下のようになります。
| 役割 | Rails APIでの扱い |
|---|---|
| Model | 使う |
| Controller | 使う |
| View | 使わない（React側が担当） |
つまり Rails APIは、MVCのうち「V（画面表示）をフロントエンドに委譲した構成」です。
Rails APIの処理の流れ
以下は、ユーザー操作からRails APIがレスポンスを返すまでの流れを、ざっくりと示したものです。
- ユーザーがブラウザで、Reactで作られたUIを操作する
- ReactがRails APIにHTTPリクエストを送る
- Rails APIがリクエストを受け取る
- ルーティング（URLとControllerを結びつける仕組み）によって、呼び出すControllerが決まる
- Controllerが処理を判断する
- Modelがデータを取得・保存する
- ControllerがJSONとしてレスポンスを返す
※ Controllerでレスポンスを返す点は、RailsもRails APIも共通です。
この流れを押さえておくと、
Rails APIで「どこに何を書くのか」がイメージしやすくなります。
Rails APIのフォルダ構造
それでは最後に、Rails APIにおけるフォルダ構造をざっくりと紹介します。
Railsには多くのディレクトリがありますが、最初はすべてを理解する必要はありません。
まずは、Rails APIで特によく使う、以下のcontrollersとmodelsの2つを押さえましょう。
app/
├── controllers/
├── models/今はこの2つだけ覚えればOKです。
controllers/
controllers/ には、Controllerクラスを定義した .rb ファイルを作成します。
たとえば、users_controller.rb のようなファイルを作成し、そこに リクエストを受け取ってレスポンスを返す処理 を書きます。
Controllerの中では、以下のようなことを行います。
- リクエストを受け取る
- どのModelの処理を呼ぶかを判断する
- Modelの結果をもとに、JSONとしてレスポンスを返す
models/
models/ には、Modelクラスを定義した .rb ファイルを作成します。
たとえば、user.rb のようなファイルを作成し、そこに データと業務ルールを表す処理 を書きます。
Modelの中では、以下のようなことを行います。
- データベースとやり取りする
- データの正しさを保証する（バリデーション）
- 業務上のルール（ドメインロジック）を扱う
おわりに
この記事では、Ruby on Rails の全体像を整理した上で、
Rails API がどのような構造で、どのような流れで動いているのかを解説しました。
Railsは、「Webアプリケーションを作るための機能」と 「役割ごとに整理された構造（MVC）」 をセットで提供してくれるフレームワークです。
Rails API は、その Rails の構造を活かしつつ、
画面表示（View）をフロントエンドに委譲し、APIとして利用する構成 です。
Rails API も、特別に難しい技術ではありません。
- Rails が MVC 構造を前提としていること
- Rails API では Controller と Model が処理の中心になること
- リクエストからレスポンスまでの基本的な流れがあること
といった 全体像と処理の流れ を押さえておくだけで、Rails API のコードはぐっと読みやすくなります。
本記事が、Ruby on Rails / Rails API を「構造と流れを意識しながら読める・書けるようになる」、ための 最初の一歩になれば幸いです。
Rubyとは｜Railsを理解するために最低限知っておきたい基本文法
Railsのルーティングとは｜routes.rbとresourcesの基本をRails APIでわかりやすく解説
Controllerとは｜Rails APIにおけるControllerの役割と書き方をわかりやすく解説
【手順解説】ReactとRails APIで投稿サービスを作る（認証なし）
【初心者向け】DockerでRails APIとPostgreSQLの環境構築をする(M1 Mac)
【初心者向け】DockerでRails APIとMySQLの環境構築をする(M1 Mac)