AIで作ったアプリを壊さずに改良する方法

AIで作ったアプリを壊さずに改良するには、プロンプトごとに変更を1つだけにし、プレビューで確認し、次に進む前にチェックポイントを保存してください。見えているものを説明し、コードがどうなっているかの推測は避けましょう。大きな変更は、実装する前に計画します。変更がうまくいかなかったら、AIに修正を頼むのではなく、最後に正常に動いていたバージョンに戻してください。

アプリの最初のバージョンは数分でできあがることも多いです。難しいのは50回目の変更です。新しいプロンプトのたびに、すでに動いている何かが壊れるリスクがあります。このガイドは、そうならないための進め方を説明します。

改良のループ

1. 変更を1つ選ぶ。 1つの機能、1つのバグ、または1つのページです。
2. ユーザーに見えて、ユーザーができることの観点で説明する。
3. 大きな変更は、先に計画する。 計画を依頼し、読んでから構築します。
4. プレビューで結果を確認する。 変更した箇所と、その周辺の流れを確認します。
5. 保存する。 チェックポイントやコミットを作ります。
6. 繰り返す。

どのステップも、変更を小さく、元に戻せる状態に保つためにあります。

ステップ1：やりたいことのリストを作る

プロンプトを送る前に、変えたいことを重要度の順に書き出してください。1つのメッセージに10個の要望を詰め込むのを防げますし、途中で浮かんだアイデアに「今はやらない」と言う手段にもなります。

大きな変更は分割しましょう。「チームアカウントを追加する」は、チームを作成する、メンバーを招待する、チームを切り替える、データを現在のチームに限定する、というように分けられます。それぞれが独立したプロンプトになります。ユーザーストーリーの書き方は、こうした分割に役立ちます。

ステップ2：見えている状態を伝える

AIは、あなたが伝えない限り画面を見られません。具体的な箇所を指し示し、どうなるべきかを伝えてください。

料金ページをスマートフォンで見ると、Proプランのボタンが右端で切れています。デスクトップのレイアウトはそのままにしてください。640px未満の画面では、カードを縦に並べ、ボタンを横幅いっぱいにしてください。

「料金ページがスマホで見ると見栄えが悪い」と伝えるのと比べてみてください。前者は1回で実装し、確認できます。後者は、頼んでいないデザインの作り直しを招きがちです。

スクリーンショットも役立ちます。ビルダーが画像を受け付けるなら、問題の箇所を添付して丸で囲みましょう。

ステップ3：大きな変更の前に計画する

データモデル、決済、ユーザーの役割など、アプリの複数の部分に関わる変更では、コードを変更する前に計画を依頼してください。

まだコードは変更しないでください。ユーザーがチームに所属し、自分のチームのプロジェクトだけを見られるようにしたいです。変更の計画を立ててください。変わるテーブル、ページ、APIルートはどれか。既存ユーザーのデータはどうなるか。どの順番で作るか。

計画を読んでください。間違っていれば、計画の修正は、作ったものを元に戻すよりずっと安上がりです。

ステップ4：変えてはいけないものを伝える

AIツールは、頼んでいないところまで「整理」してしまうことがあります。動いているものを守りましょう。

注文のテーブルに日付のフィルターを追加してください。テーブルの列、スタイル、エクスポートボタンは変えないでください。

すべての場面で適用されるルール（ブランドカラー、トーン、「確認なしにデータを削除しない」など）は、毎回繰り返すのではなく、AIが毎回読むプロジェクトのメモやナレッジ設定に書いておきましょう。

ステップ5：変更箇所以外も確認する

プロンプトのたびに、次をテストしてください。

• 変更そのもの。 頼んだとおりに動くか。デスクトップとスマートフォンの両方で確認します。
• その周辺。 同じページの他の部分や、同じデータを使う流れ。
• 主要な流れ。 サインアップ、ログイン、主な操作、決済。大きな変更のたびに30秒ほど通しで確認すれば、ほとんどの破損を早期に見つけられます。

