ARC（自動参照カウント）とは？iOSにおけるメモリ管理の仕組みと実務での注意点を徹底解説

iOSアプリ開発では、画面遷移、非同期処理、ネットワーク通信、一覧表示、状態管理など、実装の見た目として目立ちやすい要素に注目が集まりやすい一方で、メモリ管理は「動いている間は見えにくい」ため、理解が後回しにされやすい領域です。しかし実際には、アプリが安定して動き続けるかどうか、画面を何度も行き来しても重くならないか、長時間使っても不要なオブジェクトが残り続けないかといった品質は、メモリ管理の理解に強く依存しています。つまり、ARCは低レイヤーの知識というより、日常的なiOS開発の品質を支える基礎そのものです。

特にSwiftでは、ARCによって多くのメモリ管理が自動化されているため、手動で retain や release を書く必要は基本的にありません。そのため、一見すると「メモリ管理はもう意識しなくてよい」と感じやすいのですが、ここに大きな落とし穴があります。ARCが自動化しているのは参照カウントの増減であって、所有関係の設計そのものではありません。つまり、ARCは自動で動くが、何を強く保持し、何を弱く参照すべきかは開発者が設計しなければならないということです。

実務で問題になるのも、ARCの動作不良というより、所有関係の設計ミスです。画面とViewModel、親子オブジェクト、delegate、クロージャ、Coordinator、タイマー、通知監視など、オブジェクト同士が互いにどう関係するかを曖昧なまま書くと、循環参照や過剰保持が発生しやすくなります。つまり、ARCを理解するとは、単に「自動参照カウントの仕組み」を覚えることではなく、iOSアプリにおけるオブジェクトの生存期間と所有関係をどう設計するかを理解することでもあります。

本記事では、ARCの基本から出発し、強参照、弱参照、非所有参照、循環参照、クロージャキャプチャ、SwiftとObjective-Cでの違い、実務で起きやすいミス、設計上の注意点までを順を追って整理します。特に重要なのは、ARC = 参照カウントによる自動メモリ管理であり、問題の本質 = 所有関係の設計ミスにあるという視点です。この軸を持つだけで、iOSのメモリ管理はかなり整理して理解しやすくなります。

1. ARC（自動参照カウント）とは

ARC（自動参照カウント）とは、オブジェクトが現在どれだけ参照されているかを数え、その参照数に応じてメモリ解放のタイミングを自動的に管理する仕組みです。SwiftやObjective-Cでは、オブジェクトが生成されるたびに、そのオブジェクトを指している参照の数が管理され、誰からも参照されなくなった時点で不要と判断されます。つまり、ARCはメモリを「時間」や「スコープ」だけで管理するのではなく、参照の有無を基準に管理している仕組みです。

この仕組みが重要なのは、iOSアプリでは多くのオブジェクトが複雑な関係を持ちながら生存するからです。ViewController、View、ViewModel、Service、Model、クロージャ、タイマーなどは、すべて互いに参照し合う可能性があります。こうした環境で手動のメモリ管理を徹底するのは非常に難しく、解放漏れや二重解放のリスクも高まります。ARCはそうした複雑さを軽減するために導入されており、開発者がすべての解放を手作業で扱わなくてもよいようにしています。

ただし、ここで誤解してはいけないのは、ARCは万能の自動掃除機ではないということです。ARCは参照カウントに基づいて解放するだけなので、互いに強く参照し合っているオブジェクトは、たとえ実質的には不要でも参照数がゼロにならず、解放されません。つまり、ARCはメモリ管理を自動化している一方で、どの参照が強くあるべきか、どの参照を弱くすべきかという設計判断は自動化していないのです。この点を理解しないまま使うと、「ARCがあるのになぜリークするのか」という誤解につながります。

1.1 メモリ管理の基本的な役割

メモリ管理の基本的な役割は、不要になったオブジェクトを適切なタイミングで解放し、必要なものだけを保持することです。アプリは動作中に多くのオブジェクトを生成しますが、それらをすべて保持し続けると、メモリ使用量が増え続け、最終的には重さや不安定さ、クラッシュの原因になります。逆に、まだ必要なものを早く解放してしまうと、参照切れや異常動作が起こります。つまり、メモリ管理とは「解放すること」ではなく、必要な間だけ保持し、不要になった瞬間に解放できることを目指す仕組みです。

