ReplitでWebアプリを作る基本手順

ReplitでWebアプリを作るなら、最初に「誰が何を入力し、どんな結果を得るか」を1つだけ決めます。その流れが動く最小版を作り、画面・保存・権限・失敗時の動きを順に確かめてから機能を増やすのが安全です。Replit Agentは自然文の依頼からアプリ作成やテストを進められますが、完成条件を曖昧にすると、見た目だけ整って操作できない画面や、必要以上に広い実装になりやすくなります。

この記事のゴールは、アイデアをAgentへ渡す文章に変え、プレビュー上で中核操作を確認できる状態にすることです。作成や公開の各機能はプランやプロジェクト構成で違う場合があります。最新の画面表示と公式ドキュメントを確認しながら進めてください。

先に一つの利用フローを決める

「タスク管理アプリ」だけでは、何を作れば完成なのか決まりません。最初に利用者、入力、処理、結果を並べます。たとえば「個人が買い物候補を入力し、予算内かを見て、あとで一覧から削除できる」なら、入力欄、合計表示、一覧、削除操作が初期版の中心です。共有、通知、ログインはその後で判断できます。

表は横にスクロールできます

項目	記入例	決める理由
利用者	自分ひとり	認証・共有が必要かを切り分ける
入力	品名、価格	入力画面と必須チェックが決まる
処理	合計を計算し予算と比較	中核ロジックが決まる
結果	合計、残額、候補一覧	完成画面を説明できる
保存	次回も残す	DBが必要かを判断できる
失敗時	数値以外は保存しない	エラー表示を設計できる

この段階では、まだログインや決済を入れません。使う人が一人で、端末を閉じても保存する必要がないなら、まず永続DBなしで試す余地があります。反対に、複数ユーザーの個人情報を扱うなら、認証とデータ分離を初期設計に含める必要があります。

Agentへ渡す要件を「画面」より「結果」で書く

Replitの公式案内では、Agentへ自然文で説明し、プロジェクトを作り、結果を試して調整する流れが示されています。依頼文には、目的・利用者・入力・出力・制約・完了条件を含めます。最初から「おしゃれなアプリを作って」と頼むと、見た目の好みは伝わっても、どの操作が成功すれば完成なのかは残ります。

たとえば買い物候補アプリなら、最初の依頼をこう分けられます。

個人用の買い物候補アプリを作りたい。商品名と価格を入力し、予算と合計を比較して一覧表示する。価格が空欄または負数なら保存せず、入力欄の近くに理由を表示する。候補の追加・削除を実装する。まず必要な画面、データの持ち方、未決事項を説明し、まだ実装しないでください。

計画を見て、画面、データ項目、エラー表示が揃ったら、次に一段だけ実装を依頼します。使えるPlanモードがある場合は、コード変更前に計画を確認できます。表示されない環境では、チャットで「変更前に設計案だけ提示」と伝えれば目的を近づけられますが、利用できる機能自体は契約や設定に依存します。

まず完成させるのは一連の操作

ホーム画面がきれいでも、ボタンが保存につながらなければWebアプリとしての主要な仕事は終わっていません。最初の完成単位は、利用者が入力して、処理を実行し、結果を確認できる一往復です。

1. 入力項目と必須条件を決める。

2. 入力を送る操作を作る。

3. 正常値なら結果を画面へ返す。

4. 空欄・不正値なら保存せず、直し方を表示する。

5. ページを再読み込みしたときに必要な状態が残るか確認する。

6. 一覧から編集・削除するなら、対象行を間違えない操作を作る。

Agentが「画面を作成しました」と返しても、送信ボタン、読み込み中、成功、失敗、空状態をそれぞれ試します。操作を押した結果が何も起きない、エラーが画面外へ出る、保存した内容が更新後に消える場合は、中核フローがまだ完成していません。

Databaseを加える判断

入力内容を次回も残す、複数端末から使う、複数ユーザーで共有するなど、保存要件が明確になってからDBを加えます。Replitの公式DatabaseはSQLデータベースを提供し、Agentに統合を依頼するとschemaとアプリ側の接続を設定できます。ただし「アプリを作るなら必ずDBが必要」とは限りません。短いデモや一時計算なら保存自体が不要です。

DBを使う場合は、Agentにテーブル名だけ渡さず、保存する情報と所有者を明示します。例：「候補には作成者ID、商品名、価格、作成日時を持たせる。利用者は自分の候補だけを読める。削除後は一覧と合計に反映する」。この説明が曖昧だと、画面上では分かれていても、サーバー側で他人のデータを取得できる設計になりかねません。

