なぜ「再現HTML」を渡すと話が早いのか
バグ報告でよくあるすれ違いは、QAの環境では起きるのに開発者の手元では再現しない、というものです。OSやブラウザのバージョン、特定の入力データ、画面サイズなど、再現条件は細かく、文章やスクリーンショットだけでは伝わりきりません。結果として「再現できないので一旦クローズ」となり、調査が後回しになります。
そこで有効なのが、不具合が起きている画面のHTMLやアセット一式をそのまま渡す方法です。問題のマークアップ・CSS・スクリプトを切り出した最小の再現ファイルがあれば、開発者は受け取った瞬間に同じ崩れや挙動を目の前で確認できます。原因の切り分けが「再現できるか」から「どこが原因か」に一気に進みます。
ただし、メールにZIPを添付したり、チャットにファイルを貼ったりする運用は、相手が解凍して開く手間がかかり、画像やCSSのパスがずれて見た目が変わることもあります。クリックひとつで開ける共有URLにしておくと、この摩擦をまとめて減らせます。
- 文章だけだと再現条件が伝わらず差し戻されやすい
- 再現HTMLがあれば実際の崩れや挙動を即確認できる
- ZIP添付は解凍やパスずれの手間が残る
共有前に再現HTMLを整える
まずは不具合に直接関係する部分だけを残した、最小の再現ファイルを用意します。本番のページ全体ではなく、問題のコンポーネントや画面だけに絞ると、開発者が原因にたどり着くまでが短くなります。CSSや画像、JavaScriptが必要なら、それらをまとめてZIP（HTML/CSS/JS/画像一式）にしておくと、相互参照が崩れません。
再現に必要な前提も添えておくと親切です。たとえば「Safariの最新版で、画面幅375pxのとき送信ボタンが重なる」のように、ブラウザ・画面サイズ・操作手順をひとことメモしておくと、受け手はピンポイントで確認できます。再現ファイル自体に短いコメントを書き込んでおくのも有効です。
本番のソースを切り出す際は、誤って機密情報を含めないよう注意します。社内向けのURLや、ソースに残ったままのキーらしき文字列などが混ざっていないか、共有前に一度見直しておきましょう。
この業務で使うときのおすすめ設定
QAがバグ再現HTMLを開発に素早く共有を業務で使うなら、共有前・レビュー中・差し替え・クローズの4段階で考えると運用しやすくなります。成果物を作るだけでなく、誰がいつ何を確認したら完了なのかを先に決めます。
対象読者がそのまま使える依頼文テンプレ、推奨認証方式、公開期限、レビュー完了条件を追加。 レビュー中は新しいリンクを何度も作るより、同じURLで差し替えて「最新版はこのURL」と統一すると確認漏れを減らせます。
- 共有前: HTML/ZIP、表示崩れ、機密情報、認証方式を確認する
- レビュー中: 観点、締切、返信先、差し替えルールを明記する
- 差し替え: 同じURLで更新し、最新版だけを見てもらう
- クローズ: 承認後に期限切れ・非公開化・最終版保存を行う
ギガサイト便で再現HTMLを共有する手順
ここからは、再現HTMLを共有URLにする具体的な流れです。サーバーの用意やデプロイ設定は必要ありません。アップロードした静的ファイルが、そのまま認証付きの共有URLとして開けるようになります。
- 再現用のHTML単体、またはアセット込みのZIPを用意する
- トップページのアップロード欄にファイルをドロップする
- 登録なしでもその場で共有URLが発行される（匿名公開はnoindex・7日間の期限・IPレート制限あり）
- 社内限定にしたい場合は無料アカウントを作り、会社ドメイン認証やパスワード認証を選ぶ
- 発行されたURLをIssueやチャットの不具合チケットに貼る
- URL末尾のスラッグを「bug-1234」のように分かりやすく編集しておく
誰に見せるかを認証方式で選ぶ
再現HTMLには、画面の文言や内部の挙動など、社外に出したくない情報が含まれることがあります。共有時は閲覧できる相手を絞れると安心です。リンクを知っていれば誰でも見られる「URLのみ」のほか、合言葉を共有する「パスワード認証」、指定したメール宛のワンタイムで本人確認する「メール認証」が選べます。
社内の開発メンバーだけに見せたいなら、指定したメールドメインを持つ人だけが閲覧できる「会社ドメイン認証」が便利です。チームの全員に同じ合言葉を配らなくても、社員のアドレスで認証すれば見られるため、運用がシンプルになります。
なお、匿名公開ページにはnoindexが付き、通常は検索結果に出ません。ただしnoindexは検索避けであってアクセス制御ではない点に注意してください。本当に見せたい相手を限定したいときは、必ず認証方式を設定しましょう。
- URLのみ: リンクを知る全員が閲覧
- パスワード認証: 合言葉を知る人だけ
- メール認証: 指定アドレス宛のワンタイムで本人確認
- 会社ドメイン認証: 指定ドメインの社員だけ
修正サイクルを回しやすくする工夫
バグ調査は一度で終わらず、追加の確認や別パターンの再現が続くことがあります。同じURLのままファイルを差し替えられるので、再現ケースを追加したり、最小化を進めたりしても、リンクを送り直す必要がありません。チケットに貼ったURLをそのまま使い回せます。
対応が終わったら公開期限を設定しておくと、期限切れで自動的に閲覧できなくなり、古い再現ファイルが残り続けるのを防げます。誰がいつ開いたかはアクセスログで確認できるため、開発側が見たかどうかの確認にも役立ちます。
アップロード時にはセキュリティスキャンが走り、キーらしき文字列・外部フォーム送信・外部スクリプト依存・静的公開に不要なファイルなどの兆候を検出して警告します。再現ファイルに残っていた不要な情報に気づくきっかけになります。内容を理解したうえで公開するかを選べます。
共有時に押さえておきたい前提
公開されるのはあくまで静的なHTMLです。PHPなどのサーバーサイド処理は動かないため、サーバー処理に依存するバグをそのまま再現したい場合は、フロント側で起きている現象に絞って切り出す必要があります。フォームの送信結果を保存するような挙動も、静的公開では再現できません。
とはいえ、表示崩れ・レイアウトのずれ・JavaScriptの動作不良といった、フロントエンドで完結する不具合の多くはこの方法で十分に共有できます。実機の画面そのものを相手に届けられるので、口頭やスクリーンショットでのやり取りより誤解が減ります。
再現条件のメモと認証設定をセットにして渡せば、QAから開発への引き継ぎはぐっとスムーズになります。差し戻しの往復を減らし、調査の初速を上げる手段として、再現HTMLの共有URL化は試す価値があります。
よくある質問
バグ報告にスクリーンショットを添えても再現できないと言われます。どうすれば伝わりますか
不具合が起きている画面のHTMLやアセット一式を、そのまま共有URLにして渡すのがおすすめです。受け手はクリックするだけで同じ崩れや挙動を再現できます。あわせてブラウザ・画面サイズ・操作手順を短くメモしておくと、確認がさらに速くなります。
再現HTMLを社外に見られたくありません。アクセスを絞れますか
認証方式を選べます。パスワード認証、指定アドレス宛のメール認証のほか、指定したメールドメインを持つ人だけが閲覧できる会社ドメイン認証を使えば、社内の開発メンバーに限定できます。検索避けのnoindexはアクセス制御ではないため、限定したい場合は必ず認証を設定してください。
再現ケースを追加したいとき、URLを送り直す必要がありますか
同じURLのままファイルを差し替えられるので、送り直しは不要です。チケットに貼ったリンクをそのまま使い回せます。対応が終わったら公開期限を設定しておくと、期限切れで自動的に閲覧できなくなり、古い再現ファイルが残りません。
サーバー処理が絡むバグも再現できますか
公開されるのは静的なHTMLのため、PHPなどのサーバーサイド処理やフォームの受信保存は再現できません。一方で、表示崩れやJavaScriptの動作不良など、フロントエンドで完結する不具合は十分に共有できます。サーバー依存の現象はフロント側に切り出して渡すとよいでしょう。
レビュー完了の条件はどう決めるとよいですか？
確認観点、締切、承認者、差し替え後の再確認有無を先に決めます。「誰がOKと言ったら完了か」を明確にすると、共有URLが増えても混乱しにくくなります。