iOSアプリ開発でメモリ管理が特に重要なのは、ユーザー操作によって画面遷移や状態変化が頻繁に起こるからです。ある画面では必要だったオブジェクトが、別の画面へ移ると不要になることはよくあります。そのとき、所有関係が適切なら自然に解放されますが、不要な参照が残っていると解放が起きず、見えないところでメモリが蓄積していきます。つまり、メモリ管理の役割は単なる節約ではなく、アプリのライフサイクルに合わせてオブジェクトの生存期間を整えることにあります。

1.2 参照カウントの仕組み

参照カウントの仕組みでは、あるオブジェクトに対して何本の強い参照が向いているかを数えます。オブジェクトが生成された直後に参照が一つ存在し、その後別の変数やプロパティへ代入されるたびに参照数が増えます。逆に、変数が nil になったり、所有していたオブジェクトが解放されたりすると、参照数は減少します。そして最終的に参照カウントがゼロになったとき、そのオブジェクトは不要とみなされ、解放されます。つまり、ARCの本質は「自動で解放すること」ではなく、参照数の増減を追跡して解放条件を判断することです。

この仕組みの利点は、オブジェクトの実際の利用状況にかなり近い形でライフサイクルを管理できることにあります。スコープを抜けたからといって即解放されるのではなく、別の場所からまだ参照されていれば残ります。一方で、誰からも必要とされなくなれば自然に解放されます。つまり、ARCはコードの構造ではなく、オブジェクト同士の実際の参照関係を基準にしているため、UIや非同期処理の多いiOSアプリと相性がよい仕組みです。

ただし、ここでも重要なのは「強い参照だけが参照カウントへ影響する」という点です。弱参照や非所有参照は、オブジェクトを参照していてもカウントを増やしません。つまり、参照カウントの仕組みを理解するには、単に「参照があるか」ではなく、「その参照はカウントに影響する強参照かどうか」を見分ける必要があります。ここがARC理解の核心の一つです。

1.3 なぜARCが必要なのか

ARCが必要なのは、オブジェクト指向アプリケーションではオブジェクトの生存期間が非常に複雑になりやすいからです。もしメモリ管理を完全に手動で行うなら、いつ retain し、いつ release するかをすべて開発者が判断しなければなりません。しかし、実際のiOSアプリでは、画面遷移、非同期クロージャ、delegate、キャッシュ、Serviceレイヤー、ViewModel、通知監視など、参照関係が複雑に入り組みます。その中で手動管理を正確にやり続けるのは現実的ではなく、解放漏れや過剰解放のリスクも高くなります。

ARCは、この負担をコンパイラとランタイムが肩代わりすることで、日常的なメモリ管理をかなり安全かつ扱いやすくしています。つまり、ARCの価値は「メモリ管理を意識しなくてよくすること」ではなく、「毎回の解放処理を手動で書かなくても、参照関係に基づいて自然に管理できるようにすること」にあります。ただし、ここで重要なのは、自動化されているのは参照カウントの増減であって、所有関係そのものの設計は開発者の責任であるという点です。この役割分担を理解しているかどうかが、ARCを正しく使えるかの分かれ目になります。

2. 強参照とはどのようなものか

強参照とは、その参照先のオブジェクトを「生きたままにしておく」力を持つ参照です。Swiftで通常のプロパティや変数としてオブジェクトを保持すると、多くの場合それは強参照になります。つまり、あるオブジェクトを強参照している限り、そのオブジェクトの参照カウントは減らず、解放されません。この意味で強参照は、単なるアクセス手段ではなく、オブジェクトの生存を保証する所有関係の表現だと考える必要があります。

この点を軽く見ると、強参照を「とりあえず使う普通の参照」くらいに考えてしまいがちですが、実務ではそれが大きな問題になります。なぜなら、強参照は便利で自然な一方で、使い方を誤るとオブジェクト同士が互いを保持し合い、解放されない原因になるからです。つまり、強参照はARCの中心的な仕組みでありながら、同時に循環参照の起点にもなり得る存在です。そのため、強参照を理解することは、ARC全体を理解するための入口でもあります。

