BLOG

FAQの作り方|5つの工程と使われないFAQに共通する3つの原因

FAQ作りで時間がかかるのは質問を集める段階ではなく、問い合わせメールの長い文面を、読者が検索窓に打つ短い言葉へ書き直す段階です。まずは問い合わせの多い20問ほどに絞り、1つの質問に条件分岐を詰め込まず、質問側を分けてください。ツールの検討はその後でも遅くありません。

長い問い合わせメールの文面が、短い質問文と回答が並んだ一覧へ整理されていく流れを、左から右へ示した構図。

「よくある質問のページなら、これまで届いた問い合わせを並べていけば形になるはず」。FAQの用意を任されて、そう考えた方は多いでしょう。問い合わせ対応を担ってきた部署には質問も回答もすでに揃っていて、あとは件数の多いものを選び、体裁を整えるだけの作業に見えるためです。

弊社はこれまで多くの企業サイトのコンテンツ制作を手がけてきました。その経験から言えるのは、FAQが使われるかどうかを分けるのは集めた問い合わせの数ではないということです。決め手になるのは質問文をどの言葉で書くかです。社内で使っている呼び方をそのまま質問文に置くと、読者が実際に検索するときの言い回しから外れ、質問の数を増やしても探している1問が見つからないままになります。

本記事では、FAQを作る5つの工程から、公開後に使われないFAQへ共通して現れる3つの原因と質問文の直し方までを、記事制作会社の視点で順を追ってお伝えします。

この記事でわかること
  • FAQとQ&Aの違いと、顧客向け・社内向け・応対担当者向けの使い分け
  • 目的の決定から公開後の見直しまで、FAQを作る5つの工程
  • 作ったのに使われないFAQへ共通して現れる3つの原因
  • 問い合わせの原文を読者の検索語へ直す、具体的な書き換え方
  • スプレッドシートからFAQシステムへ切り替える判断の目安

FAQとQ&Aの違いと3種類の使い分け

FAQは Frequently Asked Questions の略で、日本語では「よくある質問」と訳されます。頻繁に寄せられる質問と、その回答をひとまとまりにして掲載したものを指します。まず押さえておきたいのは、FAQという言葉が指す範囲は掲載する場所ではなく、質問の集まり方で決まるという点です。

FAQとQ&Aは質問の出どころが違う

Q&Aは、想定される質問と回答をひとそろい並べたもので、実際に聞かれたかどうかは問いません。商品説明の補足や、営業資料の末尾に付ける想定問答がこれにあたります。対してFAQは、実際に寄せられた問い合わせのうち件数の多いものを抜き出して構成します。

つまり、Q&Aは作り手が想定する質問、FAQは実際に届いた質問という違いになります。この区別は言葉遊びではありません。想定で作った質問は、担当者が説明したい順に並びがちです。実際に届いた質問から作れば、並び順は自動的に件数の多い順、つまり読者が知りたい順に決まります。

ただし、公開直後のサービスには過去の問い合わせが存在しません。その場合は想定問答から始めて構いませんが、公開後3か月ほどで実際の問い合わせと入れ替える前提で組んでおくとよいでしょう。

読者が誰かで3種類に分かれる

FAQは、読む人が誰かによって作り方が変わります。同じ「解約したい」という質問でも、顧客に向けるなら手続きの入口を示し、応対担当者に向けるなら例外条件や確認事項まで書く必要が出てきます。

種類

読む人

主な置き場所

効果の測り方

顧客向け

商品やサービスの利用者

自社サイトの公開ページ

問い合わせ件数、ページ内での解決率

社内向け

自社の従業員

社内ポータル、ナレッジ共有ツール

総務や情報システム部門への問い合わせ件数

応対担当者向け

窓口やコールセンターの担当者

業務システム、応対支援ツール

応対時間、担当者ごとの回答のばらつき

