良いバグレポートの書き方（AIや開発者向け）

良いバグレポートとは、開発者やAIが、あなたが見たのと同じ問題を、あなたに質問せずに確認できるものです。分かりやすいタイトル、再現する正確な手順、期待した結果、実際に起きたこと、コピーした一字一句そのままのエラーメッセージ、そして発生した場所（どのページ、ブラウザ、デバイス、どのユーザーか）が必要です。1つのバグにつき1つのレポートにし、役立つならスクリーンショットを添えてください。

ほとんどのバグは、直すことより理解することに時間がかかります。明確なレポートは、その理解の部分を取り除いてくれます。これはAIツールではさらに重要です。AIは「チェックアウトがおかしい」の意味を、フォローアップの質問で確かめられないので、推測してしまいます。そして、間違った推測は、別の何かを壊すことがあります。

テンプレート

これをコピーして埋めてください。

タイトル: [何が、どこで問題か] 例：「18時以降の時間を予約フォームが拒否する」

再現手順:
1. ...
2. ...
3. ...

期待される結果: [起きるべきこと]
実際の結果: [代わりに起きたこと]

エラーメッセージ: [正確な文言（ある場合）]
場所: [ページ/URL、ブラウザ、デバイス、ログインしていたユーザー]
頻度: [毎回 / ときどき / 1回]
スクリーンショットまたは録画: [添付]

このガイドの残りでは、各パートを説明します。

ステップ1：まず再現する

書く前に、バグをもう一度起こしてみてください。どの手順が重要か、毎回起きるのかが分かります。

• 更新する、またはログアウトして再度ログインするなど、クリーンな状態から始めます。
• 行ったクリックと入力した内容を、1つずつ書き留めます。
• それを引き起こす最も短い経路を見つけようとします。
• 別のブラウザやアカウントで試します。1人のユーザーだけに起きるなら、それは大きな手がかりです。

これについては、AIで作ったアプリをデバッグする方法をご覧ください。

ステップ2：具体的なタイトルを書く

タイトルには、何が、どこで問題なのかを書きます。一覧をざっと見た人が、どのバグか分かるようにするためです。

ステップ3：正確な手順を並べる

番号を付けてください。どのページ、どのボタン、何を入力したかを、文字どおり書きます。

1. 顧客としてログインする（テストアカウント：customer@example.com）。 2.「スターターキット」をカートに入れる。
2. 割引コードWELCOME10を入力し、適用をクリックする。
3. チェックアウトをクリックする。

「コードを使ってチェックアウトしてみる」では、重要なことが抜けてしまいます。どのユーザーか、どの商品か、どのコードか、先に適用されたかどうか、です。

ステップ4：期待と実際

これがレポートの核心です。両方を書いてください。違いこそがバグだからです。

• 期待される結果： チェックアウトのページが開き、合計に10%の割引が表示される。
• 実際の結果： ボタンに1秒ほどスピナーが表示された後、何も起きない。割引コードなしならチェックアウトは動く。

「期待される結果」がないと、読み手はその動作が間違っていることに気づけないかもしれません。「実際の結果」がないと、何を探せばよいか分かりません。

ステップ5：エラーを正確にコピーする

エラーメッセージは、原因への最も速い手がかりです。言い換えず、一字一句そのままテキストとしてコピーしてください。

見つけ方は次のとおりです。

• 画面上： アプリが表示したメッセージ。
• ブラウザのコンソール： 開発者ツール（F12、または右クリック→「検証」）を開き、Consoleタブの赤い行を見ます。
• Networkタブ： 開発者ツールで、失敗したリクエストを見つけ、そのURLとステータスコードを書き留めます（例：POST /api/checkout → 500）。
• サーバーのログ（アクセスできる場合）。

TypeError: Cannot read properties of undefined (reading 'percent') at checkout.ts:48のような1行は、問題をずばり指し示すことがよくあります。

ステップ6：文脈を加える

• 場所： ページのURL、環境（プレビュー、ステージング、本番）。
• 誰か： どのユーザーや役割か。管理者、メンバー、ログアウト中の人など。
• デバイスとブラウザ：「iPhoneのSafari」と「WindowsのChrome」では違いが出ることがあります。
• データ： そのレコードの異常な点。非常に長い文章、特殊文字、大量の項目など。
• いつから始まったか：「昨日の割引コードの変更以降」は非常に有益です。
• 頻度： 毎回か、10回に1回か。

ステップ7：見せる

問題を囲んだスクリーンショットや、短い画面録画は、特にレイアウトのバグで、あいまいさを取り除きます。AIツールが画像を受け付けるなら、添付してください。キーや他人のデータなど、非公開の情報は切り取って隠してください。

AIビルダーへのバグレポート

同じ構成は、そのままプロンプトとして使えます。次の2つを加えると役立ちます。

• 変えてはいけないものを書く。 修正が新たな問題を生まないようにするためです。
• 修正を書くだけでなく、検証するよう頼む。

顧客としてログインし、カートに「スターターキット」があり、コードWELCOME10を適用した状態でチェックアウトをクリックすると、何も起きません。期待：合計が10%引きのチェックアウトページが開く。実際：一瞬スピナーが出た後、何も起きない。ネットワークタブではPOST /api/checkoutが500を返している。コードなしのチェックアウトは動く。原因を見つけて修正してください。ただし、割引コードのない注文の価格計算は変えないでください。その後、パーセント割引のコード、固定額のコード、コードなしの3つでチェックアウトを確認してください。

原因が分からない場合は、まず診断を依頼してください。

まだコードを変更しないでください。このレポートに基づいて、考えられる原因は何か、それぞれを確かめるには何をすればよいかを教えてください。

よくある間違い

• 「壊れている」。 手順も、期待される結果もなく、何に対処すればよいか分かりません。
• 1つのレポートに複数のバグを書く。 一部は直り、他は失われます。
• 言い換えたエラー。 「何か未定義のもの」では、役に立つ部分が隠れてしまいます。
• ユーザーや役割を書き忘れる。 管理者だけに、または新規ユーザーだけに起きるバグも多くあります。
• 欲しい修正だけを書く（「nullチェックを追加して」）。問題ではなく、解決策だけを書いてしまう。
• スクリーンショットやログに、秘密情報を含めてしまう。

チェックリスト

• バグを再現し、最も短い手順を見つけた。
• タイトルで、何が、どこで問題かを示している。
• 手順に番号が付いていて、文字どおり書かれている。
• 期待される結果と実際の結果の両方を書いた。
• エラーメッセージを正確にコピーし、失敗したリクエストとステータスコードも含めた。
• ページ、環境、ユーザー、デバイス、ブラウザを含めた。
• 頻度といつから始まったかを書いた。
• スクリーンショットや録画を、非公開の情報を取り除いて添付した。
• 1つのバグにつき1つのレポートにした。

Mythexのエージェントへのバグ報告

Mythexのプロジェクトでは、レポートがそのままプロンプトになります。いくつかの機能が役立ちます。

• スクリーンショットを添付する。 プレビューやエラー画面のスクリーンショットを、1メッセージにつき最大5ファイルまで添付できます。
• /fix は、エージェントをバグ修正に集中させます。Planモードでは、編集の前に調査させられます。
• /test は、エージェントにプレビュー内で流れを再現させ、見えたものを報告させます。
• この時点に戻すは、状況を悪化させた修正を取り消します。

ドキュメントのプロンプトによるデバッグページでも、同じ手順・期待・実際の構成を使っています。その周りの修正と確認のループについては、AIで作ったアプリを反復して改善する方法をご覧ください。

よくある質問