Webページの画像、CSS、JavaScriptなどを毎回サーバーから取り直すと時間がかかります。キャッシュを使うと、保存済みのコピーを再利用できるため、表示が速くなったり通信量を減らしたりできます。

キャッシュは「近くに置いたコピー」です。便利ですが、古いコピーが残ると変更が反映されないこともあります。

この記事では、キャッシュの意味、ブラウザで表示が速くなる流れ、Cookieや履歴との違い、古い表示が出るときの対処、Cache-Controlの基本を初心者向けに整理します。

まず結論：キャッシュは近くに置くコピー

キャッシュは、元データを毎回取りに行かなくて済むように、よく使うデータのコピーを手元や近い場所に保存する仕組みです。Webではブラウザ、CDN、サーバー、DNSなど、いろいろな場所でキャッシュが使われます。

MDNでは、HTTPキャッシュは以前のレスポンスを再利用して不要なネットワーク要求を減らす仕組みとして説明されています。まずは「同じものを何度も取り直さないための保存」と覚えると十分です。

次の図では、利用者、キャッシュ、元データの関係を見てください。キャッシュは元データそのものではなく、近くに置かれたコピーです。

キャッシュで表示が速くなる流れ

ブラウザでWebページを開くと、HTML、CSS、JavaScript、画像など複数のファイルを読み込みます。初回はサーバーから取得しますが、保存できるものはブラウザのキャッシュに残ります。

以下の図で、初回アクセスで取得して保存し、2回目以降にキャッシュを使って速く表示する流れを確認してください。毎回サーバーへ取りに行かないことがポイントです。

HTTPの基本はHTTPとは？HTTPSとは？、Webページを開く入口はブラウザとは？で確認できます。

キャッシュがある場所

キャッシュはブラウザだけにあるものではありません。ブラウザの中、CDNなどの中間地点、サーバー内部、DNSの名前解決など、目的に応じていろいろな場所にあります。

キャッシュとCookie、履歴、ブックマークの違い

キャッシュとCookieはどちらもブラウザに残ることがありますが、目的が違います。キャッシュは表示を速くするためのコピー、Cookieはサイトが状態を覚えるための小さな情報です。履歴やブックマークも、さらに役割が違います。

Cookieの詳しい仕組みはCookieとは？で解説しています。キャッシュ削除とCookie削除は影響が違うため、トラブル対応では分けて考えましょう。

キャッシュが原因で起きること

キャッシュは便利ですが、古いコピーが残ると「画像を差し替えたのに前の画像が出る」「CSSを修正したのに画面が変わらない」「ログアウト後も古い画面が見える」のような混乱が起きることがあります。

• ページの見た目が古いまま表示される
• CSSやJavaScriptの修正が反映されない
• 画像を差し替えたのに前の画像が出る
• 開発中に変更したはずの画面が変わらない
• 個人情報を含むページを保存してほしくない場面がある

利用者側では再読み込み、強制再読み込み、キャッシュ削除で改善することがあります。開発者側では、ファイル名にバージョンやハッシュを付ける、適切なCache-Controlを返す、といった設計が必要になります。

Cache-Controlの基本

Webのキャッシュは、HTTPヘッダーで制御できます。代表的なのがCache-Controlです。保存してよいか、どれくらい新鮮とみなすか、使う前にサーバーへ確認するかを指示します。

次の図では、Cache-Controlでよく見る言葉を確認してください。特にno-cacheは「保存しない」ではなく、「使う前にサーバーへ確認する」という意味である点に注意します。

Cache-Control: max-age=3600
Cache-Control: no-cache
Cache-Control: no-store
ETag: "abc123"

MDNのCache-Control解説でも、no-cacheは保存を禁止するものではなく、再利用前の検証を要求するものと説明されています。保存させたくない場合はno-storeを検討します。

利用者ができる対処

ページが古いまま見えるとき、利用者側で試せることがあります。まず通常の再読み込みを行い、それでも変わらない場合は強制再読み込みやキャッシュ削除を試します。

• 通常の再読み込みをする
• 強制再読み込みをする
• ブラウザ設定からキャッシュされた画像やファイルを削除する
• 別のブラウザやシークレットウィンドウで確認する
• ログイン状態が関係する場合はCookie削除の影響も考える

ただし、会社PCや業務システムでは、勝手にCookieやサイトデータまで削除すると再ログインや設定リセットが必要になる場合があります。キャッシュだけを削除するのか、Cookieも含めるのかを確認してから操作しましょう。

開発者が注意するポイント

開発者は、速く表示したいファイルと、古い内容を見せたくないファイルを分けて考える必要があります。画像、CSS、JavaScriptなどの静的ファイルは長くキャッシュしやすい一方、HTMLや個人情報を含む応答は慎重に扱います。

• 変更されにくい静的ファイルは長めにキャッシュする
• 変更時にファイル名やURLを変えるキャッシュバスティングを使う
• HTMLは必要に応じて再検証させる
• 個人情報やログイン後の画面は共有キャッシュに載せない
• no-cacheとno-storeを混同しない

web.devでも、バージョン付きURLには長いmax-ageを使いやすく、バージョンなしURLでは再検証やno-storeなどを使い分ける考え方が紹介されています。

既存記事とあわせて読む順番

キャッシュは、ブラウザ、HTTP、Cookie、DNSと一緒に理解するとつながります。まずWebページが表示される流れを押さえ、そのうえで「保存して再利用する場所」を見ると理解しやすいです。

• ブラウザとは？
• HTTPとは？HTTPSとは？
• Cookieとは？
• URLとは？
• DNSとは何か？

公式情報と関連リンク

HTTPキャッシュの基本はMDNのHTTP caching、Cache-Controlの詳しい意味はMDNのCache-Control、実務寄りの考え方はweb.devのHTTP Cache記事が参考になります。

• MDN: HTTP caching
• MDN: Cache-Control header
• web.dev: Prevent unnecessary network requests with the HTTP Cache

まとめ

キャッシュは、一度取得したデータを保存して、次回以降すばやく使うための仕組みです。

• キャッシュは元データの近くに置いたコピー
• ブラウザキャッシュは画像、CSS、JavaScriptなどの再利用に役立つ
• Cookieは状態保存、キャッシュは表示高速化が主な目的
• 古いキャッシュが残ると変更が反映されないことがある
• no-cacheは保存禁止ではなく、使う前の確認を意味する
• 保存させたくない場合はno-storeを検討する

キャッシュを理解すると、Webページが速く表示される理由だけでなく、変更が反映されないときの切り分けもできるようになります。まずは「速くするためのコピー」として押さえ、Cookieや履歴とは分けて考えましょう。

たとえば、ログイン状態、表示言語、カートに入れた商品の情報などを覚えるために使われます。Webサイトを閉じても次に開いたときに状態が残ることがあるのは、Cookieが関係している場合があります。

Cookieは「食べ物のクッキー」ではなく、ブラウザとWebサイトの間で使われる小さなメモのような情報です。

この記事では、Cookieの意味、保存される情報、サーバーとのやり取り、キャッシュやWeb Storageとの違い、安全に使うポイントを初心者向けに整理します。

Cookieはサイト別に残る小さな情報

Cookieは、Webサイトがブラウザに保存し、必要に応じて同じサイトへ送り返される情報です。MDNでも、Cookieはサーバーがユーザーのブラウザへ送る小さなデータで、ブラウザが保存し、後続のリクエストで同じサーバーへ返すものとして説明されています。

最初は「Webサイトが、ブラウザ側に残しておく小さなメモ」と考えると理解しやすいです。ただし、何でも保存してよい場所ではなく、保存内容や送信条件には注意が必要です。

ブラウザ、Cookie、Webサイトの関係を見てください。Cookieはブラウザに保存されますが、Webサイトとのやり取りの中で使われます。

Cookieが使われる代表例

Cookieは、Webサイトが「この利用者は前にも来た」「この設定を選んでいた」と判断するために使われます。代表的な用途は、ログイン状態の維持、表示設定、ショッピングカート、アクセス解析などです。

重要なのは、Cookieにパスワードをそのまま保存するのが一般的な使い方ではない、という点です。多くの場合は、利用者やセッションを識別するID、設定値、状態を示す小さな値を保存します。便利な用途がある一方で、閲覧状況の計測や追跡に使われることもあります。

Cookieが保存されて送られる流れ

Cookieは、ブラウザだけで勝手に作られるものではありません。典型的には、サーバーがHTTPレスポンスでSet-Cookieを返し、ブラウザがそれを保存します。その後、同じサイトへアクセスするときに、ブラウザがCookieヘッダーとして送り返します。

HTTPヘッダーで見ると、イメージは次のようになります。実際には属性が増えることもありますが、まずはSet-CookieとCookieの2つを分けて見れば十分です。

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax

GET /mypage HTTP/1.1
Cookie: session_id=abc123

HTTPの基本はHTTPとは？HTTPSとは？、Webページを開く入口はURLとは？で詳しく整理しています。

セッションCookieと永続Cookie

Cookieには、大きく分けてセッションCookieと永続Cookieがあります。セッションCookieは、ブラウザを閉じるまでの一時的な情報として使われます。永続Cookieは、有効期限が設定され、ブラウザを閉じた後も残ることがあります。

ただし、実際の挙動はブラウザ設定やサイト側の作りによって変わります。初心者の段階では、「Cookieには一時的なものと、期限付きで残るものがある」と押さえれば十分です。

Cookieとキャッシュ、Web Storageの違い

Cookieと混同しやすい言葉に、キャッシュ、localStorage、sessionStorageがあります。どれもブラウザに情報が残ることがありますが、目的と送信のされ方が違います。

次の比較図では、Cookie、キャッシュ、localStorage、sessionStorageの違いを整理してください。特にCookieは、条件を満たすとHTTPリクエストに付いてサーバーへ送られる点が大きな特徴です。

Cookieを削除するとどうなるか

Cookieを削除すると、ログイン状態が切れたり、表示設定が初期状態に戻ったり、ショッピングカートの内容が消えたりすることがあります。これは、サイトがCookieを使って状態を覚えていたためです。

一方で、不要なCookieを削除したり、サードパーティCookieを制限したりすることは、プライバシー保護の観点で役立つ場合があります。ブラウザの設定画面では、サイトごとにCookieを確認・削除できることが多いです。

サードパーティCookieとは

Cookieには、今開いているサイトが発行するファーストパーティCookieと、別のドメインが関係するサードパーティCookieがあります。サードパーティCookieは、広告配信や計測などで使われることがあり、プライバシー上の理由から制限される方向にあります。

初心者は、まず「Cookieは便利な状態保存にも使われるが、閲覧状況をまたいで把握する用途にも使われることがある」と理解しておくとよいです。細かいブラウザ別の制限は変わるため、実務では各ブラウザや公式情報を確認します。

安全に使うための確認ポイント

Cookieは便利ですが、ログイン状態や識別情報に関係するため、扱いを間違えるとセキュリティやプライバシーの問題につながります。利用者側と開発者側で見るポイントを分けると整理しやすくなります。

次の図では、Cookieを安全に使うための確認ポイントを見てください。利用者は設定や削除、開発者は属性と保存内容を確認します。

