🦜
CA.swift #22 〜Swiftの進化を活かした技術基盤への挑戦〜 レポート
公開
2025-04-03
更新
2025-04-03
文章量
約4600字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
2025年3月3日、サイバーエージェントが主催するiOSエンジニア向け勉強会「CA.swift #22」が開催されました。 今回のテーマは「Swiftの進化を活かした技術基盤への挑戦」。Swift ConcurrencyやSwiftUI、TCA（The Composable Architecture）など、Appleが提案する新しい開発手法・アーキテクチャをどのように既存のアプリへ落とし込み、進化させているのかが4つのセッションで共有されました。
この勉強会「CA.swift」は、ABEMAやAmeba、AWA、tappleなどを開発するエンジニアたちが、実際の開発現場から得られた知見をオープンに発信する場として定期的に行われています。今回はオンライン・オフラインのハイブリッド開催ということもあり、終了後の懇親会まで含め、多くのエンジニアが一緒に盛り上がりました。ここでは各セッションの内容を順番にレポートしていきます。
オープニング
冒頭では、司会より勉強会の趣旨説明やSNSでの質問案内などがありました。会場にはiOSエンジニアやSwiftに関心を持つ方々が集い、オンラインはYouTube Live配信。 久しぶりのハイブリッド開催ということもあり、リアルでもオンラインでも活発に質問が飛び交う形となりました。ちなみに、SNS上でのハッシュタグは「#ca_swift」。
登壇者は以下の4名：
小田島 直樹（Ameba） 「The Composable Architecture (TCA) を用いたAmebaのリアーキテクチャ」
吉田 周平（CL） 「SwiftUI導入から1年、SwiftUI導入とVueFluxライクな状態管理」
安井 瑛男（株式会社AbemaTV） 「大規模プロジェクトにおける段階的な技術刷新について」
廣川 昂紀（ABEMA） 「SwiftUI移行のためのインプレッショントラッキング基盤の構築」
以下、それぞれの発表要旨をまとめます。
セッション1：The Composable Architecture (TCA) を用いたAmebaのリアーキテクチャ（小田島 直樹）
概要
AmebaアプリのiOSエンジニア・小田島さんは、既存のRxSwift＋MVVM＋Clean Architectureによる実装から、TCA（The Composable Architecture）を使った新しいアーキテクチャへと段階的に移行した話を披露しました。
ポイント
既存アーキテクチャの課題
RxSwiftに依存したデータフローが肥大化し、特に複雑な画面ではViewModelが過剰に大きくなって可読性が低下
SwiftUIなどモダンな技術との整合性が取りづらく、今後の進化を妨げる可能性があった
TCAの導入
TCA（The Composable Architecture）は単方向データフローを厳密に守るリダックス系フレームワーク
アクション、ステート、レデューサー、エフェクトといった構成要素に分割し、複雑なビジネスロジックを整理
SwiftUIとの親和性が高く、スレッド安全性やテストのしやすさでメリットがある
メリット
ロジックが明確化：アクションの網羅性により「何をトリガーにどう状態を変えるか」が一目瞭然
テストが書きやすい：テストストアを用いることでレデューサーの動作を単体で検証
UIキットやSwiftUIの画面遷移をシームレスに扱える：従来のUIKit画面とも共存可能
デメリット・課題
学習コスト：リダックス系フレームワークに馴染みがないエンジニアには敷居が高い
パフォーマンス：アクションを過剰に発行しすぎるとオーバーヘッド
ライブラリ依存リスク：ポイントフリー（作者レミ氏）提供のフレームワークに依存
質疑応答
「TCAのアクション発行は重いのか？」といった質問が出ましたが、小田島さんは「無数のコンポーネントそれぞれがアクションを連発する構造になるとパフォーマンスに注意が必要。ただ通常の範囲なら問題ない」と答えていました。
セッション2：SwiftUI導入から1年、SwiftUI導入とVueFluxライクな状態管理（吉田 周平）
概要
LDHの配信アプリ「CL」を担当する吉田さんは、既存のUIKit＋VueFluxによる単方向データフローを、SwiftUIで再構築した事例を紹介。既存エンジニアの学習コストを抑えつつ、状態管理をシンプルに保つ方法が語られました。
ポイント
VueFluxとは
Flux系ライブラリをSwiftで実装したもの
単方向データフロー（アクション→ミューテーション→ステート→ビュー）を保ちやすく、CLの既存アーキテクチャとして確立
なぜSwiftUIへ移行？
新規入社エンジニアがSwiftUI学習済みであるケースが多い
ストーリーボードの差分確認が辛い
宣言的UIでコード見通しを良くしたい
アーキテクチャ例
親ビュー（スクリーン）が
StateObjectでアダプターを持ち、子ビュー（コンテント）にデータやイベントクロージャを渡すアダプターはオブザーバブルオブジェクトとしてアクションをパブリッシュし、ステートの変更を通知
従来のVueFluxの「単方向フロー」をほぼ継承しつつ、SwiftUI流にリファイン
メリット・デメリット
メリット：UI更新がシンプルになり、ビューと状態の結合が宣言的に書ける。コードレビューがしやすい
デメリット：最小限でもファイルが5つ必要（スクリーン、コンテント、アダプター、ステート、データモデル）などボイラープレートが多い
質疑応答
「画面が多いとファイル数が膨大にならないか？」という質問に対して吉田さんは「確かに増える。一方、単一方向データフローを保てる利点や今後のSwiftUIネイティブ化を考慮して割り切っている」と回答。
セッション3：大規模プロジェクトにおける段階的な技術刷新について（安井 瑛男）
概要
ABEMAを担当する安井さんは、Kotlin Multiplatformを導入しつつ、SwiftUIやSwift Concurrencyなどモダンな技術を段階的に適用する「新プロジェクト」構成を採用し、古い設計を徐々に置き換える戦略を語りました。
ポイント
技術負債とKMP導入
10年近く運用されるABEMAのiOSアプリは、CocoaPods・RxSwift・Storyboardなど古い技術が残る
Kotlin Multiplatformを本格採用し、ビジネスロジックを共通化しながらネイティブ部分をSwiftUIやConcurrencyで再構築する計画
新プロジェクト構成
コトリンマルチプラットフォーム（共通実装）をビルドして既存のiOSアプリに取り込む
新たに作ったスイフトベースの「新プロジェクト」はSwiftPMでライブラリ管理し、既存アプリから各画面単位で利用する
画面単位で旧実装をリプレースし、フィーチャーフラグで新旧を切り替え可能にして段階的移行を実現
Swift Concurrency対応
既存プロジェクトはRxSwiftを大量に使用しており、コンカレンシーを中途半端に混ぜると複雑化
新プロジェクト側で
strict concurrencyオプションを有効にしつつ（ただし最終的に問題があり5モードへ戻している）、運用ポリシーやドキュメント整備を推進
質疑応答
「新プロジェクトから旧プロジェクトを参照できないようにするには？」といった質問に対し、安井さんは「ビルドフローを工夫し、新実装をまとめて既存プロジェクトに読み込む形。新プロジェクト単体では旧コードに触れられず、逆方向もできない」と回答していました。
セッション4：SwiftUI移行のためのインプレッショントラッキング基盤の構築（廣川 昂紀）
概要
同じくABEMAの廣川さんは、SwiftUIで画面をフルリプレースする際に必要となる「インプレッションログ」（ユーザーが画面のどの部分を見たかを計測する仕組み）をどう再構築したかを紹介しました。
ポイント
インプレッショントラッキングとは
画面中の特定コンポーネントが「80%以上の領域が2秒以上表示された」などの条件で「見られた」とみなしログを送信
UI KitではUITableView/UICollectionViewにフレームを計算する仕組みがあったが、SwiftUIでは自前の仕組みが必要に
基盤実装
TrackableScrollViewとTrackableModifierを用意し、スクロール位置やフレームをキャッシュ表示領域を判定し続け、一定時間表示されたらログ送信（またはコールバック）
デバックモードでは表示状況を可視化し、テスト用にUIテストも書いて安定性を検証
課題
シミュレーターと実機で挙動が違うケースあり
UIテストは実行時間が長くなりがち。スクロールを細かく制御するのが難しく工夫が必要
質疑応答
「スクロール時に判定するとカクつきそうだが、パフォーマンスは大丈夫？」という質問では、廣川さんは「すべてのビューでジオメトリ変化を監視すると負荷になる。スクロールビューで判定タイミングをコントロールし、必要なビューのみに通知する工夫をしている」と答えていました。
全体を踏まえた感想：新技術を活かしながら段階的に前進する
今回のCA.swift #22では、Kotlin MultiplatformやSwift Concurrency、TCA、SwiftUIといった最先端のトピックが次々に登場しました。共通しているのは 「既存の巨大アプリをいかに段階的にリプレースしながら、新技術を取り入れるか」 という視点です。
TCAやFlux系アーキテクチャー：学習コストはあるが、テスト容易性やロジックの明確化に優れる。AmebaやCLが採用した事例は、既存エンジニアの知識を最大限活かしながらSwiftUIへ移行する手がかりとなる
Kotlin Multiplatformとの併用：ABEMAが示すように、大規模プロダクトでビジネスロジックを共通化しつつ、ネイティブUIをSwiftUIで刷新する計画を段階的に進める
コンカレンシー対応やログ基盤の再構築：新技術を入れるには運用ドキュメントやデバッグツールが欠かせない。インプレッショントラッキングも含め、「使う人が使いやすい基盤」を整えることが大事
「Swiftの進化」と銘打たれた今回は、いずれの取り組みにおいても単なる最新技術の導入に留まらず、既存ユーザー・既存プロジェクトとの整合性をどう確保しながら前進するかという泥臭いアプローチが強調されました。
今後もCA.swiftでは、サイバーエージェントグループ内でのiOS開発知見を持ち寄りながら、事例やノウハウを共有していく見込みとのこと。大規模アプリを抱えるチームならではの「スピード感と地に足のついた技術選定」が、さらなるサービス改善へ繋がることでしょう。
以上、CA.swift #22「Swiftの進化を活かした技術基盤への挑戦」のイベントレポートでした。次回以降の開催でも、iOS開発者必見のリアルな知見が共有されるはずですので、ぜひチェックしてみてください。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
