AIが自社サイトから問い合わせできない？ボタンと入力フォームの点検方法
お客様がAIに「この会社に相談の問い合わせをして」と頼んだのに、サイト上でどのボタンを押せばよいか見つけられなかったらどうでしょう。サービスの説明が充実していても、問い合わせの途中で止まってしまえば、相談にはつながりにくくなります。GoogleのWeb開発ガイドでも、AIエージェントは画面だけでなくHTMLやアクセシビリティ情報を読み、実行できる操作を探すと説明しています。まずは、問い合わせボタンの名前から、入力エラー、受付完了の案内までを明確にすることが大切です。
問い合わせボタンの名前
まず、主なサービスページの公開URLか、個人情報を含まない画面をAIに渡し、次のように頼んでみましょう。
相談を希望するお客様が次に押す場所と、わかりにくい表現を探してください。ページを直接確認できた場合は、ボタンの名前と移動先も書いてください。確認できなかった動作は推測せず、担当者が点検する項目として残してください。
この段階では実際に問い合わせを送らず、公開画面だけを確認します。「もっと見る」「確認」や矢印だけのボタンでは、何が起こるのかを周囲の文脈から読み取る必要があります。相談を受け付けるなら、「サービスについて相談する」のように、行動がわかる名前にしましょう。費用が発生する申し込みを、単なる問い合わせのように表示することも避けてください。
画面に見える文字と、機械が読み取る名前も一緒に確認します。開発担当者には、移動にはリンク、操作の実行にはボタンを使い、それぞれの役割と名前を一致させてほしいと伝えましょう。ボタンのように見せた枠を置くだけでは、操作方法によっては実行できる操作を見つけにくくなります。画面が突然動いたり、別の要素がボタンを覆ったりしないかも点検します。
入力欄と必須情報
入力欄の中にある「メールアドレスを入力してください」という灰色の文字は、入力を始めると消えてしまいます。欄の上に「返信用メールアドレス」という名前を残し、必須かどうかと入力できる形式を案内しましょう。開発時には、その名前を実際の入力欄に結び付ける必要があります。W3Cのフォームガイドでも、入力項目を識別するラベルと、入力欄との明確な関連付けを推奨しています。
最初の問い合わせで必須にする情報も減らせないか考えてみましょう。相談内容と返信用メールアドレスだけで、担当者が次の質問に進めるかを検討します。実際には使わない住所・売上・添付ファイルまで必須にすると、入力する負担と情報を管理する負担がどちらも増えます。必要な同意や個人情報の案内は、実際の収集目的に合わせて見直してください。
以下は、架空の問い合わせフォームを改善前後で比較する体験です。「エラー例を入力」を押し、両方のモードで受付を試すボタンを押して、案内の違いを比べてください。続いて「正常な例を入力」で完了メッセージを確認し、受付を試すボタンをもう一度押して、重複時の案内も見てみましょう。入力内容はこの画面内だけで使用し、外部への送信・保存は行いません。実際の個人情報は入力しないでください。
問い合わせフォームの改善前後を体験
架空の問い合わせで、入力欄・ボタン・エラー・完了案内の違いを比べます。入力内容を送信・保存しない学習用デモです。実際の個人情報は入力しないでください。
読み込み中…
この体験は、実際のAIによる問い合わせの成功率を測定したものではありません。入力欄・ボタン・エラー・完了メッセージを比較する学習用のデモです。
修正方法がわかるエラー案内
「エラーが発生しました」とだけ表示されても、次に何をすればよいかわかりません。どの欄の何が間違っていて、どう直せばよいかを伝えましょう。メールアドレスの形式に問題があるなら、その入力欄の近くに「@とドメインを含むメールアドレスを入力してください」と表示する方法があります。
ほかの入力内容を残し、最初のエラー箇所へ移動できるようにすれば、入力し直す負担を減らせます。赤い枠線と一緒に、エラーメッセージも表示してください。画面を読み上げる支援ツールでエラーを認識できるかも、開発担当者と確認します。
運用を始める前に、正しい入力だけでなく、次のケースも試しましょう。
- 必須項目が空欄の状態
- メールアドレスなどの入力形式が間違っている状態
- 文字数や添付ファイルの容量を超えた状態
- 受付処理が遅く、ボタンをもう一度押した状態
テスト用サーバーや承認された試験手順で架空の情報を使い、実際のお客様からの問い合わせと区別して行います。エラーが出たときに長い問い合わせ内容を最初から書き直す必要がないか、スマートフォンではエラーメッセージが入力欄から離れていないかも確認してください。問題が起きた画面と再現手順を残せば、担当者が同じ問題を見つけて修正できます。
問い合わせ完了が伝わる画面
ボタンの色が変わったり、入力欄が空になったりしただけでは、受付に成功したとはわかりません。サーバー側で受付を確認した後に、「お問い合わせを受け付けました」という結果と、実際の次の手順を表示しましょう。 受付番号があるサービスなら番号を、確認メールを送るサービスなら送信状況を案内します。実際の運用で対応できない返信期限を約束してはいけません。
処理中であることを表示し、繰り返しクリックへの対策も行いましょう。画面上のボタンを押せなくするだけでは重複を完全に防げないため、サーバー側にも重複を判定・処理するルールが必要です。実際の検証では、完了画面と管理者が受け取る問い合わせ記録が一致するかを確認します。
改善は「問い合わせ先を見つける → 必要な情報を入力する → エラーを直す → 完了を確認する」の順に進めてみてください。人はキーボードとスマートフォンで操作をたどり、AIを使った試験が許可されている環境があれば、同じ架空の問い合わせで比較します。止まった段階と重複受付の有無を残すと、次に直す場所が明確になります。
WebMCPは、サイトの機能をAIに明確に伝えるための、開発中のWeb標準の提案です。Chromeではサイトごとの試験プログラムで利用できますが、すべてのブラウザーやAIが共通で対応している機能ではありません。検索結果に表示されるための必須条件として示された技術でもありません。わかりやすい画面と入力構造を整えたうえで、実際に使うエージェントで動作を確認しましょう。
お客様が問い合わせを任せたとき、人もAIも「何を入力し、何を直し、いつ完了したのか」がわかるでしょうか？
問い合わせフォームの点検は、AI活用に備えながら、今いる訪問者の使いやすさも改善する機会です。実際の効果は、修正前後の問い合わせ完了記録で確認してください。
公開ページで操作が止まる箇所を探し、担当者の修正項目としてまとめる作業にも、業務に合うAI選びが必要です。AIBは、特定のAI企業に偏らない独立したAI比較プラットフォームを運営し、企業の経営者や実務担当者が業務と予算に合うAIを選び、活用できるよう支援しています。自社サイトの問い合わせ経路とAI活用の方向性を一緒に見直したい方は、ぜひご相談ください。
出典・参考資料
- AIエージェントによるWebサイトの理解：Build agent-friendly websites
- 入力欄・エラー・完了の案内：Labeling Controls · User Notification
- WebMCPの試験対応と開発状況：WebMCP