問い合わせの通知メールに、こういうものが混ざることがあります。会社名が「株式会」で切れている。本文が「はじめまして」だけ。同じ人から3分後にもう一通、今度は最後まで書かれたものが届く。
送信者が不注意なのではありません。 日本語を入力して変換を確定しようと Enter を押した瞬間に、フォームが送信されています。書いている側には、送るつもりの操作をした自覚がありません。「送信ボタンを押していないのに送られた」ので、驚いて書き直してもう一度送る。 通知だけを見ていると、二重送信の多いフォームにしか見えません。
犯人は Enter ではなく「変換確定の Enter」
日本語入力では、Enter が2つの役割を持ちます。変換候補を確定する Enter と、確定後に押す Enter です。ブラウザ側から見ると、どちらも同じキーが押されたイベントとして流れてきます。
これを区別するために用意されているのが KeyboardEvent の isComposing です。IME が変換処理中であれば true、確定後なら false を返します。素直に読めば、isComposing が true のときだけ弾けば済みそうに見えます。
実際、多くのフォームはこれで直ります。問題は、直りきらないブラウザがあることです。
isComposing だけでは足りない理由
Safari では、変換を確定するための Enter を押した時点で isComposing が false になっているケースが報告されています。この状態では、確定の Enter と、確定後の「送信するつもりの Enter」を isComposing で区別できません。ガードを入れたのに Safari だけ直らない、という相談はほぼこれです。
もう1つ、環境によっては変換確定の Enter が keyCode 229 として届きます。 keyCode は仕様上は非推奨のプロパティですが、IME 由来のイベントを弾くフォールバックとしては今も有効です。
そこで実装は二段構えにします。
const input = document.querySelector('#message');
let composingEndedAt = 0;
input.addEventListener('compositionend', () => {
composingEndedAt = performance.now();
});
input.addEventListener('keydown', (e) => {
if (e.key !== 'Enter') return;
// 1段目: 変換処理中の Enter を弾く
if (e.isComposing || e.keyCode === 229) return;
// 2段目: 変換確定の直後に届いた Enter を弾く（Safari 対策）
if (performance.now() - composingEndedAt < 50) return;
// ここまで来たものだけを「送信の意思がある Enter」として扱う
e.preventDefault();
submit();
});2段目のしきい値は 50 ミリ秒程度が目安です。人間が変換を確定してから、次に意識して Enter を押し直すまでに 50 ミリ秒しかかからないことはありません。 逆に、確定と同時に発生する Enter はこの窓に収まります。
keypress イベントは使いません。すでに非推奨で、IME 絡みの挙動もブラウザ間で揃いません。判定は keydown に寄せます。
そもそも Enter で送らない、という選択
技術的な回避策の話をしましたが、問い合わせフォームに限れば、いちばん確実なのは「Enter では送らない」ことです。
HTML のフォームには暗黙の送信（implicit submission）という仕組みがあり、テキスト入力欄にフォーカスがある状態で Enter を押すと、送信ボタンを押したのと同じ扱いになります。これは仕様どおりの動作なので、JavaScript を書かなければ「Enter で送られない」状態にはなりません。
用途別に整理すると、こうなります。
| 入力欄の種類 | Enter に持たせる役割 |
|---|---|
| 問い合わせフォームの各項目 | 何も起こさない（送信はボタンのみ） |
| 検索ボックス | 検索を実行（1項目のみなので誤送信の実害が小さい） |
| チャット・コメントの入力欄 | 改行。送信は修飾キー（Ctrl / ⌘ + Enter）か送信ボタン |
チャット UI で Enter を送信に割り当てるかどうかは長く議論のある論点ですが、日本語入力を前提にするなら、送信に修飾キーを要求するほうが事故は確実に減ります。 送信が1操作増えることを嫌う声は出ますが、書きかけが飛ぶコストのほうが大きいのが普通です。
検収でどう確かめるか
制作会社に依頼している場合、この不具合は成果物を見ても分かりません。 英数字だけで入力テストをすると再現しないためです。受け入れ確認では、次の手順を明示的に入れてください。
- 日本語 IME をオンにして、変換が必要な文字列を入力する。 「かぶしきがいしゃ」のように、一度で確定しない語を選びます
- 変換候補が出ている状態で Enter を押す。 ここでフォームが送信されたら不具合です
- Chrome と Safari の両方で試す。 Chrome だけ直っていて Safari で再現する、が最も多いパターンです
- スマートフォンでも試す。 iOS / Android の日本語キーボードは PC と挙動が異なります
この4つは、フォーム最適化（EFO）の観点で入力項目を削る話とは別軸のチェックです。項目数を減らしても、送信のタイミングが暴発する問題は残ります。あわせて、入力エラーの文言をどう書くかやキーボード操作とフォーカス移動の設計も、同じ受け入れ確認の中で見ておくと二度手間になりません。
次にやること
まず、直近3ヶ月の問い合わせ通知を見返して、本文が極端に短いもの・同一人物からの連続送信を数えてください。 そこに一定数あるなら、フォームは動いているが取りこぼしている状態です。件数が出れば、改修を後回しにする理由がなくなります。
そのうえで、自社のフォームを IME をオンにして自分で送ってみてください。 変換候補が出ている状態の Enter で送信されるなら、それが今この瞬間も起きていることです。
問い合わせフォームの改修、入力体験の見直し、リード取りこぼしの調査については、グリームハブの HP 制作・リニューアル相談で承っています。既存サイトの構成によって最短の直し方が変わるため、個別にご相談ください。お問い合わせからどうぞ。
