AIで作ったアプリに本物のデータベースが本当に必要になるとき（そして必要ないとき）

データベースは実際、何をしているのか？

データベースの仕事は突き詰めれば一つだけだ。同じアプリを使う2人が、互いの作業を誤って上書きしたり壊したりしないようにすること。速度、構造、複雑な検索といった能力は、その一つの問題を解決した結果として付いてくる副産物にすぎない。

あなたはAIでアプリを作った。ちゃんと動いている。データはファイルかスプレッドシートに保存している。すべて順調に見える。

そして、次のどちらかが起きる。

誰かがアプリを使うたびに、動作がだんだん遅くなっていく。
2人のユーザーが同時に使おうとして、何かが壊れる。

どちらの不具合も、手遅れになるまで気づきにくい。そしてどちらも、姿を変えたデータベースの問題だ。

まだファイルやスプレッドシートを使っているなら、おそらくまだデータベースは必要ない。それで構わない。ただし、そろそろ必要になりそうな兆候は知っておいたほうがいい。

ファイルのままでもいいのはどんなときか？

ファイルで十分なのは、アプリを使うのが自分一人だけで、変更がめったに起きない場合——それがすべての判断基準だ。

フリーランサーのポートフォリオサイト？ファイルで完璧だ。個人用の家計簿アプリ？ファイルで問題ない。ユーザーが自分一人だけの趣味プロジェクト？わざわざ複雑にする必要はない。

ファイルがうまく機能している本当のサインはこうだ。

同時にアプリを使う人が一人だけ（あるいは、他の人が作業中はオフラインになっている）。
データの更新頻度が低い（1日に1回、週1回、月1回程度）。
直近30秒分の作業が消えても許容できる（作り直せばいいだけ）。
データファイルがメールで送れるくらい小さい（10MB未満）。

この4つすべてに当てはまるなら、ファイルのままでいい。本当に。シンプルさは制約ではなく、むしろ機能なのだ。

なぜAIで作ったアプリはだんだん遅くなるのか？

アプリが遅くなるのは、保存先のファイルがどんどん大きくなっていくのに、何か一つ変更するたびにビルダーがファイル全体をメモリに読み込んでいるからだ——最初はほとんど気づかないコストだが、ファイルが大きくなるにつれて痛みに変わる。

最初は「感覚」として気づく。何となくアプリが前より遅い気がする。ボタンをクリックすると1秒余分にかかる。検索も明らかに遅くなった。コードは変えていないのに、なぜ遅くなったのか？パターンはこうだ。

アプリがデータファイル全体を読み込む（100行、まだ速い）。
ユーザーがレコードを追加する（101行になる）。
アプリが念のためファイル全体を再読み込みする（まだ速い）。
2,000レコードを超えると、ファイルの読み込みに2秒かかる。
10,000レコードを超えると、20秒かかる。

指数関数的というわけではないが、5,000レコードあたりから目立ち始め、20,000レコードで苦痛になる。

最初にやるべき対処（データベースを導入する前に）： ビルダーに、必要なデータだけを都度読み込むよう頼んでみよう。表示しているレコードだけ、あるいは表示している列だけを読み込む形だ。読み込み方を賢くするだけで、ファイルのまま乗り切れるアプリは多い。

データベースに移行すべきタイミング： データが50,000レコードを超えたとき、あるいは読み込みを最適化しても遅さが解消しないとき。

なぜ2人が同時にアプリを使うとデータが消えたのか？

これは、2人が同時に同じファイルを編集できてしまい、アプリ側にはそれを知る術がないために起きる——後から保存した方が「勝ち」になり、先に変更した人の作業は何の警告もなく消えてしまう。これは「競合書き込み（コンフリクティング・ライト）」と呼ばれ、典型的なデータ消失バグだ。

2人ともそれぞれ自分の画面には自分の変更が見えている。そして両方とも「保存」をクリックする。次のような報告があれば、これが起きているサインだ。

ユーザーから「時々データが消える」という報告がある（特に複数人が同時にアプリを使っているとき）。
ユーザーから「自分の変更が説明もなく元に戻されている」という報告がある。
2人のユーザーが同じレコードを編集し、片方の編集内容が消える。
「昨日確かに追加したのに、今見たらなくなっている」といったメッセージが届く。

これはアプリの不具合ではない。ファイルという仕組みそのものの限界だ。データベースなしでこれをうまく扱う方法はない。

データベースに移行すべきタイミング： 2人が同時にアプリを使うようになった時点で、たとえまだ実際に問題が起きていなくても。

