%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}
この記事の結論
情報を集める前に、探す人の言葉と行動から、見つけられる構造を設計します。
情報を集める前に、探す人の言葉と行動から、見つけられる構造を設計します。
「回答は社内のどこかにあるはずなのに見つからない」「同じ質問に担当者が繰り返し答えている」「記事を増やしても、利用者が検索結果から選べない」。こうした状況では、記事の追加だけでなく、情報の置き方と更新の仕組みを見直す必要があります。
ナレッジベースとは、組織の知識を整理・蓄積し、必要な人が検索して活用できるようにする場所です。構築を担当する方は、まず利用者の質問を集め、既存の回答を探し、見つからない理由を分けてみてください。この記事では、その結果をカテゴリ、記事、検索語、更新方法に反映する手順を説明します。読み終えたら、記事を追加すべきか、既存記事の入口や内容を直すべきかを判断できます。
本記事は社内Wiki・ナレッジベースカテゴリに属しています。経営管理全体を体系的に学びたい方は経営管理完全ガイドをご覧ください。
この記事でわかること
ナレッジベースを構築する際、記事を増やす前に決めたい設計項目と、公開後に見直す方法を整理します。
- 情報設計の始め方 — 利用者の質問と既存の回答を照合し、情報が見つからない理由を調べます。
- カテゴリの選び方 — テーマ、タスク、対象者、業務の流れを比較し、利用者が選べる入口を決めます。
- 検索しやすい記事の作り方 — タイトル、タグ、メタデータ、記事テンプレートの役割を分けて整えます。
- 公開後の改善方法 — 検索結果のない語や記事への評価から、修正する場所と見直す条件を決めます。
ナレッジベースの情報設計は利用者の探し方から始めます
社内のフォルダやスプレッドシートに情報が分かれていると、同じ内容の別版が残り、どれを参照すべきか判断しにくくなります。最初に、問い合わせや社内で繰り返される質問を集め、「誰が」「どの場面で」「どんな言葉を使って」答えを探すかを記録します。続いて、その答えが現在どこにあるかを確認します。
答えがあるのに見つからない質問と、答え自体がない質問は、必要な作業が異なります。前者は入口や記事の表現を、後者は回答の確認と記事作成を検討します。この順序で調べると、記事を増やす前に直せる問題が見えてきます。
次の図は、利用者の質問を起点にナレッジベースの導線を確かめる手順を示します。
発見可能性・一貫性・最新性を設計基準にする
情報設計では、記事が見つかるか、開いた後に読み進められるか、内容を信頼して使えるかを順に確かめます。問題が見つかった段階によって、戻る作業を変えます。
| 原則 | 内容 | 具体例 |
|---|---|---|
| 発見可能性 | 利用者が必要な情報を直感的に見つけられる | カテゴリ名を業務用語で統一 |
| 一貫性 | 構造やフォーマットが統一されている | テンプレートによる記事構成の統一 |
| 最新性 | 常に最新の情報が掲載されている | 更新日の表示、定期レビュー |
検索しても記事が出てこない場合は、まず記事の有無を確認します。記事があればタイトル、検索語、カテゴリを見直します。記事を開いても手順が読み取れない場合は、回答の位置や説明の順番を見直します。内容が現在の業務と合わない場合は、更新担当者が事実を確認してから修正します。更新日だけを変えても、内容を確認したことにはなりません。
利用者調査から導線のテストまで進める
質問を集めたら、利用者が選ぶカテゴリと、管理者が想定したカテゴリを比べます。記事の見出しを利用者に分類してもらうカードソーティングは、両者の認識のずれを調べる方法の一つです。質問した時点で利用者が選べる名前を入口にし、トップページ、検索、関連記事から目的の記事へ進めるかを確かめます。
導線を作った後は、集めた質問の言葉をそのまま使って探してもらいます。
- 違うカテゴリを選んだなら ── 分類名を確認します
- 検索結果から記事を選べなかったなら ── タイトルを確認します
- 記事を開いても回答が分からなかったなら ── 概要と手順を確認します
どこで止まったかを記録してから直し、同じ質問でもう一度探せるかを確かめてください。
カテゴリは記事の内容より利用者の目的で選びます
情報を管理する部門名と、利用者が選びたい入口は一致するとは限りません。カテゴリ名を決める前に、集めた質問を並べ、利用者が質問した時点で分かることを探します。「何をしたいか」が分かるならタスク、「どの立場で使うか」が分かるなら対象者が入口の候補です。
分類軸を比較して主な入口を決める
分類方法は次のとおりです。記事の主な入口には、利用者が質問した時点で判別できる軸を選びます。別の軸からも探される記事は、関連記事や検索語で補えるかを先に考えます。
| アプローチ | 分類基準 | 適するケース |
|---|---|---|
| テーマ別 | 情報のテーマ・トピック | 幅広いトピックを扱うKB |
| タスク別 | ユーザーが達成したいタスク | 操作手順が中心のKB |
| 対象者別 | ユーザーの役割・職種 | 多様な部門が利用するKB |
| フェーズ別 | 業務の時系列 | オンボーディング向けKB |
複数の軸を組み合わせる場合も、入口ごとに何を基準に選ぶかを説明できる状態にします。たとえば「何をしたいか」で探す質問が中心ならタスクを主な入口とし、対象者によって手順が変わることは記事の冒頭で示します。利用者がカテゴリ名を見ても行き先を決められないなら、分類を細かくする前に名前と軸を見直します。
階層を増やす前に記事の置き場所を確かめる
大カテゴリの下に初期設定、アカウント管理、データインポートなどを置き、さらに具体的な手順やFAQを配置する構造が考えられます。ただし、階層の深さは先に固定せず、利用者が入口から記事まで迷わず進めるかで判断します。
記事が複数のカテゴリに同じくらい当てはまる場合は、まず主な置き場所を決めます。別の入口からも探されるなら、関連記事や検索語で到達できるかを試します。置き場所のない質問が繰り返し現れる場合は、既存カテゴリへ無理に入れず、新しい入口が必要かを質問の内容と照らして判断します。HubSpotでカテゴリ、サブカテゴリ、タグを使う場合の設定対象は、公式資料でも確認できます。
検索語とメタデータを記事の入口として整えます
カテゴリからたどる人と、検索窓に質問を入れる人では、同じ記事への入り方が違います。検索では、利用者が入力する言葉に対応する記事があるかに加え、結果一覧を見てその記事を選べるかを確かめます。結果がない場合と、結果はあるのに選ばれない場合では、見直す場所が異なります。
タグは利用者の言葉に合わせて管理する
まず、問い合わせで使われた言葉と記事のタイトルを比べます。「FAQ」「よくある質問」「Q&A」のような言い換えがあるなら、同じ目的の記事にたどり着けるかを確認します。語を追加する際は命名規則を決め、既存のタグで表せないかを調べてから登録します。
検索結果がない語に対応する記事が存在するなら、タイトルやタグを見直します。結果が多くて選べないなら、似た記事の役割を整理し、タイトルと概要で違いを示します。HubSpotのナレッジベースでは、記事にタグを設定できます。（出典：Manage knowledge base categories, subcategories, and tags、Create and customize knowledge base articles）
メタデータは絞り込みと更新に使う
主なメタデータは次のとおりです。項目を追加する前に、誰が入力し、利用者の判断や担当者の更新作業にどう使うかを決めます。
| メタデータ | 内容 |
|---|---|
| 対象者 | 新入社員 / マネージャー / エンジニア etc. |
| 対象製品 | 製品名・サービス名 |
| 難易度 | 初級 / 中級 / 上級 |
| 最終更新日 | 情報の鮮度を利用者に示す |
| 関連記事 | 関連するKB記事へのリンク |
対象者で手順が変わるなら、メタデータだけに頼らず、記事の冒頭にも対象者を示します。対象製品によって説明が変わるなら、読み始める前に違いが分かるようにします。最終更新日は、内容を確認した担当者と一緒に管理します。入力項目を増やしても使い道が定まらない場合は、まず記事の選択や更新に必要な項目から整えてください。
記事テンプレートは回答から手順へ進める形にします
記事ごとに結論の位置が異なると、利用者は開くたびに答えを探すことになります。テンプレートでは、最初に質問への回答を示し、その後に次を置きます。
- 対象者
- 前提条件
- 手順
- 注意事項
- 関連記事
判断が分かれる箇所は、手順の末尾にまとめず、その判断が必要な場所に条件を書きます。
タイトルと概要で記事を選べるようにする
タイトルは、利用者が入力する質問や達成したい作業が分かる言葉にします。概要には、記事で得られる答えと対象者を示します。検索結果で記事が選ばれない場合は、本文を増やす前にタイトルと概要を点検します。
記事を開いた後で別の記事を探し直しているなら、質問への答えが冒頭にあるか、対象外となる条件が後ろに隠れていないかを確認します。
手順の途中で操作が変わる場合は、「どの条件ならどちらへ進むか」をその場に書きます。
利用者に実際の質問から記事を選んでもらい、必要な手順までたどれることを公開前の確認条件にします。
書き手に頼らない更新の流れを作る
問い合わせで得た回答を記事にする場合は、下書きを作る前に既存記事を検索します。
- 答えがあれば ── その記事の更新を検討します
- 答えがなければ ── 質問と確認済みの回答をテンプレートに沿って下書きにします
公開前には、内容を確認できる担当者が、対象者、前提条件、手順を見直します。
問い合わせで以前の手順が通用しないと分かったときも、更新対象として記録します。どの質問や変更を受けて見直したかを残せば、次の担当者が確認すべき箇所を追えます。確認が終わるまで利用者に示す説明も点検し、古い手順をそのまま案内しないようにします。
AI検索と問い合わせ対応は記事の品質を先に整えます
自然言語による検索やAIを使った問い合わせ対応でも、参照する記事の対象者や前提条件が曖昧なら、回答が適切かを確かめにくくなります。
まず、記事を単独で読んだ人が「自分に当てはまるか」「次に何をするか」を判断できる状態にします。
AIに渡す記事と人が判断する内容を分ける
HubSpotの顧客対応エージェントは、既存のHubSpotコンテンツを回答に利用でき、プレビューとテストもできます。（出典：Set up the customer agent）関連記事：HubSpotナレッジベースの活用方法。
テストでは、実際の問い合わせに近い質問を使い、回答の内容だけでなく参照した情報源も確認します。
- 記事に答えがあるのに誤った説明が出るなら ── 対象者や前提条件の書き方を見直します
- 記事に答えがないなら ── 確認済みの回答を記事に反映します
- 質問ごとに判断が変わるなら ── 記事だけで完結させず、人へ引き継ぐ条件を決めます
社内Wikiと顧客対応のつながりを考える
社内向けの説明と顧客向けの回答には、共有できる情報と分けるべき情報があります。
- 公開できる内容だけ ── 顧客向けの記事に置きます
- 社内の判断手順は ── 参照権限を考えて管理します
問い合わせから新しい質問が見つかったら、回答を確認したうえで、顧客向け記事へ反映するか、社内向けに残すかを決めます。
社内WikiやFAQをNotionで運用し、HubSpotのチケット対応画面から参照したい場合は、Sync for Notionの情報も確認できます。
導入を判断する際は、HubSpotマーケットプレイスの掲載ページで利用条件と機能を確認し、現在の情報の置き場所と必要な参照方法に合うかを比べてください。
公開後は検索できなかった質問から改善します
公開時の分類を完成形と考えず、利用者の検索語、記事への評価、繰り返される問い合わせを見て、どこで回答への道筋が止まったかを調べます。指標を眺めるだけで終えず、分類、タイトル、本文、更新のどこを直すかに結びつけます。
指標を改善の問いに読み替える
次の表は、計測項目と見方を整理するための例です。「目標値（例）」の数値は共通の達成基準や効果の見込みを示すものではありません。採用する前に、自社で何を計測できるか、分母と分子をどう定義するか、現在の状況と比べて何を改善したいかを確認してください。
| KPI | 計測方法 | 目標値（例） |
|---|---|---|
| 検索ヒット率 | 検索クエリに対して結果が返る割合 | 90%以上 |
| 自己解決率 | KB閲覧後に問い合わせに至らなかった割合 | 70%以上 |
| 記事満足度 | 各記事の「役に立った」評価の割合 | 80%以上 |
| 更新鮮度 | 最終更新日が3ヶ月以内の記事の割合 | 80%以上 |
| カバレッジ | 問い合わせトピックに対するKB記事の網羅率 | 85%以上 |
検索しても結果がないなら、対応する記事の有無を調べます。記事があればタイトルやタグを、なければ回答を確認して記事化を検討します。結果はあるのに問い合わせが続くなら、対象者、前提条件、手順の抜けを調べます。記事への評価が低い場合は、評価だけで原因を決めず、どの質問に答えられなかったかを確認します。ナレッジマネジメントとはの記事でも、ナレッジ活用の効果測定を扱っています。
計測できる項目から見直しの順番を決める
HubSpotでナレッジベースを開くには、アカウントの「More」から「Service」>「Knowledge Base」へ進みます。「More」が表示されない場合は、「Service」>「Knowledge Base」へ直接進みます。（出典：Analyze knowledge base performance）
閲覧後に問い合わせがなかったことだけで、利用者が解決したとは判断できません。検索結果を選べたか、記事への評価はどうか、同じ質問の問い合わせが続いていないかを合わせて見ます。修正後は同じ言葉で検索し、想定した記事を選んで回答まで進めることを確認します。計測できない指標には仮の数値を置かず、取得できる検索語や記事への反応から改善を始めます。
よくある質問
ナレッジベースの記事数はどのくらい必要ですか？
記事数を先に決めるより、繰り返し寄せられる質問に答えられるかを確認します。質問を既存記事で答えられるものと、答えがないものに分けてください。記事があっても見つからないなら、まずタイトル、カテゴリ、検索語を見直します。答えがない場合は内容を確認できる担当者を決めてから記事を作り、同じ質問で探せるかを確かめます。
社内向けと顧客向けのナレッジベースは分けるべきですか？
公開できる情報と社内で判断する情報を洗い出し、利用者と参照権限を決めてから構成を選びます。同じ質問を扱う場合でも、顧客向けには確認済みの回答を示し、社内向けには判断や引き継ぎに必要な手順を置く方法があります。どちらかの記事を更新した際に、もう一方も確認する条件と担当者を記録してください。
ナレッジベースの記事は誰が書くべきですか？
問い合わせに答える担当者が質問と回答の下書きを残し、内容を確認できる担当者が公開前に見直す流れが考えられます。まず既存記事を確認し、答えがあれば更新、なければ新規作成を選びます。公開後に手順の変更や同じ質問が見つかったとき、誰が確認するかまで決めておくと運用を続けやすくなります。
記事はどこで分割すべきですか？
異なる目的の手順や、対象者によって前提が変わる説明が混在したら、記事を分ける候補です。一方、作業を完了するまで続けて読む必要がある手順は、見出しを付けて同じ記事にまとめる方法があります。分割後は、それぞれのタイトルで目的が分かるか、必要な場合に記事間を行き来できるかを確かめてください。
まとめ
ナレッジベースの構築は、利用者の質問を集め、既存の回答と照らし、見つからない理由を分けるところから始まります。
- 答えがあるなら ── カテゴリ、タイトル、検索語、本文のどこで止まるかを調べます
- 答えがないなら ── 内容を確認し、対象者と前提条件を示した記事を作ります
公開後も同じ質問で探し直し、回答まで進めるかを確かめてください。
企業様によって最適な形は異なります。まずは繰り返し寄せられる質問を選び、利用者が使う言葉で既存の回答を探してみてください。その結果をもとに、入口の修正、内容の更新、記事の追加のどれから着手するかを決められます。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。現在の質問、記事の置き場所、検索で見つからない場面を共有いただければ、ナレッジベースの構成と更新の進め方を一緒に整理できます。
あわせて読みたい
このテーマと関連する内容を、次の記事でも詳しく解説しています。
- 社内Wikiの作り方｜ゼロから構築して全社に定着させるまでの実践ガイド
- 社内FAQの作り方｜FAQ設計とAIチャットボット連携
- ナレッジマネジメントのKPIと効果測定｜知識活用の成果を数値で可視化する方法
- 文書管理ルールの策定方法｜命名規則・フォルダ構造・保存期限の設計ガイド
- SOPの作り方｜標準作業手順書を効果的に作成する手順・テンプレート・運用ポイント
経営管理の理解をさらに深めるために、社内FAQの作り方もあわせてご覧ください。質問を記事にまとめる際の構成や、回答を探しやすくする方法を確認できます。また、社内Wikiツール比較では、情報の置き場所を選ぶ際に比較したい観点を確認できます。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
