3行でいうと
- 公式が示す基本の流れは、計画(必要なら Plan)→ 作る → Preview で試す → 具体的なフィードバックで直す → 困ったら History のチェックポイントで戻す、です。
- 最初の1回は、公式の「Build your first app」のとおり、成果物に「Website」、モードに「Free」を選び、1つの成果だけを頼むのが公式の流れです。
- 公開は、Project Editor の「Tools」→「Replit Cloud」の下の「Publishing」→「Publish」の順です。公式は、公開の前に「Sharing」と「Suggested add-ons」を見直すよう書いています。
- 公式が書いていないこと(ボタンの正確な位置、初期値、戻したときの細かい挙動)は、この記事でも書きません。
この記事は、公式の資料を2026年10月25日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。以下の手順は、公式の手順を順に並べたものです。プロンプトの例は、この記事で組んだ例で、動作は確かめていません。画面の表記は変わることがあるので、手元の画面と照らして読んでください。
先に結論
- 公式の流れは、場面が変わっても同じ形です。1つの成果を頼む → Preview で使ってみる → 見たことを具体的に伝える。 公式の「Vibe coding guide」は、「具体的に」「優先順位を付けて」「文脈を添えて」の3点をプロンプトの書き方として挙げています。
- 手を動かす前に、導入と最初の設定(05)が済んでいる前提で書きます。連携(外部サービス、MCP、GitHub など)は07と08です。
- 料金やクレジットの数字はこの記事には書きません。モードを上げる、Plan を使う、公開する、といった操作が費用に関わることは、公式のページに書かれています(04を参照)。
前提:用語をそろえる
- Agent:頼んだことを実行するAIです。公式は、計画から公開まで進める、と書いています。
- Project Editor:Agent との会話と、アプリのライブのプレビューが並ぶ作業画面です。
- Preview:作っているアプリの動きを見る所です。
- チェックポイント:Agent が作業の途中で作る、戻れる地点です。公式の「Version control」は、Git に保存され、「History」で見られ、1回の操作で戻せる、と書いています。
- ロールバック:以前のチェックポイントの状態に戻すことです。
- Plan mode:コードやデータを変える前に、作業の計画(タスクの一覧)を作り、承認してから作るモードです。
- Free / Auto / Power / Max:Agent のモードです。公式の「Replit Agent」の表記です。Free は、プランの枠の範囲で追加の費用なしに使うモードで、Auto は Power か Max の中でモデルを自動で選ぶモード、と書かれています。
- Chat:質問、調べもの、計画のための入口です(公式のドキュメントの3つの入口の1つ)。
- Routine:公式のチャットの資料に出てくる、定期的に動く仕組みです。この記事では、名前を挙げるだけにします。
- プロンプト欄:チャットで文章を書く所です。公式は、添付、Plan、音声入力の操作があると書いています。
最初の1時間の順番(この記事の案)
これは、公式の「Build your first app」に、この記事で時間の目安を足した案です。時間の長さは、公式に書かれたものではありません。
| 順番 | することの内容 | 参照する場面 |
|---|---|---|
| 1 | 05の手順で、ウェブから入ってサインインする | 05 |
| 2 | 新しいチャットで「Website」と「Free」を選び、1つの成果を頼む | 場面1 |
| 3 | 「Preview」で、訪問者になったつもりで一通り試す | 場面2 |
| 4 | 気づいた点を、1回だけ具体的に直してもらう | 場面2 |
| 5 | 広げたくなったら、計画を先に作ってもらう | 場面3 |
| 6 | 壊れたら、症状を伝え、直らなければ戻す | 場面4 |
| 7 | 公開はこの段階では見送るか、公開前の確認を読む | 場面7 |
01には、公式の最初のアプリの流れを約10分と書きました。ここでの1時間は、その流れに余裕を足したこの記事の案です。
場面1:最初のWebsiteを作る
公式の手順を順に並べます。
- 新しいチャットを始める。サイドバーの「New」を選ぶ(デスクトップでは、「New」にカーソルを合わせる。公式の表記は「On desktop」で、アプリかブラウザかは公式の文から判別できていません)。
- 成果物に「Website」を選ぶ。プロンプト欄に「Output」が出ていれば、そこから選ぶ。出ていなければ、「Add attachment」→「Create something new」→「Website」の順。
- モード選択を開き、「Free」を選ぶ。
- プロンプトを書いて送る。公式の例は、1つの成果(ワークショップを探すアプリ)、訪問者にできてほしいこと、見て分かる成功の条件、今回は後回しにすること(ログイン、データ、支払い、連携)を書いています。この記事の例は次のとおりです。
(この記事の例)家庭菜園の育て方を記録する、1ページのサイトを作ってください。できてほしいこと:野菜の名前と植えた日を入力して一覧に追加できる、一覧で並びを日付順にできる。今回は、ログイン、データの保存、支払い、外部サービスとの連携は作らないでください。
- チャットで進み具合を見る。公式は、「Website」の成果物が示されて、「Preview」が動くまで待つよう書いています。完成まで数分かかることがある、とも書かれています。
返ってくるもの
公式によると、Agent は、プロジェクトを用意し、アプリを作り、自分でも確かめ、直します。チャットに作業の様子が出て、最後に「Website」の成果物と動く「Preview」が示されます。
途中で、Agent が「より上のモードのほうがよい」と提案することがあります。公式は、上げるかどうかは自分で選べると書いています。最初の例は Free のまま完成する、とも書かれています。確認が出て、上のモードを使った場合は、費用が発生しうることが公式のページ(Agent の説明)に書かれています。内容を読んでから承認してください。
場面2:Previewで試し、1回だけ直す
Previewで試す
公式の確認項目を、この記事の例の題材に当てはめます。
- 「Preview」で、訪問者になったつもりでアプリを使う。
- 主な操作(例:野菜を追加する)ができるか見る。
- 画面の幅をスマホの幅にして、崩れないか見る。
- 頼んでいないのに変わった所がないか見る(公式の「Vibe coding guide」の確認項目)。
直してもらう
公式は、動かない所があれば、コードを自分で調べず、見たことを Agent に伝えるよう書いています。「Vibe coding guide」は、症状と、期待していたことを分けて書く例を挙げています(たとえば、完了の表示は出るが、フォームの文字が古いまま残る、という書き方)。
この記事の例は次のとおりです。
(この記事の例)追加ボタンを押すと、一覧には増えますが、入力欄の文字が消えません。追加したあとは、入力欄を空にしてください。ほかの画面は変えないでください。
公式の最初のアプリの流れは、広げるときも1つの焦点のプロンプトにする、と書いています。直してもらったあとは、同じ操作でもう一度試します。
返ってくるもの
Agent が変更を行い、「Preview」が更新されます。意図どおりでなければ、さらに具体的に書いて繰り返します。更新の様子の細かい出方は、公式のページでは確認できていません。
場面3:計画を先に作る(Plan mode)
作る内容が複数にわたるとき、公式の「Plan mode」は、計画を先に作るやり方を示しています。
- Project Editor で Agent と作っているところから、チャット入力欄の右下の「Plan」の切り替えを選ぶ。
- 要件を伝え、相談する。この間、Plan mode はプロジェクトのコードやデータを変えない、と書かれています。
- Agent が、順番のあるタスクの一覧を返す。各タスクには、目的と完了の条件が含まれることがある、と書かれています。
- 次のどれかを選ぶ。
- 「Revise」:計画をさらに直す。
- 「Cancel」:計画を捨てる。
- 「Build here」:承認して、今の Agent のセッションで作る。
- 「Build in background」:承認して、別のタスクとして動かす。
- 作ったあとの進み具合は、今のセッションか、背景のタスクで見る。背景のタスクは、「Automatically apply changes」を有効にしない限り、変更を自分が確認して適用するまで待つ、と書かれています。
この記事の例は次のとおりです。
(この記事の例)野菜の記録サイトに、収穫日の記録と、野菜ごとの絞り込みを足したいです。まず計画だけ作ってください。範囲は、最小の試せる形にしてください。
公式の「Vibe coding guide」は、計画を読むときに、「正しい問題を解いているか」「抜けや範囲外はないか」「どう試すか」を見るよう書いています。広すぎるときは、「最小の試せる形」に縮めるよう頼む、とも書いています。
気をつけること(Plan mode)
- 公式は、Plan mode では、質問、助言、タスクの一覧のすべてが課金される、と書いています。質問が複雑で会話が長いほど費用が上がる、とも書かれています。
- Plan mode は、Agent でアプリを作っている間だけ使えます。「Conversations」からは使えない、と書かれています。
- プロジェクトの最初のチェックポイントの前は、承認のボタンが「Start building」になり、2つの作り方の選択は出ません。
- 「task plan is ready for review」のバナーが出たら、「Review now」を選び、タスクプランのカードの「View」を選ぶ、と「Vibe coding guide」に書かれています。
場面4:壊れたら、チェックポイントで戻す
公式は、Agent が作業の途中でチェックポイントを作る、と書いています。戻す手順は、公式の「Vibe coding guide」の記述です。
- Agent のパネルの「History」を開く。
- 戻りたいチェックポイントを探す。各チェックポイントには、「Rollback here」と「Changes」の操作がある。「Changes」で内容を確かめられる、と読めます。
- 「Rollback here」を選ぶ。確認のダイアログが出て、戻される内容(ファイル、Agent の記憶、タスク、任意の Database のチェックボックス)が並ぶ。
- 内容を読み、進めるなら確認する。
「直すか戻すか」迷うときは、現在のバージョンと、最後に動いていたバージョンを比べるよう Agent に頼む、と書かれています。
この記事の例は次のとおりです。
(この記事の例)直したあとから、一覧が表示されなくなりました。いまのバージョンと、最後に動いていたバージョンの違いを説明してください。
返ってくるもの・確認点
確認のダイアログに、何が戻されるかが並ぶ、と公式は書いています。データベースの中身を戻すかどうかは、任意のチェックボックスで選ぶ形です。戻したあとの Preview の挙動の細かい説明は、読んだ範囲では確認できていません。
場面5:機能を足す(ログイン、データベース、支払い、連携)
公式の「Build your first app」は、最初の核が動いてから足すよう書いています。足す機能として、ページには次の4つの名前が並んでいます。
- 「Add login」
- 「Add a database」
- 「Add payments」
- 「Add integrations」
この記事の例は次のとおりです。
(この記事の例)記録を、ブラウザを閉じても残したいです。データベースに保存するようにしてください。
足すと、外部のサービスやデータベースとの関わりが増えます。Agent が外部のサービスを使うときの仕組みと、データの行き先は、08(Connectors、MCP、AI Integrations)と、03、04を参照してください。
場面6:Chatで質問・調べものをする
Chat は、アプリを作らずに、質問や調べものや計画をするための入口です。公式の「Start a chat」と「Prompting」の流れを並べます。
- サイドバーの「New」を選び、新しいチャットを開く。
- プロンプト欄に、短い質問か、ざっくりした考えを書く。公式は、短くても始められる、と書いています。
- 文脈を足したいときは、プロンプト欄の「plus」メニューを開く。公式の「Start a chat」によると、ファイルのアップロード、新しく作る、プロジェクトの取り込み、スキルやデザインシステムの利用、連携の追加の項目があります。メニューの項目の正確な表記と順は、手元の画面で確かめてください。
- 答えを見て、追加で質問する。公式は、前の会話の文脈は残るので、同じ説明を繰り返さなくてよい、と書いています。
公式の「Prompting」は、良いプロンプトの要素として、次の4つを挙げています(この4つは決まった型ではなく、選択肢として書かれています)。
| 要素 | 公式の説明の要点 |
|---|---|
| Outcome | 答え、分析、計画、Routine、作るものなど、何がほしいか |
| Context | 関係するファイル、連携、Web の資料、例、フィードバック、画像、画面のスクリーンショット |
| Boundaries | 残すこと、優先すること、外すこと。直接の指示で書く |
| Use | 誰向けか、何の判断か、形式、次の行動など、作業に関わる点 |
この記事の例は次のとおりです。
(この記事の例)小さなチームが、週ごとの進み具合の報告に入れるとよい項目を、5つ挙げてください。1項目は1行で。
返ってくるもの
文章の答えが返ります。追加の質問で、証拠の提示、エラーの文を足しての修正、分析のスライド化、次の行動の表づくり、などに広げられる、と公式は例を挙げています。
場面7:公開する
公開の手順は、公式の「Publishing (Deployments)」のとおりです。
- Project Editor で「Tools」を選び、「Replit Cloud」の下の「Publishing」を選ぶ。
- 「Publishing」の画面で、設定を見直す。公式は、「Sharing」と「Suggested add-ons」を見直すよう書いています。
- 「Add a payment method」が出たら、画面の案内に従って支払い方法を足す。
- 「Publish」を選ぶ。
公式が書いている点を並べます。
| 項目 | 公式の資料に書かれていること |
|---|---|
| 公開の種類 | Autoscale、Static、Reserved VM、Scheduled の4つ。プロジェクトの種類に応じた初期の選択があり、変更できる。選び方の判断図が公式にある |
| 再公開 | もう一度公開すると、ファイルと依存関係の新しいスナップショットが作られ、公開中のアプリは、エディタではなくスナップショットから更新される |
| アクセスの制限 | 見られる人を限る設定は、Pro と Enterprise のみ |
| ファイルの保存 | 公開したアプリのファイルシステムに書いたデータは当てにしない。ストレージやデータベースを使う |
| 独自ドメイン | 別の「Custom Domains」のガイドに案内されている。このページには手順がない |
| 状況の確認 | 「Publishing」のツールが、状態と設定、ウェブのアクセス解析を示す |
| 公開の取り下げ、ログ、Secrets の扱い | このページには書かれていない |
この記事の例(Agent に公開の前の確認を頼む文)は次のとおりです。
(この記事の例)公開する前に、コードの中に、パスワードやAPIキーが直接書かれていないか確認してください。見つかったら、場所を教えてください。
公開すると、他の人が見られる状態になります。公開の前に、秘密の値や個人のデータが入っていないかを確かめてください(これはこの記事の注意です。読んだ公開のページに同じ注意は確認できていません。01も参照)。
場面8:スマホで動かして試す
モバイルアプリを作った場合の試し方は、05の「手順4:スマホで動作を試す(Expo Go)」にあります。要点は、スマホの Expo Go で、プレビューの QR コードを読み取る、です。
場面9:ほかのAIや外のツールとつなぐ
別のAIや外のツールから Replit を使う方法は、07(外から Replit を使う側)に、Replit から外へつなぐ方法は、08にまとめました。06では、手順を繰り返しません。
プロンプトの書き方の表(公式の要点)
公式の「Vibe coding guide」と「Prompting」を、そのまま表にします。
| 避けたい状態 | 公式の書き方に沿った言い換えの方向 |
|---|---|
| 「アプリをよくして」だけ | どのページを、何のために、どんな制約で、と具体的に書く |
| 要望がいくつもあって優先順位がない | どれが一番大事か、最初の版は単純でよいかを書く |
| 文脈がない | 誰向けか、何のためかを文章で書く。言葉で足りなければ、スクリーンショット、スケッチ、ファイル、エラーの文を足す |
| 関係ない所まで変わる | 変えてはいけない所を書く |
| 「フォームを直して」だけ | 見たこと(完了表示は出るが、古い文字が残る)と、期待(空になる)を書く |
つまずきと見直し先
| 起きたこと | 公式の資料に書かれた確認先 |
|---|---|
| 作った結果が思ったものと違う | 場面2のとおり、見たことと期待を具体的に書いて、1回ずつ直す |
| 直したら悪くなった | 場面4のとおり、「History」で戻る。迷うときは、Agent に現在と最後に動いた版の比較を頼む |
| 計画が広すぎる | 最小の試せる形に縮めるよう頼む(場面3) |
| Plan を使ったら費用が気になる | Plan mode の質問や計画づくりも課金される。使用量は https://replit.com/settings/usage |
| 上のモードを勧められた | 上げるかどうかを選べる。確認の内容を読んでから承認する |
| 公開できない、「Add a payment method」が出た | 画面の案内に従い支払い方法を足す(場面7)。条件の詳細は、このページには書かれていない |
| 公開したアプリのデータが消える | ファイルシステムに書いたデータは当てにしない。ストレージかデータベースを使う |
| 画面の表記が、この記事と違う | 公式のページごとに表記が違う所がある。手元の画面と照らす |
たとえ話:台所の下ごしらえ
Replit での作り方は、台所の流れに似ています。まず1皿だけ決めて作り(場面1)、味見をして(場面2)、足りない所を一言で伝え、品数が増えるときは先に献立を書き(場面3)、失敗したら火を止めて前の鍋に戻す(場面4)。客に出すのは、味見が済んでからです(場面7)。これは僕らのたとえで、公式の表現ではありません。
気をつけること
- この記事は、実際に使って確かめた記録ではありません。公式の資料を読んだ範囲です。
- この記事のプロンプトの例は、この記事で組んだものです。Agent がどう答えるかは確かめていません。同じ文でも、結果は同じにならないことがあります。公式も、Agent は間違えることがある、と注意しています(01)。
- Plan の利用、上のモードへの切り替え、公開は、費用に関わることが公式に書かれています。数字は04と公式の画面で確かめてください。
- チェックポイントで戻すとき、確認のダイアログに出る内容(ファイル、Agent の記憶、タスク、データベース)を読んでから進めてください。
- 公開すると、他の人が見られる状態になります。秘密の値や、他人の個人情報が入っていないかを、公開の前に確かめてください。
- 公式のページ同士で、ボタンの表記や入口が違う所があります。この記事では、書かれた表記を併記しています。
- 公式が書いていない点(Preview の更新の細かい出方、戻したあとの挙動、公開の取り下げ)は、書いていません。
出典
- Build your first app(Replit Docs、確認日 2026-10-25)
- Replit Agent(Replit Docs、確認日 2026-10-25)
- Vibe coding guide(Replit Docs、確認日 2026-10-25)
- Plan mode(Replit Docs、確認日 2026-10-25)
- Version control(Replit Docs、確認日 2026-10-25)
- Project Editor(Replit Docs、確認日 2026-10-25)
- Publishing (Deployments)(Replit Docs、確認日 2026-10-25)
- Start a chat(Replit Docs、確認日 2026-10-25)
- Prompting(Replit Docs、確認日 2026-10-25)
- Get started(Replit Docs、確認日 2026-10-25)
- Welcome to Replit(Replit Docs、確認日 2026-10-25)
- Preview and test on your phone(Replit Docs、確認日 2026-10-25)