FAQセクション：フォーマット、スキーマ、例

FAQは、ページのメインセクションでは解決されない、証拠に基づいた少数の質問に答えるクロージングコンテンツ要素です。その質問は読者の言葉を使用し、各30〜60語の回答は単独で成立します。以下の実際の要素は、このページの[[faq]]フロントマターからレンダリングされており、Markdown本文に複製されていません。

上記の表示用の質問とそのFAQPage構造化データは同一のソースを共有しています。フロントマターのエントリを編集すると両方の表現が変更されるため、洗練されたページ上の回答が機械可読バージョンから乖離するのを防ぎます。

この要素が重要な理由

読者は多くの場合、別の完全な説明を必要とするのではなく、狭い不確実性を抱えてページの終わりに到達します。購入者は製品の機能を理解していても、設定にクレジットカードが必要かどうか疑問に思うかもしれません。手順を実行している人は手順は知っていても、必要な入力が不足している場合に何が起こるかを確認する必要があるかもしれません。FAQは、すべての読者を別の長いセクションに通すことなく、これら頻度の高い後期段階の質問に予測可能な場所を提供します。

この要素が機能するのは、質問の文言が認識の手がかりとなるからです。「データをエクスポートできますか？」とスキャンしている読者は、「追加情報」のような曖昧な見出しを解釈するよりも早く自分の関心を特定できます。そして回答が即座にその懸念を解決します。これは読者の心理であり、装飾ではありません。このコンポーネントは、特定の疑問とその解決の間の距離を縮めます。

FAQはまた、機械抽出のための境界のある質問と回答のペアを作り出します。機械抽出可能性とは、ソフトウェアがユニットを分離し、完全なページの外部でもその意味を保持できることを意味します。実際の質問とそれに続く自己完結型の回答は、雑多なクロージングパラグラフに隠された回答よりも、検索システム、内部検索、サポートツール、AIエージェントにとって識別しやすいものです。この境界は、言語が明示的である場合にのみ機能します。「はい、上記の通り」は視覚的にはFAQの中にありますが、抽出されると役に立たなくなります。

フロントマターが公開ソースである理由は、同じレコードが3つの用途（表示ブロック、FAQPage構造化データ、コーパスレベルの分析）に供給されなければならないからです。コーパスレベルの分析とは、すべてのページをコレクションとしてクエリすることです。例えば、キャンセルに関するすべての回答を見つけたり、どのページタイプが定期的に6つの質問を超えるかを確認したりします。エントリを型指定された[[faq]]レコードに保持することで、これらのチェックが可能になります。質問を本文にコピーすると、2つの編集可能なバージョンが作成され、乖離を招きます。

使用するタイミング

調査によって、ページに関連するものの、完全なセクションを正当化するには狭すぎる、繰り返し発生する質問がいくつか明らかになった場合にFAQを使用します。良い候補は、エッジケース、適格性、互換性、タイミング、読者が日常的に混同する定義、購入の反論、または安全な次のアクションを明確にするものです。各質問は、同じオーディエンスがページの主要な意思決定またはタスクを完了するのに役立つものでなければなりません。

質問の調査は執筆の前に行います。検索サジェスト、内部サイト検索、サポートチケット、セールスコールのメモ、コミュニティディスカッション、追跡されたAIプロンプトから正確な言語を収集します。プロンプトトラッキング は、企業がAIエンジン全体で監視することを選択した質問を記録するため有用です。繰り返されるプロンプトは、見込み客がカテゴリ、機能、または比較についてどのように質問するかを明らかにすることができます。その記録は文言と需要の証拠であり、無関係なプロンプトをページに強制的に押し込む許可ではありません。

テンプレートが用意されているという理由だけでFAQを使用しないでください。「なぜ私たちのプラットフォームは素晴らしいのか？」のようなでっち上げの質問は、疑問符をつけたマーケティングコピーであることがわかります。「FAQスキーマのメリット？」のようなキーワードの断片は読者のように聞こえません。どちらも信頼を損ない、機械に実際の情報ニーズについてほとんど教えません。

FAQは、アウトラインに収まらなかった段落の投棄場所ではありません。回答が中核的な主張を紹介する場合、必要な手順を説明する場合、ページの最も強力な証拠を担う場合、または60語以上を必要とする場合、それは実際の作業をしており、おそらく名前付きのセクションに値します。メイン構造に移動してください。FAQはその後、残ったより小さなフォローアップ質問に答えることができます。

記事を質問形式で繰り返さないでください。「Xとは何か？」、「Xが重要な理由は？」、「Xはどのように機能するか？」は、それらがすでにページの最初の3つのセクションである場合、質の低いクロージング質問です。繰り返しはカバレッジを増やさずにページを長くし、同じ質問に対してわずかに異なる回答を生み出すリスクがあります。

