HTMLフォームの作り方｜入力欄・ラベル・送信と検証の基本

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

HTMLフォームは、入力欄を並べるだけで完成するものではありません。何を入力するか伝えるラベル、送る値の名前、入力を確認する仕組み、送信先での処理がつながって初めて役立ちます。まずは画面の入力とサーバーの処理を分け、ブラウザー内だけで試せる小さなフォームから学ぶと、問題が起きた場所を追いやすくなります。

この記事では、架空の学習相談フォームを題材に、input、label、name、選択肢、必須表示、GETとPOST、入力検証を説明します。WordPressのプラグイン設定ではなく、HTMLを使って構造を作る入門です。実在の個人情報やパスワードは使わず、練習用の仮の値で試してください。掲載コードは本番の問い合わせ受付システムとして完成したものではありません。

2026年10月3日にMDNのフォーム関連資料を確認しています。入力部品の見え方やブラウザーのエラー文言は環境によって異なります。図版は説明用の生成イメージで、コードの実行画面ではありません。本文の完全例は通常の送信をJavaScriptで止めて入力練習をするもので、メール送信、データ保存、本人確認は行いません。

HTMLフォームの仕組み｜入力・送信・処理を分けて考える

フォームには三つの段階がある

一つ目は、利用者がブラウザーで情報を入力する段階です。名前、メール、選択肢、文章などを、適した入力部品で受け取ります。二つ目は、入力された値を送信する段階です。どの宛先へ、どの方法で送るかをフォームの設定などで決めます。三つ目は、サーバーが受け取り、内容を検証し、必要な保存や通知を行う段階です。HTMLだけを作っても、三つ目が自動的に用意されるわけではありません。

フォームが表示される、送信ボタンが押せる、受付が完了する、通知メールが届くという状態は、それぞれ別です。見た目だけ完成しても、宛先の処理がなければ情報を受け付けられません。逆に送信先が動いていても、ラベルが曖昧で入力しにくければ利用者は困ります。学習では各段階を分けて確認し、何ができて何が未実装かを説明できるようにしましょう。

MDNのform要素の説明で、送信先や送信方法の役割を確認できます。実際のフォームでは、送信ボタン側の属性やJavaScriptによる処理が関わる場合もあります。初めは複雑な仕組みを混ぜず、一つのフォームと一つの送信方法で動きを理解することが大切です。

先に受付目的と必要な項目を決める

架空の学習相談なら、相談内容を理解して返信するための項目を考えます。表示名、返信先、関心のある分野、相談内容があれば足りるかもしれません。住所、生年月日、勤務先などを何となく追加する必要はありません。項目が増えるほど、入力する人の負担と、受け取る側が管理する情報が増えます。何のために必要なのか説明できる項目から作りましょう。

必須と任意も、見た目の都合で決めません。返信するためにメールが必要なら必須、相談の補足として役立つだけの項目は任意というように、処理の目的から判断します。任意の項目を空欄にしても受付が進められる設計が必要です。必須を増やして詳しい情報を集めるより、最低限の情報で次のやり取りへ進めるかを検討します。

項目の一覧には、画面に見せる名前、データの名前、必須かどうか、入力条件を並べます。たとえば画面表示が「返信先メールアドレス」、nameがemailという関係です。この整理を先にすると、サーバー側が期待する名前とHTMLのnameが食い違う問題を防ぎやすくなります。フォームの文章とプログラム上の識別子を分けて考えてください。

※表は横にスクロールできます。

練習と公開するフォームを区別する

学習用のフォームでは、仮の名前やexample.comのような例示用ドメインを使います。実際の顧客情報を入力すると、予想しない送信やログ記録が起きたときの影響が大きくなります。自分のPC内の練習ファイルで構造を学び、外部サービスへ接続する段階では、送る情報と宛先を改めて確認してください。コードの練習が、そのまま個人情報の収集を始める許可にはなりません。