3種類を同じファイルで管理しようとすると、たいてい破綻します。社内向けの注意書きが顧客向けの回答に混ざったり、逆に顧客に見せられない例外条件が抜け落ちたりするためです。読者が違えば別のFAQとして分けて作るのが基本になります。

関連記事:コンテンツマーケティングの基礎知識を総まとめ|やり方から成果につなげる方法まで徹底解説

FAQを用意すると社内の何が変わるか

FAQの効果として真っ先に挙がるのは問い合わせ件数の削減ですが、実際の現場で先に効いてくるのは別のところです。減るのは問い合わせの総数というより、同じ質問が繰り返し届く分の対応時間だと考えたほうが、期待値のずれが起きません。

回答のばらつきが減る点も見落とされがちです。担当者ごとに説明の仕方が違う状態は、顧客からすると「人によって言うことが違う会社」に映ります。文章として一度確定させておけば、着任したばかりの担当者でも同じ内容を案内できるようになるでしょう。

営業時間外の自己解決が可能になる点も見逃せません。夜間や休日に生じた疑問は、翌営業日まで待てずに離脱へつながることも珍しくないためです。

そして意外に価値が大きいのが、問い合わせログの資産化でしょう。どの質問が多いかを整理する過程で、自社の説明のどこが分かりにくいかが浮かび上がります。FAQを作る作業は、副産物としてサイトや商品説明の改善点を洗い出す作業でもあるのです。

FAQを設置しただけで問い合わせが減るとは限りません。掲載した質問文が読者の言葉と噛み合っていない場合、ページは存在するのに使われず、問い合わせ件数は変わらないという結果になります。設置よりも、次章以降で扱う書き方のほうが結果を左右します。

関連記事:キャッチコピーとは?作り方の手順と名作事例に学ぶ、伝わる言葉の型

FAQの作り方5つの工程

ここからは実際の手順です。工程に分けておくと、途中で止まったときにどこへ戻ればよいかが分かります。とりわけ3つめの書き直しは、社内の方だけで進めると時間がかかりやすい工程でしょう。あらかじめ担当者と日数を確保しておくことをおすすめします。

1
STEP
目的と読者を決める

何のために作るのかを1行で書き出します。問い合わせ対応の時間を減らしたいのか、購入前の不安を解消して申し込みまで進めたいのか、社内の問い合わせを減らしたいのか。目的が違えば、載せるべき質問も変わります。購入前の不安を減らしたいのに、解約や返金の手続きばかり並んでいるFAQは目的とずれた状態でしょう。あわせて読者も決めます。既存顧客か、検討中の見込み客か、従業員か。ここが曖昧なまま進むと、後の工程で判断の基準がなくなります。

2
STEP
質問を集めて多い順に並べる

問い合わせメール、電話の応対記録、チャットの履歴、営業やカスタマーサポートの担当者への聞き取り、サイト内検索のログ。この5つが主な材料です。集めたら件数を数え、多い順に並べます。数え方は厳密でなくて構いません。同じ意味の質問をまとめて、おおよその件数が分かれば十分です。ここで全部を載せようとしないことが肝心で、最初に公開するのは上位20問から30問ほどに絞ります。件数の少ない質問まで並べると一覧が長くなり、多い質問が埋もれてしまいます。

3
STEP
質問文を読者の言葉に直す

集めた問い合わせの原文は、状況説明が長く、丁寧な言い回しに包まれています。そのままでは検索に引っかかりません。「先月から利用しているのですが、来月人数が増える予定で、その場合の料金について教えていただけますか」という原文は、「利用人数が増えたときの料金はどうなりますか」に縮めます。読者が検索窓へ打ち込む言葉に寄せるのがこの工程の目的です。社内の正式名称ではなく、顧客が普段使っている呼び方を選びます。

4
STEP
回答を作って確認を取る

回答は結論から書き始め、次に理由や条件、最後に次の行動を置きます。書き上げたら、その質問を実際に受けている部署へ確認を回します。料金や契約条件、個人情報の扱いに関わる回答は、法務や管理部門の確認も必要です。この確認工程を飛ばして公開すると、後から訂正が入り、修正履歴の管理が煩雑になります。確認の依頼は質問ごとにばらばらに送らず、部署単位でまとめて送るほうが早く戻ります。

