Replitの基本的な使い方

Replitを初めて使うときは、最初から細かいcodeを書こうとするより、何を作るか → Agentに伝える → Previewで確認 → 修正 → Publishという流れで覚えると理解しやすくなります。

Replitはbrowser上でAgent、database、Secrets、checkpoints、deploymentを扱えるcloud workspaceです。どの機能が使えるかはplanやworkspace設定で変わるため、作業を始める前に表示を確認します。

作りたいものを小さく定義する

Replitへsign inし、新しいAppを作成します。

Agentを使う場合は「何を作りたいか」をnatural languageで伝えます。

最初のpromptでは、機能を盛り込みすぎるより、

• 誰が使うか

• 何ができれば完成か

• 必要なpage

• 保存するdata

• loginの有無

• 外部APIの有無

を短く整理します。

たとえば「社内用の問い合わせ管理tool。login後に一覧・詳細・status変更ができる」のように、目的とcore flowを先に伝えます。

要件に合うAgent設定を選ぶ

Replit AgentにはLite、Economy、Powerがあります。

Lite

小さな修正、UI調整、bug fix向け。

Economy

costを抑えながら日常的なbuildを進めたい場合。

Power

複雑なfeature、大きめのcodebase、production-grade task向け。

公式DocsではMax modeは終了し、最もcapabilityが必要な標準taskではPowerを使う案内になっています。

またPowerではTurboを有効にでき、処理speedを上げられますが、costも増えるため、常時onにするより必要な場面だけ使います。

変更前にPlanの範囲を確認する

大きなfeatureでは、Agentが出すplanを先に確認します。

特に、

• database schema

• authentication

• payment

• external API

• permission

• deployment構成

は、実装後に変えると修正範囲が広がります。

「まずplanだけ出して、codeはまだ変更しない」と指示する方法も有効です。

Previewで受け入れ条件を確かめる

AgentがbuildしたらPreviewで実際に操作します。

見た目だけでなく、

• buttonが動くか

• form submitできるか

• reload後もdataが残るか

• error時の表示

• mobile幅

• login / logout

• permission

まで確認します。

Advanced settingsにApp Testingが表示される場合は、Agentにbrowser flowを試させることもできます。LiteではApp TestingとCode Optimizationsはoffと公式docsに記載されています。利用可否や実行費用はplan・workspaceの現在表示を確認してください。

ただしAI testだけでなく、自分でもcore flowを触ります。

失敗を一つずつ切り分ける

「全部いい感じに直して」より、

• このbuttonが反応しない

• mobileでheaderが崩れる

• database保存後に一覧へ反映されない

のように症状を分けた方が修正が安定します。

error messageやscreenshotも一緒に渡します。

変更前の復旧点を確保する

Replit Agentは開発中の節目でcheckpointを作ります。

checkpointは変更前へ戻るための復旧点として使えます。ただし外部databaseや接続サービスまで同じように巻き戻ると決めつけず、restore後に実際の状態を確認してください。

大きな変更で壊れた場合はrollbackできます。

AI開発では変更量が大きくなりやすいため、「壊れたら戻せる」状態を維持することが重要です。

API keyはSecretsで管理する

OpenAIやStripeなど外部serviceのAPI keyを使う場合、promptやsource codeへ直接貼らずSecretsを使います。

ReplitはAPI key等の秘密情報をpromptへ直接入れないよう案内しており、Secretsを使う構成が基本です。

公開前にproduction条件を確認する

動作確認が終わったらPublishingから公開します。

Replitではappの性質に応じてdeployment typeが分かれます。

Agentで作るfull-stack appではAutoscaleやReserved VMなどが候補になります。

公開後はstatus、logs、resource usage、analytics、uptime等を確認できます。

「Previewで動く」と「productionで安定して動く」は別なので、publish後もlogを確認します。

まずは使ってみる

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

• 

  Replit

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

よくあるつまずき

最初のpromptが大きすぎる

featureを分割します。

Agentが不要な部分まで変更する

変更範囲をfile / page / feature単位で指定します。

costが予想より増える

Agent mode、Turbo、長いtask、test回数を確認します。

壊れた状態から修正を重ねる

checkpointへ戻し、原因となった変更からやり直します。

keyをcodeに書く

Secretsへ移します。

最初の依頼を検収できる形にする

Agentへ渡す要件は、自由な説明だけでなく「目的・範囲・制約・合格条件」に分けます。問い合わせ管理Appを作る例なら、次のように書けます。

• 目的：社内担当者が問い合わせを登録し、対応状況を追える

• 範囲：一覧、詳細、担当者、status変更まで。外部公開・決済は今回作らない

• 保存：問い合わせ本文、受付日、担当者、status。顧客の実データは入れない

• 制約：loginを必須にし、API keyはSecretsへ置く

• 合格条件：未入力を拒否できる、status変更がreload後も残る、権限のない人は見られない

• 確認：desktopとmobileで主要操作を行い、変更fileと未対応点を説明する

「動けば完成」ではなく、誰がどの操作をでき、何を見れば合格かを先に決めると、Previewで確認する範囲が定まります。

Planから実装へ進む境界

小さい画面文言の変更なら、そのまま依頼しても構いません。login、database schema、外部API、payment、公開設定が関わるときは、先にPlanを読みます。Planでは次を見てください。

• 変更対象が依頼した画面・機能に収まっているか

• 新しいpackage、API、権限、database tableが増えていないか

• production dataを使う前提になっていないか

• 失敗時の戻し方と検証方法が書かれているか

範囲外の機能や権限追加があれば、実装前に止め、理由を聞いてからPlanを修正します。

Previewの検収表

最初の試作は、機密情報を含まない架空データで次の表を埋めます。

• 入力：空欄、正常値、長文、想定外の文字

• 操作：登録、編集、status変更、reload、logout後の再login

• 期待：保存結果、validation、権限、error表示が要件どおり

• 確認者：利用者役と管理者役で見える範囲を分ける

• 証跡：再現手順、画面、error、Agentが変更したfile

App TestingがAdvanced settingsに表示される環境では、Agentにbrowser上のflowを試させられます。ただし人の判断が必要なpermission、security、アクセシビリティや実データの整合まで保証するものではありません。通常の手動確認と必要なtestを残します。

つまずき別の次の一手

Agentが対象外のfileまで変更したら、追加の修正指示を重ねる前にdiffを読み、checkpointまたはGitから戻せる範囲を確認します。期待したdataが保存されない場合は、入力validation、保存先、reload後の取得を分けて調べます。Previewでは動くのに公開後に失敗する場合は、Secrets、environment variable、deployment設定の差を確認します。

原因を一つに絞れないときは、実装を増やすより再現条件を小さくします。実ユーザーやproduction dataを使わず、同じ操作を再現できる最小例を作る方が安全です。

最初の評価は「一人の利用者の一連操作」で行う

機能を点ごとに確認するだけでなく、利用者が目的を終えられるかを通して試します。問い合わせ管理なら、担当者が新規登録し、別の権限の利用者が一覧を確認し、statusを更新し、reload後も結果を見られるかを一続きで確かめます。入力validation、権限、保存、再表示のどこで失敗したかを記録し、Agentへはその再現手順と期待結果を渡します。

AIものさしの判断

Replitは、ideaからappを作り、testし、deployするところまで一つのcloud workspaceで進めたい人に向いています。

最初は、

1. 小さい要件を書く

2. Agentでbuild

3. Preview確認

4. 問題を一つずつ修正

5. Checkpointを確認

6. Publish

の流れで十分です。

複雑なappほど、一発生成よりfeatureを分割した方が管理しやすくなります。