はじめに
「これまでどうやってRailsが成長してきたのか気になるけど、あんまりそれがまとまっている記事がないなぁ🤔」と思い、自分で調べようと思ったのがきっかけで始めたのが、この「【Rails史】Railsの過去を知る」シリーズです✍️
各パートの記事を一つにまとめ、Railsの20年にわたる進化の軌跡を振り返ります🙌
目次
- はじめに
- 目次
- Railsとは?
- Railsの軌跡 - 第1章
- Railsの軌跡 - 第2章
- Railsの軌跡 - 第3章
- Railsの軌跡 - 第4章
- Railsの軌跡 - 第5章
- Railsの軌跡 - 第6章
- Railsの軌跡 - 第7章
- 終わりに
- 参考記事
Railsとは?
Railsとは、プログラミング言語「Ruby」で書かれたWebアプリケーションフレームワークです。Railsは、あらゆる開発者がWebアプリケーション開発で必要となる作業やリソースを事前に想定することで、Webアプリケーションをより手軽に開発できるように設計されています。
参考:Railsガイド-Railsとは何かより
記載されているように、Railsは他のフレームワークと比べて開発する際のコード量が少なく済むにもかかわらず、高機能なWebアプリケーションを構築できることが特徴です!
Railsで作られているサービス
- GitHub(世界最大のソースコード管理サービス)
- Airbnb(民泊仲介サービス)
- Shopify(世界的なECサイト作成プラットフォーム)
- Hulu(動画配信サービス)
- Cookpad(料理レシピ共有サービス)
このように、Railsは多くの有名サービスで採用されており、Webアプリケーション開発において非常に人気のあるフレームワークです✨
Railsの軌跡 - 第1章
〜2003年:Railsがいない当時の状況
-
Railsが誕生する以前、Webアプリケーション開発は主にPHPやPerl、Javaなどの言語で行われており、Web開発は二極化していました。
| 言語タイプ | 代表的な言語 | 特徴 |
|---|---|---|
| スクリプト言語系 | PHP、Perlなど | 手軽に始められるが、フレームワークとしての規約が少なく、ビジネスロジックとHTML表示ロジックが混在した「スパゲッティコード」になりがち |
| コンパイル言語系 | Java、C#など | 堅牢でスケーラブルであり大規模開発に向いていたが、単純なビューの表示でも数千行のXML設定ファイルが必要になるなど、開発の敷居が高かった |
2003年:Rubyの発見
このような状況にフラストレーションを感じていたのが、後にRailsを開発することになるデンマーク出身のプログラマー、David Heinemeier Hansson(DHH氏)でした。
彼は当時、37signals(現Basecamp)のJason Fried氏とともにプロジェクト管理ツールの開発を進めており、当初使用していたPHPに保守性の面などで限界を感じていました。
そんな中、DHH氏はRubyという言語に出会います。Rubyは日本のまつもとゆきひろ氏によって開発されたオブジェクト指向スクリプト言語であり、そのシンプルで直感的な文法と高い柔軟性に魅了されました😳
DHH氏はRubyを使ってプロジェクト管理ツールの開発を進めることに決め、これが後のRails開発の基盤となりました。

