SLMで社内FAQを作ると、ChatGPTと比べて何が違いますか？

最大の違いは社内文書が外部に送信されない点です。ChatGPT APIを使うと質問内容がOpenAIのサーバーに送られますが、SLMを自社サーバーで動かす場合はデータが社内に留まります。ランニングコストもAPIの従量課金ではなくサーバー固定費のみになります。一方で初期構築にエンジニアリングの工数がかかります。

SLMのFAQボットが答えられない質問はどう対処しますか？

あらかじめ「わかりません」と答えるルールを設定し、人間の担当者へのエスカレーションフローを用意しておきます。RAGの知識ベースに含まれない内容や複雑な判断が必要な質問は自動でチケットを発行してSlackやメールで担当者に通知する構成が一般的です。

初期構築にどのくらいの期間と費用がかかりますか？

社内のエンジニアが構築する場合、最小構成（Ollama＋RAG＋基本のUIのみ）で1〜2ヶ月が目安です。社内文書の整備状況と連携システムの複雑さによって変わります。クラウドサーバーを使う場合の初期コストは数万円程度から始められますが、文書整備・テスト・維持管理の人件費が大きくなる場合があります。具体的な費用は構成と社内体制によって大きく変わるため、概算は構成を決めてから出すことをお勧めします。

SLMで社内FAQを自動化する手順と導入のポイント

結論：SLM＋RAGで社内FAQを自社サーバーに構築すると、APIコストゼロと情報漏洩リスクの低減を同時に実現できる

社内FAQをChatGPTで運用しているチームが直面しやすい問題が2つあります。一つは従量課金によるAPIコストが積み上がること、もう一つは社内の規程・個人情報・顧客情報を含む質問内容が外部サーバーに送信されることへの懸念です。

SLMと呼ばれる小型言語モデルを自社サーバーで動かし、RAGという仕組みで社内文書を参照させる構成を取ると、この2つの問題を同時に解消できます。ランニングコストはサーバーの固定費のみになり、質問内容は社内ネットワーク外に出ません。

初期構築には工数がかかりますが、月間のAPI利用料が数十万円規模になっている組織や、機密情報を含む社内文書をAIで扱いたい組織では、半年以内に初期費用を回収できるケースがあります。

なぜSLMで社内FAQを作るのか

社内FAQツールの選択肢として、SaaSのチャットボット製品・ChatGPT APIを使った構成・SLMをセルフホストする構成の3パターンがあります。

SaaSチャットボットは初期設定が早い反面、カスタマイズ性に限界があり月額費用が継続的にかかります。ChatGPT APIは柔軟ですが、前述のとおりデータの社外送信と従量課金が課題です。

SLMのセルフホスト構成の最大のメリットは、データが社内に留まることです。人事制度・就業規則・顧客対応マニュアルなどの機密文書を知識ベースに入れても、その内容は社内サーバーの中で完結します。情報セキュリティ部門が外部AIサービスの業務利用を制限している組織でも、セルフホスト構成であれば承認を得やすくなります。

APIコストの観点では、月に10万回の質問応答をChatGPT APIで処理する場合の費用と、同等の性能のSLMを社内サーバーで動かす場合の固定費を比較すると、後者が安くなる分岐点は組織の利用規模によって変わります。SLMとAPIコストの比較で計算方法を解説しています。

全体のシステム構成

社内FAQボットの標準的な構成は以下のとおりです。

SLM（言語モデル）: 自然言語での質問を受け取り、回答文を生成する役割を担います。Phi-4 Mini・Gemma 3・Llama 3.2などが選択肢で、日本語精度・サーバースペック・ライセンスを考慮して選びます。

RAG（検索拡張生成）: ユーザーの質問に対して、関連する社内文書の断片を検索データベースから取り出し、それをSLMへの入力に追加する仕組みです。SLMは自分の学習データだけでなく、取り出した社内文書を参照しながら回答を生成します。これにより、SLMが学習していない社内固有の情報（入社後の手続き・自社の製品仕様・今期の経費精算ルールなど）に答えられるようになります。

ベクトルデータベース: 社内文書を検索可能な形で格納するデータベースです。文書をチャンク（数百文字程度の断片）に分割してベクトル化し、意味的に近い文書を検索できるようにします。代表的なツールにChromaDB・Weaviate・pgvector（PostgreSQLの拡張）があります。