5
STEP
公開して検索された言葉を見る

公開したら終わりではありません。サイト内検索を設置しているなら、検索されたのに結果が0件だった言葉を定期的に確認します。そこには、読者が使っている言葉と、掲載している質問文とのずれが直接表れるでしょう。あわせて、公開後も届き続けている問い合わせの内容を見ます。掲載済みの質問が届いているなら見つけられていない証拠であり、掲載していない質問が届いているなら追加すべき候補です。

FAQを作る5つの工程の流れ図

5つめから2つめへ戻る流れがあることに注目してください。FAQは一度作って完成する制作物ではなく、公開後の問い合わせを材料に更新し続ける前提で設計するものです。更新の担当者と頻度を決めないまま公開したFAQは、半年もすると実態と合わなくなります。

関連記事:コンテンツ制作とは?目的や種類、効果的な作り方とポイントを徹底解説

使われないFAQに共通する3つの原因

ここまでの工程どおりに作っても、公開後に「結局、問い合わせが減らない」という相談は届きます。数多くの企業サイトの原稿を扱ってきた立場から言えば、その原因は驚くほど似た3つのパターンに収まります。

Web担当者Web担当者

問い合わせの多い質問はひととおり載せたつもりです。それでも同じ質問が届くのは、単に見つけてもらえていないだけでしょうか。

Writers-hub編集部Writers-hub
編集部

見つけられていないのは確かですが、原因は置き場所より質問文の言葉にあることが多いです。担当者が書いた質問文は社内の呼び方に寄りやすく、利用者が打ち込む言葉と重なりません。まずは実際に検索されている言葉と、掲載している質問文を並べてみてください。

以下の3つは、どれも「回答の内容が間違っている」わけではない点が共通しています。内容は正しいのに読者に届いていない、という状態です。

社内の言葉のまま載せた質問文

最も多い原因です。問い合わせ対応の担当者が質問文を書くと、日頃使っている社内の呼び方がそのまま出てきます。次のような表現に心当たりがあれば、書き換えの対象になります。

  • 各種お手続きの流れについて
  • ご利用規約の改定に関するご案内
  • サービス仕様に関するよくあるお問い合わせ
  • プラン変更に伴う契約内容の改定について

これらに共通するのは、名詞を並べた表題になっていて、質問の形をしていない点です。読者は「〜について」とは検索しません。実際に打ち込むのは、動詞を含んだ短い言葉です。

  • 解約したいときはどうすればよいですか
  • 領収書はどこからダウンロードできますか
  • 支払い方法をあとから変更できますか
  • 利用人数が増えたときの料金はどうなりますか

書き換えの目安として、質問文は主語を読者に置き、20文字から30文字程度に収めます。長い質問文は一覧で読み飛ばされ、短すぎる質問文は複数の意味に取られます。

1つの回答に詰め込まれた条件分岐

2つめの原因は、質問を1つにまとめすぎることです。たとえば「解約したい」という質問を1問で処理しようとすると、回答の中にWebからの手続き、電話での手続き、法人契約の場合、無料期間中の場合と、条件分岐が並びます。読者はその中から自分に当てはまる行を探す作業を強いられます。

対処は単純で、条件分岐は回答に書かず、質問の側で分けます。「Webから解約する方法」「電話で解約する方法」のように、分岐を質問文へ持ち上げるわけです。

ただし、何でも分ければよいわけではありません。分ける軸には条件があります。読者が自分で判断できる条件、つまり契約の種類や利用している端末なら分けて問題ありませんが、システムの内部状態のように読者側から分からない条件で分けると、どちらを選べばよいか判断できなくなります。この線引きが、一覧を膨らませずに分岐を解消する要点です。

条件分岐を回答から質問へ移す前後の構造比較図

