- 「表示が崩れている」
- 「フォームが送信できない」
- 「この画像だけ表示されない」
こうした報告を受けたとき、いきなり制作会社へ連絡する前に、自分で状況を切り分けられると仕事が一段速くなります。
そのための道具が、Chromeに最初から入っているデベロッパーツール(Chrome DevTools)です。追加インストールは不要で、右クリックの「検証」から今すぐ開けます。
ただし、はじめて開いた人のほとんどは、英語だらけの画面に圧倒されてそっと閉じます。原因はシンプルで、「どのタブが、どの疑問に答えてくれるのか」を知らないまま開いているからです。
Takumaこの記事では、タブの網羅的な解説ではなく、Web運用の現場で実際に発生する疑問から逆算して説明します。
\ サイト診断が無料で行えます!ぜひ試してみてください /
Chromeデベロッパーツールとは?


結論から言うと、Chromeデベロッパーツールは「今見ているWebページが、実際にどうなっているのかを調べるための検査ツール」です。



ページを直す道具ではなく、状態を確認して原因を絞り込む道具だと考えてください。
Chromeに標準搭載されたWebページの検証ツール
Chromeデベロッパーツールは、Google Chromeに最初から組み込まれている機能です。
拡張機能のインストールも、アカウント登録も、費用も不要です。
確認できる主な内容は、次のとおりです。
- HTMLの構造(見出し、リンク、alt属性、構造化データなど)
- CSS(色、余白、文字サイズ、どのルールが効いているか)
- JavaScriptのエラーや警告
- サーバーとの通信内容(HTTPステータス、リダイレクト、読み込み時間)
- スマホ・タブレット幅での表示
- Cookie、Local Storage、キャッシュ
- ページの表示速度や品質スコア
「エンジニア向け」という印象が強いツールですが、実際に日々使うのはSEO担当者、Web担当者、広告運用者、WordPressサイトの管理者といった非エンジニアです。
コードを書けなくても、状態を読み取るだけで十分に実用的だからです。


Chrome DevToolsとデベロッパーツールは同じもの
検索していると複数の呼び方が出てきますが、指しているものは同じです。
| 表記 | 補足 |
|---|---|
| Chrome DevTools | 公式ドキュメントでの正式な呼び方 |
| Chromeデベロッパーツール | 日本語記事で最も一般的 |
| Chrome開発者ツール | Chromeメニュー内の日本語表記 |
| 検証(けんしょう) | 右クリックメニューの項目名 |
| インスペクタ/Inspect | 英語UIでの呼び方 |
「検証を開く」も「DevToolsを開く」も「F12を押す」も、すべて同じ画面を開く操作です。
呼び方の違いで混乱する必要はありません。
なお、似た名前で「Chrome DevTools Protocol」「Chrome DevTools MCP」というものもありますが、これらは自動操作や外部ツール連携のための仕組みで、今回扱う手動の検証作業とは目的が異なります。この記事では触れません。
DevToolsはテスト環境ではない
ここが最も重要な前提です。
DevToolsで加えた変更は、原則としてページを再読み込みした時点で消えます。そして本番サイトには一切保存されません。
Chrome公式ドキュメントでも、Elementsパネルで行ったDOMツリーへの変更はDevToolsが保存しない、と明記されています(後述するLocal Overridesは例外的な仕組みです)。
つまり、DevToolsの役割は次の4つに整理できます。
- 状態の確認
- 一時的な編集(見た目のシミュレーション)
- 仮説検証
- 不具合の切り分け
実務での使い分けは、次の流れが基本です。
- DevToolsで仮説を試す
- ローカル環境で実際に修正する
- ステージング環境で本番前に確認する
- 本番へ反映する
| 項目 | Chrome DevTools | ローカル環境 | ステージング環境 | 本番環境 |
|---|---|---|---|---|
| 主な用途 | 状態確認・一時編集・原因切り分け | コードの実際の修正 | 公開前の最終確認 | 一般公開 |
| 変更の保存 | 原則保存されない(再読み込みで消える) | ファイルに保存される | 保存される | 保存される |
| 影響範囲 | 自分のブラウザの表示のみ | 自分のPCのみ | 関係者のみ | 全ユーザー |
| PHPやDBの修正 | できない | できる | できる | できる |
| 失敗したときのリスク | ほぼゼロ | 小さい | 中程度 | 大きい |
DevToolsは壊す道具ではありません。何を触っても、再読み込みすれば元に戻ります。初心者ほど「触ってはいけない」と身構えますが、実際は逆で、遠慮なく触りながら覚えるのが最短ルートです。


Chromeデベロッパーツールの開き方
開き方は3通りありますが、実務では「右クリック→検証」と「ショートカット」の2つを覚えれば十分です。
右クリックの「検証」から開く
最も直感的で、初心者に一番おすすめの開き方です。
- 調べたい部分(見出し、ボタン、画像など)の上にマウスカーソルを置く
- 右クリックする
- メニュー最下部付近の「検証」をクリックする


この方法の利点は、クリックした要素のHTMLが最初から選択された状態で開くことです。「このボタンのHTMLが見たい」という目的なら、これが最短です。



なお、Chromeのメニューからは「⋮(三点リーダー)→ その他のツール → デベロッパー ツール」でも開けます。
ショートカットキーで開く
慣れてきたらショートカットのほうが速いです。よく使う4つだけ覚えてください。
| 操作 | Mac | Windows |
|---|---|---|
| DevToolsを開く/閉じる | Command + Option + I | F12 または Ctrl + Shift + I |
| 要素選択モード(クリックした要素を調べる) | Command + Shift + C | Ctrl + Shift + C |
| Consoleを開く | Command + Option + J | Ctrl + Shift + J |
| デバイスモード(スマホ表示)の切り替え | Command + Shift + M | Ctrl + Shift + M |
| コマンドメニューを開く | Command + Shift + P | Ctrl + Shift + P |
| キャッシュを無視して再読み込み | Command + Shift + R | Ctrl + Shift + R |
特にコマンドメニュー(Command/Ctrl + Shift + P)は覚える価値が高いショートカットです。
機能名の一部を入力すれば、どのパネルにあるかを知らなくても目的の機能を呼び出せます。後述するフルサイズのスクリーンショットも、ここから実行します。
表示位置を変更する
DevToolsが画面の右半分を占領して、ページ本体が細長くなってしまう、初心者が最初につまずくのがこれです。
表示位置は自由に変えられます。
- DevTools右上の「⋮」(Customize and control DevTools)をクリックする
- Dock side の並んだアイコンから位置を選ぶ


選べる位置は4つです。
- 右側(Dock to right):スマホ表示の確認に向く。縦に長い領域を確保できる
- 下側(Dock to bottom):Networkパネルなど横に長い表を見るときに向く
- 左側(Dock to left):右利きの視線移動を減らしたい人向け
- 別ウィンドウ(Undock into separate window):DevToolsだけを別ウィンドウに切り離す。デュアルディスプレイ環境なら圧倒的に見やすい
「別ウィンドウ」は特に、モニターが2枚ある環境で威力を発揮します。