フロントエンド: 従業員が質問を入力するUIです。SlackやMicrosoft Teamsのボットとして実装するか、社内Webシステムにチャット画面を組み込む形が多いです。

この構成の全体像を図示すると以下のとおりです。

ユーザーが「在宅勤務の申請手順は？」と質問する
RAGが質問文をベクトル化し、関連する就業規則の断片を検索する
SLMが「質問＋関連文書の断片」を受け取り、回答文を生成する
生成された回答をユーザーに返す

RAGの仕組みについてはRAGとは何か・なぜ必要かで詳しく解説しています。

導入の4ステップ

ステップ1：FAQ収集と文書整備

RAGの精度は知識ベースに入れる文書の質に大きく依存します。まず現在の問い合わせ対応の記録を確認し、過去6ヶ月間に5件以上繰り返されている質問を抽出します。HR部門なら「有給の残日数の確認方法」「育児休業の取得条件」、IT部門なら「VPNの接続方法」「社内Wi-Fiのパスワード再発行手順」などが典型的なパターンです。

これらの質問に対応する社内文書を特定し、最新版であることを確認します。古い情報や矛盾する情報が知識ベースに混在すると、FAQボットが誤った回答を生成する原因になります。文書が分散しているなら、まずSharePointやNotionなど一箇所に集約する作業から始めます。

最初は50〜100文書から始め、精度を確認しながら追加していく方が管理しやすいです。

ステップ2：モデル選定

SLMの選定では、日本語精度・動作に必要なサーバースペック・ライセンス・エコシステムの4点で評価します。

日本語FAQを主な用途とするなら、日本語での性能を評価する必要があります。Llama 3.2 3Bの日本語追加学習版・Phi-4 Mini・Gemma 3 4Bを実際に同じ質問で試し、回答の自然さと正確さを比較するのが最も確実です。

サーバースペックは、量子化された3〜4Bモデルであれば16GB RAMのクラウドインスタンスで動きます。AWS・GCP・Azureで16GB RAM・4コアのインスタンスを使う場合、月額費用は1万〜3万円程度が目安です（リージョン・スポット利用の有無によって変わります）。

ステップ3：RAG構築

RAGの実装は、PythonのライブラリであるLangChainまたはLlamaIndexを使うと工数を削減できます。

基本的な実装の流れは以下のとおりです。

社内文書をPDF・Word・テキスト形式で取り込む
文書を500〜1000字程度のチャンクに分割する
Embeddingモデルを使って各チャンクをベクトル化してChromaDBに格納する
ユーザーの質問をベクトル化し、コサイン類似度で上位3〜5チャンクを取得する
取得したチャンクをプロンプトに追加してSLMへ送る

Embeddingモデルは別途必要で、OpenAIのEmbedding APIを使うと外部送信が発生します。完全にオフラインで動かしたい場合は、multilingual-e5-largeやparaphrase-multilingual-mpnet-base-v2などのローカルで動くEmbeddingモデルを使います。

ステップ4：テストと精度改善

本番運用前に、100問程度のテストセットで精度を評価します。回答が正しいかどうかを確認し、誤答のパターンを分類します。

よくある誤答のパターンとその対処は以下のとおりです。

関連文書が取得できていない: チャンクのサイズやEmbeddingモデルの選択を見直します。質問文と文書の表現が異なる場合（「有給」と「年次有給休暇」など）、シノニム辞書を追加するか、検索クエリを拡張する処理を入れます。

関連文書は取得できているが回答が不正確: SLMへのプロンプトを改善します。「以下の文書のみを根拠に回答してください。文書に記載がない場合は『わかりません』と回答してください」のような指示を追加することで、モデルが知識ベース外の情報を使って回答することを抑制できます。

回答が長すぎる・短すぎる: プロンプトで回答の長さを指定します。「200文字以内で」「箇条書きで3点以内に」のような制約を追加します。

実際の精度と限界

SLMとRAGの組み合わせが得意なのは、「知識ベースに含まれる情報を検索して整理して返す」タスクです。手続き・規程・マニュアルに基づく定型的な質問への回答はよく機能します。

一方で以下のような質問はSLMが苦手で、人間へのエスカレーションが必要です。

