AIでFirebase計測、20回やり直した

アプリを公開した。ダウンロード数も見られる。

それでも、「どこで人が離れたか」は何も分からなかった。

今回、Firebase Analytics（アプリ内で起きた行動を記録・分析する仕組み）をStepLockへ組み込んだ。実装には当時最新のChatGPTとCodexを使ったが、テストと修正のチャットラリーは20回を超えた。

この記事では、AIを使っても詰まった理由と、同じ作業をするときに使えるプロンプト、公開前チェックリストをまとめる。

---

公開しただけでは、何も分からなかった

StepLockは、歩いた分だけスマホを使えるAndroidアプリだ。

Google Playで一般公開したあと、学んだマーケティングの考え方を実際の数字で検証したくなった。

届いた→認知した→ダウンロードした→継続した→なくてはならない存在になった→口コミした

この流れのどこまで進んでいるのか。

Google Playの数字だけでも、ダウンロードされたことは分かる。しかし、ダウンロードした人が初期設定を終えたのか、権限設定で離脱したのか、実際にロック機能を使ったのかまでは見えない。

そこでFirebase Analyticsを導入した。

---

最初に必要だったのは、コードではなく翻訳だった

「継続した人を測りたい」とAIに伝えても、そのままでは計測できない。

“継続”という人間の言葉を、アプリ内で観測できる行動へ翻訳する必要がある。

StepLockでは、次の7種類の行動を記録する設計にした。

・初期設定を始めた

・権限設定に成功・失敗した

・初期設定を完了した

・ロック画面が表示された

・歩いて利用時間を獲得した

・獲得した時間を消費した

・主要機能でエラーが起きた

Firebaseでは、こうした一つひとつの行動記録を「イベント」と呼ぶ。

一方で、「なくてはならない存在になった」「誰かに勧めた」は、Firebaseだけでは直接測れない。

測りたいことと、実際に測れることは違う。

ここを分けないまま実装すると、数字は増える。しかし、知りたかった答えには近づかない。

---

最新AIを使っても、20回以上やり直した

アプリへ計測機能を追加するコード自体は、AIがすぐに書いてくれた。

ところが、アプリとして動かせる状態にまとめる処理が成功したあとからが長かった。開発の世界では、この処理を「ビルド」と呼ぶ。

行動記録がFirebaseへ届かない。必要な場面で記録されない。逆に、同じ行動が複数回記録される。一度しか記録したくない初期設定が、すでにアプリを使っている人でも記録されてしまう。

一つ直してテストすると、別の条件が気になる。その結果をAIへ戻し、コードを確認し、また実際のスマホで試す。

ChatGPTとCodexを駆使しても、やり取りは20回を超えた。

「アプリが動く」と「正しい数字が取れる」は別の完成条件だった。

特に難しかったのは、記録が確認できない原因の切り分けだ。

アプリ側の問題なのか。テストの手順が間違っているのか。それとも、Firebaseの画面へ数字が反映されるまで待つ必要があるのか。

AIは修正案を何個でも出せる。しかし、確認条件が曖昧なら、別の修正案を何個でも出し続ける。

---

測りたいものを、全部送ってよいわけではない

情報を細かく送るほど、分析しやすくなるように思える。

ただし、アプリの計測では、細かさがそのままプライバシー上のリスクになる。

StepLockでは、次の情報をFirebaseへ送らない設計にした。

・歩数の生の値

・正確に歩いた時刻

・制限対象に選んだアプリ名

・アプリを内部で識別するための文字列

・エラー時に表示される詳しい技術情報

・自由入力された文章

・氏名やメールアドレス

歩いて獲得した時間も、「正確に何分」という値ではなく、1分、2〜5分、6〜10分、11分以上という幅に丸めた。

エラーも詳しい内容をそのまま送らず、「歩数を検知できない」「ロック画面を表示できない」といった決められた分類だけを送る。

計測の目的は、ユーザーを細かく見ることではない。改善すべき場所を見つけることだ。

---

AABができた後、プライバシーポリシーで止まった

実装とテストが終わり、AABもできた。

AABとは、Google Playへアプリを提出するために、プログラムや画像などを一つにまとめた配布用ファイルだ。

これで終わりではなかった。

Firebaseを追加すると、外部サービスへ送信する情報が変わる。つまり、プライバシーポリシーも変えなければならない。

何を収集するのか。何のために使うのか。どこへ送信されるのか。送らない情報は何か。利用者がデータを削除できるのか。

さらに、次の三つを一致させる必要があった。

１．実際のアプリの動き

２．Google Playへ申告したデータの取扱内容

３．公開しているプライバシーポリシー

コードに「歩数は送っていない」と書かれていても、別の場所から送られていれば説明は成立しない。反対に、安全な作りでも、公開文に書かれていなければ利用者には分からない。

これはAIを使っていなければ、気づかず公開していた可能性が高い。

一方で、AIが指摘してくれたからといって、その文章をそのまま採用できるわけでもない。最終的には、実際のアプリの動きと説明文を一つずつ照合する必要があった。

---

20回のやり直しで、確認順を変えた

次に同じ作業をするなら、コードから始めない。

この順番で確認する。

何を知りたいのか

その状態を、どの行動で観測するのか

送ってはいけない情報は何か

どの操作をしたときに、何回記録するのか

実際のスマホでどう再現し、何をもって成功とするのか

アプリの動き・Google Playへの申告・プライバシーポリシーが一致しているか

Firebaseの導入は、SDKを追加するだけの作業ではなかった。

SDKとは、Firebaseとアプリを接続するためにGoogleが用意した、プログラム部品のセットだ。

Firebaseの導入は、仮説を観測できる行動へ変換する作業だった。

---

AIへそのまま渡せる計測設計プロンプト

以下の【　】だけ書き換えて使える。

【アプリの概要】へFirebase Analyticsを導入したい。目的は【知りたいユーザー行動・改善したい箇所】の把握。

コードを書く前に、次の順番で設計してほしい。

１．知りたいことを、観測できるアプリ内行動へ変換する

２．記録する行動名と、その行動に付ける補足情報を表にする

３．同じ行動の二重記録、既存ユーザーの誤記録、記録漏れが起きる条件を洗い出す

４．個人情報、自由入力、生の数値など、送信すべきでない情報を示す

５．各記録の実機テスト手順と成功条件を作る

６．Google Playへのデータ取扱申告と、プライバシーポリシーに影響する項目を示す

不明な実装は推測せず、確認すべきファイルと確認理由を先に示すこと。最後に「アプリの動き・テスト結果・公開文」の不一致を確認するチェックリストを出すこと。

---

AAB作成後の公開前チェックリスト

・Firebaseのリアルタイム確認画面で、すべての行動記録が届くことを実機確認した

・同じ操作が複数回記録されていない

・既存ユーザーの操作が、初回利用として誤記録されない

・個人情報・自由入力・加工前の細かな数値を送っていない

・エラーの詳細全文ではなく、決められた分類だけを送っている

・Google Playへ申告したデータの取扱内容を見直した

・プライバシーポリシーを更新した

・アプリの動き・Google Playへの申告・公開文が一致している

Google Playへの提出用ファイルを作ったあとも、最終版で動作確認した

今回実装したStepLockは、Google Playで公開している。