AIで作ったアプリのデバッグ方法：実践的な手順

AIで作ったアプリをデバッグするには、まずバグを意図的に再び起こし、証拠を集めます。正確な手順、エラーメッセージ、ブラウザのコンソールとネットワークタブに表示されている内容です。そして、それを「Xをして、Yを期待したが、Zになった」という形でAIに伝えます。修正によって状況が悪化したら、修正を重ねるのではなく、最後に動いていたバージョンに戻してください。コードを読めなくても、これらはうまく行えます。

このガイドでは、一連の流れ全体と、技術者ではない人のためのブラウザ開発者ツールの概要を扱います。

デバッグの流れ

人が修正する場合でもAIが修正する場合でも、バグ修正は同じ流れに従います。

1. 再現する — バグを確実に起こす。
2. 観察する — エラーメッセージと、アプリが何をしていたかを集める。
3. 説明する — AIに、正確な手順、期待する結果、実際の結果を伝える。
4. 修正する — AIに一つのことだけ変えてもらう。
5. 検証する — まったく同じ手順を繰り返し、直ったことと、近くの機能が壊れていないことを確認する。
6. 必要なら巻き戻す — 悪化したら元に戻し、より良い情報を伝えて、やり直す。

AIで作ったアプリで時間を無駄にする最大の原因は、手順1、2、5を飛ばすことです。「壊れている」と言うだけ、変更をテストせずに受け入れる、そして壊れた状態の上に次の修正を重ねる、といったことです。

手順1：バグを再現する

いつでも起こせるバグは、半分直ったようなものです。バグを引き起こす最も短い手順を見つけてみましょう。

次の点を自問してください。

• 毎回起きるか？ たまにしか起きないなら、起きたときに何が違うのか。特定のレコード、遅い接続、ログアウトしていることなど。
• すべてのユーザーに起きるか？ 別のアカウントでログインしてみてください。多くのバグは、新規ユーザーでデータがない場合や、役割が違うユーザーでだけ表示されます。
• すべての端末で起きるか？ スマホ幅の画面や、別のブラウザで試してください。
• 特定の変更の後に起きたか？ 昨日まで動いていたなら、直近の数回の変更が一番の疑わしい原因です。

手順を短い番号付きリストに書き出しましょう。後でプロンプトに貼り付けます。

手順2：エラーメッセージを読む

エラーメッセージは難しそうに見えますが、必要な部分は数箇所だけです。

理解する必要はありません。正確にコピーすることが大切です。「Cannot read properties of undefined (reading 'name')」は、コードが期待していたデータ（予約やユーザーなど）が存在しなかったことをAIに伝えます。「何か未定義のエラー」のように言い換えると、その情報が失われてしまいます。

よくあるものをざっくり訳すと次のとおりです。

• undefined / null のエラー — コードが期待したデータが届かなかった。読み込み中の状態や、空のリストをコードが処理していないことが多い。
• 404 Not Found — ページやAPIのアドレスが存在しない。ルートのタイプミスや、名前が変わったページへのリンクであることが多い。
• 401 Unauthorized / 403 Forbidden — リクエストがログインしていない、またはユーザーにその操作の権限がない。
• 500 Internal Server Error — サーバー側のコードがクラッシュした。本当の理由はブラウザではなく、サーバーのログにある。
• CORS のエラー — ブラウザが別のドメインへのリクエストをブロックした。通常はサーバー側の設定の問題。

手順3：ブラウザの開発者ツールを使う

どのデスクトップブラウザにも、標準の開発者ツール（「デベロッパーツール」）が備わっています。ページの裏側で何が起きているかを表示します。Chrome、Edge、Firefoxでは、ページのどこかを右クリックして**「検証」**を選ぶか、F12（Macの場合はCmd+Option+I）を押します。Safariでは、先に設定で「開発」メニューを有効にしてください。

必要なのは3つのタブだけです。

コンソール

コンソールタブには、ページのコードからのエラーやメッセージが表示されます。エラーは赤で示されます。ボタンを押しても何も起きない場合、クリックした瞬間に赤いエラーがコンソールに表示されることがよくあります。エラーの全文をコピーしてください（ほとんどのブラウザでは、右クリックでコピーのオプションが表示されます）。

ネットワーク

ネットワークタブには、ページが送信するすべてのリクエストが表示されます。データの読み込み、フォームの保存、ログインなどです。開いてから、バグを起こす操作を繰り返してください。

• 赤い行や、ステータスが400以上の行を探してください。
• 失敗した行をクリックすると、そのレスポンスが見られます。サーバーのエラーは、画面上のどんなものよりも役立つメッセージを含んでいることがよくあります。
• リクエストのURLとステータスコードをメモしてください。「/api/bookingsへのPOSTが500を返した」という一文は、AIに伝えるととても有用です。

バグにページの再読み込みやリダイレクトが関係する場合は、ログを保持にチェックを入れて、リクエストが消えないようにしてください。