複数の規程が絡み合い、解釈が必要な質問（例：「育児休業取得後の有給残日数の計算は？」）
知識ベースに情報がない最新の状況に関する質問
感情的なサポートが必要な相談（ハラスメント・健康相談など）
正解が一つでない判断を求める質問

FAQボットが「わかりません」と答えた質問を記録し、定期的に人間が確認してQAを追加することで、精度は徐々に向上します。最初から完璧を求めず、6ヶ月かけて知識ベースを育てるサイクルを組み込む設計が現実的です。

費用感

社内FAQボットの費用は、初期構築コストとランニングコストに分かれます。

初期構築コスト: 社内エンジニアが担当する場合は工数のみです。最小構成（Ollama＋RAG＋Slack連携）であれば1〜2人月が目安になりますが、文書整備の状況・既存システムとの連携・テスト期間によって変わります。外部のベンダーに依頼する場合は100〜500万円程度の幅があります（構成と要件による）。

ランニングコスト: クラウドサーバー費用が主なコストです。16GB RAMのインスタンス1台を常時起動する場合、月額1〜3万円が目安です（AWS・GCP・Azureのリージョンと契約形態によって変わります）。APIの従量課金がなくなるため、利用頻度が高い組織ほどコスト優位が大きくなります。

ChatGPT APIと比較した場合の損益分岐点を計算するには、現在のAPI利用量（月間トークン数）を確認し、SLMのサーバーコストと比べます。詳細な計算方法は生成AI導入の費用対効果で解説しています。

具体的な導入事例パターン

HR部門：入退社・勤怠・福利厚生の問い合わせ対応

HR部門に最も多い定型的な問い合わせ（「有給の残日数の確認方法」「育児休業中の給付金の計算方法」「慶弔休暇の取得条件」など）をFAQボットで自動化したパターンです。

就業規則・育児介護休業規程・福利厚生ハンドブックなど10〜20文書を知識ベースに入れ、Slackのbotとして実装します。HR担当者が1日に対応していた定型問い合わせを30件から8件に削減できた事例があります。数字は構成と文書の品質によって大きく変わります。

IT部門：社内システムのサポートデスク

「VPNに繋がらない」「ファイルの共有権限を変えたい」「社内ツールのパスワードをリセットしたい」などの問い合わせはパターンが限られており、FAQボットとの相性が良いです。

操作マニュアル・トラブルシューティングガイドを知識ベースに入れ、解決できた問い合わせは自動クローズ、解決できなかったものはチケット発行してエンジニアに割り当てる構成を取ります。

営業部門：製品仕様・価格・競合比較の問い合わせ

営業が顧客訪問前に社内Slackで「製品Aと製品Bの違いを教えて」「この機能の価格はいくらか」と質問するケースに対応します。製品仕様書・価格表・競合比較資料を知識ベースに入れ、外出先からスマートフォンで質問できるようにします。

価格情報は変更が頻繁なため、知識ベースの更新ルールを明確にしておく必要があります。古い価格が表示されると営業上のトラブルになるため、定期的な文書同期の仕組みを入れることが重要です。

導入時の注意事項

文書の著作権と利用許諾: 外部から取得した文書をRAGの知識ベースに入れる場合、その文書の利用規約を確認してください。社内で作成した文書であれば問題ありませんが、ベンダーの製品ドキュメントや業界団体の資料などは利用条件が異なります。

個人情報の取り扱い: 知識ベースに従業員や顧客の個人情報が含まれる文書を入れる場合は、個人情報保護法への適合を確認します。誰がどの質問をしたかのログも個人情報になり得るため、ログの保存期間と閲覧権限の設計が必要です。

回答の免責事項: FAQボットの回答は参考情報であり、法的・医療的な判断の根拠にしないことをユーザーに明示することを推奨します。

SLMをオンプレで動かすメリットと注意点では、自社サーバーでSLMを運用する際のセキュリティ設計と運用体制の整え方を詳しく解説しています。

まとめ

SLMとRAGを組み合わせた社内FAQボットは、APIコストを削減しながら社内情報の社外送信リスクを排除できる構成です。導入は4ステップで進め、最初の50〜100文書から始めて精度を確認しながら段階的に拡張するのが失敗を防ぐ進め方です。HR・IT・営業のどの部門でも定型問い合わせを絞り込んで小さく始め、成果を確認してから他部門へ横展開するアプローチが実務上うまくいきやすいです。