サポートのナレッジギャップ分析：ヘルプセンターに足りないものを見つける方法

サポートのナレッジギャップ分析とは？

サポートのナレッジギャップ分析は、2つのリストを比べます。お客様が実際にサポートチームへ尋ねていること、そしてナレッジベースが実際に答えていること。その差がギャップリストです。うまくやれば、誰も開かない300行のスプレッドシートではなく、書くべき記事、直すべき記事の短い優先順位付きバックログが手に入ります。

私はeeselでAIエージェントを作っており、その仕事を通じてギャップの捉え方が変わりました。AIエージェントはどのお客様よりも注意深くヘルプセンターを読むので、最初に浮かび上がるのは気の利いた答えではありません。ドキュメントに何もなかった、あるいは間違ったことが書かれていたトピックのすべてです。これは役に立ちます。ギャップが空白のページに見えることはめったにないからです。たいていは次の3つのどれかの形をとります。

• 欠けている。 そのトピックを扱う記事がまったくない。最も見つけやすく、最も直しやすいタイプです。
• 古い、または矛盾している。 記事はあるが古い返金期間のままだったり、2つの記事が食い違っていたりする。Gorgiasはこれを「Resolve knowledge conflict」という別の種類として、Opportunitiesフィードに挙げています。
• 読み手に合っていない。 記事は正確だが、別の人の質問に答えている。バス運行追跡サービスからeeselに来た、月200〜250件のZendeskチケットを扱うサポートマネージャーは、ナレッジベース全体が管理者向けに書かれている一方で、チケットは乗客から来ていると気づきました。答えは技術的にはすべてそこにあるのに、どれも役に立っていなかったのです。

3つ目のタイプは、検索レポートでは決して見えません。お客様の検索には結果が返っているからです。ただ、それが間違った結果なのです。だからギャップ分析は、検索だけでなくチケットを見る必要があります。検索のみのアプローチは検索クエリとギャップの対応づけのガイドで扱っており、始め方としては悪くありません。ただし、全体像ではありません。

検索ヒットなしがギャップを過小評価する理由

検索ヒットなしは昔ながらのギャップのシグナルで、どのガイドもここから始めます。問題は、誰を数えているかです。検索ヒットなしが起きるのは、お客様がヘルプセンターを開き、クエリを入力し、何も返ってこなかったときだけです。問い合わせフォームに直行するお客様、注文確認メールに返信するお客様、チャットを開くお客様は、このレポートに現れません。

Help Scoutは、もうひとつの盲点について率直です。Docsレポートは、返信エディタ内のDocs検索バーからの検索とAPI経由の検索を除外するため、自社エージェントの検索ヒットなしも数えられません。エージェントがチケット対応中にヘルプセンターを検索して何も見つからないという状況は、最も強いギャップのシグナルのひとつなのに、標準レポートでは見えません。

チケットは、より大きな話を語ります。Zendesk自身のAutomation potentialヘルプページにあるサンプルレポートでは、アカウントが5,791件の会話を分析し、そのうち719件をナレッジギャップとして判定しました。既存の記事がすでにカバーしていた592件より多い数です。これはデモアカウントでありベンチマークではありませんが、私が見ている傾向と一致します。チケットキューには、検索ログよりも多くの未回答トピックが眠っています。

ですから、検索ヒットなしは分析に残します。ただし、それぞれに盲点を持つ4つの入力のうちのひとつになります。

集めるべき4つのシグナル

以下の各シグナルには、何を捉えるか、何を見逃すか、どこで見つかるかを添えています。初日に4つすべては要りません。最初の1回なら2つで十分です。ただし、そのうち1つはチケット由来にしてください。

1. 検索ヒットなし

お客様が自分の言葉で、何を探していたかを教えてくれるシグナルです。語彙の面では非常に優秀です。お客様は「解約」と検索するのに、記事のタイトルは「サブスクリプションの管理」になっている、といったことが分かります。Help Scoutの検索ヒットなしの直し方のガイドも、まさにその対処を提案しています。記事のKeywordsフィールドに別の言い方を追加するか、トピックが未カバーなら新しい記事を書く、というものです。

確認できる場所：

