SwiftのActorを使って安全な並行処理を実装しよう

はじめに

こんにちは！この記事では、Swift 5.5で導入されたモダンな並行処理機能であるActorについて、解説していきます。

近年のモバイルアプリは、APIからのデータ取得、画像の非同期読み込み、複雑な計算など、複数の処理を同時に行うことが当たり前になっています。こうした「並行処理」は、アプリの応答性を高めるために不可欠ですが、同時に「データ競合」という厄介な問題を引き起こす原因にもなります。

SwiftのActorは、このデータ競合の問題を解決し、開発者がより安全かつシンプルに並行処理を記述できるようにするために導入されました。

対象読者

この記事は、以下のような方を対象としています。

• Swiftの基本的な文法は理解しているが、並行処理についてはまだ自信がない方
• async/awaitは知っているけれど、Actorについてはよく知らない方
• データ競合という言葉を聞いたことはあるが、具体的な対策方法が分からない方
• 特に、Flutter/DartのIsolateを使った経験があり、Swiftにおける並行処理のアプローチに興味がある方

この記事から得られること

この記事を最後まで読むことで、あなたは以下の知識を得ることができます。

• Actorが解決する「データ競合」の問題点
• Actorの基本的な使い方と、そのメリット
• UI更新を安全に行うための@MainActorの役割
• Actorを使いこなす上での注意点や、関連するSendableプロトコルの概念

それでは、SwiftのActorがもたらす安全でモダンな並行処理の世界へ一緒に進んでいきましょう！

2. Actorが登場した背景：並行処理とデータ競合

SwiftのActorを理解するためには、まず「なぜActorが必要になったのか？」という背景を知ることがとても重要です。その鍵となるのが、並行処理と、それに伴うデータ競合という問題です。

なぜ並行処理が必要なのか？

今日のモバイルアプリは、非常に多くのタスクを同時にこなしています。例えば、

• ユーザーが画面をスクロールしている間にも、ネットワークから新しい情報をダウンロードする。
• ボタンをタップしたときに、重い計算処理を行いつつも、UIはスムーズにアニメーションさせる。

もし、これらの処理を一つずつ順番に（直列に）行っていたらどうなるでしょうか？ おそらく、データのダウンロードが終わるまで画面が固まってしまったり、計算中はアプリが全く反応しなくなったりするでしょう。これではユーザー体験を大きく損ねてしまいます。

そこで並行処理の出番です。並行処理とは、複数の処理をあたかも同時に実行しているかのように見せることで、アプリの応答性を保ち、ユーザーに快適な操作を提供するための技術です。

並行処理の落とし穴：「データ競合」

しかし、この並行処理には大きな落とし穴があります。それが**データ競合（Data Race）**です。

データ競合とは、複数の処理（スレッド）が、同じデータ（メモリ上の値）に同時にアクセスしようとし、そのうち少なくとも1つが書き込みを行おうとするときに発生する問題です。

簡単な例で考えてみましょう。銀行口座の残高を管理するプログラムがあるとします。

// 銀行口座を表すクラス（データ競合が起こる例）
class BankAccount {
    var balance: Int = 10000 // 残高

    // 入金
    func deposit(amount: Int) {
        let newBalance = balance + amount
        // ...通信など少し時間がかかる処理があったとする...
        balance = newBalance
    }
}

このBankAccountクラスのインスタンスに対して、2つの異なる処理（AさんとBさんからの入金）がほぼ同時に行われたとします。

1. 処理A: 10,000円の残高に、5,000円を入金しようとします。
2. 処理B: 10,000円の残高に、3,000円を入金しようとします。

理想的な結果は、10000 + 5000 + 3000 = 18000円になることです。しかし、タイミングによっては以下のような最悪の事態が起こりえます。

1. 処理Aが現在の残高10000を読み込み、newBalanceとして15000を計算します。
2. 処理Aが計算結果をbalanceに書き込む前に、処理Bが割り込みます。
3. 処理Bも現在の残高10000を読み込み（まだ処理Aの結果は反映されていない！）、newBalanceとして13000を計算します。
4. 処理Bがbalanceを13000に更新します。
5. 処理Aが、先ほど計算しておいた15000をbalanceに書き込みます。

