同じ質問に何度も返信していると、FAQページを作れば少しは楽になるのでは、と考えますよね。ただ、質問と回答を並べるだけでは、読む人が答えにたどり着けるとは限りません。
先に整えたいのは、実際の問い合わせから質問を拾い、既存ページで直すもの、FAQにまとめるもの、個別に答えるものへ分ける作業です。
FAQは質問を並べる前の整理で決まる
最初に確かめたいのは、問い合わせてきた人が何をしようとして、どこで止まっているかです。
「料金について」「サービスについて」と自社側の分類から項目を作り始めると、この視点が抜け落ちやすくなります。
利用者の目的は、「誰が」「何をしたいか」「なぜしたいか」の3つに分けて書くと整理しやすいでしょう。
英国政府のWebサイト(GOV.UK)のコンテンツ設計ガイドでも、利用者のニーズをこの3つで書き、本人が実際に使う言葉で表す型が使われています。
講座を初めて検討している立場として、申し込む前に自分が受講対象かどうかを確かめたい。申し込んだあとで合わないと分かるのは避けたいから。
このとき、「FAQを読みたい」「料金表を見たい」のような手段を書かないのがコツです。手段を先に決めてしまうと、本当はもっと合う解決策があっても見えなくなります。
小規模事業のFAQ候補も、まずは利用者の行動として言葉にしてみましょう。
- 申し込む前に、自分が対象者か確かめたい
- 当日の持ち物を準備したい
- 予約を変更したい
- 支払い方法を選びたい
- 問題が起きたときの連絡先を知りたい
目的が見えてくると、FAQに載せる回答、申込ページに直接書くべき説明、個別対応に残す内容を分けやすくなります。
最初にFAQページが必要か判断する
質問が繰り返し届いていても、独立したFAQページを作ることが最初の解決策とは限りません。よく聞かれるのは、その情報がサイトのどこかに必要だというサインです。
考えるべきなのは、置き場所がFAQなのか、既存ページなのかという点でしょう。
FAQを別ページとして足すと、既存ページと同じ説明を別の言い方で繰り返すことになりがちです。質問文の見出しは、単純な見出しより読み取りに時間もかかります。
「予約変更の期限」と「予約日を変更したい場合、いつまでに連絡すればよいですか?」を見比べると分かりやすいですよね。
まずは、その質問が生まれた原因を確かめましょう。
- 申込ページに必要な条件が書かれていない
- 書いてはあるが、見出しや置き場所が分かりにくい
- 複数のページで説明が食い違っている
- 内容は正しいが、利用者が使う言葉と違う
- 個別の事情が多く、共通の回答だけでは解決できない
原因が1から4のどれかなら、FAQを作るより既存ページの修正が先です。
たとえばキャンセル期限は、申し込む人全員が事前に知っておくべき条件です。FAQだけに置くのではなく、予約ページの条件として見える位置に載せておきましょう。
独立したFAQページが候補になるのは、複数のページにまたがる補足をまとめて案内したいときや、利用前・利用中・利用後の疑問をひとつの入口から探せるようにしたいときです。
FAQを作ること自体を目的にせず、既存ページで解決する内容と、補足の入口にまとめる内容を分けて考えてください。
FAQに載せる質問候補を集める
思いつきで質問を決めると、運営者が説明したいことばかりが並びがちです。
候補は、すでに届いている問い合わせから集めましょう。
メール、問い合わせフォーム、LINE、SNSのDM、電話のメモ、対面で聞かれたことなど、確認できる記録をひとつの場所に寄せていきます。
候補表に残すのは、「どの段階で、何が分からず、次に何をしたかったか」という共通部分だけで十分です。氏名や連絡先、個人の具体的な事情は移さないようにしましょう。
問い合わせ記録を同じ基準で集める
質問文だけを書き写していくと、あとで似た問い合わせをまとめにくくなります。記録する項目を最初にそろえておくと、整理がずいぶん楽になるはずです。
| 記録する項目 | 書き方の例 |
|---|---|
| 質問の要約 | 予約日を変更したい |
| 質問した人の大まかな区分 | 初めての利用者 |
| 問い合わせが来た経路 | LINE |
| 段階(利用前・申込中・利用後) | 申込後 |
| 本人が次にしたかったこと | 別の日程で受講したい |
| 既存ページの回答 | 予約ページに記載なし |
| 共通の回答で解決できるか | 期限内なら解決できる |
| 最後に確認した日 | 記録を見直した日付 |
たとえば「日程は変更できますか」と「予約日をずらしたい」は、言い方が違っても同じ目的にまとめられます。
反対に「体調不良のときの振替」と「講師都合の中止」は、条件が違うなら回答を分けた方がよいでしょう。
件数だけでなく、同じ内容を扱うページのアクセス状況や、申込画面の途中で離脱が起きていないかも参考になります。
問い合わせ記録とアクセス解析の両方を見ておくと、聞かれてはいないけれど利用者がつまずいている場所にも気づきやすくなります。
質問を利用者の目的別にまとめる
集めた質問は、社内の部門名やサービスの内部用語ではなく、利用者が進めたい行動で分けましょう。たとえば次のような分け方です。
- 選ぶ前
-
対象者、サービスの違い、必要な準備
- 申し込む
-
空き状況、申込方法、支払い
- 利用する
-
当日の流れ、持ち物、参加方法
- 変更する
-
日時の変更、キャンセル、登録情報の修正
- 困ったとき
-
接続できない、メールが届かない、連絡先を知りたい
この分類は、そのままページの見出し候補にもなります。
ただし、集めた質問をすべてFAQに入れるわけではありません。既存ページへ戻す内容や、個別対応に残す内容はここから外していきます。
載せる質問と載せない質問を選ぶ
候補を選ぶときは、聞かれた回数だけで決めないのがポイントです。
めったに聞かれない質問でも、申込条件や当日の参加可否に関わる内容なら、見つけやすい場所に置いておく必要があります。
判断には、次の4つの軸を使うと迷いにくいでしょう。
| 判断の軸 | 確かめること |
|---|---|
| 共通性 | 多くの人に同じ回答を出せるか |
| 重要度 | 知らないと申込や利用を進められないか |
| 重複 | 既存ページに同じ説明があるか |
| 個別性 | 契約内容や本人の状況を見ないと答えられないか |
共通性と重要度が高い内容は、FAQか該当ページに載せる候補です。既存ページにすでに回答があるなら、同じ文章をFAQへ複製するより、そのページの見出しや案内リンクを直しましょう。
説明が一か所にまとまっていれば、内容を変えるときの手間も増えません。
個別性が高い質問は、一般的な判断基準までを示したうえで、「詳しい状況は問い合わせの際にお知らせください」と連絡方法につなぎます。
商品ごとの見積額、個別契約の可否、体調や事情に応じた判断などは、公開のFAQで一律に答えない方が安全な場合もあります。どこまでを共通の回答にするかは、実際のサービス範囲と対応方針に合わせて運営者が決めてください。
読んだ人が次へ進める回答を書く
回答は、最初の一文で結論を伝えるのが基本です。運営側の事情から説明を始めるのではなく、読む人が判断に必要な順番で、条件と次の行動を続けていきます。
並べ方は次の5つを目安にするとよいでしょう。
- 結論(できる・できない・条件付きのどれか)
- 条件(期限、対象、必要な準備)
- 手順(どのページや連絡先から進めるか)
- 例外(個別の確認が必要な場合)
- 次の行動(申込、変更、問い合わせへのリンク)
予約変更についての回答なら、たとえば次のような形になります。
結論と条件を最初に示し、操作する場所を案内したうえで、期限を過ぎた人だけを問い合わせ先へつなぐ流れです。ここで使った期限は例なので、実際の運用ルールと必ずそろえてください。
ひとつの回答に目的を詰め込みすぎないことも大切です。「申込方法」「支払い方法」「キャンセル条件」をひとつの項目にまとめると、必要な情報がかえって探しにくくなります。
回答が長くなりそうなら、FAQには概要だけを書き、詳しい説明は詳細ページへ案内しましょう。
FAQの見せ方と置き場所を決める
回答がそろったら、見せ方を決めます。最初に試したいのは、通常の見出しと短い回答をそのまま並べる形です。
利用者が使う言葉を見出しの前半に置き、ページの先頭に各項目へのページ内リンクを用意しておけば、項目が増えても目的の場所へ移動しやすくなります。
よく見かけるアコーディオン(見出しを押すと回答が開閉する表示)は、ページを短く見せられる反面、内容を隠す仕組みでもある点に注意が必要です。
全員が見る必要のある内容には使わないこと、まずはアコーディオンなしで試すこと、質問の羅列を区切る目的では使わないことがポイントになります。
小規模事業のサイトなら、次の順番で検討すると判断しやすいでしょう。
見出しと回答を普通に並べる形です。項目が少ないうちは、これで十分です。
利用目的ごとにまとめ、ページの先頭から各まとまりへ移動できるようにします。
FAQには概要を残し、詳しい手順や規約の説明は専用のページに任せましょう。
一部の補足だけを畳みたい場合に、利用者に試してもらうなどして使われ方を確かめてから取り入れます。使うテーマやプラグインで、キーボードで開閉できるか、見出しとして正しく扱われるかも見ておくと安心です。
料金、対象者、申込条件、キャンセル期限のように、判断する前に全員が確認すべき情報は隠さない方がよいでしょう。
見た目の好みより、必要な情報を見つけられるかどうかを基準に選んでください。
FAQから問い合わせにつなぐ
FAQだけで、すべての事情に答えるのは難しいものです。最後には問い合わせへの出口を用意しておきましょう。
とはいえ「解決しない場合はこちら」とリンクを置くだけでは、問い合わせる側も受ける側も、何を伝えればよいかが分かりません。