片方の画面にサイト、もう片方にDevToolsという配置にすると、ページを狭めずに検証できます。
Chromeデベロッパーツールを日本語化する方法
DevToolsのUIは日本語表示に切り替えられます。Chrome 94以降、日本語を含む80以上の言語に対応しました。
- DevToolsを開く
- 右上の歯車アイコン(Settings)をクリックする(
F1でも開けます) - 左メニューのPreferences(基本設定)を選ぶ
- Appearance(外観)セクションのLanguageを「日本語 – Japanese」に変更する
- 上部に表示される「Reload DevTools」をクリックする
「Browser UI Language」を選ぶと、Chrome本体の表示言語に自動で合わせられます。




日本語化すると初心者には読みやすくなりますが、トラブル解決時の情報量は英語のほうが圧倒的に多いという副作用があります。
エラーメッセージや機能名で検索する機会が増えたら、英語表示に戻すことも検討してください。この記事では、検索しやすさを優先して英語の機能名を併記しています。


ElementsでHTML・CSSを一時編集する方法


Elementsパネルは、今表示されているページのHTMLとCSSを確認し、その場で書き換えて見た目を試せる機能です。
「この見出しを1行短くしたらどう見えるか」「ボタンの色を変えたら目立つか」を、制作会社に依頼する前に自分で試せます。
調べたい要素を選択する
まず、調べたい部分のHTMLにたどり着く必要があります。手順は次のとおりです。
- DevToolsを開く
- 左上の矢印アイコン(要素選択モード)をクリックする(
Command/Ctrl + Shift + C) - ページ上の見出しやボタンにマウスを乗せる
- 青くハイライトされ、要素名とサイズが表示される
- クリックすると、対応するHTMLがElementsパネル内で選択される
画面下部にはパンくず表示(例:body > div.container > main > h2)が出ます。これは「今選んでいる要素が、どの階層にあるか」を示すもので、親要素を選び直したいときに便利です。
クリックしたつもりが、目的の要素より内側(<span>など)や外側(<div>)が選ばれることがあります。その場合はキーボードの ↑ ↓ でHTMLツリー内を移動して、目的の要素を選び直してください。
見出しやボタンの文章を仮編集する
文言変更の効果は、実際に画面へ入れてみないと判断できません。DevToolsなら30秒で試せます。


- Elementsパネルで、変更したいテキスト部分をダブルクリックする
- 文字が編集可能になるので、新しい文言を入力する
Enterを押す- ページ上の表示が即座に切り替わる
タグごと書き換えたい場合は、要素を右クリックして「Edit as HTML」(Macは F2 でも可)を選ぶと、HTMLをまとめて編集できます。


左側のページ表示と、右側のHTMLが連動している点に注目してください。HTMLを書き換えた瞬間に、左のページ表示も変わります。
この変更は、ページを再読み込み(F5)した瞬間に消えます。



本番サイトには一切影響しません。だからこそ、キャッチコピーのA/B案を関係者に見せる、CTAボタンの文言を短くして収まりを確認する、といった用途に安心して使えます。


CSSを一時変更する
Elementsパネルの右側(または下側)にあるStylesペインで、CSSを書き換えられます。
- 要素を選択する
- Stylesペインで、変更したいプロパティの値をクリックする
- 値を入力し、
Enterで確定する - 何も適用されていないプロパティを追加したいときは、
element.style { }の中括弧内をクリックして入力する
初心者がまず試すとよいのは、次の7つです。
| プロパティ | 何が変わるか | 入力例 |
|---|---|---|
color | 文字の色 | #333333 |
background-color | 背景色 | #f5f5f5 |
font-size | 文字サイズ | 18px |
margin | 要素の外側の余白 | 24px 0 |
padding | 要素の内側の余白 | 16px |
width | 横幅 | 320px |
display | 表示形式(noneで非表示) | none |
カラーコードの変更が最も分かりやすい入り口です。
color や background-color の値の左には小さな四角い色見本があり、これをクリックするとカラーピッカーが開きます。スポイトツールでページ内の色を拾うこともできるので、「このボタンの色、他の要素と揃っているか」の確認にも使えます。
余白の調整もよく使います。Stylesペインの一番下にあるBox Model(入れ子の四角形の図)は、margin・border・padding・content の実測値を表示します。数値部分をダブルクリックすれば、その場で変更できます。
「なんとなく詰まって見える」という感覚的な違和感を、具体的な数値に翻訳してくれる図です。


カラーコードの左にある色見本アイコンをクリックすると、カラーピッカーが開きます。数値を打たなくても色を試せるので、非エンジニアはここから始めるのがおすすめです。
変更したはずなのに反映されない場合、そのプロパティに取り消し線が引かれていないかを確認してください。
取り消し線は「より優先度の高い別のCSSに上書きされている」というサインです。この場合は、上書きしている側のルールを探す必要があります。


画像や要素を一時的に非表示にする
「このバナーを消したら、ページの印象はどう変わるか」を確認する方法です。
- 要素を選択して
Hキーを押す(表示・非表示のトグル) - または Stylesペインで
display: none;を追加する - 完全に削除して試したい場合は、要素を選択して
Deleteキー
削除してしまっても、再読み込みすれば元に戻ります。
要素の要不要を議論するとき、口頭で説明するより「消した状態のスクリーンショット」を見せたほうが早く決まります。
HTMLやCSSの変更は保存できるのか
結論として、Elementsパネルでの編集は保存されません。
Chrome公式ドキュメントも、ElementsパネルのDOMツリーへの変更はDevToolsが保存しない仕様であることを明記しています。
一方で、Local Overrides という機能を使えば、変更内容をローカルのフォルダに保存し、再読み込み後も維持できます。
ただしこれもあくまで自分のブラウザ内での話で、本番サイトのファイルが書き換わるわけではありません。詳しくは後半の章で説明します。
| 方法 | 再読み込み後 | 本番サイトへの反映 | 難易度 |
|---|---|---|---|
| Elements編集 | 消える | されない | かんたん |
| Local Overrides | 残る(自分のPCのみ) | されない | 応用 |


Chromeデベロッパーツールでスマホ表示を確認する方法