最終的な残高は15000円になってしまい、処理Bの3,000円の入金が完全に消えてしまいました。

これがデータ競合の恐ろしさです。この問題は、

• 再現性が低い: 発生するタイミングが予測できず、デバッグが非常に困難。
• 深刻なバグに繋がる: データが壊れたり、アプリがクラッシュしたり、セキュリティ上の脆弱性の原因になったりする。

といった特徴があり、長年多くの開発者を悩ませてきました。

SwiftのActorは、まさにこのデータ競合の問題を、言語レベルの機能として安全かつエレガントに解決するために登場したのです。

3. SwiftのActorとは：データ競合からの解放

並行処理における「データ競合」の恐ろしさについて解説しました。複数の処理が同じデータに同時にアクセスすることで、データが壊れてしまう危険性がある、という問題でした。

それでは、いよいよ本題であるSwiftのActorが、この問題をどのように解決するのかを詳しく見ていきましょう。

SwiftにおけるActorとはどういう機能か

一言でいうと、Actorとは**「内部の状態（データ）を外部のアクセスから保護する金庫」**のようなものです。

actorキーワードを使って型を定義すると、そのインスタンスはActorになります。Actorは、自身が持つプロパティへのアクセスを厳格に管理し、一度に一つの処理からしかデータへのアクセスを許可しません。

もし複数の処理が同時にActorのデータにアクセスしようとした場合、Actorはそれらを**順番待ちの行列（キュー）**に並ばせ、一つずつ順番に処理します。これにより、データ競合が原理的に発生しなくなるのです。

では、実際にコードを見てみましょう。前の章でデータ競合の問題があったBankAccountを、classからactorに変えてみます。

// BankAccountをActorとして定義
actor BankAccount {
    var balance: Int = 10000 // 保護された状態

    // 入金メソッド
    func deposit(amount: Int) {
        balance = balance + amount
    }

    // 残高を取得するメソッド
    func getBalance() -> Int {
        return balance
    }
}

たったこれだけです。classをactorに変えただけで、このBankAccountはデータ競合から保護されるようになりました。開発者が自分でロック処理などを書く必要は一切ありません。

awaitによる非同期アクセス

Actorがデータを保護しているということは、外部からそのデータにアクセスするには特別な方法が必要になる、ということです。それがawaitキーワードです。

Actorの外部から、そのプロパティやメソッドにアクセスしようとすると、コンパイラは「この処理は他の処理を待つ必要があるかもしれないから、非同期で呼び出してね」と要求します。これがawaitが必要な理由です。

func someBusinessLogic() async {
    let account = BankAccount()

    // Actorのメソッドを呼び出すには `await` が必要
    await account.deposit(amount: 5000)

    // プロパティへの直接アクセスも同様
    let currentBalance = await account.balance
    print("現在の残高は \(currentBalance) 円です")
}

awaitを付けることで、もし他の処理がaccountを利用中だった場合、その処理が終わるまでここで実行を一時停止し、順番を待ちます。順番が来たら処理を再開します。この仕組み全体をSwiftのシステムが管理してくれるため、私たちはただawaitと書くだけで、安全なアクセスが保証されるのです。

どういう場面で使うと効果的か？ Actorを使うとどういうメリットがあるのか

Actorの最大のメリットは、なんといってもデータ競合をコンパイラレベルで防ぎ、並行処理の安全性を劇的に高めてくれることです。これにより、以下のような恩恵が得られます。

• コードの簡潔化: 従来必要だった複雑なロック処理やディスパッチキューの管理が不要になり、ビジネスロジックに集中できます。
• バグの減少: 再現性が低くデバッグが困難なデータ競合に起因するバグを未然に防ぐことができます。

では、具体的にどのような場面でActorを使うと効果的なのでしょうか。それは**「複数の場所からアクセスされる可能性のある、変更可能なデータ（状態）」**を扱うあらゆる場面です。

• 共有リソースの管理

  • アプリ全体で共有される設定情報 (UserSettings)
  • ユーザーのログイン状態 (AuthenticationManager)
  • ダウンロードした画像のキャッシュ (ImageCache)

• カウンターや集計処理

  • Webサイトへのアクセス数を数えるカウンター
  • ゲームのスコア管理
  • 複数の非同期処理の進捗を管理するオブジェクト