• 利用者は、Cookie削除でログアウトや設定リセットが起きることを理解する
• 共有PCではログイン状態を残したままにしない
• 開発者は、重要なCookieにSecure、HttpOnly、SameSiteなどの属性を検討する
• Cookieにパスワードや秘密情報をそのまま保存しない
• サードパーティCookieや同意管理は、プライバシーの観点も含めて確認する

開発者が最初に見るCookie属性

Web開発でCookieを扱う場合は、値だけでなく属性も重要です。属性は、Cookieをどの範囲で、いつまで、どの通信で送るかを決めます。

OWASPのセッション管理に関する資料でも、セッションIDの保護やCookie属性の設定は重要な対策として扱われています。実務でログインに関係するCookieを扱う場合は、フレームワーク任せにせず、属性と保存内容を確認しましょう。

既存記事とあわせて読む順番

Cookieはブラウザ、URL、HTTP、サーバーとの関係で理解するとつながります。まずブラウザでWebページを開く流れを押さえ、そのうえでHTTPヘッダーとしてCookieを見ると理解しやすいです。

• ブラウザとは？
• URLとは？
• HTTPとは？HTTPSとは？
• クライアントサーバシステムとは？
• APIとは？APIとWeb APIの違い

公式情報と関連リンク

Cookieの基本はMDNのHTTP cookies、Set-Cookieヘッダー、Web Storageとの違いはMDNのWeb Storage APIが参考になります。セッション管理の安全性はOWASPの資料も確認対象になります。

• MDN: HTTP cookies
• MDN: Set-Cookie header
• MDN: Web Storage API
• OWASP Session Management Cheat Sheet

まとめ

Cookieは、Webサイトがブラウザに保存する小さな情報です。

• Cookieはブラウザに保存され、同じサイトへ送り返されることがある
• ログイン状態、表示設定、カート、計測などで使われる
• Set-Cookieは保存の指示、Cookieは送信される情報
• キャッシュやWeb Storageとは目的と送信のされ方が違う
• 安全に扱うには保存内容、Secure、HttpOnly、SameSiteなどを確認する

Cookieを理解すると、ブラウザ、HTTP、ログイン、セッション管理の関係が見えやすくなります。まずは「ブラウザに残るサイト別の小さなメモ」として押さえ、次に送信の流れと安全設定を確認していきましょう。

HTMLでテーブル（表）を作成するtableタグ（<table>タグ・<tr>タグ・<th>タグ・<td>タグ）の基本・意味・使い方を初心者向けにわかりやすく解説します。

<table>
  <tr>
    <th>見出し1</th>
    <th>見出し2</th>
  </tr>
  <tr>
    <td>データ1</td>
    <td>データ2</td>
  </tr>
  <tr>
    <td>データ3</td>
    <td>データ4</td>
  </tr>
</table>

tableタグはデータを行と列の形式で整理し、表示するために使用されるHTML要素。テーブルは、情報を視覚的に整理して比較しやすくすることができ、一般的には数値データや、関連する項目のリストなどを表示するのに適しています。

Webエンジニアを目指す方であれば知らないと恥ずかしい超・基本知識の１つです。是非最後までご覧ください。

参考　HTMLの基本構文ルール

HTML：テーブル（表）の定義方法

tableタグを使ってテーブルを作成する際には、次のようなタグを組み合わせて使用します。

テーブルを作るには、tableタグだけではなく、その要素を表す <tr>タグ・<th>タグ・<td>タグが必要になります。

全てを暗記する必要はありませんが、それぞれのタグがどのように利用され、どのような意味を持つのか？をまずは頭に入れておきましょう。

• <table>
  • テーブル全体を定義します。テーブルはこのタグで始まり、</table>で終わります。
• <tr>
  • テーブルの行を定義するために使用されるタグです。
    →Table Row (テーブルの行) の略です。「ここから新しい行が始まりますよ」という意味。
• <th>
  • テーブルの見出しセルを定義するために使用されるタグで、通常は行や列のラベルに使用されます。
    →Table Header (テーブルの見出し) の略です。行の中でも「見出し」となるセルに使います。
• <td>
  • テーブルのデータセルを定義するために使用されるタグで、実際のデータを表します。
    →Table Data (テーブルのデータ) の略です。行の中でも「データ」となるセルに使います。
    

最初のうちはちょっと複雑に感じるかもしれません。順を追って理解していきましょう。

HTML：<table>タグの使い方

<table>タグは、テーブル（表）を作成するタグです。

イメージとして「ここにテーブル（表）を作成しますよ！」という宣言をするだけの役割を担っていると考えてOK。

<table>
<!-- ここに行数や見出しなどを定義していく -->
</table>

HTML：<tr>タグの使い方

<tr>タグはテーブルの行数を指定するタグです。<tr>タグを設置した分だけ、行数が増えていくことになります。

上記の例で言えば、<tr>タグは4つ（＝４行あるので）設置していることになります。必要に応じて、何個でも設置することが可能です。

trとは「Table Row」の略です。Rowとは、行という意味を持つため迷ったときは略す前の名称を思い出すと良いでしょう。<tr>タグは、<table>タグの中にネストして利用します。

<table>
  <tr>
<!-- ここに表の値などを定義していく -->
  </tr>
  <tr>
<!-- ここに表の値などを定義していく -->
  </tr>
</table>

HTML：<th>タグの使い方

<th>タグは、テーブルの見出しやタイトルを定義します。

<th>タグは「Table Header」の略であり、<tr>タグの中にネストして利用します。なお、<th>タグは見出し・タイトルを定義するタグであるため、テキストは太字かつ中央寄せで表示されます。

<table>
  <tr>
    <th>国</th>
    <th>通貨</th>
    <th>言語</th>
  </tr>
  <tr>
<!-- ここに表の値を定義していく -->
  </tr>
</table>

HTML：<td>タグの使い方

<td>タグは「Table Data」の略で、テーブルセルの内容を定義します。<tr>タグの中にネストして利用します。

<table>
  <tr>
    <th>国</th>
    <th>通貨</th>
    <th>言語</th>
  </tr>
  <tr>
    <td>日本</td>
    <td>円</td>
    <td>言語</td>
  </tr>
  <tr>
    <td>アメリカ</td>
    <td>＄</td>
    <td>英語</td>
  </tr>
  <tr>
    <td>イギリス</td>
    <td>￡</td>
    <td>英語</td>
  </tr>
</table>

こちらのコードを実行した結果がこちら。

このように、<table>タグ・<tr>タグ・<th>タグ・<td>タグの４つを利用することでHTMLでテーブル（表）を定義することが可能になります。

<table>
  <tr>
    <th>見出し1</th>
    <th>見出し2</th>
  </tr>
  <tr>
    <td>データ1</td>
    <td>データ2</td>
  </tr>
  <tr>
    <td>データ3</td>
    <td>データ4</td>
  </tr>
</table>

現代のWeb環境におけるテーブル（表）の重要性

たまに、現代のWeb環境においてはテーブル（tableタグ）はもはや不要である？という意見を見かけますが、以下のような観点を踏まえると依然として重要なタグの１つであると言えます。

1. データの整理と表示
   • HTMLの表はデータを整理し、読みやすい形式で表示するのに適しています。例えば、統計データ、スケジュール、比較リストなどが挙げられます。
2. アクセシビリティ
   • 正しくマークアップされた表は、スクリーンリーダーを使用する視覚障害者に対して、情報の構造を明確に伝えることができます。
3. 互換性と標準化
   • ほとんどのブラウザでサポートされており、異なるデバイスやブラウザ間で一貫した表示を提供します。

ちょっと寄り道的に解説すると、昔はテーブル要素をページのレイアウトを整えるために利用する手法が流行った時期があるのですが、もうその目的では利用しませんよ・・・！ということを勘違いしてしまうと不要論につながってしまいます。

限定的な使用

• レイアウトツールとしての使用の減少
  • 過去にはWebページのレイアウト作成に広く使われていましたが、現在ではCSSフレックスボックスやグリッドレイアウトなどの技術が推奨されています。これらはレスポンシブデザインに適しており、より柔軟なレイアウトを可能にします。

最適な使用

• 意図した目的での使用
  • テーブルは主にタブラー形式のデータ表示のために使用するべきです。レイアウト目的での使用は、セマンティック（意味論的）なWebデザインの原則に反しています。
    参考　セマンティックHTMLとは？

HTMLの表は現代のWeb環境において、特定の用途、特にデータの整理とアクセス可能な表示において重要ですが、ページレイアウトのツールとしては他のより適した技術に取って代わられています。適切なコンテキストで使用される場合、表は効果的なツールであり続けます。

HTML：テーブルのデザイン

ここからは、HTMLでテーブルのデザイン変更を行う方法を解説していきます。CSSを使用してスタイルを指定する方が現代的で柔軟ですが、知識の１つとして知っておいて損はありません。

代表的な以下の属性について解説します。

tableタグで利用できる主な属性

• border属性
• bordercolor属性
• bgcolor属性
• cellspacing属性
• cellpadding属性

テーブルに罫線をつける方法（border属性）

border属性（参考 属性とは？）は、HTMLのtableタグにおいて、テーブルやセルの境界線（ボーダー）の幅を指定するために使用される属性です。この属性に数値を指定することで、ボーダーの幅をピクセル単位で設定できます。

例えば、次のようにtableタグにborder属性を指定することで、テーブル全体に1ピクセル幅のボーダーを適用できます。

<table border="1">
  ...
</table>

<style>
  table {
    border-collapse: collapse;
  }
  th, td {
    border: 1px solid black;
  }
</style>
<table>
  <tr>
    <th>見出し1</th>
    <th>見出し2</th>
  </tr>
  <tr>
    <td>データ1</td>
    <td>データ2</td>
  </tr>
  <tr>
    <td>データ3</td>
    <td>データ4</td>
  </tr>
</table>

上記を実行した結果がこちら。

枠線の色を変える（bordercolor）

bordercolor属性は、HTMLのテーブルやセルの境界線（ボーダー）の色を指定するためにかつて使用されていた属性です。この属性に色名や16進カラーコードを指定することで、ボーダーの色を設定できました。

例えば、以下のようにtableタグにbordercolor属性を指定することで、ボーダーの色を赤に設定できました。

<table border="1" bordercolor="red">
  ...
</table>

しかし、bordercolor属性も非標準の属性であり、HTML標準仕様には含まれていません。そのため、現代のWeb開発では使用を避け、代わりにCSSを利用してボーダーの色をスタイルすることが推奨されています。

例えば、以下のようにCSSのborderプロパティを使用して、同様のボーダーの色を適用できます。

<style>
  table {
    border-collapse: collapse;
  }
  th, td {
    border: 1px solid red;
  }
</style>

<table>
  <tr>
    <th>見出し1</th>
    <th>見出し2</th>
  </tr>
  <tr>
    <td>データ1</td>
    <td>データ2</td>
  </tr>
  <tr>
    <td>データ3</td>
    <td>データ4</td>
  </tr>
</table>

この例では、border-collapse: collapse;を使ってテーブルのボーダーがつながるようにしています。また、thおよびtd要素に対して、border: 1px solid red;を使って1ピクセル幅の赤いボーダーを適用しています。

CSSを使用することで、より柔軟で綺麗なデザインを実現できますし、標準仕様に準拠したコードを書くことができます。

背景色を変更する方法（bgcolor属性）