スマホからのアクセスが大半を占める今、スマホ表示の崩れは直帰率とコンバージョンに直結します。
DevToolsのデバイスモード(Device Mode)を使えば、実機がなくても幅を変えた表示を確認できます。
デバイスモードを起動する
- DevToolsを開く
- 左上のスマホとタブレットが重なったアイコン(Toggle device toolbar)をクリックする
- ショートカットは
Command + Shift + M(Mac)/Ctrl + Shift + M(Windows)
起動すると、ページ表示エリアの上部に「Dimensions」「幅 × 高さ」「Zoom」などのツールバーが現れます。
iPhone、Pixel、Galaxy、iPadへ切り替える
ツールバー左端のDimensionsプルダウンから、端末を選びます。標準では iPhone、Pixel、Samsung Galaxy、iPad、Surface などのプリセットが用意されています。
端末を選ぶと、画面幅・デバイスピクセル比・ユーザーエージェント文字列がまとめて切り替わります。
スマホ端末を追加する
一覧に目的の端末がない場合は、追加できます。
- Dimensionsプルダウンを開く
- 最下部の「Edit…」をクリックする
- Settings > Devices の画面が開く
- 表示したい端末のチェックボックスをオンにする
- 一覧にない端末は「Add custom device」から、名前・幅・高さ・デバイスピクセル比・UA文字列を入力して追加する
自社サイトのアクセス解析で上位に来る端末の画面幅を調べて、それを登録しておくと検証精度が上がります。
任意の画面幅で確認する
端末プリセットではなく、幅を直接指定して確認する方法もあります。
- Dimensionsで「Responsive」を選ぶ
- 幅・高さの数値を直接入力する(例:
375×667、390×844、430×932) - ツールバーの回転アイコンで縦向き/横向きを切り替える
- Zoomで表示倍率を変更する(画面に収まらない大きな端末の確認に便利)
表示領域の端をドラッグして、幅を連続的に変えていく方法もおすすめです。レイアウトが崩れ始める幅(ブレークポイント)を体感的に見つけられます。
上部のツールバーで端末名と画面幅を確認してください。ここに表示されている数値が、実際に検証している画面幅です。
スマホ表示で確認するポイント
漫然と眺めても崩れは見つかりません。次の6点を順にチェックしてください。
- ヘッダーの見切れ:ロゴやメニューが画面端で切れていないか
- CTAのはみ出し:ボタンの文言が長すぎて枠から出ていないか、折り返して不自然になっていないか
- 横スクロール:ページを左右に振ってみて、意図しない横スクロールが発生しないか(表や画像、長いURLテキストが原因になりやすい)
- 固定要素の重なり:追従ヘッダーや固定バナーが、本文やフォームを隠していないか
- 文字サイズ:本文が小さすぎないか(一般に16px前後が目安)
- 画像サイズ:必要以上に大きな画像を読み込んでいないか
Device Modeと実機確認の違い
デバイスモードは画面幅とユーザーエージェントのシミュレーションであり、実機の完全再現ではありません。
- 実機のブラウザ固有の描画差(特にiOS Safari)
- 実際のタッチ操作の感触、スクロールの慣性
- 実機のCPU性能による処理速度
- アプリ内ブラウザ(LINE、Instagramなど)での挙動
レイアウト崩れの一次チェックはDevTools、最終確認は実機。この使い分けが安全です。特にiOS Safari特有の崩れは、Chromeのデバイスモードでは再現されません。
スマホ表示にならない場合の対処法
デバイスモードにしたのにPC表示のままの場合、次を確認してください。
- ページを再読み込みしていない:UAの切り替えは再読み込み後に反映されることがあります
- キャッシュが効いている:
Command/Ctrl + Shift + Rでキャッシュを無視して再読み込みする - UAではなく画面幅で出し分けているサイト:幅を十分に狭くしたか確認する
- サーバー側でUA判定してPC版を返している:Networkパネルでレスポンスを確認する
- キャッシュプラグインやCDNがPC版HTMLを返している:WordPressサイトで頻発します。キャッシュを削除して再確認してください


ConsoleでJavaScriptエラーを確認する方法
- 「フォームが送信できない」
- 「ボタンを押しても何も起きない」
このタイプの不具合は、Consoleパネルに答えが出ていることが非常に多いです。
Consoleを開いて既存ログを消す


大事なのは順番です。
先にログを消してから、問題の操作を再現すること。これをやらないと、無関係なログに埋もれて原因を見失います。
- Consoleタブを開く(
Command + Option + J/Ctrl + Shift + J) - 左上の🚫アイコン(Clear console)をクリックしてログを消す
- フォーム送信やボタンクリックなど、問題の操作を再現する
- 直後に追加された赤い行を確認する
この4ステップだけで、「いつ出たエラーなのか」が明確になります。



赤いエラー行の右端に表示されているファイル名と行番号に注目してください。開発担当者に共有すべき情報はここに含まれています。
赤いエラーと黄色い警告の違い
| 表示 | 意味 | 対応の目安 |
|---|---|---|
| 赤(Error) | 処理が止まっている可能性が高い | 機能が動かないなら最優先で調査 |
| 黄(Warning) | 動作はするが推奨されない、または将来的に問題になる | すぐ壊れるわけではない。余裕があるとき対応 |
| 白・青(Log / Info) | 開発者が意図的に出力した情報 | 基本的に無視してよい |
赤があっても、目的の機能が正常に動いているなら緊急ではないケースも多くあります。逆に、目的の機能が動いていないなら、赤いエラーを最優先で読んでください。
よくあるJavaScriptエラー
初心者が遭遇しやすいものを、意味と典型的な原因で整理します。
| エラー | ざっくりした意味 | よくある原因 |
|---|---|---|
Uncaught TypeError | 想定と違う型のデータを操作しようとした | 要素が見つからないまま処理を続けている |
Uncaught ReferenceError: xxx is not defined | 存在しない変数や関数を呼び出した | スクリプトの読み込み順序ミス、読み込み失敗 |
Cannot read properties of null | 存在しない要素を操作しようとした | HTMLの構造変更でclass名やIDが消えた |
Failed to load resource | ファイルの読み込みに失敗した | ファイルのURLミス、404、外部サービス停止 |
gtag is not defined | GA4のタグが読み込まれる前に計測処理が走った | タグ設置位置の問題、広告ブロッカー、GTMの読み込み失敗 |
gtag is not defined はSEO・広告担当者が特に遭遇しやすいエラーです。計測データが欠損している原因がこれ、というケースは珍しくありません。
フォームやボタンが動かない場合の調査方法
- Consoleを開いてClearする
- 問題のボタンをクリック、またはフォームを送信する
- 赤いエラーが出るか確認する
- エラーが出た場合:ファイル名と行番号を控える
- エラーが出ない場合:Networkパネルに切り替え、Fetch/XHRで絞り込んで送信リクエストが発生しているか確認する
- リクエスト自体が発生していないなら、JavaScriptがそもそも実行されていない可能性が高い
- リクエストは出ているがステータスが400番台・500番台なら、サーバー側の問題
「エラーが出ない」も重要な情報です。 その場合は原因がフロント側ではなくサーバー側にある、という切り分けができます。
Chrome拡張機能由来のログに注意する
Consoleに大量のエラーが出ていても、その多くは自分のサイトとは無関係な拡張機能のログであることがあります。
chrome-extension://から始まるURLcontent.jscontentscript.jsinject.jsといったファイル名- MozBar、Grammarly、パスワード管理ツールなど拡張機能名が含まれる
対策は3つです。
- シークレットウィンドウで確認する(拡張機能が原則無効になる)
- 疑わしい拡張機能を一時的にオフにする
- ConsoleをClearしてから操作を再現し、その操作で新たに出たログだけを見る
Consoleのフィルター欄に -extension と入力して除外する方法もあります。
開発担当者へ共有する情報
エラーを見つけたら、次の6点をまとめて渡すと調査が一気に速くなります。「動きません」だけの報告と比べて、往復のやり取りが半分以下になります。
- 対象URL(パラメータ付きなら完全な形で)
- 再現手順(何をクリックして、何を入力したか)
- エラーメッセージの全文(コピーして貼り付ける)
- エラーに表示されているファイル名と行番号
- Console画面のスクリーンショット
- 発生日時、使用ブラウザ・OS・端末