最初のDBテストでは、テスト利用者を作り、追加・一覧・更新・削除を順に試します。画面が表示されるだけでなく、DBに意図した行だけが書かれ、権限のない利用者からは読めないことを確認します。テストデータと本番データを同じものとして扱わないでください。公開前は、可能なら別アカウントでも確認し、利用者が自分の記録だけを読めるかを確かめます。画面で隠れているだけではAPI権限の誤りを防げません。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Replit

  公式サイトを見るTool詳細を見る

Secretsと外部サービス

APIキーやDB接続情報をコード、画面、サンプルデータへ直書きしません。ReplitのSecrets等の専用設定で環境変数として管理し、アプリ側は環境変数から読み込みます。設定した値がプレビュー環境と公開環境のどちらで利用されるかも確認してください。秘密情報をブラウザーへ返すコードに入れれば、保管場所を分けても漏えいを防げません。

外部APIを追加する場合は、そのAPIを呼ぶ処理をサーバー側に置き、ブラウザーのNetwork欄や公開HTMLから鍵が見えないことを確認します。利用上限、課金、利用規約、個人情報の扱いは外部サービス側でも確認が必要です。Agentが接続を作ったというだけで、権限設定や契約が済んだとは判断しません。

Previewで確かめる順番

プレビューでは見た目だけでなく、実際の利用順に試します。初回表示、入力、成功、入力ミス、再読み込み、ログイン状態、データのない状態を確認し、最後にスマートフォン幅でも同じ操作をします。機能を追加するたびに全画面を眺めるのではなく、先に決めた中核フローを最初から最後まで通すのが効率的です。

表は横にスクロールできます

ケース	操作	合格の目安
正常入力	必要項目を入力して送信	結果が意図した場所に表示される
必須漏れ	必須項目を空にして送信	保存されず、項目を特定できる説明が出る
境界値	0、負数、長い文字列など	定義したルールで処理される
二重操作	連続で送信	重複レコードや二重課金を防げる
再読み込み	保存後に更新	保存要件に沿って状態が残る
権限	別ユーザーでアクセス	他人のデータへアクセスできない

ReplitのApp Testingなど自動テスト機能が利用できる場合も、出力を読む人の確認は残ります。自動テストが通ったテストケースと、未確認のケースを分けて記録してください。

Publish前に環境差を埋める

公開方式を選ぶ前に、アプリがブラウザーだけで完結するか、サーバー処理やDBを必要とするかを確認します。ReplitのDeployment typesでは、静的サイト、常時動くサーバー、アクセス量に応じて動くアプリ、定期実行などを区別しています。静的配信にバックエンドの処理は載りません。Webアプリの見た目が動くことだけで方式を決めず、API・ログイン・DBが公開後も必要かを確認します。

公開前には、環境変数、公開側DB、ビルド・起動設定、認証リダイレクト、エラー時の表示を確認します。開発環境で作ったサンプルデータを公開DBへそのまま持ち込まず、必要な初期データだけを選びます。公開後に問題が出たとき戻せるGitの状態やバックアップも残しておきます。

つまずいたときの原因を分ける

Agentの実装が大きくなりすぎたら、希望機能を追加するのではなく「最初の中核操作に必要なものだけ残す」と依頼し直します。データが保存されない場合は、画面の状態更新だけなのか、DB書き込みが成功したのか、再読込時に取得しているのかを切り分けます。

ログイン後に他人のデータが見える可能性がある場合は、公開前のブロッカーです。表示上のフィルターだけに頼らず、サーバー側の認可条件を確認します。エラーを修正するときは、元の症状・再現操作・期待結果を記録し、Agentが大きく書き換えた差分は一度に採用しません。

AIものさしの判断

ReplitでWebアプリを作る近道は、最初の指示を長くすることではありません。利用者の一連の操作と、何をもって完了とするかを先に決めることです。入力から結果まで動く最小版を作り、データ保存、ログイン、外部APIを必要な順に足せば、無関係な機能まで一度に生成するリスクを抑えられます。

プレビューで中核操作、失敗時、データ権限を確認できた段階で、公開方式と環境差をチェックします。趣味のデモなら保存や認証を省ける場合がありますが、個人情報や顧客データを扱うなら、アクセス制御、秘密情報、保存先、削除方法を決めるまで公開を保留してください。

公開後の変更前に、公開URL・公開方式・DB接続先の組み合わせをもう一度確認します。開発環境だけで使っていた処理が公開側に残っているなら、無理に公開を進めず、欠けた設定を特定してから試してください。