bgcolor属性は、HTMLの過去のバージョンで使用されていた属性で、テーブルやセルの背景色を指定するために使われていました。この属性に色名や16進カラーコードを指定することで、背景色を設定できました。

例えば、次のようにtableタグやtdタグにbgcolor属性を指定することで、背景色を設定できました。

<table bgcolor="#f2f2f2">
  <tr>
    <th>見出し1</th>
    <th>見出し2</th>
  </tr>
  <tr>
    <td bgcolor="lightblue">データ1</td>
    <td bgcolor="lightblue">データ2</td>
  </tr>
  <tr>
    <td>データ3</td>
    <td>データ4</td>
  </tr>
</table>

しかし、bgcolor属性はHTML4.01で非推奨となり、HTML5では完全に廃止されました。現代のWeb開発では、代わりにCSSを使用してテーブルやセルの背景色をスタイルすることが一般的です。

例えば、次のようにCSSのbackground-colorプロパティを使用して、同様の背景色を適用できます。

<style>
  table {
    background-color: #f2f2f2;
  }
  td:first-child {
    background-color: lightblue;
  }
</style>

<table>
  <tr>
    <th>見出し1</th>
    <th>見出し2</th>
  </tr>
  <tr>
    <td>データ1</td>
    <td>データ2</td>
  </tr>
  <tr>
    <td>データ3</td>
    <td>データ4</td>
  </tr>
</table>

セル間のスペースを指定（cellspacing属性）

cellspacing属性は、HTMLのtableタグにおいて、テーブル内のセル間のスペース（セルスペーシング）を指定するために使用される属性です。この属性に数値を指定することで、セル間のスペースをピクセル単位で設定できます。

例えば、次のようにtableタグにcellspacing属性を指定することで、セル間に5ピクセルのスペースを設けることができます。

<table cellspacing="5">
  ...
</table>

しかし、cellspacing属性も他の属性と同様にHTML5で非推奨となりました。代わりにCSSを使用してテーブルのセル間のスペースをスタイルすることが一般的です。

例えば、次のようにCSSのborder-spacingプロパティを使用して、同様のセル間のスペースを設定できます。

<style>
  table {
    border-collapse: separate;
    border-spacing: 20px;
  }
</style>

<table>
  <tr>
    <th>見出し1</th>
    <th>見出し2</th>
  </tr>
  <tr>
    <td>データ1</td>
    <td>データ2</td>
  </tr>
  <tr>
    <td>データ3</td>
    <td>データ4</td>
  </tr>
</table>

この例では、border-collapse: separate;を使ってテーブルのボーダーが分離されるようにしています。また、border-spacing: 20px;を使ってセル間のスペースを20ピクセルに設定しています

セル内のスペースを指定（cellpadding属性）

cellpadding属性は、HTMLのtableタグにおいて、テーブルのセル内の余白（セルパディング）を指定するために使用される属性です。この属性に数値を指定することで、セル内の余白をピクセル単位で設定できます。

例えば、次のようにtableタグにcellpadding属性を指定することで、セル内の余白を10ピクセルに設定することができます。

<table cellpadding="10">
  ...
</table>

しかし、cellpadding属性についてもHTML5で非推奨となりました。

代わりにCSSを使用してテーブルのセル内の余白をスタイルすることが一般的です。例えば、次のようにCSSのpaddingプロパティを使用して、同様のセル内の余白を設定できます。

<style>
  th, td {
    padding: 10px;
  }
</style>
<table>
  <tr>
    <th>見出し1</th>
    <th>見出し2</th>
  </tr>
  <tr>
    <td>データ1</td>
    <td>データ2</td>
  </tr>
  <tr>
    <td>データ3</td>
    <td>データ4</td>
  </tr>
</table>

Google Chrome、Safari、Microsoft Edge、Firefoxなどが代表的なブラウザです。スマートフォンやパソコンでWebサイトを見るとき、多くの場合はブラウザを通してページを開いています。

ブラウザは「インターネットそのもの」ではありません。インターネット上のWebページを見に行くための窓口です。

この記事では、ブラウザの意味、URLを開くと何が起きるのか、HTML・CSS・JavaScriptとの関係、検索エンジンやWebサイトとの違い、安全に使うポイントを初心者向けに整理します。

ブラウザはWebを見るための窓口

ブラウザは、ユーザーが入力したURLやクリックしたリンクをもとに、Webページを取得しに行くためのアプリ・ツールです。サーバーから受け取ったHTML、CSS、JavaScript、画像などを組み合わせて、読める画面として表示します。

MDNでは、ブラウザはWeb上のページを取得して表示し、リンクを通じて別のページへアクセスできるプログラムとして説明されています。まずは「Webページを取りに行って表示するアプリ」と覚えると十分です。

代表的なブラウザ

ブラウザにはいくつか種類があります。日常的によく使われるのは、Chrome、Safari、Microsoft Edge、Firefoxなどです。どれもWebページを見るためのアプリですが、開発元、標準設定、拡張機能、端末との相性などが異なります。

どのブラウザを使っても、基本的な役割は同じです。URLを開き、Webページを取得し、画面に表示します。

ブラウザ画面でよく見る名前

ブラウザを使うときは、画面上の名前もあわせて覚えると理解しやすくなります。URLを入力する場所はアドレスバー、複数のページを切り替える場所はタブ、よく見るページを保存する機能はブックマークです。

• アドレスバー：URLや検索語を入力する場所
• タブ：複数のWebページを同じブラウザ内で切り替える場所
• 戻る・進む：前後に見たページへ移動するボタン
• 更新ボタン：今見ているページを読み込み直すボタン
• ブックマーク：あとで見たいページを保存する機能
• 履歴：過去に開いたページの記録

問い合わせやトラブル対応で「ブラウザのタブを閉じる」「アドレスバーのURLを確認する」と言われることがあります。用語を知っているだけで、操作説明をかなり読み取りやすくなります。

ブラウザでページが表示される流れ

ブラウザでWebページを見るとき、裏側ではいくつかの処理が順番に進みます。細かい通信の仕組みを全部覚える必要はありませんが、URL、サーバー、HTTPという言葉が関係することは押さえておきましょう。

次の図では、ブラウザがURLを読み、サーバーへページを取りに行き、受け取った材料を画面に組み立てる流れを確認してください。

URLの基本はURLとは？、HTTPの仕組みはHTTPとは？HTTPSとは？で詳しく解説しています。

ブラウザは何を表示しているのか

Webページは、最初から完成した画像として届くわけではありません。多くの場合、ブラウザはHTML、CSS、JavaScript、画像などのファイルを受け取り、それらを解釈して画面を作ります。

HTMLはページの骨組み、CSSは見た目、JavaScriptは動きや操作を担当します。ブラウザはこれらの材料を読み取り、ユーザーが見やすい形に組み立てます。

次の図では、Webページの材料をブラウザが組み立てるイメージを見てください。ブラウザは単に文字を表示しているだけではなく、複数のファイルを解釈しています。

ブラウザ・検索エンジン・Webサイトの違い

初心者が混同しやすいのが、ブラウザ、検索エンジン、Webサイトの違いです。たとえばChromeはブラウザ、Google検索は検索エンジン、検索結果から開くページがWebサイトです。

Googleという名前は検索エンジンとして使われることもあれば、Chromeというブラウザを提供している会社名として出てくることもあります。そのため、最初は役割で分けて考えると混乱しにくくなります。

次の図では、ブラウザ、検索エンジン、Webサイト、アプリの違いを整理してください。

ブラウザでできること

ブラウザはWebページを見るだけでなく、さまざまな操作の入口になります。今のWebサービスでは、メール、地図、動画、買い物、資料作成、学習サイトなど、多くの機能がブラウザ上で使えます。

• URLを入力してWebページを開く
• 検索エンジンで情報を探す
• Webアプリを使う
• ファイルをダウンロードする
• ログインしてサービスを利用する
• タブや履歴、ブックマークでページを管理する

Webアプリとは、ブラウザ上で使えるアプリのようなものです。インストール型アプリと違い、URLを開くだけで使えるものも多くあります。

ブラウザを安全に使うポイント

ブラウザは便利ですが、危険なサイトや偽のログイン画面に出会うこともあります。安全に使うためには、アドレスバー、HTTPS、権限、更新、履歴やCookieを意識します。

次の図では、ブラウザを使うときの最低限の確認ポイントをまとめています。特に、ログイン前にURLとドメインを見る習慣は重要です。

• ログイン前にアドレスバーのドメインを確認する
• https://で通信が保護されているか見る
• 通知、位置情報、カメラなどの権限をむやみに許可しない
• ブラウザを古いまま使い続けない
• 共有PCでは履歴、Cookie、ログイン状態に注意する

ブラウザとサーバーの関係

ブラウザは、利用者側で動くクライアントです。サーバーは、Webページやデータを提供する側です。ブラウザがサーバーへ依頼し、サーバーが結果を返すことでWebページが表示されます。

この関係はクライアントサーバーシステムと呼ばれます。詳しくはクライアントサーバシステムとは？の記事で確認できます。

また、Web APIを呼び出すときも、ブラウザがサーバーへデータを取りに行くことがあります。APIの入口はAPIとは？APIとWeb APIの違いで整理できます。

既存記事とあわせて読む順番

ブラウザを理解したら、URL、HTTP、DNS、クライアントサーバーの順に読むと、Webページが表示される流れがつながります。

• URLとは？
• HTTPとは？HTTPSとは？
• DNSとは何か？
• クライアントサーバシステムとは？
• ゼロから学ぶネットワーク入門

公式情報と関連リンク

ブラウザの基本的な定義はMDNのBrowser用語集、Webページ表示の流れはMDNのHow the Web worksやHow browsers workが参考になります。初心者の段階では、まずブラウザがWebページを取得して表示するアプリだと理解できれば十分です。

• MDN Browser glossary
• MDN How the Web works
• MDN How browsers work

まとめ

ブラウザは、Webページを取得して、画面に表示するためのアプリです。

• Chrome、Safari、Edge、Firefoxなどが代表的なブラウザ
• ブラウザはURLを読み、サーバーからWebページの材料を受け取る
• HTML、CSS、JavaScript、画像などを組み立てて表示する
• ブラウザ、検索エンジン、Webサイトは役割が違う
• 安全に使うにはURL、HTTPS、権限、更新を確認する

ブラウザを理解すると、URL、HTTP、DNS、Web APIといったWebの基礎用語がつながりやすくなります。まずは、ブラウザを「Webページを見に行き、画面に表示するための窓口」として押さえましょう。

ブラウザの上にあるアドレスバーに表示されている、https://it-biz.online/... のような文字列がURLです。Webページを見る、画像を開く、APIへアクセスするなど、多くのWeb操作はこのURLを手がかりに始まります。

URLは「Web上の住所」です。住所を見ると建物の場所が分かるように、URLを見るとWeb上の目的地が分かります。

この記事では、URLの意味、ドメインやパスとの違い、URLを開くと何が起きるのか、安全に見るポイントを初心者向けに整理します。

まず結論：URLはWeb上の住所

URLは、Uniform Resource Locatorの略です。日本語では「統一資源位置指定子」と訳されることがありますが、最初からこの訳語を覚える必要はありません。まずは「Web上の住所」と考えると十分です。

MDNでは、URLはWebページ、画像、動画などのリソースがインターネット上のどこにあるかを示す文字列として説明されています。ここでいうリソースとは、Web上で取得できる情報やファイルのことです。

