Zendesk AIとGoogle Driveの連携:2つの接続方法

なぜチームはGoogle DriveをZendeskのナレッジソースにしたいのか

zendeskのAIは、何を読み込ませるか次第の性能でしかありません。そしてそこが、ほとんどの解説記事が飛ばしてしまう部分です。ここに、正直なZendesk AIスレッドのほぼすべてで引用されるRedditのコメントがあります。

「Co-Pilot自体はまあまあだけど、その効果は完璧に整備されたzendeskナレッジベースがあるかどうかにかなり左右されると分かった。うちのは……そうじゃないんだよね、笑」

u/ToastBix, r/Zendesk

これが一文に凝縮された問題の本質です。AIは読み込めるものからしか回答できず、多くのチームでは良質なコンテンツがヘルプセンター記事になったことは一度もありません。それは共有されたGoogle Driveフォルダの中に眠っています。これはカスタマーサービス向けAIを初めて導入するときにありがちな罠です。モデル自体は問題なく、ボトルネックは知識の配管の方なのです。

私がこれまで見た中で最もわかりやすい例の一つは、zendeskを使うバス追跡会社からのもので、月間200~250件ほどのチケットを扱っていました。彼らのサポート知識は、整ったzendeskヘルプセンターには全く存在していませんでした。Google Drive内のプロダクトマニュアルと、大量の解決済みチケットの中にあり、しかもマニュアルは管理者向けに書かれている一方、チケットは利用者(乗客)から来ていました。彼らが実際に求めていたことは率直でした。

「受信するzendeskチケットの60%を処理でき、より良い分析と解決のために実際の担当者を呼び込むべきタイミングを判断できるアプリケーションを作ってほしい」

eesel営業商談より、匿名化(マニュアルがGoogle Driveにあったzendesk利用のバス追跡サポートチーム)

それこそが本来の仕事です。Driveのドキュメントを読み、チケット履歴を読み、現場の質問に答え、確信が持てないときはきれいにエスカレーションする。以下の2つのルートはどちらも、その一形態を実現できます。違うのは、Driveをどう読み込むか、その読み込みがどれだけ新鮮に保たれるか、そしていくらかかるかです。

ルートA:Zendesk AI経由でGoogle Driveをネイティブに接続する

zendesk自身のAIエージェントは外部コンテンツを取り込むことができ、Google Driveはその代表例の一つとして挙げられています。zendeskのナレッジソースに関するドキュメントによれば、AIエージェントが接続できるソースの種類は正確には2つだけです。zendeskのヘルプセンターと、ウェブクローラーまたはナレッジコネクタを通じて取り込む外部ナレッジです。マーケティングページにはこう明記されています。「AIエージェントをヘルプセンターや、Google DriveやPDFのような外部ソースに接続。」これらのエージェントの挙動に初めて触れる方は、基本を押さえたZendesk AIレビューも参考にしてください。

というわけで、ネイティブの経路は実在します。重要なのは細かい条件で、それが自社の環境に合うかどうかを左右します。

プランによる制限があります。 ナレッジコネクタはエントリープランのSupport Teamには含まれておらず、これが無料版zendeskではここまでたどり着けない理由でもあります。利用できるようになるのはSuite Team(年間契約で55ドル/エージェント/月)とSuite Professional(115ドル)からです。同期したDriveコンテンツを保持する外部ナレッジストレージにも上限があります。Support Teamでは100MB、Suite TeamとProfessionalでは500MBです。PDFがぎっしり詰まった大きなDriveにとって、500MBは計画に織り込むべき現実的な天井です。

Driveは同期であり、リアルタイムではありません。 これは、信頼する前にテストしておきたい部分です。zendeskは、接続済みのヘルプセンターはリアルタイムで検索される一方、接続済みの外部ソースは「通常24時間ごとに行われる直近の同期時点で利用可能だった情報」に対して検索される、と明記しています。朝9時にDrive内のポリシー文書を編集しても、次の同期が来るまでAIは昨日のバージョンで答え続けるかもしれません。