2.1 強参照の基本

強参照の基本は、「このオブジェクトは自分が必要とするので保持する」という意味です。たとえば ViewController が ViewModel を持つ、Model を配列に保持する、Service をプロパティとして持つといった場面では、強参照が自然です。これらはそのオブジェクトが存在している間、相手にも生きていてほしい関係だからです。つまり、強参照は所有の表現であり、所有している側が相手のライフサイクルを支える構造になります。

ここで大事なのは、強参照を悪者扱いしないことです。ARCの問題が出ると、すぐ「強参照が悪い」と考えがちですが、実際には強参照は必要不可欠です。もしすべてを弱参照で持ってしまえば、本来必要なオブジェクトまで途中で消えてしまい、アプリはまともに動きません。つまり、強参照は避けるべきものではなく、どこで強く持つのが自然かを正しく設計するべきものです。

2.2 参照カウントへの影響

強参照は参照カウントへ直接影響します。あるオブジェクトが強参照されるたびに、その参照カウントは増えます。逆に、強参照が解かれれば参照カウントは減少します。つまり、強参照はオブジェクトの生存期間を決める主要な要素です。ARCはこの参照カウントを監視し、ゼロになった時点で解放を行うため、どこで強参照が追加され、どこで解かれるかを意識することが極めて重要です。

実務では、問題の本質は「強参照があること」ではなく、「意図しない強参照が残ること」にあります。たとえば本来一時的な関係でよいものを強く持ち続けると、オブジェクトの寿命が必要以上に延びてしまいます。つまり、参照カウントへの影響を理解するとは、単に増減のルールを知ることではなく、その参照がオブジェクトの寿命をどのように変えるのかを設計として捉えることでもあります。

3. 弱参照と非所有参照はどのように違うのか

ARCを実務で扱ううえで最も混乱しやすいのが、弱参照（weak）と非所有参照（unowned）の違いです。どちらも参照カウントを増やさないという共通点を持つため、「循環参照を避けるための参照」としてまとめて理解されがちですが、実際には使う前提がかなり異なります。つまり、両者の違いを単なる文法や属性の違いとして覚えるのではなく、ライフサイクルに対してどのような前提を置いている参照なのかとして理解する必要があります。

弱参照と非所有参照の違いを曖昧にすると、不要に weak を多用して値がすぐ消えて困ったり、逆に unowned を使って参照先の解放後にクラッシュを引き起こしたりします。つまり、この違いはスタイルの問題ではなく、安全性と設計意図に直結する問題です。ARCを理解していても、ここを曖昧にしたままでは実務でかなり不安定になります。

3.1 弱参照の特徴

弱参照は、参照先のオブジェクトを見たいが、その生存を保証したくないときに使う参照です。weak で宣言された参照は参照カウントを増やさず、参照先が解放されると自動的に nil になります。つまり、弱参照は「相手が生きていれば参照するが、いなくなったら消えてもよい」という関係を表します。この性質のため、delegate や親子関係の逆方向参照などでよく使われます。

重要なのは、弱参照には常に「参照先が先に消える可能性がある」という前提があることです。そのため、型は通常 Optional になります。つまり、弱参照は安全性が高い一方で、常に nil の可能性を考慮しなければなりません。これは不便に見えることもありますが、逆に言えば「参照先が消えるのが自然な関係」に対してはもっとも素直な表現です。

3.2 非所有参照の特徴

非所有参照は、参照カウントを増やさない点では弱参照と同じですが、「参照先は自分が生きている間は必ず存在している」という強い前提を置く点が異なります。unowned は参照先が解放されても自動で nil にならず、もし解放後にアクセスするとクラッシュします。つまり、非所有参照は「自分が所有していないが、寿命の順序として先に消えることはない」と言い切れる関係で使うべきものです。

