PoC開発サービス
同じ質問へ何度も回答しているのに、FAQを更新する時間が取れない。問い合わせ履歴は残っていても、どれを記事にするか選び、現在のルールと照合する作業が後回しになる。こうした業務では、FAQ候補を作る工程をAIで支援するPoCを検討できます。
最初は、特定の商品や業務に関する履歴だけを対象にします。似た質問をまとめ、質問文と回答案を作り、根拠資料を添える。担当者が採用・修正・保留を判断するところまでを検証します。候補を作る処理と、FAQを公開する操作は分けます。
FAQの候補作成で減らしたい作業を決める
候補作成には、履歴を集める、同じ質問をまとめる、既存FAQと比べる、回答案を書く、担当者が確認するという作業があります。どこに時間がかかっているかを先に測ります。
質問の一覧を作るだけで足りるなら、利用中の問い合わせ管理機能や表計算で対応できるかを試します。個別開発を考えるのは、履歴と社内資料を突き合わせる、既存FAQの更新候補を出す、承認結果を残すといった工程が繰り返し発生する場合です。
生成した件数だけを成果にしないようにします。担当者が使える候補を確認し終えるまでの負担が減るかが、検証したい点です。
問い合わせ履歴と現在の回答根拠を用意する
準備するのは質問本文だけではありません。最終回答、対応が完了したかどうか、対象の商品やサービス、回答した時期をそろえます。途中の返信だけを取り出すと、後で訂正された案内を正解として扱ってしまいます。
| 準備する資料 | 確認すること |
|---|---|
| 問い合わせと対応履歴 | 最終回答、未解決の案件、訂正の有無 |
| 現在の案内・手順書 | 有効な版、適用条件、回答を確認する担当者 |
| 既存FAQ | 同じ内容があるか、古い記述があるか |
| 公開範囲のルール | 社内用か顧客向けか、記載できない情報は何か |
| 原稿の見本 | 質問文、回答、条件、確認日をどう表示するか |
候補作成に不要な氏名、連絡先、個別契約の情報などは、取り込み前に除くか置き換えます。社内向けのFAQでも、履歴を読める範囲と、作成した原稿を共有できる範囲を確認してください。
古い回答をそのままFAQへ移さず、現在の根拠資料と照合します。根拠が見つからない質問は保留へ回し、AIに不足する条件を補わせない設計にします。
似た質問でも条件が違えば分ける
表現が似ていても、対象商品、契約、利用環境によって答えが変わる質問があります。まとめる基準には質問文だけでなく、回答が適用できる条件を含めます。
件数を数える場合は、同じ問い合わせの追記や再送を重複して数えないようにします。たびたび現れる質問でも、特定の一案件でやり取りが長引いただけなら、全体で多い質問とは扱えません。質問の件数と、別々の案件の数を区別して記録します。
仮例：住所変更の質問に別の手順が含まれる場合
架空のサービスで、請求書の送付先変更と、商品の配送先変更が同じ窓口へ届くとします。どちらにも住所変更という言葉がありますが、受付先や期限が違うなら、別のFAQ候補にします。
PoCでは、正しく分けられるかを検証します。回答案には対象と条件を残し、二つの手順を混ぜた原稿は採用しません。実際の商品名や期限を使うときは、現在の案内資料を根拠にします。
回答案には確認できる根拠を付ける
候補には、元になった問い合わせの識別番号と、回答の根拠資料の該当箇所を付けます。質問の存在を確認する履歴と、現在の正しい回答を確認する資料は、役割が違います。
NISTの生成AIリスク管理資料でも、出力に含まれる情報源や引用を確認・検証することを挙げています。NISTの一次資料を踏まえ、リンクが付いているだけで承認せず、その箇所が回答の内容を支えているかを確認します。
既存FAQと同じ内容なら、新規作成の候補から外すか、更新候補として出します。新しい質問、既存記事の修正、根拠不足の保留を分けると、担当者が次の作業を判断できます。
承認した版だけを公開へ渡す
確認結果には、採用・修正・保留の区分、担当者、確認日を残します。承認後に回答案を作り直した場合は、変更した内容を再確認します。承認した原稿と公開する原稿が同じ版であることを確認する工程も必要です。
個別のお客様への特例を、全利用者向けの標準ルールへ変えていないかも確認します。答えが部門内で割れている場合は、担当者がルールを確定するまで公開候補から外します。
成功条件は採用できた候補と確認時間で測る
評価用の履歴には、既存FAQで足りる質問、答えが変わった質問、未解決の質問を含めます。候補を調整するために使う履歴と、最後の評価に使う履歴を分けてください。
人が同じ履歴から候補を作った場合と比べ、採用できた原稿数、条件を混ぜた件数、根拠が合わない件数、既存FAQとの重複を記録します。少数しか発生しないものの、案内が必要な質問を落としていないかも見ます。
時間は、履歴の準備、候補の確認、根拠の照合、修正まで含めます。原稿作成だけが速くなっても、確認に時間がかかるなら、対象範囲や出力形式を見直します。短いPoCで確認できるのは主に作成工程です。問い合わせ件数の減少は、公開後の利用状況を別に測って判断します。
開発費用とFAQ更新の担当を確認する
見積もりでは、履歴の取得元、対象件数、現在の資料の保管先、既存FAQとの比較方法を伝えます。承認画面や公開先への連携まで作るかも、開発範囲を変えます。最初は候補一覧と根拠を出すところに絞れます。
AiPHAのPoC開発サービスは、開発・検証20万円〜、10日でAIエージェントを納品する案内です。金額は対象業務と開発範囲に応じた見積もりです。履歴の取得や公開先との接続もこの条件にすべて含まれると決めず、範囲と納期を確認してください。AIサービス利用料などは別途確認します。
運用では、候補を見る担当者、回答根拠を承認する担当者、古くなったFAQを更新する担当者を決めます。規程や商品仕様が変わった際の見直しも必要です。継続保守や追加開発は、対応範囲と費用を別途確認します。
個別開発を急がない方がよい条件
履歴が少なく手作業で短時間に更新できるなら、専用開発を急ぐ必要はありません。未解決の問い合わせが多い、標準の回答ルールがない、原稿を承認する人がいない場合は、回答資料と担当を先に整えます。
AiPHAの30分の無料相談では、問い合わせの種類、現在のFAQ作成手順、確認に時間がかかる箇所をもとに、PoCで試す範囲を検討できます。機密情報を含む履歴の共有は、使用するデータと共有方法を確認してから進めます。