WordPressのトラブル対応は、多くの場合「過去に誰かが解決している問題」です。
しかし、その解決方法を探すためにフォーラムや記事を何度も検索するのは、意外と手間がかかります。
そこで今回は、WordPressフォーラムの「解決済みトピック」をナレッジとして蓄積し、チャット形式で検索・相談できる仕組みを構築しました。
このシステムは、RAG（Retrieval Augmented Generation）の仕組みを使い、過去の解決事例をもとに回答するチャットボットとして動作します。
こちらから体験することができます。
この記事では、このWordPressサポートチャットの技術構成と仕組みを紹介します。
システムの全体構成
今回構築したシステムは、以下の流れで組み立てました。
- WordPressフォーラムから解決済みトピックを特定
- WebページをMarkdownとして取得
- LLMで内容を整理・要約
- Difyのナレッジベースへ登録
- RAGによる検索と回答生成
- Web UIからチャットとして利用
これにより、WordPressのトラブル相談をチャット形式で行えるようになります。
WordPressフォーラムの解決済みトピックを収集
ナレッジの元データとして利用しているのは、WordPress公式フォーラムの「解決済みトピック」です。
WordPressフォーラムには、実際にユーザーが問題を報告し、解決に至った議論が多数蓄積されています。
これらは実際のトラブルシューティングの記録であり、RAGのナレッジとして非常に有用です。
これらのトピックURLをNode.jsのスクリプトで収集し、対象ページの一覧を作成します。
収集する対象は以下のようなページです。
- WordPressサポートフォーラム
- プラグインのサポートフォーラム
- 解決済みステータスのトピック
この段階ではURL一覧を取得するだけのシンプルなスクレイピングです。
FirecrawlでページをMarkdown化
収集したURLの内容は、そのままではRAGのナレッジとして扱いにくいため、Firecrawlを使用してMarkdownとして取得します。
Firecrawlは、Webページを構造化して取得できるクローリングツールです。
HTMLから不要な要素を除き、記事本文をMarkdownとして抽出できます。
この処理により、以下のようなメリットがあります。
- HTMLノイズの除去
- LLMが扱いやすい形式に変換
- 投稿内容をそのままテキスト化
フォーラムのスレッド内容をMarkdown形式で取得することで、後続の処理がシンプルになります。
Ollama（gpt-oss）で内容を整理・要約
フォーラムの投稿はそのままだと冗長なため、Ollamaで動作するgpt-ossモデルを使って内容を整理します。
主に以下の処理を行います。
- トラブルの内容の要約
- 解決方法の整理
- 不要な会話の削除
- ナレッジとして利用できる形への整形
この処理をローカルLLMで実行することで、大量のデータを低コストで処理できます。
要約されたデータは、RAG用のナレッジとして扱いやすい構造になります。
Difyのナレッジベースへ登録（親子チャンク）
整理されたデータは、DifyのAPIを使ってナレッジベースへ登録します。
登録は「親子チャンク構造」で行っています。
親チャンク
- トピック全体の要約
- 問題の概要
子チャンク
- 具体的な解決方法
- 設定変更の内容
- トラブルの詳細
この構造にすることで、検索時に以下のメリットがあります。
- 関連する情報をまとめて取得できる
- コンテキストが欠けにくい
- 回答の精度が上がる
RAGの品質は、このチャンク設計に大きく影響します。
OpenAI系APIで回答生成
ナレッジ検索後の回答生成には、OpenAI系のAPIを使用しています。
処理の流れは以下の通りです。
- ユーザーの質問を受け取る
- Difyがナレッジ検索を実行
- 関連するチャンクを取得
- LLMが回答を生成
この仕組みにより、LLMは「ナレッジに基づいた回答」を行います。
いわゆるハルシネーションを防ぐため、
回答はナレッジを優先するプロンプト設計にしています。
DifyのWeb UIをカスタマイズ
チャットのUIは、Dify公式の以下のリポジトリをベースにしています。
このリポジトリをforkして、以下の調整を行いました。
- UIの簡略化
- 説明文の追加
- サイトデザインへの統合
- アイコン画像の変更
これにより、Webサイトからそのままチャット相談が不自然にならないようにできるようになります。
Docker環境で自宅サーバー公開
システム全体はDockerで構築し、自宅サーバーで公開しています。
主な構成は以下です。
- Dify
- Ollama
- Firecrawl
- Node.jsバッチ処理
- Web UI
Docker Composeでまとめて管理することで、環境の再現性と運用のしやすさを確保しています。
また、自宅サーバーで運用することで以下のメリットがあります。
- LLM処理コストの削減
- データの完全管理
- システム構成の自由度
RAGを使ったサポートシステムの可能性
今回の仕組みは、WordPressフォーラムをナレッジとして利用していますが、同様の仕組みはさまざまな分野に応用できます。
例えば
- 社内FAQ
- サポート履歴
- 過去の問い合わせログ
- 製品マニュアル
こうした情報をナレッジ化することで、サポート対応の効率化が可能になります。
RAGは単なるAIチャットではなく、「過去の知識を活用する検索システム」としての価値が大きい技術です。
今回のWordPressサポートチャットは、その一例として公開しています。
興味がある方はこちらからご相談することができます。
まとめ
生成AIが話題になっていますが、自分としては最初、どの立ち位置で関わるべきか少し迷いがありました。
これまでWebサービスの公開や運用には慣れているものの、生成AIや機械学習のような新しい分野をどう活用すればよいのか、はっきりしたイメージが持てなかったためです。
そんな中で考えたのが、「検索」に近い用途でした。
RAGは、生成AIに必要な情報をベクトル検索で取り出し、その内容をもとに回答を生成する仕組みです。つまり、従来の検索に近い役割を持ちながら、対話形式で情報を提示できる技術とも言えます。
検索サービスの公開やデータ整理は、これまでの経験の中でも比較的得意としてきた領域です。そのため、RAGのような仕組みであれば、自分のこれまでの知識や技術とも相性が良いと感じました。
また、Webサービスとして形にして公開するところまでまとめ上げることも、これまで続けてきた強みの一つです。生成AIそのものを研究するというよりも、RAGを使った実用的なサービスとして形にしていく方向で取り組んでいこうと思っています。
今後もこのような取り組みを進めながら、実験や公開した内容については、また記事として共有していければと考えています。
コメントを残す