このため、unowned は weak より記述は簡潔ですが、安全性の前提は厳しくなります。参照先の寿命をきちんと設計できている場合には有効ですが、少しでも「先に解放される可能性がある」なら危険です。つまり、非所有参照は便利な弱参照の代用品ではなく、ライフサイクルの前提が明確に決まっているときだけ使うべき参照です。

3.3 使い分けの基準

使い分けの基準は単純で、「参照先が先に消える可能性があるなら weak、絶対に先に消えないと設計上言い切れるなら unowned」です。ここで重要なのは、気分や好みで選ばないことです。weak は Optional 扱いが増えるため少し手間ですが、安全性は高いです。一方 unowned はコードがすっきり見えても、前提を外すと即クラッシュにつながります。つまり、選択基準は記述の簡潔さではなく、ライフサイクル設計の確実さです。

弱参照と非所有参照の比較

使用言語

Swift

ファイル名

WeakReferenceSample.swift

class A {
    weak var b: B?
}

この例では、A は B を参照していますが、その参照は B の生存を保持しません。つまり、B が不要になれば解放され、その後 a.b は自動的に nil になります。これは「見たいが所有したくない」関係の典型です。

実務では delegate や親参照の逆向きなどでこの考え方が非常に重要になります。つまり、weak を覚えること以上に、「この関係は本当に相手を生かし続けるべきか」を考えることが本質です。

4. 循環参照はどのように発生するのか

循環参照とは、複数のオブジェクトが互いを強く参照し合うことで、実質的には不要になっていても参照カウントがゼロにならず、解放されなくなる状態を指します。ARCは参照カウントに基づいて解放を行うため、オブジェクト同士が互いを生かし続けている限り、自動では回収されません。つまり、循環参照はARCの失敗ではなく、ARCの前提を破る所有関係の設計ミスです。

ここで重要なのは、循環参照は特殊なケースではなく、通常のアプリ設計の中で非常に起こりやすいという点です。親子オブジェクト、delegate、クロージャ、Coordinator、ViewController と ViewModel など、相互に関係を持つ設計では自然に発生し得ます。つまり、循環参照は単なるメモリ理論ではなく、実務で最も頻出するARC問題の中心です。

4.1 相互参照の構造

循環参照の構造は非常に単純です。AがBを強く持ち、BもAを強く持つと、外側から不要になったとしても、Aの参照カウントはBによって保たれ、Bの参照カウントはAによって保たれます。その結果、どちらも解放されません。つまり、循環参照の本質は「互いが互いの生存条件になってしまうこと」です。

この構造が厄介なのは、コード上では自然に見えることが多い点です。親が子を持つ、子が親を知る、画面がViewModelを持つ、ViewModelが画面を更新したい、といった設計はよくあります。しかし、それをすべて強参照で表現してしまうと、所有関係が閉じた輪になりやすくなります。つまり、循環参照は不自然なコードから生まれるのではなく、自然に書いたコードがそのまま危険になるという点で厄介です。

4.2 解放されない原因

解放されない原因は、ARCが不要性を「参照カウントがゼロかどうか」でしか判断できないことにあります。外部から見れば不要でも、相互参照が残っている限り、ARCにとってはまだ使われているオブジェクトに見えます。つまり、ARCは「意味的に不要か」を理解しているわけではなく、「まだ強く参照されているか」だけを見ています。このため、所有関係の設計が誤ると、自動管理であっても自然には解放されません。

4.3 発生しやすいケース

発生しやすいケースとしては、親子オブジェクトの双方強参照、delegate を強く持つ設計、ViewController と ViewModel の相互保持、クロージャ内での self 強参照、Coordinator と画面の双方向保持などがあります。つまり、循環参照は特定の技法でだけ起こるのではなく、所有関係を曖昧にしたあらゆる場所で起こり得ます。実務では「どこで起きやすいか」を知っておくことが、予防の第一歩になります。

循環参照が発生しやすいケース

使用言語

Swift

ファイル名

RetainCycleSample.swift

class A {
    var b: B?
}

class B {
    var a: A?
}

このコードでは、A は B を強参照し、B も A を強参照しています。そのため、外側からこの二つが不要になっても、お互いの参照によって参照カウントが残り、解放されません。これは循環参照のもっとも基本的な形です。

