ナレッジベースの作り方：記事、検索、権限、AIによる回答

ナレッジベースとは、検索できる回答の図書館のことです。何かのやり方、何かの直し方、ルールの内容などを探せます。作るには、いくつかの明確なカテゴリにまとめた記事、ライターが実際に使う編集ツール、利用者が実際に入力する言葉から正しい記事を見つける検索、そして誰が何を読めるかの決定が必要です。その対象は、一般公開、ログイン済みの顧客、またはスタッフのみのいずれかです。AIアプリビルダーは、短い作業で構造、エディタ、検索を生成できます。ただし、ナレッジベースを役立つものにするのは、文章と日々の更新です。最初の日から、編集しやすい設計にし、古くなった記事に気づける仕組みを用意してください。

まず、誰のためのものかを決める

同じ機能でも、まったく異なるサイトに使われます。

• 公開のヘルプセンター。顧客や見込み客向けです。速く、検索エンジンにインデックスされ、利用者の言葉で書かれている必要があります。
• 顧客専用のドキュメント。有料顧客やパートナー向けに、ログインの後ろに置きます。
• 社内ナレッジベース。スタッフ向けの方針、手順、やり方を掲載します。非公開である必要があり、デザインよりも検索と鮮度が重要です。

公開記事と社内記事を1つのサイトに混在させると、情報漏えいの大半が起きます。両方が必要なら、記事ごとに明確な公開範囲を設定するか、2つの別々のサイトを運用してください。

アプリに必要なもの

データ

2つのフィールドが大きな役割を果たします。担当者（その記事を正確に保つ責任者）と、最終確認日時（誰かが最後にまだ正しいと確認した日時）です。この2つがあれば、6か月間誰も確認していない記事を一覧にできます。

ページ

• 閲覧画面：検索とカテゴリがあるトップページ、カテゴリページ、目次、関連記事、「この記事は役に立ちましたか？」のフォームを備えた記事ページ。
• 編集画面：フィルター（下書き、古い記事、評価が低い記事）付きの記事一覧、プレビュー付きのエディタ、改訂履歴。
• 管理画面：カテゴリ、ユーザーと役割、結果が0件だった検索のレポート。

権限

閲覧者は、閲覧を許可された公開済みの記事だけを見られます。編集者は記事を作成・編集できます。カテゴリごとに制限する場合もあります。管理者は公開、アーカイブ、ユーザー管理を行います。社内のナレッジベースでは全員がログインする必要があります。公開のヘルプセンターでは、ライターだけがログインします。

判断事項とトレードオフ

エディタ：Markdownかリッチテキストか

Markdownは素早く、移植性が高く、版管理とも相性が良い一方、敬遠するライターもいます。見出し、リスト、画像、注意書き、コードブロックを備えたリッチテキストエディタは、なじみがあります。どちらを選ぶにしても、後でエクスポートできる形式でコンテンツを保存してください。

検索

数百件程度の記事なら、タイトル、要約、本文を検索対象にし、タイトルの一致を上位に表示する基本的なデータベースのテキスト検索で十分です。それ以上の件数になったり、誤字や言い換え（「請求書」と「請求」など）が重要になったりする場合は、本格的な全文検索やホスト型の検索サービスを使ってください。検索の追加ガイドで選択肢を解説しています。結果が0件だった検索はすべて記録してください。それは、書くべき記事の無料のリストになります。

AIによる回答

記事から回答する「質問する」ボックスは、今では一般的です。関連性の高い部分を取り出し、言語モデルにその部分だけから回答させる仕組みです。RAGとはを参照してください。出典の記事は必ず表示し、「わかりません」という回答を許可し、記事に古い情報があれば、AIが自信を持ってそれを繰り返すことを忘れないでください。記事がしっかり整ってから作り、先に作らないでください。

版管理と確認

改訂履歴を残し、誰が何を変えたかを確認して、元に戻せるようにしてください。規制のある内容（人事方針や安全手順など）は、変更を公開する前に承認のステップを追加してください。

うまくいく最初のプロンプト

