#iOS | #Android Fashion News

モダンなAndroid開発（Jetpack Compose + MVVM/MVI）において、ViewModelの役割は単なる「データ保持」から「状態管理のハブ」へと進化しました。今回は、3つのアーキテクチャ図を比較しながら、その設計思想の違いを整理します。

🤔 1. 最もシンプルな「State管理のみ」

class TaskViewModel(private val repository: TaskRepository) : ViewModel() {
    // 状態（State）のみを保持
    val uiState: StateFlow<List<Task>> = repository.getTasks()
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), emptyList())

    // 直接関数を呼び出す
    fun addTask(name: String) {
        viewModelScope.launch {
            repository.saveTask(Task(name))
        }
    }
}

@Composable
fun TaskScreen(viewModel: TaskViewModel = viewModel()) {
    // 状態をそのまま収集
    val tasks by viewModel.uiState.collectAsState()
    var text by remember { mutableStateOf("") }

    Column {
        TextField(value = text, onValueChange = { text = it })
        Button(onClick = { 
            // ViewModelの関数を直接叩く (Simple)
            viewModel.addTask(text) 
        }) {
            Text("追加")
        }
        
        LazyColumn {
            items(tasks) { task -> Text(task.name) }
        }
    }
}

特徴:
ViewModelはRepositoryからデータを取得し、State（状態）を保持してViewへ流すだけのシンプルな構造です。

メリット:
コード量が少なく、小規模なプロジェクトや単純な画面には最適。

課題:
ビジネスロジックがViewModelに肥大化しやすく（Fat ViewModel）、View側でのユーザー操作（Action）がどう処理されるかが図示されておらず、双方向のやり取りが曖昧になりがちです。

🤔 2. Domain/Usecaseの導入による責務の分離

// ビジネスロジックを分離
class GetSortedTasksUseCase(private val repository: TaskRepository) {
    operator fun invoke(): Flow<List<Task>> = repository.getTasks().map { it.sortedBy { t -> t.date } }
}

class TaskViewModel(
    private val getSortedTasksUseCase: GetSortedTasksUseCase,
    private val addTaskUseCase: AddTaskUseCase 
) : ViewModel() {

    val uiState = getSortedTasksUseCase()
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), emptyList())

    fun onAddTaskClicked(name: String) {
        viewModelScope.launch {
            addTaskUseCase(name)
        }
    }
}

@Composable
fun TaskScreen(viewModel: TaskViewModel = viewModel()) {
    val tasks by viewModel.uiState.collectAsState()

    // UIロジック（ソート済みデータなど）を表示するだけ
    TaskList(
        tasks = tasks,
        onAddClick = { name -> viewModel.onAddTaskClicked(name) }
    )
}

特徴:
ViewModelの中にDomain/Usecaseという概念が登場します。

進化のポイント:
ビジネスロジックをRepository直呼びではなく、Usecaseとして切り出すことで、ViewModelは「UIの状態管理」に専念できるようになります。

メリット:
ロジックの再利用性が高まり、ユニットテストが書きやすくなります。クリーンアーキテクチャに近い考え方です。

🤔 3. MVI（Intent/Action）とEffectの導入

// 1. 入力(Action)と出力(Effect)を型定義
sealed interface TaskAction {
    data class AddTask(val name: String) : TaskAction
    object Refresh : TaskAction
}

sealed interface TaskEffect {
    data class ShowSnackBar(val message: String) : TaskEffect
    object NavigateToDetail : TaskEffect
}

class TaskViewModel(private val useCase: TaskUseCase) : ViewModel() {
    private val _effects = Channel<TaskEffect>()
    val effects = _effects.receiveAsFlow()

    // 2. Actionを一箇所で受ける (Intent)
    fun dispatch(action: TaskAction) {
        when (action) {
            is TaskAction.AddTask -> handleAddTask(action.name)
            TaskAction.Refresh -> { /* リフレッシュ処理 */ }
        }
    }

    private fun handleAddTask(name: String) {
        viewModelScope.launch {
            useCase.add(name)
            // 3. 状態変化ではない「副作用」を通知
            _effects.send(TaskEffect.ShowSnackBar("保存しました"))
        }
    }
}

@Composable
fun TaskScreen(viewModel: TaskViewModel = viewModel()) {
    val tasks by viewModel.uiState.collectAsState()
    val snackbarHostState = remember { SnackbarHostState() }

    // 1. 副作用(Effect)のハンドリング
    LaunchedEffect(Unit) {
        viewModel.effects.collect { effect ->
            when (effect) {
                is TaskEffect.ShowSnackBar -> {
                    snackbarHostState.showSnackbar(effect.message)
                }
                TaskEffect.NavigateToDetail -> {
                    // Navigation 3 等での遷移処理
                }
            }
        }
    }

    Scaffold(
        snackbarHost = { SnackbarHost(snackbarHostState) }
    ) { padding ->
        TaskContent(
            tasks = tasks,
            onAction = { action -> 
                // 2. すべての操作を dispatch(Action) に集約
                viewModel.dispatch(action) 
            }
        )
    }
}

@Composable
fun TaskContent(tasks: List<Task>, onAction: (TaskAction) -> Unit) {
    Button(onClick = { onAction(TaskAction.AddTask("New Task")) }) {
        Text("Actionを送る")
    }
}

特徴:
ユーザーの操作をAction/Intentとして定義し、副作用をEffectとして分離した、最もモダンな形です。

進化のポイント:

• Action/Intent: Viewからの入力が型定義されたイベントとしてViewModelに届く（単方向データフローの強化）。
• Effect: 画面遷移やトースト表示など、一回限りのイベントをStateとは別に管理する。

メリット:
状態遷移が予測可能になり、デバッグが容易になります。Composeとの相性も抜群です。

🤔 まとめ：どれを選ぶべきか？

最初からパターン3を詰め込みすぎると複雑になりますが、長期的な保守を考えるなら、たとえ小規模でも「ViewからのAction」と「UIへのState」を明確に分ける意識が大切です。

まずは「何がViewに属し、何がロジックに属するか」をシンプルに保つことが、良いアーキテクチャへの近道です。

Beyond Hype: The Evolving Android Architecture from Fat View Model to MVI | by chanzmao | Mar, 2026 | ProAndroidDev

Tired of ViewModels that are over 1,000 lines long? This article details how to

medium.com