実務ではここまで単純ではないものの、本質は同じです。つまり、循環参照を防ぐには、「相互に知っている」ことと「相互に強く所有する」ことを同一視しないことが重要です。知っている必要はあっても、所有までは不要な関係は多く、そこを弱参照や非所有参照で表現することがARC設計の核心になります。

5. クロージャと参照はどのように関係するのか

クロージャはSwiftで非常によく使われる構文ですが、ARCの文脈では循環参照の温床になりやすい要素でもあります。なぜなら、クロージャは外側のスコープにある値をキャプチャできるため、そこで self を参照すると、クロージャが self を強く保持する構造が自然にできてしまうからです。特に、非同期処理、完了ハンドラ、タイマー、アニメーション、イベントコールバックなど、クロージャが長く生きる可能性がある場面では要注意です。つまり、クロージャは便利で強力な一方で、ARCの観点では「隠れた所有関係」を生みやすい存在です。

この問題が厄介なのは、クロージャのコードが短く自然に見えることです。self.doSomething() と書くだけで、実際には self の生存期間に影響を与えている場合があります。つまり、クロージャ内の参照はただのメソッド呼び出しではなく、所有関係の一部として理解しなければなりません。ここを軽く見ると、「なぜこのViewControllerが消えないのか分からない」という典型的な問題に直結します。

5.1 クロージャによるキャプチャ

クロージャによるキャプチャとは、クロージャが外側の変数やオブジェクトを内部で使えるように保持することです。Swiftでは明示しなくても多くの場合自動的にキャプチャされるため、書き心地はよいですが、ARCの観点では「何をどの強さで持っているか」を意識しなければなりません。特に self をそのまま使うと、クロージャが self を強くキャプチャするのが基本です。つまり、クロージャは記法として短くても、裏では参照関係を一つ増やしている可能性があります。

5.2 強参照によるリーク

クロージャが self を強くキャプチャし、そのクロージャ自体を self が強く保持していると、典型的な循環参照が成立します。たとえば ViewController が完了ハンドラをプロパティとして持ち、そのハンドラ内で self を参照している場合などです。このとき、ViewController はクロージャを持ち、クロージャは ViewController を持つため、どちらも解放されません。つまり、クロージャのリークは特別なケースではなく、「所有しているクロージャの中で所有者自身を強く使う」と発生しやすい非常に典型的な問題です。

5.3 キャプチャリストの使い方

キャプチャリストは、この問題を明示的に制御するための仕組みです。[weak self] と書けば self を弱参照でキャプチャでき、参照先が解放されたら nil になります。[unowned self] と書けば非所有参照として扱えますが、解放後アクセスでクラッシュする前提も伴います。つまり、キャプチャリストは単なる書き方のテクニックではなく、クロージャと外側オブジェクトの所有関係をどう設計するかを明示する手段です。

クロージャと参照のパターン

使用言語

Swift

ファイル名

ClosureCaptureSample.swift

{ [weak self] in
    self?.doSomething()
}

この例では、self を弱参照でキャプチャしているため、クロージャが self の生存を保持しません。もし self が先に解放されていれば、self? は nil となり、安全に何もしない形になります。これは、画面や一時的なオブジェクトを扱うクロージャで非常によく使われるパターンです。

ただし、[weak self] を機械的に入れればすべて解決するわけではありません。本当に弱参照でよいのか、クロージャ実行時に self が必要不可欠なのか、guard let self で一時的に強く持ち直すべきかなど、設計判断は残ります。つまり、クロージャのメモリ管理で重要なのは文法ではなく、クロージャと self の寿命関係をどう定義するかです。

6. ARCはどのように自動管理を行うのか

ARCは、オブジェクトごとの参照カウントを見ながら、自動的に保持と解放のタイミングを調整します。Swiftコードを書くとき、開発者が通常 retain や release を明示的に書くことはありませんが、実際にはコンパイラとランタイムが必要な場所へ保持・解放の処理を挿入しています。つまり、ARCは「魔法のように自動で全部やってくれる」というより、保持と解放のルールをコードの背後で自動挿入している仕組みだと捉えるほうが正確です。

