メインコンテンツへスキップ
2026-04-21 · 読了 9 分

画像で伝えるバグ報告の完全ガイド

「ページの表示がおかしい」「エラーが出る」「動きません」——こうしたバグ報告を受け取ったことのない開発者はいないでしょう。そこから「どのページですか?どんなエラーですか?何をクリックしましたか?」と3分間のやり取りが始まります。修正そのものは2分で終わるのに、状況を理解するのに10分かかるのです。

注釈を入れたスクリーンショットが1枚あれば、この摩擦のほとんどはなくなります。問題が目に見え、場所も一目瞭然で、手順には番号が振られている。開発者はチケットを開いた瞬間に何が起きているかを把握し、すぐ修正に取りかかれます。

本ガイドでは、ビジュアルなバグ報告について知っておきたいことをひととおり解説します。なぜ有効なのか、どう作れば伝わるのか、最も時間を節約できる注釈のテクニック、そしてどのツールを使えばよいかまでを取り上げます。

バグ報告でスクリーンショットが文章に勝つ理由

文章だけのバグ報告には、根本的な問題が3つあります。

曖昧さ。 「設定ページのボタンが動かない」と言われても、候補は15個あるかもしれません。「通知設定パネルの送信ボタン」まで絞れても、開発者はそこまで画面を移動し、ボタンを探し、再現を試みる必要があります。矢印でボタンを指したスクリーンショットが1枚あれば、その曖昧さは一瞬で解消します。

文脈の欠落。 報告する人は「関係ありそう」と思ったことを書きますが、それが開発者に必要な情報とは限りません。スクリーンショットなら、エラーメッセージ、URL、ブラウザの状態、周囲のUI要素まで、報告者が意識していなくても画面にあるものはすべて記録されます。実際、報告者が一言も触れていなかった部分から原因が判明することは少なくありません。

再現の難しさ。 「クリックしたらエラーになりました」だけでは、開発者は再現できません。「1. 設定を開く、2. エクスポートをクリック、3. このエラーダイアログが出る」のように各手順を番号付きのスクリーンショットで示せば、漠然とした報告が再現可能なテストケースに変わります。

Microsoftとチューリッヒ大学の調査によると、視覚的な添付があるバグ報告は、テキストのみの報告より13〜18%早く解決されています。週に数百件のバグ報告を扱う大きな組織では、この差は膨大な時間になります。

伝わるバグ報告スクリーンショットの条件

スクリーンショットの価値は一律ではありません。注釈のない生のスクリーンショットでも何もないよりはましですが、注釈を入れたものにはかないません。良いビジュアルバグ報告と、優れたビジュアルバグ報告を分けるのは次の5点です。

1. 適切な範囲をキャプチャする

全画面ではなく、範囲指定でキャプチャしましょう。目的は問題の場所が分かる程度の文脈を見せることであって、見る人が問題を探し回るほど広く写すことではありません。UIのバグなら、その部品と周辺だけ。エラーダイアログなら、何をきっかけに出たか分かる程度に背景を含めて撮ります。

2. 問題を指し示す

矢印や丸で、問題の場所をはっきり示します。自分には明らかに見えるバグでも、開発者は他に10件のチケットを抱えているかもしれません。矢印が1本あるだけで、何を報告しているのかが確実に伝わります。

3. テキスト注釈で文脈を補う

短いテキストラベルがあるだけで、多くの誤解を防げます。色が違う箇所には「期待:青/実際:緑」。誤字の横には「ここは『Expprt』ではなく『Export』」。読み込みが遅い部品には「表示まで8秒」。ラベルは短く、1文までに抑えましょう。

4. 手順に番号を振る

再現に一連の操作が必要なバグでは、番号付きの注釈が大きな威力を発揮します。「手順1:設定をクリック。手順2:ダークモードを切り替え。手順3:一番下までスクロール。手順4:この要素が消える」。スクリーンショット上の番号がそれぞれの操作に対応し、視覚的な再現手順書になります。

5. 機密情報を隠す

バグトラッカーに添付する前に、画面に映っている機密情報を確認しましょう。メールアドレス、APIキー、トークン、個人データ、社内URL、データベースの中身などです。バグ報告に載せるべきでないものは、ぼかしやモザイクのツールで隠します。公開されたGitHubのIssueに載る可能性があるスクリーンショットでは、特に重要です。 スクリーンショットのセキュリティガイド で詳しく解説しています。

バグの種類別・注釈のテクニック

レイアウト・CSSのバグ

ずれている要素を四角で囲みます。本来そろうべき位置は線で示しましょう。「期待は16pxの余白、実際は0px」のように具体的な数値をテキストで添えます。DevToolsを開いて算出済みスタイルをキャプチャできるなら、2枚目として添付してください。

機能のバグ

再現手順に番号を振ります。操作の前と後の状態を、それぞれキャプチャしましょう。エラーメッセージが出るなら、全文が見える状態で四角を付けて強調します。ブラウザのコンソールにエラーが見えるなら、それも含めてください。開発者はJavaScriptのエラー、通信の失敗、CORSの問題を必ず確認します。

コンテンツ・文言のバグ

誤っているテキストを丸で囲み、正しい内容をテキスト注釈で書き添えます。誤字なら、該当する単語を矢印で指すだけで十分です。表示されていないコンテンツについては、本来あるべき位置に四角を描き、「欠落:〇〇」とラベルを付けます。