• Zendesk： 既製のSearchダッシュボードに「Searches with no results」KPIと上位5件のグラフがあり、最大390日分のデータが見られます。検索結果のガイドによります。Suiteプラン、またはKnowledge ProfessionalかEnterpriseを付けたSupportが必要です。
• Help Scout： Reports、Docs、Failed searches表の順に開きます。Standardプランはデータを2年間、PlusとProはアカウントが続く限り保持します。
• HubSpot： ナレッジベース分析に、Service Hub ProfessionalとEnterpriseで「Search terms with no results」が表示されます。HubSpotのナレッジベース分析のガイドによります。
• Gorgias： Help Centerレポートに「No-result searches」KPIがあり、Search terms表を「Has results is false」で絞り込むとバックログになります。また、特定の言語でヒットなしが多い場合、たいていは記事が翻訳されていないことを意味する、とGorgiasは述べています。
• Zoho DeskとFront： Zohoのナレッジベースダッシュボードは、キーワードをPopularとFailedに分けます。Frontのナレッジベースレポートには「failed」ラベルがないため、検索回数が多く、平均結果数が少ないキーワードを探します。

Freshdeskは例外です。ナレッジベース分析のどこにも検索ヒットなしのレポートが見つかりませんでした。そのためFreshdeskでは、ヘルプセンターに独自の分析を加えるか、残りの3つにより多く頼ることになります。そのレポートで実際に何が見られるかは、Freshdeskのナレッジベース事例の記事で扱っています。

2. 記事のないチケットのトピック

これは最大のシグナルですが、多くのチームが飛ばします。以前は、チケットをエクスポートして手でタグ付けすることを意味したからです。すでにチームがチケットのタグ付けを一貫して使っているなら、今でもその方法でできます。前四半期のチケットをタグごとにまとめ、上位のタグごとに記事があるか確認します。ただし、タグはずれていくものなので、手作りのタグレポートは出発点として扱うのがよいでしょう。事前に整理する方法は、チケットタグの扱い方のガイドにあります。

ここではヘルプデスクが追いついてきました。2026年4月30日に開始されたZendeskのAutomation potentialレポートは、毎週、解決済みチケットの過去90日分を読み取り、「Covered by knowledge」と「Knowledge gaps」に振り分け、各トピックに高・中・低のインパクトを付けます。ギャップにカーソルを合わせて Generate article draft をクリックします。SuiteとSupportの全プランに含まれ、管理者専用です。

HubSpotのナレッジベースエージェントは、Service Hub ProfessionalとEnterpriseでベータ提供中で、クローズ済みチケットをスキャンし、「Create article」と「Update article」の両方の下書きを提案します。クローズ済みチケットが最低5件必要で、生成された記事1本につき200 HubSpot Creditsかかります。Professionalに月3,000クレジットが含まれることを考えると、無視できない数字です。GorgiasにはAI Libraryというより遅い版があり、チケット数に基づいて3〜6か月ごとに記事を提案します（英語のみ）。ZohoのZia Ticket to Articleは、1件のチケットの1〜10件の会話を下書きにしますが、これは検出ではなく記録です。

このシグナルが見逃すもの：ベテランエージェントの頭の中にある答えです。経験豊富なエージェントが同じ難しい質問を週に2回、記憶だけで解決していれば、チケットは解決済みに見え、トピックも「カバー済み」に見えるかもしれません。公共部門のIT サービス会社のサポートリーダーは、その年に2人のシニアエージェントが辞める予定で、辞める前にその知識を文書化したいとeeselのチームに語りました。どのチケットレポートも、これをフラグ付けできなかったでしょう。この問題についてはオフショアサポートの知識移転でさらに書いています。

3. AIエージェントが答えられなかった質問

AIエージェントがキューの一部に答えているなら、これは手元で最も精度の高いシグナルです。お客様の検索は、どんな言葉を入力したかを教えてくれます。チケットのタグは、トピックを教えてくれます。試みて失敗したAIエージェントは、質問そのもの、検索したドキュメント、そしてどれにも答えがなかったことを教えてくれます。

FreshdeskのAI Agent StudioにあるImproveタブがよい例です。そのヘルプ記事によると、AIが解決できなかった会話から2種類のインサイトを作ります。トピックを扱う記事がない場合の「New content」と、記事はあるが古い、または誤解を招く場合の「Edit content」です。各カードには何件のチケットに基づくかが表示されるので、大きいものから対応できます。FreshdeskはImproveを2026年9月30日まで全顧客に提供していました。料金ページでは現在Freddy AI Agentの下に掲載され、最初の500セッションが含まれ、その後は100セッションあたり49ドルです。

そのほか：

