「サポートのチャットボットは、もう自社で作れるのではないか」。生成AIとRAG（検索拡張生成）が普及したいま、この問いを持つのは自然なことです。実際、LLMのAPIとナレッジ検索を組み合わせれば、動くチャットボットは数時間から数日で作れます。作れるかどうかは、もう論点ではありません。

しかし、動くものが作れることと、問い合わせを解決し続けるものが運用できることは、別の問題です。私たちが見てきた内製プロジェクトの多くは、構築でつまずくのではなく、公開後の「育てる」段階で止まります。この記事では、内製の7ステップを実務の順番で解説したうえで、本当に難しいのはどこか、そして内製とSaaSをどう使い分けるべきかまで踏み込みます。

全体像：7ステップと「育てるループ」

先に全体像を示します。前半のステップ1〜2が設計、3〜5が構築、6〜7が運用の入り口です。

注目してほしいのは、ステップ7からステップ3へ戻る点線の矢印です。チャットボットは一直線に完成するものではなく、未解決の問い合わせログをナレッジに還流させるループを回し続けることで初めて成果が出ます。

ステップ1：問い合わせを分析し、対象範囲を決める

最初にやるべきことは、ツール選定でもプロンプト作成でもなく、自社の問い合わせの分析です。

直近3〜6ヶ月の問い合わせログを取り出し、コンタクトリーズン（問い合わせ理由）ごとに分類して件数を数えます。多くのサポート組織では、上位2割の問い合わせ理由が全体の7〜8割を占めます。

そのうえで、ボットに任せる範囲と任せない範囲を決めます。パスワード再設定や配送状況の確認のような、答えが一意に決まる定型の問い合わせから始めるのが定石です。逆に、解約の引き止め、クレーム、契約条件の交渉といった判断や感情を伴う問い合わせは、初期リリースでは対象外と明記します。

ここで「何をやらないか」を決めておくことが、後続のすべてのステップの分母を小さくします。

• 例（架空のアパレルEC・A社）：

  直近3ヶ月・約9,000件のログを分類すると、「配送状況の確認」「返品・交換の手順」「サイズ表の見方」など上位8つの理由で全体の75%を占めていた。このうち判断の要らない6つを対象とし、返金交渉とクレームは対象外と明記した。

ステップ2：うまくいかない時の体験を設計する

構築に入る前に、もう1つ決めるべきことがあります。ボットが答えられなかった時に何が起きるか、です。

理想的にうまくいく対話は、いまのLLMなら簡単に実現できます。

差がつくのは失敗時です。ナレッジで答えが見つからなかったら、正直に「わからない」と言うのか、有人チャットに引き継ぐのか、問い合わせフォームに誘導するのか。「人に代わって」と言われたら即座に応じるのか。営業時間外はどうするのか。

これらはプロンプトの書き方の問題ではなく、業務としてどう振る舞うべきかの意思決定です。

あわせて、成功を測るKPIもここで定義します。推奨は自己解決率（ボットだけで問い合わせが完結した割合）と回答正答率の2つです。この設計を文書にして関係者と合意しておくと、後の評価・改善の基準がぶれません。

• 例：
  A社は「検索でヒットしなければ推測せず、問い合わせフォームへ誘導する」「『人に代わって』には営業時間内なら即座に有人チャットへ、時間外はフォームへ」と決め、初年度のKPIを自己解決率40%と置いた。

ステップ3：ナレッジを整備し、「正」を1つにする

RAGの回答品質は、モデルの賢さよりもナレッジの質で決まります。内製プロジェクトで最も時間がかかるのは、実はこのステップです。

整備を始める前に、切り分けておくべき問いが1つあります。

その問い合わせは、ナレッジだけで自己解決に導けるか。「返品期限は何日か」はナレッジで解決します。しかし「私の注文はいまどこにあるか」は、どれだけFAQを磨いても解決しません。

必要なのは本人確認と注文システムへの照会、つまり個人の特定と手続きの自動化であり、これはナレッジではなくシステム連携の領域です。FAQベースで解決しない問い合わせは、最先端のAIを持ってきても解決しない。ここを混同すると、「ナレッジを増やしたのに自己解決率が上がらない」という迷路に入ります。

ナレッジで解けるものに集中し、個人特定と手続きが必要なものは、連携を作り込むか初期は対象外とするかを先に決めておきます。

そのうえで、ナレッジ整備でやることは3つです。

第一に、既存のFAQ・マニュアル・社内ドキュメントを棚卸しし、対象範囲（ステップ1）に対応するものを集める。