本番へ公開する場合は、入力項目だけでなく利用目的、保存期間、閲覧できる担当者、削除方法、問い合わせへの対応なども必要になります。この記事ではそれらの運用をすべて実装しません。フォームの画面を作れることと、責任を持って情報を受け付けられることを分けて、必要な知識や支援を追加していきましょう。

入力欄を作る｜label・name・type・選択肢の基本

labelのforと入力欄のidを対応させる

入力欄の近くへ文字を置くだけでは、その文字と入力欄の関係が十分に伝わらない場合があります。label要素を使い、forの値を対象のidへ合わせます。同じ文書の中でidが重複しないようにしてください。対応が正しければ、ラベルをクリックしたときに入力欄へ移動するなど、操作の助けになります。見た目の位置だけでなく、HTMLの関係を作ることが重要です。

<label for="display-name">表示名（必須）</label>
<input id="display-name" name="display_name" type="text" required>
<label for="reply-email">返信先メールアドレス（必須）</label>
<input id="reply-email" name="email" type="email" autocomplete="email" required>

この例でidはラベルとの対応や要素の識別に使い、nameは送信する値の名前になります。同じ文字列にしても構いませんが、役割は別です。idだけを付けてnameを忘れると、見た目とラベルの操作はできても、通常のフォーム送信で期待した名前の値が含まれない原因になります。入力欄が表示されていることだけで完成と判断しないようにしましょう。

MDNのlabel要素の説明も確認し、明示的な対応と、labelの中へ入力欄を入れる方法の違いを学べます。最初の練習では、forとidを使う方法に統一すると対応が追いやすくなります。フォームを複製したときはidもそのまま重複しないように、各欄が一意に識別できるか点検してください。

typeは入力してほしい内容に合わせる

inputのtypeには、text、email、tel、number、dateなどがあります。目的に合う型を選ぶと、対応する端末で入力しやすいキーボードが表示されたり、基本的な形式の検証が行われたりします。ただし、型を選んだだけで実在の情報かどうかまで確認できるわけではありません。emailは形式の確認を助けますが、そのアドレスの所有者や受信可能性を証明しません。

電話番号や郵便番号は、数字でできていても数量ではありません。先頭の0、区切り記号、国ごとの形式などが関わるため、単純にnumberを使うと扱いにくくなる場合があります。何を保存したいかを考え、文字列として扱う入力と、計算する数量を分けます。typeやinputmodeなどの属性は、見た目だけでなく入力の意味に合わせて選んでください。

MDNのinputリファレンスで、型ごとの動作と属性の対応を確認できます。すべての属性がすべての型へ同じように効くわけではありません。日付の部品などはブラウザーによって見え方が異なるため、一つのスクリーンショットを基準に同じ見た目を保証しないようにします。対象環境で入力できることを確認しましょう。

※表は横にスクロールできます。

ラジオボタンとチェックボックスを使い分ける

一つだけ選んでもらう候補には、同じnameを持つラジオボタンを使う方法があります。各選択肢のidとvalueは区別し、labelを付けます。複数選んでよい項目にはチェックボックスを検討します。何個選べるかが読者に分かる説明を添え、見た目だけで判断させないようにしましょう。

<fieldset>
  <legend>相談したい分野（必須・一つ選択）</legend>
  <label for="topic-html">
    <input id="topic-html" type="radio" name="topic" value="html" required>
    HTML
  </label>
  <label for="topic-css">
    <input id="topic-css" type="radio" name="topic" value="css">
    CSS
  </label>
</fieldset>

fieldsetは関連する入力をまとめ、legendでそのまとまりの説明を付けるために使えます。選択肢が何に対する回答なのかを明確にすることが目的です。線で囲まれる見た目だけを理由に使うのではなく、意味のあるグループへ適用します。CSSで外見を変えても、見出しと選択肢の関係が残る構造を大切にしましょう。

チェックされていないチェックボックスや選択されていないラジオボタンは、通常の送信データでその値が含まれない場合があります。サーバー側で「値がない」状態をどう扱うかを決める必要があります。同じnameの複数値を送る設計では、受け取り側が配列などとして扱えるかも確認します。見た目の部品と、受け取るデータの形を一緒に考えてください。