よくある惜しいミスは、関連する質問だがその回答が中心的である場合です。症状タイプのページでは、「これはいつ深刻になるのか？」は自然なFAQのように見えるかもしれませんが、警告サインは安全性に影響するため、すべての読者が目にするメインボディに表示されるべきです。FAQは警告リストも弱い要約も繰り返すことはできません。代わりに、特定の状況が推奨される次のアクションを変更するかどうかなど、狭い未解決の質問を使用してください。

配置場所

FAQはクロージング要素であり、その役割はページが主要な回答を提供した後に残った質問を解決することです。実質的な本文、例、および裏付け証拠の後に配置します。FAQがそれらの情報源に依存する場合は、情報源をその直前に配置します。主要なCTA（コールトゥアクション）と関連コンテンツのリンクはその後ろに配置します。この順序により、読者は次に何をするかを決める前に最終的な不確実性を解決できます。

制作版FAQをヒーローセクションの直下、イントロダクション内、手順の間、または主張とその証拠の間に配置しないでください。この仕様の上部にある実際のブロックは、要素ライブラリに必要なデモンストレーションであり、通常のページに対する推奨される配置ではありません。

1ページに1つのFAQブロックを使用します。2つ目のアコーディオン、同じ内容を含む「よくある質問」セクション、または質問として書き換えられた要約の隣に配置してはいけません。大きな用語集リストの隣に配置することも避けてください。2つの密集した短いエントリのセットは、同じスキャン行動を競合します。両方が必要な場合は、定義を関連する本文セクションに保持し、未解決の質問のためにクロージングブロックを予約してください。

構造

ラベル付きスクリーンショットは、意味領域を視覚的処理から分離します。凡例はこのページに残り、画像がリサイズまたは置換されてもラベルが読みやすい状態を保ちます。

1. セクション見出し： コレクションを「よくある質問」として命名します。文書階層における実際の見出しです。
2. 質問： 読者の言葉を完全な疑問文として使用し、疑問符で終わります。
3. 開示コントロール： 折りたたみ可能バリアントでは、操作可能なボタンが回答が展開されているかどうかを示し、制御対象の回答領域を識別します。
4. 回答： 最初に直接的な応答を提示し、次に1つの有用な限定条件、区別、または次のアクションを提供します。
5. 項目境界： 視覚的かつプログラム的に、各質問が正確に1つの回答と関連付けられるようにします。
6. フロントマターレコード： questionとanswerをペアにする非視覚的なソースであり、表示とFAQPage出力の両方に供給されます。

デザイン例

バリアントはプレゼンテーションを変更するものであり、コンテンツの所有権は変更しません。すべてのバージョンは同じ[[faq]]レコードを読み取り、同じ質問と回答のペアを保持します。

標準レスポンシブバリアント

デスクトップでは質問と回答を整列した列で表示し、小さい画面では開示コントロールを使用して縦方向のスペースを節約します。これはデザインシステムがレスポンシブ動作を提供する場合のデフォルトです。

折りたたみモバイルバリアント

質問はボタンとして表示されたまま、回答はその場で開きます。コントロールは展開状態を伝え、キーボードアクセスを保持し、回答を読み上げ順で隣接させなければなりません。

長文質問ストレスバリアント

自然な質問が2行に折り返されることがあります。レイアウトは、切り詰めずに疑問符、コントロールターゲット、および回答の位置揃えを保持しなければなりません。

FAQなし状態

調査済みの質問がない場合は、何もレンダリングしません。空の見出し、プレースホルダー行、または汎用的な生成コンテンツを表示しないでください。

パラメータ

パラメータはコンテンツ契約です。各ペアを抽出可能に保ち、クロージング要素が第二の記事になるのを防ぐために制限が存在します。

証拠参照は公開される必要はありませんが、編集レビューに耐えられるものでなければなりません。サポートチケットID、コールノートのリンク、クエリのエクスポート、または追跡されたプロンプトレコードで十分です。「ライターが思いついた」は認められません。

構文とコード例

3つの形式すべてがFAQエントリを構造化ページメタデータとして扱います。レンダリング指示には重複した質問や回答は含まれません。

ポータブルMarkdownディレクティブ

:::faq{source="frontmatter" heading="Frequently asked questions"}
:::

ポータブルドキュメントモデルはレコードをページメタデータとして保存します：

[[faq]]
question = "Can I export the report as a CSV?"
answer = "Yes. Export creates a CSV containing the report's current dataset. Check the export scope before sharing it, because screen filters and account permissions can affect which records are included."

Hugoショートコード

{{< faq-side-by-side title="Frequently asked questions" >}}{{< /faq-side-by-side >}}

Hugoショートコードは.Page.Params.faqを読み取ります。JSONボディは受け付けません。インライン項目を追加すると第二のソースが作成されるため、この要素では禁止されています。