Networkで通信状況を確認する方法


Networkパネルでは、ページを表示するために発生したすべての通信を確認できます。
404の特定、リダイレクトの確認、重い画像の発見など、SEO・Web運用の実務で使用頻度が最も高いパネルです。
Networkを開いてページを再読み込みする
Networkパネルは開いている間の通信しか記録しません。 開く前の通信は表示されないため、必ず「開いてから再読み込み」の順序で操作します。


- Networkタブを開く
- 左上の録画ボタン(●)が赤いことを確認する(グレーなら停止中なのでクリック)
- 🚫アイコンでこれまでのログをClearする
- 必要に応じてDisable cacheにチェックを入れる(初回訪問者と同じ状態を再現できる)
- ページを再読み込みする



Statusカラムの数値と、Timeカラムの数値に注目してください。この2列を見るだけで「エラーがないか」「何が重いか」が把握できます。
Networkの主要項目
| カラム | 意味 | 見るポイント |
|---|---|---|
| Name | ファイル名やURL | 何が読み込まれているか |
| Status | HTTPステータスコード | 200以外、特に赤い表示 |
| Type | ファイル種別(document、script、imgなど) | 想定外のファイルがないか |
| Initiator | その通信を発生させた側 | 「誰がこれを呼んだのか」の特定 |
| Size | 転送サイズ | 突出して大きいファイル |
| Time | 完了までの時間 | 突出して遅い通信 |
| Waterfall | 時系列のタイミング図 | どこで待ち時間が発生しているか |
画像、JavaScript、API通信を絞り込む
パネル上部のフィルターボタンで種別を絞り込めます。
- Doc:HTML本体。リダイレクトやステータス確認はここ
- CSS:スタイルシート
- JS:JavaScriptファイル
- Img:画像。重い画像を探すときはここ
- Fetch/XHR:フォーム送信やAPI通信。「ボタンを押したのに何も送信されていない」の確認に使う
- Font:Webフォント。表示遅延の原因になりやすい
- Media:動画・音声
検索欄にドメイン名やファイル名の一部を入力して絞り込むこともできます。
404、500などのHTTPステータスを確認する
Statusカラムの数値の意味です。
| コード | 意味 | 判断 |
|---|---|---|
| 200 | 正常 | 問題なし |
| 204 | 正常。返す中身がないだけ | エラーではない 計測タグでよく発生 |
| 301 | 恒久的なリダイレクト | 意図したものか確認 |
| 302 | 一時的なリダイレクト | 恒久移転なら301にすべき |
| 304 | キャッシュが有効なので再送不要 | エラーではない むしろ効率的な状態 |
| 404 | ページ・ファイルが存在しない | 要対応 |
| 500 | サーバー内部エラー | 最優先で要対応 |
204と304はエラーではありません。
204は「正常に受け取ったが返す中身がない」、304は「前回と同じなのでキャッシュを使ってよい」という意味です。
GA4やGTMの計測通信は204を返すことが多く、これを見て「計測が失敗している」と誤解するケースが頻繁にあります。
通信をクリックしてHeadersを見る
一覧の行をクリックすると、詳細が右側(または下側)に開きます。Headersタブで確認すべき項目は次のとおりです。
- Request URL:実際にリクエストされたURL。パラメータの有無もここで確認
- Request Method:
GET(取得)かPOST(送信)か - Status Code:ステータスコード
- Response Headers:サーバーが返した情報
content-type:ファイル種別(text/html、image/webpなど)location:リダイレクト先URL(301・302のとき表示される)cache-control:キャッシュの扱いx-robots-tag:クロール・インデックスの指示。SEOでは要チェック
- Request Headers:ブラウザが送った情報(
user-agentなど)
リダイレクトを確認する
リダイレクトは、通常のままだと画面が切り替わった瞬間にログが消えてしまいます。
Preserve logを使うのがコツです。
- Networkパネル上部の「Preserve log」にチェックを入れる
- ログをClearする
- 旧URLをアドレスバーに入力してアクセスする
- 一覧の一番上の行(旧URL)をクリックする
- Status Codeが301か302かを確認するResponse Headersの
locationで転送先を確認する
- 多段リダイレクト:旧URL → 中間URL → 最終URLと2回以上経由していないか。表示速度とクロール効率の両方に悪影響があります
- 301か302か:恒久的な移転なのに302になっていないか
- JavaScriptリダイレクトとの違い:Statusが200のままURLだけ変わっている場合、サーバー側ではなくJavaScriptによる転送です。サーバーリダイレクトのほうが確実で、SEO上も推奨されます
重い通信を探す
表示が遅い原因を特定する手順です。
- Timeカラムのヘッダーをクリックして並べ替える → 時間がかかっている通信が上に来る
- Sizeカラムで並べ替える → ファイルサイズが大きい通信が分かる
- 該当の通信をクリックし、Timingタブを開く → 待ち時間(Waiting)とダウンロード時間(Content Download)のどちらが長いかが分かる
- Waterfallの形を見る → 特定の通信が終わるまで他が待っている「直列」の状態がないか確認する


よくある犯人は3つです。
- 圧縮されていない大きな画像(数MB級のJPEGなど)
- 外部の計測タグ・広告タグ(自社では制御しにくい)
- 遅いAPIレスポンス



Waiting時間が長い場合はサーバー側、Content Download時間が長い場合はファイルサイズが原因、という切り分けができます。
Networkに何も表示されない場合
慌てる前に、次の5点を確認してください。
- 録画が停止している:左上の●がグレーになっていないか
- 再読み込みしていない:Networkは開いた後の通信しか記録しません
- フィルターがかかっている:Img や JS などが選択されたままになっていないか
- 検索欄に文字が残っている:以前の検索条件が残っていないか
- 「Hide data URLs」などのオプションがオンになっている:上部のチェックボックスを確認
拡張機能の広告ブロッカーが通信自体をブロックしているケースもあります。シークレットウィンドウで再確認すると切り分けられます。


Cookie・Local Storage・キャッシュを確認する方法
- 「同意バナーが毎回出る」
- 「ログイン状態が保持されない」
- 「A/Bテストの振り分けが機能しているか確認したい」
こうした確認はApplicationパネルで行います。


ApplicationパネルでCookieを確認する
- Applicationタブを開く
- 左メニューのStorage > Cookiesを展開する
- 対象のドメインをクリックする