ボタンのtypeを明示する

フォーム内のbuttonは、typeの指定によって役割が変わります。送信にはsubmit、独自の処理を呼ぶだけならbuttonなどを使います。補助ボタンを置いたつもりで送信が起きる問題を減らすため、役割を明示しましょう。ボタンの文字も「実行」だけではなく、何が起きるかが分かる言葉にします。

<button type="button">入力例を表示</button>
<button type="submit">相談内容を送信する</button>

入力例を表示するボタンは、HTMLを書いただけで自動的に例を出すわけではありません。必要な動作をJavaScriptなどで用意します。初期化ボタンは、入力済みの内容を失わせる可能性があるため、安易に追加しないようにします。利用者に必要な操作へ絞り、押し間違いの影響も考えて配置してください。

使いやすさを整える｜必須表示・説明・キーボード操作

placeholderをラベルの代わりにしない

placeholderは入力例や補助的なヒントに使えますが、入力すると見えなくなるため、項目名の代わりには向きません。「メールアドレス」とだけ薄く表示し、上にラベルがない入力欄では、入力後に何の欄か確認しにくくなります。常に見えるラベルを付け、例が必要な場合は別の説明を添えましょう。

入力例は実際に受け付ける形式と一致させます。ハイフンありの例を見せているのに、検証ではハイフンを拒否する設計は混乱を招きます。文字数、使える形式、任意か必須かを、入力前に理解できる位置へ置いてください。エラーになってから初めて条件を知らせるより、最初から迷わず入力できる案内が役立ちます。

補足文と入力欄の関係をプログラム上でも伝えるために、aria-describedbyを使う方法があります。参照するidが実際の説明文に付いているか確認してください。属性を付ければ自動的に分かりやすくなるわけではなく、説明の内容が具体的であることも必要です。まず可視の文章を整え、その関係をHTMLで表します。

<label for="message">相談内容（必須）</label>
<p id="message-help">試したことと、困っている点を1000文字以内で書いてください。</p>
<textarea id="message" name="message" rows="6" maxlength="1000"
  aria-describedby="message-help" required></textarea>

必須は色だけで表さない

必須項目は、「必須」という文字など、色以外の情報でも分かるようにします。赤い印だけでは意味が伝わらない場合があります。フォームの冒頭で表示の意味を説明し、各項目でも一貫した方法で示します。任意の項目も、入力しなくてよいことが分かると、利用者が不要な情報まで書くことを避けやすくなります。

requiredはブラウザーの制約検証に関わる属性です。見た目に「必須」と書いたことと、属性を設定したことは別なので、両方を照合します。必須と表示しているのに空欄で送れる、任意と表示しているのに送信を止められる、といった食い違いがないか試します。条件付きで必須になる項目では、その条件が画面にも処理にも反映されている必要があります。

入力項目を途中で表示・非表示にする場合も、隠れている必須欄が送信を止めていないか注意します。単にCSSで見えなくしただけでは、フォームの状態が期待どおり変わらない場合があります。初心者の練習では、まずすべての項目が見える単純な構成を完成させ、その後に条件分岐を加える方が検証しやすくなります。

キーボードだけで一周する

マウスを使わず、Tabキーなどで入力欄とボタンへ移動できるか試します。現在どこを操作しているか分かるフォーカス表示を消さないようにしましょう。CSSで見た目を整えるときにoutlineを一律で消すと、キーボード利用者が位置を見失う場合があります。必要なら、十分に見える別のフォーカス表現を用意します。

項目の順番は、自然に入力できる流れにします。表示名、返信先、相談分野、本文というように、関連する内容をまとめます。見た目の配置だけを左右に入れ替えると、キーボードの移動順と食い違う場合があります。HTMLの順で意味が通る構造を作り、その上で画面幅に合わせた配置を整えてください。

※表は横にスクロールできます。

スマートフォンでは入力部品の大きさも見る

