FAQハブページ:構造と例
実際の顧客の質問からFAQハブページを構築し、カニバリゼーションを防ぎ、回答を明確に整理し、SEOのために適切な可視のFAQPageスキーマを安全に使用する方法。
FAQハブページは、1つの限定されたトピックに関する繰り返しの質問を、単一のナビゲート可能な目的地に統合します。これは、何を尋ねたいかをすでに知っている読者のために構築されています。読者は自分の言葉を認識し、正しい回答に素早く到達し、質問がFAQの回答よりも大きい場合は、より詳細な正規ページに進むことができる必要があります。
ハブは、チームが思いつくあらゆる質問を詰め込むためのコンテナではありません。その役割は、より強力な定義、ガイド、またはトラブルシューティングコンテンツと競合する新しいページを作成することなく、繰り返し発生するサポートと評価の作業を削減することです。 SEO投稿タイプシステム内では、これは検討段階のサポートフォーマットです。関連する質問を収集するのに十分な広さを持ちながら、各重要なインテントが依然として1つの所有者を持つように十分に規律があります。
読者の質問:「このトピックに関するよくある質問の明確な回答は、いくつかの無関係なページを検索しなくても、どこで得られますか?」
編集ルール: 小さな質問はここで回答し、大きな質問はそれを所有するページにルーティングします。
回答する質問
効果的なハブは、読者が決定、設定、購入、訪問、またはエスカレーションする前に繰り返し尋ねる質問をカバーします。トピックによっては、以下が含まれる場合があります。
- 何が含まれるか、除外されるか、互換性があるか、利用可能か、または必須か?
- 回答はどのオーディエンス、プラン、場所、製品、または状況に適用されるか?
- 購入またはアカウント変更の前、最中、後に何が起こるか?
- キャンセル、返品、アクセス、プライバシー、またはサポートを管理するポリシーはどれか?
- 完全な定義、手順、または診断のために読者はどこに行くべきか?
- 最近何が変更され、回答は最後にいつ確認されたか?
表現は実際の言語を反映する必要があります。チケット、電話、検索、AIプロンプトからの認識可能な表現を保持し、質問を明確にするために必要な最小限の編集のみを行います。内部の専門用語は、読者の表現が一致を確立した後に回答内に登場することができます。
この投稿タイプを使用するタイミング
まず、なぜ別ページが役立つのかという理由から始めます。 FAQ構造は、主な役割が別にあるページに追加される再利用可能な要素です。これは、製品説明、ガイド、またはサービス説明の後にあるいくつかの残存する異議を解決します。FAQハブは異なります。質問がページの主要な情報アーキテクチャであり、ページはそれらの質問の集合的な有用性によって存在価値を得ます。
読者がグループ化やページ内ナビゲーションを必要とするほどの明確で証拠に基づく項目がある場合、複数のページが同じ回答を繰り返すことになる場合、およびすべての質問が1つのトピックとオーディエンスに適合する場合、質問はブロックの規模を超えています。魔法の数はありませんが、5つの通常の異議がハブを必要とすることはめったになく、セットアップ、請求、アクセス、ポリシーにわたる20の質問は通常、明示的なグループを必要とします。数は症状であり、ナビゲーションと繰り返しの需要が判断基準です。
逆のリスクは、テンプレートにFAQスロットがあるためにハブが構築されることです。サポートや検索のエビデンスが信頼できる質問を提供できない場合は、質問を捏造しないでください。読者に何も教えず、主に構造化マークアップを保持するために存在する大きなページよりも、短く関連性のあるブロックの方が優れています。
| このタイプを選択 | 読者の出発点 | 回答の形状 | 使用すべきでない場合 |
|---|---|---|---|
| FAQハブ | 読者はトピックを知っており、いくつかの繰り返し質問の1つを持っている | グループ化された質問、最初の文での回答、正規ルート | リストが短すぎてナビゲーションを必要としない、または質問にエビデンスがない |
| FAQ要素 | 読者は別の何かについてのページを消費し、いくつかの残存する異議を持っている | 最後の方に追加される3〜8の簡潔な回答 | 質問がページの全目的である、または複数のテーマにわたる |
| 用語集ページ | 読者は1つの用語の安定した意味を必要としている | 正規の定義、別名、例、関連エンティティ | 読者が運用、ポリシー、または意思決定の質問をしている |
| トラブルシューティングページ | 読者は症状、エラー、または失敗した結果を持っている | 診断ブランチ、原因、安全な修正、検証 | 質問が症状ベースではなく一般的である |
| ナレッジベース記事 | 読者は1つの製品固有のタスク、ポリシー、または設定の回答を必要としている | 製品コンテキストを持つ1つの焦点を絞った運用記事 | 公開された複数質問の発見ページが実際のニーズである |
これらのビジネスタイプに最適
このタイプは、同じ資格確認とサポートの質問が繰り返し発生し、回答がメンテナンスできるほどゆっくりと変化し、曖昧な回答の結果が重要である場合に最も効果的です。
- SaaS。 プラン、セキュリティ、統合、移行、請求、アクセス、サポートに関する質問をグループ化します。完全なセットアップ手順は、トグルに圧縮するのではなく、ドキュメントにルーティングします。
- Eコマース。 配送、返品、サイズ、互換性、支払い、保証、在庫ポリシーに関する質問を統合します。ストア全体に適用されない製品固有の事実は、該当する製品またはカテゴリページに残します。
- ローカルサービス。 サービスエリア、予約、準備、料金体系、アクセス、キャンセル、アフターケアに関する質問に回答します。地理的および緊急時の範囲を明示します。
- B2Bサービス。 セールス会話の前に、範囲、エンゲージメントモデル、調達、 deliverables、クライアントの責任、機密保持、引き継ぎに対処します。
- ヘルスケアと薬局。 資格、アクセス、準備、履行、エスカレーションにはレビュー済みの回答を使用します。診断や個別化された医療アドバイスは一般的なFAQの対象外とします。
- マーケットプレイス。 買い手、売り手、プロバイダーの質問を分離し、参加者ルール、手数料、信頼管理、紛争ルートが混ざらないようにします。
検索インテント
検索インテントは、クエリの背後にあるジョブです。FAQハブのインテントは通常、既知のトピック内での狭い情報検索です。「XはYと統合できますか?」「いつ請求されますか?」「予約を変更できますか?」読者は、物語的な導入よりも認識とスピードを重視します。
サポートチケット、セールスコールノート、サイト内検索、検索サジェスト、コミュニティスレッド、カスタマーサクセスの会話、追跡されたAI質問から質問を収集します。AmICitedの プロンプトトラッキングは、チームが購入者が回答エンジンに尋ねる正確なプロンプトを記録し、それらのエンジンがブランドの現在の回答を返すかどうかを検査するのに役立ちます。ボリューム、頻度、ビジネス上の影響、安全性を別々のシグナルとして扱います。ある質問が多くの読者をブロックするため、重大なリスクを表すため、または購入決定を変更するために重要度が高くなることがあります。これらが同じランキング方法であると偽らないでください。
順序付け方法を明示的に宣言します。人々が請求、セットアップ、プライバシーなどのカテゴリを認識する場合はテーマを、質問が評価からオンボーディング、更新へと自然に進行する場合はジャーニーステージを、チケット、検索、または通話データが順序をサポートする場合にのみ頻度を使用します。テーマでグループ化し、各グループ内では頻度で並べるなど、ハイブリッドは宣言されていれば許容されます。偶然の順序付けは、ページがサポートのバックログのように感じさせます。
読者がすべてのグループ見出しを1つのビューポートでスキャンできない場合、またはハブに約12以上の回答が含まれている場合は、ページ内ナビゲーションを使用します。正確な閾値は回答の長さとグループの数によって異なります。運用上のテストは、読者がブラウザ検索を使用せずに既知の質問を見つけられるかどうかです。
ページ構造
ワードバンドは、回答の深さを管理し、不必要に膨らませないようにします。ハブは成長するにつれてスキャンしやすくなるべきです。
| セクション | ワードバンド | 目的 | 必須? |
|---|---|---|---|
| ヒーローと範囲 | 50–100 | トピック、オーディエンス、カバレッジ、確認日を明記し、読者が回答が適用されるかどうかを判断できるようにする | はい |
| クイックオーバービュー | 40–80 | 最も重要な範囲の境界を述べ、質問の整理方法を説明する | はい |
| ページ内ナビゲーション | 3–8グループリンク | 読者をテーマまたはジャーニーステージに直接ルーティングする | 条件付き:複数のグループまたは約12以上の回答がある場合 |
| 質問グループ | 各80–500 | 関連する質問を説明的なH2見出しの下に安定したアンカーでまとめる | はい |
| 個別回答 | 通常40–120 | 最初の文で回答し、必要な範囲、例外、例、またはルートを追加する | はい |
| エスカレーションまたは連絡ルート | 40–100 | 一般的な回答ではアカウント固有または高リスクのケースを解決できない場合の対処法を説明する | 条件付き |
| 出典とレビューノート | 40–150 | 権威あるポリシー、技術、または規制のインプットと最後の実質的なレビューを特定する | 単純な事実には条件付き、重大な主張には必須 |
| 関連コンテンツ | 2–5リンク | 読者を正規の定義、手順、ポリシー、トラブルシューティングにルーティングする | はい |
| CTA | 30–80 | 情報を得た検討段階の読者に適した1つの次のアクションを提供する | はい |
回答の深さは所有権ルールに従います。最初の文は単独で機能する必要があり、「状況によります」で始めてはなりません。ただし、すぐに回答が何に依存するかを明記する場合は例外です。誤った行動を防ぐために必要な詳細のみを追加します。回答に複数の見出し、前提条件、エビデンス、または順序付けられたステップが必要な場合、ハブはそのページを再現するのではなく、要約してリンクする必要があります。
必須要素
| 要素 | 常時または条件付き | 位置 | 存在理由 |
|---|---|---|---|
| クイックオーバービューと目次 | 常時;短いハブでは目次部分は条件付き | ヒーローの後、最初のグループの前 | 範囲を明示し、長いハブに各テーマへの予測可能なルートを提供する |
| アンカーリンク | 条件付き | ページ内ナビゲーションが存在する場合、すべてのグループ見出しに | 安定した説明的なターゲットにより、読者とサポートチームが関連セクションを共有できる |
| FAQ構造 | 常時 | メインボディ、ナビゲーションの下にグループ化 | 一貫した質問見出し、自己完結型の回答、同期された構造化レコードを作成する |
| 関連コンテンツブロック | 常時 | 最後の質問グループの後、CTAの前 | ハブを無制限に拡張することなく、重要なインテントを正規の所有者にルーティングする |
| 出典ブロック | 条件付き、ただし重大または外部統制の主張には必須 | 該当グループの後または末尾近く | ポリシー、規制、製品、技術的な主張を追跡可能かつレビュー可能にする |
| CTAブロック | 常時 | 最終作成要素 | 未解決の不確実性を、すべての回答を中断するのではなく、1つの釣り合いの取れた次のステップに変換する |
フロントマター
フロントマター仕様に従います。この仕様では、entity = "post-type-faq-hub"を使用します。実際に作成するハブでは、表示タイトルではなく限定されたトピックを特定します。請求に関するFAQはentity = "billing-faq"を使用でき、見出しは「請求に関する質問にお答えします」などに自由に変更できます。
schemaTypes = [ "Article", "FAQPage" ]は、実装が両方のタイプを出力し、マークされたすべての質問と完全な回答が表示されている場合にのみ使用します。テンプレートが単一の値を期待する場合は、2つ目のスキーマフィールドを即興で作成するのではなく、承認されたFAQPage設定を使用します。マークアップは表示される表現と一致する必要があり、修飾も含みます。隠されたスキーマ専用の質問、短縮された構造化回答、マークアップに挿入されたプロモーションコンテンツは契約に違反します。
| フィールド | 必須の値またはルール |
|---|---|
entity | 安定したトピック識別子(例:billing-faq)。キーワードを詰め込んだタイトルではない |
schemaTypes | サポートされ、表示上一致する場合のみ、Articleに加えてFAQPage |
questionOrder | theme、journey-stage、またはfrequency。ハイブリッドの場合は明示的に宣言 |
lastReviewed | 回答の正確性、正規ルート、出典が確認された日付 |
elements | 実際にレンダリングされる要素の順序付きリスト |
businessTypes | 優先順位順の関連ビジネスモデル |
[[faq]] | 表示されるマークアップ済みの質問ごとに1レコード、同一の回答テキスト |
[[lnks]] | 内部リンクごとに1レコード、正確な表示アンカーテキスト |
FAQPageスキーマは表示可能なページを記述するものであり、公開する理由ではありません。検索プレゼンテーションの適格性は変化するため、リッチリザルトが利用できないという理由だけで有用なコンテンツを削除することなく、現在のポリシーを検証します。
完全な例
以下の例は、架空のSaaS請求ハブを示しています。構成は冒頭で宣言されたジャーニーステージによるものです。短い回答はハブに属し、重要な手順には正規ルートがあります。
FleetDesk請求FAQ
トライアル、請求書、プラン変更、キャンセルに関する回答をご覧ください。質問は評価から更新までグループ化されています。これらの回答は直接オンラインサブスクリプションに適用されます。リセラー契約のお客様は、その契約に記載された請求連絡先を使用してください。最終レビュー:2026年8月27日。
サブスクリプション前
請求はいつから始まりますか?
アカウント設定に表示される終了日より前にキャンセルしない限り、トライアル終了時に請求が開始されます。チェックアウトサマリーには、プランを確定する前に請求間隔と金額が表示されます。年払いはできますか?
はい。年払いはプランセレクターから選択可能で、確定前に年間料金全額が表示されます。間隔の変更は、すでに発行された請求書を書き換えるのではなく、次の更新に影響します。請求書とアカウント変更
請求書はどこでダウンロードできますか?
アカウント所有者は、請求 → 請求書から発行済みの請求書をダウンロードできます。完全な手順、権限、請求書未発行の確認については、請求書ダウンロードガイドをご覧ください。ユーザーを追加するとどうなりますか?
請求対象ユーザーの追加は、確認前に表示される按分条件に従ってサブスクリプションを変更します。プレビューがその変更の管理金額です。古い請求書から請求額を推測しないでください。キャンセルと更新
キャンセルするとデータはすぐに削除されますか?
いいえ。キャンセルは次の更新を停止しますが、現在の有料期間が終了するまでアカウントは利用可能です。保持ポリシーでは、何をエクスポートできるか、アカウントデータがいつ削除されるかが説明されています。アカウント固有の請求については誰に問い合わせればよいですか?
請求書番号とアカウントドメインを添えて請求サポートに連絡してください。リクエストにカード情報やパスワードを含めないでください。
この例では、各質問に即座に回答し、回答が変わる場合は範囲を明示し、手順やポリシーには onward ルートを使用しています。プロダクションバージョンでは、一般的なルート名を実際の内部リンクに置き換え、各請求ルールを現在の商用ポリシーから引用します。キーワードカバレッジを広げるためだけに「FleetDeskとは?」を追加することはありません。その定義は別の場所に属します。
デザインギャラリー
すべてのデザインバリエーションは、質問の表現、回答テキスト、出典ノート、見出し階層、キーボード動作を保持する必要があります。ギャラリーは、見つけやすさをテストするものであり、装飾的な新規性をテストするものではありません。
アコーディオンは視覚的な長さを削減できますが、質問ラベルを隠したり、回答をアクセシブルなドキュメントから削除したり、直接リンクを妨げたりしてはいけません。1つの回答が重要な修飾を伴う場合、デフォルトで開かれたセクションが役立つことがあります。短いハブでは、スキャンに繰り返しのインタラクションが必要ないため、開かれた散文の方が優れていることがよくあります。
品質チェックリスト
- ハブは1つの限定されたトピックをカバーし、回答が適用されるオーディエンスまたはアカウントコンテキストを明記している。
- すべての質問が、サポート、セールス、サイト内検索、検索サジェスト、コミュニティのエビデンス、または追跡されたAIプロンプトにトレース可能である。
- 質問はインテントごとに重複排除されており、顧客の言語が内部の製品用語に置き換えられていない。
- 順序付け方法(テーマ、ジャーニーステージ、頻度、または宣言されたハイブリッド)が表示され、一貫して適用されている。
- 長いハブには、安定した説明的なグループアンカーへのページ内ナビゲーションがある。
- すべての回答が最初の文で質問を解決し、必要な範囲、例外、エビデンス、または次のアクションのみを含んでいる。
- 既存の定義、ガイド、ポリシー、トラブルシューティングページは、完全なインテントに対して正規のままである。
- 重大な回答は、出典、適用範囲、所有者、レビュー日を明記している。
- 表示される質問、表示される回答、
[[faq]]レコード、FAQPageマークアップが正確に一致している。 - アコーディオンコントロールがキーボードと支援技術で動作し、有用なコンテンツが視覚的な状態だけに依存せずに存在している。
- 関連リンクは、キーワードの類似性ではなく、未解決の読者のジョブによって選択されている。
- 最終CTAは1つの検討段階のアクションを提供し、個別の回答を中断しない。
よくある間違い
- 正規ページをカニバライズする。 これが最も有害な失敗です。ハブが「Xとは何か?」に完全に回答すると、 what-isページと競合します。ハブが「Xのやり方」を再現すると、 ハウツーガイドと競合します。ハブの回答は簡潔に保ち、有用な範囲を示し、所有者にルーティングします。
- 質問を捏造する。 「Xは良いですか?」や「なぜXが最良なのか?」などの明白なキーワードバリエーションは、サポートではなくプロモーションを示します。掲載には出典を要求します。
- 偶然の整理。 チケットが到着した順序からコピーされたリストは、読者にすべての質問を検査することを強制します。ナビゲーションモデルを宣言して適用します。
- 前置きで回答する。 「請求が混乱を招く可能性があることを理解しています」は事実を遅らせます。回答を最初の文に入れます。
- アコーディオンを使用して弱い範囲を隠す。 折りたたまれた回答は、繰り返し、混在したオーディエンス、または欠落したグループラベルを修正しません。
- 回答をポリシーから乖離させる。 製品、価格、法務、安全性、可用性の回答には、所有者とレビュートリガーが必要であり、古い公開日だけでは不十分です。
- スキーマ専用コンテンツを公開する。 質問は、マークアップのためだけでなく、読者のために存在しなければなりません。表示されるページと異なる構造化データは、信頼とメンテナンスの欠陥を生み出します。
- すべての質問を同様に小さいものとして扱う。 いくつかの質問は、欠落している正規のガイド、ポリシー、または診断ページを明らかにします。インテントを昇格させ、明確なルートを残し、完全な回答を100語に強制しないでください。
内部リンク
カニバリゼーションルールは絶対的です。質問にすでに正規ページがある場合、ハブはそのページにリンクし、その完全な回答を再作成しません。 リンクが意味をなすための十分なコンテキスト(通常は1〜2文)を提供しますが、1つのURLに定義、手順、比較、ポリシー、または診断を所有させます。
すべてのハブ質問について、簡単な所有権レコードを作成します。質問の表現、インテント、正規URL、ハブ回答の範囲、エビデンスの出典、所有者、レビュー日。「正規ページなし」は、質問が小さすぎて正規ページに値しない場合に有効です。「不明」は有効ではありません。公開前に所有権を確定します。
質問のグループが有用な場所(製品、サービス、アカウント、連絡先、サポート画面)からハブにリンクします。周囲のページがその正確な問題を提起している場合は、グループまたは質問に直接ディープリンクします。未解決のジョブを完了する2〜5の宛先に外部リンクし、アンカーテキストは具体的にします。「請求書をダウンロード」は宛先を伝えますが、「もっと詳しく」は伝えません。
関連コンテンツエリアをサイトインデックスに変えないでください。FAQハブは、小さな回答を十分にし、大きな回答を見つけやすくする必要があります。
結果の測定方法
読者が正しい回答を見つけ、適切な次のステップを取るかどうかを測定します。公開前に、現在の繰り返しサポート質問の数と表現、サイト内検索の離脱、質問バリエーションのオーガニックインプレッション、追跡されたAI回答、既存の正規ページへのクリックを記録します。利用可能なトラフィックとサポート量を反映したレビュー期間を選択します。固定日数はすべてのビジネスにとって意味があるわけではありません。
公開後、以下を評価します。
- 発見: ハブがサポートする質問セットのインプレッションとエントランス。正規ページが所有するクエリから分離します。
- 見つけやすさ: グループアンカーの使用、サイト内検索の絞り込み、測定可能な場合の質問展開、回答インタラクション前の離脱。
- 解決: 繰り返されるチケットやセールス質問の変化、セルフサービスの完了、エスカレーションの質。連絡が減っても、顧客が依然として正しい結果に到達している場合にのみ有用です。
- ルーティング: 簡潔なハブ回答から正規の定義、手順、ポリシー、トラブルシューティングへのクリック。
- AI回答の正確性: 追跡された回答が範囲を保持し、2つの競合するソースを混ぜるのではなく、ハブまたは正しい正規ページを引用しているかどうか。
- メンテナンス: 古くなった回答の発見、壊れた正規ルート、一致しない構造化レコード、ソース変更から公開修正までの時間。
SEO結果フレームワークを使用して、ページを維持、再グループ化、更新、統合、分割、または廃止するかを決定します。インプレッションの増加は重複チケットの増加を許容せず、チケットの減少は読者が単にタスクを放棄した場合の理解を示すものではありません。
FAQ
FAQハブページとは何ですか?
FAQハブは、1つの限定されたトピックに関する繰り返しの質問に特化したページです。質問をグループ化して並べ替え、小さな質問には直接回答し、重要な質問は正規ページにルーティングします。
FAQはいつブロックから専用ハブに移行すべきですか?
リサーチにより、グループ化とページ内ナビゲーションを必要とするほどの明確な繰り返し質問が十分にある場合、かつそのコレクションが1つの明確なオーディエンスとトピックに役立つ場合にハブを作成します。スキーマを保持するためだけにハブを作成しないでください。
FAQハブの回答はどのくらいの長さにすべきですか?
最初の文で回答し、回答を安全かつ有用にするために必要な修飾、例、または範囲のみを追加します。完全な回答に完全な議論や手順が必要な場合は、要約して正規ページにリンクします。
FAQハブはwhat-is質問やhow-to質問をターゲットにできますか?
それらの質問をリストアップすることはできますが、既存の定義や手順を再作成すべきではありません。簡潔なルーティング回答を提供し、正規のwhat-isページまたはハウツーガイドにリンクして、1つのURLが完全なインテントを所有するようにします。
すべてのFAQハブにFAQPageスキーマが必要ですか?
いいえ。FAQPageは、質問と完全な回答が読者に表示され、構造化データと正確に一致し、現在の検索エンジンポリシーに準拠している場合にのみ使用します。スキーマは、弱いまたは捏造された質問を正当化するものではありません。
FAQハブはどのくらいの頻度でレビューすべきですか?
製品、ポリシー、価格、規制、またはサポートパターンが変更されたとき、およびトピックに適した定期的な頻度でレビューします。新しい質問のエビデンスを使用して、エントリを追加、統合、ルーティング、または廃止します。
繰り返しの質問を維持された回答システムに変える
サポート、セールス、検索、追跡されたプロンプトからのエビデンスから始めます。すべての重要なインテントに1つの正規の所有者を割り当て、ハブが所有すべき小さな回答のみを公開します。 AmICited Cockpitを開くで、公開前に質問セットのベースラインを設定し、その後、回答エンジンがどのようにそれを表現するかを監視します。
よくある質問
FAQハブは、1つの限定されたトピックに関する繰り返しの質問に特化したページです。質問をグループ化して並べ替え、小さな質問には直接回答し、重要な質問は正規ページにルーティングします。
リサーチにより、グループ化とページ内ナビゲーションを必要とするほどの明確な繰り返し質問が十分にある場合、かつそのコレクションが1つの明確なオーディエンスとトピックに役立つ場合にハブを作成します。スキーマを保持するためだけにハブを作成しないでください。
最初の文で回答し、回答を安全かつ有用にするために必要な修飾、例、または範囲のみを追加します。完全な回答に完全な議論や手順が必要な場合は、要約して正規ページにリンクします。
それらの質問をリストアップすることはできますが、既存の定義や手順を再作成すべきではありません。簡潔なルーティング回答を提供し、正規のwhat-isページまたはハウツーガイドにリンクして、1つのURLが完全なインテントを所有するようにします。
いいえ。FAQPageは、質問と完全な回答が読者に表示され、構造化データと正確に一致し、現在の検索エンジンポリシーに準拠している場合にのみ使用します。スキーマは、弱いまたは捏造された質問を正当化するものではありません。
製品、ポリシー、価格、規制、またはサポートパターンが変更されたとき、およびトピックに適した定期的な頻度でレビューします。新しい質問のエビデンスを使用して、エントリを追加、統合、ルーティング、または廃止します。
このセクションの他のチュートリアル
実践する準備はできましたか?
無料チェック · 7日間お試し · クレジットカードが必要