次の図は、URLを入力したブラウザが、目的のWebページへ向かうイメージです。

URLの基本形

URLは、いくつかの部品に分けて読めます。たとえば、次のURLを見てみます。

https://www.example.com/articles/url?id=10#summary

長く見えますが、最初に見るべきなのは、通信の種類、サイト名、ページの場所です。慣れてきたら、条件やページ内の位置も読めるようになります。次の図では、URLを部品ごとに分けて見てください。全部を暗記する必要はありませんが、ドメインとパスの違いは早めに押さえると役に立ちます。

実例でURLを読んでみる

実際のURLを読むときは、左から順番にすべてを完璧に理解しようとしなくて構いません。まずは、どのサイトの、どのページを開こうとしているのかを見ます。

たとえば、https://it-biz.online/it-skills/http/ というURLなら、https:// は安全なWeb通信、it-biz.online はサイト名、/it-skills/http/ はサイト内の記事の場所だと読めます。

検索結果やECサイトでは、URLの後ろに?keyword=...や?id=...のようなクエリが付くことがあります。これは、検索キーワード、商品ID、並び順、流入元などの追加情報を渡すために使われます。

また、#summaryのようなフラグメントは、同じページ内の特定位置へ移動するために使われます。ページの中にある「まとめ」や「見出し」へ直接飛ぶリンクでよく見かけます。

初心者のうちは、URL全体を暗記するよりも、長いURLを見たときに『ドメインはどこか』『パスはどこからか』『クエリは付いているか』を分ける練習をする方が実務で役立ちます。

URL・ドメイン・IPアドレスの違い

URLを学ぶと、ドメインやIPアドレスという言葉も出てきます。これらは似ていますが、同じものではありません。

ドメインは、it-biz.online のようなサイトの名前です。IPアドレスは、ネットワーク上の機器を識別する番号です。URLは、それらに加えて、ページの場所や条件まで含められます。

次の図では、URL、ドメイン、IPアドレス、ページタイトルを分けて見てください。混同しやすい言葉を先に整理しておくと、HTTPやDNSの記事が読みやすくなります。

URLを開くと何が起きるか

ブラウザでURLを開くと、ただ文字列を表示しているだけではありません。ブラウザはURLからドメインを読み取り、そのドメインがどのサーバーを指すのかを調べ、目的のページを取りに行きます。

この流れでは、DNSやHTTPが関係します。DNSはドメインからIPアドレスを調べる仕組みで、HTTPはブラウザとサーバーがWebページをやり取りするための通信の基本です。

次の図では、URLを開いてからページが表示されるまでの流れを確認してください。細かい通信手順をすべて覚えるより、URLがDNSやHTTPにつながっていることを押さえるのが先です。

httpとhttpsの違い

URLの先頭にあるhttp://やhttps://は、スキームと呼ばれます。Webページを見るときによく使われるのはHTTPとHTTPSです。

初心者の段階では、https://は通信が暗号化されるWeb通信、http://は暗号化されないWeb通信、と押さえれば十分です。ログイン、決済、個人情報入力では、基本的にhttps://になっているかを確認しましょう。

HTTPとHTTPSの詳しい仕組みは、HTTPとは？HTTPSとは？の記事で解説しています。

URLを見るときの安全チェック

URLは便利ですが、フィッシングサイトや怪しいリンクを見分けるときにも重要です。リンクの文字だけで判断せず、実際に開こうとしているURL、とくにドメインを確認します。

次の図では、URLを見るときの最低限のチェックポイントを整理しています。特に、https://かどうか、本当のドメインが何か、長いクエリに不要な情報が含まれていないかを見ます。

• ログイン前にhttps://か確認する
• 見た目のリンク文字ではなく、実際のドメインを見る
• 似た文字を使った偽ドメインに注意する
• 長いURLをそのまま共有すると、検索条件やIDが含まれることがある
• 不審な短縮URLは、信頼できる相手からのものか確認する

URLとURIの違いは最初から必要？

URLを調べると、URIという言葉も出てきます。URIは、より広くリソースを識別するための名前です。URLは、そのリソースの場所を示すものとして説明されます。

ただし、IT初心者が最初にWebページを見る範囲では、URLを理解できれば十分なことが多いです。URIとの細かい違いは、API設計や仕様書を読む段階で必要になったら深掘りすれば問題ありません。

既存記事とあわせて読む順番

URLを理解したら、ドメイン、DNS、HTTP、クライアントサーバーの順に読むと、Webページが表示される流れがつながりやすくなります。

• DNSとは何か？
• HTTPとは？HTTPSとは？
• クライアントサーバシステムとは？
• APIとは？APIとWeb APIの違い
• ゼロから学ぶネットワーク入門

公式情報と関連リンク

仕様として確認する場合は、WHATWG URL StandardとMDNのURL用語集を参照します。WHATWG URL Standardは、ブラウザなどがURLをどのように扱うかを定義する標準です。

• WHATWG URL Standard
• MDN URL 用語集
• MDN URL API

まとめ

URLは、Webページや画像などがインターネット上のどこにあるかを示す文字列です。

• URLはWeb上の住所として理解できる
• ドメインはサイト名、パスはサイト内の場所を表す
• URLを開くとDNSやHTTPの仕組みにつながる
• https://かどうか、本当のドメインは何かを確認する
• URIとの細かい違いは、最初は深追いしなくてよい

URLを読めるようになると、Webページの仕組み、HTTP、DNS、APIの理解が一気につながりやすくなります。まずは、URLを「通信の種類」「ドメイン」「ページの場所」に分けて見るところから始めましょう。

チャットのように双方が頻繁に送信するならWebSocketが候補になります。一方で、ニュース、通知、処理状況、ログのように「サーバー側で起きた変化を画面へ届けたい」だけなら、SSEの方がシンプルに書けることがあります。

SSEは「ブラウザからも自由に送る通信」ではありません。サーバーからブラウザへ流れる通知レーンとして見ると理解しやすくなります。

この記事では、SSEの意味、EventSourceの使い方、WebSocketやポーリングとの違い、再接続、運用上の注意点を初心者向けに整理します。

まず結論：SSEはサーバーからブラウザへの一方向通知

SSEの中心は、サーバーからクライアントへイベントを送ることです。クライアントとは、ここでは主にブラウザを指します。

ブラウザは最初にSSE用のURLへ接続します。その後、サーバーは接続を閉じずに、新しい通知があるたびにデータを少しずつ送ります。ブラウザ側では、そのデータをイベントとして受け取って画面へ反映します。

次の図では、SSEを「サーバーからブラウザへ流れる通知レーン」として見てください。WebSocketのような双方向の会話ではなく、サーバー発の更新を受け取る流れです。

SSEが必要になる場面

SSEが役立つのは、ユーザーが何度も更新ボタンを押さなくても、サーバー側の新しい情報を画面へ届けたい場面です。

• 処理の進捗を画面に表示したい
• 管理画面に新着通知を出したい
• サーバーログや監視結果を流したい
• ニュースフィードやタイムラインを更新したい
• 在庫、注文、ジョブ状態などの変化を反映したい

反対に、ユーザーがメッセージを頻繁に送り、相手からも返ってくるような双方向のやり取りでは、WebSocketの方が自然なことがあります。

REST API・ポーリング・WebSocketとの違い

SSEを理解するときに一番つまずきやすいのは、似た通信方式との違いです。ここでは、REST API、ポーリング、SSE、WebSocketを「何をしたいか」で分けます。

次の図では、実装名ではなく、読者が実現したい動きから選ぶように見てください。サーバーから一方的に知らせたいならSSE、双方が送るならWebSocketが候補です。

参考　REST APIとは何か？ / HTTPとは？HTTPSとは？

EventSourceで受け取る最小コード

ブラウザ側では、EventSourceを使ってSSEの接続を開きます。MDNでも、SSEを扱うAPIはEventSourceインターフェースに含まれると説明されています。

const source = new EventSource("/events");

source.onopen = () => {
  console.log("SSEに接続しました");
};

source.onmessage = (event) => {
  console.log("受信:", event.data);
};

source.onerror = () => {
  console.log("接続エラーまたは再接続中です");
};

// 画面を閉じる、購読をやめるなどのタイミングで呼ぶ
// source.close();

このコードでは、new EventSource("/events")でサーバーのイベント配信URLへ接続します。onmessageは、サーバーから通常のメッセージが届いたときに実行されます。

ただし、このコードだけをブラウザに貼っても動きません。サーバー側がSSE用のレスポンスを返す必要があります。SSEは、ブラウザ側のEventSourceと、サーバー側のtext/event-stream形式のレスポンスがセットです。

次の図では、コードの左側とサーバーから流れてくる文字列の右側を対応させて見てください。EventSourceは受け口、text/event-streamは流れてくる形式です。

サーバーが返すtext/event-streamの形

SSEでは、サーバーがContent-Type: text/event-streamのレスポンスを返します。MDNの例でも、サーバー側はtext/event-streamで応答し、各通知をテキストのブロックとして送ると説明されています。

event: progress
data: {"percent": 80}
id: 42

この例では、eventがイベント名、dataが実際に渡したいデータ、idがイベントの識別子です。最後の空行で、1件のイベントが終わります。

イベント名を付けない場合は、ブラウザ側では通常のmessageイベントとして受け取れます。イベント名を付けた場合は、addEventListener("progress", ...)のように名前で分けて処理できます。

再接続とLast-Event-IDの考え方

SSEの便利な点の1つは、接続が切れたときにブラウザが再接続を試みることです。MDNでも、クライアントとサーバーの接続が閉じた場合、デフォルトでは接続が再開されると説明されています。

ただし、自動再接続があるから何も考えなくてよい、という意味ではありません。途中で切れた場合に、同じ通知を二重に処理しないか、逆に通知が抜けないかを考える必要があります。

次の図では、idを手がかりに、どこまで読んだかを復旧するイメージを見てください。実務では、イベントIDや状態管理を使って、再接続後の抜けや重複を減らします。

SSEを使うときの注意点

SSEはWebSocketよりシンプルに見えますが、運用では長く開いたHTTP接続として扱う必要があります。特に、接続数、中継サーバー、切断復旧は先に見ておきたいポイントです。

次の図では、実装後に詰まりやすい場所を3つに分けています。SSEは一方向の通信としては分かりやすい一方で、開いた接続を維持するための設計が必要です。

• HTTP/1.1では同一ブラウザ・同一ドメインの接続数制限に注意する
• HTTP/2を使える環境では、同時ストリーム数の扱いも確認する
• プロキシやロードバランサーがレスポンスをバッファしないか確認する
• 切断時に再接続できるだけでなく、抜けや重複も考える
• 長時間接続を前提に、認証切れや権限変更時の扱いを決める

MDNでは、HTTP/2ではない場合、SSEのオープン接続数に制限があり、複数タブで痛みやすい点も注意されています。小さなデモでは問題にならなくても、実務ではユーザー数、タブ数、接続先ドメインを含めて考えましょう。

SSEを選ぶ判断基準

SSEを選ぶかどうかは、通信の派手さではなく、必要な方向で決めます。サーバーからブラウザへ知らせるだけならSSEは有力です。ブラウザからも細かく送るならWebSocket、単発の取得や登録ならREST APIが自然です。