WordPressブロックまたはショートコード

<!-- wp:amicited/faq {"source":"post-meta","heading":"Frequently asked questions"} /-->

[amicited_faq source="post-meta" heading="Frequently asked questions"]

WordPressでは、各質問と回答は、ブロックレンダラーとJSON-LDエミッターの両方で使用される反復可能な投稿メタデータに属します。同じペアをブロックHTMLやショートコードの本文コンテンツに貼り付けても、ページが正しく見えてもパリティは失われます。

例

良い例

レポートをエクスポートした後、レポート期間を変更できますか？
はい。レポート内のレポート期間を変更し、新しいエクスポートを作成して、ファイルが修正された範囲を反映するようにしてください。既存のCSVは静的なスナップショットであり、後でダッシュボードフィルターが変更されても自動的には更新されません。

この例が機能するのは、質問がユーザーがエクスポートワークフローに遭遇した後に尋ねそうなことだからです。最初の文は「はい」と答え、アクションを述べています。2番目の文は結果の境界（以前のファイルは自動更新されない）を説明しています。30語で、回答は隠れたチュートリアルになることなく完結しています。

悪い例

レポートエクスポートCSVダウンロード？
上記の通り、当社の強力なプラットフォームはエクスポートを容易にします。利用可能なすべての素晴らしいオプションの詳細については、レポートセクションを参照してください。

質問は話し言葉ではなくキーワードの断片です。回答はエクスポートが可能かどうかを述べておらず、存在しない文脈に依存し、裏付けのないプロモーション的主張を追加し、読者を別の場所に誘導しています。言い換えだけでは不十分です。ライターは実際の質問を確認し、実際の動作を提供しなければなりません。

2つ目の悪いパターンは、前提条件、5つの手順、および警告を含む180語の回答です。たとえすべての文が正確でも、その内容は手順セクションに属します。FAQはより狭い残存質問に答えるか、削除されるべきです。

スキーママークアップとアクセシビリティ

スキーママークアップ は、ページコンテンツの意味と関係を識別する標準化された機械可読コードです。FAQエントリはSchema.orgのFAQPageにマッピングされます。表示される各質問はmainEntity内のQuestionになり、その回答はタイプAnswerとtext値を持つacceptedAnswerになります。サイトはこの構造をJSON-LD （リンク構造化データのためのJSONベースの形式）として出力します。

マークアップは表示コンテンツと意味と表現において正確に一致しなければなりません。スキーマ専用の質問を追加したり、マークアップ内でのみ表示用の回答を短縮したり、ページ編集後に古い回答をJSON-LDに残したりしないでください。フロントマターのみのルールは、両方の出力を同じレコードから派生させることでこれらの障害を防ぎます。構造化データはコンテンツを記述するものであり、薄っぺらい、でっち上げの、または隠されたコンテンツを補うものではなく、リッチ検索結果を保証するものでもありません。

アクセシビリティは開示動作に依存します。開示とは、関連コンテンツを表示または非表示にするコントロールです。質問が回答を切り替える場合は、ネイティブのbuttonであるべきで、aria-expandedで現在の状態を、aria-controlsで回答の一意のIDを指す必要があります。ARIA（Accessible Rich Internet Applications）は、ネイティブHTMLだけでは表現できない場合にステートと関係性を提供します。

キーボードユーザーはすべての質問に到達し、EnterまたはSpaceで開き、論理的な順序でページを進めることができなければなりません。フォーカスは可視である必要があります。回答は文書順で質問の後に続くべきであり、見出しはレベルを飛ばしてはいけません。シェブロンの回転、色、またはアニメーションだけを唯一の展開状態シグナルとして依存しないでください。デスクトップで回答が常に表示される場合でも、dtとddまたは同等の意味的関係を通じて質問と関連付けられたままである必要があります。

作成ルール

典型的なFAQでは4〜6の質問を使用します。4つが実用的な下限です。なぜなら、それより少ない質問で別個のクロージングインターフェースを正当化することはほとんどなく、1〜3の回答は通常関連する本文セクションの隣に配置できるからです。6つが実用的な上限です。なぜなら、より長いセットはスキャンが困難になり、主要なトピックが記事から差し控えられたことを示すことが多いからです。例外には証拠が必要です。規制された製品ではより多くの狭い適格性質問が必要になる場合があり、簡潔な製品ページではブロック全体を省略する場合があります。

すべてのエントリを読者の言葉での実際の質問として表現します。ソースからの有用な語彙は保持しますが、個人データ、アカウント固有の詳細、および会話上のノイズは削除します。回答も同じ場合にのみ、真の重複を統合します。「毎月キャンセルできますか？」と「返金は受けられますか？」は同じセールスコールで発生するかもしれませんが、異なる意思決定を表しており、統合してはいけません。