次の行動が書かれていない回答文

3つめは回答の終わり方です。「詳しくはお問い合わせください」で締めくくると、せっかく読んでもらったのに問い合わせへ戻してしまいます。FAQを読んでいる読者は、まさに問い合わせを避けようとしている人たちです。

回答の最後には、次にとるべき行動をひとつだけ置きます。手続きページへのリンク、必要な書類の名前、電話の受付時間のいずれかです。複数の行動を並べると、また選ぶ作業が発生してしまいます。ひとつに絞ることが、読者の手間を最も減らします。

問い合わせログは手元にあるのに、質問文へ直すところで止まっていませんか

問い合わせの原文を読者の言葉へ書き換える作業は、自社の担当者ほど難しくなります。社内の用語に慣れているぶん、どこが専門的なのか気づきにくいためです。弊社では、問い合わせ履歴をお預かりして質問文と回答文の原稿を組み立て、公開後の更新まで含めた制作体制づくりをお手伝いしています。

読者の言葉に直す質問文と回答文の書き方

前章で挙げた3つの原因は、どれも書き方で解消できます。ここでは質問文と回答文それぞれについて、実際の手を動かす部分を具体化します。

質問文は一問一答にして主語を読者へ置く

質問文を書くときの基本は、1つの質問に1つの答えが対応する状態を保つことです。「料金と支払い方法について」のように2つの論点が入った質問文は、回答も2つに分かれ、読者はどちらかを読み飛ばします。

主語を読者へ置く、という点も効果があります。「弊社の返品規定について」ではなく「購入した商品を返品できますか」と書けば、読者は自分ごととして受け取りやすくなるはずです。丁寧さを意識するあまり「〜についてご案内いたします」と書き足すと、検索語から遠ざかるため削ります。

表記のゆれも見ておきたい点です。読者が「解約」と検索するか「退会」と検索するかは、サービスによって分かれます。両方の言葉が使われているなら、質問文に片方を、回答本文にもう片方を入れておくと、どちらの検索語でも拾える状態になります。

回答文は結論から始めて1画面で読み切れる長さにする

回答の書き出しは、実はそれほど種類がありません。回答の書き出しは、できます、できません、条件によりますの3つに整理できます。この3つのどれかを最初の1文で言い切ってから、理由や手順を続けます。

💡

「マイページから変更できます」「原則として返金には応じかねます」「ご契約プランによって異なります」。冒頭の1文でこう言い切ってしまうと、読者は残りを読むかどうかを自分で判断できます。逆に前置きから入る回答は、結論まで読まないと自分に関係があるか分かりません。

長さの目安は、スマートフォンで1画面から2画面です。文字数にすると200文字から400文字程度に収まります。それ以上の説明が必要な質問は、回答内にすべてを書かず、詳しい解説ページへ誘導する形へ切り替えたほうが読みやすくなるでしょう。

専門用語をどう扱うかも判断が要ります。社内の正式名称をすべて排除すると、かえって正確性を欠く場合があるためです。実務では、質問文には読者の言葉を、回答本文の初出で正式名称を括弧書きで添える形が扱いやすいと感じています。

回答文を書き終えたら確認する4点
  • 最初の1文で、できるかできないかを言い切っているか
  • 条件分岐が3つ以上並んでいないか(並んでいれば質問を分ける)
  • 最後に次の行動がひとつだけ示されているか
  • その質問に関わる部署の確認が済んでいるか

FAQの管理方法3つの比較と選ぶ順番

質問文と回答文が固まったら、どこで管理するかを決めます。ここで先にツールを選んでしまう例をよく見かけますが、順番としては中身が先です。管理方法は、質問の数と更新の頻度が見えてから決めても遅くありません。

スプレッドシートやExcelサイトのCMSページFAQシステム
初期費用ほぼ不要既存サイトがあれば不要月額または初期費用が発生
公開までの早さ
読者側の検索性×(社内管理用)
更新のしやすさ
分析機能×
向いている質問数〜50問〜100問100問以上