Parcellyという、小規模なオンラインショップ向けの配送ラベルアプリのための公開ヘルプセンターを作ってください。トップページには大きな検索ボックスと、6つのカテゴリ（はじめに、ラベルの印刷、配送業者、請求、返品、トラブルシューティング）を置いてください。記事には、タイトル、要約、画像と注意書き付きのMarkdown本文、カテゴリ、タグ、ステータス（下書き、公開、アーカイブ）、担当者、最終確認日を持たせてください。記事ページには、目次、関連記事、任意のコメント付きの「この記事は役に立ちましたか？」の はい／いいえ を表示してください。検索はタイトル、要約、本文を対象にし、タイトルの一致を最上位にしてください。すべての検索語と結果の有無を記録してください。編集画面（ログイン必須、役割は編集者と管理者）では、下書き、180日間確認されていない記事、役に立つ評価が低い記事を一覧にし、改訂履歴を保持してください。各記事には、検索エンジン向けに固有のページタイトルとメタディスクリプションを付けてください。清潔感があり、落ち着いて読みやすいデザインにし、スマートフォンを優先してください。

構築の手順

1. 実際のサポート問い合わせから、最初の20〜30記事を書き出す。何かを作る前に行います。このリストがカテゴリを決めます。
2. サイトを生成し、スマートフォンでの読みやすさを確認する。行の長さ、見出し、画像を確認します。
3. エディタと役割を設定する。ライターは開発者に頼らず、記事を追加・修正できる必要があります。
4. 検索を作り、利用者が実際に使う言葉（誤字を含む）でテストする。
5. フィードバックと検索ログを作る。
6. 古い記事のレポートを作る。担当者と最終確認日に基づきます。
7. 公開サイトのSEOの基本を整える。ページタイトルと説明文を固有のものにし、URLを分かりやすくし、サイトマップを作ります。AIで作ったサイトのSEOを参照してください。
8. 製品やサポートの返信からリンクを張り、結果が0件の検索ログを毎週確認する。
9. 内容がしっかりしたら、AIによる回答を追加する。

よくある失敗

• 部署ごとに整理する。読者が何をしようとしているかではなく、組織図に沿って分けてしまう。
• 1つの記事に5つのタスクを詰め込む。1記事1タスクにし、何を解決するかが分かるタイトルを付けてください。
• 記事ごとの担当者がいない。誰も更新せず、最初に間違った回答が出た時点で信頼が落ちます。
• 公開記事に社内メモを載せる。公開範囲を分けて、公開前に確認してください。
• タイトルにしか一致しない検索。読者は記事名ではなく、症状を入力します。
• 代替テキストや文脈のないスクリーンショット。すぐに古くなるので、手順は言葉でも説明してください。

既製の製品が適している場合

チームが既にドキュメントツールやウィキを使っているなら、そこに社内のナレッジベースを作るのが最も抵抗の少ない道です。NotionとConfluenceの比較では、よくある2つの選択肢を扱っています。ヘルプデスク製品を使っているなら、その内蔵のヘルプセンターがチケットと記事をつなぎ、顧客に記事を提案してくれます。これは再現が難しい機能です。開発者向けのドキュメントは、コードと一緒に置くドキュメントサイトジェネレーターが理想的です。

独自の構造や権限が必要な場合（顧客ごと、拠点ごと、役割ごとの記事）、製品の内部にナレッジベースを置きたい場合、ウィキにはない審査や承認の手順が必要な場合、別のサブスクリプションなしで自社の内容に対するAIの回答が欲しい場合は、自分で作るのが適しています。カスタムのヘルプデスクと組み合わせると自然です。

Mythexで作る

Mythexでは、チャットでナレッジベースを説明すると、ライブプレビューで構築されます。記事、改訂履歴、フィードバックは、必要に応じてエージェントが追加するPostgresデータベースに保存され、画像はプロジェクトのファイルストレージに入ります。Mythexには組み込みのエンドユーザー向けログインがないため、編集者のログインは、自分で選んだ認証方式を使います。AIによる回答には、AIプロバイダーのAPIキーをプロジェクトのシークレットとして保存して使います。利用料はMythexのクレジットではなく、プロバイダーのアカウントに請求されます（AIのレシピ）。新しいMythexアプリは、既定でクライアントサイドでレンダリングされるReactの単一ページアプリです。これは検索エンジンに弱いため、公開のヘルプセンターでは、静的に配信しやすい構成やNext.jsなどのサーバーサイドレンダリングの構成を依頼してください（SEOのレシピ）。

最初のプロンプトには、製品ナレッジハブやチームのドキュメントアプリのテンプレートが役立ちます。

よくある質問