第二に、同じ質問に対して矛盾する記述がないかを確認し、正しい情報源を1つに定める。古いマニュアルと新しいFAQで返品期限が食い違っている、という状態のままRAGに投入すると、ボットはどちらかをランダムに引いて答えます。

第三に、1つのドキュメントには1つのトピックだけを書くように分割する。「よくある質問まとめ」のような長大なページは、検索の精度を大きく下げます。

そして重要なのは、各ナレッジに更新責任者を決めておくことです。料金改定や仕様変更のたびに誰が直すのか。これが決まっていないナレッジは、公開の日から劣化が始まります。

• 例：
  棚卸しの結果、返品期限が旧マニュアルでは14日、新FAQでは30日と食い違っていた。
  A社は現行規約の30日を「正」と定めて旧マニュアルを廃棄。「返品・交換まとめ」の長大ページは「返品期限」「返品送料」「交換手順」など12本の短い記事に分割し、それぞれにCS企画の担当者を更新責任者として割り当てた。

ステップ4：RAGの最小構成で組み立てる

ここから技術の話に入ります。ただし、最初から凝る必要はありません。RAGチャットボットの最小構成は次の4層です。

1. LLM API：
   回答文を生成する本体。Claude、GPT、Geminiなどの商用APIを使うのが標準です。自社でモデルをホスティングする選択肢もありますが、初期構築でその必要が生じることはまれです
   
   

2. 埋め込み（Embedding）とベクトルDB：
   ナレッジを数値ベクトルに変換して格納し、質問と意味的に近い文書を検索します。PostgreSQLのpgvector拡張やマネージドのベクトルDBが一般的です
   
   

3. チャンク分割：
   ナレッジを検索単位に切る処理です。1チャンクは数百文字程度、見出しや段落の意味の切れ目で分割するのが基本です。ここの設計が検索精度に最も効きます
   
   

4. アプリケーション層：
   質問受付→検索→プロンプト組み立て→生成→回答表示、の一連の流れを制御します。LangChainやLlamaIndexのようなフレームワークを使っても、素のAPI呼び出しで書いても構いません

精度が足りない場合の改善手段として、キーワード検索とベクトル検索を併用するハイブリッド検索や、検索結果を並べ直すリランキングがあります。ただしこれらは、まず最小構成で動かして正答率を測ってから足すべきものです。最初から全部盛りにすると、どこが効いているのか分からなくなります。

• 例：
  A社はLLMに商用API、ベクトルDBは使い慣れたPostgreSQLのpgvectorを選択。
  FAQ約300記事を見出し単位・平均400字のチャンクに分割し、「質問を受け取る→上位5件を検索→回答を生成する」だけの最小構成を、まず2週間で動かした。

ステップ5：エージェント作業手順書を書く

システムプロンプトというと、短い命令文を想像するかもしれません。しかし実務で機能するのは、新人オペレーターに渡す業務マニュアルに近い文書です。

私たちはこれをエージェント作業手順書と呼んでいます。エージェントの役割定義から、対応範囲、行動手順、回答形式、禁止事項までを1つの手順書として書き上げ、それをそのままシステムプロンプトにする、という考え方です。

手順書で定義すべきことは、大きく4つです。

役割と口調（自社のトーンに合わせる）、行動手順（「必ず検索を実行し、提供された情報に基づいてのみ回答する」のように、回答までの手順と根拠の範囲を固定する）、わからない時・対応範囲外の時の振る舞い（ステップ2で決めた通りに、案内の定型文まで書いておく）、そして禁止事項です。

禁止事項はガードレールとして明文化します。

返金や補償の約束をしない。医療・法律に踏み込む断定をしない。個人情報を尋ねすぎない。プロンプトインジェクション（「これまでの指示を無視して」のような入力）への耐性も、この段階でテスト項目に入れておきます。

回答には引用元のナレッジへのリンクを添えると、ユーザーが自分で確認でき、誤答時の被害も抑えられます。

• 例：
  A社の作業手順書は「あなたはA社の問い合わせ対応担当です」という役割定義に始まり、「必ず検索してから回答する」「返金・補償の約束をしない」「答えられない時はこの定型文を使う」までを1つの文書にまとめた。出来上がりは、新人オペレーター向けマニュアルの目次とほぼ同じ構成になった。

ステップ6：評価セットで正答率を測る

「なんとなく良さそう」で公開してはいけません。

ステップ1で分析した実際の問い合わせから100問程度を抜き出し、模範回答とセットにした評価セットを作ります。これに対してボットの回答を採点し、正答率を測ります。