過去のチケットはここではソースになりません。 接続可能なソースの種類はヘルプセンターと外部クロールコンテンツのみです。zendeskのチケットアーカイブは、AIエージェントが直接読むものではありません。zendeskはKnowledge builderを通じてチケット履歴をコンテンツに変換し、解決済みチケットから記事を下書きし、エージェントはその記事を読みます。これは妥当な設計ですが、正確に理解しておく価値があります。AIが根拠とするのはあなたのドキュメントであって、生のチケットではありません。

そして、解決1件ごとに課金されます。 シート料金に加えて、zendeskの料金ページにはコミット済み自動解決1件あたり1.50ドル、または従量課金で2.00ドルと記載されており、これは公開されている3つのプラン全てで共通です。この話のうれしい半分は2026年5月に追加されたもので、カウントされるのは検証済みの解決のみという点です。これはLLMが72時間のフォローアップなし期間の後に、リクエストが実際に解決されたことを確認する仕組みです。含まれる解決や補助的なエスカレーションは、この上限枠を消費しません。より詳細な内訳を知りたい方は、Zendesk AI解決率に関する解説をご覧ください。

ネイティブのルートAを一言で言うと、すでにSuite Team以上のプランを利用していて、Driveのコンテンツが控えめで変化も緩やかであれば、これは接続するためのクリーンでサポートされた方法です。

ルートB:eeselをZendeskに重ね、Google Driveに向ける

もう一つのルートは、zendeskをそのままにしておいて、その上にAIチームメイトを追加します。eeselは独立したチャットボットウィジェットや別の受信箱ではなく、本物のAIエージェントとしてあなたのzendeskに参加します。チケットを読み、返信を下書きして送信し、内部メモを追加し、フィールドを更新し、グループへ振り分けます。これは人間のエージェントが行うのと同じアクションです。

これがこの特定の問題に合う理由は、何をナレッジソースとして扱うかにあります。eeselではGoogle Driveが第一級のソースであり、過去のzendeskチケット、ヘルプセンター、マクロとまさに並んで存在します。それこそが、バス追跡チームが必要としていた違いでした。Driveのマニュアルと解決済みチケットの履歴の両方が、一つのエージェントに情報を供給するのです。あるeeselの顧客であるEcosaのCTOは、この複数ソースという点を率直に語っています。

「eesel AIを選んだのは、マルチチャネルのデータ入力オプションを提供してくれるからです。CSV、zendesk、Google Docsをソースとして連携させることで、私たちの膨大なドキュメントを最大限に活用できます。」

Wesley Wang、CTO、Ecosa

セットアップはzendesk MarketplaceからのワンタッチのOAuthで完了し、eeselはヘルプセンターの記事、過去のチケット、マクロを自動的に取り込みます。手動でのトレーニングは不要です。その後、セットアップ中に他のソースと同様にGoogle Driveを追加します。これは他のどこでもGoogle DriveにAIを組み込むのと同じやり方です。同社によれば、導入初週から85%以上のティア1解決率を達成し、セットアップは30分未満とのことです。

このルートがネイティブにはない形で与えてくれるもう一つのものは、本物のリハーサルです。eeselは実際のチケットに触れる前に、過去のzendeskチケットに対してエージェントをシミュレーションでき、Driveドキュメントのどこにギャップがあるか(「返金ポリシー:カバー率28%」)を正確に洗い出すので、事前に埋めることができます。それに比べると、zendesk自身のテストガイダンスは前向き(将来志向)です。テスト環境に接続し、テストメールを流し、ログを見守る形です。どちらも有効な方法ですが、公開前にカバー率の数字を見せてくれるのは片方だけです。

鮮度の問題を並べて比較する