パフォーマンスのバグ

パフォーマンスの問題は、見た目で捉えるのが難しいものです。有効なのは、ブラウザのネットワークタブで遅いリクエストを写すか、パフォーマンスタブで長いタスクを写す方法です。「このリクエストに8.2秒かかっている」のように時間を注釈で添えましょう。カクつくアニメーションなら、スクリーンショットより画面録画のほうが役立ちます。

ブラウザ間の差異によるバグ

スクリーンショットを2枚撮ります。正常に動くブラウザのものと、不具合が出るブラウザのものです。「Chrome 120(正常)」「Firefox 121(不具合)」とラベルを付けて、横に並べるか上下に重ねます。並べて見せるだけで、問題は一目で伝わります。

チームで実践するためのポイント

スクリーンショットツールを統一する。 チーム全員が同じツールを使えば、スクリーンショットの見た目がそろい、どんな注釈機能が使えるかも全員が把握できます。 Maxisnap は、矢印・番号・テキスト・ぼかしといった定番の用途をひととおりカバーしていて、動作も軽くリソース消費で不満が出ないため、チーム利用に向いています。

注釈のルールを決める。 「バグはここ」は赤い矢印、「期待する動作」は緑の矢印、「参考情報」は青い四角、再現手順は番号付きの丸——といった具合です。正式なドキュメントにする必要はなく、5分のチーム内の話し合いで十分。一度決まれば、バグ報告は作るのも読むのも格段に速くなります。

環境情報を含める。 URLバー、ブラウザのバージョン、OSの表示などをスクリーンショットに入れる習慣をつけましょう。範囲指定のキャプチャでは切り落とされがちですが、この情報の有無が、すぐ再現できるか1時間悩むかの分かれ目になります。難しければ、スクリーンショットとあわせて本文に環境情報を書いておいてください。

ファイル添付ではなく、アップロードリンクを使う。 Jiraのコメントに貼られたスクリーンショットのリンクは、その場ですぐ表示されます。一方、5 MBのPNG添付ファイルはクリックしてダウンロードする手間がかかります。 Maxisnap のように自動アップロードに対応したツールなら共有用リンクが自動で生成されるので、バグトラッカーでもSlackでもメールでも、URLを貼るだけで済みます。 SFTPアップロードの設定 は5分で終わり、以後すべてのキャプチャに恒久的なリンクが付きます。

おすすめのツール

ビジュアルなバグ報告に向いたツールには、3つの特徴があります。ホットキーで素早くキャプチャできること、その場で注釈を入れられること(別のエディタに移らずに済むこと)、そしてすぐ共有できること(アップロードまたはクリップボード)です。

  • Maxisnap ——軽快でキーボード中心のキャプチャに、その場での注釈とサーバーへのアップロードを求めるチームに。番号付きの手順やぼかしを含む11種類の注釈ツールを搭載しています。 個人利用は無料
  • Snagit ——高機能な注釈に価値を認め、年額$39 を支払える組織に。手順の番号付けやスマート移動ツールは、ドキュメント作成に非常に優れています。
  • ShareX ——設定の自由度を最大限に求め、複雑さを厭わない開発者に。無料でオープンソースです。
  • Loom ——スクリーンショットでは足りず、短い動画で説明したいときに。画面録画とナレーションの組み合わせは、複雑なバグを伝えるのに強い武器になります。(Monosnapから乗り換える方は、 MaxisnapとMonosnapの比較もあわせてご覧ください。)

良いバグスクリーンショットの費用対効果

ビジュアルなバグ報告は、単に「良い習慣」なのではなく、開発速度に測定できる効果をもたらします。計算してみましょう。

  • テキストのみのバグ報告では、着手までに平均2〜3往復の確認が必要——待ち時間は合計で約15分
  • 注釈付きのスクリーンショットなら、そのやり取りが不要に——バグ1件あたり約15分の節約
  • 週に50件のバグを起票するチームなら、確認のための時間を週に約12.5時間節約できる計算
  • 1年間では、600時間以上の開発者の時間が戻ってくることになります

しかもこの計算は、確認のやり取りに費やす時間しか見ていません。集中が途切れるコストは含まれていないのです。確認が1往復増えるたびに報告者と開発者の双方が作業を切り替えることになり、そのたびに10〜15分の生産的な時間がさらに失われます。

はじめの一歩

バグ報告に注釈付きのスクリーンショットをまだ使っていないなら、今日から始めましょう。 注釈機能のあるスクリーンショットツールをダウンロードして、5分だけ キーボードショートカットを覚えてください。そして次のバグ報告では、長い説明文を書く代わりに注釈を入れてみましょう。

「どのボタンのことですか?」ではなく「直しました、ありがとう——分かりやすいスクリーンショットでした」と返ってきたら、もうテキストだけのバグ報告には戻れなくなります。

これは開発だけの話ではありません。ビジュアルなバグ報告は、ランディングページの表示崩れを追う マーケティングチーム にも同じくらい役立ちます。また、 プロジェクト管理でのバグ報告フロー のページでは、注釈付きのキャプチャを文脈を失わずにJira/Linear/Notionへ流し込む方法を紹介しています。

もっと使いやすいスクリーンショットツールを試してみませんか?

Maxisnapを無料でダウンロードして、その違いを体感してください。

Maxisnapを無料ダウンロード