▼ この記事の内容
FAQシステムは、検索できるかだけでなく、回答を誰が確認し、いつ更新し、どこまで公開するかを候補ごとに試して選びます。検索、承認、移行を順に試す確認表で、候補ごとの対応状況を記録できます。
製品名やランキングだけでは、自社の質問が見つからない理由や、古い回答を止める責任までは比べられません。候補を増やす前に、利用者の言葉、回答の正本、公開前の確認者を並べると、デモで試す作業が具体的になります。
ここで示す表と回答例は、架空の公開FAQを題材にした教材です。実在製品の性能試験や導入効果を示すものではないため、自社の手順と実際の候補製品で確認して使ってください。
FAQシステムは検索性と更新運用で選ぶ
ランキング比較前に質問内容と更新責任を決める
FAQシステムの候補は、製品名の順位ではなく、どの質問を公開回答で扱うかから絞ります。営業時間や申請の入口のように条件が安定した質問と、契約内容や個別障害のように確認が必要な質問を分けてください。
定型回答にできない質問には、利用者が確認する項目と引き継ぐ窓口を置きます。回答の正本を持つ部署、更新のきっかけ、公開範囲を候補ごとに試すと、登録画面の使いやすさだけでは見えない条件を比べられます。
回答方式と画面・検索範囲を分けて比較する
固定した回答を探すFAQ、会話形式でやり取りするチャットUI、複数資料を検索して生成に使うRAG、社内資料を探す検索は、それぞれ回答内容、画面、回答方式、検索対象を示す言葉です。チャット画面でも固定回答や生成回答を使えるため、排他的な製品分類にはしません。MicrosoftのRAGガイダンスも、検索で取得した情報を生成に組み合わせる設計として説明しています。
その説明は、精度や誤回答防止を保証するものではありません。候補に生成回答を含めるなら、参照してよい資料、利用者の閲覧権限、答えられない時の案内を別々に確認しましょう。関連する選択肢は、AIチャットの種類と選び方でも整理しています。
営業AI・営業DX 法人向けAIチャットボットの比較方法｜回答・権限・費用を試行で確認する
参考：Retrieval-augmented generation guidance｜Microsoft Learn
同じ質問を検索で見つけられない原因を確認する
検索0件・クリックなし・問い合わせ・旧手順表示を分けて確認する
検索で見つからない状態は、一つの失敗指標にまとめません。Zendeskの検索分析の説明では、検索0件、クリックなし、検索後に作成されたチケットを別の指標として確認できます。
検索0件なら表記ゆれや索引、クリックなしならタイトルや要約、閲覧後の問い合わせなら前提条件やエラー別の手順を確認します。クリックなしだけで未解決、問い合わせだけで記事不備と決めつけず、検索語と回答本文を同じ期間・対象で見比べることが出発点です。
参考：Analyzing help center search results｜Zendesk
「ログインできない」を調査表に記録する
次は架空の業務ソフトの公開FAQを使う記入例です。「ログインできない」という利用者の表現と、管理側の記事名「認証手順」が一致しない場面を想定します。これは実測結果ではなく、原因を決めつけずに調べる順序を示す教材です。
| 観察 | まだ不明な点 | 調べる箇所 | 修正後の再確認 |
|---|---|---|---|
| 検索0件 | 別表記で登録されているか | 表記ゆれ・公開範囲・索引 | 利用者の言葉で検索する |
| 結果あり・クリックなし | 見出しが意図を示すか | タイトル・要約・対象版 | 結果一覧から開けるか |
| 閲覧後に問い合わせ | 前提条件が足りるか | エラー別手順・引継先 | 必要情報を渡せるか |
| 旧手順が表示される | 正本と公開版が一致するか | 更新日・公開版・検索反映 | 旧URLと表示内容を確認する |
表には、検索語、観察、まだ不明な点、調べる箇所、修正候補、再確認方法を残します。候補製品の検索機能を試す時も、同じ質問と同じ確認順序を使うと、回答数ではなく利用者が迷う地点を比較できます。
回答の作成・承認・公開フローを試して比較する
回答は対象版・エラー・操作・引き継ぎ情報を分けて書く
「管理者へ連絡してください」だけでは、利用者も担当者も次に確認する内容を決められません。回答には対象となる画面や版、表示されたエラー、利用者が試せる操作、引き継ぎ時に渡す情報を分けて書きます。
架空例では、「ログイン画面で表示された文言と利用しているブラウザを確認し、案内された手順を試しても解消しない場合は窓口へ渡す」とします。パスワードや認証コードを送るよう求めず、実際の操作と連絡先は自社の手順に置き換えてください。
下書きから公開までの状態と権限をデモで確認する
候補のデモでは、下書きを作れるかだけでなく、誰がレビューし、誰が承認し、誰が公開できるかを操作で確かめます。ZendeskのTeam Publishingの説明でも、レビュー待ち、承認済み、公開が区別され、管理権限のある担当者が操作します。
これはZendeskの製品固有の例であり、全製品・全プランの標準仕様や二人承認の強制を意味しません。公開済みの回答を改訂下書きへ戻せるか、権限のない利用者に公開操作が見えないか、公開範囲を変更した時に履歴を追えるかを候補ごとに確認します。
参考：Reviewing, approving, and publishing articles with Team Publishing｜Zendesk
既存FAQは移行前に棚卸しする
既存FAQの移行方針と残す情報を決める
移行は本文をコピーすれば終わる作業ではありません。既存FAQごとにURL、カテゴリ、言語、公開範囲、添付、内部リンク、更新日を棚卸しし、維持・統合・改訂・廃止のいずれにするかを記録します。
同じ質問に複数の回答がある場合は、残す正本と旧ページの扱いを決めます。移行先の仕様やURL案内が未確認なら、互換性があると推測せず、デモまたは担当者への確認項目として残してください。
旧URL案内・権限・検索・スマホ閲覧を公開前に確認する
公開前の受入確認では、旧URLからの案内、利用者ごとの閲覧権限、表示された候補、スマホでの表示を別々の作業として試します。本文が移っていても、利用者が古い手順へ到達したり、見せるべきでない回答が見えたりすれば、移行完了とは言えません。
確認できなかった項目は、合格ではなく未確認として表へ残します。公開予定日より前に、確認者、対象環境、再確認の条件を決めると、移行後の不具合を検索や問い合わせの結果だけで判断せずに済みます。
比較表と費用表はデモの確認結果を基に作成する
必要な機能と確認状況を分けて記録する
比較表には、検索と表記ゆれ、カテゴリ、下書き、承認、公開権限、版履歴、更新通知、検索分析、有人問い合わせ導線、出力と連携を並べます。各行に「必要か」と「デモまたは公式資料で確認できたか」を分けて記入してください。
| 確認項目 | 自社で必要か | 確認状況 | デモで試す操作 |
|---|---|---|---|
| 表記ゆれを含む検索 | 必要／任意 | 確認済み／未確認 | 同じ質問を別の言い方で探す |
| 下書きと承認 | 必要／任意 | 確認済み／未確認 | 権限別に公開まで進める |
| 版履歴と更新通知 | 必要／任意 | 確認済み／未確認 | 改訂後に履歴を確認する |
| 有人への引継ぎ | 必要／任意 | 確認済み／未確認 | 回答不可の導線を表示する |
必要な機能でも、確認できていなければ合格にはしません。他社製品の未確認事項を「不可」と書かず、確認先と期限を残します。FAQと周辺ツールの位置づけは、セールステックの領域別整理も補助になります。
営業AI・営業DX セールステックカオスマップ｜課題逆引き7分類
料金と更新作業を同じ期間で比較する
費用表では、作成者の利用数、公開するFAQの範囲、言語、検索やAIの使用量、承認オプション、移行支援、更新工数を同じ期間と条件でそろえます。料金資料にない必須プランや追加費用は、相場や推測で埋めず、確認先と回答期限を残します。
| 費用欄 | 比較期間にそろえる条件 | 確認する点 |
|---|---|---|
| 基本料金・作成者 | 利用人数、契約期間、必要プラン | 閲覧専用利用者、最低席数、承認機能の適用範囲 |
| 検索・AI利用 | 課金対象と想定件数 | 無料枠、超過単価、利用上限。未回答の課金も確認 |
| 公開範囲・言語 | サイト数、言語数、公開対象 | オプションと基本料金の重複を除く |
| 移行・連携 | 記事、添付、履歴、権限の対象 | 初期費用と追加作業を分ける |
| 継続更新 | 担当者の作業時間と社内単価 | 執筆・承認・検索反映確認を含める。不明はゼロにしない |
FAQの整備と併せて営業支援のFAZOMを検討する場合は、FAZOMの導入ガイドも相談前の判断材料として参照できます。ただし、このリンクはFAQシステム各社の仕様や価格を示すものではありません。
導入後は検索指標と更新工程を分けて評価する
検索0件率と平均CTRは定義・期間・対象を固定して確認する
Zendeskの検索分析の説明では、平均CTRはクリックされた結果数を検索数で割った値として説明されています。これは自己解決率ではないため、検索0件率、検索回数、利用者数、問い合わせを一つの数字に混ぜず、定義・期間・対象を固定して確認します。
問い合わせの増減には、季節、案内方法、対象者の変化など別の要因もあり得ます。FAQの導入だけが原因だと断定せず、検索語、更新した回答、利用者が次に取った行動を同じ観察期間に記録してください。
参考：Analyzing help center search results｜Zendesk
変更把握から検索反映までの時間と未完了件数を記録する
更新作業が止まっている工程は、検索の指標とは別に確認します。正本の変更を知った日、修正した日、承認した日、公開した日、表示内容を確認した日を分けると、どこで作業が止まったかを見つけやすくなります。
所要時間は変更を知った時点から検索反映を確認した時点までと定義し、完了した回答だけで集計する場合は対象件数も示します。未完了の回答は平均から消して終わりにせず、件数、経過日数、止まっている理由と確認者を残します。確認した回答数を併記すれば、誤回答の検知数を観察量の差と混同せず、次にどの質問から見直すかを決められます。
読後の解決確認と誤回答の確認数を分けて記録する
記事を読んだ後に任意で解決状況を尋ねる場合は、質問を提示した対象数と回答者数、解決したと答えた人数を併記します。回答者のうち何人が解決したかと、対象者のうち何人が回答したかは別の割合です。未回答を解決済みや未解決へ振り分けず、回答者の結果を全閲覧者へ広げません。
再問い合わせは、同じ質問かを確認できる範囲と追跡期間を先に決めます。観察期間が終わっていない対象や、問い合わせとの対応が分からない対象を別に残してください。回答内容を担当者が点検する場合も、誤りを見つけた回答数だけでなく点検した回答数、対象版、修正日を記録します。利用者の解決の申告と、回答の正確性の点検は代わりになる指標ではありません。
まとめ
比較前の条件を一枚の表にまとめる
FAQシステムは、同じ質問を候補ごとに試し、検索、回答、承認、公開、更新、移行を確認して選びます。質問の性質、回答の正本、引継先、未確認の条件を一枚の表に残せば、機能名だけで候補を決めずに済みます。
架空例を自社の質問へ置き換え、確認できなかった条件は保留として記録してください。チェック表は製品の順位や導入効果を示すものではなく、利用者が必要な答えへ到達し、更新担当が根拠を確認できるかを試すための道具です。