• データベースへのアクセス

  • データベースへの書き込み処理を一つずつに制限し、データの不整合を防ぐラッパー

このように、これまで慎重なロック管理が必要だったあらゆる場面で、Actorはシンプルかつ安全な解決策を提供してくれます。

4. Actor登場以前の実装

今ではactorと書くだけで、安全なデータ管理が実現できるようになりました。しかし、SwiftにActorが登場する前は、開発者自身が手動でデータ競合を防ぐためのコードを書く必要があり、それは非常に注意深く、そして複雑なものでした。

Actorが導入される前はどういう実装をする必要があったのでしょうか？　代表的な3つの古典的な手法を紹介します。これらの手法を知ることで、Actorがいかに画期的で、私たち開発者を助けてくれる存在であるかをより深く理解できるでしょう。

ここでは、以前登場したBankAccountを、それぞれの方法で実装してみます。

1. DispatchQueue (シリアルキュー) を使った実装

Grand Central Dispatch (GCD) の機能の一つである**シリアルキュー（Serial Queue）**は、追加されたタスクを一つずつ順番に実行する性質を持っています。この性質を利用して、データへのアクセスを直列化し、データ競合を防ぐ方法が広く使われていました。

class BankAccount {
    // このキューに追加された処理は、必ず一つずつ実行される
    private let queue = DispatchQueue(label: "com.example.bankaccount.serial")
    private var _balance: Int = 10000

    var balance: Int {
        // 値の読み取りもキューを介して行う
        return queue.sync { _balance }
    }

    func deposit(amount: Int) {
        // 値の書き込みもキューを介して行う
        queue.sync {
            _balance = _balance + amount
        }
    }
}

• 仕組み: _balanceという実際の値をプライベートな変数として持ち、それへのすべてのアクセス（読み書き）をqueue.syncブロックの中で行います。syncは、キューに追加した処理が終わるまで現在のスレッドを待機させるため、安全に値の読み書きができます。
• 課題: シンプルに見えますが、すべてのアクセスポイントでキューを通すことを徹底しなければならず、コードが冗長になりがちです。また、syncは現在のスレッドをブロックするため、使い方を誤るとデッドロック（後述）の原因にもなり得ました。

2. NSLockを使った実装

NSLockは、より古くからある古典的なロックの仕組みです。金庫の鍵のように、一度に一つのスレッドしかクリティカルセクション（保護したいコード領域）に入れないようにします。

import Foundation

class BankAccount {
    private let lock = NSLock()
    private var _balance: Int = 10000

    var balance: Int {
        lock.lock() // 鍵をかける
        defer { lock.unlock() } // このスコープを抜けるときに必ず鍵を開ける
        return _balance
    }

    func deposit(amount: Int) {
        lock.lock() // 鍵をかける
        defer { lock.unlock() } // このスコープを抜けるときに必ず鍵を開ける
        _balance = _balance + amount
    }
}

• 仕組み: データにアクセスする前にlock.lock()を呼び出して鍵をかけます。もし他のスレッドが既に鍵をかけていた場合、その鍵が開けられる（unlock()される）まで待機します。deferブロックを使うことで、処理の途中でエラーが起きても確実にunlockが呼ばれるようにするのが定石です。
• 課題: lock()とunlock()の呼び出しを常にペアで正しく管理する必要があり、非常に神経を使います。もしunlockを忘れてしまうと、他のスレッドが永遠に待ち続けるデッドロックという状態に陥り、アプリがフリーズしてしまいます。

3. DispatchSemaphoreを使った実装

セマフォは、リソースにアクセスできるスレッドの数を制限するための仕組みです。この数を1に設定することで、ロックと同様の排他制御を実現できます。

import Foundation

class BankAccount {
    // 同時アクセス数を1に制限するセマフォ
    private let semaphore = DispatchSemaphore(value: 1)
    private var _balance: Int = 10000

    var balance: Int {
        semaphore.wait() // アクセス権を要求
        defer { semaphore.signal() } // アクセス権を解放
        return _balance
    }

    func deposit(amount: Int) {
        semaphore.wait() // アクセス権を要求
        defer { semaphore.signal() } // アクセス権を解放
        _balance = _balance + amount
    }
}

