ナレッジベース（KB）は「顧客が自分で答えを見つけられる図書館」だ。よく設計された KB は顧客の自己解決率を高め、エージェントの反復対応を減らし、Breeze Customer Agent の回答精度を高める——1本の記事がサポートコストを永続的に下げ続ける複利の仕組みだ。この章では設計原則・記事テンプレート・Breeze Knowledge Base Agent による自動生成・カスタマーポータルとの連携・分析と改善サイクルを体系的に解説する。
KB の設計は「まず記事を書く」から始めてはいけない。カテゴリ構造・SEO 設計・記事の粒度——これらを先に決めてから書き始めることで、後から大規模な再編成が不要になる。HubSpot KB は Google 等の検索エンジンにインデックスされるパブリック公開が可能で、サポートページとしてだけでなくオーガニック流入の SEO 資産にもなる。
| SEO 要素 | 設計原則 | 悪い例 → 良い例 |
|---|---|---|
| 記事タイトル | 顧客が検索バーに打ち込む「質問文」に近いタイトルにする。専門用語より自然な言葉を優先する | 「パスワード再設定機能について」→ 「パスワードを忘れた場合の再設定方法」 |
| メタ説明文 | 記事の要約を120〜160文字で書く。検索結果に表示される文章として「読んだら解決できる」と伝わるように書く | 「パスワードに関する記事です」→ 「ログインパスワードを忘れた場合に、メールアドレスから再設定する手順を画像付きで解説します」 |
| URL スラッグ | 日本語ではなく英語で意味のある URL を設定する。HubSpot は自動生成するが、手動で短く修正することを推奨 | 自動生成 /articles/123456 → /password-reset-guide |
KB を0から始めるとき、最初に書くべき記事は「過去3ヶ月で最も多く来た問い合わせカテゴリ TOP10」だ。チケットの「カテゴリ別件数レポート」を確認し、上位10トピックに対して1記事ずつ書くことで、即座に自己解決率向上の効果が出始める。完璧な記事より「早く公開する」ことの方がはるかに重要だ。
KB 記事の品質がばらつくと、顧客が「この記事で解決できるかわからない」という不信感を持ち、結局チケットを送ってしまう。全エージェントが同じテンプレートを使うことで、記事の品質と構造を統一することが重要だ。HubSpot KB エディタはリッチテキスト・画像・動画・コードブロックに対応している。
| 原則 | 説明 | チェックポイント |
|---|---|---|
| ①1記事1トピック | 1本の記事で解決できる問題は1つだけに絞る。複数の問題を詰め込むと検索に引っかかりにくくなり、読者も迷う | 記事タイトルで質問が1つに絞られているか？ |
| ②最初の段落で結論 | 「この記事でわかること」を冒頭に書く。顧客が最初の3秒で「この記事が自分の問題に答えている」と判断できる | 冒頭に「この記事でわかること」があるか？ |
| ③番号付きステップ | 手順がある場合は番号付きリストで書く。「設定 → 〇〇 → 〇〇をクリック」のように画面の操作を具体的に書く | 手順が抜けなく・迷いなく追えるか？ |
| ④注意・例外を明記 | 「この手順はプランによって異なります」「管理者権限が必要です」など例外条件は目立つ注釈ボックスで表示する | 「できない場合」の対処まで書いてあるか？ |
| ⑤関連記事リンク | 記事の末尾に「次に読むべき記事」「関連トピック」をリンクする。顧客がポータル内で自己解決を完結しやすくなる | 関連する記事へのリンクが3本以上あるか？ |
| ⑥更新日を明記・定期更新 | 古い情報のまま放置すると誤案内につながる。製品リリースのたびに該当記事を更新する運用ルールを作る | 最終更新日が6ヶ月以内か？ |
| ⑦フィードバックボタン | 「役立ちましたか？ はい/いいえ」のフィードバックを必ず設置する。「いいえ」のスコアが高い記事を優先的に改善する | フィードバックボタンが設置されているか？ |
HubSpot Service Hub Enterprise では、Breeze Knowledge Base Agent が利用できる。これはチケット対応の成功事例を自動分析し、「こういう記事を作ればいい」という下書きを自動生成するエージェントだ。エージェントが毎回同じ質問に答えるたびに KB が育ち、次回は AI が自己解決する——「対応実績 → KB 記事生成 → AI 解決率向上」という自動フライホイールを実現する。
KB Agent が生成する記事下書きは、解決済みチケットの内容を基にしているため概ね正確だが、製品の最新仕様・スクリーンショット・例外条件は自動では追加されない。「生成 → 公開」を自動化するのではなく、必ず担当者がレビュー・補足してから公開することを運用ルールとして定める。品質管理なしの全自動公開は、顧客への誤案内リスクを高める。
KB Agent は Enterprise 限定のため、Professional プランでは手動で代替フローを作ることになる。実用的な代替アプローチは「週次 KB 棚卸しタスク」だ：毎週金曜に担当者が「その週に3回以上対応した質問」をリストアップし、翌週月曜に記事を1本書いて公開するルーティンを設定する。月4本のペースで積み上げれば、1年で50本の KB が完成する。
カスタマーポータルは、顧客が自分のチケットを確認・追跡し、KB 記事を検索できる「顧客向けマイページ」だ（Service Hub Professional 以上）。ポータルと KB を組み合わせることで「チケット送信の前に KB で解決 → 解決できなければポータルからチケット作成」という理想的な自己解決ファネルが完成する。
2025年3月のアップデートで、カスタマーポータル上の「Tickets（チケット）」という表示名を自社のビジネス言語に変更できるようになった。IT サービス企業なら「インシデント」、製造業なら「依頼」、医療機関なら「相談」——顧客が親しみやすい言葉に変更することで、ポータルの使いやすさが向上する。
| 業種 | デフォルト表示 | カスタマイズ例 | 効果 |
|---|---|---|---|
| IT サービス・SaaS | Tickets | インシデント / リクエスト | ITIL 用語に馴染んでいる IT 担当者が迷わず使える |
| 製造・建設 | Tickets | 依頼 / 案件 | 「チケット」という言葉に慣れていない顧客の心理的ハードルを下げる |
| 医療・クリニック | Tickets | 相談 / お問い合わせ | 親しみやすい言葉でポータル利用率が向上する |
| EC・小売 | Tickets | 注文 / 返品申請 | 顧客が「このページで何ができるか」を直感的に理解できる |
設定場所：サービス → カスタマーポータル。カスタマイズ可能な主な項目は①ポータルのサブドメイン（例：help.御社ドメイン.com）②ブランドカラー・ロゴ③チケットラベル名④表示する KB カテゴリ⑤チケット作成フォームのフィールド⑥「お問い合わせ」ボタンの表示条件（KB 検索後のみ表示など）。「KB 記事を読んだ後にしかチケット作成ボタンが表示されない」設定は、自己解決率向上に特に効果的だ。
KB は「一度作ったら終わり」ではない。顧客がどの記事を読み・何を検索し・何が解決できていないかを継続的に分析し、改善を繰り返すことで KB の価値が高まり続ける。HubSpot KB の分析タブでは検索クエリログ・記事別閲覧数・フィードバックスコアが確認できる。
| 頻度 | 確認項目 | 対応アクション |
|---|---|---|
| 毎週（金曜） | 検索ゼロ結果クエリ一覧・その週に3回以上来た同じ質問 | 翌週に記事1本を新規作成する候補をリストアップ |
| 毎月第1月曜 | 閲覧後チケット作成率 TOP5・フィードバック「いいえ」率 TOP5・6ヶ月未更新記事 | 改善候補記事に担当者をアサインし、月内に改訂して公開する |
| 製品リリース後 | リリースノートと照合し、変更が生じた機能の関連記事を特定 | 48時間以内に関連記事を更新・または新規記事を公開 |
| 四半期 | KB 全体の自己解決率・チケット件数との相関・Customer Agent の解決率推移 | カテゴリ構造の見直し・記事の統廃合・KB ロードマップの更新 |
Breeze Customer Agent は KB・Web サイト・PDF などを学習ソースとして回答するが、最も精度に直結するのはナレッジベースの質と量だ。KB 記事が少ない・古い・曖昧だと、Customer Agent は「申し訳ありませんが、この件についてはサポートにお問い合わせください」と返すだけになる。KB への投資は Customer Agent への投資と同義だと理解して運用する。
繰り返す質問を記事化 → AI・ポータルで自己解決 → 同カテゴリのチケット減少 → より多くの記事化余力が生まれる——このサイクルを意識して KB を構築する。最初の記事は「過去3ヶ月で最も多かった問い合わせ TOP10」から書き始める。
KB → カテゴリ → 記事の3層構造で整理する。カテゴリが多すぎると顧客が迷い、記事が少ないカテゴリは信頼感を下げる。各カテゴリに最低3本の記事が揃ってから公開する。
冒頭の「この記事でわかること」・番号付き手順・注意事項・関連記事リンク・フィードバックボタンを全記事に統一する。品質のばらつきが顧客の「記事を信頼しない」行動につながる。
解決済みチケットから記事下書きを自動生成するが、スクリーンショット・最新仕様・例外条件は自動では追加されない。「生成 → レビュー → 公開」の3ステップを運用ルールとして守る。
顧客がポータル内で検索して記事が見つからなかったキーワードのログが、KB に最も必要な記事のテーマだ。毎週このリストを確認し、翌週に1本書くルーティンを確立する。
Breeze Customer Agent の解決率は KB の質・量に直結する。KB への投資をサポートコスト削減投資と同じ目線で予算・工数を確保する。閲覧後チケット作成率が高い記事の改善が ROI 最大のアクションだ。