狭い画面では、ラベルと入力欄を縦に並べる方が読みやすい場面があります。横並びを維持するために文字や入力欄を極端に小さくしないようにします。メールアドレスなど長い値が見えるか、選択肢を押し分けられるか、キーボードが出たときに説明を見失わないかを確認してください。

入力欄の幅だけでなく、エラー文が出た状態も試します。通常時は収まっていても、長いエラー説明が追加されるとレイアウトが崩れる場合があります。余白や高さを固定しすぎず、文章が増えても読める構成にします。実機で確認できない場合は、その範囲を未確認として残し、ブラウザーのサイズ変更だけで実端末を検証したと扱わないようにしましょう。

送信と検証を理解する｜GET・POST・ブラウザーとサーバー

actionとmethodは送信先の仕様に合わせる

actionは通常、フォームを送る先を指定し、methodは送信方法に関わります。GETではフォームデータがURLのクエリーへ付く形になり、検索条件のような用途で使われます。POSTでは通常リクエスト本文へデータを送ります。ただし、POSTにすれば秘密になる、安全になると考えてはいけません。通信の保護、サーバーの処理、ログや保存の扱いは別に必要です。

次の断片は、送信の形を説明する例です。/searchや/contactという処理が自動的に作られるわけではありません。実際に動かすには、その宛先が対応する方法とデータ名を受け付ける必要があります。接続先がない練習では、後述のブラウザー内だけで確認する完全例を使ってください。

<form action="/search" method="get">
  <label for="search-word">検索語</label>
  <input id="search-word" name="q" type="search">
  <button type="submit">検索する</button>
</form>

<form action="/contact" method="post">
  <label for="contact-message">問い合わせ内容</label>
  <textarea id="contact-message" name="message" required></textarea>
  <button type="submit">送信する</button>
</form>

送信データの流れは、MDNのフォームデータ送信ガイドで確認できます。送信先の仕様が分からない状態で、属性を変えながら本番へ何度も送るのは避けます。テスト環境と仮のデータを使い、どの名前でどの値を受け取るかを関係者と合わせて進めましょう。

nameと送信されない項目を確認する

通常のフォーム送信では、nameがデータのキーとして重要になります。画面に見えている欄でも、nameがなければ期待する形で送られない原因になります。また、disabledのコントロールは通常の送信対象から外れます。readonlyは対応する入力部品で編集を制限するものですが、disabledと同じ送信動作ではありません。表示を薄くするためだけにdisabledを使うと、必要な値が届かないことがあります。

hiddenの値は画面へ見えないだけで、利用者側から変更されない秘密の情報とは限りません。価格、権限、承認状態など重要な判断を、隠し入力の値だけで信用しないようにします。サーバー側で信頼できる情報と照合する必要があります。HTMLは利用者が操作する側へ届くものなので、画面に出していないことを安全性の根拠にしないことが大切です。

ファイルを送る場合は、ファイル入力に加え、送信の形式やサーバー側の受け入れが必要です。acceptで種類の候補を絞っても、それだけで危険なファイルを完全に防げるわけではありません。サイズ、形式、保存場所、アクセス権などを受け取り側で確認します。初心者の最初のフォームでは、ファイル受付を後回しにして文字入力の流れを確実にする方法もあります。

ブラウザーの検証は入力の手助け

required、minlength、maxlength、min、maxなどを使うと、対応する入力部品で条件を示せます。emailなどの型も基本的な検証に役立ちます。条件を厳しくすればよいわけではなく、実際の利用者が必要な値を入力できる範囲にします。氏名を不必要に特定の文字だけへ限定したり、電話番号を一つの地域の書式だけへ固定したりすると、正しい情報を拒否する場合があります。

MDNのクライアント側フォーム検証で、HTMLの制約とJavaScriptによる補助を学べます。ブラウザー側の検証は利用者が誤りに気づくために便利ですが、回避や変更ができるため、サーバー側の検証も必要です。ブラウザーで一度通った値を、そのまま信頼して保存や表示へ使わないようにします。