• 仕組み: semaphore.wait()でアクセス権を要求し、カウンタが0でなければ処理を進めます。カウンタが0の場合は、他のスレッドがsemaphore.signal()でアクセス権を解放するまで待機します。
• 課題: NSLockと同様に、wait()とsignal()の呼び出しを正しく管理する必要があり、デッドロックのリスクが伴います。

Actorのありがたみ

これらの従来の手法は、いずれも開発者が「どこを保護すべきか」を正確に把握し、「どのようにロックを管理するか」を注意深く実装する必要がありました。たった一つのunlock忘れが、アプリ全体を停止させる致命的なバグに繋がりかねなかったのです。（懐かしいですよね。）

Actorは、こうした手動でのロック管理の複雑さと危険性を、Swiftの言語機能として完全にカプセル化してくれました。私たちはもう、ロックのかけ忘れやデッドロックの恐怖に怯えることなく、actorと宣言するだけで、本質的なビジネスロジックの記述に集中できるのです。

5. UI更新の救世主、MainActor

これまで解説してきたActorは、私たちが自分で定義する「カスタムActor」でした。しかし、Swiftには特別な目的のためにあらかじめ用意されている「グローバルActor」というものが存在します。その中で最も重要で、最も頻繁に利用されるのが**MainActor**です。

ここでは、UIプログラミングにおけるMainActorの役割を詳しく見ていきましょう。

UI更新の大原則

iOSやmacOSなどのUIフレームワークには、絶対に守らなければならない大原則があります。それは、**「UIに関するすべての操作（作成、更新、アクセス）は、必ずメインスレッドで行わなければならない」**というルールです。

もし、バックグラウンドスレッドからUIコンポーネント（UILabelやUIImageなど）を直接操作しようとすると、画面の表示が崩れたり、アプリがクラッシュしたりと、予期せぬ動作を引き起こします。これは、UIフレームワークがスレッドセーフに設計されていないためです。

従来の方法とその課題

この原則を守るため、開発者はこれまで、バックグラウンドで重い処理（ネットワーク通信など）を行った後、UIを更新する際にはDispatchQueue.main.asyncを使って、処理を明示的にメインスレッドに戻す必要がありました。

// 従来の方法
func fetchImage() {
    // バックグラウンドスレッドで画像のダウンロードを開始
    DispatchQueue.global().async {
        let data = try! Data(contentsOf: imageUrl)
        let image = UIImage(data: data)

        // UI更新のためにメインスレッドに処理をディスパッチ
        DispatchQueue.main.async {
            self.imageView.image = image
        }
    }
}

このコードは正しく動作しますが、いくつかの課題がありました。

• コードのネストが深くなる: DispatchQueue.main.asyncのクロージャによって、コードのインデントが深くなり、可読性が低下します。
• 記述忘れのリスク: メインスレッドへのディスパッチを忘れても、コンパイラはエラーを出してくれません。これにより、実行時にしか発見できない厄介なバグが生まれがちでした。
• コードの分散: UI更新のロジックが、本来の処理の流れから少し離れた場所に記述されることになります。

@MainActorによる解決策

@MainActorは、こうした課題をエレガントに解決します。@MainActorは属性（アノテーション）の一種で、これを関数やクラスに付けるだけで、そのコードが必ずメインスレッドで実行されることをコンパイラが保証してくれるようになります。

先ほどの画像ダウンロードの例を、async/awaitと@MainActorを使って書き換えてみましょう。

// モダンな方法
func fetchImage() async {
    // バックグラウンドで画像のダウンロード（URLSessionはasync/awaitに対応）
    let (data, _) = try! await URLSession.shared.data(from: imageUrl)
    
    // UI更新処理を @MainActor が付いたメソッドに分離
    await updateImage(UIImage(data: data))
}

@MainActor
func updateImage(_ image: UIImage?) {
    // このメソッド内のコードは、常にメインスレッドで実行されることが保証される
    imageView.image = image
}

いかがでしょうか。DispatchQueue.main.asyncのネストがなくなり、コードの流れが非常に自然で読みやすくなりました。updateImageメソッドに@MainActorを付けるだけで、Swiftコンパイラが自動的にメインスレッドへの切り替えを行ってくれます。もしawaitを付け忘れたりすれば、コンパイラがエラーで教えてくれるため、記述忘れのリスクもありません。

