FAQページの作り方｜
質問を並べるだけで、問い合わせ前の不安は減る？

第1話｜FAQは、何のためにつくる？

くるる

「FAQをたくさん載せれば、問い合わせ前の不安はなくなるかな？」

まなボット

「まず、どんな人が何を決めるために読むのかを考えよう。初めて依頼する人と、契約中の人では、必要な答えが違うよ」

たとえば初めて制作を依頼する担当者なら、「原稿がなくても相談できるか」「見積もり前に何を準備するか」が気になるかもしれません。契約中なら、変更依頼の窓口や確認手順が必要です。両方を混ぜる場合は、対象が分かる分類にします。

くるる

「問い合わせを減らすことが目的じゃないんだね」

まなボット

「繰り返しの説明を減らしたい場合もあるけれど、個別に聞くべきことまで聞けなくしたら困る。自分で解決できることと、相談が必要なことを見分けられるようにしよう」

FAQの役割は、読み手に判断材料を渡すこと。一般的な説明で解決できればそれでよく、条件が違えば相談へ進める状態を目指します。「質問を何件載せるか」より先に、対象読者と、読み終えた後に選べる行動を書き出してください。

第2話｜質問は、競合サイトから集めればよい？

くるる

「他社のFAQを参考にして、同じ質問を並べようかな」

まなボット

「抜けを考える参考にはなるけれど、自社で実際に迷われていることから始めたいね。営業や受付の人に、説明を繰り返している場面を聞いてみよう」

材料は、問い合わせメール、商談メモ、受付で聞かれたこと、サイト内検索などです。利用する権限のある記録だけを確認し、公開原稿には顧客名や個別事情を持ち込まないようにします。質問台帳にも不要な個人情報を転記せず、元の記録の参照先はアクセス権を管理してください。

質問を拾うときは、元の言葉と背景を分けて記録します。「いくらですか？」という質問の裏にも、総額を知りたい、追加費用が心配、社内の予算申請に使いたい、という違いがあります。聞かれた文だけを短くすると、この違いが消えてしまいます。

くるる

「まだ問い合わせが少ない会社は、どうする？」

まなボット

「想定する質問を置いてもよいけれど、実際によく聞かれた質問と区別して管理しよう。『ご相談前の確認事項』という見出しも使えるね」

質問台帳には「読者の言葉／迷っている場面／根拠となる記録／確認する部署」を残します。社内用語の「支給素材について」を、そのまま見出しにするより、「写真や原稿がまだなくても相談できますか？」の方が、自分の疑問を探しやすくなります。

第3話｜集めた質問は、全部載せる？

くるる

「候補がいっぱいになったよ。多いほど親切？」

まなボット

「探す負担も増えるから、先に答えるべき質問を選ぼう。繰り返し聞かれるかに加えて、分からないと判断を止めてしまうかを見たいね」

頻度が高い質問は優先候補ですが、頻度だけで決めません。対象外となる条件、申し込み前に必ず知ってほしい制約などは、聞かれる回数が少なくても重要です。反対に、特定の一社だけに当てはまる話を、一般的な約束として載せるのは避けます。

分類は、社内の部署順より読者の検討順を基本にします。「依頼できる内容」「費用・見積もり」「準備・進め方」「公開後の対応」など、自社のサービスに合う区切りを考えましょう。商品購入者向けの配送・返品FAQとは混ぜず、必要なら別の案内へつなぎます。

くるる

「似ている質問は、まとめていい？」

まなボット

「答えが同じならまとめられる。でも『納期はいつ？』と『急ぎでも頼める？』は、通常の流れと例外対応で答えが違うかもしれないよ」

一覧を見て、同じ回答に言い換えだけの質問が並んでいないか、逆に一つの質問に違う論点を詰め込んでいないかを確認します。最初から網羅を目指さず、根拠を確認できる重要な質問から公開する方法もあります。

第4話｜「柔軟に対応します」で、安心できる？

くるる

「回答は『柔軟に対応します。お気軽にご相談ください』でいいかな？」

まなボット

「相談してよいことは伝わるね。でも、何が分かれば相談できるかも書きたい。結論、条件、例外、次の行動の順で整理してみよう」

次は、回答の組み立て方を示す仮例です。自社の対応条件として、そのまま転用しないでください。