patternなどで書式を指定する場合は、許可したい入力の例と、拒否する例を用意します。正規表現を書いた本人が想定していない空白、記号、長い文字列が入ることもあります。入力条件を画面へ説明し、エラーになったときに何を直せばよいか分かるようにします。条件の説明と実装の両方を同じテストケースで確認してください。

※表は横にスクロールできます。

成功表示は実際の処理結果に合わせる

送信ボタンを押した瞬間に「受付完了」と表示すると、サーバーで失敗していても利用者が完了したと誤解する可能性があります。本番では、処理の応答を確認してから、その結果に合う表示へ進めます。受付はできたが通知メールに問題がある場合など、内部の工程をどう管理するかも設計が必要です。見た目の動作だけで完了を判断しないでください。

通信中に何度も押された場合の重複処理や、途中で通信が切れた場合の再試行も考えます。ボタンを無効にするだけでは、サーバー側で重複を防ぐ仕組みの代わりになりません。この記事の入門例では実際の送信処理を行わず、画面の構造と検証を学びます。本番へ進むときは、受け取り側の設計と合わせて検討しましょう。

安全に完成させる｜エラー・確認・小さな練習の進め方

ブラウザー内で試す完全例

次の例はローカルのHTMLファイルへ保存して試す練習用です。通常の送信イベントを止め、入力の基本条件を通ったことだけを画面へ表示します。実在の個人情報は入れず、仮の表示名とuser@example.comなどを使ってください。JavaScriptが動かない場合は、この例の動作条件を満たさないため、送信練習を続けずコードとブラウザーの状態を確認します。

