アプリにデータベースを追加する方法（後でデータを失わないために）

アプリにデータベースを追加するには、マネージドのリレーショナルデータベース（通常はPostgres）を選び、接続文字列をサーバー側のシークレットに保管し、保存する対象ごとにテーブルを1つ作り、ブラウザではなくバックエンドがデータベースを読み書きするようにします。AIアプリビルダーで作っているなら、通常は「このデータをデータベースに保存して」と頼むだけで、エージェントがテーブルとコードを用意します。あなたの仕事は、データを分かりやすく説明し、実際に保存されているかを確認することです。

このガイドでは、データベースが必要になるタイミング、主な選択肢、データの説明の仕方、そしてデータの消失や漏えいの原因になるミスを扱います。

アプリにデータベースが必要になるとき

アプリがページを閉じたあとも何かを覚えておく必要がある場合や、人どうしでデータを共有する場合にデータベースが必要です。典型的なサインは次のとおりです。

• 訪問者がフォーム、申し込み、予約、注文などを送信する
• ユーザーが、自分だけの保存済みコンテンツを持つアカウントを使う
• 管理者が、他の人が作成したものを確認または編集する必要がある
• 時間の経過とともに、レポートや件数を集計したい

ポートフォリオやシンプルなランディングページのように、誰が見ても同じ内容になる静的なサイトには不要です。データベースが何かよく分からない場合は、まずデータベースとはを読んでください。

選択肢

ほとんどの小規模から中規模のWebアプリでは、Postgresのようなリレーショナルデータベースが適切な初期選択です。リレーション（1人の顧客が複数の注文を持つなど）に強く、データの整合性を保ち、あとからSQLで質問に答えられます。平易な概要はPostgresとはを参照してください。

構築前にデータを整理する

もっとも役立つのは、アプリが保存するものと、それらのつながり方を書き出すことです。データベースの専門用語は必要ありません。予約アプリであれば次のようになります。

• 顧客: 名前、メールアドレス、電話番号
• サービス: 名前、所要時間、料金
• 予約: どの顧客か、どのサービスか、開始時刻、ステータス（保留中、確定、キャンセル）

これが3つのテーブルです。「どの顧客か」と「どのサービスか」は、テーブル同士のリンク（外部キー）になります。実際のデータがすでに入っているデータの構造を変えるのは、ページのレイアウトを変えるよりずっと大変なので、早い段階で正しく決めることが、どの技術を選ぶかよりはるかに重要です。

いくつかの基本ルールを挙げます。

• 種類ごとに1つのテーブル。 顧客の中にテキスト列で注文を詰め込まないでください。
• すべての行にIDと作成日時を持たせる。 どちらもあとで必ず必要になります。
• 適切な型を使う。 日付は日付型、金額は整数の最小単位（セント）または小数型で持ち、テキストにはしないでください。
• 必須項目は必須と明記する。 不正なデータはフォームだけでなく、データベース側でも拒否させてください。

プロンプトの例

一度にスキーマ全体を投げるのではなく、機能を1つずつ追加してください。

このアプリにデータベースを追加して。予約フォームの入力（顧客名、メール、サービス、開始時刻、ステータス）を保存するbookingsテーブルを作って（ステータスは保留中、確定、キャンセルのいずれか、初期値は保留中）。送信内容をそこに保存し、成功メッセージを表示し、新しい順に一覧表示する管理者ページを追加して。

そのあとで拡張します。

servicesテーブル（名前、所要時間（分）、料金（セント））を追加して。bookingsの自由入力のサービス欄を、servicesへのリンクに置き換えて。既存の予約は削除せずに移行して。

さらに締めます。

データベースの読み書きがすべてサーバー側で行われることを確認して。接続文字列がブラウザに届いてはいけない。挿入する前に、メールと開始時刻をサーバーで検証して。

手順

