DevToolsでHTTP通信・エラー・DOMを確認する方法｜新人エンジニア向けにブラウザ開発者ツールを解説

2026年6月18日 最終更新日時 : 2026年6月18日 山崎講師山崎講師

こんにちは。ゆうせいです。

今回は、ブラウザのDevToolsを使って、HTTP通信、JavaScriptエラー、DOMを確認する方法を新人エンジニア向けに解説します。

Spring Boot、Thymeleaf、JavaScript、fetch()、API連携を学んでいると、画面が思ったように動かない場面が必ず出てきます。

fetch()でAPIを呼んでいるはずなのに値が返ってこない
Spring Boot側で@RequestBodyの値がnullになる
Thymeleafで表示したはずのHTMLが見えない
CSSが効かない
404や500が出ているが原因がわからない

ボタンを押しても反応しない

このようなときに使うのが、DevToolsです。

DevToolsは、ブラウザに標準で入っている開発者向けの調査道具です。

Chrome DevToolsの公式ドキュメントでも、Networkパネルではページのネットワーク活動を調査でき、ElementsパネルではDOMツリーを確認・操作できると説明されています。

たとえるなら、DevToolsはWebアプリの「レントゲン写真」です。

画面だけ見てもわからない内部の通信、エラー、HTML構造、CSSの状態を確認できます。

DevToolsで確認できること

DevToolsでは、主に次のような情報を確認できます。

見たいもの使うタブ確認できる内容
HTTP通信NetworkURL、HTTPメソッド、ステータスコード、送信データ、レスポンス
JavaScriptエラーConsoleエラーメッセージ、console.log、警告
HTML構造ElementsDOM、HTMLタグ、CSS、styleの適用状況
JavaScriptの詳細デバッグSourcesブレークポイント、変数、実行順序
保存データApplicationCookie、LocalStorage、SessionStorage

新人エンジニアは、まずNetwork、Console、Elementsの3つを使えるようになれば十分です。

この3つを見れば、Webアプリの多くの不具合を切り分けられます。

DevToolsの開き方

ChromeやEdgeでは、次の方法でDevToolsを開けます。

操作説明
F12DevToolsを開く
Ctrl + Shift + IDevToolsを開く
右クリック → 検証クリックした要素をElementsで確認する

Macの場合は、Command + Option + Iで開けます。

画面の下や右側に、開発者用のパネルが表示されます。

最初は情報量が多くて驚くかもしれません。

でも大丈夫です。

まず見る場所は、Network、Console、Elementsの3つだけです！

NetworkタブでHTTP通信を確認する

Networkタブは、ブラウザとサーバーの通信を見る場所です。

Spring Bootへリクエストが飛んでいるか、APIが何を返しているか、404や500が出ていないかを確認できます。