• Gorgias Opportunities（ベータ、AI Agentのある全プラン）は、AI Agentがあるトピックを繰り返し引き渡すと「Fill knowledge gap」を出し、チケット数と、その元になったチケットのCSVエクスポートを提供します。
• HubSpotのカスタマーエージェントは、Knowledgeを理由とする「Coaching opportunities」を一覧にし、「Knowledge gap」「Knowledge conflict」といった種類があります。パフォーマンスガイドによります。
• Zoho DeskのSupport Specialistエージェントは、ヘルプ記事が見つからないとき、非公開コメント「Stepped away from ticket due to lack of available help article」を残します。Zohoのデジタルエージェントのページによります。レポートはありませんが、そのフレーズそのものでチケットを検索できます。
• Help Scoutには、AI Answers向けのギャップレポートがありません。ベストプラクティスのページは、Beacon Sessionsタブと、Insightsの「Contact helped」「Contact not helped」の区分を案内しており、これは手作業で確認します。

このシグナルが見逃すもの：自信満々の誤答です。AIエージェントがギャップとしてフラグを付けるのは、自分が知らないと分かっているときだけです。記事があいまいだと、それでも答えてしまうことがあります。Zendeskを使う車両テレマティクスのチームは、まさにこれを心配していました。ヘルプセンターに「全モデル」に対応と書かれていたため、ボットが対応していない車種を平気で肯定しかねなかったのです。これは古い、または誤りのタイプのギャップで、「未回答」の件数ではなく、シグナル4か、過去のチケットに対するシミュレーションで見つけます。このリスクをより広く捉えたものがAIのハルシネーションです。

4. 誤り・古い記事に対するエージェントのフラグ

エージェントは1日中ヘルプセンターの記事を読んでいて、どれが間違っているかを知っています。コツは、それを伝えるのをワンクリックにすることです。Zendeskでは、エージェントがチケット内でKnowledgeパネルを開き、段落をハイライトしてフィードバックを追加すると、記事のリンクと元のチケットが付いたチケットが作られます。記事フラグのガイドによります。これにはSuite Growth以上が必要です。FrontのAI repliesハブは、AIの各返信の根拠となるソースを表示し、古い、または誤ったコンテンツを返信ごとにその場で直すアクションを備えています。

ヘルプデスクにどちらもないなら、共有のSlackチャンネルや「KB fix」のチケットタグでも十分機能します。形式よりも習慣のほうが大切です。このシグナルの弱点は、エージェントが回避する術を覚えた記事に気づかなくなることです。だから新入社員が最良のフラグ付け役になります。カスタマーサポートエージェントのオンボーディングのガイドでは、「記事を3本フラグ付けする」を初週のタスクにすることを提案しています。

各ヘルプデスクでナレッジギャップを確認できる場所

並べて比較します。プラン料金は、各ベンダーの料金ページに基づく、年払いでのエージェントまたはシートあたりの月額です。

目につくことが2つあります。1つ目は、AIフラグの列が新しいことです。ほぼすべてが2026年に登場したので、ヘルプデスクのレポートを最後に見たのが1年前なら、もう一度見直してください。記事を提案していたZendeskの旧機能Content Cuesは2025年5月1日に廃止され、Automation potentialレポートがその後継です。2つ目は、ギャップ機能はAIに付いてくることです。FreshdeskとGorgiasは、AIエージェントを通してしかチケット由来のギャップを見つけられないため、AIエージェントを使わないチームは得られるものがかなり少なくなります。

Zendeskには、Suite Professional以上でアーリーアクセス中のナレッジコパイロットもあり、Coverage、Freshness、AI readabilityのスコアを備えています。Freshnessは6か月更新されていない記事で下がり、古くなったコンテンツを確認するのに便利な組み込みのチェックです。特にZendeskをお使いなら、Zendeskのナレッジギャップ分析とZendeskで不足記事を見つける方法の記事でさらに詳しく解説しています。

午後ひとつでできるサポートのナレッジギャップ分析の進め方

5〜50人のエージェントがいるチームなら、私はこの形で進めます。初回は約3時間、その後は毎月1時間未満です。

ステップ1：4つのシグナルを90日分集める

90日は、悪い週をならすには十分長く、答えが変わらない程度には短い期間です。検索ヒットなし、チケットの上位30のタグまたはトピック、AIエージェントのギャップまたは未回答リスト、エージェントのフラグをエクスポートします。出典の列を付けて、ひとつのシートにまとめます。

ステップ2：言い回しではなくトピックでまとめる

