Navigation 3 時代でも ViewModel は State Holder であるべきか？

Compose と Navigation 3 が変えた ViewModel の役割

長年、Android 開発では一つの考え方が当たり前とされてきました。

画面の状態（State）は ViewModel に持たせる。

これは単なるベストプラクティスではなく、Android アーキテクチャの基本原則の一つでした。

ViewModel は Configuration Changes（画面回転など）でも破棄されず、さらに SavedStateHandle を使えば Process Death 後の状態復元もできます。

そのおかげで Activity や Fragment は UI を表示することに専念でき、画面の状態はすべて ViewModel が管理する、という設計が一般的になりました。

しかしここ数年で、この考え方は少しずつ変わり始めています。

Compose も Navigation 3 も ViewModel を不要にしたわけではありません。

代わりに、それぞれが 「本来その State を持つべき場所」 を用意するようになりました。

そこで、こんな疑問が生まれます。

Navigation 3 の時代でも、ViewModel は State Holder であるべきなのでしょうか？

🤔 以前の ViewModel は画面の State をすべて抱えていた

Compose が登場する以前は、多くの ViewModel が画面に関するほぼすべての状態を保持していました。


ViewModel
├── UI State
│   ├── text
│   ├── scrollPosition
│   ├── selectedTab
│   └── dialogState
│
├── Navigation State
│   └── screen arguments
│
└── Presentation Logic

この構成には多くのメリットがありました。

- Configuration Changes に強い
- Process Death 後も状態を復元できる
- Activity / Fragment をシンプルに保てる
- UI とビジネスロジックを分離できる

そのため、新しい State が増えたら、

とりあえず ViewModel に置く

という設計が自然になっていました。

🤔 Compose は UI State を UI に戻した

Jetpack Compose は、この考え方を少し変えました。

すべての UI State を ViewModel に持たせる必要はなく、Composable 自身が State を持てるようになったのです。

例えば検索文字列なら、


var query by remember {
    mutableStateOf("")
}

だけで十分です。

さらに Configuration Changes や Process Death を越えて保持したいなら、


var query by rememberSaveable {
    mutableStateOf("")
}

を使えます。

例えば次のような State は、

- TextField の入力内容
- 選択中のタブ
- 展開状態
- ダイアログの表示状態
- スクロール位置

どれも 純粋な UI State です。

ビジネスロジックではありません。

そのため、実際に使っている Composable の中に置く方が責務も分かりやすくなります。

Compose はまず、

「UI State は UI が持つ」

という考え方を広めました。

🤔 Navigation 3 はさらに一歩進めた

Navigation 3 は、この流れをさらに推し進めています。

まず、画面引数を SavedStateHandle 経由で受け渡す必要がなくなりました。

各画面は自分専用の NavKey を持ちます。


data class UserDetail(
    val userId: Long
) : NavKey

さらに Navigation 3 では rememberSerializable が追加されました。

rememberSaveable が Android の保存・復元機構を利用するのに対し、

rememberSerializable は NavEntry 単位 で UI State を保持します。

つまり、UI State は Navigation の Back Stack と一緒に移動するようになります。

画面ごとの State を ViewModel に保存する必要はなく、

各画面自身が UI State を持つ

という構造になります。

役割を整理すると次のようになります。


UI State
    │
rememberSerializable
    │
Composable


Navigation State
    │
NavKey


Presentation Logic
    │
ViewModel

UI State は UI のもの。

Navigation State は Navigation のもの。

どちらも、もう ViewModel が管理すべき State ではありません。

🤔 では ViewModel には何が残るのか？

UI State も Navigation State も ViewModel の役割ではなくなったとしたら、

ViewModel は何を担当するのでしょうか？

実は、やることはまだたくさんあります。


ViewModel
├── Repository の調整
├── ビジネスロジック
├── Flow の変換
├── Paging
├── Retry
└── viewModelScope

ここで面白いことがあります。

この中には、

State そのものはほとんどありません。

あるのは責務です。

ViewModel は

- Repository からデータを取得し
- ユーザー操作に応答し
- ビジネスロジックを実行し
- UI が描画しやすい形へ加工する

という役割を担います。

🤔 ViewModel は「State Holder」ではなく「State Producer」へ

例えば次のような ViewModel を考えてみます。


val uiState = combine(
    userRepository.users,
    settingsRepository.settings
) { users, settings ->
    HomeUiState(
        users = users,
        darkMode = settings.darkMode
    )
}.stateIn(...)

ここで実際の State はどこにあるでしょうか。

ViewModel ではありません。

データの正しい管理場所（Single Source of Truth）は Repository にあります。

ViewModel は、それらを UI 用に変換しているだけです。

つまり ViewModel は

State を保持する存在ではなく、State を生成する存在

になりつつあります。

一見小さな違いに思えますが、

Presentation Layer の考え方を大きく変える変化です。

🤔 State を持つ責任は、それぞれのレイヤーへ

Compose より前は、


ViewModel
├── UI State
├── Navigation State
└── Presentation Logic

という構成が一般的でした。

Navigation 3 では、


rememberSerializable
└── UI State

NavKey
└── Navigation State

ViewModel
└── Presentation Logic

へと役割が整理されます。

Compose は UI State を UI に戻しました。

Navigation 3 は Navigation State を NavKey に任せ、

UI State を NavEntry ごとに保持できるようにしました。

ViewModel が不要になったわけではありません。

責務がより明確になった のです。

🤔 よりシンプルなアーキテクチャ

その結果、アーキテクチャは次のように整理できます。


+----------------------+
|      Composable      |
|----------------------|
| UI State             |
| rememberSerializable |
+----------+-----------+
           |
           v
+----------------------+
|      ViewModel       |
|----------------------|
| Presentation Logic   |
| Flow Transformation  |
| Repository Calls     |
+----------+-----------+
           |
           v
+----------------------+
|      Repository      |
|----------------------|
| Persistent Data      |
| DataStore / Database |
+----------------------+

各レイヤーが、それぞれ最も適した責務を持ちます。

- Composable は UI State
- NavKey は Navigation State
- Repository は永続データ
- ViewModel は Presentation Logic

責務が自然に分離された構造です。