【ITニュース解説】How to prompt an AI to build a Next.js app step by step (budget app example, with checkpoints that catch bugs)

AIを活用してアプリケーションを開発する際、「予算管理アプリを作ってほしい」といった大まかな指示では、期待通りの結果を得るのが難しい現実がある。AIは開発者が明示しなかった多くの詳細を「推測」して埋めてしまうため、後から意図しない仕様やバグに悩まされることになる。この問題への効果的な解決策は、アプリ開発のプロセスを細かく分割し、各ステップでAIに極めて具体的かつ明確な指示を与えることだ。そして、各ステップの最後に、その成果が正しく機能しているかを目で見て確認できる「チェックポイント」を設けることが重要になる。

良いプロンプト（AIへの指示）にはいくつかの共通した特徴がある。まず、一つのプロンプトには「一つの仕事」だけを割り当てるべきだ。「ストレージ層」といった具体的な役割を一つに絞り、「ストレージ、初期データ、経費ページ」のように複数の役割を混ぜない。次に、ファイルパス、関数名、ストレージキー、UIのラベルなど、すべての「正確な名前」を指定する。AIがこれらを自由に決定すると、後続のプロンプトで参照できなくなり、開発全体が破綻する原因となるためだ。さらに、「どちらかの方法を選んで」といった「開かれた選択肢」は与えない。常に開発者側で最善と考える方法を選び、プロンプトに明記する。そして最も重要な点として、何か目に見える形で動作確認できる「チェックポイント」を設ける。例えば、「lib/storage.tsを実装し、loadExpensesなどの型付きヘルパーを定義する。キーはvibe-budget:expensesなどを使う。typeof window === "undefined"の場合は早期リターンし、データが欠損している場合は空の配列を返すこと」といった指示の後に、「CHECKPOINT: npx tsc --noEmitでエラーが出ないことを確認する」といった具体的な検証方法を追記するのだ。

また、AIは以前のプロンプトの内容を確実に記憶しているわけではないため、全てのプロンプトに共通して適用される「ハウスルール」を定義し、AIが常に参照できる場所に配置することが効果的だ。例えば、Next.jsのClient Componentに関するルールや、localStorageやnew Date()を直接レンダリング中に呼び出さないといったルール、日付のフォーマットに関するルールなどだ。これらはAGENTS.mdファイルのようなプロジェクトルートに置くことで、AIが常にこれらの制約を守るように促す。

実際にAIにアプリ開発を依頼した際に発生した、曖昧なプロンプトによるバグとその改善例がいくつか報告されている。例えば、「最新の安定版create-next-appのデフォルト設定を使う」という指示では、create-next-appが対話形式で質問をしてくるため、AIはそれに答えられず詰まってしまう。この場合、「npx create-next-app@latest vibe-budget --ts --tailwind --eslint --app --use-npm --yes」のように、具体的なコマンドとそのオプションを全て指定することで、AIが迷うことなくプロジェクトをセットアップできるようになる。

また、「src/（またはプロジェクトのアプリケーションルート）配下」という指示も問題を生むことがある。デフォルトのNext.jsプロジェクトにはsrc/フォルダがないため、AIはどこにファイルを配置し、どうインポートすれば良いか判断できない。これを避けるには、「プロジェクトルートに以下の構造を使用し（src/フォルダはなし）、@/エイリアスを使ってインポートする。例：import { loadExpenses } from "@/lib/storage";」のように、具体的なパスとインポート方法を示す必要がある。

「クライアントレイアウトまたはホームページから一度だけensureSeedData()を呼び出す」という指示も、一見問題なさそうに見えるが、バグの温床となる。ルートレイアウトがサーバーコンポーネントである場合、シードデータはホーム画面でしか実行されず、ユーザーが/expensesなどのページに直接アクセスすると、空のカテゴリドロップダウンが表示されてしまう。これを修正するには、ensureSeedData()関数を「windowオブジェクトがない場合は早期リターンし、カテゴリがすでに存在する場合は何もしない」ように変更し、さらに「以降のすべてのページは、カテゴリをロードする前にuseEffect内でensureSeedData()を呼び出す」というルールを設けることで、どのページからアクセスしても初期データが保証されるようになる。チェックポイントも、「新しいプライベートウィンドウで/expensesに直接アクセスし、カテゴリ選択に8つのカテゴリが表示されること」のように、バグを直接検証できる形に変更する。