表示される項目の意味は次のとおりです。
| 項目 | 意味 | 見るポイント |
|---|---|---|
| Name | Cookieの名前 | _ga _gid はGA4、_fbp はMeta広告 |
| Value | 保存されている値 | 意図した値が入っているか |
| Domain | 有効なドメイン | サブドメインを含むか(先頭にドットがあるか) |
| Path | 有効なパス | / なら全ページで有効 |
| Expires / Max-Age | 有効期限 | Session ならブラウザを閉じると消える |
| HttpOnly | JavaScriptから読めない設定 | セキュリティ上、認証系はオンが望ましい |
| Secure | HTTPS接続でのみ送信 | オンが望ましい |
| SameSite | 別サイトからのリクエスト時の送信可否 | Lax Strict None |
行を右クリックすれば個別に削除でき、上部のアイコンで全削除もできます。同意バナーの初回表示テストは、該当Cookieを削除して再読み込みするのが最も確実です。
Local StorageとSession Storageを確認する




同じくApplicationパネルの左メニューにあります。
- Local Storage:ブラウザを閉じても残る。「バナーを一度閉じたら二度と出さない」といった実装に使われる
- Session Storage:タブを閉じると消える。フォームの一時保存などに使われる
キーと値の一覧が表示されるので、値をダブルクリックすれば編集も可能です。



「バナーを閉じた状態」を再現したり、リセットして初回表示を確認したりできます。
キャッシュを無効化する
「修正したのに反映されない」の大半はキャッシュが原因です。確認方法は2つあります。
- Disable cache:Networkパネル上部のチェックボックス。DevToolsを開いている間だけキャッシュが無効になります
- Empty cache and hard reload:DevToolsを開いた状態で、ブラウザの更新ボタンを長押し(右クリック)すると表示されるメニュー。キャッシュを削除したうえで再読み込みします





制作会社に「直っていません」と伝える前に、この2つを試してください。自分側のキャッシュだった、というケースは非常に多いです。


Chromeデベロッパーツールでスクリーンショットを撮る方法
DevToolsには、拡張機能なしでページ全体を1枚の画像として保存する機能があります。競合分析、社内共有、記事作成のいずれでも便利です。
表示中の画面を撮影する
- DevToolsを開く
Command + Shift + P(Mac)/Ctrl + Shift + P(Windows)でコマンドメニューを開くscreenshotと入力する- 「Capture screenshot」を選ぶ




screenshot と入力し、「Capture screenshot」を選ぶ
表示中の範囲(ビューポート)だけがPNGとして保存されます。
同じメニューには他にも次のコマンドがあります。
- Capture area screenshot:ドラッグで範囲を指定して撮影
- Capture node screenshot:Elementsで選択中の要素だけを撮影。表やカードの切り出しに便利
Webページ全体をフルサイズで撮影する
長いページを1枚に収めたいときはこれです。
- コマンドメニューを開く
screenshotと入力する- 「Capture full size screenshot」を選ぶ
スクロールが必要な範囲を含めて、ページ全体が1枚のPNGとして保存されます。




追従ヘッダーが繰り返し写り込む、遅延読み込み(lazy load)の画像が空白になる、といった現象が起きることがあります。撮影前にページを最下部まで一度スクロールして画像を読み込ませておくと、失敗を減らせます。
スマホ表示のスクリーンショットを撮影する
- デバイスモードを起動する(
Command/Ctrl + Shift + M) - 端末と向きを選ぶ
- デバイスツールバー右端の「⋮」をクリックする
- 「Capture screenshot」または「Capture full size screenshot」を選ぶ



「⋮」メニューの「Add device frame」をオンにすると、端末のフレーム付きで撮影できます。提案資料に載せるスマホ表示のモックとして使えます。


LighthouseとPerformanceでページ品質を確認する
Lighthouseで確認できる項目


Lighthouseは、ページの品質を自動診断してスコアとレポートを出す機能です。
DevToolsに「Lighthouse」パネルとして組み込まれています。
診断されるカテゴリは4つです。
- Performance:表示速度・Core Web Vitals関連
- Accessibility:アクセシビリティ(alt属性の欠落、コントラスト不足など)
- Best Practices:セキュリティやブラウザ推奨事項への適合
- SEO:title、meta description、クロール可否など基本項目
Lighthouseの実行方法
- 診断したいページを開く
- DevToolsでLighthouseタブを開く
- カテゴリ(Performance、SEOなど)を選ぶ
- Mobile / Desktopを選ぶ
- 「Analyze page load」をクリックする
- 数十秒待つとレポートが生成される



モバイルでの診断を優先してください。 Googleはモバイル版を基準に評価するためです。


スコアだけで判断してはいけない理由
Lighthouseのスコアは、次の理由で毎回変動します。「昨日は85点、今日は62点」は普通に起きます。
- 測定時のネットワーク状況・PCの負荷で結果が変わる
- Chrome拡張機能が計測に影響する(シークレットウィンドウでの測定を推奨)
- 外部の広告タグ・計測タグの応答速度に左右される
- Lighthouseは実験室データ(Lab Data)であり、実ユーザーのデータ(Field Data)とは別物
実際のユーザー体験を知りたい場合は、Search ConsoleのCore Web Vitalsレポートや、CrUX(Chrome UX Report)に基づくフィールドデータを確認してください。
Lighthouseの本当の価値はスコアではなく、レポート下部に並ぶ具体的な改善提案にあります。「画像の圧縮」「使われていないJavaScriptの削減」など、優先度つきで提示されます。
Performanceパネルで確認できること
Performanceパネルは、より詳細に表示速度を分析する機能です。


近年は入り口が大きく改善され、パネルを開くと最初にLive metrics画面が表示されます。ここではLCP・CLS・INPの3つのCore Web Vitalsが、操作に応じてリアルタイムで更新されます。
さらに録画(Record)してページを読み込むと、次のような内容を確認できます。
- 長いJavaScript処理(Long Task):50ms以上かかっている処理
- メインスレッドの混雑状況:処理が詰まって操作を受け付けられない時間帯
- レンダリングのタイミング
- レイアウトシフト(CLS):どの要素が、いつズレたか
- 画像読み込み:LCPになっている要素の特定
現在は、Lighthouseが指摘するような改善提案がInsightsサイドバーにも表示されるようになり、Performanceパネル単体でも原因分析から改善案までたどれるようになっています。



Performanceパネルは非エンジニアには難度が高い機能です。まずはLive metricsでLCPとCLSの数値を眺めるところから始めれば十分です。


SEO担当者がChrome DevToolsで確認したい項目



