# SwiftUI @Observable vs @State: 2026年にどちらをいつ使うか > SwiftUIにおける@Observableと@Stateの違いを理解し、iOSアプリに最適な状態管理ツールを選択しましょう。 - Published: 2026-02-25 - Updated: 2026-04-29 - Author: SharpSkill - Tags: swiftui, ios, observable, state-management, swift - Reading time: 14 min --- 状態管理は、パフォーマンスの高いSwiftUIアプリの基盤を成しています。iOS 17以降、`@Observable`マクロはリアクティブモデルの作成方法を一変させ、`@State`はビューのローカル状態に欠かせない存在であり続けています。それぞれのツールをいつ使うかを理解することで、不要な再レンダリングを避け、滑らかで応答性の高いアプリを構築できます。 > **この記事で扱う内容** > > 本記事では、`@Observable`と`@State`の内部メカニズム、根本的な違い、そして文脈に応じて適切なツールを選ぶための明確な指針を解説します。 ## @Stateの基本 `@State`は、SwiftUIにおける最もシンプルな状態管理の形式です。このプロパティラッパーは、それを宣言したビューだけが所有する値に対して、永続的なストレージを生成します。 ```swift // CounterView.swift struct CounterView: View { // @State creates storage managed by SwiftUI @State private var count = 0 var body: some View { VStack(spacing: 20) { // The view updates when count changes Text("Counter: \(count)") .font(.largeTitle) HStack(spacing: 16) { Button("- 1") { count -= 1 } Button("+ 1") { count += 1 } } .buttonStyle(.borderedProminent) } } } ``` `count`への変更があるたびにビューの再レンダリングが発生します。SwiftUIはこの値のライフサイクルを自動的に管理し、bodyの再構築をまたいで保持します。 ### @Stateの主な特徴 `@State`には、最適な使い方を定義づけるいくつかの特徴があります。 ```swift // StateCharacteristics.swift struct FormView: View { // ✅ Simple local state - value types @State private var username = "" @State private var isEnabled = true @State private var selectedIndex = 0 // ✅ Complex value types supported @State private var configuration = FormConfiguration() var body: some View { Form { TextField("Username", text: $username) Toggle("Enabled", isOn: $isEnabled) Picker("Option", selection: $selectedIndex) { Text("Option A").tag(0) Text("Option B").tag(1) Text("Option C").tag(2) } } } } // Structs work perfectly with @State struct FormConfiguration: Equatable { var theme: Theme = .light var fontSize: CGFloat = 16 var showNotifications: Bool = true } enum Theme { case light, dark, system } ``` 重要なポイントは、`@State`は値型(struct、enum、プリミティブ型)で動作することです。参照型(クラス)には別のツールが必要です。 ## @Observableマクロの解説 iOS 17で導入された`@Observable`は、任意のクラスをリアクティブなデータソースに変換します。従来の`ObservableObject`プロトコルと異なり、このマクロはきめ細かい観測を提供します。ビューが実際に読み取ったプロパティだけが再レンダリングを引き起こすのです。 ```swift // UserModel.swift import Observation // @Observable transforms the class into a reactive source @Observable class UserModel { var name: String = "" var email: String = "" var avatarURL: URL? var preferences = UserPreferences() // Computed properties work too var isValid: Bool { !name.isEmpty && email.contains("@") } } struct UserPreferences { var newsletter: Bool = false var notifications: Bool = true var theme: Theme = .system } ``` 魔法はコンパイル時に起こります。マクロが各プロパティに必要なトラッキングコードを自動生成するのです。 ### きめ細かな観測の実例 旧来の`ObservableObject`との大きな違いは、トラッキングの粒度にあります。 ```swift // GranularObservation.swift @Observable class ProfileModel { var name: String = "" var bio: String = "" var followerCount: Int = 0 var posts: [Post] = [] } struct ProfileHeaderView: View { let model: ProfileModel var body: some View { VStack { // This view only re-renders if name or bio change Text(model.name) .font(.title) Text(model.bio) .foregroundStyle(.secondary) } } } struct FollowerCountView: View { let model: ProfileModel var body: some View { // This view only re-renders if followerCount changes HStack { Image(systemName: "person.2") Text("\(model.followerCount) followers") } } } struct ProfileScreen: View { @State private var model = ProfileModel() var body: some View { VStack { // Each subview tracks only its dependencies ProfileHeaderView(model: model) FollowerCountView(model: model) Button("Simulate new follower") { // Only re-renders FollowerCountView model.followerCount += 1 } } } } ``` > **自動トラッキング** > > SwiftUIは各ビューの`body`を解析して、どのプロパティが読み取られているかを判断します。読み取られたプロパティだけが、変更時に再レンダリングを発生させます。 ## 直接比較: @Observable vs @State これらのツールの選択はいくつかの要因に依存します。以下は構造化された比較です。 ```swift // ComparisonExample.swift // Scenario 1: Temporary UI state → @State struct ToggleExample: View { @State private var isExpanded = false // ✅ @State appropriate var body: some View { VStack { Button(isExpanded ? "Collapse" : "Expand") { withAnimation { isExpanded.toggle() } } if isExpanded { Text("Detailed content...") } } } } // Scenario 2: Shared business data → @Observable @Observable class CartModel { // ✅ @Observable appropriate var items: [CartItem] = [] var promoCode: String? var total: Decimal { items.reduce(0) { $0 + $1.price * Decimal($1.quantity) } } var itemCount: Int { items.reduce(0) { $0 + $1.quantity } } func addItem(_ item: CartItem) { if let index = items.firstIndex(where: { $0.id == item.id }) { items[index].quantity += 1 } else { items.append(item) } } func removeItem(_ item: CartItem) { items.removeAll { $0.id == item.id } } } struct CartItem: Identifiable, Equatable { let id: UUID let name: String let price: Decimal var quantity: Int } ``` ### ユースケース一覧表 | 基準 | @State | @Observable | |------|--------|-------------| | データ型 | 値型(struct、enum) | クラス | | スコープ | ビュー内ローカル | ビュー間で共有可能 | | 複雑さ | シンプルな状態 | 複雑なビジネスロジック | | ライフサイクル | SwiftUIが管理 | 明示的に管理 | | 再レンダリング | ビュー全体 | プロパティ単位できめ細かい | ## 高度な利用パターン ### @Stateと@Observableの組み合わせ 実際のアプリでは、これらのツールは調和して共存します。`@State`がローカルなUI状態を扱い、`@Observable`がビジネスデータをカプセル化します。 ```swift // CombinedPatterns.swift @Observable class TodoListModel { var todos: [Todo] = [] var filter: TodoFilter = .all var filteredTodos: [Todo] { switch filter { case .all: return todos case .active: return todos.filter { !$0.isCompleted } case .completed: return todos.filter { $0.isCompleted } } } func addTodo(title: String) { let todo = Todo(id: UUID(), title: title, isCompleted: false) todos.append(todo) } func toggleTodo(_ todo: Todo) { guard let index = todos.firstIndex(where: { $0.id == todo.id }) else { return } todos[index].isCompleted.toggle() } } struct Todo: Identifiable, Equatable { let id: UUID var title: String var isCompleted: Bool } enum TodoFilter: CaseIterable { case all, active, completed } struct TodoListView: View { // Business data via @Observable @State private var model = TodoListModel() // Local UI state via @State @State private var newTodoTitle = "" @State private var isAddingTodo = false @State private var selectedTodo: Todo? var body: some View { NavigationStack { VStack { // Filter with Picker Picker("Filter", selection: $model.filter) { ForEach(TodoFilter.allCases, id: \.self) { filter in Text(filter.label).tag(filter) } } .pickerStyle(.segmented) .padding() // Todo list List(model.filteredTodos, selection: $selectedTodo) { todo in TodoRowView(todo: todo) { model.toggleTodo(todo) } } } .navigationTitle("Tasks") .toolbar { Button { isAddingTodo = true } label: { Image(systemName: "plus") } } .sheet(isPresented: $isAddingTodo) { AddTodoSheet(model: model) } } } } struct TodoRowView: View { let todo: Todo let onToggle: () -> Void var body: some View { HStack { Image(systemName: todo.isCompleted ? "checkmark.circle.fill" : "circle") .foregroundStyle(todo.isCompleted ? .green : .secondary) .onTapGesture(perform: onToggle) Text(todo.title) .strikethrough(todo.isCompleted) } } } extension TodoFilter { var label: String { switch self { case .all: return "All" case .active: return "Active" case .completed: return "Completed" } } } ``` ### 依存性注入を伴う@Observable より複雑なアプリでは、SwiftUIの環境を介した注入により、効果的な疎結合を実現できます。 ```swift // DependencyInjection.swift @Observable class AuthenticationService { var currentUser: User? var isAuthenticated: Bool { currentUser != nil } func login(email: String, password: String) async throws { // Authentication logic currentUser = User(id: UUID(), email: email, name: "User") } func logout() { currentUser = nil } } struct User: Identifiable, Equatable { let id: UUID let email: String let name: String } // Extension to create an environment key extension EnvironmentValues { @Entry var authService: AuthenticationService = AuthenticationService() } // Configuration in the App @main struct MyApp: App { @State private var authService = AuthenticationService() var body: some Scene { WindowGroup { ContentView() .environment(\.authService, authService) } } } // Usage in views struct ProfileView: View { @Environment(\.authService) private var authService var body: some View { if let user = authService.currentUser { VStack { Text("Hello, \(user.name)") Button("Sign Out") { authService.logout() } } } else { Text("Not signed in") } } } ``` ## パフォーマンスと最適化 ### 不要な再レンダリングの回避 `@Observable`の粒度をもってしても、特定のパターンはパフォーマンスを低下させ得ます。 ```swift // PerformanceOptimization.swift // ❌ Bad pattern: reading the entire object struct BadPatternView: View { let model: ProfileModel var body: some View { // Reads model.name AND model.posts even if only name is displayed let _ = model.posts.count // Creates unnecessary dependency Text(model.name) } } // ✅ Good pattern: targeted reading struct GoodPatternView: View { let model: ProfileModel var body: some View { // Tracks only name Text(model.name) } } // ✅ Extract into subviews to isolate dependencies struct OptimizedProfileView: View { let model: ProfileModel var body: some View { VStack { // Each subview has its own dependencies ProfileNameView(model: model) ProfilePostsView(model: model) ProfileStatsView(model: model) } } } struct ProfileNameView: View { let model: ProfileModel var body: some View { Text(model.name) .font(.title) } } struct ProfilePostsView: View { let model: ProfileModel var body: some View { ForEach(model.posts) { post in PostRow(post: post) } } } struct ProfileStatsView: View { let model: ProfileModel var body: some View { HStack { StatBadge(value: model.followerCount, label: "Followers") StatBadge(value: model.posts.count, label: "Posts") } } } ``` > **高コストなcomputed property** > > `@Observable`上のcomputed propertyはアクセスのたびに再評価されます。複雑な計算では、結果をstored propertyにキャッシュすることを検討してください。 ### withObservationTrackingによるバッチ更新 高度なシナリオでは、`withObservationTracking`を使うとバインディングを作成せずに変更を検出できます。 ```swift // ObservationTracking.swift import Observation @Observable class DataSyncModel { var lastSyncDate: Date? var pendingChanges: Int = 0 var isSyncing: Bool = false } class SyncCoordinator { let model: DataSyncModel init(model: DataSyncModel) { self.model = model startObserving() } private func startObserving() { // Observe changes without UI withObservationTracking { // Access that creates dependencies _ = model.pendingChanges _ = model.isSyncing } onChange: { // Called when an observed property changes Task { @MainActor in self.handleModelChange() } } } private func handleModelChange() { if model.pendingChanges > 0 && !model.isSyncing { // Trigger synchronization Task { await syncChanges() } } // Re-establish observation startObserving() } private func syncChanges() async { model.isSyncing = true // Sync logic... model.isSyncing = false model.pendingChanges = 0 model.lastSyncDate = Date() } } ``` ## ObservableObjectからの移行 `ObservableObject`を使っている既存プロジェクトでは、`@Observable`への移行によりコードを簡素化できます。 ```swift // MigrationExample.swift // ❌ Old pattern with ObservableObject class OldSettingsModel: ObservableObject { @Published var darkMode: Bool = false @Published var fontSize: CGFloat = 16 @Published var notifications: Bool = true } struct OldSettingsView: View { @StateObject private var settings = OldSettingsModel() // or @ObservedObject if injected var body: some View { Form { Toggle("Dark Mode", isOn: $settings.darkMode) Slider(value: $settings.fontSize, in: 12...24) Toggle("Notifications", isOn: $settings.notifications) } } } // ✅ New pattern with @Observable @Observable class NewSettingsModel { var darkMode: Bool = false var fontSize: CGFloat = 16 var notifications: Bool = true } struct NewSettingsView: View { @State private var settings = NewSettingsModel() var body: some View { Form { Toggle("Dark Mode", isOn: $settings.darkMode) Slider(value: $settings.fontSize, in: 12...24) Toggle("Notifications", isOn: $settings.notifications) } } } ``` 移行のメリット: - 各プロパティに`@Published`を付ける必要がなくなります - 生成時に`@StateObject`の代わりに`@State`を使えます - きめ細かな観測が自動化されます - 可読性と保守性の高いコードになります ## 実践的な意思決定ルール 適切なツールを選ぶための意思決定ガイドです。 ```swift // DecisionGuide.swift /* RULE 1: Ephemeral UI state → @State - Animations, transitions - Local form states - Temporary selections - Section expand/collapse */ struct AnimatedCard: View { @State private var isFlipped = false // ✅ Local UI state // ... } /* RULE 2: Shared data across views → @Observable - Business data models - Authentication state - Shopping cart - User preferences */ @Observable class UserSession { // ✅ Shared across app var user: User? var preferences: Preferences // ... } /* RULE 3: Simple struct with binding → @State - Local configuration - Isolated forms */ struct FormData { var name: String = "" var email: String = "" } struct FormView: View { @State private var formData = FormData() // ✅ Struct with @State // ... } /* RULE 4: Complex business logic → @Observable - Validations - Network calls - Data transformations */ @Observable class OrderProcessor { // ✅ Complex logic var items: [OrderItem] = [] var status: OrderStatus = .draft func validate() -> [ValidationError] { /* ... */ } func submit() async throws { /* ... */ } } ``` ## まとめ `@Observable`と`@State`の選択は、二つの基本的な問いに集約されます。データ型(値型か参照型か)と、状態のスコープ(ローカルか共有か)です。`@State`はシンプルでローカルなUI状態に優れ、`@Observable`はきめ細かな観測を必要とする複雑なデータモデルで真価を発揮します。 ### 意思決定チェックリスト - ✅ 値型と一時的なUI状態には`@State`を使う - ✅ ビジネスデータを持つクラスには`@Observable`を使う - ✅ 状態が複数のビューにまたがるときは`@Observable`を優先する - ✅ サブビューに切り出して再レンダリングを最適化する - ✅ bodyで不要なプロパティを読み取らないようにする - ✅ `ObservableObject`から段階的に移行する - ✅ 依存性注入には環境を使う - ✅ 複雑なケースではInstrumentsでパフォーマンスを検証する --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/ja/blog/ios/swiftui-observable-vs-state