質問の仮例：原稿がまだなくても、Web制作を相談できますか？

• 結論：原稿が完成していない段階でも相談できます。
• 条件：原稿作成を依頼する場合は、取材の有無、作成範囲、確認担当を打ち合わせで決めます。
• 例外：専門的な内容や制度・商品仕様は、依頼側で事実確認が必要です。原稿制作を含むかどうかで見積もりや進行が変わります。
• 次の行動：現在のサイト、手元の資料、伝えたい相手、希望時期を分かる範囲でお知らせください。

くるる

「できることだけでなく、依頼側が確認することも分かるね」

まなボット

「そう。『すべて対応』『必ず間に合う』のような広すぎる表現は、実際の運用と合っているか確認しよう」

料金を一律に答えられない場合も、「案件によります」だけで終わらせず、何によって変わるか、見積もりに必要な情報、含まれる範囲を説明します。未確定の料金や返信時間を、安心させるために作らないこと。条件が多いなら概要をFAQに置き、詳細な料金・契約案内へリンクします。

第5話｜FAQ一覧があれば、ほかのページには不要？

くるる

「回答を全部FAQページにまとめたよ。これで見つけてもらえる？」

まなボット

「サービスを読んで迷った人が、わざわざ一覧へ移動するとは限らないよ。疑問が生まれる場所にも、必要な答えを置こう」

サービス内容の近くには対応範囲の質問、料金の近くには見積もりに含むもの、相談ボタンの近くには事前準備や相談後の流れを置く、といった考え方です。FAQ一覧は全体を探す入口にして、個別ページではその場の疑問に絞ります。

くるる

「同じ回答を何か所にも書くと、修正が大変そう」

まなボット

「その通り。管理する元の回答を決めて、どこへ掲載したかを記録しよう。共通部品で更新できるか、要約から詳細へリンクするかは、サイトの仕組みに合わせるんだ」

条件の一部だけを省略した短文が、詳細ページと矛盾しないことも重要です。たとえば「対応できます」の直後に、対象となる条件を添えます。質問ごとのリンク先を用意する場合は、移動後に目的の回答が見えるかも確認しましょう。

フォームの入力やエラーの直し方は、問い合わせフォーム改善の記事で扱っています。FAQでは、その一歩手前の「相談するかどうかを判断する情報」を整えます。

第6話｜開閉式にすれば、見やすくなる？

くるる

「長くなるから、全部アコーディオンにしよう！」

まなボット

「一覧は短く見えるけれど、開かないと答えが分からない。重要な条件や短い説明は、最初から見せる方法も比べよう」

開閉式を採用するなら、質問が操作できると分かる見た目にし、開いている状態も伝えます。スマートフォンで文字を拡大したときに、質問や回答が欠けないか。回答のリンクが押せるか。開閉後に今見ている位置を見失わないかを確認します。

実装担当には、キーボードだけでも質問へ移動し、回答を開閉できるかを確認してもらいます。W3Cのアコーディオン設計例では、見出し内のボタン、開閉状態を伝えるaria-expanded、回答領域との関連付け、Enter／Spaceでの開閉、Tab／Shift＋Tabでの移動が示されています。W3C WAI：Accordion Pattern

くるる

「見た目が動けば、完成ではないんだね」

まなボット

「読み上げで質問と状態が伝わるかも大事。この項目を確かめただけで、サイト全体のアクセシビリティに適合したと断定はできないけれど、具体的な確認になるよ」

自社で使っているCMSや部品で何ができるかを確認し、見た目だけを理由に複雑な仕組みを増やさないようにしましょう。

第7話｜回答の最後は、全部「お問い合わせください」？

くるる

「詳しいことは問い合わせてもらえば、間違いがなくて安心かな」

まなボット

「毎回答えを読んでも分からないと、FAQを置く意味が薄くなるね。一般的に答えられる範囲は書いたうえで、個別確認が必要な場合を案内しよう」

回答の出口には、関連する詳しい説明、準備に使える資料、個別相談の窓口などがあります。すべての回答へ同じ大きなボタンを置くより、その疑問の次に必要な行動を選びます。読んで解決した人に、問い合わせを強制する必要はありません。

個別相談へつなぐ場合は、「何を伝えると判断しやすいか」を添えます。希望する内容、対象のページ、希望時期など、回答に必要な範囲に絞って案内してください。機密情報や個人情報を、公開欄へ書くよう促さないことも大切です。