「サブスクリプションの解約」「プランをやめたい」「退会するには」は、ひとつのギャップです。行をトピックにまとめ、出典をまたいで件数を合計します。4つのシグナルのうち3つに現れるトピックは本物です。「bitcoin」の検索ヒットなしが2件あるだけのトピックは、おそらく違います。行が数百ある場合、このクラスタリングの工程はLLMが得意ですが、そのグルーピングは必ず確認してください。

ステップ3：件数と、答えがどれだけ固定されているかで並べる

多くのギャップリストがつまずくのはここです。チームは件数だけで並べ、そのうえで「注文はどこ？」の記事を書いてしまいます。しかし、答えがお客様ごとに違うため、どんな記事でも答えられません。

• 件数が多く、毎回同じ答え： 最初に記事を書きます。返金期間、プランの上限、セットアップ手順など。ここでは1本の記事が四半期に数百件のチケットを減らせます。
• 件数が多く、アカウントデータが必要： ドキュメントは書きません。注文状況、請求日、アカウント変更には、記事ではなくデータ連携やアクションが必要です。Gorgias自身のナレッジ最適化ガイドも同じ線引きをしています。買い物客がエージェントに何かをしてほしいときはスキル、情報を求めているときは記事です。
• 件数が少なく、同じ答え： マクロか短いFAQ項目で十分です。過去のチケットからマクロを作る方法のガイドで扱っています。
• 件数が少なく、ケースごとに異なる： 人に任せます。すべてのチケットをコンテンツにする必要はありません。

ステップ4：質問している人のために書く

書く前に、そのトピックの実際のチケットを5件開き、お客様がどう表現しているかを読みます。タイトルにはその言葉を使います。そのうえで、誰が尋ねているのかを確認します。乗客か管理者か、エンドユーザーかアカウントオーナーか。先ほどのバス運行追跡のチームに必要だったのは、記事を増やすことではありませんでした。別の読み手に向けて、同じ答えを書き直すことでした。

HubSpotのナレッジベースエージェントは、これの一種を自動で行い、各提案の根拠となる「Source conversations」を添付します。どのツールで記事を下書きするにしても、編集中は元のチケットを下書きの隣に置いておいてください。

ステップ5：古い記事と矛盾する記事も同じ作業で直す

注目されるのは新しい記事ですが、間違った記事は、欠けている記事よりも大きな害をもたらします。とくにAIエージェントがそれを読むとなればなおさらです。シートを開いているうちに、「Edit content」と「knowledge conflict」の項目をすべて拾い、古い版を直すか削除します。2つの記事が同じ質問に答えているなら、統合します。古くなったヘルプセンターのコンテンツを検出するガイドに、そのためのチェックリストがあります。

ステップ6：30日後に同じトピックを再確認する

ループを閉じましょう。公開から1か月後、そのトピックのチケット数、検索ヒットなし、AIのギャップフラグが減ったかを確認します。減っていなければ、記事はあっても見つけられていないか、本当の質問に答えられていないのです。Zendeskのレポートは毎週更新されます。一方、Gorgiasのopportunitiesはナレッジを変更しても更新されないため、古い項目が自然に消えるのを待つのではなく、新しいデータを比較してください。

ここでの良い成果指標は、そのトピックのデフレクション率、またはそのトピックにおけるAIの解決率です。自分をだまさずに測る方法は、チケットデフレクションのガイドで扱っています。

サポートチームがギャップ発見について語ること

この分析の最もローテクな版は、今でも私が見た中で最良のもののひとつです。Redditのあるマネージャーは、クローズするすべてのチケットに必須項目を追加し、それを毎週のギャップレポートに変えました。

"I have two fields in my ticket resolutions that I draw from: Self Service Possible? Drop down menu with three options. Mandatory. Yes - KB Exists Yes - KB Needed No ... I run a report every Friday for any tickets that have either of the "Yes" answers selected and use that list to either make documentation tickets or notify Line Managers that their staff are raising tickets for well documented issues. Takes me about 15 minutes all in."

Commenter on r/ITManagers

この項目はシグナル2とシグナル4をワンクリックで捉え、カスタムのチケット項目に対応するどのヘルプデスクでも使えます。検索分析だけでは足りないという指摘は、今日のほとんどのツールより古いものです。Dropboxのヘルプセンターに携わっていた人が、2011年にHacker Newsでこう述べています。