1. 上記のとおりデータを一覧化する：ものの種類、項目、それらのあいだのリンク。
2. データベースを作成する。 AIビルダーならチャットで依頼します。それ以外では、マネージドのPostgresインスタンスを作り、接続文字列をコピーします。
3. 接続文字列をシークレットとして保存する（サーバー上の環境変数）。コードには決して書かないでください。環境変数とシークレットを参照してください。
4. テーブルを作成する。 マイグレーション（スキーマを変更するバージョン管理されたスクリプト）を使い、変更を再現可能かつ元に戻せるようにします。
5. 行を作成・読み取り・更新・削除するサーバールートを作る（CRUD）。ブラウザはこれらのルートを呼び出し、データベースに直接接続しません。
6. UIをそれらのルートにつなぐ。 保存するフォーム、読み込む一覧、データがないときの空の状態の表示などです。
7. 保存されることを確認する。 何かを送信し、ページを再読み込みし、別のブラウザで開きます。データが無ければ、データベースには保存されていません。
8. アクセス権を確認する。 2人目のユーザーでログインし、最初のユーザーのデータが見えたり編集できたりしないことを確かめます。
9. 公開してから、もう一度テストする。 公開されたアプリはプレビューとは別の接続を使う場合があるため、ライブURLで確認してください。

よくあるミス

• ブラウザに保存して、保存済みだと思い込む。 localStorageは、別の端末でアプリを開くまでは動いているように見えます。必ず別のブラウザでテストしてください。
• 接続文字列をフロントエンドのコードに書く。 フロントエンドのコードは誰でも読めます。そのままデータベース全体を渡すことになります。
• アクセス制御がない。 「自分の注文を表示」は、UIではなくサーバー側で、ログイン中のユーザーで絞り込む必要があります。これはAIで作られたアプリでもっとも多いセキュリティの穴です。AIで作られたアプリのセキュリティチェックリストで扱っています。
• 破壊的なスキーマ変更。 「テーブル名を変えて」「構造を変えて」と頼むと、テーブルが削除されて作り直されることがあります。実データがあるときは、「既存の行を移行し、何も削除しないで」と明記してください。
• データベースにファイルを保存する。 画像やPDFはファイルストレージに置き、テーブルにはURLやキーだけを持たせます。ファイルアップロードの追加方法を参照してください。
• バックアップがない。 顧客がつく前に、プラットフォームのバックアップの仕組みと復元方法を確認しておいてください。

チェックリスト

• 種類ごとに、IDと作成日時を持つ独自のテーブルがある
• 必須項目と型がデータベース側で強制されている
• 接続文字列はサーバー側のシークレットにのみ置かれている
• すべての読み書きがサーバールートを経由している
• 各ユーザーは自分の行のみ読み取り・変更できる
• データは再読み込み後も残り、別のブラウザでも表示される
• スキーマ変更はマイグレーションを使い、既存の行を残している
• バックアップと復元の方法を把握している
• 公開後にライブアプリでテストした

Mythexでデータベースを追加する

Mythexでは、各プロジェクトが専用のPostgresデータベースを持てます。FreeとProの両方で利用できます。通常、別途「接続」ボタンを押す必要はありません。チャットで依頼する（「waitlistのメールアドレスをデータベースに保存して」など）か、/databaseと入力すると、接続情報がワークスペースと公開アプリに組み込まれます。プロジェクトの設定で、データベースが有効かどうかを確認できます。

データベースは5分間操作がないとスリープし、次のリクエストで起動します。公開版の利用料金は、実際に起動していた時間分だけが、アプリ作成に使うのと同じクレジット残高から請求されます。公開後にデータベースを追加した場合は、ライブアプリに反映されるよう、もう一度公開してください。

詳しくは、ドキュメントのデータベースとCRUDアプリを作るのレシピを参照してください。ユーザーごとのデータに関するログイン側の仕組みは、アプリにログインを追加する方法を読んでください。

よくある質問