初心者の段階では、SSEを「WebSocketの簡易版」と覚えるより、「サーバーから一方向に流す標準機能」と覚える方が正確です。役割が違うため、どちらが上位という関係ではありません。

既存記事とあわせて読む順番

SSEを理解するには、HTTP、クライアントサーバー、API、REST APIの順で土台を確認すると読みやすくなります。

• クライアントサーバシステムとは？
• HTTPとは？HTTPSとは？
• APIとは？APIとWeb APIの違い
• REST APIとは何か？
• ゼロから学ぶネットワーク入門

公式情報と関連リンク

仕様やAPIを確認する場合は、WHATWG HTML StandardのServer-sent events、MDNのServer-sent events、EventSourceのページを参照します。

• WHATWG HTML Standard: Server-sent events
• MDN Server-sent events
• MDN Using server-sent events
• MDN EventSource

まとめ

Server-Sent Events（SSE）は、サーバーからブラウザへ更新情報を一方向に流すためのWeb標準の仕組みです。

• SSEはサーバーからブラウザへの一方向通知に向いている
• ブラウザ側ではEventSourceを使って受け取る
• サーバー側はtext/event-stream形式でイベントを流す
• WebSocketは双方向、SSEは一方向と分けて考える
• 実務では接続数、再接続、バッファリング、認証を確認する

SSEを理解すると、リアルタイム更新をすべてWebSocketで考えずに済みます。サーバーから知らせるだけでよい場面では、SSEという選択肢を持っておくと設計がシンプルになります。

通常のHTTP通信では、ブラウザがリクエストを送り、サーバーがレスポンスを返す、という往復が基本です。一方でWebSocketでは、接続を開いた後、ブラウザからサーバーへも、サーバーからブラウザへも、必要なタイミングでデータを送ることが可能。

WebSocketは「ページを表示するための仕組み」ではなく、「開いた接続で会話を続ける仕組み」と考えると理解しやすくなります。

この記事では、WebSocketの意味、HTTPやREST APIとの違い、接続開始の流れ、JavaScriptでの最小コード、使いどころと注意点を初心者向けに整理します。

まず結論：WebSocketは双方向のリアルタイム通信

WebSocketの一番大事な特徴は、双方向通信です。双方向通信とは、クライアント側から送るだけでなく、サーバー側からもクライアントへデータを送れる通信のことです。

ここでいうリアルタイム通信は、厳密に遅延がゼロという意味ではありません。ユーザーが待って更新ボタンを押さなくても、サーバー側の変化を短い遅延で画面へ届けられる、という意味で使われます。

チャットで相手の発言がすぐ表示される、管理画面に新しい通知がすぐ出る、共同編集で他の人の変更が反映される。こうした「サーバー側で起きた変化を画面へすぐ届けたい」場面でWebSocketが候補になります。

次の図で、WebSocketを「ブラウザとサーバーが1本の接続で会話を続ける仕組み」として見てください。

HTTPとの違い

HTTPは、Webページの表示やAPI呼び出しで広く使われる通信の基本です。ブラウザが「このページをください」「このデータをください」と依頼し、サーバーが返事をする形で進みます。

HTTPの基本はHTTPとは？HTTPSとは？の記事で要チェック！

WebSocketも最初の接続開始ではHTTPの仕組みを利用します。しかし、接続が確立した後は、毎回HTTPリクエストを作るのではなく、開いた接続の上で小さなメッセージをやり取りします。

次の比較図では、HTTPは「依頼して返事をもらう」、WebSocketは「開いた接続で会話を続ける」と読み分けてください。

WebSocketの接続はどう始まるか

WebSocketは、いきなり独自の通信だけで始まるわけではありません。一般的なWebの文脈では、最初にHTTPのリクエストとして接続を始め、サーバーがWebSocketへ切り替える流れを受け入れると、その後WebSocketの通信へ進みます。

RFC 6455では、WebSocketプロトコルは接続開始のハンドシェイクと、その後のメッセージフレーミングから成り、TCP上で動くものとして説明されています。初心者の段階では、まず「最初に握手して、接続ができたらメッセージを送り合う」と押さえれば十分です。

次の図では、WebSocket接続が始まる順番を確認してください。HTTPのUpgrade、切り替え成功、その後のメッセージ交換という3段階で見ます。

JavaScriptで見るWebSocketの最小コード

ブラウザのJavaScriptでは、WebSocketオブジェクトを作ってサーバーへ接続します。URLは、暗号化なしならws://、TLSで保護するならwss://を使います。実務のWebサイトでは、基本的にwss://を選ぶと考えてください。

const socket = new WebSocket("wss://example.com/chat");

socket.addEventListener("open", () => {
  socket.send("こんにちは");
});

socket.addEventListener("message", (event) => {
  console.log("受信:", event.data);
});

socket.addEventListener("close", () => {
  console.log("接続が閉じました");
});

socket.addEventListener("error", (event) => {
  console.error("通信エラー", event);
});

このコードでは、openで接続開始、sendで送信、messageで受信、closeで切断、errorでエラーを扱っています。

ただし、このコードだけをブラウザに貼っても、接続先のWebSocketサーバーがなければ動きません。WebSocketは、ブラウザ側のコードとサーバー側の受け口がセットで必要になる通信です。

ここで重要なのは、messageイベントです。WebSocketでは、サーバー側からメッセージが届いたタイミングで処理を実行できます。通常のREST APIのように、毎回こちらから取得しに行く発想とは少し違います。

WebSocketを使う場面

WebSocketは、どんなWeb開発でも必ず使うものではありません。強みが出るのは、サーバー側で起きた変化を、クライアント側へすぐ届けたい場面です。

次の図では、WebSocketが向いている代表的な場面を確認してください。見るポイントは「サーバー側の変化を待たずに画面へ届けたいか」です。

• チャットや問い合わせ画面で、新しいメッセージをすぐ表示したい
• 注文、障害、監視、株価などのライブ通知を表示したい
• 共同編集ツールで、他の人の変更をリアルタイムに反映したい
• ゲームやダッシュボードで、状態変化を継続的に受け取りたい

反対に、普通の記事ページを表示する、検索結果を返す、フォームの登録結果を返す、といった処理ではHTTPやREST APIで十分なことが多いです。

REST APIやポーリングとの使い分け

REST APIは、クライアントが必要なタイミングでサーバーへ問い合わせ、結果を受け取る設計でよく使われます

参考　REST APIとは何か？

ポーリングは、一定間隔でサーバーへ問い合わせる方法です。たとえば5秒ごとに「新着はありますか？」と聞き続けます。実装は分かりやすい一方で、何も変化がないときも通信が発生します。

判断に迷ったら、まず「サーバー側の変化をすぐ画面に届ける必要があるか」を見ます。必要がなければREST APIで十分なことが多く、必要があるならWebSocketを検討します。

参考　APIとは？APIとWeb APIの違い

Socket.IOとは何が違う？

WebSocketを調べていると、Socket.IOという名前もよく出てきます。ここで混同しやすいのは、WebSocketが通信プロトコルであるのに対し、Socket.IOはリアルタイム通信を扱いやすくするためのライブラリだという点です。

Socket.IOは、再接続、イベント名付きの送受信、環境に応じた通信方式の切り替えなどを助けます。一方で、ブラウザ標準のWebSocket APIとはそのまま互換ではありません。Socket.IOを使う場合は、サーバー側もSocket.IOに対応している必要があります。

初心者の段階では、まずWebSocketを通信の考え方として理解し、その後で「実装を楽にする選択肢としてSocket.IOがある」と分けておくと混乱しにくくなります。

初心者が誤解しやすいポイント

WebSocketは便利ですが、アプリケーション設計のすべてを置き換えるものではありません。画面表示、通常のデータ取得、ログイン、履歴取得などはHTTPやREST APIで行い、リアルタイム更新部分だけWebSocketにする構成もよくあります。

セキュリティと運用で見るポイント

WebSocketを実務で使うときは、接続できることだけでなく、誰が接続しているのか、どのメッセージを許可するのか、切断時にどう復旧するのかを考える必要があります。

• wss://を使い、通信をTLSで保護する
• 接続時やメッセージ処理時に認証・認可を確認する
• 予期しない切断に備えて再接続の設計をする
• サーバー側で接続数、送信頻度、メッセージサイズを制御する
• ブラウザやネットワーク環境による切断を前提にログを残す

特に重要なのは、WebSocket接続が長く続くことです。通常のHTTPリクエストよりも、接続数や切断時の処理が運用に影響しやすくなります。

既存記事とあわせて読む順番

WebSocketを理解するには、HTTP、クライアントサーバー、APIの順に土台を確認してから読むとつながりやすくなります。

• クライアントサーバシステムとは？
• HTTPとは？HTTPSとは？
• APIとは？APIとWeb APIの違い
• REST APIとは何か？
• ゼロから学ぶネットワーク入門

公式情報と関連リンク

仕様を深く確認する場合は、IETFのRFC 6455とMDNのWebSocket APIリファレンスを参照します。初心者の段階では、RFCを最初からすべて読む必要はありません。この記事で全体像を押さえた後、実装時に必要なイベント、メソッド、接続開始の仕様を確認すると効率的です。

• RFC 6455: The WebSocket Protocol
• MDN WebSocket API
• MDN WebSocket API overview

まとめ

WebSocketは、ブラウザとサーバーが1本の接続を開いたまま、双方向にメッセージを送り合うための通信技術です。

• WebSocketはリアルタイムな双方向通信に向いている
• HTTPは用事ごとのリクエストとレスポンス、WebSocketは接続を保った会話として見る
• チャット、ライブ通知、共同編集などで使われる
• REST APIを置き換えるものではなく、用途で使い分ける
• 実務では認証、切断、再接続、接続数の管理も重要

最初は「WebSocketは、サーバーからもブラウザへすぐ送れる通信」と覚えるだけで十分です。そのうえで、HTTPやREST APIと役割を分けて考えると、どの場面で使うべきか判断しやすくなります。

長いオブジェクト型、複数の候補を持つunion型、関数の引数や戻り値の型を、そのまま毎回書くとコードが読みにくくなります。typeを使うと、それらの型に意味のある名前を付けられます。

typeはJavaScriptの値を作る命令ではありません。TypeScriptの型チェックで使う「型の名前」です。

この記事では、typeの基本構文、union型で便利な理由、interfaceとの違い、実務での使い分けを初心者向けに整理します。

まず結論：typeは型に名前を付けるための書き方

TypeScript公式ドキュメントでは、同じ型を何度も参照するために名前を付けられる仕組みとしてtype aliasが説明されています。まずは「型の別名を作る」と考えると分かりやすいです。

type User = {
  id: number;
  name: string;
};

function showUser(user: User) {
  console.log(user.name);
}

この例では、{ id: number; name: string }という型にUserという名前を付けています。以後は、同じ型をUserとして読めます。

typeが必要になる理由

型をその場に直接書くこともできます。しかし、同じ型が複数箇所に出てくると、コードの意味が追いにくくなります。

function send(user: { id: number; name: string; email?: string }) {
  // ...
}

function save(user: { id: number; name: string; email?: string }) {
  // ...
}

このような型は、typeで名前を付けると、何を表すデータなのかが分かりやすくなります。

type User = {
  id: number;
  name: string;
  email?: string;
};

