はじめに
現在、弊社では全社向けにkeelaiという内製のAIアシスタントを提供・運用していて、主にSlack botとして社内提供しています。2023年に発足したもので、keelaiプロジェクトの詳細はこちらです。
このプロジェクトの開発当初からの課題の一つとして、「社内ドキュメントを検索しても、欲しい情報がAIにヒットしない（見つからない）」というものがありました。つまり「RAG（Retrieval-Augmented Generation）の検索精度」の問題ですが、利用者からすればシンプルに「このAI、私の知りたいことを分かってくれない」という微妙な体験になってしまいます。
この記事では、keelaiが社員の質問に的確に答えられるようにするため行なった、「技術的な実装」と「泥臭い運用」の両面からのアプローチを紹介します。
全体像：ただの検索ではなく調査エージェントへ
まず、keelaiの裏側では、単にキーワードで検索するだけでなく、ResearchAgentというモジュールが動いています。これは、ユーザーの問いに対してAIが「この質問なら、このソースのドキュメントを探すべきだな」と自律的に判断し、何度か検索クエリなどをリトライしながら調査するようなものです。
しかし、いくらAIが優秀でも、検索対象となるデータ（Source）が整理されていなければ答えは見つかりません。そこで、以下の4つの施策を行いました。
取り組み①：FAQサイトのデータに言い換え（paraphrasing）を用意する
課題
開発チームでは社内FAQサイトも用意していて、その情報が最も信頼できる情報源となっています。FAQ管理はスプレッドシートで行い、そこからGitHubのプルリクエストが定期的に出力され、それがマージされればシステムに取り込まれる仕組みを構築しました。これによって各バックオフィス部署を巻き込んで一緒にFAQの整備できるようにしています。
例えば、「PCのパスワードリセット」という項目があっても、ユーザーは「ログインできない」「パスワード忘れた」と入力します。これではAIが見つけられないこともありました。
解決策：paraphrasing（言い換え）の大量登録
FAQに対してparaphrase（言い換え）を用意し、どんな聞き方をされてもヒットするようにしました。「自動生成」と「手動補正」のハイブリッドで、検索の網羅性を高めています。
具体的にはparaphrasingの項目が空の場合（初回登録時）にGitHub Actionsで自動生成するようにしていて、後から手動でも追加できるようにしています。これである程度安定して社内の質問に回答できるようになりました。
取り組み②：長いドキュメントを要約して見つけやすくする
課題
Confluenceなどの社内Wikiにある長い仕様書や議事録。これらはRAGに取り込む際に細かく分割（チャンク化）されます。しかし、細切れにされると「ドキュメント全体の文脈」が失われ、「〇〇プロジェクトの概要を知りたい」といった大枠の質問に答えられなくなってしまいます。
解決策：「#summary」による全体像の提示
ドキュメントを取り込む際、ページ全体の要約（Summary）をAIに生成させ、それを #summary というタグ付きで登録しました。これにより、「〇〇プロジェクトって何？」といった全体像を問う質問に対し、まずはこの「要約」がヒットし、そこから詳細情報へ案内できるようになりました。
取り組み③：「社内用語集」への追加
課題
社内特有のプロジェクト名、略語、チーム名ってけっこうありますよね？これらは一般的なAIが最も苦手とする「未知の単語」です。
解決策：泥臭い手動登録
「社内用語集」を作成し、FAQと同様の仕組みで検索対象に加えました。技術的な解決策ではなく、非常に泥臭い運用でカバーしています。
- 全社総会を聞きながら、出てきた新単語やプロジェクト名をその場で辞書登録する
- Slackで飛び交う新しい略語を見つけたら即登録する
検索機能（ResearchAgent）を実装した手前、普段の社内の話題でもこれ検索できないなと思うようなワードが気になってしまうようになり、コツコツ追加していってました（笑）。特に総会などでは「そういえばこれって新入社員にはわからない単語だな」という単語をエンジニアらしからぬ一日数件程度ずつ追加していったところ、登録数はついに1000語を超えました。
全社レベルや、特に私が触れる機会の多いエンジニア関連の情報で話題になっているものはほとんどのケースで網羅できているかなと思います。（…って思っていても毎日数件ずつ見つかるんですが…ｗ）
取り組み④：ソースごとの信頼度を明示してAIの検索時に考慮させる
課題
社内FAQや用語集などの信頼できる情報源を用意しても、それより議事録やSlackの対話ログなどが優先されてしまうケースがありました。
解決策：プロンプトで「情報の信頼度」を指示する
データセットを整備した上で、それを使うAI（ResearchAgent）にも工夫を凝らしています。具体的には、プロンプト（AIへの指示書）で「どの情報源を優先して調べるべきか」を明確に指示しています。
以下は実際の指示内容の一部です。
Source to search. Try from top to bottom of the list in order of reliability.
1. S3 (Official FAQ / Glossary)
2. GitHub (Engineering / Products / System Specifications)
3. Confluence (General Documents but contains miscellaneous and outdated content)
4. Slack (Conversations / Official Announcement)
...
8. null (means all sources)
内容を解説すると、次のような点を意識しています。
- 信頼度順に検索: 公式FAQや用語集を最優先し、まずは「確実な概要」を取得させます
- 補足情報の活用: またGitHubやSlack、Confluenceなどは相対的に優先度を下げ、「開発系の内容ならGitHub」「（自社の運用では）社内の公式のアナウンスはSlackにある」など文脈に応じて検索させて「補足情報」として扱うよう指示しています
これにより、AIは「まずは公式情報を確認し、足りない詳細をSlackの議論から補う」といった、人間のような調査ができるようになりました。
今後の課題
ここまで精度向上の取り組みを紹介しましたが、まだまだ課題はあります。特に現在は以下の3点を改善したいと思ってます。
①検索速度の高速化
AIがReActで「何度か試行錯誤しながら調査する」ステップを踏んでいるため、回答までに数分かかってしまうことがあります。GPT5 MINIを利用しているのですが、より高速なモデルがリリースされた際（特に推論なしモードで頭いいケース）には、推論プロセスの最適化により、精度を落とさずに待ち時間を短くする改修を進めています。
②部門ごとの専門知識への対応
現在は全社共通の知識ベースを使っていますが、本来は「人事規定」「営業資料」「開発ドキュメント」など、部門ごとに特化した検索機能も用意させるべきなんじゃないかと考えています。とはいえソースに部署名を入れるなどの運用では組織変更への対応コストもあるし、最適なデータ分割の粒度ややり方を考案中です。
③正解のないタスクの検索
これまでのやり方で、FAQのような正解のある問題はうまく教えてくれるものの、複数の社内情報や社外情報を複合してインサイトを得るような使い方はカバーできていないと感じてます。例えばUXリサーチの実用上では別途NotebookLMが使われているようです。ChatGPTの外部検索ではもう少しうまくやってくれるイメージがあるので改善したいのですが、今のところ対応方法がイメージついておらず悩んでます…。