日付の取り扱いも注意が必要だ。「date ISO string」という指示は、new Date().toISOString()をAIに選ばせがちだが、これはUTC形式であり、<input type="date">が期待するyyyy-mm-dd形式とは異なる。また、タイムゾーンの問題で日付がずれることもある。この問題を解決するためには、todayISO()のような具体的なヘルパー関数を定義し、日付をYYYY-MM-DD形式の文字列として扱い、月の比較も文字列で行うように明確に指示する必要がある。

カテゴリ削除時のロジックも、「『その他』への削除または再割り当てをブロックする — どちらか一方のアプローチを選択」といった指示では、AIはどちらかを選び、その選択が後続のバグにつながる可能性がある。例えば、削除されたカテゴリに関連する予算が残ってしまうといった問題だ。これを避けるには、「削除する際は、まず確認を求め、そのカテゴリの全ての経費を『その他』に移動し、そのカテゴリの予算を全て削除してから、カテゴリ自体を削除する。『その他』カテゴリ自体は削除できない」といった、すべての分岐を明確に記述する必要がある。

金額入力の検証も重要で、「非数値入力を拒否する」といった漠然とした指示ではなく、「lib/money.tsにformatMoney(amount: number)とparseAmount(input: string): number | nullを作成し、12や12.5のような単純な正の数値のみを受け入れ、小数点以下2桁に丸め、それ以外はnullを返すこと。この関数を全てのフォームで使用する」といった具体的な関数シグネチャとルールを提示することで、AIは正確な実装を生成できる。

デモデータの日付に関しても、「今月の一週間の現実的なデモデータを追加する」という指示では、月の初旬に実行した場合、デモデータが前月分にまたがってしまい、予算やサマリーの表示とずれる問題があった。これを避けるには、「全ての日付を今月中に収める（月の初旬の場合は1日を使う）」といった具体的な制約を追加する。

チェックポイントは、単に「正常に動作すること」を確認するだけでなく、「壊そうとすること」が重要だ。例えば、「開発サーバーが起動する」という弱いチェックポイントではなく、「localhost:3000を開き、タイトルが明るい背景に表示され、コンソールにエラーがないことを確認する」という具体的なチェックを行うべきだ。最終的なチェックポイントとしては、「npm run lintとnpm run buildを実行し、すべてのエラーを修正する。その後、経費の追加/編集/削除、フィルター、カテゴリの追加/名前変更/削除、予算とバーの色、サマリーと月ボタン、エクスポート/インポート、幅375pxのウィンドウでの表示、各ページのハードリフレッシュを順に確認する」といった、徹底した検証プロセスを組み込むことで、アプリの堅牢性を保証できる。

もしチェックポイントが失敗した場合は、すぐに次のプロンプトに進まず、その症状に特化した「狭い修正プロンプト」をAIに与え、修正が完了したら再度チェックポイントを確認してから次に進むべきだ。AIが「データベースを追加する」など、計画外の変更を提案してきた場合は、それを拒否し、当初の計画に沿って進めることが重要だ。

まとめると、AIにアプリ開発を依頼する際は、プロンプトごとに一つの明確な仕事を与え、ファイル名や関数名などを正確に指定し、AIに選択肢を与えず全てを開発者側で決定する。そして、意図的にバグを誘発するような堅牢なチェックポイントを設けること。さらに、共通のハウスルールはAGENTS.mdのような常に参照される場所に置き、問題が発生した際には、一つずつ具体的な修正プロンプトで対応し、その都度チェックポイントを再確認するという手法が、効率的で堅牢なアプリケーション開発への鍵となる。