function send(user: User) {
  // ...
}

function save(user: User) {
  // ...
}

typeの価値は、短くすることではなく、型に意味のある名前を付けることです。

typeの読み方を図で見る

次の図では、typeを「型を書く、名前を付ける、何度も使う」という流れで見てください。型の分類名より先に、再利用の流れを理解するのがポイントです。

union型に名前を付けると便利

typeは、オブジェクト型だけでなく、複数の候補を持つunion型にも名前を付けられます。

type Status = "loading" | "success" | "error";

let currentStatus: Status = "loading";

このように書くと、Statusには指定した文字列だけを入れられます。画面の状態、APIの結果、処理ステータスなどを表すときに便利です。

typeは実行時の値を作らない

初心者が混同しやすいのは、typeがJavaScriptのオブジェクトや変数を作るわけではない点です。TypeScriptの型は、基本的にコンパイル時のチェックに使われます。

type User = {
  id: number;
  name: string;
};

const user: User = {
  id: 1,
  name: "Sato",
};

実際に存在する値はuserです。Userは、その値がどんな形であるべきかを確認するための型名です。

interfaceとの違い

typeとinterfaceは、どちらもオブジェクトの形に名前を付けられます。そのため、簡単なオブジェクト型だけを見ると似ています。

TypeScript公式ドキュメントでも、typeとinterfaceは多くの場面で似ており、必要な機能が出てくるまでは個人の好みで選べるという考え方が示されています。

typeを使うとよい場面

• union型に名前を付けたい
• 文字列リテラルの候補を管理したい
• 関数の引数や戻り値の型を短く読みたい
• 複数の型を組み合わせて別名を付けたい

type ApiResult =
  | { ok: true; data: string[] }
  | { ok: false; message: string };

このような「成功か失敗かで形が変わるデータ」は、typeで表すと読みやすくなります。

interfaceを使うとよい場面

interfaceは、オブジェクトの形を拡張していく場面でよく使われます。クラスの実装条件や、ライブラリの型定義でもよく見かけます。

interface User {
  id: number;
  name: string;
}

interface AdminUser extends User {
  role: "admin";
}

初心者のうちは、union型や文字列候補ならtype、オブジェクトの形を拡張したいならinterfaceと考えると判断しやすいです。

初心者がつまずきやすいポイント

type名の付け方

typeは型を短くするためだけに使うものではありません。型名を見たときに、そのデータが何を表すのか分かることが大切です。

たとえば、DataやValueだけでは意味が広すぎます。ユーザー情報ならUser、画面状態ならPageStatus、APIの返却結果ならApiResultのように、役割が分かる名前を付けると読みやすくなります。

type PageStatus = "idle" | "loading" | "success" | "error";

type UserSummary = {
  id: number;
  displayName: string;
};

名前を付けることで、関数の引数や戻り値を見ただけで、コードの意図を追いやすくなります。これは型安全性だけでなく、チームで読むコードの分かりやすさにも効きます。

型を直すときの考え方

実務では、最初に作った型があとから変わることがあります。たとえば、APIの返却項目が増えたり、ステータスの種類が増えたりする場合です。

このとき、同じ型を複数箇所へ直接書いていると、修正漏れが起きやすくなります。typeで名前を付けておけば、変更する場所を集約しやすくなります。

ただし、何でも1つの巨大な型にまとめると、逆に読みにくくなります。画面用、API用、保存用など、役割が違う型は分けて名前を付けるのが現実的です。

チームで読むコードとしてのtype

TypeScriptの型は、自分のためだけでなく、あとから読む人への説明にもなります。関数の引数にUserと書かれていれば、その関数がユーザー情報を受け取ることがすぐ分かります。

逆に、毎回長いオブジェクト型を直接書いていると、同じ意味の型なのか、少し違う型なのかを判断しづらくなります。共有して使う型には名前を付け、画面の中だけで一度しか使わない型は無理に外へ出さない、という線引きが実務では扱いやすいです。

公式情報と関連して読みたい記事

• TypeScript Handbook: Type Aliases
• TypeScript Handbook: Object Types
• TypeScriptのinterfaceとは？
• TypeScriptのunion型とは？

まとめ

TypeScriptのtypeは、型に名前を付けて読みやすく再利用するための書き方です。

• 長い型に意味のある名前を付けられる
• union型や文字列リテラル型と相性がよい
• 実行時の値を作るものではない
• interfaceとは似ているが、得意な場面が少し違う

Promiseが分かると、fetch、then、catch、async/await のコードを「何を待って、どこで結果を受け取るのか」という流れで読めるようになります。

Promiseは「結果そのもの」ではなく、「あとで結果を受け取る入口」です。最初はこの理解だけで十分です。

この記事では、Promiseの意味、3つの状態、then・catch・finallyの使い方、fetchでつまずきやすいポイント、async/awaitとの関係を順番に解説します。

まず結論：Promiseは将来の結果を表すオブジェクト

Promiseは、非同期処理の最終的な成功または失敗を表すオブジェクトです。MDNでも、Promiseは非同期処理の完了または失敗と、その結果の値を表すものとして説明されています。

ただし、初心者のうちは仕様文を暗記するより、次の読み方を先に覚える方が実用的です。

非同期処理を始める
  ↓
Promiseが返る
  ↓
成功したら then
失敗したら catch
最後に finally

この時点で大事なのは、Promiseが返ってきても、まだ中身の結果を直接持っているとは限らないことです。結果はあとから成功または失敗として確定します。

Promiseが必要になる場面

JavaScriptでは、通信、タイマー、ファイル読み込みのように、すぐ終わらない処理がよく出てきます。特にWebアプリでは、APIからデータを取るfetchが代表例です。

通信が終わるまで画面全体を止めると、ユーザーは操作できません。そのためJavaScriptでは、通信を待っている間も他の処理を進め、結果が返ってきたときに続きを実行します。

この「あとで続きを実行する」ための約束を整理するのがPromiseです。

Promiseの流れを図で見る

次の図では、Promiseを「非同期処理の結果を、成功・失敗・最後の処理へ分けて受け取る流れ」として見てください。細かい用語より先に、左から右への読み順を作るのがポイントです。

pending・fulfilled・rejectedの3状態

Promiseには状態があります。まずは次の3つだけ押さえれば十分です。

Promiseは最初にpendingになり、その後、成功すればfulfilled、失敗すればrejectedになります。成功と失敗のどちらかに決まった状態を、実務では「settled」と表現することもあります。

then・catch・finallyの役割

Promiseでよく使うのは、then、catch、finallyです。

fetch("/api/users")
  .then((response) => response.json())
  .then((users) => {
    console.log(users);
  })
  .catch((error) => {
    console.error("取得に失敗しました", error);
  })
  .finally(() => {
    console.log("読み込み処理を終了します");
  });

ポイントは、前のthenで返した値が、次のthenへ渡されることです。response.json()を返すから、次のthenで変換後のデータを受け取れます。

fetchでよくある誤解：HTTPエラーは必ずcatchに入るわけではない

Promiseをfetchで使うとき、初心者がつまずきやすいのがエラー処理です。ネットワーク自体に失敗した場合はcatchに入りますが、HTTPステータスが404や500の場合は、必ずしも自動でcatchに入るとは限りません。

fetchの結果では、response.okを見て、HTTPとして成功扱いできるかを確認するのが安全です。

fetch("/api/users")
  .then((response) => {
    if (!response.ok) {
      throw new Error("HTTPエラー: " + response.status);
    }
    return response.json();
  })
  .then((users) => {
    console.log(users);
  })
  .catch((error) => {
    console.error(error);
  });

このように書くと、通信そのものの失敗だけでなく、サーバーがエラーを返した場合も同じcatchで扱いやすくなります。

async/awaitはPromiseを読みやすくする書き方

async/awaitは、Promiseと別物ではありません。Promiseを、上から順に読む形で書きやすくするための構文です。

async function loadUsers() {
  try {
    const response = await fetch("/api/users");

    if (!response.ok) {
      throw new Error("HTTPエラー: " + response.status);
    }

    const users = await response.json();
    console.log(users);
  } catch (error) {
    console.error(error);
  }
}

awaitはPromiseの完了を待ち、その結果を取り出します。つまり、async/awaitを使っていても、裏側ではPromiseを扱っています。

最初に覚える判断基準

• fetch()の戻り値はPromiseとして読む
• thenでは次へ渡したい値をreturnする
• HTTPステータスの失敗はresponse.okで確認する
• async/awaitはPromiseを消すものではなく、読みやすくする書き方と考える

Promise.allは最初から暗記しなくてよい

Promiseを調べると、Promise.all、Promise.race、Promise.allSettledなども出てきます。これらは複数のPromiseをまとめて扱うための機能です。

ただし、初学者が最初に全部を覚える必要はありません。まずは、1つのPromiseが成功・失敗へ分かれる流れを読めることが先です。複数の通信を同時に待つ必要が出てきたときに、Promise.allを学ぶ順番で問題ありません。

たとえば、ユーザー情報と注文履歴を同時に取得したい場合は、複数のPromiseをまとめて待つ考え方が必要になります。一方、単に1つのAPIからデータを取るだけなら、then・catch・finallyとasync/awaitを理解していれば十分です。

コードレビューで見るポイント

Promiseを使ったコードを読むときは、まず「どこでPromiseが作られ、どこで結果を取り出しているか」を見ます。次に、失敗時の処理があるか、ローディング表示などの後片付けが漏れていないかを確認します。

特にWeb画面では、通信中の表示、成功時の表示、失敗時の表示がそろっているかが重要です。Promiseの文法だけでなく、ユーザーに何が見えるかまで考えると、実務のコードを読みやすくなります。

公式情報と関連して読みたい記事

• MDN: Promise
• MDN: Fetch API の使用
• fetch APIとは？GETとPOSTの使い方
• async/awaitとは？Promiseとの違い

まとめ

Promiseは、非同期処理の結果をあとで受け取るための仕組みです。最初は「将来の結果を表すオブジェクト」と考えれば十分です。

• 成功時はthen
• 失敗時はcatch
• 最後の処理はfinally
• fetchではresponse.okも確認する
• async/awaitはPromiseを読みやすくする構文

まず最初にお伝えしたいのは、JSPは決して難しいものではありません。むしろ、「ちょっと動きのあるWebページを、できるだけ簡単に作りたい！」という人のために生まれたものなのです。近年では他の技術に取って代わられた印象が否めないJSPですが、昔からある巨大なレガシーシステムなどでは現役で、システムの更改案件などではよく目にすることがあります。

このページでは「JSPってそもそも何？」という一番大事な部分から、初心者向けに順を追って１からわかりやすく専門用語を避けて解説します。

JSPとは何か？

JSP（Java Server Pages）は、Javaを使ってWebページを動的に生成するための技術で、通常のHTMLファイルにJavaのコードを埋め込むことで、アクセスするたびに内容が変化するページを作成することを可能にします。

そのため、JSPはJavaをベースとしていますが、HTMLの知識があれば、基本的な使い方は十分に理解することができます。

【前提１】静的なページと動的なページ

Webページには、大きく分けて2種類あります。
1つは「静的なページ」、もう1つは「動的なページ」です。

静的コンテンツ/動的コンテンツの違いを１分で解説【初心者向け】

