LPのマイクロコピー改善ガイド｜ボタン・入力欄・エラー文の見直し方

LPのボタンや入力欄にある短い言葉は、利用者が「次に何が起こるか」を判断する手がかりになります。「送信」と書かれたボタンを押すと確認画面に進むのか、そのまま相談内容が送られるのか。資料を受け取るだけなのか、営業担当から連絡が来るのか。こうした違いが伝わらなければ、内容に興味があっても操作をためらう理由になります。

この記事では、企業のLPや問い合わせフォームを管理する方に向けて、ボタン・ラベル・補足説明・エラー・完了メッセージを見直す手順を説明します。W3Cと英国政府の設計資料、実際に公開された改善記録を参照します。日本語の文案例や会社の状況は説明用の想定であり、Acquaやお客様の改善実績ではありません。

文言を変えれば一定の割合で問い合わせが増える、という約束はできません。まず操作と説明の食い違いを直し、読めること、正しく動くこと、相談につながることを別々に確認します。制作会社へ修正を頼む際にも使えるよう、最後に記録と依頼の項目をまとめました。

1. 言葉を直す前に、実際の動作と約束を整理する

マイクロコピーの対象を、ボタンだけに絞らない

マイクロコピーは、画面操作を助ける短い文章のことです。ボタンの文言だけでなく、入力項目の名前、記入例、必須・任意の表示、エラーの説明、送信完了後の案内も対象になります。LPの大きな見出しがサービスの価値を説明するのに対し、これらの言葉は、目の前の操作を判断するために使われます。

最初は、LPの冒頭からフォーム送信後までを順番にたどり、言葉が表示される場所を一覧にします。画面名、現在の文言、押したときの動作、利用者が受け取るものを並べると、同じ「申し込む」が資料請求と契約申込の両方に使われている、といった不一致を見つけやすくなります。見た目の好みを話す前に、動作の事実を揃えるための作業です。

押す前の予想と、押した後の結果を照合する

たとえば、説明用に設備点検の相談LPを考えます。「診断を受ける」というボタンがあっても、その場で診断結果が出るのか、日程調整の依頼を送るのかでは意味が違います。後者なら、予約が確定するまでの手続きも必要です。実際は担当者が内容を確認して折り返す仕組みなのに、即時に診断が完了するような文言を付けると、受付後の説明にも負担が残ります。

画面を見ながら「この操作で決まること」「まだ決まらないこと」を書き出してください。資料の表示、相談の送信、日程の希望提出、契約の成立は別の出来事です。ボタンが短くても、その違いを周辺の説明で補えます。サービス担当者が説明している内容と、制作担当者が実装した内容が違う場合は、先に運用を確認してから言葉を決めます。

無料・所要時間・返信期限の根拠を担当者と確認する

「無料」「すぐ」「簡単」「必ず返信」といった言葉には、運用上の条件が伴います。相談は無料でも現地調査は有料かもしれません。入力時間は必要資料の有無で変わり、返信までの時間は休日や受付状況によって変わります。安心してもらうための文言ほど、どこまで約束できるかを確認する必要があります。

確認表には、対象の行動、料金が発生する時点、対応できる時間、例外時の案内、内容を決める担当者を書きます。まだ確認できていないことは、断定の強い宣伝文句に置き換えません。「相談内容を送る」「資料の内容を見る」のように、現時点で確実に行われる操作を表す言葉から始める方法があります。後から条件が変わったときに、LPとフォームと自動返信を一緒に直せるよう、掲載箇所も記録しておきます。

2. ボタンは、行き先と実行する操作が分かる言葉にする

確認・送信・保存を同じ言葉で扱わない

GOV.UKのボタン設計ガイドでは、ボタンが行う動作を表す文言を使い、情報を保存するかどうかによって「続ける」に相当する表現を使い分けています。この考え方は、日本語の問い合わせフォームでも参考になります。ただし、英語の表現をそのまま翻訳して採用するのではなく、自分のサイトの動作に合わせます。

確認画面へ進む段階なら「入力内容を確認」、確認後に情報を送る段階なら「相談内容を送信」のように分けられます。入力内容を保存しないのに「保存して次へ」とは書けません。確認画面自体がないフォームでは、確認用の言葉を追加するためだけに画面を増やす必要もありません。まず今の仕組みを確かめ、処理と表示を一致させます。

短さと具体性を、前後の説明も含めて判断する

「こちら」「詳細」「次へ」は短く収まりますが、単独では行き先を説明しにくい言葉です。一方で、サービス名やメリットをすべてボタンへ入れると、スマートフォンで何行にも折り返され、主な操作が読み取りにくくなります。ボタンには中心となる行動を置き、対象や条件は直前の見出しや補足文で説明すると整理しやすくなります。