最初の1つとしてスプレッドシートをおすすめするのは、機能が優れているからではありません。質問文と回答文を作る段階では、並べ替え、統合、削除を何度も繰り返します。その作業に最も向いているのが表計算ソフトだからです。確定した内容をCMSのページへ書き出す、という順番が結果的に早く進みます。

では、FAQシステムへ切り替える判断はいつか。目安は3つあります。掲載する質問が100問を超えたとき、更新を複数部署で分担するようになったとき、そして「どの質問がよく読まれ、どこで解決できずに離脱したか」を数字で追う必要が出てきたときです。この3つのいずれにも当てはまらない段階では、システムの導入費用に見合う効果が出にくいと考えています。

FAQページに期待できるSEO効果の範囲

FAQには検索対策の効果があると説明されることが多く、実際に効果もあります。ただし、期待できる範囲は数年前から変わっているため、そこは正確に押さえておきたいところです。

かつては、FAQPageという構造化データを設置すると、検索結果に質問と回答が折りたたみ形式で表示される仕組みがありました。しかしGoogleは2023年8月に方針を変更し、この表示の対象を政府機関や医療分野など一部の信頼性の高いサイトに限定しています。一般の企業サイトでは、構造化データを設置しても検索結果の見た目が変わることは期待しにくくなりました。

HowTo 和常见问题解答富媒体搜索结果方面的变化 | Google Search Central Blog | Google for Developers
🌐 developers.google.com
外部リンク

※ Google検索セントラルブログ「Changes to HowTo and FAQ rich results」(2023年8月8日公開)に基づく

とはいえ、FAQページ自体の検索価値がなくなったわけではありません。むしろ、残っている効果のほうが流入に直結します。FAQに載っている質問文は、読者が実際に検索する言葉とほぼ一致するためです。「サービス名 解約 方法」「商品名 送料」のように具体的な語を組み合わせた検索に対して、FAQページは1問1答という形で直接の答えを持っています。1件あたりの検索数は小さくとも、そうした組み合わせを1ページで数十通り拾える点が、記事コンテンツにはない特徴でしょう。

構造化データについても、設置する意味がなくなったとは考えていません。検索エンジンがページの構造を理解する助けにはなりますし、生成AIによる検索結果でも、質問と回答が明確に区切られた文章は引用されやすい形をしています。表示上の見返りを主目的にせず、内容が正しく読み取られるための整備として捉えるのが実態に合っています。

Latest Google Search Documentation Updates | Google Search Central | What's new | Google for Developers
Learn about the latest and most recent Google Search Central documentation updates. Stay current with what's new at Google Search Central.
🌐 developers.google.com
外部リンク

構造化データを追加する場合は、ページ上に実際に表示されている質問と回答だけを記述します。表示していない内容をデータにだけ書く形は、Googleのガイドラインで認められていません。

FAQで拾える検索語を、記事側とどう分担するか決まっていますか

FAQで受けるべき質問と、解説記事として厚く書くべきテーマは分けて設計する必要があります。同じ内容を両方に置くと、どちらも中途半端になりやすいためです。弊社では、検索されている言葉を整理したうえで、FAQと記事の役割分担から検索対策を設計しています。

公開後に続ける見直しの進め方

FAQは公開してからのほうが作業量は少なく済みますが、頻度を決めておかないと止まります。実務では、月に1回、30分ほど見る時間を確保しておく形が続きやすいと感じています。

見る項目は3つです。1つめは、サイト内検索で結果が0件だった検索語。読者の言葉と質問文がずれている箇所が、ここに直接表れます。2つめは、公開後も届き続けている問い合わせ。掲載済みの質問が届くなら見つけられていない状態であり、未掲載の質問が届くなら追加の候補です。3つめは、料金改定や仕様変更があった月に、その影響を受けるFAQを洗い出す作業になります。