"Improving it is a bit more complicated than just getting analytics around how many hits on /help end up searching, reading help articles, and maybe filing tickets. There is a lot more needed to understand which areas of the help center aren't getting enough prominence, which topics are just missing..."

ivankirigin, Hacker News

すでにAI版を自力で組んだチームもあります。あるZendesk管理者は、新しいチケットごとにナレッジベースから答えようとし、できなければ不足している記事を下書きする自動化を作りました。

"If it can't it drafts me an article that would cover it, as well as tells me why."

u/Mjwild91, r/Zendesk

そして、古さの問題のほうが、たいていは手ごわいものです。r/startupsのあるチームは、iOS、Android、Webにまたがってヘルプセンターが遅れていく様子を書いていました。

"I feel that a big part of the challenge is to track which legacy articles are broken by a new feature."

u/19Vicus90, r/startups

だからこそ、四半期に一度だけでなく、リリースのたびに短いギャップチェックを行う意味があるのです。

ナレッジギャップ分析を無駄にするミス

• 検索ヒットなしをリスト全体として扱う。 数えているのは検索した人であって、お客様ではありません。必ずチケット由来のシグナルと組み合わせてください。
• アカウント固有の質問に記事を書く。 「注文はどこ？」に必要なのはページではなく照会です。記事にしても、「お問い合わせください」と書かれたページが増えるだけです。
• 追加するだけで、直さない。 AIエージェントが自信満々に引用する古い記事は、記事がないより悪いものです。矛盾は同じ作業で直しましょう。
• AIの下書きを読まずに公開する。 上の表のどのツールも下書きを保存しますが、どれもあなたのチームほどポリシーを知りません。公開前に、各下書きを元のチケットと照らして読んでください。
• 一度きりで終える。 料金、ポリシー、製品が変わるたびにギャップは再び開きます。上位10トピックの月次チェックで、早期に拾えます。
• ヘルプセンター外のナレッジを無視する。 Confluence、Google Docs、Slackのスレッド、古いマクロにある答えも、ナレッジです。AIやエージェントがそれに届かなければ、お客様にとってはギャップです。サポートチーム向けのAIナレッジマネジメントのガイドで、つなぎ方を扱っています。

サポートのナレッジギャップ分析にeeselを使う

ギャップリストを自動で作りたいなら、最も簡単なのは、AIチームメイトにキューを担当させ、どこでつまずいたかを教えてもらうことです。eeselのAIヘルプデスクチームメイトは、Zendesk、Freshdesk、Gorgias、Front、Help Scoutなどに参加し、ヘルプセンター、マクロ、過去のチケット、Confluence・Notion・Google Driveのドキュメントから学び、返信を下書きまたは送信します。ドキュメントから答えられなかったすべてのタスクは、ナレッジギャップとして記録されます。

Reportsページでは、エージェントが答えるための知識を欠いていた頻度と、それが日ごとにどう変わるかが分かります。ドキュメントは簡潔にこう述べています。"A knowledge gap is your agent telling you something is missing from your documentation." Activityページで任意のタスクを開くと、何を検索し、何が見つかり、ギャップに当たったかどうかが分かるので、間違った答えを、その原因となったドキュメントまでたどれます。

そこから、Update knowledge baseスキル（SkillsページではKB Auto-updaterとして表示）が、ヘルプセンターが答えていない質問を見つけ、不足している記事をチームがレビューできる下書きにします。これはワークスペースごとに有効化する機能なので、タイルに「Contact us」と出ている場合は、eeselのチームが有効にします。また、本番稼働の前に過去のチケットに対してシミュレーションを実行することもできます。各回答を実際にチームが送った内容と照らして採点し、ギャップをチケットのテーマ別に一覧にします。

月に約200〜300件のチケットを英語とフランス語で扱うFront上のあるB2B SaaSチームは、まさにこの組み合わせをeeselに求めました。ユーザーガイド、Slack、社内ナレッジベース、過去のチケットから答えを引き出し、足りないものについてはギャップ検出と記事の下書きを行う、というものです。役割の線引きをはっきりさせておくと、eeselはヘルプセンターのエディタでも検索分析ツールでもないため、シグナル1にはヘルプデスクの検索ヒットなしレポートを使い続けてください。eeselが加えるのはシグナル3で、誰もタグ付けしなくても、すべてのチケットで得られます。プランは料金ページにあるとおり、月額299ドルから500クレジットで、eeselを試すなら、100クレジットを使って自分のチケットで無料で試せます。