@MainActorは、以下のように様々な場所に付けることができます。

• 関数・メソッド: その関数全体がメインスレッドで実行されます。
• プロパティ: そのプロパティへのアクセス（読み書き）がメインスレッドで行われます。
• クラス: そのクラスのすべてのメソッドとプロパティが、暗黙的に@MainActorで保護されます。UIViewControllerのサブクラスなど、UI関連のクラス全体に付けると便利です。

MainActorは、その名の通りActorの一種です。しかし、自分で状態を持つのではなく、処理を実行する場所をメインスレッドに限定するという役割に特化した、特別なグローバルActorなのです。

UIプログラミングを行う上で、@MainActorはデータ競合を避け、安全でクリーンなコードを書くための必須のツールと言えるでしょう。

6. Actorを使いこなすための注意点

ActorはSwiftにおける並行処理を劇的に安全にしてくれる強力な機能ですが、その特性を正しく理解して使わないと、思わぬ落とし穴にはまることがあります。ここでは、Actorを使いこなす上で特に重要なポイントを解説します。

1. Actor Reentrancy (再入可能性)

これはActorを扱う上で最も重要で、少しトリッキーな概念です。

Actorのメソッドの実行中にawaitで処理を中断すると、その間に他の処理が同じActorに割り込んでくる可能性がある、という性質を**再入可能性（Reentrancy）**と呼びます。

Actorはデータ競合を防ぐために、一度に一つの処理しか内部のコードを実行させません。しかし、awaitで実行を中断している間は、Actorは「手が空いている」と判断し、順番待ちしている他の処理を実行しようとします。これにより、awaitの前後でActorの状態が変わっている可能性があるのです。

簡単な例を見てみましょう。

actor ImageProcessor {
    private var processedImageCount = 0

    func processImages() async {
        print("画像の処理を開始します。現在の処理枚数: \(processedImageCount)")

        // ① ここで重い処理をシミュレート
        await Task.sleep(nanoseconds: 1_000_000_000) // 1秒待機

        // ② awaitから再開した時点
        // この間に他の処理が割り込んでいる可能性がある！
        guard processedImageCount == 0 else {
            print("既に他の処理が実行されたため、中断します。")
            return
        }

        processedImageCount += 1
        print("画像の処理が完了しました。現在の処理枚数: \(processedImageCount)")
    }
}

let processor = ImageProcessor()

// ほぼ同時に2つの処理を開始
Task { await processor.processImages() }
Task { await processor.processImages() }

このコードを実行すると、コンソールには以下のように出力される可能性があります。1秒後、**両タスクがほぼ同時期に「再開可能」**になりますが、
どちらが先にスレッドを得て再開し、さらに Actor の実行権（executor）を先に獲得するかはスケジューラ次第だからです。

画像の処理を開始します。現在の処理枚数: 0
画像の処理を開始します。現在の処理枚数: 0
画像の処理が完了しました。現在の処理枚数: 1
既に他の処理が実行されたため、中断します。

• 何が起きたか: 最初のタスクが①のawaitで中断している間に、2つ目のタスクが割り込み、先に処理を完了させてprocessedImageCountを1に更新しました。その後、最初のタスクが②で再開したときには、processedImageCountが0であるという期待が裏切られてしまったのです。

• 対策: awaitをまたいで状態が不変であると仮定してはいけません。awaitの直後には、必ず状態を再チェックする習慣をつけましょう。上の例のguard文のようなチェックが非常に重要になります。

2. @MainActorの適切な利用

@MainActorはUI更新を安全にするための強力なツールですが、使い方を誤るとパフォーマンスの低下を招きます。

• UIに関係ない重い処理を@MainActorで実行しない: @MainActorが付いたメソッド内で行われる処理は、すべてメインスレッドを占有します。ここに数秒かかるような重い計算などを書いてしまうと、その間UIが完全に固まってしまい、アプリの応答性が著しく低下します。
• 適切に分離する: 重い処理は@MainActorの付いていない場所（＝バックグラウンドスレッド）で行い、その結果をUIに反映する部分だけを@MainActorのメソッドとして切り出すのが基本です。