採点は人手でやるのが基本ですが、LLMに採点させる方法（LLM-as-a-Judge）を併用すると、作業手順書やチャンク設計を変えるたびに自動で再評価できるようになります。

この「変更→再評価」の仕組みを最初に作っておくことが、公開後の改善速度を決めます。合格ラインの目安は、対象範囲内の質問で正答率9割です。届かない場合、原因はたいていモデルではなくナレッジ（ステップ3）にあります。

• 例：
  実ログから100問を抜き出し、CS責任者が模範回答を付けた。
  A社の初回の正答率は71%。誤答は返品関連のナレッジの抜けに集中していたため、記事を12本追加して再評価すると88%まで改善した。モデルは一度も変えていない。

ステップ7：小さく公開し、ログで育てる

公開は小さく始めます。特定のカテゴリのページだけ、あるいは社内向けだけに限定して出し、実ユーザーの質問ログを集めます。

想定していなかった聞き方、答えられなかった質問、途中で離脱された対話。この未解決ログこそが、次に整備すべきナレッジのリストです。

週次で未解決ログをレビューし、ナレッジを追加・修正し、評価セットに新しい質問を足す。

このループを回した分だけ自己解決率は上がっていきます。逆に言えば、このループが止まったチャットボットは、世の中の変化に置いていかれて静かに使われなくなります。

• 例：
  A社はまず「返品・交換」カテゴリのページだけにボットを公開。
  2週間の質問ログから「コンビニ受け取りに変更したい」という想定外の頻出質問が見つかり、ナレッジと評価セットに追加した。
  この週次レビューを回しながら、1ヶ月後に全カテゴリへ展開した。

内製の壁は「8歩目」にある

動くものは数時間から数日で作れても、ナレッジ整備や評価まで含めたここまでの7ステップには、エンジニア1〜2名で数週間から数ヶ月かかります。内製の本当の壁はその先、ステップ7のループを何年も回し続ける段階にあります。

具体的にはこうなります。立ち上げたエンジニアが異動し、作業手順書とチャンク設計の意図が失われる。

ナレッジ更新が「余裕がある時にやる仕事」に格下げされ、正答率が季節ごとに下がる。LLMのモデルが更新されるたびに挙動が変わり、リグレッションテストと調整に想定外の工数が発生する。

どれも技術的には解決可能ですが、解決し続けるには専任に近い体制が必要です。作るのは1回のプロジェクトですが、育てるのは終わりのない業務です。内製を検討するなら、構築の工数ではなく、この運用体制を確保できるかを先に問うべきです。

内製かSaaSかを分ける4つの判断軸

内製とSaaS、どちらが正しいという話ではありません。判断軸は次の4つです。

1. エンジニアリソースの常設：
   構築時だけでなく、運用フェーズに継続的にエンジニアを割り当てられるか。割り当てられないなら、運用の仕組みが製品側に組み込まれているSaaSに分があります
   
   

2. 問い合わせの変化頻度：
   商品やキャンペーンの入れ替わりが激しいほどナレッジ更新の負荷が上がり、更新運用の仕組みの差が効いてきます
   
   

3. 要件の特殊性：
   基幹システムとの深い連携や特殊な業務フローなど、汎用製品で吸収できない要件が中核にあるなら内製の価値が出ます
   
   

4. コスト構造：
   内製は初期が重く運用も人件費が続く、SaaSは月額が続く。3年の総所有コストで比べると、直感と逆の結果になることがよくあります

実務では二者択一でもありません。社内向けは内製で経験を積み、顧客向けはSaaSで運用ごと任せる、といった併用は現実的な解です。

私たちは「育てる体制」こそが本体だと考える

私たちは、チャットボットの本体はモデルでもプロンプトでもなく、ナレッジを正しく保ち続ける運用のループだと考えています。

だからこそ、内製という選択肢を否定しません。この記事の7ステップを実際にやり切った組織は、ナレッジ運用の筋力がつき、どのツールを使っても成果を出せるようになります。

一方で、その運用ループを自社で回し続けることが難しいなら、ループそのものを製品として提供するSaaSに任せるのは、撤退ではなく合理的な設計判断です。

あなたの組織が確保すべきなのは、チャットボットを作る技術でしょうか。それとも、答えを正しく保ち続ける体制でしょうか。内製を検討しているすべてのチームに、この問いを置きたいと思います。

運用ループまで含めたAIチャットボットの設計に関心のある方は、お気軽にお問い合わせください。