Claude on Xcode で Firebase SDK の更新作業を半自動化する — 個人開発 6 本の iOS アプリで固めた実装メモ

Firebase SDK 12.x から 13.x へのバージョン更新を Claude on Xcode に分担させる

ここからが本題です。6 本のアプリを順番に上げていく工程で、Claude on Xcode に分担させた作業と、自分の手で残した作業を分けて書きます。

下調べ（Claude on Xcode に任せた工程）

各アプリで最初にやるのは、リリースノートの当たりをつけることです。手で公式リポジトリの Releases タブを 12.0 から 13.2 まで遡る必要はなく、Claude on Xcode に範囲を指定して聞いてしまうのが速いです。

firebase-ios-sdk 12.0 から 13.2.1 までの破壊的変更を整理してください。

特に以下のモジュールに影響しそうな変更を優先的に。

- FirebaseAnalytics
- FirebaseCrashlytics
- FirebasePerformance
- FirebaseRemoteConfig

各変更について、影響を受けそうなプロジェクトのファイル名と
行番号も Project Navigator の情報から推定してください。

Claude on Xcode は IDE のシンボル情報を直接読めるので、AppDelegate.swift の FirebaseApp.configure() 周りや、SceneDelegate.swift の Analytics 呼び出し、ViewController.swift の Crashlytics カスタムキー設定など、影響を受けそうな箇所を行番号付きで挙げてくれます。出力をそのまま信じるのではなく「あたりをつけるリスト」として扱う前提で、私はこれを _documents/firebase-13-migration.md に貼り付けて、確認チェックリストとして運用しました。

更新作業（半分は AI、半分は自分の手）

Package Dependencies の更新自体は、Xcode の File → Packages → Update to Latest Package Versions で済みます。問題はその後です。

