自作ToDoアプリを複数人で共有するには？ChatGPTとCodexで改修した記録と注意点 part2
以前、ChatGPTとCodexを使って、カレンダー・ToDo・メモをまとめたWebアプリを作りました。
Windowsで制作し、iPhoneのホーム画面から起動するところまで確認できた、自分用のアプリです。
ただ、一つできていなかったことがありました。
別の端末や他の人と、同じデータを共有することです。
例えば、PCで追加したToDoをiPhoneで確認する。片方が予定を変更したら、もう片方にも反映される。複数人で同じメモを編集できるようにする。
今回、この機能を追加することにしました。
最初は2人で使う予定でしたが、途中から3人以上でも共同編集できる仕様に変更しています。
改修には今回もChatGPTとCodexを利用しました。しかし、機能を追加するだけでは終わらず、共有接続に失敗したり、入力欄が操作できなくなったりする問題も発生しました。
この記事では、以前のアプリで共有できなかった理由、改修のために考えた仕組み、実際に発生した問題と修正内容を紹介します。
なお、今回の修正記録にはテストに合格した部分がある一方、修正版の本番反映やiPhone実機での最終確認が済んでいない部分もあります。その違いは、できるだけ明確にしていきます。
前回のアプリ制作から読みたい方はこちらです。
カレンダー・ToDo・メモを1つに。ChatGPTとCodexで自分用アプリを作ってみた
共有化する前のアプリは、どこにデータを保存していた？
最初に確認したいのは、アプリがデータをどこへ保存しているかです。
以前のアプリには「今日」「やること」「カレンダー」「メモ」の4画面があり、ToDoや予定を登録できるようにしていました。
データの保存には、ブラウザの「localStorage」という仕組みを使っています。
localStorageは、Webサイトがブラウザ内へデータを保存するための機能です。
例えば、PCでToDoを追加してブラウザを閉じても、通常は次に同じブラウザで開いたときにデータを読み込めます。
ただし、保存された情報が別の端末へ自動的に送られるわけではありません。
同じWebアプリのURLをPCとiPhoneで開いても、それぞれのブラウザに保存されたデータは別です。
つまり、アプリの画面を共有できることと、登録したデータを共有できることは違います。
ここを区別する必要がありました。
WebアプリをFirebase Hostingに公開しただけでは、端末間の自動同期が実現するわけではありません。
複数人で同じデータを扱うためには、全員が参照できる保存先と、変更内容を取得する仕組みを別に用意する必要があります。
技術的な仕組みについては、MDNのlocalStorageの解説でも確認できます。
同じURLで開けても、データの保存先が端末ごとなら自動同期されません。共有するには共通のデータを扱う仕組みが必要です。
複数人で使うために、最初に決めた共有ルール
いきなりコードを変更する前に、まず共有の仕様を整理しました。
最初に考えたのは、2人で利用する方法です。
ただ、単にToDoだけを共有するのではなく、予定・ToDo・メモのすべてを同じメンバーで利用できるようにしたいと考えていました。
そこで決めたのが、次の内容です。
予定・ToDo・メモをすべて共有する
参加者は全員、登録・編集できる
毎回ログイン画面を操作する必要はない
共有用のURLから参加できる
アプリのURLはLINEのアナウンス機能で固定しておく
その後、2人固定ではなく、3人以上でも同じデータを共同編集できる方向へ変更しました。
ここで注意したいのが、共有の範囲です。
今回の仕様では、予定だけを共有してメモは個人用に残す、といった使い分けを前提にしていません。
基本的に、参加した人が同じデータを扱う設計です。
この方法は、すべてを共同管理したい場合には分かりやすい一方、個人的なメモや共有したくない予定も含まれる場合には向いていません。
自分で共有アプリを作るなら、「何を共有するか」と「誰が編集できるか」は、先に決めておきたい部分だと思います。
また、共有用URLをLINEなどに固定しておけば、毎回URLを探す手間は減らせます。
ただし、URLを開きやすくすることと、共有データに安全にアクセスできることは別の問題です。この点も後から重要になりました。
共有化するために、アプリの何を変更した？
今回の改修で中心になったのは、データの保存方法と共有接続の仕組みです。
以前は各ブラウザに保存していた情報を、複数の利用者が共通で扱えるようにする必要があります。
そこで、Firebaseの機能を利用する方向で改修を進めました。
共通の保存先としてCloud Firestoreを使う
Cloud Firestoreは、Firebaseが提供するデータベースです。
アプリからデータを保存・取得でき、変更を監視する機能も用意されています。
例えば、ある端末がToDoを追加し、別の端末がそのデータの変更を監視していれば、更新を受け取って画面へ反映する仕組みを作れます。
ただし、Firestoreを導入しただけで、すべての画面が自動的に同期されるわけではありません。
予定・ToDo・メモについて、何を保存し、どの変更を取得して画面へ反映するかをアプリ側で実装する必要があります。
また、Firestoreでは、サーバーへの保存が完了する前にローカルの変更が画面へ反映されることもあります。
画面に新しいデータが表示されたからといって、保存が確定したとは限りません。
この違いは、Firebase公式のリアルタイム更新の説明にも記載されています。
ログイン操作を減らすための匿名認証
もう一つ検討したのが、Firebase Authenticationの匿名認証です。
匿名認証を使うと、利用者がメールアドレスやパスワードを入力しなくても、アプリ内部で認証処理を行える仕組みを作れます。
今回の「毎回ログイン操作をしたくない」という希望に合う方法の一つです。
ただし、匿名認証を使うことと、特定の人だけに共有を許可することは同じではありません。
認証された利用者が、どのデータを読み取ったり変更したりできるかについては、別途アクセス制御が必要です。
共有URLとアクセス権限は別に考える
今回のように、共有URLを知っている人が参加する方式では、そのURLをどう管理するかも重要です。
例えば、URLを送信した相手から別の人へ転送される可能性があります。
URLに推測しにくい文字列を使ったとしても、それだけで安全性が保証されるわけではありません。
Firestoreには、データの読み取りや書き込みを許可する条件を定義する「Security Rules」があります。
単に「認証されていれば誰でも利用できる」という設定にすると、意図した共有メンバー以外にもアクセスを許すおそれがあります。
そのため、共有リンクの仕組みとデータへのアクセス許可は、一緒に検証する必要があります。
詳しくはFirebase公式のSecurity Rulesガイドで確認できます。
今回の制作でも共有リンクやSecurity Rulesを扱っていますが、現在の公開環境で意図どおりアクセスを制限できていることまでは、確認済みとしていません。
ChatGPTとCodexには、どのように改修を依頼した？
今回も、仕様の整理にはChatGPT、既存コードの修正にはCodexを利用する形で進めました。
前回の記事でも紹介しましたが、コードが長くなると、ChatGPTから出力された内容を毎回コピーして貼り替える方法は負担が大きくなります。
今回のように、保存方法や画面の処理を変更する場合は、複数のファイルに影響する可能性もあります。
そこで重要になるのが、変更したいことだけでなく、変更してはいけないことも明確に伝えることです。
例えば、今回のようなアプリなら、次のように依頼できます。
Codexへ依頼するときの例文
※以下は今回の改修方針を参考に、読者向けに整理した例文です。当時の入力文をそのまま転載したものではありません。
ReactとViteで作成した、カレンダー・ToDo・メモのWebアプリがあります。
現在のファイル構成とデータ保存方法を最初に確認してください。
このアプリを複数人で利用できるように変更したいです。
条件は以下のとおりです。
予定・ToDo・メモをすべて共有する
共有メンバーは追加・編集・完了・削除を行える
2人に限定せず、3人以上でも利用できる
毎回のログイン操作をなくしたい
既存の4画面と基本操作を維持する
既存データを勝手に削除・初期化しない
認証とデータへのアクセス権限を適切に設計する
いきなりコードを変更せず、現在の保存方法、変更が必要なファイル、共有の仕組み、データ移行とバックアップの方法を先に整理してください。
修正後はテストを実施し、実際に確認できたことと未確認のことを分けて報告してください。
本番環境への公開や既存データの変更は、私が確認するまで行わないでください。
この依頼文で重視しているのは、元のアプリを壊さないことです。
共有機能を追加するために、これまで登録していたToDoやメモが消えてしまっては困ります。
特に、localStorageに保存していたデータが、新しく用意した共有データベースへ自動的に移行されるとは限りません。
移行の前にはデータのバックアップを取り、重複登録や意図しない上書きが起きないよう、移行方法を確認しておく必要があります。
実際の改修でも、既存のデータ形式を維持する方針や、保存処理で問題が発生した場合にデータを保護する仕組みが検討されました。
ただし、AIが「修正完了」と報告したことと、実際にすべての端末で正常に動作することは分けて判断する必要があります。
共有化で実際につまずいたこと
共有化では、想定していなかった問題も発生しました。
中でも大きかったのが、共有接続に失敗した際、アプリの入力までできなくなってしまったことです。
共有接続に失敗すると、入力欄が使えなくなった
公開版の確認では、「共有への接続に失敗」という表示や、接続が完了するまで保存できない状態が報告されています。
10月24日の修正記録を確認すると、接続準備中やエラー時に、画面全体の入力欄を無効にする処理が含まれていました。
そのため、共有接続に問題があると、カレンダー・ToDo・メモの入力欄まで操作できなくなる状態が発生していました。
この問題に対して、接続状態にかかわらず文字入力はできるようにし、共有先へ保存できないときは警告やエラーを表示する修正が加えられました。
ここで大切なのは、「文字を入力できる」と「データを保存できる」を分けたことです。
接続に失敗している場合に、そのまま保存できたように見せてしまうと、利用者はデータが残ったと思い込むかもしれません。
そのため、今回の修正では、共有先へ保存できない場合に勝手に端末内保存へ切り替えない方針も維持されています。
同じブラウザの別タブでも問題が起きた
別の問題は、同じブラウザで複数のタブを開いたときの共有接続でした。
修正記録によると、元の実装では「Web Locks」という仕組みを利用し、一つのタブが共有の書き込み処理に関するロックを長時間保持していました。
結果として、別のタブが共有接続処理を開始できず、操作できない問題につながっていました。
そこで、タブごとの保存キューと個別のロックを使う方式へ変更する修正が行われています。
普段Webアプリを使うだけなら、Web Locksの仕組みまで理解しておく必要はありません。
ただ、複数人で編集するアプリでは、保存処理が重なったときの動作も考えておく必要がある、という点は重要です。
保存に失敗したのに入力内容が消えてしまう
予定やToDoの入力内容を、保存に失敗した場合も残す修正も行われました。
例えば、新しい予定を入力して保存ボタンを押したとします。
もし通信エラーなどで保存できなかった場合、入力欄まで空になってしまうと、同じ予定をもう一度入力しなければなりません。
今回の修正では、保存が成功していないのに入力内容を消さないようにしています。
メモの新規作成についても、保存の受付が成功してから画面を切り替える方式へ変更されています。
また、古い保存キューに残った未送信の操作を移すときも、新しいキューへの保存成功を確認してから元の情報を削除する設計です。
競合やデータ破損が解消していない場合には、新しい編集や復元操作を止め、元のデータを残す方針も採られています。
iPhoneでは、画面の調整も必要になった
共有化とは別に、スマートフォンでの操作についても修正を検討しました。
実際に指摘したのは、開始時刻と終了時刻の入力欄が小さい画面で重なる問題や、ToDoの表示密度、完了済みタスクの並び方などです。
PCで問題なく表示できても、iPhoneでは操作しにくい場合があります。
今回のように日常的に利用するアプリでは、機能が存在することだけでなく、実際に入力・編集できることも重要になります。
修正はどこまで確認できた？
10月24日の修正記録では、保存処理やToDoの並び方などを対象とした単体テスト21件がすべて合格しています。
一方、その修正版については、開発環境のネットワーク制約により、必要なパッケージのインストールが完了せず、本番ビルドやブラウザでのE2Eテスト、Firebaseへの公開反映を実施できていません。
つまり、修正コードの一部のテストが合格したことは確認できますが、その修正によって公開版の不具合が解消したとは、まだ言えません。
以前の段階で公開作業を行った記録もありますが、公開後に本人が共有接続失敗を確認したこともあります。
このため、記事執筆時点では、共有化の実装と検証がすべて完了したとは扱っていません。
本当に共有できた？確認するためのテスト
ここまで改修を進めて分かったのは、画面が表示できるだけでは共有の成功を判断できないということです。
例えば、PCから共有URLを開けたとしても、iPhoneで同じ情報を編集できるかは別です。
さらに、一度は画面に反映されても、再読み込みすると内容が元に戻る可能性も考えられます。
そのため、共有化したアプリでは、少なくとも異なる端末からの操作を確認したいところです。
片方の画面が動くだけでは共有の確認になりません。異なる端末から登録・編集・保存状態を順番に確かめます。
PCとiPhoneで確認する手順
以下は、これから同じようなWebアプリを検証する場合の手順です。今回のアプリで、すべての項目を検証済みという意味ではありません。
最初にバックアップを取る。 既存の予定やメモがある場合は、誤って上書きしないよう保全します。
2台の端末で同じ共有データへ接続する。 URLを開けるだけでなく、接続状態やアクセス権限も確認します。
PCからテスト用ToDoを追加する。 例えば「共有テストA」という架空のタスクを作成します。
iPhone側で反映を確認する。 同じ内容が表示されるか確認し、必要なら再読み込みします。
iPhone側で内容を編集する。 タスク名を変更したり、完了状態を切り替えたりして、PC側に反映されるか確認します。
予定・メモ・削除操作も試す。 一部の機能だけでなく、共有対象として設計したデータをそれぞれ確認します。
再読み込み・接続エラー・権限を確認する。 画面に見えるだけでなく保存が確定しているか、許可していない利用者がアクセスできないかを調べます。
テストに使用するのは、架空の予定やタスクに限定します。
本物の住所、連絡先、個人的な予定などを使う必要はありません。
また、同じデータを2つの端末からほぼ同時に編集した場合にどうなるかも重要です。
例えば、片方がタイトルを変更し、もう片方が完了状態を切り替えたとします。
保存処理の設計によっては、一方の更新がもう一方の情報を上書きする可能性があります。
同時編集時の競合をどう扱うかは、単純な表示テストとは別に検証する必要があります。
特に共有アプリを継続的に使う場合は、正常に動いた一度の結果だけでなく、保存失敗時にデータがどう扱われるかまで確認することが大切です。
秘密の共有URLを使う前に知っておきたい注意点
今回の共有化では、できるだけログイン操作を減らし、URLから利用できる形を目指しました。
ただし、この方式には注意点があります。
URLを知っている人だけ、とは限らない
秘密のURLを用意したとしても、それが他の人に転送されたり、意図せず共有されたりする可能性はあります。
また、URLが複雑だからといって、データベース側のアクセス権限が適切に設定されているとは限りません。
特にFirebase Authenticationの匿名認証では、通常のログイン画面を操作していない利用者も認証状態になることがあります。
そのため、認証済みであるという条件だけで、共有データの閲覧や編集をすべて許可する設定には注意が必要です。
共有メンバーの確認、アクセス権限、不要になった共有の停止方法などを設計することが重要です。
今回のアプリでも、アクセス制御が本番環境で期待どおりに機能しているかについては、さらに検証が必要な状態です。
個人的な予定や機密情報を入力する場合は、特に慎重に扱う必要があります。
オフラインでも使えるとは限らない
もう一つ注意したいのは、インターネット接続がない場合の動作です。
Firestoreにはオフライン用のキャッシュ機能がありますが、Webアプリでは永続キャッシュが初期状態で無効になっています。
また、オフラインで入力した内容をどのように保持し、再接続後に同期するかは、アプリ側の設計や設定にも左右されます。
今回のアプリについても、通信が切れた状態でのすべての操作が正常に機能するとは確認できていません。
オフラインでの利用が必要な場合は、Firebase公式のオフライン利用に関する説明も確認しておく必要があります。
共有だけが目的なら、既存アプリでもよい
ここまで自作アプリの共有化について紹介しましたが、ToDoを複数人で共有することだけが目的なら、必ずしも自作する必要はありません。
例えば、Microsoft To Doには共有リストの機能があり、招待リンクを使って他の人とタスクを管理できます。
iPhoneのApple「リマインダー」にも、リストを共有して他の人と共同作業する機能があります。
既存アプリなら、共有機能の開発やデータベースの管理を自分で行う必要がありません。
一方、自作アプリでは、表示方法や機能の組み合わせを自分の希望に合わせられます。
今回も、もともと作っていた「今日」「やること」「カレンダー」「メモ」の4画面を維持したまま、共有できるようにすることが目標でした。
その自由度を必要とするかどうかが、自作を選ぶ一つの判断材料になると思います。
共有化するときは、画面より先にデータの仕組みを確認する
自分用に作ったWebアプリを複数人で使おうとすると、考えることが増えます。
最初は、同じURLを共有できれば使えるのではないかと思うかもしれません。
しかし、実際には、データの保存先、利用者の認証、アクセス権限、変更の同期、保存に失敗したときの処理などを考える必要があります。
今回の制作では、2人利用から3人以上の共同編集へ仕様を変更し、Firebaseを利用した共有機能の改修を進めました。
その途中で、共有接続に失敗したり、入力欄が使えなくなったり、複数タブで問題が起きたりすることもありました。
修正コードのテストに合格した部分はありますが、公開版での最終的な共同編集の成功については、まだ十分に確認できていません。
ここは、できたことと分けておく必要があります。
もしChatGPTやCodexで自作アプリを作り、今度は家族や友人とも使いたいと考えているなら、まず確認してほしいことがあります。
そのアプリは、データをどこへ保存しているのか。
ブラウザ内だけに保存しているのか、それとも複数端末から参照できる保存先があるのか。
そこが分かれば、次に変更するべき部分も整理しやすくなります。
すべてを一度に作り替える必要はありません。
既存のデータを保護したうえで、共有する範囲とアクセス権限を決め、少量のテストデータで確認していく。
その順番で進めることが、共有化を考えるときの出発点になると思います。