この理解は重要です。なぜなら、ARCを完全にブラックボックスとして見ると、「なぜここで解放されないのか」「なぜこの代入で寿命が延びたのか」といったことが理解しにくくなるからです。ARCは自動ですが、原理は参照カウントの増減に非常に忠実です。つまり、自動管理という言葉に引っ張られすぎず、内部では retain/release 相当の概念が動いていると理解しておくことが、実務では大きく役立ちます。

6.1 retainとreleaseの仕組み

retain は参照カウントを増やす概念、release は参照カウントを減らす概念です。Swiftではこれを明示的に書くことはほぼありませんが、参照を新たに保持したときには実質的に retain 相当が起き、不要になったときには release 相当が起きます。つまり、ARCは参照の追加・削除に合わせて保持と解放を管理している仕組みです。

6.2 コンパイラによる挿入

ARCの大きな特徴は、この retain/release 相当の処理をコンパイラが適切な位置へ自動的に挿入することです。これにより、開発者は通常のオブジェクト指向コードを書くだけでよく、毎回メモリ管理コードを明示的に書く必要がありません。つまり、ARCの便利さは、メモリ管理そのものが消えたことではなく、手作業で書くべきだった保持・解放の制御がコンパイラに委譲されたことにあります。

6.3 手動管理との違い

手動管理との違いは、保持・解放の実装責任を開発者が直接持たないことです。Objective-CのMRC時代には、retain や release の呼び忘れ・呼び過ぎが深刻な問題になりましたが、ARCではその多くが自動化されています。しかし、所有関係の設計ミスは自動化されません。つまり、ARCは手動管理の負担を大きく減らした一方で、「何をどう保持すべきか」の設計責任までは奪っていません。この点が、ARC理解の中で最も大事な線引きです。

7. SwiftとObjective-Cでの違いは何か

SwiftとObjective-CはどちらもARCを使いますが、実務での扱いやすさや安全性には違いがあります。Objective-CではARCが導入される以前に手動メモリ管理の時代があり、その名残としてメモリ管理をより低レベルに意識しやすい文脈があります。一方Swiftは、最初からARC前提の言語設計であり、Optional や型安全、クロージャ構文などと組み合わさることで、所有関係や解放の扱い方がより構造的に見えやすくなっています。つまり、ARC自体は両方に存在していても、その使われ方や理解しやすさには差があります。

また、Swiftでは weak や unowned の扱いが文法レベルで明確であり、クロージャキャプチャも言語仕様の中で整理されています。そのため、所有関係の設計をコード上で比較的読み取りやすいです。Objective-Cでも同様の概念はありますが、記述の安全性や明快さではSwiftのほうが扱いやすい場面が多いです。つまり、SwiftとObjective-Cの違いはARCの有無ではなく、ARCを前提にした設計をどれだけ安全に書けるかにあります。

7.1 メモリ管理の記述方法

Swiftでは、強参照・弱参照・非所有参照、クロージャキャプチャなどが比較的明示的に書けます。Optional と組み合わせることで、「この参照は消え得る」という前提も型として表現しやすいです。一方、Objective-Cでは文法や歴史的背景から、Swiftほど一貫して読みやすいとは限りません。つまり、Swiftではメモリ管理の意図をコードへ反映しやすいという利点があります。

7.2 安全性の違い

安全性の面では、Swiftのほうが型システムやOptionalによって、解放後アクセスや不正な前提を意識しやすい傾向があります。ただし、unowned や強いクロージャキャプチャのように、Swiftでも設計ミスは十分起こります。つまり、SwiftはObjective-Cより安全に書きやすいですが、ARC問題そのものがなくなるわけではありません。重要なのは、言語が安全性を補助してくれても、所有関係の設計は依然として開発者の責任だという点です。

8. ARCでも発生する問題とは何か

ARCがあるからといって、メモリ問題が完全になくなるわけではありません。ARCは参照カウントの増減を自動化しているだけなので、所有関係の設計を誤れば、リークも過剰保持も誤解も起こります。つまり、ARCは「メモリ管理問題をなくす技術」ではなく、「手動解放の負担を減らす技術」です。この前提を忘れると、「ARCがあるのに問題が起きた」という不自然な見方をしてしまいます。

