13年分のAppDelegate資産を持つ、300画面規模のアプリをiOSの強制対応期限までにSceneDelegateへ移行する——ZOZOのWEARチームが公開した実例が教えてくれるのは、AIに最初にやらせたのがコード生成ではなく「影響範囲の洗い出し」と「QA観点の生成」だったことだ。
役割分担表を読ませて対象メソッドを先に特定する手順と、DiffからQA観点を自動で出す仕組み、そして「今回はやらない」と人間が先に決めたスコープの線引き。
WEARは13年分のAppDelegateの資産を抱える、300個のViewControllerからなる大規模アプリだ。
iOS 27以降、SceneDelegateに未対応のアプリは起動できなくなる。つまり「今回は見送る」という選択肢自体が存在しない、強制対応の移行だった。ZOZO TECH BLOGが公開したこの実例が示すのは、この規模の移行にAIをどう使ったかという、コードを書く手前の設計判断だ。
大きすぎるタスクをそのままAIに渡すと迷子になる。WEARチームが最初に投げたのは、実装ではなくこの3つだった。
Claude CodeやGitHub Copilotに、AppDelegateとSceneDelegateの役割分担表を読み込ませ、移行対象になる具体的なデリゲートメソッドを洗い出させる。まず「何を動かすか」のリストを、コードを書く前に作る。
デリゲートメソッドを一括で移すのではなく、1個ずつSceneDelegateへ移す。AIが高い精度で仕事をできる粒度に切り分けるほど、一括処理につきものの対応漏れリスクが下がる。
プロトタイプ作成時に全体の影響範囲を把握し、実際のPR作成時にはDiffからQA観点をJiraへ出力。さらにプロトタイプ段階の観点とブランチごとの観点を突き合わせて検証する。
この手順で実際に見つかった見落としやすい観点として、記事は「特定の地域からアクセスしたときだけ表示される利用規約ウィンドウ」と「複数のライフサイクルイベントにまたがるメンテナンス画面の表示処理」を挙げている。どちらも、1画面を単体で見ているだけでは気づきにくい、条件分岐やイベントの重なりに依存する挙動だ。
技術面の落とし穴も具体的だった。WindowをUIApplication.shared.connectedScenes.first?.windows.firstで取得する従来のコードは、マルチウィンドウ環境で誤ったWindowを参照してしまうためview.windowへの書き換えが必須になる。外部起動の判定もlaunchOptionsからUIScene.ConnectionOptionsへ移り、userActivitiesとurlContextsを見てURLスキーム・ユニバーサルリンク・リモート通知のどれかを判別する形に変わる。
ここが核心。AIに任せたのは「移行対象の洗い出し」と「QA観点の生成」——コードを書く前の情報収集と点検リストづくりだった。1画面ずつ移す判断も、人間が先に決めたスコープの範囲内でAIに正確に仕事をさせるための設計だ。
移行方針は「シーンのライフサイクル対応に限定する」「処理のリファクタリングは後回しにする」「マルチウィンドウ対応は見送る」という3点でスコープを絞り込んでいる。これは技術的な難易度の問題ではなく、リスクを増やさないための線引きだ。動くコードを壊さないことを最優先に、"ついでにきれいにする"誘惑を切り離している。
「AIの『できました』を信じない」検品文化（AIの「できました」を信じない｜3段階で検品する運用）が生成後の確認だったのに対し、今回の話は生成の前段階でAIを使う話だ。個人開発でも、記事の一括改修やスキーマ変更のような「範囲が広くて怖いタスク」に同じ順番を当てはめられる。
西見公宏・吉田真吾・大嶋勇樹。範囲の広いタスクをAIにどう切り分けて渡すか、影響範囲の把握や検証設計を体系的に学べる一冊
Amazonのアソシエイトとして、meclGGは適格販売により収入を得ています。