◉ Claude.ai/2026-05-27上級

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

Xcode に統合した Claude on Xcode を使い、Firebase SDK のメジャー更新と SPM 移行を 6 本の iOS アプリでまとめて進めた工程を、選択コマンド・プロンプト雛形・回帰検証の流れまで残します。

claude-on-xcode² firebase ios¹⁴ swift-package-manager 個人開発¹¹⁰

✦ プレミアム記事

朝、Xcode の Project Navigator を開いて Firebase の Swift Package を見ると、12.0.0 から 13.2.1 まで Update が並んでいることがあります。Update Package を押すだけなら一瞬ですが、その奥には Crashlytics の Run Script、SwiftLint 設定、Privacy Manifest、ATT プロンプトの順序など、6 本のアプリそれぞれで微妙にずれた箇所が眠っています。気づかずにリリースすると、夜中の Crashlytics 通知が静かに増えていく — それが個人開発で iOS アプリを 12 年運営してきた身として、何度も繰り返した苦い経験でした。

2026 年に入ってから、Anthropic が公開した Claude on Xcode を業務 IDE に組み込み、Firebase の更新作業の段取りを大きく組み直しました。Xcode 16.4 / Claude on Xcode 0.4 系の組み合わせで、累計 5,000 万ダウンロードを支えてきた壁紙・癒し・引き寄せ系のアプリを 6 本まとめて 13 系まで持ち上げた工程を、ここに残します。

Dolice Labs の運営も 2014 年からの個人開発と地続きで、今回扱う Firebase SDK 更新の題材は、実際に App Store / Google Play の最新リリースに含めたものを、検証順に書き直しています。

Claude on Xcode が「Firebase 更新ストレス」を変えた最初の 30 分

最初に Claude on Xcode を入れて触ったのは、Beautiful HD Wallpapers のプロジェクトでした。CocoaPods から SPM への移行は別記事で記録済みで、その時点では Firebase SDK のバージョンは 12.4 系でした。

Xcode を開いた状態で右側のサイドバーに Claude のパネルを並べて、まず投げたのは次のプロンプトです。

このプロジェクトの Package Dependencies を読んで、
firebase-ios-sdk が今どのバージョンか、
最新のメジャーバージョンへの更新で破壊的変更が
ありそうな箇所をピンポイントで挙げてください。
特に Crashlytics と Analytics、AdMob 周りの依存関係を
注視してほしいです。

Claude on Xcode は IDE のコンテキストとして Package.resolved や *.xcodeproj/project.pbxproj を読み取れるので、firebase-ios-sdk の現在ピン留めバージョンを正確に把握した上で、Crashlytics の setCrashlyticsCollectionEnabled 周りの API 変更可能性、Analytics のイベント命名規約のリント強化、Google Mobile Ads SDK 12 系との互換マトリクスを最初の応答で並べてくれました。完全に正しいわけではないので、最後は Firebase のリリースノートを自分で見直す前提です。それでも「リリースノートを読む順番」が決まるだけで、最初の 30 分が劇的に短くなる感覚は、Xcode 単体で作業していた頃には味わえないものでした。

ここで重要なのは、Claude on Xcode は Xcode 内のシンタックス情報やビルド設定を読めますが、Firebase Console や App Store Connect のような外部システムにはアクセスできない点です。役割分担を最初に決めておくと、後で迷いません。

インストールと初期セットアップ — Xcode 16.4 / Claude on Xcode 0.4 系の前提

公式の手順そのままでは、個人開発のプロジェクトに入れた時に詰まる箇所がいくつかあります。

Anthropic アカウントの API キーを Claude on Xcode の設定に登録します。チーム開発であれば Claude Console 側で Workspace を作って権限を絞るのが順当ですが、私のように一人で運営しているプロジェクトでは個人ワークスペースの専用キーをそのまま使い、月次の使用量を Console の Usage タブで眺める運用に落ち着きました
Xcode の Source Editor 拡張を許可します。System Settings → Privacy & Security → Extensions → Xcode Source Editor から Claude on Xcode をオンにしないと、コード補完が動かないどころか、Project Navigator のコンテキストすら読めません
Indexing が完了してから話しかけることを徹底します。firebase-ios-sdk のような重い SPM を入れた直後は、Xcode のインデックスが回り切るまで 3〜5 分かかります。インデックス未完で問い合わせると、Claude on Xcode が古いコードグラフで応答するので、信頼度が大きく落ちます

3 つ目はビルドが落ちても気づきにくい落とし穴で、私自身、最初の 2 週間で 3 回引っかかりました。Activity Monitor で XCBBuildService の CPU が落ち着いてから話しかける、という単純なルールに変えてから安定しています。

設定が終わったら、最初のセッションで以下のプロンプトを送って、プロジェクトのコンテキストを Claude 側に読み込ませます。

このプロジェクトの全体像を整理してください。

- ターゲット構成（Main / Extension / Widget / Watch）
- Package Dependencies のメジャーバージョン一覧
- Build Settings で SWIFT_VERSION / IPHONEOS_DEPLOYMENT_TARGET / SWIFT_STRICT_CONCURRENCY の値
- Run Script Phases の名前と役割

これらをマークダウンで一覧化してください。

このアウトラインは後で何度も参照するので、Claude on Xcode に頼んだ後に .claude/project-overview.md として保存しておくと、別セッションでも引き継ぎが効きます。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦Claude on Xcode を Xcode のサイドバーに常駐させて、Firebase SDK 12 系から 13 系への更新を AI に下調べさせ、自分はビルド検証に専念するワークフローを 6 本のアプリで再現できるようになります

✦CocoaPods から SPM への移行で残りがちな Run Script フェーズの dSYM アップロード設定や、Pods 関連の .gitignore / xcconfig の整合性を、Claude on Xcode に再生成させて 30 分以内に再構築する手順が分かります

✦個人開発 12 年・累計 5,000 万 DL の運用視点で、Claude on Xcode を使う工程と使わない工程を分けた判断材料（テストランナー連携・Crashlytics 突合・ATT 順序）を取得できます

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

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 テストを通します。

FirebaseApp.configure() がクラッシュせずに完了することを確認するスモークテスト
Analytics.logEvent(_:parameters:) を 1 回呼んで Console エラーが出ないかを確認するテスト
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 を相棒に組み込むことで、その作業時間を「次のアプリのデザイン」に振り向ける余地が生まれます。私自身も同じ運用を続けながら、別のサイトでも記録を増やしていきますので、引き続き読んでいただけたら嬉しいです。