実務で多いのは、メモリリーク、過剰な保持、解放タイミングの誤解です。これらはコードが動いている間は見えにくいため、問題が蓄積しやすいです。つまり、ARCでも発生する問題を理解することは、ARCを過信しすぎないために必要です。

8.1 メモリリーク

メモリリークは、オブジェクトが不要になった後も解放されない状態です。循環参照やクロージャキャプチャが典型的な原因になります。つまり、リークはARCの不具合ではなく、ARCが解放条件を満たせない構造が残っていることから起こります。

8.2 過剰な保持

過剰な保持は、リークほど明確ではないものの、本来もっと早く手放してよいオブジェクトを長く持ち続ける状態です。キャッシュしすぎ、大きな配列を必要以上に保持する、画面終了後も関連オブジェクトを生かす、といったケースが該当します。つまり、ARCは解放条件を満たすまで残すだけなので、「残しすぎ」自体は普通に起こり得ます。

8.3 解放タイミングの誤解

ARCでは、スコープを抜けたから必ず解放されるわけではありません。別の場所で強参照されていれば残ります。そのため、開発者が「もう終わったはず」と思っていても、実際にはどこかで保持され続けていることがあります。つまり、ARC理解では「いつ解放されるか」を感覚で判断するのではなく、参照関係から考える必要があります。

9. 実務でのメモリ管理の設計はどう考えるべきか

実務でのメモリ管理設計では、「どのオブジェクトがどのオブジェクトを所有するのか」を明確にすることが最重要です。ARCは参照カウントを自動化してくれますが、所有関係が曖昧なままでは、強参照を多用して循環参照を生んだり、逆に弱参照だらけで必要なオブジェクトが早く消えたりします。つまり、メモリ管理設計の中心はARCの知識ではなく、所有関係のモデリングです。

また、ライフサイクルを意識することも不可欠です。画面が存在する間だけ必要なもの、アプリ全体で共有すべきもの、一時的に使うだけのものを区別しないと、すべてを同じように強く持ってしまいやすくなります。つまり、実務のメモリ管理は「どの参照属性を使うか」の前に、「そのオブジェクトは誰の責任でどこまで生かすべきか」を設計する必要があります。

9.1 所有関係の明確化

所有関係の明確化とは、どのオブジェクトが生存責任を持つかをはっきりさせることです。たとえば ViewController が ViewModel を持つのか、ViewModel が Service を持つのか、delegate は所有しないのか、といった整理です。つまり、所有関係が明確であれば、強参照と弱参照の選択も自然になります。

9.2 ライフサイクルの設計

ライフサイクル設計では、オブジェクトが「いつ生まれ」「いつ不要になるか」を考えます。画面と一緒に消えるべきか、アプリ起動中ずっと残るべきか、一時的処理の中だけで十分かによって、保持方法は変わります。つまり、ライフサイクルを意識しないメモリ管理は、保持すべきものと解放すべきものの境界を曖昧にします。

9.3 不要参照の排除

不要参照の排除とは、本来不要な相互参照や長期保持を見つけて減らすことです。知っている必要はあっても所有する必要はない関係は多くあります。つまり、メモリ管理の最適化は「すべてを弱くする」ことではなく、「不要な強参照を持たないようにする」ことです。

10. パフォーマンスへの影響はどの程度あるのか

ARCは便利ですが、パフォーマンスにまったく無関係ではありません。参照カウントの増減は自動とはいえ処理コストを持ちますし、過剰な保持やリークはメモリ使用量を押し上げます。ただし、通常のアプリでARC自体のオーバーヘッドが最大問題になることはそれほど多くありません。実務で本当に問題になるのは、ARCの存在そのものより、ARCで管理される参照関係の設計が悪いことです。つまり、パフォーマンス影響の本質は「ARCが遅い」ではなく、「ARCに任せる構造が悪い」ことにあります。

10.1 メモリ使用量

メモリ使用量への影響は非常に大きいです。不要な強参照が残れば解放が遅れ、不要オブジェクトが積み重なります。つまり、ARC設計の悪さはそのままメモリ量へ表れやすいです。

