完成していたアプリを、公開の前にほぼ作り直した判断の記録

旧版はFlutterで約3,700行あり、返信を考えるための主要機能はひと通り動いていました。画面を触るだけなら完成に近く見えます。しかし、公開前の確認で見えてきたのは、機能の不足ではなく、出荷後の運用に耐えない土台でした。

AIのAPIキーをアプリへ同梱していたこと、課金状態や無料回数を端末側の値で判定していたこと、開発用とリリース用の設定が十分に分かれていなかったこと。どれもデモでは見えにくい一方、実際に配布すれば不正利用、想定外の課金判定、障害調査の難しさにつながります。

さらに、メイン画面は約1,760行、生成画面も約1,000行ありました。表示、状態管理、API呼び出し、課金判定が同じ場所へ集まり、ひとつ直すたびに別の機能へ影響しやすい状態でした。完成していたのは目に見える操作であって、サービスとしての運用ではありませんでした。

最初は、危険な箇所だけを順番に直すつもりでした。APIキーをサーバー側へ移し、課金判定を直し、大きな画面を少しずつ分割すればよいように思えます。部分修正なら、すでに動く画面を残せるため、短期的には速く見えます。

しかし、修正対象は互いにつながっていました。生成処理の移動は認証と利用回数に影響し、課金判定の変更は画面状態とエラー表示に影響します。大きな画面を残したまま責務だけを抜き取ると、新旧の経路が混在し、かえって確認範囲が増えます。

判断材料になったのは、既存利用者がまだいなかったことです。データ移行や旧版との互換性を守らず、構造を変えられる最後の時期でした。公開を一度急いでから大規模移行をするより、公開前に止まり、同じ仕様を新しい土台へ移すほうが総コストは低いと判断しました。

実際に使って練られていたものまでゼロに戻す必要はありませんでした。返信を3案出すこと、トーンと文章量を組み合わせること、相手ごとに履歴を持つこと、話題を提案すること。これらはユーザーが受け取る価値なので残しました。

• 返信案は3つから選べる形を維持する
• 相手ごとの履歴とメモは持ち越す
• 生成時のトーンと文章量の考え方は残す
• APIキー・無料枠・課金判定は端末の外へ移す
• 画面から通信や永続化の責務を分離する

逆に、画面の都合に引っ張られた状態管理、複数の場所に散った判定、端末だけを信頼する仕組みは捨てました。作り直しは、過去の実装を否定する作業ではありません。体験として残すものと、これからの変更を邪魔する実装を切り分ける作業でした。

旧版は、返信生成、話題提案、定型文などの機能ごとに入口があり、利用者がタブを行き来する構成でした。機能を説明するには分かりやすい一方、実際の利用場面では「どの機能を使うか」より「誰に返信するか」が先にあります。

新しいResuruでは、相手と会話履歴をひとつのスレッドとして扱います。相手を選べば、前回の流れを見ながら返信を考えられます。機能名を覚えてもらうのではなく、会話の続きを始めるだけで必要な機能へ届く構造に変えました。

この変更で、データ構造も画面構造も「機能単位」から「会話単位」へ揃いました。見た目だけを変えるのではなく、利用者が考える順番と、アプリ内部が情報を扱う順番を同じにしたことが、全面刷新の中で最も大きな変更でした。

Resuruを開く目的は、Resuruそのものを眺めることではありません。返信を作って、元のメッセージアプリへ戻ることです。滞在時間を伸ばすより、迷っている時間を短くするほうが、このプロダクトでは価値になります。

そこで、アプリ内のスレッドだけでなく、会話スクリーンショットの共有とキーボードからも同じ生成機能へ入れるようにしました。返信をじっくり考えるときはアプリ、今いる画面から離れたくないときはキーボードというように、状況に応じて入口を選べます。

キーボード拡張にはフルアクセスの説明など、通常の画面とは違う配慮も必要です。設計時に確認した内容は「フルアクセスを許可」が怖い。Resuruのキーボードが何をするかに、会話データを端末側へ置く判断は会話をサーバーに置かないと決めた。Resuruのデータ設計と機種変更に分けてまとめています。

全面刷新を始めると、せっかくなので新機能も入れたくなります。しかし、新しい要件まで同時に足すと、移植の不具合と新機能の不具合を切り分けにくくなります。そこで最初の目標を「旧版で価値が確認できた体験を、安全な構造で再現すること」に限定しました。

画面を美しくする変更も、構造の確認を終えてから進めました。先に通信、保存、認証、課金の境界を作り、その上に既存の体験を戻します。途中で発見した改善案はその場で全部実装せず、別の課題として残しました。

コードが整理されても、実際の利用経路を確認しなければ安心とは言えません。アプリ単体、共有からの起動、キーボード、通信失敗、未ログイン、利用回数の境界など、入口と状態の組み合わせを洗い出しました。

とくに、正常時だけでなく失敗時の戻り方を確認します。AIから返事が来ない、ネットワークが切れる、権限が足りないといった場面で、入力内容を失わず、次に何をすればよいか分かるかを見ます。公開後に直し続けられる構造とは、変更しやすいコードだけでなく、壊れ方を確認できる状態でもあります。

一度にすべてを自動化できなくても、公開前のチェック項目として残せば次の更新にも使えます。完成を「画面が動いた瞬間」ではなく、「主要な利用経路と失敗時の挙動を説明できる状態」と捉え直しました。

確認結果は、その場の記憶だけで終わらせません。どの入口から、どの状態で、何を確認したかを残します。次の更新で同じ画面を触ったとき、前回の確認を再利用できるからです。個人開発では確認担当を別に置けないため、未来の自分が迷わず同じ経路を試せることが、品質を保つ助けになります。

目の前の問題だけを直せば、もっと早く一度は公開できたかもしれません。ただし、APIキー、課金、拡張機能、端末内データ、画面構造が互いに絡んだ状態で修正を重ねれば、公開後により高いコストを払うことになります。

作り直している期間は、進んでいないようにも見えました。完成済みの画面を捨て、同じ機能をもう一度作るからです。それでも、新しい土台では修正箇所と影響範囲を説明しやすくなり、次の機能を足す前にどこを確認すべきかも明確になりました。

「もう動いているから残す」ではなく、「これから直し続けられるか」で残すものを決める。 Resuruを作り直して、一番大きく変わった判断基準です。完成に見える段階でも、利用者へ渡した後の運用を想像すると、止まって作り直すほうが早い場合があります。

もちろん、すべてのアプリで全面刷新が正解になるわけではありません。既存利用者のデータ、移行手段、止められる期間、問題の局所性によっては段階的な修正のほうが安全です。今回は公開前で、問題が複数の層へまたがり、守るべき体験が明確だったから選べた方法でした。作り直すこと自体ではなく、選んだ理由を説明できることが大切です。