HTML

The HTML action attribute specifies where a form submits its data, helping you control the request URL (including defaults when omitted) and coordinate it with method, validation, and per-button overrides like formaction.

action

action は <form> の送信先（リクエスト先URL）を指定し、送信ボタンが押されたときに「どこへ・どんなURLで」送るかを決めます。

このページでできるようになること

まずは直感：action って何？

ざっくり言うと、action は「このフォームの内容を、どのURLへ送るか」を決める宛先欄です。

正確な定義（仕様に沿った説明）

何のために存在するか

action は、フォーム送信（submit）時にブラウザが作るリクエストの「送信先URL」を指定するための属性です。指定したURLは、必要に応じて現在の文書URLを基準に解決されます（相対URL）。

何に適用されるか（対象）

action は <form> に指定します。送信ボタン（<button type="submit"> や <input type="submit">）側では formaction を使うと、押されたボタンだけ送信先を上書きできます。

できること / できないこと（制約）

できること
  • 送信先URL（相対/絶対）を指定し、GETならクエリ、POSTならボディにデータを載せて送る“入口”を決める
  • 同一フォームでも formaction で送信先を分けられる（例：下書き保存/本送信）
  • 同一オリジンでも別オリジンでも指定はできる（実務ではセキュリティ設計が前提）
できないこと（重要）
  • 送信内容（どの値が送られるか）を直接決めること（それは入力の name/value、状態、disabled などで決まる）
  • バリデーションを“必ず”回避すること（回避したいなら formnovalidate や novalidate を意図して使う）
  • サーバー側の処理や遷移を保証すること（サーバーがそのURLで何をするかは別問題）

影響範囲（レイアウト/描画/ユーザー操作/アクセシビリティ）

レイアウト
action 自体はレイアウトや見た目を変えません。
描画
送信後にページ遷移や再描画が起きるかは、action 先の応答と、SPA等の作り方に依存します。
ユーザー操作
送信はキーボード（Enter）でも起きます。意図しない送信先に飛ばないよう、action とボタンの型（type）をセットで確認します。
アクセシビリティ
送信ボタンが複数ある場合、ラベル（ボタン文言）で「どこへ送る操作か」が分かると誤操作が減ります。エラー時はどの入力が原因かを明示します。

基本の書き方（最短の型）

最小サンプル（コピペ用）

HTML

<form action="/search" method="get">
    <label>
        キーワード
        <input type="search" name="q" required>
    </label>
    <button type="submit">検索</button>
</form>

まずは「送信先（action）と送信方法（method）」をセットで書くのが最短です。

よく使う指定／典型パターン

同一サイト内のエンドポイントへ送る（推奨）
action="/path"（サイトルート基準で意図がブレにくい）
相対URLで送る
action="submit" / action="./submit"（基準URLに依存するので、ルールを決めて使う）
同じページに送る
action を省略（または action=""）
押したボタンだけ送信先を変える
<button type="submit" formaction="/draft">

仕様として押さえるポイント（初心者が事故りやすい所）

action を省略すると？（既定の送信先）
基本は「現在の文書URL（同じページ）」へ送ります。つまり、同じURLへ GET/POST します。
action=""（空文字）は？
多くの場合、結果は省略と同様に「同じページ」になります。迷うなら、意図が伝わる方を選び、チーム内で統一します。
相対URLは何を基準に解決される？
通常は「現在の文書URL」を基準に解決されます。<base href="..."> があると基準が変わるため、相対URL運用では <base> の有無をセットで把握します。
GET/POSTで「URLに何が出る」？
method="get" は入力値がクエリ（?q=...）としてURLに付きます。method="post" は基本的にURLに出ず、ボディ側へ載ります。
どの値が送られる？（name/value の基本）
送信されるのは、フォーム内の「成功したコントロール（successful controls）」の name/value です。disabled の入力は送られません。チェックボックスやラジオは、選択されているものだけが送られます。
押された送信ボタンは送信データに入る？
送信ボタンに name があれば、そのボタンが押されたときだけ送られます（複数ボタンの判定に使えます）。
バリデーションで送信が止まる？
制約検証（constraint validation）で不正があると送信は止まります。無視したい場合はフォーム全体で novalidate、特定ボタンだけなら formnovalidate を使います。

よくある勘違い・混同ポイント

action を書けば送信が必ず成功する
送信先URLが正しくても、入力のバリデーションやネットワーク、サーバー側の応答で失敗します。まずは DevTools の Network で「どのURLへ、どのmethodで送ったか」を確認します。
GET は危険だから全部 POST にする
検索など「URLを共有したい」用途は GET が自然です。逆にパスワードなど秘匿すべき情報は GET に載せません。目的で使い分けます。
相対URLならどこでも同じ
ページの配置や <base> の有無で解決結果が変わります。送信先がズレる事故が多いので、ルート相対に統一するか、基準を明文化します。
formaction は JavaScript がないと使えない
いいえ。HTMLだけで送信先の分岐ができます。押したボタンごとに formaction / formmethod / formenctype / formtarget を上書きできます。