3. nonisolatedキーワード

Actorのプロパティやメソッドは、デフォルトでActorによって保護（隔離）されています。しかし、中には保護する必要がないものもあります。例えば、

• 変更されることのない定数（letで宣言されたプロパティ）
• Actorの内部状態に一切依存しない、純粋な計算を行うメソッド

こうしたメンバーにnonisolatedキーワードを付けると、Actorの保護から除外され、外部からawaitなしで同期的にアクセスできるようになります。

actor DataManager {
    let cacheKey: String = "unique-cache-key"
    private var cachedData: Data? = nil

    // Actorの状態に依存しないので、nonisolatedにできる
    nonisolated func log(message: String) {
        print("[Log]: \(message)")
    }

    func loadData() async -> Data {
        // ... データ読み込み処理 ...
        return cachedData!
    }
}

let manager = DataManager()
// nonisolatedなプロパティやメソッドにはawaitなしでアクセスできる
print(manager.cacheKey)
manager.log(message: "処理を開始します")

nonisolatedを適切に使うことで、不要なawaitの記述を減らし、コードの可読性とパフォーマンスを少しだけ向上させることができます。

4. Actorの粒度

アプリを設計する際に、「どのくらいの大きさでActorを作るか」という粒度の問題は非常に重要です。

• 粒度が大きすぎる場合: アプリのほぼすべての状態を一つの巨大なActorで管理しようとすると、そのActorへのアクセスが集中し、処理が順番待ちばかりになってしまいます。これがシステムのボトルネックとなり、パフォーマンスが低下する可能性があります。
• 粒度が細かすぎる場合: 状態を細かすぎるActorに分割しすぎると、今度はActor同士の連携が複雑になりすぎます。複数のActorがお互いの処理の完了を待ち合ってしまい、身動きが取れなくなるデッドロックという新たな問題を引き起こす可能性があります。

関連する状態と、それに関連するロジックを一つのまとまりとしてActorにするのが、適切な粒度設計の基本です。

これらの注意点を理解し、Actorの特性を最大限に活かすことで、より安全で堅牢、かつパフォーマンスの高い並行処理コードを記述できるようになります。

7. 安全なデータ受け渡しのためのSendable

これまでの説明で、Actorが自身の内部状態をデータ競合から守る強力な仕組みであることを学びました。しかし、アプリケーションは通常、複数のActorや、Actorと他のコード（例えばUIを更新する@MainActorなど）が連携して動作します。そうなると当然、Actorの境界を越えてデータをやり取りする必要が出てきます。

ここでは、Actor間でデータを安全に受け渡しするための重要な仕組みであるSendableプロトコルについて解説します。

なぜSendableが必要なのか？

考えてみてください。もし、Actor間で自由にデータを渡せてしまったら、何が起こるでしょうか？

例えば、あるクラスのインスタンス（参照型）を2つのActorで共有したとします。それぞれのActorは、自分自身の状態は保護していますが、共有されたクラスインスタンスについては保護できません。結果として、その共有インスタンスに対して複数のActorから同時に書き込みアクセスが発生し、せっかくActorを使って防いだはずのデータ競合が再び発生してしまう可能性があります。

これではActorの意味がありません。そこでSwiftは、Actorの境界を越えて安全に受け渡しできる型を明確に区別するための仕組みを導入しました。それがSendableプロトコルです。

Sendableプロトコルとは

Sendableは、特定の型が**「並行処理の文脈で安全に値をコピーして渡せること」**をコンパイラに示すための目印となるプロトコルです。Sendableに準拠した型の値は、複数のスレッドで同時に扱ってもデータ競合を引き起こさないことが保証されます。

Actorのメソッドに引数として渡したり、メソッドから戻り値として返したりできるのは、原則としてSendableに準拠した型のみです。もしSendableでない型の値を渡そうとすると、コンパイラが警告やエラーを出して、危険なコードを未然に防いでくれます。

どのような型がSendableなのか？

Sendableプロトコル自体は、実装すべきメソッドやプロパティを何も持ちません。その型がスレッドセーフであるという「意味的な要件」を満たしているかどうかが重要です。

1. 暗黙的にSendableに準拠する型