想定例として、サービス紹介の末尾には「点検内容を相談する」、料金表の近くには「見積もりの進め方を見る」といった候補が考えられます。同じフォームへ進む場合でも、途中の説明と矛盾しないことが必要です。複数の言い方を置くなら、送信する相談の種類が利用者にも受付担当にも分かるかを確認してください。ボタン名の違いだけで、異なるサービスが受けられるように見せないようにします。

同じ操作の呼び方を、ページをまたいで揃える

LPでは「無料相談」、フォームでは「お申し込み」、完了画面では「ご注文ありがとうございます」と表示されると、途中で契約になったのかと不安を生む可能性があります。各画面を単独で読むだけでは、この食い違いを見逃します。LP、フォーム、確認画面、完了画面、自動返信の件名まで並べて確認するのが確実です。

社内用の言葉と利用者向けの言葉も分けます。受付システム上の処理名が「案件登録」であっても、そのままボタンに表示する必要はありません。「相談」「資料請求」「予約希望」のように、利用者が行う手続きの名前を決め、画面全体へ適用します。すでに問い合わせフォームがある場合は、フォーム全体の改善ガイドと合わせて、項目や受付方法の整合も確認できます。

3. 入力欄は、項目名・記入例・利用目的を分けて説明する

入力中も、何の項目か分かるようにする

W3C WAIのラベルの解説は、入力部品を適切に識別できる名前と関連付けを扱っています。見た目に文字が近くにあることと、支援技術を含めてどの項目の名前か分かることは別です。制作担当者には、表示する文言だけでなく、項目名と入力欄が適切に関連付いているかも確認してもらいます。

見た目の点検では、入力前、文字を入れた後、エラーになった後の三つの状態を見ます。記入例が入力欄の中にだけ表示される仕組みでは、入力すると例が消えることがあります。項目名まで消えてしまうなら、画面上へ戻らないと何を入れていたか確認できません。名前は入力欄の外へ置き、必要な形式の説明も、入力中に参照できる位置へ置く案を検討します。

必須と任意は、受付に必要な理由から決める

「必須項目は少ないほどよい」と数だけで決めると、返信や担当振り分けに必要な情報まで取れなくなることがあります。逆に、念のためという理由で項目を増やせば、利用者は答える目的が分かりません。まず各項目について、誰が、どの場面で使い、分からない場合はどう受付を進めるかを書きます。

たとえば、現地対応の可否を判断するために所在地が必要なら、最初から番地まで求めるのか、市区町村で足りるのかを考えられます。電話連絡を必ず行わないなら、電話番号を求める目的も確認します。「分からない」「未定」を受け付ける項目は、無理に仮の数字を入れさせない案内にします。選択肢を増やす変更が必要なら、受付システム側でも処理できるかを合わせて確認してください。

記入例を、実際に送られてよい内容と区別する

相談内容の例文を置く場合は、利用者が自分の状況へ置き換えられる内容にします。「現在のサイトで困っていること」「希望する時期」「分かっている条件」のような観点は補助になりますが、長い完成文を必須回答のように見せると、同じ分量を書かなければならないと感じさせる可能性があります。分からない項目があっても相談できるかどうかも案内します。

例文には、実在のお客様のメールや相談内容を無断で流用しません。メールアドレスなら例示用の形式を使い、会社名や状況も説明用と分かるものにします。添付ファイルを受け付ける場合は、形式・容量・何を添付してほしいかを入力前に示します。文言の改善で扱える範囲と、ファイル受付機能そのものの制約を分けることが、実装後の食い違いを減らします。

4. エラーは、直す場所と次の行動を具体的に伝える

「入力エラー」だけで利用者へ判断を返さない

「入力内容が正しくありません」だけでは、どの項目をどう直せばよいか分かりません。項目名、受け付けられなかった理由、直すための情報を組み合わせます。メールアドレスの形式を確認したい場面なら、氏名まで含めたフォーム全体を赤くするのではなく、対象の欄を特定できる案内が必要です。

W3C WAIの通知に関する解説では、送信が成功したかどうかを伝え、エラーは理解しやすく修正方法が分かる内容にすることを説明しています。この考え方を点検へ使うなら、エラー文を読んだ人が、制作担当者の補足なしで対象欄へ戻れるかを見ます。赤色だけで違いを表さず、文章として理由が分かることも確認します。

入力の間違いと、サービス側の問題を分ける

