MVCモデルは古くありません。2026年10月時点で、Ruby on Rails 8.1.4、Laravel 13.35、ASP.NET Core MVC（.NET 10）はどれもモデル・ビュー・コントローラーの3分割で作られています。古いと言われているのは、ブラウザやスマートフォンの画面をMVCで組む使い方です。
この記事では、古いと言われる理由を層ごとに切り分け、「MVVMも古いのか」という次の疑問にも答えます。最後に、MVCのままでよい条件と、MVVMや別の構成へ移るべき条件を表にまとめました。MVC・MVVM・MVPの違いをコードで比べたい場合はMVCとは？MVVM・MVPとの違いを同じ機能のコードで比較をご覧ください。
まとめ
- サーバーサイドのMVCは現役：Rails 8.1.4（2026年9月24日）、Laravel v13.35.0（2026年10月6日）、ASP.NET Core MVC（.NET 10系列・最新パッチ10.0.12を当てる前提で2028年11月14日までサポート）が3分割を保っています。
- 古いと言われるのはブラウザ側：SPAではReactなどのコンポーネントが画面と状態を受け持ち、コントローラーを置く設計は主流から外れました。
- MVVMも古くない：WPFと.NET MAUIでは、公式ドキュメントがMVVMを設計パターンとして解説しています。Androidの公式ガイドはMVVMという語を使わず、ViewModelと単方向データフロー（UDF）を推奨しています。
- 移行が必要なのは条件付き：サーバーがHTMLを返す業務アプリならMVCのままで構いません。双方向データバインディングを持つUIプラットフォームで画面状態が多い場合はMVVMが向いています。
- コントローラーの肥大化は移行理由にならない：マイクロソフトの公式ドキュメントも、業務ロジックはコントローラーからドメインモデルへ移すよう注記しています。パターンを替える前にここを直します。
サーバーサイドMVCの現在地：2026年10月時点の主要フレームワーク
サーバーがリクエストを受けてHTMLを返す構成では、MVCは今も標準です。主要なフレームワークの最新版を各配布元で確認すると、次のとおりです。
| フレームワーク | 最新版（2026年10月12日確認） | 公開日 | MVCの扱い |
|---|---|---|---|
| Ruby on Rails | 8.1.4 | 2026年9月24日 | 公式ガイドがMVCで構成と明記 |
| Laravel | v13.35.0 | 2026年10月6日 | Controllers章・Views章が独立 |
| ASP.NET Core MVC | .NET 10.0.12 | 2026年9月8日 | MVCパターンのフレームワーク |
| Django | 6.1系ドキュメント | – | MTVと呼ぶがMVCに対応 |
Railsの公式ガイド（v8.1）はGetting Started with Railsで「Rails code is organized using the Model-View-Controller (MVC) architecture.」と書いています。Laravelの公式ドキュメントにもViewsの章があり、ビューは「コントローラーやアプリケーションのロジックを表示のロジックから切り離す」ものと説明されています。
ASP.NET Core MVCは.NET 10（LTS）向けが公式ドキュメントの既定表示です。.NETのサポートポリシーでは、.NET 10のサポート終了日は2028年11月14日です。次の.NET 11も2026年9月8日にRC1が出ています。少なくとも2028年まで保守が約束されている技術を「古い」と呼ぶのは無理があります。
JSONだけを返すAPIサーバーにはビューがありません。この場合、MVCかどうかはほとんど意味を持たず、コントローラーとドメイン層の分け方が設計の中心になります。
「古い」の正体：ブラウザ側でコントローラーが主役を降りた経緯
この章では、MVCへの批判のうち、ブラウザの中で画面を組む方法の変化を取り上げます。サーバー側の話と混ぜると議論がかみ合いません。
2007年のサーバー側MVCへの批判と適用範囲
MVCの終わりを告げる主張は新しいものではありません。InfoQ日本語版は2007年11月12日にService Oriented UI(SOUI)の出現はMVCの死を意味するのだろうか？を掲載し、Ajaxの普及でサーバー側のMVC（MVC2）は時代遅れになると主張したNolan Wright氏とJeff Haynie氏の意見を紹介しています。
それから約19年を経た2026年10月も、RailsとLaravelではMVCに基づく構成が使われています。「死んだ」と言われたのは、サーバーが画面を毎回作り直す方式の一部でした。MVCという分け方そのものではありません。
Reactの一方向データフローとコンポーネント
現在のブラウザ側は、コンポーネントが表示と状態をまとめて持つ構成が主流です。Reactの公式ドキュメントThinking in Reactは「React uses one-way data flow」と書き、データは親から子のコンポーネントへ流れると説明しています。双方向データバインディングより記述が少し増えることも、同じページで認めています。
Reactは独立したControllerクラスを要求しません。ユーザー入力を受けて状態を更新する処理は、コンポーネントのイベントハンドラーやコールバックとして書きます。ブラウザ内でMVCの名前が使われなくなったのは、この役割の置き方の違いによるものです。ただし、Reactで画面を組んでも、APIの先にあるサーバーはRailsやASP.NET Core MVCのようなサーバー側フレームワークで組めます。ブラウザ側からMVCが外れても、サーバー側の出番は残ります。役割の分担がどう変わったかはフロントエンドとバックエンドの違いとは？役割・言語・連携と開発発注時の体制設計を解説で整理しています。
名前で判断しない：1978年の原ノートから続く語義のずれ
MVCという言葉は、考案された時点から意味がずれています。名前が古いことを、採用をやめる理由にしないでください。
考案者のTrygve Reenskaug氏は、自身のページ（2026年10月時点で元のURLは404のため、Internet Archiveの保存版で確認）に、1978年にXerox PARCで最初の実装と原ノートを書いたと記しています。そのノートが定義したのはModel・View・Controller・Editorの4語でした。Model-View-Controllerという名前に落ち着いたのは1979年12月10日付のノート「Models-Views-Controllers」です。
同じページで、Reenskaug氏はSmalltalk-80のMVCを「自分がXerox PARCを去った後にJim Althoff氏らが実装したもので、自分は関わっていない」と書いています。Althoff氏はControllerを少し違う意味で使っており、Smalltalk-80のControllerはReenskaug氏の言うEditorにあたります。
現代のフレームワークでもずれは続いています。Djangoの公式FAQでは、viewは利用者に見せるデータを選び、templateは見せ方を受け持つと説明しています。コントローラーにあたるのは、URL設定に従ってリクエストを適切なviewへ送るフレームワーク自体で、この分け方をMTV（model・template・view）と表現しています。名前が違っても、データ・表示・入力処理を分けるという考え方は同じです。
MVVMは古いのか：WPF・.NET MAUI・Androidで見る2026年の位置づけ
「MVCが古いならMVVMはどうか」と続けて調べる人が多くいます。結論から言うと、MVVMも古くありません。ただし、プラットフォームごとに立場が違います。MVVMの仕組みそのものはMVVMとは？仕組み・構成要素とMVC/MVPとの違いを実装例で解説で扱っています。
WPF・.NET MAUIにおけるMVVMの適用根拠
MVVMはJohn Gossman氏が2005年10月のブログIntroduction to Model/View/ViewModel pattern for building WPF appsで示したパターンです。そこでは、MVVMは「ビューをデザイナーが担当する現代的なUI開発プラットフォーム向けのMVCの変形」とされ、データバインディングの仕組みに頼ると書かれています。
この前提はWPFと.NET MAUIに今も当てはまります。.NET MAUIの公式アーキテクチャ文書はMVVMを、業務ロジックと表示ロジックをUIから切り離すパターンとして説明しています。実装を支えるCommunityToolkit.Mvvmも、NuGetで8.4.2（2026年3月25日）が公開されています。WPF自体の現状はWPFとは？2026年も現役か・WinFormsやWinUI 3との違いと.NET 10での使い方にまとめています。
Android公式ガイドのViewModel・UDF推奨と適用条件
Androidのアーキテクチャの推奨事項（2026年10月5日更新）は、単方向データフロー（UDF）に従うことを「Strongly recommended」としています。ViewModelがUIの状態を公開し、UIからの操作はメソッド呼び出しで受け取る形です。同じページは、ViewModelは画面単位で使い、再利用する小さなUI部品には使わないよう求めています。
このページとアプリアーキテクチャガイドの本文には、MVVMという語が1回も出てきません。ViewModelは「状態はViewModelからUIへ、操作はUIからViewModelへ」という一方向の流れの中で使われています。この記述から読み取れるのはUDFの推奨であって、MVVMが古いという評価ではありません。ViewModelも、その利点がアプリに当てはまる場合に使うよう推奨されています。Jetpack Composeでの書き方はJetpack Composeとは？宣言的UIの仕組みとBOM運用・採用判断を解説を参照してください。
MVCのままでよい条件・移行すべき条件の判断表
パターンの新旧ではなく、画面をどこで組み立てるかで決めます。次の表は、作るものごとの判断です。
| 作るもの | 判断 | 理由 |
|---|---|---|
| サーバーがHTMLを返す業務Webアプリ | MVCのまま | Rails・Laravel・ASP.NET Coreの標準 |
| JSONを返すAPIサーバー | MVCかは論点外 | ビューが無い |
| WPF・.NET MAUIのアプリ | MVVM | データバインディング前提 |
| Android（Jetpack Compose） | ViewModel＋UDF | 公式の推奨事項 |
| ReactなどのSPA | コンポーネント＋一方向データフロー | イベントハンドラーで状態を更新 |
避けるべきなのは、サーバーがHTMLを返す既存のMVCアプリを、「古いから」という理由でMVVMへ作り替えることです。ASP.NET Core MVCでも、画面に渡すデータをまとめるViewModel型は公式ドキュメントで説明されており、ビューを簡潔に保つ目的ならMVCのまま使えます。画面用のViewModel型を置くことと、データバインディングを前提にしたMVVMへ移ることは別の判断です。
逆に、移行を検討すべきなのは、1画面に入力欄や表示の切り替えが多く、サーバーとの往復のたびに画面全体を作り直すのが遅くなっている場合です。まず通信時間と再描画の範囲を測ります。部分更新で足りるなら、Turbo Framesのようにページの一部だけを差し替える方法でMVCのまま解決できます。複雑な画面状態をブラウザで持つ必要があるときに、その画面だけReactなどのコンポーネントへ切り出します。
コントローラーの肥大化を直す順序：パターン変更の前にやること
「MVCは古い」と感じるきっかけで多いのは、コントローラーが数百行に膨らんで読めなくなることです。これはパターンの寿命ではなく、責務の置き場所の問題です。マイクロソフトのOverview of ASP.NET Core MVCも、コントローラーのロジックが複雑になりすぎないよう「業務ロジックをコントローラーからドメインモデルへ押し出す」よう注記しています。複数のアクションが同じ種類の処理を繰り返すなら、その共通処理をフィルターへ移すよう勧めています。フィルターは例外処理や認可のような横断的な処理をまとめる仕組みです。
次のC#コードは、注文確定の割引計算をコントローラーからOrderクラスへ移した構成例です。コントローラーには、注文の取得・保存・画面遷移だけが残ります。OrderLine、ShopDbContext（Entity Framework Core）、using、Doneビューは省略しています。これらを補った.NET SDK 10.0.401の環境で、小計9,999円は割引なし、10,000円は9,000円、10,001円は9,000.9円になることを確認しました。
public class Order
{
public int Id { get; set; }
public List<OrderLine> Lines { get; } = new();
public decimal Total { get; private set; }
public string Status { get; private set; } = "Draft";
public void Confirm()
{
var subtotal = Lines.Sum(l => l.Price * l.Quantity);
Total = subtotal >= 10000m ? subtotal * 0.9m : subtotal;
Status = "Confirmed";
}
}
public class OrdersController : Controller
{
private readonly ShopDbContext _db;
public OrdersController(ShopDbContext db) => _db = db;
[HttpPost]
public async Task<IActionResult> Checkout(int orderId)
{
var order = await _db.Orders.Include(o => o.Lines).FirstAsync(o => o.Id == orderId);
order.Confirm();
await _db.SaveChangesAsync();
return RedirectToAction(nameof(Done));
}
public IActionResult Done() => View();
}割引の条件が変わっても、修正するのはOrder.Confirmだけです。このメソッドはデータベースも画面も使わないので、単体テストを書くときにコントローラーを組み立てる必要がありません。Railsでモデル側が膨らんだ場合の分け方はRailsのFat Model対策｜1500行model.rbを分割する4手法と判断基準、層をさらに分けるならクリーンアーキテクチャとは？4層と依存性ルールを原典で解説し、いらない場面の判断基準までが参考になります。
移行を考えるのは、この切り出しを済ませた後です。業務ロジックをドメイン層に分けておけば、画面側を替えるときもそのまま再利用できます。ただし、SPAへ移す場合はAPIの境界、認証、入力検証、画面状態の管理も見直しが必要です。
よくある質問
MVCモデルは古いのですか？
古くありません。2026年10月時点で、Rails 8.1.4、Laravel v13.35.0、ASP.NET Core MVC（.NET 10）がモデル・ビュー・コントローラーの3分割を採っています。古いと言われるのは、ブラウザ内でコントローラーを置いて画面を組む使い方で、ReactなどのSPAではコンポーネントと一方向データフローが主流になりました。サーバーがHTMLを返す業務アプリであれば、MVCを選んで問題ありません。
MVVMは古いのですか？
古くありません。WPFと.NET MAUIでは公式ドキュメントがMVVMを設計パターンとして解説しており、CommunityToolkit.Mvvm 8.4.2（2026年3月25日）も公開されています。Androidの公式ガイドはMVVMという語を使っていませんが、ViewModelが状態を公開し、UIが操作をViewModelへ渡す単方向データフロー（UDF）を強く推奨しています。これはMVVMが廃れたという意味ではなく、Androidではその流れ方が指定されているということです。
MVCモデルの欠点は何ですか？
代表的な欠点は、業務ロジックをコントローラーに書き込みやすく、コントローラーが肥大化しやすいことです。もう1つは、画面の状態が多いリッチなUIで、入力のたびに通信して画面全体を再描画する実装が応答を遅くすることです。ただし、この更新方式はMVCの必須条件ではありません。前者は業務ロジックをドメインモデルへ移せばMVCのまま解決します。後者は、部分更新で足りるかを先に確かめ、足りない画面だけをSPAのコンポーネントに切り出します。
MVCモデル以外にどんな選択肢がありますか？
画面側ではMVVM（WPF・.NET MAUI）、MVP、Reactなどのコンポーネントと一方向データフロー、AndroidのViewModelとUDFが主な選択肢です。サーバー側の層の分け方では、クリーンアーキテクチャやオニオンアーキテクチャのように、業務ロジックをフレームワークから切り離す構成があります。MVCとこれらは併用でき、MVCのコントローラーの奥にドメイン層を置く形が一般的です。
3層アーキテクチャは古いですか？
3層アーキテクチャ（プレゼンテーション層・アプリケーション層・データ層）も、Webシステムの基本構成として使われています。MVCは主にプレゼンテーション層の内部をどう分けるかの話で、3層アーキテクチャとは対象の範囲が違います。各層の役割は3層アーキテクチャとインテグレーション層とは｜各層の役割とフロントエンド・バックエンドの担当領域で解説しています。
