本文へスキップ
tech公開更新約9分で読めます

問い合わせフォームの項目の決め方 コールセンターの一次回答を早くする設計

シェア
問い合わせフォームの項目の決め方 コールセンターの一次回答を早くする設計

問い合わせフォームの必須項目は、最初の返信を書くときに使うものだけに絞ります。基本は、返信先の連絡先、用件の分類、本文の3つです。

電話番号や住所を「念のため」必須にしても、一次回答は早くなりません。お客様の手間と、受け取る側の個人情報の管理負担が増えるだけです。

フォームは、お客様が問題の解決に最もよく使う手段でもあります。Tayoriが公表したカスタマーサポート調査2026では、お問い合わせフォームが毎年約6割で首位でした。入口の項目の決め方が、その後ろにいるコールセンターの一次回答の速さを左右します。

項目を残すかは「最初の返信で使うか」で決める

項目を残すかは「最初の返信で使うか」で決める

項目が増える理由は、たいてい「あとで使うかもしれない」です。マーケティング部門は業種を、営業は会社規模を聞きたがる。足し算で決めると、フォームは長くなる一方です。

GovTech東京の入力フォームガイダンスは、入力項目を厳選し、必要のない情報は取得しないとしています。そのうえで、フリガナ・電話番号・メールアドレス・住所を「要注意」の項目に挙げています。

今のフォームを見直すときは、項目ごとに次の表を埋めます。

項目 最初の返信で使うか 使わないなら、いつ・誰が使うか 判定
氏名 宛名に使う 必須
メールアドレス 返信先 必須
用件の分類 担当の振り分け 必須
本文 回答の材料 必須
電話番号 使わない 電話で折り返す用件のときだけ 任意、または用件で出し分け
住所 使わない 交換品の発送が決まったとき 外して、必要になってから聞く
会社規模 使わない 営業部門の分析 外す

(判定は記入例です)

「いつ・誰が使うか」の列が埋まらない項目は外します。埋まる項目でも、その場面が来てから聞けば足りるものは、返信の中で聞けば済みます。

同じガイダンスは、抽選で詳しい個人情報が要る場合も、申込み時は名前とメールアドレスなど最低限にとどめ、当選者へのメールで住所などを取る進め方を示しています。問い合わせフォームにもそのまま使える考え方です。

個人情報は利用目的を1行で書ける項目だけ取る

項目を減らすことは、法令対応の負担を減らすことでもあります。個人情報保護委員会のガイドライン(通則編)は、利用目的をできる限り具体的に特定するよう求めています。「事業活動に用いるため」は、特定していない例として挙がっています。

本人から入力画面などで直接取得するときは、あらかじめ利用目的を明示します。ガイドラインは、自社主催のキャンペーンの申込みで、自社のホームページの入力画面に入力された個人情報を取得する場合を、その事例に挙げています。

実務では、送信ボタンの近くに利用目的の要約とプライバシーポリシーへのリンクを置きます。項目が増えるほど、この文は長くなります。何に使うかを1行で書けない項目は、外す候補です。

本文欄にも気を配ります。お客様は、病歴や家族の事情を書いてくることがあります。

ガイドラインは、要配慮個人情報を本人から適正に直接取得する場合、本人が提供したことをもって取得に同意があったと解されるとしています。受け取ったあとの保存期間と閲覧権限は、別に決めておきます。本文欄の下に「カード番号やパスワードは記入しないでください」と添えるのも、受け取る側を守る一文です。

用件の選択肢はコールセンターの振り分け先と一対一にする

用件の分類は、受け取った側が担当を決めるための項目です。選択肢は、窓口の振り分け先と一対一になるように作ります。

「その他」が多く選ばれるフォームでは、人が本文を読んで振り分け直しています。一次回答が遅れる原因の一つがここです。

選択肢は次の順に決めます。

  1. 振り分け先(担当チーム・部署)を書き出す
  2. 振り分け先ごとに、お客様が使う言葉でラベルを付ける。「契約管理」ではなく「プランの変更・解約」
  3. 選択肢は縦に並べる。5個以内ならラジオボタン、6個以上ならプルダウンにする(GovTech東京のガイダンスの基準)
  4. 「その他」を置き、選ばれた割合を毎月見る

用件を選んだあとに、その用件で要る項目だけを出す作り方もあります。「注文・配送」を選んだときだけ注文番号の欄を出す、という形です。

注文番号のような項目には、どこを見れば分かるかを添えます。Tayoriが公表したカスタマーサポート調査2025によると、問い合わせを検討したのに実際はしなかった人は43.7%でした。理由の例には「必要な情報(注文番号など)を探すのが面倒で断念した」が挙がっています。

「注文番号はご注文確認メールの件名にあります」の1行があるだけで、探す手間は減ります。

入力の手間は5つの作り方で減らす

入力の手間は5つの作り方で減らす

よく使う項目の作り方は、GovTech東京のガイダンスが項目ごとに示しています。問い合わせフォームに関係する5つを抜き出しました。

項目 作り方
氏名 1つの入力欄にまとめる。オートフィルに対応し、十分な最大文字数をとる
メールアドレス 1つの入力欄(@の前後で分けない)。確認用の2回入力は求めない
電話番号 1つの入力欄。ハイフンの有無も全角・半角も受け付ける
自由記入 最大文字数を書き、入力中に文字数を表示する
必須の表示 「*」などの記号だけにせず、ラベルの横に「必須」と文字で書く

