Slackに常駐するAIエージェントで社内QAを自動化する：実装から運用まで

「同じ質問に何度も答える」という静かなコスト

実は、社内の問い合わせ対応は思っているより大きなコストを食っている。「有給申請の手順ってどこで見るんでしたっけ」「VPNの設定方法を教えてください」「〇〇システムのパスワードリセットはどうすれば」——こういった質問は毎日どこかで発生している。回答する側の担当者は一回あたり5分で済むとしても、一日に10件来れば1時間消える計算だ。

そしてこれが積み重なると、担当者は「自分の本来の仕事」をする時間が削られていく。さらに困るのは、担当者が休んでいるときに同じ質問が来ても誰も答えられないことだ。「Aさんに聞けばわかる」という属人化が、組織のナレッジをブラックボックスにしていく。

AIエージェントをSlackに常駐させることで、これらの定型的な質問に24時間365日自動応答できる環境を構築できる。午前2時に新人スタッフが有給申請の手順を知りたいと思ったとき、翌朝まで待たなくていい。ボットが即座に正確な手順を返してくれる。担当者は繰り返し質問の対応から解放され、本当に価値のある仕事に集中できる。

成功の前提を一つ明確にしておきたい。回答の元となる社内ドキュメントが整備されている必要がある。ボットの回答品質はドキュメントの品質に直結するからだ。「まずドキュメントを整備してからボットを作る」——この順序を守ることが、失敗しない最大のコツだ。

アーキテクチャの設計——4層で考えると整理しやすい

基本アーキテクチャは「Slack Bolt → RAGエンジン → LLM → Slack応答」の4層構成で考えると整理しやすい。各層の責任範囲が明確になり、問題が起きたときにどの層で何が起きているかを特定しやすくなる。

Slack Bolt層は、アプリメンション（@botname）や特定キーワードをトリガーにしてフローを起動する役割を担う。「#社内QA」チャンネルでのメッセージ全件を受け取るか、ボットへのメンションのみを受け取るかは運用方針によって選べる。最初は特定チャンネルでのメンション限定から始めるのが、誤爆リスクが低くておすすめだ。

RAGエンジン層は、ベクトルデータベース（Pinecone・Chroma・Qdrantなど）に格納された社内ドキュメントを検索し、質問と関連性の高いドキュメントのチャンクをLLMのコンテキストに追加する。この「関連情報を引っ張ってきてLLMに渡す」という仕組みが、汎用LLMを社内専門家に変える核心だ。ドキュメントの更新頻度に応じてインデックスの再構築スケジュールを設定する。週次更新のドキュメントであれば日次でインデックスを再構築、リアルタイム更新が必要な場合はWebhookで変更を検知して差分インデックスを作成する設計にしておくと長期運用が楽になる。

LLM層は、RAGが取得した関連情報を元に自然な日本語で回答を生成する。ここで大事なのは「ドキュメントに書いていないことは答えない」という制約をシステムプロンプトで明示することだ。制約がないと、LLMが知識を「創作」して誤った回答を返すリスクがある。「提供されたドキュメントに基づいてのみ回答し、情報がない場合はその旨を伝える」という一文が、回答の信頼性を守る。

Slack Bolt Appの実装——動く最小構成から始める

Slack Bolt for Python/JavaScriptは、Slack Appの開発に特化したフレームワークだ。app.mentionハンドラーでメンションを受け取り、質問文をRAGエンジンに渡し、回答をSlackメッセージとして返信する——この基本フローはコード30行程度で動く。まず最小構成を動かして「ボットがSlackで返答できる」という状態を作ることを優先してほしい。RAGの精度調整は後からでもできる。

実装上の重要点は「応答中」の状態をユーザーに伝えることだ。LLMの処理には3〜10秒かかることがある。何も表示されない状態でユーザーを待たせると「壊れてるのかな」と思われる。まず「回答を調べています...」という中間メッセージを送信しておき、処理完了後にSlack APIのchat.updateで内容を書き換える。このひと手間でUXが大幅に改善する。

スレッド内で返信することも忘れないでほしい。チャンネルのメインタイムラインに返信すると、他の会話と混在して読みにくくなる。thread_tsパラメーターを元のメッセージのタイムスタンプに設定するだけで、スレッド返信になる。これだけで「ボットがチャンネルを荒らさない」という評判が守られる。絵文字リアクションで「受付中」を示してから回答を返すというパターンも、視覚的にわかりやすくておすすめだ。

権限周りも丁寧に設定しておくと後で困らない。Slack Appのスコープは必要最小限に絞る。app_mentions:read・chat:write・channels:historyで基本機能は十分に動く。不要な権限を付与してしまうと、セキュリティ審査で引っかかるリスクが上がる。

精度向上と運用管理——「わかりません」をなくす継続改善

ボットが「わかりません」と返答した質問をログに記録し、回答できなかった理由を分析することが精度向上の近道だ。多くの場合、3つのパターンに集約される。ドキュメントに情報が存在しない・情報はあるが古くなっている・表現が検索クエリと一致しない——の3つだ。

それぞれの対策は明確だ。情報が存在しない場合はドキュメントを追加する。情報が古い場合は更新する。表現が一致しない場合は同義語辞書を整備するか、ドキュメントに「よくある質問パターン」を追記する。月1回のレビューをルーティン化するだけで、精度は継続的に向上する。あるチームでは3ヶ月の運用で「わかりません」の発生率が導入当初の28%から7%まで下がったという実績がある。

ユーザーからのフィードバックを収集する仕組みも最初から入れておくことをおすすめしたい。回答メッセージの下に「役に立った / 役に立たなかった」のリアクションボタンを追加し、「役に立たなかった」が押されたものを改善キューとして管理する。ネガティブなフィードバックがあった質問と回答のペアを週次でレビューすれば、プロンプトとドキュメントの改善ポイントが見えてくる。

長期運用で特に意識してほしいのは、「ドキュメントのオーナー」を決めることだ。ボットが古い情報を返し続けると、ユーザーの信頼が一気に下がる。各ドキュメントに担当者を設定し、四半期ごとに「情報が最新か」を確認するリマインダーを送る仕組みを組み込んでおくと、ナレッジベースの鮮度が長期的に保たれる。ボットへの信頼は、ドキュメントの鮮度と同義だ。