【初心者向け】「動的」「静的」という言葉の意味とその違いを端的に解説します。本で学習したがイマイチ理解できない、、、結局一言でいうと違いは何？という疑問をお持ちの方に具体例を用いながら分かりやすく解説します。

it-biz.online

2026.04.26

静的なページとは、内容があらかじめ決まっていて、アクセスするたびに同じ内容が表示されるページです。たとえば、自己紹介だけが書かれた会社のホームページや、お知らせ一覧だけが載っているページなどが該当します。

一方、動的なページは、アクセスした時点の情報や、閲覧しているユーザーの状態に応じて内容が変わります。たとえば、ショッピングサイトで商品が表示されたり、ログイン中のユーザー名が画面に表示されたりするページがそうです。

静的なページはHTMLだけで作成できますが、動的なページを作るには、プログラムによってページの内容を生成する仕組みが必要です。JSPは、そのような仕組みの一つです。

もちろんJSP以外にも同じようなことを実現することが可能で、現代ではほとんどJSP以外が主役です。なのですが、レガシーシステムでは今でも現役で動いていることが多いので「まあ知っておいて損はないかな」というのがJSPの位置づけです。

JSPとはどのような技術か

JSPは、JavaのコードをHTMLに埋め込むことで、Webサーバー上で動的にHTMLを生成する技術です。拡張子が .jsp であるファイルを使ってページを作成します。

JSPファイルは、Webサーバー（通常はTomcat）に配置され、ユーザーがアクセスすると、サーバー側でJavaのコードが実行されます。その結果として生成されたHTMLが、ブラウザに送信され、画面に表示されます。

つまり、JSPは「動的にHTMLを生成する仕組み」であり、「HTMLの中にJavaの処理を一部書き足せる形式のファイル」と言えます。

JSPの動作のしくみ

JSPファイルは、ユーザーがアクセスしたときに、サーバー側で一度「Javaのクラス（Servlet）」に変換されます。変換されたクラスはコンパイルされ、Javaプログラムとして実行されます。このとき、JSPファイルに書かれたHTMLの部分はそのままHTMLとして出力され、Javaのコード部分は処理されて結果が埋め込まれます。最終的に生成されたHTMLがブラウザに送信され、ユーザーに表示されます。

このしくみによって、JSPは1枚のファイルで「HTMLの見た目」と「動的な処理」を両立させることができます。

JSPの動き方の流れ

1. ユーザーが .jsp ファイルをリクエストする（例：hello.jsp）
2. Tomcat がその .jsp を読んで、中の Java を実行
3. 結果として HTML を作り出し、ブラウザに返す
4. ブラウザには、あたかも普通のHTMLのように見える

この一連の流れによって、「動きのあるページ」がリクエスト元に返却されることになります。

JSPを動かすための準備

JSPファイルは、通常のHTMLファイルと違い、単独では動作しません。JSPはサーバー側でJavaのコードを実行する仕組みのため、その処理を受け持つ「Webサーバー」や「Javaの開発環境」が必要です。

この章では、JSPを動かすために必要なソフトウェアや環境を、1つずつ順を追って準備していきます。

JSPの動作に必要なもの

JSPを動作させるには、次の3つが必要です。ここでは、それってそもそも何？みたいな説明＋実際にあなたのPCにインストールする手順をメモ程度に記載しておきますので、この辺の知識がすでにあるよ！という方は読み飛ばしてください。

JDKのインストール

まず、Javaの開発環境であるJDKをインストールします。JDKがインストールされていないと、JSPも動作しません。

Javaの開発環境構築の３ステップ解説（JDK/JRE/JVMの仕組みを１から解説）

【超・初心者向け】Javaの開発環境を初心者向けに簡単に設定する方法をわかりやすく解説します。JDKのインストール、IDEの選択、開発のスタートまで、スムーズにJavaプログラミングを始める方法をご説明します。

it-biz.online

2026.04.16

手順

1. Oracleの公式サイトまたはOpenJDKのサイトから、JDKをダウンロード。
2. お使いのOSに合ったインストーラを選び、画面の指示に従ってインストール。
3. インストール後、コマンドプロンプト（またはターミナル）を開き、↓のコマンドを入力。

java -version

バージョンが表示されれば、正常にインストールされています。

Tomcatのインストール

JSPファイルを処理するために、Tomcatをインストールします。TomcatはJavaで動作するWebサーバーで、JSPの実行に適した軽量なサーバーです。

手順

1. Apache Tomcat の公式サイトにアクセス。
2. zip ファイル（Windows の場合）または tar.gz ファイル（Mac/Linux の場合）をダウンロード。
3. ダウンロードしたファイルを任意の場所に展開（解凍）。
   →C:\tomcat や ~/tomcat などが一般的ですが、どこでもOK。
4. binフォルダにある startup.bat（Windows）または startup.sh（Mac/Linux）を実行。
5. ブラウザを開き、次のURLにアクセスします：

無効なURLです

localhost

Tomcatのトップページが表示されれば、インストールは成功です。

JSP用のフォルダを作る

Tomcatでは、webapps フォルダの中にあるプロジェクトが自動的に読み込まれます。自分でJSPファイルを作って表示するには、ここに新しいフォルダを作成します。

手順

1. Tomcatフォルダ内の webapps に移動。
2. 新しくフォルダを作成し、たとえば jsp-demo という名前をつける。
3. jsp-demo フォルダの中に、最初のJSPファイルを作成します。ファイル名は hello.jsp など。

エディタの準備

JSPファイルは、普通のテキストファイルとして作成できますが、プログラミングに適したエディタを使うと効率が上がります。以下のいずれかのエディタを使用するのが一般的です。

• Visual Studio Code（無料で軽量、拡張機能が豊富）
• IntelliJ IDEA（Javaに特化した統合開発環境）
• Eclipse（Java開発で定番のIDE）

初心者の方には、Visual Studio Codeが扱いやすくおすすめです。必要に応じて「Java Extension Pack」などを追加すると、補完機能や構文チェックも利用できます。

最初のJSPファイルを作ってみよう

前の章で、JSPを動かすための準備が整いました。この章では、実際にJSPファイルを1つ作成し、それをブラウザで表示するところまで進めます。

ここでは、「JSPとはどういうものか」を実際に体験しながら、基本的な書き方や仕組みを理解していきます。

JSPファイルとはどんなファイルか

JSPファイルは、基本的にはHTMLっぽく見えるコードで、この中の必要な部分にJavaのコードを差し込むことで、表示内容を動的に変えることができるようにしています。たとえば、「現在の日時を表示する」などの処理が可能になります。

JSPファイルの拡張子は .jsp です。ファイルの中には、通常のHTMLタグと、Javaのコードが組み合わさって記述されます。

<%@ page contentType="text/html; charset=UTF-8" %>
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Hello JSP</title>
</head>
<body>
  <h1>こんにちは、JSPの世界へようこそ！</h1>
  <p>現在の時刻は：<%= java.time.LocalDateTime.now() %></p>
</body>
</html>

上記のJSPファイルの中では、JavaのコードとHTMLが組み合わさっています。それぞれの部分について説明します。

• <%@ page contentType="text/html; charset=UTF-8" %>
  → この行は「ページ全体の設定」です。文字コードをUTF-8にすることで、文字化けを防ぎます。
• <%= java.time.LocalDateTime.now() %>
  → この部分がJSPの特徴です。「現在の時刻を表示する」Javaのコードが入っています。
  <%= と %> で囲まれた中はJavaの「式」として実行され、結果がそのままHTMLに差し込まれます。

上記のファイルをブラウザで表示するためにエディタで編集して保存しましょう。

1. Tomcatの webapps フォルダの中にある、前章で作成した jsp-demo フォルダに移動。
2. hello.jsp という名前の新しいファイルを作成。
3. ファイルをエディタで開き、↑の内容を記述し保存！

ブラウザで表示してみる

ファイルを保存したら、Tomcatが起動していることを確認し、ブラウザで次のURLにアクセスしてみましょう。

無効なURLです

localhost

画面に「こんにちは、JSPの世界へようこそ！」という見出しと、現在の時刻が表示されていれば成功です。

ブラウザでページを更新するたびに、時刻が変化するはずです。これは、JSPがアクセスされるたびにJavaのコードを実行して、ページの中身を動的に作っているということを意味します。

JSPの基本構文

前の章では、JSPファイルを作成し、Javaのコードを埋め込むことで「現在の時刻を表示する」ページを作成しました。ここからは、JSPファイルで使われる代表的な構文について解説します。どのようにJavaのコードをHTMLに差し込むのか、そしてJSP特有の書き方にはどんな種類があるのかを、順を追って学習していきましょう。

JSPの構成要素

JSPでは、以下の4種類の記述形式が用意されています。これらを使い分けることで、Javaの処理とHTMLの表示を同時に扱うことができます。

ディレクティブ

ディレクティブは、JSPファイル全体に関する設定を行うものです。最もよく使われるのは page ディレクティブです。

<%@ page contentType="text/html; charset=UTF-8" %>

この記述によって、出力するHTMLの文字コードがUTF-8になります。日本語を正しく表示するために必須です。

スクリプトレット

スクリプトレットは、JSPファイル内にJavaの処理を書くための領域です。

<%
  int year = java.time.LocalDate.now().getYear();
  String message = "今年は " + year + " 年です。";
%>
<p><%= message %></p>

この例では、Javaで現在の年を取得し、それを文字列として作成しています。そして <%= ... %> を使って、結果をHTMLに出力しています。

スクリプトレットの中ではJavaの文法がそのまま使えます。ただし、後述するようにスクリプトレットは新しい開発ではなるべく使わない方向にあります。

式（Expression）

式は、値をそのままHTMLとして出力したいときに使います。

<p>こんにちは、<%= "JSPユーザー" %>さん！</p>

上の例では、"JSPユーザー" という文字列がHTMLに挿入され、ブラウザには次のように表示されます。

こんにちは、JSPユーザーさん！

この書き方は非常にシンプルで、値を表示するだけであれば便利ですが、複雑な処理は向きません。

宣言

宣言は、JSPファイルの中でメソッドや変数を定義したい場合に使います。

<%! 
  private String getGreeting(String name) {
    return "こんにちは、" + name + "さん！";
  }
%>
<p><%= getGreeting("太郎") %></p>

このように、JSPファイルの中で小さな関数を定義して、それを式の中で呼び出すこともできます。ただし、JSPファイルに処理を詰め込みすぎると保守が難しくなるため、このような記述はできるだけ避け、外部のJavaクラスに処理を分けることが望まれます。

コメントの書き方

JSPには、HTMLのコメントと、JSP用のコメントの2種類があります。

<!-- これはHTMLのコメントです（ブラウザの「ページのソース」に表示されます） -->

<%-- これはJSPのコメントです（ブラウザには一切表示されません） --%>

HTMLのコメントはWebページに送信されるため、内容を見られる可能性があります。
一方、JSPのコメントはサーバー側で処理が止まるため、セキュリティ的に重要なコメントや開発者向けのメモはJSPのコメントで書くのが安全です。

スクリプトレットはなるべく使わない

JSPの構文として紹介しましたが、スクリプトレット（<% ... %>）の使用は、今では非推奨とされています。理由は以下の通り。