これは、公開から数週間後に静かに噛みついてくる違いです。誰かがDrive内のドキュメントを更新しても、AIは古い回答を返し続けます。

ネイティブコネクタでは、外部ソースはzendeskのおよそ24時間ごとの同期で更新されるため、Driveの編集が顧客に届くまで最大1日かかることがあります。これは安定したポリシー文書には問題ありませんが、配送遅延やサービス障害の告知のように、インシデントの最中に変化する内容にとっては本物のリスクです。「AIは私たちのDriveを読んでいる」とチームに約束する前に知っておきたい類のことです。というのも、一日のうちの一定時間、AIは昨日のDriveを読んでいることになるからです。

それぞれのルートの実際のコスト

どちらもGoogle Driveから回答できます。しかし課金の単位がまったく異なり、本当のお金はその単位の中にあります。

ここに、バス追跡チームの規模、つまり月間約250チケット、5エージェントチームと仮定し、AIがそのほとんどを処理すると想定した試算例があります。

シート料金の項目こそが静かな落とし穴です。ネイティブAIでは、AIが実際に作業したかどうかにかかわらずヘルプデスクのシート分を支払い、その上でさらに解決件数に応じて支払うことになります。eeselの従量課金制の料金体系は1チケットあたり0.40ドルというシンプルな単一の数字で、人間がAIの代わりに対応したチケットについては課金されません。そのギャップこそ、私が話をしたあるヘルスケアプラットフォームのCXリーダーがそもそも他の選択肢を探し始めたきっかけであり、彼らは自社の利用量に対してネイティブのZendesk AIを「不十分で割高」だと感じていました。

ネイティブ側にも公平を期すと、zendeskの検証済み解決モデルは、AIが実際に何かをクローズしたときにのみ課金される仕組みであり、これは会話ごとの一律課金よりも解決あたりの単価をやわらげてくれます。これは本物の改善です。ただし、その下にあるシート料金は、依然として多くのチームが過小評価している項目です。

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

正直な使い分けを述べます。私はzendesk連携を作る側の人間なので、当然ながら中立ではないという前提でお読みください。

• ネイティブのルートAを選ぶべきなのは、 すでにSuite Team以上の料金を支払っていて、知識の大半が整ったヘルプセンター記事で少しだけDriveがある程度であり、そのDriveコンテンツが小さく変化も緩やかで、すべてを一つのzendesk請求書にまとめたい場合です。
• eeselのルートBを選ぶべきなのは、 本当の答えがGoogle Driveと解決済みチケット履歴の両方に眠っていて、AIにその両方を読ませたく、Driveの鮮度を保つことを重視し、シート料金プラス解決件数の計算が痛み始めている場合です。自信満々のボットが誤った答えを出して痛い目にあったことがあるなら、過去のチケットに対するシミュレーションが決め手になります。

どちらも全面的な置き換えではありません。特にルートBは、すでに運用しているzendeskプラットフォームの上に乗る形で設計されているため、既存のセットアップの隣で試すには低リスクです。もっと深く知りたい方には、私たちのzendesk料金の内訳、最良のカスタマーサービスAIのまとめ、そしてAIナレッジベースツールのガイドがさらに詳しく解説しています。まだネイティブ側を調整している段階であれば、Zendesk AI返信設定も次に読む価値があります。

あなたのZendeskでeeselを試す

サポートの回答がGoogle Driveと何千件もの過去のzendeskチケットに散らばっているなら、eeselはまさにその分散状態のために作られています。数分でzendeskに組み込める新入社員のように機能し、Driveのドキュメントとチケット履歴を一緒に読み込み、自律的に動く前にあなたがレビューできる本物の返信を下書きします。まずは自社の過去のチケットに対してシミュレーションを行い解決率を確認でき、クレジットカードなしで無料でお試しいただけます。

自社のDriveフォルダに向けてシミュレーションを実行し、1セントも投じる前に何が解決できるかを確かめてください。