実務でよくある使用例（制作会社の現場を想定）

検索フォーム：URLを共有したいので GET にする
method="get" とルート相対の action="/search" にして、クエリがURLに出る形にすると「検索結果の共有」が自然です。
問い合わせフォーム：送信先は固定して、ボタンで分岐する
「確認へ進む」「下書き保存」など、意図が違う送信はボタン側で分けます。

HTML

<form action="/contact/confirm" method="post">
    <!-- inputs... -->
    <button type="submit">確認へ</button>
    <button type="submit" formaction="/contact/draft" formmethod="post">下書き保存</button>
</form>
同じページに送って「結果だけ変える」
検索結果やフィルタなど、同一URLで完結させたいときは action を省略して同じページへ送ります（サーバー側でGETを処理する前提）。

実務で起きがちな事故と回避策

想定と違うURLに送ってしまう
  • action が相対URLで、ページの配置変更でズレた
  • <base> によって相対URLの基準が変わった
  • 押したボタンに formaction が付いていた
最短の確認：DevTools の Network で「Request URL」を見る / Elements で form.action と submitter.formAction を確認する。
GET のはずなのにクエリが付かない
  • method が post になっている（ボタンの formmethod に注意）
  • 送る入力に name が付いていない
  • disabled で送信対象から外れている
最短の確認：Network の Query String Parameters / Form Data を見る。
送信ボタンを押しても送信されない
  • 制約検証で止まっている（required、type="email"、pattern など）
  • ボタンが type="button" になっている
最短の確認：Console の警告、入力に表示されるバルーン、ボタンの type を確認する。

アクセシビリティ／UX観点での注意

送信ボタンが複数あるときは、違いが文言で分かる
同じフォーム内で送信先が違うなら、ボタンのラベルで「何が起きるか」を区別します（例：「下書き保存」「送信」）。
エラー時は「どの入力が原因か」をユーザーに返す
ブラウザ標準の検証だけに頼らず、サーバー側エラーも含めて、該当項目へ誘導できると離脱が減ります。aria-live は“最後の手段”として、まずはHTMLの関連付け（<label>、エラーテキスト）を整えます。
GET のクエリはURL共有・履歴に残る
便利ですが、個人情報や機密を載せない設計にします。オートコンプリート（autocomplete）も含めて、入力の性質ごとに見直します。

関連要素・属性の相互作用

<form>
  • method：GET/POST
  • enctype：application/x-www-form-urlencoded / multipart/form-data / text/plain
  • target：送信結果の表示先（同タブ/新規タブ/iframe）
  • novalidate：フォーム全体で制約検証を無効にする
送信ボタン（<button> / <input type="submit">）
  • formaction：押したボタンだけ送信先URLを上書き
  • formmethod / formenctype / formtarget：押したボタンだけ送信方式を上書き
  • formnovalidate：押したボタンだけ検証を無視
入力（<input> / <select> / <textarea>）
name がないと送信されません。disabled は送信対象外です。

試験で得点できる整理（用語・ひっかけ・ミニ確認）

用語

successful controls
送信に含まれる入力のこと。disabled は含まれない、チェックされていないチェックボックス等は含まれない、などがポイント。
constraint validation
ブラウザ標準の制約検証。required、type、pattern などで送信が止まる。

ひっかけ回避

ミニ確認

Q. 同じフォームで「保存」と「送信」を分けたい。まず何を使う？
A. ボタン側の formaction（必要なら formmethod）で分岐する。
Q. GETで送ったのに値が送られない。最初に見るものは？
A. 入力に name があるか、そして Network の Query String Parameters。

FAQ

Q. action を省略すると送信先はどう決まりますか？
A. 基本は現在の文書URL（同じページ）です。ページのURLに対して GET/POST を行います。
Q. action=""（空文字）と省略は同じですか？
A. 多くの場合同じページになりますが、相対URL運用や <base> の影響を受ける場面があるため、チーム内で統一して書きます。
Q. 送信先をボタンごとに変えるとき、JavaScript は必要ですか？
A. 不要です。formaction（必要なら formmethod など）でHTMLだけで分岐できます。
Q. 送信ボタンを押しても反応がありません。
A. まずは検証で止まっていないか（required など）と、ボタンが type="submit" かを確認します。

症状早見（最短で切り分ける）

症状：想定外のURLへ送られる
原因候補：相対URLのズレ / <base> / formaction 上書き。
確認：Network の Request URL / form.action と submitter.formAction。
症状：GETなのにクエリが付かない
原因候補：method が POST / 入力に name がない / disabled。
確認：Network の Query String Parameters。
症状：送信されない
原因候補：制約検証で停止 / ボタン型の間違い。
確認：必須入力のバルーン、Console の警告、ボタンの type。

まとめ：迷ったときの判断軸（短いチェックリスト）