情報確認日：2026年10月14日（本文で引用した公式資料を再確認）。
予約フォームをAIに頼むとき、「予約できるアプリを作って」だけでは、二重予約、キャンセル、管理者の閲覧範囲などの条件が抜けやすくなります。完成した画面を見てから直すより、試作する機能と確認する順番を先に決める方が、修正範囲を把握できます。
この記事は、Replitの公式ドキュメントをもとにした試作ガイドです。予約フォームの仕様と指示例はAIGNALの提案で、実際に作成・公開したアプリの検証結果ではありません。
1. 最初の試作は「入力を確認できる画面」まで
本物の予約受付、メール送信、決済を一度に実装せず、架空データで画面を確認します。初回の依頼例は次のようにします。
社内レビュー用の予約フォームを試作してください。
対象は1拠点、1種類のサービス、日時は日本時間です。
入力項目は架空の氏名、希望日時、人数、備考です。
初回は画面と入力チェックだけを作り、外部送信や公開はしません。
必須項目未入力、過去の日付、人数が範囲外のときはエラーを表示します。
まず仕様の不明点と作業計画を示してください。
「日本時間」は表示だけでなく、保存形式と日付判定にも関係します。何を保存し、利用者へどの時間で表示するかを仕様に残してください。
2. 保存、重複防止、管理画面を別の変更にする
画面が確認できたら、保存処理、予約枠の重複防止、管理者の閲覧機能を順に追加します。各段階で、変更内容をAgentに説明させ、前の機能が動くかを確認します。
| 段階 | 確認する例 |
|---|---|
| 入力 | 空欄、過去の日付、極端に長い備考を受け付けない |
| 保存 | 送信後に保存先IDを取得でき、更新しても記録が残る |
| 重複防止 | 同じ枠へ同時送信しても予約数が上限を超えない |
| 管理 | 一般利用者が予約一覧や他人の情報を取得できない |
画面の送信ボタンを無効にするだけでは、同時予約への対策になりません。保存側で枠の上限を守る処理が必要です。Agentにはその実装箇所と、同時送信を確認する方法まで説明を求めます。
3. チェックポイントの復元範囲を区別する
Replitのチェックポイントは、コードに加えて開発の文脈を保存する仕組みです。[1] 変更前後の地点を記録しておくと、どの変更で問題が起きたかを確認できます。
ただし、ロールバックでは開発データベースの復元が任意で、本番データベースはこの操作だけでは自動復元されません。[1] 「コードを戻したので予約データも戻った」と判断しないよう、復元対象を分けます。
| 対象 | 復旧計画に残す内容 |
|---|---|
| コード | 正常だったチェックポイントと変更内容 |
| 開発データ | 復元するか、架空データを作り直すか |
| 本番データ | 別途バックアップ・復旧方法を確認する |
| 外部処理 | 送信済みメールなど、巻き戻せない結果を照合する |
4. APIキーはSecretsへ、利用はサーバー側へ
外部APIを追加するとき、キーをAgentとの会話やソースへ貼り付けない運用にします。ReplitのSecretsは、認証情報を保存し、環境変数として利用する仕組みです。[2]
Secretsへ保存しても、キーをブラウザー向けコードに埋め込めば漏えいにつながります。APIを呼ぶ場所がサーバー側か、エラー表示やログに秘密値が出ないかを確認してください。開発用と本番用の接続先も記録します。
5. 本番移行は、試作の動作確認と分ける
Replitでは開発用と本番用のデータベースが分かれ、公開時の構造変更には注意が必要です。[3] 架空の予約やテストアカウントを、そのまま本番へ移す前提にしないでください。
公開を検討する前に、次を担当者が確認します。
- 実際の受付枠とキャンセル条件を仕様へ反映した。
- 未ログイン者、一般利用者、管理者の権限を確認した。
- テストデータ、Secrets、接続先を整理した。
- 公開後の費用を、開発時のAI利用費と分けて確認した。
- 障害時の受付停止、手動受付、データ復旧の担当を決めた。
AIGNALの実務見解
試作の成果として残したいのは、動く画面に加え、仕様表・確認結果・未対応項目です。この3点があれば、開発者へ引き継ぐときも、AIに続きを依頼するときも、作り直す範囲を判断しやすくなります。
公式出典・関連解説
- [1] Replit：Checkpoints and Rollbacks
- [2] Replit：Secrets
- [3] Replit：Development and production databases
- 概要を先に知りたい方へ：noteのReplit Agent解説