ここではSEOの実務で、DevToolsを使えばその場で確認できる項目を整理します。
外部ツールを立ち上げる前に、DevToolsで済むものは意外と多いです。
titleとmeta description
- 見るパネル:Elements(
<head>内) - 探すもの:
<title>、<meta name="description"> - 問題例:同じtitleが複数ページで使い回されている、テンプレートの変数が展開されずに残っている、descriptionが未設定、CMSのプラグイン設定とHTMLの出力が食い違っている
<head> は折りたたまれていることが多いので、<head> 左の三角をクリックして展開してください。
canonical
- 見るパネル:Elements(
<head>内) - 探すもの:
<link rel="canonical" href="..."> - 問題例:全ページがトップページを指している、httpとhttpsが混在、末尾スラッシュの有無が実際のURLと不一致、パラメータ付きURLが正規化されていない
canonicalの事故は、影響が大きい割に気づきにくいタイプの問題です。テンプレート変更後は必ず確認してください。
robots meta
- 見るパネル:Elements(
<head>内)/Network(Response Headers) - 探すもの:
<meta name="robots" content="..."> - 問題例:公開したいページに
noindexが残っている(テスト環境からの移行時に頻発)、意図せずnofollowが全体に適用されている
H1、H2、H3の見出し構造
- 見るパネル:Elements、またはConsole(後述のコードで一覧化)
- 探すもの:見出しタグの階層と文言
- 問題例:H1が存在しない/複数ある、H2を飛ばしてH3が使われている、デザイン目的で見出しタグが使われている
画像のalt属性
- 見るパネル:Elements、またはConsole
- 探すもの:
<img>のalt属性 - 問題例:alt未設定、ファイル名がそのまま入っている(
IMG_2034.jpg)、キーワードを詰め込んだ不自然なalt
内部リンクとnofollow
- 見るパネル:Elements、またはConsole
- 探すもの:
<a href>のrel属性、リンク先URL - 問題例:内部リンクに
nofollowが付いている、アンカーテキストが「こちら」ばかり、リンク先が相対パスの誤りで404になっている
JSON-LD形式の構造化データ
- 見るパネル:Elements(
<script type="application/ld+json">) - 探すもの:
@type、必須プロパティの有無 - 問題例:JSONの構文エラーで読み込まれていない、
@typeが実際のコンテンツと合っていない、複数のプラグインが重複して出力している
構造化データの妥当性判定は、最終的にはGoogleのリッチリザルトテストなど専用ツールで行ってください。
DevToolsは「そもそも出力されているか」「重複していないか」の一次確認に向いています。
JavaScript実行後に本文やリンクがDOM上へ存在するか
- 見るパネル:Elements(実行後のDOM)/Network の Doc(元のHTML)
- 探すもの:本文テキスト、内部リンクが、それぞれどちらに存在するか
- 問題例:元のHTMLにはほぼ何もなく、JavaScript実行後にはじめて本文が生成されている
これはDevToolsならではの確認方法です。
Elementsパネルが表示するのはJavaScript実行後のDOMであり、Networkパネルの Doc → Response で見られるのはサーバーが返した元のHTMLです。
この2つを比較すると、コンテンツがJavaScriptに依存しているかどうかが分かります。
ブラウザで見えているのに元のHTMLにない、という状態は、レンダリングが正しく行われなければ検索エンジンに認識されないリスクを意味します。
404、500、リダイレクト
- 見るパネル:Network(Docフィルター、Preserve logをオン)
- 探すもの:Status Code、
locationヘッダー - 問題例:内部リンクの404、多段リダイレクト、301にすべき箇所が302、リダイレクトループ
X-Robots-Tagなどのレスポンスヘッダー
- 見るパネル:Network → 対象通信 → Headers → Response Headers
- 探すもの:
x-robots-tag、content-type、cache-control、vary - 問題例:HTML内にはnoindexがないのに、レスポンスヘッダーで
x-robots-tag: noindexが指定されている
これはHTMLをいくら見ても分からないため、原因不明のインデックス未登録を調査するときに必ず確認したい項目です。PDFなどHTML以外のファイルの制御にも使われます。
GA4・GTMの通信
- 見るパネル:Network(検索欄に
collectやgtmと入力) - 探すもの:
google-analytics.com/g/collectへの通信、gtm.jsの読み込み - 問題例:計測タグが二重に発火している、特定ページだけタグが読み込まれていない、Consoleに
gtag is not definedが出ている
collect への通信がステータス204で返ってくるのは正常です。エラーではありません。
スマホ表示の横スクロールやCTAの見切れ
- 見るパネル:デバイスモード
- 探すもの:意図しない横スクロール、はみ出したボタン、追従要素の重なり
- 問題例:表や画像が画面幅を超えている、CTAボタンの文言が折り返して読みにくい、固定バナーがフォームの送信ボタンを隠している


位置情報・通信速度・ユーザーエージェントを変更する方法
DevToolsでは、ブラウザの環境そのものを一時的に切り替えられます。
「特定条件でだけ起きる不具合」の再現に使う機能です。
位置情報を一時変更する
- コマンドメニュー(
Command/Ctrl + Shift + P)でSensorsと入力する - 「Show Sensors」を選ぶ
- Locationのプルダウンから都市を選ぶ、または「Custom location…」で緯度・経度を入力する
- 「Location unavailable」を選べば、位置情報が取得できない状態も再現できる









店舗検索や地図機能を持つサイトのテストに使えます。位置情報の取得に失敗したときの表示が壊れていないか、という確認は見落とされがちです。
通信速度を変更する
Networkパネル上部のThrottlingプルダウンから選びます。


- Fast 4G:比較的良好なモバイル回線
- Slow 4G:やや遅いモバイル回線。Lighthouseのモバイル計測条件に近い設定
- 3G:かなり遅い回線
- Offline:完全にオフライン
- Custom:帯域と遅延を自分で設定
Chrome 127より前は「Fast 3G」「Slow 3G」という名称でした。現在は「Slow 4G」「Fast 4G」に整理されています。古い解説記事とメニュー名が異なる場合がありますが、機能は同じ系統のものです。



Offlineは、通信が切れたときにエラー表示が適切に出るかの確認に使えます。
ユーザーエージェントを変更する
- コマンドメニューで
Network conditionsと入力し、「Show Network conditions」を選ぶ - User agentの「Use browser default」のチェックを外す
- プルダウンから端末やクローラーのUAを選ぶ、または任意の文字列を入力する
プルダウンにはGooglebot相当のUA文字列も用意されています。




UAを変更しても、Chrome自体がGooglebotになるわけではありません。 変わるのは「ブラウザが名乗る名前」だけです。IPアドレスもレンダリングの仕組みもGoogleのクローラーとは異なります。
UAで出し分けているサイトの挙動確認には使えますが、「Googlebotから見たページ」の正式な確認は、Search Consoleの URL検査ツールで行ってください。
DevToolsでIPアドレスを変更できるのか
結論:Chrome DevToolsだけでは、インターネット上の公開IPアドレスは変更できません。
DevToolsで変更・再現できるのは、あくまでブラウザ側の設定や状態です。
| DevToolsで変更できる | DevToolsでは変更できない |
|---|---|
| 位置情報(緯度・経度) | 公開IPアドレス |
| タイムゾーン | 接続元の国・地域の判定(IPベースのもの) |
| ロケール(言語・地域設定) | サーバー側のジオロケーション判定 |
| ユーザーエージェント | 実際のネットワーク経路 |
| 通信速度・オフライン状態 | — |
IPベースで地域判定しているサイト(地域別価格、地域別コンテンツなど)の挙動を確認したい場合は、VPNやプロキシなど別の仕組みが必要です。



DevToolsのLocation設定を変えても、サーバーから見た接続元は変わりません。


