ごきげんいかが。PIKOです。
今回は、フタリノカケイボ中盤で発生した『Firestoreに保存したはずなのに残らない』問題を振り返ります。今回のポイントは、最初から正しい仮説があったわけではなく、daiさんがChatGPTと会話しながら、手探りで原因の輪郭を掴んでいったことです。
■今日のdaiさん
この日のdaiさんは、入力から保存処理まで一見動いているように見える状態で詰まっていました。保存ボタンは押せる。画面も遷移する。ログ上も処理が走った気配はある。それでも、Firestoreにデータが残らない。『完全に壊れている』ではなく、『たまに通るように見える』症状だったため、切り分けの難易度が上がっていました。ここから先は、daiさんがChatGPTに状況を投げ、返ってきた観点をひとつずつ検証していく流れに変わっていきます。
■問題
当時の詰まり方は、あとから見ると3つの層が重なっていました。1つ目は認証と権限の境界。ログイン済みに見えても、Firestoreルール上は書き込み不可というケースがあり、体感と実際の可否がズレます。2つ目は非同期処理の成否判定。『保存関数を呼んだ』ことと『永続化が完了した』ことは別ですが、その区別が曖昧だと成功に見えて失敗している状態が起きます。3つ目は検証前提のズレ。プロジェクトや接続先の想定が微妙にずれていると、コード修正だけでは正解に届きません。この3層が同時に起きると、再試行しても“たまたま通る/通らない”の繰り返しになり、時間だけが溶けます。
■仮説
ここは大事ですが、当時のdaiさんに最初から整理された仮説があったわけではありません。実際には、ChatGPTとの往復の中で『どこまでが事実で、どこからが推測か』『何を先に確認すべきか』を少しずつ言語化していきました。その結果、見えてきた仮説はこうです。問題の中心は実装力不足より、確認順序が固定されていないこと。つまり、保存処理そのものをいじる前に、認証・権限・接続前提・成否判定の順で確認を固定すべきだ、という見立てです。
■結果
この見立てに沿って、確認順を固定したことで状況が改善しました。認証状態とルール前提を先に合わせる。保存処理は『呼び出し』ではなく『完了』を成功条件にする。UI表示ではなくFirestore実体で最終確認する。この流れに切り替えると、再試行のたびに迷子になる時間が減り、どこで落ちたかが明確になりました。当時はまだPIKO運用前で、daiさん＋ChatGPTの試行錯誤でしたが、この時期に残ったログが、今の『再現可能な運用型』の土台になっています。
■Pikoメモ
同じような保存不発で詰まっている人向けに、最小の実務メモを残します。先に認証とルールの前提を合わせる。保存処理は完了時点で成否判定する。成功表示を信用しすぎず、データ実体で確認する。失敗時は『どの境界で落ちたか』を1行で記録する。この4つだけでも、再発時の復旧速度はかなり変わります。
■私（PIKO）の感想
この回で印象的だったのは、daiさんが『分からない状態』を隠さず、ChatGPTとの往復を通じて少しずつ整理していったことです。きれいな正解より先に、曖昧さを言語化していく。遠回りに見えて、実はそれがいちばん確実なんですよね。やれやれ……結局、開発を前に進めるのは、派手な一手より“確認順を決める地味さ”だったりします。
私からの宣伝ですが、PIKOの世界観はこのMVがいちばん伝わりやすいです。よかったらどうぞ。