問い合わせの前に伝えてほしいことを、必要最小限で示しておくと、やり取りの往復が減ります。
- 利用している商品・サービス名
- 申込前・申込後・利用中のどの段階か
- 起きている問題
- すでに試したこと
- 希望する対応
注文番号などを送ってもらう場合は、公開コメントやSNSの投稿ではなく、問い合わせフォームのような非公開の窓口へ案内してください。パスワードや認証コード、決済情報は送らないよう、注意書きを添えておくと安心です。
各回答から関連ページへ移動できるようにしておくと、読んだ人は探し直さずに次の行動へ進めます。
申込方法の回答には申込ページ、日程変更の回答には変更手続きのページ、個別の確認が必要な回答には問い合わせフォームというように、回答と行き先をひとつずつ対応させておくのが理想です。

公開後は質問の増減を見直す
FAQは、公開したら終わりというわけにはいきません。サービス内容や料金、受付方法が変われば、回答もすぐに古くなります。
ページに更新日だけを表示していても、誰が何を確認するのかが決まっていなければ、中身の正しさは保てないんですよね。
少人数で運用するなら、簡単な管理表で十分です。
- 質問と回答の担当者
- 回答の根拠になる社内ルールや詳細ページ
- 最終確認日と次回の確認予定日
- 問い合わせ件数の変化
- 既存ページへ統合するか、FAQに残すかの判断
新しい問い合わせが来ても、すぐにFAQへ項目を足す必要はありません。まずは、同じ目的の質問がすでにないかを確かめましょう。
反対に、質問が減った項目があっても、それがFAQのおかげとは限りません。季節や申込数、サービス内容の変更といった別の要因も考えられます。
効果を決めつけず、問い合わせの中身とページの使われ方をあわせて見ていくのがおすすめです。
その項目を載せた理由と、どうなれば利用者の疑問が解決したと言えるのかを書き残しておくと、担当者の感覚だけで追加や削除をしてしまう状態も避けやすくなります。
FAQが向くケースと別ページが向くケース
FAQが向いているのは、短い共通の回答で次の行動がはっきりする質問です。利用前後のちょっとした補足を、ひとつの入口から探せるようにしたい場合にも使えます。
一方、全員が読むべき重要な条件や、説明が長い手順、更新のタイミングが異なる情報は、申込ページや個別の案内ページに置いた方が管理しやすいでしょう。
質問をクリックしないと見えない構成だと、大事な条件を見落とされるおそれもあります。
| 置き場所 | 向いている内容の例 |
|---|---|
| FAQ | 営業時間、持ち物、一般的な変更方法、連絡先 |
| 既存ページへ統合 | 対象者、料金、申込条件、キャンセル条件 |
| 別ページ | 詳しい操作手順、ケースごとの分岐が多い説明、長い規約 |
| 個別対応 | 本人確認が必要な内容、契約ごとに判断が変わる内容 |
この振り分けは固定ではありません。実際のページ構成や利用者の動きを見ながら、同じ説明があちこちに増えていないかを定期的に確かめてください。
まとめ
FAQページづくりは、質問の数を増やすことより、「誰が、何をしようとして、どこで止まったか」を整理するところから始まります。
問い合わせ記録から候補を集め、既存ページで直す内容、共通の回答にできる内容、個別対応に残す内容へ分けるのが先です。
最初は重要な質問を少しだけ選び、通常の見出しと短い回答で公開するのが扱いやすいでしょう。回答には条件と次の行動を添え、解決しない人のための問い合わせ先も用意しておきます。
公開後に見るべきなのは、項目の数ではありません。情報の重複や古さ、そして読んだ人が次の行動へ進めているかどうかを、定期的に見直していきましょう。

