Microsoft Edgeの開発者ツール活用法：表示崩れと動かない原因を切り分ける

DevToolsは「画面を一時的に調べる」道具

DevToolsには、HTMLやCSSを確認する要素ツール、JavaScriptのエラーを見るConsole、通信を確認するNetwork、画面幅を変えて試すデバイス エミュレーションなどがあります。最初から全部を覚える必要はありません。症状に合うパネルを一つ選びます。

要素ツールで色や余白を変更すると、その場では画面が変わります。しかし、基本的にはページ上での一時的な確認です。原因を特定したら、元のソースファイルを修正し、再読み込みして確認します。

ポイント：Consoleへパスワード、APIキー、顧客情報などの秘密情報を貼り付けないでください。外部サイトで実行するコードや、意味が分からないコードはそのまま貼り付けず、内容を確認してから使います。

開く・閉じる・モバイル表示を切り替える

WindowsのMicrosoft Edgeでは、ページを右クリックして「検査」を選ぶ方法が分かりやすいでしょう。ショートカットならF12またはCtrl＋Shift＋IでDevToolsを開き、Ctrl＋Shift＋Cで要素を選ぶモード、Ctrl＋Shift＋JでConsoleを開けます。

スマートフォン表示を確認するときは、DevToolsのデバイス エミュレーションを使います。実機と完全に同じになるわけではないため、最後は実際のスマートフォンでも、横幅・文字サイズ・タップしやすさを確認します。

要素ツールでHTMLとCSSの原因を探す

表示崩れが起きた場所で右クリックして検査すると、DOMツリー上の対象要素が選択されます。右側のスタイルを見れば、どのCSSが適用されているか、別の指定で上書きされていないかを確認できます。

たとえばカードが想定より広いときは、width、max-width、padding、box-sizing、親要素のdisplayやgridの列数を順番に見ます。いきなり複数の値を変えず、一つだけ変更して結果を確認します。

.card {
  outline: 2px solid tomato;
}

• 対象要素と親要素を確認する
• 適用中のCSSと打ち消されたCSSを比べる
• 一度に一つの値だけ変える
• 原因が分かったらソースファイルを修正する

ConsoleでJavaScriptのエラーと状態を確認する

ボタンを押しても反応しない場合は、Consoleに赤いエラーが出ていないかを確認します。エラーがなければ、ページ上の要素や変数が想定どおり存在するかを小さな式で調べます。

次の例は、見出しの文字と、alt属性がない画像の数を確認するものです。確認用の式は、ページを壊す処理ではなく、読み取るだけの短いものから始めます。

document.querySelector("h1")?.textContent
document.querySelectorAll("img:not([alt])").length

ポイント：エラーの行番号やファイル名を確認してから修正します。エラーが一つとは限らないため、最初に出たエラーを直し、ページを再読み込みして次のエラーを確認する流れが安全です。

Networkで画像・API・ファイルの読み込みを調べる

画像が出ない、データが表示されない、読み込みが遅いといった問題はNetworkで調べます。ページを再読み込みし、一覧から対象のファイルやリクエストを探します。Status、Type、Size、Timing、Responseなどを順番に確認します。

ステータスだけで原因を断定せず、URLが正しいか、リクエストの方法やパラメーターが想定どおりか、返ってきた内容がエラーメッセージになっていないかを見ます。個人情報を含む通信の内容は、公開の場で共有しないようにします。

デバイス エミュレーションでスマホ幅を確認する

デスクトップでは問題がなくても、スマートフォン幅で見出しがはみ出す、ボタンが押しにくい、表が横に切れることがあります。幅を変えながら、本文の折り返し、画像の縮み方、横スクロールの有無、固定表示の重なりを見ます。

表示だけでなく操作も確認します。タップする場所が十分に空いているか、キーボードを開いたときに入力欄が隠れないか、戻る操作で状態が失われないかなど、画面幅に応じた使い方を試します。

• 見出しとボタンが画面内に収まるか見る
• 表やコードは横スクロールできるか確認する
• タップ対象が近すぎないか見る
• 実機での最終確認も行う

SourcesとWorkspaceは、変更を残すときに使う

Sourcesでは、読み込まれたJavaScriptやCSSを確認できます。DevToolsの画面で変更しただけでは、再読み込みやページを閉じたときに消える場合があります。Workspaceなどの対応した環境を使う場合も、どのファイルに変更を保存しているかを確認します。

検証のための一時変更と、本番へ反映する変更を分けると、作業の事故を防ぎやすくなります。変更内容をメモし、元のファイルを保存してから、修正・再読み込み・再確認の順で進めます。

30分で行うデバッグの型

不具合が起きたら、まず発生条件を一文にします。「iPhone幅でメニューを開くと本文が横にずれる」のように書くと、確認する場所が絞られます。次に、要素、Console、Networkの順で、症状に合うものだけを調べます。

修正後は、直った画面だけでなく、同じ操作をもう一度行い、別の幅や別のデータでも問題が起きないか確認します。原因と修正を短く記録しておけば、同じ不具合が再発したときに調査時間を減らせます。

• 現象と再現条件を一文にする
• 症状に合うパネルを一つ選ぶ
• 一つ変更して再現テストする
• 別の幅・データ・操作でも確認する
• 原因と修正を記録する