要素

要素（またはインスペクター）タブには、ページの構造とスタイルが表示されます。レイアウトのバグに最も役立ちます。要素の上にカーソルを置くと、そのサイズと余白がハイライトされます。ここで編集する必要はありません。「モバイルでフッターの幅が2,000ピクセルになり、ページが横にはみ出している」と伝えるだけで十分です。

手順4：サーバーのログを確認する

バグの中には、ブラウザからは見えないサーバー側で起きるものもあります。ネットワークタブの500エラーは典型的な兆候です。サーバーのログ（バックエンドが動作中に出力するテキスト）には、通常、本当のエラーがスタックトレース（失敗したときに実行されていた関数の一覧）とともに含まれています。

その場所はツールによって異なります。多くのAIアプリビルダーでは、プロジェクトのターミナルやログの表示を開けます。または、AIにこう頼むだけでもかまいません。「直近のリクエストからのサーバーログのエラーを確認して、何が失敗したか教えてください。」

手順5：AIにバグを説明する

集めた情報を、次の形にまとめてください。

予約ページで、会員としてログインした状態で、明日9:00のクラスのキャンセルをクリックしました。期待する結果：予約が消え、クラスの空きが1つ増える。実際の結果：画面上で何も変わらない。コンソールにはBookingCard.tsx:31でTypeError: Cannot read properties of undefined (reading 'id')が表示されており、ネットワークタブではDELETE /api/bookings/123が500を返しています。原因を見つけて修正し、予約が1件の会員と複数件の会員の両方でキャンセルが動くことを確認してください。

各部分の役割は次のとおりです。

• どこで、どの役割では、対象の画面と役割を絞り込みます。
• 正確な手順は、AIがバグを再現できるようにします。
• 期待と実際は、「直った」の意味を定義します。
• エラーの文言と失敗したリクエストは、原因を直接指し示します。
• **「確認してください」**は、AIに編集だけでなく検証も求めるものです。

AIが2回修正を試みて失敗した場合は、何かを変える前に説明するよう求めてください。

まだコードは変えないでください。何がこの問題の原因だと考えますか？ そう考える根拠は何ですか？

間違った推測は、文章にしてみると見抜きやすく、間違った修正を直すよりずっと安上がりです。

手順6：検証し、周辺も確認する

AIが「直った」と言ったら、手順1の正確な手順を繰り返してください。そして、その周囲も確認します。

• 別の役割のユーザーで、同じ操作をする
• データがない場合と、大量にある場合で、同じ操作をする
• 修正したものとコンポーネントを共有している他のページ
• レイアウトに手を入れたなら、スマホ幅の画面

AIによる変更は、ある経路を直す一方で、別の経路をこっそり壊すことがあります。今2分確認すれば、後で混乱した1時間を防げます。

手順7：積み重ねず、巻き戻す

修正で状況が悪化した場合や、3回やり取りしても進まない場合は、元に戻してください。最後に動いていたバージョンに巻き戻し、より良い証拠を添えて言い直すほうが、3回の失敗の上に4回目の修正を重ねるよりほぼ確実に効果的です。失敗するたびに残ったコードが、次の試みを混乱させるからです。

巻き戻しを簡単にする良い習慣は次のとおりです。

• 変更するたびに必ずテストする。どの変更が壊したかが分かります。
• 変更は小さく保つ。1メッセージにつき1つの機能または修正。
• 危険なことを始める前に、最後に動いていたバージョンを記録しておく。
• コードがGitにある場合は、動くバージョンをコミットしておく。そこに戻れます。

AIで作ったアプリによくあるバグのパターン

バグではない場合

「バグ」の中には、AIが指示どおりに作ったものの、説明が曖昧だったというものもあります。修正したいことが実際には動作の変更なら、はっきりそう伝えてください。「〜になるように変えてください」。正しい動作そのものが分からなくなったら、まずそれを決めてください。ルールを明確に指定する方法については、AIアプリビルダーへのプロンプトの書き方を参照してください。実際のユーザーのためにアプリを準備しているなら、AIのプロトタイプを本番環境に移す方法で、公開前に確認すべきことを扱っています。

Mythexでのデバッグ

Mythexには、流れの各手順に対応するツールがあります。

• プレビュー：スマホ幅の枠を含め、バグを再現できます。
• /test：エージェントがライブプレビューをユーザーのように操作し、壊れた流れを報告します。
• /fix：エージェントに、壊れている箇所を指定して修正させます。
• プランモード：エージェントが、何かを編集する前に調査して説明します。
• コード → ターミナル：アプリのサーバーログを表示します。
• この時点に戻す：どの返信でも、その時点のチェックポイントにプロジェクトを巻き戻せます。

公開に失敗した場合、公開ダイアログには通常AIで修正が表示されます。これはビルドの出力やアプリのログを読みます。ドキュメントのアプリのデバッグと公開のトラブルシューティングを参照してください。

よくある質問