観察 — curl と開発者ツールで HTTP の実物を読む
curl -v の > は送ったリクエスト、< は受け取ったレスポンス。-I でヘッダだけ、-L でリダイレクト追跡。開発者ツールの Network タブとあわせて、3 点セット読みを実物に当てる。
教材の HTTP から、実物の HTTP へ
ここまでの 5 章で、往復書簡の書式・動詞・返事の数字・添え書き・キャッシュと、読み方の道具はそろいました。この章では、それを実物に当てます。道具は 2 つ — コマンドラインの curl と、ブラウザの開発者ツールです。
この 2 つは役割が少し違います。curl は 1 本のリクエストを素のまま送って生のテキストを見せてくれる顕微鏡、開発者ツールはページ全体の何十本ものリクエストを一覧するレーダーです。1 本を深く見るなら curl、全体から異常を探すなら Network タブ、と使い分けます。
curl -v — 往復書簡がそのまま流れる
curl -v https://example.com/ を実行すると（-v は verbose、詳細表示）、接続の経過とともに、第 1 章で読んだ骨格がそのまま画面に流れます。読み方の鍵は行頭の記号です。
GET / HTTP/1.1）とリクエストヘッダHTTP/1.1 200 OK）とレスポンスヘッダつまり > の塊で「何を頼んだか」、< の 1 行目で「結果はどうだったか」、続く < の行で「条件と補足」— 3 点セットがそのまま並んでいます。
curl -v の出力の注釈図です。記号 3 種（* / > / <）の見分けが付けば、どんなに長い出力でも「準備」「頼んだこと」「返ってきたこと」の 3 ブロックに切り分けられます。
-I と -L — ヘッダだけ・転送の先まで
調査で頻出する 2 つのオプションを押さえます。
curl -I（大文字のアイ）は「ヘッダだけください」です。HEAD メソッド（第 2 章）でリクエストするので、返ってくるのはステータス行とヘッダのみ。Content-Type・Content-Length・Cache-Control といった添え書きを、本文をダウンロードせずに確認できます。
$ curl -I https://example.com/
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256
Cache-Control: max-age=86400
curl -L は「転送の先まで辿ってください」です。curl は既定ではリダイレクトを辿らず、301/302 の返事をそのまま見せます。この正直さは調査に便利で、「どこへ転送しようとしているか」は Location ヘッダで確認できます。最終的な中身まで欲しいときに -L を付けます。ブラウザは常に -L 相当の動きを自動でしているので、curl で初めて「転送そのもの」が観察できる、とも言えます。
小問 6-1 — curl の出力を読む
curl -v の記号と、-I・-L の使い分けです。第 1 章の骨格がそのまま出てきます。
Q1. curl -v https://example.com/ の出力に含まれる、行頭の > と < の意味として正しいものはどれですか。
矢印は通信の向きです。> は自分からサーバへ（送信 = リクエスト行とリクエストヘッダ）、< はサーバから自分へ（受信 = ステータス行とレスポンスヘッダ）。この 2 種類の行に、第 1 章で読んだ骨格がそのまま現れます。エラーか正常か、暗号化か平文かを表す記号ではありません。
Q2. 巨大なファイルの Content-Type や Content-Length を、本文をダウンロードせずに確認したいとき、最も適切な curl の使い方はどれですか。
-I は HEAD リクエストを送るオプションで、返ってくるのはヘッダだけです（第 2 章の HEAD の出番です）。-L はリダイレクト追跡、-o は本文をファイルに保存（まさにダウンロードしてしまう）、--data は POST 送信で目的と逆方向です。「ヘッダだけ見たい」は調査で頻出するので、-I は手に馴染ませておく価値があります。
Q3. curl https://example.com/old-page を実行すると 301 のレスポンスだけが返り、ページの中身が表示されませんでした。転送先まで自動で辿って中身を取得するオプションはどれですか。
curl は既定ではリダイレクトを辿らず、301/302 のレスポンスをそのまま見せてくれます（調査ではこの正直さが便利です）。-L を付けると Location ヘッダの転送先へ自動で再リクエストし、最終的な中身まで取得します。-I はヘッダのみ、-v は詳細表示、-s は進捗表示を消すオプションで、いずれも転送は辿りません。
開発者ツールの Network タブ — 列の意味が分かれば怖くない
ブラウザで開発者ツール（多くの環境で F12）を開き、Network タブを選んでページを再読み込みすると、そのページが発したすべてのリクエストが 1 行 1 本で並びます。まず読むべき列は 4 つです。
(disk cache) / (memory cache) と出たら、サーバにリクエストは飛んでいない（第 5 章の fresh の出口）。304 の行は転送が数百バイトになっているはず行をクリックすると Headers パネルが開き、リクエスト行・ステータス行・すべてのヘッダ — つまりこの講座で読んできたテキストそのもの — が確認できます。
もう 1 つ、チェックボックスの Disable cache を覚えてください。開発者ツールを開いている間だけキャッシュを無効にし、常にサーバから取得させる設定です。「修正が反映されない」ときに、キャッシュのせいか本当に反映されていないのかを切り分ける最短の道具です。
典型的な観察手順 — 3 点セットを実物に当てる
「表示がおかしい」「API が失敗する」と言われたときの、この講座の型に沿った手順をまとめます。
Step 4 が効くのは、curl がまっさらな 1 本を送ってくれるからです。ブラウザで再現する問題が curl で再現しなければ、疑うべきはキャッシュや Cookie などブラウザ側の状態 — 逆に curl でも再現すれば、サーバ側に絞れます。
小問 6-2 — Network タブを読む
ブラウザの開発者ツールで同じ 3 点セットを読みます。キャッシュの見え方が鍵です。
Q4. 開発者ツールの Network タブで、ある CSS ファイルの行の Size 列に (disk cache) と表示されています。意味として正しいものはどれですか。
Size 列の (disk cache) や (memory cache) は、第 5 章の「fresh — リクエストすら飛ばない」の出口が現実に見えている場面です。サーバではなく、ブラウザ自身のキャッシュから読まれました。つまり「サーバを直したのに変わらない」とき、この表示があれば原因はほぼ確定です。サーバ側のディスクやファイル破損の話ではありません。
Q5. Network タブの「Disable cache」にチェックを入れる目的として正しいものはどれですか。
Disable cache は「開発者ツールを開いている間だけ、ブラウザキャッシュを使わない」設定です。修正した CSS や JS が反映されているかを、キャッシュに邪魔されずに確認できます。キャッシュを使わないぶん表示はむしろ遅くなり、サーバ側や CDN のキャッシュには手を触れません。開発中の定番設定ですが、閉じれば元に戻る点も覚えておきましょう。
Q6. 「ページの表示がおかしい」と報告を受けて Network タブを開いたとき、この講座の型に沿った観察の初手として最も適切なものはどれですか。
3 点セット読みの実践形です。まず失敗行の「結果はどうだったか」（Status）を読み、百の位で誰の問題かを分類し、次に「何を頼んだか」（メソッドと URL）、最後に「条件と補足」（ヘッダ）へ進みます。全ボディの精読や再インストールから始めるのは順序が非効率で、Time 列は性能調査の道具 — エラー調査の初手はステータスコードです。
この章で持ち帰ること
- curl -v は > = 送ったもの、< = 受け取ったもの、* = 接続の経過。3 点セットがそのまま並ぶ
- -I はヘッダだけ（HEAD）、-L はリダイレクトの先まで。既定で転送を辿らない正直さが調査に効く
- Network タブは Status → メソッドと URL → Headers の順に読む。Size 列の
(disk cache)は「リクエストが飛んでいない」の目印 - ブラウザで再現して curl で再現しないならブラウザ側の状態、curl でも再現するならサーバ側 — 切り分けの定石
道具はすべてそろいました。最終章は総合演習 — 実務風の 8 つのケースに、この講座の型を当てて読み解きます。