Replitのデータベースは、入力した情報を次回も残したり、複数の利用者で扱ったりするときに使います。Agentへ作成を頼む前に、保存項目、誰が読めるか、開発用と本番用の接続先を決めます。開発画面で保存できても、公開アプリで同じデータが見えるとは限りません。
この記事では、管理型SQLデータベースの導入から、開発環境の確認、公開時のスキーマ変更、復旧範囲までを整理します。実際のReplit操作、SQL実行、公開、復旧は実施していません。タスクとテーブルの例は説明用です。
目次
最初に、何を保存するかを決める
一回限りの計算で保存が不要なら、DBを使わない構成も選べます。次回の再表示、端末間の共有、検索が必要なら、最小の項目と所有者を決めてからDBへ進みます。
個人用タスクなら、例えば次の形です。これはReplit必須のテーブル定義ではありません。
表は横にスクロールできます
| 項目 | この例の意味 | 決めること |
|---|---|---|
| id | タスクの識別子 | タイトルが同じでも区別する |
| user_id | 所有者 | サーバー側で本人の行だけ扱う |
| title | 作業内容 | 空欄を許すか、長さの制限 |
| status | 未完了・完了 | 許可値以外を保存しない |
| created_at | 作成日時 | 表示順とタイムゾーン |
画面で他人の行を隠すだけでは、データの権限確認になりません。取得・更新・削除の処理が対象利用者の権限を確認する設計にします。保持期間と削除条件も、必要な範囲で定めます。
Agentには、変更前に案を出してもらう
Replit DatabaseはProject Editorから使う管理型SQLデータベースです。公式は、Agentへ統合を依頼すると、スキーマとアプリの読み書きを設定する流れを説明しています。Replit公式：Database（新しいタブで開く）
最初の依頼を、画面だけの要望で終わらせないようにします。
個人用タスクを保存したいです。所有者、タイトル、未完了・完了、作成日時を持たせます。利用者は自分の行だけを読取・更新・削除できます。タイトルは空欄不可です。まずスキーマ、制約、権限確認、既存データへの影響を提案してください。まだDBやコードを変更しないでください。開発用と本番用の対象が不明なら確認事項にしてください。
提案では、主キー、所有者との関係、必須項目、削除の範囲を確認します。「ユーザーを消したらタスクも消すか」「同じタイトルを複数作れるか」は、自分の要件として決めます。Agentの提案を、そのまま組織のデータ管理方針にはしません。
開発DBで、保存と権限を別に確かめる
テスト用の利用者とデータを使い、作成・読取・更新・削除を一つずつ確認します。以下の確認表を用意します。
表は横にスクロールできます
| 操作 | 入力・操作例 | 確認すること |
|---|---|---|
| 作成 | タイトル「請求書を送る」 | 対象利用者の行が一件だけ増える |
| 読取 | 一覧を再読み込み | 保存した内容を再取得できる |
| 更新 | 未完了から完了へ | 指定した一件だけ変わる |
| 削除 | 対象IDを削除 | 想定した一件だけ処理される |
| 権限 | 別利用者から同じIDへアクセス | 他人の行を読取・変更できない |
| 入力不正 | タイトル空欄、未知のstatus | 保存せず、理由を表示する |
ボタンを連続で押す場合や通信失敗後の再操作も確認します。画面の件数だけでは、別の行を更新した誤りが分かりません。対象IDと所有者、保存された値を対応させます。失敗時に空配列だけ返して成功のように表示すると、接続不良とデータなしを区別できなくなるため避けます。
開発用と本番用は、データと構造を分けて考える
公式は、開発DBをAgentと実験する場所、本番DBを公開アプリのデータの場所として説明しています。Agentは本番DBを直接変更できません。一方、Agentと変更した開発DBの構造は、公開時に本番へ適用されます。「直接触れない」ことを「公開しても本番に影響しない」と読み替えないでください。
開発DBが現行のHelium基盤で、開発データが入っている場合、公式は公開時に本番DBを自動作成すると説明しています。旧Neonの開発DBでは、公開設定で本番DB作成と開発データのコピーを選ぶ手順が示されています。Replit公式：Development and production databases（新しいタブで開く）
開発データのコピーとスキーマ変更は別です。テストアカウントや未完成のサンプルを、そのまま本番へ入れる必要はありません。対象アプリの基盤と公開設定を確認し、旧環境のチェック項目が全アプリで同じように出るとは想定しません。
表は横にスクロールできます
| 変更するもの | 確認する対象 | 勘違いしやすいこと |
|---|---|---|
| 開発用のテスト行 | 開発DBの対象行 | 本番にも同じ行があると思う |
| 列・テーブルの構造 | 公開時に適用される変更 | Agentが本番を直接触れないから無影響と思う |
| 公開アプリの利用者データ | 本番DBとアプリの権限 | 開発用の一覧だけ見て正常とする |
| 初期データのコピー | 対象環境の公開設定 | テストデータも必要な初期データと扱う |
接続情報を調べる際は、対象DB名、利用環境、権限を確認します。パスワード付き接続文字列をチャットや記事、公開ログへ貼りません。アプリが参照する接続先と、確認中のDatabase画面が同じ対象かを照合します。
まずは使ってみる
記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。
Replit
必須列を追加する例で、変更前の不足を見つける
タスクへ担当区分を追加したいとします。開発データには値が入っていても、本番の既存行が新しい必須条件を満たすとは限りません。
次は架空の三行です。空欄は、この例では値が決まっていない状態を表します。
表は横にスクロールできます
| id | title | 追加したい担当区分 |
|---|---|---|
| T01 | 請求書を送る | 経理 |
| T02 | 見積書を確認する | 空欄 |
| T03 | 契約書を保管する | 総務 |
この状態で担当区分を必須にする案なら、三行のうち一行が条件を満たしていません。Agentへ全行を「経理」に埋めさせれば、形式はそろっても内容が誤ります。区分の正しい値、未確定を許す段階、既存行を整える手順を先に決めます。
- 現在のスキーマと、影響する既存行を確認する。
- 値を決める根拠と、未確定の行を残す扱いを決める。
- 追加・値の設定・制約の適用をどの順で行うか提案してもらう。
- 検証用データで、旧画面と新画面の操作を確認する。
- 対象本番DBの復旧方法と担当者を確認してから反映を判断する。
これは移行計画の考え方で、Replitが必ずこの順に自動処理するという仕様ではありません。削除、名前変更、型変更の場合も、既存コードが参照する項目と既存データを同時に見ます。
コードを戻す操作と、DBを戻す操作を分ける
現行の開発DBを対象とするCheckpoint復旧では、通常のロールバックは既定でDBを変更しません。開発DBも対象にする場合は、Additional rollback optionsでDatabaseを選ぶ必要があります。旧Neon開発DBの復旧方式は異なり、公式は時点復旧を案内しているため、対象環境に合った手順を確認してください。本番DBは、この操作で自動復旧されません。Replit公式：Checkpoints and Rollbacks（新しいタブで開く）
本番DBの復旧には、Data recoveryで説明される時点復旧やバックアップを使います。利用できる履歴はプランと保持設定によります。DBの復旧でコードが戻るわけではなく、コードのロールバックで本番DBが戻るわけでもありません。Replit公式：Data recovery（新しいタブで開く）
表は横にスクロールできます
| 戻したいもの | 事前に特定すること | 復旧後の確認 |
|---|---|---|
| 開発コード | 対応するチェックポイント | 依存関係と主要操作 |
| 開発DBも含む状態 | DBを復旧対象にする選択 | テーブル、行、コードとの整合 |
| 本番DB | 対象DB、復旧可能な時点、必要な権限 | 代表データ、件数、利用者の操作 |
| 本番のコードとDB | 両者が対応する版と時点 | 復旧範囲と、その後のデータの扱い |
例えば10時の状態へDBを戻す案なら、10時以降に作成・更新したデータをどう扱うかも検討します。「戻すボタンがある」だけで、失いたくない更新まで保持できるとは判断しません。実行前に、影響する時点と対象、作業担当を明確にします。
保存できないときは、画面・処理・DBの順に追う
表示だけ更新されているのか、サーバーへ依頼が届いたのか、DBへ行が保存されたのかを分けます。各段階の対象IDと時刻を対応させると、接続不良、入力制約、権限、表示条件のどこを調べるか絞れます。
公開先だけ空になる場合は、まず開発DBと本番DBの違いを確認します。データがないことと、取得エラーを空として表示したことは別です。原因が分からないまま開発データをコピーしたり、本番の接続先を差し替えたりせず、対象を確認してから必要な修正を決めます。
公開前に確認すること
- 保存項目と所有者、削除条件が決まっている。
- 開発DBで作成・読取・更新・削除と別利用者の権限を確認した。
- 公開時の構造変更と初期データのコピーを区別した。
- 既存行が新しい制約へ適合するか確認した。
- 対象本番DBの復旧可能な時点と、コードの対応版を確認した。
- 接続情報を公開画面やログへ出していない。
- 本番での確認が必要な項目を、開発成功だけで合格にしていない。
料金や保存・復旧の上限も、利用するプランと現行設定から確認してください。
ReplitでDBを使う基本は、Agentへスキーマを作らせるだけで終わらせず、保存先と権限、既存行への影響、戻す範囲を説明できる状態にすることです。公開方式の選択はReplitの公開・デプロイ確認で、アプリ全体の作り方はWebアプリ作成の基本で確認できます。
参考資料
- Replit：Database（新しいタブで開く）
- Replit：Development and production databases（新しいタブで開く）
- Replit：Checkpoints and Rollbacks（新しいタブで開く）
- Replit：Data recovery（新しいタブで開く）
資料確認日：2026年10月21日。利用できる機能、保存・復旧の条件、料金は、利用時点の公式案内と対象アプリの設定で確認してください。