メールアドレスの2回入力について、ガイダンスは手間が増えるだけでエラー防止は期待できないとしています。外して困らない項目です。欄を1つ消すだけです。

アクセシビリティの国際規格WCAG 2.2は、入力を求める箇所にラベルか説明を付けるよう求めています(達成基準3.3.2)。同じ手続きの中で前に入力した情報をもう一度求めるなら、自動で入力済みにするか、選べるようにすることも求めています(3.3.7)。

この考え方で見ると、ログイン済みの会員に氏名やメールアドレスを打ち直させるフォームは直す対象です。会員情報から引ける項目は、最初から入力済みにしておきます。

送信後の画面と自動返信に受付番号と回答予定日を出す

フォームの設計は送信ボタンで終わらず、完了画面と自動返信メールに受付番号と回答予定日を出すところまで続きます。

GovTech東京のガイダンスも、公開前の準備として一次返信の対応期限を定めることを挙げています。返答に関わる担当の確認フローを体制表にしておくことも同じ箇所にあります。

完了画面には、送信内容の控えと、急ぎの場合の連絡先も置きます。同じ内容を電話でもう一度問い合わせる二重の問い合わせは、送信が届いたか分からないときに起きやすくなります。

自動返信のあとに送る個別の返信の書き方は、問い合わせメール返信テンプレートの作り方に例文があります。

フォームの手前にFAQがあるなら、フォームに来るのはFAQで解決しなかった人です。FAQの閲覧からフォーム送信までをつないで測ると、自己解決率の見落としが減ります。

AIで自動分類する前に、選んだ分類と本文の一致率を測る

フォームの問い合わせをAIで自動分類したり、回答の下書きを作らせたりする場合、お客様が選んだ用件の分類は、AIにとっての正解ラベルになります。

選択肢が振り分け先と揃っていないフォームでは、選ばれた分類と本文の中身が食い違う件数が増えます。そのデータでAIの分類精度を測っても、誤っているのがAIなのか元のラベルなのか分かりません。

AIを入れる前に、例えば直近の問い合わせから100件ほどを抜き出します。お客様が選んだ分類と、本文から人が判断した分類が一致する割合を測ってください。

一致率が低いなら、先に直すのは選択肢です。AIではありません。

本文欄の扱いも精度に効きます。AIが下書きを作るなら、本文と追加項目の情報だけで答えられるかが分かれ目です。

用件ごとに出し分ける追加項目(注文番号、利用中のプラン、エラーの表示内容)は、人の一次回答にもAIの下書きにも効きます。減らすのは使わない項目で、増やすのはその用件で必ず使う項目。ここを取り違えなければ、項目を減らす話とAIの話はぶつかりません。

新しく窓口を作る段階なら、フォーム・FAQ・対応履歴を揃える順番から決めると、AIを足すときに作り直さずに済みます。

まとめ

必須項目の判定は、「最初の返信で使うか」の一問で足ります。迷う項目は、使う場面が来てから聞けば間に合います。

明日できるのは、先月「その他」を選んだ問い合わせを例えば20件ほど読み、どの振り分け先に回ったかを書き出すことです。同じ行き先が何度も出てきたら、それが足りない選択肢です。

よくある質問

電話番号は必須にしないほうがよいですか。

メールで返信する窓口なら、電話で折り返す用件のときだけ出す形で足ります。

用件の選択肢はいくつまでにすべきですか。

数の上限より、振り分け先と一対一になっているかを先に確かめます。5個以内ならラジオボタン、6個以上ならプルダウンが表示の目安です。

確認画面は必要ですか。

GovTech東京のガイダンスは、確認ページを必ず設置するとしています。送信前に内容を見直せると、誤ったメールアドレスによる返信の不達も減ります。

本文に要配慮個人情報が書かれていたら同意を取り直すべきですか。

個人情報保護委員会のガイドラインは、本人から適正に直接取得する場合は、本人が提供したことをもって同意があったと解されるとしています。受け取った後の保存期間と閲覧権限を決めておくことのほうが先です。

注記

確認日: 2026年11月4日。調査の数字は各発表時点のもので、Tayoriの調査はPR TIMESに掲載された同社の発表によります。項目の判定表は記入例で、実在の窓口のデータではありません。個人情報の取扱いや利用目的の書き方の適否は、個人情報保護委員会の最新のガイドラインを確認し、必要に応じて専門家に相談してください。本稿はAI著者によるデスクリサーチと編集部の実務設計案で、特定の製品を推奨するものではありません。


出典

この記事はCC AI LabのAI著者(相馬 迅/相原 ことは)が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。

確定版の速報を、会員に先行配布します。

無料の会員登録で、ベンチマーク速報レポートと隔週ニュースレターを受け取れます。

無料で会員登録する
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
この記事の著者
相原 ことはAI執筆 ・ 編集部監修
アナリスト/CC AI Lab

コンタクトセンターAIの事例と技術を構造で読み解く、CC AI LabのAIアナリスト「相原 ことは」です。導入事例、アーキテクチャ、コスト構造、ベンチマーク、KPI設計や移行パターンといった実務のロングテールを、複数の一次発表を横断して整理します。数値は出典付きで扱い、単一ベンダーの優劣ではなく投資テーマや設計論点として提示します。相原 ことはの記事はすべてCC AI Lab編集部が内容を確認・承認したうえで公開しています。

この著者の記事一覧
シェア