GOV.UKのエラーメッセージの説明は、利用者が入力を直して解決する問題と、利用者では直せないサービス側の問題を区別しています。入力欄のエラー部品を、サービスの停止や対応対象外の案内にそのまま使うべきではない、という指針です。民間の問い合わせフォームでも、修正できないことを何度も修正するよう求めない設計に応用できます。

たとえば、通信に失敗して送信結果を確認できない場合に「必須項目を入力してください」と表示するのは適切ではありません。再試行できるのか、すでに受付された可能性があるのか、別の連絡方法があるのかを、実装で把握できる範囲に合わせて案内します。原因を取得できない仕組みなのに、原因を断定する文言を作るのも避けます。必要なら文面だけでなく、エラーを区別する機能の修正を依頼します。

再入力と再送信の負担まで確認する

エラーを表示したときに、正しく入力した内容まで消えてしまうと、文言だけを丁寧にしても手間は残ります。入力値が残るか、修正した欄が分かるか、もう一度送ったときに同じ内容が重複して届かないかを確認します。個人情報を扱うため、どこまで内容を残すかは保存方法や運用条件と一緒に考えます。

依頼書には、エラーの文言だけでなく、再現する入力、表示位置、残る入力値、修正後の動作を書いてください。「エラーを分かりやすくする」より、「メールアドレスの形式が合わないとき、当該欄の近くへ理由を表示し、氏名と相談内容は消さない」と書いた方が、完了条件を確かめられます。試す際はテスト用の情報と許可された送信先を使い、実際のお客様へ通知を送らない環境を用意します。

5. 完了画面と自動返信で、受付後の見通しを伝える

何が完了したのかを、曖昧にしない

「ありがとうございます」だけでは、資料請求を送れたのか、予約が確定したのか、単にボタンを押せたのかが分かりません。完了した手続きの名前と、その時点で確定していることを伝えます。受付処理が成功したことと、担当者が内容を確認したこと、見積もりを作成したことは同じではありません。

GOV.UKの完了ページの設計例は、手続きの完了、次に起きること、必要な連絡情報などを示す構成を紹介しています。自社のLPへ応用するときは、受付システムが実際に確認できる状態だけを書くようにします。送信ボタンを押した瞬間に成功文を出すだけでは、送信先へ渡せた証拠にはなりません。文言を決める担当と、成功判定を実装する担当で意味を揃えます。

返信の目安と、連絡が来ないときの方法を揃える

返信の目安は、受付担当者が対応できる条件を確認したうえで書きます。営業日の考え方、休日の受付、確認に時間がかかる相談の扱いなど、利用者に関係する条件を簡潔に示します。説明用の文案例としては「内容を確認し、担当者からご連絡します」がありますが、実際に連絡方法や目安を案内できるなら、それを具体的に加えます。

連絡が来ない場合の案内も、同じフォームへの再送しか方法がない状態になっていないか確認します。別の連絡先を掲載するなら、その窓口が今回の相談を調べられる必要があります。受付番号が発行される仕組みなら、問い合わせ時に何を伝えると確認しやすいかを書けます。仕組みにない受付番号や、存在しない専用窓口を、便利そうだからという理由で文面へ加えてはいけません。

画面・メール・担当者の案内を同じ基準で管理する

完了画面で「メールで返信」と伝え、自動返信で「電話します」と書かれていれば、どちらを待つべきか分かりません。自動返信の件名、本文、差出人の表示、返信先まで含めて、同じ手続きを案内しているかを読み合わせます。フォームのコピーとメール設定が別の管理画面にある場合でも、変更時の確認対象は一つの一覧へまとめておくと扱いやすくなります。

また、自動返信が届いたことと、担当者の受信や対応完了は区別します。メールの配送や迷惑メール判定も関係するため、文言の差し替えだけで到達を保証することはできません。詳細な設計は問い合わせフォームの自動返信メールガイドで扱っています。ここでは、画面に書いた約束と、実際の受付体制が一致しているかを確認するところまでを文言レビューに含めます。

6. 公開事例から、言葉と見た目を一緒に点検する

GOV.UKのタスクリスト改善で観察されたこと

英国政府の2023年12月のタスクリスト改善記録では、利用者がリンクの文字ではなく、進行状態を示すタグを押そうとする行動が報告されています。状態表示が通常のボタンに似て見えることが、見直しの理由になりました。改良では状態タグの文字や背景の扱いを変え、タスクの行全体もクリックできるようにしています。

これは政府サービスにおける観察と設計変更の記録であり、企業のLPで問い合わせが何割増えるという事例ではありません。参考になるのは、利用者がどこを押そうとしたかを観察し、言葉だけでなく、色や操作できる範囲も一緒に見直した点です。日本語の文言へ置き換える場合も、元の改善率として使える数字はありません。