Consoleを使ってSEO情報を抽出する方法
Consoleでは、今開いているページに対してJavaScriptを実行できます。手作業で数えると1時間かかる作業が、数秒で終わります。


実行方法は共通です。 Consoleタブを開き、コードを貼り付けて Enter を押すだけです。ページを書き換える処理ではないので、サイトが壊れることはありません。
- 自社サイト、または一般公開されているページを対象にする
- 対象サイトの利用規約を確認する
- ログインが必要な領域や有料コンテンツの制限を回避しない
- 個人情報や認証情報を取得しない
- CAPTCHAやアクセス制限を回避しない
- 非公開APIを不正に利用しない
- 短時間に大量アクセスを行わない
- 取得したコンテンツを無断で転載しない
ここで紹介するのは、ブラウザで既に表示されている公開情報を、手作業の代わりに整理するという使い方です。
認証を突破したり制限を回避したりする行為は、規約違反や法的リスクにつながります。



競合サイトを見るときも、あくまで「自分でブラウザを開いて読んだ範囲を整理する」レベルにとどめてください。
見出しを一覧化する


// ページ内の h1〜h4 をすべて取得し、タグ名と文言を表形式で表示する
const headings = [...document.querySelectorAll('h1, h2, h3, h4')].map(h => ({
タグ: h.tagName, // H1 / H2 などのタグ名
テキスト: h.innerText.trim().slice(0, 60) // 長い見出しは60文字で省略
}));
console.table(headings); // 表形式で出力
見方:console.table は結果を表で表示します。タグ名の並びを上から追って、H1が1つあるか、H2→H3の階層が飛んでいないかを確認してください。
ページ内リンクを抽出する


// ページ内のすべてのリンクを、アンカーテキスト・URL・rel属性つきで一覧化する
const links = [...document.querySelectorAll('a[href]')].map(a => ({
アンカー: a.innerText.trim().slice(0, 40),
URL: a.href,
rel: a.rel || '-', // nofollow などが入っていれば表示
target: a.target || '-'
}));
console.table(links);
console.log('リンク総数:', links.length);
見方:アンカーテキストが「こちら」「詳細はこちら」ばかりになっていないか、想定外の nofollow がないかを確認します。
外部リンクだけを抽出する


// 自ドメイン以外へのリンク(外部リンク)だけを抜き出す
const host = location.hostname; // 今見ているサイトのドメイン
const external = [...document.querySelectorAll('a[href^="http"]')]
.filter(a => a.hostname !== host) // ドメインが違うものだけ残す
.map(a => ({
アンカー: a.innerText.trim().slice(0, 40),
URL: a.href,
rel: a.rel || '-'
}));
console.table(external);
console.log('外部リンク数:', external.length);
見方:意図しない外部リンクが残っていないか、アフィリエイトリンクに sponsored が付いているかの確認に使えます。
alt属性がない画像を探す


// alt属性が未設定、または空文字の画像を抽出する
const noAlt = [...document.querySelectorAll('img')]
.filter(img => !img.alt || img.alt.trim() === '')
.map(img => ({
src: img.currentSrc || img.src,
幅: img.naturalWidth, // 実際の画像の横幅(px)
高さ: img.naturalHeight
}));
console.table(noAlt);
console.log('alt未設定:', noAlt.length, '/ 画像総数:', document.images.length);
見方:装飾目的の画像はaltが空でも問題ありません。内容を伝える画像にaltがない場合のみ対応してください。あわせて、幅が2000pxを超えるような画像が並んでいたら、圧縮・リサイズの検討対象です。
title、description、canonical、robotsをまとめて確認する


// head内のSEO基本項目を一括で表示する
const meta = (name) => document.querySelector(`meta[name="${name}"]`)?.content ?? '(なし)';
console.table({
title: document.title,
description: meta('description'),
robots: meta('robots'),
canonical: document.querySelector('link[rel="canonical"]')?.href ?? '(なし)',
ogTitle: document.querySelector('meta[property="og:title"]')?.content ?? '(なし)',
lang: document.documentElement.lang || '(なし)'
});
見方:(なし) と表示された項目が未設定です。canonicalが今見ているURLと一致しているかも、あわせて確認してください。
JSON-LDを抽出する


// ページ内のJSON-LD(構造化データ)を1件ずつ展開して表示する
[...document.querySelectorAll('script[type="application/ld+json"]')].forEach((s, i) => {
try {
const data = JSON.parse(s.textContent);
console.log(`--- JSON-LD ${i + 1} 件目 ---`, data); // 展開可能な形で出力
} catch (e) {
// 構文エラーがあるとGoogleにも読み取られない可能性が高い
console.warn(`JSON-LD ${i + 1} 件目は構文エラーの可能性があります:`, e.message);
}
});
見方:出力された ▶ をクリックすると中身を展開できます。黄色い警告が出た場合は構文エラーで、検索エンジンにも読み取られていない可能性があります。同じ @type が複数出力されていたら、プラグインの重複を疑ってください。
HTMLテーブルを整理する


// ページ内1つ目のテーブルをタブ区切りで取り出し、クリップボードへコピーする
const table = document.querySelectorAll('table')[0]; // [1] にすれば2つ目のテーブル
const rows = [...table.querySelectorAll('tr')].map(tr =>
[...tr.querySelectorAll('th, td')].map(cell => cell.innerText.trim())
);
console.table(rows);
copy(rows.map(r => r.join('\t')).join('\n')); // タブ区切りでコピー
console.log('クリップボードにコピーしました。スプレッドシートへ貼り付けできます。');
見方:copy() はDevToolsのConsole専用の機能です。実行後、そのままGoogleスプレッドシートやExcelに貼り付ければ、表として展開されます。自社サイトの料金表や仕様表をデータ化したいときに便利です。


Local Overridesで変更をリロード後も残す方法
Local Overridesは、DevToolsで加えた変更をローカルフォルダに保存し、再読み込みしても維持する機能です。
初心者にとっては応用機能なので、Elements・デバイスモード・Console・Networkに慣れてから触ってください。
通常のElements編集との違い
Elementsパネルでの編集は再読み込みで消えますが、Local Overridesを設定すると、DevToolsが保存したローカルのファイルを、サーバー上のファイルの代わりに読み込むようになります。
そのため、CSSやJavaScriptの修正案を「実際に何度も画面を触りながら」検証できます。
ただしChrome公式ドキュメントのとおり、ElementsパネルのDOMツリーへの変更はLocal Overridesでも保存されません。
保存できるのはCSS、JavaScript、レスポンスヘッダー、XHR/fetchのレスポンスなどです。
CSSやJavaScriptをローカル保存する
- Sourcesパネル → Overridesタブを開く
- 「Select folder for overrides」をクリックし、保存用の空フォルダを選ぶ
- 上部に出る「Allow」をクリックしてアクセスを許可する
- StylesペインでCSSを変更する
- 再読み込みしても変更が維持される