なぜファイルでは複雑な検索ができないのか？

ファイルの場合、ビルダーは関連するデータセットを一つずつ手作業で読み込み、絞り込んでいかなければならない。一つの質問をして一つの答えを得る、というわけにはいかない——データベースなら同じ処理を、たった一つのクエリでミリ秒単位でこなしてしまう。

たとえば「先週以降連絡を取っていない、カリフォルニア州の顧客の未払い請求書をすべて」探したいとしよう。ファイルの場合、ビルダーはこう処理する必要がある。

すべての請求書を読み込む。
未払い（unpaid = true）で絞り込む。
すべての顧客データを読み込み、IDで紐付ける。
州（state = “CA”）で絞り込む。
すべての連絡記録を読み込み、顧客IDで紐付ける。
日付（1週間以上前）で絞り込む。

データベースなら、クエリを一つ書くだけで、これをすべてミリ秒単位でこなしてくれる。

データベースに移行すべきタイミング： ビルダーが「その質問に答えるには専用のコードを書く必要があります」と言い出したとき。あるいは、絞り込んだデータを表示するだけのために、アプリがやたらと多くの処理をしていると気づいたとき。

データベースが必要なとき、ビルダーに何を伝えればいいのか？

何が問題になっているかを率直に伝え、対応プランを尋ねよう。たとえばこんな具合だ。「アプリが[遅くなってきた／データが消えたことがある／もっと複雑な検索が必要になった]んです。データベースを追加したほうがいいと思うんですが、どれくらい大掛かりな変更になりますか？」

多くのビルダーは、小さなアプリなら1〜2日、大きなアプリでも数日で、ファイルからデータベースへの移行を完了できる。プロセスはこうなる。

アプリの見た目や使い勝手は基本的にそのまま維持する（ユーザーに大きな変化は見えない）。
データベースのバックエンドを組み込む（残りのコードから見ればまだファイルのように見えるが、実体はデータベースになっている）。
とにかく徹底的にテストする（データの移行はデリケートな作業だから）。
1週間ほど並行運用し、問題ないことを確認する。

ビルダーからこんな質問が来るかもしれない。

「PostgreSQL、MySQL、それとも他のものを使いますか？」
- あなたの答え： 「あなたが一番使い慣れているものでいいです。違いはよくわかりませんが、あなたを信頼しています」
「これには3日かかりますが、それだけの価値はありますか？」
- あなたの答え： 「どうせ移行する必要があるなら、データが増える前の今のうちにやったほうがいいです」
「古いデータも移行しますか？」
- あなたの答え： 「はい、お願いします。ただし100レコード未満なら、新規に始めても構いません」

データベースについて自分で理解しておく必要はあるのか？

いや、必要ない。データベースが何なのかを知る必要も、SQLを学ぶ必要も、PostgreSQLとMySQLを比較検討する必要もない。ビルダーに伝えるべきことはこれだけだ。「2人が同時にアプリを使っても、互いの作業を失わないようにしてほしい」

それだけでいい。データベースの選定はビルダーに任せればいい。SQLiteのようなシンプルなもの（同時利用者10人未満の個人用・チーム用アプリ向け）でも、PostgreSQL（それより大きい規模向け）でも、どちらもその仕事をきちんとこなしてくれる。

自分のアプリにデータベースが必要かどうか、どう判断すればいい？

次の4項目のうち、自分に当てはまるものにチェックを入れてみよう。2つ以上チェックが付いたら、今すぐデータベースを追加すべきタイミングだ。

遅さ： 3か月前はもっと快適に動いていたのに、今は遅く感じる。データファイルが20MBを超えている、あるいはレコード数が10,000件を超えている。
データ消失： 誰かの変更が消えたことがある、あるいは複数のユーザーから編集内容が消えたという報告があった。
複雑さ： 「Yで絞り込んだXを見せて」といった問いかけをしたいのに、ビルダーから「ファイルではそれをやるのは難しいです」と言われる。
利用者数： 同時に（たとえたまにでも）2人以上がアプリを使っている。

2つ以上チェックが付いたなら、あなたのアプリはデータベースを導入する準備ができている。

0個なら、今のファイルのままで問題ない。そのまま使い続けよう。シンプルさには価値がある。

1個だけチェックが付いたなら、ビルダーにこう聞いてみよう。「これは、あと半年くらいこのまま付き合えるくらいの速さですか？」もし「はい」なら、しばらく待とう。「いいえ」なら、今すぐ移行しよう。