2014年から個人で iOS と Android の壁紙アプリを運用してきたのですが、今春から数本のアプリで Swift Package Manager 移行と iOS 26 対応を兼ねた構造的なリファクタリングを進めています。コード自体は10年以上手を入れ続けたもので、UIViewController がいくつも肥大化していて、新しい変更を入れるたびに「どこに何があるのか」を読み解くだけで半時間が溶けることもありました。
そんな最中に試したのが Antigravity の Walkthroughs です。Agent モードに「リファクタリングのステップを Walkthrough で出して」と頼むと、変更を「いま何を直していて、次に何を直すか」という解説付きの段階に分けて見せてくれる機能です。2週間ほど日常の作業に組み込んでみたので、向き不向きと、自分なりに整理した使い分けを残しておきます。
Walkthroughs を使い始めた経緯
最初は Agent モードに「MainViewController.swift を MVVM 風に整理してください」とだけお願いしていました。出力はそれっぽいのですが、一度に複数のファイルが書き換わると、どこから読めばいいのか分からなくなることが多々ありました。差分を順に読むのは可能でも、変更の意図が頭に入ってこないのです。
Walkthroughs に頼むようになってから、その「読み解く負担」がだいぶ軽くなりました。具体的には、リファクタリング全体を5〜8ステップ程度に区切り、各ステップに短い意図説明と差分が紐づいた形で提示されます。私の場合は1ステップあたり「ファイル1〜2本・行数50〜120行」程度になるよう調整して、レビューしながら進めるのが安定する印象でした。
Walkthrough Step 3 of 6:
Title: UICollectionViewDataSource を WallpaperListViewModel に切り出す
Files: WallpaperListViewController.swift / WallpaperListViewModel.swift (new)
Intent: 表示ロジックをコントローラから剥がし、後続ステップで
ユニットテストを書ける形にする
Diff:
+ class WallpaperListViewModel { ... }
- extension WallpaperListViewController: UICollectionViewDataSource { ... }
+ extension WallpaperListViewController: UICollectionViewDataSource { ... }「次のステップに進む前に、いまの変更だけビルドして実機で確認したい」というやり方が自然にできるようになり、レガシーコードに対する心理的な抵抗が少し下がりました。
実運用で良かったところ
2週間使っていちばん助かったのは、レビュー観点が明確になったことです。ステップごとに意図が言語化されているので、自分が「いま何の品質を担保すべきか」を意識しながら読めます。「このステップは振る舞いを変えない純粋なリファクタなので、外側の挙動だけ確認する」「このステップは挙動が一つだけ変わるので、その一点に集中する」といった具合に、確認すべき対象が絞り込まれるのです。
宮大工だった両祖父の話を父からよく聞いて育ったのですが、「直す前にまず古い継ぎ手をよく見ろ」という言葉が記憶に残っています。Walkthroughs を使っているとき、私自身まさにそれと近い感覚で、変更を進める前にいったん手を止めて、いまの構造を観察する時間が増えました。ツールに教えられるというより、ツールが「観察する間」を作ってくれる感覚に近いです。
もう一つ実用的だったのが、AdMob まわりの初期化コードに触ったときの安心感です。広告 SDK の初期化は順序を間違えると本番でだけ落ちることがあるため、いきなり全部を書き換えるのは怖い箇所です。Walkthroughs で「広告関連の責務だけを移動する」「次に名前を変える」「最後にテストを追加する」と段階を切ってもらうと、各ステップで pod-try ビルドや TestFlight ビルドを挟みやすく、回帰の発見が早くなりました。
ぶつかった限界
良いことばかり書いてもフェアではないので、つまずいた点も残しておきます。
1つ目は、複数ファイルにまたがる依存変更で、Walkthrough のステップ分割が雑になることがあった点です。具体的には、protocol を切り出して既存クラス3つに実装させるような変更で、3つの実装変更を1ステップに詰め込まれてしまい、レビューが重くなる場面がありました。これは「最大でも1ステップ2ファイルに収めてください」と最初の依頼に明示することで、ある程度コントロールできます。
2つ目は、Walkthroughs はあくまで「進め方の提示」であって「最終形の保証」ではないことです。途中ステップで生成された中間状態のコードがビルドエラーを含むことがあり、各ステップの末尾で xcodebuild -scheme WallpaperApp -destination "generic/platform=iOS" を回す前提で受け取るのが現実的でした。Plan Mode のように事前にコンパイラ的な整合をある程度取ってくれるわけではない、と割り切るのが楽です。
3つ目は、ステップ間で文脈が薄まる現象です。長い Walkthrough を後半まで進めると、序盤に決めた命名規則を忘れて新しい名前を提案してくることがありました。私は最初の依頼の冒頭に「以下の命名規則を最後まで守ってください」と短いリストを置くことで対処しています。これは Plan Mode でも同じ工夫が効きます。
Plan Mode との使い分け
Plan Mode と何が違うのか、というのは2週間使い終えていま自分が一番説明したいことです。私の運用では、ざっくり次のように使い分けるのが落ち着きました。
- Plan Mode が合う場面: 新機能の追加など、まだコードがない領域の設計を詰めたいとき。要件と制約から逆算して、影響範囲とインターフェースを先に固めたい場合に強いです。
- Walkthroughs が合う場面: 既存コードの構造を変えるリファクタリングや、レガシーな初期化処理を順番に置き換えるような、「中間状態を保ったまま動かしながら進めたい」ときに合います。
レガシー資産が多い壁紙アプリのような個人開発プロジェクトでは、Walkthroughs の出番が思っていた以上に多かったというのが正直なところです。逆に、まったく新しい SwiftUI 画面を一から作るときは Plan Mode のほうが速く形になります。
静かに続けて気づいたこと
10年以上動き続けているアプリのコードを触るのは、新規開発とは違う緊張感があります。「ここを直したら、誰の朝の壁紙更新が止まるかもしれない」という感覚が、頭の片隅から離れません。Walkthroughs は派手な機能ではありませんが、その緊張を少しずつ言語化し、外側に出してくれる道具でした。
個人開発者にとって、リファクタリングは「やったほうがいい」と分かっていても腰が重い作業です。私の場合、Walkthroughs を入れてから、リファクタリングに着手する1日あたりのコミット数が体感で2倍くらい増えました。一度に大きく書き換える代わりに、小さな安全な変更を積み重ねる方向に自然と振れたのが大きいのだと思います。
次は Crashlytics の自動分析パイプラインと Walkthroughs を組み合わせて、本番で観測されたクラッシュからリファクタ案を提案するところまで自動化したい、と考えています。同じように10年規模のコードを抱えている個人開発者の方の参考になれば幸いです。
お読みいただきありがとうございました。