ユーザーはFAQを「読み込んでいる」！2026年に仕込むべき、アコーディオンに隠さないFAQ設計と実装術

スマホで縦が足りないから、FAQ はアコーディオンで畳む。制作の現場では、まだこの判断が既定になりがちです。ところが問い合わせや申し込みの直前に、人がいちばん読むのも同じ FAQ です。畳んであると、答えにたどり着くまでにタップが入り、途中で離れます。

2026年に強いのは、魔法の UI ではなく、最初から読める FAQ です。カテゴリと見出しでスキャンでき、ページ内検索でも拾え、HTML 上の文が JSON-LD と同じである。人の不安を先に解消することと、機械が本文を取り違えないことは、別施策に見えつつ同じ仕込みです。CVR も AI の引用も「必ず上がる」とは言いません。摩擦と取り違えが減る、という設計です。

この記事では、フリーランスのWebディレクター兼エンジニアとして、情報設計とフロント実装を見てきた立場から、隠さない FAQ の理由と職種別の入れ方を整理します。確認できない改善率や、特定の生成 AI に選ばれた、という話は出しません。

なぜ「畳まない FAQ」が強いか

1. 検討が深い人ほど、探す手間を嫌がる

料金、納期、対象外、解約。ここを知りたい人は、すでに比較の終盤です。質問一覧が閉じていると、自分の項目を探す作業が先に来ます。一目で見出しが並び、答えがその下にある方が、不安の解消は速いです。省スペースは、精読してほしいブロックでは優先度を下げてよい、という判断です。

2. ページ内検索（Cmd+F / Ctrl+F）

display: none や、閉じたまま中身を隠す実装では、ブラウザのページ内検索がヒットしないことがあります。「書いてあるのに見つからない」は、情報がないのと同じに見えます。初期からテキストが見えている（または hidden に頼らない）と、検索はそのまま使えます。アコーディオンでも、閉じた <details> の扱いはブラウザで差があるので、検索できることを前提にしない方が安全です。

3. マシンリーダビリティと AI 検索

クローラが読むのは、多くの場合、最初に返る HTML です。クリック後にだけ fetch する答えは、人にも機械にも遅れます。初期 HTML に答えがあるアコーディオンは、機械には見えることがあります。弱いのは「機械が絶対読めない」ことより、人が開かない・検索できない・JSON-LD と本文が違うことです。GEO / LLMO は公式指標ではありません。やることは、見出し付きの本文と、同じ文の FAQPage です。

畳んだ FAQ と、開いてスキャンできる FAQ

悪い例：全部閉じて、開かないと読めない

質問が10個、全部閉じている。スマホで2つ開いて、目的の項目が下にあり、戻ると前が閉じる。途中でフォームに戻らず離脱する型です。答えが短いのも、アコーディオン前提で「中を増やしたくない」から、条件が書けていないことが多いです。

良い例：カテゴリと見出しで、スクロールだけで追える

料金・範囲・契約・サポートのように塊を分け、各質問を h3 にする。ページ内の目次からアンカーで飛ぶ。本文は最初から開いている。JSON-LD の Question / Answer は、画面の文と揃える。件数の保証はありませんが、同じ流入でも「答えを探す作業」が減る構造です。

【職種別】工程で仕込むこと

Webディレクター / UXライター

一問一答の羅列より、購買の壁に沿った分類です。料金（税、見積もりの出し方）、仕様（何をする / しない）、契約（期間、著作権）、サポート（窓口、営業時間）。抽象的な「柔軟に対応」は、比較の終盤では不安を残します。数字や条件は、確認できるものだけ書く。無いものは書かない。

ミニ事例です。アコーディオンに収めるため、回答を1行にしたページは、電話で同じ質問が繰り返されます。カテゴリ見出しの下に、条件まで書いた開いた FAQ は、フォーム前の自己解決が増えやすいです。削減件数はサイト次第です。測るなら、FAQ 経由のスクロールと送信を分けて見てください。

UI/UXデザイナー

開いたままでも圧迫しないよう、質問は太く、回答は一段落と余白でコントラストを付けます。長い場合は、左または上部に目次（ページ内リンク）を置き、スムーズスクロールは見出しの高さ分オフセットする。カード型にするなら、閉じる操作を足さず、塊の境界だけ視覚化する。トグルを開くまで回答の長さが分からない、は精読の敵です。

フロントエンドエンジニア / コーダー

セマンティクスは、section + 見出し、または dl / dt / dd で十分です。見た目のために全部 div にしない。初期表示を display: none にしない。開閉が必要でも、答えは最初から DOM に置き、CSS で畳むならページ内検索とスクリーンリーダーの影響を実機で見る。

JSON-LD の FAQPage は、画面に無い質問を足す場所ではありません。

<section id="faq" aria-labelledby="faq-title">
  <h2 id="faq-title">よくある質問</h2>
  <nav aria-label="FAQの目次">
    <ol>
      <li><a href="#faq-price">見積もりに何が必要ですか？</a></li>
      <li><a href="#faq-scope">対応できないことはありますか？</a></li>
    </ol>
  </nav>

  <h3 id="faq-price">見積もりに何が必要ですか？</h3>
  <p>現状サイトの URL、希望公開時期、必須のページ数を共有ください。未確定でも構いません。</p>

  <h3 id="faq-scope">対応できないことはありますか？</h3>
  <p>広告運用の代行と、確認できない実績数値の作成は行いません。</p>
</section>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "見積もりに何が必要ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "現状サイトの URL、希望公開時期、必須のページ数を共有ください。未確定でも構いません。"
      }
    },
    {
      "@type": "Question",
      "name": "対応できないことはありますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "広告運用の代行と、確認できない実績数値の作成は行いません。"
      }
    }
  ]
}
</script>

ミニ事例です。開閉のたびに答えを API から取る実装は、表示も機械の取得も不安定です。HTML と JSON-LD を同じ文にしたページは、更新が1箇所に見えます。速度は、アコーディオン用 JS を減らした方が取りやすいことが多いです。

クライアントへ先に伝えること

「長いと見づらい」には、目次とカテゴリでスキャンさせる、と返します。全部をトップに置く必要はなく、サービスページの判断直前に、そのサービスの FAQ を開いて置く方が効きます。運用では、実際の問い合わせ文を月1で1問足す。サポートの繰り返しと、検索・引用の材料が同じ文になります。診断商品である必要はありません。

2026年版 FAQ設計＆実装チェックシート

まとめ：FAQ は補足ではなく、判断の本文である

アコーディオンは、設定画面や履歴のように「今は見なくてよいもの」向きです。申し込み直前の不安解消は、隠さず、見出しで辿れる方が向きます。人のタップを減らし、検索でき、機械には初期 HTML と一致した構造化データを渡す。それが 2026年に仕込む FAQ です。

既存ページなら、いま閉じている質問を一度全部開いて、目次だけで辿れるか見てください。導線と FAQ の見直しは、相談・お問い合わせからどうぞ。