Document360のAI活用:ナレッジベースにAIを追加する2つの方法

まず、自信満々の誤答についての話

私はeeselでインテグレーションを構築しているので、AIが企業のナレッジベースを読み込み、実際の質問に答えようとする様子を見る時間が多くあります。その仕事のおかげで、ボットが常に正しく答えるデモには深く疑いを持つようになりました。

印象に残っている例があります。月に数百件のZendeskチケットから数千件へとスケールしていたB2Bの車両テレマティクスチームが、AIエージェントをナレッジベースに接続しました。すると、システム上どこにも存在しないブランドの車種について「はい、そのモデルには対応しています」と自信満々に顧客に伝え始めたのです。なぜでしょうか。ナレッジベース内の一行に「すべてのモデルに対応しています」と書かれていたからです。AIは壊れていませんでした。ナレッジベースに書かれていることをそのまま繰り返す、まさにナレッジベースが指示する通りのことをしていたのです。彼らの最初の数週間についての率直な感想は「最初は試行錯誤だった」というものでした。

これがDocument360のようなナレッジベース上でAIを使う際のすべてです。ツール自体を用意するのは簡単な部分です。難しいのは、AIが実際に顧客に何を言うかを、言う前に知ることです。この点を念頭に置きながら選択肢を見ていきましょう。ほとんどの「ドキュメントにAIを追加しよう」という売り込みが、静かに省略している部分だからです。

「Document360のAI活用」が実際に意味すること

Document360はヘルプデスクではなくナレッジベースのプラットフォームなので、「AIを追加する」というのは明確に2つの目的に分かれます。この区別を正しく理解しておくことで、間違った製品を購入せずに済みます。

最初の目的は執筆です。記事そのものを書き、編集し、翻訳し、維持することです。ここはテクニカルライターやサポートリーダーが時間を費やす部分であり、Document360のネイティブAIが強みを発揮する部分です。

2つ目の目的は回答です。完成した記事を使って質問を解決することで、ヘルプサイト上の顧客であっても、チケット対応中に答えを探すエージェントであっても同じです。これはサポート指標に影響を与える目的であり、実際に判断が必要になる目的でもあります。顧客が質問をする場所はドキュメントサイトだけではないからです。ほとんどの質問はヘルプデスク内で行われ、それはドキュメントサイトとは異なる場所です。これが、AI for Zendesk、AI for Freshdesk、AI for Help Scoutを別のガイドとして書いた理由と同じです。ドキュメントは入力の一つですが、業務が実際に流れ込むのはキューだからです。

ルートA:Document360のネイティブEddy AI

Document360がAIで行うすべてのことはEddy AIというブランドで提供されています。最初に理解しておくべき重要な点は、Eddyは単一の機能ではなく、バンドルに加えて2つのアドオンで構成されているということです。そしてその境界線こそが、サポートチームが驚くポイントです。

プランにバンドルされているのは、Eddy AIライティングエージェント、AIコンテンツおよびFAQ作成、AI検索と回答、自動生成されるグロッサリー、重複コンテンツ検知、そしてMCPサーバーです。別売りなのはAI Chatbot(読者に回答する埋め込みウィジェット)とAI Premium Suite(画面キャプチャ、ステップバイステップガイド、インタラクティブデモ、動画録画)です。カスタマー向けのチャットボットがこの境界線のどちら側にあるかに注目してください。

Eddy AIでドキュメントを執筆する

執筆という目的については、これは良い適合であり、私も喜んで使います。ライティングエージェントはエディタ内に直接組み込まれているため、今取り組んでいる記事から離れずに、アウトラインを生成したり、セクションを拡張したり、トーンを変更したり、長い文を分割したり、関連記事やタグの提案を受けたりできます。半分書きかけのドキュメントの山を整えることが目標なら、Eddyは既に作業している場所で仕事をしてくれます。それこそが執筆用AIがあるべき場所です。

読者への回答:AI検索とチャットボット

ドキュメントサイト内での回答という目的については、Document360は2つの機能を提供します。1つ目はAI検索と回答で、10件の青いリンクを返す代わりに記事から直接の答えを合成し、参照元の記事を引用します。

出典を示していることに加えて、回答の直下に「AIは誤りを含む場合があります。重要な情報は必ずご確認ください」と表示している点は、うれしい発見です。この誠実さはナレッジベース用ボットにとって正しい姿勢であり、上で紹介したテレマティクスの話の裏返しでもあります。

2つ目の機能はEddy AI Chatbotで、サイトに埋め込むアドオンウィジェットです。コンテンツから回答し、答えがない場合は何かを作り出すのではなくチケットを起票することを提案します。

このチャットボットは見た目より柔軟です。ソース設定では、ナレッジベース、外部ウェブサイト、生テキスト、アップロードファイル、FAQ、さらにはZendeskやFreshdeskのチケットまで指定できます。すべてコンテンツアクセス設定とストレージ上限付きです。

正直に指摘すべき制限が2つあり、いずれも冒頭の話を踏まえると気になるはずです。1つ目は、チャットボットが回答するのはドキュメントサイト上であり、エージェントのヘルプデスク内ではないということです。つまりヘルプセンターでは対応を逸らせますが、チケットキュー内で返信を作成することはありません。2つ目は、ここには自分の過去のチケット履歴でのドライランが存在しないということです。ソースを設定して公開するだけです。これは「切り替えて様子を見る」パターンであり、まさに「すべてのモデルに対応しています」というナレッジベースの一文が、本番環境で自信満々の誤答に変わる仕組みです。

MCPサーバー(実際に最も現代的な部分)

