本稿では、カスタマーサポートシステム向けの「AIチャットボット」を開発する際、その中核機能である「知識ベース（ナレッジベース）」をどのようなアーキテクチャで構築すべきか、その選定プロセスと思考の軌跡、そして具体的な実装方法について紹介します。
はじめに
AIの潮流が押し寄せる中、これからのカスタマーサポートソフトウェアにとって AIチャットボット機能の実装は、もはや「あれば便利なオプション」ではなく「必須条件」となっています。システムにAI機能を組み込むには、主に以下の3つのアプローチが考えられます。
- AIプラットフォームのクラウドサービスを全面的に利用する
ユーザーの知識ベースを外部のAIプラットフォームにアップロードし、訪客からの質問に対してAPI経由で回答を生成する方式。 - Difyなどの私有化（セルフホスト型）AIプラットフォームを構築する
自前の環境にDify等を立て、システム間連携によってAI機能を実現する方式。Difyとは： オープンソースのLLMアプリ開発プラットフォーム。生成AIアプリの開発・デプロイを簡素化し、ユーザーフレンドリーなUIと強力なツール群を提供することで、開発者が迅速に商用レベルのAIアプリを構築できるように設計されています。
- AI機能を完全に内蔵する
知識ベースのベクトル化と検索（RAG）を自前で実装し、オープンソースモデルを直接呼び出す機能をシステム内部に組み込む方式。
各アプローチの課題
まず 1. クラウドサービス利用案 ですが、これは最も軽量で実装も容易です。しかし、私の掲げる「100%プライベートデプロイ」「データへの完全な主権（ローカル保存）」という方針と真っ向から対立します。政府、金融、保険といったデータの機密性を最優先するユーザーにとって、外部へのデータ流出は受け入れがたいリスクです。
次に 2. Difyなどの構築案 ですが、多くの小規模チームや中小企業にとっては「重すぎる」のが難点です。専門のIT担当者がいない組織にとって、これほど複雑なシステムをデプロイ・運用するのはハードルが高すぎます。また、モデルの推論のためにGPU搭載サーバーを用意しなければならない点も大きな負担となります。
最後に 3. AI機能の完全内蔵案 です。開発コストが高いことに加え、これも小規模チームにとっては導入の難易度を跳ね上げます。ベクトル検索をサポートするデータベースなどの外部コンポーネントを別途デプロイする必要があり、さらに推論用のGPUサーバーも必要になります。これでは、手軽に導入できるとは言い難いのが現実です。
現状と目標
ここで、私の目標に立ち返ってみます。「安全・安定・信頼、そして軽量かつプライベートデプロイ可能なカスタマーサポートシステム」の開発です。
あえて「軽量」という言葉を強調したのは、これまでの開発過程で、数人、あるいは一人だけで運営している非常に多くの小規模チームと接してきたからです。彼らの多くは、既存の企業サイトやアプリにシンプルなサポート機能を組み込み、見込み客と基本的なコミュニケーションを取り、確実に成約に結びつけたいと考えています。しかし、複雑なシステム説明や専門用語を目にした瞬間、導入を諦めてしまうのが現実です。彼らが求めているのは、どこまでも「シンプル」であることなのです。
特にこうした小規模チームがプライベートデプロイを行う際、高額なサーバー費用や帯域コストを捻出できないケースも少なくありません。中には、既存のWebサーバーに相乗りでデプロイしたり、クラウドベンダーのセールで購入した格安の「2vCPU / 4GBメモリ」といった環境で運用したりするユーザーが大多数を占めます（ただし、環境が最小限だからといって、システムの安定性や安全性に妥協があるわけではありません）。
したがって、前述の案2（Dify等の構築）と案3（フル内蔵）は、選択肢から外れます。これらを選ぶことは、大多数の小規模ユーザーを切り捨てることを意味し、それは私にとってあり得ない選択です。
消去法で行けば、残るは案1の「AIプラットフォームのクラウドサービスを全面的に利用する」方法のみに見えます。
しかし、AIチャットボットの本質は、単にAIモデルと雑談することではありません。「注文方法は？」「商品は何日で届く？」といった、ユーザー独自の知識ベース（ナレッジベース）に基づいて訪客と対話することにあります。
この橋渡し役となるのが「知識ベース」です。クラウドサービスに完全に依存する場合、ユーザーはすべての社内ドキュメントをパブリッククラウドにアップロードしなければなりませんが、これは多くのユーザーにとって受け入れがたい条件です。昨今の情報セキュリティに対する意識の高まり、特に政府、金融、保険などの分野において、「データのクラウド化」は検討の遡上にすら載らない（即座に却下される）問題だからです。
そこで、もう一つの前提条件が浮上します。**「知識ベースは100%ユーザーのローカルデータベースに存在しなければならない」**ということです。
最も現実的な折衷案はこうです。訪客が AI チャットボット機能を利用する際、まずローカルデータベース内の知識ベースを検索し、その内容をもとにプロンプトを構成した上で、AI プラットフォームの機能を呼び出すという形です。これは案 1 とは異なり、知識ベースをどこかの企業のプラットフォームに丸投げして管理させるのではなく、純粋に ChatGPT や Gemini の API を呼び出すだけで完結します。
ローカル知識ベースの管理
このプランの核心は、「いかにしてローカル知識ベースを構築・管理するか」に集約されます。
ベクトルデータベースによる管理が最良の選択ではありますが、前述した通り、プライベートデプロイにおいては「ユーザーの導入負担を増やさない軽量さ」が絶対条件です。
そこで、私の構想はまず以下のような構成に固まりました。
「ローカルデータベース ＋ 全文検索 ＋ Top N件の抽出 ＋ プロンプトの構成」
全文検索の成熟したソリューションは多々あります。
- Elasticsearch： 業界のデファクトスタンダード。分散型アーキテクチャで、大規模クラスターやシャード、レプリカを標準でサポート。
- OpenSearch： Elastic社のライセンス変更に伴い、AWSがElasticsearchからフォークしたオープンソース版。
- Solr： 老舗の選択肢。精密な分詞や伝統的なテキスト検索には強みがあるものの、拡張性はESに劣る。既存プロジェクトの保守を除けば、新規で選ばれることは少なくなった。
- その他： Meilisearch（Rust製）、Typesense（C++製）など。
かつて私が企業の一員としてプロジェクトに携わっていた頃なら、迷わず Elasticsearch を導入していたでしょう。当時のプロジェクトには大きなクライアントがいて、数千万円規模の予算があり、潤沢なサーバーリソースと熟練の運用チームが揃っていたからです。
しかし、今の私にはそれらがありません。私がサポートすべき小規模チームにとって、プライベートデプロイの際に Elasticsearch のような「重火器」を持ち出すのは、あまりに現実離れしています。
窮地を救う選択肢
このジレンマをどう解決すべきか。再び現状に立ち返ってみると、小規模チームが管理するAI知識ベースには、ある顕著な特徴があることに気づきました。それは「知識ベース自体の規模も比較的小さい」ということです。
「数万件、数十GBのドキュメントを数ミリ秒で検索できる」と豪語したところで、彼らにとっては別世界の住人の話にしか聞こえません。
小規模チームの知識ベースは、通常、数十件程度。数百件に達することすら稀です。ここで改めて、条件とニーズを整理します。
- データは 100% ローカル化されている必要があります： 具体的には「ローカルデータベース ＋ 全文検索 ＋ Top N 件の抽出 ＋ プロンプトの構成」というスキームを採用し、生成されたプロンプトを ChatGPT や Gemini といった AI モデルに送信する形をとります。
- 徹底した軽量化： デプロイの負担を一切増やさない。数百件程度のドキュメントを検索できれば十分。
この条件をすべて満たす、唯一にして成熟した選択肢。それが Lucene でした。
Lucene なら独立したサービスをインストール・デプロイする必要がなく、依存関係もゼロです。サーバーのメインプログラムに直接組み込めるため、ユーザーはプライベートデプロイの際にその存在を意識することすらありません。
実際のところ、Lucene は決して「非力」ではありません。100万〜1,000万件程度のドキュメント数であれば、クエリの遅延は通常 10〜50ms 程度に収まります。小規模ユーザーの数十件、数百件程度のドキュメントを処理するなど、Lucene にとっては「朝飯前」どころか、あまりに余裕すぎる仕事なのです。