状態を示す言葉と、実行する言葉を区別する

企業サイトでも「確認中」「受付済み」「送信する」が同じ濃い色の角丸表示になっていると、状態と操作の区別がつきにくくなる場面があります。説明用の例では、「確認中」は今の進み具合を知らせる表示であり、「内容を確認」は利用者が行う操作です。文字が似ていても役割は違うため、同じ見た目で揃えることが必ずしも分かりやすさにつながりません。

文言一覧に「役割」という列を加えると、この違いを整理できます。リンク、送信ボタン、状態表示、補足、警告のどれなのかを記録し、見た目や実装がその役割に合っているか確認します。必要なら制作担当者へ、キーボードで操作できるか、読み上げでボタンやリンクとして伝わるかも確かめてもらいます。画面上の文字を置き換えただけで、操作部品の意味まで変わったとは判断しません。

自社の利用場面に置き換えて、観察する課題を作る

GOV.UKのユーザビリティテストの手引きでは、利用者に課題を行ってもらい、その様子を観察する方法を説明しています。文言を評価する場合も、「このボタンを押してください」と答えを教えるより、「点検を依頼できるか確認し、相談方法を探してください」のように、達成したい用事を伝える方が検討材料を得られます。

観察メモには、最初に読んだ言葉、押そうとした場所、ためらった箇所、次に起こると予想したことを残します。「使いやすそう」という感想と、実際に目的の画面へ進めた事実を分けて記録してください。公開事例の見た目をそのまま採用することが目的ではありません。自社の利用者がどの場面で迷い、その迷いを言葉・配置・動作のどこで解消するかを判断するために使います。

7. 修正を依頼し、表示・動作・成果を別々に確かめる

文言の修正票に、表示条件と完了条件を入れる

制作会社へ依頼するときは、「もっと問い合わせしたくなる言葉に」という希望だけでなく、現在の画面と問題を共有します。どのURLの、どの状態で、どの文言が出ているのか。利用者が何を誤解しそうなのか。正しい動作は何か。これらを揃えると、文言だけで直る問題か、確認画面や受付機能まで変更する必要があるかを判断できます。

原稿の承認者と、公開作業の担当者も決めます。「無料」や返信期限は営業・受付担当の確認が必要なことがあり、ボタンの動作は実装担当の確認が必要です。どちらか一方だけで決めず、未決定の項目と確認先を残します。詳しい伝え方はホームページの修正依頼ガイドにまとめています。

読めることと、正しく動くことを先に確かめる

公開前は、スマートフォンの狭い画面でも文字が切れないか、長い文言が隣のボタンに重ならないか、文字を拡大しても読めるかを確認します。ボタンだけではなく、入力中の補足説明、エラー、完了画面も対象です。通常の入力に加えて、未入力、形式違い、戻って修正する操作を試し、それぞれの状態に適した言葉が出るかを見ます。

文言を変えるときに、プログラムが表示文字を手がかりに動いていると、計測や処理へ影響することもあります。制作担当者には、見た目の変更後も送信や計測が意図どおり動くかを確認してもらいます。実際の送信を試す場合は、受信先やテスト情報を合意してから行います。表示が整ったという確認と、メールが受信されたという確認を一つの合格欄にまとめないことが大切です。

問い合わせの結果は、条件と母数を残して判断する

Googleの拡張計測機能の説明では、フォーム操作の開始や送信に関するイベントを扱っています。ただし、イベント名が表示されているだけでは、自社のフォームで何を数え、受付まで届いたかは分かりません。ボタンのクリック、送信処理の成功、担当者の受信、有効な相談を別に確認し、どの段階を評価するか決めます。

文言変更の前後を比べるなら、変更日、対象ページ、文面、同時期の広告や料金変更、訪問者数、対象となる相談数を記録します。説明用に、ある期間の訪問が200件・相談が4件、次の期間が100件・相談が3件だったとします。単純な割合は2%から3%になりますが、相談の件数は減っています。この数字だけでは文言が改善を生んだとも、悪化させたとも判断できません。流入の違い、集計条件、件数の少なさを含めて考える必要があります。

アクセスが少ない場合も、操作の誤解や読めない表示は点検できます。まず確認できた不具合を直し、成果の比較は必要なデータが集まってから行います。一律の期間や成功率を合格条件にせず、分からないことも記録してください。問い合わせが来ない理由全体を整理したい場合は、計測・内容・導線・受付の確認手順へ進めます。相談を依頼する際は、気になる画面、現在の文言、期待する動作、受付方法を揃えると、制作や改善の相談を具体的に進められます。