企業サイトのFAQは、質問をたくさん並べれば便利になるわけではありません。読者が迷う点を、サービス説明で先に答えるのか、短い一問一答にするのか、個別の問い合わせで扱うのかを決めることが出発点です。答えの原資料と更新担当がない質問は、掲載後に古くなるおそれがあります。

この記事はコーポレートサイトに必要な掲載内容のうち、FAQの役割と設計を詳しく説明します。

質問候補は、実際に受けた疑問から集める

営業・問い合わせ・サポートの担当者に、繰り返し説明している内容を聞きます。問い合わせ文をそのまま公開せず、個人情報や個別案件の事情を取り除き、共通の疑問に書き直します。サイト内検索などの実データがあれば候補に加えますが、確認できない検索回数や需要を推測で付けません。

質問ごとに「読者の次の行動」「回答の正本」「主管部署」「確認日」を記録します。まず重要なサービス本文に必要な説明を追加し、FAQは補足やページ間の道案内に使います。

サービス本文・FAQ・問い合わせを分ける判断表

次の表は、小規模な企業サイトを想定して本記事で作った設計例です。実際の問い合わせを集計した結果や、SEVEN PEBBLESの案件データではありません。

疑問の種類最初に置く場所FAQに書く内容根拠と更新の責任
全員に共通するサービスの内容・手順サービスページを正本にする短い答えと該当見出しへのリンクサービス担当が仕様変更時に両方確認
条件で変わる費用・納期料金・進行の説明ページ変動する条件を示し、個別見積もりへ案内。未確定額は書かない正式な価格表・営業ルールを主管者が確認
申込期限や受付状況申込ページを正本にする最新の受付情報へリンクし、固定した古い日付を残さない受付担当が変更日に確認
個人情報や機密を含む個別相談個別の問い合わせ窓口一般的な相談方法だけ案内し、具体例を無断転記しない窓口責任者が公開範囲を判断

一問一答は短く、根拠と次の行動を明示する

質問文は利用者の言葉に近づけ、一つの質問で一つの判断に答えます。回答の最初に結論を置き、条件・例外がある場合は続けて書きます。「詳しくはこちら」だけでは行き先が分かりません。「料金が変わる条件を確認する」「導入手順を見る」のように、リンク先の意味が伝わる文言にします。W3CのWCAG解説も、リンクの目的を周辺文脈から理解できるよう求めています。

長い規約、詳細な仕様、更新頻度の高い条件をFAQだけに重複掲載すると不一致が起きやすくなります。正本のページへリンクし、FAQ側は要約と位置付けます。答えられないことは断言せず、必要な条件と相談先を明示します。

カテゴリ、開閉UI、スマートフォン表示を確認する

質問が増えたら、利用者が探す用語でカテゴリを分けます。「契約前」「利用中」「請求」など行動段階に沿う分類も候補です。開閉式にする場合は、キーボードで操作でき、開閉状態が支援技術へ伝わる実装を確認します。W3CのDisclosure Patternは、ボタンで開閉し、状態を aria-expanded で示す実装を説明しています。装飾的な開閉だけで回答が読めなくならないか、スマートフォンとキーボードで実際に確かめます。

回答の更新表を持ち、表示効果を過大評価しない

各回答に根拠となるページや社内原資料、主管者、最終確認日、変更の合図を持たせます。サービス改定、価格変更、受付停止があれば正本とFAQを一緒に確認します。日付だけを新しくして内容を放置しないようにします。

FAQの目的は、サイト内で読者の疑問に答えることです。Googleは2026年にFAQリッチリザルトの表示を終了し、関連文書も削除しました。FAQPage構造化データを付ければ検索結果で目立つ、順位が上がるといった前提で設計しないでください。

公開前チェック

参照した一次資料

資料確認日：2026年10月11日。判断表は資料を踏まえた本記事の編集上の提案です。