はじめに
Ruby on Railsを使って開発していると、「なんとなく動いている」状態になりがちですよね。
この記事では、Web技術の歴史を振り返りながら、Rackとは何か、そしてなぜRailsが今の形になったのかを体系的に理解していきます。
対象読者
- Railsを使い始めたばかりの方
- 「CGI」「Servlet」「Rack」という言葉を聞いたことはあるけど、違いが分からない方
- Web技術の全体像を理解したい方
Web技術の進化：静的HTMLから動的Webへ
初期のWeb：静的HTMLのみ
1990年代初頭、Webサイトは静的なHTMLファイルをそのまま返すだけでした。
クライアント → Webサーバー → HTMLファイルを返す → クライアント
問題点：
- 誰が見ても同じ内容
- ユーザーごとのカスタマイズ不可
- データベースと連携できない
CGI（Common Gateway Interface）の登場
CGIは、Webサーバーが外部プログラムを実行して、動的にHTMLを生成する仕組みです。
クライアント → Webサーバー → CGIプログラム実行 → 動的HTML生成 → クライアント
特徴：
- 初期はPerlがよく使われた
- リクエストごとにプロセスを起動
- ユーザーごとに違う画面を表示できる
問題点：
- 遅い：毎回プロセスを起動するため、パフォーマンスが悪い
- スケーラビリティに課題
Java Servletの登場
Javaが登場し、Servletという技術が生まれました。
改善点：
- プロセスを常駐させる（毎回起動しない）
- 高速化
- エンタープライズ向けの機能が充実
// Servletの例
public class UserServlet extends HttpServlet {
protected void doGet(HttpServletRequest request,
HttpServletResponse response) {
// ユーザー一覧を取得してHTMLを返す
}
}
問題点：
- 設定ファイルが複雑
- 開発の手間が大きい
フレームワーク時代の到来
2000年代に入り、開発を効率化するフレームワークが登場します。
| 言語 | フレームワーク | 登場年 |
|---|---|---|
| Ruby | Ruby on Rails | 2004年 |
| Python | Django | 2005年 |
| PHP | Laravel | 2011年 |
| Java | Spring Boot | 2014年 |
Ruby on Railsの革新：
- Convention over Configuration（設定より規約）
- 少ないコードで多くのことができる
- 開発速度の向上
Rackとは何か？
ここで重要な概念がRackです。
Rackの定義
Rack = Ruby用のWebサーバーインターフェース（仕様）
Webサーバー（Nginx/Apache）
↓
【Rack Interface】← これは仕様・約束事
↓
Rubyアプリケーション（Rails/Sinatra等）
よくある誤解：「Rackはミドルウェア？」
答え：NO！
Rackは**ミドルウェアではなく、インターフェース（仕様）**です。
ミドルウェアとインターフェースの違い
| 項目 | ミドルウェア | インターフェース |
|---|---|---|
| 性質 | 動作するソフトウェア | 仕様・プロトコル |
| 例 | Nginx、MySQL、Redis | USB規格、HTTP、Rack |
| 役割 | 実際に処理を行う | 接続方法の標準規格 |
比喩で理解する
- USB規格 = Rack（接続の標準仕様）
- USBケーブル = PumaやUnicorn（実装）
- パソコンと周辺機器 = WebサーバーとRailsアプリ
Rackの役割
Rackは「WebサーバーとRubyアプリケーションをつなぐ標準的な約束事」を定義しています。
Rackがない世界：
Nginx用のRails ❌
Apache用のRails ❌
Nginx用のSinatra ❌
Apache用のSinatra ❌
→ 全部別々に作る必要がある！
Rackがある世界：
どのWebサーバーでも ✅
どのRubyフレームワークでも ✅
自由に組み合わせOK！
RackとJava Servletの比較
| 項目 | Java | Ruby |
|---|---|---|
| インターフェース仕様 | Servlet API | Rack |
| アプリケーションサーバー | Tomcat、Jetty | Puma、Unicorn |
| フレームワーク | Spring、Struts | Rails、Sinatra |
どちらも「Webサーバーとアプリケーションをつなぐ仕様」という点で同じです。
Rackを使っているRubyエコシステム
Rackに準拠したフレームワーク
- Ruby on Rails
- Sinatra
- Hanami
- Grape（API専用）
全てRackインターフェースに準拠しているため、同じアプリケーションサーバーで動きます。
Rackに準拠したアプリケーションサーバー
- Puma（Railsのデフォルト）
- Unicorn
- Passenger
- Thin
どのフレームワークでも動作します。
他の言語の同等技術
Rackと同じような仕組みは、他の言語にも存在します。
| 言語 | インターフェース名 |
|---|---|
| Ruby | Rack |
| Python | WSGI (Web Server Gateway Interface) |
| Perl | PSGI (Perl Web Server Gateway Interface) |
| Node.js | Connect/Express middleware |
全て「Webサーバーとアプリケーションをつなぐ標準仕様」という同じ役割を持っています。
まとめ
Web技術の進化
静的HTML
↓
CGI（動的HTML、でも遅い）
↓
Servlet/Rack（高速化、標準化）
↓
フレームワーク（開発効率化）
Rackの重要ポイント
- Rack = インターフェース（仕様）、ミドルウェアではない
- WebサーバーとRubyアプリをつなぐ標準規格
- Java の Servlet API と同じ役割
- Rackのおかげで、Webサーバーとフレームワークを自由に組み合わせられる
なぜこれを理解すべきか
- Railsのエラーメッセージが理解しやすくなる
- デプロイ時の選択肢（Puma、Unicornなど）の意味が分かる
- Web技術全体の見通しが良くなる
次のステップ
次の記事では、Rails内部のMVCアーキテクチャについて、データがどう流れるのかを図解で学びます！
- 【記事2】Rails初心者が完全理解すべきMVCアーキテクチャ（準備中）
- 【記事3】HTTPリクエスト/レスポンスとActiveRecordを理解する（準備中）
参考資料
この記事が役に立ったら、ぜひいいねやストックをお願いします！
質問やフィードバックもお気軽にコメントください 😊