メルティア /entry 改善案 — スクショ比較
2026-09-12／土台＝本番 meltia.net/entry/ の実HTML（アセットも本番から読み込み）。
プロトタイプは送信不能。社内検証用・noindex。
🔴 訂正2件
① 当初「送信ボタンがページの98.7%」と報告したのはHTMLソース内のバイト位置で、描画位置ではありませんでした。 実測はスマホ56.7%（y=2,161px／全体3,810px）。
② 続いて「契約書はタブ枠に格納済み」と書きましたが、これも不正確です。 畳まれてはいません。タブ5枚と枠は常時開いていて、 中身（7,358px分）だけが267pxの窓に収まっている状態です。 書面ブロックはスマホで440px・PCで602px、常に場所を取っています。
① 当初「送信ボタンがページの98.7%」と報告したのはHTMLソース内のバイト位置で、描画位置ではありませんでした。 実測はスマホ56.7%（y=2,161px／全体3,810px）。
② 続いて「契約書はタブ枠に格納済み」と書きましたが、これも不正確です。 畳まれてはいません。タブ5枚と枠は常時開いていて、 中身（7,358px分）だけが267pxの窓に収まっている状態です。 書面ブロックはスマホで440px・PCで602px、常に場所を取っています。
だから「本当に畳む」案（案④）を足しました。
書面ブロックが 440px → 108px（PCは602px→83px）になり、送信ボタンが386px上がります。
同意の順序（書面→チェック→送信）は変わらないので、法的な論点がいちばん小さい案です。
実測値の比較
| 案 | ページ全体 | 最初の入力欄 | 入力欄がFVに | 送信ボタン | 現状比 |
|---|---|---|---|---|---|
| 現状 | 3,810px（4.5画面） | 881px | × 入らない | 2,161px（56.7%） | — |
| 案④ 書面を畳む | 3,423px（4.1画面） | 881px | × 入らない | 1,775px（51.8%） | -386px |
| 案② 入力欄の直後にも | 3,994px（4.7画面） | 881px | × 入らない | 1,465px（36.7%） | -696px |
| 案⑤ ④＋②の併用 | 3,608px（4.3画面） | 881px | × 入らない | 1,465px（40.6%） | -696px |
| 案① 追従バー | 3,938px（4.7画面） | 881px | × 入らない | 0px（0%） | 常時表示 |
| 案③ ヒーロー圧縮 | 3,719px（4.4画面） | 790px | ○ 入る | 2,070px（55.7%） | -91px |
viewport 844px 基準。
① ページを開いた最初の画面
② 送信ボタンが見える位置
③ ページ全体の長さ（縮小）
| 案 | ページ全体 | 最初の入力欄 | 入力欄がFVに | 送信ボタン | 現状比 |
|---|---|---|---|---|---|
| 現状 | 3,654px（4.1画面） | 1,257px | × 入らない | 2,711px（74.2%） | — |
| 案④ 書面を畳む | 3,074px（3.4画面） | 1,257px | × 入らない | 2,132px（69.4%） | -579px |
| 案② 入力欄の直後にも | 3,842px（4.3画面） | 1,257px | × 入らない | 1,850px（48.2%） | -861px |
| 案⑤ ④＋②の併用 | 3,263px（3.6画面） | 1,257px | × 入らない | 1,850px（56.7%） | -861px |
| 案① 追従バー | 3,782px（4.2画面） | 1,257px | × 入らない | 0px（0%） | 常時表示 |
| 案③ ヒーロー圧縮 | 3,366px（3.7画面） | 969px | × 入らない | 2,423px（72%） | -288px |
viewport 900px 基準。
① ページを開いた最初の画面
② 送信ボタンが見える位置
それぞれ何に効くか
| 案 | 内容 | 効く相手 | 効かない相手 | 障壁 |
|---|---|---|---|---|
| 案④ 書面を畳む | 常時開いているタブ枠を、クリックで開く形にする | 書面ブロック440px→108px。送信ボタンが386px上がる | 決断そのもので止まっている人 | 同意の順序は変わらない（書面→チェック→送信のまま）。法的な論点が最も小さい |
| 案② 入力欄の直後にも | 3項目を入れ終わった位置にも同意＋申し込むを置く | 送信ボタンが696px上がる。下まで行かずに送れる | 決断そのもので止まっている人 | 🔴 同意が書面確認より前に来る。法的確認が要る |
| 案⑤ ④＋②の併用 | 書面を畳み、かつ入力欄の直後にも同意＋申し込む | ④の短縮と②の近さを両取り。送信696px上＋全体202px短縮 | 決断そのもので止まっている人 | 🔴 ②と同じ論点を含む |
| 案① 追従バー | 同意＋申し込むを画面下に常時表示する | スクロール位置を問わずいつでも押せる | 決断そのもので止まっている人 | 🔴 ②と同じ論点を含む |
| 案③ ヒーロー圧縮 | 写真と余白を詰めて、入力欄を上へ寄せる | スマホは入力欄がFVに入る。PCは969pxで、まだ69px下 | 送信ボタンまでの距離はほぼ変わらない（-91px） | 写真の見せ方が変わる。好みの問題 |
測れていること
GA4 30日（8/13〜9/11・ユーザー数）で 到達99人 → 入力着手44人 → 申込17人 （送出ログでは19件）。入力を始めた約27人が離脱しています。
平均滞在は92秒。17,000字の書面を読むなら30分以上かかるので、書面は読まれていません。 つまり「読む負担」ではなく「場所を取っているだけの通過物」で、畳む（案④）のは理にかなっています。
GA4 30日（8/13〜9/11・ユーザー数）で 到達99人 → 入力着手44人 → 申込17人 （送出ログでは19件）。入力を始めた約27人が離脱しています。
平均滞在は92秒。17,000字の書面を読むなら30分以上かかるので、書面は読まれていません。 つまり「読む負担」ではなく「場所を取っているだけの通過物」で、畳む（案④）のは理にかなっています。
🔴 測れていないこと（ここを推測で埋めない）
その27人が「送信ボタンを見たうえで押さなかった」のか、「ボタンまで到達しなかった」のかは、 現状のGA4では判別できません。
このプロパティに記録されているスクロールのしきい値は90%の1つだけ （実測：
🔴 以前「下まで到達した人の約半分は押せる状態で押していない」とお伝えしたのは誤りでした。 90%到達の36人には入力していない人も含まれ、逆に送信した人は56.7%で止まるので 36人に含まれない可能性が高い。2つの数字は重ね合わせられません。
先に目盛りを足すのが順序です。スクロールのしきい値を 25/50/75/90 にするか、 「送信ボタンが画面に入った」イベントを1つ足せば、27人の落ちた場所が確定します。 それが分かってから案を選べば、当てずっぽうになりません。
その27人が「送信ボタンを見たうえで押さなかった」のか、「ボタンまで到達しなかった」のかは、 現状のGA4では判別できません。
このプロパティに記録されているスクロールのしきい値は90%の1つだけ （実測：
percentScrolled の値は 90 のみ）。
送信ボタンのある56.7%を跨いだかどうかを測る目盛りが無いためです。🔴 以前「下まで到達した人の約半分は押せる状態で押していない」とお伝えしたのは誤りでした。 90%到達の36人には入力していない人も含まれ、逆に送信した人は56.7%で止まるので 36人に含まれない可能性が高い。2つの数字は重ね合わせられません。
先に目盛りを足すのが順序です。スクロールのしきい値を 25/50/75/90 にするか、 「送信ボタンが画面に入った」イベントを1つ足せば、27人の落ちた場所が確定します。 それが分かってから案を選べば、当てずっぽうになりません。