個人開発で運用しているiOS壁紙アプリの一群を、CocoaPodsからSwift Package Manager（SPM）へ移行する作業を5月の前半に始めました。Firebase iOS SDKがCocoaPodsサポートを段階的に縮小していく流れの中で、2014年から積み上げてきた自分のアプリ群（累計5,000万ダウンロード超）も追従しないわけにはいかなくなったからです。
ただ、移行に着手するまでの「下調べ」が想像以上に重い作業でした。各サブモジュール（Analytics・Crashlytics・Remote Config・Cloud Messaging・AdMob連携）のSPM対応状況、依存関係、最低iOSバージョンの変化、CocoaPods時代の Podfile.lock をどうSPMの Package.resolved に橋渡しするか――。記事やGitHub Issueを巡回するだけでは効率が悪く、何かツールに整理を任せられないかと思いました。
そこでNotebookLMとGemini Deep Researchを、同じ調査タスクに2週間並行で投入してみました。どちらもGeminiベースで「リサーチ補助」を謳いますが、設計思想が違うため、得意な場面と苦手な場面がはっきり分かれます。以下、実際に使い分けてみた所感を整理してみます。
2週間の運用ルール — 同じ問いを両方に投げる
比較を雑にしないために、2週間のあいだ次のルールを置きました。
- 移行調査で出てきた問いは、原則としてNotebookLMとDeep Researchの両方に投げる
- NotebookLM側には、自分で集めた一次資料（Firebase公式ドキュメントのPDF・GitHubの
Package.swift・過去の個人メモ）だけを取り込む - Deep Research側には、同じ問いをそのままプロンプトとして渡す
- 両者の回答をGoogle Driveのドキュメントに並べて貼り、最後に自分の判断を一行添える
回答の良し悪しを主観で比べてもブレるので、最終的に「自分がSPM移行のチェックリストに採用したかどうか」を採用率として記録しました。2週間で38問の調査クエリを投げ、結果として NotebookLMの採用率は約71%・Deep Researchの採用率は約53% という数字になりました。ただし、この数字だけを見るとNotebookLMが圧勝に見えますが、実際は「強いシーン」がきれいに分かれます。
NotebookLMが強いのは「自分で集めた一次資料」を扱うとき
NotebookLMの本領は、自分で投入したソースの中から答えを引き出すところにあります。今回の調査で言えば、Firebase iOS SDKの CHANGELOG.md、GitHubの firebase-ios-sdk リポジトリの Package.swift、AdMobとFirebaseの連携モジュールの更新履歴をまとめて取り込みました。
「Firebase CrashlyticsのSPM対応は何バージョン以降か」「Performance Monitoringのシンボルアップロードスクリプトは、SPMではどこに置くべきか」といった具体的な問いに対して、NotebookLMはソース内の記述をきちんと引用しながら答えてくれます。引用付きで返ってくるので、私自身があとからリポジトリで該当箇所を確認するときに迷いません。
特に助けられたのは、過去に書きためた個人メモを取り込めた点です。2024年以降に書いたFirebase関連の作業ノートをPDF化して放り込み、「以前ハマった pod install のエラーは、SPMでも同じ条件で再現するか」を尋ねると、以前の対処内容まで含めて整理してくれます。Deep Researchには自分の過去メモまで読ませることはできないので、ここは構造的にNotebookLMに分があります。
逆に、ソースに含まれていない情報はうまく拾えません。NotebookLMは「ソースの外には踏み込まない」設計に振り切られているので、最新の動向や、まだ公式ドキュメントに反映されていないGitHub Issueの議論などは取りこぼします。
Gemini Deep Researchが強いのは「未知の最新議論」を辿るとき
Deep Researchは、明確に「外側を探しに行く」役割で機能しました。たとえば「firebase-ios-sdk の最近のメジャーバージョンで、AdMob mediationアダプタの最低iOSバージョンが変わった経緯」のような、複数のリリースノート・Issue・StackOverflowをまたいで結論を出す必要がある問いです。
Deep Researchは、Web検索結果を辿りながら自分でリサーチプランを立て、最終的に出典付きのレポートとして渡してくれます。私が手で同じことをやろうとすると半日かかる作業が、20〜30分の生成時間で「下書き」までは到達します。
私が好きなのは、出典リンクをクリックして元情報に当たれる点です。Deep Researchの結論をそのまま採用するのは怖いので、必ず重要な記述は一次ソースを開いて読み直しますが、「どこを読みに行けばいいか」が明確になっているだけで作業負担が下がります。
ただ、Deep Researchにも限界がありました。自分の社内事情やアプリ固有の事情を持ち込めないので、「自分のアプリで現状こうなっているが、SPMに移行したらどう変わるか」という問いには答えにくいのです。あくまで「世間一般でのFirebase SDK移行」という抽象度で返ってくるため、最後の判断は自分でやる必要があります。
同じ問いに対する両者の回答パターンを比べてみた
具体的に印象に残ったのは、「Firebase Performance MonitoringのdSYMアップロードスクリプトを、SPM環境でどこに置くか」という問いに対する違いでした。
NotebookLMは、私が取り込んだFirebase iOS SDKのREADMEの該当セクションを直接引用しながら、「Run Script Phaseに ${BUILD_DIR%/Build/*}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/upload-symbols を指定する」という具体的なパスを返してきました。出典が明示されているので、すぐにそのままXcodeのビルドフェーズに反映できました。
Deep Researchは、同じ問いに対して「公式ドキュメントの記述 + 同様の問題で詰まった人のStackOverflow議論 + 最近の firebase-ios-sdk Issueでの補足」を組み合わせて返してきました。一次ソースだけ読むと見落とすような、Apple Silicon Mac環境特有のパス問題まで触れていて、こちらは別の角度から助かりました。
つまり、NotebookLMは「自分が把握している世界の中で漏れなく整理する」のが上手で、Deep Researchは「自分が知らない外側の議論まで巡回する」のが上手です。同じ問いでも、得られる視点が違います。
結論として落ち着いた使い分け方
2週間運用してみて、自分の中では次の使い分けに落ち着きました。
- 公式ドキュメントのPDF・自分の過去メモ・GitHubの
Package.swiftを取り込んで「ソースを横断する」調査 → NotebookLM - 公式ドキュメントの外側、GitHub IssueやStackOverflowを含めた「世界の最新議論を辿る」調査 → Deep Research
- 設計判断の最後の一押しがほしいとき → 両方の回答を並べて、自分の判断を一行添える
両方を併用する手間はありますが、「自分の判断を一行添える」を続けると、調査ノートそのものが移行作業のチェックリストに育ちます。私の場合、移行完了までに80行ほどのチェックリストが自然に積み上がりました。これはAIではなく自分で書いた一行が積み重なったもので、最後の意思決定の根拠として残っています。
SPM 移行後に2つを残すかどうか
SPM移行そのものは5月後半でひと段落しましたが、NotebookLMとDeep Researchのセットはそのまま運用に残すことにしました。今後Firebase iOS SDKのメジャーアップデートや、AdMob mediationアダプタの追加対応が来るたびに、同じ並行運用が役に立ちそうだからです。
両家の祖父が宮大工だった影響なのか、私は「丁寧に組み上げたものは長く持つ」という感覚を強く持っています。コードベースだけではなく、調査ノートも同じだと感じています。NotebookLMとDeep Researchを併用したことで、これまで自分の頭の中にあった暗黙の知識が、目に見えるソース集とレポートとして残りました。次の移行作業のときに、過去の自分が書いたメモをNotebookLMに放り込めば、また調査のスタートラインを少し前に置けるはずです。
Firebase周りの移行作業を控えている個人開発者の方には、片方だけではなく、両者を同じ問いに並行で投げる運用を一度試してみることを推奨します。最初の数問は「同じ答えしか返ってこないな」と感じるかもしれませんが、4〜5問続けるあたりから、両者の役割分担が自然と見えてきます。