先頭に挙げたいネイティブ機能はMCPサーバーです。Model Context Protocolは、AIアシスタントが外部システムにクエリを実行できるようにする新しい標準であり、Document360がこれを提供しているということは、MCP対応のアシスタントがナレッジベースを直接読み込めるということです。あなたのチームがMCPに対応したアシスタントを使っているなら、これは本当の橋渡しであり、あるべき頻度よりも珍しい存在です。何ができて何ができないかはChatGPT for Document360で解説しており、同じパターンはWikiツール全般にも広がっていて、ChatGPT for Confluenceで取り上げています。

Eddy AIの実際のコスト

ここでは一度立ち止まる必要があります。Document360はもう固定プラン料金を公開していません。料金ページは「お客様のニーズに合わせたカスタム料金」と題した見積もり専用のコンフィギュレーターで、営業との会話に導かれます。

Document360自身のFAQには、見積もりを左右する6つの要素が記載されています。

トライアルは太っ腹です(14日間、クレジットカード不要、全機能利用可)。そして各見積もりには専任のサクセスマネージャーとオンボーディングが含まれます。しかしこのモデルでは、営業と話さなければAIの価格を知ることができず、多くのサポートチームが求める部分は、すでに交渉しているベースの上に乗るアドオンです。利用者はそれに気づいています。あるG2レビュアーの欠点についての要約は率直でした。

「高価であり、多くの新機能は別のライセンスを必要とする。」

Document360のレビュー、G2

そしてRedditでは、これをナレッジベースとして運用しているプロダクトマネージャーがもっと直接的にこう述べています。

「Document360をナレッジベースのプロバイダーとして使っていますが、正直気に入っていませんし、提供内容に対して非常に高価です。」

r/ProductManagement, Knowledge Base Provider?

公平を期すなら、コア製品自体には本物の評価があり、G2では542件のレビューにわたって4.5から4.7あたりを維持しており、インターフェースと検索が最も多く評価されています。コストへの不満は、ソフトウェア自体ではなく、アドオン+見積もりという構造そのものに向けられたものです。Document360の料金の内訳で詳しく解説しており、乗り換えも検討しているならDocument360 vs Helpjuiceでその比較を取り上げています。

ルートB:Document360の上にeeselを重ねる

本当の目的が2つ目の意図、つまりサポートの質問に回答することであれば、Document360のチャットボットアドオンに依存しない別の方法があります。専用のAIサポートチームメイトをDocument360のドキュメントに向け、ヘルプデスク内で動かすという方法です。

念のため申し添えると、これは私が取り組んでいる仕事そのものなので、その前提でこのセクションを読んでください。eeselは、あなたのナレッジソースを読み込み、既に運用しているヘルプデスクに参加し、チケットを解決するAIサポートチームメイトです。現時点ではワンクリックのネイティブなDocument360コネクタはないため、正直な仕組みとしては、公開されているヘルプセンターや指定したURLをクロールすることでDocument360のコンテンツを取り込みます。これはどのドキュメントサイトからも学習する方法と同じです。Document360のナレッジベースが公開されている場合はシンプルですが、完全にプライベートな場合は、eeselがアクセスできるソースを指定することになります。

2つのルートが最も異なる点は次のとおりです。

• ウィジェット内だけでなくキュー内でも機能します。 eeselはZendesk、Freshdesk、Gorgias、Help Scoutなどに接続するため、エージェントが実際に作業する場所で返信を作成または自動送信でき、Document360からの回答を唯一のソースではなく、複数のナレッジソースの一つとして取り込めます。
• 本番運用前にシミュレーションできます。 これは私のテレマティクス顧客を救っていたはずの部分です。eeselは実際の過去チケットを何千件も処理して、どう回答したかを事前に見せてくれるため、「すべてのモデルに対応しています」のような落とし穴を、事後ではなく事前に見つけられます。
• 料金は一律で予測可能です。 見積もりも席数課金もありません。AIが処理したチケットの分だけ支払います。

いくつかのチーム規模でのeeselのコストモデルを示します。Document360の見積もりと比較する際の参考にしてください。

解決したチケット、またはチャットセッション1件は、メッセージ数に関係なく40セントのタスクとして扱われ、プラットフォーム料金も最低利用料金もありません(料金)。実際にAIが処理したチケットの分だけ支払うため、月間1,000件のチケットのうち200件を段階的にAIに振り分ける場合のコストは全額ではなく80ドルになります。これはAI for HubSpot Service HubやAI for Salesforce Service Cloudで解説しているのと同じモデルです。

では、どちらのルートを選ぶべきか

ここに単一の勝者はありません。2つのルートは2つの異なる目的に応えるものだからです。ツールを目的に合わせましょう。

執筆の目的だけが必要なら、ここで読むのをやめてEddy AIを使ってください。その分野では優れています。この判断が本当に興味深くなるのは、「Document360のAI活用」が実際には「顧客に回答すること」を意味するようになったときです。その質問はドキュメントツールの中にはなく、ヘルプデスクの中にあるからです。AI for FrontやAI for Jira Service Managementを比較しているチームが同じ結論に至るのも同じ理由です。ナレッジベースは入力であり、キューこそが仕事なのです。

Document360のドキュメントでeeselを試す

回答という目的でここに来たのであれば、eeselはまさにそのために作られています。Document360のヘルプセンターを指定し、既に運用しているヘルプデスクを接続すれば、既存のドキュメントを知識として使い、書き直すことなくチケットの作成と解決を行います。

自信満々のボットが誤る様子を見てきた経験から、最も信頼できる差別化要因はシミュレーションのステップだと思います。実際のチケット履歴でeeselを実行し、一人の顧客が見る前にその回答を確認してください。その後、段階的に展開し、処理したチケットにつき一律40セントを支払います。無料でお試しいただけ、クレジットカードも営業電話も不要なので、コミットする前にドキュメントの読み込み方を確認できます。eeselを始める。