以下の型は、その性質上、本質的にスレッドセーフであるため、特別な記述なしでSendableとして扱われます。

• 値型（struct, enum）: コピーして渡される（値渡し）ため、元の値が変更される心配がありません。ただし、その構造体や列挙体のすべてのプロパティがSendableである必要があります。Int, String, Array<String>などの基本的な値型はすべてSendableです。
• Actor型: Actor自身が状態を保護する仕組みを持っているため、Sendableです。

2. 明示的にSendableに準拠させる必要がある型

• クラス（class）: クラスは参照型であり、複数の場所から同じインスタンスを指し示すことができるため、デフォルトではSendableではありません。クラスをSendableに準拠させるには、データ競合が起きないことを開発者自身が保証し、以下の厳しい条件を満たす必要があります。
  • finalキーワードが付いていて、これ以上継承されないこと。
  • 格納されているプロパティがすべて不変（let）であり、かつその型もSendableであること。
  • もしくは、すべてのプロパティへのアクセスが内部的にロックなどで保護されていることを保証し、@unchecked Sendableとしてマークすること（上級者向け）。

// 格納プロパティがすべてletでSendableなので、Sendableに準拠できる
final class UserProfile: Sendable {
    let id: UUID
    let name: String

    init(id: UUID, name: String) {
        self.id = id
        self.name = name
    }
}

@Sendableクロージャ

Taskの初期化処理やActorのメソッドに、引数としてクロージャを渡す場面もあります。こうしたクロージャもActorの境界を越えるため、@Sendable属性でマークして、そのクロージャがスレッドセーフであることを示す必要があります。

@Sendableが付いたクロージャには、以下のような制約が課せられます。

• クロージャの外にある変更可能な変数（var）をキャプチャ（取り込み）できない。
• キャプチャする値はSendableな型でなければならない。

func processInBackground(completion: @Sendable @escaping () -> Void) {
    Task.detached {
        // ... 何か重い処理 ...
        completion()
    }
}

Sendableは、一見すると複雑な制約のように思えるかもしれません。しかし、この仕組みがあるおかげで、私たちはコンパイラの助けを借りながら、データ競合の心配をすることなく、自信を持ってActor間の連携を記述することができるのです。

8. Flutter/Dartの似たような機能

この記事の読者の中には、Flutter/Dartでの開発経験をお持ちの方もいらっしゃるかと思います。そうした方々にとって、SwiftのActorは「DartのIsolateに似ているようで、少し違うな？」と感じられるかもしれません。

ここでは、SwiftのActorとDartのIsolateを比較し、両者の思想の違いと共通点を探っていきましょう。

Dartにおける並行処理の主役：Isolate

Dartは、シングルスレッドでイベントループを回す言語モデルを採用しています。しかし、重い計算などでUIスレッドをブロックしないように、Isolate という仕組みを使って並行処理を実現します。

Isolateの最大の特徴は、**「共有メモリを持たない、完全に独立した実行環境である」**という点です。それぞれのIsolateは、自分自身のメモリ空間とイベントループを持っており、他のIsolateのメモリに直接アクセスすることは絶対にできません。

では、Isolate間でどのように通信するのでしょうか？ それはメッセージパッシングによって行われます。SendPortとReceivePortという仕組みを使い、Isolate間でデータのコピーを送り合うことで通信します。これは、メモリを直接共有することによるデータ競合を原理的に不可能にするための、非常にクリーンで安全なアプローチです。

ActorとIsolateの思想的な比較

こうして見ると、SwiftのActorとDartのIsolateは、目指しているゴールが非常によく似ていることが分かります。

• 共通のゴール: データ競合を防ぎ、安全に並行処理を行うこと。
• 共通のアプローチ: 状態（データ）を隔離し、外部からの直接的なアクセスを制限すること。

しかし、その実現方法には思想的な違いがあります。

• DartのIsolate: **「メモリを共有しない」**という厳格な原則を貫くことで、安全性を保証します。データは常にコピーされて渡されます。
• SwiftのActor: **「一度に一つのスレッドからしかアクセスさせない」**という排他制御によって安全性を保証します。Actorは、その内部に状態（データ）を保持しており、複数のスレッドがその「共有された状態」に安全にアクセスするための仕組みです。

