%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
HubSpotナレッジベースは、問い合わせの答えを記事として蓄積し、顧客対応や社内共有に活用する仕組みです。作成後の更新と改善まで設計することが運用の要点です。
HubSpotナレッジベースは、問い合わせの答えを記事として蓄積し、顧客対応や社内共有に活用する仕組みです。作成後の更新と改善まで設計することが運用の要点です。
「同じ質問に何度も回答していて、ほかの問い合わせに手が回らない」
「FAQはあるけれど、必要な記事を見つけてもらえない」
「担当者ごとに回答が違い、引き継ぎにも時間がかかる」
——問い合わせ対応を個人の記憶や表計算シートで補っていると、情報の更新漏れや重複が起きやすくなります。
HubSpotナレッジベースとは、Service HubでFAQやヘルプ記事を作成・公開し、顧客が自分で情報を探せるようにする機能です。記事をチケット対応やBreeze顧客対応エージェントにつなぐと、問い合わせの受付から回答、担当者への引き継ぎまでを同じ業務フローで扱いやすくなります。
本記事は「HubSpot初期設定・オンボーディング完全マニュアル｜アカウント作成後にやるべき設定一覧」シリーズの一部です。
本記事は「HubSpot完全ガイド」関連記事です。
この記事でわかること
この記事では、ナレッジベースを作る前の情報整理から公開後の見直しまでを、問い合わせ対応の流れに沿って説明します。記事を単独のFAQで終わらせず、チケットやAIによる案内にどう接続するかも扱います。
- ナレッジベースの役割 — FAQ記事が顧客対応やチケット管理の中で担う役割を整理します。
- 構築とカテゴリ設計 — 記事のテーマ、分類、執筆、公開までの進め方を紹介します。
- Breezeとの連携 — 顧客対応エージェントに記事を参照させる際の準備と確認方法を解説します。
- 社内ナレッジへの応用 — 顧客向け情報と社内向け情報の分け方を整理します。
- 公開後の改善 — 閲覧や検索、チケットの状況から次に見直す記事を決める方法を説明します。
HubSpotナレッジベースを問い合わせ対応の流れに置く
ナレッジベースはFAQを公開する場所であると同時に、問い合わせ対応で繰り返し使う知識を引き継ぐ仕組みです。
問い合わせ受付から解決までをつなぐ
顧客がFAQを読んで解決できれば、チケットを作らずに済む場合があります。記事だけで解決しない問い合わせはチケットとして受け付け、担当者が過去のやり取りや関連情報を見ながら対応します。解決した質問は、記事の追加や修正候補として蓄積できます。
この流れを作るときは、ナレッジベースを独立したWebページとして扱わず、コンタクトの問い合わせ、チケットの対応、解決後の情報更新までをひと続きに考えます。顧客の識別やチケット管理の方法が整っていない場合は、まず受付と対応履歴の整理から始めると、記事がどの業務で役立つか判断しやすくなります。
記事を担当者の記憶に頼らない回答基盤にする
記事を増やすこと自体を目的にせず、問い合わせのたびに「既存記事で案内できたか」「どこに説明が足りなかったか」を記録します。
記事で答えられる質問を増やし、個人の経験をチームで再利用できる形にすることが運用のポイントです。
機能の利用条件を公式情報で確認する
ナレッジベースはService Hub Professional以上で利用できます。プラン構成や機能条件は更新される可能性があるため、契約前にはHubSpotの公式製品ページとアカウント内の利用可否を照合してください。Breeze顧客対応エージェントも、ナレッジソースとしてナレッジベース記事を選択できます（出典：顧客対応エージェントのコンテンツソースを管理する）。
次の表は、プランごとにナレッジベース、記事数上限、カスタムドメイン、分析機能を整理したものです。
| プラン | ナレッジベース | 記事数上限 | カスタムドメイン | 分析機能 |
|---|---|---|---|---|
| Free / Starter | × | — | — | — |
| Professional | ○ | 5,000記事 | ○ | ○ |
| Enterprise | ○ | 10,000記事 | ○ | ○（高度） |
次の画面は、デモ環境のナレッジベース画面（未設定状態）。
機能が利用できる場合も、公開範囲やコンテンツの準備は別途設計が必要です。顧客向けに公開する記事と、担当者だけが参照する手順を区別し、誰が閲覧できるかを記事ごとに確認してから公開します。
問い合わせデータから記事のテーマを決める
ナレッジベースの企画は、思いついた質問を並べるより、実際に届く問い合わせを整理するところから始めます。メールやチケット、担当者のメモに情報が散らばっていると、どの質問が繰り返され、どの回答が古いかを比較しにくくなります。問い合わせの記録を見ながら、記事にする優先順位と更新担当を決めます。
問い合わせを質問のまとまりに分類する
過去のチケットや問い合わせ記録から、顧客が何を知りたいのかを読み取り、似た質問をまとめます。たとえば初期設定、日常操作、エラー時の確認、契約や利用条件など、顧客が探す場面に沿って整理します。社内で使う製品名や工程名と、顧客が実際に使う言葉が異なる場合は、記事タイトルには顧客の表現を優先します。
分類後は、質問の頻度だけでなく、回答にかかる時間や誤案内時の影響も見ます。繰り返し届き、回答手順が共通しているテーマは記事化の候補です。一方、個別事情によって判断が変わるテーマは、一般的な案内と担当者へ相談する条件を分けて記載します。
| 判断の観点 | 記事化しやすい状態 | 個別対応を残す状態 |
|---|---|---|
| 質問の内容 | 同じ目的の問い合わせが繰り返される | 顧客ごとに前提が大きく異なる |
| 回答の根拠 | 手順や条件を共通化できる | 契約や個別判断の確認が必要 |
| 誤案内の影響 | 公開前に手順を検証できる | 誤りが顧客の判断に大きく影響する |
| 次の対応 | 記事内で解決まで案内できる | 担当窓口への引き継ぎが中心になる |
記事の対象読者と公開範囲を決める
同じ操作でも、管理者と一般利用者では必要な説明が異なることがあります。記事の企画時に「誰が、どの状況で、何を完了できればよいか」を決め、対象者に必要な前提知識と操作権限を明記します。社内向け情報を顧客向けの公開場所へ混在させないよう、公開対象も合わせて選びます。
対象を決めずに書き始めると、説明が専門的になりすぎたり、社内用語の解説が抜けたりします。顧客向けに公開する内容は顧客の画面や言葉に合わせ、社内の対応判断やエスカレーション条件は担当者向けの場所に分けます。
小さく始めて構成を見直す
最初から網羅的なサイトを作ろうとすると、記事の整備に時間がかかり、公開後の更新も重くなります。まずは問い合わせ記録から共通性の高いテーマを選び、記事を作成して利用状況を見ます。分類しにくい質問や検索で見つけにくい記事が分かってから、カテゴリを分割・統合します。
カテゴリ数を先に決め打ちするより、顧客がどの言葉で探すか、記事がどの問い合わせを解決するかを基準に調整します。構成の変更が必要になった場合に備え、記事の担当者と更新時に確認する情報も記録しておくと、運用の引き継ぎがしやすくなります。
カテゴリと記事を設計して公開する
記事を探しやすくするには、顧客の目的に沿ったカテゴリと、質問に直接答える本文の両方が必要です。カテゴリの名前が社内の組織や製品構造だけに沿っていると、顧客が自分の問題をどこに分類すればよいか迷うことがあります。顧客が行う作業や困っている状況を軸に、分類を組み立てます。
カテゴリの切り口を選ぶ
カテゴリの切り口には、製品・サービス、利用シーン、利用者の役割などがあります。複数の軸を一度に混ぜると分類が分かりにくくなるため、顧客が最初に選びやすい切り口を主軸にします。
| 切り口 | 向いている情報 | 分類時の確認点 |
|---|---|---|
| 製品・サービス別 | 機能やサービスごとの操作案内 | 顧客が製品名を把握しているか |
| 利用シーン別 | 初期設定、日常操作、問題解決 | 作業の流れに沿って探せるか |
| 利用者別 | 管理者、一般利用者などの役割別手順 | 権限の違いが説明に影響するか |
| 利用者別 | 管理者向け、一般ユーザー向け、開発者向け | 権限の違いが説明に影響するか |
実際のカテゴリは、問い合わせの分類と検索語を見て決めます。ある切り口だけでは記事を見つけにくい場合は、カテゴリを増やす前にタイトルや説明文に顧客が使う語を含められるか検討します。
記事は一つの質問に一つの答えを返す
一つの記事に複数の問題を詰め込むと、顧客も担当者も必要な箇所を見つけにくくなります。記事の冒頭に質問への結論を書き、前提条件、操作手順、うまく進まない場合の確認事項の順に説明します。専門用語は初出時に説明し、画面操作が必要な場合は対象メニューと操作順を具体的に記します。
手順を公開する前には、記載した権限で操作できるか、表示名が実際の画面と一致しているかを確認します。画面や仕様の変更で手順が変わった場合は、古い案内を残したままにせず、内容を更新するか公開を見直します。
初期設定から公開まで進める
HubSpotの画面でナレッジベースを利用できる場合、初期設定、記事作成、公開の順に進めます。表示されるメニュー名や設定項目は契約内容やアカウントの状態で異なることがあるため、画面上の案内と公式ヘルプを照合して操作してください。
| 段階 | 決めること | 次へ進む目安 |
|---|---|---|
| 初期設定 | サイト名、ドメイン、デザイン、ナビゲーション | 顧客がアクセスでき、主要カテゴリを見つけられる |
| 情報設計 | カテゴリ、記事テーマ、対象読者 | 各記事の公開範囲と担当者が定まっている |
| 執筆 | 結論、前提、手順、例外時の対応 | 対象者が記事を読んで次の行動を判断できる |
| 公開 | 公開状態、検索表示、表示内容 | 顧客の視点で記事を開き、手順を確認できる |
公開前には、記事タイトル、本文、画像、リンク、カテゴリ、公開範囲を確認します。記事がトップページや検索から見つかり、説明どおりに操作できる状態になってから公開します。
Breeze顧客対応エージェントと連携する
Breeze顧客対応エージェントは、設定したコンテンツソースを参照して顧客の質問に応答する機能です。ナレッジベースをソースに加えると、FAQを問い合わせ対応の入口で活用できます。ただし、AIの応答を最終判断として扱わず、解決しない質問を担当者へ引き継ぐ条件も合わせて決めます。
参照させる記事を整える
AIが参照する記事は、顧客の質問と回答が対応し、前提条件や例外が読み取れる内容にします。略語や社内用語だけで書かず、回答の根拠となる条件と、該当しないときの次の手順を明記します。古い記事や内容が重複した記事がある場合は、どれを正とするかを整理してからソースに加えます。
記事の質は、AIがどの情報を参照できるかに関係します。誤った内容が残っていれば、AIの案内にも影響する可能性があります。記事の正確性を担当者が確認し、顧客に提示してよい情報だけを公開対象にします。
コンテンツソースと応答を確認する
HubSpotの公式案内では、顧客対応エージェントのコンテンツソースとしてナレッジベース記事を追加・管理できます（出典：顧客対応エージェントのコンテンツソースを管理する）。設定画面で対象記事を選び、顧客が使うチャネルに割り当てた後、想定質問を使って回答と参照元を確認します。
確認では、正しい記事を参照しているか、質問の前提が足りないときに確認を促すか、回答できない場合に担当者へ引き継ぐかを見ます。誤った回答や曖昧な回答が出た場合は、記事の前提や表現を修正し、同じ質問で再確認します。
次の画面はBreezeカスタマーエージェントの設定とプレビューを示しています。設定内容とプレビューで確認できる範囲を照らし合わせ、記事を公開する前のテストに活用します。
AIと担当者の役割を分ける
AIには、記事に基づく基本案内や、担当者へつなぐ前の質問整理を任せられます。
契約の個別判断、例外対応、顧客への最終的な約束は、担当者が内容を確認して判断する運用にします。
AIが解決できない場合の引き継ぎ先と、引き継ぎ時に残す情報を決めておくと、顧客が同じ説明を繰り返す負担を減らせます。
チャット履歴やチケットに対応内容が残るようにし、未解決の質問は記事改善や新規記事の候補へ戻します。こうすると、ナレッジベースは問い合わせの入口だけでなく、対応から得た知識を次の顧客対応に活かす流れの一部になります。
社内Wikiとして使う場合は公開範囲を分ける
ナレッジベースの記事は顧客向けFAQだけでなく、社内の対応手順やオンボーディング資料を整理する用途にも活用できます。顧客向けの記事と社内向けの手順は対象者や機密性が異なるため、同じ場所に並べる前にアクセス方法を確認します。既存の社内Wikiを併用する場合は、どの情報をどちらで管理するかを決めます。
社内で共有する情報を整理する
次のようなものは、社内で再利用する知識の候補です。
- 営業のよくある質問
- サポート時の確認手順
- 新しい担当者向けの操作案内
記事には手順だけでなく、判断に迷ったときの相談先や例外条件も含めます。これにより、特定の担当者に聞かないと進められない業務を減らし、引き継ぎ時にも同じ手順を参照できます。
顧客向け情報と社内情報を混在させない
社内向け記事を顧客向けの公開サイトに置くと、内部の判断基準や連絡先が意図せず共有されるおそれがあります。
公開対象、閲覧制限、パスワード保護など、アカウントで利用できる制御方法を確認し、限定公開のつもりで公開する運用に頼らないようにします。
記事のプレビューだけで判断せず、公開後のURLと実際のアクセス条件を確認します。次のように分けると、更新担当も明確になります。
- 顧客に見せてよい手順 ── 公開記事へ
- 社内判断や対応基準 ── 社内向けの保管場所へ
Notionを併用するときの情報導線を決める
社内WikiをNotionで管理している場合、問い合わせ対応中に必要なFAQや手順へ移動しやすい導線を考えます。Sync for Notionを使うと、チケット対応画面からNotionのページを参照できます（Sync for Notion、HubSpotマーケットプレイス）。
ナレッジベースとNotionに同じ内容を重複して置く場合は、どちらを正本とするか、更新を誰が担当するかを定めます。次のように役割を分けると、内容の食い違いを見つけやすくなります。
- 顧客に公開するFAQ ── ナレッジベース
- 社内の対応手順 ── 既存Wiki
公開後の指標から記事を改善する
公開した記事は、閲覧や検索、チケットの状況を見ながら見直します。数値を集めるだけでは改善につながらないため、どの状態なら記事を追加し、どの状態なら既存記事を修正するかを決めます。対応履歴と記事を同じ流れで確認できると、問い合わせが残った理由を次の改善に反映しやすくなります。
検索と閲覧から不足情報を見つける
閲覧数が多い記事は、顧客がよく参照する情報として、内容が現在も正しいか確認します。検索しても結果が出ない語句は、新しい記事の候補になる場合があります。また、検索結果から記事が開かれない場合は、タイトルやカテゴリが顧客の言葉と合っているか見直します。
| 見る情報 | 状況 | 次に行うこと |
|---|---|---|
| 記事別閲覧 | よく読まれている | 手順やリンクが現在も有効か確認する |
| 検索キーワード | 記事と異なる語が使われている | タイトルや本文に顧客の表現を加える |
| 検索結果なし | 対応する記事が見つからない | 問い合わせ記録を確認し、新規作成か既存記事の拡充を選ぶ |
| 記事評価 | 役立たない評価が続く | 不足している前提や手順を問い合わせ内容と照合する |
| チケットの推移 | 同じ質問が引き続き届く | 記事の見つけやすさと回答範囲を確認する |
問い合わせと記事の間を往復する
チケットが減ったかどうかだけで判断すると、質問の種類や問い合わせ窓口の変化を見落とすことがあります。チケットの内容と検索語を照らし、記事を読んでも解決しなかった理由を分類します。記事が見つからない場合は分類やタイトルを直し、説明不足なら本文を補い、個別判断が必要なら担当者への案内を明確にします。
改善の結果は、記事の更新履歴や担当者が分かる形で残します。次に同じ質問が届いた際に、担当者が改善前後を把握できるため、個人の記憶だけに依存しない運用につながります。
更新の優先順位と担当を決める
情報の変更があったときに誰が記事を直すかが決まっていないと、古い手順が公開されたままになりやすくなります。製品や業務の変更を把握する担当者と記事の編集担当者を結び、変更時に確認する項目を共有します。
一斉に全記事を見直すのが難しい場合は、問い合わせが多い記事、誤案内時の影響が大きい記事、検索結果がない質問に関係する記事から優先します。確認後は、内容を維持する、修正する、公開を止めるのいずれかを決め、次の見直し担当へ引き継ぎます。
よくある質問
HubSpotナレッジベースはどのプランから利用できますか？
この機能はService Hub Professional以上で利用できます。プランや利用条件が更新される場合があるため、契約内容とHubSpot公式の最新案内を確認してください。利用対象でない場合は、既存のWebサイトやブログでFAQを整理する方法も検討できます。
ナレッジベースの記事数に上限はありますか？
利用予定の記事数と契約プランをHubSpotの公式情報で照合し、上限が運用に影響する場合は公開先の構成を見直してください。
Breeze顧客対応エージェントはナレッジベースを参照できますか？
HubSpotの公式案内では、顧客対応エージェントのコンテンツソースとしてナレッジベース記事を管理できます。設定後は想定質問で参照元と回答を確認し、解決できない質問が担当者につながるかもテストします。AIの案内だけで判断しないよう、担当者への引き継ぎ条件を運用に含めます。
社内向けのWikiとして使えますか？
社内の手順や対応基準を整理する用途に応用できます。ただし、顧客向け記事と社内限定情報は公開範囲を分けてください。既存のWikiと併用する場合は、正本と更新担当を決めて重複や内容のずれを防ぎます。
FAQ記事は検索エンジンから見つけられますか？
記事の公開設定やサイトの構成によって、検索エンジンでの表示条件は異なります。検索流入を目的にする場合は、公開範囲、メタ情報、URL、検索エンジンのインデックス状況を確認し、顧客が使う語で記事タイトルを整えます。社内限定の記事は検索対象として公開しない運用にします。
まとめ
HubSpotナレッジベースは、問い合わせへの回答を記事にまとめ、顧客の自己解決、担当者のチケット対応、Breeze顧客対応エージェントの案内に活用する仕組みです。問い合わせ記録からテーマを選び、顧客が使う言葉で記事を作り、公開範囲と更新担当を定めて改善を続けます。
- チケットや問い合わせ記録から、共通する質問と回答の根拠を整理します。
- 対象読者、カテゴリ、公開範囲、更新担当を決めて記事を公開します。
- 検索語や未解決のチケットを確認し、記事の修正か新規作成かを決めます。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
