手順

AI を使ってアプリを作る手順

AI でアプリを作る現実的な進め方は 4 段階です。1 つ目にビルダー型ツールで画面とデータの形を出し、2 つ目にその出力をリポジトリへ落とし、3 つ目にターミナル型エージェントで認証・エラー処理・テストを詰め、4 つ目に公開します。最も失敗しやすいのは 1 段階目に留まり続けることで、ビルダー型は骨格を出すのは速い一方、クレジット制のため試行錯誤には向きません(Lovable の無料枠は 1 日 5 ビルドクレジット、2026-09-05 確認)。

日本語 · 最終確認日: 2026-09-05 · 英語版の全文: English

段階 1:作るものを 1 段落で書く

ツールを開く前に、誰が何をするアプリなのかを 1 段落で書いてください。「タスク管理」ではなく「1 人で使う。タスクに期限とタグを付け、今日やる分だけ 1 画面に出す」まで書きます。この段落があると、以降どのツールを使っても指示がぶれません。逆にこれが無いままプロンプトを書き始めると、出力のたびに要件が動きます。

段階 2:ビルダー型で骨格を出す

ビルダー型は空の状態から画面遷移とデータの形を一気に出すのが得意です。ただしクレジット制であることを前提に動いてください。Lovable の無料プランは 1 日 5 ビルドクレジット(月最大 30)と月 20 クラウドクレジットで、公式ページによる消費目安は単純なタスクが 0.50、中程度が 0.90〜1.20、複雑なものが 1.70 クレジットです。つまり 1 日で試せるのは実質数回で、「気に入るまで作り直す」使い方はできません。

ここで止まらないこと

生成されたものが動いた瞬間に完成した気になるのが最大の落とし穴です。ビルダー型の出力に足りていないのはたいてい、エラー処理、権限、テスト、そして「想定外の入力が来たとき」の挙動です。これらは次の段階の仕事です。

段階 3:エージェント型に切り替えて仕上げる

リポジトリに落としたら、Claude Code や OpenCode のようなターミナル型エージェントに切り替えます。ここで効くのがプロジェクト直下の `CLAUDE.md` です。ビルドコマンド、テストコマンド、命名規則を書いておくと、毎回同じ説明をしなくて済みます。公式は 1 ファイル 200 行未満を目安としており、これはコンテキスト消費と遵守率の両面からの推奨です。

  1. 入力検証とエラー処理を足す。「想定外の入力が来たときの挙動を全ハンドラで統一して」のように、対象を明示して頼みます。
  2. テストを書かせる。まず失敗するテストを書かせ、それから通す順にすると、実際に検証しているかが分かります。
  3. 認証と権限を確認する。生成物で最も抜けやすいのがここです。
  4. 差分を必ず読む。読まないまま重ねた変更は、後で切り分けられなくなります。

段階 4:公開する

公開前に確認することは 3 つだけです。秘密情報がリポジトリに入っていないか、本番用の設定が開発用と分かれているか、そして最低限のログが出ているか。エージェントは頼めばこれらをチェックしますが、頼まなければ見ません。「セキュリティを確認して」ではなく「.env や API キーがコミットされていないか、git 履歴も含めて確認して」と具体的に指示してください。

どのツールで始めるか

無料で通しで試したい場合、段階 2 は Lovable の無料枠、段階 3 は Gemini CLI(Google アカウント認証で毎分 60・1 日 1,000 リクエスト)または OpenCode(ソフトは無料、モデル代のみ)で足ります。すでに Claude のサブスクがあるなら段階 3 は Claude Code が追加費用なしで使えます(Pro・Max・Team に含まれる)。

よくある質問

AI だけでアプリを完成させられますか?
骨格までは十分に作れますが、そのまま公開できる状態にはまずなりません。生成物に不足しがちなのはエラー処理、権限、テスト、想定外入力への挙動です。ビルダー型で骨格を出し、ターミナル型エージェントでこれらを詰める 2 段構えが現実的です。
無料でどこまでできますか?
骨格の生成は Lovable の無料枠(1 日 5 ビルドクレジット、月最大 30)で試せます。仕上げ側は Gemini CLI が Google アカウント認証で毎分 60・1 日 1,000 リクエスト無料、OpenCode はソフト自体が無料でモデル代のみです。すべて 2026-09-05 に各公式ページで確認しています。
プロンプトはどう書けば精度が上がりますか?
対象を特定できる情報を入れることです。ファイル名、関数名、エラーメッセージは原文のまま貼ります。また「セキュリティを確認して」のような抽象的な依頼より、「.env や API キーがコミットされていないか git 履歴も含めて確認して」のように検証可能な形にするほうが確実に動きます。
既存のアプリに機能を足す場合も同じ手順ですか?
違います。既存コードがある場合はビルダー型を飛ばし、最初からエージェント型を使ってください。既存の規約・認証基盤・データモデルが制約として主役になるためで、プロジェクト直下の CLAUDE.md にそれらを書いて渡すのが最短です。

出典