言うなれば、Isolateが「それぞれが独立した家（メモリ空間）に住み、手紙（メッセージ）でやり取りする」モデルだとすれば、Actorは「一つの家にある金庫（保護された状態）を、ルール（排他制御）に従って皆で共有して使う」モデル、と表現できるかもしれません。

手軽な並列処理：compute関数

Flutterエンジニアであれば、Isolateを直接使うよりもcompute関数にお世話になることの方が多いかもしれません。

// Dart/Flutter
Future<int> heavyTask(int value) async {
  // 何か重い計算
  return result;
}

// computeを使ってバックグラウンドで実行
final result = await compute(heavyTask, 100);

computeは、引数で渡された関数をバックグラウンドのIsolateで実行し、結果をFutureで返してくれる高レベルなAPIです。Isolateのセットアップやポートの管理といったお決まりのコードを隠蔽してくれるため、単発の重い処理をバックグラウンドに逃がしたい場合に非常に便利です。

Swiftにも、Task.detachedなど似たような目的で使えるAPIはありますが、computeほど手軽に「関数を一つ渡すだけ」というわけにはいきません。このあたりの手軽さは、Flutter/Dartの魅力的な部分と言えるでしょう。

まとめ

SwiftのActorとDartのIsolateは、異なるアプローチを取りながらも、「安全な並行処理」という同じ頂を目指す仲間のような存在です。どちらの仕組みも、それぞれの言語の設計思想に基づいており、非常にうまく機能します。

Flutter/Dartの経験がある方にとっては、Isolateの「メモリ非共有」の考え方をベースに、Actorの「共有状態へのアクセス制御」という考え方を理解すると、よりスムーズにSwiftの並行処理モデルを習得できるはずです。

9. まとめ

この記事では、Swift 5.5から導入されたモダンな並行処理機能であるActorについて、その背景から基本的な使い方、注意点、そして関連技術に至るまでを詳しく解説してきました。

最後に、これまでの内容を振り返り、Actorが私たち開発者にもたらす価値を再確認しましょう。

Actorが解決したこと

私たちはまず、並行処理における古くからの課題、データ競合について学びました。複数のスレッドが同じデータに同時にアクセスし、書き込みを行うことで、データが破壊されたり、アプリが予期せぬ動作をしたりする、非常に厄介な問題でした。

SwiftのActorは、この問題を言語レベルで解決するために登場しました。

• Actorは、内部の状態（データ）を保護する金庫のように振る舞い、一度に一つの処理からしかアクセスを許可しません。これにより、データ競合を原理的に防ぎます。
• 開発者は、DispatchQueueやNSLockといった複雑で間違いやすい手動のロック管理から解放され、actorと宣言するだけで、安全に状態を共有できるようになりました。

安全なエコシステム

Actorは単独で機能しているわけではありません。Swiftのモダンな並行処理は、関連する機能と連携することで、より堅牢なエコシステムを形成しています。

• @MainActor: UI更新を必ずメインスレッドで行うことを保証し、UIに関するデータ競合やクラッシュを防ぎます。DispatchQueue.main.asyncのネストから私たちを解放し、コードをクリーンにしてくれます。
• Sendable: Actorの境界を越えてデータを安全にやり取りするためのルールを定めます。コンパイラがSendableでない型の受け渡しをチェックしてくれるため、意図せず危険なデータを共有してしまうことを未然に防げます。

これらの仕組みが組み合わさることで、Swiftの並行処理は、かつてないほど安全で、かつ直感的に記述できるものになりました。

これからのSwiftプログラミングとActor

async/awaitの登場により、Swiftの非同期コードの見た目は大きく変わりました。そしてActorは、その見た目の下で、非同期コードの「安全性」を根底から支える、なくてはならない存在です。

これからのSwiftプログラミング、特に非同期処理や並行処理が関わるコードを記述する上で、Actorの知識は必須と言えるでしょう。最初は「再入可能性」などの新しい概念に戸惑うかもしれませんが、その挙動を正しく理解すれば、これほど頼りになる機能はありません。

この記事が、SwiftのActorを使ってより安全で質の高いアプリを構築するための一助となれば幸いです。

最後までお読みいただき、ありがとうございました！