Networkパネルから始める方法もあります。対象の通信を右クリックし、「Override content」を選ぶと、そのファイルの編集画面へ直接移動できます。
APIレスポンスを仮変更する
Networkパネルで通信を右クリックし、「Override content」を選べば、XHRやfetchのレスポンス内容を書き換えられます。




「APIがまだ完成していないが、データが返ってきたときの表示を確認したい」という場面で使えます。
レスポンスヘッダーも同様に、「Override headers」から書き換えられます。x-robots-tag を追加したときの挙動確認などにも応用できます。
本番サイトには反映されない
Local Overridesで書き換えた内容は、自分のブラウザにしか反映されません。
他の人が同じURLを開いても、元のページが表示されます。あくまで「自分の環境で先に試す」ための機能です。
なお、Local Overridesを有効にしている間はキャッシュが自動的に無効化されます。設定したまま忘れていると、他の検証に影響することがあるため、使い終わったらオフに戻してください。


Chromeデベロッパーツールでできないこと
できることと同じくらい、できないことを知っておくと判断を誤りません。
- 本番サイトへ変更内容を保存する:一切できません。サーバー上のファイルは変わりません
- PHPを直接修正する:PHPはサーバー側で実行されるため、DevToolsからは触れません
- WordPressの設定を更新する:管理画面から行う必要があります
- データベースを書き換える:DevToolsの守備範囲外です
- サーバー環境を完全再現する:サーバー側の処理は推測しかできません
- 公開IPアドレスを変更する:VPNやプロキシが必要です
- 実機を完全再現する:デバイスモードはあくまでシミュレーションです
- Googlebotを完全再現する:UAを変えられるだけです。正式な確認はSearch Consoleの URL検査ツールで行ってください
- サイト全体を継続的にクロールする:1ページずつの確認が前提です。全体調査はScreaming FrogやAhrefsなど専用ツールを使ってください



DevToolsは「1ページを深く調べる」ツールです。サイト全体を横断的に見る用途には向いていません。


Chromeデベロッパーツールでよくある質問
Chromeデベロッパーツールは無料ですか?
無料です。Google Chromeに標準搭載されているため、追加の費用も、拡張機能のインストールも、アカウント登録も不要です。
Chromeが入っていれば、右クリックの「検証」から今すぐ使えます。
Chromeデベロッパーツールの変更は保存されますか?
保存されません。
Elementsパネルで加えたHTML・CSSの変更は、ページを再読み込みした時点で消え、本番サイトにも一切反映されません。
例外的に、Local Overridesを設定した場合のみ、自分のブラウザ内でCSSやJavaScriptの変更を維持できますが、この場合もサーバー上のファイルは変更されません。
Chromeデベロッパーツールを日本語にできますか?
できます。
DevToolsの設定(歯車アイコン、またはF1)→ Preferences → Appearance → Language で「日本語 – Japanese」を選び、「Reload DevTools」をクリックすれば切り替わります。
Chrome 94以降、日本語を含む80以上の言語に対応しています。
スマホ表示へ切り替える方法は?
デバイスモードを使います。
DevToolsを開き、左上のスマホとタブレットが重なったアイコンをクリックするか、Command + Shift + M(Mac)/Ctrl + Shift + M(Windows)を押してください。上部のDimensionsプルダウンから、iPhoneやPixelなどの端末を選べます。
iPhoneのChromeでDevToolsは使えますか?
iPhoneのChrome単体では使えません。
iOSのブラウザにはDevToolsが搭載されていないためです。実機のiPhoneの表示を検証したい場合は、MacとiPhoneをケーブルで接続し、SafariのWebインスペクタを使う方法が一般的です。
PC上での簡易確認であれば、Chromeのデバイスモードで十分なケースが多いです。
Chrome DevToolsでIPアドレスを変更できますか?
できません。
DevToolsで変更できるのは、位置情報・タイムゾーン・ロケール・ユーザーエージェント・通信速度といったブラウザ側の設定だけです。
サーバーから見える公開IPアドレスは変わらないため、IPで地域を判定しているサイトの挙動を確認するには、VPNやプロキシなど別の仕組みが必要です。
Consoleに大量のエラーが表示されても問題ありませんか?
必ずしも問題とは限りません。
Chrome拡張機能や外部の広告・計測タグが出しているエラーが混ざっていることが多いためです。
判断するには、Consoleを一度Clearしてから問題の操作を再現し、その操作で新たに出たエラーだけを見てください。
chrome-extension:// や content.js を含むログは、拡張機能由来の可能性が高いです。シークレットウィンドウで再確認すると切り分けられます。
Networkに通信が表示されないのはなぜですか?
最も多い原因は、Networkパネルを開く前にページを読み込んでいることです。
Networkパネルは開いている間の通信しか記録しないため、開いた後に再読み込みしてください。
それでも表示されない場合は、録画ボタンが停止していないか、種別フィルターや検索欄に条件が残っていないかを確認してください。広告ブロッカーが通信自体を遮断しているケースもあります。
DevToolsでGooglebotの表示を確認できますか?
完全には確認できません。
ユーザーエージェントをGooglebot相当に変更することはできますが、変わるのは「ブラウザが名乗る名前」だけで、IPアドレスもレンダリングの仕組みも実際のGooglebotとは異なります。
正式に確認したい場合は、Google Search Consoleの URL検査ツールで「公開URLをテスト」を実行し、レンダリング結果を確認してください。
Chrome DevToolsとLighthouseの違いは?
Lighthouseは、DevToolsの中に含まれる機能の1つです。
DevTools全体が「ページの状態を手動で調べるツール群」であるのに対し、Lighthouseは「ページを自動診断してスコアと改善提案を出す機能」です。
原因を自分で追いたいときはElementsやNetwork、改善候補を洗い出したいときはLighthouse、と使い分けてください。
まずはElements・スマホ表示・Console・Networkから覚えよう!
Chromeデベロッパーツールは機能が多く、すべてを覚える必要はありません。
実務で使用頻度が高い順に、次の4つから始めれば十分です。
- Elements:HTMLとCSSを一時編集して、文言や色、余白を試す
- デバイスモード:スマホ表示の崩れ、横スクロール、CTAの見切れを確認する
- Console:JavaScriptエラーを確認し、フォームやボタンの不具合を切り分ける
- Network:404・500・リダイレクト・重い通信を確認する
そのうえで、必要になったタイミングで次を追加してください。
- Application:Cookie、Local Storage、キャッシュの確認
- Lighthouse:ページ品質の自動診断と改善提案の洗い出し
- Sources > Overrides:変更を再読み込み後も維持する応用機能
最後にもう一度、最も重要な前提を確認します。
DevToolsは確認と仮説検証のツールであり、テスト環境でも修正ツールでもありません。
本番サイトの修正、PHPの変更、データベースの更新、公開IPアドレスの変更は、いずれもDevToolsだけでは行えません。
だからこそ、何を触っても壊れません。
今すぐ自社サイトを開いて、右クリックから「検証」を押してみてください。



見出しの文言をダブルクリックして書き換え、再読み込みで元に戻る、この2分の体験が最初の一歩として最も効果的です。