DHH氏:Ruby on Railsはどのように生まれ、発展してきたのかより
2004年:Railsが誕生
DHH氏はRubyを使ってプロジェクト管理ツールの開発を進める中で、Webアプリケーション開発における共通の課題に直面しました。例えば、データベースとのやり取り、HTTPリクエストの処理、ビューのレンダリングなど、多くの反復的な作業が必要であることに気づきました。
これらの課題を解決するために、DHH氏は共通の機能を抽象化し、再利用可能なコンポーネントとしてまとめることを考えました。こうしてRailsの原型が誕生し、2004年にオープンソースプロジェクトとして公開されました🧑💻
私😳「てっきりDHH氏が最初からRailsを作ろうと考えていたものかと思ってた!」
Railsの2つの哲学
- DRY(Don't Repeat Yourself):同じコードを繰り返し書かないことを重視し、コードの重複を避けることで保守性を向上させる。
- Convention over Configuration(設定より規約):開発者が明示的に設定しなくても、フレームワークが合理的なデフォルト設定を提供することで、開発の手間を削減する。
2005年:Rails元年と「Web2.0」の衝撃
Rails 1.0のリリース
2005年12月13日、DHH氏はRails 1.0を正式にリリースしました。
Rails 1.0は、開発者にとって非常に使いやすく、生産性を大幅に向上させるフレームワークとして注目を集めました。
Rails 1.0時点の主な機能と構成
| 機能 | 説明 |
|---|---|
| MVCアーキテクチャの確立 | データベースを扱うActiveRecord、リクエストを処理する ActionPack(ControllerとView)といった現在のRailsの核となる構造が正式に導入 |
スキャフォールディング (Scaffolding) |
コマンド一つでCRUD機能の雛形を自動生成する機能が含まれており、迅速なプロトタイピングを可能にした |
| データベースマイグレーション | データベーススキーマのバージョン管理を容易にするマイグレーション機能が導入され、データベースの変更をコードで管理できるようになった |
| Ajaxサポート |
Railsは当時最先端だったAjaxをネイティブにサポートし、インタラクティブなWebアプリケーションの開発を促進した |
"15分でブログを作る" デモの衝撃
- 「
How to build a blog engine in 15 minutes」として知られるDHH氏のプレゼンテーションでは、DHH氏がRailsを使ってわずか15分でブログエンジンを構築する様子が披露され、そのシンプルさと効率性に多くの開発者が驚嘆しました😲 - このプレゼンはRailsの「公式マーケティング」的な役割を果たし、フレームワークが爆発的に普及する決定的な要因となりました。
私😳:「今じゃ当たり前やけど、20年前に15分で作れるのは衝撃やろな」
Rubyの知名度向上とWeb2.0
Railsの登場は、Rubyの知名度を大きく向上させました。RailsはRubyの魅力を引き出し、多くの開発者がRubyに興味を持つきっかけとなりました。
また、2000年代中頃は「Web2.0」と呼ばれるムーブメントが起こり、ユーザー生成コンテンツ、ソーシャルメディア、インタラクティブなWebアプリケーションが注目されていました。
Railsはこのムーブメントの中で、迅速な開発と高い生産性を提供するフレームワークとして、多くのスタートアップや企業に採用されました🙆
2006年:Twitterの誕生と日本上陸
2005年の衝撃から1年、Railsは急速に普及し世界中に広がっていきました。
Twitterの誕生
- 2006年3月、
Railsで作られた「Twitter」がリリースされました。 - 短期間で開発され、急成長したTwitterは、
Railsの柔軟性とスピードを象徴する成功例となりました⭐️
日本にも届いたRails
- 2006年、日本でも待望の翻訳書『RailsによるアジャイルWebアプリケーション開発』が出版され、
Railsの概念や使い方が日本の開発者コミュニティに広まりました📚 - これにより、日本でも多くの開発者が
Railsを学び、開発現場で採用され始めました。
RESTfulアーキテクチャの採用
- 年末リリースの
Rails 1.2では、RESTfulアーキテクチャが正式に採用されました。 - 具体的には、「リソース(モノ)を中心にURLを設計する」というRESTの概念が採用され始めました。
- これによりこの後の
Rails 2.0以降で、RailsがRESTを前提とした設計思想を持つフレームワークとして確立されていきます。
Railsの軌跡 - 第2章
2007年:Rails 2.0のリリースとRESTfulへの転換
2007年12月、Rails 2.0がリリースされました。このバージョンでは、RESTful設計がフレームワークの中心に据えられ、RailsがRESTを前提とした設計思想を持つフレームワークとして確立されました。
これにより、RailsはWebアプリケーション開発における標準的な設計パターンを提供し、開発者がより効率的にアプリケーションを構築できるようになりました👏
Rails2.0リリース
-
RESTfulアーキテクチャの採用によって、URL設計とリソース操作の一貫性が向上⭕️ - それまでの
Rails1.x系では、URLの決め方は開発者の自由(バラバラ)であったが、2.0からはresources :usersのように書くだけで、CRUD操作に対応したRESTfulなルーティングが自動生成されるようになった! -
CSRF(Cross-Site Request Forgery)対策がデフォルトで有効化され、セキュリティが強化された - HTTP Basic認証のサポートが追加され、簡単に認証機能を実装可能に!
私🙄「この頃からRESTful設計がRailsにあったんだ。今でも使われているのはそれほど優れた設計なんだな〜」
REST? RESTful設計?
-
REST(Representational State Transfer)は、Webアプリケーションの設計原則の一つであり、リソース指向のアーキテクチャスタイルを指します。 -
RESTful設計では、リソース(データやサービス)を一意に識別するためにURLを使用し、HTTPメソッド(GET、POST、PUT、DELETEなど)を使用してリソースに対する操作を定義します。 -
Rails 2.0以降で、RailsがRESTを前提とした設計思想を持つフレームワークとして確立されていきます。
余談
この時期にDHH氏がRails開発にMacBookを使用していたこともあり、RailsコミュニティではWindowsからMacユーザーへ移行が進んだみたいです💻
「Web開発=Mac」というイメージがありますが、この頃からだったのかもしれません🤔
また、2007年は初代iPhoneが発売された年でもあり、PCだけではなくモバイル端末で見え方も意識され始めました。
2008年:GitHubの登場とMerbの台頭
GitHubの登場
2008年2月にGitHubが正式にローンチされました!
2008年4月には、Railsプロジェクト自体がそれまで利用していたSubversionからGitHubへ移行しました。
これ以降、世界中のエンジニアがプルリクエストを通じてRailsの開発に参加しやすくなり、オープンソースとしての発展速度がさらに加速しました。
Merbの台頭
この頃、Merbという新しいRubyフレームワークがRailsの代替として注目を集めていました。
理由は、機能が増えすぎて「重く遅い」という批判がいくつかあったRailsに対して、Merbは軽量で高速なフレームワークとして設計されており、特にパフォーマンスを重視する開発者から支持を得ていたためです。
Merbはモジュール化された設計を採用しており、必要な機能だけを選択して使用できる柔軟性がありました。
RailsとMerbの統合発表
2008年12月23日、RailsのDHH氏とMerbの主要メンバーらは、「RailsとMerbの統合」を電撃発表しました📣
-
理由
- 二つの似たフレームワークでコミュニティを分断させるのではなく、
Merbの「クリーンな内部設計」とRailsの「使いやすさ」を合体させて、最高のものを作るという決断でした。
- 二つの似たフレームワークでコミュニティを分断させるのではなく、
-
結果
-
Rails 3.0として統合され、Merbの設計思想やコンポーネントがRailsに取り入れられました。 -
Rails3以降の「エンジン機能」「Active Model」「クリーンなルーティング」などの多くは、Merbの思想やコードがベースになっています。
-
私😳「まさかの激アツ展開キター!!敵だと思ってた相手と手を組んでより高みを目指すとかドラマやん!」
日本語化が標準機能に
-
Rails 2.2で、i18n(国際化)機能が標準で組み込まれました。 - それまで日本語対応には複雑な改造が必要でしたが、これ以降
ja.ymlファイル一つで簡単にアプリを日本語化できるようになりました。 -
Railsコミュニティでは、日本語の翻訳ファイルが充実し、多くの開発者が日本語でアプリケーションを構築できるようになりました🎉
2009年:Rails 2.3のリリースとRails 3への布石
Railsにとって「統合」と「次世代への準備」の1年となりました。
前年末に発表されたMerbとの統合を具体化し、現在も使われている重要なツールの原型が完成した時期です!
Rails2.3のリリース
2009年3月、Rails3への重要な架け橋となるRails 2.3がリリースされました。以下の機能が導入され開発体験が大幅に向上しました🚀
| 機能 | 説明 |
|---|---|
| Rackのサポート | Webサーバーとフレームワークを繋ぐ標準規格「Rack」に完全対応したことにより、ミドルウェアの利用が容易になり、柔軟なアプリケーション構築が可能に |
| Rails Engine | アプリケーション内で再利用可能なコンポーネントを作成できる「エンジン」機能が導入され、プラグインやモジュールの開発が容易に |
| Nested Attributes | 親子関係にあるモデルの属性を一括で保存・更新できる機能が追加され、フォーム処理が簡素化 |
Rails3.0の開発加速と「Bundler」の誕生
2008年末のMerbとの統合宣言を受け、2009年はRails 3の開発が本格化しました🧑💻
-
Bundlerの登場
- ライブラリの依存関係を管理する
Bundlerプロジェクトが本格始動しました(Yehuda Katzらによる)。 - それまでの不安定なGem管理を劇的に改善し、現代の全てのRubyプロジェクトに欠かせないインフラとなっています。
- ライブラリの依存関係を管理する
-
内部構造の見直し
-
Merbのモジュール化された設計思想を取り入れ、Railsの内部構造が大幅に見直されました。 - 例えば、
Action MailerやActive Recordなどをより独立性の高いモジュールに再構築する作業が進められました。
-
Rails Engineの登場⚙️
-
Rails 2.3で導入された「エンジン」機能は、アプリケーション内で再利用可能なコンポーネントを作成できる仕組みです。 - これにより、プラグインやモジュールの開発が容易になり、コードの再利用性が向上しました。
- 現在では、多くの人気Gem(例:
Deviseなど)がエンジンとして実装されており、Railsアプリケーションに簡単に組み込むことができます。
私🧐「今では当たり前の機能も最初からあったわけではなくて、課題を解決するために取り入れられてきたんやな〜」
Railsの軌跡 - 第3章
2010年:Rails3.0のリリースと「現代的なコード」の幕開け
2010年8月29日にRails 3.0がリリースされました!
前年末からの「Merbとの統合」が実を結び、Merbの「モジュール性(部品の切り離しやすさ)」と「パフォーマンス」を取り入れたRailsはよりモダンで堅牢なフレームワークへと進化を遂げました。
Rails3.0リリース
| 機能 | 説明 |
|---|---|
Merbとの結合 |
内部構造がモジュール化(コンポーネント化)され、不要な機能をオフにしたり、特定のライブラリを入れ替えたりすることが容易に |
Active Recordの改善 |
クエリインターフェースが強化され、複雑なクエリをより簡潔にメソッドチェーンで直感的にSQLを組み立てる現在のスタイルが導入 |
Bundlerの標準採用 |
依存関係管理ツールであるBundlerが標準で採用され、Gemのバージョン管理と依存関係の解決が容易に。rails new をすると自動的にGemfileが作られる今のスタイルは、ここから始まった |
XSS対策の強化 |
クロスサイトスクリプティング(XSS)攻撃に対する防御機能が強化され、デフォルトで安全なHTML出力が行われるようになった |
Active Recordの書き方が今のスタイルに
- Before(Rails2.x):巨大なハッシュで条件を指定していました
users = User.find(:all, :conditions => ["age > ?", 18], :order => "created_at DESC")
- After(Rails3.x〜):現在のメソッドチェーンで条件を指定するスタイルに変わりました
users = User.where("age > ?", 18).order(created_at: :desc)
私😮「メソッドチェーンで直感的に書けるのは最初からじゃなかったんや😳アップデート感謝🙏」
スタートアップの主力に
-
Rails 3.0のリリースにより、Railsはスタートアップ企業の主力フレームワークとしての地位を確立しました。 - 2010年ごろには、
TwitterやHuluなどの巨大サービスがRailsを主要技術として活用しており、「プロトタイプ用」から「大規模商用サービス用」へとその評価を高めていきました。
2011年:Rails 3.1のリリースとフロントエンドへの挑戦
この年はRails 3.1がリリースされ、フロントエンド開発における重要な機能が導入されました!
Rails3.1リリース
2011年8月31日にリリースされ、下記のような新機能が追加されました。
| 機能 | 説明 |
|---|---|
| アセットパイプラインの導入 | これまでは、CSSやJSファイルを書いたらそのままサーバーに置いていたが、それを「加工してから配信する」という仕組みを標準化 |
| jQueryのデフォルト採用 | それまで標準だったPrototype.jsに代わり、世界的に普及していたjQueryがデフォルトのJSライブラリになった |
CoffeeScriptのサポート |
JavaScriptをより簡潔に書けるCoffeeScriptがサポートされ、JSコードをより効率的に記述可能に(※現在はJavaScript自体が進化したため、あまり使われなくなった) |
Sassのサポート |
CSSをより効率的に記述できるSassがサポートされ、スタイルシートの保守性が向上 |
アセットパイプラインとは?
-
Rails 3.1で導入されたアセットパイプラインは、CSSやJavaScriptなどのフロントエンドアセットを効率的に管理・配信する仕組みです。 - 開発者はファイルを細かく分けて整理しながら開発でき、本番環境では自動的に1つの高速なファイルとして配信され、この「開発のしやすさ」と「実行時の速さ」の両立は、当時のWebフレームワークとしては画期的な機能でした。
- 具体的には、下記を自動で行う仕組みです。
- 複数のCSS/JSファイルを1つに結合(結合)
- 不要な空白やコメントを削除してファイルサイズを縮小(圧縮)
- SassやCoffeeScriptなどのプリプロセッサをコンパイル
- キャッシュ制御のためのファイル名にハッシュを付与
私😲「フロントエンドの管理が楽になるのはありがたい!当たり前に使っているけど当時は画期的だったんだな〜」
2011年は、「アセットパイプライン」という概念を導入したことで、Railsが単なるサーバーサイドの道具ではなく、「フロントエンドのパフォーマンス管理まで責任を持つフルスタックフレームワーク」へと進化した重要な年だったと思います。
2012年:Rails 3.2のリリースとセキュリティ強化
Rails3.2リリース
2012年1月にリリースされ、以下のような新機能が追加されました。
| 機能 | 説明 |
|---|---|
| 開発モードの高速化 | 依存関係の解決ロジックが改善され、ファイル変更後の再読み込みが非常に速くなり、開発体験が向上 |
Active Recordのexplainメソッド |
クエリの実行計画を確認できるexplainメソッドが追加され、パフォーマンスチューニングが容易に |
「マスアサインメント脆弱性」とGitHubハッキング事件
- 2012年、
GitHubがハッキングされる事件が発生しました。この事件は、Railsアプリケーションにおける「マスアサインメント脆弱性」を悪用したものでした。 - マスアサインメント脆弱性とは、ユーザーからの入力を一括でモデルに割り当てる際に、意図しない属性まで更新されてしまう脆弱性のことです。
事件の詳細
- ロシアのプログラマー(Egor Homakov氏)が、GitHubのとある脆弱性を指摘しました。
- 彼は警告のために、Railsの「マスアサインメント」という仕組みの穴を突き、GitHubの公開リポジトリ(Rails本家のリポジトリ)の管理者権限を勝手に奪取して見せました(もちろん悪用はせず、すぐに報告しました)
- GitHubの問題ではなく
Railsの問題であったため、Railsを使用している多くのアプリケーションが影響を受ける可能性がありました。 - GitHubはこの脆弱性を修正し、Homakov氏のアカウントを一時停止した後、最終的に復旧させむしろ彼と積極的にこの問題を議論しました。
Strong Parametersの導入
- この事件を受けて「送られてきたデータをそのまま保存するのは危険すぎる」という認識が広まりました
- 対策としては、コントローラーで「どの属性を更新して良いか」を明示的に指定する
Strong Parametersが導入されました - これにより、意図しない属性の更新を防ぎ、セキュリティが大幅に強化されました
- 2012年にGemとしてリリースされ、後の
Rails 4.0で標準機能として組み込まれました
私😲「ストロングパラメーターがなかった時の脆弱性について、まさかGitHubで実際に証明されていたとは😂」
Railsの軌跡 - 第4章
2013年:Rails4.0リリースとTurbolinksの登場
Rails4.0のリリース
2013年6月にRails4.0がリリースされました!主な内容は以下の通りです。
| 機能 | 説明 |
|---|---|
| Strong Parameters | 2012年の事件を受け、セキュリティ対策であるStrong Parametersが標準機能へ。これにより、開発者は「許可したデータ以外は通さない」という安全なコードを自然と書くようになり、Railsアプリの堅牢性が飛躍的に向上した |
| Turbolinksの導入 | 「SPAのように、画面遷移を高速にしたい」。その願いをサーバーサイド主導で叶えるTurbolinksがデフォルトで搭載された。 JSを駆使しなくても、Railsの規約に従うだけでネイティブアプリのようなサクサク感が出せる。この「Rails Way」なアプローチは、多くの開発者を驚かせた |
| 非同期キューの標準化 | ActiveJob(Rails 4.2で完成)の前段階として、キューイングの仕組みが整理され始めた |
| Ruby2.0への対応 | 2013年2月に登場した Ruby 2.0 をフルサポートし、最新のRubyの機能を活用できるようになった |
Turbolinksって何がすごかったの??
-
通常のWeb(遅い...😑)
- リンククリック → サーバーにリクエスト送信 → サーバーでHTML生成 → ブラウザで再描画
-
SPA(Reactなど)(速い!🚀でも作るのが大変😅)
- リンククリック → APIにリクエスト送信 → JSON受信 → JavaScriptで画面更新
-
Turbolinks(速い!🚀しかもRailsだけで作れる!😆)
- リンククリック → サーバーにリクエスト送信 → CSS/JSは使い回す → 必要な部分だけ差し替え
当時、ReactやAngularなどのSPAフレームワークが台頭し始めていましたが、Railsコミュニティでは「もっとシンプルに、Railsだけで高速な画面遷移を実現したい!」というニーズがありました。
Turbolinksはそのニーズに応え、Rails開発者にとって画期的なソリューションとなりました!
※ ただし、jQueryなどの既存のJavaScriptライブラリとの相性問題があり、多くの開発者を悩ませることにもなりました...😅
Dockerの登場
2013年3月にはDockerが誕生し、Railsアプリケーションの実行環境をコンテナ化して配布する、現在の開発スタイルの基礎がこの年に生まれました。
Dockerについて詳しくはこちらをご確認ください👀
2014年:Rails4.1&4.2リリース | Rails10周年
Rails4.1リリース
2014年4月にリリースされたRails4.1では、開発者の日常的な不満を解消する実用的な新機能が多数導入されました🎉
| 機能 | 説明 |
|---|---|
| Active Record Enums | データベースの数値を、プログラム上ではわかりやすい言葉(active, archivedなど)として扱えるEnumsが登場した 「 status = 1 って何だっけ?」と悩む必要がなくなり、user.active? のように英語を読む感覚でコードが書けるようになった |
| Action Mailer Previews | メール送信機能の開発・デバッグを容易にするAction Mailer Previewsが導入された メールの内容をブラウザでプレビューできるようになり、開発効率が向上した |
|
Spring (アプリケーションプリローダー) |
コマンド実行時のRailsの起動を高速化するツールが標準搭載された テストやマイグレーションなど、頻繁に実行するコマンドの待ち時間が大幅に短縮され、開発者のストレスが軽減された |
secrets.ymlの導入 |
アプリケーションの秘密情報(APIキーやパスワードなど)を管理するためのsecrets.ymlが導入されたセキュリティ管理が体系化され、より安全なアプリケーション開発が可能になった |
enumについて詳しくはこちらをご確認ください📝
私😌「メールのプレビュー機能はたまにしか使わんけど、パッと確認したいときに便利なんよな」
Rails4.2リリース
2014年12月にリリースされたRails4.2では、以下のような新機能が追加されました!
| 機能 | 説明 |
|---|---|
| Active Job | 非同期処理(バックグラウンドジョブ)の標準インターフェースが導入された。これにより、Sidekiqなどのバックエンドを簡単に切り替えられるようになった |
| メールの非同期送信 |
Active Jobを利用して、deliver_later メソッドでメール送信を簡単にバックグラウンド化できるようになった |
| WebConsole | 開発中のエラー画面上で直接Rubyコードを実行してデバッグできる、インタラクティブなコンソールが標準で統合された |
Rails10周年🎊
2004年の誕生から10周年を迎え、シカゴで開催されたRailsConf 2014では、創設者のDHH氏やYehuda Katz氏らがこれまでの10年を振り返り、将来の展望を語る記念すべき講演が行われました。
2015年:次世代への準備を重ねた年
2015年は、従来の「サーバーサイドでHTMLを生成するRails」という枠を超え、「リアルタイム」や「API」といったモダンWebの要求に全方位で応える準備を整えた年でした!
Rails5.0の発表
2015年のRailsConfでDHH氏より発表されたRails5.0は、コミュニティに大きな期待を抱かせました🥳
| 機能 | 説明 |
|---|---|
| Action Cable | 今までNode.jsなどの外部サービスに頼っていたリアルタイム通信を、Railsだけで実現するためのフレームワークが導入されることが発表されたこれにより、チャットアプリや通知機能などのリアルタイム機能が簡単に実装できるように! |
| APIモード | それまで外部Gem(rails-api)として提供されていたAPI専用モードが公式に統合されることが発表されたこれにより、フロントエンド( React/Vueなど)とバックエンドを分離したモダンなアプリケーション開発スタイルに正式対応した |
APIモードって何がいいの?😵💫
従来のRailsとAPIモード、何がどう違うんだろう??
-
従来のRails(フルスタックモード)
- コントローラーはHTMLレスポンスを返すことが前提
- ビューやアセットパイプラインなど、フロントエンド関連の機能が多数含まれる
-
APIモード
- コントローラーはJSONレスポンスを返すことが前提
- ビューやアセットパイプラインなど、フロントエンド関連の機能は含まれない
- 軽量で高速なAPIサーバーを構築可能
APIモードを使うことで、フロントエンドとバックエンドを明確に分離した設計が容易になり、モダンなWebアプリケーション開発に最適化された環境が提供されました🎉
Rails5.0 β版リリース
2015年12月にはRails5.0のβ版がリリースされ、長年使われてきたrakeコマンドがrailsコマンドに統合されました。
rake db:migrateがrails db:migrateと書けるようになったのはこの時からです。
エコシステムの変化
-
Reactの台頭
- 2013年にFacebookが開発した
Reactが急速に普及し始め、Railsを「APIサーバー」として使い、フロントエンドをReactで構築する構成が増え始めた時期でした。
- 2013年にFacebookが開発した
-
Webpackerの登場
-
RailsアプリケーションでモダンなJavaScript開発を容易にするためにWebpackをどう導入するかが議論され始めました🤔
-
DHH氏は「The Rails Doctrine(Railsの教義)」を整理し、シングルページアプリケーション(SPA)全盛期にあっても、Railsのフルスタックなアプローチがいかに生産的であるかを改めて強調しました。
Railsの軌跡 - 第5章
2016年:Rails5.0正式リリース
長期間のベータテストを経て、2016年6月にRails5.0が正式リリースされました! 主な新機能は以下の通りです。
Rails5.0のリリース
| 機能 | 説明 |
|---|---|
| Action Cable | WebSocketをRailsの流儀で扱えるようになり、チャットやリアルタイム通知などの機能を標準で実装可能に |
| APIモード | JavaScriptフレームワーク(React/Vueなど)やモバイルアプリのバックエンドに特化した、軽量なRailsアプリを構築する設定が追加 |
| Railsコマンドの統合 | それまでrakeコマンドで行っていた操作(マイグレーション等)が、すべてrailsコマンド(rails db:migrateなど)に統合され、利便性が向上 |
| ApplicationRecordの導入 | すべてのモデルの基底クラスとしてApplicationRecordが導入され、共通のロジックや設定を一元管理できるように |
Action Cableとは?
- WebSocketを利用して、リアルタイム通信を可能にするRailsのフレームワーク
- チャットアプリや通知システムなど、リアルタイム性が求められる機能を簡単に実装できる
- Railsの既存のMVCアーキテクチャとシームレスに統合されているため、学習コストが低い
Turbolinks5の導入
-
Rails5では、Turbolinks5が導入され、従来のTurbolinksよりも高度な機能と柔軟性が提供されました。 -
Turbolinks5は、部分的なページ更新や履歴管理の改善など、より洗練されたユーザー体験を実現しました。
2017年:Rails5.1リリースとJavaScriptエコシステムの強化
2017年4月にリリースされたRails5.1では、JavaScriptエコシステムの強化に重点が置かれました⭐️
Rails5.1リリース
| 機能 | 説明 |
|---|---|
| Webpackerの導入 | JavaScriptパッケージ管理ツールのwebpackをRailsで利用可能にするラッパーが登場しました。これにより、React、Vue、Angularといったモダンなフレームワークの導入が公式にサポートされた |
| Yarnのサポート | これまではGemでJSライブラリを無理やり管理していたが、JavaScriptのパッケージマネージャーであるYarnが公式にサポートされ、JavaScriptライブラリの管理が容易に |
| System Testsの導入 | Capybaraを利用したシステムテストが標準でサポートされ、ブラウザを介したエンドツーエンドのテストが簡単に書けるようになった |
| Encrypted Secrets | 機密情報を暗号化して管理する仕組みが導入され、セキュリティが強化された |
Webpackerとは?🤔
- JavaScriptのモジュールバンドラーであるWebpackをRailsアプリケーションで簡単に利用できるようにするGem
-
app/javascriptディレクトリを作成し、ここにJavaScriptコードを配置することで、モダンなJavaScript開発が可能に - 当時、Reactなどの最新JSを使うにはWebpackというビルドツールが必須であったが、設定が難解で、Railsと組み合わせるのは至難の業だったので、Webpackerの登場は非常に大きな前進となった
私😮「正直なところWebpackとかWebpackerとかJS関連の部分ちゃんと理解できていないけど、RailsができるだけJSライブラリを使いやすくしようと改善してくれていることは分かった🙆」
2018年:Rails5.2リリースとインフラ機能の強化
2018年4月にリリースされたRails5.2では、これまで外部ライブラリに頼っていた多くの機能が標準化されました🔧
Rails5.2リリース
| 機能 | 説明 |
|---|---|
| Active Storageの導入 | Amazon S3やGoogle Cloud Storageなどのクラウドストレージへのファイルアップロード・管理を、モデルから直接扱えるようになった。画像のリサイズ(要ImageMagick等)も標準でサポート |
| Bootsnapの標準採用 | アプリケーションの起動を劇的に高速化する bootsnap がデフォルトで有効になり、開発時の待ち時間がさらに短縮 |
| Redis Cache Storeの標準サポート | Redisをキャッシュストアとして公式にサポートし、高速なキャッシュ運用が可能に |
| Encrypted Credentials | 機密情報管理の新しい仕組みが導入され、config/credentials.yml.encに暗号化された形式で保存されるようになった |
GitHubの買収
- 2018年6月に
Railsで構築された世界最大の開発プラットフォームGitHub が、Microsoftによって買収されるという衝撃的なニュースがありました。
DHH氏の主張
- DHH氏は、この頃からJavaScriptを多用するSPAの流行に対して懐疑的な立場を強め、Rails単体でユーザー体験を完結させることの重要性を再度強調しました。
- これがのちの
HotwireやStimulusの登場につながっていきます。
Railsの軌跡 - 第6章
2019年:Rail6.0リリースとZeitwerkの導入
2019年8月にRails6.0がリリースされました! 主な新機能は以下の通りです。
Rails6.0のリリース
| 機能 | 説明 |
|---|---|
| Webpackerがデフォルトに | それまでのアセットパイプラインに代わり、WebpackベースのJavaScript管理が標準となった。これにより、モダンなJavaScriptフレームワークの利用が容易に |
| Action Textの導入 | リッチテキストエディタを簡単に実装できるAction Textが追加された。複雑な装飾テキストの保存・表示が数行のコードで実現可能に |
| Action Mailboxの導入 | 受信メールをRailsアプリ内で処理できるAction Mailboxが追加され、メールベースのワークフロー構築が容易に |
| Multiple Databaseのサポート | 複数のデータベースを簡単に扱えるようになり、リードレプリカの利用やデータベース分割が容易に |
| Zeitwerkの導入 | 新しいコードローダーであるZeitwerkがデフォルトとなり、コードの自動読み込みがより堅牢かつ柔軟に |
Zeitwerkとは?🤔
- Rubyのコードローダーで、Rails6からデフォルトで採用された
- ファイル名とクラス名の規約に基づいて自動的にコードを読み込む
- Railsは「ファイル名からクラス名を探す」機能を持っているが、以前の仕組み(
Classicモード)は少しバグっぽかったり、予期せぬエラーが出たりすることがあった -
Zeitwerkはこれらの問題を解決し、より一貫性のあるコード読み込みを実現🙆
Stimulusの普及
- DHH氏らが提唱した軽量JavaScriptフレームワークStimulusが、重厚なSPAへの対抗軸としてRails開発者の間で急速に普及しました。
2020年:Rails6.1リリースと改善の年
2020年12月にリリースされたRails6.1では、開発者体験とパフォーマンスの向上に焦点が当てられました⭐️
Rails6.1リリース
| 機能 | 説明 |
|---|---|
| 水平スケーリングの強化 | Rails6.0で導入された複数データベースサポートが強化され、水平スケーリングがより容易に |
| Active Storageの改善 | 複数のサービス(S3、Google Cloudなど)を同時に扱えるようになり、ファイル管理の柔軟性が向上 |
| strict_loadingの導入 | N+1問題を未然に防ぐため、関連モデルの読み込みを強制的に制限する機能が登場 |
Hotwireの発表
- DHH氏率いる37signalsが、Hotwire (HTML Over The Wire) を電撃発表しました。
-
Turboの登場
- かつてのTurbolinksを置き換えるTurboがリリースされました。これにより、SPA(React等)を使わなくても、サーバー側で生成したHTMLを部分的に更新するだけで、非常に滑らかで高速なユーザー体験を実現できる道が示されました。
-
Railsの原点回帰
- 「JavaScriptを大量に書くのではなく、HTMLをサーバーから送る」というRails本来の哲学を現代技術で再定義したもので、コミュニティに大きな衝撃を与えました。
2021年:Rails7.0リリースとWebpackerからの脱却

2021年12月にリリースされたRails7.0は、JavaScript管理の大幅な刷新と開発者体験の向上を目指しました🎉
Rails7.0のリリース
| 機能 | 説明 |
|---|---|
| Importmapの導入 | Webpackerに代わる新しいJavaScript管理手法としてImportmapが導入され、Node.jsやWebpackを使わずにJavaScriptライブラリを直接ブラウザで読み込むことが可能に |
| Hotwireの公式サポート | Hotwire(TurboとStimulus)が公式にサポートされ、SPAのような体験をRailsだけで実現可能に |
| Active Recordの暗号化 | データベースレベルでのカラム暗号化が標準機能として導入され、個人情報などの管理がより安全に |
DHH氏はRails7のリリースに際し、「The One Person Framework」と題したブログ記事を公開しました。
巨大なテック企業がやっているような「専任のフロントエンドチーム、バックエンドチーム、インフラチーム」がいなくても、「Railsを使えば、たった一人のエンジニアでも、それらに匹敵する高機能なアプリが作れる」という力強いメッセージとなっています。
私😌「Rails7でImportmapが導入されたことで、JavaScriptの複雑なビルドツールから解放されて、よりシンプルに開発できるようになったのはありがたい🙆♂️」
「てかほんまにフロントエンドは移り変わりが激しいな😇」
Railsの軌跡 - 第7章
2022年:Rails7.0の普及
Rails7.0で導入された「ビルドツールを使わない開発」が実際のプロジェクトで試され、その利便性が証明されました。
-
Import Maps の定着
- Node.jsやWebpackをインストールせずにJavaScriptを扱う「No Build」スタイルが、小〜中規模の開発において圧倒的なスピードをもたらしました。
-
Hotwire の実践
- Turbo と Stimulus を使い、SPA(React等)に匹敵するリッチなUIをサーバーサイド中心で構築する手法が注目されました。
DHH氏からの発表
-
Propshaftの登場
- 重厚なアセットパイプライン(Sprockets)に代わる、非常にシンプルでモダンなアセット管理ツール Propshaft が発表されました
-
クラウドからの脱却
- 自社サービス(Basecamp/HEY)をクラウド(AWS)から自前サーバーへ移行する「Cloud Exit」を宣言し、大きな議論を呼びました。これが2023年に発表されるデプロイツール「Kamal」の開発に直結しました。
2023年:Rails7.1リリースとKamalの登場
-
Rails7.1は2023年10月にリリースされ、開発者の生産性を高める実用的な機能が導入されました⭐️ - これまで高度な知識が必要だった「Docker環境の構築」が、Railsの標準機能になりました。
rails newするだけですぐに使える最適化されたDockerfileが手に入ります。 - また、DHH氏が提唱する「Cloud Exit(クラウド脱却)」を実現するためのツールKamalが正式にリリースされました。
Dockerさえ動けば、AWS、GCP、または月額数ドルの安価なVPSでも、ゼロダウンタイムで簡単にRailsアプリをデプロイできるようになり、複雑なPaaS(Heroku等)や高価なマネージドサービスに頼らない、「独立した開発者」というRailsの理想が再提示されました!
2024年:Rails7.2&8.0リリース
- 2024年8月に
Rails7.2、11月にRails8.0がリリースされました!
Rails7.2リリース
| 機能 | 説明 |
|---|---|
| Dev Containerのサポート | アプリケーションでDev Container設定を生成する機能が追加され、開発環境のセットアップがさらに簡単に |
| PWAファイルがデフォルトに | 新規Railsアプリ作成時にPWA(Progressive Web App)関連のファイルが自動生成され、PWA対応が容易に |
Rails8.0リリース
| 機能 | 説明 |
|---|---|
| Propshaftの標準化 | Propshaftが正式にRailsのデフォルトアセットパイプラインとなり、シンプルで高速なアセット管理が可能に |
| SQLiteの強化 | SQLiteが大幅に強化され、小規模から中規模のアプリケーションでの利用がさらに促進された |
Rails誕生から20年が経過し、DHH氏が掲げる「シンプルさ」と「独立した開発者」の理念が再び強調されました。Railsは、これからも進化を続け開発者にとって最適なフレームワークであり続けるはずなので、楽しみにしRails開発者の方々に感謝し、これからも使っていきたいと思います😌
終わりに
Railsの歴史を振り返ることで、これまでの成り立ちなど全然知らなかったので非常に勉強になりました📚
また、これまで色んな方のお力がありRailsがここまで成長してきたことに改めて感謝の気持ちでいっぱいです🙏
最後まで読んでいただきありがとうございました😊
参考記事