Chrome DevTools公式ドキュメントでは、Networkパネルを使うとネットワーク活動を記録し、各リクエストの詳細を確認できると説明されています。([(https://developer.chrome.com/docs/devtools/network?utm_source=chatgpt.com))

fetch()やフォーム送信で困ったら、まずNetworkを見てください。

Networkタブの基本的な使い方

1. DevToolsを開く
2. Networkタブをクリックする
3. 画面を再読み込みする
4. ボタンを押す、フォーム送信する、fetch()を実行する
5. 一覧に出てきた通信をクリックする
6. Headers、Payload、Responseを確認する

Networkタブを開いたあとに操作するのがポイントです。

先に操作してからNetworkを開くと、通信が記録されていないことがあります。

Networkで見るべき項目

項目意味確認ポイント
Nameリクエスト名どのURLへアクセスしたか
StatusHTTPステータス200、201、400、404、500など
MethodHTTPメソッドGET、POST、PUT、DELETEなど
Type種類document、fetch、script、cssなど
Payload送信データフォーム値やJSONが正しく送られているか
Response返却内容HTML、JSON、エラーメッセージ

Networkタブは、郵便追跡のようなものです。

どこへ送ったのか、何を送ったのか、相手から何が返ってきたのかを確認できます。

HTTPステータスコードを見る

Networkで最初に見るべきなのは、Statusです。

ステータス意味新人向けの見方
200 OK成功正常に取得できた
201 Created作成成功登録APIなどが成功した
302 Foundリダイレクト別URLへ移動している
400 Bad Requestリクエスト不正送った値や形式に問題がある
401 Unauthorized未認証ログインしていない
403 Forbidden禁止権限がない
404 Not Found見つからないURLやControllerのMappingが違う
405 Method Not Allowedメソッド不一致GETなのにPOST用URLへ送っているなど
415 Unsupported Media Typeメディアタイプ不一致JSONなのにContent-Typeが違うなど
500 Internal Server Errorサーバー内部エラーSpring Boot側で例外が起きている

ステータスコードは、サーバーからの返事です。

テストの採点でたとえるなら、200は「正解」、400は「問題文の読み間違い」、404は「提出先の教室を間違えた」、500は「採点する先生側でトラブル」です。

fetch()の通信をNetworkで確認する

たとえば、JavaScriptで次のfetch()を書いたとします。

const requestData = {
    name: "山田太郎",
    email: "yamada@example.com"
};

fetch("/api/users", {
    method: "POST",
    headers: {
        "Content-Type": "application/json"
    },
    body: JSON.stringify(requestData)
})
    .then(function (response) {
        return response.json();
    })
    .then(function (data) {
        console.log(data);
    });

Networkタブでは、/api/usersという通信を探します。

クリックしたら、次の項目を確認します。

Network内の場所確認内容
HeadersRequest URL、Request Method、Status Code、Content-Type
Payload送信したJSON
ResponseSpring Boot APIから返ってきたJSON
PreviewJSONを見やすく整形した表示

Spring Boot側で@RequestBodyの値がnullになる場合、Payloadを見てください。

PayloadにJSONが出ていなければ、JavaScript側で送れていません。

PayloadにJSONがあるのにSpring Boot側でnullなら、DTOのプロパティ名、setter、Content-Type、@RequestBodyを確認します。

フォーム送信をNetworkで確認する

HTMLフォームの場合もNetworkで確認できます。

<form th:action="@{/users}" method="post">
    <input type="text" name="name">
    <input type="email" name="email">
    <button type="submit">登録</button>
</form>

送信後、Networkで/usersの通信をクリックします。

PayloadまたはForm Dataに、次のような値が出ます。

name: 山田太郎
email: yamada@example.com

ここに値が出ていない場合は、HTMLのname属性を確認してください。

フォーム送信では、inputのname属性がないと値が送られません。

悪い例です。

<input type="text" id="name">

良い例です。

<input type="text" id="name" name="name">

idは画面上の部品を識別する名前です。

nameはサーバーへ送るときの名前です。

Spring Bootの@RequestParamと対応するのはnameです。

PRGパターンのredirectもNetworkで確認できる

PRGパターンでは、POST後にredirectします。

@PostMapping("/users")
public String register() {
    return "redirect:/users";
}

Networkを見ると、次のような流れが確認できます。

順番MethodURLStatus
1POST/users302
2GET/users200

302は「別のURLへ移動してください」という意味です。

その後、GET /usersで一覧画面が表示されます。

PRGパターンが本当に動いているか確認したいときも、Networkタブが役立ちます。

ConsoleタブでJavaScriptエラーを確認する

Consoleタブは、JavaScriptのエラーやconsole.logの結果を見る場所です。

Chrome DevTools公式ドキュメントでは、Consoleを使ってconsole.logメッセージを確認できるだけでなく、任意のJavaScript文を評価してバグ修正の仮説を試せると説明されています。

画面のボタンを押しても反応しないときは、Consoleを見てください。

JavaScriptでエラーが出ている可能性があります。

Consoleでよく見るエラー

エラー例意味確認ポイント
Uncaught ReferenceError変数や関数が見つからない名前のスペル、scriptの読み込み順
Cannot read properties of nullnullに対して処理しようとしたidの指定、HTML読み込み前の実行
Unexpected token文法エラーカンマ、括弧、クォーテーション
Failed to fetchfetch通信に失敗URL、CORS、サーバー起動状態
404 in consoleファイルやAPIが見つからないパス、static配下、ControllerのURL

Consoleのエラーは、JavaScriptからの悲鳴です。

画面が無言で動かないときでも、Consoleには「ここで困っています」と出ていることがよくあります。

console.logで値を確認する

JavaScriptの変数に何が入っているか確認したいときは、console.logを使います。

const name = document.getElementById("name").value;
console.log("入力された名前:", name);

fetch()で送る直前のデータも確認できます。

const requestData = {
    name: name,
    email: email
};

console.log("送信データ:", requestData);

APIから返ってきたデータも確認できます。

fetch("/api/users")
    .then(function (response) {
        return response.json();
    })
    .then(function (data) {
        console.log("APIのレスポンス:", data);
    });

console.logは、JavaScriptのSystem.out.printlnのようなものです。

ただし、実務では個人情報やパスワードをConsoleに出さないように注意してください。

ConsoleでJavaScriptを直接試す

Consoleでは、その場でJavaScriptを実行できます。

たとえば、画面に次のHTMLがあるとします。

<input type="text" id="name" value="山田太郎">

Consoleに次のように入力できます。

document.getElementById("name").value

結果として、次のように表示されます。

山田太郎

ボタンが見つかるか確認することもできます。

document.getElementById("registerButton")

nullが返ってきたら、idが違うか、HTMLがまだ存在していません。

このようにConsoleは、コードの一部をその場で試す実験室として使えます。

ElementsタブでDOMを確認する

Elementsタブは、ブラウザが実際に解釈しているHTML構造、つまりDOMを確認する場所です。

Chrome DevTools公式ドキュメントでは、ElementsパネルはDOMツリーを調べたり操作したりでき、HTMLに似たDOMツリーから特定のノードを選択できると説明されています。

DOMとは、Document Object Modelの略です。

ブラウザがHTMLを読み取って作った、画面の部品ツリーだと考えてください。

HTMLファイルは設計図です。

DOMは、設計図をもとにブラウザが実際に組み立てた建物です。

HTMLソースとDOMは違う

新人エンジニアが混乱しやすい点として、HTMLソースとDOMは同じではありません。

Thymeleafでは、サーバー側でHTMLが生成されます。

たとえば、テンプレートには次のように書いていたとします。

<p th:text="${user.name}"></p>

ブラウザに届いた後のDOMでは、次のようになっているかもしれません。

<p>山田太郎</p>

Elementsタブで見るのは、ブラウザに届いて解釈された後のDOMです。

Thymeleafのth:textそのものではなく、変換後のHTMLを見ることになります。

つまり、Elementsは「最終的にブラウザが見ている姿」を確認する場所です。

Elementsでよく確認すること

確認したいこと見る場所例
要素が存在するかDOMツリーid="registerButton"があるか
idやnameが正しいか選択したHTMLname="email"になっているか
CSSが効いているかStylesdisplay:noneになっていないか
入力値が入っているかinput要素value属性や現在値
Thymeleafの結果変換後HTMLth:textが正しく表示されているか

画面に表示されない原因は、サーバー側だけとは限りません。

HTMLは存在しているけれど、CSSで非表示になっている場合もあります。

ElementsでDOMとStylesを確認しましょう。

idとnameをElementsで確認する

fetch()やフォーム送信でよくあるミスは、idとnameの混同です。

<input type="text" id="userName" name="name">

JavaScriptで値を取るときは、idを使うことが多いです。

document.getElementById("userName").value

フォーム送信でSpring Bootへ送るときは、nameが重要です。

@RequestParam String name
属性主な使い道
idJavaScriptやCSSで特定要素を探す
nameフォーム送信時のパラメータ名

Elementsでinputを選択し、idとnameが期待どおりか確認してください。

ここを見れば、Spring Boot側で値が取れない原因が見つかることがよくあります。

CSSが効かない原因をElementsで確認する

Elementsタブの右側にはStylesがあります。

Stylesでは、その要素にどのCSSが適用されているか確認できます。

たとえば、ボタンが見えない場合、次のようなCSSが効いているかもしれません。

display: none;

また、文字色と背景色が同じで見えない場合もあります。

color: white;
background-color: white;

CSSは「効いていない」のではなく、「別のCSSに上書きされている」ことも多いです。

Stylesを見ると、どのCSSが有効で、どのCSSが打ち消されているかを確認できます。

DevTools上で一時的にHTMLやCSSを変更する

Elementsでは、HTMLやCSSを一時的に変更できます。

たとえば、Stylesでheightを変更して地図の高さを試すことができます。

#map {
    height: 500px;
}

画面上ではすぐ反映されます。

ただし、DevTools上の変更はファイルには保存されません。

ページを再読み込みすると元に戻ります。

DevToolsで試して、良さそうなら実際のCSSファイルやHTMLへ反映します。

DevToolsは、下書き用のホワイトボードのようなものです。

本番のノートに清書するには、ソースコード側を修正してください。

Spring Boot開発でよくある確認パターン

パターン1：APIが呼ばれているか確認したい

1. Networkタブを開く
2. ボタンを押す
3. /api/usersなどの通信があるか探す
4. Statusを見る
5. PayloadとResponseを見る

通信がなければ、JavaScriptのイベントが動いていない可能性があります。

Consoleでエラーを確認しましょう。

パターン2：Spring Boot側で@RequestBodyがnullになる

1. Networkタブで対象APIをクリックする
2. Headersを見る
3. Content-Typeがapplication/jsonか確認する
4. Payloadを見る
5. JSONのキー名を確認する
6. Java DTOのプロパティ名とsetterを確認する

fetch()側では、次の3点が重要です。

headers: {
    "Content-Type": "application/json"
},
body: JSON.stringify(requestData)

Spring Boot側では、@RequestBodyが必要です。

@PostMapping("/api/users")
public UserDto createUser(@RequestBody UserCreateRequest request) {
    return userService.create(request);
}

パターン3：フォーム送信で@RequestParamが取れない

1. Elementsでinputのname属性を見る
2. NetworkでForm Dataを見る
3. Controllerの@RequestParam名と比較する

HTMLです。

<input type="text" name="email">

Controllerです。

@RequestParam String email

この名前が一致しているか確認してください。

パターン4：ボタンを押しても反応しない

1. ConsoleにJavaScriptエラーがないか見る
2. Elementsでボタンのidを確認する
3. JavaScriptのgetElementByIdの名前と比較する
4. scriptファイルが読み込まれているかNetworkで確認する

よくあるミスです。

<button id="registerButton">登録</button>
document.getElementById("registButton")

HTMLではregisterButton。

JavaScriptではregistButton。

スペルが違うため、JavaScript側で要素を取得できません。

パターン5：Thymeleafで値が表示されない

1. Controllerでmodel.addAttributeの名前を確認する
2. Thymeleafの${...}の名前を確認する
3. Elementsで実際に出力されたHTMLを見る
4. ConsoleやNetworkで500エラーが出ていないか確認する

Controllerです。

model.addAttribute("user", userDto);

Thymeleafです。

<p th:text="${user.name}"></p>

Model名とThymeleafの変数名が一致しているか確認してください。

ApplicationタブでCookieやSession関連を確認する

ログイン機能を作っていると、CookieやSessionも気になることがあります。

DevToolsのApplicationタブでは、CookieやLocalStorageなどを確認できます。

項目確認できるもの
CookiesJSESSIONIDなどのCookie
Local Storageブラウザに保存したデータ
Session Storageタブを閉じるまでの保存データ

Spring Bootのセッションを使っている場合、JSESSIONIDというCookieが出ることがあります。

JSESSIONIDは、ブラウザとサーバー側セッションを結びつけるためのIDです。

ログイン状態がうまく維持されない場合、Cookieが保存されているか確認するとヒントになります。

Sourcesタブでブレークポイントを使う

JavaScriptの動きを細かく追いたい場合は、Sourcesタブを使います。

Sourcesでは、JavaScriptの行にブレークポイントを置けます。

ブレークポイントとは、「この行で一時停止してください」という印です。

document.getElementById("registerButton").addEventListener("click", function () {
    const name = document.getElementById("name").value;
    const email = document.getElementById("email").value;
});

nameを取得する行にブレークポイントを置くと、ボタンを押したタイミングで処理が止まります。

その時点の変数の値を確認できます。

JavaのEclipseデバッガと似ています。

JavaScriptにもデバッガがある、と覚えてください。

DevToolsで調査するときの基本順序

不具合調査では、見る順番を決めると迷いにくくなります。

1. Consoleを見る
2. Networkを見る
3. Elementsを見る
4. Spring BootのConsoleログを見る
5. JavaのデバッガでControllerやServiceを確認する

まずConsoleでJavaScriptエラーを確認します。

次にNetworkでHTTP通信を確認します。

画面やHTMLの問題ならElementsを確認します。

サーバー側までリクエストが届いているなら、Spring BootのログやJavaデバッガを見ます。

フロント側かサーバー側かを切り分けるのが重要です。

フロント側とサーバー側の切り分け

症状見る場所判断
Networkに通信が出ないConsole、ElementsJavaScriptやHTML側の問題が多い
Networkに通信が出て404Network、ControllerURLやMappingの問題が多い
Networkに通信が出て400Payload、DTO、バリデーション送信データや形式の問題が多い
Networkに通信が出て500Spring Bootログ、Javaデバッガサーバー側例外が多い
通信は200だが画面が変わらないConsole、JavaScript処理レスポンス後の表示処理の問題が多い

この切り分けができると、調査がかなり速くなります。

「なんとなく動かない」から、「HTTPは200で返っているが、JavaScriptの画面反映処理が動いていない」まで具体化できます。

新人エンジニアが最初に覚えるチェックリスト

確認項目見る場所
JavaScriptエラーがあるかConsole
APIに通信が飛んでいるかNetwork
HTTPステータスは何かNetworkのStatus
送信データは正しいかNetworkのPayload
APIレスポンスは何かNetworkのResponse
HTML要素のidやnameは正しいかElements
CSSで非表示になっていないかElementsのStyles
CookieやSession IDはあるかApplication

このチェックリストを見ながら調査するだけでも、原因を見つけやすくなります。

よくある失敗とDevToolsでの見つけ方

失敗DevToolsでの見つけ方修正例
APIのURLが違うNetworkで404を見るfetchのURLと@GetMappingを合わせる
POSTのつもりがGETになっているNetworkのMethodを見るmethod: "POST"を指定する
JSONを送れていないPayloadが空JSON.stringifyを使う
Content-Typeが違うHeadersを見るapplication/jsonを指定する
JavaScriptのid指定が違うConsoleでnullエラーを見るElementsで実際のidを確認する
CSSで隠れているElementsのStylesを見るdisplayやvisibilityを確認する
Thymeleafの値が出ないElementsで最終HTMLを見るModel名とプロパティ名を確認する

DevToolsを使うときの注意点

DevToolsは便利ですが、いくつか注意点があります。

注意点理由
DevTools上のHTML変更は保存されない再読み込みすると元に戻る
パスワードをConsoleに出さないログから漏れる危険がある
APIレスポンスに機密情報を出さないNetworkで誰でも見える
本番環境の調査は慎重に行う個人情報や機密データが表示される可能性がある

Networkタブでは、APIから返ってきたJSONが見えます。

つまり、passwordHashや個人情報をAPIレスポンスに入れていると、ブラウザ側で見えてしまいます。

「画面に表示していないから安全」ではありません。

レスポンスに含めた時点で、DevToolsから確認できます。

APIでは、外に出してよい情報だけを返してください。

まとめ

DevToolsは、Webアプリケーション開発で必須の調査道具です。

Spring Boot、Thymeleaf、fetch()、API連携、JavaScript、CSSの不具合を調べるときに役立ちます。

タブ主な役割
NetworkHTTP通信、ステータス、Payload、Responseを確認する
ConsoleJavaScriptエラーやconsole.logを確認する
ElementsDOM、HTML、CSSを確認する
ApplicationCookie、LocalStorage、SessionStorageを確認する
SourcesJavaScriptをブレークポイントでデバッグする

一言でまとめるなら、DevToolsは「ブラウザ側で何が起きているかを見るための診断装置」です。

新人エンジニアは、まず次の流れを覚えてください。

画面が動かない
        ↓
ConsoleでJavaScriptエラーを見る
        ↓
NetworkでHTTP通信を見る
        ↓
PayloadとResponseを見る
        ↓
ElementsでDOMとid、name、CSSを見る
        ↓
必要ならSpring BootログやJavaデバッガを見る

今後の学習では、NetworkのHeaders、Payload、Response、Consoleのエラー読み取り、ElementsのDOM確認、ApplicationのCookie確認、Sourcesのブレークポイントを順番に学ぶとよいです。まずはfetch()でAPIを呼ぶ小さな画面を作り、DevToolsのNetworkで送信JSONとレスポンスJSONを確認してみましょう！

セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。

投稿者プロフィール

山崎講師
山崎講師代表取締役
セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。

学生時代は趣味と実益を兼ねてリゾートバイトにいそしむ。長野県白馬村に始まり、志賀高原でのスキーインストラクター、沖縄石垣島、北海道トマム。高じてオーストラリアのゴールドコーストでツアーガイドなど。現在は野菜作りにはまっている。
対象読者
新人エンジニア研修講師
前の記事
Spring Bootの@RestControllerとは？Webアプリケーションを学んだ新人エンジニア向けにAPIをやさしく解説New!!
2026年6月18日
次の記事
ローカルSMTPを使って問い合わせ完了メールを送る方法｜新人エンジニア研修向けにSpring BootとJavaMailSenderを解説New!!
2026年6月18日