はじめに
「よくある質問（FAQ）をちゃんと整備したい」と考えたとき、最初の選択肢に挙がるのはFAQ専用のSaaS（月額契約で使えるクラウドサービス）ではないでしょうか。管理画面つきで数日あれば公開できるので、選ぶ理由は十分にあります。
ただ、いざECサイトに組み込む段階になると、フォントやボタンの見た目がサイト本体と揃わない、検索窓がサイト内検索とは別の動きをする、姉妹サイトを増やすとそのぶん契約も増える、といった問題が出てきます。
この記事では、アパレル・ギア系のECサイトでFAQを外部SaaSに頼らず自サイトに実装した理由と、その全体像を解説します。100問を超えるFAQを約10カテゴリに整理し、検索・管理画面・複数サイトへの展開までを自前でまかなう構成です。実装の細かな手順よりも、「何を判断してこの形にしたか」を中心にまとめました。
SaaSではなく自サイトに作った3つの理由
見た目と検索の操作感がサイト本体と揃う
SaaSのFAQは、どうしても「そこだけ別サービス」という見え方になります。フォントの太さもボタンの角の丸みも微妙に違い、検索窓の挙動もサイト内検索とは別物です。ユーザーからすると一つひとつは小さな違和感ですが、こうしたズレが重なると「探しにくいサイト」という印象につながります。
自サイトに実装すれば、商品ページで使っているのと同じ部品でFAQ画面を組み立てられます。検索も同じ仕組みの上に載せられるので、ユーザーは商品を探すときと同じ感覚でFAQを引けます。この操作感の統一が、内製を選んだ一番の理由でした。
サイトが増えても追加費用がほとんど増えない
FAQ SaaSの多くは、問い合わせ件数やページビューに応じた従量課金です。運営していたのは姉妹ECサイトが複数ある環境で、同じFAQ基盤を横展開したいという要件がありました。サイトの数だけ契約が増える前提だと、運営が広がるほど固定費が積み上がっていきます。
自前で持っていれば、一度作った仕組みを別サイトに載せ替えるだけで済みます。増えるのはサーバー費用くらいで、サイト数に比例して費用が跳ね上がることはありません。数年単位で見ると、この差はかなり大きくなります。
FAQそのものが検索からの入り口になる
FAQは問い合わせを減らすための道具であると同時に、検索エンジンからの流入を生むコンテンツでもあります。ユーザーが実際に困って検索する言葉が、そのまま質問文として並んでいるわけですから。
SaaSに預けると、URLの形や構造化データ（検索エンジンにページの意味を伝えるための追加情報）の制御が効きにくく、SEO面での自由度が下がります。自サイトに持てば、カテゴリページのURLも見出しの構造も自分で設計でき、FAQページ自体を集客の入り口として育てられます。
導入は数日で済むが、見た目がサイト本体と揃わない・検索が別の動きをする・サイトが増えるほど費用が積み上がる
商品ページと同じ部品で組める・検索の操作感が統一される・複数サイトへ低コストで横展開できる
導入の速さを取るか、その後の自由度と費用を取るか。この比較が、内製を選ぶかどうかの判断軸になります。
内製FAQの全体像 — 保管・配信・検索の三層
FAQの中身はカテゴリごとのファイルで持つ
FAQの本体は、カテゴリごとに分けたJSONファイル（項目名と値が並んだ、人が読める形式のデータファイル）で管理しています。「送料・配送」「返品・交換」「会員登録」といった単位で1ファイル。開発側はこれをGit（変更履歴を記録しながらファイルを管理する仕組み）で扱うので、いつ・誰が・どこを直したかがすべて残ります。
表示用のデータは高速な置き場所から配る
ファイルは管理には向きますが、ユーザーがページを開くたびに読み込んで解析するのは効率がよくありません。そこで、本番の表示にはVercel KV（データを高速に出し入れできる保管場所）を使い、ファイルの中身をこちらへ同期しています。管理のしやすさと表示の速さを、どちらも諦めずに済む形です。
100問を横断できる検索の索引を別に持つ
100問を超えるFAQを、カテゴリを一つずつ開いて探すのは現実的ではありません。全カテゴリのFAQをまとめた検索用のインデックス（本の巻末索引にあたるデータ）を別に用意し、入力した言葉に応じてその場で候補を絞り込むようにしました。ユーザーはカテゴリを意識せず、思いついた言葉だけで探せます。
約10カテゴリ・100問超（変更履歴つきで管理）
本番の表示用データ
カテゴリ横断で探すため
カテゴリ別ページ・折りたたみ表示・問い合わせへの導線
図にすると、元データを1か所に置き、そこから表示用と検索用の2系統に配る、という三層の形になります。
現場がすぐ直せて、開発もきちんと管理できる状態
編集の入り口を二つ用意する
FAQ運用でよく起きるのが、「現場は気づいたらすぐ直したい」「開発はデータをきちんと管理したい」という要望のぶつかり合いです。この構成では、現場スタッフはワンタイムパスワードでログインする管理画面からFAQを直接編集でき、開発側は同じデータをファイルとして扱います。両者は同期用の仕組みでつながっていて、どちらの入り口から編集しても、最終的にデータは一つに収束します。
姉妹サイトへはそのまま展開する
この仕組みは、姉妹ECサイトにも同じ形で展開しています。データの持ち方も管理画面も検索も共通なので、サイトごとに作り直す必要はありません。新しいサイトを立ち上げるときは、そのサイト用のFAQデータを用意して同期するだけ。土台を一度きちんと作っておくと、こういう場面で効いてきます。
内製で手元に残ったもの
サイト本体と揃った見た目、統一された検索の操作感、複数サイトへの展開しやすさ、そして検索流入を生むコンテンツとしてのFAQ。SaaSでは得にくいこれらを、まとめて自分の管理下に置けるのが内製の利点です。
まとめ
FAQを内製した理由は、見た目と検索の操作感、費用、複数サイトへの展開、そして検索流入を生むコンテンツという4点に集約されます。派手な機能ではありませんが、こうした土台の部分が、問い合わせの削減と集客の両方に長く効いてきます。
なお、この構成の設計と実装ではAIエージェントに手伝ってもらった部分も多く、非エンジニアでも「何をどう組み合わせるか」さえ決められれば形にできる、という手応えがありました。
各パートの詳細は、次の3記事で解説しています。