• HTMLとJavaのロジックが混ざることで、読みづらくなる
• 保守性が下がり、エラーが起きやすくなる
• JSTL（JSP標準タグライブラリ）やEL（式言語）の方がシンプルで安全に書ける

そのため、今後はJSTLやELを使って、できるだけ「Javaコードを書かずに表示を制御する方法」を覚えていくことが大切です。

次の章では、JSTLとEL（式言語）を使った“スクリプトレットを使わない”JSPの書き方を学びます。より読みやすく、安全なJSPの記述方法を習得していきましょう。

ELとJSTLでスクリプトレットのないJSPへ

ここまでの解説では、JSPの基本構文としてスクリプトレット（<% ... %>）などを紹介しました。
しかし近年のJSP開発では、スクリプトレットを使わない記述スタイルが主流となっています。

この章では、EL（Expression Language）とJSTL（JSP Standard Tag Library）という2つの仕組みを使って、JSPファイルの中にJavaコードを書かずに動的な表示を行う方法を学んでいきます。

EL（式言語）とは

EL（Expression Language）は、JSPの中でJavaの値を簡潔に記述するための言語です。
スクリプトレットのように <%= で囲む必要がなく、シンプルに ${変数名} と書くだけで値を出力できます。

<p>こんにちは、${userName} さん。</p>

このコードでは、Javaのサーバー側で userName という名前のデータ（属性）が用意されていれば、自動的にその値が表示されます。

JSTL（JSP標準タグライブラリ）とは

JSTLとは、JSP上で使える共通の処理をあらかじめタグ化したライブラリです。
たとえば、以下のような処理が可能です。

• 条件分岐（if）
• 繰り返し処理（forEach）
• 値のフォーマット（日付や数値）
• URLの生成

JSTLを使うことで、複雑なJavaの処理をわかりやすいタグで書くことができるようになります。

JSTLを使う準備

JSTLを使うには、JSTLライブラリの .jar ファイルを JSPプロジェクトの中に追加する必要があります。

手順

1. JSTLの最新版（Jakarta標準）をダウンロード
   → https://jakarta.ee/specifications/tags/
2. ダウンロードした jakarta.servlet.jsp.jstl-api-x.x.x.jar などの .jar ファイルを、Tomcatの lib フォルダ、またはプロジェクトの WEB-INF/lib フォルダにコピーします。
3. JSPファイルの先頭に、以下のようにタグライブラリを読み込む宣言を記述します。

<%@ taglib prefix="c" uri="https://jakarta.ee/taglibs/core" %>

この設定により、<c:if> や <c:forEach> などのJSTLタグが使えるようになります。

JSTLで条件分岐をする

スクリプトレットで if 文を書かなくても、JSTLの <c:if> タグを使うことで簡単に条件分岐ができます。

<%@ taglib prefix="c" uri="https://jakarta.ee/taglibs/core" %>
<c:if test="${loginUser != null}">
  <p>ようこそ、${loginUser.name} さん</p>
</c:if>

このように、loginUser という属性が null でなければ、挨拶文が表示されます。

JSTLで繰り返し表示をする

リストや配列の内容を繰り返し表示するには、<c:forEach> を使います。

サーバー側で、次のようにリストをセットしておきます（Servletなどで）：

List<String> names = List.of("太郎", "花子", "次郎");
request.setAttribute("nameList", names);

JSPファイルでは、次のように記述します：

<%@ taglib prefix="c" uri="https://jakarta.ee/taglibs/core" %>
<ul>
  <c:forEach var="name" items="${nameList}">
    <li>${name}</li>
  </c:forEach>
</ul>

このコードにより、以下のようなHTMLが生成されます：

<ul>
  <li>太郎</li>
  <li>花子</li>
  <li>次郎</li>
</ul>

JSPをすっきり保つために

ELとJSTLを使うことで、JSPファイル内にJavaのコードを書く必要がなくなり、HTMLに近い構造を保ちながら動的な処理を行うことができます。
これは、JSPを読みやすく・保守しやすくする上でも非常に重要です。

また、デザイナーと共同で作業するようなプロジェクトでも、HTMLに近い見た目を保つことで、分業がしやすくなります。

フォームからデータを受け取る

JSPを使ってWebアプリケーションを作成する際、ユーザーの入力に応じて処理を行うことは非常に重要です。この章では、HTMLのフォームを使って入力されたデータを、JSPで受け取って表示する方法を学びます。

フォーム送信の流れ

フォームを使った処理は、次のような流れで行われます。

1. 入力フォームのあるページ（JSP）を表示する
2. ユーザーが名前などの情報を入力し、送信ボタンを押す
3. 入力内容がサーバーに送られる
4. 受け取ったJSPファイルがその情報を読み取り、画面に表示する

JSPではこの一連の流れを、HTMLとJavaの仕組みで簡単に実現できます。

フォームを作るJSP（entry.jsp）

まずは、名前を入力するための簡単なフォームを作成します。

entry.jsp

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>名前の入力</title>
</head>
<body>
  <h2>お名前を入力してください</h2>
  <form action="result.jsp" method="post">
    <label>名前：<input type="text" name="username" /></label>
    <input type="submit" value="送信" />
  </form>
</body>
</html>

このページでは、名前を入力して「送信」ボタンを押すと、result.jsp にPOSTリクエストでデータが送信されます。

データを受け取るJSP（result.jsp）

次に、送信されたデータを受け取って表示するためのJSPファイルを作成します。

result.jsp

<%@ page contentType="text/html; charset=UTF-8" %>
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>入力結果</title>
</head>
<body>
  <h2>ようこそ！</h2>
  <p>あなたの名前は <strong><%= request.getParameter("username") %></strong> さんですね。</p>
</body>
</html>

ここでは、request.getParameter("username") というコードで、フォームから送られたデータを取得しています。

• request はJSPに自動で用意されているオブジェクト。
• getParameter("username") は、フォームのname="username" に対応した値を取得するメソッド。

ELを使って書き換える

JSTLやELを使えば、result.jsp をもっとすっきり書くこともできます。以下のようにリクエスト属性に値をセットしてから表示することで、式言語を活用できます。

Servlet側（例）

String name = request.getParameter("username");
request.setAttribute("username", name);
request.getRequestDispatcher("/result.jsp").forward(request, response);

result.jsp：

<%@ taglib prefix="c" uri="https://jakarta.ee/taglibs/core" %>
<p>こんにちは、${username} さん！</p>

ただし、Servletを使う方法はこのガイドの後半で詳しく扱いますので、今はまず request.getParameter() による受け取りに慣れることをおすすめします。

セッションとCookieでデータを保持する

JSPでは、ユーザーが入力した情報を「別のページでも使いたい」という場面がよくあります。
たとえば、ログイン状態を維持したり、前の画面で入力された名前を次の画面でも表示したりする場合です。

そのようなときに役立つのが セッション（Session） と クッキー（Cookie） です。
この章では、それぞれの役割と使い方を学びます。

セッションの基本操作

データの保存：

<%
  String name = request.getParameter("username");
  session.setAttribute("userName", name);
%>

このコードは、userName という名前でセッションに値を保存します。

データの取得：

<%
  String name = (String) session.getAttribute("userName");
%>
<p>ようこそ、<%= name %> さん</p>

このようにすれば、前のページで保存した値を、別のページで取り出して使うことができます。

セッションの有効期間と注意点

セッションは、ユーザーがブラウザを閉じるか、一定時間操作をしないと自動的に無効になります。Tomcatの初期設定では、30分間操作がないとセッションが切れます。

また、多くの情報をセッションに保存しすぎると、サーバーのメモリを圧迫する可能性があるため、用途を絞って使うことが大切です。

Cookieとは

Cookie（クッキー）は、情報をユーザーのブラウザに保存する仕組みです。
サーバー側から「この情報を保存しておいてください」と指示すると、ブラウザがその内容を保持し、次回以降のアクセス時にその情報を自動的に送信してきます。

Cookieの基本操作

Cookieの作成と送信：

<%
  String name = request.getParameter("username");
  Cookie cookie = new Cookie("userName", name);
  cookie.setMaxAge(60 * 60); // 1時間（秒単位）
  response.addCookie(cookie);
%>

Cookieの取得：

<%
  String name = "";
  Cookie[] cookies = request.getCookies();
  if (cookies != null) {
    for (Cookie c : cookies) {
      if ("userName".equals(c.getName())) {
        name = c.getValue();
      }
    }
  }
%>
<p>こんにちは、<%= name %> さん</p>

このように、Cookieを使えば、ブラウザに保存された情報を次回のアクセス時にも利用できます。

セッションとCookieの使い分け

一時的な状態保持（ログイン情報など）にはセッション、
ユーザーに関連する設定（言語選択やテーマなど）にはCookieがよく使われます。

JSPで簡単なアンケートアプリを作ろう

JSPを使ってWebアプリケーションを作るには、「複数ページにまたがる処理」を整理することが大切です。
この章では、3画面構成のアンケートアプリを作り、情報の受け渡し、表示の切り替え、セッションの活用を総合的に体験します。

アプリの構成と目的

このアプリでは、以下のような流れでユーザーにアンケートに答えてもらい、最終画面でまとめて表示します。

1. 入力画面：名前と好きな色を入力（form）
2. 確認画面：入力された内容を表示（セッションで一時保持）
3. 完了画面：ありがとうメッセージと入力内容の最終確認

プロジェクト構造

jsp-demo/
├─ input.jsp     （入力画面）
├─ confirm.jsp   （確認画面）
└─ thanks.jsp    （完了画面）

入力画面：input.jsp

<%@ page contentType="text/html; charset=UTF-8" %>
<!DOCTYPE html>
<html>
<head><meta charset="UTF-8"><title>アンケート入力</title></head>
<body>
  <h2>アンケートにご協力ください</h2>
  <form action="confirm.jsp" method="post">
    <p>お名前：<input type="text" name="userName" /></p>
    <p>好きな色：
      <select name="favoriteColor">
        <option value="赤">赤</option>
        <option value="青">青</option>
        <option value="緑">緑</option>
      </select>
    </p>
    <input type="submit" value="確認画面へ" />
  </form>
</body>
</html>

確認画面：confirm.jsp

<%@ page contentType="text/html; charset=UTF-8" %>
<%
  String userName = request.getParameter("userName");
  String favoriteColor = request.getParameter("favoriteColor");

  session.setAttribute("userName", userName);
  session.setAttribute("favoriteColor", favoriteColor);
%>
<!DOCTYPE html>
<html>
<head><meta charset="UTF-8"><title>確認画面</title></head>
<body>
  <h2>以下の内容でよろしいですか？</h2>
  <p>お名前：<%= userName %></p>
  <p>好きな色：<%= favoriteColor %></p>
  <form action="thanks.jsp" method="post">
    <input type="submit" value="送信する" />
  </form>
</body>
</html>

完了画面：thanks.jsp

<%@ page contentType="text/html; charset=UTF-8" %>
<%
  String name = (String) session.getAttribute("userName");
  String color = (String) session.getAttribute("favoriteColor");

  // 必要があればセッションのデータを破棄
  session.invalidate();
%>
<!DOCTYPE html>
<html>
<head><meta charset="UTF-8"><title>送信完了</title></head>
<body>
  <h2>ご協力ありがとうございました！</h2>
  <p><strong><%= name %></strong> さんの好きな色は <strong><%= color %></strong> ですね。</p>
</body>
</html>