ほとんどのチームが抱えるナレッジベースの問題は、実はドキュメントの問題ではない。ドキュメント自体は存在する。誰かが休暇ポリシーを書き、返品プロセスを書き、オンボーディングのチェックリストを書き、runbookを書いた。それらはConfluenceやNotion、どこかのGoogleドキュメントの中にある。問題は、それらを見つけるためにSlackを離れ、ブラウザのタブを開き、検索を実行し、あちこちクリックし、諦めて、おそらく知っているであろう人に聞く必要があることだ。
ナレッジベース用のAI Slackボットは、そのループを閉じる。質問はSlackの中で生まれ、答えはSlackの中で返ってくる。出典はスレッド内に明記される。誰もワークスペースを離れない。誰も返信を待たない。
ナレッジベースが埃をかぶる理由
正直に言えば、あなたのナレッジベースは、整理が悪いから、あるいは誰も気にしていないから失敗しているわけではない。Slackで同僚に聞けば30秒で結果が得られるのに対し、Confluenceを検索すると2分かかった上に見つからないかもしれない -- その差が失敗の原因だ。
この摩擦の差こそが問題のすべてだ。人はドキュメント化されているものではなく、簡単なものを選ぶ。
あるeesel AIユーザーは、r/Zendeskでこの変化を率直に語っている。
「ボットから得られる情報は、誰かに聞かなければならない場合と違って、ドキュメントと同様に常にリアルタイムで最新の状態になっている」-- u/kate468
この「誰かに聞かなければならない場合と違って」という部分が核心だ。AI Slackボットは、ドキュメントを検索しやすくするだけでなく、同僚に聞くよりも到達しやすくする。
ナレッジベース用のAI Slackボットが実際に行うこと
ナレッジベース用のSlackボットは、既存のドキュメントソースに接続し、Slack内にボットユーザーとして存在する。誰かが質問とともに@メンションすると、接続されたソースを検索し、最も関連性の高いコンテンツを見つけ、元のドキュメントへのリンクとともにスレッド内で返信する。
「ウィジェットに質問を入力する」タイプのチャットボットではない。むしろ、すべてのドキュメントを読み込んだ上で、既存のチャンネル内で応答してくれる新しいチームメンバーを加えるようなものだ。
優れた実装と忘れられがちな実装を分ける主な挙動は以下のとおり。
- チャンネルではなくスレッドで返信する。 これにより#generalや#supportがうるさくなるのを防ぐ。
- 出典を明記する。 「これが当社の返品ポリシーです(Confluence)」は信頼できる。出典のない裸の回答は、検証や文脈の確認をする手段がない。
- わからないことを適切に処理する。 ドキュメントがその内容をカバーしていなければ、優れたボットはそう伝える。自信満々のハルシネーションは最悪の失敗モードだ。
- 常に最新である。 リアルタイム同期により、回答は2か月前のスナップショットではなく現行のドキュメントと一致する。
仕組み
その仕組みは以下のとおり。
- チームメンバーがSlackチャンネルで
@eesel 不良品の返品ポリシーは?と入力する。 - エージェントがメンションを検知し、メッセージを読み、接続されたすべてのナレッジソースを検索する。
- 確信度をチェックする -- 一致度が高ければ送信する。確信度が低ければレビュー用に下書きを作成するか、エスカレーションする。
- 返信はSlackのスレッドに届く。「返品ポリシー(Confluence)によると、当社の返品ポリシーでは90日以内の返品が可能です...」
docs.eesel.aiによると、トリガーは@eesel mentionedイベントであり、エージェントがアクセス権を持つチャンネル内で誰かがメンションするたびに発火する。アクションはBlock Kit形式のフォーマットに対応したスレッド返信だ。どちらも設定可能で、チャンネルごとに異なる挙動を割り当てられる -- #supportではレビュー用下書き、#onboardingでは完全自律型といった具合だ。
Slackナレッジボットで確認すべきポイント
すべての実装が同じ結果になるわけではない。2週目には忘れられてしまうボットと、チームが実際に使い続けるボットとを分ける機能は以下のとおり。
リアルタイムのナレッジ同期。 ボットが先週火曜日にインデックス化されたスナップショットから回答している場合、古い回答が返ってくる。ライブのドキュメント(Notion、Drive、Confluence)から取得するコネクタが最低限の基準だ。
ナレッジソースの幅広さ。 あなたの知識は一箇所にまとまっていない。チームには通常、社内Wiki(Confluence、Notion)、ファイルストレージ(Google Drive、SharePoint)、過去のサポートチケット(Zendesk、Freshdesk)、PDFがある。Confluenceしか読まないボットは、半分のケースで答えを見逃す。
すべての返信における出典引用。 引用がなければ、回答を検証したり、より広い文脈を確認したりする手段がない。出典の明記は、ボットが古いドキュメントから引用している場合にそれを見つける助けにもなる。
確信度ベースのルーティング。 自信満々に間違った回答を送るボットは、ボットが存在しないよりも悪い。高確信度の回答は送信し、低確信度の回答は人間のレビュー待ちにし、一致するものがなければ明示的に「わかりません」と伝えるシステムを探そう。
制御可能な展開。 レビュー用下書きモードで始め、信頼が積み上がるにつれて自律型へと移行できること。最初から完全自律型に踏み切り、初期に一度悪い回答を出してしまったチームは、戻ってこない傾向がある。
eesel AIをSlackナレッジボットとして設定する
サインアップから最初の実際の@メンション応答まで、実際の設定手順を紹介する。
ステップ1: eesel AIアカウントを作成する。 eesel.aiでサインアップする。クレジットカード不要で50ドル分の無料利用枠がもらえる。
ステップ2: Internal Knowledge Agentを作成する。 ダッシュボードで新しいエージェントを作成し、Internal Knowledge Agentタイプを選択する。これは、社外顧客チケット向けのHelpdesk Agentや、Shopify向けのE-commerce Agentとは異なり、ドキュメントから社内チームの質問に答えるために作られたエージェントタイプだ。
ステップ3: ナレッジソースを接続する。 Integrationsに移動してソースを追加する。eesel AIが対応しているのは、Google Drive、Confluence、Notion、SharePoint、Zendesk、Freshdesk、ウェブサイト、PDF、そして100以上の追加連携だ。すべて自動的にインデックス化される。複数のソースは一つのナレッジプールに統合され、エージェントがそこから情報を引き出す。
ステップ4: エージェントの指示を書く。 指示は、新入社員向けのオンボーディング資料に書くような内容だ -- エージェントが何者か、どう応答すべきか、わからないときはどうするか、どの話題をエスカレーションするか。ダッシュボードで平易な言葉で書くか、チャットパネルでやりたいことを説明してeeselに生成させることもできる。
ステップ5: Slackに接続する。 Integrations > Slackに移動する。Connectをクリックし、ワークスペース内でeeselを承認し、エージェントが参加するチャンネルを選ぶ。docs.eesel.aiによると、この承認作業全体は2分もかからない。
ステップ6: 公開前にテストする。 ダッシュボードのチャットパネルでエージェントに質問してみる。回答をドキュメントと照らし合わせて確認する。何かおかしければ、平易な言葉でエージェントに伝えれば指示が更新される。ドキュメントによれば「チャットパネルでテストし、エージェントが何を間違えるかを確認し、改善する」というプロセスだ。
ステップ7: 下書きモードで公開する。 レビュー用下書きを有効にした状態で始める。回答はチャンネルに投稿される前に、レビューキューに投稿される。1~2週間精度を確認できたら、半自律型または完全自律型に切り替える。
信頼のランプ: 初日から自律型にする必要はない
社内で期待値をすり合わせておく価値のある点がある。スイッチを切り替えて、いきなりボットに完全な制御を渡すわけではないということだ。eesel AIは、実際に新しいチームメンバーをオンボーディングする方法に対応した4段階の信頼のランプを軸に構築されている。
- ダッシュボードでテスト。 あなただけがやり取りする。実際のチームメンバーは誰も見ない。
- 下書きモード(HITL)。 エージェントは実際の@メンションを処理するが、投稿前にすべての返信があなたの承認待ちのキューに入る。承認前に編集できる。
- 半自律型。 高確信度の回答は自動で送信される。低確信度の回答は人間にルーティングされる。
- 完全自律型。 エージェントがすべてを処理する。アクティビティダッシュボードで監視する。
docs.eesel.aiによれば、「連携を接続しても、それが自動的に有効化されるわけではありません。エージェントが自律的に動作するには、トリガーを明示的に有効化する必要があります」。ペースは常にあなたがコントロールする。
チームが実際に使っている用途
新入社員のオンボーディング。 「VPNの設定は?」「経費はどこで申請する?」「Xの担当は誰?」新入社員は入社1週目に必ずこうした質問をする。ボットは既存のオンボーディング資料から答えるので、チームが同じ質問に何度も対応せずに済む。
ITヘルプデスクのTier1対応。 InDebted社のIT責任者Jason Loyola氏は、eesel AIを「Jira上のヘルプデスクチケットへの一次対応者」として使っている。「基本的にエージェントと同じように動作します」とのことだ。Tier1の質問には回答し、難しい問題はエスカレーションされる。
HRポリシーの照会。 福利厚生の質問、休暇申請、ポリシーの確認 -- 頻度が高く複雑度の低い問い合わせであり、HRの時間を奪うため自動化に最適な対象だ。
セールスとCSのイネーブルメント。 「SOC 2認証は取得していますか?」「どの連携に対応していますか?」「エンタープライズ料金はいくらですか?」セールスとCSのチームはこうした質問を常に受ける。製品ドキュメントや料金ページに接続していれば、回答は常に最新であり、@メンション一つで得られる。
チーム横断のナレッジ共有。 デバイス・アズ・ア・サービス企業のEverphoneは、Confluence、Slack、ウェブにまたがってeesel AIを運用し、2,400以上のナレッジ項目をインデックス化している。Simployerは専用のSlackボットを使い、EUデータレジデンシーとGDPR準拠を組み込んだ形で2,000人以上の従業員に対応している。
実際の費用
eesel AIは、プラットフォーム利用料も席数課金もないタスクベースの料金体系を採用している。
| タスクタイプ | 価格 |
|---|---|
| 軽量タスク(簡単な照会) | 無料 |
| 通常タスク(Slackクエリ、チャットセッション) | 1件0.40ドル |
| 年間契約(月300ドル以上) | 25%割引 |
| エンタープライズ | 月額固定1,000ドル + 使用料 |
月500件の質問をSlackで行うチームなら、月200ドルだ。Global Pay -- 27,000人規模の決済企業 -- は、SlackにeeselAIを導入後、コンプライアンス、QA、開発チームで50~80%の時間削減を報告している。この規模になると、ROIの計算は単純明快だ。
正直に言っておくべきことがある。G2(4.6/5、レビュー15件)で挙げられる二大の不満点は「コスト」と「高価」だ。クエリ量が多いと、クエリごとの料金は固定のプラットフォーム料金よりも早く積み上がる。チームが月に数千件の照会を行うなら、年間契約かエンタープライズ層の見積もりを取る価値がある。
無料トライアルではクレジットカード不要で50ドル分の利用枠がもらえる -- コミットする前に、1つのチャンネルで意味のあるパイロット運用を行うには十分な量だ。
eesel AIを試す
eesel AIは、既存のドキュメント(Notion、Confluence、Google Drive、SharePoint、そして100以上の追加連携)をSlackに接続し、すべての@メンションを出典付きの回答済みの質問へと変える。設定は30分もかからない。クエリごとの料金体系なので、2回しか使わない人のための席数ライセンスではなく、チームが実際に使った分だけ支払う。
目新しさが薄れた後もチームが使い続ける決め手となる機能は、リアルタイム同期だ。ドキュメントが変われば、ボットの回答も変わる。手動での再インデックスも、情報の陳腐化もない。それが、かっこいいデモを、チームが頼りにするツールへと変える要因だ。
まず一つのチャンネルに展開するのが良い出発点だ -- #it-support、#hr-questions、あるいはチームで最も繰り返される質問が集まる場所だ。本格的に展開する前に、精度に慣れておこう。無料トライアルの50ドル分の利用枠は、1つのチャンネルでの数週間分の実運用テストをカバーする。