回答は30〜60語で作成します。最初の文が質問に答え、2番目の文が最も有用な条件、区別、理由、または次のアクションを詳述します。回答が抽出後も生き残るように主題を明示します。「はい、そうです」、「上記参照」、「前に説明した通り」、「詳細はお問い合わせください」を完全な回答として決して書かないでください。

落ち着いた事実に基づくトーンを使用します。回答内で必要な技術用語を定義しますが、専門用語を積み重ねないでください。リンクは、移動先が次のアクションを可能にするか、または必要な詳細を提供する場合にのみ含めます。表示される回答は、リンクをたどらなくても完結している必要があります。お客様の声、セールススローガン、無関係なキーワード、ネストされたテーブル、複数ステップの手順、または裏付けのない主張を含めないでください。

すべての投稿タイプは、FAQがカバーしなければならない意図カテゴリを宣言します。意図カテゴリとは、質問の背後にある意思決定の種類であり、キーワードテーマではありません。症状タイプのページは、原因、自己治療、深刻度、購入のカテゴリを宣言し、少なくとも1つの質問が警告サインをカバーする必要があります。警告サインは安全性に関わるため、メインボディは依然としてそれらを提示しなければなりません。FAQカテゴリチェックにより、クロージング質問が簡単な商業的トピックのみを議論しないことを保証します。

その方法を一般化し、これら4つのカテゴリをどこにでもコピーしないでください。比較では、切り替えコスト、互換性、契約、最適フィットのカテゴリが必要になる場合があります。ハウツーガイドでは、前提条件、障害復旧、完了確認、メンテナンスが必要になる場合があります。宣言されたカテゴリがページの検索意図 と実際の証拠を反映している場合にカバレッジは成功であり、すべてのページが普遍的な質問セットを繰り返す場合ではありません。

使用する投稿タイプ

postTypesフロントマターは登録された結合を記録します。以下の表は各結合をカバレッジと配置のルールに変換します。調査で有用な残存質問が見つからない場合にFAQを必須にするものではありません。

「通常あり」とは、その投稿タイプが一般的に残存質問を生み出すことを意味し、編集者がそれらを製造すべきということではありません。証拠の閾値は依然として適用されます。

QAチェックリスト

レビューアは、視覚的なスタイリングを判断する前にソースレコードをチェックします。

• 単一ソース： 表示されるすべてのペアは[[faq]]フロントマターからのものであり、質問や回答がMarkdown本文に複製されていない。
• 実際の需要： 各質問には、検索サジェスト、サイト検索、サポート、セールス、調査、または追跡されたAIプロンプトにトレース可能なソースがある。
• 自然な表現： すべての質問は読者の言語における文法上の疑問文であり、キーワードの断片や製品の主張ではない。
• 直接的な回答： 最初の文が質問を解決し、2番目の文が最も有用な限定条件またはアクションを追加する。
• 独立した意味： どの回答も「上記」、「前述」、「これ」、または他の欠落した指示対象に依存していない。
• 長さ： 各回答は30〜60語を含み、各質問は自然な文言が本当にそれ以上を必要とする場合を除き120文字未満に留める。
• 数： ブロックは通常4〜6のエントリを含み、例外には記録された理由があること。
• 置き換えられたセクションがない： メインボディに属する中核的な主張、必要な手順、主要な警告、または証拠セットを含む回答がない。
• 繰り返しがない： 質問はすでに完全に回答された見出しを言い換えておらず、回答は記事を再度要約していない。
• 宣言されたカバレッジ： セットは投稿タイプに必要な意図カテゴリをカバーしており、主題が要求する場合はリスクまたは警告カテゴリを含む。
• 正しい配置： 制作版ブロックは実質的なコンテンツと情報源の後に続き、主要なCTAと関連コンテンツの前に位置する。
• 表示とスキーマのパリティ： FAQPage.mainEntityにはレンダリングされたブロックと同じ質問と回答が含まれており、隠れたり古くなったエントリはない。
• アクセシブルなコントロール： トグルボタンは展開状態を公開し、回答IDは一意であり、キーボード操作が機能し、フォーカスは可視であり、文書順序は論理的である。
• 空の状態： 適格な質問がないページは、FAQ見出しやプレースホルダーコンテンツをレンダリングしない。
• スクリーンショットステータス： キャプチャコメントは、名前付きアセットが存在するまでコメントのままである。存在しないパスが画像としてレンダリングされることはない。

FAQ

上部の実際の例とFAQPageデータは、このページのフロントマターにある5つのレビュー済み[[faq]]レコードから生成されています。これらは、必要性、情報源、回答の長さ、独立した表現、および表示とスキーマのパリティをカバーしており、ここに2番目のコピーを保持していません。