10.2 CPU負荷

CPU負荷としては、参照カウントの増減自体にもコストがあります。ただし通常はそれ自体より、過剰生成や過剰保持によって間接的にCPUが増えるほうが問題になりやすいです。つまり、ARCのCPU影響は直接より間接のほうが実務では大きいです。

10.3 最適化のポイント

最適化のポイントは、ARCを避けることではなく、所有関係を簡潔にし、不要な保持や不要な生成を減らすことです。つまり、ARC最適化とは低レベルの細工ではなく、設計の整理に近いです。

11. よくあるミスとその回避方法

ARCまわりでよくあるミスは、文法を知らないことより、所有関係を曖昧なまま書いてしまうことから起こります。特に多いのは、weak を使うべき場所で強参照のままにすること、クロージャで self をそのまま捕まえること、親子関係やCoordinator構造で双方向保持を作ってしまうことです。つまり、ARCの失敗は記述ミスというより、設計判断の先送りとして現れやすいです。

また、これらのミスはコードが一応動いてしまうため、気づきにくいのも特徴です。クラッシュせず、画面も表示され、操作もできるが、使い続けるとだんだんおかしくなる、という形で表面化することが多いです。つまり、よくあるミスを知ることは、問題発生後の対処だけでなく、設計時の予防にもつながります。

11.1 weakを使わないケース

delegate や逆向き参照で強参照のままにすると、循環参照の典型的な原因になります。つまり、「相手を知る必要はあるが所有する必要はない」関係で弱参照を使わないことが問題です。

11.2 クロージャでの循環参照

クロージャで self をそのまま使うと、クロージャが self を強く保持し、さらに self がそのクロージャを保持していると循環参照になります。つまり、クロージャは短いコードでも所有関係を作るという意識が必要です。

11.3 所有関係の誤設計

本来一方向の所有で十分なところを、双方向の強参照で設計してしまうと、解放されない構造が生まれます。つまり、ARC問題の根本は属性指定よりも所有関係の誤設計にあります。

よくあるミスと対策

12. ARCを理解する上で重要なこと

ARCを理解するうえで最も重要なのは、ARCを「全部自動でやってくれる仕組み」と見なさないことです。ARCは参照カウントの増減を自動で管理してくれますが、何を所有すべきか、どこで弱参照にすべきか、クロージャでどうキャプチャすべきかまでは決めてくれません。つまり、ARCは自動化されたメモリ管理であっても、設計責任そのものは依然として開発者に残っています。

また、所有関係を意識すること、自動管理に依存しすぎないこと、実際の挙動を計測や確認で理解することも重要です。ARCは理論だけでなく、実際の画面遷移や非同期処理の中でどう振る舞うかを見て初めて腹落ちする部分も多いです。つまり、ARC理解とは文法知識の暗記ではなく、所有関係・ライフサイクル・実行結果をつなげて考えられるようになることです。

まとめ

ARC（自動参照カウント）とは、オブジェクトの強参照数を管理し、参照カウントがゼロになったときに自動で解放するメモリ管理の仕組みです。SwiftやiOS開発ではこのARCによって日常的なメモリ管理の多くが自動化されていますが、それはあくまで参照カウントの増減が自動化されているという意味です。つまり、ARC = 参照カウントによる自動メモリ管理であって、所有関係の設計そのものを自動で正してくれるわけではありません。

実務で問題になるのも、ARCの不具合ではなく、強参照・弱参照・非所有参照の使い分けや、循環参照、クロージャキャプチャ、所有関係の誤設計です。特に大切なのは、問題の本質 = 所有関係の設計ミスだという視点です。誰が誰を所有し、誰は相手を知るだけでよいのか、どのライフサイクルで解放されるべきかが明確であれば、ARCは非常に強力に働きます。

つまり、ARCを理解するとは、単に weak や unowned の文法を覚えることではなく、iOSアプリ全体のオブジェクトの寿命と関係性を設計できるようになることです。この視点が身につくと、メモリリークや retain cycle は難解な不具合ではなく、所有関係の構造問題としてかなり整理して考えられるようになります。