各FAQに更新日を表示しておくと、読者が情報の新しさを判断できるだけでなく、社内でも「1年以上触っていない質問」を機械的に洗い出せます。更新日の表示は、運用を続けるための仕掛けとしても働きます。

FAQ公開後の見直しサイクル図

FAQの作り方についてよくある質問

最後に、FAQの制作をお手伝いする中で実際に受けることの多い質問を挙げておきます。件数や並び順のように、明確な正解がないぶん迷いやすい部分をまとめました。

FAQは何問くらいから公開すればよいですか?

20問から30問で十分です。件数の少ない質問まで並べると一覧が長くなり、問い合わせの多い質問が埋もれてしまいます。公開後に届いた問い合わせを見ながら追加していく形が現実的です。

質問の並び順はどう決めればよいですか?

問い合わせ件数の多い順が基本です。ただし購入前の不安解消が目的なら、料金や申し込み手順を先に置く並べ方もあります。目的によって並び順は変わります。

FAQと問い合わせフォームはどちらを目立たせるべきですか?

FAQを先に置き、その下に問い合わせの入口を置く配置が扱いやすいです。FAQを飛ばして問い合わせへ進む読者もいますが、入口を隠すと不信感につながるため、隠さずに順番で誘導します。

FAQの原稿は誰が書くのが適切ですか?

質問の材料は問い合わせ対応の担当者が持っていますが、読者の言葉へ書き換える作業は書き慣れた人が担当したほうが早く進みます。材料の提供と文章化を分担する形が現実的です。

社内向けFAQも同じ作り方でよいですか?

工程は同じですが、検索する言葉が違います。社内では正式な業務名称で検索されることが多いため、質問文に業務名称と通称の両方を入れておくと見つけやすくなります。

まとめ|FAQは集める作業より読者の言葉に直す作業

FAQの作り方を、5つの工程と、使われないFAQに共通する3つの原因という2つの角度から見てきました。工程としては、目的と読者を決め、質問を集めて多い順に並べ、質問文を読者の言葉へ直し、回答を作って確認を取り、公開後に検索された言葉を見る、という流れです。

改めて要点を挙げるなら、FAQの品質は、集めた数ではなく質問文の言葉で決まります。問い合わせの原文をそのまま載せず、読者が検索窓に打ち込む短い言葉へ書き直す。条件分岐は回答へ詰め込まず、質問の側で分ける。回答の最後には次の行動をひとつだけ置く。この3点を守るだけで、同じ材料から作ったFAQでも使われ方が変わってきます。

私たち合同会社Writers-hubは、企業サイトのコンテンツ制作を専門に手がけています。問い合わせ履歴から質問文と回答文を組み立てる作業も、記事制作と同じく「読者の言葉を探して書く」仕事です。社内の言葉から離れた原稿づくりに手が回らないときは、制作体制の設計からご相談いただけます。

FAQを作り切ったあと、更新を続ける担当と手順は決まっていますか

FAQは公開後の更新まで含めて設計しないと、半年ほどで実態と合わなくなります。原稿の制作だけでなく、誰が何を見て更新するかという運用の形まで含めて、コンテンツ制作の支援を行っています。まずは現在の問い合わせ状況をお聞かせください。

この記事を書いた人

米山拓真

米山拓真

合同会社Writers-hub 代表社員

滋賀県立大学工学研究科の修士課程を修了後、大手制作会社の編集部を経て2019年にWebライターとして独立。2020年に記事制作を手順化した「ハブ式SEOライティングメソッド」を開発し、これまでに200人以上のライターを育成しました。2022年3月に合同会社Writers-hubを設立し、会社として累計8,000記事以上のSEO記事制作に携わっています。2024年にAIライティングシステム「一気通貫Pro」、2025年から書き手の文体を再現するAI編集者「Edico」を開発。このブログでは、クライアント案件と自社サイトで実際に試したことを書いています。

読んで終わりにしないために

記事の内容を自社に当てはめるとどうなるか、オンライン30分で一緒に整理します。費用はかかりません。

無料で相談する