くるる

「『FAQを読んでからでないと問い合わせできません』は、避けたいね」

まなボット

「そう。自分の状況に当てはまらない人が相談できる出口は残そう。窓口の名称も、リンク先でできることとそろえよう」

ボタン周辺の短い言葉を検討するときは、マイクロコピー入門も参考になります。ただし、返信期限や無料の範囲などは、実際の対応と一致する内容だけを掲載します。

第8話｜公開したら、次はいつ直す？

くるる

「FAQが完成した！しばらく触らなくても大丈夫？」

まなボット

「料金や対応範囲が変わったら、古い回答が誤解につながるよ。公開前に、誰が何をきっかけに見直すかまで決めよう」

質問台帳へ、回答の確認担当、根拠となる社内資料、掲載先、確認日、次の確認予定を加えます。営業担当が文章を作り、サービス責任者が条件を確認し、Web担当が反映するなら、その分担を残します。一人で兼任する場合でも、確認する内容は分けて考えます。

定期点検に加え、料金改定、提供範囲の変更、受付方法の変更、同じ誤解による問い合わせの発生を更新のきっかけにします。変更時はFAQ一覧だけでなく、サービスページの要約や案内資料にも同じ説明が残っていないか確認します。

くるる

「更新日だけ新しくしておけば、古く見えない？」

まなボット

「内容を確かめた記録が大事だよ。日付だけ変えても、答えは正しくならないからね」

Googleも、検索向けに見せるためだけの日付更新や、量を増やすことより、人に役立つ内容を重視する観点を示しています。Google：有用で信頼性の高いコンテンツの作成

担当者が不在のときの確認先も決めておくと、直したいのに誰も判断できない状態を避けやすくなります。

第9話｜FAQの効果は、閲覧数で分かる？

くるる

「たくさん開かれた質問が、よいFAQってこと？」

まなボット

「関心が高い可能性はあるけれど、説明が分からなくて何度も開いているのかもしれないね。数字と問い合わせ内容を合わせて見よう」

確認するのは、FAQへの到達、回答の利用、関連ページや相談窓口への移動、実際に届く問い合わせの内容です。開閉回数は理解した人数ではありません。問い合わせの減少も、自己解決が増えた場合と、相談しにくくなった場合の両方が考えられます。

同じ質問が続くなら、回答が見つからないのか、条件が曖昧なのかを受付担当と確かめます。公開前後を比較するときは、期間、流入元、閲覧端末、サービス変更などの違いも記録し、少ない件数から改善率を断定しないようにしましょう。

くるる

「公開前の動作テストで、相談ボタンを押した分は？」

まなボット

「実際の相談成果とは分ける。クリックしただけなのか、受付が成立したのかも区別しよう。計測の確認ができたことを、問い合わせが増えた実績にはしないよ」

FAQの質問数や構造化データを増やせば、検索順位やクリック率が上がるとは断定できません。2026年10月確認時点で、GoogleのFAQリッチリザルトは提供を終了しています。公式更新履歴では、2026年5月7日から非表示になり、6月15日に関連文書を削除したことが確認できます。Google Search Central：公式更新履歴

検索結果で目立たせるためだけに質問を増やすのではなく、読者が自分の条件を確かめ、必要な行動を選べる回答になっているかを見直しましょう。

まとめ｜まず、一つの質問を「判断できる答え」にする

くるる

「質問を増やす前に、今ある回答を見直せそう！」

まなボット

「まずは繰り返し聞かれる質問を一つ選ぼう。誰がどんな場面で迷うのか、回答の条件は正しいか、どこへ置けば見つかるか。その順で確認すると進めやすいよ」

最初の打ち合わせには、現在のサイトURL、よく聞かれる質問、回答の根拠になる資料、社内の確認担当を持ち寄ってください。質問の整理、原稿づくり、ページへの配置、開閉式の実装、計測、公開後の更新をどこまで依頼するかも分けておきます。

MADE IN CREWでは、Web・LP制作において、商談時の質問や問い合わせ前の不安を整理し、原稿・情報設計・導線を検討しています。FAQだけを追加するか、サービス説明から見直すか迷う段階でも、現在のページと困っていることからご相談ください。