「Document360向けChatGPT」は1つのことのように聞こえますが、実際には4つあります。Document360内に公式のOpenAIアプリはありません。選択肢は、Document360独自のEddy AIを使う、Document360 MCPサーバーやノーコードツール経由でChatGPTのような外部モデルをつなぐ、Document360 APIとOpenAI APIで自作する、またはDocument360の知識を読み込んで顧客に回答する専用のAIチームメイトを導入する、の4つです。
多くの人が見落としているのは、「Document360向けChatGPT」が何のためのものかという点です。この検索には2つの異なる仕事が隠れています。ドキュメントを書くことと、ドキュメントをもとに顧客に回答することです。Document360のEddy AIは前者に注力しています。後者、つまり丁寧に書いた記事を解決済みチケットに変えることこそ、本当の判断が必要な部分です。
ドキュメントに基づく自律的な回答が欲しいだけなら、eesel AIがDocument360のヘルプセンター、過去のチケット、ウェブサイトを読み込み、すでに使っているヘルプデスク内で回答します。料金は月額299ドルから500クレジット（対応したチケット1件につき1クレジット）で、ユーザーごとの料金はありません。自作したい場合はDocument360 APIとOpenAI APIで実現できますが、検索、ガードレール、保守はずっと自社で担うことになります。
まず、チームが繰り返す間違いについて
私はAIエージェントを仕事として作っているので、「ChatGPTをDocument360のナレッジベースに向けるだけでいいですか？」と聞かれたら、正直にこう答えます。できますし、それは難しい部分ではありません。モデルは優秀です。API呼び出しをつなぐのは週末で終わります。役に立つか恥をかくかを決めるのは、モデルの周りにあるすべてです。
配管が薄いとどうなるかを見てきました。初期の頃、ナレッジベース検索が空だったときの強固なフォールバックを用意する前に、当社のあるAIが太陽電池に関するサブスクリプションの詳細を自信満々に作り上げ、実際の顧客に送ってしまいました。別のAIは答えを持たない質問に、周期表を読み上げるかのように「Oxygen」と楽しげに返しました。モデルに問題はありませんでした。問題はその周りの根拠づけでした。
これがDocument360向けChatGPTの話のすべてです。モデルは簡単な10%にすぎません。根拠づけ、ガードレール、「本当に確信があることだけ答える」というロジックが残りの90%であり、ナレッジベースがサポートの原動力になるか、新たなチケットの発生源になるかを決めます。4つの方法を見ていく間、この点を覚えておいてください。
「Document360向けChatGPT」が実際に意味すること
これを検索する人は、たいてい2つのまったく異なる成果のどちらかを求めています。ツールを選ぶ前に分けて考える価値があります。
1つ目の仕事はドキュメントを書くことです。AIで記事を下書きしたり、FAQセットを生成したり、トーンを整えたりします。Document360のEddy AIはまさにこのために作られており、ボトルネックが執筆にあるなら大きな時間短縮になります。
2つ目の仕事はドキュメントから顧客に回答することです。書いた内容を読み、ヘルプウィジェットでもサポートチケットでも実際の質問を解決するAIです。多くのサポートチームが実際に求めているのはこちらで、チケット削減やナレッジ管理がここに属します。AIが触れる前に、これらのコンテンツを管理するDocument360のダッシュボードをご覧ください。
この区別を踏まえて、手軽なものから最も手間のかからないものまで、4つの現実的な道を紹介します。
ルート1：Eddy AI、Document360に最初から入っているAI
最も手軽なのは、すでに支払っているかもしれないルートです。Eddy AIはDocument360の組み込みアシスタントで、機能は別売りではなくプランに含まれています。Eddy AI Writing Agent、AIによるコンテンツとFAQの作成、用語集の自動生成、重複コンテンツの検出、そしてここで最も重要なAI Search and Answerがあり、青いリンクの一覧ではなく、引用付きの統合された回答を返します。
このパネルにある小さな「AI can make mistakes, please verify important information」という一文に注目してください。これは検索・回答機能の正直な特徴を示しています。すでにヘルプセンター内にいる読者を助けるには優れており、設計上、人間が介在し続けます。
顧客向けの回答用として、Document360はAI Chatbotもアドオンとして販売しています。埋め込み型のヘルプウィジェットに配置され、Document360自身の機能表によると、ナレッジベース、ウェブサイト、ファイル、FAQ、さらにはZendeskやFreshdeskのチケットから回答を引き出します。どのソースを使えるかを細かく設定できます。
ボットが対応できない場合は、連携したヘルプデスク（現在はZendeskまたはFreshdesk）を通じてチケットを作成できます。
向いているケース： ナレッジベースがDocument360にあり、プラットフォームを離れずにウィジェット内の回答ボットが欲しいなら、Eddy AIとAI Chatbotが最も抵抗の少ない道です。判断を左右する正直な制約が2つあります。1つ目は、顧客向けの機能は付属ではなくアドオンであり、これはレビューにも表れています。G2のあるユーザーが述べたように、Document360は良いものの"a lot of new features need a separate license."です。2つ目は、チャットボットが自前のウィジェット内で回答するため、チームが実際にチケットキューで作業している場合、2つのツール間で会話を移し替え続けることになる点です。
ルート2：MCPサーバーやノーコードツールでChatGPTをつなぐ
Document360ブランドのアシスタントではなく、ChatGPTやClaudeにナレッジベースを読ませたい場合、Document360は多くのナレッジベースより明快な答えを持っています。Eddy AIの一部としてMCPサーバーを提供しているのです。Model Context Protocolは、外部のAIアシスタントがナレッジベースを管理されたコンテキストソースとして利用できるようにするオープン標準です。平たく言えば、ChatGPTやClaudeのクライアントをDocument360のコンテンツに向け、何もエクスポートせずに実際の記事で回答させることができます。
これは本物の差別化要因であり、「ChatGPTをDocument360に接続する」という問いへの正直な技術的答えです。顧客向けのサポートボットというより、チーム向けのドキュメント検索に近いものですが、社内利用なら手早く使えます。
回答ではなくコンテンツのワークフロー向けには、Document360はZapierやMakeとも連携します。記事が変更されたときにOpenAIのステップを起動したり、コンテンツを別のシステムに同期したり、Document360に戻る文章を下書きしたりできます。ドキュメントのイベントにGPT呼び出しを後付けするノーコードの方法です。
向いているケース： MCPサーバーは、チーム自身がAIクライアントを通じてドキュメントと対話するのに最適で、ノーコードはコンテンツ自動化に最適です。どちらも、顧客チケットを自力で解決する、根拠に基づいた自律型エージェントではありません。コネクターであって、サポート戦略ではありません。
ルート3：Document360 APIで自作する
これは検索語がそのまま指しているルートです。Document360 APIとOpenAI APIを取り、つなぎます。実際に可能で、本当にカスタムなワークフローなら正しい選択になりえます。Document360から適切な記事を取得し、プロンプトに詰め込み、GPTを呼び出し、回答を必要な場所に投稿します。
問題は、「ChatGPTをDocument360に接続する」が実際の請求書で最も小さな項目だということです。残りは次のとおりです。
- 検索。 ChatGPTは返金ポリシーを知りません。適切な記事を各プロンプトに取り込むパイプラインを自分で作らなければ、モデルは自信満々に作り話をします。上で述べた失敗そのものです。
- アクション。 回答の下書きは簡単です。チケットの更新、振り分け、営業時間の考慮には、アクションごとにAPI呼び出しを書いてテストする必要があります。
- ガードレール。 ルールベースのボットのように推測するのではなく、確信のあることだけに答え、残りは引き継ぐロジックが必要です。
- 保守。 プロンプトの変更、モデルのアップグレード、新しいエッジケースのすべてが、ずっとあなたのチームの仕事になります。
このトレードオフは実際の購入者から絶えず聞きます。似たドキュメントツールに知識を置いていたあるエンジニアリングリードは、計算のすべてを一文で表しました。
"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."
Karel, GENERAL BYTES (case study)
このmaintain（保守）という言葉こそ、チームが過小評価するものです。デモを作るのは楽しい作業です。モデル更新で挙動が静かに変わった午前2時にそれを運用するのは、楽しくありません。チームにエンジニアリングの意欲があり、どの製品もカバーしないワークフローがあるなら、作ってください。そうでなければ、そうしなくて済むようにルート4があります。
ルート4：Document360の知識を読むAIチームメイトを導入する
購入という選択肢は、構築そのものを省きます。ChatGPTをDocument360に自分で縫い付ける代わりに、サポートツール内での働き方をすでに知っているAIヘルプデスクエージェントを迎え、Document360のコンテンツを知識ソースの1つとして指定します。eesel AIはこのカテゴリーに属します。
重要なのは、eesel AIはドキュメントがたまたまDocument360にあることを気にしない点です。知識がある場所から読み取ります。公開済みのヘルプセンターや任意のウェブサイトのURLをクロールでき、Confluence、Notion、Google Docs、ファイルアップロードにも接続します。そして重要なことに、それらすべてを過去のサポートチケットと統合するため、1つの回答がDocument360の記事、社内wiki、先月のチケットを同時に参照できます。
自作を考える読者が抱く不安に、いくつかの点が直接応えます。
- あなたの知識からのみ回答します。 eesel AIは承認済みのソースに根拠を置いており、生の自作構成を危険にするハルシネーション問題への対策になります。
- 普通の言葉で設定できます。 書き方、扱うチケット、エスカレーションのタイミングを、望むことを説明するだけで変更できます。格闘すべきルールエンジンはありません。
- 公開前にテストできます。 eesel AIはまず過去のチケットでシミュレーションを実行するため、顧客が1人も話しかける前に、解決率とDocument360ドキュメントのギャップがわかります。
さらに、Document360のウィジェット内チャットボットと違い、eesel AIはチームがすでに使っているヘルプデスク内で回答します。Zendesk、Freshdesk、Help Scout、サービスデスクのいずれでも同様です。ライブエージェントとして設定した様子がこちらです。
制約についても公平に述べます。eesel AIは専門のカスタマーサービスエージェントであり、ブレインストーミングする汎用のChatGPTではなく、基盤モデルの選択はEnterpriseプランの機能です。ライターのためのチャット相手が欲しかったのなら、それはルート1か2であり、このルートではありません。
各ルートの実際の費用
費用はルート間で最も差が出る部分なので、正直に比較します。Document360はAIをカスタム見積もりの6つの要素の1つとして計測します。eesel AIは席料なしで、対応したチケットごとに計測します。自作は、予測しやすいソフトウェア費用をエンジニアリング時間と引き換えにします。
| ルート | 支払うもの | 落とし穴 |
|---|---|---|
| Eddy AI（組み込み） | Document360の見積もりの一部 | AI ChatbotとAI Premium Suiteは別売りのアドオン |
| MCPサーバー + ノーコード | Eddy AIに含まれる。別途OpenAI APIまたはZapierの費用 | チーム向けのコネクターであり、顧客向けサポートエージェントではない |
| OpenAIで自作 | APIトークン + エンジニアリング + 保守時間 | 構築は費用の10%。運用が残りの90% |
| eesel AI | 月額299ドルから500クレジット（対応したチケット1件につき1クレジット）、ユーザーごとの料金なし | 解決の有無にかかわらず対応したチケットごとにクレジットを消費。セルフサービスではモデルを選べない |
Document360の金額はつかみにくいものです。そもそも存在しないからです。Document360の料金ページは見積もり制で、FAQではAI利用が、チームアカウント、ワークスペース、言語、セキュリティ要件、プライバシーモデルと並んで、価格を動かす6つの要素の1つとして挙げられています。批判ではなく、確定額を自分で調べられない理由にすぎません。コミュニティで繰り返し指摘されるのは、本当に欲しかった機能を追加すると合計が膨らむという点です。
"I'm using Document360 as my knowledge base provider and I really don't enjoy them and they are very expensive for what they offer."
誤解のないように言うと、Document360は評価の高い製品で、数百件のレビューでG2で5点満点中およそ4.5〜4.7を獲得しており、エディターと検索が評価されています。料金モデルは、ただ事情を理解したうえで検討する価値があるということです。
実際の設定方法
ライター向けのコパイロットではなく、Document360の知識から回答する本物のエージェントが欲しいと決めたなら、設定は短くて済みます。多くのサポートチームがたどり着く、導入型ルートの流れは次のとおりです。
- ドキュメントを指定する。 公開済みのDocument360ヘルプセンターのURLをeesel AIに渡してクロールさせるか、Confluence、Google Docs、ファイルアップロードも併せて接続します。すべてが1つのナレッジベースにまとまります。
- チケットから学習させる。 ヘルプデスクを接続し、記事だけでなく過去のチケットとマクロも読み込ませます。
- 対象範囲を決める。 タグ、チャネル、条件で扱うチケットを決め、トーンとエスカレーションのルールを普通の言葉で書きます。
- シミュレーションする。 過去のチケットで実行し、公開前に解決率とナレッジのギャップを確認します。自作でよく省かれ、後悔するのがこの手順です。
- 段階的に公開する。 下書きモードで開始し、返信を確認してから、信頼できるようになったら簡単なチケットタイプを自律モードに切り替えます。
どのルートを選んでもこの形は変わりません。接続し、知識に根拠を置き、範囲を決め、テストし、ゆっくり展開します。ルートの違いは、手順2から4のどれだけを自作し、どれだけを購入するかだけです。
Document360のナレッジベースでeesel AIを試す
「Document360向けChatGPT」の目的が実は「ドキュメントから、作り話をせずに顧客に回答するAI」だったなら、OpenAI APIを自分で配線するより、既製のチームメイトのほうが早く目的地に着けます。eesel AIはDocument360のヘルプセンター、過去のチケット、その他のナレッジソースを読み込み、すでに使っているヘルプデスク内でチケットを下書きまたは解決します。料金は月額299ドルから500クレジット（対応したチケット1件につき1クレジット）で、ユーザーごとの料金はなく、100クレジットで無料で始めることもできます。
自作では初日に得られないのがシミュレーションです。知識を接続すると、顧客が1人も回答を見る前に、eesel AIが先週のチケットをどう処理したか、そしてDocument360の記事のどこにギャップがあるかを正確に教えてくれます。