何かおかしければ、正確に報告しましょう。良いバグ報告の書き方を参照してください。

ステップ6：修正を重ねず、戻す

変更で何かが壊れ、最初の修正がうまくいかないときは、そこで止まってください。壊れた状態の上にさらに「修正」を重ねると、問題が積み重なります。

代わりに次の手順を行います。

1. 最後に正常に動いたバージョン（チェックポイントやGitのコミット）に戻す。
2. プロンプトのどこがわかりにくかったかを考える。
3. より小さく、より明確な依頼で、もう一度試す。

前回の変更で下書きの保存が壊れたので、元に戻しました。今回は、ヘッダーに自動保存の表示を文字で追加するだけにしてください。下書きの保存の仕組みは変えないでください。

ステップ7：作り直すのが正しい場合を知る

ゼロから作り直すと、動いている細かい部分の多くを失います。作り直す価値があるのは次の場合だけです。

• 製品のアイデアが根本的に変わった。
• 基盤の構造が、今必要なことを支えられない。例えば、静的サイトとして作られたものに、アカウントやデータベースが必要になった場合。
• プロジェクトがまだほとんど空の状態にある。

作り直すときは、残すものを書き出してください。名前、色、コピー、ユーザーに好まれた部分などです。

プロンプトの例

続ける前に、現在のアプリの仕組みを要約してください。ページ、保存しているデータ、壊れやすいと思う箇所を含めてください。

定期予約を追加したいです。役立つ最小限の形はどれですか？ 1つずつ実施できる、3つの独立した変更として提案してください。

直近の3つの変更について、チェックアウトの流れを壊している可能性がある箇所を確認してください。まだ編集しないでください。

よくあるミス

• 1つのプロンプトに10個の依頼を入れる。 一部だけ完了し、どこが完了したかわからなくなります。
• 曖昧なフィードバック。 「壊れている」「もっと良くして」では、AIは推測するしかありません。
• 周辺を確認しない。 共有コンポーネントを変えたら、他の3つのページが壊れていることがあります。
• 修正の上に修正を重ねる。 バグに4回プロンプトを重ねたら、戻しましょう。
• 標準的なルールをプロジェクトのメモに書かず、毎回説明し直す。
• 行き詰まったら作り直す。 「最初からやり直す」と感じる場面の多くは、実際には2ステップ戻せば済みます。

チェックリスト

• プロンプトごとに目標は1つ。
• 見えている状態と、あるべき状態を伝えている。
• 大きな変更は、コードの前に計画を立てている。
• 変えてはいけないものを伝えている。
• 変更ごとに、変更箇所、その周辺、主要な流れを確認している。
• うまくいった変更のたびに、チェックポイントかコミットを保存している。
• 修正が失敗したら、修正を重ねずに戻している。
• 標準的なルールは、AIが毎回読むプロジェクトのメモに書いている。

Mythexでの改良

Mythexは、この進め方を中心に作られています。

• Plan、Build、Askモード。 Planでは、編集する前にアプローチを話し合えます。Askでは、コードを変えずに回答します。Buildで変更を実装します。チャットを参照してください。
• チェックポイント。 成功したターンのあとに、Mythexがgitのチェックポイントを保存します。この時点に戻すで元に戻せます。以前のメッセージを編集して破棄して再送信すれば、その時点から別のプロンプトを試せます。作り直さずに改良するを参照してください。
• ナレッジ。 プロジェクト設定 → ナレッジには、エージェントがすべてのメッセージで従う常設のメモを保存できます。
• /test。 大きな変更のあとに、エージェントがプレビューをユーザーとして操作し、動作を確認します。

小さな依頼は、クレジットの消費も少なくなります。プロンプトの書き方そのものは、AIアプリビルダー向けのプロンプトの書き方を、壊れたときの対処はAIで作ったアプリのデバッグ方法を参照してください。

よくある質問