Crashlytics の Run Script フェーズが SDK 13 系で警告を出すケースがあります。具体的には、${BUILD_DIR%/Build/*}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run のパスが xcfilelist 形式の Input Files / Output Files と整合していないと、Crashlytics が dSYM のアップロードを行うパスがうまく解決できないことがあります。

そこで Claude on Xcode に、現在の Run Script フェーズの設定を読み込ませて、SDK 13 系で推奨される形に書き直してもらいます。

Build Phases にある "Crashlytics run script" のコマンド、
Input Files、Output Files の現在値を読み取ってください。
それを Firebase iOS SDK 13.x で推奨されている設定に
書き換える提案を、変更前後の diff で示してください。

特に Output Files の指定が不適切だと、
incremental build で Run Script が走らないことがあるので
そこを丁寧に。

Claude on Xcode は project.pbxproj の PBXShellScriptBuildPhase セクションを直接読み書きできるので、変更案を Pull Request の diff のような形で出してくれます。私はその出力を Xcode の UI 上で手動で適用する派ですが、claude コマンド経由で apply まで任せることもできます。失敗しても git の restore で戻せるので、最初は AI に直接書き換えさせる運用も悪くありません。

バージョン互換ロックの確認（自分の手で残した工程）

Google Mobile Ads SDK と Firebase SDK の組み合わせは、毎回バージョンマトリクスを確認しています。AdMob は壁紙系アプリの月間 100 万円超の収益源で、メディエーション設定とも絡んでいるため、Claude on Xcode の応答だけで判断するのは怖い領域です。

ここはあえて自分の手で公式ドキュメントを開いて、互換性を確認します。AI は「下調べを担当する司書」、自分は「最終判断を担当する責任者」というメンタルモデルに落ち着きました。

SPM 移行で「Pods/ の残骸」を黙ってクリーンアップさせる

6 本のうち 2 本は、まだ CocoaPods と SPM が混在している状態でした。SDK 13 系へ上げるタイミングで、CocoaPods を完全撤去することにしました。

Pods 撤去後に残る痕跡は、想像以上に多いです。

• .gitignore の Pods/ エントリ
• Podfile と Podfile.lock
• xxx.xcworkspace（CocoaPods が生成していたもの）
• Pods グループの Project Navigator 上の参照
• xcconfig ファイルへの #include "Pods/Target Support Files/.../*.xcconfig" の参照
• Build Settings の PODS_ROOT、PODS_CONFIGURATION_BUILD_DIR などの変数参照
• Run Script Phases の [CP] Check Pods Manifest.lock 等

これらを 1 ファイルずつ手で確認するのは退屈です。Claude on Xcode にプロジェクト全体を見渡してもらい、撤去対象のリストを出させます。

このプロジェクトから CocoaPods を完全撤去したいです。

以下の観点で、撤去すべきファイル・設定・参照を全部リストアップしてください。

1. ファイルシステム上のファイル
2. project.pbxproj 内の PBXFileReference / PBXGroup
3. xcconfig や Build Settings 内の ${PODS_*} 系変数
4. Run Script Phases 内の [CP] で始まるスクリプト
5. .gitignore の Pods 関連エントリ

それぞれ削除しても安全かどうか、不安があれば理由も書いてください。

このプロンプトは 6 本のアプリで使い回しました。1 アプリあたり 15〜20 個の撤去候補が出てきて、その 9 割は機械的に削除して大丈夫なものでした。残り 1 割が「Pods/Target Support Files/.../GoogleService-Info.plist を CocoaPods 経由で参照していた箇所」のような、注意が必要なケースで、ここを手動で詰めることになります。

Claude on Xcode はこのリストを Project Navigator の UI 操作まで踏み込んで提案できるので、Right-click → Delete → Remove Reference のような操作も指示してきます。素直に従って構いません。間違っていても Git で戻せます。

Run Script フェーズの dSYM アップロード設定を AI に再生成させる

CocoaPods 経由の Firebase Crashlytics では、Pods/FirebaseCrashlytics/run を呼ぶ Run Script フェーズが、CocoaPods によって生成・管理されていました。SPM に移行した瞬間、このフェーズは消えます。dSYM のアップロードが止まり、Crashlytics 上で「Symbolicate 不可」のクラッシュが日々積み上がっていく — これが地味で痛い問題です。

この設定の再生成は、Claude on Xcode の得意分野です。

このプロジェクトは Firebase Crashlytics を SPM 経由で使っています。

dSYM を Crashlytics に自動アップロードする Run Script フェーズを
追加してください。

要件:
- Build Phase の最後に追加すること
- Input Files に Info.plist と DWARF dSYM を入れること
- Output Files は空のままで構いません（Build Phase が必ず走るように）
- Shell は /bin/sh
- スクリプト本体は、firebase-ios-sdk の SourcePackages から
  upload-symbols を呼び出すこと
- GoogleService-Info.plist のパスは
  ${PROJECT_DIR}/${PROJECT_NAME}/GoogleService-Info.plist

Claude on Xcode は project.pbxproj に PBXShellScriptBuildPhase を追加するパッチを書いてきます。私は最終的に Xcode UI 上で確認しながら適用する派ですが、AI が出した内容と Firebase 公式ドキュメントの最新例（Apple Silicon 対応など）を見比べて、必要に応じて自分で微調整します。

スクリプト本体は次のような形に収束しました。

#!/bin/sh
"${BUILD_DIR%/Build/*}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run"

Input Files には次の 2 行を入れます。

${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${TARGET_NAME}
$(SRCROOT)/$(BUILT_PRODUCTS_DIR)/$(INFOPLIST_PATH)

このスクリプトを 6 本のアプリすべてに入れて、TestFlight ビルドを 1 本ずつ流し、Crashlytics ダッシュボードに dSYM が届くことを確認します。確認まで終わって初めて、SDK 更新作業が完了したと言える状態です。

SDK 更新後の回帰検証 — Claude on Xcode の「テスト走らせて」運用

Firebase SDK のメジャー更新は、ビルドが通っただけでは安心できません。Analytics のイベントが正しく送れているか、Crashlytics の手動レポート（Crashlytics.crashlytics().log / record(error:)）が動いているか、Remote Config の取得が壊れていないかを、最低限の自動テストでチェックしておきたいところです。

Claude on Xcode は xcodebuild 経由のテスト実行を任せるのに向いています。

このプロジェクトのユニットテストを実行してください。

ターゲットは XXXTests、シミュレータは
iPhone 15 Pro / iOS 17.5 を指定してください。

失敗したテストがあれば、テスト名と原因の推定を整理してください。

このプロンプトを送ると、Xcode 内のターミナルで xcodebuild test -workspace ... -scheme XXXTests -destination ... のようなコマンドを生成して走らせます。実行ログを Claude on Xcode が読み取り、失敗テストがあれば該当のテストケースをエディタで開いた上で、修正候補を提案してくれます。

私の運用では、Firebase 更新後に必ず以下の 3 テストを通します。

1. FirebaseApp.configure() がクラッシュせずに完了することを確認するスモークテスト
2. Analytics.logEvent(_:parameters:) を 1 回呼んで Console エラーが出ないかを確認するテスト
3. Crashlytics.crashlytics().setCustomValue(_:forKey:) を呼んで、Crashlytics の初期化を検証するテスト

これらは Firebase の公式ドキュメントが推奨しているものではなく、12 年の運用経験から、私が「ここで毎回壊れる」と感じている箇所を Test に変換したものです。Claude on Xcode に「6 アプリすべてに同じテストを足したい、書き方を統一して」と頼むと、テストファイルのテンプレートを生成してくれて、6 本のテストプロジェクトに展開する時間が劇的に縮みます。

6 本のアプリで観察した詰まりどころと回避策

6 本全てで同じ手順を踏んだわけではありません。アプリごとに観察した詰まりどころを並べておきます。

壁紙アプリ A では、32bit 時代の古い .lproj フォルダが残っていて、Firebase 13 系の Privacy Manifest と相互作用しておかしな警告が出ました。Claude on Xcode に「Privacy Manifest の警告を整理してほしい」と頼んだら、.lproj フォルダの整合性まで含めて提案してくれて、結果的に古いローカライズフォルダを撤去する判断に至りました。

癒し系アプリ B では、Firebase Performance の初期化が applicationDidFinishLaunching 内ではなく独自の setupAnalytics() メソッドに分離されていたため、Claude on Xcode の自動移行提案が「AppDelegate.swift の 24 行目を書き換える」と読み違えました。実際に書き換えるべきは別ファイルでした。AI の提案は鵜呑みにせず、必ず diff で確認するという原則を強化する結果になりました。

引き寄せ系アプリ C では、AdMob の Mediation Adapter が古く、Firebase の Analytics For Firebase 連携で予期しない依存関係エラーが出ました。Claude on Xcode に依存関係グラフを整理させたら、AdMob 12.x への先行アップデートが必要だと提案され、その通りでした。AdMob 側の eCPM 推移を Claude in Chrome で監視しているのと組み合わせて、3 日かけて段階的に上げました。

残り 3 本は同じ系統のアプリだったので、最初の 1 本の手順を Claude on Xcode に「再現する手順書として整理してほしい」と頼み、docs/firebase-13-migration.md のような形で残しました。2 本目以降はその手順書を参照しながら作業したので、所要時間は 1 本目の 1/3 程度に収まりました。

Claude on Xcode を「採用しない」と判断した工程

念のため、ここは AI を使わなかった工程も書いておきます。

• Crashlytics に届くクラッシュのトリアージは、スタックトレースを Claude in Chrome 側に読ませる方が、Firebase Console の UI を直接見られる分、効率が良いと感じました。Claude on Xcode は IDE 内のコードに紐づいた読解は強いですが、サーバ側のダッシュボードを横断的に見る用途には向いていません
• 段階公開の判断は AI に意思決定を委ねず、自分でやります。TestFlight 配信して 24 時間でクラッシュ率を見て、本番ロールアウトに踏み切る判断は、誤った判断のコストが大きすぎる工程です。責任の所在を明確にしておく方が、長期的に良い運用になると考えています
• App Store の審査返信は、Claude on Xcode の用途から外れています。文面は別途、Claude.ai 側で下書きさせて、最後は自分で書き直して投函しています

「使わない判断」を明文化しておくことで、AI への依存と自律の境界がはっきりします。私自身は「Xcode の中で完結する作業は Claude on Xcode、外を跨ぐ作業はそれぞれの環境の AI」という分け方に落ち着きました。

次に取り組むこと

Firebase SDK 13 系への移行は完了しましたが、Claude on Xcode の使い倒し方はまだ序盤です。次に試してみたいのは、Swift 6 の Strict Concurrency 対応を Claude on Xcode に分担させる工程です。Sendable への適合と @MainActor の境界設計は機械的に置換できる部分と、設計判断が必要な部分が混ざっていて、AI と人間の役割分担を考える良い題材になりそうです。

同じように個人開発で複数アプリを保守している方が、Firebase の更新に億劫さを感じているなら、Claude on Xcode を入れる初日のセットアップだけ済ませてみることをお勧めします。最初の 30 分で「IDE の中に常駐する助手」がいる感覚を体験できれば、後はその助手にどこまで任せるか、どこは自分で抱えるかを、自分の判断で組み立てていけるようになります。

お読みいただきありがとうございました。Firebase SDK の更新は、毎年回ってくる地味な作業の代表格ですが、AI を相棒に組み込むことで、その作業時間を「次のアプリのデザイン」に振り向ける余地が生まれます。私自身も同じ運用を続けながら、別のサイトでも記録を増やしていきますので、引き続き読んでいただけたら嬉しいです。