管理画面編集とGit経由の同期運用

はじめに

FAQ運用で意見が分かれやすいのが、「誰がFAQを直すのか」という点です。カスタマーサポートの担当者は、古い回答に気づいたその場で直したい。開発側は、データを履歴つきできちんと管理したい。どちらの言い分にも理由がありますが、片方だけを通すと必ず不便が出ます。管理画面だけにすると変更の経緯が残らず、ファイル管理だけにすると誤字の修正にも開発の手が必要になります。

この記事では、アパレル・ギア系のECサイトで、現場は管理画面から、開発はファイルから、という二つの編集の入り口を用意し、それを同期の仕組みでつないだ運用を解説します。どちらから直しても、最終的にデータが一つに収束する形です。仕組みそのものは複雑ではありませんが、二つの入り口を持つ以上、決めておかないと事故につながる手順がいくつかあります。その決めごとも含めてまとめました。

編集の入り口を二つに分ける

現場スタッフは管理画面から直せるようにする

FAQを直したい人の多くは、コードにもファイル管理の仕組みにも触りません。問い合わせ対応をしていて「この回答、いまの送料と違う」と気づいたときに、その場で直せることが大事です。そこで、ワンタイムパスワード（毎回発行される使い捨ての暗証番号）でログインする管理画面を用意し、質問文・回答本文・並び順を直接編集できるようにしました。編集したい人が、専門知識なしで、気づいたときに直せる。これが現場側の入り口です。

開発側はファイルと変更履歴で管理する

一方、開発側はカテゴリ別のファイルをGit（変更履歴を記録しながらファイルを管理する仕組み）で扱います。カテゴリの追加、回答の構造を変えるような一括修正、姉妹サイトへの展開といった作業は、コードと同じように作業用の枝を切り、レビューを通してから反映したい。Gitに載せておけば、いつ・誰が・どこを変えたかが残り、問題が出たときは前の状態へ戻せます。

同じFAQデータに対して、日々の修正と、まとまった変更とで、触る入り口を分けている、という図です。

どちらが何を担当するかを先に決めておく

入り口を分けたら、担当範囲も言葉にしておきます。文言の修正・回答の更新・並び替えは現場、カテゴリ構成の変更・複数サイトへの展開・データ形式の変更は開発。この線引きが曖昧だと、現場が大きな変更に手を出して収拾がつかなくなったり、逆に細かな修正まで開発待ちになったりします。判断に迷うのは「新しいカテゴリを作るほどではないが、既存のどこにも入らない質問」といったケースなので、そういうときは開発側に相談する、と決めておくと止まりません。

二つの入り口を同期でつなぐ

送り出す処理と、引き取る処理

入り口が二つあると、必ず「どちらが最新か」という問題が起きます。これを解くのが、双方向の同期処理です。開発側で整えたファイルの内容を本番のデータへ送り出す処理（faq-push）と、管理画面で加えられた最新の内容を手元のファイルへ引き取る処理（faq-pull）の二つを用意しました。まとまった変更は送り出しで配信し、現場の修正は引き取りで回収する。この往復があるから、二つの入り口が並んで成立します。

現場の修正を上書きしないための手順

起きると影響が大きいのは、現場が管理画面で直した内容を、開発が古いファイルを送り出して消してしまうケースです。回答が数日前の状態に戻り、しかも誰も気づかない、ということが起こり得ます。これを防ぐため、開発側で作業を始める前に、まず引き取り処理で最新を取り込む手順を運用ルールにしました。「触る前に引く」を徹底するだけで、この種の事故はほぼ起きなくなります。

配信のあとに検索用の索引も作り直す

FAQには、カテゴリをまたいで探すための検索用の索引が別にあります。本文だけを更新して索引を古いままにしておくと、検索結果に出てくる文言と実際のページの内容がずれます。ユーザーからすると、検索で見つけた回答を開いたら中身が違う、という状態です。そのため、本番へ配信する処理の最後に索引を作り直す手順を組み込み、本文と検索結果が必ず同じ内容になるようにしています。

引き取る、直す、送り出す、索引を作り直す。この4手順を毎回同じ順番で回すのがポイントです。

事故を防ぐための決めごと

ログインできる人を絞る

管理画面が扱うのは公開情報のFAQですが、誰でも書き換えられる状態は避けたいところです。ワンタイムパスワードでログインを絞り、編集できる担当者を限定しています。共通パスワードを配って使い回す方式に比べ、担当者の入れ替わりにも対応しやすく、パスワードをどこかに書き残す必要もありません。管理画面を日常的に使う現場との相性が良い方式です。

姉妹サイト分も同じ手順で回す

同じ仕組みを姉妹ECサイトにも展開しているため、編集の入り口も同期の手順もサイトをまたいで共通です。担当者は「どのサイトのFAQを直しているか」だけを意識すればよく、サイトごとに操作を覚え直す必要はありません。開発側も、送り出しと引き取りの対象をサイト単位で切り替えるだけで済みます。運用の手順を1種類に保てることは、サイト数が増えるほど効いてきます。

同期のタイミングを文書にしておく

同期の仕組みは、いつ実行するかを決めていないと機能しません。「作業を始める前に必ず引き取る」「配信したら索引も更新する」といったタイミングを、運用ルールとして短い文書にまとめてあります。担当者が代わっても同じ手順で回せますし、手順を思い出せないときの確認先にもなります。仕組みを作るのと同じくらい、この決めごとが運用の安定に効きます。

まとめ

FAQの編集は、現場が管理画面、開発がファイル、という二つの入り口を用意し、送り出しと引き取りの同期処理でつなぐことで両立させました。すぐ直したい現場と、きちんと管理したい開発。どちらの要望も削らずに済むのがこの運用の利点です。同期処理そのものはAIエージェント（AIによる開発支援）に組んでもらいましたが、実務で効いているのは「触る前に引く」という運用ルールのほうでした。

データの持ち方の詳細はJSON＋KVによるFAQデータ管理と検索インデックス、全体像はFAQシステムの内製をご覧ください。