FAQシステムの内製 — 検索・管理UI・サイト横断

はじめに

「よくある質問（FAQ）をちゃんと整備したい」と考えたとき、最初に検討するのはFAQ専用のSaaSではないでしょうか。
確かに導入は速いのですが、いざECサイトに組み込もうとすると「デザインが浮く」「検索が別物」「複数サイトで使い回せない」といった悩みが出てきます。

この記事では、私がアパレル・ギア系のECサイトで、FAQを外部SaaSに頼らず自サイトに内製した理由と、その全体像を解説します。100問を超えるFAQを約10カテゴリに整理し、検索・管理画面・サイト横断まで自前でまかなう構成です。

なぜSaaSではなく内製したのか

デザインと検索の一体感

SaaSのFAQは、どうしても「そこだけ別サービス」という見え方になりがちです。フォントもボタンも微妙に違い、検索窓も本体サイトとは別物として動きます。ユーザーからすると小さな違和感ですが、こうしたズレが積み重なると「探しにくいサイト」という印象につながります。内製すれば、商品ページと同じ部品でFAQを組み立てられ、検索結果もサイト内検索と地続きにできます。この一体感こそ、私が内製を選んだ一番の理由なんです。

コストと複数サイト展開

FAQ SaaSは問い合わせ数やページビューで課金されることが多く、サイトが増えるほど費用も膨らみます。私の環境では姉妹ECサイトが複数あり、同じFAQ基盤を横展開したいという要件がありました。内製なら、一度作った仕組みを別サイトに載せ替えるだけで済み、追加コストはほぼサーバー費用だけです。SaaSの月額を積み上げるより、長い目で見て安く収まりました。

コンテンツ資産として自分の手元に持つ

FAQは「問い合わせを減らす道具」であると同時に、検索エンジンから流入を生むコンテンツ資産でもあります。SaaSに預けると、URL構造や構造化データの制御が効かず、SEO面での自由度が下がります。自サイトに持てば、カテゴリページのURLも見出し構造も自分で設計でき、FAQそのものが集客の入り口になります。データが手元にある安心感も大きいですよね。

内製FAQの全体像

データはJSON、配信はKV

FAQの中身は、カテゴリごとのJSONファイルで管理しています。開発側はこれをGitで扱い、本番の配信は高速なキーバリューストア（Vercel KV）から行う二段構えです。JSONを「正」として持ちつつ、実際の表示はKVから引くことで、表示は速く、管理はしやすい状態を両立しています。カテゴリ別ページとアコーディオン表示という素直なUIも、この軽量なデータ構造があるからこそ無理なく作れました。

検索インデックスでインライン検索

100問を超えるFAQを、カテゴリを開いて一つずつ探すのは現実的ではありません。そこで、全FAQを横断できる**検索用インデックス（search-index）**を用意し、入力に応じてその場で候補を絞り込むインライン検索を用意しました。ユーザーは質問の一部を打つだけで、カテゴリをまたいで該当FAQにたどり着けます。この検索の作り込みは、次の記事で詳しく解説します。

「現場が編集、開発がレビュー」を両立する

二つの編集経路を持つ

FAQの運用でよくある衝突が、「現場はすぐ直したい」「開発はデータを管理したい」というせめぎ合いです。私の設計では、現場スタッフはOTP認証の管理画面からFAQを直接編集でき、開発側はGitでJSONを管理します。両者はpush/pullスクリプト（faq-push / faq-pull）でKVと双方向に同期します。どちらの経路から編集しても、最終的にデータが一つに収束する仕組みです。

サイト横断で同じ仕組みを使う

姉妹ECサイトにも、この内製FAQをそのまま展開しています。データ構造も管理画面も検索も共通なので、サイトごとに作り直す必要がありません。新しいサイトを立ち上げるときも、FAQのカテゴリJSONを用意して同期するだけで、同じ品質のFAQ体験を提供できます。仕組みを一度きちんと作っておくと、こういう横展開の場面でぐっと効いてきますよね。

まとめ

FAQを内製した理由は、デザインと検索の一体感、コスト、複数サイト展開、そしてコンテンツ資産という4点に集約されます。派手な機能ではありませんが、こうした地味な土台が、問い合わせ削減と集客の両方に長く効いてきます。

このテーマは、次の3記事でさらに深掘りしています。