<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>学習相談フォームの練習</title>
  <style>
    * { box-sizing: border-box; }
    body { margin: 0; font-family: system-ui, sans-serif; line-height: 1.7; color: #17313a; }
    main { max-width: 42rem; margin: auto; padding: 1.5rem; }
    .field { margin-block: 1.25rem; }
    .field > label, legend { font-weight: 700; }
    .field > label { display: block; margin-bottom: 0.4rem; }
    input[type="text"], input[type="email"], select, textarea {
      width: 100%; padding: 0.75rem; border: 1px solid #657d87;
      border-radius: 0.3rem; font: inherit;
    }
    fieldset { margin-block: 1.25rem; padding: 1rem; border: 1px solid #657d87; }
    .choice { display: block; padding-block: 0.35rem; }
    .help { margin: 0.3rem 0; color: #3d555e; }
    button { padding: 0.75rem 1.25rem; font: inherit; background: #075f76; color: #fff; border: 0; }
    :focus-visible { outline: 3px solid #b64613; outline-offset: 3px; }
    #result { min-height: 2em; font-weight: 700; }
  </style>
</head>
<body>
  <main>
    <h1>学習相談フォームの練習</h1>
    <p>仮の値だけを入力してください。これは受付サービスではありません。</p>
    <form id="practice-form" action="#" method="get">
      <div class="field">
        <label for="practice-name">表示名（必須）</label>
        <input id="practice-name" name="display_name" type="text" maxlength="50" required>
      </div>
      <div class="field">
        <label for="practice-email">返信先メールアドレス（必須）</label>
        <p class="help" id="email-help">例：user@example.com。実際のアドレスは使いません。</p>
        <input id="practice-email" name="email" type="email" aria-describedby="email-help" required>
      </div>
      <fieldset>
        <legend>相談したい分野（必須・一つ選択）</legend>
        <label class="choice" for="practice-html">
          <input id="practice-html" name="topic" type="radio" value="html" required> HTML
        </label>
        <label class="choice" for="practice-css">
          <input id="practice-css" name="topic" type="radio" value="css"> CSS
        </label>
      </fieldset>
      <div class="field">
        <label for="practice-level">現在の学習状況（任意）</label>
        <select id="practice-level" name="level">
          <option value="">選択しない</option>
          <option value="start">学習を始めたところ</option>
          <option value="practice">小さな作品を練習中</option>
        </select>
      </div>
      <div class="field">
        <label for="practice-message">相談内容（必須）</label>
        <p class="help" id="practice-help">困っている点を1000文字以内で入力してください。</p>
        <textarea id="practice-message" name="message" rows="6" maxlength="1000"
          aria-describedby="practice-help" required></textarea>
      </div>
      <button type="submit">入力を確認する（練習）</button>
    </form>
    <p id="result" role="status"></p>
    <noscript><p>この練習はJavaScriptが必要です。送信操作をせず設定を確認してください。</p></noscript>
  </main>
  <script>
    const form = document.querySelector('#practice-form');
    const result = document.querySelector('#result');
    form.addEventListener('submit', (event) => {
      event.preventDefault();
      result.textContent = '基本の入力条件を確認しました。サーバーへ送信・保存していません。';
    });
    form.addEventListener('input', () => {
      result.textContent = '';
    });
  </script>
</body>
</html>

この例では、空欄のまま確認ボタンを押すと、対応するブラウザーが必須項目の入力を促します。メール欄へ不完全な値を入れた場合も試し、どの条件で先へ進めないかを見てください。すべての基本条件が通ると練習用の文言が出ます。これはサーバーが受け付けたという意味ではなく、ブラウザー内での動作確認です。

次に、labelのforを一か所だけ別の値へ変えてラベルをクリックし、正しい場合との違いを観察します。試したら元へ戻してください。nameを一つ外した場合は、後でFormDataや開発者ツールを学ぶ際に、値がどう扱われるかを確認する課題にできます。複数の変更を一度にしないことが、HTMLの各属性の役割を理解する助けになります。

エラーは直し方まで伝える

本番で独自のエラー表示を作る場合は、「入力が不正です」だけでなく、どの項目をどう直すかを伝えます。文字数が多すぎるなら上限を示し、必須が空欄なら必要な項目名を示します。入力した内容を全部消してしまうと、利用者が最初からやり直す負担が増えます。安全性とプライバシーを考えながら、修正しやすい状態を保つ設計が必要です。

エラーを赤色だけで表さず、文章やアイコンなども使います。複数のエラーがある場合は、全体の案内と各欄の説明を対応させる方法があります。画面上の表示だけでなく、キーボードや支援技術でも問題の箇所へ進めるかを確認してください。入力できる人だけを想定せず、間違えた後に戻れることまでが使いやすさに関わります。

公開前のテスト項目を残す

正しい入力で一度送れただけでは、検証として十分とは限りません。必須の空欄、任意の空欄、長い文章、全角文字、記号、想定外の選択値、通信失敗など、条件を分けて試します。サーバー側のテストでは、ブラウザーが止める入力も届く可能性を考えます。画面の検証を通った値だけで試すと、受け取り側の弱点を見落とすことがあります。

※表は横にスクロールできます。

小さなフォームから学習範囲を広げる

最初の到達点は、ラベルと入力欄が正しく対応し、値の名前を説明でき、必須と任意の動作を確認できることです。その後に、サーバーとの接続、送信結果の表示、迷惑送信への対策、情報の保管へ進みます。機能を増やす前に、どの段階で何を確認するかを理解しておくと、不具合を調べやすくなります。

本番の問い合わせ受付を作る場合、既存の信頼できるサービスやフレームワークを使う選択肢もあります。自作すればすべてを自由にできる一方、保守や安全性の責任も増えます。学習のための自作と、実際の顧客情報を受け付ける仕組みは分けて判断してください。既存サービスを使う場合も、入力項目と送信先、保存先を理解するためにHTMLの基礎が役立ちます。

質問対応を受けながらWeb制作を学びたい場合は、副業向けプログラミングスクールの料金・教材・支援比較も参考になります。HTMLの画面づくりを学びたいのか、サーバー処理まで作りたいのかで必要な内容が違います。練習で困った点を整理してから、対象言語と質問できる範囲を比較しましょう。

HTMLフォームの基本は、入力の目的を絞り、ラベルと値の名前を整え、利用者が間違いを直せるようにし、送信先の検証までつなげることです。まずは仮の値を使う小さな練習で、表示、入力、検証、結果表示を一周してください。見た目と実際の受付状態を分けて考えることが、安全で分かりやすいフォームを作る出発点になります。